RDRAND

RDRAND(de "read random") es una instrucción para devolver números aleatorios desde un generador de números aleatorios de hardware integrado en el chip de Intel que ha sido inicializado por una fuente de entropía integrada en el chip. ^{[ 1 ]} También se conoce como Intel Secure Key Technology , ^{[ 2 ]} con nombre en clave Bull Mountain . ^{[ 3 ]} Intel introdujo la función alrededor de 2012, y AMD agregó soporte para la instrucción en junio de 2015. Está disponible en los procesadores Ivy Bridge ^{[ a ]} ​​y forma parte de las arquitecturas de conjunto de instrucciones Intel 64 e IA-32 . ^{[ 5 ]}RDRAND

El generador de números aleatorios cumple con los estándares de seguridad y criptográficos como NIST SP 800-90A , ^{[ 6 ]} FIPS 140-2 y ANSI X9.82 . ^{[ 1 ]} Tras una solicitud de Intel, Cryptography Research Inc. publicó una investigación sobre RDRAND en el artículo Análisis del generador de números aleatorios digitales Ivy Bridge de Intel . ^{[ 7 ]}

RDSEEDes similar a RDRANDy proporciona acceso de nivel inferior al hardware generador de entropía. La RDSEEDinstrucción del generador y del procesador rdseedestá disponible con las CPU Intel Broadwell ^{[ 8 ]} y las CPU AMD Zen . ^{[ 9 ]}

La CPUIDinstrucción se puede usar tanto en CPU AMD como Intel para comprobar si la RDRANDinstrucción es compatible. Si lo es, el bit 30 del registro ECX se activa después de llamar a la función estándar CPUID 01H. ^{[ 10 ]} Los procesadores AMD se comprueban para la característica usando la misma prueba. ^{[ 11 ]}RDSEED La disponibilidad se puede comprobar en CPU Intel de manera similar. Si RDSEEDes compatible, el bit 18 del registro EBX se activa después de llamar a la función estándar CPUID 07H. ^{[ 12 ]}

El código de operación para RDRANDes 0x0F 0xC7, seguido de un byte ModRM que especifica el registro de destino y opcionalmente combinado con un prefijo REX en modo de 64 bits. ^{[ 13 ]}

Intel Secure Key es el nombre que Intel le da tanto a la RDRANDinstrucción como a la implementación de hardware del generador de números aleatorios (RNG) subyacente, ^{[ 1 ]} que fue nombrado en clave "Bull Mountain" durante el desarrollo. ^{[ 14 ]} Intel llama a su RNG "generador digital de números aleatorios" o DRNG. El generador toma pares de muestras de entropía bruta de 256 bits generadas por la fuente de entropía de hardware y las aplica a un acondicionador del Estándar de Cifrado Avanzado (AES) (en modo CBC-MAC ) que las reduce a una única muestra de entropía acondicionada de 256 bits. Un generador determinista de bits aleatorios llamado CTR DRBG definido en NIST SP 800-90A se inicializa con la salida del acondicionador, proporcionando números aleatorios criptográficamente seguros a las aplicaciones que los solicitan a través de la RDRANDinstrucción. ^{[ 1 ] [ 14 ]} El hardware emitirá un máximo de 511 muestras de 128 bits antes de cambiar el valor de la semilla. Mediante esta RDSEEDoperación se obtiene acceso a las muestras acondicionadas de 256 bits procedentes del AES-CBC-MAC.

La RDSEEDinstrucción se agregó a Intel Secure Key para inicializar otro generador de números pseudoaleatorios, ^{[ 15 ]} disponible en las CPU BroadwellRDSEED . La fuente de entropía para la instrucción se ejecuta de forma asíncrona en un circuito auto-sincronizado y utiliza el ruido térmico dentro del silicio para generar un flujo aleatorio de bits a una velocidad de 3  GHz, ^{[ 16 ]} más lento que los 6,4  Gbit/s efectivos que se pueden obtener de RDRAND(ambas velocidades se comparten entre todos los núcleos e hilos ). ^{[ 17 ]} La RDSEEDinstrucción está destinada a inicializar un PRNG de software de ancho arbitrario, mientras que RDRANDestá destinada a aplicaciones que simplemente requieren números aleatorios de alta calidad. Si no se requiere seguridad criptográfica, un PRNG de software como Xorshift suele ser más rápido. ^{[ 18 ]}

Es una opción para generar números aleatorios criptográficamente seguros utilizando RDRANDOpenSSL RDSEED, para ayudar a proteger las comunicaciones.

Se evaluó la aplicación científica RDRANDen un simulador de Monte CarloRDRAND , centrándose en el rendimiento y la reproducibilidad, en comparación con otros generadores de números aleatorios. Se llegó a la conclusión de que usar en lugar de Mersenne Twister no proporciona resultados diferentes, pero sí un peor rendimiento y reproducibilidad. ^{[ 25 ] [ 20 ]}

En septiembre de 2013, en respuesta a un artículo del New York Times que revelaba el esfuerzo de la NSA por debilitar el cifrado , ^{[ 26 ]} Theodore Ts'o publicó públicamente sobre el uso de RDRANDfor /dev/randomen el kernel de Linux : ^{[ 27 ]}

Me alegra mucho haber resistido la presión de los ingenieros de Intel para que /dev/randomconfiara únicamente en la RDRANDinstrucción. Citando el artículo del New York Times ^{[ 26 ]} : "Para este año, el Proyecto de Habilitación de Sigint había encontrado maneras dentro de algunos de los chips de cifrado que codifican información para empresas y gobiernos, ya sea trabajando con fabricantes de chips para insertar puertas traseras..." Confiar únicamente en el generador de números aleatorios de hardware, que utiliza una implementación sellada dentro de un chip imposible de auditar, es una MALA idea.

Linus Torvalds desestimó las preocupaciones sobre el uso de RDRANDen el kernel de Linux y señaló que no se usa como la única fuente de entropía para /dev/random, sino que se usa para mejorar la entropía combinando los valores recibidos de RDRANDcon otras fuentes de aleatoriedad. ^{[ 28 ] [ 29 ]} Sin embargo, Taylor Hornby de Defuse Security demostró que el generador de números aleatorios de Linux podría volverse inseguro si se introduce una puerta trasera en la RDRANDinstrucción que apunta específicamente al código que lo usa. La implementación de prueba de concepto de Hornby funciona en un kernel de Linux sin modificar anterior a la versión 3.13. ^{[ 30 ] [ 31 ] [ 32 ]} El problema se mitigó en el kernel de Linux en 2013. ^{[ 33 ]}

Los desarrolladores cambiaron el kernel de FreeBSDRDRAND para que no utilizara directamente PadLock con el comentario "Para FreeBSD  10, vamos a retroceder y eliminar RDRANDlos backends de Padlock y alimentarlos a Yarrow en lugar de entregar su salida directamente a /dev/random . Todavía será posible acceder a los generadores de números aleatorios de hardware, es decir RDRAND, Padlock, etc., directamente mediante ensamblador en línea o utilizando OpenSSL desde el espacio de usuario, si es necesario, pero ya no podemos confiar en ellos." ^{[ 28 ] [ 34 ]} FreeBSD /dev/random utiliza Fortuna y RDRAND a partir de FreeBSD  11. ^{[ 35 ]}

El 9 de junio de 2020, investigadores de la Vrije Universiteit Amsterdam publicaron un ataque de canal lateral llamado CrossTalk ( CVE-2020-0543 ) que afectó RDRANDa varios procesadores Intel. ^{[ 36 ]} Descubrieron que las salidas del generador digital de números aleatorios (DRNG) de hardware se almacenaban en un búfer de preparación que se compartía entre todos los núcleos. La vulnerabilidad permitía que el código malicioso que se ejecutaba en un procesador afectado leyera RDRANDlos RDSEEDresultados de las instrucciones de una aplicación víctima que se ejecutaba en otro núcleo del mismo procesador, incluidas las aplicaciones que se ejecutaban dentro de los enclaves Intel SGX . ^{[ 36 ]} Los investigadores desarrollaron un exploit de prueba de concepto ^{[ 37 ]} que extrajo una clave ECDSA completa de un enclave SGX que se ejecutaba en un núcleo de CPU separado después de una sola operación de firma. ^{[ 36 ]} La vulnerabilidad afecta a escenarios donde el código no confiable se ejecuta junto con el código confiable en el mismo procesador, como en un entorno de alojamiento compartido.

Intel se refiere a la vulnerabilidad CrossTalk como muestreo de datos del búfer de registro especial (SRBDS). En respuesta a la investigación, Intel lanzó actualizaciones de microcódigo para mitigar el problema. El microcódigo actualizado garantiza que los accesos fuera del núcleo se retrasen hasta que las operaciones sensibles , específicamente las instrucciones , , y , se completen y el búfer de preparación se haya sobrescrito. ^{[ 21 ]} El ataque SRBDS también afecta a otras instrucciones, como las que leen MSR , pero Intel no aplicó protecciones de seguridad adicionales a ellas debido a preocupaciones de rendimiento y la menor necesidad de confidencialidad de los resultados de esas instrucciones. ^{[ 21 ]} Una amplia gama de procesadores Intel lanzados entre 2012 y 2019 se vieron afectados, incluidos procesadores de escritorio, móviles y de servidor. ^{[ 38 ] [ 39 ]} Las mitigaciones en sí mismas resultaron en impactos negativos en el rendimiento al usar las instrucciones afectadas, particularmente cuando se ejecutan en paralelo por aplicaciones multihilo, debido al aumento de la latencia introducido por las comprobaciones de seguridad y la serialización efectiva de las instrucciones afectadas en todos los núcleos. Intel introdujo una opción de exclusión voluntaria, configurable a través del MSR en cada procesador lógico, que mejora el rendimiento al deshabilitar las comprobaciones de seguridad adicionales para las instrucciones que se ejecutan fuera de un enclave SGX. ^{[ 21 ]} RDRANDRDSEEDEGETKEY IA32_MCU_OPT_CTRL

En octubre de 2025, Gregory Price de Meta Platforms descubrió un problema con la instrucción RDSEED en los procesadores AMD Zen 5. Debido a este problema, la instrucción RDSEED podía devolver un valor de 0 en lugar de un número aleatorio, indicando incorrectamente que la operación había tenido éxito. Esto solo afectaba a las versiones de 16 y 32 bits de la instrucción, no a la de 64 bits. ^{[ 40 ] [ 41 ]}

• Conjunto de instrucciones AES
• Bullrun (programa de descifrado)

• Proyecto de código abierto RdRand .NET