Criptografía poscuántica: el inventario que hace falta antes de cambiar algoritmos

Una empresa puede tener un sitio web actualizado y seguir dependiendo de criptografía antigua en el programa que firma sus actualizaciones, en una VPN de un proveedor o en el sistema que protege las claves de archivos históricos. El primer paso para migrar a criptografía poscuántica consiste en localizar esas dependencias. El informe final NIST IR 8547 se publicó el 27 de octubre de 2026. Explica la transición desde algoritmos de clave pública vulnerables frente a un ordenador cuántico suficientemente potente. En Europa hay una hoja de ruta distinta, dirigida a los Estados miembros. Ninguno de los dos documentos dice que ese ordenador ya exista ni que todas las empresas españolas deban cambiar todos los certificados en una misma fecha.

¿Qué podría capturar hoy un atacante para descifrarlo mañana?

Una de las razones para empezar pronto es la posibilidad de capturar comunicaciones cifradas ahora y tratar de descifrarlas en el futuro, cuando exista tecnología suficiente. No hace falta saber el año exacto de ese avance para tomar decisiones. Un secreto que pierde valor en dos días y un expediente que debe conservar confidencialidad durante veinte años tienen horizontes distintos. Si además adaptar los sistemas lleva varios años, esperar al último momento puede dejar expuesta información que ya viajó por la red. Las orientaciones conjuntas de CISA, NSA y NIST proponen identificar primero la tecnología vulnerable y la criticidad de los datos que protege.

El riesgo no se limita a la confidencialidad. Firmamos digitalmente programas y documentos para poder verificar su origen e integridad. Un sistema que valida actualizaciones de firmware puede seguir confiando durante muchos años en el mismo formato y las mismas claves de confianza. En ese caso preocupa qué firma aceptará el equipo en el futuro y cómo podrá verificarse una transición de modo seguro. «Ciframos todo» resulta una respuesta insuficiente: cifrar un mensaje, establecer una clave para la sesión y firmar una actualización son tareas diferentes.

Tres estándares que no cumplen la misma función

En agosto de 2024 el NIST finalizó FIPS 203 (ML-KEM), un mecanismo de encapsulación que permite establecer un secreto compartido. Ese secreto sirve de base para claves que el protocolo utilizará después; el mecanismo no es la herramienta con la que se cifra directamente cada archivo o cada página que viaja por la red. FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) son estándares de firma. Resuelven el problema de producir y comprobar firmas con mecanismos diseñados frente a la amenaza cuántica. La publicación de un estándar no instala soporte en servidores, equipos de usuario ni dispositivos heredados.

Es relevante distinguir el algoritmo de la pieza donde se implementa. El certificado público que presenta un servidor suele dar información sobre su clave y firma. No demuestra qué mecanismo de establecimiento de claves se acordó en todas las conexiones, si intervino un intermediario ni cómo se protege el tráfico entre ese intermediario y el servidor de origen. Una captura autorizada de una negociación concreta aporta evidencia para ese cliente, ese servicio y ese momento. Un catálogo que dice «compatible con PQC» prueba, a lo sumo, una capacidad declarada por el proveedor. La configuración y el uso efectivo tienen que comprobarse por separado.

Cómo levantar un inventario que permita decidir

Una primera fila puede referirse al frontal de una aplicación, con propietario técnico, endpoint autorizado, versión, protocolo, función criptográfica y evidencia fechada. Una segunda, al servicio que autentica usuarios. Una tercera, a la firma con la que se actualiza el software de los equipos. Registra el origen de cada dato: configuración examinada, prueba de interoperabilidad, documentación del proveedor o inferencia pendiente. Si un tercero opera una parte y todavía no ha contestado, consérvalo como desconocido. Una casilla vacía puede ser más urgente que un algoritmo antiguo conocido si bloquea la recuperación del servicio y nadie sabe quién lo mantiene.

No se debe copiar en esa tabla una clave privada, un secreto de sesión, contraseñas ni material descifrado de clientes. El propósito es conocer tipos, versiones, propietarios y dependencias, no crear un archivo que permita suplantar los sistemas. Tampoco es necesario escanear Internet ajeno para conseguir una fotografía útil de la propia organización. Comienza con activos que administra o cuyo examen está autorizado. El proyecto NCCoE sobre migración documenta tareas de descubrimiento criptográfico y pruebas de interoperabilidad; la hoja de trabajo que proponemos aquí es una aplicación editorial simplificada de esa separación.

Un caso pequeño con dos prioridades diferentes

Supongamos que una organización mantiene un portal informativo y un servicio aparte que recibe contratos confidenciales. Ambos terminan TLS en el mismo proveedor, pero el primero sirve páginas públicas y el segundo transmite documentos que deben protegerse durante años. Una lista que solo diga «TLS en los dos» no permite priorizar. Para el servicio de contratos anotamos la vida útil de la información, los clientes que se conectan y si el proveedor dispone de una prueba de negociación poscuántica en ese recorrido. Para el portal no desaparece la necesidad de autenticidad; cambia el peso relativo de la confidencialidad a largo plazo.

Ahora añadamos una tercera dependencia: el aparato que verifica las actualizaciones del servicio de contratos acepta una sola familia de firmas. Su vida prevista es de quince años y no sabemos todavía si puede actualizar su verificador. Tal vez esa dependencia requiera actuar antes que un servidor modernizable en una tarde, aunque el aparato no atienda tantas conexiones. El inventario útil no clasifica por número de visitas, sino por función, impacto, horizonte del dato y dificultad de reemplazo. Quince años es una hipótesis del ejemplo, no una duración prometida para ningún dispositivo real.

Una decisión razonable sería pedir al proveedor una versión de prueba, documentación de los clientes admitidos y un plan para los que aún no lo están. Hay que medir qué ocurre con la latencia, el tamaño de los mensajes, los intermediarios y los límites de dispositivos pequeños. Una sesión exitosa desde un portátil moderno no garantiza que negocie bien un cliente embebido. La retirada de mecanismos heredados necesita pruebas con el conjunto de clientes admitidos y un procedimiento para recuperar un fallo sin rebajar la seguridad de todos de forma silenciosa.

Qué fechas cita Estados Unidos y qué recomienda Europa

El NIST sitúa 2035 como objetivo principal de migración de los sistemas federales estadounidenses y señala dos hitos más tempranos para activos federales de alto valor y sistemas de alto impacto: 2030 para establecimiento de claves y 2031 para firmas digitales. El informe final de 2026 desarrolla la transición en sus estándares. Son referencias con destinatario y alcance concretos. Es incorrecto presentar 2030 como fecha universal de caducidad de cualquier certificado en España, o interpretar 2035 como el año en que llegará necesariamente un ordenador capaz de romper esos sistemas.

La Comisión Europea explica que los Estados miembros adoptaron en junio de 2025 una hoja de ruta coordinada de alto nivel. Recomienda que todos hayan iniciado la transición al final de 2026 y que los usos de alto riesgo estén protegidos lo antes posible y, como máximo, al final de 2030. Iniciar una transición no significa haber completado todos los sistemas. Tampoco se sigue de esa recomendación que todos los sitios en un país ya estén migrados. Las obligaciones efectivas de una organización pueden depender de su sector, contratación pública, contratos y autoridades competentes.

Cómo exigir una respuesta verificable a un proveedor

Un correo que pregunte «¿sois poscuánticos?» invita a responder sí o no sin aclarar nada. Una pregunta mejor sería: «En el servicio y versión que tenemos contratados, ¿qué función poscuántica se ofrece, qué protocolo la utiliza, para qué clientes y cómo comprobamos que se negoció?». Para firmas de software, pide el formato aceptado por el verificador instalado y el proceso de actualización de la confianza. Para almacenamiento, distingue el cifrado de datos del mecanismo que protege sus claves. Las respuestas deben tener fecha: el soporte anunciado hoy puede llegar primero a un entorno de pruebas y más tarde al producto real.

Una organización pequeña tampoco necesita inventar algoritmos ni ensamblar por su cuenta un protocolo híbrido. Los esquemas que combinen mecanismos tradicionales y poscuánticos deben formar parte de una implementación y un protocolo que consideren cómo negociar, derivar, validar y manejar fallos. Concatenar dos resultados o activar una opción con un nombre llamativo no demuestra que se hayan obtenido las propiedades deseadas. La prueba final tiene un objeto concreto: cliente identificado, versión de servidor, negociación o firma observada y resultado de compatibilidad. Si no se puede describir esa prueba, conviene conservar la palabra «pendiente» en la fila correspondiente.

Una prueba pequeña puede dejar un rastro comprensible sin contener secretos. Anota fecha, versión exacta del cliente de prueba, servicio de destino y configuración prevista. Registra qué se negoció realmente y qué ocurrió cuando se probó con un cliente antiguo autorizado. Si la comunicación tuvo éxito porque se volvió silenciosamente al mecanismo anterior, ese dato debe figurar como compatibilidad por retroceso, no como evidencia de negociación poscuántica. Si el cliente se negó a conectar, la decisión cambia: habrá que documentar qué usuarios se verían afectados y si existe una actualización compatible. Las dos respuestas son útiles aunque ninguna permita todavía retirar el mecanismo anterior.

Al evaluar la firma, la comprobación es diferente. Un sistema de pruebas puede verificar una actualización legítima con el mecanismo previsto y rechazar otra cuyo contenido se modificó. Además, conviene ensayar qué sucedería si se renueva una clave autorizada o si el verificador instalado aún no entiende el nuevo formato. Que un servidor web negocie correctamente una sesión no demuestra que un dispositivo antiguo pueda confiar en una actualización firmada. Son dos filas distintas del inventario precisamente porque su evidencia también es distinta.

El resultado del primer mes de trabajo puede ser mucho más modesto que declarar una empresa «lista para la era cuántica»: saber qué mecanismo protege los documentos más duraderos, quién puede cambiarlo, qué dependencia no se puede actualizar y cómo demostrar qué ocurrió en un ensayo. Con esas cuatro respuestas se puede acordar una prioridad y un presupuesto. Sin ellas, renovar primero lo que esté más a la vista puede dejar intacta la dependencia que más costará cambiar.

Fuentes y agradecimientos

Agradecemos al NIST el informe final 8547 y sus estándares FIPS, a NCCoE la documentación de migración y a la Comisión Europea la hoja de ruta de los Estados miembros. El inventario y el escenario son ejemplos originales de Gaia; no representan un escaneo de infraestructura real ni una certificación.