VPN-Migration nach Quantum: IPsec-, TLS-VPNs und Fernzugriff

Kurz gesagt: Die Migration von Post-Quantum-VPNs bietet zwei unterschiedliche Ausgangspunkte, je nachdem, was Ihr Gerät aktuell unterstützt. RFC 8784 ermöglicht die Integration eines Post-Quantum-Pre-Shared Keys in die IKEv2-Schlüsselableitung ohne neuen Schlüsselaustauschalgorithmus – ein einfacher erster Schritt, der bereits von vielen Firewalls der aktuellen Generation unterstützt wird. RFC 9370, aufbauend auf dem Intermediate Exchange von RFC 9242, ergänzt IKEv2 um einen echten hybriden Post-Quantum-Schlüsselaustausch. TLS-basierte Remote-Access-VPNs nutzen denselben hybriden Schlüsselaustausch (X25519MLKEM768), der bereits in Browsern und CDNs eingesetzt wird. Die entscheidende Einschränkung in beiden Fällen ist die Firmware: Behandeln Sie die spezifische Produktversion Ihres Geräts als zwingende Abhängigkeit und überprüfen Sie die Interoperabilität anhand der exakten Peer-Kombination, die Sie verwenden, und nicht nur anhand der allgemeinen Roadmap des Herstellers.

Die VPN-Migration erfährt in den meisten PQC-Planungen weniger Aufmerksamkeit als die TLS-Migration – ein Fehler, wenn man bedenkt, wie viel langlebiger und sensibler Datenverkehr über IPsec- und TLS-VPN-Tunnel läuft. Anders als bei einem Webserver lässt sich eine VPN-Appliance in der Regel nicht durch ein Firmware-Update beheben; sie ist fest von der Firmware abhängig, deren Release-Zyklus oft vom Hersteller vorgegeben ist und über den man keinen Einfluss hat. Die Appliance befindet sich an beiden Enden eines Tunnels und muss interoperabel sein. Dieser Leitfaden behandelt die Protokolle, die Frage der Appliance-Bereitschaft und einen schrittweisen Rollout-Ansatz.

Wichtige Erkenntnisse

• RFC 8784 (Post-Quantum Pre-Shared Keys) ist der einfachste erste Schritt für IKEv2 VPNs, da kein neuer Schlüsselaustauschalgorithmus erforderlich ist, sondern lediglich ein Pre-Shared Key, der in die bestehende Ableitung integriert wird.
• RFC 9370, basierend auf dem Intermediate Exchange von RFC 9242, fügt IKEv2 einen echten hybriden Post-Quantum-Schlüsselaustausch hinzu, der einen klassischen Austausch mit einem oder mehreren Post-Quantum-KEMs kombiniert.
• TLS-basierte Remote-Access-VPNs erben die Unterstützung für den hybriden Schlüsselaustausch vom zugrunde liegenden TLS-Stack und folgen dem gleichen X25519MLKEM768-Bereitstellungsmuster wie Browser- und CDN-Datenverkehr.
• Firmware- und Produktversion sind eine feste Voraussetzung für VPN-Appliances und keine Konfigurationsoption; Ankündigungen des Herstellersupports und die tatsächliche Einsatzbereitschaft sind zwei separate Fragen.
• Die Leitlinien der CISA zur Quantenbereitschaft behandeln die Einbindung von Anbietern und die Validierung der Interoperabilität als Kernbestandteile des Migrationsfahrplans und nicht als nachträgliche Überlegung.

IPsec-Schlüsselaustausch: Zwei Wege, unterschiedlicher Aufwand

IKEv2 verfügt über zwei unterschiedliche, standardbasierte Wege zur Post-Quanten-Resistenz, die sich nicht gegenseitig ausschließen.

RFC 8784, Post-Quantum Pre-Shared Keys, integriert einen symmetrischen, außerhalb des regulären Datenverkehrs verteilten Pre-Shared Key in die IKEv2-Schlüsselableitung neben dem bestehenden klassischen Austausch. Es erfordert keinen neuen asymmetrischen Algorithmus und keine wesentlichen Änderungen an der IKEv2-Aushandlung selbst. Daher ist es oft die erste Funktion, die von Appliances mit dieser Funktionalität ausgeliefert wird, und der schnellste Weg zu einer gewissen Quantenresistenz auf Infrastrukturen, die dies bereits unterstützen.

RFC 9370, „Mehrere Schlüsselaustausche in IKEv2“, bietet die umfassendere Lösung: Es erweitert das Protokoll um einen oder mehrere zusätzliche Schlüsselaustausche, typischerweise einen Post-Quanten-KEM wie ML-KEM, neben dem klassischen Austausch mittels kaskadierter Schlüsselableitung. Da der ursprüngliche IKE_SA_INIT-Austausch große Schlüsselmengen nicht fragmentieren konnte, führte RFC 9242 erstmals einen „Zwischenaustausch“ ein, um RFC 9370 die Übertragung der größeren Post-Quanten-Schlüsselmenge nach dem initialen Handshake zu ermöglichen, wenn die Fragmentierung verfügbar ist. Dies ist der Weg zu einem echten hybriden Schlüsselaustausch und nicht nur zu einem zusätzlichen vorab vereinbarten Geheimnis.

TLS-VPNs: Übernahme des gleichen hybriden Schlüsselaustauschs

TLS-basierte Remote-Access-VPNs nutzen denselben TLS-1.3-Stack wie alle anderen TLS-terminierenden Dienste. Das bedeutet, dass sie den hybriden Post-Quantum-Schlüsselaustausch genauso nutzen wie Webserver: durch die Unterstützung der X25519MLKEM768-Gruppe durch die zugrundeliegende TLS-Bibliothek. Ausführlich beschrieben ist dies in unserem X25519MLKEM768-Bereitstellungsleitfaden . Die dort beschriebenen Aushandlungsmechanismen, Kompatibilitätsrisiken und Testmethoden gelten direkt für ein TLS-VPN-Gateway, mit einer Ausnahme: VPN-Client-Software (nicht nur Browser) muss die hybride Gruppe unterstützen, und die Aktualisierungszyklen von VPN-Software sind oft langsamer als die automatischen Browser-Updates.

Gerätebereitschaft: Herstellerunterstützung ist nicht gleichzusetzen mit Einsatzbereitschaft.

Die Ankündigung von Post-Quantum-Support durch einen Hersteller in einer Roadmap oder Pressemitteilung bedeutet nicht, dass dieser Support auf der in Ihrer Umgebung eingesetzten Produktversion verfügbar, getestet und stabil ist. Behandeln Sie Firmware- und Produktversion als feste, explizite Abhängigkeit in Ihrem Migrationsplan: Ermitteln Sie die exakte Mindestversion, die die von Ihnen geplante Schlüsselaustauschmethode unterstützt, vergleichen Sie diese mit Ihrer aktuell eingesetzten Version und planen Sie den Upgrade-Zyklus als Teil des Migrationszeitplans ein, anstatt von einer automatischen Aktualisierung auszugehen.

Die Validierung der Interoperabilität ist genauso wichtig wie die Versionsunterstützung. Die Unterstützung von IKEv2 nach der Quantenintegration durch zwei verschiedene Anbieter oder sogar durch zwei verschiedene Produktlinien desselben Anbieters garantiert keine reibungslose Kommunikation von Anfang an. Validieren Sie daher die exakte Peer-Kombination, die Sie tatsächlich verwenden – Client zu Konzentrator, Standort zu Standort –, anstatt anzunehmen, dass die Einhaltung allgemeiner Standards Interoperabilität garantiert.

Client-Kompatibilität

Die Kompatibilität von VPN-Client-Software für den Remotezugriff ist unabhängig vom Gateway oder Konzentrator. Ein VPN-Gateway mit Unterstützung für hybriden Schlüsselaustausch nützt nichts, wenn die Client-Anwendung – sei es ein dedizierter VPN-Client oder ein browserbasiertes TLS-VPN-Portal – diese Unterstützung nicht bietet. Erfassen Sie die Client-Softwareversionen Ihrer Remote-Mitarbeiter genauso sorgfältig wie die Gateway-Firmware, da eine gemischte Flotte aus aktuellen und veralteten Clients die realistische Ausgangssituation für die meisten Unternehmenseinführungen darstellt und kein vollständiger Systemwechsel.

Ein stufenweiser Einführungsansatz

1. Ausgangslage und Inventar: Vor jeder Konfigurationsänderung sollten Sie die aktuelle Firmware- oder Softwareversion jedes VPN-Gateways, Konzentrators und Clients sowie dessen dokumentierte Post-Quantum-Fähigkeiten überprüfen.
2. Zuerst die klassische Basislinie modernisieren: Es muss sichergestellt werden, dass eine starke klassische Kryptographie und aktuelle Protokollversionen bereits vorhanden sind; die Post-Quanten-Fähigkeit baut auf einer modernen Basis auf, nicht auf einer veralteten.
3. Beginnen Sie mit RFC 8784, sofern verfügbar: Post-Quanten-Pre-Shared Keys bieten einen sinnvollen Schutz vor Harvest-Now-Decrypt-Later bei minimalem Protokollrisiko – ein vernünftiger erster Schritt, während die Unterstützung für einen breiteren hybriden Schlüsselaustausch weiterentwickelt wird.
4. Pilotprojekt zum hybriden Schlüsselaustausch gemäß RFC 9370 in einem nichtkritischen Tunnel: Die Interoperabilität muss anhand der exakten Peer-Kombination überprüft werden, bevor der Produktivverkehr berührt wird.
5. Legen Sie explizit das klassische Fallback-Verhalten fest: Entscheiden, ob einem Peer, der keinen Post-Quanten-Schlüsselaustausch aushandeln kann, die Verbindung mit rein klassischer Kryptographie gestattet oder gänzlich abgelehnt werden soll, und diese Entscheidung dokumentieren, anstatt sie als implizite Standardeinstellung zu belassen.
6. Protokollieren und überwachen Sie ausgehandelte Algorithmen: Verfolgen Sie, welche Schlüsselaustauschmethode jeder Tunnel im Produktivbetrieb tatsächlich aushandelt, damit ein stillschweigender Rückgriff auf die rein klassische Methode als Kennzahl sichtbar wird und bei einem Audit keine Überraschung darstellt.

Was wir tatsächlich empfehlen würden

Beginnen Sie mit RFC 8784-konformen Pre-Shared Keys auf einer Infrastruktur, die dies bereits unterstützt. Diese bieten echten Schutz vor Harvest-Now-Decrypt-Later und das geringste Implementierungsrisiko aller derzeit verfügbaren Optionen. Erstellen Sie Ihr Firmware- und Client-Versionsinventar, bevor Sie sich auf einen Zeitplan für die Einführung eines hybriden Schlüsselaustauschs festlegen. Betrachten Sie Ankündigungen der Hersteller-Roadmaps als Planungsgrundlage, nicht als verbindlichen Bereitstellungstermin. Testen Sie den hybriden Schlüsselaustausch nach RFC 9370 zunächst in einem einzelnen, nicht kritischen Tunnel und validieren Sie die genaue Peer-Kombination, anstatt sich auf die allgemeine Einhaltung von Standards zu verlassen.

Wie Verschlüsselungsberatung helfen kann

Der oben beschriebene schrittweise Rollout setzt eine präzise Bestandsaufnahme der VPN-Gateway-Firmware, der Client-Softwareversionen und der Tunnelkonfigurationen in Ihrer gesamten Umgebung voraus – genau die Art von Wissenslücke, die die meisten Migrationspläne schon im Vorfeld zum Scheitern bringt. CBOM Secure erstellt und pflegt diese Bestandsaufnahme und ordnet jeden VPN-Endpunkt seiner aktuellen Version und seinen Post-Quantum-Fähigkeiten zu, sodass der Migrationsplan auf realen Daten basiert.

Wenn die ML-KEM-Schlüsseloperationen selbst auf FIPS-validierter Hardware ausgeführt werden müssen, unterstützt HSM-as-a-Service den RFC 9370 Hybrid Exchange ohne separaten Hardwarebeschaffungszyklus pro Gateway. Unsere PQC-Beratungsdienste sequenzieren den Firmware-Upgrade-Zyklus, die Interoperabilitätsvalidierung und den oben beschriebenen stufenweisen Rollout entsprechend Ihrer spezifischen Gerätekonfiguration und Tunneltopologie. So wird der Zeitplan des Herstellers in einen realen, getesteten Migrationsplan umgesetzt und nicht nur in Annahmen.

Firmware ist der eigentliche Migrationszeitplan

Die Migration von Post-Quantum-VPNs ist weniger eine Frage der Algorithmen als vielmehr der Firmware und Interoperabilität. RFC 8784 bietet einen unkomplizierten ersten Schritt, RFC 9370 die vollständige Hybridlösung, und TLS-VPNs übernehmen die gleichen Schutzmechanismen wie der Webverkehr. Entscheidend für den Fortschritt der Migration ist, ob Ihre spezifische Appliance-Version an beiden Enden jedes Tunnels die gewählte Methode unterstützt und korrekt interoperabel ist. Daher sind die Bestandsaufnahme und die Validierung der Interoperabilität wichtiger als die Protokollauswahl selbst.

Häufig gestellte Fragen

Wie lässt sich ein bestehendes IKEv2-VPN am schnellsten um Post-Quantum-Schutz erweitern?

RFC 8784, Post-Quantum Pre-Shared Keys. Es benötigt keinen neuen Schlüsselaustauschalgorithmus, sondern lediglich einen Pre-Shared Key, der in die bestehende IKEv2-Ableitung integriert wird, und ist bereits auf vielen Geräten der aktuellen Generation verfügbar.

Worin besteht der Unterschied zwischen RFC 8784 und RFC 9370?

RFC 8784 integriert einen symmetrischen Pre-Shared Key in die bestehende Schlüsselableitung von IKEv2 ohne neuen Algorithmus. RFC 9370 führt einen echten hybriden Post-Quanten-Schlüsselaustausch ein, der den klassischen Austausch mit einem oder mehreren Post-Quanten-KEMs wie ML-KEM kombiniert und den Intermediate Exchange gemäß RFC 9242 für die Übertragung des größeren Schlüsselmaterials erfordert.

Benötigen TLS-basierte Remote-Access-VPNs separate Post-Quanten-Arbeiten im Vergleich zu IPsec-VPNs?

Sie erben den hybriden Schlüsselaustausch vom zugrunde liegenden TLS 1.3-Stack und folgen dem gleichen X25519MLKEM768-Muster wie jeder andere TLS-Dienst. Allerdings muss die VPN-Client-Software speziell die Hybridgruppe unterstützen, und die Aktualisierungszyklen des Clients sind oft langsamer als die des Browsers, weshalb hierfür eine eigene Kompatibilitätsprüfung erforderlich ist.

Ist die Unterstützung von VPN-Funktionen nach der Quantenüberprüfung durch den Hersteller gleichbedeutend mit der Einsatzbereitschaft?

Nein. Die Roadmap eines Herstellers dient der Planung, nicht als Bereitstellungstermin. Vergewissern Sie sich, dass die in Ihrer Umgebung verwendete Firmware- oder Produktversion die von Ihnen vorgesehene Schlüsselaustauschmethode tatsächlich unterstützt und dafür validiert wurde, bevor Sie einen Rollout-Zeitplan erstellen.

Soll es Peers, die ausschließlich klassisch kommunizieren, erlaubt sein, sich zu verbinden, sobald der Post-Quanten-Schlüsselaustausch eingeführt ist?

Dies sollte eine explizite, dokumentierte Entscheidung und keine Standardeinstellung sein. Es muss festgelegt und dokumentiert werden, ob ein Peer, der keinen Post-Quanten-Schlüsselaustausch aushandeln kann, weiterhin Verbindungen mit rein klassischer Kryptografie herstellen darf oder abgewiesen werden soll. Die ausgehandelten Algorithmen im Produktivbetrieb müssen protokolliert werden, um das tatsächliche Verhalten nachvollziehbar zu machen.