Le National Cyber Security Centre du Royaume-Uni a publié des recommandations pour configurer la cryptographie post-quantique dans TLS, et son message aux opérateurs est sans détour : le moment de migrer est maintenant. La mise à jour a été annoncée dans un billet de blogue, Post-quantum updates to our TLS guidance, qui indique que les conseils TLS de l'organisme couvrent désormais le déploiement des algorithmes post-quantiques, et non plus seulement la question de savoir s'il faudra y penser un jour.

Ce changement est important pour toute personne exploitant une infrastructure d'identité au Royaume-Uni, c'est-à-dire pour quiconque possède une page de connexion. TLS est le transport sous-jacent de chaque assertion SAML, de chaque échange de jeton OIDC, de chaque appel de provisionnement SCIM et de chaque API qui émet un jeton porteur. Si l'échange de clés protégeant ces sessions peut éventuellement être compromis par un ordinateur quantique, la couche d'identité s'effondre avec lui. Le NCSC demande maintenant aux opérateurs de cesser de traiter cela comme un sujet de recherche et de commencer à le traiter comme un travail de configuration.

L'annonce elle-même est brève. Elle indique que le NCSC a publié ses recommandations pour configurer la cryptographie post-quantique dans TLS et que la migration devrait commencer. Dans le matériel examiné ici, aucune échéance n'est fixée, aucun algorithme obligatoire n'est nommé et aucune mesure d'application n'est mentionnée. Les lecteurs devraient consulter l'intégralité des conseils du NCSC pour connaître les recommandations de configuration précises, plutôt que de se fier à des résumés, y compris celui-ci.

Un contexte général aide à comprendre pourquoi TLS est la première cible. Le risque quantique à court terme pour TLS n'est pas que des attaquants compromettent les sessions actuelles en temps réel. Il s'agit du « harvest now, decrypt later » : un adversaire enregistre le trafic chiffré aujourd'hui et le déchiffre une fois qu'un ordinateur quantique suffisamment performant existe. C'est pourquoi l'échange de clés constitue la partie urgente, car il protège la confidentialité de tout ce qui suit. Les signatures et les certificats sont également importants, mais un certificat falsifié n'est utile qu'au moment de l'attaque, alors qu'une session enregistrée demeure enregistrée indéfiniment. C'est pourquoi les travaux de l'industrie sur le TLS post-quantique, notamment les projets de l'IETF TLS working group sur l'échange de clés hybride, se sont concentrés sur la combinaison d'un accord de clés classique avec un mécanisme d'encapsulation de clés post-quantique, de sorte que la session soit sécurisée si l'un ou l'autre tient. Le NIST a publié des normes finales pour les algorithmes post-quantiques, notamment le mécanisme d'encapsulation de clés ML-KEM dans FIPS 203, qui est le bloc de construction utilisé par la plupart de ces déploiements hybrides. C'est au document de référence du NCSC lui-même de préciser si et comment ses conseils s'alignent sur ces détails.

Pour les équipes IAM, la vérité inconfortable est que la configuration TLS est habituellement le problème de quelqu'un d'autre, jusqu'à ce qu'elle ne le soit plus. Les fournisseurs d'identité, les mandataires inverses, les passerelles API, les équilibreurs de charge et le vieux keystore Java oublié dans un coin terminent tous TLS, et ils partagent rarement un seul propriétaire. L'échange de clés post-quantique tend à se présenter comme une fonctionnalité de négociation entre le client et le serveur, de sorte qu'un navigateur moderne communiquant avec un CDN moderne l'utilise peut-être déjà, pendant que la connexion LDAP-over-TLS vers l'annuaire sur site négocie des suites de chiffrement qui étaient à la mode à l'époque des téléphones à clapet. La bonne nouvelle, c'est que la majeure partie du travail consiste en un inventaire et des mises à niveau, et non en une invention cryptographique. Personne n'est invité à implémenter un schéma sur réseau euclidien en une fin de semaine. On demande de savoir ce que l'on exploite, de le mettre à jour et d'activer les bonnes options.

Il existe aussi un précédent encourageant. La migration depuis TLS 1.0 et 1.1, ainsi que le retrait antérieur des certificats SHA-1, semblaient tous deux interminables à l'époque et ont pourtant été menés à bien, en grande partie parce que les navigateurs et les bibliothèques ont bougé en premier et que le reste de l'écosystème a suivi. Le TLS post-quantique s'annonce de la même façon. Les organisations qui traitent les conseils du NCSC comme une liste de contrôle dès maintenant passeront les prochaines années à corriger tranquillement leur configuration. Celles qui attendent auront le plaisir de redécouvrir chaque point de terminaison TLS non documenté de leur environnement lors d'un incident, ce qui est une façon terrible de constituer un registre d'actifs mais, il faut l'admettre, une façon très exhaustive.

Quoi vérifier : commencez par un inventaire de chaque point de terminaison TLS dans le chemin d'identité, notamment les points de terminaison du fournisseur d'identité, les API de jeton et d'introspection, les connecteurs SCIM, LDAPS et tous les sidecars de maillage de services, et consignez la version de la bibliothèque ou de l'appliance derrière chacun. Lisez intégralement les conseils du NCSC et comparez ses recommandations de configuration à ce que ces points de terminaison peuvent négocier aujourd'hui, en portant une attention particulière à l'échange de clés. Ouvrez ensuite des tickets auprès des fournisseurs qui ne peuvent pas encore le faire, car un chemin de mise à niveau pris en charge est la seule chose qu'un changement de configuration ne peut pas simuler.