Post-Quantum-TLS für Verteidigungs-APIs: hybride Handshakes im Produktionsbetrieb

Jede Verteidigungs-API im Produktionsbetrieb ist heute durch einen Schlüsselaustausch geschützt – typischerweise X25519 oder eine elliptische Kurve –, den ein hinreichend leistungsfähiger Quantencomputer letztlich brechen wird. Diese Maschine existiert noch nicht, aber die Daten, die diese APIs durchqueren, haben eine Vertraulichkeitslebensdauer von Jahren oder Jahrzehnten. Ein Angreifer kann den verschlüsselten Datenverkehr jetzt aufzeichnen und ihn später entschlüsseln, sobald die Hardware verfügbar ist. Post-Quantum-TLS schließt dieses Fenster, indem dem Handshake ein quantenresistenter Schlüsselkapselungsmechanismus hinzugefügt wird. Dieser Artikel beschreibt, wie man ihn auf echten Verteidigungs-APIs einsetzt: den hybriden ML-KEM-Handshake, die Zertifikatsfrage, die Leistungs- und Bandbreitenauswirkungen und ein schrittweises Rollout, das keinen einzigen bestehenden Client unterbricht.

Das Harvest-now-decrypt-later-Bedrohungsmodell

Der Grund, warum Post-Quantum-TLS dringend ist, hat nichts damit zu tun, ob heute ein kryptografisch relevanter Quantencomputer existiert. Es geht um die Asymmetrie zwischen dem Zeitpunkt der Datenerfassung und dem Zeitpunkt der Entschlüsselung. Ein Angreifer mit den Ressourcen, Datenverkehr abzuzapfen und zu speichern, kann die verschlüsselten Sitzungen einer Verteidigungs-API auf unbestimmte Zeit archivieren. In dem Moment, in dem ein Quantencomputer zur Verfügung steht, der in der Lage ist, Shor's Algorithmus im erforderlichen Maßstab auszuführen, wird jede gespeicherte Sitzung, deren Schlüsselaustausch einen klassischen Algorithmus verwendet hat, rückwirkend offenbart. Wir behandeln diese Quantenbedrohungs-Zeitachse an anderer Stelle ausführlich; die operative Schlussfolgerung für ein API-Team ist einfach. Wenn Ihre Daten über den Zeitpunkt der praktischen Quantencomputer hinaus geheim bleiben müssen, kann die Migration nicht auf diesen Zeitpunkt warten – zu diesem Zeitpunkt ist der erfasste Datenverkehr bereits kompromittiert.

Deshalb haben Authentifizierung und Vertraulichkeit unterschiedliche Dringlichkeit. Eine gefälschte Signatur spielt nur im Moment der Verbindung eine Rolle – ein Quantencomputer, der Signaturen im Jahr 2035 bricht, kann einen 2026 abgeschlossenen Handshake nicht rückwirkend fälschen. Vertraulichkeit ist das Gegenteil: Sie muss für die gesamte Aufbewahrungslebensdauer der Daten gelten. Post-Quantum-TLS priorisiert daher zunächst den Schlüsselaustausch und verschiebt die Signaturmigration – genau die Reihenfolge, die CNSA 2.0 und die breiteren Standardisierungsgremien empfehlen.

Hybride Handshakes: doppelte Absicherung

Der standardisierte Post-Quantum-Schlüsselkapselungsmechanismus ist ML-KEM (FIPS 203, abgeleitet von CRYSTALS-Kyber). Grundsätzlich könnte ein TLS 1.3-Handshake ML-KEM allein verwenden. In der Praxis verwenden Verteidigungseinsätze einen hybriden Handshake, der ML-KEM und einen klassischen Algorithmus zusammen ausführt und ihre Ausgaben kombiniert.

Der Mechanismus ist unkompliziert. Während des TLS 1.3-Schlüsselaustauschs leiten Client und Server jeweils zwei gemeinsame Geheimnisse ab – eines vom klassischen Algorithmus (X25519) und eines von ML-KEM-768. Die beiden Geheimnisse werden verkettet und als ein einziges kombiniertes Geheimnis in den TLS-Schlüsselplan eingespeist. Der Sitzungsschlüssel wird daher aus beiden abgeleitet. Ein Angreifer muss beide Algorithmen brechen, um die Sitzung wiederherzustellen: Der klassische widersteht heutigen Angreifern, und ML-KEM widersteht einem zukünftigen Quantenangreifer.

Der hybride Ansatz ist bewusst konservativ. ML-KEM ist neu, und das Vertrauen der kryptografischen Gemeinschaft in jeden Algorithmus wächst mit Jahren der Prüfung. Die Kombination mit dem bewährten X25519 bedeutet, dass die Sitzung selbst dann nicht schwächer als das heutige klassische TLS ist, wenn später ein Implementierungsfehler oder eine unerwartete Schwäche in der Post-Quantum-Komponente gefunden wird. Die Kosten für das Tragen beider sind bescheiden, und für Verteidigungsworkloads ist der Konservatismus es wert.

Die benannte Gruppe: X25519MLKEM768

In TLS 1.3 wird die hybride Konstruktion als eine einzige benannte Gruppe in der supported_groups-Erweiterung exponiert. Die weit verbreitete Form ist X25519MLKEM768, die X25519 mit ML-KEM-768 paart (der Sicherheitsstufe-3-Parametersatz, geeignet für die meisten CNSA 2.0-Ziele). Der Server bewirbt die Gruppe, der Client bietet einen Schlüsselanteil dafür an, und die Aushandlung verläuft genau wie für jede andere Gruppe. Entscheidend ist, dass hybrides TLS in die bestehende TLS 1.3-Aushandlungsmaschinerie eingebettet ist – es gibt keine neue Protokollschicht, nur eine neue Gruppenkennung und einen größeren Schlüsselanteil.

Leistung und Bandbreite: wo die Kosten tatsächlich anfallen

Eine verbreitete Annahme ist, dass Post-Quantum-Kryptografie langsam ist. Für ML-KEM ist das falsch. Die Gitteroperationen hinter ML-KEM-768-Schlüsselerzeugung, -kapselung und -entkapselung sind schnell – häufig schneller als die elliptische Kurven-Skalarmultiplikation des klassischen Algorithmus, den sie begleiten. Auf einem modernen Server-Kern fügen die ML-KEM-Operationen in einem hybriden Handshake deutlich weniger als eine Millisekunde hinzu. Die CPU ist nicht die Einschränkung.

Die echten Kosten sind Bytes auf der Leitung. Ein öffentlicher ML-KEM-768-Schlüssel beträgt etwa 1184 Bytes und der Chiffretext etwa 1088 Bytes. Zusammen mit dem klassischen X25519-Anteil trägt der hybride Schlüsselaustausch über ClientHello und ServerHello hinweg ungefähr 2,3 KB bei. Die operativ relevante Konsequenz: Das ClientHello, das mit klassischen Gruppen bequem unter 1400 Bytes liegt, überschreitet nun ein einzelnes Netzwerkpaket. In einem sauberen Netzwerk ist dies unsichtbar. Auf einer verlustbehafteten oder eingeschränkten Verbindung – einem Satellitenbackhaul, einem überlasteten taktischen Funkkanalträger – bietet das zusätzliche Paket eine neue Möglichkeit für Verlust und Neuübertragung, und der Handshake-Fehler-Tail kann wachsen.

Dies verändert das Rollout-Risikobild. Was gemessen werden muss, ist nicht die Handshake-CPU-Zeit, sondern das ClientHello-Fragmentierungsverhalten und die Middlebox-Toleranz über die spezifischen Netzwerkpfade, die eine Verteidigungs-API tatsächlich bedient. Eine API, die nur über ein gesundes Rechenzentrums-Fabric erreicht wird, wird im Wesentlichen keine Auswirkungen sehen; eine, die von benachteiligten taktischen Links erreicht wird, benötigt eine sorgfältige Validierung, bevor die hybride Gruppe aktiviert wird.

Die Zertifikatsfrage: zuerst Vertraulichkeit, später Authentifizierung

Ein häufiger Verwechslungspunkt ist, ob der Einsatz von Post-Quantum-TLS die Neuausstellung jedes Zertifikats erfordert. Für die erste Phase tut er das nicht. Der hybride Handshake schützt den Schlüsselaustausch – den Teil von TLS, der die Vertraulichkeit der Sitzung herstellt – und das ist der einzige Teil, der dem Harvest-now-decrypt-later-Angriff ausgesetzt ist. Die Serverauthentifizierung verwendet weiterhin die bestehende RSA- oder ECDSA-Zertifikatskette.

Es gibt einen praktischen Grund, die Signaturmigration über das Bedrohungsmodell-Argument hinaus aufzuschieben. Die standardisierten Post-Quantum-Signaturalgorithmen, ML-DSA (FIPS 204) und SLH-DSA (FIPS 205), erzeugen weitaus größere Signaturen und öffentliche Schlüssel als ECDSA. Eine auf ML-DSA aufgebaute Zertifikatskette kann um eine Größenordnung größer sein, was jeden Handshake aufbläst und eingeschränkte Clients belastet. Das Zertifizierungsstellenökosystem, die Browser- und OS-Vertrauensspeicher und die meisten Client-TLS-Stacks sind noch nicht bereit, Post-Quantum-Signaturketten im großen Maßstab zu validieren. Das Erzwingen von Post-Quantum-Authentifizierung heute würde weitaus mehr kaputt machen, als es schützt.

Die korrekte Reihenfolge, die mit der CNSA 2.0-Leitlinie für die Verteidigung übereinstimmt, lautet daher: Jetzt hybriden Schlüsselaustausch einsetzen, um Harvest-now-decrypt-later zu vereiteln, die klassische Authentifizierung beibehalten und Signaturen in einer separaten, späteren Phase zu ML-DSA migrieren, sobald die CA-Kette und Ihre Client-Population dies unterstützen können. Die Behandlung dieser als zwei unabhängige Migrationen hält jede einzelne bewältigbar.

Schrittweises Rollout ohne Client-Unterbrechungen

Das wichtigste Prinzip für ein nicht störendes Rollout ist, dass die hybride benannte Gruppe additiv sein muss. Sie aktivieren X25519MLKEM768 neben den klassischen Gruppen, nicht anstelle von ihnen. TLS 1.3-Gruppenaushandlung ist von Natur aus abwärtskompatibel: Ein moderner Client, der die hybride Gruppe anbietet, erhält sie; ein älterer Client, der nur X25519 anbietet, fällt auf die klassische Gruppe am selben Endpunkt zurück. Kein Client wird beschädigt, indem der Server einfach weiß, wie man eine neue Gruppe spricht.

Von dort aus ist das Rollout eine Übung in Messung. Zuerst inventarisieren Sie jeden TLS-Terminierungspunkt – Edge-Load-Balancer, API-Gateways, Service-Mesh-Sidecars, Ursprungsserver – und die Kryptobibliothek an jedem, da die Upgrade-Geschichte nur so gut ist wie der am wenigsten leistungsfähige Terminator. Ein Hardware-Gerät mit eingefrorener Firmware, das nicht ML-KEM sprechen kann, wird zur Gating-Einschränkung und muss identifiziert werden, bevor Versprechen gemacht werden.

Zweites, schalten Sie die hybride Gruppe im additiven Modus hinter einem Feature-Flag ein und instrumentieren Sie die ausgehandelte Schlüsselaustauschgruppe für jeden abgeschlossenen Handshake. Diese Telemetrie zeigt Ihnen den echten Anteil des bereits geschützten Datenverkehrs und identifiziert die Clients und Netzwerke, die nie aktualisieren. Drittens – und erst wenn die Telemetrie nahezu universelle hybride Aushandlung auf einer Route zeigt – können Sie optional die hybride Gruppe auf den sensibelsten Endpunkten erzwingen, indem Sie den klassischen Fallback dort entfernen, während der Rest der API additiv bleibt. Die Durchsetzung ist der letzte Schritt, eng angewendet, mit einem getesteten Rollback in den additiven Modus immer verfügbar.

Diese Reihenfolge ist aus demselben Grund wichtig wie bei jedem kryptografischen Migrationsprogramm – die Migration ist ein langlebiger, reversibler Zustandsübergang, kein Schalter. Für Organisationen, die die breitere kryptografische Migration rund um ihre APIs planen, ordnet die CNSA 2.0-Migrationsroadmap den TLS-Schlüsselaustausch in den Kontext der vollständigen Algorithmeninventur und -zeitachse ein.

Operative Leitplanken für Verteidigungs-APIs

Über die Aushandlung hinaus trennen einige Leitplanken eine gehärtete Bereitstellung von einer fragilen. Setzen Sie das Mindestprotokoll auf TLS 1.3 auf Post-Quantum-fähigen Routen; die hybride Konstruktion existiert nur in 1.3, und das Erlauben eines Downgrades auf 1.2 stellt wieder einen rein klassischen Schlüsselaustausch her. Deaktivieren Sie Sitzungswiederaufnahme-Pfade, die es einer Verbindung ermöglichen würden, einen frischen hybriden Schlüsselaustausch zu überspringen, es sei denn, die Wiederaufnahme selbst leitet Post-Quantum-Schutz weiter. Und stellen Sie sicher, dass Ihr Beobachtbarkeits-Stack sowohl die TLS-Version als auch die ausgehandelte Gruppe aufzeichnet, sodass eine Regression – ein Bibliotheks-Downgrade, ein falsch konfiguriertes Gateway – als Rückgang des hybriden Anteils erscheint, anstatt Ihre APIs stillschweigend auf rein klassische Vertraulichkeit zurückzusetzen.

Krypto-Agilität ist die Eigenschaft, die all dies über den mehrjährigen Horizont, den die Migration tatsächlich umspannt, wartbar macht. ML-KEM-768 ist der richtige Parametersatz für die meisten Verteidigungs-APIs heute, aber die Standards werden sich weiterentwickeln, benannte Gruppen werden hinzugefügt, und Ihre Routen mit höchster Klassifizierung können schließlich ML-KEM-1024 erfordern. Konfiguration, nicht Code, sollte entscheiden, welche Gruppen ein Endpunkt anbietet, sodass das Erhöhen des Post-Quantum-Sicherheitsniveaus oder das Ausmustern einer veralteten Gruppe eine operative Änderung und keine Neubereitstellung ist. Dieselbe Agilität gilt umgekehrt: Wenn ein Fehler in einer bereitgestellten Gruppe gefunden wird, möchten Sie ihn innerhalb von Minuten in der gesamten Flotte deaktivieren. Behandeln Sie die unterstützte-Gruppen-Liste als eine verwaltete, versionierte Richtlinie, und Ihre APIs bleiben während der gesamten Transition quantensicher, nicht nur zu einem einzigen Zeitpunkt.

Das Rollout vor der Produktionseinführung testen

Validieren Sie den hybriden Handshake gegen die gesamte Vielfalt Ihrer Client-Population, bevor Sie ihn breit aktivieren. Richten Sie einen Staging-Endpunkt ein, der X25519MLKEM768 additiv anbietet, und treiben Sie ihn mit jedem Client-Typ an, der die API im Feld berührt – aktuelle SDKs, eingebettete Clients auf eingeschränkter Hardware und alle Drittanbieter-Integratoren. Zeichnen Sie die ausgehandelte Gruppe für jeden auf, damit Sie wissen, welche Clients aktualisieren und welche stillschweigend klassisch bleiben. Achten Sie besonders auf Clients hinter Inspection-Proxys oder Regierungs-Gateways, da dort das vergrößerte ClientHello am wahrscheinlichsten fallen gelassen wird. Ein Staging-Durchlauf, der die echte Netzwerktopologie übt und nicht nur eine saubere Laborverbindung, ist das, was es Ihnen ermöglicht, hybrid später mit Zuversicht auf einer sensiblen Route durchzusetzen, anstatt zu hoffen.