Recursos

Preparar TLS para la criptografía poscuántica: qué incluir en el inventario

Para preparar una migración de TLS a la criptografía poscuántica, identifica dónde se utilizan algoritmos de clave pública vulnerables a ataques cuánticos. Registra quién gestiona esos sistemas y qué cambios admiten sus clientes. Sustituir los certificados es solo una parte del trabajo.

Normas publicadas

El NIST finalizó tres normas de criptografía poscuántica en agosto de 2024: ML-KEM para el establecimiento de claves, y ML-DSA y SLH-DSA para firmas digitales. Estos algoritmos tienen funciones distintas.

El riesgo afecta principalmente a la criptografía asimétrica: RSA, DSA, ECDSA, EdDSA, DH sobre cuerpos finitos y ECDH. El cifrado simétrico y las funciones hash no se ven afectados del mismo modo. Por eso, un plan de preparación de TLS no debe presentar todos los cifrados o hashes como igualmente comprometidos.

La hoja de ruta coordinada de la UE propone que los Estados miembros y las organizaciones implicadas planifiquen juntos la transición a la criptografía poscuántica (PQC). Las organizaciones europeas pueden utilizarla como referencia para planificar su migración.

Algoritmo Norma Función Nota operativa
ML-KEM FIPS 203 Establecimiento de claves La familia de algoritmos más directamente relacionada con el intercambio de claves TLS.
ML-DSA FIPS 204 Firmas digitales Relevante para los futuros mecanismos de firma de certificados y software.
SLH-DSA FIPS 205 Firmas digitales Una norma de firmas basada en funciones hash que aporta diversidad de algoritmos.

Establecimiento de claves y autenticación mediante certificados

Planifica por separado el establecimiento de claves y la autenticación mediante certificados: utilizan algoritmos diferentes y tienen requisitos de compatibilidad distintos.

Establecer las claves de sesión

ClienteServidor

Proteger los datos intercambiados

ECDHE · ML-KEM

Autenticar el servidor

ClienteServidor

Comprobar su identidad mediante certificados y firmas

X.509 · CertificateVerify
Usar un intercambio de claves poscuántico no convierte la cadena de certificados en poscuántica. Son dos migraciones distintas.
Protocolos y compatibilidad

Establecimiento de claves

Es la parte de la negociación TLS que genera los secretos de sesión. El acuerdo híbrido ECDHE-MLKEM está publicado en la RFC 10024; los grupos ML-KEM independientes siguen en fase de borrador. Ambos dependen de la compatibilidad de clientes, servidores, bibliotecas y políticas.

Autenticación mediante certificados

Es la cadena de certificados X.509 utilizada para autenticar al servidor. Existen RFC para los identificadores ML-DSA, SLH-DSA y ML-KEM en X.509, pero eso no equivale a compatibilidad en producción con certificados de servidor TLS de confianza pública.

Prioriza según el tiempo que los datos deban permanecer confidenciales

Una razón para preparar ya la transición a PQC es el riesgo de «recoger ahora, descifrar después»: un atacante puede registrar tráfico cifrado hoy e intentar descifrarlo más adelante si llega a disponer de un ordenador cuántico capaz de romper la criptografía utilizada. El riesgo es especialmente relevante cuando los datos deben seguir siendo confidenciales durante años.

Un sitio comercial, un panel de administración interno, un portal de nóminas y un endpoint de exportación de datos de clientes tienen requisitos de confidencialidad distintos. Utiliza esos requisitos para priorizar su migración.

La migración de las firmas de certificados aborda otro riesgo. Afecta a la autenticación futura, las cadenas de confianza, las políticas de los programas raíz, el comportamiento de Certificate Transparency y la compatibilidad de los clientes. No permite descifrar tráfico ya registrado.

Qué pueden hacer los equipos ahora

  • Identifica dónde se utilizan RSA, ECDSA, EdDSA, DH sobre cuerpos finitos y ECDH en certificados, endpoints TLS, dispositivos, balanceadores de carga, VPN y servicios gestionados.
  • Registra qué sistemas terminan las conexiones TLS, qué certificados presentan, qué equipos son responsables y qué proveedores controlan los componentes criptográficos.
  • Clasifica los datos según el tiempo que deban permanecer confidenciales. Los datos que deben protegerse durante años cambian las prioridades; las sesiones web públicas breves, por lo general, no.
  • Pide a los proveedores fechas concretas y nombres precisos de las funciones compatibles: ML-KEM en lugar de Kyber anterior al estándar, ML-DSA, SLH-DSA, TLS híbrido, validación de algoritmos CAVP, validación de módulos FIPS 140-3 cuando sea necesaria y comportamiento al negociar una opción inferior o alternativa.
  • Prueba TLS híbrido solo cuando conozcas los clientes que se conectarán y resulte sencillo volver a la configuración anterior. Mide la latencia, el tamaño de la negociación, el comportamiento de los equipos intermediarios y la capacidad de observar los resultados.
  • No reduzcas el plan de migración a volver a emitir certificados. Las políticas de certificados públicos y la compatibilidad de los clientes siguen siendo relevantes.

Qué conviene evitar

  • Comprar un producto solo porque se anuncia como resistente a ataques cuánticos.
  • Sustituir todos los certificados públicos antes de que los navegadores, autoridades de certificación y clientes admitan los algoritmos correspondientes.
  • Suponer que un intercambio de claves PQC también proporciona firmas de certificados PQC.
  • Tratar la criptografía poscuántica y la distribución cuántica de claves como si fueran el mismo proyecto de migración.
  • Descuidar la asignación de responsables de certificados, las renovaciones y las prácticas de seguridad TLS porque PQC parezca más estratégico.

Cómo encaja Nocert

Nocert no emite certificados ni migra endpoints a criptografía poscuántica. Los espacios de trabajo Compliance de Business y Custom muestran algoritmos de certificados, resultados de comprobaciones de políticas TLS y evidencias con fecha y hora procedentes de observaciones públicas e internas.

Utiliza estas observaciones para planificar la migración. Registra el responsable, proveedor, algoritmos y restricciones de compatibilidad de cada sistema.

Fuentes primarias

Esta nota se basa en las normas y recomendaciones de migración PQC del NIST, los trabajos de TLS y X.509 del IETF, los Baseline Requirements del CA/Browser Forum y la hoja de ruta coordinada de la UE sobre PQC.