Come noto, /dev/random, un generatore di numeri pseudo-casuali crittograficamente sicuro (CSPRNG), presenta un problema spiacevole: i blocchi. In questo articolo si spiega come questo problema possa essere risolto.
Negli ultimi mesi, i metodi di generazione di numeri casuali nel kernel sono stati leggermente rielaborati, ma i problemi in questo sottosistema sono stati affrontati per un periodo più ampio Le ultime sono state apportate per evitare che la chiamata di sistema getrandom() si blocchi a lungo durante l'avvio del sistema, ma la causa principale di ciò era il comportamento del pool di numeri casuali bloccante. Una recente patch avrebbe rimosso questo pool, e ci si aspettava che questo approccio venisse portato al kernel principale.
Andy Lutomirski ha pubblicato la terza versione della patch alla fine di dicembre. Essa introduce «due principali cambiamenti semantici nelle API casuali di Linux». La patch aggiunge un nuovo flag GRND_INSECURE alla chiamata di sistema getrandom() (anche se Lutomirski si riferisce a essa come getentropy(), che è implementato in glibc utilizzando getrandom() con flag fissi); questo flag costringe la chiamata a restituire sempre la quantità di dati richiesta, ma senza garanzia che questi dati siano casuali. Il kernel si sforzerà di fornire i migliori dati casuali disponibili al momento. «Probabilmente, la cosa migliore da fare è chiamarlo “INSECURE” per impedire l'uso di questa API per cose che necessitano di sicurezza».
Le patch rimuovono anche il pool bloccante. Attualmente, il kernel supporta due pool di dati casuali: uno corrisponde a /dev/random e l'altro a /dev/urandom, come descritto in questo documento del 2015. Il pool bloccante è quello di /dev/random; la lettura da questo dispositivo sarà bloccata (come suggerisce il suo nome) fino a quando non sarà stata raccolta dall sistema un'«adeguata» entropia per soddisfare la richiesta. Ulteriori letture da questo file saranno bloccate anche se nel pool non c'è abbastanza entropia.
La rimozione del pool di blocco significa che la lettura da /dev/random si comporta come getrandom() con il valore dei flag pari a zero (e trasforma il flag GRND_RANDOM in noop). Dopo l'inizializzazione del generatore di numeri casuali crittografici (CRNG), la lettura da /dev/random e le chiamate a getrandom(…,0) non porteranno a blocchi e restituiranno la quantità richiesta di dati casuali.
Lutomirski dice: «Ritengo che il pool di blocco di Linux sia superato. Il CRNG di Linux genera dati di output sufficientemente buoni da poterli utilizzare anche per la generazione di chiavi. Il pool di blocco non è più forte in alcun senso materiale, e per mantenerlo è necessaria una notevole infrastruttura di dubbia utilità».
Le modifiche sono state apportate con l'intento di non danneggiare i programmi esistenti, e in effetti, i problemi di attesa prolungata per cose come la generazione di chiavi GnuPG dovrebbero diminuire.
«Queste serie non devono interrompere alcun programma esistente. /dev/urandom rimane invariato. /dev/random continua a bloccarsi subito dopo il caricamento, ma si blocca meno di prima. getentropy() con i flag esistenti restituirà un risultato che sarà altrettanto valido per scopi pratici come prima».
Lutomirski ha osservato che resta ancora aperta la questione se il kernel debba fornire cosiddetti «numeri casuali veri», che in una certa misura era il compito del kernel bloccante. Vede solo una ragione per questo: «rispettare gli standard governativi». Lutomirski ha suggerito che, se il kernel deve garantire questo, dovrebbe essere fatto attraverso un'interfaccia completamente diversa o dovrebbe essere trasferito nello spazio utente, fornendo la possibilità di estrarre campioni grezzi di eventi che possono essere utilizzati per creare tale pool di blocco.
Stephan Müller ha ipotizzato che il suo set Il generatore di numeri casuali Linux (LRNG) (attualmente alla versione 26) può essere un modo per fornire veri numeri casuali per le applicazioni che ne hanno bisogno. LRNG "è pienamente conforme ai requisiti delle 'Raccomandazioni per le fonti di entropia utilizzate per la generazione di bit casuali' SP800-90B", il che lo rende una soluzione al problema degli standard governativi.
Matthew Garrett ha contestato il termine 'dati casuali veri', osservando che i dispositivi scelti possono in linea di principio essere modellati abbastanza accuratamente da renderli prevedibili: 'qui non stiamo campionando eventi quantistici'.
Mueller ha risposto che questo termine proviene dallo standard tedesco AIS 31 per descrivere un generatore di numeri casuali che produce risultati 'alla stessa velocità con cui la sorgente di rumore di base genera entropia'.
Oltre alle divergenze terminologiche, la presenza di un pool di blocco, come suggerito dalle patch di LRNG, porterà semplicemente a vari problemi, almeno se è accessibile senza privilegi.
Come ha detto Lutomirski: "Questo non risolve il problema. Se due diversi utenti eseguono programmi stupidi, come gnupg, si esauriranno semplicemente a vicenda. Vedo che attualmente ci sono due problemi principali con /dev/random: è soggetto a DoS (ossia esaurimento delle risorse, influssi malevoli o simili) e, poiché non sono richiesti privilegi per usarlo, è anche soggetto ad abusi. Gnupg è sbagliato, è un completo collasso. Se aggiungiamo una nuova interfaccia non privilegiata che verrà utilizzata da gnupg e programmi simili, perderemo di nuovo."
Mueller ha fatto notare che l'aggiunta di getrandom() ora consentirà a GnuPG di utilizzare questa interfaccia, poiché fornirà la garanzia necessaria che il pool sia stato inizializzato. Sulla base delle discussioni con lo sviluppatore di GnuPG Werner Koch, Mueller ritiene che la garanzia sia l'unico motivo per cui GnuPG attualmente legge direttamente da /dev/random. Ma se c'è un'interfaccia non privilegiata soggetta a interruzioni del servizio (come oggi è /dev/random), secondo Lutomirski, verrà utilizzata in modo errato da alcune applicazioni.
Teodoro Cao (Theodore Yue Tak Ts’o), sviluppatore del sottosistema di numeri casuali di Linux, sembra aver cambiato idea riguardo alla necessità di un pool bloccante. Ha detto che rimuovere questo pool permetterà di eliminare in modo efficace l'idea che Linux abbia un vero generatore di numeri casuali (TRNG): «Questo non è assurdo, poiché è proprio ciò che hanno sempre fatto *BSD.»
È anche preoccupato che fornire un meccanismo TRNG serva semplicemente come esca per gli sviluppatori di applicazioni, e ritiene che, data la varietà di hardware supportato da Linux, sia impossibile garantire un TRNG nel kernel. Anche l'opzione di lavorare con l'hardware solo con privilegi di root non risolverà il problema: «Gli sviluppatori di applicazioni indicano che, per motivi di sicurezza, la loro applicazione dovrebbe essere installata come root, perché solo in questo modo puoi accedere a numeri casuali 'veramente buoni'.»
Müller ha chiesto se Cao avesse rinunciato a implementare un pool bloccante, che lui stesso aveva proposto tempo fa. Cao ha risposto che intende prendere le patch di Lutomirski e si oppone attivamente all'aggiunta di un'interfaccia bloccante nel kernel.
«Il kernel non può garantire che la sorgente di rumore sia stata caratterizzata in modo adeguato. L'unica cosa che può ottenere uno sviluppatore GPG o OpenSSL è una vaga sensazione che TRUERANDOM sia 'migliore', e poiché vogliono maggiore sicurezza, senza dubbio cercheranno di utilizzarlo. A un certo punto verrà bloccato, e quando qualche altro utente intelligente (forse un esperto di rilascio di distribuzioni) lo inserirà nello script di init e i sistemi smetteranno di funzionare, agli utenti non resterà che lamentarsi con Linus Torvalds».
Cao sostiene anche di fornire a crittografi e a chi ha realmente bisogno di TRNG un modo per raccogliere la propria entropia nello spazio utente, per utilizzarla come meglio crede. Dice che la raccolta di entropia non è un processo che può essere eseguito dal kernel su tutti i tipi di hardware supportato, inoltre, il kernel stesso non può valutare la quantità di entropia fornita dalle varie sorgenti.
«Il nucleo non dovrebbe mescolare insieme diverse sorgenti di rumore e, ovviamente, non dovrebbe cercare di affermare di sapere quanti bit di entropia sta ottenendo quando cerca di giocare a qualche 'gioco disordinato di entropia' su un'architettura CPU ridicolmente semplice per casi d'uso IOT/Embedded, quando tutto è disallineato con un unico generatore master, e quando non ci sono istruzioni CPU per riordinare o rinominare i registri, ecc.»
«Si può parlare di fornire strumenti che tentano di effettuare questi calcoli, ma tali operazioni dovrebbero essere eseguite sull'hardware di ogni utente, il che è semplicemente impraticabile per la maggior parte degli utenti della distribuzione. Se questo è destinato solo ai crittografi, allora deve essere fatto nel loro spazio utente. E non semplifichiamo GPG, OpenSSL, ecc., affinché tutti dicano: 'vogliamo la 'vera casualità' e non ci accontentiamo di meno'. Possiamo discutere su come fornire interfacce ai crittografi in modo che possano ottenere le informazioni necessarie attraverso l'accesso a sorgenti di rumore primarie, separate e nominate, e, forse, in qualche modo, la sorgente di rumore sarà in grado di autenticarsi in una libreria o applicazione dello spazio utente».
C'è stata una piccola discussione su come potrebbe apparire tale interfaccia, poiché, ad esempio, per alcuni eventi potrebbero esserci implicazioni in termini di sicurezza. Cao ha sottolineato che i codici di scansione della tastiera (cioè le pressioni dei tasti) vengono mescolati in un pool come parte della raccolta di entropia: «Spostare questo nello spazio utente, anche attraverso una chiamata di sistema privilegiata, sarebbe, quantomeno, imprudente». È del tutto possibile che altri tempi di eventi possano creare qualche fuga di informazioni tramite canali laterali.
Pertanto, si ha l'impressione che il problema di lunga data del sottosistema dei numeri casuali di Linux sia in procinto di essere risolto. Le modifiche apportate al sottosistema dei numeri casuali recentemente hanno infatti portato solo a problemi di DoS durante il suo utilizzo. Tuttavia, ora ci sono modi efficaci per ottenere i migliori numeri casuali che il kernel possa fornire. Se TRNG è ancora desiderato per Linux, questo difetto dovrà essere risolto in futuro, ma molto probabilmente non sarà fatto all'interno dello stesso kernel.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Leggi di
Fonte: habr.com
