ML-KEM-Schlüsselverwaltung: Post-Quanten-Schlüssel erzeugen, speichern und rotieren (2026)

ML-KEM-Schlüsselverwaltung umfasst die Kontrollen für das Erzeugen, Speichern, Verteilen, Rotieren und Vernichten der Schlüssel von ML-KEM, dem Post-Quanten-Verfahren zur Schlüsselkapselung (Key Encapsulation Mechanism, KEM), das NIST in FIPS 203 standardisiert hat. Die meisten ML-KEM-Schlüssel sind ephemer und leben nur für einen einzigen TLS-Handshake. Die statischen Schlüssel brauchen dieselbe Verwahrung wie jeder langlebige private Schlüssel, mit zwei neuen Details: grössere Schlüssel und ein 64-Byte-Seed, der genauso schutzbedürftig ist wie der private Schlüssel selbst.

Der Schlüsselaustausch ist der Teil Ihrer Kryptografie, der «harvest now, decrypt later» ausgesetzt ist: Datenverkehr, der heute mit RSA- oder ECDH-Schlüsselaustausch aufgezeichnet wird, lässt sich entschlüsseln, sobald ein ausreichend grosser Quantencomputer existiert. Deshalb stellen der Entwurf des NIST-Übergangsplans und der Zeitplan der US-Bundesbehörden den Schlüsselaustausch an die erste Stelle, und deshalb ist ML-KEM der erste Post-Quanten-Algorithmus, den die meisten Organisationen produktiv einsetzen werden, oft bereits über hybrides TLS in aktuellen OpenSSL-Versionen.

Dieser Leitfaden behandelt die Schlüsselgrössen nach FIPS 203, die Unterschiede der ML-KEM-Schlüsselverwaltung gegenüber RSA und ECDH, hybrides TLS mit X25519MLKEM768, den richtigen Speicherort für ML-KEM-Schlüssel, eine Lebenszyklus-Tabelle, die Fristen nach NIST IR 8547 und CNSA 2.0 sowie die Migrationsplanung.

---

Inhaltsverzeichnis

1. Was ist ML-KEM?
2. ML-KEM-Parametersätze und Schlüsselgrössen
3. Warum sich die ML-KEM-Schlüsselverwaltung von RSA und ECDH unterscheidet
4. Vergleich: RSA und ECDH vs. ML-KEM-Schlüsselverwaltung
5. Hybrides Post-Quanten-TLS und X25519MLKEM768
6. Wo ML-KEM-Schlüssel liegen: ephemer vs. statisch
7. Der Lebenszyklus von ML-KEM-Schlüsseln
8. Fristen: NIST IR 8547 und CNSA 2.0
9. So planen Sie Ihre ML-KEM-Migration
10. Die Rolle von DuoKey
11. FAQ

---

Was ist ML-KEM?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) ist in FIPS 203 spezifiziert, das NIST am 13. August 2024 veröffentlicht hat. In den Worten von NIST ist es ein Verfahren zur Schlüsselkapselung, mit dem zwei Parteien «to establish a shared secret key over a public channel» können, also über einen öffentlichen Kanal ein gemeinsames geheimes Schlüsselmaterial vereinbaren. Seine Sicherheit beruht auf dem Module-Learning-with-Errors-Problem, das nach heutigem Kenntnisstand Angriffen durch Quantencomputer standhält.

Für die Schlüsselverwaltung sind zwei Punkte wichtig:

• ML-KEM ist ein KEM, kein Signaturverfahren. Es ersetzt RSA-Schlüsseltransport und (EC)DH-Schlüsselvereinbarung. Es signiert nichts. Zertifikate, Code-Signing und Authentisierung wechseln zu ML-DSA (FIPS 204) oder SLH-DSA (FIPS 205); diese behandelt unser Leitfaden zu ML-DSA-Zertifikaten und Post-Quanten-PKI.
• Ein KEM hat drei Operationen, nicht zwei. KeyGen erzeugt einen Kapselungsschlüssel ek (öffentlich) und einen Entkapselungsschlüssel dk (privat). Encaps(ek) liefert einen Chiffretext und ein 32 Byte langes gemeinsames Geheimnis. Decaps(dk, ciphertext) stellt dasselbe gemeinsame Geheimnis wieder her.

Die begleitende Empfehlung von NIST, SP 800-227 (final, September 2025), erklärt den sicheren Einsatz von KEMs, unter anderem statische gegenüber ephemeren Schlüsseln, ruhende Daten und hybride Konstruktionen. Lesen Sie sie zusammen mit FIPS 203, wenn Sie eine ML-KEM-Richtlinie verfassen.

---

ML-KEM-Parametersätze und Schlüsselgrössen

FIPS 203 lässt drei Parametersätze zu. Die Grössen unten stammen aus FIPS 203, Tabelle 3; die Sicherheitskategorien aus Abschnitt 8.

Zum Vergleich: Ein öffentlicher X25519-Schlüssel ist 32 Bytes gross.

Welchen Parametersatz wählen? FIPS 203 hält fest: «NIST recommends using ML-KEM-768 as the default parameter set, as it provides a large security margin at a reasonable performance cost.» NIST empfiehlt also ML-KEM-768 als Standard. Zudem rät FIPS 203, beim erstmaligen Einrichten eines Schutzes den stärksten praktikablen Parametersatz zu verwenden, um einen späteren Wechsel zu vermeiden. Systeme der nationalen Sicherheit folgen CNSA 2.0, das auf ML-KEM-1024 verweist (siehe Fristen).

Der Seed. Die ML-KEM-Schlüsselerzeugung beginnt mit zwei 32 Byte langen Zufallswerten, d und z. FIPS 203 erlaubt, diesen 64-Byte-Seed zu speichern und das Schlüsselpaar später neu abzuleiten, ergänzt aber: «it is sensitive data and shall be treated with the same safeguards as a decapsulation key.» Der Seed ist also mit denselben Schutzmassnahmen zu behandeln wie ein Entkapselungsschlüssel.

---

Warum sich die ML-KEM-Schlüsselverwaltung von RSA und ECDH unterscheidet

1. Eine andere Schnittstelle. Bei ECDH kombiniert jede Seite ihren privaten Schlüssel mit dem öffentlichen Schlüssel der Gegenseite. Beim RSA-Schlüsseltransport wählt der Sender ein Geheimnis und verschlüsselt es. ML-KEM ist keines von beiden: Die kapselnde Partei erhält ein frisches gemeinsames Geheimnis und einen Chiffretext, und nur wer dk besitzt, kann dieses Geheimnis wiederherstellen. Bibliotheken, HSM-APIs und Key-Wrapping-Abläufe, die auf encrypt/decrypt oder derive aufbauen, brauchen einen neuen Pfad für encapsulate/decapsulate. Genau diesen fügt PKCS#11 3.2 hinzu (siehe FAQ).

2. Für ephemere und statische Schlüssel gelten unterschiedliche Regeln. SP 800-227 ist eindeutig: «If an application uses an ephemeral key pair, the key pair shall be used for only one execution of key-establishment via a KEM and shall be destroyed as soon as possible after its use.» Ein ephemeres Schlüsselpaar darf also nur für einen einzigen Schlüsselaustausch verwendet und muss danach so schnell wie möglich vernichtet werden. Ein statischer ML-KEM-Schlüssel ist dagegen ein langlebiger privater Schlüssel, der Verwahrung, Backup und Rotation braucht.

3. Zwei private Formate zu verwalten. Ein privater ML-KEM-Schlüssel kann als 64-Byte-Seed, als expandierter dk (1632 bis 3168 Bytes) oder in beiden Formen gespeichert werden. SP 800-227 merkt an: «some applications might call for storing keys using only a short seed, while other applications might call for storing keys in an expanded format that allows for faster computations.» Ihre Richtlinie muss festlegen, welches Format gespeichert, exportiert und gesichert wird, denn ein Backup, das nur den Seed enthält, lässt sich nicht in ein System zurückspielen, das nur dk akzeptiert, und umgekehrt.

4. Der Besitznachweis ändert sich. Ein KEM-Schlüssel kann keinen Zertifikatsantrag signieren. Laut SP 800-227 muss eine Partei, die den statischen Kapselungsschlüssel einer anderen Partei verwendet, «must have assurance of the other party's ownership of the key», also Gewissheit über deren Besitz des Schlüssels haben, die sie von einer Zertifizierungsstelle oder über einen Besitznachweis (Proof of Possession) plus Identitätsprüfung erhält. Rechnen Sie damit, dass sich die Enrollment-Abläufe für ML-KEM-Zertifikate vom Modell «CSR mit Signatur» unterscheiden, das Sie für RSA verwenden.

5. Die Prüfung der Eingaben ist Pflicht. FIPS 203 verlangt, dass Encaps und Decaps nur auf geprüften Eingaben laufen (Abschnitt 7). Der Import eines Schlüssels aus einer nicht vertrauenswürdigen Quelle ist daher ein Validierungsschritt und nicht bloss eine Dateikopie.

6. Grössere Objekte. Grössere Schlüssel und Chiffretexte wirken sich auf TLS-Handshakes, Datenbankspalten, Attributgrenzen und HSM-Speicherkontingente aus.

---

Vergleich: RSA und ECDH vs. ML-KEM-Schlüsselverwaltung

---

Hybrides Post-Quanten-TLS und X25519MLKEM768

X25519MLKEM768 ist eine Schlüsselaustauschgruppe für TLS 1.3, die ML-KEM-768 und X25519 parallel ausführt und beide gemeinsamen Geheimnisse kombiniert. Die Sitzung bleibt so lange sicher, wie einer der beiden Algorithmen hält. Sie ist in RFC 10024 standardisiert, «Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3» (Standards Track, August 2026), hervorgegangen aus dem IETF-Entwurf draft-ietf-tls-ecdhe-mlkem.

RFC 10024 definiert drei Gruppen:

Ein Detail bringt Implementierende oft aus dem Tritt: Bei X25519MLKEM768 steht der ML-KEM-Teil im Key-Share und im verketteten gemeinsamen Geheimnis zuerst, während die beiden Gruppen mit NIST-Kurven den ECDH-Teil an den Anfang stellen.

Was das für die Schlüsselverwaltung bedeutet: Es gibt nichts zu speichern. In hybridem TLS 1.3 erzeugt der Client pro Handshake ein frisches ML-KEM-Schlüsselpaar und sendet den 1184 Byte grossen Kapselungsschlüssel; der Server antwortet mit einem Chiffretext. Beide Schlüsselpaare sind ephemer und werden nach dem Handshake vernichtet, genau wie heute bei ECDHE. Der Server authentisiert sich weiterhin mit seinem bestehenden RSA- oder ECDSA-Zertifikat.

Das Verfahren ist zudem bereits im Einsatz. OpenSSL 3.5.0 (8. April 2025) hat ML-KEM, ML-DSA und SLH-DSA eingeführt und «the default TLS keyshares ... to offer X25519MLKEM768 and X25519» geändert, bietet also standardmässig X25519MLKEM768 und X25519 an. So prüfen Sie, ob ein Server die Gruppe aushandelt:

# OpenSSL 3.5 or later
openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i -E "group|temp key"

---

Wo ML-KEM-Schlüssel liegen: ephemer vs. statisch

Die erste Entscheidung lautet, welche Schlüssel überhaupt verwaltet werden müssen.

Für statische Schlüssel setzt SP 800-227 die Grundlinie: Private Daten (Seeds und Entkapselungsschlüssel) «needs to be stored within the cryptographic module in a manner that is secure against both leakage and unauthorized modification», müssen also im kryptografischen Modul geschützt gegen Abfluss und unbefugte Änderung gespeichert werden, und Import sowie Export «needs to be performed in a secure manner». In der Praxis heisst das: Schlüssel im KMS oder HSM erzeugen, dk als nicht exportierbar markieren, sofern das Backup keinen gewrappten Export erfordert, und Anwendungen nur Decaps zur Verfügung stellen.

---

Der Lebenszyklus von ML-KEM-Schlüsseln

Verwenden Sie diese Tabelle als Ausgangspunkt für eine Richtlinie zu statischen ML-KEM-Schlüsseln. Ephemere TLS-Schlüssel betreffen nur die Zeilen Erzeugung und Vernichtung, und diese übernimmt die TLS-Bibliothek.

Wenn Sie für Tests eine portable Schlüsseldatei brauchen, zeigt OpenSSL 3.5 die Wahl des Seeds direkt. Standardmässig behält OpenSSL den Seed; dieser Befehl schreibt nur den dk nach FIPS 203:

openssl genpkey -provparam ml-kem.retain_seed=no -algorithm ml-kem-768 -out priv-only.pem

Verwenden Sie solche Software-Schlüssel nur für Tests.

---

Fristen: NIST IR 8547 und CNSA 2.0

NIST IR 8547. Transition to Post-Quantum Cryptography Standards von NIST ist weiterhin ein Initial Public Draft (veröffentlicht am 12. November 2024; Kommentarfrist bis 10. Januar 2025). Für den Schlüsselaustausch schlägt der Entwurf vor, Finite-Field-DH/MQV, Elliptic-Curve-DH/MQV und RSA-Schlüsselaustausch mit 112 Bit Sicherheit nach 2030 abzukündigen (deprecated) und diese Algorithmen mit 112 Bit sowie mit 128 Bit oder mehr nach 2035 zu verbieten (disallowed). Da es sich um einen Entwurf handelt, zeigen diese Daten die Richtung von NIST, nicht endgültige Regeln.

CNSA 2.0. Systeme der nationalen Sicherheit in den USA folgen der CNSA-2.0-Suite der NSA. Ein von der NSA verfasster IETF-Internet-Draft, der TLS für CNSA 2.0 profiliert (draft-becker-cnsa2-tls-profile), hält fest: «CNSA 2.0 requires the use of ML-KEM-1024 for key establishment in TLS». Die Fristen pro Kategorie und ihr Zusammenspiel mit dem Zeitplan des OMB für die Bundesbehörden finden Sie in unserem Leitfaden zur US-Regulierung der Post-Quanten-Kryptografie mit NIST, OMB und CNSA 2.0.

---

So planen Sie Ihre ML-KEM-Migration

1. Zuerst inventarisieren. Ermitteln Sie, wo RSA- und ECDH-Schlüsselaustausch stattfindet: TLS-Endpunkte, VPNs, Key-Wrapping-Schlüssel, KMS- und HSM-Schlüssel, Code. Beginnen Sie mit einem kryptografischen Inventar und führen Sie es als CBOM (Cryptography Bill of Materials).
2. Ephemer und statisch trennen. Ephemerer TLS- und VPN-Schlüsselaustausch ist ein Upgrade-Projekt (Bibliotheken, Load Balancer, Middleboxes, die grössere Handshakes verkraften müssen). Statische KEM-Schlüssel sind ein Projekt der Schlüsselverwaltung.
3. Hybrid aktivieren, wo möglich. Aktivieren Sie X25519MLKEM768 auf den Endpunkten, die Sie kontrollieren, und messen Sie, wie oft die Gruppe ausgehandelt wird. Die Zertifikate bleiben unverändert.
4. Schlüsselspeicher prüfen. Verlangen Sie von jedem Anbieter von HSM, KMS und Secrets Manager datierte Angaben zur Unterstützung von ML-KEM-Schlüsselobjekten, Kapselungs-/Entkapselungsoperationen, Speicherung als Seed oder dk und gewrapptem Export.
5. Richtlinie schreiben. Parametersatz, Speicherformat, Kryptoperiode, Backup-Format, Vernichtung und wer entkapseln darf. Nutzen Sie die Lebenszyklus-Tabelle oben.
6. Den Algorithmus zur Richtlinienentscheidung machen. Fest codierte Algorithmen machen jede Änderung zu einem Release; eine Plattform für Krypto-Agilität verlagert diese Wahl in eine zentrale Richtlinie.
7. Laufend messen. Cryptographic Posture Management hält das Inventar aktuell und verfolgt die Behebung; eine PQC-Migrations-Roadmap verknüpft dies mit Terminen und Verantwortlichen.

---

Die Rolle von DuoKey

DuoKey deckt die oben beschriebenen Schritte Inventar und Richtlinie ab. Gemäss der Dokumentation von DuoKey:

• Discovery. Der PQC Scanner von DuoKey, die Discovery-Engine von DuoKey CPM, findet Zertifikate und Schlüssel in Dateisystemen, Keystores und Cloud-KMS (AWS, Azure, GCP), und sein Domain Scanner erkennt Post-Quanten-Schlüsselaustausch. Er kennzeichnet RSA und ECDSA als quantenverwundbar, führt ML-KEM als informativ auf und erstellt eine CBOM sowie einen Quantum Readiness Score. Sie können mit dem kostenlosen Quantum Readiness Score beginnen, der keinen Zugriff auf interne Systeme benötigt.
• Richtlinie statt fest codierter Algorithmen. Mit der Crypto Agility Plane (CAP) deklarieren Entwicklerinnen und Entwickler eine Datenklasse und einen Zweck statt eines Algorithmus. Eine zentrale Mandantenrichtlinie bestimmt zur Laufzeit den Algorithmus, die Post-Quanten-Ausrichtung (classical, hybrid oder pqc_only), die Schlüsselreferenz und das Backend. Die hybride Ausrichtung mit ML-KEM und ML-DSA ist standardmässig verfügbar. Der Wechsel zu reinem PQC ist eine Änderung der Richtlinie; der Anwendungscode ändert sich nicht.
• Schlüssel bleiben in Ihren Backends. CAP hält kein Schlüsselmaterial. Es erreicht die Backends über PKCS#11 und KMIP, darunter Securosys-HSMs, Azure Key Vault, AWS KMS, Google Cloud KMS, HashiCorp Vault und OpenBao. MPC ist ein optionales Vault-Backend für die Schwellenwert-Verwahrung von Schlüsseln, bei der kein einzelner Host einen vollständigen Schlüssel hält. Welche Backends ML-KEM-Schlüssel nativ halten, hängt von der Unterstützung des jeweiligen Backends ab.
• Eine Konsole und ein Audit-Trail. DuoKey Cockpit bietet RBAC und ABAC, Mandantentrennung und ein kryptografisch verkettetes Audit-Log.

CAP läuft heute auf DuoKey Cockpit über eine REST-API sowie Referenz-Clients für Java/Spring Boot und .NET/EF Core; paketierte SDKs stehen auf der Roadmap. Für alles, was hier nicht aufgeführt ist, etwa die ML-KEM-Unterstützung eines bestimmten HSM-Modells, wenden Sie sich an DuoKey.

---

FAQ

Q: Was ist ML-KEM-Schlüsselverwaltung?

Sie umfasst die Kontrollen für das Erzeugen, Speichern, Verteilen, Rotieren, Sichern und Vernichten von ML-KEM-Schlüsseln, den in FIPS 203 definierten Post-Quanten-KEM-Schlüsseln. Ephemere Schlüssel in hybridem TLS erfordern nur eine korrekte Konfiguration; statische Schlüssel brauchen ein vollständiges Lebenszyklusmanagement in einem KMS oder HSM, einschliesslich des Schutzes des 64-Byte-Seeds.

Q: Ersetzt ML-KEM RSA?

Teilweise. ML-KEM ersetzt RSA (und ECDH) für den Schlüsselaustausch: Schlüsseltransport und Schlüsselvereinbarung. RSA-Signaturen ersetzt es nicht; dafür hat NIST ML-DSA (FIPS 204) und SLH-DSA (FIPS 205) standardisiert. Während des Übergangs wird ML-KEM meist hybrid mit X25519 oder ECDH kombiniert.

Q: Was ist X25519MLKEM768?

Eine hybride Schlüsselaustauschgruppe für TLS 1.3, die ML-KEM-768 mit X25519 kombiniert, standardisiert in RFC 10024 mit dem Code Point 0x11EC. Der Client-Share umfasst 1216 Bytes, der Server-Share 1120 Bytes und das kombinierte gemeinsame Geheimnis 64 Bytes. OpenSSL 3.5 bietet die Gruppe standardmässig an.

Q: Kann ein HSM ML-KEM-Schlüssel speichern?

Das hängt vom HSM und seiner Firmware ab. Der Standard PKCS#11 3.2 (OASIS Standard, Juni 2026) definiert ML-KEM-Schlüsselobjekte (CKK_ML_KEM), einen Mechanismus zur Erzeugung von Schlüsselpaaren (CKM_ML_KEM_KEY_PAIR_GEN), C_EncapsulateKey und C_DecapsulateKey sowie Attribute sowohl für den Seed (CKA_SEED) als auch für den Entkapselungsschlüssel (CKA_VALUE). Ob ein bestimmtes HSM diese umsetzt und mit welchem Validierungsstatus, müssen Sie beim jeweiligen Hersteller erfragen.

Q: Soll ich den ML-KEM-Seed oder den Entkapselungsschlüssel speichern?

Beides ist zulässig. FIPS 203 erlaubt, den 64-Byte-Seed zu speichern und das Schlüsselpaar neu abzuleiten, sofern der Seed dieselben Schutzmassnahmen erhält wie der Entkapselungsschlüssel. Wählen Sie pro System ein kanonisches Format und stellen Sie sicher, dass sich Ihr Backup-Format dort importieren lässt, wo Sie es wiederherstellen würden.

Q: Welchen ML-KEM-Parametersatz soll ich verwenden?

NIST empfiehlt ML-KEM-768 als Standard und rät zum stärksten praktikablen Parametersatz. Verwenden Sie ML-KEM-1024, wo CNSA 2.0 gilt oder Ihre Richtlinie die Sicherheitskategorie 5 verlangt.

Q: Brauche ich neue Zertifikate, um ML-KEM in TLS zu nutzen?

Nicht für den hybriden Schlüsselaustausch. X25519MLKEM768 ändert den Schlüsselaustausch, nicht die Authentisierung; Ihre bestehenden RSA- oder ECDSA-Zertifikate funktionieren weiter. Zertifikate ändern sich erst, wenn Sie die Signaturen auf ML-DSA migrieren.

---

Fazit: Checkliste zur ML-KEM-Schlüsselverwaltung

ML-KEM verändert die Schlüsselverwaltung weniger, als die Schlüsselgrössen vermuten lassen, sofern Sie die beiden Fälle trennen. Ephemere Schlüssel in hybridem TLS sind eine Konfigurationsaufgabe, die Sie noch in diesem Quartal angehen können. Statische Schlüssel brauchen eine Richtlinie, die den Seed, die KEM-Schnittstelle und den Besitznachweis abdeckt.

• Ein Inventar zeigt, wo RSA- und ECDH-Schlüsselaustausch eingesetzt wird
• X25519MLKEM768 ist auf den Endpunkten, die Sie kontrollieren, aktiviert und überwacht
• Statische ML-KEM-Anwendungsfälle sind erfasst, jeweils mit einer verantwortlichen Person
• Für jedes KMS und HSM liegt eine datierte Angabe zur Unterstützung von ML-KEM-Schlüsseln und Kapselung/Entkapselung vor
• Die Richtlinie legt Parametersatz, Speicherformat (Seed, dk oder beides), Kryptoperiode, Backup und Vernichtung fest
• Seeds sind mit denselben Kontrollen geschützt wie Entkapselungsschlüssel
• Die Wahl des Algorithmus wird per Richtlinie gesteuert, nicht in Anwendungen fest codiert
• Die Migrationstermine folgen NIST IR 8547 und, wo relevant, CNSA 2.0

---

Referenzen

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST SP 800-227: Recommendations for Key-Encapsulation Mechanisms
• NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards
• RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
• IETF Datatracker: draft-ietf-tls-ecdhe-mlkem
• OASIS PKCS #11 Specification Version 3.2
• IETF Internet-Draft: CNSA 2.0 TLS profile (draft-becker-cnsa2-tls-profile-05)
• OpenSSL 3.5 release notes
• OpenSSL 3.5: EVP_PKEY-ML-KEM
• DuoKey Docs: Crypto Agility Plane SDK
• DuoKey Docs: PQC Scanner