La semilla aleatoria no se propaga a los grupos de entropía de manera oportuna

Question

La semilla aleatoria no se propaga a los grupos de entropía de manera oportuna

#1 de Kirill Sinitski (1 votos)

9

El controlador de aleatoriedad del kernel de Linux recopila la entropía del entorno. Debido a que habrá poca entropía durante el arranque, una semilla aleatoria a menudo se mantiene en /var/lib/misc/random-seed o en una ubicación similar. Cuando el sistema se apaga, se escribe una nueva semilla aleatoria de 512 bytes en este archivo. Cuando el sistema se inicia, este archivo se escribe en /dev/urandom , lo que lo agrega al grupo de entropía. El punto es permitir que el estado de la agrupación de entropía persista en los reinicios. Hay problemas:

Los datos escritos en el grupo de no bloqueos se colocan primero en el grupo de entrada, y solo se podrán utilizar después de recopilar suficiente entropía para una "reinicialización catastrófica". Esto significa que puede tomar unos minutos para que la entropía en la semilla aleatoria afecte realmente al CSPRNG.
Por la misma razón, si el sistema se inicia y luego se apaga en unos minutos, la nueva semilla escrita no tendrá entropía de la semilla anterior, lo que hace que sea mucho más fácil de predecir. Es probable que este sea un problema para los sistemas que pueden tener un tiempo de actividad muy bajo, ya que significa que restablecerán su semilla de entropía persistente con bastante frecuencia.

¿Mi análisis es correcto? ¿Cuáles son las implicaciones reales de estos problemas? Por ejemplo, ¿hay algún sistema de uso común (especialmente sistemas integrados) que requiera aleatoriedad impredecible unos minutos después del reinicio, o que tenga un tiempo de actividad muy corto?

En el controlador de aleatoriedad del kernel, escribiendo a cualquiera las agrupaciones de bloqueo o no bloqueado activan la operación random_write() y dentro de él, write_pool() con el grupo de entrada especificado como el argumento. El grupo de entrada se usa periódicamente para reiniciar el grupo de bloqueo a través de push_to_pool() función de cola de trabajo. La agrupación sin bloqueo se reiniciará desde la agrupación de entrada cada 5 minutos cuando % co_de Se llama a% para extraer datos de la agrupación sin bloqueo (suponiendo que al menos 128 bits de entropía se hayan agregado a la agrupación de entrada desde la última reinicialización). Este flujo de información implica que la semilla aleatoria almacenada durante los reinicios solo afectará el contenido del grupo de bloqueo después de una reinicialización catastrófica (64 bits) y el CRNG sin bloqueo cada 5 minutos.

linux random entropy

pregunta forest 12.04.2018 - 02:09

fuente

1 respuesta

Lea otras preguntas en las etiquetas linux random entropy

¿Por qué WPA3 utiliza el cifrado de 192 bits? Sistemas de contraseña de prueba de conocimiento cero

score 1 · Answer 1

Hay algunas suposiciones que debo cuestionar:

A. "Porque habrá poca entropía durante el arranque".

B. "El punto es permitir que el estado del grupo de entropía persista en los reinicios"

Direccionamiento A: Si bien es posible que la configuración específica del sistema utilice problemas de baja entropía, esto no es una ocurrencia típica. Sin embargo, " Extracción de sus Ps y Q: Detección de claves débiles generalizadas en dispositivos de red " por N. Heninger describe dicha condición en sistemas sin cabeza. Para que ocurra esta condición, deben estar ausentes múltiples fuentes de entropía u operar con un rendimiento degradado. Primero, debe ser un sistema sin cabeza, por lo que no hay entropía de add_input_randomness (). En segundo lugar, la actividad del controlador debe ser muy limitada y esto incluye la tarjeta de red, por lo que hay pocas interrupciones en la activación de add_interrupt_randomness (). En tercer lugar, no debe haber ningún dispositivo de bloque (por ejemplo, disco duro), por lo que add_disk_randomness () no genera entropía. Por ejemplo, el SATA3 SSD moderno generará alrededor de 200 bits de entropía por sí mismo durante el arranque mediante add_disk_randomness ().

Direccionamiento B: Guardar el estado del grupo de entropía es una solución incompleta para un problema grave. Si tiene una entropía de arranque baja, ese es el problema clave en el que debe enfocarse. Si también reinicia con frecuencia, ese problema se vuelve catastrófico. Mejorar el diseño de entropía guardado no resolverá el problema subyacente de la falta de entropía.