HSM (Hardware-Sicherheitsmodul)

Ein Hardware-Sicherheitsmodul (HSM) ist ein dediziertes, manipulationssicheres Hardwaregerät, das kryptografische Schlüssel erzeugt, speichert und verwendet, sodass das Schlüsselmaterial außerhalb des Geräts niemals im Klartext existiert. Jeder sensible Vorgang – einen Schlüssel erzeugen, signieren, verschlüsseln oder einen anderen Schlüssel entpacken – findet innerhalb der gehärteten Grenze des HSM selbst statt.

Bei einem HSM geht es nicht darum, wer einen Schlüssel kontrolliert; das ist die Aufgabe der kundenverwalteten Schlüssel. Bei einem HSM geht es darum, wo der Schlüssel physisch liegt und wie er geschützt wird. Es ist der hardwarebasierte Vertrauensanker, der oft unter einem Schlüsselverwaltungsdienst (KMS) liegt – der Ort, an dem „Ihr eigener“ Schlüssel tatsächlich residiert.

Was ein HSM tatsächlich leistet

Ein HSM vereint vier Fähigkeiten in einem einzigen gehärteten Gerät:

• Schlüsselerzeugung. Schlüssel werden auf dem Gerät mithilfe eines echten Hardware-Zufallszahlengenerators (TRNG) erzeugt und erreichen so eine höhere Entropie als mit Software allein.
• Sichere Speicherung. Private und geheime Schlüssel bleiben innerhalb der kryptografischen Grenze und werden niemals im Klartext exportiert; höchstens verlassen sie das Gerät verpackt (verschlüsselt) mit einem anderen Schlüssel, der das Gerät ebenfalls nie verlässt.
• Operationen auf dem Gerät. Signieren, Ver- und Entschlüsseln sowie das Ver- und Entpacken von Schlüsseln laufen innerhalb des HSM ab, sodass die Anwendung Daten hineingibt und ein Ergebnis erhält, ohne je den rohen Schlüssel zu berühren.
• Zugriffskontrolle und Auditierung. Starke Authentifizierung, Rollentrennung und manipulationssichere Protokollierung bestimmen, wer jeden Schlüssel verwenden darf, und halten fest, wie er verwendet wurde.

Da der Schlüssel das Gerät nie in nutzbarer Form verlässt, liefert der Diebstahl des umgebenden Servers nicht den Schlüssel.

HSM vs. KMS vs. CMK/BYOK

Diese Begriffe werden oft synonym verwendet, beantworten aber unterschiedliche Fragen:

• KMS (Schlüsselverwaltungsdienst) ist die Software, die den Lebenszyklus der Schlüssel verwaltet – Erzeugung, Rotation, Richtlinien, Zugriff und Auditierung – üblicherweise als API bereitgestellt.
• HSM ist der hardwarebasierte Vertrauensanker. Ein KMS ist häufig „HSM-gestützt“, das heißt, die von ihm verwalteten Hauptschlüssel werden tatsächlich innerhalb eines HSM erzeugt und aufbewahrt.
• CMK / BYOK betrifft die Kontrolle: ob Sie und nicht der Anbieter den Schlüssel besitzen und verwalten.

Kurz gesagt: Die CMK entscheidet, wer den Schlüssel kontrolliert, ein KMS entscheidet, wie der Schlüssel verwaltet wird, und ein HSM entscheidet, wo der Schlüssel liegt und wie manipulationssicher seine Verwahrung ist. Ein kundenverwalteter Schlüssel liegt sehr häufig in einem HSM-gestützten KMS.

Sicherheitsnachweis: FIPS 140-3, Manipulationssicherheit und Schnittstellen

Der Wert eines HSM beruht auf einem unabhängigen Nachweis, dass seine Schutzmechanismen tatsächlich greifen.

• FIPS 140-3. Dies ist der aktuelle US-amerikanische und kanadische Standard für kryptografische Module und löst FIPS 140-2 ab (dessen Validierungen auslaufen). Er definiert vier Sicherheitsstufen (1 bis 4) mit zunehmendem physischem und logischem Schutz; HSMs werden üblicherweise auf Stufe 3 validiert, die Manipulationserkennung und -reaktion sowie identitätsbasierte Authentifizierung hinzufügt.
• Manipulationssicherheit. HSMs verbinden Manipulationsnachweis (man sieht, dass geöffnet wurde) mit Manipulationsreaktion (Schlüssel werden gelöscht, wenn die Grenze durchbrochen wird). Viele werden zusätzlich nach Common Criteria evaluiert.
• Standardschnittstellen. Anwendungen kommunizieren mit HSMs über PKCS#11 (eine lokale API, auch Cryptoki genannt, für die Kommunikation mit einem kryptografischen Token) und KMIP (ein Netzwerkprotokoll für die Schlüsselverwaltung zwischen einem Client und einem KMS oder HSM).

Appliance vor Ort, Cloud-HSM und wann Sie eines brauchen

HSMs gibt es in mehreren Bereitstellungsformen:

• Appliance vor Ort. Ein physisches Gerät in Ihrem eigenen Rechenzentrum, das Ihnen die direkte Verwahrung der Hardware gibt.
• Cloud-HSM. Eine dedizierte, mandantenreine HSM-Instanz, die bei einem Cloud-Anbieter gemietet wird – nach wie vor ein echtes HSM, nur remote gehostet und betrieben.
• HSM-gestütztes KMS. Ein verwaltetes KMS, dessen Hauptschlüssel im Hintergrund in HSMs liegen, was einen Großteil des Nachweises liefert, ohne dass Sie die Hardware selbst betreiben.

In der Regel benötigen Sie ein HSM, wenn eine Vorschrift oder ein Vertrag einen hardwarebasierten Vertrauensanker verlangt: Finanzdienstleistungen und Zahlungsverkehr (z. B. PCI DSS), Arbeitslasten im öffentlichen Sektor und in der Verteidigung sowie Public-Key-Infrastrukturen wie eine Stammzertifizierungsstelle oder ausstellende Zertifizierungsstelle.

HSM und ARTESCA

ARTESCA ist kein HSM und enthält auch keines. Stattdessen ist ARTESCA darauf ausgelegt, Verschlüsselungsschlüssel vollständig außerhalb des Speicher-Arrays zu halten und ihre Verwahrung an einen von Ihnen kontrollierten Schlüsselmanager zu delegieren, der HSM-gestützt sein kann.

ARTESCA verschlüsselt Objekte im Ruhezustand mittels serverseitiger Verschlüsselung mit Envelope-Verschlüsselung: Jedes Objekt erhält einen eindeutigen Datenschlüssel, und dieser Datenschlüssel wird mit einem Hauptschlüssel verpackt. Wenn ARTESCA mit einem externen KMS konfiguriert ist, verlässt das Hauptschlüsselmaterial niemals das KMS: In den Objektmetadaten wird nur eine Referenz (die Schlüssel-ID) gespeichert, und Objektdaten werden niemals an das KMS gesendet. Zu den unterstützten externen Backends gehören KMIP-kompatible Schlüsselmanager (wie Thales CipherTrust Manager, HashiCorp Vault und HyTrust KeyControl) sowie AWS-KMS-kompatible Dienste. Jeder von ihnen kann wiederum durch ein HSM als Vertrauensanker gestützt werden.

Das Ergebnis ist eine saubere Zero-Trust-Trennung: Ihre Daten liegen in ARTESCA, Ihre Schlüssel liegen in Ihrem KMS oder HSM, und kein einzelnes System hält beides. Dies ergänzt die kundenverwalteten Schlüssel für die Kontrolle über den Schlüssel und S3 Object Lock für die Unveränderlichkeit der Daten.

HSM-FAQs

Was ist der Unterschied zwischen einem HSM und einem KMS?

Ein KMS ist Software, die den Lebenszyklus der Schlüssel verwaltet (Erzeugung, Rotation, Richtlinien und Zugriff). Ein HSM ist die manipulationssichere Hardware, in der Schlüssel erzeugt und aufbewahrt werden können. Sie ergänzen sich: Ein KMS ist oft „HSM-gestützt“ und nutzt ein HSM als Vertrauensanker.

Ist ein Cloud-HSM immer noch ein „echtes“ HSM?

Ja. Ein Cloud-HSM ist ein dediziertes, mandantenreines Hardwaremodul, das ein Cloud-Anbieter in Ihrem Auftrag betreibt. Die Hardware und ihre FIPS-Validierung sind real; nur Hosting und physische Verwahrung unterscheiden sich von einer Appliance vor Ort.

Was bedeutet eine FIPS-140-3-Stufe?

FIPS 140-3 definiert vier Schutzstufen für kryptografische Module. Höhere Stufen fügen stärkere Authentifizierung und physischen Manipulationsschutz hinzu. HSMs werden üblicherweise auf Stufe 3 validiert, die Manipulationserkennung und -reaktion sowie identitätsbasierte Authentifizierung erfordert.

Brauche ich ein HSM, um kundenverwaltete Schlüssel zu nutzen?

Nicht unbedingt. Bei kundenverwalteten Schlüsseln geht es darum, wer den Schlüssel kontrolliert, und sie können in einem Software-KMS aufbewahrt werden. Ein HSM erhöht den Nachweis, indem es sicherstellt, dass das Schlüsselmaterial in manipulationssicherer Hardware liegt – weshalb viele kundenverwaltete Schlüssel in einem HSM-gestützten KMS liegen.

PKCS#11 oder KMIP – was ist der Unterschied?

PKCS#11 ist eine lokale API, mit der eine Anwendung ein kryptografisches Token oder HSM auf demselben System nutzt. KMIP ist ein Netzwerkprotokoll zur Schlüsselverwaltung zwischen einem Client und einem KMS oder HSM. Es sind komplementäre Standards; ARTESCA integriert sich über KMIP mit externen Schlüsselmanagern.