Hardware-Sicherheitsmodule: Schlüssel in geprüfter Hardware

Maßgeblich ist der geforderte Nachweis für Ihren Anwendungsfall. Wir prüfen Zertifikat, Status, Hardware- und Firmwarestand sowie die dokumentierten Einsatzbedingungen. FIPS, Common Criteria und Payment-Prüfungen haben unterschiedliche Geltungsbereiche. Ein einzelnes Zertifikat bestätigt nicht automatisch die gesamte Lösung.

Es gibt verschiedene Prüfungen für HSMs. Nicht jede Prüfung passt zu jedem Einsatz. Wir prüfen den genauen Gerätetyp, die Softwareversion und die erlaubte Nutzung. Ein Gerätenachweis gilt nicht automatisch für das ganze System.

Ein Hersteller kann Integration und Betrieb vereinfachen. Unterschiedliche Anforderungen können aber verschiedene Plattformen erforderlich machen. Wir trennen zunächst Sicherheitsdomänen und Anwendungsfälle. Ob dafür mehrere Hersteller nötig sind, wird begründet entschieden; die Trennung allein fordert nicht automatisch unterschiedliche Marken.

Ein Hersteller kann den Betrieb vereinfachen. Manchmal brauchen verschiedene Aufgaben unterschiedliche Geräte. Wir prüfen, ob dafür auch unterschiedliche Hersteller nötig sind.

Eigene Hardware, beauftragter Betrieb und verwaltete Dienste unterscheiden sich bei Verantwortung, Kosten und Verfügbarkeit. Standorte und Regionen werden ausdrücklich festgelegt. Backup, Wiederanlauf, Hersteller-Support und ein späterer Ausstieg gehören in dieselbe Entscheidung.

Sie können eigene Geräte nutzen oder einen Dienst buchen. Kosten und Aufgaben unterscheiden sich. Gemeinsam legen wir Standorte, Zuständigkeiten und Wiederherstellung fest. Auch einen späteren Wechsel planen wir ein.

PQC-Unterstützung hängt von Hardware, Firmware, Schnittstellen und Anwendung ab. Ein angekündigtes Update ist kein Nachweis für eine produktiv nutzbare, validierte Konfiguration. Wir inventarisieren Schlüssel und Protokolle, prüfen den Herstellerstand und planen kompatible Übergänge einschließlich Gegenstellen und Wiederherstellung.

Neue kryptografische Verfahren müssen von Gerät und Anwendung unterstützt werden. Ein angekündigtes Update reicht als Nachweis nicht aus. Wir prüfen die vorhandenen Systeme und planen einen passenden Übergang.

Ein Hardware-Sicherheitsmodul schützt kryptografische Schlüssel und führt unterstützte Operationen innerhalb einer definierten Sicherheitsgrenze aus. Ob ein Schlüssel exportiert werden darf, bestimmt seine Konfiguration zusammen mit dem unterstützten Verfahren. PKCS #11, CNG- oder Java-Provider und Schlüsselmanagement-Schnittstellen erfüllen unterschiedliche Aufgaben. Wir prüfen die vollständige Anwendungskette statt nur die Nennung einer Schnittstelle. Kryptografie und Hardware-Sicherheitsmodule sind unsere Kernkompetenz. Wir kennen die Serien der Hersteller, die Prüfnummern der Zertifikate und die Grenzen der einzelnen Plattformen. Wir führen Ihr Vorhaben von der Auswahl über die Schlüsselzeremonie bis in den laufenden Betrieb.

Vier typische Aufgaben zeigen, wo HSMs sinnvoll eingesetzt werden. Welche Nachweise und Schutzmechanismen benötigt werden, ergibt sich aus Ihrer Anwendung und den konkreten Anforderungen. Ein HSM allein bestätigt weder die Sicherheit der gesamten Umgebung noch deren Compliance.

Diese vier Beispiele zeigen mögliche Aufgaben für ein HSM. Welche Nachweise Sie brauchen, hängt von Ihrem Einsatz ab. Ein geprüftes Gerät macht nicht automatisch die gesamte Umgebung sicher.

Root- und ausstellende CA können ihre privaten Schlüssel über eine unterstützte HSM-Anbindung verwenden. Dazu gehören passende Zertifikatsprofile, Rollen und Sperrverfahren. Ein kompromittierter CA-Server kann trotz geschütztem Schlüssel unzulässige Aufträge auslösen; deshalb sichern wir auch Freigaben und die Anwendung ab.

Eine Zertifizierungsstelle stellt Zertifikate aus. Ihre privaten Schlüssel können in einem HSM liegen. Die Software muss trotzdem geschützt sein. Wer sie übernimmt, könnte sonst unerlaubte Signaturen anfordern.

Payment-HSMs unterstützen dafür vorgesehene Funktionen für PIN-Verarbeitung, Kartenschlüssel oder Schlüsselverteilung. Wir prüfen Kommandos, Schlüsselverfahren, Partneranforderungen und den konkreten Prüfstand des Geräts. Ein General-Purpose-HSM ist nicht automatisch ein Ersatz.

Ein Payment-HSM ist für Aufgaben im Zahlungsverkehr gedacht. Es kann zum Beispiel bei der PIN-Prüfung helfen. Wir prüfen die nötigen Funktionen und die Anforderungen Ihrer Partner. Nicht jedes HSM kann diese Aufgaben erfüllen.

HSM-gestützte Signaturen können Schlüssel für Software und Firmware schützen. Der Prozess muss zusätzlich festlegen, wer welches Artefakt freigibt und signieren darf. Anforderungen an die Schlüsselverwahrung werden für das verwendete Zertifikat und Vertrauensmodell geprüft.

Eine digitale Signatur hilft, Software und ihren Herausgeber zu prüfen. Das HSM kann den Signaturschlüssel schützen. Zusätzlich muss geregelt sein, wer welche Software zur Signatur freigibt.

Ein Schlüsselmanagementsystem kann Anwendungen und Speicher über unterstützte Protokolle wie KMIP anbinden und ein HSM als Schutzkomponente nutzen. Bei BYOK, externer Schlüsselverwaltung und Envelope Encryption prüfen wir, wo welche Schlüssel verwendet werden und wer Operationen auslösen kann. BYOK allein schließt einen Anbieterzugriff auf Daten nicht aus.

Ein zentrales System kann Schlüssel für Anwendungen und Speicher verwalten. Ein HSM kann dabei besonders wichtige Schlüssel schützen. Wir prüfen, wer welche Schlüssel verwenden darf. Ein eigener Schlüssel in der Cloud bedeutet nicht automatisch, dass der Anbieter keine Daten lesen kann.

Vier Fragen entscheiden über Hersteller und Serie: die geforderte Prüfstufe, die nötige Leistung, die Schnittstellen Ihrer Anwendungen und das Betriebsmodell. Wir klären sie in einem Workshop und halten das Ergebnis in einer Entscheidungsvorlage fest.

Vier Fragen entscheiden über Hersteller und Serie. Erstens die geforderte Prüfstufe. Zweitens die nötige Leistung. Drittens die Schnittstellen Ihrer Anwendungen. Viertens das Betriebsmodell. Wir klären diese Fragen in einem Workshop. Das Ergebnis halten wir in einer Vorlage fest.

Durchsatz ist nur mit Algorithmus, Schlüsselgröße, Parallelität und Clientanbindung vergleichbar. Wir messen außerdem Latenz und Ausfallverhalten. Bei Mandantentrennung zählen Rechte, gemeinsam genutzte Ressourcen und Administration – nicht allein die Zahl der Partitionen.

Die Geschwindigkeit hängt von der Aufgabe ab. Auch Schlüsselgröße und gleichzeitige Anfragen spielen eine Rolle. Wir testen Ihre Anwendung. Bei getrennten Nutzern prüfen wir außerdem Rechte und gemeinsam genutzte Ressourcen.

Provider, Mechanismen und Schlüsselattribute müssen zur Anwendung passen. Ein Simulator kann erste Entwicklungsfragen klären, ersetzt aber keinen Nachweis für Hardwareverhalten, Leistung oder Zertifizierungsmodus. Repräsentative Tests erfolgen mit der vorgesehenen Zielumgebung.

Gerät und Anwendung müssen zusammenpassen. Ein Simulator hilft bei ersten Tests. Er bildet aber nicht alle Eigenschaften echter Hardware ab. Wichtige Tests führen wir deshalb mit der geplanten Zielumgebung durch.

Prüfungen und regulatorische Anforderungen sind keine austauschbaren Gütesiegel. Für die Auswahl ordnen wir die Nachweise dem konkreten Modul, seinem Produktstand und dem geplanten Einsatz zu. Den Status prüfen wir vor der Beschaffung anhand der zuständigen Stellen.

Prüfungen und regulatorische Anforderungen sind keine austauschbaren Gütesiegel. Für die Auswahl ordnen wir die Nachweise dem konkreten Modul, seinem Produktstand und dem geplanten Einsatz zu. Den Status prüfen wir vor der Beschaffung anhand der zuständigen Stellen.

CMVP-Zertifikat, Security Policy, Versionen, Betriebsmodus und Status prüfen