TNFL : la menace quantique qui vise la confiance numérique
Publié le 27/7/2026
Auteur : Arnaud DUFOURNET, Directeur Marketing & Expérience Client
Pendant longtemps, la menace quantique la plus connue a été HNDL (Harvest Now, Decrypt Later), ou « collecter maintenant, déchiffrer plus tard ». Le principe est simple : des attaquants interceptent aujourd’hui des données chiffrées, les stockent, puis attendent l’arrivée d’un ordinateur quantique capable de casser les algorithmes actuels pour en révéler le contenu.
Mais cette vision est incomplète. La menace la plus insidieuse ne vise pas seulement la confidentialité des données : elle cible aussi leur intégrité, leur authenticité et la non-répudiation. C’est là qu’intervient TNFL, pour Trust Now, Forge Later, que l’on peut traduire par « faire confiance aujourd’hui, falsifier plus tard ».

Qu’est-ce que TNFL ?
TNFL désigne un scénario dans lequel un attaquant exploite, à terme, la puissance d’un ordinateur quantique pour forger des signatures numériques valides à partir de clés publiques ou de signatures collectées aujourd’hui.
Contrairement à HNDL, TNFL ne repose pas sur l’interception massive de secrets. Il s’attaque au cœur du modèle de confiance numérique : signatures électroniques, certificats TLS, signatures de code, certificats racine, artefacts logiciels et documents juridiques ou financiers signés.
En d’autres termes, HNDL casse le secret. TNFL casse la confiance.
Comment fonctionne TNFL ?
Une attaque de type TNFL peut se résumer en quatre étapes.
1. Collecter aujourd’hui les éléments de confiance
Les attaquants n’ont pas besoin de voler une clé privée tout de suite. Ils peuvent simplement conserver des certificats publics, des signatures légitimes, des chaînes de certification ou des artefacts signés. Ces éléments sont accessibles publiquement ou circulent dans les systèmes de production, les dépôts logiciels, les terminaux, les firmwares et les archives.
2. Attendre la capacité quantique
Lorsque des ordinateurs quantiques deviendront assez puissants, certains algorithmes asymétriques classiques comme RSA et ECC deviendront vulnérables. L’algorithme de Shor permettra alors, dans le scénario redouté, de retrouver une clé privée à partir d’une clé publique correspondante.
3. Forger une identité numérique crédible
Avec la clé privée obtenue, l’attaquant peut signer de faux documents, de fausses mises à jour logicielles, de faux certificats ou de faux messages en se faisant passer pour une entité légitime. Le problème n’est pas seulement la fraude technique : c’est la possibilité de réécrire le passé cryptographique.
4. Détruire la non-répudiation
C’est ici que TNFL devient particulièrement grave. Si une signature forgée est cryptographiquement valide, il devient très difficile de prouver qu’elle est frauduleuse sur le plan technique. Dans certains contextes, la victime (une entreprise ou un particulier) peut perdre sa capacité à démontrer qu’elle n’est pas à l’origine de l’action signée.
Pourquoi TNFL est si préoccupant ?
TNFL ne menace pas seulement des fichiers ou des communications. Il menace les mécanismes mêmes qui permettent aux systèmes numériques de faire confiance à une source, à un logiciel ou à un document.
Les conséquences peuvent être majeures dans trois domaines.
- La chaîne logistique logicielle : une mise à jour malveillante pourrait être signée comme si elle provenait d’un éditeur légitime, et donc installée sans méfiance par les systèmes de production.
- Les autorités de certification : si une clé racine ou une sous-autorité venait à être compromise rétroactivement, un attaquant pourrait alors émettre de faux certificats parfaitement valides pour n’importe quel site web ou créer de fausses sous-autorités. C’est toute une portion de l’écosystème de confiance TLS qui pourrait être fragilisée.
- Les documents juridiques et financiers : un contrat, un ordre de paiement ou une validation réglementaire pourrait être falsifié avec une apparence d’authenticité difficile à contester.
Le risque n’est donc pas seulement technique. Il est aussi juridique, opérationnel et réputationnel.
Comment s’en protéger ?
TNFL ne casse pas seulement un algorithme : il remet en cause la fiabilité à long terme des signatures. Dans les environnements critiques, une signature ne prouve pas seulement l’origine d’un document, elle fonde une chaîne de responsabilité. Si cette chaîne peut être reconstruite ou imitée a posteriori, la confiance numérique devient vulnérable à une falsification rétrospective. C’est pourquoi TNFL est décrit comme une crise de l’authenticité numérique autant qu’une menace cryptographique.
Etant donné l’enjeu, la réponse ne peut pas se limiter à “passer au quantique plus tard”. Il faut dès à présent repenser la durée de vie de la confiance numérique, la rotation des clés et l’agilité cryptographique.
1. Cartographier les actifs cryptographiquesLa première priorité consiste à établir un inventaire précis de tous les usages cryptographiques : certificats, clés de signature, bibliothèques, algorithmes, systèmes embarqués et dépendances logicielles. Une approche de type CBOM (Cryptographic Bill of Materials) aide à identifier où se trouvent les points de fragilité.
L’objectif est simple : savoir où RSA, ECC et les mécanismes hérités sont utilisés, et mesurer leur exposition dans le temps.
2. Réduire la durée de vie des certificats
Plus une clé ou un certificat reste valide longtemps, plus sa valeur historique augmente pour un attaquant futur. Réduire les cycles de vie limite cette fenêtre de risque.
Dans la pratique, cela signifie raccourcir fortement les durées de validité, automatiser le renouvellement et supprimer les certificats trop anciens dès que possible. La logique est de réduire au maximum la durée pendant laquelle un artefact signé peut être exploité contre vous plus tard.
Dans cet esprit, le CA/Browser Forum1 a entériné en avril 2025 la réduction drastique de la durée de vie des certificats TLS publics selon un calendrier très précis :
- Avant mars 2026 : La durée maximale est de 398 jours (~13 mois).
- À partir du 15 mars 2026 : Réduction à 200 jours.
- À partir du 15 mars 2027 : Réduction à 100 jours.
- À partir du 15 mars 2029 : Réduction finale à 47 jours (ainsi qu’une réutilisation des validations de domaine limitée à 10 jours).
3. Préparer la migration vers la PQC
La cryptographie post-quantique doit être intégrée dans la feuille de route dès maintenant. Les standards du NIST pour les signatures post-quantiques, comme ML-DSA, constituent une base sérieuse pour anticiper la transition.
Dans bien des cas, une stratégie hybride est pertinente : elle combine un algorithme classique et un algorithme post-quantique afin de conserver la compatibilité tout en assurant une protection contre les tentatives de falsification. C’est souvent la meilleure approche pendant la phase de migration.
4. Construire l’agilité cryptographique
L’erreur serait de devoir réécrire tout le code à chaque changement d’algorithme. Les organisations doivent s’appuyer sur des interfaces crypto unifiées et des outils de gestion du cycle de vie des certificats (CLM) qui permettent de remplacer un algorithme par un autre via une simple modification de configuration. En cas de rupture technologique quantique, l’entreprise doit être capable de re-signer l’intégralité de son infrastructure en quelques heures, et non en plusieurs mois.
HNDL menace ce que nous voulons cacher. TNFL menace ce que nous voulons prouver. Continuer à signer nos actifs numériques critiques avec des clés asymétriques classiques, c’est léguer nos identités, nos certificats et nos preuves d’authenticité aux cybercriminels de l’ère quantique. La menace TNFL n’est pas une fiction : c’est déjà un enjeu de gouvernance.
1 Le CA/Browser Forum (ou CA/B Forum) est une organisation internationale à but non lucratif regroupant :
Les Éditeurs de navigateurs web et de systèmes d’exploitation : les acteurs qui développent les logiciels vérifiant ces certificats (ex. Google/Chrome, Apple/Safari, Mozilla/Firefox, Microsoft).
Les Autorités de Certification (CA) : les organismes qui émettent les certificats numériques (ex. DigiCert, Let’s Encrypt, Sectigo).