/dev/random, 'n kriptografies veilige pseudo-ewekansige getalgenerator (CSPRNG), is bekend om een irriterende probleem te hê: blokkering. Hierdie artikel verduidelik hoe jy dit kan oplos.
Oor die afgelope paar maande is die fasiliteite vir die generering van ewekansige getalle in die kern effens herwerk, maar probleme in hierdie substelsel is in die loop van die breër opgelos. . Die meeste is gemaak om te verhoed dat die getrandom()-stelseloproep vir 'n lang tyd blokkeer wanneer die stelsel begin, maar die onderliggende rede hiervoor was die blokkeergedrag van die ewekansige poel. 'n Onlangse pleister sou hierdie swembad verwyder het en daar sou verwag word dat dit na die hoofkern sou mik.
Andy Lutomirski het die derde weergawe van die pleister aan die einde van Desember gepubliseer. Hy dra by "twee groot semantiese veranderinge aan ewekansige Linux API's". Die pleister voeg 'n nuwe GRND_INSECURE-vlag by die getrandom()-stelseloproep (alhoewel Lutomirsky daarna verwys as getentropy(), wat in glibc geïmplementeer word deur gebruik te maak van getrandom() met vaste vlae); hierdie vlag veroorsaak dat die oproep altyd die hoeveelheid data wat versoek word terugstuur, maar sonder om te waarborg dat die data ewekansig is. Die kern sal eenvoudig sy bes doen om die beste ewekansige data te produseer wat dit op die gegewe tydstip het. "Seker die beste ding om te doen is om dit 'ONSEKER' te noem (onseker) om te verhoed dat hierdie API gebruik word vir dinge wat sekuriteit benodig."
Die kolle verwyder ook die blokkerende swembad. Die kern hou tans twee ewekansige datapoele in stand, een wat ooreenstem met /dev/random en die ander met /dev/urandom, soos beskryf in hierdie 2015. Die blokkeerpoel is die swembad vir /dev/random; lees vir daardie toestel sal blokkeer (wat sy naam beteken) totdat "genoeg" entropie van die stelsel versamel is om die versoek te bevredig. Verdere leeswerk van hierdie lêer word ook geblokkeer as daar nie genoeg entropie in die swembad is nie.
Die verwydering van die slotpoel beteken dat die lees van /dev/random soos getrandom() optree met vlae wat op nul gestel is (en die GRND_RANDOM-vlag in 'n noop verander). Sodra die kriptografiese ewekansige getalgenerator (CRNG) geïnisialiseer is, sal lees van /dev/random en oproepe na getrandom(...,0) nie blokkeer nie en sal die gevraagde hoeveelheid ewekansige data terugstuur.
Lutomirsky sê: “Ek glo dat die Linux-blokkeerpoel verouderd geraak het. CRNG Linux genereer uitset wat goed genoeg is om selfs vir sleutelgenerering gebruik te word. Die blokkeerpoel is nie sterker in enige wesenlike sin nie en vereis baie infrastruktuur van twyfelagtige waarde om dit te ondersteun.”
Die veranderinge is gemaak met die doel om te verseker dat bestaande programme nie werklik geraak sal word nie, en in werklikheid sal daar minder probleme wees met lang wag vir dinge soos GnuPG-sleutelgenerering.
“Hierdie episodes mag nie enige bestaande programme ontwrig nie. /dev/urandom bly onveranderd. /dev/random blokkeer steeds onmiddellik met opstart, maar dit blokkeer minder as voorheen. getentropy() met die bestaande vlae sal 'n resultaat gee wat net so geskik is vir praktiese doeleindes as voorheen."
Lutomirsky het opgemerk dat dit steeds 'n ope vraag is of die kern sogenaamde "ware ewekansige getalle" moet verskaf, wat is wat die blokkerende kern veronderstel was om te doen tot 'n sekere mate. Hy sien net een rede hiervoor: "voldoening aan regeringstandaarde." Lutomirsky het voorgestel dat as die kern dit sou verskaf, dit deur 'n heeltemal ander koppelvlak gedoen moet word, of dit moet na gebruikersruimte geskuif word, wat die gebruiker toelaat om rou gebeurtenismonsters te haal wat gebruik kan word om so 'n slotpoel te skep.
Stephan Müller het voorgestel dat sy stel vir Linux Random Number Generator (LRNG) (tans weergawe 26 vrygestel) kan 'n manier wees om ware ewekansige getalle te verskaf vir toepassings wat dit nodig het. LRNG "voldoen ten volle aan SP800-90B-riglyne oor entropiebronne wat gebruik word om ewekansige stukkies te genereer," wat dit 'n oplossing maak vir die probleem met regeringstandaarde.
Matthew Garrett het beswaar gemaak teen die term "ware ewekansige data", en het opgemerk dat die toestelle wat gemonster is, in beginsel presies genoeg gemodelleer kan word om hulle voorspelbaar te maak: "ons neem nie kwantumgebeurtenisse hier nie."
Müller het geantwoord dat die term van die Duitse standaard AIS 31 kom om 'n ewekansige getalgenerator te beskryf wat slegs 'n resultaat produseer "teen dieselfde tempo as wat die onderliggende geraasbron entropie produseer."
Terminologieverskille tersyde, om 'n toesluitpoel te hê soos voorgestel deur die LRNG-kolle sal bloot tot verskeie probleme lei, ten minste as dit sonder voorregte toegang verkry word.
Soos Lutomirsky gesê het: “Dit los nie die probleem op nie. As twee verskillende gebruikers dom programme soos gnupg gebruik, sal hulle mekaar net dreineer. Ek sien dat daar tans twee hoofprobleme met /dev/random is: dit is geneig tot DoS (d.w.s. hulpbronuitputting, kwaadwillige invloed of iets soortgelyks), en aangesien geen voorregte vereis word om dit te gebruik nie, is dit ook geneig tot misbruik. Gnupg is verkeerd, dit is 'n totale ineenstorting. As ons 'n nuwe onbevoorregte koppelvlak byvoeg wat gnupg en soortgelyke programme sal gebruik, sal ons weer verloor."
Mueller het opgemerk dat die byvoeging van getrandom() GnuPG nou sal toelaat om hierdie koppelvlak te gebruik, aangesien dit die nodige waarborg sal bied dat die swembad geïnisialiseer is. Gebaseer op gesprekke met GnuPG-ontwikkelaar Werner Koch, glo Mueller dat die waarborg die enigste rede is waarom GnuPG tans direk vanaf /dev/random lees. Maar as daar 'n onbevoorregte koppelvlak is wat vatbaar is vir ontkenning van diens (soos /dev/random vandag is), voer Lutomirsky aan dat dit deur sommige toepassings misbruik sal word.
Theodore Yue Tak Ts'o, ontwikkelaar van Linux se ewekansige getal-substelsel, het blykbaar van plan verander oor die behoefte aan 'n blokkeerpoel. Hy het gesê dat die verwydering van hierdie poel effektief ontslae sal raak van die idee dat Linux 'n ware ewekansige getalgenerator (TRNG) het: "dit is nie nonsens nie, want dit is presies wat *BSD nog altyd gedoen het."
Hy is ook bekommerd dat die verskaffing van 'n TRNG-meganisme bloot as 'n lokaas vir toepassingsontwikkelaars sal dien en glo dat dit in werklikheid, gegewe die verskillende soorte hardeware wat deur Linux ondersteun word, onmoontlik is om TRNG in die kern te waarborg. Selfs die vermoë om slegs met toerusting met wortelvoorregte te werk, sal nie die probleem oplos nie: "Toepassingsontwikkelaars spesifiseer dat hul toepassing as wortel vir sekuriteitsdoeleindes geïnstalleer word, sodat dit die enigste manier is waarop jy toegang tot die 'regtig goeie' ewekansige nommers kan kry."
Mueller het gevra of Cao die blokkeerpoel-implementering wat hy self lankal voorgestel het, laat vaar het. Cao het geantwoord dat hy van plan is om Lutomirsky se pleisters te neem en is aktief teen die toevoeging van 'n blokkerende koppelvlak terug na die kern.
“Die kern kan geen waarborge gee of die geraasbron behoorlik gekarakteriseer is nie. Die enigste ding wat 'n GPG- of OpenSSL-ontwikkelaar kan kry, is 'n vae gevoel dat TRUERANDOM "beter" is, en aangesien hulle meer sekuriteit wil hê, sal hulle dit ongetwyfeld probeer gebruik. Op 'n stadium sal dit geblokkeer word, en wanneer 'n ander slim gebruiker (dalk 'n verspreidingspesialis) dit in die init-skrip invoeg en die stelsels ophou werk, sal gebruikers net by Linus Torvalds self moet kla."
Cao bepleit ook dat kriptograwe en diegene wat TRNG eintlik nodig het 'n manier gee om hul eie entropie in gebruikersruimte te oes om te gebruik soos hulle goeddink. Hy sê dat die insameling van entropie nie 'n proses is wat deur die kern uitgevoer kan word op al die verskillende hardeware wat dit ondersteun nie, en die kern kan ook nie die hoeveelheid entropie wat deur verskillende bronne verskaf word, skat nie.
"Die kern behoort nie verskillende geraasbronne saam te meng nie, en dit moet beslis nie probeer beweer dat hy weet hoeveel stukkies entropie dit kry wanneer dit 'n soort "twitchy entropy game" op 'n verregaande eenvoudige SVE probeer speel argitektuur vir verbruikersgebruikers. IOT/Ingeboude gevalle waar alles nie gesinchroniseer is met 'n enkele meester-ossillator, waar daar geen SVE-instruksie is om 'n register te herrangskik of te hernoem nie, ens.
“Jy kan praat oor die verskaffing van gereedskap wat hierdie berekeninge probeer doen, maar sulke dinge moet op elke gebruiker se hardeware gedoen word, wat eenvoudig nie prakties is vir die meeste verspreidingsgebruikers nie. As dit slegs vir kriptograwe bedoel is, laat dit dan in hul gebruikersruimte gedoen word. En laat ons nie GPG, OpenSSL, ens. vereenvoudig sodat almal sê "ons wil "ware willekeurigheid" hê en sal nie met minder tevrede wees nie." Ons kan praat oor hoe ons koppelvlakke aan kriptograwe verskaf sodat hulle die inligting kan kry wat hulle benodig deur toegang te verkry tot die primêre geraasbronne, geskei en benoem, en miskien kan die geraasbron homself op een of ander manier aan 'n biblioteek- of gebruikersruimtetoepassing verifieer."
Daar was 'n mate van bespreking oor hoe so 'n koppelvlak kan lyk, aangesien daar byvoorbeeld sekuriteitsimplikasies vir sommige gebeurtenisse kan wees. Cao het opgemerk dat sleutelbordskanderingkodes (d.w.s. toetsaanslagen) in 'n poel gemeng word as deel van entropieversameling: "Om dit in gebruikersruimte in te bring, selfs deur 'n bevoorregte stelseloproep, sou om die minste te sê onverstandig wees." Dit is heel moontlik dat ander gebeurtenistydsberekeninge 'n soort inligtinglekkasie deur sykanale kan veroorsaak.
Dit lyk dus of 'n langdurige probleem met Linux se ewekansige getalsubstelsel op pad is na 'n oplossing. Die veranderinge wat die ewekansige getal-substelsel onlangs ondergaan het, het eintlik net tot DoS-kwessies gelei tydens die gebruik daarvan. Nou is daar doeltreffende maniere om die beste ewekansige getalle te kry wat die kern kan verskaf. As TRNG steeds wenslik is op Linux, sal hierdie fout in die toekoms aangespreek moet word, maar dit sal waarskynlik nie binne die kern self gedoen word nie.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com