Guardando semillas aleatorias al reiniciar / apagar, y restaurándolas durante el arranque del sistema

  

¿Por qué hacer eso, en primer lugar? ¿Necesitamos "preservar" la semilla aleatoria entre reinicios? ¿Qué pasaría si no lo hacemos? ¿Tendrá la computadora una aleatoriedad 0 cuando arranque?

Esto resulta ser una pregunta mucho más profunda de lo que te imaginas. Intentaré hacerle justicia sin escribir un libro de texto.

Básicamente: las computadoras apestan al azar; cuando tienes algo de aleatoriedad real (también conocida como entropía), es una buena idea mantenerla.

Supongamos que su computadora no tiene un generador de números aleatorios de hardware. (Los chips de Intel modernos tienen la instrucción rdrand que se conecta a un hardware rng, pero por razones políticas, el kernel de Linux no lo usa).

En el arranque, ¿de dónde obtiene el núcleo una aleatoriedad pura? Según Wikipedia :

  

El kernel de Linux genera entropía a partir de los tiempos del teclado, los movimientos del mouse y los tiempos IDE, y hace que los datos de caracteres aleatorios estén disponibles para otros procesos del sistema operativo a través de los archivos especiales / dev / random y / dev / urandom. Esta capacidad se introdujo en la versión 1.3.30 de Linux.

Por lo tanto, el mouse, el teclado y la sincronización de los eventos de IO del disco duro. Digamos que necesita la entropía durante el inicio del sistema operativo (por ejemplo, inicia sshd que necesita generar claves en su primer inicio), aún no ha cargado los controladores del teclado y del mouse, y que al principio del ciclo de inicio no lo hará. han realizado muchas llamadas de E / S en el disco - demonios, con suficiente antelación en el arranque, el kernel todavía se está ejecutando en una RAM FS, e incluso después de eso puede estar en un SSD o una unidad flash que tiene tiempos de E / S muy predecibles.

Entonces volvamos a tu pregunta:

  

¿Qué pasaría si no lo hacemos? ¿Tendrá la computadora una aleatoriedad 0 cuando arranque?

Es posible.

En los dispositivos Linux incrustados pequeños, como los enrutadores que arrancan desde la memoria flash (tanto los pequeños como los grandes centros de datos que alimentan Internet), este es realmente un problema grave.

Para una lectura impresionante sobre este tema, vea el documento de 2012 Extracción de sus Ps y Qs: Detección de claves débiles generalizadas en Dispositivos de red que tiene el sorprendente descubrimiento de que

  

El 0,75% de los certificados TLS [en Internet] comparten claves debido a una entropía insuficiente durante la generación de claves.

Solo unas pocas líneas debajo del Short-Description que citó, /etc/init.d/urandom señala algunas suposiciones sobre el secreto:

## 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.

Más adelante en ese archivo, donde se escribe la semilla en el disco, hay un comentario:

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

que vale la pena leer pero incluye:

* 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.

Guardar la entropía entre reinicios es una solución imperfecta para la escasez de entropía durante el arranque. ¿Por qué imperfecto? Primero, porque la entropía guardada es visible, si un atacante potencial pudiera obtener esa semilla guardada, también podría comprometer a todos los generadores de números aleatorios que se hayan sembrado con ella. Segundo, porque cuando el sistema se restaura desde copias de seguridad o varias instancias de VM generadas con la misma semilla guardada, todos reutilizarán la misma entropía guardada.

Aún así, tales desastres son aún preferibles a no tener una entropía de tiempo de arranque disponible para su sistema.

Tenga en cuenta que si configura para guardar la entropía, su solución no será certificable, ya que FIPS y prácticamente cualquier otra norma relacionada con crypto e infosec prohíbe esta práctica.