Während sich Organisationen auf die Ausstellung ihrer ersten Post-Quantum-Zertifikate vorbereiten, taucht immer wieder eine praktische und überraschende Frage auf: Benötigen PQC -Zertifikate ein spezielles „quantensicheres“ Hardware-Sicherheitsmodul, oder kommen die bereits im Einsatz befindlichen HSMs problemlos damit zurecht?
Das ist eine berechtigte Frage, und die Antwort ist weitaus interessanter als ein einfaches Ja oder Nein. Der Begriff „quantensicheres HSM“ taucht in der Werbung von Anbietern, in Beschaffungschecklisten und in Architekturdiskussionen immer wieder auf, oft ohne klare Definition seiner Bedeutung. Manche Organisationen gehen davon aus, dass ihre bestehenden HSMs mit dem Erhalt eines PQC-Zertifikats überflüssig werden. Andere wiederum nehmen das Gegenteil an: Ein HSM sei lediglich ein sicheres Gerät, dessen Algorithmen im Zertifikat keine Rolle spielten. Beide Annahmen sind aufschlussreich falsch.
Dieser Blog erklärt, was ein HSM tatsächlich leistet, was „quantensicher“ in diesem Zusammenhang bedeutet, warum diese Unterscheidung für den Schutz von PQC-Zertifikaten wichtig ist und was Sie tatsächlich überprüfen sollten, bevor Sie davon ausgehen, dass Ihre Hardware bereit ist.
Was ein HSM tatsächlich schützt
Um die privaten Schlüssel hinter PQC-Zertifikaten mit denselben Sicherheitsgarantien wie bei klassischen Schlüsseln zu generieren, zu speichern und zu verwenden, benötigen Sie ein HSM, das die verwendeten Post-Quanten-Algorithmen nativ unterstützt, insbesondere ML-DSA (FIPS 204) für Signaturen und ML-KEM (FIPS 203) für die Schlüsselerzeugung. Ein HSM, das diese Algorithmen nicht unterstützt, kann innerhalb seiner sicheren Grenzen keine PQC-Schlüsseloperationen durchführen, wodurch der gesamte Zweck des HSM-Einsatzes zunichtegemacht wird.
Der Begriff „quantensicheres HSM“ birgt jedoch viele implizite Aspekte, und genau hier beginnt die Verwirrung. Ein HSM wird nicht im selben Sinne „quantensicher“ wie ein Algorithmus quantenresistent. Die Hardware selbst ist nicht anfällig für Quantenangriffe. Entscheidend ist, ob die Firmware und die kryptografische Bibliothek des HSM postquantenmechanische Algorithmusoperationen nativ innerhalb der Hardwaregrenzen ausführen können, sodass der private Schlüssel die geschützte Hardware niemals verlässt.
Wenn Sie ein Zertifikat oder eine Software mithilfe eines HSM signieren, funktioniert der Vorgang folgendermaßen: Die zu signierenden Daten, üblicherweise ein Hash davon, werden an das HSM gesendet. Das HSM führt die Signierung intern mit dem darin gespeicherten privaten Schlüssel durch und gibt lediglich die Signatur zurück. Der private Schlüssel verlässt die Hardware niemals. Genau darin liegt der entscheidende Vorteil eines HSM. Das bedeutet, dass der private Schlüssel selbst dann geschützt bleibt, wenn alle anderen Systeme in Ihrer Umgebung kompromittiert werden.
Die FIPS 140-3-Umstellung
FIPS 140 ist der US-Regierungsstandard zur Validierung kryptografischer Module, einschließlich HSMs. Die Validierung bestätigt, dass ein Modul zugelassene Algorithmen korrekt implementiert und definierte physische und logische Sicherheitsanforderungen erfüllt. Jahrzehntelang war FIPS 140-2 die maßgebliche Version. Sie wurde vor etwa 25 Jahren eingeführt und 2021 offiziell für neue Validierungen außer Kraft gesetzt. Alle Validierungen seitdem erfolgen gemäß FIPS 140-3.
Dieser Zeitpunkt hat eine direkte und wichtige Konsequenz für die Post-Quanten-Kryptographie: Alle PQC-FIPS-Validierungen entsprechen FIPS 140-3, nicht FIPS 140-2. Die Post-Quanten-Algorithmen wurden vom NIST im August 2024 standardisiert, also lange nachdem FIPS 140-2 keine neuen Validierungen mehr annahm. Das CMVP hat seine Standards und Tools aktualisiert, sodass ML-KEM, ML-DSA und SLH-DSA in neue FIPS-140-3-Einreichungen aufgenommen werden können. Es gibt keinen Weg mehr, wie ein PQC-Algorithmus eine FIPS-140-2-Validierung erhalten kann, da dieses Programm keine neuen Einreichungen mehr akzeptiert.
Hinzu kommt eine Frist, die die Dringlichkeit noch verstärkt: Das NIST wird im September 2026 alle FIPS 140-2-Zertifikate in den historischen Status versetzen. Module auf der Liste der historischen Zertifikate sind möglicherweise nicht mehr für neue Beschaffungen in vielen föderalen und regulierten Kontexten geeignet.
Die praktische Schlussfolgerung ist, dass Organisationen, denen die Ausstellung von PQC-Zertifikaten wichtig ist, gezielt nach HSMs mit FIPS 140-3- Validierung suchen sollten, die die relevanten PQC-Algorithmen beinhalten oder über einen klaren, verbindlichen Fahrplan für diese Validierung verfügen. Mehrere Anbieter haben hier bereits wichtige Meilensteine erreicht. Bis Ende 2025 und Anfang 2026 erhielten Anbieter wie Crypto4A, Entrust, Idemia, Kryptus, Marvell, Securosys und Utimaco die CAVP-Algorithmuszertifizierung für ML-KEM, ML-DSA und SLH-DSA. HSMs wie das Entrust nShield 5, das Marvell LiquidSecurity 2 sowie das Thales Luna G7 und K7 befinden sich im Validierungsprozess nach FIPS 140-3 mit PQC-Unterstützung.
Technische Herausforderungen von PQC-Schlüsseln in Hardware
Die Unterstützung von PQC in HSMs ist keine triviale Firmware-Aktualisierung, und das Verständnis der damit verbundenen technischen Herausforderungen erklärt, warum die Unterstützung durch die Hersteller schrittweise und nicht auf einmal eingeführt wurde.
Größere Schlüssel- und Signaturgrößen belasten die Hardwarekapazitäten.
PQC-Schlüssel sind wesentlich größer als ihre klassischen Pendants. Ein ML-DSA-Privatschlüssel kann je nach Parametersatz zwischen etwa 1.6 KB und 4 KB groß sein, im Vergleich zu einigen hundert Bytes bei ECDSA . HSMs arbeiten mit festen Speicher- und Speicherkapazitäten, und einige dieser Module haben Schwierigkeiten mit dem größeren PQC-Schlüsselmaterial. Dies ist eine Hardware-Beschränkung, kein Fehler, verdeutlicht aber, warum nicht jedes HSM-Modell PQC gleich gut verarbeiten kann.
Seed-basierte Schlüsselerzeugung führt zu einem Kompromiss
ML-DSA und SLH-DSA unterstützen die Generierung von Schlüsseln aus einem kompakten Seed, der mitunter nur 32 bis 64 Byte lang ist, anstatt den vollständigen, expandierten privaten Schlüssel zu speichern. Dies mindert das Speicherproblem, da im HSM nur der kleine Seed gespeichert wird. Der Nachteil liegt im Rechenaufwand: Der vollständige private Schlüssel muss bei Bedarf jedes Mal aus dem Seed abgeleitet werden, was den Verarbeitungsaufwand erhöht. Die IETF untersucht derzeit die Auswirkungen dieses dualen Schlüsselformats, bei dem ein Schlüssel entweder als kompakter Seed oder als größerer, expandierter Schlüssel dargestellt werden kann, da es die PKCS#12-Dateiverarbeitung, die HSM-Integration und die Interoperabilität zwischen Systemen, die unterschiedliche Formate erwarten, erschwert.
Der Leistungsaufwand ist real
Post-Quanten-Algorithmen benötigen mehr Rechenressourcen als ihre klassischen Pendants. Die ML-KEM-Schlüsselerzeugung benötigt etwa dreimal so viele Zyklen wie ECDH, und die ML-DSA-Signierung benötigt auf vergleichbarer Hardware etwa fünfmal so viele Zyklen wie ECDSA. HSMs mit festen Rechenbudgets können nach der Migration zu PQC einen geringeren Durchsatz aufweisen. Bei Signierungs- oder Schlüsselerzeugungsvorgängen mit hohem Volumen muss dieser Durchsatzeinfluss getestet und eingeplant werden, anstatt ihn zu ignorieren.
Große Nutzlasten stoßen an Netzwerkgrenzen
Beim Signieren großer Objekte wie umfangreicher Zertifikatssperrlisten ist die Datenmenge, die über das Netzwerk an ein HSM gesendet werden kann, oft begrenzt. Daher ist clientseitiges Hashing, bei dem nur der Hashwert der Daten anstelle der gesamten Nutzdaten an das HSM gesendet wird, das empfohlene Verfahren für die PQC-Signierung. Dadurch bleibt die Datenmenge, die das HSM passiert, unabhängig von der Größe des zu signierenden Artefakts gering.
Die Standardisierung ist noch im Gange.
PKCS#11 , die Standardschnittstelle für HSM-Operationen, ist noch nicht vollständig etabliert. LMS und HSS wurden in PKCS#11 Version 3.1 standardisiert, während ML-DSA, SLH-DSA und ML-KEM in PKCS#11 Version 3.2 standardisiert werden. Einige REST-basierte HSMs unterstützen diese Algorithmen bereits vor der vollständigen PKCS#11-Standardisierung. In der Praxis führt dies jedoch dazu, dass die PQC-Unterstützung je nach Hersteller und sogar zwischen verschiedenen Firmware-Versionen desselben Produkts deutlich variiert.
Bewährte Verfahren für den PQC-Schlüsselschutz
Hier sind die Vorgehensweisen, die gut konzipierte PQC-Zertifikatbereitstellungen durchweg auszeichnen.
PQC-Privatschlüssel werden zusammen mit klassischen Schlüsseln in Hardware gespeichert.
Das wichtigste Prinzip ist Konsistenz. Der für klassische Zertifikatsschlüssel geltende Hardware-Schutzstandard muss gleichermaßen für PQC-Schlüssel gelten. Dies erfordert PQC-fähige HSMs, nicht weil die Hardware anfällig war, sondern weil Hardware-Schutz die Unterstützung hardwareseitiger Algorithmen voraussetzt.
Standardisieren Sie auf FIPS 140-3-validierte Hardware.
Da FIPS 140-2 in den historischen Status übergeht und alle PQC-Validierungen auf FIPS 140-3 basieren, positioniert die Ausrichtung der HSM-Beschaffung auf FIPS 140-3 mit PQC-Algorithmusunterstützung das Unternehmen optimal für den laufenden Betrieb und die regulatorischen Erwartungen.
Verwenden Sie clientseitiges Hashing für Signiervorgänge
Indem man an das HSM nur Hashes anstatt vollständiger Nutzdaten sendet, bleibt die Datenmenge, die die Grenze überschreitet, klein, was bei PQC aufgrund der größeren Signaturen und der Netzwerkbeschränkungen bei der HSM-Kommunikation von größerer Bedeutung ist.
Einführung von Hybridzertifikaten während der Übergangsphase
Der Hybridansatz ist der empfohlene Übergangsweg. Stellen Sie sicher, dass das HSM sowohl die klassische als auch die postquantenmechanische Hälfte schützt, damit der Hybridansatz keinen softwarebasierten Schlüssel einführt.
Vor der endgültigen Entscheidung im Produktionsmaßstab testen
Da die PQC-Unterstützung je nach Hersteller und Firmware-Version variiert und sich Schlüssellängen und Durchsatzeigenschaften deutlich von klassischen Algorithmen unterscheiden, sind frühzeitige Tests im Produktionsmaßstab unerlässlich. Stellen Sie sicher, dass Operationen wie das Signieren großer CRLs innerhalb der Beschränkungen Ihres HSM funktionieren, bevor Sie sich darauf verlassen.
Für Krypto-Agilität entwickelt
Entwerfen Sie die Zertifikats- und Signaturinfrastruktur so, dass Algorithmen geändert werden können, ohne dass das gesamte System neu aufgebaut werden muss. Die PQC-Umstellung ist nicht die letzte kryptografische Änderung, die Sie vornehmen werden, und eine auf Agilität ausgelegte Infrastruktur kann zukünftige Änderungen zu deutlich geringeren Kosten auffangen.
Wie Verschlüsselungsberatung helfen kann
Die Frage, ob PQC-Zertifikate quantensichere HSMs erfordern, liegt an der Schnittstelle von kryptografischer Architektur, Hardwarebeschaffung und PKI-Governance, und genau dort ist das Produktportfolio und die Beratungsleistungen von Encryption Consulting angesiedelt.
Mit unserer CodeSign Secure- Plattform, die auf dem bereits besprochenen Prinzip basiert, dass PQC-Privatschlüssel denselben Hardware-Schutz wie klassische Schlüssel verdienen, können Sie ML-DSA- und SLH-DSA-Signaturvorgänge in FIPS-validierten HSMs von Thales, Entrust, Utimaco und Securosys durchführen, ohne dass der Privatschlüssel die Hardwaregrenze verlässt. Die Plattform unterstützt LMS für die Firmware-Signatur und verwendet clientseitiges Hashing, sodass nur Hashes und nicht vollständige Artefakte die HSM-Grenze passieren. Für Organisationen, die PQC-Zertifikate für die Code- und Firmware-Signatur ausstellen oder verwenden, bietet CodeSign Secure die hardwareseitige Vertrauenskette von der Schlüsselgenerierung bis zur Signatur.
CertSecure Manager ist eine weitere Plattform, die Sie bei der Verwaltung des Zertifikatslebenszyklus während des PQC-Übergangs unterstützt, einschließlich der Ausstellung und Verwaltung von Post-Quantum-Zertifikaten. Dank seiner Krypto-Agilität ermöglicht er die parallele Ausführung klassischer und Post-Quantum-Algorithmen in der hybriden Bereitstellungsphase. Die zentrale Governance gewährleistet, dass PQC-Zertifikate genauso sorgfältig verfolgt, erneuert und verwaltet werden wie klassische Zertifikate.
Unsere Post-Quantum-Kryptografie-Beratungsdienste helfen Unternehmen, genau die Art von Architektur- und Beschaffungsfragen zu beantworten, die wir in diesem Blog behandelt haben: welche HSMs in Ihrer Umgebung PQC-fähig sind, welche Firmware-Upgrades oder einen Austausch benötigen, wie Sie eine hybride Zertifikatsbereitstellung strukturieren und wie Sie Ihre Hardware-Roadmap an den Übergang zu FIPS 140-3 und die Frist im September 2026 für den historischen Status von FIPS 140-2 anpassen.
Fazit
Benötigen PQC-Zertifikate also quantensichere HSMs? Die präziseste Antwort lautet: PQC-Zertifikate benötigen HSMs, die Post-Quanten-Algorithmen nativ unterstützen, wenn die privaten Schlüssel dieser Zertifikate hardwareseitig geschützt werden sollen. Die Bezeichnung „quantensicheres HSM“ ist im Grunde eine Kurzform für ein HSM, dessen Firmware ML-DSA, ML-KEM und verwandte Operationen innerhalb seiner sicheren Grenzen ausführen kann.
Die HSM-Hardware war nie quantenanfällig. Geändert hat sich lediglich, dass der Schutz des privaten Schlüssels eines quantenresistenten Zertifikats in Hardware voraussetzt, dass die Hardware den Algorithmus dieses Schlüssels versteht. Ein HSM, das keine ML-DSA-Operationen durchführen kann, kann keinen ML-DSA-Schlüssel schützen, und ein quantenresistentes Zertifikat, dessen privater Schlüssel ungeschützt in Software gespeichert ist, weist eine Schwachstelle auf, die den gesamten Zweck der Migration zunichtemacht.
Bei Encryption Consulting sind unsere Produkte und Beratungsleistungen darauf ausgelegt, Sie bei diesen Entscheidungen richtig zu unterstützen – von der Ermittlung Ihres kryptografischen Bestands bis hin zur Ausstellung von PQC-Zertifikaten mit hardwaregeschützten Schlüsseln.
