Krüptograafiliselt turvalisel pseudojuhuslike arvude generaatoril (CSPRNG) /dev/random on teadaolevalt üks tüütu probleem: blokeerimine. See artikkel selgitab, kuidas saate seda lahendada.
Viimaste kuude jooksul on kerneli juhuslike numbrite genereerimisvõimalusi veidi ümber töödeldud, kuid selle alamsüsteemi probleemid on laiema kasutuse käigus lahendatud.
Andy Lutomirski avaldas plaastri kolmanda versiooni detsembri lõpus. Ta annab oma panuse "kaks peamist semantilist muudatust juhuslikes Linuxi API-des". Plaaster lisab süsteemikutsele getrandom() uue lipu GRND_INSECURE (kuigi Lutomirsky viitab sellele kui getentropy(), mida glibc-s rakendatakse fikseeritud lippudega getrandom() abil); selle lipu abil tagastab kõne alati nõutud andmemahu, kuid ei garanteeri, et andmed on juhuslikud. Kernel annab lihtsalt endast parima, et toota parimaid juhuslikke andmeid, mis tal antud ajahetkel on. "Tõenäoliselt on kõige parem nimetada seda "EBATURVALIKS" (ebaturvaline), et vältida selle API kasutamist asjade jaoks, mis vajavad turvalisust."
Plaastrid eemaldavad ka blokeeriva basseini. Kernel haldab praegu kahte juhuslikku andmekogu, millest üks vastab /dev/random ja teine /dev/urandom, nagu on kirjeldatud selles
Lukukogumi eemaldamine tähendab, et /dev/random lugemine käitub nagu getrandom(), mille lippude väärtused on seatud nulli (ja muudab lipu GRND_RANDOM noopiks). Kui krüptograafiline juhuslike numbrite generaator (CRNG) on initsialiseeritud, ei blokeerita failist /dev/random lugemine ja getrandom(...,0) kõned ja tagastatakse soovitud hulk juhuslikke andmeid.
Lutomirsky ütleb: "Usun, et Linuxi blokeerimisbassein on vananenud. CRNG Linux genereerib väljundit, mis on piisavalt hea, et seda isegi võtme genereerimiseks kasutada. Blokeeriv bassein pole üheski materiaalses mõttes tugevam ja nõuab selle toetamiseks palju kahtlase väärtusega infrastruktuuri.
Muudatused tehti eesmärgiga tagada, et olemasolevaid programme tegelikult ei mõjutataks ja tegelikult oleks vähem probleeme pika ootamisega asjadele nagu GnuPG võtme genereerimine.
"Need episoodid ei tohi häirida ühtegi olemasolevat programmi. /dev/urandom jääb muutumatuks. /dev/random blokeerib endiselt kohe käivitamisel, kuid see blokeerib vähem kui varem. getentropy() koos olemasolevate lippudega annab tulemuse, mis on praktilistel eesmärkidel sama sobiv kui varem."
Lutomirsky märkis, et endiselt on lahtine küsimus, kas tuum peaks esitama nn tõelisi juhuslikke numbreid, mida blokeeriv tuum teatud määral tegema pidigi. Ta näeb sellel ainult ühte põhjust: "vastavus valitsuse standarditele". Lutomirsky soovitas, et kui kernel peaks seda pakkuma, tuleks seda teha täiesti erineva liidese kaudu või see tuleks teisaldada kasutajaruumi, võimaldades kasutajal hankida töötlemata sündmuste näidiseid, mida saaks kasutada sellise lukukogumi loomiseks.
Stephan Müller soovitas, et tema komplekt
Matthew Garrett vaidlustas termini "tõelised juhuslikud andmed", märkides, et valimiga võetud seadmeid saab põhimõtteliselt piisavalt täpselt modelleerida, et muuta need prognoositavaks: "me ei võta siin kvantsündmusi."
Müller vastas, et termin pärineb Saksa standardist AIS 31, et kirjeldada juhuslike arvude generaatorit, mis annab tulemuse ainult "sama kiirusega, kui aluseks olev müraallikas tekitab entroopiat".
Kui terminoloogiaerinevused kõrvale jätta, põhjustab LRNG-plaastrites soovitatud lukukogumi olemasolu lihtsalt mitmesuguseid probleeme, vähemalt siis, kui sellele juurde pääsete ilma privileegideta.
Nagu Lutomirsky ütles: "See ei lahenda probleemi. Kui kaks erinevat kasutajat käitavad rumalaid programme, nagu gnupg, kurnavad nad üksteist lihtsalt tühjaks. Ma näen, et /dev/random on hetkel kaks peamist probleemi: see on kalduvus DoS-ile (st. ressursside ammendumine, pahatahtlik mõjutamine või midagi sarnast) ja kuna selle kasutamiseks pole vaja mingeid privileege, on see ka altid kuritarvitamisele. Gnupg eksib, see on täielik kokkuvarisemine. Kui lisame uue privilegeerimata liidese, mida gnupg ja sarnased programmid kasutavad, kaotame jälle."
Mueller märkis, et getrandom() lisamine võimaldab nüüd GnuPG-l seda liidest kasutada, kuna see annab vajaliku garantii, et kogum on lähtestatud. GnuPG arendaja Werner Kochiga peetud arutelude põhjal usub Mueller, et garantii on ainus põhjus, miks GnuPG loeb praegu otse failist /dev/random. Kuid kui on olemas privilegeerimata liides, mis on vastuvõtlik teenuse keelamisele (nagu täna on /dev/random), väidab Lutomirsky, et mõned rakendused kasutavad seda vääralt.
Linuxi juhuslike arvude alamsüsteemi arendaja Theodore Yue Tak Ts'o näib olevat muutnud oma meelt blokeerimisbasseini vajaduse osas. Ta ütles, et selle kogumi eemaldamine kaotaks tõhusalt mõtte, et Linuxil on tõeline juhuslike arvude generaator (TRNG): "See pole jama, sest see on täpselt see, mida *BSD on alati teinud."
Samuti tunneb ta muret selle pärast, et TRNG-mehhanismi pakkumine toimib rakenduste arendajatele lihtsalt söödana ja usub, et Linuxi toetatud erinevat tüüpi riistvara tõttu on tegelikult võimatu TRNG-d tuumas tagada. Isegi võimalus töötada seadmetega ainult juurõigustega ei lahenda probleemi: "Rakenduste arendajad määravad, et nende rakendus installitakse turvalisuse huvides administraatorina, nii et ainult nii pääsete juurde "tõeliselt headele" juhuslikele numbritele."
Mueller küsis, kas Cao on loobunud blokeerimisbasseini rakendamisest, mille ta ise oli juba ammu välja pakkunud. Cao vastas, et kavatseb Lutomirsky plaastrid võtta ja on aktiivselt vastu blokeeriva liidese kernelile tagasi lisamisele.
"Tuum ei saa anda mingeid garantiisid selle kohta, kas müraallikat on õigesti iseloomustatud. Ainus, mida GPG või OpenSSL-i arendaja võib saada, on ähmane tunne, et TRUERANDOM on "parem" ja kuna nad tahavad rohkem turvalisust, proovivad nad seda kahtlemata kasutada. Mingil hetkel see blokeeritakse ja kui mõni teine nutikas kasutaja (võib-olla levitamise spetsialist) sisestab selle init-skripti ja süsteemid lakkavad töötamast, jäävad kasutajad vaid Linus Torvaldsile endale kaebama.
Cao pooldab ka krüptograafidele ja neile, kes tegelikult vajavad TRNG-d, võimaluse koguda oma entroopiat kasutajaruumis, et seda oma äranägemise järgi kasutada. Ta ütleb, et entroopia kogumine ei ole protsess, mida kernel saaks teostada kogu erineval riistvaral, mida ta toetab, samuti ei saa tuum ise hinnata erinevate allikate pakutavat entroopia hulka.
"Tuum ei tohiks segada erinevaid müraallikaid ja kindlasti ei tohiks see püüda väita, kui palju entroopia bitte see saab, kui ta üritab mängida mingit "tõmblevat entroopiamängu" ennekuulmatult lihtsal protsessoril. arhitektuur tarbijakasutajatele. IOT/manustatud juhtumid, kus kõik on ühe peaostsillaatoriga sünkroonist väljas, kus puuduvad CPU-le juhised registri ümberjärjestamiseks või ümbernimetamiseks jne.
"Võite rääkida tööriistade pakkumisest, mis proovivad neid arvutusi teha, kuid selliseid asju tuleb teha iga kasutaja riistvara peal, mis pole enamiku levitajate jaoks otstarbekas. Kui see on mõeldud ainult krüptograafidele, siis tehku seda nende kasutajaruumis. Ja ärgem lihtsustagem GPG-d, OpenSSL-i jne nii, et kõik ütlevad "me tahame "tõelist juhuslikkust" ja ei lepi vähemaga. Võime rääkida sellest, kuidas pakume krüptograafidele liideseid, et nad saaksid vajalikku teavet, pääsedes ligi peamistele eraldatud ja nimega müraallikatele, ja võib-olla saab müraallikas end kuidagi raamatukogus või kasutajaruumirakenduses autentida.
Arutati selle üle, milline selline liides võiks välja näha, kuna näiteks võib see mõne sündmuse puhul avaldada mõju turvalisusele. Cao märkis, et klaviatuuri skannimiskoodid (st klahvivajutused) segatakse entroopia kogumise osana basseini: "Selle toomine kasutajaruumi isegi privilegeeritud süsteemikõne kaudu oleks pehmelt öeldes ebamõistlik." On täiesti võimalik, et muud sündmuste ajastused võivad tekitada kõrvalkanalite kaudu mingisuguse infolekke.
Seega näib, et Linuxi juhuslike arvude alamsüsteemiga seotud pikaajaline probleem on lahenduse poole liikumas. Juhuslike arvude alamsüsteemi hiljutised muudatused on tegelikult põhjustanud selle kasutamise ajal ainult DoS-i probleeme. Nüüd on olemas tõhusad viisid parimate juhuslike arvude saamiseks, mida kernel suudab pakkuda. Kui TRNG on Linuxis endiselt soovitav, tuleb see viga tulevikus kõrvaldada, kuid tõenäoliselt ei tehta seda kernelis endas.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele,
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin
Allikas: www.habr.com