El título y el cuerpo de su pregunta hacen dos preguntas diferentes: cómo el sistema operativo crea la entropía (esto realmente debería obtener entropía) y cómo genera pseudoaleatoriedad a partir de esta entropía. Comenzaré explicando la diferencia.
¿De dónde viene la aleatoriedad?
Los generadores de números aleatorios (RNG) vienen en dos tipos:
Algunas aplicaciones, como las simulaciones de fenómenos físicos, pueden contentarse con números aleatorios que pasan pruebas estadísticas. Otras aplicaciones, como la generación de claves criptográficas, requieren una propiedad más fuerte: la imprevisibilidad . La imprevisibilidad es una propiedad de seguridad, no (solo) una propiedad estadística: significa que un adversario no puede adivinar la salida del generador de números aleatorios. (Más precisamente, puede medir la calidad del RNG midiendo la probabilidad de que un adversario adivine cada bit de salida de RNG. Si la probabilidad es considerablemente diferente de 1/2, el RNG es malo).
Hay fenómenos físicos que producen datos aleatorios con buenas propiedades estadísticas, por ejemplo, desintegración radiactiva, o algunas observaciones astronómicas de ruido de fondo o fluctuaciones del mercado de valores. Dichas mediciones físicas necesitan acondicionamiento ( blanqueamiento ) para convertir las distribuciones de probabilidad sesgadas en una distribución de probabilidad uniforme. Una medición física que todos conocen no es buena para la criptografía: las fluctuaciones del mercado de valores pueden ser buenas para geohashing , pero no se pueden usar para generar claves secretas .
La criptografía requiere secreto : un adversario no debe poder averiguar los datos que entraron en el condicionamiento. Existen generadores de números pseudoaleatorios criptográficamente seguros (CSPRNG): algoritmos PRNG cuya salida es adecuada para su uso en aplicaciones criptográficas, además de tener buenas propiedades estadísticas . Una de las propiedades que hacen que un CSPRNG sea criptográficamente seguro es que su salida no permite que un adversario reconstruya el estado interno (conocer todos los bits pero uno producido por un CSPRNG no ayuda a encontrar el bit que falta). No explicaré cómo hacer un CSPRNG porque esa es la parte fácil: puede seguir las recetas dadas por criptógrafos profesionales (use un estándaralgoritmo, como Hash_DRBG, HMAC_DRBG o CTR_DRBG de NIST SP 800-90A ) o el ANSI X9.31 PRNG . El CSPRNG requiere dos propiedades de su estado para ser seguro:
- El estado debe mantenerse en secreto desde el principio y en todo momento (aunque la exposición del estado no revelará resultados pasados).
- El estado debe ser lineal: el RNG nunca debe iniciarse dos veces desde el mismo estado.
Arquitectura de un generador de números aleatorios.
En la práctica, casi todos los buenos generadores de números aleatorios combinan un CSPRNG con una o más fuentes de entropía . Para decirlo de manera sucinta, la entropía es una medida de la imprevisibilidad de una fuente de datos. Basar un generador de números aleatorios únicamente en un RNG de hardware es difícil:
- Es probable que los datos físicos sin procesar necesiten acondicionamiento de todos modos para convertir los datos probabilísticos en una distribución uniforme.
- La salida de la fuente de aleatoriedad debe mantenerse en secreto.
- Las fuentes de entropía son a menudo lentas en comparación con la demanda.
Por lo tanto, el RNG en un sistema operativo casi siempre funciona así :
- Acumula suficiente entropía para construir un estado interno impredecible.
- Ejecute un CSPRNG , utilizando la entropía acumulada como semilla, es decir, como el valor inicial del estado interno.
- Opcionalmente, mezcle periódicamente entropía adicional en el estado interno. (Esto no es estrictamente necesario, ya que la entropía no se "consume" a ningún ritmo medible . Ayuda contra ciertas amenazas que filtran el estado RNG sin comprometer todo el sistema).
Un servicio de generación de números aleatorios es parte del trabajo de un sistema operativo, porque la recopilación de entropía requiere acceso al hardware, y las fuentes de entropía constituyen un recurso compartido: el sistema operativo debe ensamblarlas y derivar resultados de ellas que se adapten a las aplicaciones. Se requiere un condicionamiento pseudoaleatorio de las fuentes de entropía en el sistema operativo; también podría ser criptográficamente seguro, porque esto no es fundamentalmente más difícil (y se requiere en sistemas operativos donde las aplicaciones no confían entre sí; en sistemas totalmente cooperativos, cada aplicación tendría que ejecutar su propio CSPRNG internamente si el sistema operativo no proporcionó uno de todos modos).
La mayoría de los sistemas con almacenamiento persistente cargarán una semilla RNG del disco (usaré "disco" como abreviatura para cualquier tipo de almacenamiento persistente) cuando arranquen y sobrescribirán la semilla con algunos datos pseudoaleatorios nuevos generados a partir de esa semilla, o si está disponible con datos aleatorios generados a partir de esa semilla más otra fuente de entropía. De esta manera, incluso si la entropía no está disponible después de un reinicio, la entropía de una sesión anterior se reutiliza.
Se debe tener cuidado con el estado guardado. ¿Recuerdas cómo dije que el estado debe ser lineal? Si inicia dos veces desde el mismo estado del disco, obtendrá las mismas salidas RNG. Si esta es una posibilidad en su entorno, necesita otra fuente de entropía. Tenga cuidado al restaurar desde copias de seguridad o al clonar una máquina virtual . Una técnica para la clonación es mezclar la entropía almacenada con algunos datos ambientales que son predecibles pero únicos (por ejemplo, hora y dirección MAC); tenga en cuenta que si los datos ambientales son predecibles, cualquier persona que posea el estado de VM almacenado puede reconstruir la semilla de una instancia de VM bifurcada.
Fuentes de entropía
Encontrar (y usar correctamente) fuentes de entropía es la parte más desafiante de la generación de números aleatorios en un sistema operativo. Las fuentes de entropía disponibles dependerán necesariamente del hardware y del entorno en el que se ejecute el hardware.
Si tiene suerte, su hardware proporciona un periférico que se puede utilizar como fuente de entropía: un generador de números aleatorios de hardware , ya sea dedicado o de uso lateral. Por ejemplo:
NIST SP800-90B proporciona pautas de diseño para hardware RNG. Evaluar un RNG de hardware es difícil . Los RNG de hardware suelen ser bestias delicadas, que deben usarse con cuidado: muchos tipos requieren un tiempo después del arranque y un tiempo entre lecturas para desestabilizar, a menudo son sensibles a las condiciones ambientales como la temperatura, etc.
Los procesadores Intel x86-64 basados en la arquitectura Ivy Bridge proporcionan la RdRandinstrucción que proporciona la salida de un CSPRNG sembrado por ruido térmico . La mayoría de los procesadores de teléfonos inteligentes incluyen una fuente de entropía de hardware, aunque Android no siempre la usa.
Los sistemas que carecen de una fuente de entropía fuerte tienen que ver con la combinación de fuentes de entropía débiles y con la esperanza ( asegurando que sería una palabra demasiado fuerte) de que serán suficientes. Los movimientos aleatorios del mouse son populares para las máquinas cliente, y es posible que haya visto el programa de seguridad de ciertos programas de criptografía que le piden que mueva el mouse (aunque en cualquier sistema operativo de PC del siglo XXI el sistema operativo habrá acumulado entropía sin que la aplicación tenga que molestarse )
Si desea ver un ejemplo, puede mirar Linux, aunque tenga en cuenta que no es perfecto . En particular, se /dev/randombloquea con demasiada frecuencia (porque bloquea hasta que haya suficiente entropía disponible, con una noción demasiado conservadora de entropía), mientras /dev/urandomque casi siempre es bueno, excepto en el primer arranque, pero no indica cuándo no tiene suficiente entropía. Linux tiene controladores para muchos dispositivos HRNG y acumula entropía de varios dispositivos (incluidos los dispositivos de entrada ) y los tiempos de disco .
Si tiene almacenamiento persistente (confidencial), puede usarlo para guardar la entropía de un arranque a otro, como se indicó anteriormente. El primer arranque es un momento delicado: el sistema puede estar en un estado bastante predecible en ese punto, especialmente en dispositivos producidos en masa que esencialmente operan fuera de la fábrica de la misma manera. Algunos dispositivos integrados que tienen almacenamiento persistente se aprovisionan con una semilla inicial en la fábrica (producida por un RNG que se ejecuta en una computadora en la fábrica). En entornos de servidores virtualizados, la entropía inicial se puede aprovisionar al instanciar una máquina virtual desde el host o desde un servidor de entropía.
Los dispositivos mal sembrados son un problema generalizado en la práctica: un estudio de claves RSA públicas descubrió que muchos servidores y dispositivos tenían claves generadas con un RNG deficiente, probablemente un buen PRNG que no estaba suficientemente sembrado. Como diseñador de sistemas operativos, no puede resolver este problema por su cuenta: es el trabajo de la entidad que controla la cadena de implementación asegurarse de que el RNG se sembrará correctamente en el primer arranque. Su tarea como diseñador de sistemas operativos es proporcionar un RNG adecuado, incluida una interfaz para proporcionar esa primera semilla, y garantizar una señalización de error adecuada si se utiliza el RNG antes de que se siembre correctamente.