Pruebas y validación de implementaciones de RNG

Las pruebas de generadores de números aleatorios afrontan un desafío fundamental: las secuencias verdaderamente aleatorias y las secuencias pseudoaleatorias producidas por un buen PRNG parecen idénticas ante las pruebas estadísticas. Ninguna prueba de longitud finita puede demostrar que una secuencia es aleatoria; las estadísticas solo pueden detectar la no aleatoriedad con cierto grado de confianza. Las pruebas verifican que un RNG no tenga sesgos ni patrones evidentes, pero no pueden demostrar su seguridad criptográfica. Las pruebas de RNG criptográficos tienen dos objetivos distintos: (1) calidad estadística: verificar que la distribución de la salida parezca uniforme e independiente; (2) fortaleza criptográfica: verificar que el algoritmo DRBG esté implementado correctamente y que se cumplan sus afirmaciones de seguridad. Estos objetivos requieren enfoques de prueba diferentes.

NIST SP 800-22 proporciona 15 pruebas estadísticas para evaluar secuencias de bits. Entre ellas se incluyen las siguientes: prueba de frecuencia (monobit): la proporción de unos debe aproximarse a 0,5. Prueba de frecuencia por bloques: frecuencia de unos en cada bloque de m bits. Prueba de rachas: número de rachas ininterrumpidas de bits idénticos. Prueba de la racha más larga: longitud de la racha más larga de unos. Prueba de rango de matrices binarias: rango de las matrices binarias formadas a partir de la secuencia. Prueba espectral (DFT): detecta patrones periódicos. Coincidencia de patrones superpuestos: cuenta las apariciones de patrones específicos. Prueba estadística universal de Maurer: comprime la secuencia y mide cuánto se acorta. Cada prueba produce un valor p; p < 0.01 sugiere no aleatoriedad. Las pruebas se ejecutan sobre entre 1 millón y 1.000 millones de bits.

TestU01 (L'Ecuyer y Simard, 2007) es una batería completa de pruebas estadísticas ampliamente utilizada en la comunidad de RNG. SmallCrush: 10 pruebas y unos 35 segundos, adecuada para comprobaciones rápidas. Crush: 144 pruebas y unas 2 horas. BigCrush: 160 pruebas y unas 24 horas. Las pruebas de BigCrush detectan correlaciones sutiles que NIST SP 800-22 no detecta. Los DRBG criptográficos bien diseñados (HMAC_DRBG, CTR_DRBG) superan BigCrush sin dificultad: para los algoritmos de tiempo polinómico, su salida es computacionalmente indistinguible de una secuencia aleatoria. Los PRNG no criptográficos (Mersenne Twister y generadores lineales congruenciales) fallan algunas pruebas de BigCrush. Fallar BigCrush indica claramente que el RNG no debería utilizarse con fines criptográficos.

SP 800-90B y 90A especifican pruebas de estado que los DRBG deben ejecutar continuamente durante su funcionamiento. Prueba continua de RNG (CRNGT): cada bloque generado se compara con el bloque anterior; si son iguales (RNG bloqueado), el DRBG debe pasar a un estado de error y dejar de generar. Prueba de recuento de repeticiones: si muestras consecutivas tienen el mismo valor repetido más veces de lo que cabría esperar estadísticamente según la estimación de entropía, la prueba falla. Prueba de proporción adaptativa: si el valor más frecuente aparece más veces que el umbral establecido en una ventana, la prueba falla. Estas pruebas de estado detectan fallos en las fuentes de entropía (un sensor bloqueado o un fallo del hardware del HWRNG) antes de que comprometan silenciosamente la generación de claves criptográficas.

PractRand es una herramienta moderna de pruebas de RNG diseñada para la evaluación en línea (streaming), que analiza la secuencia a medida que se genera en lugar de requerir una longitud predeterminada. Aplica, entre otras, pruebas de intervalos, pruebas de distribución de bits y pruebas espectrales, con precisión adaptativa. PractRand es especialmente eficaz para detectar RNG que producen secuencias cortas de buena calidad, pero revelan patrones después de miles de millones de bits. Los DRBG criptográficos producen una salida que PractRand no puede distinguir de una secuencia aleatoria, independientemente de la longitud; esta es la definición operativa de indistinguibilidad computacional. PractRand también se utiliza para evaluar fuentes de entropía (probando la salida de /dev/urandom y de RDRAND) y detectar fallos de hardware o sesgos sistemáticos.

El Cryptographic Algorithm Validation Program (CAVP) proporciona vectores de prueba oficiales para los DRBG de SP 800-90A. Las pruebas de CAVP consisten en enviar una implementación al sistema automatizado de pruebas de NIST con vectores de prueba de respuesta conocida (KAT): dada una entrada de entropía, un nonce, una cadena de personalización y un additional_input específicos, la implementación debe producir exactamente los bits de salida esperados. CAVP no comprueba las propiedades estadísticas, sino la corrección algorítmica. La certificación FIPS 140-3 exige la validación CAVP para todos los algoritmos criptográficos utilizados dentro del límite del módulo. Los vectores de prueba de CAVP están disponibles públicamente en el servidor ACVP (Automated Crypto Validation Protocol) de NIST y se integran en las suites de pruebas de OpenSSL, mbedTLS y BoringSSL.

Antes de poder inicializar un DRBG de forma segura, se debe validar su fuente de entropía. SP 800-90B define lo siguiente: (1) Estimación de entropía: medir la entropía real por bit mediante pruebas estadísticas (estimación de min-entropía). (2) Pruebas de arranque: verificar que la fuente de entropía produzca una salida válida antes del primer uso. (3) Pruebas bajo demanda: pruebas opcionales activadas por la aplicación. (4) Pruebas de estado de la fuente de ruido: detectar la degradación del hardware. Fuentes de entropía comunes y su entropía estimada por bit: CPU RDRAND/RDSEED (~1 bit/bit, con certificación de hardware); /dev/urandom (mezcla varias fuentes y utiliza una estimación de entropía conservadora); TRNG de oscilador de anillo (0,5-0,9 bits/bit, según el diseño); ruido de ADC (0,1-0,5 bits/bit). La validación conforme a SP 800-90B requiere pruebas de laboratorio con equipos especializados.

Los entornos virtuales presentan desafíos específicos para las pruebas de RNG. Las máquinas virtuales pueden encontrarse con condiciones de baja entropía durante el arranque (sin eventos de hardware) o después de restaurar una instantánea (reinicio del estado). Los contenedores Docker comparten el RNG del kernel del host, por lo que un contenedor no puede probar directamente la calidad de la entropía subyacente. Pruebas para implementaciones en máquinas virtuales: (1) Medir el tiempo hasta que se complete la lectura de /dev/random; las esperas prolongadas indican una entropía insuficiente. (2) Comprobar si se generan UUID o claves duplicados en instancias de máquinas virtuales ejecutadas en paralelo (un modo de fallo real documentado en implementaciones en la nube). (3) Verificar que VIRTIO-RNG (virtio_rng.ko) esté cargado en las máquinas virtuales; proporciona inyección de entropía del host al invitado. (4) Auditar la secuencia de arranque de la aplicación: ¿la generación de claves ocurre antes de que haya suficiente entropía disponible?

Probar la seguridad frente a fork evita una vulnerabilidad sutil: cuando un proceso hace fork, tanto el proceso padre como el hijo comparten el mismo estado del DRBG, lo que hace que generen secuencias idénticas. Detección: iniciar N procesos hijo, generar un UUID en cada uno y verificar que todos los UUID sean únicos. Si dos coinciden, el RNG no es seguro frente a fork. OpenSSL corrigió un error de seguridad frente a fork en 2020 (CVE-2020-1971 no estaba relacionado directamente con DRBG, pero el patrón es similar). Las versiones actuales de OpenSSL utilizan una actualización de la semilla basada en el PID: si el PID ha cambiado desde la última llamada (lo que indica un fork), el DRBG vuelve a recibir automáticamente una semilla. Para probarlo, ejecutar la prueba antes y después de un fork y confirmar que se produjo la resembra verificando que las salidas sean distintas.

Una lista de comprobación práctica para auditar implementaciones de RNG: (1) ¿El RNG se inicializa a partir del sistema operativo (getrandom, BCryptGenRandom) en lugar de utilizar semillas basadas en el tiempo? (2) ¿El tipo de DRBG es un mecanismo aprobado por NIST SP 800-90A (Hash, HMAC, CTR)? (3) ¿La longitud de la semilla es suficiente para la fortaleza de seguridad declarada? (4) ¿La resembra se activa periódicamente o después de un número fijo de llamadas a generate? (5) ¿La implementación gestiona la seguridad frente a fork (resembra después de un fork)? (6) ¿Las pruebas de estado están habilitadas y detienen el sistema si fallan? (7) ¿El estado se pone a cero al apagar el sistema? (8) ¿Los vectores de prueba de CAVP se ejecutan en CI/CD? (9) ¿Las estimaciones de entropía están documentadas y validadas? (10) Para los requisitos de FIPS: ¿el módulo cuenta con la certificación FIPS 140-3?

Los fallos históricos de RNG demuestran lo mucho que está en juego. Debian OpenSSL (2006-2008): un parche eliminó accidentalmente dos líneas de código de recopilación de entropía, lo que redujo el conjunto de semillas a un espacio de PID de 15 bits; para toda la base de usuarios de Debian solo se generaron 32.767 claves SSH posibles. Fue necesario reemplazar todas las claves de host SSH y las claves de usuario generadas por Debian. Billeteras de Bitcoin en Android (2013): SecureRandom de Android utilizaba una inicialización de semilla en el nivel de Java que fallaba en algunos dispositivos, lo que provocaba valores k duplicados en las firmas ECDSA y revelaba directamente las claves privadas. Sony PS3 (2010): utilizaba un nonce constante al firmar el firmware con ECDSA, lo que permitía extraer la clave privada a partir de dos firmas (el mismo k en mensajes distintos revela la clave mediante álgebra sencilla).

¿Cuál de las siguientes pruebas detecta que un DRBG podría estar generando una salida fija (el mismo valor repetidamente)?

Las pruebas estadísticas (NIST SP 800-22, TestU01 BigCrush, PractRand) verifican la calidad de la salida, pero no pueden demostrar la seguridad criptográfica. Las pruebas de respuesta conocida de CAVP verifican la corrección algorítmica de las implementaciones de SP 800-90A. Las pruebas de fuentes de entropía de SP 800-90B (estimación de min-entropía y pruebas de estado) validan la entrada de la semilla. La prueba continua de RNG (CRNGT) detecta en tiempo real las salidas fijas. Las implementaciones en máquinas virtuales y contenedores requieren inyección de entropía (VIRTIO-RNG) y comprobaciones de entropía durante el arranque. Las pruebas de seguridad frente a fork verifican que los procesos hijo no hereden el estado del DRBG del proceso padre. Los fallos del mundo real (Debian, Android) demuestran que los errores de RNG conducen directamente al compromiso de claves criptográficas. Las listas de comprobación para auditorías formalizan estas verificaciones para las implementaciones en producción.