/dev/random, un generator de numere pseudo-aleatorie (CSPRNG) securizat criptografic, este cunoscut că are o problemă enervantă: blocarea. Acest articol explică cum o poți rezolva.
În ultimele câteva luni, facilitățile de generare a numerelor aleatorii din nucleu au fost ușor reproiectate, dar problemele din acest subsistem au fost rezolvate pe parcursul mai larg. ... Cel mai au fost făcute pentru a preveni blocarea apelului de sistem getrandom() pentru o lungă perioadă de timp când sistemul pornește, dar motivul de bază a fost comportamentul de blocare al pool-ului aleatoriu. Un patch recent ar fi eliminat acest pool și ar fi fost de așteptat să se îndrepte către nucleul principal.
Andy Lutomirski a publicat a treia versiune a patch-ului la sfârșitul lunii decembrie. El contribuie „două modificări semantice majore ale API-urilor Linux aleatorii”. Patch-ul adaugă un nou flag GRND_INSECURE la apelul de sistem getrandom() (deși Lutomirsky se referă la el ca getentropy(), care este implementat în glibc folosind getrandom() cu steaguri fixe); acest flag face ca apelul să returneze întotdeauna cantitatea de date solicitată, dar fără a garanta că datele sunt aleatorii. Nucleul va face tot posibilul pentru a produce cele mai bune date aleatorii pe care le are la momentul dat. „Probabil că cel mai bun lucru de făcut este să-i spui „INSIGUR”. (nesigur) pentru a preveni utilizarea acestui API pentru lucruri care au nevoie de securitate.”
Patch-urile elimină și grupul de blocare. Nucleul menține în prezent două pool-uri de date aleatorii, unul corespunzând lui /dev/random și celălalt /dev/urandom, așa cum este descris în acest 2015. Pool-ul de blocare este pool-ul pentru /dev/random; citirile pentru acel dispozitiv se vor bloca (adică numele său) până când a fost colectată „suficientă” entropie din sistem pentru a satisface cererea. Citirile ulterioare din acest fișier sunt, de asemenea, blocate dacă nu există suficientă entropie în pool.
Eliminarea grupului de blocare înseamnă că citirea din /dev/random se comportă ca getrandom() cu steaguri setate la zero (și transformă steag-ul GRND_RANDOM într-un noop). Odată ce generatorul de numere aleatoare criptografice (CRNG) este inițializat, citirea din /dev/random și apelurile către getrandom(...,0) nu se vor bloca și va returna cantitatea cerută de date aleatoare.
Lutomirsky spune: „Cred că pool-ul de blocare Linux a devenit învechit. CRNG Linux generează rezultate suficient de bune pentru a fi folosite chiar și pentru generarea de chei. Baza de blocare nu este mai puternică în niciun sens material și necesită multă infrastructură de valoare îndoielnică pentru a-l susține.”
Modificările au fost făcute cu scopul de a se asigura că programele existente nu vor fi cu adevărat afectate și, de fapt, vor exista mai puține probleme cu așteptări lungi pentru lucruri precum generarea cheilor GnuPG.
„Aceste episoade nu trebuie să perturbe niciun program existent. /dev/urandom rămâne neschimbat. /dev/random încă blochează imediat după pornire, dar se blochează mai puțin decât înainte. getentropy() cu steagurile existente va returna un rezultat care este la fel de potrivit pentru scopuri practice ca înainte."
Lutomirsky a remarcat că este încă o întrebare deschisă dacă nucleul ar trebui să ofere așa-numitele „numere aleatorii adevărate”, ceea ce ar fi trebuit să facă nucleul de blocare într-o anumită măsură. El vede un singur motiv pentru aceasta: „respectarea standardelor guvernamentale”. Lutomirsky a sugerat că, dacă kernel-ul ar oferi acest lucru, ar trebui să se facă printr-o interfață complet diferită sau ar trebui să fie mutat în spațiul utilizatorului, permițând utilizatorului să recupereze mostre de evenimente brute care ar putea fi folosite pentru a crea un astfel de grup de blocare.
Stephan Müller a sugerat că setul său pentru Linux Random Number Generator (LRNG) (în prezent versiunea 26 lansată) ar putea fi o modalitate de a oferi numere aleatoare adevărate pentru aplicațiile care au nevoie de ele. LRNG este „pe deplin compatibil cu liniile directoare SP800-90B privind sursele de entropie utilizate pentru a genera biți aleatori”, ceea ce îl face o soluție la problema standardelor guvernamentale.
Matthew Garrett s-a opus termenului de „date aleatorii adevărate”, menționând că dispozitivele eșantionate ar putea fi, în principiu, modelate suficient de precis pentru a le face previzibile: „nu eșantionăm aici evenimente cuantice”.
Müller a răspuns că termenul provine din standardul german AIS 31 pentru a descrie un generator de numere aleatorii care produce doar un rezultat „la aceeași rată cu care sursa de zgomot de bază produce entropie”.
Lăsând deoparte diferențele de terminologie, a avea un grup de blocare așa cum sugerează patch-urile LRNG va duce pur și simplu la diverse probleme, cel puțin dacă este accesat fără privilegii.
După cum a spus Lutomirsky: „Acest lucru nu rezolvă problema. Dacă doi utilizatori diferiți rulează programe stupide precum gnupg, se vor epuiza unul pe celălalt. Văd că în prezent există două probleme principale cu /dev/random: este predispus la DoS (adică epuizarea resurselor, influență rău intenționată sau ceva similar) și, din moment ce nu sunt necesare privilegii pentru a-l folosi, este predispus și la abuz. Gnupg greșește, este o prăbușire completă. Dacă adăugăm o nouă interfață neprivilegiată pe care gnupg și programele similare o vor folosi, vom pierde din nou."
Mueller a remarcat că adăugarea lui getrandom() va permite acum GnuPG să folosească această interfață, deoarece va oferi garanția necesară că pool-ul a fost inițializat. Pe baza discuțiilor cu dezvoltatorul GnuPG Werner Koch, Mueller consideră că garanția este singurul motiv pentru care GnuPG citește în prezent direct din /dev/random. Dar dacă există o interfață neprivilegiată care este susceptibilă de a refuza serviciul (cum este /dev/random astăzi), Lutomirsky susține că va fi folosită greșit de unele aplicații.
Theodore Yue Tak Ts'o, dezvoltatorul subsistemului de numere aleatoare Linux, pare să se fi răzgândit cu privire la necesitatea unui pool de blocare. El a spus că eliminarea acestui pool ar scăpa efectiv de ideea că Linux are un adevărat generator de numere aleatorii (TRNG): „Nu este o prostie, deoarece asta este exact ceea ce *BSD a făcut întotdeauna”.
El este, de asemenea, îngrijorat de faptul că furnizarea unui mecanism TRNG va servi pur și simplu ca momeală pentru dezvoltatorii de aplicații și consideră că, de fapt, având în vedere diferitele tipuri de hardware suportate de Linux, este imposibil să se garanteze TRNG în nucleu. Nici măcar capacitatea de a lucra cu echipamente numai cu privilegii root nu va rezolva problema: „Dezvoltatorii de aplicații specifică ca aplicația lor să fie instalată ca root din motive de securitate, astfel încât să fie singura modalitate prin care poți accesa numerele aleatoare „foarte bune””.
Mueller a întrebat dacă Cao a abandonat implementarea pool-ului de blocare pe care el însuși a propus-o de mult. Cao a răspuns că intenționează să ia patch-urile lui Lutomirsky și se opune activ adăugării unei interfețe de blocare înapoi la kernel.
„Nucleul nu poate oferi nicio garanție dacă sursa de zgomot a fost caracterizată corespunzător. Singurul lucru pe care îl poate obține un dezvoltator GPG sau OpenSSL este un sentiment vag că TRUERANDOM este „mai bun” și, din moment ce doresc mai multă securitate, vor încerca fără îndoială să o folosească. La un moment dat, va fi blocat, iar când un alt utilizator inteligent (poate un specialist în distribuție) îl introduce în scriptul de inițiere și sistemele nu mai funcționează, utilizatorii vor trebui doar să se plângă lui Linus Torvalds însuși.”
Cao susține, de asemenea, oferirea criptografilor și celor care au nevoie de TRNG de o modalitate de a-și recolta propria entropie în spațiul utilizatorului, pentru a o utiliza după cum consideră de cuviință. El spune că colectarea entropiei nu este un proces care poate fi efectuat de nucleu pe toate hardware-urile pe care le suportă și nici nucleul în sine nu poate estima cantitatea de entropie furnizată de diferite surse.
„Nucleul nu ar trebui să amestece diferite surse de zgomot împreună și, cu siguranță, nu ar trebui să încerce să pretindă că știe câți biți de entropie primește atunci când încearcă să joace un fel de „joc de entropie agitată” pe un procesor revoltător de simplu. arhitectură pentru utilizatorii consumatori. Cazuri IOT/Embedded în care totul nu este sincronizat cu un singur oscilator master, în care nu există nicio instrucțiune CPU pentru a reordona sau redenumi un registru etc.”
„Puteți vorbi despre furnizarea de instrumente care încearcă să facă aceste calcule, dar astfel de lucruri trebuie făcute pe hardware-ul fiecărui utilizator, ceea ce pur și simplu nu este practic pentru majoritatea utilizatorilor de distribuție. Dacă acest lucru este destinat doar criptografilor, atunci lăsați-l să se facă în spațiul lor de utilizator. Și să nu simplificăm GPG, OpenSSL etc., astfel încât toată lumea să spună „vrem „aleatorie adevărată” și să nu ne mulțumim cu mai puțin”. Putem vorbi despre modul în care le oferim criptografilor interfețe, astfel încât aceștia să poată obține informațiile de care au nevoie accesând sursele primare de zgomot, separate și denumite și, poate, cumva, sursa de zgomot se poate autentifica la o bibliotecă sau la o aplicație de spațiu de utilizator.”
Au existat câteva discuții despre cum ar putea arăta o astfel de interfață, deoarece, de exemplu, ar putea exista implicații de securitate pentru unele evenimente. Cao a remarcat că codurile de scanare a tastaturii (adică apăsările de taste) sunt amestecate într-un grup ca parte a colectării entropiei: „Aducerea acestui lucru în spațiul utilizatorului, chiar și printr-un apel de sistem privilegiat, ar fi cel puțin neînțelept.” Este foarte posibil ca alte momente ale evenimentelor să creeze un fel de scurgere de informații prin canale secundare.
Deci, se pare că o problemă de lungă durată cu subsistemul cu numere aleatorii Linux este pe cale de rezolvare. Modificările pe care le-a suferit recent subsistemul cu numere aleatoare au dus, de fapt, doar la probleme DoS în timpul utilizării acestuia. Acum există modalități eficiente de a obține cele mai bune numere aleatorii pe care le poate oferi nucleul. Dacă TRNG este încă de dorit pe Linux, atunci acest defect va trebui abordat în viitor, dar cel mai probabil acest lucru nu se va face în nucleul în sine.
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com