Ataques de replay y vulnerabilidades por reutilización de nonces

Un nonce (número utilizado una sola vez) garantiza que, al cifrar dos veces el mismo mensaje en texto plano, se obtengan textos cifrados distintos. Esto es esencial para la seguridad semántica: un atacante que observe varios textos cifrados no obtiene información sobre si cifran los mismos textos planos o textos planos diferentes. En los cifrados de flujo y en los cifradores de bloque en modo CTR, el nonce sirve de semilla para generar el flujo de claves, por lo que es fundamental para la seguridad.

En AES-GCM, el nonce de 96 bits se utiliza para inicializar un contador para el cifrado en modo CTR y también contribuye al cálculo de autenticación GHASH. El valor del contador de cada bloque AES se obtiene incrementándolo a partir del nonce. Si dos cifrados utilizan el mismo nonce y la misma clave, generan el mismo flujo de claves, por lo que el XOR de sus textos cifrados es igual al XOR de sus textos planos.

Dos textos cifrados de GCM generados con el mismo par (clave, nonce): el XOR de ambos equivale al XOR de sus textos planos. Si un atacante conoce uno de los textos planos, algo habitual en escenarios de texto plano elegido, puede recuperar inmediatamente el otro. Incluso sin conocer un texto plano, el XOR de los textos cifrados revela patrones lingüísticos y puede atacarse mediante técnicas de crib-dragging. Este es uno de los patrones de uso indebido más catastróficos de la criptografía.

La reutilización del nonce en GCM tiene otra consecuencia catastrófica además de la recuperación del texto plano. La clave de autenticación H de GHASH se deriva únicamente de la clave de cifrado. Si dos mensajes comparten un par (clave, nonce), el atacante puede resolver ecuaciones polinómicas para recuperar H. Al conocer H, el atacante puede falsificar etiquetas de autenticación GCM válidas para textos cifrados arbitrarios, rompiendo por completo la integridad de los mensajes.

TLS 1.3 aprendió de los riesgos de reutilización de nonces presentes en las implementaciones de TLS 1.2. TLS 1.3 genera nonces de GCM mediante el XOR entre el IV de escritura de 12 bytes, derivado del handshake, y el número de secuencia de 8 bytes, ampliado con ceros hasta 12 bytes. Como los números de secuencia se incrementan con cada registro, cada registro utiliza un nonce único. Esto elimina el riesgo de generar nonces aleatorios y garantiza la unicidad de los nonces mediante el mecanismo de números de secuencia.

Un ataque de repetición captura un mensaje válido o un token de autenticación y lo retransmite posteriormente para conseguir un efecto fraudulento. Algunos ejemplos son retransmitir una transacción bancaria para cobrarla dos veces, retransmitir una respuesta de autenticación válida para suplantar a un usuario o retransmitir un comando firmado a un dispositivo. El atacante no necesita comprender ni modificar el mensaje; basta con retransmitir los datos capturados para llevar a cabo el ataque.

Incluir una marca de tiempo en los mensajes autenticados proporciona protección contra las repeticiones. El receptor acepta los mensajes únicamente dentro de una ventana temporal corta, por ejemplo, durante los 5 minutos posteriores a la marca de tiempo indicada. Un mensaje repetido horas después queda fuera de la ventana y se rechaza. La marca de tiempo debe estar autenticada, dentro del HMAC o de los datos adicionales de AEAD, para impedir que un atacante la modifique y haga que parezca reciente.

Los números de secuencia ofrecen una protección contra las repeticiones más sólida que las marcas de tiempo, ya que detectan no solo repeticiones antiguas, sino también entregas duplicadas o fuera de orden. El receptor mantiene el siguiente número de secuencia esperado y una ventana deslizante de números vistos recientemente. Cada mensaje debe tener un número de secuencia dentro de la ventana aceptable y no visto anteriormente. TLS utiliza números de secuencia para impedir la repetición de registros dentro de una sesión.

Para AES-GCM, la estrategia recomendada para generar nonces aleatorios consiste en utilizar 96 bits obtenidos de un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG). Con nonces aleatorios de 96 bits, la probabilidad de colisión prevista por el límite de cumpleaños alcanza 2^-32 después de 2^32 cifrados, aproximadamente 4 mil millones. En aplicaciones de gran volumen, cambie a un nonce basado en un contador o utilice otro AEAD, como XChaCha20-Poly1305 con su nonce de 192 bits, para ampliar el límite seguro.

Los nonces deterministas basados en contadores evitan los problemas del límite de cumpleaños, pero requieren una gestión cuidadosa del estado. El contador debe conservarse entre los reinicios de la aplicación; si se restablece a cero al reiniciar, se crea inmediatamente una reutilización del nonce con la misma clave. El contador debe actualizarse atómicamente antes de utilizar el nonce, no después. En los sistemas distribuidos, los nonces basados en contadores requieren coordinación para impedir que dos nodos utilicen el mismo valor del contador.

XChaCha20-Poly1305 amplía el nonce de ChaCha20-Poly1305 de 96 a 192 bits. Con nonces aleatorios de 192 bits, la probabilidad de colisión según el límite de cumpleaños es insignificante incluso después de 2^96 cifrados, un número de mensajes astronómicamente grande. Esto hace segura la generación de nonces aleatorios sin preocupaciones prácticas por el límite de cumpleaños. La función crypto_secretbox de libsodium, basada en XSalsa20-Poly1305, utiliza nonces de 192 bits por la misma razón.

Resumen de la reutilización de nonces: los nonces garantizan la unicidad de los textos cifrados; la reutilización del nonce en GCM revela el XOR de los textos planos y rompe la autenticación mediante la recuperación de H; TLS 1.3 utiliza el XOR del número de secuencia con el IV para garantizar la unicidad del nonce; los ataques de repetición retransmiten mensajes válidos sin modificarlos; las marcas de tiempo y los números de secuencia en mensajes autenticados previenen las repeticiones; utilice nonces aleatorios de 96 bits para GCM, teniendo en cuenta el límite de cumpleaños, o XChaCha20 para disponer de un espacio mayor de nonces aleatorios.