Warum Post-Quanten-Vertrauen in der Hardware beginnt

Veröffentlicht: September 2025. Aktualisiert: August 2026. Geprüft von den Teams HSM Services und PQC Advisory von Encryption Consulting.

Jeder Plan zur Migration in die Post-Quanten-Technologie stößt irgendwann an dieselbe Grenze: Der Algorithmus lässt sich standardisieren, die Anwendung patchen und die Zertifikatsrichtlinie überarbeiten – all das ist jedoch bedeutungslos, wenn der private Schlüssel, auf dem alles basiert, auf Hardware generiert, gespeichert oder signiert wurde, deren korrekte Ausführung nicht gewährleistet ist. Selbst eine Softwarebibliothek, die Post-Quanten-Kryptographie (PQC) perfekt implementiert, kann durch einen über einen Seitenkanal kompromittierten Schlüssel, einen nicht wirklich zufälligen Zufallszahlengenerator oder eine Firmware, die unter Last stillschweigend auf einen klassischen Algorithmus zurückgreift, angreifbar sein. Deshalb muss das Vertrauen in die Post-Quanten-Technologie bereits in der Hardware selbst verankert sein, genauer gesagt im Hardware-Sicherheitsmodul (HSM) , das die Schlüsselgenerierung und -signierung für alle nachfolgenden Komponenten steuert.

Dies ist nun relevant, da die Standards nicht mehr nur theoretisch sind. Das NIST finalisierte FIPS 203 (ML-KEM) , FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) am 13. August 2024, und HSM-Anbieter haben das vergangene Jahr damit verbracht, diese Standardisierung in auslieferbare Firmware umzusetzen. Die verbleibende Frage für die meisten Unternehmen ist nicht, welchen Algorithmus sie wählen sollen, sondern ob die Hardware ihrer PKI, TLS-Terminatoren, Codesignierungspipeline und Schlüsselverwaltungssysteme diese Algorithmen innerhalb einer validierten Sicherheitsgrenze im Produktionsmaßstab ausführen kann, ohne die Verfügbarkeit zu beeinträchtigen.

Warum beginnt die Vorbereitung auf die Zeit nach der Quantenbeschleunigung auf der Hardware- und HSM-Ebene?

Die PQC-Bereitschaft beginnt auf Hardwareebene, da das HSM die Vertrauensbasis für jeden Schlüssel bildet, den der Algorithmus jemals verwendet. Ist das Modul, das einen ML-KEM- oder ML-DSA-Schlüssel generiert, speichert und verwendet, selbst nicht vertrauenswürdig, ist die mathematische Stärke des Algorithmus irrelevant. Vier Hardware-Garantien gelten direkt für die PQC-Ära, und jede einzelne ändert sich auf spezifische, überprüfbare Weise, sobald größere Post-Quantum-Schlüssel zum Einsatz kommen.

• Unveränderliche Geräteidentität. Eine hardwaregebundene Identität, die weder geklont noch gefälscht werden kann, authentifiziert das HSM gegenüber den davon abhängigen Systemen. Im Kontext der Post-Quanten-Technologie muss diese Identität zunehmend mit einem quantenresistenten Algorithmus signiert werden, damit ein Angreifer mit zukünftigen Quantenfähigkeiten sie nicht nachträglich fälschen kann.
• Manipulationssichere Schlüsselaufbewahrung. Schlüssel, die innerhalb der kryptografischen Grenzen des HSM generiert und verwendet werden, werden niemals im Klartext gespeichert. Dies ist bei PQC besonders wichtig, da die privaten Schlüssel von ML-DSA und SLH-DSA sowie der für einige Signaturverfahren erforderliche Betriebszustand umfangreicher und im Falle einer Kompromittierung aufwändiger wiederherzustellen sind.
• Echte Zufallszahlengenerierung. Gitterbasierte Verfahren wie ML-KEM und ML-DSA benötigen hochwertige Entropie für die Schlüsselerzeugung und, in manchen Implementierungen, für die randomisierte Signatur. Ein Hardware-basierter echter Zufallszahlengenerator (TRNG), der physikalisches Rauschen nutzt, ist eine solidere Grundlage für PQC-Schlüsselmaterial als ein Software-Pseudozufallszahlengenerator.
• Sicheres Booten und Firmware-Signierung. Das HSM validiert seine eigene Firmware vor dem Start. Da PQC-Firmware-Updates immer häufiger durchgeführt werden, muss Secure Boot diese Updates mit quantenresistenten Signaturen verifizieren. Genau dafür schreibt CNSA 2.0 LMS, XMSS oder ML-DSA im Kontext der Firmware- und Softwaresignatur vor.

Keine dieser vier Garantien ist neu. Was sich im PQC-Zeitalter ändert, ist die Größe und Form des Materials, das sie schützen, und genau hier zeigen sich die meisten Lücken in der PQC-Bereitschaft in produktiven HSM-Systemen.

CBOM Secure

Erhalten Sie vollständige Transparenz durch kontinuierliche kryptografische Erkennung, automatisierte Inventarisierung und datengesteuerte PQC-Sanierung.

Demo buchen

Wie ist der aktuelle Stand der PQC-Unterstützung von HSM-Anbietern?

Alle drei großen HSM-Anbieter, Thales, Entrust und Utimaco, liefern nun NIST CAVP-validierte ML-KEM- und ML-DSA-Unterstützung in ihrer aktuellen Firmware aus – als Upgrade und nicht als Hardware-Austausch. Unterschiede bestehen weiterhin bei der Unterstützung von SLH-DSA und zustandsbehafteten Hash-basierten Signaturverfahren. Die FIPS 140-3-Modulvalidierung, die PQC-Algorithmen innerhalb der zertifizierten Grenzen kombiniert und nicht nur die Algorithmen isoliert betrachtet, ist das neueste und wichtigste Unterscheidungsmerkmal.

Anbieter und Produktlinie	PQC-Algorithmen Versand	Zustellungsmethode	FIPS 140-3 Status (Stand: Aktualisierung)
Thales Luna HSM (Firmware 7.9, Juli 2025)	ML-KEM (FIPS 203), ML-DSA (FIPS 204), hybrides PQC für Backup und Schlüsselsynchronisierung	Firmware-Upgrade für bestehende Luna-Hardware, kein externes Funktionsmodul erforderlich	Die Validierung nach FIPS 140-3 Level 3 ist laut Bericht zum Zeitpunkt der Veröffentlichung im Gange.
Thales Trusted Cyber ​​Technologies Luna T-Serie (Firmware 7.15.1, Zertifikat 5450)	ML-DSA, ML-KEM, LMS, das vollständige CNSA 2.0 PQC-Set	In den USA hergestellte Luna PCIe HSM, Luna Network HSM, Luna as a Service, CipherTrust Manager	FIPS 140-3 Level 3 validiert (Stand: August 2026), die erste HSM-Produktlinie, die alle CNSA 2.0 PQC-Algorithmen in einer FIPS 140-3-Validierung vereint
Thales Luna 8 (angekündigt im August 2026)	Klassische und Post-Quanten-Algorithmen auf einem kundenspezifischen kryptografischen Prozessor	Neue Hardwaregeneration, speziell entwickelt für PQC- und KI-Workloads	Die Bewertung nach FIPS 140-3 Level 3 und den Common Criteria ist im Gange und zum Zeitpunkt der Bekanntgabe noch nicht abgeschlossen.
Entrust nShield (Firmware 13.8.0, veröffentlicht am 22. August 2025)	ML-DSA, ML-KEM, SLH-DSA, alle drei NIST CAVP-validiert	Native Firmware-Unterstützung, angekündigt mit NIST CAVP-Validierung am 10. September 2025	Die Validierung des CAVP-Algorithmus wurde bestätigt; bitte prüfen Sie vor der Beschaffung den aktuellen FIPS 140-3-Status auf Modulebene.
Utimaco u.trust GP HSM (Se-Serie und CSe-Serie)	ML-DSA (FIPS 204), ML-KEM (FIPS 203), LMS, mit SLH-DSA auf der Roadmap	Quantum Protect-Anwendungspaket, auf vorhandener Hardware aktiviert, kein Hardwaretausch erforderlich	Die Validierung der CAVP-Algorithmen auf Algorithmenebene wurde für die Auslieferung von Algorithmen bestätigt; beinhaltet ein proprietäres Zustandsverwaltungsdesign für LMS und XMSS in HA- und Backup-Szenarien.

Zwei Punkte sind hier besonders wichtig. Erstens: Algorithmusvalidierung und Modulvalidierung sind nicht dasselbe. Die CAVP-Ankündigung eines Anbieters als Beweis dafür zu werten, dass ein bestimmtes HSM-Gerät vollständig FIPS 140-3-validiert ist und PQC innerhalb der Grenzen implementiert hat, ist ein häufiger Fehler bei der Beschaffung. Encryption Consulting erläutert diesen Unterschied ausführlich in „ Sind Ihre HSMs PQC-fähig?“ . Zweitens: Die Unterstützung von SLH-DSA (FIPS 205) ist tatsächlich uneinheitlich: Entrust hat es validiert, Utimaco führt es als Roadmap auf, und die für dieses Update überprüften Thales-Quellen bestätigen es nicht in der ausgelieferten Firmware. Wenn Ihre PQC-Roadmap speziell auf SLH-DSA basiert, beispielsweise als konservativer Hash-basierter Fallback für langlebige Signaturschlüssel, sollten Sie den aktuellen Status des Anbieters direkt überprüfen, bevor Sie sich für eine Plattform entscheiden.

Was ist Krypto-Agilität auf Hardwareebene und warum ist sie wichtig?

Kryptoagilität auf Hardwareebene bedeutet, dass ein HSM neue Algorithmen per Firmware-Update und modularem SDK integrieren kann, ohne dass die Hardware ausgetauscht oder die zugehörigen Anwendungen neu entwickelt werden müssen. Die oben genannten Firmware-Updates von Thales, Entrust und Utimaco belegen dies eindrucksvoll: Alle drei Unternehmen haben ML-KEM und ML-DSA in bereits vorhandene Kundenhardware integriert – per Upgrade statt durch kompletten Hardwareaustausch.

Die Hardware-Krypto-Agilität hängt von einigen spezifischen Designentscheidungen ab, die bei jeder HSM-Beschaffungs- oder Erneuerungsentscheidung überprüft werden sollten:

• Firmware-Aktualisierungsmechanismus. Kann die Unterstützung neuer Algorithmen als signiertes Firmware-Update bereitgestellt werden, und ist dieser Update-Prozess selbst durch eine quantenresistente Signatur geschützt, sodass er während des Übergangs nicht gefälscht werden kann?
• Modulare kryptografische Anbieter. Ist die PQC-Unterstützung in die Kernfirmware integriert, wie beim Thales Luna-Ansatz, oder wird sie als separates Anwendungspaket bereitgestellt, wie bei Utimacos Quantum Protect? Beide Modelle funktionieren, die Beschaffungs- und Lizenzierungsanforderungen unterscheiden sich jedoch.
• API- und Standardkonformität. Stellt das HSM PQC-Operationen über aktuelle PKCS#11-Mechanismus-Identifikatoren und SDK-Versionen der Anbieter bereit, die Ihre Anwendungen bereits verwenden, oder ist ein paralleler Integrationspfad erforderlich?
• Spielraum für den nächsten Standard. Das NIST evaluiert weiterhin zusätzliche Signaturverfahren, die über die drei ursprünglichen FIPS-Standards hinausgehen. Eine flexible HSM-Plattform sollte in der Lage sein, eine vierte Algorithmenfamilie ohne einen weiteren Hardwarezyklus zu integrieren.

Krypto-Agilität ist eine Absicherung, kein Endziel. Ein HSM, das theoretisch aktualisiert werden kann, ist in der Praxis nur dann agil, wenn Ihr Unternehmen über den Firmware-Update-Prozess, die Testumgebung und die Disziplin im Änderungsmanagement verfügt, um das Upgrade tatsächlich durchzuführen, bevor die geschützten Algorithmen zur Schwachstelle werden.

Wie sieht eine hybride Bereitstellungstopologie aus klassischem HSM und PQC aus?

Kaum eine Organisation wechselt direkt von rein klassischen zu PQC-nativen HSM-Operationen. In der realen Einsatztopologie laufen klassische und Post-Quanten-Algorithmen parallel im selben HSM-Cluster während eines mehrjährigen Übergangszeitraums. Dabei werden hybride Schlüsselaustauschverfahren und, sofern die Anwendung dies unterstützt, duale oder zusammengesetzte Signaturen verwendet.

Eine typische Hybridtopologie besteht aus drei Schichten:

1. Die HSM-Clusterschicht. Ein hochverfügbarer HSM-Cluster, egal ob es sich um lokale Appliances, Cloud-HSM-Instanzen oder eine HSM-as-a-Service Die Bereitstellung beinhaltet eine Firmware, die sowohl klassische (RSA, ECC) als auch PQC-Algorithmen (ML-KEM, ML-DSA) gleichzeitig unterstützt, mit Partitionierung, sodass verschiedene Anwendungsgruppen nach unabhängigen Zeitplänen migriert werden können.
2. Die Protokollschicht. TLS-Terminatoren und PKI-Ausstellungssysteme verhandeln einen hybriden Schlüsselaustausch, beispielsweise X25519 in Kombination mit ML-KEM-768, sodass eine Sitzung auch dann sicher bleibt, wenn entweder die klassische oder die Post-Quantum-Komponente kompromittiert wird. Zertifizierungsstellen stellen kombinierte oder duale Zertifikate aus, sofern die Client-Umgebung diese unterstützt, und greifen auf rein klassische Zertifikate zurück, wenn Clients noch keinen Post-Quantum-Schlüsselaustausch (PQC) durchführen.
3. Die Anwendungsschicht. Für die Code-Signierung, die Datenbankverschlüsselung und Workflows zur Signatur von Dokumenten mit langer Lebensdauer wird das HSM aufgerufen, um je nach Anwendungsfall den geeigneten Algorithmus zu ermitteln. Dabei wird berücksichtigt, wie lange die Signatur oder der Chiffretext vertrauenswürdig bleiben muss, anstatt alle Arbeitslasten am selben Tag auf PQC umzustellen.

Die Entscheidung, welche Schicht zuerst migriert werden soll, sollte sich nach dem Gefährdungspotenzial richten, nicht nach der Bequemlichkeit. Schlüsselaustauschverfahren zur Verschlüsselung (TLS-Sitzungsschlüssel, VPN-Tunnel, verschlüsselte Backups) sind heute anfällig für Angriffe, bei denen der verschlüsselte Text abgefangen und später entschlüsselt werden kann, sobald ein kryptografisch geeigneter Quantencomputer existiert. Digitale Signaturen zur Authentifizierung bergen ein anderes Risikoprofil: Eine heute validierte Signatur verliert ihre Gültigkeit nicht rückwirkend. Daher können Signaturprozesse in der Regel etwas später als Verschlüsselungsprozesse durchgeführt werden. Eine wichtige Ausnahme bilden langlebige Code- und Firmware-Signaturschlüssel, bei denen eine gefälschte Signatur auch Jahre später noch Schaden anrichten würde. Diese auf dem Gefährdungspotenzial basierende Priorisierung entspricht der Logik, die Encryption Consulting in „RSA: Secure Today, Scheduled for Retirement“ anwendet . Dort wird die Migration aus der Perspektive klassischer Algorithmen erläutert.

Wie ist die FIPS 140-3-Grenze auf PQC-validierte HSMs anzuwenden?

Die Validierung nach FIPS 140-3 bezieht sich auf die Grenzen eines definierten kryptografischen Moduls, nicht auf einen abstrakten Algorithmus. Diese Unterscheidung ist der am häufigsten missverstandene Aspekt bei der Beschaffung von HSM-PQC. Das Cryptographic Algorithm Validation Program (CAVP) des NIST prüft die mathematische Korrektheit einer Implementierung von ML-KEM oder ML-DSA. Das Cryptographic Module Validation Program (CMVP) des NIST prüft hingegen, ob das gesamte Hardware- und Firmware-Modul, einschließlich der Algorithmusimplementierung, des Schlüsselmanagements, des Schutzes vor physischer Manipulation und der Selbsttests, als Einheit die Anforderungen von FIPS 140-3 erfüllt. Ein Anbieter kann bereits ein gültiges CAVP-Zertifikat für ML-KEM besitzen, lange bevor das HSM-Gerät, auf dem es läuft, über ein aktualisiertes FIPS 140-3-Modulzertifikat verfügt, das die PQC-Operationen innerhalb der Grenzen abdeckt.

Diese Lücke ist nicht hypothetisch. Das Firmware-Update für Thales Luna vom Juli 2025 enthielt Unterstützung für ML-KEM und ML-DSA, wobei die Validierung nach FIPS 140-3 Level 3 als in Bearbeitung beschrieben wurde. Das bedeutet, dass die Algorithmen verfügbar waren, bevor das Modulzertifikat, das sie abdeckte, fertiggestellt war. Erst im August 2026 war die Luna T-Serie von Thales Trusted Cyber ​​Technologies mit Firmware 7.15.1 und Zertifikat 5450 die erste dokumentierte HSM-Produktlinie, die den vollständigen CNSA 2.0 PQC-Algorithmensatz (ML-DSA, ML-KEM und LMS) in einer abgeschlossenen FIPS 140-3 Level 3-Validierung vereinte. Zwischen der Verfügbarkeit der Algorithmen und der Validierung der Modulgrenzen, die regulierte Käufer im Rahmen eines Audits anführen können, verging also etwa ein Jahr.

Für Organisationen in regulierten Umgebungen (DFARS, FedRAMP, PCI DSS oder Behörden gemäß CNSA 2.0) gilt folgende Faustregel: Die Ankündigung eines Anbieters zu einem PQC-Algorithmus ist nicht gleichbedeutend mit einem validierten Modul, das Sie in einer regulierten Arbeitslast einsetzen können. Fragen Sie gezielt nach der FIPS-140-3-Zertifikatsnummer, die die von Ihnen geplante Firmware-Version abdeckt, und vergewissern Sie sich, dass die Liste der validierten Algorithmen dieses Zertifikats die von Ihnen vorgesehenen PQC-Algorithmen enthält und nicht nur die ursprünglichen klassischen Algorithmen des Moduls.

Welche Änderungen gibt es bei der Schlüsselzeremonie für die PQC-Schlüsselgenerierung?

Eine PQC-Schlüsselzeremonie folgt der gleichen Governance-Struktur wie eine klassische Zeremonie, Doppelkontrolle, bezeugte Erzeugung, dokumentierte Verwahrerrollen, aber die technischen Details innerhalb dieser Zeremonie ändern sich auf eine Weise, die ein für RSA oder ECC geschriebenes Skript nicht berücksichtigen kann.

• Größeres Schlüssel- und Unterschriftenmaterial. Ein ML-KEM-768-Schlüssel hat eine Größe von etwa 1.2 KB, während ein ML-DSA-65-Schlüssel samt Signatur zusammen mehrere Kilobyte umfasst. Im Vergleich dazu ist ein ECC-Schlüssel gleicher Stärke nur 32 bis 64 Byte groß. Zeremonieskripte, die Planung der Speicherkapazität für Backup-Medien und alle Prozesse, die Schlüsselfingerabdrücke manuell transkribieren oder verifizieren, müssen dies vor der Zeremonie berücksichtigen, nicht erst währenddessen.
• Entropieanforderungen. Die gitterbasierte Schlüsselerzeugung benötigt pro Operation mehr Entropie als die ECC-Schlüsselerzeugung. Stellen Sie sicher, dass der Hardware-TRNG-Durchsatz des HSM für die in Ihrem Zeremonienplan geforderten PQC-Schlüsselerzeugungsvolumina validiert ist, insbesondere für Massen-Schlüsselerzeugungsereignisse im Vorfeld einer Migrationswelle.
• Stateful hash-basierte Signaturen benötigen State-Disziplin, nicht nur Key-Disziplin. Die zustandsbehafteten Hash-basierten Verfahren LMS und XMSS, die CNSA 2.0 für die Signierung von Firmware und Software zulässt, erzeugen eine feste Anzahl von Einmalsignaturen pro Schlüssel. Die Verfahren müssen dokumentieren, wie der Signaturstatus des privaten Schlüssels verfolgt und niemals wiederverwendet wird, auch nicht bei Backups oder Kopien dieses Schlüssels, da die Wiederverwendung einer Einmalsignatur die Sicherheitsgarantie vollständig aufhebt.
• Ablauf der Zeremonie und Schulung der Zeugen. Zeugen und Verwahrer, die in RSA- und ECC-Zeremonien geschult sind, benötigen eine kurze, spezifische Einweisung in die Frage, was ein PQC-Zeremonie-Verifizierungsschritt tatsächlich bestätigt, da der visuelle Vergleich eines mehrere Kilobyte langen öffentlichen Schlüsselfingerabdrucks nicht dasselbe ist wie der Vergleich eines kurzen ECC-Fingerabdrucks.

Wie beurteilen Sie die PQC-Bereitschaft in Ihrem gesamten HSM-System?

Eine strukturierte Bewertung klärt, ob jedes HSM in Ihrer Umgebung PQC bereits heute ausführen kann, ob ein Upgrade dafür möglich ist oder ob es vor dem Migrationstermin ersetzt werden muss. Encryption Consulting führt diesen Prozess in fünf Schritten durch:

1. Erfassen Sie alle HSMs und deren Firmware-Versionen. Erstellen Sie ein vollständiges Inventar der kryptografischen Assets, das lokale Appliances, Cloud-HSM-Instanzen und eingebettete Module, das Aufzeichnungsmodell, die Firmware-Version und den aktuellen FIPS 140-3-Zertifikatsstatus für jedes Asset umfasst.
2. Die Nutzung von Kartenalgorithmen wird mit der Geschäftsgefährdung in Verbindung gebracht. Ermitteln Sie, welche HSMs den Schlüsselaustausch für langlebige vertrauliche Daten (Erfassung-jetzt-Entschlüsselung-später-Exposition) im Vergleich zu Signaturen für langlebige Vertrauensartefakte wie Root-CAs und Firmware-Signaturschlüssel schützen, da diese unterschiedliche Migrationsdringlichkeiten bedingen.
3. Bitte bestätigen Sie den PQC-Fahrplan des Anbieters und den Validierungsstatus pro Modell. Für jedes HSM-Modell im Bestand ist die aktuelle Firmware-Verfügbarkeit von ML-KEM, ML-DSA und, falls erforderlich, SLH-DSA oder LMS/XMSS sowie das FIPS 140-3-Zertifikat, das diese Firmware abdeckt, zu bestätigen, nicht nur die allgemeine PQC-Ankündigung des Herstellers.
4. Test des Hybridbetriebs in einer Nicht-Produktionsumgebung. Vor der Inbetriebnahme sollten Firmware-Upgrades, der hybride Schlüsselaustausch sowie die Verarbeitung größerer Schlüssel und Signaturen anhand des realen Anwendungsdatenverkehrs validiert werden, einschließlich Durchsatz und Latenz unter der erwarteten Last.
5. Erstellen Sie den stufenweisen Migrations- und Stilllegungsplan. Führen Sie Upgrades nach Expositions- und Geschäftsrisiko durch, kennzeichnen Sie alle HSMs, die die PQC-Bereitschaft nicht durch Firmware erreichen können und ersetzt werden müssen, und legen Sie Außerbetriebnahmetermine fest, die mit Ihrem CNSA 2.0- oder internen Compliance-Zeitplan übereinstimmen.

Welche Hochverfügbarkeits- und Backup-Überlegungen gelten für PQC-fähige HSMs?

Das Design von Hochverfügbarkeit und Backup für PQC-fähige HSMs muss zwei Probleme lösen, die das klassische HSM-Clustering nicht lösen konnte: größere Schlüsselmengen, die zwischen Cluster-Mitgliedern verschoben werden, und – bei zustandsbehafteten Hash-basierten Signaturen – die Verhinderung, dass ein Backup- oder Failover-Ereignis jemals einen Signaturzustand wiederverwendet.

Standardmäßige HSM-Cluster replizieren Schlüssel zwischen den Mitgliedern, sodass ein Knotenausfall Signier- oder Entschlüsselungsvorgänge nicht unterbricht. Bei ML-KEM und ML-DSA verschiebt diese Replikation lediglich mehr Daten pro Schlüssel, was eine Frage der Kapazitäts- und Bandbreitenplanung und kein strukturelles Problem darstellt. LMS und XMSS sind komplexer: Wenn ein Cluster auf ein Backup umschaltet, dessen Ansicht darüber, welche Einmalsignatur-Knoten bereits verwendet wurden, nicht synchronisiert ist, kann derselbe Knoten zweimal signiert werden, wodurch die Sicherheitsgarantie des Algorithmus vollständig verletzt wird. Utimacos Quantum Protect-Paket begegnet diesem Problem direkt mit einem – laut Hersteller – patentierten Zustandsverwaltungsansatz, der speziell für Hochverfügbarkeits- und Backup-Szenarien mit zustandsbehafteten Algorithmen entwickelt wurde. Jeder Anbieter oder jede HSM-Plattform, die Sie hinsichtlich der Unterstützung von LMS oder XMSS evaluieren, sollte Ihnen in konkreten technischen Begriffen erklären können, wie die Wiederverwendung von Zuständen bei Cluster-Failover und Backup-Wiederherstellung verhindert wird, und nicht nur die Unterstützung des Algorithmus bestätigen.

Die Backup- und Wiederherstellungsverfahren erfordern aktualisierte Kapazitäts- und Zeitannahmen. Größere PQC-Schlüssel und Signaturmaterialien bedeuten, dass Backup-Medien, verschlüsselte Exportdateien und Wiederherstellungsfenster neu ausgelegt werden müssen, anstatt weiterhin von den Größen- und Zeitvorgaben der klassischen Ära auszugehen.

Welche Integrationsvoraussetzungen müssen erfüllt sein, bevor PQC auf produktiven HSMs aktiviert werden kann?

Bevor Sie den PQC-Betrieb auf einem produktiven HSM aktivieren, vergewissern Sie sich, dass diese Voraussetzungen erfüllt sind, da eine fehlende Voraussetzung ein geplantes Upgrade in einen Ausfall verwandelt:

• Client SDK- und PKCS#11-Provider-Versionen. Anwendungen integrieren sich über eine Clientbibliothek und PKCS#11 oder ein herstellerspezifisches SDK mit dem HSM; diese Bibliothek benötigt vor dem Firmware-Upgrade eine Version, die die neuen PQC-Mechanismus-Kennungen erkennt, andernfalls schlagen die Aufrufe fehl, obwohl die HSM-Firmware den Algorithmus unterstützt.
• PKI- und CA-Softwarekompatibilität. Ihre Zertifizierungsstellensoftware, ob lokal oder extern, verwaltete PKI-als-Dienstleistung Die Plattform oder eine öffentliche CA-Integration muss die Ausstellung von Zertifikaten gegen PQC- oder hybride öffentliche Schlüssel unterstützen, bevor diese Schlüssel im Produktiveinsatz verwendet werden können.
• Unterstützung bei Netzwerk- und Protokollverhandlungen. TLS-Terminatoren, Load Balancer und VPN-Gateways im Datenpfad benötigen TLS-Stacks, die hybride Schlüsselaustauschgruppen unterstützen; ein HSM, das ML-KEM-Schlüssel generieren kann, hilft nicht, wenn nichts im Verbindungspfad diese aushandeln kann.
• MTU- und Fragmentierungsbehandlung. Größere PQC-Schlüssel und -Zertifikate erhöhen die Größe der TLS-Handshake-Nachrichten, was dazu führen kann, dass Handshakes die MTU-Grenzen des Pfades auf einigen Netzwerkpfaden überschreiten und Fehler in der Fragmentierungsbehandlung älterer Netzwerkgeräte aufdecken, die bei Handshakes klassischer Größe nie aufgetreten sind.
• Überwachung und Benachrichtigungsaktualisierungen. Für die klassische Schlüsselerzeugung und Signaturlatenz abgestimmte operative Dashboards und Alarmschwellenwerte benötigen aktualisierte Baselines, da PQC-Operationen einen anderen, im Allgemeinen höheren Rechenaufwand pro Operation verursachen.

Eine kryptografische Erkennungs- und Inventarisierungsplattform ist der schnellste Weg, diese Voraussetzungen in einem großen System zu bestätigen, anstatt jede Anwendung einzeln zu prüfen; genau diese Lücke soll CBOM Secure schließen.

Welche Fehlerszenarien sollten Sie einplanen?

Die meisten Hardware-Fehler im Bereich der Prozessqualitätskontrolle lassen sich in wenige, vorhersehbare Kategorien einteilen. Eine entsprechende Planung vor der Migration verringert das Risiko ungeplanter Ausfälle oder von Compliance-Lücken, die bei einem Audit entdeckt werden.

Fehlermodus	Warum es passiert	Mitigation
Die Firmware für PQC kann nicht aktualisiert werden.	Für HSM-Hardware, deren Lebenszyklus oder Support eingestellt wurde, wird vom Hersteller niemals ein PQC-Firmware-Update veröffentlicht.	Firmware-Enddaten für Lagerbestände jetzt verfügbar; kostengünstige Hardware-Aktualisierung für alle Modelle ohne bestätigten PQC-Firmware-Roadmap
Durchsatz und Latenz verschlechtern sich unter PQC-Last.	ML-DSA-Signierung und die Verwaltung größerer Schlüssel benötigen pro Operation mehr Rechenleistung als RSA oder ECC auf derselben Hardware.	Führen Sie vor der Umstellung einen Lasttest des PQC-Betriebs unter dem erwarteten Produktionsvolumen durch; vergleichen Sie die vom Hersteller veröffentlichten Leistungsdaten mit Ihren eigenen Verkehrsmustern.
Wiederverwendung des Zustands der zustandsbehafteten Signatur während eines Failovers	HA-Cluster-Mitglieder oder Backup-Wiederherstellungen geraten aufgrund des LMS- oder XMSS-Einmalsignaturstatus außer Synchronisation.	Nutzen Sie HSM-Plattformen mit dokumentierten und getesteten Garantien zur Zustandssynchronisierung für zustandsbehaftete Algorithmen über Hochverfügbarkeit und Datensicherung hinweg.
Handshake oder Nachrichtengröße unterbrechen veraltete Netzwerkpfade	Größere PQC-Schlüssel und -Zertifikate überschreiten die MTU- oder Puffervorgaben älterer Netzwerkgeräte.	Testen Sie hybride TLS-Handshakes über den tatsächlichen Netzwerkpfad, einschließlich aller älteren Load Balancer oder Middleboxes, vor der Produktionsfreigabe.
Algorithmus validiert, aber Modulgrenze nicht	Die Validierung des CAVP-Algorithmus wird als gleichwertig mit einem abgeschlossenen FIPS 140-3-Modulzertifikat behandelt.	Bitte überprüfen Sie die spezifische FIPS 140-3-Zertifikatsnummer und die zugehörige Liste der validierten Algorithmen für die exakt eingesetzte Firmware-Version.
Inkompatibilität der Client- oder Anwendungsbibliothek	Der PKCS#11-Anbieter oder die SDK-Version ist älter als die PQC-Mechanismus-Kennungen, die die neue Firmware bereitstellt.	Aktualisieren und testen Sie Clientbibliotheken in einer Testumgebung vor dem Firmware-Upgrade, nicht parallel dazu.

Einschränkungen

• NIST IR 8547 ist zum Zeitpunkt dieser Aktualisierung noch ein erster öffentlicher Entwurf; die Kommentierungsfrist endete am 10. Januar 2025, und der darin vorgeschlagene Übergangszeitplan ist noch nicht endgültig festgelegt und kann sich noch ändern.
• Die Unterstützung von PQC durch die Hersteller und der Status der FIPS 140-3-Zertifizierung ändern sich häufig. Die Herstellerangaben in diesem Artikel basieren auf öffentlich verfügbaren Informationen zum Zeitpunkt dieser Aktualisierung. Bitte bestätigen Sie die genaue Firmware-Version und Zertifikatsnummer vor der Beschaffung oder dem Einsatz beim Hersteller.
• Die in CNSA 2.0 festgelegten verbindlichen Meilensteine ​​gelten direkt für US-amerikanische nationale Sicherheitssysteme; kommerzielle Unternehmen sind nicht an CNSA 2.0 gebunden, nutzen es aber häufig als Planungsreferenz für die Algorithmenauswahl und den Zeitplan.
• Die Leistungsdaten für PQC-Operationen variieren je nach HSM-Modell, Firmware-Version und Arbeitslast erheblich; betrachten Sie die hier angegebenen allgemeinen Hinweise als Ausgangspunkt für Ihre eigenen Lasttests und nicht als Ersatz dafür.

Was würde Encryption Consulting empfehlen?

Die HSM-Schicht sollte bei jeder PQC-Migration als erste und nicht als letzte Kontrollinstanz betrachtet werden. Konkret bedeutet dies, mit einer kryptografischen Bestandsaufnahme anstatt mit einem Algorithmus-Pilotprojekt zu beginnen, den FIPS-140-3-Modulstatus zu bestätigen, anstatt sich auf eine CAVP-Aussage zu verlassen, und die Schlüsselzeremonie sowie die Änderungen im HA-Runbook vorzunehmen, bevor ein einziger Produktionsschlüssel generiert wird.

Die PQC Advisory Services von Encryption Consulting setzen dabei einen strukturierten, neunphasigen Fahrplan um, der kryptografische Ermittlung, risikobasierte Priorisierung, Anbieter- und Hardwarebewertung, hybriden Architekturentwurf und stufenweise Implementierung umfasst, sodass die Hardware- und die Anwendungsschicht nach einem koordinierten Zeitplan und nicht unabhängig voneinander migriert werden.

Wo die Lücke speziell die Hardware betrifft, bewertet unser HSM-Services- Team die aktuelle HSM-Firmware und den FIPS-Validierungsstatus anhand Ihrer PQC-Anforderungen, führt Machbarkeitsstudien für hybride und PQC-native Konfigurationen durch und entwirft die für zustandsbehaftete Algorithmen erforderlichen Änderungen an Hochverfügbarkeit und Schlüsselverwaltung. Für Umgebungen, in denen das erste Problem schlichtweg darin besteht, nicht zu wissen, welche Komponenten wo eingesetzt sind, erstellt und pflegt CBOM Secure das kontinuierliche kryptografische Inventar, das alle nachfolgenden Schritte ermöglicht.

PQC-Beratungsdienste

Erreichen Sie die Post-Quanten-Bereitschaft mit einer von Experten geleiteten kryptografischen Bewertung, einer Migrationsstrategie und einer praktischen Implementierung gemäß den NIST-Standards.

Mehr erfahren

Fazit

Algorithmen stehen in den meisten Diskussionen um PQC im Vordergrund, doch die HSM-Schicht entscheidet darüber, ob diese Algorithmen in der Praxis vertrauenswürdig sind. Die Hardware muss PQC-Schlüssel mit echter Entropie generieren, sie innerhalb eines validierten Bereichs speichern, Firmware-Upgrades, die mit dem sich weiterentwickelnden Standard Schritt halten, standhalten und Hochverfügbarkeits- und Backup-Verfahren unterstützen, die die spezifischen Anforderungen zustandsbehafteter Signaturverfahren erfüllen. Thales, Entrust und Utimaco haben die Lücke bei der Algorithmenunterstützung im letzten Jahr weitgehend geschlossen, und die ersten FIPS 140-3-validierten Module, die die vollständige CNSA 2.0 PQC-Suite kombinieren, werden 2026 verfügbar sein. Was noch aussteht, ist der operative Betrieb: die Bestandsaufnahme der HSM-Infrastruktur, die Bestätigung der Validierung auf Modulebene anstelle von Ankündigungen auf Algorithmenebene und die Neuentwicklung von Schlüsselverwaltungs- und Hochverfügbarkeits-Runbooks für größere Schlüssel und, falls relevant, für Einmalsignaturen. Organisationen, die die Hardware-Schicht als Ausgangspunkt für die PQC-Migration und nicht als Nebenaspekt der Anwendungsschicht betrachten, werden zum Erreichen der relevanten Fristen optimal vorbereitet sein.

Häufig gestellte Fragen

Benötigen wir neue HSM-Hardware zur Unterstützung von PQC oder reicht ein Firmware-Upgrade aus? Für die meisten HSMs der aktuellen Generation genügt ein Firmware-Upgrade. Thales, Entrust und Utimaco haben bestehende Hardware bereits per Firmware-Update um ML-KEM- und ML-DSA-Unterstützung erweitert. Ältere oder abgekündigte HSM-Modelle, die kein PQC-Firmware-Update mehr erhalten werden, bilden die Ausnahme. Diese müssen identifiziert und der Austausch jetzt eingeplant werden.

Ist die Ankündigung eines PQC-Algorithmus durch einen Anbieter gleichbedeutend mit einem FIPS 140-3-validierten, PQC-fähigen Modul? Nein. Die Validierung des Algorithmus durch das CAVP-Programm des NIST und die Modulvalidierung durch CMVP sind separate Prozesse. Bei der aktuellen Generation von PQC-Firmware-Releases liegt üblicherweise ein Zeitraum von etwa einem Jahr zwischen den beiden Validierungen. Prüfen Sie die spezifische FIPS 140-3-Zertifikatsnummer für die Firmware-Version, die Sie einsetzen möchten.

Welchen PQC-Algorithmus sollte unser HSM zuerst unterstützen, ML-KEM oder ML-DSA? Die Priorisierung sollte sich nach dem Gefährdungspotenzial richten, nicht nach der Präferenz. ML-KEM schützt die Schlüsselerzeugung, die heute anfällig für Harvest-Now-Decrypt-Later-Angriffe ist. Dabei wird jeglicher Datenverkehr abgefangen und entschlüsselt, sobald ein kryptografisch geeigneter Quantencomputer existiert. ML-DSA schützt Signaturen. Hierbei öffnet sich das Zeitfenster für die meisten Anwendungsfälle erst später, außer bei langlebigen Code- und Firmware-Signaturschlüsseln, die mit ähnlicher Dringlichkeit wie die Schlüsselerzeugung behandelt werden sollten.

Benötigen LMS und XMSS eine andere Betriebsführung als ML-DSA? Ja. LMS und XMSS sind zustandsbehaftete, hashbasierte Signaturverfahren mit einer festen Anzahl von Einmalsignaturen pro Schlüssel. Die Wiederverwendung einer Signatur, die bei einem fehlerhaften HA-Failover oder der Wiederherstellung eines Backups auftreten kann, beeinträchtigt die Sicherheitsgarantie. ML-DSA und ML-KEM benötigen diese Zustandsverwaltung nicht.

Wie viel größer sind PQC-Schlüssel und -Signaturen im Vergleich zu RSA- oder ECC-Schlüsseln in der Praxis? Ein ML-KEM-768-Schlüssel ist etwa 1.2 KB groß, während ein ECC-Schlüssel gleicher Stärke etwa 32 bis 64 Byte umfasst. ML-DSA-Schlüssel und -Signaturen haben zusammen eine Größe von wenigen Kilobyte. Berücksichtigen Sie dies bei der Planung der Speicherkapazität von Backup-Medien, der Zertifikats- und Handshake-Größenbeschränkungen sowie bei allen Zeremonien, die Schlüsselmaterial manuell verifizieren.

Referenzen

• NIST FIPS 203, Modulgitterbasierter Schlüsselkapselungsmechanismus-Standard: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, Modulgitterbasierter digitaler Signaturstandard: https://csrc.nist.gov/pubs/fips/204/final
• NIST FIPS 205, Standard für zustandslose, Hash-basierte digitale Signaturen: https://csrc.nist.gov/pubs/fips/205/final
• NIST IR 8547 (Erster öffentlicher Entwurf, November 2024), Übergang zu Post-Quanten-Kryptographiestandards: https://csrc.nist.gov/pubs/ir/8547/ipd
• Leitfaden der NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0): https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
• Thales, Luna HSM v7.9 bietet PQC-Bereitschaft in großem Umfang: https://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
• Thales Trusted Cyber ​​Technologies, in den USA hergestelltes Post-Quantum-HSM erreicht FIPS 140-3 Level 3: https://www.thalestct.com/hsm-fips140-3-validation/
• Thales Group, Thales entwickelt kryptografische Sicherheit für das Zeitalter der KI und des Post-Quanten-Computing (Luna 8): https://www.thalesgroup.com/en/news-centre/press-releases/thales-builds-cryptographic-security-age-ai-and-post-quantum-computing
• Entrust, nShield HSMs Post-Quantum Cryptography Algorithms Achievement From the NIST Cryptographic Algorithm Validation Program: https://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
• Utimaco, Die Post-Quanten-Frist 2029: Können Ihre HSMs die Migration schaffen? https://utimaco.com/news/blog-posts/post-quantum-hsm-migration-2029