Poznato je da /dev/random, kriptografski siguran generator pseudoslučajnih brojeva (CSPRNG), ima jedan dosadan problem: blokiranje. Ovaj članak objašnjava kako to možete riješiti.
U proteklih nekoliko mjeseci, objekti za generiranje slučajnih brojeva u kernelu su malo prerađeni, ali su problemi u ovom podsistemu riješeni tokom šireg ... Najviše su napravljene da bi se spriječilo da sistemski poziv getrandom() blokira dugo vremena kada se sistem pokrene, ali osnovni razlog za to je bilo ponašanje blokiranja nasumične grupe. Nedavna zakrpa bi uklonila ovaj bazen i očekivalo se da će krenuti prema glavnom jezgru.
Andy Lutomirski je krajem decembra objavio treću verziju zakrpe. On doprinosi "dvije velike semantičke promjene nasumičnih Linux API-ja". Zakrpa dodaje novu GRND_INSECURE zastavicu u sistemski poziv getrandom() (iako ga Lutomirsky naziva getentropy(), koji je implementiran u glibc koristeći getrandom() sa fiksnim zastavicama); ova oznaka uzrokuje da poziv uvijek vraća traženu količinu podataka, ali bez garancije da su podaci nasumični. Kernel će jednostavno dati sve od sebe da proizvede najbolje nasumične podatke koje ima u datom trenutku. "Vjerovatno je najbolje nazvati to 'NESIGURNO' (nesigurno) kako bi se spriječio ovaj API da se koristi za stvari koje trebaju sigurnost."
Zakrpe također uklanjaju blok za blokiranje. Kernel trenutno održava dva nasumična skupa podataka, jedan koji odgovara /dev/random, a drugi /dev/urandom, kao što je opisano u ovom 2015. Grupa za blokiranje je skup za /dev/random; čitanja za taj uređaj će se blokirati (što znači njegovo ime) sve dok se ne prikupi "dovoljno" entropije iz sistema da bi se zadovoljio zahtjev. Dalja čitanja iz ove datoteke su također blokirana ako nema dovoljno entropije u grupi.
Uklanjanje skupa zaključavanja znači da se čitanje iz /dev/random ponaša kao getrandom() sa zastavicama postavljenim na nulu (i pretvara GRND_RANDOM zastavicu u noop). Kada 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 nasumičnih podataka.
Lutomirsky kaže: “Vjerujem da je Linux blok za blokiranje postao zastario. CRNG Linux generiše izlaz koji je dovoljno dobar da se čak može koristiti i za generisanje ključeva. Pul za blokiranje nije jači ni u kakvom materijalnom smislu i zahtijeva mnogo infrastrukture sumnjive vrijednosti da bi ga podržao.”
Promjene su napravljene s ciljem da se osigura da postojeći programi neće biti stvarno pogođeni, a zapravo bi bilo manje problema s dugim čekanjem na stvari poput GnuPG generiranja ključeva.
“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() sa postojećim zastavicama će vratiti rezultat koji je jednako prikladan za praktične svrhe kao i prije."
Lutomirsky je primetio da je još uvek otvoreno pitanje da li kernel treba da obezbedi takozvane "prave slučajne brojeve", što je jezgro za blokiranje u određenoj meri trebalo da uradi. On vidi samo jedan razlog za to: “usklađenost sa državnim standardima”. Lutomirsky je predložio da, ako bi kernel to omogućio, to bi trebalo biti učinjeno preko potpuno drugačijeg sučelja, ili bi trebalo biti premješteno u korisnički prostor, omogućavajući korisniku da dohvati neobrađene uzorke događaja koji bi se mogli koristiti za kreiranje takvog spremišta zaključavanja.
Stephan Müller je predložio da njegov set za Linux Generator slučajnih brojeva (LRNG) (trenutno objavljena verzija 26) mogao bi biti način da se osiguraju istinski slučajni brojevi za aplikacije kojima je to potrebno. LRNG je “potpuno usklađen sa SP800-90B smjernicama o izvorima entropije koji se koriste za generiranje nasumičnih bitova”, što ga čini rješenjem za problem vladinih standarda.
Matthew Garrett se usprotivio terminu "pravi nasumični podaci", napominjući da se uzorkovani uređaji u principu mogu modelirati dovoljno precizno da budu predvidljivi: "mi ovdje ne uzorkujemo kvantne događaje."
Müller je odgovorio da taj izraz dolazi iz njemačkog standarda AIS 31 za opisivanje generatora slučajnih brojeva koji samo proizvodi rezultat "po istoj stopi kao što osnovni izvor buke proizvodi entropiju".
Na stranu terminološke razlike, posjedovanje skupa zaključavanja kao što sugeriraju 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, oni će se samo iscrpljivati. Vidim da trenutno postoje dva glavna problema sa /dev/random: sklon je DoS-u (tj. iscrpljenju resursa, zlonamjernom utjecaju ili nečem sličnom), a budući da nisu potrebne privilegije za njegovo korištenje, sklon je i zloupotrebama. Gnupg je pogrešan, to je potpuni kolaps. Ako dodamo novi neprivilegirani interfejs koji će koristiti gnupg i slični programi, opet ćemo izgubiti."
Mueller je primijetio da će dodavanje getrandom() sada omogućiti GnuPG-u da koristi ovo sučelje, budući da će pružiti potrebnu garanciju da je bazen inicijaliziran. Na osnovu razgovora sa GnuPG programerom Wernerom Kochom, Mueller vjeruje da je garancija jedini razlog zašto GnuPG trenutno čita direktno iz /dev/random. Ali ako postoji neprivilegirano sučelje koje je podložno uskraćivanju usluge (kao što je /dev/random danas), Lutomirsky tvrdi da će ga neke aplikacije zloupotrebljavati.
Čini se da je Theodore Yue Tak Ts'o, programer Linux-ovog podsistema slučajnih brojeva, promijenio mišljenje o potrebi za blokom za blokiranje. Rekao je da bi se uklanjanjem ovog bazena efektivno riješila ideja da Linux ima pravi generator slučajnih brojeva (TRNG): "ovo nije glupost, jer je to upravo ono što je *BSD uvijek radio."
On je također zabrinut da će obezbjeđivanje TRNG mehanizma jednostavno poslužiti kao mamac za programere aplikacija i vjeruje da je zapravo, s obzirom na različite tipove hardvera koje podržava Linux, nemoguće garantirati TRNG u kernelu. Čak ni mogućnost rada s opremom samo s root privilegijama neće riješiti problem: "Programeri aplikacija navode da njihova aplikacija bude instalirana kao root iz sigurnosnih razloga, tako da je to jedini način na koji možete pristupiti 'stvarno dobrim' slučajnim brojevima."
Mueller je pitao da li je Cao odustao od implementacije bloka za blokiranje koju je sam dugo predlagao. Cao je odgovorio da planira da preuzme zakrpe Lutomirskog i aktivno se protivi dodavanju interfejsa za blokiranje nazad u kernel.
“Jezgro ne može dati nikakve garancije da li je izvor buke ispravno okarakterisan. Jedina stvar koju GPG ili OpenSSL programer može dobiti je nejasan osjećaj da je TRUERANDOM "bolji", a pošto žele više sigurnosti, nesumnjivo će pokušati da ga koriste. U nekom trenutku će biti blokiran, a kada ga neki drugi pametni korisnik (možda stručnjak za distribuciju) ubaci u init skriptu i sistemi prestanu da rade, korisnici će morati samo da se žale Linusu Torvaldsu."
Cao se također zalaže da se kriptografima i onima kojima je TRNG zaista potreban način da sakupe sopstvenu entropiju u korisničkom prostoru kako bi ih koristili kako smatraju prikladnim. On kaže da prikupljanje entropije nije proces koji kernel može izvršiti na svom različitom hardveru koji podržava, niti sam kernel može procijeniti količinu entropije koju pružaju različiti izvori.
„Jezgro ne bi trebalo da meša različite izvore buke zajedno, i svakako ne bi trebalo da tvrdi da zna koliko bitova entropije dobija kada pokušava da igra neku vrstu „igre entropije“ na nečuveno jednostavnom CPU-u arhitektura za potrošačke korisnike. IOT/Ugrađeni slučajevi u kojima sve nije sinkronizirano s jednim glavnim oscilatorom, gdje nema CPU instrukcija za promjenu redoslijeda ili preimenovanja registra, itd.”
“Možete govoriti o obezbjeđivanju alata koji pokušavaju da izvrše ove kalkulacije, ali takve stvari se moraju raditi na hardveru svakog korisnika, što jednostavno nije praktično za većinu korisnika distribucije. Ako je ovo namijenjeno samo kriptografima, neka se to radi u njihovom korisničkom prostoru. I nemojmo pojednostavljivati GPG, OpenSSL itd. pa da svi kažu "želimo "istinski slučajnost" i nećemo pristajati na manje." Možemo razgovarati o tome kako obezbjeđujemo interfejse kriptografima tako da oni mogu dobiti informacije koje su im potrebne pristupom primarnim izvorima buke, odvojenim i imenovanim, i možda se na neki način izvor buke može autentifikovati u biblioteci ili aplikaciji korisničkog prostora."
Postojala je neka rasprava o tome kako bi takav interfejs mogao izgledati, budući da bi, na primjer, mogle postojati sigurnosne implikacije za neke događaje. Cao je primetio da se kodovi za skeniranje tastature (tj. pritisci na tastere) mešaju u skup kao deo prikupljanja entropije: "Unošenje ovoga u korisnički prostor, čak i putem privilegovanog sistemskog poziva, u najmanju ruku ne bi bilo mudro." Sasvim je moguće da druga vremena događaja mogu stvoriti neku vrstu curenja informacija kroz sporedne kanale.
Dakle, izgleda da je dugogodišnji problem sa Linuxovim podsistemom slučajnih brojeva na putu ka rješenju. Promjene koje je podsistem nasumičnih brojeva nedavno pretrpio zapravo su dovele samo do problema sa DoS-om dok ga koristite. Sada postoje efikasni načini da se dobiju najbolji slučajni brojevi koje kernel može pružiti. Ako je TRNG i dalje poželjan na Linuxu, onda će ovaj nedostatak morati biti riješen u budućnosti, ali najvjerovatnije to se neće raditi unutar samog kernela.
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com