/dev/random, kriptografski siguran generator pseudoslučajnih brojeva (CSPRNG), poznato je da ima jedan neugodan problem: blokiranje. Ovaj članak objašnjava kako to možete riješiti.
Tijekom proteklih nekoliko mjeseci mogućnosti generiranja nasumičnog broja u jezgri malo su prerađene, ali problemi u ovom podsustavu riješeni su tijekom šireg . Najviše napravljeni su kako bi se spriječilo dugotrajno blokiranje sistemskog poziva getrandom() kada se sustav podigne, ali temeljni razlog za to bilo je ponašanje blokiranja nasumičnog skupa. Nedavna zakrpa bi uklonila ovaj bazen i očekivalo bi se da ide prema glavnoj jezgri.
Andy Lutomirski objavio je treću verziju patcha krajem prosinca. On doprinosi "dvije velike semantičke promjene nasumičnih Linux API-ja". Zakrpa dodaje novu GRND_INSECURE oznaku sistemskom pozivu getrandom() (iako Lutomirsky to naziva getentropy(), što je implementirano u glibc koristeći getrandom() s fiksnim oznakama); ova zastavica uzrokuje da poziv uvijek vrati traženu količinu podataka, ali bez jamstva da su podaci nasumični. Kernel će jednostavno dati sve od sebe da proizvede najbolje slučajne podatke koje ima u danom trenutku. "Vjerojatno je najbolja stvar nazvati to 'NESIGURNO' (nesiguran) kako bi se spriječilo korištenje ovog API-ja za stvari kojima je potrebna sigurnost."
Zakrpe također uklanjaju blok za blokiranje. Kernel trenutno održava dva nasumična skupa podataka, jedan odgovara /dev/random, a drugi /dev/urandom, kao što je opisano u ovom 2015. Skup za blokiranje je skup za /dev/random; čitanja za taj uređaj će blokirati (što znači njegovo ime) dok se iz sustava ne prikupi "dovoljno" entropije da se zadovolji zahtjev. Daljnja čitanja iz ove datoteke također su blokirana ako u skupu nema dovoljno entropije.
Uklanjanje skupa zaključavanja znači da se čitanje iz /dev/random ponaša kao getrandom() sa zastavicama postavljenim na nulu (i pretvara zastavicu GRND_RANDOM u noop). Nakon što se kriptografski generator slučajnih brojeva (CRNG) inicijalizira, čitanje iz /dev/random i pozivi getrandom(...,0) neće blokirati i vratit će traženu količinu slučajnih podataka.
Lutomirsky kaže: “Vjerujem da je skup za blokiranje Linuxa zastario. CRNG Linux generira izlaz koji je dovoljno dobar da se čak koristi za generiranje ključeva. Blokirajući skup nije jači u bilo kojem materijalnom smislu i zahtijeva mnogo infrastrukture sumnjive vrijednosti da ga podrži.”
Promjene su napravljene s ciljem da se osigura da postojeći programi stvarno neće biti pogođeni, i zapravo, da će biti manje problema s dugim čekanjem za stvari poput GnuPG generiranja ključa.
“Ove epizode ne smiju poremetiti postojeće programe. /dev/urandom ostaje nepromijenjen. /dev/random i dalje blokira odmah nakon pokretanja, ali blokira manje nego prije. getentropy() s postojećim oznakama vratit će rezultat koji je jednako prikladan za praktične svrhe kao i prije."
Lutomirsky je primijetio da je još uvijek otvoreno pitanje treba li kernel osigurati takozvane "prave slučajne brojeve", što je blokirajući kernel trebao činiti u određenoj mjeri. On za to vidi samo jedan razlog: “usklađenost s državnim standardima”. Lutomirsky je predložio da, ako bi kernel to omogućio, to bi trebalo biti učinjeno kroz potpuno drugačije sučelje, ili bi se trebalo premjestiti u korisnički prostor, dopuštajući korisniku da dohvati neobrađene uzorke događaja koji bi se mogli koristiti za stvaranje takvog skupa zaključavanja.
Stephan Müller predložio je da njegov set za Linux Generator slučajnih brojeva (LRNG) (trenutno izdana verzija 26) mogao bi biti način da se dobiju pravi slučajni brojevi za aplikacije koje ga trebaju. LRNG je "u potpunosti usklađen sa smjernicama SP800-90B o izvorima entropije koji se koriste za generiranje nasumičnih bitova", što ga čini rješenjem problema državnih standarda.
Matthew Garrett usprotivio se izrazu "pravi slučajni podaci", napominjući da se uzorkovani uređaji u načelu mogu modelirati dovoljno precizno da budu predvidljivi: "ovdje ne uzorkujemo kvantne događaje."
Müller je odgovorio da termin dolazi iz njemačkog standarda AIS 31 za opisivanje generatora slučajnih brojeva koji samo proizvodi rezultat "istom brzinom kao što osnovni izvor buke proizvodi entropiju."
Terminološke razlike na stranu, posjedovanje skupa zaključavanja kako predlažu LRNG zakrpe jednostavno će dovesti do raznih problema, barem ako mu se pristupa bez privilegija.
Kao što je Lutomirsky rekao: “Ovo ne rješava problem. Ako dva različita korisnika pokreću glupe programe kao što je gnupg, samo će isprazniti jedan drugog. Vidim da trenutno postoje dva glavna problema s /dev/random: sklon je DoS-u (tj. iscrpljenosti resursa, zlonamjernom utjecaju ili nečemu sličnom), a budući da za njegovo korištenje nisu potrebne nikakve privilegije, sklon je i zloporabi. Gnupg je pogrešan, to je potpuni kolaps. Ako dodamo novo neprivilegirano sučelje koje će koristiti gnupg i slični programi, opet ćemo izgubiti."
Mueller je primijetio da će dodatak getrandom() sada omogućiti GnuPG-u korištenje ovog sučelja, budući da će pružiti potrebno jamstvo da je skup inicijaliziran. Na temelju razgovora s programerom GnuPG-a Wernerom Kochom, Mueller vjeruje da je jamstvo jedini razlog zašto GnuPG trenutno čita izravno iz /dev/random. Ali ako postoji neprivilegirano sučelje koje je osjetljivo na uskraćivanje usluge (kao što je /dev/random danas), Lutomirsky tvrdi da će ga neke aplikacije zloupotrijebiti.
Čini se da se Theodore Yue Tak Ts'o, programer Linuxovog podsustava nasumičnog broja, predomislio o potrebi za skupom za blokiranje. Rekao je da bi se uklanjanjem ovog skupa učinkovito riješilo ideje da Linux ima pravi generator slučajnih brojeva (TRNG): "ovo nije besmislica, budući da je to točno ono što je *BSD uvijek radio."
Također je zabrinut da će pružanje TRNG mehanizma jednostavno poslužiti kao mamac za programere aplikacija i vjeruje da je zapravo, s obzirom na različite vrste hardvera koje podržava Linux, nemoguće jamčiti TRNG u kernelu. Čak ni mogućnost rada s opremom samo s root privilegijama neće riješiti problem: "Programeri aplikacija određuju da njihova aplikacija bude instalirana kao root iz sigurnosnih razloga, tako da je to jedini način na koji možete pristupiti 'stvarno dobrim' nasumičnim brojevima."
Mueller je pitao je li Cao odustao od implementacije skupa blokiranja koju je sam dugo predlagao. Cao je odgovorio da planira preuzeti zakrpe Lutomirskyja i aktivno se protivi ponovnom dodavanju sučelja za blokiranje u kernel.
“Jezgra ne može jamčiti je li izvor buke ispravno karakteriziran. Jedina stvar koju GPG ili OpenSSL programer može dobiti je nejasan osjećaj da je TRUERANDOM "bolji", a budući da žele više sigurnosti, nedvojbeno će ga pokušati koristiti. U nekom trenutku bit će blokiran, a kada ga neki drugi pametni korisnik (možda specijalist za distribuciju) ubaci u init skriptu i sustavi prestanu raditi, korisnici će se morati žaliti samo Linusu Torvaldsu."
Cao se također zalaže da se kriptografima i onima koji stvarno trebaju TRNG omogući način prikupljanja vlastite entropije u korisničkom prostoru kako bi je koristili kako žele. On kaže da prikupljanje entropije nije proces koji kernel može izvesti na svim različitim hardverima koje podržava, niti sam kernel može procijeniti količinu entropije koju pružaju različiti izvori.
"Jezgra ne bi trebala miješati različite izvore buke, a svakako ne bi trebala tvrditi da zna koliko bitova entropije dobiva kada pokušava igrati neku vrstu "igre trzave entropije" na nečuveno jednostavnom CPU-u arhitektura za potrošačke korisnike. IOT/ugrađeni slučajevi gdje sve nije sinkronizirano s jednim glavnim oscilatorom, gdje nema CPU instrukcija za promjenu redoslijeda ili preimenovanje registra, itd."
“Možete govoriti o pružanju alata koji pokušavaju napraviti te izračune, ali takve se stvari moraju raditi na hardveru svakog korisnika, što jednostavno nije praktično za većinu korisnika distribucije. Ako je ovo namijenjeno samo kriptografima, onda neka to rade u njihovom korisničkom prostoru. I nemojmo pojednostaviti GPG, OpenSSL itd. tako da svi kažu "želimo "istinsku slučajnost" i nećemo pristati na manje." Možemo razgovarati o tome kako pružamo sučelja kriptografima tako da mogu dobiti informacije koje su im potrebne pristupom primarnim izvorima šuma, odvojenim i imenovanim, i možda se izvor šuma nekako može autentificirati biblioteci ili aplikaciji korisničkog prostora."
Bilo je nekih rasprava o tome kako bi takvo sučelje moglo izgledati, budući da bi na primjer moglo postojati sigurnosna implikacija za neke događaje. Cao je primijetio da se kodovi za skeniranje tipkovnice (tj. pritisci tipki) miješaju u skup kao dio prikupljanja entropije: "Uvođenje ovoga u korisnički prostor, čak i kroz privilegirani sistemski poziv, bilo bi u najmanju ruku nepametno." Sasvim je moguće da druga vremena događaja mogu izazvati neku vrstu curenja informacija kroz sporedne kanale.
Dakle, izgleda da je dugogodišnji problem s Linuxovim podsustavom nasumičnog broja na putu prema rješenju. Promjene kroz koje je podsustav nasumičnog broja nedavno prošao zapravo su samo rezultirale problemima s DoS-om tijekom njegove upotrebe. Sada postoje učinkoviti načini za dobivanje najboljih nasumičnih brojeva koje kernel može pružiti. Ako je TRNG još uvijek poželjan na Linuxu, tada će se ovaj nedostatak morati riješiti u budućnosti, ali najvjerojatnije to neće biti učinjeno unutar same jezgre.
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com