Hardware-Sicherheitsmodul: Unterschied zwischen den Versionen

Aus IT-Forensik Wiki
K (St181103 verschob die Seite Hardware Security Module nach Hardware-Sicherheitsmodul: Übersetzung)
 
(2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 44: Zeile 44:
|-
|-
|  
|  
|Stufe 1
|Sicherheitsstufe 1
|Stufe 2
|Sicherheitsstufe 2
|Stufe 3
|Sicherheitsstufe 3
|Stufe 4
|Sicherheitsstufe 4
|-  
|-  
|Cryptographic Module Specification
|Spezifikation des kryptografischen Moduls
|colspan="4"|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.
|colspan="4"|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.
|-
|-
|Cryptographic Module Ports and Interfaces
|Anschlüsse und Schnittstellen des kryptografischen Moduls
|colspan="2"|Required and optional interfaces.  Specification of all interfaces and of all input and output data paths.
|colspan="2"|Notwendige und optionale Schnittstellen.  Spezifikation aller Schnittstellen und aller Eingangs- und Ausgangsdatenpfade.
|colspan="2"|Data ports for unprotected critical security parameters logically or physically separated from other data ports.
|colspan="2"|Datenanschlüsse für ungesicherte kritische Sicherheitsparameter (engl.: Critical Security Parameter, CSP) logisch oder physisch getrennt von anderen Anschlüssen.
|-
|-
|Roles, Services, and Authentication
|Rollen, Dienste und Authentifizierung
|Logical separation of required and optional roles and services.
|Logische Trennung von notwendigen und optionalen Rollen und Diensten.
|Role-based or identity-based operator authentication.
|Rollen- oder Identitäts-basierte Bediener-Authentifizierung
|colspan="2"|Identity-based operator authentication.
|colspan="2"|Identitäts-basierte Bediener-Authentifizierung
|-
|-
|Finite State Model
|Endlicher Zustandsautomat
|colspan="4"|Specification of finite state model. Required states and optional states.  State transition diagram and specification of state transitions.
|colspan="4"|Spezifikation eines endlichen Zustandsautomaten. Notwendige und optionale Zustände. Zustands-Übergangs-Diagramm und Spezifikation der Zustandsübergänge.   
|-
|-
|Operational Environment
|Betriebsumfeld
|Single operator. Executable code. Approved integrity technique
|Einzelner Bediener. Ausführbarer Code. Freigegebener Integritätssicherungs-Mechanismus
|Referenced PPs evaluated at EAL2 with specified discretionary access control mechanisms and auditing.
|Gemäß EAL2 festgelegte Schutzprofile (engl.: Protection Profile, PP) mit spezifizierten Benutzerbestimmbaren Zugriffskontrollmechnismen und Auditierung
|Referenced PPs plus trusted path evaluated at EAL3 plus security policy modeling.
|Gemäß EAL3 festgelegte Schutzprofile mit Sicherheitsrichtlinien-Modellierung.
|Referenced PPs plus trusted path evaluated at EAL4.
|Gemäß EAL4 festgelegte Schutzprofile mit vertrauenswürdigem Pfad (engl.: Trusted Path).
|-
|-
|rowspan="2"|Cryptographic Key Management
|rowspan="2"|Kryptografisches Schlüsselmanagement
|colspan="4"|Key management mechanisms: random number and key generation, key establishment, key distribution, key entry/output, key storage, and key zeroization.
|colspan="4"|Schlüsselmanagement-Mechanismen: Zufallszahlen- und Schlüsselgenerierung, Schlüsseleinrichtung, Schlüsselverteilung, Schlüsselein-/-ausgabe, Schlüsselspeicherung und Schlüssel-Nullsetzung (engl.: Zeroization).
|-
|-
|colspan="2"|Secret and private keys established using manual methods may be entered or output in plaintext form.
|colspan="2"|Geheime und private Schlüssel, die manuell eingerichtet wurden, können in Klartextform ein- oder ausgegeben werden.
|colspan="2"|Secret and private keys established using manual methods shall be entered or output encrypted or with split knowledge procedures.
|colspan="2"|Geheime und private Schlüssel, die manuell eingerichtet wurden, sollen verschlüsselt oder mit Split-Knowledge-Verfahren ein- oder ausgegeben werden.
|-
|-
|EMI/EMC
|EM-Interferenz / EM-Kompatibilität
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class A (Business use).  Applicable FCC requirements (for radio).
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class A (gewerbliche Nutzung).  Anwendbare FCC-Anforderungen (für Funk).
|colspan="2"|47 CFR FCC Part 15.  Subpart B, Class B (Home use).
|colspan="2"|47 CFR FCC Part 15.  Subpart B, Class B (private Nutzung).
|-
|-
|Self-Tests
|Selbsttest
|colspan="4"|Power-up tests: cryptographic algorithm tests, software/firmware integrity tests, critical functions tests.  Conditional tests.
|colspan="4"|Einschalttests: Tests der kryptografischen Algorithmen, Software-/Firmware-Integritätstests, Tests kritischer Funktionen.  Bedingte Tests.
|-
|-
|Design Assurance
|Entwurfsabsicherung
|Configuration management (CM). Secure installation and generation. Design and policy correspondence. Guidance documents.
|Konfigurations-management (KM). Sichere Installation und Generierung. Übereinstimmung von Entwurf und Richtlinie Leitlinien-Dokumente
|CM system.  Secure distribution. Functional specification.
|KM-System.  Sichere Verteilung. Funktionale Spezifikation.
|High-level language implementation.
|Implementierung in Hochsprache
|Formal model. Detailed explanations (informal proofs). Preconditions and postcondition
|Formale Modellierung. Detaillierte Erläuterungen (informelle Beweise). Vor- und Nachbedingungen
|-
|-
|Mitigation of Other  Attack
|Mitigation anderer Angriffe
|colspan="4"|Specification of mitigation of attacks for which no testable requirements are currently available.
|colspan="4"|Spezifikation der Mitigation von Angriffen, für die derzeit keine testbaren Anforderungen verfügbar sind.
|}
|}
   
   
Zeile 104: Zeile 104:
   
   
==HSMs aus Sicht der IT-Forensik==
==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.
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.
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.

Aktuelle Version vom 21. August 2019, 12:27 Uhr

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

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

Abgerufen von „http://it-forensik.fiw.hs-wismar.de/index.php?title=Hardware-Sicherheitsmodul&oldid=823“