Pourquoi vous avez besoin dès maintenant d'une feuille de route pour la migration vers le PQC
La dernière fois que le secteur a dû faire face à une migration cryptographique à grande échelle visant à remplacer le protocole RSA par la cryptographie à courbe elliptique (ECC), la transition a pris plus d'une décennie. De nombreuses organisations ne l'ont jamais menée à bien.
La migration vers la cryptographie post-quantique sera d’un ordre de grandeur plus difficile. Les algorithmes de cryptographie post-quantique (PQC) impliquent des clés de plus grande taille, de nouvelles exigences de sécurité, plusieurs familles d’algorithmes et, potentiellement, plusieurs étapes de migration, y compris des périodes transitoires durant lesquelles des algorithmes hybrides, à la fois classiques et post-quantiques, fonctionneront en parallèle. Contrairement à la transition vers la cryptographie elliptique (ECC), cette migration devra peut-être s’effectuer dans des délais très courts, sous la pression de la menace croissante que représentent les adversaires dotés de capacités quantiques et des échéances réglementaires telles que la norme CNSA 2.0.
Sans feuille de route structurée, les organisations risquent de se retrouver dans une situation de précipitation réactive lorsque les menaces quantiques se concrétiseront. Avec une telle feuille de route, la transition devient un processus maîtrisé et progressif qui protège les données critiques à chaque étape.
Ce guide vous accompagne à travers six étapes pour élaborer une feuille de route de migration vers la cryptographie post-quanta (PQC) qui permettra à votre organisation de passer de l'évaluation à l'action.
Étape 1 : Identifier et recenser vos actifs cryptographiques
On ne peut pas migrer ce qu’on ne voit pas. La première étape consiste à dresser un inventaire exhaustif de tous les actifs cryptographiques au sein de votre entreprise.
À découvrir
Votre inventaire doit comprendre :
- Certificats et clés: tous les certificats X.509, TLS , clés de signature de code et clés SSH actuellement utilisés
- Les algorithmes et protocoles sur lesquels repose chaque système (RSA, ECDSA, AES, etc.) ainsi que les protocoles qui les utilisent (TLS, IPsec, S/MIME)
- Bibliothèques cryptographiques: les software qui permettent la mise en œuvre de la cryptographie dans vos applications
- Les modulesHardware (HSM) sont des dispositifs qui stockent et gèrent des clés ; ils peuvent nécessiter hardware du micrologiciel ou hardware pour prendre en charge la cryptographie post-quanta (PQC).
- Terminaux réseau, charges de travail dans le cloud et pipelines CI/CD, partout où des certificats sont émis, renouvelés ou validés
- IoT les appareils distants, les systèmes embarqués et hardware déployé sur le terrain, hardware de longs cycles de vie et des capacités de mise à jour limitées
Pourquoi les méthodes manuelles échouent
Le simple fait de recenser tous les éléments cryptographiques au sein d’une grande entreprise constitue déjà une tâche ardue. Les certificats sont émis et révoqués en permanence, les charges de travail dans le cloud sont activées et désactivées sans cesse, et les équipes de développement intègrent des dépendances cryptographiques sans suivi centralisé. Les audits manuels sont donc irréalisables à l’échelle d’une entreprise.
Les outils de découverte automatisée sont indispensables. Ils fournissent une vue d'ensemble de base de l'utilisation de la cryptographie, qui sert de base à toutes les étapes suivantes de la feuille de route, et permettent une surveillance continue afin que votre inventaire reste à jour à mesure que votre environnement évolue.
Point clé :
Si vous ne savez pas où se trouvent vos éléments cryptographiques, vous ne pouvez ni évaluer votre risque quantique, ni hiérarchiser votre migration, ni mesurer vos progrès. Commencez par là.
Étape 2 : Classer et hiérarchiser en fonction du risque
Tous les systèmes ne sont pas exposés au même risque quantique. Une fois que vous disposez d'une bonne visibilité, classez vos actifs cryptographiques en fonction de quatre facteurs :
Cadre de classification des risques
Sensibilité des données
Quelles sont les exigences en matière de confidentialité ? Les dossiers médicaux, les secrets d'affaires, les renseignements gouvernementaux et les données financières nécessitent une protection maximale.
Durée de confidentialité
Pendant combien de temps ces données doivent-elles rester confidentielles ? Les données qui doivent être protégées pendant une décennie ou plus sont exposées au risque quantique le plus urgent.
Longévité du système
Combien de temps ce système restera-t-il en service ? Les calculateurs automobiles, les satellites et les implants médicaux ne peuvent pas être facilement mis à jour une fois déployés.
Difficulté de remplacement
Ce système peut-il être mis à jour à l'aide d'un software , ou nécessite-t-il hardware coûteuses ? Les systèmes nécessitant des modifications doivent faire l'objet d'une planification en amont.
HNDL : Le principal facteur justifiant la priorité accordée au chiffrement
Le risque quantique le plus urgent n’est pas une attaque future : il se produit dès maintenant. Dans le cadre d’une attaquede type « Harvest Now, Decrypt Later» (HNDL), les attaquants interceptent et stockent aujourd’hui des données chiffrées, dans l’intention de les déchiffrer dès qu’un ordinateur quantique pertinent sur le plan cryptographique (CRQC) sera disponible.
À l'heure actuelle, toutes les données devant rester confidentielles à long terme sont vulnérables à l'attaque HNDL. C'est pourquoi les protocoles d'établissement de clés constituent la priorité absolue en matière de migration : si l'échange de clés est compromis, la clé de chiffrement et toutes les données qu'elle protège sont exposées.
Les algorithmes de signature numérique présentent un profil de risque différent. Une signature ne peut être falsifiée qu’après la mise en place d’un CRQC, et non de manière rétroactive. Cela signifie que la migration des signatures est urgente pour les systèmes dont hardware est long (lorsque les phases de conception et de déploiement peuvent s’étendre au-delà du calendrier du CRQC), mais qu’elle est moins urgente que la migration du chiffrement dans les scénarios impliquant des données au repos.
Délais réglementaires
Tous les systèmes soumis à des exigences de conformité doivent être mis en correspondance avec les calendriers réglementaires. La norme CNSA 2.0 de la NSA impose une migration progressive vers les algorithmes de cryptographie post-quantique (PQC) en fonction des cas d’utilisation, avec des échéances initiales. Les organisations des secteurs réglementés doivent aligner leurs priorités sur ces échéances externes.
Point clé :
Donnez la priorité à la migration vers le chiffrement pour les données confidentielles à longue durée de vie (risque HNDL), puis occupez-vous de la migration vers la signature pour hardware à long cycle de vie. Alignez toutes ces étapes sur les échéances réglementaires.
Étape 3 : Choisissez votre stratégie de migration
Il n'existe pas de parcours de migration unique et idéal. La meilleure stratégie dépend de votre profil de risque, de vos exigences en matière de conformité et de vos contraintes techniques. La plupart des organisations auront recours à une combinaison d'approches sur différents systèmes.
Migration par étapes : privilégier la confidentialité avant tout
Cette approche par étapes consiste à migrer dans un premier temps les protocoles clés d'établissement vers la PQC, afin de remédier au risque lié au HNDL, puis à migrer les signatures numériques dans un deuxième temps.
Le raisonnement sous-jacent:
La migration de l'établissement de clés est moins perturbante que celle des signatures. Les signatures PQC sont nettement plus volumineuses que leurs équivalents classiques, et les chaînes de certificats nécessitant plusieurs signatures, la migration des signatures peut impliquer des changements architecturaux plus importants. En sécurisant d'abord l'établissement de clés, vous protégez la confidentialité avec relativement moins d'efforts tout en reportant les PKI plus complexes PKI .
Certains protocoles font déjà l'objet d'une normalisation dans la perspective de cette migration en deux étapes, ce qui garantit une sécurité post-quantique pour les propriétés de confidentialité tout en conservant, pendant la période de transition, une sécurité reposant uniquement sur des ordinateurs classiques pour l'authentification.
Idéal pour :
Les organisations fortement exposées aux menaces HNDL qui doivent garantir rapidement la confidentialité de leurs données sans perturber l'ensemble de leur PKI .
Cryptographie hybride : la ceinture et les bretelles
Les algorithmes hybrides combinent un algorithme classique et un algorithme de cryptographie post-quanta (PQC), de sorte que le système reste sécurisé tant qu'au moins l'un des deux algorithmes n'a pas été piraté.
Le raisonnement sous-jacent:
Les algorithmes de cryptographie post-quantique (PQC) sont plus récents, et leurs risques en matière de sécurité ne sont pas encore pleinement compris. L’algorithme SIKE, qui avait atteint la phase finale du processus de normalisation du NIST avant d’être complètement piraté par une attaque informatique classique, démontre que même les algorithmes validés peuvent échouer. La cryptographie hybride permet de se prémunir contre cette incertitude.
Compromis :
Les approches hybrides accroissent la complexité, génèrent des artefacts cryptographiques plus volumineux, entraînent une baisse des performances, nécessitent davantage de code et de tests, et impliquent une étape de migration supplémentaire lors du passage définitif d’une approche hybride à une approche PQC pure. L’approche hybride est une mesure transitoire, et non une fin en soi.
Les mécanismes hybrides d'encapsulation de clés (KEM) sont moins coûteux que les signatures hybrides, car les KEM sont éphémères et ne nécessitent pas d'infrastructure d'identité à long terme. Les signatures hybrides, en revanche, impliquent des clés persistantes, des certificats et l'infrastructure de confiance complète, y compris une double migration de PKI.
Idéal pour :
Les organisations peu enclines à prendre des risques ou celles opérant dans des environnements où les conséquences d'une défaillance d'un algorithme de cryptographie post-quantique (PQC) seraient graves.
CNSA 1.0 et CNSA 2.0 : s'aligner sur la stratégie du gouvernement
Pour les organisations soumises aux exigences du gouvernement américain, l'approche en deux volets de la NSA offre une feuille de route claire pour la migration :
CNSA 1.0utilise des algorithmes traditionnels dotés de paramètres plus importants, ce qui lui permettra de résister plus longtemps aux attaques quantiques que les configurations standard. Cela permet de gagner du temps, mais il ne s'agit en aucun cas d'une stratégie à long terme. Cela ne fera peut-être que repousser le problème de quelques années.
La norme CNSA 2.0définit les algorithmes de cryptographie post-quanta (PQC) normalisés par le NIST, destinés à une utilisation à long terme. La migration vers la norme CNSA 2.0 se fera de manière échelonnée, la NSA fournissant des calendriers adaptés à chaque cas d'utilisation.
Idéal pour :
Les prestataires du secteur public, les organismes de défense et toute entité tenue de se conformer aux directives cryptographiques de la NSA. Les organisations nécessitant un niveau de sécurité élevé peuvent considérer cette option comme une bonne pratique.
Agilité cryptographique
L'agilité cryptographique désignela capacité d'une organisation à gérer de manière systématique les algorithmes, les protocoles, les clés ou tout autre élément cryptographique sans perturber ses opérations. Quelle que soit la stratégie choisie, l'agilité cryptographique en est le facteur clé. Une architecture crypto-agile vous permet de changer de stratégie ou de combiner différentes approches sans avoir à repenser vos systèmes de A à Z.
Étape 4 : Préparer votre PKI
PKI la colonne vertébrale de l'identité numérique et de la confiance ; elle représente souvent l'étape la plus complexe et la plus chronophage de toute migration vers la cryptographie post-quantum (PQC). La migration PKI ne PKI pas PKI une simple réémission de certificats. Elle nécessite la mise à jour des autorités de certification, des chemins de validation et de tous les systèmes qui dépendent de la chaîne de certificats.
Pourquoi l'infrastructure PKI un facteur limitant
Chaque certificat numérique, chaque connexion authentifiée et chaque élément signé au sein de votre organisation passe par PKI. Tant que votre PKI ne prendra pas en charge les algorithmes PQC, l'adoption à grande échelle de la PQC restera bloquée, quel que soit le degré de préparation de vos applications ou protocoles.
Le défi lié à la taille des signatures PQC
Les algorithmes de signature PQC normalisés à ce jour par le NIST génèrent des signatures nettement plus volumineuses que leurs équivalents classiques. Les chaînes de certificats nécessitent généralement plusieurs certificats et, par conséquent, plusieurs signatures, ce qui signifie que l'augmentation de taille s'accumule tout au long de la chaîne. Cela peut remettre en cause les hypothèses sur lesquelles reposent les protocoles existants, les tampons réseau et les systèmes de stockage.
Les signatures plus volumineuses ont également des répercussions sur les performances en aval : augmentation de la consommation de bande passante, multiplication des allers-retours dans les protocoles d'établissement de connexion et risques potentiels de déni de service lorsque des messages trop volumineux nuisent aux performances du HSM.
Se préparer à la transition
Testez d'abord les certificats PQC et hybrides dans des environnements hors production.
Vérifiez que vos autorités de certification sont en mesure d'émettre des certificats PQC et que vos chemins de validation gèrent correctement les artefacts de plus grande taille.
Prévoir la coexistence.
Pendant la période de transition, votre infrastructure devra prendre en charge simultanément les certificats classiques et les certificats PQC. Les systèmes chargés de valider les certificats doivent pouvoir traiter ces deux types de certificats sans rencontrer de dysfonctionnement.
Mettez à jour systématiquement les ancrages de confiance.
Les certificats racine et les autorités de certification intermédiaires doivent être migrés selon un calendrier coordonné, en mettant à jour les certificats finaux sans modifier la chaîne de confiance qui les précède.
Assurer la coordination avec les partenaires et les fournisseurs.
Tout système échangeant des certificats avec des tiers nécessite une harmonisation des calendriers de prise en charge des certificats PQC.
Point clé à retenir :
PKI est une condition préalable à une migration à plus grande échelle vers la cryptographie post-quantum (PQC). Il sera essentiel de commencer à préparer votre infrastructure de certificats dès maintenant.
Étape 5 : Tester, valider et déployer par phases
Ne passez jamais directement à la mise en production. Les algorithmes PQC présentent des caractéristiques de performance fondamentalement différentes de celles des algorithmes classiques, et les hypothèses qui ont prévalu pendant des décennies risquent de ne plus être valables lors de la transition.
Éléments à tester
Bande passante et latence :
Les artefacts PQC sont beaucoup plus volumineux, ce qui entraîne une utilisation accrue de la bande passante et un nombre plus important d'allers-retours dans les protocoles d'établissement de connexion. Évaluez l'impact sur les conditions spécifiques de votre réseau et les exigences de vos applications.
Débit du module HSM :
Les algorithmes de signature PQC traitent généralement l'intégralité du message en interne, ce qui peut nuire aux performances pour les messages volumineux, en particulier sur les modules HSM. Le pré-hachage peut pallier ce problème, mais ajoute à la complexité de la mise en œuvre.
Interopérabilité :
Testez les configurations PQC et hybrides avec chaque partenaire, fournisseur et système dépendant qui échange des éléments cryptographiques avec votre infrastructure. La diversité des combinaisons hybrides peut poser des défis en matière d'interopérabilité.
Validation de la chaîne de certificats :
Vérifiez que la chaîne complète, de l'autorité de certification racine au certificat final, fonctionne correctement avec les signatures PQC dans toutes les applications utilisatrices.
Déploiement progressif avec possibilité de revenir en arrière
Planifiez votre déploiement par étapes, en prévoyant des possibilités de retour en arrière explicites à chaque étape. Lorsque vous modifiez l'infrastructure de sécurité fondamentale, la possibilité de revenir en arrière n'est pas facultative : elle est indispensable.
Une architecture « crypto-agile » facilite considérablement tant le déploiement que la restauration. Grâce à cette « crypto-agilité », les algorithmes peuvent être remplacés par le biais de modifications de politique plutôt que par des modifications du code, ce qui réduit les risques et les efforts liés à chaque phase de déploiement.
Liste de contrôle de validation
Tests en environnement isolé
Valider tous les algorithmes de contrôle de qualité post-production (PQC) et toutes les configurations hybrides dans un environnement de test dédié avant toute mise en production.
Comparaison des performances de référence
Comparez les performances de PQC à celles de votre implémentation classique actuelle pour tous les indicateurs clés (latence, débit, utilisation des ressources).
Vérification de la compatibilité des partenaires
Vérifiez que les systèmes externes utilisant vos certificats ou vos données chiffrées sont capables de gérer les artefacts PQC.
Test de la procédure de restauration
Vérifiez que vous pouvez revenir sans problème aux algorithmes classiques si des problèmes surviennent lors du déploiement.
de surveillance et d'alerte
Mettre en place une surveillance continue afin de détecter toute dégradation des performances, tout échec de validation des certificats et tout problème d'interopérabilité après le déploiement.
Point clé :
Effectuez des tests approfondis, procédez à des déploiements progressifs et conservez toujours la possibilité de revenir en arrière. L'agilité cryptographique allège la charge liée aux tests, mais ne la supprime pas pour autant.
Étape 6 : Prévoir une évolution continue des algorithmes
La transition vers la cryptographie post-quantique ne s'achève pas avec le déploiement de vos premiers algorithmes résistants à l'informatique quantique. Le paysage cryptographique continuera d'évoluer, et votre feuille de route doit tenir compte de ces changements permanents.
Le paysage normatif continue d'évoluer
À ce jour, le NIST a normalisé cinq algorithmes de cryptographie post-quanta (PQC) ; d'autres algorithmes sont en cours de développement, notamment des algorithmes de signature optimisés pour différents cas d'utilisation. Chaque nouvel algorithme présentera des compromis différents en termes de taille des clés, de taille des signatures, d'efficacité et de propriétés de sécurité.
Au-delà du NIST, d’autres organismes de normalisation mènent leurs propres processus. Le BSI allemand a recommandé sa propre suite d’algorithmes de cryptographie post-quanta (PQC), comprenant notamment certains algorithmes qui n’ont pas été retenus par le NIST. La Corée, la Chine et la Russie mènent des projets de normalisation indépendants dans le but de normaliser des algorithmes destinés à être utilisés sur leur territoire. Les organisations opérant à l’échelle mondiale pourraient devoir prendre en charge plusieurs familles d’algorithmes simultanément.
Il n'existe pas d'algorithme universel
Le « meilleur » algorithme PQC pour un cas d’utilisation donné dépend fortement du hardware du contexte opérationnel. Dans les appareils aux ressources limitées ( IoT , contrôleurs embarqués, cartes à puce), les compromis entre la taille de la clé, la taille de la signature et l’efficacité de calcul peuvent avoir un impact considérable sur le débit et la viabilité. L’algorithme optimal pour un TLS dans le cloud n’est pas le même que celui adapté à une liaison de communication par satellite.
Cela signifie que le choix d'un algorithme n'est pas une décision ponctuelle. À mesure que de nouveaux algorithmes seront normalisés et que les algorithmes existants seront mieux compris, les organisations devront actualiser leurs choix.
L'agilité en matière de cryptographie : une capacité permanente
La meilleure façon de se préparer à l'évolution constante des algorithmes consiste à faire del'agilité cryptographiqueune capacité opérationnelle permanente, et non pas simplement un outil destiné à la migration initiale vers la cryptographie post-quantum (PQC). Grâce à une architecture cryptographiquement agile et à une plateforme de gestion basée sur des politiques, les composants cryptographiques peuvent être remplacés conformément aux politiques mises à jour, sans qu'il soit nécessaire de repenser les systèmes ou de réécrire le code.
Comme le souligne le NIST, « l'agilité cryptographique est une pratique essentielle qui devrait être adoptée à tous les niveaux, des algorithmes aux architectures d'entreprise ».
Point clé :
Concevez vos systèmes de manière à pouvoir s'adapter aux futures évolutions des algorithmes. La migration vers la cryptographie post-quanta (PQC) n'est pas un projet ponctuel, mais marque le début d'une démarche continue de gestion cryptographique.
Comment Keyfactor vous aider
Chaque étape de la feuille de route de migration vers le PQC correspond directement à des fonctionnalités de la plateforme Keyfactor:
Détection et inventaire (Étape 1) :
Keyfactor Agilesec propose une fonctionnalité de détection automatisée qui établit un inventaire complet des actifs cryptographiques au sein des applications, des appareils, des charges de travail dans le cloud et de l’infrastructure, vous offrant ainsi la base de visibilité sur laquelle repose l’ensemble de votre feuille de route.
PKI (Étape 4) :
EJBCA offre une prise en charge intégrée des certificats résistants à l'informatique quantique et des certificats hybrides, permettant ainsi à vos autorités de certification d'émettre dès aujourd'hui des certificats PQC. SignServer permet la signature de code à l'aide des algorithmes PQC du NIST, étendant ainsi la signature résistante à l'informatique quantique à votre chaîne software .
Déploiement par étapes (Étape 5) :
Keyfactor Command automatise la gestion du cycle de vie des certificats (renouvellement, provisionnement et révocation à grande échelle), permettant ainsi aux organisations de changer d’algorithmes cryptographiques sans interruption et de revenir en arrière si nécessaire.
Évolution en cours (Étape 6) :
Bouncy Castle Les API en Java et C# permettent dès aujourd’hui aux équipes produit d’intégrer des algorithmes de cryptographie post-quantique (PQC) dans leurs applications, tout en leur offrant la flexibilité nécessaire pour adopter de nouveaux algorithmes à mesure qu’ils sont normalisés. La gestion basée sur des politiques prend en charge les futurs changements d’algorithmes sans nécessiter de refonte de l’architecture.
Le bilan
Les organisations qui commencent dès aujourd’hui à élaborer leur feuille de route pour la migration vers la cryptographie résistante à l’informatique quantique pourront opérer cette transition à leur propre rythme. Celles qui attendront se retrouveront confrontées à des délais serrés, à des options limitées et à des risques accrus.
Les six étapes décrites dans ce guide ne constituent pas une simple liste de contrôle à suivre une fois pour toutes. Elles constituent les fondements d’une démarche de gestion cryptographique continue : commencer par assurer la visibilité, hiérarchiser les priorités en fonction des risques, choisir la stratégie de migration adaptée à chaque système, préparer votre PKI , tester et déployer par étapes, et développer les capacités opérationnelles nécessaires pour s’adapter à l’évolution du contexte.
En cryptographie, « plus tard » signifie souvent « trop tard ». La feuille de route commence dès maintenant.
