Agotamiento de entropía y errores de claves débiles

La inanición de entropía ocurre cuando un sistema carece de suficientes entradas impredecibles para sembrar su CSPRNG. Esto sucede en dispositivos embebidos recién arrancados, servidores virtualizados o sistemas sin interacción del usuario. La salida del RNG se vuelve predecible.

En 2006, un desarrollador de Debian eliminó una línea señalada por Valgrind: MD_Update(&m, buf, j). Esa línea era la fuente de entropía. Como resultado, OpenSSL en Debian solo se sembraba con el PID (un máximo de 32.768 valores). Todas las claves generadas entre 2006 y 2008 se encuentran en un conjunto de 32.768 posibilidades.

Las claves RSA, DSA y ECDSA, las claves de host SSH, los certificados TLS y las claves de VPN SSL generados en sistemas Debian/Ubuntu entre 2006 y 2008 quedaron comprometidos. Sistemas afectados: Debian Etch, Debian Lenny y Ubuntu 7.04-8.04. Se publicaron listas negras y se revocaron certificados.

Las máquinas virtuales pueden clonarse con un estado de disco idéntico. Si ambas generan claves a partir del mismo estado del CSPRNG, producen las mismas claves. Actualmente, los hipervisores inyectan entropía mediante VirtIO RNG o tablas ACPI, pero las máquinas virtuales mal configuradas siguen expuestas a este riesgo durante el arranque.

Los dispositivos IoT (routers y cámaras) suelen generar claves SSH/TLS durante el primer arranque, antes de acumular entropía. Los estudios descubrieron millones de dispositivos que compartían unos pocos miles de pares de claves RSA porque todos se habían sembrado a partir del mismo estado de arranque con baja entropía.

Lenstra et al. (2012) recopilaron 11,7 millones de certificados TLS y calcularon los GCD por pares. Encontraron 12.720 claves RSA que compartían un factor primo, lo que significaba que ambas claves podían factorizarse por completo. El 0,2 % de todas las claves públicas estaban comprometidas. Causa: entropía insuficiente durante el arranque.

ECDSA requiere un nonce aleatorio k único para cada firma. Si k se reutiliza (o es débil), la clave privada se puede recuperar de inmediato: d = (s1-s2)^{-1} * (z1-z2) * k / (r1-r2) mod n. La PS3 de Sony utilizaba k=constant: todos los juegos podían firmarse con la clave recuperada.

Java SecureRandom en Android 4.x se sembraba con la hora del sistema en determinadas condiciones. Varias aplicaciones de cartera Bitcoin generaban firmas con el mismo nonce k, lo que dejaba expuestas las claves privadas. Se robaron millones de dólares. Google corrigió la implementación de SecureRandom.

Herramientas: ssh-vulnkey (comprueba la lista negra de claves débiles de Debian), badkeys (comprueba si los certificados TLS contienen primos conocidos como débiles) y el algoritmo GCD-batch para auditar grandes volúmenes de claves RSA. Los registros de Certificate Transparency permiten realizar análisis a escala de toda la población.

Utilice getrandom(GRND_RANDOM) al generar la primera clave. Lea de /dev/urandom después de esperar a la siembra inicial (compruebe /proc/sys/kernel/random/entropy_avail > 128). Utilice el RNG de hardware (RDRAND) como entropía adicional. No genere nunca claves durante el primer arranque sin esperar.

Persista el estado del CSPRNG entre reinicios: guarde 32 bytes de /dev/urandom en un archivo de semilla durante el apagado; léalos y vuelva a incorporarlos durante el arranque. Esto proporciona continuidad de la entropía entre arranques en frío. Linux lo hace automáticamente; los sistemas embebidos a menudo no.

La inanición de entropía provoca claves predecibles. Fallos reales: Debian OpenSSL (semilla basada únicamente en el PID), ataques GCD contra dispositivos IoT y reutilización de nonces ECDSA en la PS3 y en la cartera Bitcoin de Android. Siembre siempre a partir de la entropía del sistema operativo y audite cuidadosamente la generación de claves en sistemas embebidos. Siguiente: generación segura de claves, nonces e IV.