Cryptographie post-quantique : l’inventaire vient avant le nouvel algorithme

Pour préparer une migration post-quantique, commencez par recenser les usages de la cryptographie asymétrique, les données et processus qu’ils protègent, ainsi que les composants nécessaires à leur évolution. Classez ensuite chaque usage selon la durée de protection attendue, sa criticité, sa capacité de mise à jour et sa prochaine fenêtre de renouvellement.

Ce travail produit trois livrables distincts : un registre des dépendances cryptographiques, une file de priorités et un calendrier de transition. Les algorithmes et configurations hybrides ne sont testés qu’ensuite, sur des périmètres définis par l’inventaire, avant toute décision de mise en production.

Construire un inventaire orienté vers la décision

Une liste de certificats ou de bibliothèques ne suffit pas. Chaque entrée doit relier un usage métier, les données protégées, la propriété recherchée — confidentialité, authenticité, intégrité ou non-répudiation — et les composants dont dépend le remplacement du mécanisme cryptographique.

Le projet de migration du NCCoE, rattaché au NIST, sépare précisément deux chantiers : la découverte des usages cryptographiques, destinée à éclairer la gestion des risques et les priorités, puis les essais d’interopérabilité des mécanismes post-quantiques dans un environnement contrôlé hors production.

Pour chaque usage, relevez au minimum :

• le service concerné, son responsable et les données protégées ;
• le protocole, l’algorithme, les clés, les certificats et les bibliothèques employés ;
• les équipements, modules matériels, autorités de certification, API et services tiers dépendants ;
• le fournisseur, la version, la fin de support et la feuille de route post-quantique connue ;
• le mode d’évolution possible : configuration, mise à jour logicielle, remplacement matériel ou modification contractuelle.

Les outils de découverte accélèrent le recensement, mais une analyse organisationnelle reste nécessaire pour retrouver la cryptographie intégrée à un équipement, déléguée à un prestataire ou imposée par un partenaire. Les équipes chargées des identités, des PKI, des réseaux, des sauvegardes, des applications et des achats doivent donc compléter les résultats techniques.

Prioriser avec une matrice à quatre dimensions

La première dimension est la durée pendant laquelle la confidentialité ou l’authenticité doit subsister. Un document qui doit rester secret au-delà du prochain renouvellement technique n’a pas le même calendrier qu’une session éphémère, notamment parce que des données interceptées aujourd’hui pourraient être conservées en vue d’un déchiffrement futur.

La FAQ de l’ANSSI recommande d’inventorier les produits, les usages métier, les algorithmes et les données dont la confidentialité ou l’authenticité doit être garantie après 2030, puis d’intégrer les délais de renouvellement et les feuilles de route des fournisseurs. Elle précise aussi que ses préconisations post-quantiques ne constituent pas, à elles seules, une obligation réglementaire générale.

Attribuez à chaque ligne une valeur faible, moyenne ou forte sur quatre axes :

• Durée de protection : jusqu’à quand les données doivent-elles rester confidentielles ou authentifiables ?
• Criticité métier : quelles seraient les conséquences d’une divulgation, d’une usurpation ou d’une interruption ?
• Capacité de mise à jour : une configuration suffit-elle, ou faut-il remplacer un équipement, un protocole ou un contrat ?
• Fenêtre de renouvellement : une fin de support, une refonte ou un appel d’offres permet-il déjà d’intervenir ?

Une matrice directement exploitable peut classer en P1 les protections longues associées à un service critique ou à un composant difficile à modifier. La catégorie P2 regroupe les usages importants mais actualisables, ou proches d’un renouvellement. P3 couvre les protections brèves, peu critiques et sans dépendance lourde. Ce classement est une règle de gestion interne, pas une échelle officielle : un composant impossible à mettre à jour doit toujours faire l’objet d’un arbitrage explicite.

Transformer les priorités en calendrier interne

Le calendrier doit partir du besoin de protection et non d’une date institutionnelle prise isolément. Pour chaque usage, partez de l’échéance interne, puis retranchez les délais de qualification, d’essai, d’achat, de déploiement et de traitement des dépendances. Si le point de départ obtenu précède le prochain cycle budgétaire, l’arbitrage ne peut pas attendre ce cycle.

1. Associer à chaque ligne un responsable et une date de révision.
2. Interroger les fournisseurs des composants P1 sur leurs produits, formats et calendriers de prise en charge.
3. Inscrire la crypto-agilité et les exigences post-quantiques pertinentes dans les renouvellements déjà programmés.
4. Réserver un environnement d’essai aux cas prioritaires dont les dépendances sont suffisamment connues.

Ce calendrier doit distinguer ce qui relève de l’analyse, de l’achat, du pilote et de la production. Il évite de transformer une échéance indicative en obligation uniforme tout en empêchant qu’un équipement rigide soit reconduit faute d’avoir été identifié assez tôt.

Tester l’hybridation sans confondre pilote et production

Un pilote hybride combine un mécanisme classique et un mécanisme post-quantique afin d’éviter qu’une transition immédiate ne repose uniquement sur une technologie plus récente. Il doit répondre à une question précise : la configuration retenue fonctionne-t-elle avec les clients, serveurs, certificats, équipements intermédiaires et procédures d’exploitation du cas d’usage ?

Choisissez un périmètre P1 représentatif mais circonscrit. Vérifiez la compatibilité de bout en bout, les tailles de clés, de signatures ou de messages, les temps de traitement, les erreurs de négociation et la consommation de ressources. Testez aussi la rotation des clés, le retour arrière et la coexistence avec les partenaires qui n’acceptent pas encore les mêmes mécanismes.

La crypto-agilité ne se résume pas à un menu permettant de choisir un algorithme. Les paramètres et mécanismes doivent pouvoir évoluer sans réécriture complète de l’application ; les dépendances et versions doivent rester visibles ; une mise à jour doit pouvoir être déployée, surveillée puis annulée de façon contrôlée.

Définir la porte de sortie vers la production

La cartographie décrit l’existant, le pilote produit des preuves techniques et la décision de production accepte un risque résiduel documenté. La réussite d’un essai sur un protocole ou un produit ne valide pas automatiquement les autres usages du même fournisseur.

Une bascule peut être examinée lorsque le propriétaire du périmètre est identifié, que ses dépendances sont couvertes, que l’hybridation correspond au contexte de sécurité et que l’interopérabilité, la supervision et le retour arrière ont été testés. La version de l’inventaire utilisée pour cette décision doit conserver une date de révision, un responsable et un état de mise à jour.

Le premier résultat de la migration est donc un registre exploitable accompagné de priorités, pas un nouvel algorithme déployé partout. Cet ordre permet de concentrer les essais sur les données qui exigent une protection durable, de profiter des renouvellements prévus et de traiter les composants rigides avant qu’ils ne deviennent des impasses.