Cifrado autenticado: AES-GCM y ChaCha20-Poly1305

El cifrado autenticado (AE) resuelve un problema fundamental: el cifrado tradicional solo proporciona confidencialidad —mantiene los datos en secreto—, pero no verifica si el texto cifrado ha sido manipulado. Un atacante podría modificar bits del texto cifrado y el receptor descifraría datos corruptos sin saber que fueron alterados. El cifrado autenticado con datos asociados (AEAD) añade simultáneamente una garantía de integridad y autenticidad, generando tanto el texto cifrado como una etiqueta de autenticación que detecta cualquier modificación.

AES-GCM (Galois/Counter Mode) combina dos componentes: AES-CTR (Counter Mode) para el cifrado y GMAC (Galois Message Authentication Code) para la integridad. AES-CTR genera un flujo de claves cifrando un valor de contador y aplicándole XOR al texto plano; esto permite paralelizar el cifrado, a diferencia del modo CBC. GMAC calcula una etiqueta de autenticación sobre el texto cifrado y cualquier dato asociado. La etiqueta resultante (de 128 bits) se transmite junto con el texto cifrado; un solo cambio de bit invalida la etiqueta.

AES-GCM requiere un nonce (número usado una sola vez), normalmente de 96 bits (12 bytes). El nonce debe ser único para cada operación de cifrado con la misma clave; no tiene que ser secreto, pero nunca debe repetirse. Reutilizar un nonce en AES-GCM es catastrófico: si se cifran dos mensajes con la misma clave y el mismo nonce, un atacante puede aplicar XOR a los textos cifrados para cancelar el flujo de claves y, potencialmente, recuperar ambos textos en claro. Esta vulnerabilidad a veces se denomina «uso incorrecto del nonce» y ha provocado ataques reales de recuperación de claves.

Cuando se reutilizan nonces de AES-GCM, el atacante puede calcular C1 XOR C2 = P1 XOR P2 (el XOR de ambos textos en claro), porque se utilizó el mismo flujo de claves para los dos. Además, la reutilización del nonce permite recuperar la clave de autenticación H, lo que significa que el atacante puede falsificar etiquetas de autenticación válidas para mensajes arbitrarios, quebrantando por completo tanto la confidencialidad como la integridad. Sistemas como la PS3 de Sony sufrieron exactamente este ataque. La defensa consiste en usar nonces aleatorios (generados con un CSPRNG) o un contador determinista que nunca se reinicie.

ChaCha20-Poly1305 es el otro cifrado AEAD obligatorio en TLS 1.3. ChaCha20 es un cifrado de flujo diseñado por Daniel Bernstein que genera un flujo de claves mediante operaciones de suma, rotación y XOR (ARX): no utiliza tablas de búsqueda, funciona completamente en tiempo constante y es extremadamente rápido en CPU sin aceleración de hardware para AES. Poly1305 es un MAC de un solo uso (código de autenticación de mensajes) que calcula la etiqueta de autenticación sobre el texto cifrado. Juntos proporcionan una seguridad equivalente a AES-GCM, pero son considerablemente más rápidos en dispositivos móviles y de IoT.

Los procesadores de escritorio y servidor x86 y ARM64 modernos incluyen instrucciones de hardware AES-NI que hacen que AES-GCM sea extremadamente rápido. Sin embargo, muchos procesadores móviles y de IoT carecen de AES-NI, por lo que AES-GCM implementado por software es relativamente lento. ChaCha20-Poly1305 se diseñó para ofrecer un alto rendimiento mediante operaciones aritméticas sencillas, proporcionando a los dispositivos móviles un rendimiento comparable sin aceleración de hardware. Google añadió ChaCha20-Poly1305 a TLS como alternativa precisamente para los dispositivos Android, y ahora es un conjunto de cifrado de primera clase en TLS 1.3.

La «AD» de AEAD significa datos asociados: metadatos en texto claro que se autentican, pero no se cifran. Esto permite autenticar datos que deben permanecer legibles (como los encabezados de paquetes o los campos de tipo de registro) y, al mismo tiempo, protegerlos contra manipulaciones. En TLS 1.3, los bytes del encabezado del registro se incluyen como datos asociados en el cálculo de AEAD. Si un atacante modifica el encabezado (por ejemplo, cambia la longitud del registro), la verificación de la etiqueta de autenticación falla y la conexión se termina.

Antes de que AEAD se convirtiera en el estándar, los criptógrafos recomendaban Encrypt-then-MAC (EtM): cifrar el texto en claro y después calcular un MAC sobre el texto cifrado. Es seguro, pero requiere dos operaciones independientes con dos claves distintas. Los esquemas AEAD, como AES-GCM, combinan ambas operaciones con una sola clave, lo que reduce la complejidad de implementación y elimina toda una clase de ataques de oráculo de relleno que afectaban a MAC-then-Encrypt (MtE), el orden utilizado en versiones anteriores de TLS (CBC + HMAC). TLS 1.3, al usar AEAD, evita por completo estos problemas.

Tanto AES-128-GCM como AES-256-GCM están aprobados por NIST y se consideran seguros frente a ordenadores clásicos. AES-128 ofrece una seguridad de 128 bits con un rendimiento ligeramente superior; AES-256 ofrece una seguridad de 256 bits, lo que proporciona un margen mayor frente al criptoanálisis futuro y las amenazas cuánticas. Para la mayoría de las aplicaciones actuales, AES-128-GCM es suficiente, pero los sistemas gubernamentales con información clasificada (NSA Suite B) requieren AES-256. TLS 1.3 ofrece ambos, y los servidores pueden establecer prioridades según su política de seguridad.

Al descifrar un texto cifrado AEAD, el receptor debe verificar la etiqueta de autenticación antes de descifrar. El proceso es el siguiente: volver a calcular la etiqueta esperada a partir del texto cifrado recibido, la clave y el nonce; compararla con la etiqueta recibida mediante una función de comparación en tiempo constante; y proceder al descifrado únicamente si coinciden. La comparación en tiempo constante es fundamental: si la comparación se detiene al encontrar el primer byte distinto, un atacante puede realizar un ataque de canal lateral basado en el tiempo para falsificar etiquetas válidas byte a byte. Cualquier biblioteca AEAD que utilice una comparación con salida anticipada es vulnerable.

Los algoritmos AEAD están presentes en todo tipo de sistemas de seguridad modernos: TLS 1.3 utiliza AES-GCM y ChaCha20-Poly1305 para cifrar todos los registros; la VPN WireGuard utiliza exclusivamente ChaCha20-Poly1305; el protocolo Signal lo utiliza para cifrar mensajes; y el protocolo QUIC (en el que se basa HTTP/3) utiliza AES-GCM. Cuando vea un conjunto de cifrado como TLS_AES_256_GCM_SHA384, SHA384 hace referencia a la función hash HKDF para la derivación de claves, no al mecanismo de integridad: la etiqueta GCM se encarga de la integridad.

Ponga a prueba su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que los algoritmos AEAD proporcionan confidencialidad e integridad simultáneamente mediante una etiqueta de autenticación que detecta cualquier modificación del texto cifrado; que reutilizar un nonce de AES-GCM es catastrófico, ya que permite recuperar el flujo de claves y falsificar la clave de autenticación, por lo que los nonces deben ser únicos para cada cifrado; y que ChaCha20-Poly1305 es la alternativa eficiente en rendimiento a AES-GCM para dispositivos que carecen de aceleración de hardware para AES. A continuación, exploraremos las funciones de derivación de claves para proteger contraseñas.