Ce schéma illustre comment une base de données chiffrée à l’aide d’une clé de données symétrique peut néanmoins rester vulnérable aux menaces quantiques via le mécanisme de clé publique servant à établir, transporter ou protéger cette clé. Il met également en évidence des dépendances souvent négligées, notamment la signature dans les processus CI/CD et l’administration SSH, où l’enjeu principal est l’authenticité plutôt que la confidentialité différée.
Une fois chaque dépendance identifiée au niveau de l’architecture, l’objectif est de parvenir à une décision de migration justifiée, plutôt qu’à une simple affirmation générique selon laquelle un système serait « prêt pour le quantique ». Il est nécessaire d’identifier les primitives menacées par l’algorithme de Shor, de distinguer l’établissement de clés des signatures, et de relier chaque primitive exposée à l’actif et à la limite de confiance qu’elle protège. En août 2024, le NIST a normalisé trois algorithmes fondamentaux de cryptographie post-quantique (PQC) : FIPS 203 ML-KEM pour l’établissement de clés, FIPS 204 ML-DSA pour les signatures numériques et FIPS 205 SLH-DSA pour les signatures sans état basées sur le hachage.
Les modules suivants permettront de développer quatre compétences pratiques :
L’agilité cryptographique désigne la capacité à remplacer des algorithmes cryptographiques, des clés et les dépendances associées sans perturbation inacceptable ni perte d’interopérabilité. Il s’agit d’une propriété du système global — incluant la configuration, la gestion des certificats, le support des fournisseurs et la négociation des protocoles — et non d’une propriété inhérente à un algorithme seul.
Quels sont les points de contact exposés à une perte future de confidentialité des données conservées, et lesquels présentent principalement un risque d’usurpation d’identité ou d’atteinte à l’intégrité après le « jour Q » (Q-Day) ? La comparaison distingue ces décisions.
Un enregistrement client chiffré dans une sauvegarde à longue durée de conservation reste illisible aujourd’hui, même si un attaquant a copié cette sauvegarde depuis un stockage d’objets il y a des années. L’attaquant n’a eu besoin ni d’un accès à la base de données ou à l’application, ni de la clé de chiffrement. Si la clé de chiffrement des données de la sauvegarde a été établie ou protégée à l’aide de la cryptographie RSA ou sur les courbes elliptiques, un futur ordinateur quantique capable d’effectuer de la cryptanalyse pourrait retrouver cette clé et exposer les données conservées. La question pour le défenseur n’est donc pas de savoir quand un terminal sera piraté, mais plutôt si les données chiffrées aujourd’hui devront encore rester confidentielles une fois que la cryptanalyse quantique sera devenue réalisable.
Le même problème se pose pour le trafic TLS capturé sur le réseau. Une session protégée par un mécanisme conventionnel d’établissement de clé publique peut préserver la confidentialité de l’identifiant customer_id=48291 pendant son exécution ; toutefois, une capture conservée pourrait être déchiffrée ultérieurement si sa protection par clé publique venait à céder face à une attaque quantique. Il s’agit de la stratégie « collecter maintenant, déchiffrer plus tard » (harvest now, decrypt later) : la collecte de données protégées en vue d’un déchiffrement ultérieur, lorsque des capacités de calcul plus puissantes seront disponibles. Le risque associé dépend de la durée de vie de la confidentialité des données, et non simplement de la date d’arrivée prévue d’un ordinateur quantique.
Q-Day
Le Q-Day désigne le moment où un ordinateur quantique capable de cryptanalyse (CRQC) pourra concrètement mettre en échec les hypothèses de sécurité à clé publique dont dépend encore un système. Pour le propriétaire d’un système, le Q-Day constitue un jalon de planification, et non une prédiction de date calendaire précise. Le NIST souligne que les estimations concernant l’échéance des CRQC varient considérablement, alors que les transitions cryptographiques nécessitent historiquement des années pour être intégrées aux produits, services et infrastructures.
Ce cours aborde cette menace de manière ciblée et précise. L’algorithme de Shor menace les opérations de cryptographie à clé publique basées sur RSA et les courbes elliptiques, utilisées pour l’établissement de clés et les signatures numériques. Cela ne signifie pas pour autant que chaque octet chiffré devient vulnérable au même degré. Le chiffrement symétrique, les fonctions de hachage, le stockage des clés, la configuration des protocoles, le cycle de vie des certificats et la rétention des données restent des facteurs déterminants pour savoir si une dépendance à la cryptographie à clé publique (vulnérable aux attaques quantiques) expose réellement un actif.
Les sauvegardes et les captures de trafic TLS n’étant que deux voies d’accès à un même système, la migration commence par l’identification de tous les points où la cryptographie à clé publique établit une relation de confiance. Dans un service type, un navigateur accède à une interface web, celle-ci appelle une API, et l’API interroge une base de données. L’architecture comprend également le stockage des sauvegardes, les accès d’administration, la signature des builds, les journaux et les intégrations externes. Un inventaire cryptographique doit consigner, pour chaque voie d’accès, le protocole, l’algorithme, la bibliothèque, le certificat, le propriétaire de la clé et la durée de vie des données associés.
TLS utilise couramment RSA ou ECC pour l’authentification et, selon la configuration du protocole déployé, pour l’établissement de clés. Les clés de signature JWT peuvent s’appuyer sur RSA ou sur des signatures à courbes elliptiques pour permettre à une API de vérifier l’origine et l’intégrité d’un jeton. Les certificats de signature de code permettent d’établir si un artefact de publication provient bien d’un éditeur autorisé. Les clés d’hôte SSH authentifient le serveur auquel les administrateurs accèdent. Ces mécanismes répondant à des objectifs de sécurité différents, leur remplacement ne saurait se résumer à une simple substitution uniforme d’algorithmes.
L’architecture ci-dessous distingue les points d’utilisation de la cryptographie à clé publique des mécanismes de protection symétrique ; c’est cette distinction qu’un inventaire doit impérativement préserver :