Post-Quanten-Schlüsselverwaltung: HSMs, Krypto-Agilität und CNSA 2.0

Kryptografische Algorithmen sind der einfache Teil einer Post-Quanten-Transition. Jeder kann ML-KEM in eine Handshake-Bibliothek integrieren. Der schwierige Teil ist alles rund um den Algorithmus: wo die Schlüssel liegen, wie sie unter Manipulationsschutz generiert werden, wie sie an Tausende von eingesetzten Knoten verteilt werden, wie sie rotiert werden, wenn sich ein Parametersatz ändert, und wie das gesamte Gefüge interoperabel mit Gegenstellen bleibt, die noch nicht migriert haben. Dieses Gefüge ist die Schlüsselverwaltung – und für Verteidigungssysteme ist sie das tragende Element des Übergangs zu CNSA 2.0. Dieser Artikel untersucht, wie man Post-Quanten-Schlüsselverwaltung für klassifizierte und kontrollierte Systeme aufbaut: Hardware-Sicherheitsmodul-Integration, hybride Schlüsselvereinbarung, Krypto-Agilität als architektonische Eigenschaft und eine Migrationssequenz, die den Kontakt mit der operativen Realität übersteht.

Warum die Schlüsselverwaltung – nicht der Algorithmus – die eigentliche Migration ist

Die standardisierten Post-Quanten-Primitive sind nun stabil. NIST hat ML-KEM (FIPS 203) für die Schlüsselverkapselung, ML-DSA (FIPS 204) für digitale Signaturen und SLH-DSA (FIPS 205) als hashbasierte Signaturalternative finalisiert, ergänzt durch die bewährten zustandsbehafteten Hash-Verfahren LMS und XMSS für Software- und Firmware-Signing. Implementierungen existieren in gängigen TLS- und VPN-Stacks. Wenn die Wahl eines Algorithmus das gesamte Problem wäre, wäre die Migration bereits abgeschlossen.

Das ist sie nicht, weil die Schlüssel, die diese Algorithmen verbrauchen, größer, zahlreicher und langlebiger sind, als die Systeme, die sie verwalten, ursprünglich ausgelegt wurden. Ein klassischer ECDH-Schlüssel auf der P-384-Kurve liegt weit unter hundert Bytes. Ein ML-KEM-1024-Schlüsselpaar und ein ML-DSA-87-Schlüsselpaar werden in Kilobytes gemessen. Multipliziert man das über jeden TLS-Endpunkt, jedes Funkgerät, jedes signierte Firmware-Image und jeden gespeicherten Data-at-Rest-Schlüssel in einem eingesetzten Programm, landen die Anforderungen im Schlüsselverwaltungssystem: Slotkapazität im HSM, Bandbreite auf dem Verteilungskanal, Speicher im Key Vault und die Zeit, die benötigt wird, um alles zu rotieren, wenn sich ein Algorithmus ändert.

Deshalb behandeln glaubwürdige Programme den Übergang als Schlüsselverwaltungsprogramm mit einer kryptografischen Komponente und nicht umgekehrt. Der Algorithmus ist eine Abhängigkeit; der Schlüssellebenszyklus ist das Projekt.

HSM-Integration: die Vertrauensgrundlage unter Post-Quanten-Last

Für jedes System, das klassifizierte oder kontrollierte Daten verarbeitet, müssen Post-Quanten-Schlüssel in einem nach FIPS 140-3 validierten Hardware-Sicherheitsmodul generiert und gespeichert werden – dieselbe Vertrauensanforderung, die für klassische Schlüssel galt. Das HSM ist dort, wo Entropie gesammelt wird, wo private Schlüssel niemals im Klartext das Gerät verlassen und wo Signatur- und Schlüsselverkapselungsoperationen hinter Manipulationsschutz ausgeführt werden.

Die Post-Quanten-Unterstützung über HSM-Produktlinien kommt, aber uneinheitlich. Mehrere validierte Linien bieten ML-KEM und ML-DSA jetzt in validierter Firmware oder in einem Early-Access-Kanal vor der Validierung an, und die meisten bieten LMS und XMSS für Code-Signing an, da diese Verfahren ausgereift und standardisiert sind. Die Integrationsarbeit betrifft weniger die Frage, ob der Algorithmus vorhanden ist, als vielmehr die Auswirkungen zweiter Ordnung größerer Schlüssel.

Schlüsselslotkapazität und Backup

Ein HSM verfügt über eine begrenzte Menge geschützten Schlüsselspeichers. Das Ersetzen klassischer Schlüssel im Byte-Bereich durch Post-Quanten-Schlüssel im Kilobyte-Bereich kann die Slotkapazität weit früher als erwartet erschöpfen, insbesondere bei Appliances, die vor Jahren für eine klassische Schlüsselpopulation dimensioniert wurden. Backup- und Wiederherstellungsformate müssen ebenfalls neu dimensioniert werden, und das Schlüsselverpackungsverfahren, das exportiertes Schlüsselmaterial schützt, muss selbst Post-Quanten-sicher sein, damit die Backups kein Ernteziel werden. Planen Sie Kapazitäten für die Post-Quanten-Schlüsselpopulation – nicht für die klassische, die sie ersetzt.

Leistung unter realistischer Last

ML-DSA-Signing und ML-KEM-Verkapselung weisen andere Leistungsprofile auf als RSA und ECC, und diese Profile variieren je nach HSM-Modell erheblich. Der Signierdurchsatz kann insbesondere in einer Code-Signing-Pipeline oder einem hochvolumigen Mutual-TLS-Gateway zum Engpass werden. Messen Sie das spezifische Modell unter der Last, die es tatsächlich sehen wird – gleichzeitige Sitzungen, Signierrate, Schlüsselgenerierungsschübe bei der Massen-Rotation –, anstatt Parität mit klassischen Operationen vorauszusetzen. Ein Migrationsplan, der auf einer Datenblatt-Zahl basiert, die unter Last nicht hält, ist ein Plan, der im Einsatz scheitert.

Krypto-Agilität als architektonische Eigenschaft

Krypto-Agilität ist die Fähigkeit, Algorithmen, Parametersätze und Protokolle systemweit zu ändern, ohne Anwendungen neu erstellen oder die Interoperabilität unterbrechen zu müssen. Sie ist kein nachträglich hinzugefügtes Feature; sie ist eine Eigenschaft der Art, wie das System auf Kryptografie verweist. In einem agilen Design benennt eine Anwendung niemals direkt einen Algorithmus. Sie fordert eine Operation an – „Sitzungsschlüssel für diesen Peer vereinbaren", „dieses Firmware-Image signieren" – gegenüber einer Schlüsselkennung und einer Richtlinie. Die Richtlinie benennt den Algorithmus und den Parametersatz; die Schlüsselverwaltungsschicht löst ihn auf.

Der Nutzen ist operativer Natur. Wenn sich die Leitlinien zur ML-KEM-Parameterauswahl ändern, ein neues Signaturverfahren zur Suite hinzugefügt wird oder ein eingesetztes Primitiv zurückgezogen werden muss, ist die Änderung eine Richtlinienaktualisierung, die über die Schlüsselverwaltungsebene verteilt wird – kein Firmware-Recompile, der zu jedem Knoten im Feld übertragen werden muss. Für Verteidigungssysteme mit zehn- und zwanzigjährigen Betriebsdauern und noch reifenden Primitiven ist das der Unterschied zwischen einer Konfigurationsänderung und einem Neuabnahme-Programm.

Agilität beschränkt das Design auch auf nützliche Weise. Sie erzwingt eine saubere Trennung zwischen Schlüsselmaterial und dem Code, der es verwendet, explizite Versionierung kryptografischer Richtlinien und die Aushandlung von Fähigkeiten beim Verbindungsaufbau, sodass ein migrierter Knoten weiterhin mit einem nicht migrierten kommunizieren kann. Das sind genau die Eigenschaften, die eine mehrjährige Transition benötigt. Krypto-Agilität frühzeitig in die Geheimnisschutz- und Signing-Pipeline einzubauen ist weit günstiger als sie nachzurüsten, sobald ein Parametersatz unter Termindruck geändert werden muss.

Hybride Schlüsselvereinbarung während des Übergangs

Der verbreitete Ansatz zur Einführung von Post-Quanten-Schlüsselvereinbarung, ohne alles auf einen neuen Algorithmus zu setzen, ist die hybride Schlüsselvereinbarung. Ein hybrider Handshake führt eine klassische Schlüsselvereinbarung (typischerweise ECDH auf P-384) und ein Post-Quanten-KEM (ML-KEM) parallel durch und leitet dann den Sitzungsschlüssel aus beiden gemeinsamen Geheimnissen über eine Standard-Schlüsselableitungsfunktion ab. Das kombinierte Geheimnis ist nur so schwach wie das stärkere seiner beiden Eingaben.

Das abzusichernde Risiko ist konkret. Die Post-Quanten-Algorithmen sind neu; ein Implementierungsfehler oder eine unvorhergesehene Schwäche in einem noch jungen Primitiv kann nicht ausgeschlossen werden. Falls das eintritt, schützt die klassische Komponente die Sitzung weiterhin vor jedem Angreifer ohne Quantencomputer. Wenn umgekehrt ein kryptografisch relevanter Quantencomputer erscheint, schützt die Post-Quanten-Komponente Sitzungen, deren klassische Schlüsselvereinbarung andernfalls gebrochen würde. Keine Komponente allein muss perfekt sein; beide müssen versagen, damit die Sitzung bricht.

Aus Sicht der Schlüsselverwaltung verdoppelt der Hybridmodus in etwa das Schlüsselmaterial pro Sitzung und die CPU-Kosten des Handshakes, und er erfordert eine Fähigkeitsaushandlung, damit ein hybridfähiger Knoten bei einer Gegenstelle, die nur klassisch oder nur Post-Quanten unterstützt, graceful zurückfallen kann. Die Schlüsselverwaltungsschicht ist der Ort, an dem diese Aushandlungsrichtlinie liegt, wo die beiden Schlüsseltypen gemeinsam verfolgt werden und wo der Prüfpfad belegt, welche Sitzungen die Post-Quanten-Komponente tatsächlich genutzt haben. Dasselbe Hybridprinzip liegt physikschichtbezogenen Ansätzen wie der Quantenschlüsselverteilung für taktische Verbindungen zugrunde, obwohl QKD die Schlüsselvereinbarung über einen anderen Kanal adressiert, anstatt die Schlüsselverwaltungsebene zu ersetzen.

CNSA 2.0 und die Harvest-Now-Decrypt-Later-Uhr

CNSA 2.0 legt Ziel und Zeitplan fest. Es schreibt ML-KEM für die Schlüsselvereinbarung, ML-DSA für allgemeine Signaturen und LMS oder XMSS für Software- und Firmware-Signing in nationalen Sicherheitssystemen vor – mit einem gestuften Zeitplan: zuerst Software- und Firmware-Signing, dann Netzwerk- und Schlüsselverwaltungsgeräte, mit vollständiger Übernahme bis 2033. Schlüsselverwaltungsgeräte sind ausdrücklich im Scope – sie müssen diese Post-Quanten-Schlüssel generieren, speichern und verteilen, idealerweise in validierter Hardware.

Der Termin ist aber nicht der eigentliche Treiber. Der Treiber ist Harvest-Now-Decrypt-Later: Ein Angreifer zeichnet heute verschlüsselten Verteidigungsdatenverkehr auf und speichert ihn, bis ein zukünftiger Quantencomputer die klassische Schlüsselvereinbarung brechen kann, die ihn schützte. Alle Daten, deren Vertraulichkeit die Zeit bis zum Quantencomputer überdauern muss, sind bereits exponiert – unabhängig vom Zieldatum 2033. Das verändert die Priorisierung grundlegend: Die ersten zu migrierenden Verbindungen sind die, die die langlebigsten Geheimnisse tragen, nicht die, die am einfachsten anzufassen sind.

Die Migration sequenzieren, ohne den Feldbetrieb zu unterbrechen

Eine praktikable Sequenz beginnt mit einem kryptografischen Inventar: jeder Punkt, an dem das System Schlüssel generiert, speichert, austauscht oder verifiziert, annotiert mit Algorithmus, Schlüssellebensdauer und der Vertraulichkeits- oder Integritätslebensdauer der geschützten Daten. Dieses Inventar steuert die Priorisierung. Firmware- und Software-Signing migrieren früh – sie sind die erste Phase von CNSA 2.0 und schützen die Lieferkette selbst – gefolgt von den Verbindungen, die die langlebigsten Geheimnisse tragen, dann der breiten Population ephemerer Sitzungen.

Jede migrierte Komponente durchläuft die krypto-agile Abstraktion, betreibt Hybrid, wo Interoperabilität mit noch nicht migrierten Gegenstellen erforderlich ist, und wird von einem HSM gesichert, das für die Post-Quanten-Schlüsselpopulation dimensioniert ist. Dabei setzt die Schlüsselverwaltungsschicht verkürzte Schlüssellebensdauern und automatisierte Rotation durch, damit das Expositionsfenster für jeden einzelnen Schlüssel klein bleibt. Für Programme, die bereits einen umfassenderen Übergang planen, ist das nahtlos mit der CNSA 2.0 Compliance- und Migrations-Roadmap verbunden; den übergeordneten Blick bietet der Begleitartikel zur CNSA 2.0 Compliance für Verteidigungsorganisationen.

Die Disziplin, die alles zusammenhält, ist die Krypto-Agilitäts-Übung: Tauschen Sie periodisch einen Parametersatz End-to-End in einer repräsentativen Umgebung aus, um zu beweisen, dass der Migrationspfad weiterhin nutzbar ist. Eine Migrationsfähigkeit, die niemals getestet wird, ist eine Fähigkeit, die man tatsächlich nicht hat, wenn die nächste Algorithmusänderung eintrifft.