Il driver di casualità del kernel Linux raccoglie entropia dall'ambiente. Poiché durante l'avvio ci sarà poca entropia, un seme casuale viene spesso mantenuto a /var/lib/misc/random-seed o ad una posizione simile. Quando il sistema si arresta, un nuovo seme casuale da 512 byte viene scritto in questo file. All'avvio del sistema, questo file viene scritto su /dev/urandom , che lo aggiunge al pool di entropia. Il punto è quello di consentire lo stato del pool di entropia di persistere attraverso i riavvii. Ci sono problemi:
-
I dati scritti nel pool non bloccante vengono messi per la prima volta nel pool di input e saranno utilizzabili solo dopo aver raccolto abbastanza entropia per un "reseeding catastrofico". Ciò significa che potrebbero essere necessari alcuni minuti prima che entropia nel seme casuale abbia effettivamente effetto sul CSPRNG.
-
Per lo stesso motivo, se il sistema si avvia e poi si spegne entro pochi minuti, il nuovo seme che viene scritto non avrà entropia dal seme precedente, rendendo molto più facile da prevedere. Questo è probabilmente un problema per i sistemi che possono avere un uptime molto basso, poiché significa che resetteranno in modo efficace i loro semi entropici persistenti abbastanza spesso.
La mia analisi è corretta? Quali sono le implicazioni del mondo reale di questi problemi? Per esempio, ci sono sistemi di uso comune (specialmente sistemi embedded) che richiedono casualità imprevedibile entro pochi minuti dal riavvio o che possono avere tempi di operatività molto brevi?
Nel driver randomness del kernel, scrivi a entrambi i pool di blocco o non bloccanti attivano l'operazione random_write() e al suo interno, write_pool() con il pool di input specificato come l'argomento. Il pool di input viene periodicamente utilizzato per eseguire il reseeding del pool di blocchi tramite push_to_pool() funzione workqueue. Il pool di nonblocco verrà resettato dal pool di input ogni 5 minuti quando _extract_crng() viene chiamato per estrarre i dati dal pool non bloccante (supponendo che siano stati aggiunti almeno 128 bit di entropia al pool di input dall'ultimo seeding). Questo flusso di informazioni implica che il seme casuale memorizzato attraverso i riavvii influirà solo sul contenuto del pool di blocco dopo un resement catastrofico (64 bit) e il CRNG non bloccante ogni 5 minuti.