Zum Inhalt springen
CONFIGLANE

Kryptografie · Migration

Post-Quantum im Netzwerk: Was heute verfügbar ist und was Sie jetzt vorbereiten

Die Standards stehen, die ersten Implementierungen sind da, die Roadmaps sind datiert. Der Teil, den kein Hersteller liefern kann, ist die Antwort auf die Frage, wo in Ihrem Netz heute welche Kryptografie arbeitet — und genau der ist der Engpass.

Von ConfiglaneVeröffentlicht 7 Min. LesezeitEnterprise Networks

Das Wichtigste in Kürze

  • Der Zeitdruck kommt nicht vom Quantenrechner, sondern vom Mitschnitt: Was heute abfließt, kann später entschlüsselt werden. Für lange schutzbedürftige Daten läuft die Frist bereits.
  • Die Algorithmen sind standardisiert — ML-KEM als FIPS 203, ML-DSA als FIPS 204, SLH-DSA als FIPS 205 —, und IKEv2 kann über RFC 9242 und RFC 9370 mehrere Schlüsselaustausche kombinieren.
  • Hybrid ist der empfohlene Übergang: klassisches und post-quantenfestes Verfahren gleichzeitig. Diese Linie tragen NIST, NSA, das BSI und die französische ANSSI gemeinsam.
  • Bei Cisco Secure Firewall sind RFC 8784 ab ASA 9.18 und die hybriden Austausche nach RFC 9242/9370 ab ASA 9.19 verfügbar; ML-KEM ist für FTD 10.5 und ASA 9.25 für Ende 2026 angekündigt.

Post-Quantum-Kryptografie leidet unter einem Kommunikationsproblem: Sie wird als Zukunftsthema verhandelt, obwohl der Teil mit der Frist längst begonnen hat. Der Grund ist unspektakulär und liegt nicht in der Rechenleistung, sondern im Speicher.

Warum die Uhr bereits läuft

Das Angriffsmodell heißt „harvest now, decrypt later“: Verschlüsselter Verkehr wird heute mitgeschnitten und gespeichert, um ihn zu entschlüsseln, sobald ein hinreichend leistungsfähiger Quantenrechner existiert. Für den Angreifer ist das billig — Speicher kostet fast nichts, und er muss nicht wissen, was er hat.

Daraus folgt die einzige Rechnung, die für die Planung zählt: Wie lange müssen die Daten geschützt bleiben, die heute über diese Strecke laufen? Bei Konstruktionsdaten, Patentvorbereitungen, Personal- oder Gesundheitsdaten sind zehn Jahre eine konservative Annahme. Wer solche Daten über eine Verbindung schickt, die nur klassisch geschützt ist, hat die Frist bereits überschritten — unabhängig davon, wann der erste kryptografisch relevante Quantenrechner tatsächlich läuft.

Was inzwischen standardisiert ist

Die Unsicherheit der letzten Jahre ist an dieser Stelle vorbei. Es gibt benannte Standards, und die Protokollarbeit für IKEv2 ist abgeschlossen.

StandardWas er regeltRolle im Netz
FIPS 203 — ML-KEMSchlüsselkapselung, Parameter 512/768/1024Schlüsselaustausch für VPN und TLS
FIPS 204 — ML-DSADigitale SignaturenGeräte- und Softwareauthentisierung
FIPS 205 — SLH-DSAHashbasierte SignaturenAlternative mit anderer mathematischer Grundlage
RFC 9242Intermediate Exchange in IKEv2Trägt die großen Schlüssel, ohne IP-Fragmentierung zu erzwingen
RFC 9370Mehrere Schlüsselaustausche in IKEv2Ermöglicht den hybriden Austausch
RFC 8784Post-Quantum-Preshared-Keys für IKEv2Übergangsschutz ohne neue Algorithmen
Die relevanten Standards

Der Zusammenhang zwischen den beiden RFCs ist der praktische Kern: RFC 9370 erlaubt, während eines IKEv2-Aufbaus mehrere Schlüsselaustausche zu kombinieren und daraus einen gemeinsamen Schlüssel abzuleiten. Weil post-quantenfeste Schlüssel deutlich größer sind als klassische, braucht es dafür RFC 9242 — den Intermediate Exchange —, damit die Nachrichten nicht auf IP-Ebene fragmentiert werden müssen. Beides zusammen ergibt einen hybriden Austausch, der abwärtskompatibel bleibt.

Hybrid ist die Empfehlung, nicht der faule Kompromiss

Bei einem hybriden Verfahren laufen ein klassisches und ein post-quantenfestes Verfahren gleichzeitig; der Sitzungsschlüssel entsteht aus beiden. Der Verkehr ist damit genau so lange sicher, wie mindestens eines der beiden Verfahren hält.

Das ist kein Zögern, sondern die begründete Übergangsstrategie: Die post-quantenfesten Verfahren sind jung, und ihre Implementierungen sind es erst recht. Die Kombination schützt gegen den Quantenrechner, ohne im Gegenzug ein Risiko aus einem Implementierungsfehler in einem neuen Verfahren einzukaufen. NIST, die NSA, das BSI und die französische ANSSI empfehlen diesen Weg übereinstimmend für die Migrationsphase.

Was auf Cisco-Plattformen verfügbar ist — und was angekündigt

Für Cisco Secure Firewall ist der Fahrplan öffentlich und ungewöhnlich konkret. Zwei Dinge sind heute nutzbar, der Rest ist datierte Roadmap:

FähigkeitReleaseZeitpunkt
RFC 8784 (Post-Quantum-Preshared-Keys)ASA ab 9.18verfügbar
RFC 9242 / RFC 9370 (hybrider Austausch)ASA ab 9.19verfügbar
ML-KEM für VPN-HandshakesFTD 10.5 / ASA 9.25angekündigt für Ende 2026
TLS-Entschlüsselung mit PQCFTD 10.5angekündigt
ML-DSA und SLH-DSA (Signaturen)FTD/ASA 11.0angekündigt für H2 2027
Remote-Access-VPN mit PQCASA/FTD 11.0geplant
Cisco Secure Firewall: Stand laut Hersteller-Roadmap

Die wichtigste Lesart dieser Tabelle: Der Übergangsschutz ist keine Zukunftsfrage. Wer ASA in einer Version ab 9.19 betreibt, kann hybride Austausche heute aktivieren — für die Strecken, auf denen langlebig schutzbedürftige Daten laufen. Das ist eine Konfigurationsentscheidung, kein Beschaffungsprojekt.

Bei MACsec liegen die Dinge anders. Die Integration post-quantenfester Verfahren in den dynamischen Schlüsselaustausch ist in Arbeit, aber Terminaussagen sind hier mit Vorsicht zu behandeln, solange die Funktionen nicht in einem freigegebenen Konfigurationsleitfaden stehen. Für Strecken zwischen Rechenzentren, die heute mit MACsec geschützt sind, heißt das: Das Thema gehört auf die Risikoliste, nicht auf den Projektplan.

Der Schritt, der immer zuerst kommt: das Krypto-Inventar

Jede Migrationsplanung scheitert an derselben Frage: Wo genau wird was verschlüsselt? Nicht auf Produktebene, sondern auf Strecken- und Algorithmusebene. Diese Erhebung ist unspektakulär, dauert Wochen und ist der einzige Teil, der sich nicht durch ein Upgrade ersetzen lässt.

  1. Strecken erfassen

    Jeder Tunnel, jede TLS-terminierende Stelle, jede MACsec-Verbindung, jeder Management-Zugang. Auch die, die seit Jahren niemand angefasst hat — besonders die.

  2. Verfahren je Strecke bestimmen

    Welcher Schlüsselaustausch, welche Signatur, welche Schlüssellängen? Das steht in der Konfiguration, nicht im Datenblatt.

  3. Schutzdauer der Daten zuordnen

    Fachlich, nicht technisch: Wie lange muss vertraulich bleiben, was hier fließt? Diese Zahl bestimmt die Priorität, nicht die Bandbreite der Strecke.

  4. Gegenstellen und Abhängigkeiten prüfen

    Ein hybrider Austausch braucht beide Seiten. Fremdgegenstellen, Cloud-Endpunkte und ältere Appliances entscheiden über die tatsächliche Reihenfolge.

  5. Reihenfolge festlegen und umsetzen

    Zuerst die Strecken mit langer Schutzdauer und beidseitig fähigen Endpunkten. Umstellung als regulärer Change mit Rückfallplan, nicht als Sonderaktion.

Dieses Inventar hat einen Nebennutzen, der die Arbeit oft allein rechtfertigt: Es findet zuverlässig die Strecken, die noch mit veralteten Verfahren oder abgelaufenen Zertifikaten arbeiten. Die Post-Quantum-Frage ist dann der Anlass, nicht der einzige Ertrag. Wie wir solche Erhebungen führen und in belastbare Changes überführen, beschreibt unsere Arbeitsweise unter Unternehmensnetze und Netzwerk-Security.

Was in zwölf Monaten realistisch ist

  • Krypto-Inventar für die Kernstrecken. Vollständig für Site-to-Site-VPN, Management-Zugänge und Rechenzentrumsverbindungen.
  • Hybride Austausche dort aktivieren, wo beide Seiten es können. Auf ASA ab 9.19 ist das eine Konfiguration, kein Projekt.
  • Beschaffung anpassen. Neue Firewalls, Router und Terminierungspunkte werden gegen die Fähigkeit geprüft, ML-KEM per Software nachzurüsten — nicht gegen die heutige Funktionsliste.
  • Zertifikatslaufzeiten und -prozesse aufräumen. Die Signaturumstellung kommt 2027; sie trifft nur die vorbereitet, die wissen, welche Zertifikate wo hängen — und die 47-Tage-Staffel zwingt ohnehin zur Automatisierung.
  • Die MACsec-Strecken als offenen Punkt führen. Mit Datum der nächsten Prüfung, nicht als erledigt.

Was in zwölf Monaten nicht realistisch ist: eine vollständig post-quantenfeste Infrastruktur. Das ist keine Schwäche der Planung, sondern der Stand der Implementierungen. Reine PQC-Betriebsmodi bleiben vorerst die Ausnahme; der hybride Übergang ist für diese Phase der Zielzustand.

Quellen

Jede belegte Aussage dieses Beitrags ist hier nachvollziehbar. Das Abrufdatum sagt, wie frisch die Prüfung ist.

FAQ

Häufige Fragen zur Post-Quantum-Migration

Müssen wir jetzt handeln, obwohl es noch keinen relevanten Quantenrechner gibt?

Für Daten mit langer Schutzdauer ja. Das Angriffsmodell setzt keinen heutigen Quantenrechner voraus, sondern nur die Fähigkeit, Verkehr zu speichern. Für kurzlebige Daten — eine Sitzung, ein Tagesreport — ist die Dringlichkeit dagegen gering. Die Schutzdauer ist das Kriterium, nicht die Wichtigkeit des Systems.

Reicht RFC 8784 als Übergang?

Als Zwischenschritt ja, als Ziel nein. Post-Quantum-Preshared-Keys schützen den IKEv2-Aufbau zusätzlich mit einem gemeinsamen Geheimnis und brauchen keine neuen Algorithmen — dafür müssen die Schlüssel verteilt und verwaltet werden. Für eine Handvoll fester Gegenstellen ist das praktikabel, für viele dynamische Verbindungen nicht.

Was kostet ein hybrider Schlüsselaustausch an Leistung?

Der Aufwand liegt im Handshake — größere Nachrichten und etwas mehr Rechenzeit —, nicht im laufenden Datenstrom. Bei langlebigen Site-to-Site-Tunneln ist der Effekt in der Praxis vernachlässigbar. Kritisch wird es nur bei sehr hohen Aufbauraten kurzlebiger Verbindungen; dort gehört es in den Lasttest.

Müssen wir Hardware tauschen?

Für den hybriden Austausch nach RFC 9370 in der Regel nicht — er kam bei ASA per Software ab 9.19. Für ML-KEM und die späteren Signaturverfahren gilt: Prüfen Sie bei Neubeschaffungen ausdrücklich die Nachrüstbarkeit per Software, statt sich auf die heutige Funktionsliste zu verlassen.

Nächster Schritt

Gilt das auch für Ihr Netz?

Ein Assessment beantwortet die Frage an Ihrer Infrastruktur statt an einem Beispiel — mit einem belastbaren ersten Change am Ende.

Assessment anfragen

Assessment → belastbarer erster Change