După cum se știe, /dev/random, un generator de numere aleatoare criptografic securizate (CSPRNG), are o problemă neplăcută - blocările. În acest articol, se discută despre cum poate fi rezolvată această problemă.
În ultimele câteva luni, metodele de generare a numerelor aleatoare din kernel au fost puțin revizuite, dar problemele din acest subsistem au fost abordate pe o perioadă mai lungă. Cele mai au fost făcute cu scopul de a preveni blocarea prelungită a apelului de sistem getrandom() la încărcarea sistemului, dar cauza de bază a fost comportamentul blocant al rezervorului de numere aleatoare. O actualizare recentă ar fi eliminat acest rezervor, iar se aștepta ca aceasta să fie direcționată către kernelul principal.
Andy Lutomirski a publicat a treia versiune a patch-ului la sfârșitul lunii decembrie. Acesta face „două modificări semantice de bază în API-urile aleatoare ale Linux”. Patch-ul adaugă un nou flag GRND_INSECURE la apelul de sistem getrandom() (deși Lutomirski se referă la el ca getentropy(), care este implementat în glibc prin getrandom() cu flag-uri fixe); acest flag determină apelul să returneze întotdeauna cantitatea de date solicitate, fără a garanta că acestea sunt aleatoare. Kernelul va face tot posibilul să ofere cele mai bune date aleatoare de care dispune în acel moment. „Probabil cel mai bine pe care putem să-l facem este să-l numim 'INSECURE' (nesigur), pentru a împiedica utilizarea acestui API pentru lucruri care au nevoie de securitate.” (nesigur), pentru a preveni utilizarea acestui API pentru lucruri care necesită securitate.
Patch-urile elimină de asemenea rezervorul blocant. În prezent, kernelul menține două rezervoruri de date aleatoare, unul corespunzând /dev/random și celălalt - /dev/urandom, așa cum este descris în această 2015. Rezervorul blocant este rezervorul pentru /dev/random; citirea pentru acest dispozitiv va fi blocată (așa cum sugerează numele) până când din sistem a fost colectată o 'suficientă' entropie pentru a satisface cererea. În continuare, citirile din acest fișier sunt de asemenea blocate, dacă rezervorul nu conține suficientă entropie.
Eliminarea pool-ului de blocare înseamnă că citirea din /dev/random se comportă ca getrandom() cu valoarea flags egală cu zero (și transformă flagul GRND_RANDOM în noop). După inițializarea generatorului criptografic de numere aleatoare (CRNG), citirea din /dev/random și apelurile getrandom(…,0) nu vor bloca și vor returna cantitatea solicitată de date aleatoare.
Lutomirski spune: „Consider că pool-ul de blocare Linux și-a consumat existența. CRNG Linux generează ieșiri care sunt suficient de bune pentru a fi utilizate chiar și pentru generarea de chei. Pool-ul de blocare nu este mai puternic în niciun sens semnificativ, iar pentru menținerea sa este nevoie de multă infrastructură de valoare discutabilă.”
Modificările au fost făcute cu scopul de a se asigura că programele existente nu vor suferi, iar de fapt, problemele cu așteptarea îndelungată pentru lucruri precum generarea cheilor GnuPG vor deveni mai puțin frecvente.
„Aceste serii nu ar trebui să afecteze niciun program existent. /dev/urandom rămâne neschimbat. /dev/random este încă blocat imediat după încărcare, dar se blochează mai puțin decât înainte. getentropy() cu flag-uri existente va returna un rezultat care va fi la fel de adecvat pentru scopuri practice ca și înainte.”
Lutomirski a subliniat că rămâne deschisă întrebarea dacă nucleul ar trebui să furnizeze așa-numitele „numere aleatoare adevărate”, ceea ce într-o anumită măsură trebuia să facă pool-ul de blocare. El vede în asta un singur motiv: „respectarea standardelor guvernamentale”. Lutomirski a sugerat că, dacă nucleul trebuie să asigure acest lucru, atunci ar trebui să fie realizat printr-o interfață complet diferită sau ar trebui mutat în spațiul utilizatorului, oferindu-i posibilitatea de a extrage mostre brute de evenimente care pot fi utilizate pentru a crea un astfel de pool de blocare.
Stephan Müller a sugerat că setul său generatorul de numere aleatorii Linux (LRNG) (în prezent a fost lansată versiunea 26) poate fi o modalitate de a furniza numere aleatorii adevărate pentru aplicațiile care au nevoie de acestea. LRNG este „complet conform cerințelor „Recomandărilor privind sursele de entropie utilizate pentru generarea de biți aleatori” SP800-90B”, ceea ce îl face o soluție pentru problemele standardelor de stat.
Matthew Garrett a contestat termenul „date aleatorii adevărate”, subliniind că dispozitivele alese pot fi, în principiu, modelate suficient de precis pentru a le face previzibile: „noi nu selecționăm aici evenimente cuantice”.
Müller a răspuns că acest termen provine din standardul german AIS 31 pentru descrierea generatorului de numere aleatorii, care pur și simplu produce rezultate „cu aceeași viteză cu care sursa de zgomot de bază produce entropie”.
Pe lângă neînțelegerile terminologiei, prezența unui pool de blocare, așa cum este sugerat de patch-urile LRNG, va duce pur și simplu la diverse probleme, mai ales dacă este accesibil fără privilegii.
Așa cum a spus Lutomski: „Acest lucru nu rezolvă problema. Dacă doi utilizatori diferiți rulează programe stupide, cum ar fi 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țe dăunătoare sau ceva de genul acesta), și, din moment ce nu sunt necesare privilegii pentru utilizarea lui, este de asemenea predispus la abuzuri. Gnupg este greșit, este un colaps complet. Dacă adăugăm o nouă interfață neprivilegiată, care va fi utilizată de gnupg și programe similare, vom pierde din nou.”
Müller a menționat că adăugarea getrandom() va permite acum GnuPG să folosească această interfață, deoarece va asigura garanția necesară că pool-ul a fost inițializat. Pe baza discuțiilor cu dezvoltatorul GnuPG Werner Koch, Müller consideră că garanția este singura cauză pentru care GnuPG citește în prezent direct din /dev/random. Dar dacă există o interfață neprivilegiată, care este predispusă la atacuri de tip denial of service (așa cum este /dev/random în prezent), atunci, conform lui Lutomski, aceasta va fi utilizată necorespunzător de unele aplicații.
Teodor Tsao (Theodore Yue Tak Ts’o), dezvoltatorul subsistemului de numere aleatorii Linux, și-a schimbat, se pare, opinia cu privire la necesitatea unui pool de blocare. El a spus că eliminarea acestui pool va îmbunătăți ideea că Linux are un generator adevărat de numere aleatorii (TRNG): „nu este o nebunie, deoarece este exact ceea ce au făcut întotdeauna *BSD".
De asemenea, el este îngrijorat că furnizarea unui mecanism TRNG va servi doar ca momeală pentru dezvoltatorii de aplicații și consideră că, având în vedere diferitele tipuri de hardware acceptate de Linux, este imposibil să garantezi TRNG în nucleu. Problema nu va fi rezolvată nici măcar de posibilitatea de a lucra cu hardware-ul doar pe baza privilegiilor de root: „Dezvoltatorii de aplicații specifică că aplicația lor, pentru a fi sigură, trebuie să fie instalată ca root, pentru că doar așa poți obține „numere aleatorii cu adevărat bune".
Müller a întrebat dacă Tsao a renunțat la implementarea pool-ului de blocare, pe care el însuși l-a propus acum mult timp. Tsao a răspuns că plănuiește să aplice patch-urile lui Lutomski și se opune cu fermitate reluării interfeței de blocare în nucleu.
„Nucleul nu poate oferi nicio garanție cu privire la faptul că sursa de zgomot a fost caracterizată corect. Singurul lucru pe care îl poate obține dezvoltatorul GPG sau OpenSSL este o senzație vagă că TRUERANDOM este „mai bun”, iar deoarece doresc mai multă securitate, cu siguranță vor încerca să-l utilizeze. La un moment dat, se va bloca, iar când un alt utilizator inteligent (poate un specialist în distribuție) îl va introduce în scriptul init, sistemele se vor opri și utilizatorilor nu le va rămâne decât să se plângă lui Linus Torvalds”.
Tsao pledează, de asemenea, pentru a oferi criptografilor și celor care au cu adevărat nevoie de TRNG o modalitate de a-și colecta propria entropie în spațiul utilizatorului, pentru a o folosi după bunul plac. El spune că procesul de colectare a entropiei nu este unul pe care nucleul să-l poată realiza pe toate tipurile de hardware pe care le acceptă, în plus, nucleul însuși nu poate evalua cantitatea de entropie furnizată de diverse surse.
„Nucleul nu ar trebui să amestece diferite surse de zgomot, și, desigur, nu ar trebui să încerce să afirme că știe câte biți de entropie primește atunci când încearcă să joace un fel de „joc zgomotos de entropie” pe o arhitectură CPU simplă la maximum pentru cazurile de utilizare IoT/Embedded, când totul este desincronizat cu un singur generator master, atunci când nu există instrucțiuni CPU pentru a reorganiza sau redenumi registrele etc.“.
„Se poate vorbi despre furnizarea unor instrumente care încearcă să facă aceste calcule, dar astfel de lucruri ar trebui să fie realizate pe echipamentul fiecărui utilizator, ceea ce pentru majoritatea utilizatorilor distribuitorului este pur și simplu nepractic. Dacă însă aceasta este destinată doar criptografilor, atunci să se facă în spațiul lor utilizator. Și să nu simplificăm GPG, OpenSSL etc., pentru ca toată lumea să zică: „vrem „veritabilă aleatorie” și nu ne mulțumim cu mai puțin”. Se poate discuta despre modul în care le oferim criptografilor interfețe astfel încât să poată obține informațiile necesare datorită accesului la sursele primare de zgomot, separate și denumite, și, poate, că într-un fel sursa de zgomot se va putea autentifica în bibliotecă sau în aplicația din spațiul utilizatorului.“.
A avut loc o mică discuție despre cum ar putea arăta o astfel de interfață, deoarece, de exemplu, pentru unele evenimente ar putea exista consecințe în ceea ce privește securitatea. Cao a subliniat că codurile de scanare a tastaturii (adică a tastelor apăsate) se amestecă în pool ca parte a colectării entropiei: „Mutarea acestui lucru în spațiul utilizatorului, chiar și printr-un apel de sistem privilegiat, ar fi, cel puțin, imprudent”. Este foarte posibil ca și alte timpi de evenimente să poată crea o scurgere de informații prin canale secundare.
Astfel, se creează senzația că problema de lungă durată a subsistemului de numere aleatorii din Linux este pe calea de a fi rezolvată. Modificările pe care subsistemul de numere aleatorii le-a suferit recent au dus în realitate doar la probleme DoS în timpul utilizării sale. Acum, însă, au apărut metode eficiente de a obține cele mai bune numere aleatorii pe care nucleul le poate oferi. Dacă TRNG este în continuare dorit pentru Linux, această lipsă va trebui rezolvată în viitor, dar, cel mai probabil, nu se va face în interiorul nucleului în sine.
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
