Sécurité post-quantique : ce qui est intercepté aujourd'hui sera lu demain

Les titres habituels sur le sujet des ordinateurs quantiques sont soit de la panique, soit de la rassurance. Les deux ne sont pas utiles. En regardant la situation avec lucidité, elle est maîtrisable : une partie du chiffrement utilisé aujourd’hui a une date d’expiration, une autre non, et la différence peut s’expliquer en une phrase. Cependant, cela devient ensuite pratique — et c’est là que se situent les vrais problèmes.

Le problème s’appelle « Intercepter maintenant, déchiffrer plus tard »

Celui qui intercepte du trafic de données chiffré aujourd’hui peut le stocker. Non pas pour le lire maintenant, mais pour le lire dès que les moyens d’y parvenir existeront. Un ordinateur quantique suffisamment puissant brise avec l’algorithme de Shor précisément les méthodes qui sécurisent aujourd’hui l’échange de clés : RSA, Diffie-Hellman et les courbes elliptiques.

L’attaque a donc lieu dans le futur, mais la collecte des données a lieu maintenant. Pour l’évaluation des risques, cela signifie : ce n’est pas la date du premier ordinateur quantique qui compte, mais la question de savoir combien de temps les données qui transitent aujourd’hui sur la ligne doivent rester protégées. Un contrat d’assurance maladie, un plan de construction ou un mandat d’avocat ne sont pas moins confidentiels dans dix ans qu’aujourd’hui.

La formulation classique de cela est l’inégalité de Mosca : si le temps pendant lequel vos données doivent rester secrètes, plus le temps que prend votre transition, est supérieur au temps avant le premier ordinateur quantique capable — alors vous êtes en retard. Il n’est pas nécessaire de connaître la date de l’ordinateur quantique pour cela. Il suffit de savoir que votre propre transition prend des années.

Ce qui est concerné — et ce qui ne l’est pas

Ici, la précision est utile, car elle fait gagner du temps.

De ces trois lignes découle toute la priorisation : l’échange de clés est le chantier, tout le reste a le temps.

La solution existe — et elle est hybride

Les algorithmes sont standardisés depuis août 2024. Le NIST a publié avec FIPS 203 ML-KEM, une méthode d’échange de clés basée sur les treillis, qui selon l’état actuel des connaissances résiste également aux ordinateurs quantiques.

L’essentiel est la manière dont on l’utilise : hybride. La méthode classique reste en place, la nouvelle s’ajoute par-dessus, et la clé de session est générée à partir des deux. Si l’une des deux méthodes tombe, l’autre continue de protéger. Ce n’est pas de l’hésitation, mais une prudence justifiée — les nouvelles méthodes sont nettement plus jeunes et ont été attaquées publiquement pendant une durée beaucoup plus courte que RSA ou X25519. Le BSI allemand recommande précisément pour cette raison l’utilisation exclusivement hybride. On ne s’attache donc pas un nouveau risque avec la transition, mais on ajoute une seconde couche par-dessus.

En pratique, les méthodes s’appellent ainsi — les deux sont disponibles, les deux sont éprouvées :

Où cela échoue en pratique

Si les algorithmes et les standards sont prêts — pourquoi la transition est-elle alors un travail ? Pour cinq raisons, qui n’ont rien à voir avec la cryptographie.

1. Personne ne sait où se trouve la crypto. Ce n’est pas le serveur web qui est le problème, mais la sauvegarde qui se réplique quelque part la nuit, l’agent de supervision, la connexion de base de données entre deux centres de données, l’appareil en production avec l’interface web de 2014. La partie la plus difficile d’une migration PQ est une liste d’inventaire complète — pas le choix de l’algorithme.
2. La version du logiciel décide, pas la volonté. ML-KEM n’existe dans OpenSSH qu’à partir de la version 9.9. Ubuntu 24.04 fournit 9.6, Debian 13 fournit en revanche OpenSSH 10. Celui qui écrit le nouvel algorithme en dur dans la configuration fait tomber chaque serveur qui ne le connaît pas : le service refuse de démarrer à cause d’un nom inconnu dans la configuration. Pour un serveur SSH, cela signifie dans le pire cas la perte de l’accès.
3. Les anciens systèmes ne le peuvent jamais. Dans presque tout environnement organique, il y a un système dont le logiciel ne recevra jamais une version compatible PQ — parce que l’application dessus n’est pas migrable, parce que le fabricant n’existe plus ou parce qu’un processus de certification en dépend. Ces systèmes ne disparaissent pas parce qu’on rédige une directive. Ils ont besoin d’une classification : quoi y fait-on tourner, encore pour combien de temps, et quelle couche de protection est placée devant en attendant ?
4. Imposer brise des choses que personne n’a en tête. Celui qui désactive les méthodes classiques n’exclut pas seulement les attaquants, mais aussi chaque client trop ancien — l’agent de sauvegarde, le runner CI, la supervision. Ces connexions ne tombent pas rarement immédiatement. Elles tombent quand on a besoin de la sauvegarde.
5. Le piège le plus trompeur : PQ est configuré, mais n’est jamais utilisé. Le client et le serveur s’accordent sur la première entrée commune de leur liste d’algorithmes. Si la méthode PQ est en troisième position et une classique avant, la classique est utilisée — à chaque fois. La configuration semble correcte, un rapport de contrôle signale « présent », et en réalité l’entrée est un poids mort. Ce n’est pas la présence qui compte, mais l’ordre.

Comment nous résolvons cela

Notre propre infrastructure fonctionne via des baselines de durcissement automatisées : un script définit le niveau de sécurité d’un serveur, un second le mesure indépendamment. Le principe directeur derrière est plus ancien que le sujet quantique :

Le durcissement sans vérification est de l’espoir.

Nous avons vécu une fois qu’un fichier de configuration apparemment exemplaire n’avait aucun effet, parce qu’un autre fichier le surclassait. Depuis, nous ne vérifions jamais si un paramètre est quelque part, mais toujours ce que le service fait réellement.

Sur cette base, notre transition ressemble à ceci :

La liste des algorithmes est construite à l’exécution

Le script demande au serveur quelles méthodes sa version SSH connaît, et prend la meilleure combinaison disponible — ML-KEM, s’il est présent, sinon la méthode hybride plus ancienne. Un serveur avec Debian 13 reçoit ainsi automatiquement ML-KEM, un avec Ubuntu 24.04 continue sans changement, et lors de la prochaine mise à niveau de la distribution, la configuration suit d’elle-même. Un script pour tous les systèmes, sans vérifications de versions que quelqu’un devrait maintenir. Si le service refuse malgré tout la nouvelle configuration, elle est automatiquement annulée — pour une configuration SSH, c’est la différence entre un avertissement et une panne serveur.

On vérifie l’ordre, pas la présence

Le passage de contrôle signale un problème si une méthode classique est avant la méthode PQ — exactement le piège du point 5.

On contre-vérifie ce qui se passe réellement

Le passage de contrôle établit une vraie connexion au service, qui n’autorise que la méthode PQ, et évalue sur quoi les deux parties se sont accordées. Pas « aucune erreur » — cela serait inutile, car même un service planté ne signale pas d’erreur. Mais la confirmation enregistrée que l’échange a effectivement eu lieu de manière post-quantique.

La coupure dure est un interrupteur, pas un standard

Désactiver complètement les méthodes classiques est possible, mais c’est une décision consciente par système et non le réglage par défaut. Le bon ordre est : d’abord hybride partout, puis mesurer, puis recenser les anciens clients restants — et seulement ensuite désactiver.

Le plus grand levier ne se trouve pas chez SSH

Le trafic SSH circule chez nous exclusivement dans les réseaux internes et via VPN. Celui qui veut l’intercepter est déjà dans le réseau. Le trafic qui peut réellement être collecté à grande échelle est le trafic HTTPS public à la périphérie du réseau. Là, la capacité PQ dépend de la version de la bibliothèque TLS — chez les images conteneur courantes aujourd’hui, la limite se situe précisément entre les deux : une version le peut, la précédente non. Le chemin vers cela passe donc par une mise à jour d’image et une ligne de configuration, pas par un projet.

Certaines choses sont déjà sûres, sans qu’on le remarque

Notre VPN d’administration utilise WireGuard avec un échange de clés classique — mais avec une clé pré-partagée individuelle par appareil. Cette clé ne passe jamais sur la ligne, et elle rend le tunnel résistant aux quantiques. Un détail de la procédure d’installation, qui a été mis en place initialement pour une autre raison et qui est aujourd’hui par hasard exactement juste. On ne trouve de tels points que si l’on parcourt le parc de manière systématique — ce qui nous ramène au point 1.

Ce que nous recommandons

Post-Quantique n’est pas un projet que l’on démarre et termine, mais une propriété que l’on intègre dans le standard avec lequel les systèmes sont déployés et vérifiés. Celui qui commence aujourd’hui devrait procéder dans cet ordre :

1. Prendre l’inventaire. Quelles connexions transportent des données qui seront encore protégées dans dix ans ? C’est la seule question qui détermine la priorité.
2. Les périphéries d’abord. Tout ce qui passe par Internet ouvert, avant l’interne.
3. Passer en hybride, ne pas remplacer. La protection d’aujourd’hui reste préservée.
4. Mesurer l’effet, ne pas lire la configuration. L’ordre des algorithmes décide si la transition a réellement un effet.
5. Nommer les anciens systèmes. Ce qui ne sera jamais compatible PQ doit figurer sur une liste avec date d’expiration — et en attendant derrière des couches de protection supplémentaires.
6. Imposer seulement à la fin. Et alors avec un chemin de retour.

L’effort pour les quatre premiers points est maîtrisable si l’environnement est géré de manière automatisée. Chez nous, il s’agissait d’ajouts aux scripts existants, pas d’une nouvelle infrastructure.

Nous conseillons et accompagnons les entreprises dans précisément ce recensement et cette transition — de l’inventaire au durcissement des systèmes jusqu’à la vérification continue et automatisée. Contactez-nous si vous souhaitez savoir où en sont vos connexions.