En Linux, los archivos /dev/randomy los/dev/urandom archivos son las fuentes de bloqueo y no bloqueo (respectivamente) de bytes pseudoaleatorios.
Se pueden leer como archivos normales:
$ hexdump /dev/random
0000000 28eb d9e7 44bb 1ac9 d06f b943 f904 8ffa
0000010 5652 1f08 ccb8 9ee2 d85c 7c6b ddb2 bcbe
0000020 f841 bd90 9e7c 5be2 eecc e395 5971 ab7f
0000030 864f d402 74dd 1aa8 925d 8a80 de75 a0e3
0000040 cb64 4422 02f7 0c50 6174 f725 0653 2444
...
Muchas otras variantes de Unix proporcionan /dev/randomy /dev/urandomtambién, sin la distinción de bloqueo / no bloqueo.
El equivalente de Windows es la CryptGenRandom()función .
¿Cómo genera el sistema operativo pseudoaleatoriedad?
operating-systems
cryptography
randomness
security
entropy
Adam Matan
fuente
fuente
Respuestas:
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:
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:
Por lo tanto, el RNG en un sistema operativo casi siempre funciona así :
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.
fuente
Además de la respuesta de Gilles, las interrupciones también se pueden usar para establecer la entropía. En Linux, por ejemplo, al agregar un controlador de interrupciones, puede definir si la ocurrencia de esta interrupción debe usarse como una contribución al grupo de entropía del núcleo.
Por supuesto, este nunca debería ser el caso con las interrupciones que un atacante podría determinar. Por ejemplo, a primera vista, el tráfico de red (es decir, sus interrupciones resultantes) parece ser una buena fuente de aleatoriedad. Sin embargo, un atacante podría manipular su tráfico de manera que luego pueda predecir la aleatoriedad que necesita para alguna operación.
fuente