Criptoagilidad: definición y cómo integrarla en los sistemas

La criptoagilidad es la capacidad de un sistema para cambiar sus algoritmos, parámetros y claves criptográficos sin reescribir el código de la aplicación y sin esperar a una nueva versión del producto. No es una funcionalidad que se compra: es un conjunto de propiedades de ingeniería, principalmente configuración en lugar de elecciones codificadas de forma fija, negociación a nivel de protocolo, un inventario actualizado, fronteras de abstracción limpias y ciclos de vida automatizados de claves y certificados. Los reguladores describen ya esa misma capacidad con sus propias palabras; por ejemplo, las normas técnicas de DORA exigen una política de cifrado con disposiciones para cambiar la tecnología criptográfica a medida que evoluciona el criptoanálisis.

Qué significa la criptoagilidad

Una definición de trabajo útil: un sistema es criptoágil cuando un operador competente puede sustituir un algoritmo, un tamaño de clave o una versión de protocolo en una ventana de cambio controlada, utilizando configuración y automatización que ya existen, y puede demostrar después qué está en uso. La prueba es operativa, no teórica. Si cambiar un grupo de intercambio de claves obliga a editar código fuente, reconstruir una imagen de contenedor, renegociar con un proveedor o descubrir dependencias no documentadas, el sistema no es ágil, diga lo que diga su documentación.

Conviene retener tres distinciones:

• La agilidad no equivale a estar preparado para la era poscuántica. La criptografía poscuántica (PQC) es un destino. La agilidad es el vehículo. Un servidor que hoy ofrece un intercambio de claves poscuántico híbrido pero que no podrá cambiarlo el año que viene ha resuelto una migración y no se ha preparado para ninguna otra.
• La agilidad no se limita a la negociación. Transport Layer Security (TLS) negocia. Los formatos de datos almacenados, el firmware firmado, los módulos de seguridad de hardware, los terminales de pago y los dispositivos embebidos a menudo no lo hacen. Es ahí donde la agilidad debe diseñarse en lugar de configurarse.
• La agilidad tiene un orden de prioridad. Harvest now, decrypt later (HNDL, «recolectar ahora, descifrar después») describe el tráfico grabado que un adversario conserva hasta que su descifrado sea posible. Las sesiones grabadas solo están protegidas por el intercambio de claves, y por eso el establecimiento de claves migra primero y las firmas pueden seguir después. Nuestro artículo sobre harvest now, decrypt later explica ese orden en detalle.

Configuración antes que código, negociación antes que valores fijos

La primera propiedad es que la selección de algoritmos reside en una configuración de la que es responsable un operador, en un único lugar por host o por servicio, y se revisa como cualquier otro control. Una política criptográfica centralizada es preferible a opciones específicas de cada aplicación, porque son precisamente esas opciones las que acaban olvidándose.

TLS: grupos con nombre y una lista de preferencias ordenada

En TLS 1.3, el intercambio de claves es un grupo con nombre que se negocia en cada conexión. El registro de la Internet Assigned Numbers Authority (IANA) recoge los grupos híbridos X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) y SecP384r1MLKEM1024 (0x11ED), junto con los grupos ML-KEM puros (parámetros TLS de la IANA). ML-KEM es el mecanismo de encapsulación de claves (KEM) estandarizado por el NIST en FIPS 203 el 13 de agosto de 2024. RFC 10024 (agosto de 2026) especifica el acuerdo de claves híbrido poscuántico y tradicional para TLS 1.3.

Una configuración ágil declara una preferencia ordenada y mantiene una alternativa clásica, de modo que un cliente que no admita el grupo híbrido pueda seguir conectándose. Los grupos ML-KEM requieren OpenSSL 3.5 o posterior:

# /etc/ssl/openssl.cnf (OpenSSL 3.5 or later)
openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Groups = X25519MLKEM768:X25519:P-256
MinProtocol = TLSv1.2

Verifique desde el exterior antes y después de cualquier cambio, con una prueba de solo lectura:

# read-only test: does the server accept the hybrid group?
openssl s_client -groups X25519MLKEM768 -connect example.com:443 < /dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

En la capa del servidor web, esa misma preferencia es una sola directiva, por ejemplo ssl_ecdh_curve X25519MLKEM768:X25519; en nginx compilado con un OpenSSL adecuado. Nuestra guía para activar ML-KEM en nginx, Apache, HAProxy y Caddy ofrece la sintaxis de cada producto y las versiones mínimas. Pruebe primero en preproducción y conserve el grupo de respaldo.

SSH: el mismo patrón, ya disponible

OpenSSH es un buen modelo de agilidad en la práctica. La versión 9.0 (8 de abril de 2022) convirtió un intercambio de claves híbrido en la opción predeterminada. La versión 9.9 (19 de septiembre de 2024) añadió mlkem768x25519-sha256. La versión 10.0 (9 de abril de 2025) lo convirtió en el acuerdo de claves predeterminado, y la 10.1 (6 de octubre de 2025) emite una advertencia cuando una conexión negocia un acuerdo de claves no poscuántico, mediante WarnWeakCrypto, activado por defecto (notas de versión de OpenSSH). Los operadores que habían expresado sus preferencias en la configuración heredaron el cambio; quienes habían fijado un único algoritmo en sus scripts, no.

# list what this client supports, then set an ordered preference
ssh -Q kex

# /etc/ssh/sshd_config (OpenSSH 9.9 or later), classical fallback last
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Inventario, abstracción y automatización

Un inventario que se pueda consultar, no una hoja de cálculo que se reescribe

No se puede cambiar lo que no se puede enumerar. Un inventario justifica su existencia cuando responde a una pregunta en minutos: qué servicios siguen negociando un intercambio de claves exclusivamente clásico, qué certificados utilizan qué algoritmo de firma, qué bibliotecas proporcionan las primitivas y quién es responsable de cada elemento. Registre como mínimo el activo, el protocolo y su versión, los algoritmos y tamaños de clave, la finalidad, el responsable, la versión de la biblioteca o del módulo y el mecanismo de renovación. Una lista de materiales criptográficos (CBOM) es una forma legible por máquina de conservar esta información; consulte qué es un CBOM. Considere el CBOM como una práctica que sugerimos, no como un requisito legal.

Capas de abstracción que ocultan el algoritmo

El código de la aplicación debería solicitar una capacidad, no un nombre. Cuatro patrones aportan la mayor parte del beneficio:

• Llamar a través de un proveedor o de una biblioteca interna ligera. Un único módulo traduce la política en primitivas, de modo que un solo cambio se propaga.
• Versionar cada formato almacenado. Anteponga a los textos cifrados, tokens y sobres firmados un identificador de algoritmo y una versión de formato, para que los datos antiguos sigan siendo legibles mientras los nuevos utilizan el nuevo algoritmo.
• No presuponer nunca los tamaños. Las claves públicas y los textos cifrados de ML-KEM, así como las firmas ML-DSA, son considerablemente más grandes que sus equivalentes de curva elíptica. Las columnas de base de datos de longitud fija, los búferes fijos, los límites de tamaño de mensaje y los campos de protocolo dimensionados para claves de 32 bytes son el obstáculo bloqueante más habitual. Prefiera campos con prefijo de longitud.
• Mantener una doble vía de verificación. Acepte y verifique tanto el algoritmo antiguo como el nuevo durante la transición y, después, retire el antiguo según un calendario con fechas.

Claves y certificados que rotan sin intervención humana

Una rotación que se realiza a mano una vez al año no es un control, es un ensayo que fallará. La emisión y la renovación automatizadas, las vigencias cortas de los certificados y una alerta ante cualquier certificado no renovado son lo que convierte un cambio de algoritmo en una tarea rutinaria: cuando cambia el algoritmo de firma, la cadena de automatización simplemente emite certificados distintos. Los simulacros de rotación deben figurar en el calendario de cambios. Las firmas basadas en hash con estado (LMS y XMSS, estandarizadas en NIST SP 800-208) son la excepción que confirma la regla: su gestión del estado hace que duplicar sin más una clave de firma sea inseguro, por lo que requieren una gestión de claves deliberada en lugar de una automatización genérica.

Dónde exige agilidad la regulación y qué evidencias encajan

Varios textos exigen esta capacidad sin emplear la expresión. La tabla distingue lo que dice literalmente cada texto de cómo sugerimos acreditarlo. Esto es información, no asesoramiento jurídico: confirme sus propias obligaciones con su asesor legal o su supervisor.

Consulte la redacción exacta en el Regulation (EU) 2024/1774 y vea nuestras páginas sobre DORA y PCI DSS v4.0.1 para conocer los hitos con sus fechas. Mantenga los matices en su justa medida: la hoja de ruta coordinada de implementación de la UE (EU Coordinated Implementation Roadmap v1.1) es una orientación coordinada para los Estados miembros y no un reglamento vinculante para las empresas, BSI TR-02102-1 es una directriz técnica, la ANSSI indica que sus recomendaciones poscuánticas aún no son obligaciones normativas fuera de su ámbito regulado, y NIST IR 8547 sigue siendo un borrador público inicial.

Errores que anulan la agilidad sin hacer ruido

• Fijar un único algoritmo en el código o en scripts en lugar de expresar una preferencia ordenada en la configuración.
• Retirar demasiado pronto la alternativa clásica. Mantenga X25519 después de X25519MLKEM768 hasta haber medido su población de clientes.
• Conservar grupos obsoletos anteriores al estándar. Los grupos TLS del borrador Kyber están obsoletos: migre a X25519MLKEM768 y a los demás híbridos registrados.
• Un inventario sin responsables. Una lista de la que nadie rinde cuentas no genera cambios.
• Olvidar los artefactos de larga duración: el firmware firmado, las firmas de documentos, las copias de seguridad y los datos archivados sobreviven a los sistemas que los crearon.

Mida lo que negocian hoy sus sistemas

La agilidad empieza con una línea de base honesta, y su parte visible desde el exterior se obtiene rápidamente: analice su dominio con PQC Status para ver qué versiones de TLS, suites de cifrado, grupos de intercambio de claves y algoritmos de certificado negocia realmente su servidor. Un análisis describe únicamente la configuración TLS visible desde el exterior: no es una certificación ni una atestación de cumplimiento, como explica nuestra página de metodología. El siguiente paso concreto es tomar ese resultado, registrar cada servicio en su inventario criptográfico con un responsable y, a continuación, trasladar la selección de algoritmos de un servicio a una configuración centralizada y ensayar su cambio en preproducción.