Die wesentliche Rolle von Hardware-Sicherheitsmodulen (HSMs) in Public-Key-Infrastrukturen (PKI)

Hardware-Sicherheitsmodule (HSMs) bilden die Hardware-Vertrauensbasis für Public-Key-Infrastrukturen (PKI) . Sie generieren CA-Privatschlüssel innerhalb eines FIPS-validierten Bereichs, führen alle Signaturvorgänge in manipulationssicherer Hardware durch und schützen das wichtigste Element jeder PKI-Hierarchie: den CA-Privatschlüssel. Ein kompromittierter CA-Privatschlüssel ermöglicht es Angreifern, gefälschte Zertifikate für jede Identität im Vertrauensbereich dieser CA auszustellen. Empfohlene Vorgehensweise: Implementieren Sie HSMs gemäß FIPS 140-2 Level 3 oder höher für alle CA-Ebenen, führen Sie eine formelle Schlüsselzeremonie zur Generierung des Root-CA-Schlüssels durch und gewährleisten Sie die hohe Verfügbarkeit der HSMs sowie getestete Backups, bevor die PKI produktiv eingesetzt wird.

Kurzantwort: Warum sind HSMs für PKI unerlässlich?

Die Sicherheit von PKIs hängt vollständig von der Integrität der privaten Schlüssel von Zertifizierungsstellen (CA) ab. Die Speicherung von Schlüsseln in Software ist anfällig für logische Angriffe (Speicherzugriff, privilegierter Betriebssystemzugriff) und physische Angriffe (Entfernung der Festplatte). HSMs schützen die privaten Schlüssel von CAs innerhalb einer FIPS-validierten, manipulationssicheren Hardwaregrenze, aus der der Schlüssel niemals im Klartext austritt. Selbst wenn der Host-Server, auf dem die CA-Software läuft, vollständig kompromittiert wird, bleibt der private Schlüssel innerhalb des HSM geschützt. Dieser hardwarebasierte Schutz erstreckt sich über den gesamten Schlüssellebenszyklus: von der Generierung innerhalb der Hardwaregrenze während einer Schlüsselzeremonie über alle Signiervorgänge innerhalb dieser Grenze bis hin zur ausschließlichen verschlüsselten Sicherung. Informationen zur Verwaltung des Zertifikatlebenszyklus auf Basis von HSM-gestützten CA-Schlüsseln finden Sie unter CertSecure Manager.

Die entscheidende Rolle der PKI in der digitalen Sicherheit

PKI bietet ein strukturiertes Framework zur Verwaltung digitaler Zertifikate und kryptografischer Schlüssel und ermöglicht so die sichere Kommunikation zwischen Entitäten. Es bildet die Grundlage für HTTPS auf Websites, E-Mail-Verschlüsselung und -Signatur, digitale Signaturen für Dokumente und Code sowie Zugriffskontrollmechanismen in Unternehmensumgebungen. PKI basiert auf asymmetrischer Verschlüsselung: einem öffentlichen und einem privaten Schlüsselpaar, bei dem der private Schlüssel signiert und der öffentliche Schlüssel verifiziert. Die Vertrauensbeziehung ist in der CA-Hierarchie verankert.

Die Sicherheit der gesamten PKI-Hierarchie hängt von der Integrität ihrer CA-Privatschlüssel ab. Der Root-CA-Privatschlüssel signiert Zertifikate untergeordneter CAs; ein untergeordneter CA-Privatschlüssel signiert Endbenutzerzertifikate für Websites, Benutzer, Geräte und Code. Wird ein CA-Privatschlüssel kompromittiert, kann ein Angreifer gültige Zertifikate für jede Identität innerhalb des Geltungsbereichs dieser CA ausstellen, wodurch alle Zertifikate in dieser Vertrauenskette ungültig werden. Daher ist der Schutz der CA-Privatschlüssel die wichtigste Sicherheitsmaßnahme in jeder PKI-Implementierung.

Was ist ein Hardware-Sicherheitsmodul (HSM)?

Ein HSM ist ein dediziertes Hardwaregerät, das kryptografische Schlüssel innerhalb einer sicheren, manipulationsgeschützten Umgebung generiert, speichert und verwaltet. Alle kryptografischen Operationen finden innerhalb der Hardware statt; private Schlüssel verlassen die Umgebung niemals im Klartext. Wichtige Merkmale für PKI:

• Manipulationssicherheit: Die integrierte Erkennung von physikalischen und logischen Manipulationen reagiert auf Eindringversuche, indem sie Schlüsseldaten löscht, bevor diese extrahiert werden können.
• FIPS 140-Validierung: HSMs werden gemäß FIPS 140-2 oder dem aktuellen FIPS 140-3-Standard validiert. Level 3 (erforderlich für die meisten PKI-Workloads) bietet zusätzlich identitätsbasierte Authentifizierung und Schutz vor physischer Manipulation.
• Hardware-Schlüsselgenerierung: Die Schlüssel werden mithilfe eines Hardware-Random-Number-Generators (TRNG) erzeugt, der eine kryptografische Qualität der Entropie erreicht, die Software-RNGs nicht erreichen können.
• Multi-Faktor-Authentifizierung: Der Zugriff auf HSM-Funktionen erfordert physische Smartcards, PINs oder gleichwertige Anmeldeinformationen, wodurch die Kontrolle der CA-Schlüsseloperationen durch mehrere Personen sichergestellt wird.
• Bereitstellungsflexibilität: Verfügbar als PCIe-Karten, die in Servern, netzwerkfähigen Geräten, tragbaren USB-Geräten und Cloud-basierten HSM-Diensten integriert sind.

FIPS-Grenze in der PKI: Was bedeutet das für CA-Schlüssel?

Die FIPS-140-Grenze definiert den physischen und logischen Bereich, innerhalb dessen kryptografische Operationen stattfinden und Schlüssel geschützt werden. Für PKI ist diese Grenzziehung von entscheidender Bedeutung:

• Innerhalb der CA-Grenzen generierte private Schlüssel existieren unter keinen Umständen außerhalb dieser Grenzen im Klartext, auch nicht während Sicherungsvorgängen (bei denen das Schlüsselmaterial in verschlüsselter Form exportiert wird, die von HSM-generierten Schlüsselverschlüsselungsschlüsseln umschlossen ist).
• Sämtliche CA-Signaturvorgänge (Signatur von untergeordneten CA-Zertifikaten, Signatur von Endbenutzerzertifikaten, Signatur von CRLs) finden innerhalb der Grenzen statt; nur Signaturen und öffentliches Schlüsselmaterial verlassen das Netzwerk.
• FIPS 140-2 Level 3 (der Standard für Enterprise-PKI) verlangt, dass das Modul physisch auf Manipulationen reagiert, um sicherzustellen, dass eine physische Kompromittierung des Geräts kein Schlüsselmaterial liefert.
• FIPS 140-3 ist der aktuelle Standard. Organisationen, die HSMs evaluieren, sollten sowohl den aktuellen Validierungsstatus als auch den Fahrplan des Anbieters für die FIPS 140-3-Zertifizierung überprüfen.

Bereitstellungstopologie: HSM-Modelle für PKI

PKI-Ebene	Empfohlener HSM-Formfaktor	FIPS-Niveau	Konnektivität	HA-Modell
Offline-Root-CA	USB- oder PCIe-HSM; zwischen den Zeremonien offline gehalten	Mindestens Stufe 3; Stufe 4 für höchste Sicherheit	Air-Gap; keine Netzwerkverbindung	Einzelnes Gerät; Schlüsselblöcke in verschlüsselter Archivierung unter M-of-N-Verwahrung gesichert.
Online-Ausstellungsbehörde	Netzwerkgebundenes HSM-Gerät oder Cloud-HSM	Mindestens Stufe 3	Verbindung zum CA-Server über TCP/IP oder PKCS#11 über das Netzwerk	HSM-Cluster mit mindestens 2 Geräten; Schlüsselmaterial clusterweit synchronisiert
Emission großer Mengen (Unternehmens- oder öffentliche Zertifizierungsstelle)	Netzwerk-HSM-Cluster mit Lastverteilung	Level 3	Netzwerkgebunden; mehrere HSM-Clients	Aktiv-Aktiv-Cluster; geografische Redundanz über Verfügbarkeitszonen hinweg
Cloud-/Hybrid-PKI	Cloud-HSM (HSM als Dienst) oder hybride lokale Stammzertifizierungsstelle + Cloud-ausstellende Zertifizierungsstelle	Stufe 3 (Hardwaregerät prüfen, nicht Softwareebene)	Cloud-basiert; Zugriff über das Anbieternetzwerk	Anbieterverwaltete Clusterreplikation; regionsübergreifende Datensicherung

Schlüsselzeremonie: Einrichtung der Root-CA in Hardware

Die Zeremonie zur Festlegung des Root-CA-Schlüssels ist der kritischste operative Vorgang bei der Implementierung einer PKI. Sie etabliert den privaten Schlüssel, der die gesamte Vertrauenshierarchie verankert. Die Zeremonie muss in Anwesenheit von Zeugen durchgeführt, in einem unterzeichneten Protokoll dokumentiert und mit dem HSM an einem physisch gesicherten Ort abgehalten werden.

1. Vorbereitungen vor der Zeremonie: Identifizieren Sie die Verantwortlichen für das M-von-N-Quorum (typischerweise 3 von 5 oder 2 von 3); bestätigen Sie den FIPS-140-Validierungsstatus und das Attestierungszertifikat des HSM; bereiten Sie den vom Air-Gap getrennten Zeremonienarbeitsplatz vor; stellen Sie das Offline-HSM und die Smartcard-Lesegeräte bereit; bestätigen Sie die Zeugenliste und sorgen Sie für die physische Sicherheit des Zeremonienraums.
2. HSM-Initialisierung: Das HSM wird auf Werkszustand zurückgesetzt, um sicherzustellen, dass kein vorheriges Schlüsselmaterial vorhanden ist; die Firmware-Version und der Validierungsstatus werden überprüft.
3. Erstellung von Administratoranmeldeinformationen: Die HSM-Sicherheitsbeauftragten-Zugangsdaten (SO) werden mithilfe von M-of-N-Quorum-Smartcards erstellt; jede Smartcard wird einem separaten Verwahrer zugeteilt; keine einzelne Person besitzt die Mehrheit der Karten.
4. Generierung von Root-CA-Schlüsseln: Das Root-CA-RSA- oder ECC-Schlüsselpaar wird innerhalb der HSM-Grenze generiert; der private Schlüssel wird in Hardware erstellt und existiert außerhalb der Grenze niemals im Klartext; der öffentliche Schlüssel wird für das selbstsignierte Root-CA-Zertifikat exportiert.
5. Erstellung des Root-CA-Zertifikats: Es wird ein selbstsigniertes Root-CA-Zertifikat erstellt; der Signiervorgang findet innerhalb des HSM statt; das Ergebnis ist das Root-CA-Zertifikat, wobei der private Schlüssel in der Hardware verbleibt.
6. Sicherung des verschlüsselten Schlüssels: Erstellen Sie eine verschlüsselte Sicherung des Root-CA-Schlüsselmaterials mithilfe des Sicherungsmechanismus des HSM; die Sicherung wird mit dem eigenen Schlüsselverschlüsselungsschlüssel des HSM geschützt; verteilen Sie die Sicherungsautorisierungsdaten mittels Secret Sharing an die Verwahrer; speichern Sie die Sicherung an einem physisch getrennten, sicheren Ort.
7. Auditdokumentation: Alle Zeremonienschritte werden in einem unterzeichneten Protokoll festgehalten; dieses Protokoll wird mit der gleichen Sorgfalt behandelt wie das Schlüsselmaterial selbst; Zeugen unterzeichnen das Protokoll.

Wie HSMs die PKI-Sicherheit stärken

Sichere Schlüsselgenerierung und -speicherung

HSMs generieren CA-Privatschlüssel in einer sicheren Hardwareumgebung mithilfe eines Hardware-TRNG und gewährleisten so eine kryptografische Qualität der Schlüssel, die durch Software-Schlüsselgenerierung nicht erreicht werden kann. Im Gegensatz zur softwarebasierten Schlüsselspeicherung existiert der Schlüssel niemals im Arbeitsspeicher des Host-Betriebssystems oder auf der Festplatte im Klartext. Dadurch werden die primären Angriffsflächen für Cyberkriminelle eliminiert.

Kryptografische Integrität während des gesamten Schlüssellebenszyklus

Die Integrität der PKI hängt von einem ordnungsgemäßen Schlüsselmanagement über den gesamten Lebenszyklus ab. HSMs übernehmen die Rotation, Erneuerung und den Widerruf von CA-Schlüsseln und gewährleisten dabei die Einhaltung der Hardwaregrenze. Alle CA-Signaturvorgänge finden innerhalb des HSM statt; weder der private Schlüssel noch Zwischenwerte von Operationen verlassen die Hardwaregrenze.

Manipulationssichere Architektur

HSMs erkennen und reagieren auf unautorisierte physische Zugriffsversuche. Gemäß FIPS 140-2 Level 3 reagiert das Modul aktiv auf Manipulationen, indem es Schlüsselmaterial löscht, bevor es extrahiert werden kann. Dies bedeutet, dass ein Angreifer, der physischen Zugriff auf das HSM-Gerät erlangt, den privaten CA-Schlüssel selbst mit spezialisierten Hardware-Analyseverfahren nicht wiederherstellen kann.

Einhaltung gesetzlicher Vorschriften und Zertifizierung

Organisationen in regulierten Branchen müssen Rahmenbedingungen wie die DSGVO , PCI DSS und HIPAA einhalten . HSMs bieten FIPS-validierten Hardware-Schutz für CA-Schlüssel, erfüllen die Anforderungen dieser Rahmenbedingungen an die Hardware-Schlüsselspeicherung und reduzieren den Dokumentationsaufwand bei Audits.

Skalierbarkeit für Enterprise-PKI

Mit zunehmender Komplexität von PKI-Implementierungen, die mehr Identitäten, Geräte und Anwendungen verwalten müssen, skalieren auch HSMs entsprechend. Netzwerk-HSM-Appliances unterstützen mehrere CA-Clients gleichzeitig; HSM-Cluster verteilen die Signaturlast auf mehrere Appliances; PKI-as-a-Service- Modelle nutzen Cloud-HSMs, um eine geografische Verteilung ohne lokale Hardware in jeder Region zu ermöglichen.

HSMs im Zertifikatslebenszyklusmanagement

Die effiziente Verwaltung digitaler Zertifikate ist untrennbar mit der HSM-Verwaltung verbunden. HSMs sind in jeder Phase des Zertifikatslebenszyklus involviert, in der CA-Privatschlüssel verwendet werden:

• Zertifikatsausstellung: Jedes von der Zertifizierungsstelle ausgestellte Zertifikat wird mit dem privaten Schlüssel der Zertifizierungsstelle innerhalb des HSM signiert; das HSM führt den Signiervorgang durch und gibt nur die Signatur zurück.
• CRL-Unterzeichnung: Zertifikatssperrlisten (CRLs) müssen nach einem festgelegten Zeitplan mit dem CA-Schlüssel signiert werden; das HSM führt diese Signierungsvorgänge für die geplante CRL-Ausstellung automatisch durch.
• CA-Zertifikatserneuerung: Wenn ein CA-Zertifikat abläuft, signiert der CA-Schlüssel im HSM die Verlängerung; der private Schlüssel kann derselbe bleiben (Schlüsselrotation) oder es wird ein neuer Schlüssel innerhalb des HSM generiert (Schlüsselgenerierungszeremonie).
• Kontrollierter Zugriff auf kryptografische Materialien: Das HSM erzwingt Multi-Faktor-Authentifizierung und rollenbasierte Zugriffskontrollen, sodass nur autorisierte CA-Administratoren wichtige Operationen initiieren können.

Für die automatisierte Verwaltung des gesamten Zertifikatslebenszyklus, der durch HSM-geschützte CA-Schlüssel abgesichert ist, siehe CertSecure Manager . Da das CA/Browser Forum eine Gültigkeitsdauer von TLS-Zertifikaten von 200 Tagen bis März 2026 und 47 Tagen bis 2029 vorschreibt, ist die Automatisierung der Zertifikatsausstellung durch HSM-basierte Zertifizierungsstellen nicht mehr optional.

HSM vs. Softwarebasierte Schlüsselspeicherung für PKI: Entscheidungstabelle

Abmessungen	Hardware-Sicherheitsmodul (HSM)	Softwarebasierte Schlüsselspeicherung
Wichtige Schutzgrenze	FIPS-validierte Hardwaregrenze; ​​Schlüssel werden außerhalb der Grenze niemals im Klartext gespeichert	Schlüssel, die im Dateisystem des Betriebssystems oder im Schlüsselspeicher abgelegt sind; zugänglich für privilegierte Prozesse
Resistenz gegen logische Angriffe	Der Schlüssel befindet sich niemals im Hostspeicher; eine Kompromittierung des Betriebssystems legt den Schlüssel nicht offen.	Schlüssel, die aus Speicherabbildern, Core-Dateien oder dem Zugriff auf privilegierte Prozesse extrahiert werden können
Widerstandsfähigkeit gegen physische Angriffe	Manipulationserkennung gemäß FIPS-Level 3+ löscht Schlüssel bei physischem Eindringen.	Das Entfernen der Festplatte liefert eine verschlüsselte Schlüsseldatei; die Sicherheit hängt von der Qualität des Passphrases ab.
CA-Schlüsselzeremonie	Schlüssel wurde im Inneren der Hardware unter Aufsicht eines Zeugen generiert; Prüfprotokoll erstellt	Schlüssel wurde in Software generiert; keine Hardware-Bestätigung der Generierungsumgebung
Einhaltung gesetzlicher Vorschriften	FIPS 140-2 Level 3; erfüllt die Anforderungen von PCI DSS, HIPAA und staatlichen PKI-Systemen.	Erfüllt möglicherweise nicht die hardwarespezifischen Anforderungen in regulierten Rahmenbedingungen.
Steuerung durch mehrere Personen	Das physische Smartcard-Quorum wird durch die HSM-Hardware sichergestellt.	Die Steuerung durch mehrere Personen hängt von Software-Zugriffskontrollen ab; diese können mit Betriebssystemberechtigungen umgangen werden.
Leistung	Spezielle kryptografische Hardware; optimiert für hohe Signiermengen	Abhängig von der Host-CPU; akzeptabel für geringe Arbeitslasten.
Eignung von PKI-Anwendungsfällen	Erforderlich für Stammzertifizierungsstellen, ausstellende Zertifizierungsstellen und jede Hierarchie öffentlich vertrauenswürdiger Zertifizierungsstellen.	Nur für interne, nicht kritische oder Test-PKI-Umgebungen akzeptabel.

Integrationsvoraussetzungen

• PKCS#11- oder CNG/CSP-Schnittstelle: Prüfen Sie, ob die CA-Software die kryptografische Schnittstelle des HSM unterstützt. Microsoft ADCS verwendet CNG/CSP-Anbieter; EJBCA, Dogtag und OpenCA verwenden PKCS#11. Installieren Sie die Anbieterbibliothek des HSM-Herstellers auf dem CA-Server, bevor Sie die CA-Software installieren.
• Netzwerkverbindung (Netzwerk-HSM): Der CA-Server muss die HSM-Appliance über den konfigurierten Port erreichen können. Eine gegenseitige TLS-Authentifizierung zwischen CA-Client und HSM ist erforderlich; konfigurieren Sie das Client-Zertifikat und das HSM-Server-Zertifikat vor der Registrierung.
• HSM-Partitionserstellung: Erstellen Sie vor der Generierung von CA-Schlüsseln eine dedizierte HSM-Partition für die PKI-Umgebung. Die Zugangsdaten dieser Partition müssen dokumentiert und unter M-of-N-Verwahrung aufbewahrt werden.
• Hochverfügbarkeitscluster: Konfigurieren Sie mindestens zwei HSM-Appliances in einem Cluster mit synchronisiertem Schlüsselmaterial, bevor die Zertifizierungsstelle (CA) produktiv eingesetzt wird. Eine PKI-HSM-Bereitstellung mit nur einer Appliance stellt einen Single Point of Failure für alle CA-Operationen dar.

Fehlermodus-Leitfaden

• Ausfall des HSM-Geräts: Bei einem vollständigen Ausfall des HSM-Clusters werden die CA-Signaturvorgänge gestoppt; die Zertifikatsausstellung und die CRL-Signatur können nicht fortgesetzt werden. Vor der Produktion: Mindestens zwei geclusterte Appliances bereitstellen; Cluster-Failover überprüfen; getestete Schlüsselsicherungen mit dokumentiertem Wiederherstellungsverfahren bereithalten.
• Verlust der HSM-Zugangsdaten (Quorumverlust): Sind die M-of-N-Verwalter nicht verfügbar, können administrative HSM-Operationen, die ein Quorum erfordern, nicht durchgeführt werden. Halten Sie für jede Quorumposition Ersatzverwalter bereit; testen Sie die Wiederherstellung mit den Ersatzzugangsdaten jährlich.
• Abgelaufenes CA-Zertifikat: Selbst wenn der private Schlüssel der Zertifizierungsstelle sicher im HSM gespeichert ist, verhindert ein abgelaufenes Zertifizierungszertifikat die Ausstellung neuer Zertifikate. Überwachen Sie daher den Ablauf des Zertifizierungszertifikats und erneuern Sie es rechtzeitig mithilfe des HSM-geschützten Schlüssels.
• CRL-Veröffentlichung fehlgeschlagen: Wenn das HSM zum Zeitpunkt der geplanten CRL-Signierung nicht verfügbar ist, läuft die CRL ab und vertrauende Parteien beginnen, Zertifikate dieser Zertifizierungsstelle abzulehnen. Verlängern Sie die Gültigkeitsdauer der CRL vor geplanten HSM-Wartungsarbeiten und implementieren Sie Warnmeldungen zur CRL-Überwachung.
• Kompromittierung des CA-Privatschlüssels (Softwarespeicherung): Wenn softwareseitig gespeicherte CA-Schlüssel kompromittiert werden, muss die gesamte PKI-Hierarchie von Grund auf neu aufgebaut werden (alle Zertifikate neu ausgestellt, Vertrauensanker bei allen vertrauenden Parteien aktualisiert). HSMs verhindern dieses Szenario, indem sie die softwareseitige Schlüsselextraktion unmöglich machen.

Cloud-HSM-Lösungen für PKI

Cloud-HSMs bieten dieselbe FIPS-validierte Hardware-Grenze wie lokale HSMs über ein Managed-Service-Modell und eliminieren so den Aufwand für Hardwarebeschaffung und -betrieb. Für PKI-Implementierungen:

• Offline-Root-CA: Es empfiehlt sich weiterhin, für die Offline-Root-CA-Zeremonie ein portables, lokales HSM (USB oder PCIe) zu verwenden, selbst wenn die ausstellende CA ein Cloud-HSM nutzt. Das Root-CA-HSM wird nur für die Root-Signaturzeremonien online geschaltet.
• Online ausstellende Zertifizierungsstelle: Cloud-HSMs eignen sich für die Ausstellung von CA-Privatschlüsselschutz; das Cloud-HSM stellt die FIPS-Grenze und den HA-Cluster bereit; die CA-Software verbindet sich über PKCS#11 oder eine Cloud-Anbieter-spezifische Schnittstelle.
• Hybrid-Modell: Lokales Root-CA-HSM plus Cloud-Issuing-CA-HSMs; das Issueing-CA-Zertifikat wird während einer Zeremonie signiert, an der sowohl das Offline-Root-HSM als auch das Cloud-HSM teilnehmen.

In unserem Leitfaden zu Cloud-HSMs: Übersicht und Anwendungsfällen finden Sie einen detaillierten Vergleich von Cloud-HSM und Cloud-KMS sowie Informationen zu Bereitstellungstopologien. Informationen zu Managed-HSM-Diensten für Ihre PKI finden Sie unter HSM as a Service.

Bewährte Verfahren für die HSM-Bereitstellung in PKI

1. Definieren Sie klare Richtlinien für das Schlüsselmanagement: Dokumentieren Sie vor der HSM-Beschaffung die Quorumsgrößen, die Zuständigkeiten der Verantwortlichen, die Verfahren für die Schlüsselzeremonie, die Anforderungen an die Datensicherung und die Zugangskontrollrichtlinien.
2. Setzen Sie niemals ein PKI-HSM mit nur einer Appliance ein: Ein einzelnes HSM ohne Clusterpartner stellt einen Single Point of Failure für alle CA-Signaturvorgänge dar; setzen Sie daher mindestens zwei Cluster-Appliances pro Umgebung ein.
3. Backup-Wiederherstellung vor der Produktion testen: Erstellen Sie vor der Inbetriebnahme der Zertifizierungsstelle eine Sicherung des HSM-Schlüssels und stellen Sie diese auf einem sekundären HSM wieder her; eine ungetestete Sicherung, die während der Notfallwiederherstellung fehlschlägt, ist gleichbedeutend mit keiner Sicherung.
4. Überwachung des Ablaufs von CA-Zertifikaten und CRLs: Der Betrieb von HSM-gestützten Zertifizierungsstellen wird gestoppt, wenn das Zertifizierungsstellenzertifikat oder die Sperrliste abläuft; implementieren Sie Überwachungsalarme mit ausreichendem Vorlauf, um vor Ablauf handeln zu können.
5. Automatisierte Zertifikatsausstellung: Da die Gültigkeitsdauer von TLS-Zertifikaten bis 2029 auf etwa 47 Tage sinken wird, ist die manuelle Zertifikatsverwaltung nicht mehr praktikabel; integrieren Sie die HSM-gestützte Zertifizierungsstelle in eine automatisierte CLM-Plattform wie beispielsweise CertSecure Manager.

Fazit

HSMs sind in PKI-Systemen unverzichtbar: Sie bilden die hardwarebasierte Vertrauensbasis, die die gesamte PKI-Hierarchie vertrauenswürdig macht. Nur softwareseitig geschützte CA-Schlüssel sind durch einen einzigen logischen Angriff katastrophal gefährdet und können die gesamte Vertrauenskette ungültig machen. FIPS 140-2 Level 3 HSMs eliminieren dieses Risiko, indem sie CA-Schlüssel in einer manipulationssicheren Hardware-Umgebung speichern, aus der sie niemals im Klartext austreten. Da PKI branchenübergreifend weiterhin die Grundlage für TLS, Codesignierung, E-Mail-Sicherheit und digitale Identität bildet, wächst auch der Bedarf an hardwarebasiertem CA-Schlüsselschutz. Lesen Sie dazu unsere verwandten Beiträge zu HSMs und Schlüsselmanagement , Cloud-HSMs und PKI as a Service.

Häufig gestellte Fragen

Warum benötigen PKI-Umgebungen HSMs anstelle von Software-Schlüsselspeichern?

CA-Privatschlüssel in Software sind anfällig für logische Angriffe (Speicherzugriff, privilegierter Betriebssystemzugriff) und physische Angriffe (Festplattenentfernung). Ein kompromittierter CA-Schlüssel ermöglicht es einem Angreifer, gefälschte Zertifikate für jede Identität innerhalb des Vertrauensbereichs dieser CA auszustellen. HSMs schützen CA-Schlüssel innerhalb einer FIPS-validierten Hardwaregrenze, aus der sie niemals im Klartext austreten. Dadurch ist eine Extraktion selbst bei vollständiger Kompromittierung des Hosts unmöglich.

Welches FIPS-140-Niveau ist für PKI-HSMs erforderlich?

FIPS 140-2 Level 3 ist der Standard für die meisten PKI-Implementierungen in Unternehmen und Behörden. Level 3 erfordert manipulationssichere Hardware, identitätsbasierte Authentifizierung (physische Smartcard-Anmeldeinformationen) und verschlüsselte Schlüsselextraktion. FIPS 140-3 ist der aktuelle Standard. Level 4 (aktive Reaktion auf Manipulationen in der Umgebung) wird für die sichersten Root-CA-Zeremonien verwendet.

Was ist eine Root-CA-Schlüsselzeremonie?

Ein kontrollierter, bezeugter Prozess zur Generierung des Root-CA-Privatschlüssels innerhalb eines HSM. Mehrere Verwahrer sind anwesend; ein M-von-N-Smartcard-Quorum stellt sicher, dass keine einzelne Person Zugriff auf den Schlüssel hat; das HSM generiert den Schlüssel intern, sodass er niemals außerhalb der Hardware existiert; alle Schritte werden in einem signierten Prüfdokument protokolliert.

Wie lassen sich HSMs in CA-Software integrieren?

Über PKCS#11 (die meisten CA-Programme unter Linux/Unix) oder Microsoft CNG/CSP (Windows ADCS). Die CA-Software nutzt die Providerbibliothek des HSM; die Schlüsselerzeugung und alle Signiervorgänge werden an das HSM und nicht an das Host-Dateisystem umgeleitet. Der private CA-Schlüssel wird während der Zeremonie innerhalb des HSM generiert und niemals im Klartext gespeichert.

Was passiert, wenn das PKI-HSM ausfällt?

Die Zertifikatsausstellung und CRL-Signierung werden bis zur Wiederherstellung des HSM ausgesetzt. Zur Vorbeugung sind HSM-Cluster (mindestens zwei Appliances), getestete Schlüsselsicherungen und eine verlängerte CRL-Gültigkeit vor geplanten Wartungsarbeiten erforderlich. Eine ungetestete Sicherung ist gleichbedeutend mit keiner Sicherung.

Worin besteht der Unterschied zwischen On-Premises-HSM und Cloud-HSM für PKI?

Lokale HSMs bieten geringste Latenz, vollständige physische Kontrolle und sind netzwerkunabhängig. Cloud-HSMs (HSM as a Service) bieten dieselbe FIPS-konforme Sicherheitsgrenze über einen Managed Service und eliminieren so den Aufwand für Hardwarebeschaffung und -betrieb. Bewährte Vorgehensweise: Eine Offline-Root-CA verwendet ein lokales, portables HSM; eine Online-Certificate-of-Certificate-Analysis-CA kann je nach Betriebsmodell entweder ein lokales Netzwerk-HSM oder ein Cloud-HSM verwenden.