Znano je, da ima /dev/random, kriptografsko varen generator psevdonaključnih števil (CSPRNG), eno nadležno težavo: blokiranje. Ta članek pojasnjuje, kako ga lahko rešite.
V zadnjih nekaj mesecih so bile zmogljivosti za generiranje naključnih števil v jedru nekoliko predelane, vendar so bile težave v tem podsistemu odpravljene v času širšega . Večina so bili narejeni, da bi preprečili dolgotrajno blokiranje sistemskega klica getrandom(), ko se sistem zažene, vendar je bil osnovni razlog za to vedenje blokiranja naključnega bazena. Nedavni popravek bi odstranil ta bazen in pričakovali bi, da se bo usmeril proti glavnemu jedru.
Andy Lutomirski je konec decembra objavil tretjo različico popravka. On prispeva "dve veliki semantični spremembi naključnih API-jev Linuxa". Popravek doda novo zastavico GRND_INSECURE sistemskemu klicu getrandom() (čeprav ga Lutomirsky imenuje getentropy(), ki je implementiran v glibc z uporabo getrandom() s fiksnimi zastavicami); ta zastavica povzroči, da klic vedno vrne zahtevano količino podatkov, vendar brez zagotovila, da so podatki naključni. Jedro se bo preprosto potrudilo proizvesti najboljše naključne podatke, ki jih ima v danem trenutku. "Verjetno je najbolje, da temu rečemo 'NEVARNO' (nevarno), da preprečite uporabo tega API-ja za stvari, ki potrebujejo varnost."
Obliži tudi odstranijo blokirni bazen. Jedro trenutno vzdržuje dve naključni podatkovni skupini, eno ustreza /dev/random in drugo /dev/urandom, kot je opisano v tem 2015. Področje blokiranja je območje za /dev/random; branje za to napravo bo blokiralo (kar pomeni njeno ime), dokler sistem ne zbere "dovolj" entropije za izpolnitev zahteve. Nadaljnje branje iz te datoteke je tudi blokirano, če v bazenu ni dovolj entropije.
Odstranitev področja zaklepanja pomeni, da se branje iz /dev/random obnaša kot getrandom() z zastavicami, nastavljenimi na nič (in spremeni zastavico GRND_RANDOM v noop). Ko je kriptografski generator naključnih števil (CRNG) inicializiran, branje iz /dev/random in klici getrandom(...,0) ne bodo blokirani in bodo vrnili zahtevano količino naključnih podatkov.
Lutomirsky pravi: »Verjamem, da je skupina za blokiranje Linuxa zastarela. CRNG Linux ustvarja izhod, ki je dovolj dober, da se lahko uporabi celo za ustvarjanje ključev. Blokirni bazen ni močnejši v nobenem materialnem smislu in zahteva veliko infrastrukture dvomljive vrednosti, da ga podpira.«
Spremembe so bile narejene z namenom zagotoviti, da obstoječi programi ne bi bili res prizadeti in da bi dejansko bilo manj težav z dolgim čakanjem na stvari, kot je generiranje ključev GnuPG.
»Te epizode ne smejo motiti nobenih obstoječih programov. /dev/urandom ostane nespremenjen. /dev/random še vedno blokira takoj po zagonu, vendar blokira manj kot prej. getentropy() z obstoječimi zastavicami bo vrnil rezultat, ki je prav tako primeren za praktične namene kot prej."
Lutomirsky je opozoril, da je še vedno odprto vprašanje, ali bi moralo jedro zagotavljati tako imenovane "prave naključne številke", kar naj bi blokirajoče jedro do določene mere storilo. Za to vidi samo en razlog: "skladnost z vladnimi standardi." Lutomirsky je predlagal, da bi moralo jedro, če bi to zagotovilo, to storiti prek popolnoma drugačnega vmesnika ali pa bi ga bilo treba premakniti v uporabniški prostor, kar bi uporabniku omogočilo pridobivanje neobdelanih vzorcev dogodkov, ki bi jih lahko uporabili za ustvarjanje takega zaklepnega bazena.
Stephan Müller je predlagal, da njegov set za Linux Generator naključnih števil (LRNG) (trenutno izdana različica 26) bi lahko bil način za zagotavljanje resničnih naključnih števil za aplikacije, ki jih potrebujejo. LRNG je "popolnoma skladen s smernicami SP800-90B o virih entropije, ki se uporabljajo za generiranje naključnih bitov", zaradi česar je rešitev za problem vladnih standardov.
Matthew Garrett je nasprotoval izrazu "resnični naključni podatki", pri čemer je opozoril, da bi lahko vzorčene naprave načeloma modelirali dovolj natančno, da bi jih naredili predvidljive: "tukaj ne vzorčimo kvantnih dogodkov."
Müller je odgovoril, da izraz izhaja iz nemškega standarda AIS 31 za opis generatorja naključnih števil, ki proizvaja samo rezultat "z enako hitrostjo, kot osnovni vir hrupa proizvaja entropijo."
Če ne upoštevamo terminoloških razlik, bo imetje bazena ključavnic, kot predlagajo popravki LRNG, preprosto povzročilo različne težave, vsaj če se do njega dostopa brez privilegijev.
Kot je rekel Lutomirsky: »To ne reši problema. Če dva različna uporabnika poganjata neumne programe, kot je gnupg, bosta samo izpraznila drug drugega. Vidim, da sta trenutno dve glavni težavi z /dev/random: nagnjen je k DoS (tj. izčrpanost virov, zlonamerni vpliv ali kaj podobnega), in ker za njegovo uporabo niso potrebne nobene pravice, je nagnjen tudi k zlorabam. Gnupg je napačen, to je popoln kolaps. Če dodamo nov neprivilegiran vmesnik, ki ga bodo uporabljali gnupg in podobni programi, bomo spet izgubili."
Mueller je opazil, da bo dodatek getrandom() zdaj omogočil GnuPG uporabo tega vmesnika, saj bo zagotovil potrebno jamstvo, da je bil bazen inicializiran. Na podlagi pogovorov z razvijalcem GnuPG Wernerjem Kochom Mueller meni, da je jamstvo edini razlog, da GnuPG trenutno bere neposredno iz /dev/random. Če pa obstaja neprivilegiran vmesnik, ki je dovzeten za zavrnitev storitve (kot je danes /dev/random), Lutomirsky trdi, da ga bodo nekatere aplikacije zlorabile.
Theodore Yue Tak Ts'o, razvijalec Linuxovega podsistema naključnih števil, se zdi, da si je premislil glede potrebe po blokirnem bazenu. Dejal je, da bi se z odstranitvijo tega bazena dejansko znebili ideje, da ima Linux pravi generator naključnih števil (TRNG): "to ni neumnost, saj je to točno tisto, kar *BSD vedno počne."
Prav tako je zaskrbljen, da bo zagotavljanje mehanizma TRNG preprosto služilo kot vaba za razvijalce aplikacij, in meni, da je glede na različne vrste strojne opreme, ki jih podpira Linux, pravzaprav nemogoče zagotoviti TRNG v jedru. Tudi zmožnost dela z opremo samo s korenskimi pravicami ne bo rešila težave: "Razvijalci aplikacij določajo, da je njihova aplikacija nameščena kot root zaradi varnosti, tako da je to edini način, da lahko dostopate do 'res dobrih' naključnih števil."
Mueller je vprašal, ali je Cao opustil izvedbo blokirnega bazena, ki jo je sam dolgo predlagal. Cao je odgovoril, da namerava vzeti popravke Lutomirskyja in aktivno nasprotuje dodajanju blokirnega vmesnika nazaj v jedro.
»Jedro ne more zagotoviti, ali je bil vir hrupa pravilno označen. Edina stvar, ki jo lahko dobi razvijalec GPG ali OpenSSL, je nejasen občutek, da je TRUERANDOM "boljši", in ker želijo več varnosti, ga bodo nedvomno poskušali uporabiti. Na neki točki bo blokiran in ko ga kakšen drug pameten uporabnik (morda specialist za distribucijo) vstavi v začetni skript in sistemi nehajo delovati, se bodo uporabniki morali pritožiti le samemu Linusu Torvaldsu."
Cao se tudi zavzema za to, da se kriptografom in tistim, ki dejansko potrebujejo TRNG, da možnost, da zberejo lastno entropijo v uporabniškem prostoru, da jo uporabijo, kot se jim zdi primerno. Pravi, da zbiranje entropije ni proces, ki bi ga lahko izvajalo jedro na vsej različni strojni opremi, ki jo podpira, niti jedro samo ne more oceniti količine entropije, ki jo zagotavljajo različni viri.
»Jedro ne bi smelo mešati različnih virov hrupa skupaj in prav gotovo ne bi smelo poskušati trditi, da ve, koliko bitov entropije dobi, ko poskuša igrati nekakšno »igro trzajoče entropije« na nezaslišano preprostem procesorju. IOT/vgrajeni primeri, kjer vse ni sinhronizirano z enim samim glavnim oscilatorjem, kjer ni navodil CPU za preurejanje ali preimenovanje registra itd.«
»Lahko govorite o zagotavljanju orodij, ki poskušajo narediti te izračune, vendar je treba takšne stvari narediti na strojni opremi vsakega uporabnika, kar preprosto ni praktično za večino uporabnikov distribucije. Če je to namenjeno le kriptografom, naj to storijo v njihovem uporabniškem prostoru. In ne poenostavljajmo GPG, OpenSSL itd., da bi vsi rekli, "želimo "pravo naključnost" in se ne bomo zadovoljili z manj." Lahko se pogovarjamo o tem, kako nudimo vmesnike kriptografom, da lahko dobijo informacije, ki jih potrebujejo, z dostopom do primarnih virov hrupa, ločenih in poimenovanih, in morda se nekako lahko vir hrupa avtentifikira v knjižnici ali aplikaciji uporabniškega prostora."
Bilo je nekaj razprav o tem, kako bi lahko izgledal tak vmesnik, saj bi na primer lahko nekateri dogodki imeli varnostne posledice. Cao je opozoril, da so kode za skeniranje tipkovnice (tj. pritiski na tipke) pomešane v bazen kot del zbiranja entropije: "Prenašanje tega v uporabniški prostor, tudi prek privilegiranega sistemskega klica, bi bilo najmanj nespametno." Povsem možno je, da lahko drugi časovni razporedi dogodkov povzročijo nekakšno uhajanje informacij po stranskih kanalih.
Torej je videti, da je dolgotrajna težava s podsistemom naključnih števil Linuxa na poti k rešitvi. Spremembe, ki jih je pred kratkim doživel podsistem naključnih števil, so dejansko povzročile le težave z DoS med njegovo uporabo. Zdaj obstajajo učinkoviti načini za pridobivanje najboljših naključnih števil, ki jih lahko zagotovi jedro. Če je TRNG še vedno zaželen v Linuxu, bo to napako treba odpraviti v prihodnosti, vendar najverjetneje to ne bo storjeno v samem jedru.
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com