/dev/aleatorio

La generación de números aleatorios en el espacio del kernel se implementó por primera vez para Linux ^{[ 2 ]} en 1994 por Theodore Ts'o . ^{[ 6 ]} La implementación utilizó funciones hash seguras en lugar de cifrados , para evitar las restricciones de exportación de criptografía vigentes cuando se diseñó originalmente el generador. La implementación también se diseñó bajo el supuesto de que cualquier función hash o cifrado podría eventualmente resultar débil, por lo que el diseño es robusto ante tales debilidades. La recuperación rápida ante el compromiso del pool no se considera un requisito, ya que los requisitos para el compromiso del pool son suficientes para ataques mucho más fáciles y directos a partes no relacionadas del sistema operativo.

En la implementación de Ts'o, el generador mantiene una estimación del número de bits de ruido en el pool de entropía . A partir de este pool de entropía se crean números aleatorios. Al leerse, el dispositivo /dev/random solo devolverá bytes aleatorios dentro del número estimado de bits de ruido en el pool de entropía. Cuando el pool de entropía está vacío, las lecturas de /dev/random se bloquearán hasta que se recoja ruido ambiental adicional. ^{[ 7 ]} El objetivo es que funcione como un generador de números pseudoaleatorios criptográficamente seguro , que proporcione una salida con la mayor entropía posible. Los autores sugieren su uso para generar claves criptográficas para protección de alto valor o a largo plazo. ^{[ 7 ]}

Una contraparte de /dev/random es /dev/urandom ("ilimitado" ^{[ 8 ]} /fuente aleatoria no bloqueante ^{[ 7 ]} ) que reutiliza el pool interno para producir más bits pseudoaleatorios. Esto significa que la llamada no se bloqueará, pero la salida puede contener menos entropía que la lectura correspondiente de /dev/random . Si bien /dev/urandom todavía está pensado como un generador de números pseudoaleatorios adecuado para la mayoría de los propósitos criptográficos, los autores de la página man correspondiente señalan que, teóricamente, puede existir un ataque aún no publicado al algoritmo utilizado por /dev/urandom , y que los usuarios preocupados por tal ataque deberían usar /dev/random en su lugar. ^{[ 7 ]} Sin embargo, es poco probable que tal ataque exista, porque una vez que el pool de entropía es impredecible, no filtra seguridad por una cantidad reducida de bits. ^{[ 9 ]}

También es posible escribir en /dev/random . Esto permite a cualquier usuario mezclar datos aleatorios en el pool. Los datos no aleatorios son inofensivos, ya que solo un usuario con privilegios puede emitir la llamada ioctl necesaria para aumentar la estimación de entropía. La cantidad actual de entropía y el tamaño del pool de entropía del kernel de Linux, ambos medidos en bits, están disponibles en /proc/sys/kernel/random/ y se pueden mostrar con el comando y respectivamente.cat /proc/sys/kernel/random/entropy_availcat /proc/sys/kernel/random/poolsize

Gutterman, Pinkas y Reinman publicaron en marzo de 2006 un análisis criptográfico detallado del generador de números aleatorios de Linux ^{[ 10 ]} en el que describen varias debilidades. Quizás el problema más grave que reportan se da en sistemas embebidos o Live CD , como enrutadores y clientes sin disco , para los cuales el estado de arranque es predecible y el suministro disponible de entropía del entorno puede ser limitado. Para un sistema con memoria no volátil , recomiendan guardar parte del estado del generador de números aleatorios al apagarlo para que pueda incluirse en el estado del generador de números aleatorios en el siguiente reinicio. En el caso de un enrutador para el cual el tráfico de red representa la principal fuente disponible de entropía, señalan que guardar el estado entre reinicios "requeriría que los atacantes potenciales interceptaran todo el tráfico de red" desde que el enrutador se pone en servicio por primera vez, u obtuvieran acceso directo al estado interno del enrutador. Este problema, señalan, es particularmente crítico en el caso de un enrutador inalámbrico cuyo tráfico de red puede capturarse a distancia y que puede estar utilizando el generador de números aleatorios para generar claves para el cifrado de datos.

El kernel de Linux proporciona soporte para varios generadores de números aleatorios de hardware , en caso de que estén instalados. La salida sin procesar de dicho dispositivo se puede obtener desde /dev/hwrng . ^{[ 11 ]}

Con el kernel de Linux 3.16 y versiones posteriores, ^{[ 12 ]} el propio kernel mezcla datos de generadores de números aleatorios de hardware en /dev/random en una escala variable basada en la calidad de estimación de entropía definible del HWRNG. Esto significa que no se necesita ningún demonio de espacio de usuario, como rngd de rng-tools , para realizar esa tarea.

El conjunto de entropía se puede mejorar con programas como timer_entropyd , haveged , randomsound , etc. Con rng-tools , los generadores de números aleatorios por hardware como Entropy Key, etc., pueden escribir en /dev/random . Los programas de prueba diehard , dieharder y ent pueden probar estos generadores de números aleatorios. ^{[ 13 ] [ 14 ] [ 15 ] [ 16 ]}

En enero de 2014, Daniel J. Bernstein publicó una crítica ^{[ 17 ]} sobre cómo Linux mezcla diferentes fuentes de entropía. Describe un ataque en el que una fuente de entropía capaz de monitorear las otras fuentes de entropía podría modificar su salida para anular la aleatoriedad de las otras fuentes de entropía. Considere la función ⁠${\displaystyle H(x,y,z)}$donde H es una función hash y x , y , z son fuentes de entropía, siendoz la salida de un HRNG malicioso basado en CPU Z:

1. Z genera un valor aleatorio de r .
2. Z calcula​${\displaystyle H(x,y,r)}$⁠ .
3. Si la salida de${\displaystyle H(x,y,r)}$⁠ es igual al valor deseado, imprime r como z .
4. De lo contrario, repita comenzando desde 1.

Bernstein estimó que un atacante necesitaría repetir ⁠${\displaystyle H(x,y,r)}$16 veces para comprometer DSA y ECDSA, haciendo que los primeros cuatro bits de la salida del RNG sean 0. Esto es posible porque Linux reinicializa H de forma continua en lugar de usar una única semilla de alta calidad. ^{[ 17 ]}

Bernstein también argumenta que la inyección de entropía es inútil una vez que el CSPRNG ha sido inicializado. ^{[ 17 ]}

En el kernel 5.17 (con retrocompatibilidad en el kernel 5.10.119), Jason A. Donenfeld propuso un nuevo diseño para la infraestructura del pool de entropía de Linux. Donenfeld informó que el pool anterior, que consistía en un único LFSR de 4096 bits , era vulnerable a dos ataques: (1) un atacante podía deshacer el efecto de una entrada conocida; (2) si se filtraba el estado completo del pool, un atacante podía establecer todos los bits del pool a cero. Su nuevo diseño, más rápido y seguro, utiliza la función hash blake2s para mezclar un pool de 256 bits. ^{[ 18 ]}