«Criptocalipsis» o «Q-day»

En el sector de la ciberseguridad a menudo preferimos anticiparnos a las amenazas. Por eso se ha acuñado el término «Criptocalipsis» —ese momento teórico en el que un ordenador cuántico sea lo suficientemente potente como para romper en poco tiempo la criptografía asimétrica que protege Internet (la base de los algoritmos de cifrado asimétrico y de firma electrónica como RSA y ECC)— .

A ello ha contribuido las recomendaciones de los organismos de estandarización (IETF, NIST, ETSI, ISO) y los grandes proveedores de infraestructura que se toman en serio los riesgos detectados .

Y el riesgo actual tiene un nombre técnico bastante inquietante: «Harvest Now, Decrypt Later» (Recolectar ahora, descifrar después).

Cabe pensar que el tráfico cifrado que circula hoy por las redes podría estar siendo recogido y almacenado masivamente por organismos de algunos estados o por grandes organizaciones delictivas con recursos económicos a su disposición.

La información que se guarda cifrada, sin conocer la clave de descifrado, parece poco útil, pero dentro de 5, 10 o 15 años, cuando llegue el llamado «Q-Day» (el día que un ordenador cuántico relevante esté operativo), esa «caja fuerte» de datos grabados hoy podría abrirse en espacios de tiempo cortos usando el algoritmo de Shor.

Si la confidencialidad de los datos de las empresas y organismos (secretos industriales, comunicaciones diplomáticas, datos médicos a largo plazo) debe durar más de una década, la criptografía convencional podría no ser suficiente.

Uno de los usos del cifrado se da en las comunicaciones seguras de los browsers o navegadores con los sitios web que tendrán instalado un certificado para que se pieda activar esa comunicación cifrada.

El protocolo utilizado se llamaba antiguamente SSL pero ya no se usa esa denominación porque ese protocolo incluía importantes vulnerabilidades, que se han resuelto posteriormente.

Ahora se emplea el protocolo TLS , la evolución del SSL, pero tampoco vale cualquier versión. No valen la versiones anteriores a la 1.2 y pronto dejará de utilizarse esta, conforme se generalice la versión TLS 1.3.

Y en el protocolo se usa un certificado X.509 en el servidor en base al cual se gestiona el intercambio de claves

1. Si un ataque en base a computación cuántica desvelara la clave privada del certificado, el atacante podría suplantar el servidor (lo que requeriría más operaciones para la suplantación como atacar los DNS). Incluso si eso sucede, habría indicios que permitirían al propietario del servidor web legítimo detectarlo y reaccionar.
2. La Confidencialidad de las comunicaciones se basa en el intercambio de claves de cifrado: Si un ataque en base a computación cuántica desvelara la clave de cifrado, de un intercambio de información del pasado (preservada por el atacante), podría descifrar todo el intercambio de información.

Por eso, la prioridad del IETF en su actualización del protocolo ha sido blindar el intercambio de claves. Y ya está publicado como estándar.

Enfoque híbrido del intercambio de claves: compatibilidad y reforzamiento

El reto en el intercambio de claves en TLS es que el objetivo de usar nuevos algoritmos postcuánticos (PQC) como Kyber (ahora estandarizado por NIST como ML-KEM), debería ser compatible con el uso de algoritmos muy probados como RSA o las Curvas Elípticas (ECC). ¿Qué pasa si al profundizar en los nuevos algoritmos se descubre una vulnerabilidad matemática no detectada en los análisis previos?

La respuesta del IETF en el reciente estándar para TLS 1.3 es el pragmatismo puro: el Intercambio de Claves Híbrido.

La idea es simple y práctica: no sustituir lo viejo por lo nuevo, sino usar ambos simultáneamente. Es una estrategia de «compatibilidad y refuerzo». Para que un atacante rompa la sesión, tendría que romper a la vez la criptografía clásica (X25519, híper probada) Y la nueva criptografía postcuántica (Kyber). Si el ordenador cuántico no da con la clave, nos protege la criptografía clásica. Si el ordenador cuántico expone la clave basada en criptografía clásica, nos protege la basada en criptografía postcuántica.

3. Cómo funciona el nuevo «Handshake» TLS 1.3 Híbrido

¿Cómo se modifica un protocolo tan establecido como TLS 1.3 para negociar dos tipos de criptografía radicalmente distintos en una sola ida y vuelta, sin perder eficiencia?

El cambio ocurre en las extensiones clave del handshake inicial:

A. El Cliente propone (ClientHello)

En un TLS 1.3 normal, el cliente usa la extensión supported_groups para decir «soporte la curva elíptica X25519» y la extensión key_share para enviar «aquí tienes mi mitad de la clave pública X25519».

En el nuevo TLS híbrido, el cliente da un paso más:

1. En supported_groups, indica soporte para nuevos identificadores «compuestos», por ejemplo, uno que significa específicamente «X25519 combinado con Kyber768».
2. En el key_share, el cliente no envía solo una clave. Envía un paquete concatenado: [Su clave pública X25519] + [Su clave pública Kyber].

B. El Servidor elige (ServerHello)

El servidor recibe la propuesta. Si soporta ese grupo híbrido y decide usarlo:

1. Selecciona el grupo compuesto.
2. Genera sus propias claves para ambos algoritmos.
3. Realiza la operación clásica Diffie-Hellman con la parte X25519.
4. Utiliza el mecanismo de Encapsulación de Clave (KEM) de Kyber para generar un «secreto compartido» y encapsularlo para el cliente.
5. Devuelve en su ServerHello el paquete: [Su clave pública X25519] + [El criptograma encapsulado de Kyber].

C. La Magia: La Derivación de la Clave Maestra

Este es el punto crítico. Al final de este intercambio, tanto cliente como servidor tienen en sus manos dos secretos compartidos distintos:

• El secreto resultante del intercambio clásico (ECDH).
• El secreto compartido desencapsulado del intercambio postcuántico (KEM).

El estándar dicta que el key schedule de TLS 1.3 (la «coctelera» criptográfica que deriva las claves finales de cifrado simétrico AES o ChaCha20) debe combinar ambos secretos. Se introducen los dos ingredientes en la función de derivación.

El resultado matemático es fundamental: la clave de sesión final resultante depende criptográficamente de ambos secretos. Si un atacante cuántico logra romper la parte de X25519 en el futuro, no le servirá de nada, porque le falta el ingrediente de Kyber para poder reconstruir la clave de sesión. La confidencialidad futura queda asegurada hoy.

4. Una nota sobre el futuro de la Autenticación (Firmas y Certificados)

Los lectores más atentos notarán que solo hemos hablado del intercambio de claves. ¿Qué pasa con el certificado que presenta el servidor para autenticarse?

A día de hoy, ese certificado (el que emiten prestadores como EADTrust o Google) sigue utilizando firmas clásicas RSA o ECDSA. Como se ha indicado al principio, esto se considera un riesgo aceptable temporalmente, ya que romper esto solo permite ataques en tiempo real, no descifrado retroactivo.

La migración a certificados con firmas postcuánticas es un desafío logístico mucho mayor que implicará actualizar todas las raíces de confianza en navegadores y sistemas operativos.

Cuando llegue ese momento, la industria se debate entre varios candidatos del NIST. Mientras que Dilithium (ML-DSA) parece el estándar para propósito general, para casos de uso específicos como la firma de documentos y PDF, FALCON se perfila como una opción técnicamente superior debido a su eficiencia y al tamaño extremadamente compacto de sus firmas, algo crítico para no engordar innecesariamente los documentos electrónicos a largo plazo.