Die ANSSI, die französische Behörde für Cybersicherheit (Agence nationale de la sécurité des systèmes d'information), verlangt von Organisationen nicht, klassische Kryptografie durch Post-Quanten-Kryptografie zu ersetzen. Sie verlangt beides gleichzeitig. Hybridisierung, also ein Schlüsselaustausch, bei dem der Sitzungsschlüssel sowohl von einem klassischen Algorithmus als auch von einem post-quantischen Key Encapsulation Mechanism (KEM) abhängt, ist in dem Bereich verpflichtend, den die ANSSI reguliert. Außerhalb dieses Bereichs veröffentlicht die ANSSI Empfehlungen und stellt ausdrücklich fest, dass diese Empfehlungen noch keine regulatorischen Pflichten sind.
Was die ANSSI unter Hybridisierung versteht
Ein hybrider Handshake führt zwei Schlüsselvereinbarungen durch und kombiniert beide gemeinsamen Geheimnisse zum Sitzungsschlüssel. Ein Angreifer muss beide brechen, um den Datenverkehr wiederherzustellen. Dieses Design adressiert zwei unterschiedliche Bedenken zugleich. Die klassische Hälfte bewahrt die Garantien aus zwei Jahrzehnten Analyse und gut auditierter Implementierungen wie X25519 oder ECDH auf NIST-Kurven. Die post-quantische Hälfte, in der Praxis ML-KEM, standardisiert vom NIST in FIPS 203 am 13. August 2024 (csrc.nist.gov), beseitigt das Risiko von Harvest now, decrypt later (HNDL), bei dem ein Angreifer verschlüsselten Datenverkehr heute aufzeichnet und Jahre später entschlüsselt. Aufgezeichneter Datenverkehr ist ausschließlich durch den Schlüsselaustausch geschützt. Deshalb wird zuerst der Schlüsselaustausch migriert, Signaturen und Zertifikate können später folgen.
Auf Protokollebene ist Hybridisierung schlicht eine Named Group. Die IANA hat X25519MLKEM768 (Codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) und SecP384r1MLKEM1024 (0x11ED) für TLS 1.3 registriert (IANA TLS parameters), und RFC 10024 (August 2026) spezifiziert hybride post-quantisch-klassische Schlüsselvereinbarungsmechanismen für TLS 1.3 (rfc-editor.org). Aktuelle Versionen von Chrome, Edge und Firefox bieten X25519MLKEM768 standardmäßig an, sodass die serverseitige Aktivierung für Nutzer in der Regel unsichtbar bleibt. Für SSH hat OpenSSH mlkem768x25519-sha256 in Version 9.9 (19. September 2024) eingeführt und in Version 10.0 (9. April 2025) zur Standard-Schlüsselvereinbarung gemacht; Version 10.1 (6. Oktober 2025) gibt eine Warnung aus, wenn eine Verbindung eine nicht post-quantische Schlüsselvereinbarung aushandelt (OpenSSH release notes).
Wo Hybridisierung Pflicht ist und wo sie eine Empfehlung bleibt
Die Anforderung der ANSSI ist in dem Bereich verbindlich, den sie verwaltet, wie in ihrer Post-Quanten-FAQ beschrieben (cyber.gouv.fr):
- Produktqualifizierung: Sicherheitsprodukte, die eine ANSSI-Qualifizierung besitzen oder anstreben.
- Diffusion Restreinte (DR): Informationssysteme der französischen Einstufung für eingeschränkt zugängliche Informationen und die Produkte, die sie schützen.
- SAIV und SIIV: die Sektoren von vitaler Bedeutung und ihre lebenswichtigen Informationssysteme.
Überall sonst handelt es sich um eine Empfehlung. Ein französisches Unternehmen, das keine qualifizierten Produkte vertreibt, keine Informationen der Stufe Diffusion Restreinte verarbeitet und kein Betreiber von vitaler Bedeutung ist, ist heute nicht an die Post-Quanten-Doktrin der ANSSI gebunden, und die ANSSI sagt dies selbst. Diese Einschränkung ist wichtig, wenn Sie eine Roadmap erstellen: Stellen Sie die Vorgaben der ANSSI Ihrem Vorstand nicht als gesetzliche Frist dar, wenn sie keine ist. Sie können dennoch an andere Texte gebunden sein, die nichts über Quantencomputer, aber alles über den Wechsel von Algorithmen sagen: DORA Artikel 6 der Delegierten Verordnung (EU) 2024/1774 der Kommission verlangt eine Leitlinie für Verschlüsselung und kryptografische Kontrollen, einschließlich Bestimmungen zur Aktualisierung oder Änderung der kryptografischen Technologie auf Grundlage von Entwicklungen in der Kryptoanalyse (EUR-Lex), und NIS2 Art. 21(2)(h) verlangt Konzepte und Verfahren für den Einsatz von Kryptografie (EUR-Lex). Unsere Lesart, ausdrücklich als Interpretation und nicht als Anforderung eines der beiden Texte gekennzeichnet: Ein Plan für hybriden Schlüsselaustausch ist eine glaubwürdige Möglichkeit zu zeigen, dass eine solche Leitlinie gelebt wird und nicht nur dekorativ ist. Dieser Artikel informiert über veröffentlichte Vorgaben und stellt keine Rechtsberatung dar.
Die Termine der ANSSI
Zwei Signale bestimmen die Beschaffung in Frankreich. Die ANSSI strebt an, Post-Quanten-Kryptografie ab 2027 für Produkte zu verlangen, die in die Qualifizierung eintreten, und sie ist der Auffassung, dass es nach 2030 nicht mehr vernünftig sein wird, Produkte ohne Post-Quanten-Kryptografie zu kaufen. Das zweite Signal ist eine Empfehlung und kein Verbot, aber ein deutlicher Hinweis für jeden mehrjährigen Vertrag, der jetzt unterzeichnet wird. Die vollständige, datierte Übersicht finden Sie auf unserer Seite zur ANSSI-Doktrin.
| Punkt | Position der ANSSI | Rechtsnatur |
|---|---|---|
| Hybrider Schlüsselaustausch im regulierten Bereich | Bereits heute verlangt (Qualifizierung, DR, SAIV und SIIV) | Pflicht innerhalb dieses Bereichs |
| Post-Quanten-Kryptografie für Produkte, die in die Qualifizierung eintreten | Ziel ab 2027 | Erklärtes Ziel der Behörde |
| Kauf von Produkten ohne Post-Quanten-Unterstützung nach 2030 | Als nicht vernünftig angesehen | Empfehlung |
| Wahl der Parametersätze | Höhere Sicherheitsstufen bevorzugen, soweit die Rahmenbedingungen es erlauben | Empfehlung |
Diese Termine liegen nah am europäischen Zeitplan: Die EU Coordinated Implementation Roadmap v1.1, veröffentlicht am 23. Juni 2025, sieht ein kryptografisches Inventar und nationale Roadmaps bis Ende 2026 vor, die Migration von Anwendungsfällen mit hohem Risiko bis Ende 2030 und von Anwendungsfällen mit mittlerem Risiko bis Ende 2035 (Europäische Kommission). Diese Roadmap ist eine koordinierte Orientierung für die Mitgliedstaaten und keine Verordnung, die Unternehmen bindet; unsere Roadmap-Seite führt die Meilensteine mit ihrem jeweiligen Status. Die BSI TR-02102-1, eine Technische Richtlinie, weist in dieselbe Richtung: Version 2026-01 empfiehlt hybride post-quantische Schlüsselvereinbarung und empfiehlt eine rein klassische Schlüsselvereinbarung nur noch bis Ende 2031 bzw. bis Ende 2030 bei sehr hohem Schutzbedarf.
Höhere Sicherheitsstufen, wo möglich
ML-KEM hat drei Parametersätze: ML-KEM-512, ML-KEM-768 und ML-KEM-1024. Die ANSSI bevorzugt die höheren Sicherheitsstufen, sofern Performance und Interoperabilität es zulassen. In der Praxis bedeutet das für öffentliche Webdienste X25519MLKEM768 als interoperable Basis, weil Browser diese Gruppe heute anbieten, während SecP384r1MLKEM1024 Verbindungen vorbehalten bleibt, bei denen beide Endpunkte unter Ihrer Kontrolle stehen und die zusätzlichen Handshake-Bytes akzeptabel sind. Die NSA verfolgt in einem anderen Rahmen eine vergleichbare Richtung: CNSA 2.0, das ausschließlich für National Security Systems der USA gilt, spezifiziert ML-KEM-1024, ML-DSA-87 und AES-256.
Zwei Vorbehalte. Ein höherer Parametersatz ist nie ein Grund, auf die klassische Hälfte zu verzichten: Eine reine ML-KEM-Gruppe wie MLKEM768 erfüllt keine Hybridisierungsanforderung. Und vorstandardisierte Kyber-Gruppen, insbesondere X25519Kyber768Draft00 (Codepoint 0x6399), sind veraltet und müssen durch die ML-KEM-Gruppen ersetzt werden, statt als Fallback beibehalten zu werden.
Was Sie einsetzen und wie Sie es prüfen
Prüfen, was Sie heute aushandeln
Beginnen Sie rein lesend. ML-KEM-Gruppen in OpenSSL erfordern OpenSSL 3.5 oder neuer. Prüfen Sie daher zuerst die Version und fragen Sie dann bei einem Server eine bestimmte Gruppe an.
openssl version
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>/dev/null \
| grep -i 'Negotiated TLS1.3 group'
ssh -Q kex | grep mlkem
Bleibt die Zeile zur Gruppe leer oder fällt sie auf X25519 zurück, ist auf dem Server keine hybride Gruppe aktiviert. Setzen Sie serverseitig die hybride Gruppe an die erste Stelle und eine klassische Gruppe dahinter, damit ältere Clients weiterhin eine Verbindung aufbauen können, und testen Sie in einer Staging-Umgebung vor der Produktion. Bei nginx, gebaut gegen OpenSSL 3.5 oder neuer, lautet die Direktive:
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
Die Syntax unterscheidet sich zwischen Webservern und Versionen. Folgen Sie daher den serverspezifischen Hinweisen in unserem Leitfaden zur Aktivierung von ML-KEM auf nginx, Apache, HAProxy und Caddy, statt eine einzige Direktive überall zu kopieren.
Nachweise, die Sie aufbewahren sollten
Ob die Regeln der ANSSI für Sie verbindlich sind oder nicht: Die Unterlagen, die ein Auditor oder ein Auftraggeber aus dem öffentlichen Sektor anfordern wird, sind dieselben:
| Frage, die Ihnen gestellt wird | Vorzulegender Nachweis |
|---|---|
| Wo befindet sich quantenanfällige Kryptografie in Ihren Systemen | Kryptografisches Inventar, pro Dienst und pro Protokoll, mit Verantwortlichen |
| Was handeln Ihre öffentlichen Endpunkte aus | Datierte Scan-Ergebnisse pro Domain, mit erfasster ausgehandelter Gruppe |
| Wie wechseln Sie den Algorithmus, wenn sich die Vorgaben ändern | Verschlüsselungsleitlinie mit benanntem Auslöser, verantwortlicher Person und Rollback-Plan |
| Was haben Sie von Lieferanten verlangt | Beschaffungsklausel, die hybriden Schlüsselaustausch fordert, mit Lieferdatum |
Halten Sie für die zweite Zeile den Namen der Gruppe fest, nicht ein Bestanden oder Nicht bestanden: Ein ausgehandeltes X25519MLKEM768 ist eine Tatsache, die ein Auditor erneut überprüfen kann.
Nächster Schritt: erst messen, dann planen
Die Doktrin der ANSSI lässt sich an einem Nachmittag lesen. Um zu wissen, welche Ihrer eigenen Dienste bereits eine hybride Gruppe anbieten, braucht es eine Messung. Sie können Ihre Domain kostenlos mit PQC Status scannen, um TLS-Versionen, Cipher Suites und Zertifikatskette zu sehen und festzustellen, ob eine hybride ML-KEM-Gruppe ausgehandelt wird. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch ein Konformitätsnachweis. Nutzen Sie ihn als erste Zeile Ihres Inventars, aktivieren Sie dann X25519MLKEM768 auf Ihren öffentlichen Endpunkten mit klassischem Fallback, und nehmen Sie eine Anforderung an hybriden Schlüsselaustausch in den nächsten Vertrag auf, den Sie verlängern, noch vor dem Beschaffungssignal für die Zeit nach 2030.