Ne choisissez pas d'algorithme post-quantique tant que vous ne savez pas où se niche la cryptographie à clé publique dans votre système d'information. Le NIST a publié les FIPS 203, 204 et 205 en août 2024 et recommande aux organisations d'entamer dès maintenant leur migration. Ces standards indiquent vers quoi migrer. Ils ne disent rien de ce que vous exploitez aujourd'hui, et le découvrir est l'étape la plus longue.
Ce que les échéances exigent de vous
La page du projet du NIST indique que, selon le calendrier de transition défini dans NIST IR 8547, les algorithmes vulnérables au calcul quantique seront dépréciés puis définitivement retirés de ses standards d'ici 2035, les systèmes à haut risque devant migrer bien plus tôt. La page consacrée au draft de l'IR 8547 précise que la version finale l'a remplacé le 27 octobre 2026. Nos sources ne listent ni les standards vulnérables ni les dates antérieures pour les systèmes à haut risque : reportez-vous au texte du NIST.
Le NCSC britannique traduit ce calendrier en jalons sur lesquels une équipe IT peut bâtir un budget, dans son guide sur les calendriers de migration PQC :
| D'ici | Ce qu'attend le NCSC |
|---|---|
| 2028 | Définir les objectifs de migration, mener un exercice de découverte complet, élaborer un plan initial |
| 2031 | Réaliser la migration précoce des systèmes les plus prioritaires ; affiner le plan pour en faire une feuille de route complète |
| 2035 | Achever la migration de l'ensemble des systèmes, services et produits |
L'inventaire alimente les trois chantiers de 2028. S'il est maigre, les deux autres relèvent de la devinette.
Ce qui figure sur la liste
La cible, c'est tout ce qui repose sur la cryptographie asymétrique à clé publique, que d'après le NCSC les ordinateurs quantiques seront capables de casser. La section du NCSC consacrée à la découverte couvre les domaines suivants :
- les systèmes et services que vous exploitez, pour vos utilisateurs internes comme pour des tiers ;
- les produits que vous fabriquez ou utilisez et qui remplissent une fonction de cryptographie, de sécurité, de communication ou de traitement de données ;
- les applications logicielles et les équipements réseau tels que routeurs, switchs, passerelles, VPN et stations de base ;
- les terminaux mobiles, serveurs et postes de travail ;
- les équipements IoT et ICS dotés d'une fonction de communication, les jetons remis aux utilisateurs, ainsi que les équipements et capteurs installés sur le terrain ;
- les données que vous détenez, leur durée de vie attendue et leur valeur pour un adversaire, ainsi que leur protection en transit et au repos.
Les certificats ne sont pas cités dans cette liste, même si le NCSC consacre une section distincte à la PKI d'entreprise. Ajoutez en lignes distinctes les certificats web publics, les CA internes, les certificats clients et les clés de signature de code ; c'est notre appréciation, pas celle du NCSC. Ajoutez aussi les prestataires de services managés.
Il ne s'agit pas d'un registre d'actifs formel. Consignez pour chaque système sa nature, son échelle, sa version, son niveau de correctifs et ses dépendances ; une ligne par système suffit.
Où les inventaires déraillent
Trois endroits méritent un examen volontaire, car aucun n'apparaît dans un export de certificats ou une liste de paquets : les clés codées en dur dans le code applicatif ou la configuration, les clés de signature conservées dans un HSM, et les firmwares des équipements embarqués et déployés sur le terrain, que l'on ne met pas à jour comme un serveur. Le NCSC signale comme contrainte le matériel à longue durée de vie et les cycles de remplacement espacés, et c'est sur ces équipements que le problème se pose avec le plus d'acuité.
Dresser la liste en une semaine
Commencez par le haut, avec les services essentiels et leurs interdépendances, puis passez à une approche ascendante là où cette vue s'arrête. Voici un découpage réaliste pour une petite équipe :
- Jour 1. Listez les services clés et les données que chacun traite, et repérez les données qui doivent rester secrètes pendant des années. Envoyez le jour même l'e-mail aux fournisseurs ci-dessous, car ce sont leurs réponses qui prennent le plus de temps.
- Jours 2 et 3. Exportez les listes de certificats de chaque CA que vous exploitez et demandez les leurs à chaque équipe qui achète des certificats. Ajoutez les configurations VPN et d'accès distant. Rassemblez les SBOM, fichiers de verrouillage (lockfiles) ou listes de paquets des logiciels que vous développez et exploitez, puis cherchez-y les bibliothèques cryptographiques et leurs versions. Parcourez les dépôts et les répertoires de configuration à la recherche de clés privées et de certificats commités ; chaque occurrence devient une ligne, et une clé privée dans un dépôt doit de toute façon être corrigée.
- Jour 4. Lancez un scanner TLS sur les points d'accès externes et internes, et vérifiez les clés d'hôte SSH ainsi que les propositions VPN ou IPsec offertes par vos passerelles. Comparez les résultats avec vos lignes : le résultat d'un scan sert de contre-vérification, pas de substitut.
- Jour 5. Fusionnez, signalez les lacunes et écrivez « inconnu » là où vous n'avez pu rien confirmer.
Les questions à poser aux fournisseurs tiennent en un seul e-mail :
- Lesquels de vos produits ou services que nous utilisons reposent sur la cryptographie à clé publique, et quelles bibliothèques et versions contiennent-ils ?
- Quel est votre plan de migration PQC, avec quelles dates ?
Le NCSC demande de s'assurer que les prestataires managés réalisent ces évaluations pour les services qu'ils exploitent pour vous. Poser la question par écrit est notre recommandation pour y parvenir.
Transformer la liste en plan
Pour chaque ligne, choisissez l'une des stratégies du NCSC : migration sur place, re-platforming, retrait du service, exploitation jusqu'à la fin de vie, ou acceptation du risque. Les systèmes qui n'utilisent aucune cryptographie à clé publique n'appellent aucune action.
Classez les lignes d'après la durée de vie et la valeur des données qu'elles protègent, puis d'après leur dépendance à du matériel à longue durée de vie.
Attendez-vous à ce que l'ancien et le nouveau coexistent un certain temps. Privilégiez les produits dotés d'agilité cryptographique, c'est-à-dire qui prennent facilement en charge d'autres suites d'algorithmes, et décidez à l'avance à quelle date vous cesserez de prendre en charge les algorithmes traditionnels.
Ce n'est qu'ensuite qu'il faut choisir les algorithmes. Le NIST s'attend à ce que ML-KEM (FIPS 203) pour l'établissement de clés, ainsi que ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) pour les signatures, forment le socle de la plupart des déploiements. La FIPS 203 comporte une note de planification signalant un point qui sera corrigé dans une révision ultérieure : consultez donc les errata avant de l'implémenter. Le NIST poursuit la standardisation de Falcon et de HQC ; sa page du projet PQC est l'endroit où suivre les évolutions.
Pour vous faire accompagner dans la découverte, notre équipe de conseil réalise des évaluations.
Par où commencer
- Désignez un responsable, bloquez une semaine et envoyez l'e-mail aux fournisseurs dès le premier jour.
- Construisez une ligne par système : responsable, finalité, usages de la cryptographie à clé publique, versions, dépendances, durée de vie des données, fournisseur, stratégie retenue, date cible.
- Collectez les certificats, les configurations VPN et les SBOM, puis lancez les analyses TLS, SSH et les recherches dans les dépôts.
- Vérifiez à la main les clés codées en dur, la signature adossée à un HSM et les firmwares embarqués, et marquez « inconnu » tout ce qui n'est pas confirmé.
- Classez les lignes selon la durée de vie des données et la dépendance au matériel, puis attribuez à chacune une stratégie du NCSC et une date cible, afin que la feuille devienne votre plan 2028.
- Lisez la version finale de l'IR 8547 pour connaître les dates de dépréciation des systèmes à haut risque, et fixez des échéances internes antérieures à 2035 là où elle l'exige.
