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]
	Stufe 1	Stufe 2	Stufe 3	Stufe 4
Cryptographic Module Specification	Specification of cryptographic module, cryptographic boundary, Approved algorithms, and Approved modes of operation. Description of cryptographic module, including all hardware, software, and firmware components. Statement of module security policy.
Cryptographic Module Ports and Interfaces	Required and optional interfaces. Specification of all interfaces and of all input and output data paths.		Data ports for unprotected critical security parameters logically or physically separated from other data ports.
Roles, Services, and Authentication	Logical separation of required and optional roles and services.	Role-based or identity-based operator authentication.	Identity-based operator authentication.
Finite State Model	Specification of finite state model. Required states and optional states. State transition diagram and specification of state transitions.
Operational Environment	Single operator. Executable code. Approved integrity technique	Referenced PPs evaluated at EAL2 with specified discretionary access control mechanisms and auditing.	Referenced PPs plus trusted path evaluated at EAL3 plus security policy modeling.	Referenced PPs plus trusted path evaluated at EAL4.
Cryptographic Key Management	Key management mechanisms: random number and key generation, key establishment, key distribution, key entry/output, key storage, and key zeroization.
	Secret and private keys established using manual methods may be entered or output in plaintext form.		Secret and private keys established using manual methods shall be entered or output encrypted or with split knowledge procedures.
EMI/EMC	47 CFR FCC Part 15. Subpart B, Class A (Business use). Applicable FCC requirements (for radio).		47 CFR FCC Part 15. Subpart B, Class B (Home use).
Self-Tests	Power-up tests: cryptographic algorithm tests, software/firmware integrity tests, critical functions tests. Conditional tests.
Design Assurance	Configuration management (CM). Secure installation and generation. Design and policy correspondence. Guidance documents.	CM system. Secure distribution. Functional specification.	High-level language implementation.	Formal model. Detailed explanations (informal proofs). Preconditions and postcondition
Mitigation of Other Attack	Specification of mitigation of attacks for which no testable requirements are currently available.

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 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.

Weblinks

[1] https://de.wikipedia.org/wiki/Hardware-Sicherheitsmodul

[2] https://en.wikipedia.org/wiki/FIPS_140-2

[3] http://hsm.utimaco.com/de/loesungen/anwendungen/zufallszahlengenerator/

[4] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

[5] https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search

{6] https://safenet.gemalto.de/data-encryption/hardware-security-modules-hsms/

[7] https://www.iso.org/standard/52906.html

[8] https://docs.microsoft.com/en-us/azure/sql-database/transparent-data-encryption-byok-azure-sql