El Centro Nacional de Ciberseguridad del Reino Unido ha publicado recomendaciones para configurar criptografía poscuántica en TLS, y su mensaje a los operadores es directo: ahora es el momento de migrar. El anuncio se realizó en una entrada de blog, Post-quantum updates to our TLS guidance, que indica que la orientación TLS del organismo cubre ya cómo desplegar algoritmos poscuánticos, y no solo si conviene pensarlo algún día.

Ese cambio de enfoque es relevante para cualquier persona que gestione infraestructura de identidad en el Reino Unido, es decir, para todo aquel que tenga una página de inicio de sesión. TLS es el transporte subyacente de cada aserción SAML, cada intercambio de tokens OIDC, cada llamada de aprovisionamiento SCIM y cada API que emite un bearer token. Si el intercambio de claves que protege esas sesiones puede ser comprometido por un ordenador cuántico en el futuro, la capa de identidad cae con él. El NCSC indica ahora a los operadores que dejen de tratarlo como un tema de investigación y empiecen a tratarlo como trabajo de configuración.

El propio anuncio es breve. Indica que el NCSC ha publicado sus recomendaciones para configurar criptografía poscuántica en TLS y que la migración debe comenzar. En el material revisado aquí, no fija ningún plazo, no nombra ningún algoritmo obligatorio ni establece medidas de cumplimiento. Los lectores deben consultar la orientación completa del NCSC para conocer las recomendaciones de configuración específicas, en lugar de confiar en resúmenes, incluido este.

Algo de contexto general ayuda a entender por qué TLS es el primer objetivo. El riesgo cuántico a corto plazo para TLS no consiste en que los atacantes rompan las sesiones actuales en tiempo real. Se trata del enfoque "harvest now, decrypt later": un adversario registra tráfico cifrado hoy y lo descifra cuando exista un ordenador cuántico suficientemente capaz. Eso convierte el intercambio de claves en la parte urgente, porque protege la confidencialidad de todo lo que viene después. Las firmas y los certificados también importan, pero un certificado falsificado solo es útil en el momento del ataque, mientras que una sesión registrada permanece registrada de forma indefinida. Por eso el trabajo del sector sobre TLS poscuántico, incluidos los borradores del grupo de trabajo TLS del IETF sobre intercambio de claves híbrido, se ha centrado en combinar un acuerdo de claves clásico con un mecanismo de encapsulación de claves poscuántico, de modo que la sesión sea segura si cualquiera de los dos resiste. NIST ha publicado estándares definitivos para algoritmos poscuánticos, incluido el mecanismo de encapsulación de claves ML-KEM en FIPS 203, que es el componente base que utilizan la mayoría de estos despliegues híbridos. Si la orientación del NCSC se alinea con esos detalles específicos, y en qué medida, es algo que corresponde decir a la propia orientación.

Para los equipos de IAM, la incómoda realidad es que la configuración TLS suele ser problema de otra persona hasta que deja de serlo. Los proveedores de identidad, los proxies inversos, las pasarelas de API, los balanceadores de carga y algún que otro Java keystore olvidado terminan TLS, y raramente comparten un único responsable. El intercambio de claves poscuántico tiende a llegar como una funcionalidad de negociación entre cliente y servidor, de modo que un navegador moderno que habla con una CDN moderna puede estar ya usándolo mientras la conexión LDAP-over-TLS al directorio local negocia conjuntos de cifrado que eran modernos en la época de los teléfonos plegables. La buena noticia es que la mayor parte del trabajo es inventario y actualizaciones, no invención criptográfica. No se le pide a nadie que implemente un esquema de retículos en un fin de semana. Se le pide que sepa qué ejecuta, que lo actualice y que active las opciones correctas.

Existe además un precedente alentador. La migración desde TLS 1.0 y 1.1, y la retirada anterior de los certificados SHA-1, parecieron interminables en su momento y ambas se completaron, en gran medida porque los navegadores y las bibliotecas se adelantaron y el resto del ecosistema siguió su estela. TLS poscuántico apunta a seguir el mismo camino. Las organizaciones que traten la orientación del NCSC como una lista de comprobación ahora pasarán los próximos años parcheando de forma tranquila. Las que esperen tendrán que redescubrir cada endpoint TLS no documentado de su entorno durante un incidente, lo cual es una manera pésima de construir un registro de activos, aunque, eso sí, muy exhaustiva.

Qué revisar: comience con un inventario de cada punto de terminación TLS en el camino de identidad, incluidos los endpoints del IdP, las APIs de tokens e introspección, los conectores SCIM, LDAPS y cualquier sidecar de service mesh, y registre la versión de la biblioteca o del appliance que hay detrás de cada uno. Lea la orientación del NCSC completa y compare sus recomendaciones de configuración con lo que esos endpoints pueden negociar hoy, prestando especial atención al intercambio de claves. Después, abra tickets con los proveedores que aún no puedan hacerlo, porque una ruta de actualización con soporte es lo único que un cambio de configuración no puede simular.