/dev/random, in kryptografysk feilige pseudo-willekeurige nûmergenerator (CSPRNG), is bekend om ien ferfelend probleem te hawwen: blokkearjen. Dit artikel ferklearret hoe't jo it kinne oplosse.
Yn 'e ôfrûne moannen binne de foarsjenningen foar generaasje fan willekeurige nûmers yn' e kernel in bytsje opnij bewurke, mar problemen yn dit subsysteem binne yn 'e rin fan' e bredere oplost . It meast waarden makke om foar te kommen dat de getrandom () systeemoprop foar in lange tiid blokkearje as it systeem opstart, mar de ûnderlizzende reden hjirfoar wie it blokkearjende gedrach fan 'e willekeurige pool. In resinte patch soe dit swimbad fuortsmiten hawwe en it soe nei de haadkearn wurde ferwachte.
Andy Lutomirski publisearre de tredde ferzje fan 'e patch ein desimber. Hy draacht by "twa grutte semantyske feroarings oan willekeurige Linux API's". De patch foeget in nije GRND_INSECURE flagge ta de getrandom () systeem oprop (hoewol't Lutomirsky ferwiist nei it as getentropy (), dat wurdt útfierd yn glibc mei help fan getrandom () mei fêste flaggen); dizze flagge feroarsaket de oprop altyd werom it bedrach fan frege gegevens, mar sûnder garandearje dat de gegevens is willekeurich. De kernel sil gewoan syn bêst dwaan om de bêste willekeurige gegevens te produsearjen dy't it hat op 'e opjûne tiid. "Wierskynlik it bêste ding om te dwaan is it 'ûnfeilich' te neamen (ûnfeilich) om te foarkommen dat dizze API brûkt wurdt foar dingen dy't feiligens nedich binne."
De patches ferwiderje ek it blokkearjende swimbad. De kernel ûnderhâldt op it stuit twa willekeurige gegevenspools, ien dy't oerienkomt mei /dev/random en de oare mei /dev/urandom, lykas beskreaun yn dit 2015. It blokkearjende swimbad is it swimbad foar /dev/random; reads foar dat apparaat sil blokkearje (betsjuttend syn namme) oant "genôch" entropy is sammele fan it systeem om oan it fersyk te foldwaan. Fierdere lêzen út dizze triem wurde ek blokkearre as der net genôch entropy yn it swimbad.
It fuortsmiten fan it slot pool betsjut dat it lêzen fan / dev/random gedraacht as getrandom () mei flaggen ynsteld op nul (en feroaret de GRND_RANDOM flagge yn in noop). Sadree't de kryptografyske willekeurige nûmergenerator (CRNG) is inisjalisearre, sil it lêzen fan /dev/random en ropt nei getrandom (...,0) net blokkearje en sil de frege hoemannichte willekeurige gegevens werombringe.
Lutomirsky seit: "Ik leau dat it Linux-blokkearjende pool ferâldere is. CRNG Linux genereart útfier dy't goed genôch is om sels te brûken foar kaaigeneraasje. It blokkearjende swimbad is yn gjin materiële betsjutting sterker en freget in protte ynfrastruktuer fan dubieuze wearde om it te stypjen.
De wizigingen waarden makke mei it doel om te soargjen dat besteande programma's net echt wurde beynfloede, en yn feite soene d'r minder problemen wêze mei lange wachtsjen foar dingen lykas GnuPG-kaaigeneraasje.
"Dizze ôfleverings meie gjin besteande programma's fersteure. /dev/urandom bliuwt net feroare. /dev/random blokkearret noch fuortendaliks by it opstarten, mar it blokkearret minder as earder. getentropy() mei de besteande flaggen sil in resultaat weromjaan dat krekt sa geskikt is foar praktyske doelen as earder."
Lutomirsky merkte op dat it noch altyd in iepen fraach is oft de kernel saneamde "wiere willekeurige nûmers" moat leverje, wat is wat de blokkearjende kernel yn in bepaalde mate soe dwaan. Hy sjocht dêr mar ien reden foar: "neilibjen fan oerheidsnoarmen." Lutomirsky suggerearre dat as de kearn dit soe foarsjen, it dien wurde soe fia in folslein oare ynterface, of it soe moatte wurde ferpleatst yn brûkersromte, wêrtroch de brûker rûge evenemintemonsters kin ophelje dy't brûkt wurde kinne om sa'n slotpool te meitsjen.
Stephan Müller suggerearre dat syn set foar Linux Random Number Generator (LRNG) (op it stuit ferzje 26 útbrocht) kin in manier wêze om wiere willekeurige nûmers te leverjen foar applikaasjes dy't it nedich binne. LRNG is "folslein konform mei SP800-90B-rjochtlinen oer entropyboarnen brûkt om willekeurige bits te generearjen," wêrtroch it in oplossing is foar it probleem fan oerheidsstanderts.
Matthew Garrett makke beswier tsjin de term "wiere willekeurige gegevens", en merkte op dat de samplede apparaten yn prinsipe krekt genôch modeleare koenen wurde om se foarsisber te meitsjen: "wy stekke hjir gjin kwantumeveneminten."
Müller antwurde dat de term komt fan 'e Dútske standert AIS 31 om in willekeurige nûmergenerator te beskriuwen dy't allinich in resultaat produseart "yn itselde taryf as de ûnderlizzende lûdboarne entropy produsearret."
Terminology ferskillen aside, it hawwen fan in slot pool lykas suggerearre troch de LRNG patches sil gewoan liede ta ferskate problemen, teminsten as it wurdt tagong sûnder privileezjes.
As Lutomirsky sei: "Dit lost it probleem net op. As twa ferskillende brûkers domme programma's lykas gnupg útfiere, sille se inoar gewoan ôfwetterje. Ik sjoch dat d'r op it stuit twa haadproblemen binne mei /dev/random: it is gefoelich foar DoS (d.w.s. boarne-útputting, kweade ynfloed of wat ferlykber), en om't gjin privileezjes nedich binne om it te brûken, is it ek gefoelich foar misbrûk. Gnupg is ferkeard, it is in folsleine ynstoarting. As wy in nije unprivileged ynterface tafoegje dy't gnupg en ferlykbere programma's sille brûke, sille wy wer ferlieze."
Mueller merkte op dat de tafoeging fan getrandom () no GnuPG dizze ynterface kin brûke, om't it de nedige garânsje sil leverje dat it swimbad is inisjalisearre. Op grûn fan diskusjes mei GnuPG-ûntwikkelder Werner Koch, is Mueller fan betinken dat de garânsje de ienige reden is dat GnuPG op it stuit direkt fan /dev/random lêst. Mar as d'r in unprivileged ynterface is dy't gefoelich is foar ûntkenning fan tsjinst (lykas /dev/random hjoed is), dan beweart Lutomirsky dat it troch guon applikaasjes misbrûkt wurdt.
Theodore Yue Tak Ts'o, ûntwikkelder fan it subsysteem fan willekeurige nûmers fan Linux, liket syn gedachten te feroarjen oer de needsaak foar in blokkearjende pool. Hy sei dat it fuortheljen fan dit swimbad effektyf it idee kwytreitsje soe dat Linux in wiere willekeurige nûmergenerator (TRNG) hat: "dit is gjin ûnsin, om't dit krekt is wat *BSD altyd dien hat."
Hy is ek benaud dat it leverjen fan in TRNG-meganisme gewoan sil tsjinje as aas foar applikaasje-ûntwikkelders en is fan betinken dat it feitlik, sjoen de ferskate soarten hardware stipe troch Linux, it ûnmooglik is om TRNG yn 'e kernel te garandearjen. Sels de mooglikheid om te wurkjen mei apparatuer allinich mei root-privileges sil it probleem net oplosse: "Applikaasje-ûntwikkelders spesifisearje dat har applikaasje wurdt ynstalleare as root foar feiligensdoelen, sadat dit de ienige manier is wêrop jo tagong krije ta de 'echt goede' willekeurige nûmers."
Mueller frege oft Cao de ymplemintaasje fan it blokkearjende swimbad ferlitten hie dat hy sels al lang foarsteld hie. Cao antwurde dat hy fan plan is om Lutomirsky's patches te nimmen en aktyf ferset tsjin it tafoegjen fan in blokkearjende ynterface werom nei de kernel.
"De kernel kin gjin garânsjes jaan oft de lûdboarne goed karakterisearre is. It ienige ding dat in GPG- as OpenSSL-ûntwikkelder kin krije is in vague gefoel dat TRUERANDOM "better" is, en om't se mear feiligens wolle, sille se sûnder mis besykje it te brûken. Op in stuit sil it blokkearre wurde, en as in oare tûke brûker (miskien in distribúsjespesjalist) it ynfoeget yn it init-skript en de systemen stopje mei wurkjen, hoege brûkers allinich te kleien by Linus Torvalds sels.
Cao pleitet ek foar it jaan fan kryptografen en dyjingen dy't TRNG eins nedich hawwe in manier om har eigen entropy yn brûkersromte te rispjen om te brûken as se goed fine. Hy seit dat it sammeljen fan entropy net in proses is dat kin wurde útfierd troch de kearn op alle ferskillende hardware dy't it stipet, noch kin de kearn sels de hoemannichte entropy beoardielje dy't troch ferskate boarnen wurdt levere.
"De kernel soe gjin ferskillende lûdsboarnen byinoar moatte mingje, en it soe perfoarst net moatte besykje te beweare hoefolle bits fan entropy it krijt as it besiket in soarte fan "twitchy entropy-spiel" te spyljen op in skandalich ienfâldige CPU arsjitektuer foar brûkers fan konsuminten. IOT / ynbêde gefallen wêr't alles net syngronisearre is mei in inkele master oscillator, wêr't d'r gjin CPU-ynstruksje is om in register opnij te bestellen of omneame, ensfh.
"Jo kinne prate oer it leverjen fan ark dy't besykje dizze berekkeningen te dwaan, mar sokke dingen moatte dien wurde op 'e hardware fan elke brûker, wat gewoan net praktysk is foar de measte distribúsjebrûkers. As dit allinich bedoeld is foar kryptografen, lit it dan dien wurde yn har brûkersromte. En lit ús GPG, OpenSSL, ensfh. Wy kinne prate oer hoe't wy ynterfaces leverje oan kryptografen, sadat se de ynformaasje kinne krije dy't se nedich binne troch tagong te krijen ta de primêre lûdsboarnen, skieden en neamd, en miskien op ien of oare manier kin de lûdsboarne himsels autentisearje foar in biblioteek of brûkersromteapplikaasje.
D'r wie wat diskusje oer hoe't sa'n ynterface der útsjen kin, om't d'r bygelyks feiligensgefolgen kinne hawwe foar guon eveneminten. Cao konstatearre dat toetseboerd scan koades (dus toetsoanslagen) wurde mingd yn in swimbad as ûnderdiel fan entropy kolleksje: "Bringe dit yn brûkersromte, sels troch in befoarrjochte systeem oprop, soe wêze ûnferstannich om it minste te sizzen." It is hiel goed mooglik dat oare evenemint timings meie meitsje in soarte fan ynformaasje lekken troch kant kanalen.
Dat it liket derop dat in lang besteande probleem mei it subsysteem fan willekeurige nûmers fan Linux ûnderweis is nei in oplossing. De wizigingen dy't it willekeurige nûmer subsysteem koartlyn hat ûndergien hawwe eins allinich resultearre yn DoS-problemen by it brûken. No binne d'r effisjinte manieren om de bêste willekeurige nûmers te krijen dy't de kernel kin leverje. As TRNG noch winsklik is op Linux, dan sil dizze flater yn 'e takomst moatte wurde oanpakt, mar wierskynlik sil dit net dien wurde binnen de kernel sels.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com