Salvataggio di seed casuali al riavvio / arresto e ripristino durante l'avvio del sistema

Why do that at all, in the first place. Do we need to "preserve" the random seed between restarts ? What would happen if we don't? Will the computer have 0 randomness when it boots?

Questa risulta essere una domanda molto più profonda di quanto tu possa immaginare. Cercherò di renderlo giustizia senza scrivere un libro di testo.

Fondamentalmente: i computer fanno schifo a caso; quando hai una certa casualità (aka entropia), è una buona idea tenerti stretto.

Supponiamo che il tuo computer non abbia un generatore di numeri casuali dell'hardware. (I moderni chip Intel hanno l'istruzione rdrand che si collega a un hardware rng, ma per ragioni politiche, il kernel Linux non lo usa.)

Al boot, da dove viene il puro casualness del kernel? Secondo Wikipedia :

The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom. This capability was introduced in Linux version 1.3.30.

Quindi mouse, tastiera e tempistica degli eventi I / O del disco fisso. Diciamo che hai bisogno di entropia durante l'avvio del sistema operativo (ad esempio, si avvia sshd che deve generare chiavi al suo primo avvio), non hai ancora caricato i driver del mouse e della tastiera e che all'inizio del ciclo di avvio non ho fatto moltissime chiamate di I / O del disco - diavolo, abbastanza presto nel boot il kernel è ancora in esecuzione in una RAM FS, e anche dopo potresti essere su un SSD o una chiavetta che ha tempi IO molto prevedibili.

Quindi torna alla tua domanda:

What would happen if we don't? Will the computer have 0 randomness when it boots?

È possibile.

Su piccoli dispositivi Linux embedded come i router che si avviano dalla memoria flash (sia quelli di piccole dimensioni che quelli di grandi dimensioni che alimentano Internet), questo è in realtà un problema serio.

Per una lettura fantastica su questo argomento, vedere il documento del 2012 Estrazione di Ps e Q: Rilevazione di chiavi deboli diffuse in Dispositivi di rete che ha la scoperta scioccante che

0.75% of TLS certificates [on the internet] share keys due to insufficient entropy during key generation.

Solo poche righe sotto il Short-Description che hai citato, /etc/init.d/urandom nota alcune ipotesi sulla segretezza:

## Assumption 1:  We assume [/var/lib/urandom/random-seed] is a file (or a symlink
## to a file) that resides on a non-volatile medium that persists
## across reboots.
## Case 1a: Ideally, it is readable and writeable.  Its is unshared,
## i.e. its contents are unique to this machine.  It is protected so
## that its contents are not known to attackers.
## Case 1b: Less than ideally, it is read-only.  Its contents are
## unique to this machine and not known to attackers.

Più tardi in quel file, dove il seme è scritto sul disco, c'è un commento:

# see documentation in linux/drivers/char/random.c

che vale la pena leggere ma include:

* When any operating system starts up, it will go through a sequence
* of actions that are fairly predictable by an adversary, especially
* if the start-up does not involve interaction with a human operator.
* This reduces the actual number of bits of unpredictability in the
* entropy pool below the value in entropy_count.  In order to
* counteract this effect, it helps to carry information in the
* entropy pool across shut-downs and start-ups.

... Even with
* complete knowledge of the start-up activities, predicting the state
* of the entropy pool requires knowledge of the previous history of
* the system.

Salvare l'entropia tra i riavvii è una soluzione imperfetta alla carenza di entropia all'avvio. Perché imperfetto? Primo, perché l'entropia salvata è rilevabile, se il potenziale attaccante potrebbe ottenere una sospensione di quel seme salvato potrebbero anche compromettere tutti i generatori di numeri casuali seminati con esso. Secondo, perché quando il sistema viene ripristinato da backup o più istanze VM generate con lo stesso seme salvato, tutte riutilizzeranno la stessa entropia salvata.

Tuttavia, tali disastri sono ancora preferibili a non avere entropia di avvio disponibile per il tuo sistema.

Ricorda che se configuri per salvare entropia, la tua soluzione non sarà certificabile, in quanto FIPS e praticamente qualsiasi altro standard relativo a crittografia e infosec proibisce questa pratica.