Hardware-Sicherheitsmodul

Ein Hardware-Sicherheitsmodul (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit) Verwaltung von Schlüsselmaterial und Ausführung kryptografischer Funktionen. Sie werden gelegentlich als "Vertrauensanker" ^[6] für den Aufbau von Sicherheitsarchitekturen bezeichnet und kommen sowohl in lokalen Rechenzentren ("on-premise") als auch in Cloud-Infrastrukturen zum Einsatz.

Je nach Modell stellen HSMs

symmetrische und asymmetrische Verschlüsselungsalgorithmen
Hashfunktionen
Funktionen zur Erzeugung von Zufallszahlen^[3]
Funktionen zur Erzeugung von Schlüsseln
Funktionen zur Verwaltung (Zugriffsrechte, Lebenszyklus) von Schlüsseln sowie
Funktionen zur Verwaltung einer HSM-Infrastruktur (Backup, Verteilung, Spiegelung)

zur Verfügung^[1]. Sie enthalten hierfür zum Teil spezialisierte Hardware-Bausteine, z.B. zur Erzeugung von Zufallszahlen oder zur effizienten Ausführung von Ver- und Entschlüsselungsoperationen.

HSMs werden sowohl als Teilkomponente für Rechner (z.B. PCI-Karte oder PCMCIA-Steckmodul) oder als eigenständiges Gerät (z.B. als Modul für 19-Zoll-Serverschränke) angeboten.

Anwendungsbereiche

HSMs kommen heute vornehmlich in Bereichen mit hohen Sicherheitsanforderungen wie

Finanzdienstleistungen/Zahlungsverkehr
Herstellung von Ausweisen und Kreditkarten
Maut- und Ticketsysteme
Zertifikats- und Signaturdienste
Verschlüsselte Archivierung

zum Einsatz^[1], finden aber mit der wachsenden Bedeutung organisationsübergreifender IT-Infrastrukturen (Stichwort: Cloud) auch darüber hinaus zunehmend Verbreitung.

Einsatz von HSMs in IT-Sicherheitsarchitekturen

Ausgangspunkt einer umfassenden IT-Sicherheitsarchitektur ist die sichere Verwaltung von Schlüsseln. Dies ist die zentrale Aufgabe von HSMs, wobei die Schlüssel entweder innerhalb der HSMs durch geprüfte und manipulationsgeschützte Algorithmen generiert oder extern erzeugt und auf einem sicheren Kanal auf das HSM gebracht werden (-> "Bring Your Own Key", kurz BYOK^[8]).

Mit Blick auf Angriffe auf den Hauptspeicher der Nutzersysteme sollten die Schlüssel die sichere Umgebung der HSM niemals verlassen, d.h. auf Basis dieser Schlüssel durchzuführende Ver- und Entschlüsselungsoperationen erfolgen i.d.R. ebenfalls innerhalb des HSMs.

Je nach Einsatzszenario werden auch anwendungsspezifische Schlüssel oder Verbindungs¬zeichenketten (engl.: Connection Strings), die innerhalb der Anwendung verschlüsselt gespeichert werden, mithilfe eines in der HSM gespeicherten Master-Keys ver- bzw. entschlüsselt und nur zur Laufzeit der Anwendung im Klartext im Hauptspeicher gehalten (Beispiel: MS Azure SQL TDE mit Azure KeyVault -> "TDE-Protector" = MasterKey, "Database Encryption Key" (DEK) = anwendungsspezifischer Schlüssel^[8]). Dieses Vorgehen ist mitunter aus Gründen des Durchsatzes oder der Anwendungsarchitektur (z.B. Datenbanken) erforderlich; in diesem Fall sind jedoch die Anwendungsdaten und der anwendungsspezifische Schlüssel während zur Laufzeit der Anwendung im Hauptspeicher angreifbar.

Ein weiteres Einsatzszenario ist die sichere Erzeugung temporärer Sitzungsschlüssel (engl. Session Keys) durch ein HSM.

Zertifizierungen für HSMs

Für HSMs existieren verschiedene Sicherheitsstandards, nach denen diese Geräte zertifiziert werden können. Der geläufigste in diesem Kontext ist FIPS (Federal Information Processing Standards) 140-2. Die Nachfolgeversion FIPS 140-3 stellt keinen eigenständigen Standard mehr dar, sondern referenziert ihrerseits den internationalen Standard ISO/IEC 19790:2012^[7] bzw. ISO/IEC 24759:2017.

FIPS 140-2 unterscheidet vier aufeinander aufbauende Sicherheitsstufen (engl.: Levels)^[2]

Level 1 - Verwendung freigegebener Algorithmen; keine spez. Sicherheitsanforderungen an die Hardware
Level 2 - Hardware muss physisch so aufgebaut sein, dass Manipulationen bzw. Manipulationsversuche erkannt werden können (engl.: "tamper-evident")
Level 3 - Hardware muss physisch so aufgebaut sein, dass "einfache" Manipulationen bzw. Manipulationsversuche erkannt und (z.B. durch sichere Löschung der Daten) verhindert werden (engl: "tamper-proof").
Level 4 - Ähnlich wie Level 3, jedoch muss der Schutz hier "mit sehr hoher Wahrscheinlichkeit" gegen alle denkbaren Angriffe wirksam sein. Geräte dieses Levels sollen insbesondere für den Einsatz in ungeschützten Umgebungen geeignet sein.

Zusammenfassung der Anforderungen pro Sicherheitsstufe nach FIPS 140-2^[4]
	Sicherheitsstufe 1	Sicherheitsstufe 2	Sicherheitsstufe 3	Sicherheitsstufe 4
Spezifikation des kryptografischen Moduls	Spezifikation des kryptografischen Moduls, der kryptografischen Abgrenzung, der freigegebenen Algorithmen und der freigegebenen Betriebsmodi. Beschreibung des kryptografischen Moduls, einschließlich aller Hardware-, Software- und Firmware-Komponenten. Erklärung der Sicherheitsrichtlinie des Moduls.
Anschlüsse und Schnittstellen des kryptografischen Moduls	Notwendige und optionale Schnittstellen. Spezifikation aller Schnittstellen und aller Eingangs- und Ausgangsdatenpfade.		Datenanschlüsse für ungesicherte kritische Sicherheitsparameter (engl.: Critical Security Parameter, CSP) logisch oder physisch getrennt von anderen Anschlüssen.
Rollen, Dienste und Authentifizierung	Logische Trennung von notwendigen und optionalen Rollen und Diensten.	Rollen- oder Identitäts-basierte Bediener-Authentifizierung	Identitäts-basierte Bediener-Authentifizierung
Endlicher Zustandsautomat	Spezifikation eines endlichen Zustandsautomaten. Notwendige und optionale Zustände. Zustands-Übergangs-Diagramm und Spezifikation der Zustandsübergänge.
Betriebsumfeld	Einzelner Bediener. Ausführbarer Code. Freigegebener Integritätssicherungs-Mechanismus	Gemäß EAL2 festgelegte Schutzprofile (engl.: Protection Profile, PP) mit spezifizierten Benutzerbestimmbaren Zugriffskontrollmechnismen und Auditierung	Gemäß EAL3 festgelegte Schutzprofile mit Sicherheitsrichtlinien-Modellierung.	Gemäß EAL4 festgelegte Schutzprofile mit vertrauenswürdigem Pfad (engl.: Trusted Path).
Kryptografisches Schlüsselmanagement	Schlüsselmanagement-Mechanismen: Zufallszahlen- und Schlüsselgenerierung, Schlüsseleinrichtung, Schlüsselverteilung, Schlüsselein-/-ausgabe, Schlüsselspeicherung und Schlüssel-Nullsetzung (engl.: Zeroization).
Kryptografisches Schlüsselmanagement	Geheime und private Schlüssel, die manuell eingerichtet wurden, können in Klartextform ein- oder ausgegeben werden.		Geheime und private Schlüssel, die manuell eingerichtet wurden, sollen verschlüsselt oder mit Split-Knowledge-Verfahren ein- oder ausgegeben werden.
EM-Interferenz / EM-Kompatibilität	47 CFR FCC Part 15. Subpart B, Class A (gewerbliche Nutzung). Anwendbare FCC-Anforderungen (für Funk).		47 CFR FCC Part 15. Subpart B, Class B (private Nutzung).
Selbsttest	Einschalttests: Tests der kryptografischen Algorithmen, Software-/Firmware-Integritätstests, Tests kritischer Funktionen. Bedingte Tests.
Entwurfsabsicherung	Konfigurations-management (KM). Sichere Installation und Generierung. Übereinstimmung von Entwurf und Richtlinie Leitlinien-Dokumente	KM-System. Sichere Verteilung. Funktionale Spezifikation.	Implementierung in Hochsprache	Formale Modellierung. Detaillierte Erläuterungen (informelle Beweise). Vor- und Nachbedingungen
Mitigation anderer Angriffe	Spezifikation der Mitigation von Angriffen, für die derzeit keine testbaren Anforderungen verfügbar sind.

Das NIST stellt ein Online-Verzeichnis von gem. FIPS 140-2 zertifizierten Geräten zur Verfügung^[5].

Aspekte der Sicherheitsorganisation

HSMs dienen ggü. rein software-gestützten "Schlüsseltresoren" hauptsächlich dem Schutz vor Angriffen von Tätern innerhalb der Anwenderorganisation (lokale Server) bzw. in Cloud-Umgebungen gegen die Angriffsszenarien "Cloud-Anbieter gegen Cloud-Nutzer" und "Cloud-Nachbar gegen Cloud-Nutzer".

Im Hinblick auf die Gestaltung einer Sicherheitsorganisation unterstützen HSMs auf verschiedene Weise: Erweiterte Funktionstrennung: Mit der Verwendung von HSMs kann neben den geläufigen Administrationsbereichen (Betriebssysteme, Anwendungen, Datenbanken und Netzwerke) ein eigenständiger Administrationsbereich für Schlüsselverwaltung und Kryptofunktionen geschaffen werden. Mehr-Augen-Prinzip: HSMs bieten in der Regel Funktionen, die den Zugriff auf Schlüsselmaterial oder die Konfiguration von Kryptofunktionen nach einem "erweiterten 4-Augen-Prinzip" schützen, d.h. es können Richtlinien festgelegt werden, dass solche Änderungen nur mit der Freigaben von mehreren Personen aus dem Pool der Administrationsberechtigten möglich sind ("k-aus-n"). Zentralisierung der Schlüsselmanagements: HSMs bieten in der Regel Unterstützung für ihre sichere, zentrale Administration, Verteilung, Sicherung und Überwachung.

HSMs aus Sicht der IT-Forensik

Aus IT-forensischer Sicht sollte die Frage, ob in einer lokalen Client-Server-Architektur oder einer Cloud-Architektur HSMs zum Einsatz kommen, Teil der Operationalen Vorbereitung (siehe BSI-Vorgehensmodell) sein, da dies wesentlichen Einfluss auf das weitere Vorgehen haben sollte.

In einer IT-Sicherheitsarchitektur unter Einsatz von HSMs ist davon auszugehen, dass insbesondere sicherheitskritische Datenbereiche im Transport (Data in Transit) und in der persistenten Speicherung (Data at Rest) sicher verschlüsselt und damit der Auswertung nicht zugänglich sein werden. Damit kommt einerseits der Live-Akquise (Data in Use) eine höhere Bedeutung zu (ggf. Auslesen von anwendungsspezifischen Schlüsseln, s.o.). Andererseits kommt der Frage, ob von einer Kooperation der Krypto-Administration ausgegangen werden kann, eine besondere Bedeutung zu.