Je mehr „Internet of Things“-Geräte (IoT-Geräte) in unseren Alltag einziehen desto größer wird das Bedürfnis, dass diese Geräte vertraulich und sicher kommunizieren. Bestes Beispiel hierfür sind unsere Smarthome-Geräte. Die Kommunikation ist zwar stark verschlüsselt aber die Geräte sind an sich physisch angreifbar. Was bedeutet das? Das bedeutet, dass das zu schützende Gut (Asset) unseres Heimes mit einem Schlüssel und Programm geschützt wird, welches sich vor Ort frei zugänglich befindet. Stellen Sie sich das so vor, als wäre Ihr TAN-Brief (auf dem sich evtl. sogar Ihr Benutzername und Passwort aufgeschrieben befinden) frei zugänglich ist. Alles was die Einbrecher machen müssten wäre dieses Dokument finden und kopieren (natürlich mit einem Smartphone) und danach nachträglich in aller Ruhe ihr Konto leerzuräumen (das ist auch der Grund warum die meisten Banken eine ‚“Zwei-Faktor-Authentifizierung“ verwenden, aber hierzu wird es später einen separaten Blogartikel von mir noch geben). Oder noch ein anderes Beispiel. Jede Alarmanlage hat eine interne Uhr. Diese wird vom Einbrecher einfach angehalten, so dass für die Alarmanlage die Zeit stillsteht. Da nützt Ihnen auch die beste Verschlüsselungstechnik nichts. Es stellt sich daher die Frage, wie überhaupt etwas sicher sein kann, wenn „Assets“ frei zugänglich sind? Die Antwort – Hardware-Sicherheitsmodule (HSMs)! 

Was sind Hardware-Sicherheitsmodule (HSM)? 

Ein HSM ist eine eigenständige Hardwareeinheit, welche benutzt wird, um kryptografische Schlüssel und Operationen (Verschlüsslungen, Signieren …) sowie vollständige Applikationen (z.B. PIN/TAN-Herleitungen) eigenständig und optimiert in einer „sicheren kryptografischen Umgebung“ aufzubewahren oder auszuführen. Unter einer „sicheren kryptografischen Umgebung“ verstehe ich Umgebungen, die von außen nur mit sehr großem Aufwand zugänglich sind und bei dem Versuch in diese Umgebung einzudringen, dies in den meisten Fällen dazu führt, dass das HSM sich eigenständig vernichtet. Man spricht bei solch einem Versuch des Eindringens vom „Tampering“. Das Vernichten hat man sich nicht so vorzustellen wie bei Mission Impossible wo die Nachricht sich mithilfe von Feuer und Rauch selbst vernichtet, sondern es werden die Schlüssel, Daten und Programminhalte unwiderruflich gelöscht.

Wo werden HSMs eingesetzt?

Mögliche Einsatzgebiete eines HSM sind:

• Geldautomaten
• Smartcards (z.B. Debit- oder Kreditkarten)
• Ausweisdokumenten mit Chiptechnologie (z.B. Personalausweis, Reisepässe oder Führerscheine)
• Security-Prozessoren in Netzwerken von Zahlungsverkehrsdienstleister
• Zugangskontrollsysteme (z.B. Fahrzeuge und Gebäude)
• Transaktionssicherung in Maut- und Ticketingsystemen
• Zeitstempeldienste
• Signaturserver
• Archivierungssysteme
• Zertifizierungsstellen (PKI)
• Kassensysteme
• Wallets (Smartphones, Cryptocurrency Hardware Wallets)
• Zufallsgeneratoren
• IoT-Geräte
• Produktionskritische Umgebungen
• Maschinen

Sie sehen, dass HSMs in nahezu allen privaten und geschäftskritischen Prozessen und Umgebungen eingesetzt werden.

Welche HSM-Varianten gibt es?

Hardware Security Module lassen sich grob in die folgenden Varianten einteilen:

• Smartcards nennt man Chipkarten, Schlüsselkarten oder Integrated Circuit Cards (ICC). Dabei handelt es sich um Kunststoffkarten mit eingebautem Chip. Dieser enthält einen Mikroprozessor und einen nichtflüchtigen EEPROM-Speicher. Ganz simple oder ältere Smartcards haben nur einen Hardwareschaltkreis zum Ansteuern eines Speicherbausteins (Speicherchips). Sie werden in sicherheitskritischen Anwendungen für die Identifikation von Personen und Berechtigungsnachweise eingesetzt (z.B. bei Zahlungsverfahren, Mobiltelefonen, Ausweissystemen etc.).
• Trusted Plattform Module (TPM) speichern abgeleitete Schlüssel von IT-Systemen und Personen für kleinere IT-Systeme (z.B. PCs, Notebooks, Smartphones, Drucker, Fahrzeuge etc.). 
• Software-HSM bieten alle Softwarefunktion eines HSMs jedoch ohne den Schutz vor physischen oder Brute-Force Angriffen mithilfe eines Hardware Crypto-Prozessor. Damit ist eine Software-HSM kein echtes HSM. 
• USB oder PCI Hardware Security Module werden für kryptographische Anwendungen eines PCs oder Servers benutzt. Diese Module besitzen geringere kryptographische Performance und können weniger Schlüssel speichern.
• Netzwerk Hardware Security Module werden für besonders wertvolle sicherheitsrelevante Informationen (Master-Keys, Schlüssel von globaler Bedeutung etc.) und für hohe Performance-Anforderungen verwendet. Der Grund ist der, dass die Einsatzgebiete Sicherheitskomponenten für größere IT-Systeme, sichere Produktionsstädten oder Hoch-Sicherheitsumfelder sind.
• High-Level Security Module (HLSM) ist in der Regel ein Vielfaches sicherer und leistungsfähiger als herkömmliche HSMs. Aus diesem Grund sind diese aber auch wesentlich teurer (mehrere tausend Euro).

Wie ist ein HSM aufgebaut?

Systemanforderungen

Über die Jahre haben sich mit den kommenden Technologien die HSM angepasst, aber sie folgten immer den folgenden Anforderungen:

• Hardwarezugriffsresistenz: Das HSM erkennt ein Eindringen in die Hardware mithilfe von Sensoren (Temperatur- und Spannungssensoren) und löscht daraufhin unverzüglich seine Assets. Dies erreicht die HSM-Hardware mithilfe einer gesonderten Schutzhülle. Ein gewaltsames Eindringen verursacht eine Schädigung der Schutzhülle, welche oft auch eine Schädigung der HSM-Hardware führt und damit dem Verlust der Assets. Die Schutzhülle kann sehr simpel sein (z.B. aus Plastik) oder eingebettet bis auf die Nanostrukturebene der Schaltkreise.
• Seitenkanalangriffsresidenz: Hier werden physikalische Nebeneffekte gesammelt und versucht durch Analyse dieser Nebeneffekte die Assets der HSMs zu extrahieren. Die physikalischen Nebeneffekte, welche beobachtet werden, sind oft der Energieverbrauch, die elektromagnetischen Abstrahlungen oder der Zeitbedarf zum Ausführen bestimmter kryptografischer Funktionen.   
• Softwarezugriffsresidenz: Hier wird versucht mithilfe von SW-Bugs von außen Zugriff auf die Assets der HSMs zu erhalten. Z.B. kann ein bestimmter Input an die HSM dazu führen, dass wegen eines Fehlers beim Programmieren der HSM der PIN-Zugriffszähler (manche HSMs vernichten ihre Assets nachdem dreimal die PIN falsch eingegeben wurde) nicht hochgezählt wird. Angreifer besitzen oft Insiderwissen zum HSM oder wissen, wie HSM-Programmierer „denken“ könnten, um Fehler während des Programmierens zu begehen.   
• Sicherer Zufallsgenerator: Hier werden für die Kryptografie geeignete Zufallsgeneratoren implementiert. Solche Zufallsgeneratoren werden z.B. zur Schlüsselgenerierung, Nonces (zufällige Bytefolgen), Salts (um Passwörter nicht im Klartext zu speichern), Stromverschlüsselung und One-Time-Pads benutzt. Warum brauchen wir einen „guten“ Zufallsgenerator? Kein verwendeter Zufallsgenerator ist zufällig und deshalb heißen diese auch Pseudozufallsgeneratoren. „Schlechte“ Zufallsgeneratoren können ein Muster besitzen, welches dazu führen kann, dass Zufallszahlen „vorhergesagt“ werden könnten, um auf diese Art und Weise Informationen über den privaten Schlüssel aus dem öffentlichen Schlüssel ableiten zu können.  

Systemaufbau

Die Architektur eines HSM ist stark auf die Sicherheitsanforderungen von Anwendern ausgerichtet. Die folgende Abbildung zeigt einen typischen Aufbau eines HSM. Um das „Tampern“ zu verhindern ist das HSM umgeben mit einem physischen Schutzmantel. Eine Sensorik dient dazu das gewaltsame Durchbrechen des Mantels zu detektieren und aktiviert dabei eine Schaltung, welche die Assets unverzüglich löscht. In der Regel verfügen HSMs (nicht alle – z.B. Smartcards) auch über eine autarke Spannungsversorgung oder sogar eine Echtzeituhr (Real-Time Clock – RTC). Das IT-System ermöglich ein zuverlässiges Ausführen von Applikationen und kryptografischer Protokolle. 

Schnittstellen

PKCS#11

PKCS (Public-Key Cryptography Standards) ist eine Spezifikation für asymmetrische Kryptographie. Entwickelt wurden sie vom Unternehmen RSA Security Inc. und Partnern mit dem Ziel die Verbreitung asymmetrischer Verschlüsselungssysteme mittels Standardisierung voranzutreiben. Der PKCS-Standard ist in 15 verschiedene Bereiche unterteilt, wo das PKCS#11 (auch Cryptoki genannt) eine API zur Übertragung von kryptografischen Informationen beschreibt. 2013 übernahm die Organization for the Advancement of Structured Information Standards (OASIS) die Standardisierung. Dies ist die am meisten benutzte Schnittstellenbeschreibung zu HSMs.

JCE

Die Java Cryptography Extension (JCE) ist eine Java Schnittstelle und Framework für diverse kryptographische Aufgaben und Teil der Java Cryptography Architecture (JCA). Warum diese Aufteilung bzw. warum nicht gleich alles in der JCA? Die Aufteilung in JCE und JCA wurde wegen der US-Beschränkungen für Kryptografie eingeführt. Die JCA genügt diesen Restriktionen und darf in den USA eingesetzt werden. Die JCE und JCA ist unabhängig von der Implementierung der spezifischen Algorithmen mit dem Unterschied, dass die JCE über ein Service Provider Interface (SPI) verschiedene Implementierungen unterschiedlicher Anbieter gleichzeitig in die Java-Laufzeitumgebung einbindet. Ab Version 1.4 hat Java eine JCE- und JCA-Implementierung.

Microsoft Cryptography API

Die Schnittstelle bei Microsoft ist die Cryptography Next Generation (CNG) und unterstützt die derzeit üblichen symmetrische und asymmetrische Algorithmen sowie die Generierung von Zufallszahlen und alle gängigen Hash-Funktionen. Microsoft richtet sich an die so genannte „Suite B“ aus. Die „Suite B“ ist eine Liste welche 2005 von der National Institute of Standards and Technology (NIST) in Amerika veröffentlicht wurde. Diese Sammlung ist eine Empfehlung der NSA für den Einsatz kryptografischer Verfahren. Parallel dazu erstellte die NSA auch die Suite-A-Liste, um die Algorithmen für den Einsatz in hochsensiblen Bereichen darzustellen. Die Suite-A-Liste wurde nie von der NIST veröffentlicht!

Eine weitere Schnittstelle für HSMs hat Microsoft für Datenbankserver implementiert – das SQL-Server Extensible Key Management (EKM). Diese Funktionsschnittstelle ermöglicht es, mit einem HSM die in vielen Anwendungsbereichen geforderte Datenbankverschlüsselung „anzudocken“.

Andere Schnittstellen

Andere Schnittstellen sind entweder anbieterspezifisch oder es handelt sich um andere definierte Schnittstellen, wie z. B. OpenSSL. OpenSSL ist eine Bibliothek für Secure Socket Layer (SSL) und Transport Layer Security (TLS). Das Engine-Konzept von OpenSSL ermöglicht es Entwicklern, Smartcards und Hardware-Sicherheitsmodule für alle kryptografischen Verfahren einzubinden, sodass Applikationen die OpenSSL verwenden transparent auf HSMs zugreifen können.

Welche Zertifizierungen gibt es für die HSMs?

Für Hardware-Sicherheitsmodule werden nach den folgenden Standards zertifiziert:

• FIPS 140-1 und FIPS 140-2 (Federal Information Processing Standard): Diese wurden von der US-Bundesregierung entwickelt und beziehen sich auf alle zivilen Regierungseinrichtungen und deren Vertragslieferanten verwendet. Diese Standards beruhen auf Modifizierung der allgemein verwendeten Standards (z.B. ANSI, IEEE, ISO). Die 140 nummerierten FIPS-Veröffentlichungen stellen eine Reihe von Sicherheitsstandards dar, die bestimmte Vorgaben für Verschlüsselungsmodule festlegen. FIPS 140-1 wurde 1994 festgelegt, jedoch durch FIPS 140-2 ersetzt. Dieser heute aktuelle Standard wurde 2001 festgelegt.

• DK (Deutsche Kreditwirtschaft): Ist ein Zusammenschluss des Bundesverbandes der Deutschen Volksbanken und Raiffeisenbanken, des Bundesverbandes deutscher Banken, des Bundesverbandes Öffentlicher Banken Deutschlands, des Deutschen Sparkassen- und Giroverbandes und des Verbandes deutscher Pfandbriefbanken. Die DK hat als Zusammenschluss der Kreditinstitute in Deutschland allgemeine Zulassungsverfahren für verschiedene bargeldlose Zahlungsverfahren etabliert. Dies ermöglicht es Marktteilnehmern, Produkte und Dienstleistungen für den Betrieb der entsprechenden Systeme bereitzustellen. Im Rahmen dieser Zulassungen werden auch Ergebnisse von Evaluierungen und Zertifizierungen nach den Common Criteria integriert. 
• CC (Common Criteria): Ist ein allgemeiner internationaler Standard zur Prüfung und Bewertung von Sicherheitsanforderungen von IT-Produkten. Das bedeutet, dass der jeweilige CC-Level von dem jeweiligen Anwendungsgebiet der HSM abhängt. Z.B. soll die HSM zur Erzeugung von digitalen Signaturen verwendet werden, wird das CC Schutzprofil CWA 14167-2 verwendet.

Für einen Betrieb in Deutschland wacht darüber das BSI und gibt einen Rahmen für die Zulassungen und eine Liste von akkreditierten Zertifizierungsdienstleistern vor.  

Zusammenfassung

HSMs bieten eine „sichere kryptografische Umgebung“ um nicht nur deren Schlüssel aufzubewahren und kryptografische Operationen auszuführen, sondern auch eigene Applikationen auszuführen. Die HSMs werden immer kompakter und robuster gegenüber Angriffen, welche „Tampern“ genannt werden. Mit dem Aufkommen von immer mehr IoT-Geräten innerhalb von Smarthomes, werden diese immer breiteren privaten Bereichen zugänglich. Ein enormer Schritt, wenn man bedenkt, dass die Anfänge teure militärische und finanzspezifische Anwendungen vor vielen Jahren wahren.     

Referenzen

http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html