Hardware-Sicherheitsmodul - Versionsgeschichte

Etduen: /* HSMs aus Sicht der IT-Forensik */

2019-08-21T10:27:17Z

HSMs aus Sicht der IT-Forensik

← Nächstältere Version		Version vom 21. August 2019, 10:27 Uhr
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 (siehe [[BSI-Vorgehensmodell]])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.

Etduen: /* HSMs aus Sicht der IT-Forensik */

2019-08-21T10:27:04Z

HSMs aus Sicht der IT-Forensik

← Nächstältere Version		Version vom 21. August 2019, 10:27 Uhr
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.

St181103 am 18. Juli 2019 um 16:41 Uhr

2019-07-18T16:41:40Z

← Nächstältere Version		Version vom 18. Juli 2019, 16:41 Uhr
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.
	\|}		\|}

St181103: St181103 verschob die Seite Hardware Security Module nach Hardware-Sicherheitsmodul: Übersetzung

2019-07-18T06:07:48Z

St181103 verschob die Seite Hardware Security Module nach Hardware-Sicherheitsmodul: Übersetzung

← Nächstältere Version	Version vom 18. Juli 2019, 06:07 Uhr
(kein Unterschied)

St181103 am 17. Juli 2019 um 20:00 Uhr

2019-07-17T20:00:32Z

← Nächstältere Version		Version vom 17. Juli 2019, 20:00 Uhr
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 ~~operativen~~ 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 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.

St181103: Die Seite wurde neu angelegt: „Ein '''Hardware-Sicherheitsmodul''' (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit)…“

2019-07-17T19:57:32Z

Die Seite wurde neu angelegt: „Ein '''Hardware-Sicherheitsmodul''' (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit)…“

Neue Seite

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.

:
{| class="wikitable"
!colspan="5"|Zusammenfassung der Anforderungen pro Sicherheitsstufe nach FIPS 140-2[4]
|-
|
|Stufe 1
|Stufe 2
|Stufe 3
|Stufe 4
|-
|Cryptographic Module Specification
|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.
|-
|Cryptographic Module Ports and Interfaces
|colspan="2"|Required and optional interfaces. Specification of all interfaces and of all input and output data paths.
|colspan="2"|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.
|colspan="2"|Identity-based operator authentication.
|-
|Finite State Model
|colspan="4"|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.
|-
|rowspan="2"|Cryptographic Key Management
|colspan="4"|Key management mechanisms: random number and key generation, key establishment, key distribution, key entry/output, key storage, and key zeroization.
|-
|colspan="2"|Secret and private keys established using manual methods may be entered or output in plaintext form.
|colspan="2"|Secret and private keys established using manual methods shall be entered or output encrypted or with split knowledge procedures.
|-
|EMI/EMC
|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 B (Home use).
|-
|Self-Tests
|colspan="4"|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
|colspan="4"|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 operativen 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