/dev/random, un generatore di numeri pseudo-aleatoriu criptograficamente sicuru (CSPRNG), hè cunnisciutu per avè un prublema fastidiosu: u bloccu. Questu articulu spiega cumu pudete risolve.
In l'ultimi mesi, e facilità di generazione di numeri aleatorii in u kernel sò state ligeramente rielaborate, ma i prublemi in questu sottosistema sò stati risolti in u cursu di u più largu. . U più sò stati fatti per impedisce a chjama di u sistema getrandom () da bluccà per un bellu pezzu quandu u sistema boots, ma u mutivu sottostante per questu era u cumpurtamentu di bloccu di a piscina casuale. Un patch recente avaria sguassatu di sta piscina è si avissi aspittatu per andà versu u core principale.
Andy Lutomirski hà publicatu a terza versione di u patch à a fini di dicembre. Ellu cuntribuisce "dui grandi cambiamenti semantici à l'API Linux casuali". U patch aghjusta una nova bandiera GRND_INSECURE à a chjama di u sistema getrandom() (ancu se Lutomirsky si riferisce à questu cum'è getentropy (), chì hè implementatu in glibc usendu getrandom () cù bandieri fissi); sta bandiera face chì a chjama torna sempre a quantità di dati dumandata, ma senza guarantisci chì i dati sò casuali. U kernel farà solu u so megliu per pruduce e megliu dati aleatorii chì hà in u mumentu datu. "Probabilmente u megliu da fà hè di chjamà" INSECURE " (insicure) per impedisce chì questa API sia usata per e cose chì necessitanu di sicurità ".
I patch eliminanu ancu a piscina di bloccu. U kernel mantene attualmente dui pools di dati aleatoriu, unu chì currisponde à /dev/random è l'altru à /dev/urandom, cum'è deskrittu in questu. 2015. A piscina di bloccu hè a piscina per /dev/random; leghje per quellu dispusitivu bluccarà (chì significheghja u so nome) finu à chì "abbastanza" entropia hè stata cullata da u sistema per suddisfà a dumanda. Ulteriori letture da stu schedariu sò ancu bluccati se ùn ci hè micca abbastanza entropia in a piscina.
Eliminà u pool di serratura significa chì a lettura da /dev/random si comporta cum'è getrandom() cù bandiere pusate à zero (è trasforma a bandiera GRND_RANDOM in un noop). Una volta chì u generatore di numeri aleatoriu criptograficu (CRNG) hè inizializatu, a lettura da /dev/random è chjama à getrandom (...) ùn bluccarà micca è restituverà a quantità dumandata di dati aleatorii.
Lutomirsky dice: "Credu chì a piscina di bloccu Linux hè diventata obsoleta. CRNG Linux genera output chì hè abbastanza bonu per ancu esse usatu per a generazione di chjave. A piscina di bloccu ùn hè micca più forte in alcun sensu materiale è richiede assai infrastruttura di valore dubbiu per sustene.
I cambiamenti sò stati fatti cù l'obiettivu di assicurà chì i prugrammi esistenti ùn saranu micca veramente affettati, è in fattu, ci saria menu prublemi cù longu aspittà per cose cum'è a generazione di chjave GnuPG.
"Questi episodi ùn devenu micca disturbà i prugrammi esistenti. /dev/urandom resta invariatu. /dev/random blocca sempre immediatamente dopu à u boot, ma blucca menu chè prima. getentropy() cù i bandieri esistenti restituverà un risultatu chì hè cusì adattatu per scopi pratichi cum'è prima ".
Lutomirsky hà nutatu chì hè sempre una quistione aperta se u kernel duveria furnisce i cosiddetti "numeri casuali veri", chì hè ciò chì u kernel di bloccu duverebbe fà in una certa misura. Ellu vede solu una ragione per questu: "rispettu à i normi di u guvernu". Lutomirsky hà suggeritu chì, se u kernel avia da furnisce questu, deve esse fattu per una interfaccia completamente diversa, o si deve esse spustatu in u spaziu di l'utilizatori, chì permettenu à l'utilizatore per ritruvà campioni di l'avvenimentu crudu chì puderia esse usatu per creà un tali pool di serratura.
Stephan Müller hà suggeritu chì u so set per Linux Random Number Generator (LRNG) (attualmente a versione 26 liberata) puderia esse un modu per furnisce veri numeri aleatorii per l'applicazioni chì ne necessitanu. LRNG hè "pienamente cumpletu cù SP800-90B Guidelines on Entropy Sources Used to Generate Random Bits", facendu una suluzione à u prublema di i standard di u guvernu.
Matthew Garrett s'oppone à u terminu "veri dati casuali", nutendu chì i dispositi campionati puderanu in principiu esse modellati abbastanza precisamente per fà li prevedibili: "ùn avemu micca campionamentu di l'avvenimenti quantistici quì".
Müller hà rispostu chì u terminu vene da u standard tedescu AIS 31 per discrìviri un generatore di numeri aleatorii chì solu pruduce un risultatu "à u listessu ritmu cum'è a fonte di rumore sottostante produce entropia".
Differenze di terminologia da parte, avè una piscina di serratura cum'è suggerita da i patch LRNG purterà solu à parechji prublemi, almenu s'ellu hè accessu senza privilegi.
Cum'è Lutomirsky hà dettu: "Questu ùn risolve micca u prublema. Se dui utilizatori diffirenti eseguinu prugrammi stupidi cum'è gnupg, si sguasseranu solu l'un l'altru. Vecu chì ci sò attualmente dui prublemi principali cù /dev/random: hè propensu à DoS (vale à dì l'esaurimentu di risorse, influenza maliziosa o qualcosa simili), è postu chì ùn ci hè micca bisognu di privilegi per aduprà, hè ancu propensu à l'abusu. Gnupg hè sbagliatu, hè un colapsu cumpletu. Se aghjustemu una nova interfaccia senza privilege chì gnupg è prugrammi simili anu da aduprà, perdemu di novu ".
Mueller hà nutatu chì l'aghjunzione di getrandom() permetterà avà à GnuPG di utilizà sta interfaccia, postu chì furnisce a garanzia necessaria chì a piscina hè stata inizializzata. Basatu nantu à discussioni cù u sviluppatore di GnuPG Werner Koch, Mueller crede chì a guaranzia hè l'unicu mutivu chì GnuPG attualmente leghje direttamente da /dev/random. Ma s'ellu ci hè una interfaccia senza privilege chì hè suscettibile à a negazione di serviziu (cum'è /dev/random hè oghje), Lutomirsky sustene chì serà abusatu da alcune applicazioni.
Theodore Yue Tak Ts'o, sviluppatore di u sottosistema di numeri aleatorii di Linux, pare avè cambiatu a so mente nantu à a necessità di una piscina di bloccu. Ellu disse chì a rimuzione di sta piscina hà da sbarazzarsi efficacemente di l'idea chì Linux hà un veru generatore di numeri aleatorii (TRNG): "Questu ùn hè micca assuciatu, postu chì questu hè esattamente ciò chì * BSD hà sempre fattu".
Hè ancu preoccupatu chì furnisce un mecanismu TRNG solu serve cum'è un esca per i sviluppatori di l'applicazioni è crede chì in fattu, datu i diversi tipi di hardware supportati da Linux, hè impussibile di guarantiscia TRNG in u kernel. Ancu l'abilità di travaglià cù l'equipaggiu solu cù privilegi di root ùn risolverà micca u prublema: "I sviluppatori di l'applicazioni specificanu chì a so applicazione sia installata cum'è root per scopi di sicurezza, perchè questu hè l'unicu modu per accede à i numeri aleatorii "veramente boni".
Mueller a demandé si Cao avait abandonné l'implémentation du pool de blocage qu'il avait lui-même proposé depuis longtemps. Cao hà rispostu chì pensa à piglià i patch di Lutomirsky è s'oppone attivamente à aghjunghje una interfaccia di bloccu torna à u kernel.
"U kernel ùn pò micca dà garanzie in quantu à se a fonte di u rumore hè stata carattarizzata bè. L'unicu ciò chì un sviluppatore GPG o OpenSSL pò uttene hè una sensazione vaga chì TRUERANDOM hè "megliu", è postu chì volenu più sicurità, senza dubbitu pruvaranu à aduprà. À un certu puntu serà bluccatu, è quandu un altru utilizatore intelligente (forse un specialista di distribuzione) l'inserisce in u script init è i sistemi cessanu di travaglià, l'utilizatori anu da solu lamentà à Linus Torvalds stessu ".
Cao sustene ancu di dà à i criptografi è à quelli chì anu veramente bisognu di TRNG un modu di cugliera a so propria entropia in u spaziu di l'utilizatori per aduprà cum'è li vede. Dice chì a cullizzioni di l'entropia ùn hè micca un prucessu chì pò esse realizatu da u kernel nantu à tutti i diversi hardware chì sustene, nè u kernel stessu pò estimà a quantità di entropia furnita da diverse fonti.
"U kernel ùn deve micca mischjà diverse fonti di rumore inseme, è certamente ùn deve micca pruvà à pretende di sapè quanti bits d'entropia riceve quandu si prova à ghjucà un tipu di "ghjocu di entropia twitchy" in un CPU scandalosamente simplice. architettura per l'utilizatori di i cunsumatori. IOT / Casi Embedded induve tuttu hè fora di sincronia cù un unicu oscillatore maestru, induve ùn ci hè micca struzzione di CPU per riordinà o rinominà un registru, etc.
"Pudete parlà di furnisce strumenti chì pruvate di fà questi calculi, ma tali cose anu da esse fattu nantu à u hardware di ogni utilizatore, chì ùn hè simplicemente micca praticu per a maiò parte di l'utilizatori di distribuzione. Se questu hè destinatu solu à i criptografi, allora lasciate esse fattu in u so spaziu d'utilizatori. È ùn simplificàmu micca GPG, OpenSSL, etc., cusì chì tutti dicenu "vulemu "veru aleatoriu" è ùn si stallanu micca di menu". Pudemu parlà di cumu furnimu interfacce à i criptografi per ch'elli ponu uttene l'infurmazioni chì anu bisognu accedendu à e fonti di rumore primariu, separati è chjamati, è forsi in qualchì manera a fonte di rumore pò autentificà sè stessu à una biblioteca o una applicazione spaziale d'utilizatore ".
Ci hè stata una discussione nantu à ciò chì una tale interfaccia puderia esse cum'è, postu chì, per esempiu, puderia esse implicazioni di sicurezza per certi avvenimenti. Cao hà nutatu chì i codici di scansione di u teclatu (vale à dì i tasti) sò mischiati in una piscina cum'è parte di a cullizzioni d'entropia: "Purtà questu in u spaziu di l'utilizatori, ancu per mezu di una chjama di sistema privilegiata, ùn saria micca prudente per dì u minimu". Hè abbastanza pussibule chì altri timing di l'avvenimenti ponu creà una sorta di fuga d'infurmazioni attraversu i canali laterali.
Dunque pare chì un prublema di longa durata cù u sottosistema di numeri aleatorii di Linux hè in strada per una suluzione. I cambiamenti chì u sottosistema di numeri aleatorii hà subitu recentemente anu daveru solu risultatu in prublemi DoS mentre l'utilizanu. Avà ci sò modi efficaci per uttene u megliu numeri aleatorii chì u kernel pò furnisce. Se TRNG hè sempre desideratu in Linux, allora questu difettu duverà esse trattatu in u futuru, ma assai prubabilmente questu ùn serà micca fattu in u kernel stessu.
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com