/dev/random, un generatore di numeri pseudo-casuali crittograficamente sicuro (CSPRNG), è noto per avere un fastidioso problema: il blocco. Questo articolo spiega come risolverlo.
Negli ultimi mesi, le funzionalità di generazione dei numeri casuali nel kernel sono state leggermente rielaborate, ma i problemi in questo sottosistema sono stati risolti nel corso del più ampio . Più sono stati creati per impedire che la chiamata di sistema getrandom() si blocchi per un lungo periodo all'avvio del sistema, ma la ragione di fondo di ciò era il comportamento di blocco del pool casuale. Una patch recente avrebbe rimosso questo pool e ci si sarebbe aspettato che si dirigesse verso il nucleo principale.
Andy Lutomirski ha pubblicato la terza versione della patch alla fine di dicembre. Contribuisce "due importanti modifiche semantiche alle API Linux casuali". La patch aggiunge un nuovo flag GRND_INSECURE alla chiamata di sistema getrandom() (anche se Lutomirsky si riferisce ad esso come getentropy(), che è implementato in glibc utilizzando getrandom() con flag fissi); questo flag fa sì che la chiamata restituisca sempre la quantità di dati richiesti, ma senza garantire che i dati siano casuali. Il kernel farà semplicemente del suo meglio per produrre i migliori dati casuali di cui dispone in un dato momento. "Probabilmente la cosa migliore da fare è chiamarlo 'INSECURO' (non sicuro) per impedire che questa API venga utilizzata per cose che richiedono sicurezza."
Le patch rimuovono anche il pool di blocchi. Il kernel attualmente mantiene due pool di dati casuali, uno corrispondente a /dev/random e l'altro a /dev/urandom, come descritto in questo 2015. Il pool di blocco è il pool per /dev/random; le letture per quel dispositivo si bloccheranno (intendendo il suo nome) finché non sarà stata raccolta entropia "sufficiente" dal sistema per soddisfare la richiesta. Anche ulteriori letture da questo file vengono bloccate se non c'è abbastanza entropia nel pool.
Rimuovere il lock pool significa che la lettura da /dev/random si comporta come getrandom() con i flag impostati a zero (e trasforma il flag GRND_RANDOM in un noop). Una volta inizializzato il generatore di numeri casuali crittografici (CRNG), la lettura da /dev/random e le chiamate a getrandom(...,0) non si bloccheranno e restituiranno la quantità richiesta di dati casuali.
Lutomirsky dice: “Credo che il pool di blocco di Linux sia diventato obsoleto. CRNG Linux genera un output sufficientemente buono da poter essere utilizzato anche per la generazione di chiavi. Il pool di blocco non è più forte in alcun senso materiale e richiede molte infrastrutture di dubbio valore per supportarlo”.
Le modifiche sono state apportate con l'obiettivo di garantire che i programmi esistenti non venissero realmente influenzati e, di fatto, ci sarebbero meno problemi con lunghe attese per cose come la generazione di chiavi GnuPG.
“Questi episodi non devono interrompere nessun programma esistente. /dev/urandom rimane invariato. /dev/random si blocca ancora immediatamente all'avvio, ma si blocca meno di prima. getentropy() con i flag esistenti restituirà un risultato altrettanto adatto per scopi pratici come prima."
Lutomirsky ha osservato che è ancora una questione aperta se il kernel debba fornire i cosiddetti “veri numeri casuali”, che è ciò che il kernel di blocco avrebbe dovuto fare in una certa misura. Vede una sola ragione per questo: “il rispetto degli standard governativi”. Lutomirsky ha suggerito che se il kernel dovesse fornire questo, dovrebbe essere fatto attraverso un'interfaccia completamente diversa, o dovrebbe essere spostato nello spazio utente, consentendo all'utente di recuperare campioni di eventi grezzi che potrebbero essere utilizzati per creare un tale pool di lock.
Stephan Müller ha suggerito il suo set per Linux Random Number Generator (LRNG) (attualmente rilasciata la versione 26) potrebbe essere un modo per fornire numeri casuali reali per le applicazioni che ne hanno bisogno. LRNG è "pienamente conforme alle linee guida SP800-90B sulle fonti di entropia utilizzate per generare bit casuali", rendendolo una soluzione al problema degli standard governativi.
Matthew Garrett si è opposto al termine “dati casuali reali”, sottolineando che in linea di principio i dispositivi campionati potrebbero essere modellati in modo sufficientemente preciso da renderli prevedibili: “qui non stiamo campionando eventi quantistici”.
Müller ha risposto che il termine deriva dallo standard tedesco AIS 31 per descrivere un generatore di numeri casuali che produce un risultato solo "alla stessa velocità con cui la sorgente di rumore sottostante produce entropia".
A parte le differenze terminologiche, avere un lock pool come suggerito dalle patch LRNG porterà semplicemente a vari problemi, almeno se si accede senza privilegi.
Come ha detto Lutomirsky: “Questo non risolve il problema. Se due utenti diversi eseguono programmi stupidi come gnupg, si prosciugheranno a vicenda. Vedo che attualmente ci sono due problemi principali con /dev/random: è soggetto a DoS (ovvero esaurimento delle risorse, influenza dannosa o qualcosa di simile) e poiché non sono richiesti privilegi per usarlo, è anche soggetto ad abusi. Gnupg è sbagliato, è un collasso completo. Se aggiungiamo una nuova interfaccia non privilegiata che verrà utilizzata da gnupg e programmi simili, perderemo di nuovo."
Mueller ha notato che l'aggiunta di getrandom() ora consentirà a GnuPG di utilizzare questa interfaccia, poiché fornirà la necessaria garanzia che il pool sia stato inizializzato. Sulla base delle discussioni con lo sviluppatore di GnuPG Werner Koch, Mueller ritiene che la garanzia sia l'unica ragione per cui GnuPG attualmente legge direttamente da /dev/random. Ma se esiste un'interfaccia non privilegiata che è suscettibile di negazione del servizio (come lo è oggi /dev/random), Lutomirsky sostiene che verrà utilizzata in modo improprio da alcune applicazioni.
Theodore Yue Tak Ts'o, sviluppatore del sottosistema di numeri casuali di Linux, sembra aver cambiato idea sulla necessità di un pool di blocco. Ha detto che la rimozione di questo pool eliminerebbe effettivamente l'idea che Linux abbia un vero generatore di numeri casuali (TRNG): "questa non è una sciocchezza, poiché questo è esattamente ciò che *BSD ha sempre fatto."
È anche preoccupato che fornire un meccanismo TRNG possa servire semplicemente da esca per gli sviluppatori di applicazioni e ritiene che, dati i diversi tipi di hardware supportati da Linux, sia impossibile garantire TRNG nel kernel. Anche la possibilità di lavorare con apparecchiature solo con privilegi di root non risolverà il problema: "Gli sviluppatori di applicazioni specificano che la loro applicazione venga installata come root per motivi di sicurezza, in modo che questo sia l'unico modo per accedere ai numeri casuali 'veramente buoni'."
Mueller ha chiesto se Cao avesse abbandonato l'implementazione del blocking pool che lui stesso aveva proposto da tempo. Cao ha risposto che intende prendere le patch di Lutomirsky e si oppone attivamente all'aggiunta di un'interfaccia di blocco al kernel.
“Il kernel non può garantire in alcun modo se la fonte di rumore sia stata adeguatamente caratterizzata. L'unica cosa che uno sviluppatore GPG o OpenSSL può ottenere è una vaga sensazione che TRUERANDOM sia "migliore" e poiché desidera maggiore sicurezza, proverà senza dubbio a usarla. Ad un certo punto verrà bloccato, e quando qualche altro utente intelligente (magari uno specialista della distribuzione) lo inserirà nello script init e i sistemi smetteranno di funzionare, gli utenti non dovranno far altro che lamentarsi con lo stesso Linus Torvalds.”
Cao sostiene inoltre di fornire ai crittografi e a coloro che effettivamente necessitano di TRNG un modo per raccogliere la propria entropia nello spazio utente da utilizzare come meglio credono. Dice che raccogliere entropia non è un processo che può essere eseguito dal kernel su tutti i diversi hardware che supporta, né il kernel stesso può stimare la quantità di entropia fornita da diverse fonti.
"Il kernel non dovrebbe mescolare insieme diverse fonti di rumore, e certamente non dovrebbe cercare di pretendere di sapere quanti bit di entropia ottiene quando tenta di giocare a qualche tipo di "gioco di entropia nervoso" su una CPU scandalosamente semplice architettura per utenti consumer.Casi IOT/Embedded in cui tutto non è sincronizzato con un singolo oscillatore master, dove non sono presenti istruzioni della CPU per riordinare o rinominare un registro, ecc."
“Si può parlare di fornire strumenti che provano a fare questi calcoli, ma queste cose devono essere fatte sull'hardware di ciascun utente, il che semplicemente non è pratico per la maggior parte degli utenti della distribuzione. Se questo è destinato solo ai crittografi, lascia che venga fatto nel loro spazio utente. E non semplifichiamo GPG, OpenSSL, ecc. in modo che tutti dicano "vogliamo" vera casualità "e non ci accontenteremo di meno". Possiamo parlare di come forniamo interfacce ai crittografi in modo che possano ottenere le informazioni di cui hanno bisogno accedendo alle fonti di rumore primarie, separate e denominate, e forse in qualche modo la fonte di rumore può autenticarsi in una libreria o in un'applicazione nello spazio utente."
Si è discusso su come potrebbe apparire un'interfaccia del genere, poiché ad esempio potrebbero esserci implicazioni sulla sicurezza per alcuni eventi. Cao ha notato che i codici di scansione della tastiera (cioè i tasti premuti) sono mescolati in un pool come parte della raccolta di entropia: "Portarli nello spazio utente, anche attraverso una chiamata di sistema privilegiata, sarebbe a dir poco saggio." È del tutto possibile che altri tempi di eventi possano creare una sorta di fuga di informazioni attraverso i canali laterali.
Quindi sembra che un problema di vecchia data con il sottosistema di numeri casuali di Linux sia in via di soluzione. Le modifiche apportate di recente al sottosistema dei numeri casuali hanno in realtà provocato solo problemi DoS durante l'utilizzo. Ora esistono modi efficienti per ottenere i migliori numeri casuali che il kernel può fornire. Se TRNG è ancora desiderabile su Linux, allora questo difetto dovrà essere risolto in futuro, ma molto probabilmente ciò non verrà fatto all'interno del kernel stesso.
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com