BSI TR-02102-1 et cryptographie post-quantique : les recommandations 2026

La BSI TR-02102-1 est la directive technique sur les mécanismes cryptographiques publiée par l'Office fédéral allemand de la sécurité des technologies de l'information (BSI, Bundesamt für Sicherheit in der Informationstechnik). La version 2026-01, datée du 23 janvier 2026, recommande l'accord de clé post-quantique hybride, considère l'accord de clé classique utilisé seul comme recommandé uniquement jusqu'à la fin de 2031 (fin 2030 lorsque les besoins de protection sont très élevés) et fixe des clés RSA d'au moins 3000 bits. Il s'agit d'une directive technique, et non d'une loi. Cet article montre comment traduire ces trois points en une configuration TLS que vous pouvez tester.

Ce qu'est la TR-02102-1, et ce qu'elle n'est pas

La TR-02102-1 liste les mécanismes cryptographiques que le BSI juge adaptés, en associant à chacun une longueur de clé et un horizon temporel. Il s'agit de recommandations. À elle seule, elle ne crée aucune obligation pour une entreprise privée. Elle ne devient contraignante que lorsqu'un autre instrument la rend contraignante : un contrat avec un client allemand, une règle sectorielle, une exigence de marché public ou une politique cryptographique interne qui la cite. Cette dernière phrase reflète notre lecture de l'usage du document en pratique, et non une citation de la directive.

Il en découle deux conséquences pour les équipes qui servent des clients allemands. D'abord, citez toujours la version. Tous les chiffres de cet article proviennent de la version 2026-01, et vous devriez les reprendre dans la version en vigueur au moment de votre audit. Ensuite, un questionnaire fournisseur qui vous demande si vous êtes conforme à la TR-02102-1 cherche en réalité à savoir si votre configuration déployée correspond aux mécanismes recommandés et à leurs horizons. Les jalons datés sont résumés sur notre page de référence BSI TR-02102-1, et la directive elle-même est publiée par le BSI au format PDF : BSI TR-02102-1.

La position de la version 2026-01 sur l'accord de clé

La directive recommande l'accord de clé post-quantique hybride. Hybride signifie combiner un accord de clé classique, comme le Diffie-Hellman sur courbes elliptiques (ECDH), avec un mécanisme d'encapsulation de clé (KEM) post-quantique, de sorte que la clé de session reste sûre tant que l'un des deux composants résiste. Dans TLS 1.3, le composant post-quantique aujourd'hui en production est ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), normalisé par le NIST sous la référence FIPS 203 le 13 août 2024.

Deux dates comptent. L'accord de clé classique utilisé seul n'est recommandé que jusqu'à la fin de 2031. Lorsque les besoins de protection sont très élevés, cette échéance devient la fin de 2030. Ce sont des recommandations assorties d'un horizon, et non une date d'arrêt imposée par un régulateur.

L'accord de clé passe en premier pour une raison physique, et non réglementaire. Le trafic TLS enregistré n'est protégé que par l'échange de clés qui a produit ses clés de session. Un attaquant qui stocke aujourd'hui des données chiffrées peut les déchiffrer plus tard si l'échange de clés devient cassable, un schéma connu sous le nom de « collecter maintenant, déchiffrer plus tard » (harvest now, decrypt later, HNDL). Les signatures et les certificats n'ont pas cette propriété : une signature vérifiée aujourd'hui ne peut pas être falsifiée rétroactivement. C'est pourquoi l'horizon de l'accord de clé arrive avant toute migration des signatures.

RSA d'au moins 3000 bits, et ce que cela ne vous apporte pas

La version 2026-01 fixe une longueur minimale de clé RSA de 3000 bits. En pratique, les autorités de certification, les modules matériels de sécurité (HSM) et les bibliothèques TLS travaillent avec des clés RSA de 3072 bits, ce qui respecte le seuil et bénéficie d'une large prise en charge. Vérifier la longueur de clé d'un certificat déployé tient en une commande.

openssl x509 -in server.crt -noout -text | grep -i public-key

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key
openssl req -new -key server.key -out server.csr

Soyez précis sur ce que cela permet d'obtenir. Une clé RSA plus longue élève le niveau de sécurité classique. Elle ne rend pas la clé résistante au quantique : RSA, ECDSA, EdDSA, ECDH, le Diffie-Hellman sur corps finis et DSA sont tous cassés par l'algorithme de Shor sur un ordinateur quantique suffisamment puissant, quelle que soit la taille de clé. Le plancher de 3000 bits et la recommandation d'accord de clé hybride répondent à deux problèmes différents, et satisfaire l'un ne satisfait pas l'autre.

À titre de comparaison, le NIST IR 8547 propose de déprécier après 2030 les algorithmes vulnérables au quantique au niveau de sécurité de 112 bits, ce qui inclut RSA-2048, et d'interdire tous les algorithmes à clé publique vulnérables au quantique après 2035. Ce document est un projet public initial publié le 12 novembre 2024, et il reste un projet : NIST IR 8547 (ipd). Un minimum allemand de 3000 bits et un projet américain de dépréciation des clés de 2048 bits vont dans la même direction, à partir de deux textes différents aux statuts différents.

Traduire la recommandation en configuration TLS

La directive recommande un mécanisme, l'accord de clé hybride. Le choix du groupe TLS 1.3 concret relève d'une décision d'implémentation, et ce qui suit est notre correspondance pratique, et non une citation. Les groupes hybrides enregistrés auprès de l'IANA sont X25519MLKEM768 (codepoint 0x11EC, 4588), SecP256r1MLKEM768 (0x11EB, 4587) et SecP384r1MLKEM1024 (0x11ED, 4589), listés dans le registre IANA des paramètres TLS. Leur utilisation dans TLS 1.3 est décrite dans la RFC 10024 (août 2026). Les versions actuelles de Chrome, Edge et Firefox proposent déjà X25519MLKEM768 par défaut : l'activer côté serveur modifie donc immédiatement ce que négocient les navigateurs réels.

Étape 1 : vérifier que la bibliothèque prend en charge les groupes

OpenSSL 3.5 ou une version ultérieure est nécessaire pour les groupes TLS ML-KEM dans OpenSSL. Vérifiez-le avant de modifier toute configuration serveur.

openssl version
openssl list -tls-groups | grep -i mlkem

Étape 2 : proposer le groupe hybride en premier, conserver un repli classique

L'ordre compte : le groupe hybride vient en premier, les groupes classiques restent derrière lui afin que les clients plus anciens puissent toujours se connecter. Ne supprimez jamais le repli classique dans la même modification.

# nginx, built against OpenSSL 3.5 or later
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

# Apache httpd with mod_ssl, OpenSSL 3.5 or later
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1

Les noms des directives et leur prise en charge diffèrent selon les distributions et selon les compilations d'une même version de serveur : vérifiez donc sur votre propre paquet plutôt que de le supposer. Les recettes complètes pour nginx, Apache, HAProxy et Caddy figurent dans notre guide activer ML-KEM sur les serveurs web courants. Testez en préproduction avant la production.

Étape 3 : vérifier ce qui est réellement négocié

openssl s_client -connect example.de:443 -tls1_3 -groups X25519MLKEM768 </dev/null | grep -i negotiated

Une poignée de main réussie affiche le groupe négocié. Répétez le même test sans le groupe hybride pour confirmer que les clients classiques se connectent toujours.

L'horizon allemand comparé aux autres calendriers

Les dates allemandes n'existent pas isolément. Si vous servez des clients dans plusieurs pays, c'est l'horizon applicable le plus proche qui pilote le plan.

Les preuves qu'un client ou un auditeur allemand demandera

NIS2, Directive (EU) 2022/2555, Article 21(2)(h), exige des politiques et des procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement. Pour les entités financières, les normes techniques de réglementation de DORA, règlement délégué (EU) 2024/1774 de la Commission, Article 6, exigent une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions pour mettre à jour ou changer de technologie cryptographique en fonction de l'évolution de la cryptanalyse. Aucun de ces textes ne nomme d'algorithmes post-quantiques.

Notre interprétation, clairement présentée comme telle : nommer la TR-02102-1 et sa version dans cette politique, avec les mécanismes que vous acceptez et l'horizon que vous appliquez, est une manière pratique de montrer que la politique s'appuie sur une référence reconnue et dispose d'un déclencheur de révision. Gardez des artefacts simples et datés : la politique elle-même, un inventaire des points de terminaison TLS avec leurs groupes négociés et la taille de clé de leurs certificats, et un résultat de scan par point de terminaison. Notre page sur NIS2 Article 21(2)(h) détaille ce que demande la directive. Cet article est fourni à titre d'information et ne constitue pas un conseil juridique.

Prochaine étape : vérifier ce que vos serveurs négocient aujourd'hui

Avant de rédiger un plan, mesurez l'état actuel. Scannez votre domaine avec PQC Status pour voir quelles versions de TLS, quels groupes d'accord de clé et quels algorithmes de certificat votre serveur propose réellement, y compris si un groupe ML-KEM hybride est négocié. Un scan décrit uniquement la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité. Utilisez le résultat comme première ligne de votre inventaire, puis activez le groupe hybride en préproduction, conservez le repli classique et consignez l'état avant et après pour chaque point de terminaison.