PQC StatusBei einem VPN ist für einen künftigen Quantenangreifer der Schlüsselaustausch der verwundbare Teil, nicht die Verschlüsselung der Nutzdaten. Für IPsec gibt es zwei veröffentlichte IETF-Mechanismen, die Sie heute nutzen können: RFC 9370, mit dem IKEv2 zusätzliche Schlüsselaustausche aushandeln kann, sodass ein Post-Quanten-KEM (Key Encapsulation Mechanism) parallel zu einer klassischen Gruppe läuft, und RFC 8784, das einen Post-Quanten-Pre-Shared-Key in die Schlüsselableitung von IKEv2 einmischt. WireGuard hat im Protokoll selbst keinen Post-Quanten-Schlüsselaustausch. Der optionale, 32 Byte große symmetrische Pre-Shared Key ist daher der einzige Hebel innerhalb des Protokolls.
Warum der Schlüsselaustausch Vorrang hat
Ein IPsec-Tunnel besteht aus zwei Schichten. ESP (Encapsulating Security Payload) schützt die Daten mit einem symmetrischen Algorithmus, typischerweise AES-256-GCM. Symmetrische Algorithmen und Hashfunktionen werden durch Shors Algorithmus nicht gebrochen, und Grovers Algorithmus ist der Grund, warum AES-256 für langfristigen Schutz bevorzugt wird. Bei der IKE-Schicht (Internet Key Exchange) ist das anders: IKEv2, wie in RFC 7296 veröffentlicht, leitet seine Schlüssel aus einem Diffie-Hellman-Austausch ab, und Diffie-Hellman auf elliptischen Kurven sowie Diffie-Hellman über endlichen Körpern werden von Shors Algorithmus auf einem ausreichend großen Quantencomputer gebrochen, unabhängig von der Gruppengröße.
Das ist schon heute relevant, und zwar wegen Harvest now, decrypt later (HNDL): Ein Angreifer, der verschlüsselten Tunnelverkehr heute aufzeichnet, muss nur abwarten, bis der Schlüsselaustausch später fällt, um ihn zu lesen. Site-to-Site-Tunnel, die Daten mit langer Vertraulichkeitsdauer transportieren (Gesundheitsakten, juristische Unterlagen, industrielle Konstruktionsdaten, Zahlungsdaten), sind der eindeutigste Fall. Die Authentisierung ist eine separate Frage. Die Peer-Authentisierung in IKEv2 mit RSA- oder ECDSA-Zertifikaten muss nur einem Angreifer standhalten, der zum Zeitpunkt des Handshakes präsent ist. Signaturen können daher nach dem Schlüsselaustausch migriert werden, migriert werden müssen sie aber dennoch.
Die drei heute verfügbaren Mechanismen
| Mechanismus | Spezifikation | Was sich ändert | Voraussetzungen |
|---|---|---|---|
| Zusätzliche Schlüsselaustausche in IKEv2 | RFC 9370, unter Nutzung des IKE_INTERMEDIATE-Austauschs aus RFC 9242 | Ein Post-Quanten-KEM wird in-band ausgehandelt, zusätzlich zur klassischen Gruppe | Unterstützung durch beide Peers, eine registrierte Schlüsselaustauschmethode für das KEM, IKEv2-Fragmentierung |
| Einmischen eines Post-Quanten-Pre-Shared-Keys (PPK) | RFC 8784 | Ein Geheimnis mit hoher Entropie wird in die IKEv2-Schlüsselableitung eingemischt, sodass ein aufgezeichneter Austausch nicht ausreicht | Out-of-Band-Verteilung, Speicherung und Rotation eines PPK pro Peer-Paar |
| WireGuard-Pre-Shared-Key | WireGuard-Protokolldokumentation (Option PresharedKey) | Ein 32 Byte großer symmetrischer Schlüssel wird in den Chaining Key des Handshakes eingemischt | Out-of-Band-Verteilung pro Peer-Paar, keine In-Band-Aushandlung |
| Schutz der ESP-Nutzdaten | AES-256-GCM | Nichts: bereits außerhalb der Reichweite von Shors Algorithmus | AES-256 für langfristigen Schutz bevorzugen |
RFC 9370: zusätzliche Schlüsselaustausche in IKEv2
Das Basis-IKEv2 handelt im IKE_SA_INIT-Austausch genau eine Schlüsselaustauschmethode aus. RFC 9370 fügt bis zu sieben weitere Transform-Typen für den Schlüsselaustausch hinzu (üblicherweise als ADDKE1 bis ADDKE7 bezeichnet). Sie werden im selben Proposal ausgehandelt und anschließend in einem oder mehreren IKE_INTERMEDIATE-Austauschen durchgeführt, dem in RFC 9242 definierten Austauschtyp. Die resultierenden gemeinsamen Geheimnisse fließen zusammen in das Schlüsselmaterial der IKE SA ein. Wenn Sie also eine klassische Gruppe als ersten Schlüsselaustausch beibehalten und ein KEM als ADDKE1 hinzufügen, erhalten Sie ein hybrides Verfahren: Ein Angreifer muss beide brechen. Hybride Verfahren empfehlen ANSSI und BSI, und sie sind die konservative Wahl, solange Post-Quanten-Implementierungen noch jung sind.
Das KEM, nach dem Sie fragen sollten, ist ML-KEM, von NIST am 13. August 2024 in FIPS 203 standardisiert. ML-KEM-768 ist der gängige mittlere Parametersatz; CNSA 2.0 verlangt ML-KEM-1024. Die maßgebliche Liste der Kennungen für IKEv2-Schlüsselaustauschmethoden ist die IANA-Registry der IKEv2-Parameter, und die Arbeit an der Spezifikation von ML-KEM für IKEv2 läuft in der IETF-Arbeitsgruppe IPSECME. Ziehen Sie daher die Registry und die Dokumentation Ihrer Implementierung heran, statt einer in einem Artikel genannten Transform-Nummer zu vertrauen.
Daraus ergeben sich zwei betriebliche Konsequenzen. Erstens sind öffentliche Schlüssel und Chiffretexte von ML-KEM weitaus größer als ein Punkt auf einer elliptischen Kurve, daher sollte die IKEv2-Nachrichtenfragmentierung (RFC 7383) aktiviert sein. Ein Grund, warum RFC 9370 IKE_INTERMEDIATE verwendet, ist, dass diese Austausche im Gegensatz zu IKE_SA_INIT fragmentiert werden können. Zweitens unterscheidet sich die Proposal-Syntax zwischen Implementierungen und Versionen, und die Schreibweise des Schlüsselworts für einen zusätzlichen Post-Quanten-Schlüsselaustausch ist nicht portabel. Prüfen Sie sie in der Dokumentation Ihrer genauen Version:
# Illustrative shape only, not a portable configuration line.
# Order: encryption - integrity/PRF - classical group - additional key exchange 1
# aes256gcm16 - prfsha384 - <classical group> - <ML-KEM as ADDKE1>
# The keyword for the additional key exchange depends on the implementation
# and its version. Take it from that version's documentation.Rein lesende Prüfungen auf einem Linux-Gateway, vor und nach einer Änderung, zeigen, was der Kernel tatsächlich installiert hat:
# List the IPsec security associations and the ESP algorithms in use
ip -s xfrm state
# Show the installed IPsec policies
ip xfrm policyTesten Sie zunächst in einer Staging-Umgebung, mit den Peers, die Sie tatsächlich nutzen, und behalten Sie ein rein klassisches Proposal als dokumentierten Fallback bei, bis alle Peers migriert sind.
RFC 8784: Einmischen eines Post-Quanten-Pre-Shared-Keys
RFC 8784 geht einen anderen Weg. Der Initiator signalisiert die Unterstützung mit einer USE_PPK-Benachrichtigung, und ein Post-Quanten-Pre-Shared-Key, identifiziert durch eine PPK_ID, wird in die Schlüsselableitung der IKE SA eingemischt. Ein Angreifer, der den Austausch aufzeichnet und später den Diffie-Hellman-Anteil bricht, kann die Sitzungsschlüssel ohne den PPK dennoch nicht ableiten. Der Nutzen liegt gerade darin, dass kein neuer asymmetrischer Algorithmus nötig ist: Viele eingesetzte IKEv2-Stacks beherrschen das bereits.
Die Grenzen sind eher betrieblicher als kryptografischer Natur. Der PPK muss echte Entropie aufweisen und von einer geeigneten Zufallsquelle erzeugt werden, nicht von einem Menschen eingetippt. Er muss out-of-band und pro Peer-Paar verteilt, gespeichert und rotiert werden, was im großen Maßstab der schwierige Teil ist. Die Peer-Authentisierung wird dadurch nicht quantensicher. Zudem erlaubt RFC 8784, den PPK als verpflichtend oder optional zu konfigurieren: Ist er optional, erhält ein Peer, der kein USE_PPK sendet, schlicht eine klassische SA. Wo beide Seiten es unterstützen, konfigurieren Sie ihn als verpflichtend und protokollieren Sie, welche Peers einen PPK ausgehandelt haben, damit Sie die Abdeckung nachweisen können, statt sie nur anzunehmen.
WireGuard heute
Der Handshake von WireGuard basiert auf Curve25519, der Schlüsselaustausch ist also in gleicher Weise quantenverwundbar wie IKEv2 mit einer klassischen Gruppe. Das Protokoll hat bewusst keine Aushandlungsschicht und keine Algorithmenagilität, es gibt also keinen Post-Quanten-Schlüsselaustausch, den man aktivieren könnte. Vorhanden ist der optionale symmetrische Pre-Shared Key, der in den Handshake eingemischt wird und den die WireGuard-Protokolldokumentation als Gegenmaßnahme gegen einen Angreifer darstellt, der Verkehr jetzt aufzeichnet und die öffentlichen Schlüssel später angreift.
# Generate one 32 byte pre-shared key per peer pair
wg genpsk
# In a wg-quick configuration file, add it to the peer section
# [Peer]
# PublicKey = <peer public key>
# PresharedKey = <output of wg genpsk>
# AllowedIPs = 10.0.0.2/32Behandeln Sie das Ergebnis als Geheimnis mit eigenem Lebenszyklus: eindeutig pro Paar, über einen vertrauenswürdigen Kanal übermittelt, rotiert und in Ihrem Schlüsselinventar erfasst. Einige Projekte betreiben einen externen Daemon, der separat einen Post-Quanten-Schlüsselaustausch durchführt und den PresharedKey-Wert regelmäßig erneuert (Rosenpass ist ein Open-Source-Beispiel für dieses Muster). WireGuard selbst bleibt dabei unverändert, allerdings um den Preis einer zusätzlichen Komponente, die bereitgestellt, überwacht und auditiert werden muss. Wenn Sie eine In-Band-Aushandlung eines standardisierten KEM benötigen, ist IPsec mit RFC 9370 der Weg, der heute existiert.
Was Sie VPN-Anbieter fragen sollten
| Frage | Warum sie wichtig ist |
|---|---|
| Welche Post-Quanten-Schlüsselaustauschmethoden unterstützt die IKE-Implementierung, in welcher Firmware-Version und unter welchen IANA-Kennungen für Schlüsselaustauschmethoden? | Macht aus einer Marketingaussage etwas, das Sie testen und dokumentieren können |
| Implementieren Sie RFC 9370 mit RFC 9242, RFC 8784 oder beides? | Hybrides In-Band-KEM und manuelles Einmischen eines PPK lösen das Problem auf unterschiedliche Weise |
| Ist der Schlüsselaustausch hybrid, und welcher ML-KEM-Parametersatz wird verwendet? | Hybrid ist die empfohlene Ausrichtung; CNSA 2.0 verlangt ML-KEM-1024 |
| Ist die Implementierung gegen FIPS 203 validiert, oder nutzt sie ein validiertes Modul? | Von manchen Beschaffungs- und Prüfregimen gefordert |
| Ist die IKEv2-Fragmentierung aktiviert, und wie wirkt sie sich messbar auf Rekey-Rate, CPU-Last und Tunnelaufbauzeit aus? | Größere KEM-Nutzdaten verändern IKE-Paketgrößen und Gateway-Last |
| Was geschieht, wenn ein Peer den Post-Quanten-Austausch nicht unterstützt, und lässt sich das protokollieren oder alarmieren? | Sie brauchen Sichtbarkeit auf einen stillen Rückfall auf eine rein klassische SA |
| Welche Interoperabilitätstests wurden mit den konkreten Peers durchgeführt, die wir nutzen (Cloud-Gateways, Partnergeräte, Remote-Access-Clients)? | An der Interoperabilität von hybridem IKEv2 geraten Einführungen ins Stocken |
| Wie sieht die Roadmap für Post-Quanten-Peer-Authentisierung (ML-DSA-Zertifikate) aus? | Erst der Schlüsselaustausch, dann die Signaturen, aber beides wird benötigt |
| Erhält die aktuelle Hardware diese Funktion, oder nur die nächste Generation? | Krypto-Beschleuniger, die für elliptische Kurven ausgelegt sind, beherrschen ML-KEM möglicherweise nicht |
| Welche schriftlichen Nachweise stellen Sie bereit: Release Notes, Testberichte, unterstützte Konfiguration? | Genau das fließt in Ihr kryptografisches Inventar ein |
Die Fristen für Netzwerkausrüstung
VPN-Gateways werden in einem Zeitplan ausdrücklich genannt. CNSA 2.0 der NSA, das für US National Security Systems gilt, schreibt die ausschließliche Nutzung seines Algorithmensatzes (darunter ML-KEM-1024) bis Ende 2030 für das Signieren von Software und Firmware sowie für klassische Netzwerkausrüstung vor, und bis Ende 2033 für Webbrowser und Webserver, Cloud-Dienste, Betriebssysteme und Nischenausrüstung. Netzwerkausrüstung gehört zur früheren Gruppe.
An anderer Stelle empfiehlt die BSI TR-02102-1 (Version 2026-01, veröffentlicht am 23. Januar 2026) eine hybride Post-Quanten-Schlüsseleinigung und hält eine allein eingesetzte klassische Schlüsseleinigung nur bis Ende 2031 für akzeptabel, bei sehr hohem Schutzbedarf bis Ende 2030; es handelt sich um eine Technische Richtlinie, nicht um eine Rechtsvorschrift. Die ANSSI macht die Hybridisierung innerhalb ihres regulierten Bereichs verpflichtend (Produktqualifizierung, Diffusion Restreinte, SAIV und SIIV) und stellt klar, dass ihre Post-Quanten-Empfehlungen anderswo noch keine regulatorischen Pflichten sind (ANSSI PQC FAQ). Die EU Coordinated Implementation Roadmap v1.1 (23. Juni 2025) fordert kryptografische Inventare und nationale Roadmaps bis Ende 2026 sowie die Migration von Anwendungsfällen mit hohem Risiko bis Ende 2030; sie ist eine koordinierte Leitlinie für die Mitgliedstaaten, keine für Unternehmen verbindliche Rechtsvorschrift. Das britische NCSC (20. März 2025) erwartet Bestandsaufnahme und einen ersten Plan bis 2028, die Migrationen mit höchster Priorität bis 2031 und den Abschluss bis 2035. NIST IR 8547 ist weiterhin ein erster öffentlicher Entwurf: Er schlägt vor, Algorithmen mit 112-Bit-Sicherheit wie RSA-2048 nach 2030 als veraltet einzustufen und alle quantenverwundbaren Public-Key-Algorithmen nach 2035 nicht mehr zuzulassen.
Unsere Lesart, als Interpretation und nicht als Rechtsberatung: Ein langlebiger Site-to-Site-Tunnel, der regulierte Daten transportiert, ist genau die Art von Anwendungsfall mit hohem Risiko, auf die diese Zeitpläne zuerst abzielen. Damit rückt der VPN-Bestand in der Reihenfolge nach vorn, auch dort, wo der Text eine Empfehlung und keine Pflicht ist.
Nächster Schritt
Beginnen Sie mit dem Inventar, denn das verlangt jeder dieser Texte: Erfassen Sie jeden Tunnel, die IKE-Version, die ausgehandelte Schlüsselaustauschgruppe, die ESP-Algorithmen, die Authentisierungsmethode und die Vertraulichkeitsdauer der transportierten Daten. Wählen Sie dann einen Tunnel mit geringem Risiko zwischen zwei Peers, die Sie selbst kontrollieren, und testen Sie ein hybrides Proposal in der Staging-Umgebung, mit einem klassischen Fallback.
PQC Status testet TLS, nicht IKEv2, und kann Ihnen daher nicht sagen, was Ihr Gateway auf UDP 500 und 4500 aushandelt. Für alles, was ein VPN-Bestand über HTTPS bereitstellt, ist es dennoch die schnellste Prüfung: Webportale der Appliances, SSL-VPN-Frontends, Management- und Enrollment-Schnittstellen. Scannen Sie diese Hostnamen kostenlos mit PQC Status, um zu sehen, ob sie bereits einen hybriden ML-KEM-Schlüsselaustausch anbieten, und senden Sie anschließend die oben aufgeführten Fragen an den Hersteller jedes Gateways.