NIST SP 800-90A: estándares DRBG

Las operaciones criptográficas necesitan números aleatorios de alta calidad: para generar claves, nonces, IVs, salts y tokens de sesión. Los generadores de números aleatorios verdaderos (TRNGs) obtienen entropía de fuentes físicas (ruido del hardware, interrupciones y ruido térmico), pero son lentos y no siempre están disponibles, especialmente en máquinas virtuales o durante el arranque temprano. Los generadores deterministas de bits aleatorios (DRBGs) resuelven este problema: se siembra un DRBG con una pequeña cantidad de entropía verdadera y se utiliza un algoritmo criptográfico para expandirla en un flujo grande de bits seudoaleatorios que son computacionalmente indistinguibles de bits verdaderamente aleatorios. NIST SP 800-90A define tres mecanismos DRBG aprobados que se utilizan en prácticamente todas las implementaciones criptográficas modernas.

Un DRBG funciona mediante tres operaciones fundamentales. Instantiate: inicializa el estado interno del DRBG utilizando entropy_input (de una fuente de entropía), un nonce (un valor de un solo uso que garantiza la unicidad) y, opcionalmente, personalization_string (un contexto específico de la aplicación). Generate: produce el número solicitado de bits seudoaleatorios y actualiza el estado interno para impedir el backtracking. Reseed: incorpora entropía nueva al estado del DRBG para proporcionar resistencia a la predicción; después de un Reseed, incluso un adversario que conociera el estado anterior no puede predecir las salidas futuras. NIST especifica intervalos máximos de generación (reseed_interval): 2^48 solicitudes antes del Reseed obligatorio para los tres tipos de DRBG.

NIST SP 800-90A define cuatro niveles de fortaleza de seguridad: 112, 128, 192 y 256 bits. La fortaleza de seguridad determina la entropía mínima necesaria durante la inicialización y la calidad de la salida generada. Para una seguridad de 128 bits, la entrada de entropía debe proporcionar al menos 128 bits de entropía. La relación es: una entropía de security_strength bits -> una salida de DRBG computacionalmente indistinguible de aleatoria para un adversario que realice 2^security_strength operaciones. Las opciones de longitud de clave (AES-128 frente a AES-256) y de hash (SHA-256 frente a SHA-512) deben igualar o superar la fortaleza de seguridad deseada. Utilizar parámetros excesivos (SHA-512 para una seguridad de 128 bits) es seguro, pero desperdicia recursos; utilizar parámetros insuficientes compromete la seguridad.

Hash_DRBG mantiene dos valores de estado: V (un valor que genera la salida) y C (una constante que se suma durante Generate). Generate: hash_gen produce bits mediante la iteración de H(0x01 || V), H(0x01 || V+1), ... hasta disponer de suficiente salida; después, V se actualiza mediante V = V + H(0x03 || V) + C + reseed_counter. Reseed: utiliza Hash_df (función de derivación hash) para combinar el V actual con entropía nueva y producir nuevos valores de V y C. Hash_DRBG es sencillo de implementar y su análisis de seguridad es simple, por lo que resulta adecuado para entornos con recursos limitados. NIST recomienda inicializarlo con SHA-256 o SHA-512. Hash_DRBG se utiliza en SHA1PRNG de Java (versiones antiguas) y en el DRBG heredado de OpenSSL.

HMAC_DRBG mantiene un estado compuesto por la clave K y el valor V. Generate: itera V = HMAC(K, V) hasta producir suficiente salida; después, K = HMAC(K, V || 0x00) y V = HMAC(K, V). Update: toma additional_input y vuelve a sembrar K y V mediante operaciones HMAC. HMAC_DRBG cuenta con una demostración de seguridad clara basada en la seguridad de HMAC (la suposición de PRF sobre HMAC). Es el DRBG recomendado con mayor frecuencia: OpenSSL (desde 1.1.1), mbedTLS, wolfSSL y la mayoría de las pilas TLS utilizan HMAC_DRBG. La construcción HMAC proporciona una mezcla integrada entre llamadas sucesivas, lo que dificulta la ejecución de ataques de backtracking incluso si el estado queda parcialmente expuesto.

CTR_DRBG utiliza un cifrador de bloque (AES) en modo contador. Estado: clave K y contador V. Generate: cifra valores sucesivos del contador E(K, V), E(K, V+1), ... e incrementa V. Update: utiliza Block_Cipher_df para derivar nuevos valores de K y V a partir de additional_input. CTR_DRBG es el DRBG más rápido: la aceleración de hardware AES-NI lo hace varios órdenes de magnitud más rápido que los DRBG basados en hash en los procesadores modernos. Es el DRBG predeterminado de Windows CNG (CryptGenRandom utiliza CTR_DRBG con AES-256), de OpenSSL 3.0 (predeterminado) y del RNG del kernel de Linux (llamada al sistema getrandom). La seguridad de CTR_DRBG depende de que AES sea una permutación seudoaleatoria, una propiedad respaldada por décadas de análisis.

La resistencia a la predicción es una propiedad por la que la salida del DRBG sigue siendo impredecible incluso para un adversario que haya comprometido previamente el estado del DRBG, siempre que se incorpore entropía nueva mediante un Reseed. Un DRBG con prediction_resistance_flag=true consulta la fuente de entropía antes de cada llamada a Generate para incorporar entropía nueva. Sin resistencia a la predicción, comprometer el estado en el instante T permite calcular todas las salidas futuras, por lo que se pierde la seguridad hacia delante. La seguridad hacia atrás, también llamada resistencia al backtracking, significa que las salidas pasadas siguen siendo impredecibles aunque se conozca el estado actual. HMAC_DRBG y CTR_DRBG la consiguen mediante sus pasos de Update, que derivan una clave nueva del estado actual después de cada Generate.

SP 800-90A especifica los algoritmos DRBG, pero no la fuente de entropía. SP 800-90B define los requisitos para las fuentes de entropía: las fuentes de ruido del hardware deben caracterizarse y validarse, las estimaciones de entropía deben ser conservadoras y las pruebas de estado deben detectar fallos de la fuente de entropía. SP 800-90C especifica cómo combinar fuentes de entropía con DRBGs para formar generadores completos de bits aleatorios. Fuentes de entropía habituales: CPU RDRAND/RDSEED (RNG de hardware, disponible en las CPU Intel/AMD desde 2012), entropía del sistema operativo (/dev/urandom en Linux, BCryptGenRandom en Windows), módulos de seguridad hardware, RNG de TPM 2.0 y ruido ambiental (temporización del disco y fluctuación de la red). Las condiciones de baja entropía (máquinas virtuales y arranque temprano) requieren un tratamiento especial para evitar semillas débiles.

FIPS 140-3, el estándar actual para la validación de módulos criptográficos, exige el uso de DRBGs de NIST SP 800-90A para toda generación de números aleatorios dentro de los módulos certificados. El módulo debe: utilizar un DRBG aprobado (Hash, HMAC o CTR); obtener la semilla de una fuente de entropía aprobada que cumpla los requisitos de SP 800-90B; realizar pruebas de autodiagnóstico al encender (POST) para verificar el funcionamiento del DRBG; implementar pruebas continuas del RNG (CRNGT) que detecten fallos de entropía atascada en cero o en uno; y admitir Reseed cuando la fuente de entropía indique que hay entropía disponible. Los HSMs (Thales Luna, AWS CloudHSM y Utimaco), las tarjetas aceleradoras de TLS y los dispositivos de cifrado de red suelen requerir módulos validados según FIPS 140-3, lo que impulsa la adopción de SP 800-90A.

Los sistemas operativos modernos mantienen un DRBG a nivel del kernel, inicializado con fuentes de entropía de hardware. Linux utiliza un DRBG basado en ChaCha20 (desde el kernel 5.17, en sustitución del diseño anterior similar a Fortuna), inicializado con RDRAND, interrupciones y eventos de disco o red. /dev/urandom devuelve la salida del DRBG y no se bloquea una vez completada la inicialización inicial. /dev/random se bloquea hasta que haya suficiente entropía disponible (un comportamiento heredado que se ha eliminado en gran medida en los kernels recientes). La llamada al sistema getrandom(2) es la interfaz moderna y solo se bloquea durante el arranque inicial, antes de que se inicialice el DRBG. Windows utiliza CTR_DRBG (AES-256) en el generador de números aleatorios del kernel, inicializado con el TPM y eventos de hardware. Las aplicaciones deben utilizar el DRBG del sistema operativo mediante API de alto nivel, en lugar de inicializar sus propios DRBG a partir de marcas de tiempo o PID.

Las vulnerabilidades de los DRBG en sistemas reales suelen deberse a errores de implementación y no a debilidades del algoritmo. (1) Inicialización insuficiente: utilizar únicamente la marca de tiempo actual o el PID produce una semilla que los atacantes pueden adivinar. (2) Ceguera ante fork: cuando un proceso realiza un fork, tanto el proceso padre como el hijo comparten el mismo estado del DRBG y generan números aleatorios idénticos. Solución: volver a inicializar después de fork (pthread_atfork o una llamada explícita a getrandom). (3) Reutilización de instantáneas de máquinas virtuales: si se restaura una instantánea de una máquina virtual, el estado del DRBG vuelve al estado de la instantánea y genera una salida que ya se había observado. Solución: inyectar entropía única al iniciar la máquina virtual (VIRTIO RNG). (4) Ignorar silenciosamente los tests de estado: un DRBG que continúa generando datos después de detectar un fallo de entropía proporciona una salida predecible para el atacante. (5) Reutilizar nonces entre distintas instancias del DRBG.

¿Qué propiedad proporciona resembrar un DRBG con entropía nueva?

NIST SP 800-90A define tres mecanismos DRBG aprobados: Hash_DRBG (hash iterativo y sencillo), HMAC_DRBG (basado en HMAC, con una demostración de seguridad clara y ampliamente implementado) y CTR_DRBG (modo contador de AES, el más rápido mediante AES-NI y predeterminado en Windows/OpenSSL). Todos comparten el ciclo de vida Instantiate/Generate/Reseed, con un límite de reseed_interval de 2^48. La fortaleza de seguridad (de 112 a 256 bits) determina los requisitos de entropía. La resistencia a la predicción requiere resembrar antes de cada llamada a Generate. FIPS 140-3 exige DRBG de SP 800-90A con fuentes de entropía de SP 800-90B. La ceguera ante fork, la reutilización de instantáneas de máquinas virtuales y la inicialización insuficiente son los principales problemas de implementación en sistemas reales.