Hardware-Sicherheit h e rh e it smodule verstehen

Hard wa re -S ic
made in Germany

Sie erfahren:
Hardware-
)
• Wie HSM gebaut sind

odule (HSM
Sicherheitsm
• Welche Anwendungs-
schnittstellen heute verfüg-
bar sind

• Welche Zertifizierungen
Was Sie über Hardware- existieren

Sicherheitsmodule wissen • Wie Sie den Utimaco

HSM-Simulator nutzen
sollten! können

Kryptografische Anwendungen sind für das Absichern

von Datentransaktionen unverzichtbar. Nur durch den
Schutz und die gesicherte Aufbewahrung der verwende-
ten kryptografischen Schlüssel in Hardware-Sicherheits-
modulen ist es möglich, das Vertrauen in die Technik zu
gewährleisten.
Wir bei Utimaco stellen Ihnen diese komplexen Geräte
zur Verschlüsselung oder Signaturerstellung in Form eines Hardware-Sicherheit
kompletten und verständlichen Produktes zur Verfügung.
Dieses Buch ist ein praktischer Leitfaden für den Einsatz
Mach dich schlau:
Auf einen Blick: made in Germany
von HSM in Ihrer Infrastruktur. Sie müssen also kein
www.fuer-dummies.de • Z wischen den verschiedenen
Krypto-Experte sein um Hardware-Sicherheitsmodule
in vollem Umfang nutzen zu können. HSM-Technologien unterscheiden
•D
 as richtige HSM für Ihre
Anwendung wählen
• E rste Integrationen mit dem
HSM-Simulator starten

Andreas Philipp ist Vice President Business Development

Präsentiert von
bei Utimaco, dem führenden Hersteller von Hardware-
Sicherheitsmodulen. Mit mehr als 20 Jahren Erfahrung im
Bereich Hardware-Sicherheit ist Herr Philipp ein bekann-
ter Experte und regelmäßig gefragter Redner bei Konfe-
renzen der Sicherheitsindustrie. Andreas Philipp
 HSM
für Dummies
 Andreas Philipp

HSM
für Dummies

WILEY-VCH Verlag GmbH & Co. KGaA

 1. Auflage 2016

© 2016 WILEY-VCH Verlag GmbH & Co. KGaA, Weinheim

Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks
and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc.
and/or its affiliates, in the United States and other countries. Used by permission.

Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene
Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc.,
USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag
für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler
keine Haftung.

Korrektur: Leonie Christel, Forchheim

Satz: inmedialo Digital- und Printmedien UG, Plankstadt
Inhaltsverzeichnis
Einleitung 7
Über dieses Buch 7
Symbole, die in diesem Buch verwendet werden 8
Törichte Annahmen über die Leser 9
Wir über uns: Utimaco 9

Kapitel 1
Wie alles begann – ein bisschen Crypto-Geschichte 11
Der Zahlungsverkehr – der Startpunkt für
Hardware-Sicherheitsmodule 12
Brief und Siegel: Standardisierung 13

Kapitel 2
Die HSM-Technik heute 15
Bauformen von HSM 16
Sicherheitsanforderungen 17
Designprinzipien für HSM 17
Der physikalische Schutz 19
Standards und Normungen 20
Fazit 20

Kapitel 3
Die Schnittstelle: der Schlüssel zur Anwendung 21
Übersicht über die aktuellen Schnittstellen für HSM 23
PKCS#11 Cryptographic Token Interface Standard 23
JCE: Java Cryptography Extension 24
Microsoft Cryptography API: Next Generation 24
Weitere Standardschnittstellen 25
Einsatzzwecke von Schnittstellen 25

5
 HSM für Dummies

Die richtige Schnittstelle auswählen 26

Entwerfen und realisieren Sie Ihre eigene API 27

Kapitel 4
Zertifizierung – ein Gütesiegel, und dann? 29
Der FIPS 140-Standard 29
Common Criteria und HSM 31
Was bedeutet eine Zertifizierung für mein Projekt? 32

Anhang
Der HSM-Simulator 35
Installation des CryptoServer Simulators 35
Den CryptoServer Simulator starten 37
Die Verbindung zum CryptoServer Simulator via CAT aufbauen 38
Wie Sie sich als Admin in den Simulator einloggen 39

6
Einleitung
Hardware-Sicherheitsmodule (kurz HSM) sind heute in den unterschiedlichsten
Anwendungen integriert und ein wesentlicher Bestandteil von unseren moder-
nen Infrastrukturen.
Wir gehen davon aus, dass Sie sich im Bereich der IT-Sicherheit auskennen – sei
es im Bereich der Absicherung von Unternehmensinfrastrukturen oder aber im
Bereich von Sicherheitsinfrastrukturen für elektronische Identitäten oder Smart
Metering. Hier sind Sie sicherlich schon mehrfach über das Thema Hardware-
Sicherheitsmodule gestolpert oder haben sich auch schon mit dem einen oder
anderen Gerät detaillierter auseinandergesetzt.
In diesem Buch erfahren Sie alles über Hardware-Sicherheitsmodule – von der
historischen Entwicklung über die aktuellen Hardware- und Softwarelösungen
bis hin zu den Trends und Entwicklungen für die Zukunft. Daneben beschäfti-
gen wir uns detailliert mit dem Thema der Zertifizierung nach Standards wie
FIPS oder Common Criteria. Schließlich betrachten wir die heute existierenden
Standardschnittstellen im Markt und stellen Ihnen diese mit all ihren Vorteilen,
aber auch Nachteilen, kurz vor.
Mit diesem Buch haben Sie jederzeit ein Nachschlagewerk zur Hand, wenn es
um das Thema Hardware-Sicherheitsmodule, Techniken, Schnittstellen und
Zertifizierungen geht.

Über dieses Buch

Dieses Buch ist in vier Kapitel und einen Anhang gegliedert:
Kapitel 1: Wie alles begann – ein bisschen Crypto-Geschichte
Hier bekommen Sie einen kurzen Abriss über die Geschichte von Hardware-
Sicherheitsmodulen.
Kapitel 2: Die HSM-Technik heute
In diesem Abschnitt lernen Sie, wie Hardware-Sicherheitsmodule heute um-
gesetzt werden. Sie erfahren, wie die unterschiedliche Hardware aktuell aus-
sieht und sich die entsprechende Software darstellt.

7
 HSM für Dummies

Kapitel 3: Die Schnittstelle: der Schlüssel zur Anwendung

Fachchinesisch oder Expertenwissen – in diesem Kapitel erfahren Sie alles
über die heute gängigen Schnittstellen von Hardware-Sicherheitsmodulen.
Kapitel 4: Zertifizierung – ein Gütesiegel, und dann?
Hier erläutern wir Ihnen die unterschiedlichen Zertifizierungsverfahren und
deren Bezug in der Anwendung.
Anhang: Der HSM-Simulator – der schnelle Einstieg
Hier stellen wir Ihnen einen funktionsfähigen HSM-Simulator vor, mit dem
Sie direkt in die Welt der HSM starten können.
Blättern Sie ruhig nach Belieben hin und her, wählen Sie sich gezielt einen Ab-
schnitt aus oder lesen Sie das Buch in einem Rutsch.

Symbole, die in diesem Buch verwendet werden

In diesem Buch bekommen Sie einen Überblick zum Thema Hardware-Sicher-
heitsmodule. Ergänzendes und Wissenswertes haben wir mit den folgenden
Symbolen gekennzeichnet:

Hier finden Sie interessante Hinweise und weiterführende Informa-

tionsquellen.

Achtung! Hier gibt es Hinweise zu Missverständnissen oder falschen

Interpretationen.

Hier möchten wir Sie warnen! Schnell sind falsche Annahmen ge-
macht, die gerade im Sicherheitsumfeld zu Schwachstellen führen.

Hier ist der Techniker gefragt. Hier gibt es Hintergründe und weiter-
führende Informationen rund um die Technik von Hardware-Sicher-
heitsmodulen.

8
 Einleitung

Törichte Annahmen über die Leser

Als wir dieses Buch geschrieben haben, sind wir davon ausgegangen, dass
Sie im Bereich der Kryptografie zu Hause sind.
Sie sich etwas besser in dem Bereich Hardware-Sicherheitsmodule ausken-
nen möchten.
Nach dem Lesen des Buches haben Sie eine gute Übersicht über das Gebiet
Hardware-Sicherheitsmodule.

Wir über uns: Utimaco

Utimaco ist ein weltweit tätiger Anbieter von professionellen IT-Sicherheits-
lösungen mit Sitz in Aachen, Deutschland. Seit 1994 entwickeln wir bei Utimaco
Hardware-Sicherheitsmodule. Damit zählt Utimaco mit zu den am längsten im
Markt etablierten Anbietern für HSM. Kunden und Partner von Utimaco in allen
Teilen der Welt schätzen die Zuverlässigkeit und die langfristige Investitions-
sicherheit der Utimaco-Sicherheitslösungen sowie die vielfältigen zertifizierten
IT-Sicherheitsstandards. Utimaco steht für anerkannte Produktqualität, Bedie-
nerfreundlichkeit, exzellenten Support und ein marktgerechtes Angebot, her-
gestellt in Deutschland. Weitere Informationen finden Sie unter:
www.hsm.utimaco.com/de/.

9
 1
Wie alles begann – ein bisschen
Crypto-Geschichte
In diesem Kapitel
Warum HSM entwickelt wurden
Wie die ersten Geräte aussahen und welche Techniken sie verwendeten
Welche ersten Formen der Standardisierung und Zertifizierung es gab

E s verwundert Sie sicherlich nicht, wenn wir Ihnen erzählen, dass Hardware-
Sicherheitsmodule ursprünglich für den Einsatz im militärischen Umfeld
entwickelt bzw. erfunden wurden. Sicherheitsmodule entstanden in einer Zeit,
in der Spezialhardware notwendig war, um kryptografische Operationen durch-
zuführen. Denn die Leistungsfähigkeit damaliger Rechnersysteme war – gerade,
was die Durchführung mathematischer Funktionen betrifft – noch nicht ent-
sprechend ausgereift. Somit war es naheliegend, einen Co-Prozessor zu bauen,
der die Mathematik der Kryptografie ausführt. In den späten 70er und frühen
80er Jahren kam dann mit dem Data Encryption Standard (DES) ein Algorith-
mus auf den Markt, der sich effizient in Hardware implementieren ließ. Das
führte zwar zu effizienten Implementierungen in Soft- und Hardware, aber lei-
der musste man erkennen, dass man noch keine Lösung für den Schutz der ver-
wendeten kryptografischen Schlüssel hatte. Das war der Punkt, an dem die ers-
ten Hardware-Sicherheitsmodule entwickelt wurden. Die ersten Geräte waren
zum Teil mit sich selbst zerstörender Technik ausgerüstet.

Hier finden Sie ein paar historische Geräte: »NSA devices with ex-
plosive tamper resistance« http://www.nsa.gov/about/crypto
logic_heritage/museum/

Diese Kombination von starken Verschlüsselungsverfahren (zumindest zu dieser

Zeit) und dem Ziel der Absicherung des Computersystems, auf dem der Algorith-
mus zum Einsatz kommt, trieb die Entwicklung von Hardware-Sicherheitsmo-
dulen voran. Die Technologie der Hardware-Sicherheitsmodule wurde jedoch
erst mit der flächendeckenden Einführung des Geldautomaten der kommerziel-
len Industriewelt zugänglich gemacht.

11
 HSM für Dummies

Der Zahlungsverkehr – der Startpunkt für

Hardware-Sicherheitsmodule
Wir kennen Geldautomaten heute als unabhängige Multi-Service-Einheiten. Bis
es so weit war, hatten sie jedoch Entwicklungszyklen von mehreren Dekaden hin-
ter sich. Als nach Einführung der Geräte das internationale Geldautomatennetz
wuchs, konzentrierte man sich mehr und mehr auf die Sicherheit der datenverar-
beitenden Großrechner (Mainframes) im Netzwerk. In den ersten Jahren waren
die Verschlüsselungsroutinen Teil des datenverarbeitenden Programmes des
Großrechners an sich. Dies hatte zur Folge, dass die sensitiven kryptografischen
Schlüsseldaten direkt im Speicherbereich des Mainframes gespeichert wurden.
Da jedoch Personen Zugriff auf diese Speicherbereiche hatten, war das Sicher-
heitsrisiko hoch und deshalb war schnell klar, dass hier Abhilfe geschaffen wer-
den musste. Zudem musste es sich um ein extern zum Mainframe betriebenes
Gerät handeln, das den sicherheitsrelevanten Code ausführen konnte und eben-
falls einen gesicherten Speicherort für die kryptografischen Schlüssel bot.

Im Grunde war die Aufgabe der »Finanz-HSM« eher simpel, dennoch

in ihrer Auswirkung relativ kritisch. Die Geräte wurden und werden
auch heute noch zur Speicherung der kryptografischen Schlüssel ein-
gesetzt, mit denen man die Karten-PIN von der Accountnummer ab-
leiten kann. Da die Policy lautet: »Alle PINs sind in verschlüsselter
Form vorzuhalten und die Klartext-PIN darf niemals unberechtigten
Dritten zugänglich sein«, war relativ schnell klar, dass hier HSM ein-
gesetzt werden mussten.

Abbildung 1.1: Das erste Sicherheitsmodul KryptoServer von Utimaco

12
 1 Wie alles begann – ein bisschen Crypto-Geschichte

Erste kommerzielle Geräte wurden fast zeitgleich von IBM und Racal entwickelt.
Auch Utimaco kam zu dieser Zeit mit seinem ersten Gerät auf den Markt.

IBM war mit seiner 3845- (Table-Top-Geräte) bzw. 3846-Serie (Rack-Mounted-

Geräte) ganz auf den Einsatz innerhalb des Mainframes fokussiert, wobei Racal
den Anwendungsschwerpunkt eher auf den alternativen Einsatz legte.

Eine schöne Übersicht zu Geräten und deren Bauweise finden Sie

unter: http://www.cryptomuseum.com/crypto/index.htm.
Hier können Sie nach Hersteller oder nach Gerätetyp suchen.

Was schon damals bei den Geräten auffiel, war die separate Eingabeeinheit, die
es ermöglichte, Schlüsselmaterial einzubringen. Jedoch waren diese Geräte
immer so konzipiert, dass sie die folgenden Anforderungen erfüllten:
Physikalische Absicherung des Datenspeichers, in dem kryptografische
Schlüssel verwahrt werden. Absicherung an dieser Stelle bedeutet das Er-
kennen von unbefugtem Zugriff.
Auslagerung des sicherheitsrelevanten Programmcodes innerhalb des HSM.
Zugriffskontrolle unterstützt durch ein Rechte- und Rollenkonzept.

Brief und Siegel: Standardisierung

Waren in den Anfängen der Sicherheitsmodule weitgehend keine Standards und
allgemeingültigen Prüfverfahren verfügbar, so hat man auf nationaler Ebene
sehr schnell erkannt, dass Anforderungen an die Sicherheit der HSM-Technolo-
gie notwendig sind. Aus diesem Grund wurden zuerst innerhalb der Kreditwirt-
schaft entsprechende Anforderungskataloge definiert und dann im Weiteren he-
rangezogen, wenn es um die Zulassung eines Gerätes ging. Aber auch hier ent-
stand, durch die zunehmende Internationalisierung des Zahlungsverkehrs, ein
Bedarf für international anerkannte und abgestimmte Standards und Prüfver-
fahren. Waren es in den Anfängen die »großen« Kreditkartenunternehmen Eu-
ropay, Mastercard und Visa, die ihre eigenen Prüfverfahren und Zulassungsme-
thoden definierten, so haben auch wir seit 1995 mit dem FIPS-Standard (Federal
Information Processing Standard) ein international anerkanntes Zertifizierungs-
schema. Ab 2012 kam dann die erste ISO-Norm dazu (ISO/IEC 19790:2012 Infor-
mation technology – Security techniques – Security requirements for crypto-
graphic modules), gefolgt von der Testnorm ISO/IEC 24759:2014 Information

13
 HSM für Dummies

technology – Security techniques – Test requirements for cryptographic modu-

les. Heute steht uns neben dem FIPS-Standard ebenfalls noch der Common Cri-
teria-Standard mit seinem Protection Profile Crypto Module und auch die PCI-
Zertifizierung (Payment Card Industry) international zur Verfügung.
 2
Die HSM-Technik heute
In diesem Kapitel
Abgrenzung von Hardware-Sicherheitsmodulen zu Smartcards,
Krypto-Geräten und Co.
Bauformen von Hardware-Sicherheitsmodulen heute
Sicherheitsanforderungen an Hardware-Sicherheitsmodule
Design-Prinzipien der Hardware-Sicherheitsmodule
Physikalische Sicherheitsmechanismen
Standards und Normungen im Bereich Hardware-Sicherheitsmodule

W enn Sie im Internet nach dem Begriff »Hardware-Sicherheitsmodule« su-

chen, finden Sie neben den unterschiedlichen Herstellerwebseiten zahl-
reiche Definitionen.

Kleiner Tipp am Rande: Nicht »HSM« angeben, da landen Sie sonst

sehr schnell bei Themen rund um die TV-Sendung »High School Mu-
sical«.

Leider sind noch immer zahlreiche Artikel verbreitet, die Hardware-Sicherheits-

module mit Chipkarten gleichsetzen beziehungsweise vergleichen. Hier mal ein
Beispiel:
»Hardware Security Modules (HSMs) like smartcards are hardware devices that
are used to store cryptographic key material in a secure way and to perform cryp-
tographic operations ... « (NetKnights, 2014). Dieser Vergleich ist zwar nicht
falsch, zeigt aber nicht das gesamte Potenzial von HSM, wie wir es heute in mo-
dernen Rechenzentren erfahren.
Gerade in den Industrieanwendungen wurden Hardware-Sicherheitsmodule
lange Zeit sehr gerne mit Smartcards verglichen. Dies zeigt jedoch nicht die
Leistungsfähigkeit der HSM im Unterschied zu Smartcards in Bezug auf Re-
chengeschwindigkeit und Datenverarbeitungsvolumen. Schauen wir uns im
Weiteren einmal Bauformen von Hardware-Sicherheitsmodulen an.

15
 HSM für Dummies

Bauformen von HSM

Die klassische Bauweise eines Hardware-Sicherheitsmoduls ist sicherlich die
Bauform der Einsteckkarte. Hierbei handelt es sich im Prinzip um eine Adapter-
karte, über die die Anbindung an den Host-Rechner ermöglicht wird und die
gleichzeitig den gesicherten Bereich des Hardware-Moduls anspricht. In Abbil-
dung 2.1 sind unterschiedliche Varianten von Hardware-Sicherheitsmodulen ge-
zeigt, die im Weiteren noch näher erklärt werden.

Abbildung 2.1: Bauformen von Hardware-Sicherheitsmodulen

Eine andere, weit verbreitete Bauform von HSM ist die Netzwerk Appliance- oder
auch Server-Variante. Hierbei handelt es sich im Prinzip um ein HSM, das direkt
via TCP/IP angesprochen wird und somit direkt in ein Netzwerk eingebunden
werden kann.

Erkennen Sie die Vorteile der Einsteckkarte im Vergleich zur Server-

Variante? Richtig – gerade wenn es um die gesicherte 1:1-Beziehung
zwischen der Anwendung und dem Vertrauensanker HSM geht, ist die
Karte das Produkt der Wahl. Bei verteilten Anwendungen, die alle je-
weils die Anforderung nach Security haben, ist sicherlich die Netz-
werk-Variante zu bevorzugen.

16
 2 Die HSM-Technik heute

Sicherheitsanforderungen
Über die letzten Jahre hinweg haben sich die Sicherheitsanforderungen an HSM
im Grunde nicht großartig verändert. Im Wesentlichen erfüllen HSM die nach-
folgenden Anforderungen:
Absicherung gegen Angriffe auf die HSM-Gerätehardware; »tamper resis-
tant«
Schutz vor Seitenkanalangriffen wie zum Beispiel Timing-Attacken oder Dif-
ferential Power Analysis, also Angriffen, die aus dem zeitlichen Verhalten
oder der Stromaufnahme der Geräte Rückschlüsse auf die Schlüssel ziehen
Absicherung der kryptografischen Anwendungsumgebung
Absicherung der Softwareumgebung gegen Manipulation und Einspielen
von Fremdprogrammen
Generierung von Schlüsseln durch echte Zufallszahlengeneratoren
Unterstützung aller derzeit etablierten kryptografischen Operationen (Si-
gnieren, Verschlüsseln und so weiter)
Dies sind die grundlegenden übergreifenden Anforderungen an HSM. An dieser
Stelle haben wir bewusst den gesamten Bereich der Schnittstelle außer Acht ge-
lassen. Dieser wird in Kapitel 3 detailliert betrachtet.

Wenn Sie weitere Informationen zu dem Bereich Hardware »Tamper«-

Mechanismen suchen, schauen Sie auf der Seite https://hsm.
utimaco.com nach. Hier gibt es eine gute Abhandlung über die Be-
reiche Tamper Resistance, Tamper Evidence, Tamper Detection und
Tamper Response.

Designprinzipien für HSM

Das grundlegende Designprinzip für HSM ist die Unabhängigkeit des Krypto-Co-
Prozessors vom Host-System mit seiner Anwendung und seinen Schnittstellen.
Die gesamte Kommunikation zwischen der Anwendung und dem HSM findet
über einen definierten Kanal statt. Des Weiteren ist eine klare Sicherheitsgrenze
zwischen dem Prozessorsystem des HSM und der Außenwelt zu ziehen, was in
Abbildung 2.2 deutlich wird.

17
 HSM für Dummies

Abbildung 2.2: Design von Hardware-Sicherheitsmodulen

Ebenso führt die definierte Abgrenzung dazu, dass eine klare Trennung der Spei-
cherbereiche für die geheimen Daten im HSM stattfindet. Nur durch die Firm-
ware innerhalb des HSM sind die Bereiche innerhalb der Sicherheitszone zu ad-
ressieren. Alle andere Hardware und auch Software außerhalb der Sicherheits-
zone, wie zum Beispiel Kabel-Trägerplatinen oder Client Software, APIs oder Au-
thentisierungs-Token, ist notwendig für den Betrieb des HSM, kann aber nicht
direkt auf die Elemente im gesicherten Bereich zugreifen.

Achtung, diese Betrachtung kann in dem einen oder anderen Anwen-

dungsfall anders ausgelegt werden. Dies bedeutet, dass auch ein Kom-
munikationskanal zum HSM geschützt werden muss, wenn hier Daten
und Informationen transportiert werden, die sicherheitsrelevant sind.

Auch im laufenden Betrieb eines HSM, also zur Laufzeit, bietet die Sicherheits-
zone maximalen Schutz gegen das Ausspähen der Schlüsselinformationen. Gera-
de auch wenn ein Gerät aus der Betriebsumgebung gestohlen wird, ist durch die
Sicherheitszone und den gesicherten Kommunikationskanal gewährleistet, dass
keine Informationen nach außen gelangen.

18
 2 Die HSM-Technik heute

Der physikalische Schutz

Wie wir gesehen haben, kommt der Sicherheitszone im HSM eine besondere Be-
deutung zu. Im Gegensatz zu den Sicherheitsmechanismen einer Smartcard
oder eines Security Chips wird bei den Schutzmechanismen für HSM eine Kom-
bination aus mechanischer, sensorischer und logischer Komponente eingesetzt.
Grundsätzlich unterscheidet man zwei Arten von physikalischer Absicherung
von kommerziell verfügbaren HSM:
Tamper Resistance: Hierbei handelt es sich um die am weitesten verbreitete
Methode der Sicherung für HSM. Ziel ist es, es einem Angreifer, der physika-
lisch an die Schaltung gelangen möchte, so schwer wie möglich zu machen.
Ein probates Mittel ist es, mit einem epoxidähnlichen Harz den gesamten
Verguss der Schaltung durchzuführen.
Tamper Response: Diese Stufe der Absicherung ist die maximale Ausbau-
stufe an physikalischer Absicherung, die wir heutzutage im kommerziellen
Bereich sehen, ein Beispiel ist in Abbildung 2.3 abgebildet. Zielsetzung ist,
dass im laufenden Betrieb und während des Lebenszyklus des HSM Angriffe
erkannt werden. Ein bewährtes Verfahren zur Erkennung von mechanischen
Angriffen auf die CPU-Einheit eines HSM ist das Verbauen eines Schutz-
schilds aus Netzen von Leiterbahnen innerhalb eines Epoxidharzvergusses.
Durch die Überwachung des Stromflusses innerhalb des leitenden Netzes
aus Leiterbahnen ist es somit möglich, einen Angriff auf den Schutzschild zu
erkennen. Mögliche aktive Gegenmaßnahmen sind dann das aktive Löschen
des Hardwarespeichers des HSM und das Zurücksetzen der CPU-Daten.

Abbildung 2.3: Schnittmodell eines HSM mit Tamper Responsive-Technologie

19
 HSM für Dummies

Des Weiteren werden in den heutigen kommerziellen HSM erweiterte physikali-

sche Überwachungsmaßnahmen eingesetzt. Zum einen sind diese im Rahmen
von Zertifizierungen gefordert (hierauf gehen wir noch ausführlich in Kapitel 4
ein). Zum anderen werden diese Maßnahmen benötigt, um weitere Angriffs-
szenarien abzuwehren. Nachfolgend finden Sie die am häufigsten anzutreffen-
den Maßnahmen:
Temperaturüberwachung: Die Umgebungstemperatur wird überwacht,
damit ein Angriff über das Absenken der Umgebungstemperatur verhindert
wird (eine sogenannte cold boot attack oder auch Kaltstartattacke:
https://de.wikipedia.org/wiki/Kaltstartattacke).
Spannungsüberwachung: Die Betriebsspannung wird hinsichtlich der Ein-
haltung der Spannungsbereiche überwacht. Sollte es zu einem Unterschrei-
ten oder Überschreiten der definierten Betriebsspannung kommen, kann es
sein, dass die elektronische Schaltung in einen nichtdefinierten Zustand
kommt und ein Angreifer so an die geheimen Daten gelangt.

Standards und Normungen

All diese Punkte und Anforderungen, gerade auch im physikalischen Schutzbe-
reich, werden sehr ausführlich innerhalb der ISO 19790 von 2012 beschrieben.
Bei dieser Norm handelt es sich um die Definition des Gerätes »Cryptographic
Module«. Sie finden hier zum einen eine sehr gute Definition unterschiedlicher
Sicherheitslevel und deren Zielsetzung sowie eine detaillierte Beschreibung der
Anforderungen an Hardwareschutz und Softwaremaßnahmen. Des Weiteren
gibt es eine umfassende Anforderungsanalyse an das Rechte- und Rollenmodell
eines HSM. Die zweite Norm im Bereich HSM, die wir Ihnen an dieser Stelle vor-
stellen wollen, ist die ISO 24759. Hierbei handelt es sich um die zur Norm ISO
19790 korrespondierende Testanforderung für Cryptographic Modules.

Fazit
In diesem Kapitel haben Sie gesehen, welche Designprinzipien, welche Sicher-
heitsanforderungen und welche Maßnahmen zum physikalischen Schutz bei
Hardware-Sicherheitsmodulen zum Einsatz kommen. Zudem haben wir Ihnen
kurz die aktuellen Normen für Hardware-Sicherheitsmodule vorgestellt. Diese
grundlegenden Definitionen werden wiederum untermauert von den unter-
schiedlichen Zertifizierungsschemata wie FIPS oder Common Criteria, die auf
diesen Prinzipien aufsetzen und hier entsprechende Prüf- und Validierungsrah-
menwerke bilden. Zu diesem Punkt lesen Sie bitte in Kapitel 4 weiter.

20
 3
Die Schnittstelle: der Schlüssel
zur Anwendung
In diesem Kapitel
Welche Schnittstellen heutzutage für HSM existieren
Zu welchem Einsatzzweck welche Schnittstelle herangezogen wird

L ogische Softwareschnittstellen kennen wir in der IT zur Genüge. Schauen

wir uns das Hardware-Sicherheitsmodul an, so haben wir es mit unter-
schiedlichen Schnittstellen, die für die verschiedensten Anwendungen und Be-
triebssysteme konzipiert sind, zu tun. Betrachten wir das Thema Schnittstelle –
im weiteren API genannt – aus Sicht des Hardware-Sicherheitsmoduls, so kön-
nen wir drei grundsätzliche, logisch voneinander getrennte APIs identifizieren:

Abbildung 3.1: Logische Softwareschnittstellen eines HSM

Key Management API:

Bei dieser Schnittstelle handelt sich um das Interface zum HSM, das dazu
dient, alle schlüsselrelevanten administrativen Funktionen auszuführen.
Hierzu zählen zum Beispiel: der gesicherte Key Backup and Restore von
Schlüsseldaten im HSM, die Transportschlüsselerzeugung und so weiter.

21
 HSM für Dummies

Command API:
Hierbei handelt es sich um das Interface zum HSM, das dazu da ist, um auf
die kryptografischen Funktionen des HSM zuzugreifen. Hierzu zählen auch
erweiterte Funktionen wie zum Beispiel die Schlüsselgenerierung und der
Import oder Export von Schlüsseldatensätzen.
User Management API:
Mithilfe dieser Schnittstelle werden alle notwendigen Funktionen aufgeru-
fen, um Anwender und deren entsprechende Rollen im HSM anzulegen und
zu verwalten.

Bei den heutigen Funktionsschnittstellen für HSM, wie zum Beispiel

PKCS#11, werden Key-Management- und User-Management-Funktio-
nen teilweise über die Command-Schnittstelle abgebildet. Hier hat lei-
der eine Vermischung der unterschiedlichen APIs stattgefunden, was
bei nicht sachgemäßer Implementierung zu Sicherheitslücken im
Gerät führen kann.

Schauen wir uns aber im Weiteren die Schnittstellen zu Hardware-Sicherheits-

modulen aus Sicht der aufrufenden Anwendung an. Beginnen wir mit einer Defi-
nition der Sicherheits-API:
Die Sicherheits-API erlaubt nicht vertrauenswürdigem Code, der inner-
halb einer Anwendung zur Ausführung kommt, auf sensible Ressourcen
eines HSM auf sichere Weise zuzugreifen. Sie ist die Schnittstelle zwi-
schen laufenden Prozessen auf dem Host-System und dem HSM.

Beispiele für Sicherheits-APIs sind die Schnittstelle zwischen dem ma-

nipulationssicheren Chip auf einer Smartcard (vertrauenswürdig) und
dem Kartenleser (nicht vertrauenswürdig), die Schnittstelle zwischen
einem kryptografischen Hardware-Sicherheitsmodul (vertrauenswür-
dig) und dem Host-Server (nicht vertrauenswürdig) oder dem Google
Maps API – eine Schnittstelle zwischen einem Server, der Google ver-
traut, und dem Rest des Internets.

Grundlegend zeichnet sich die Schnittstelle eines HSM durch folgende Eigen-
schaften aus:
Umsetzung der Sicherheitspolitik für den externen Zugriff auf den gesicher-
ten Bereich

22
 3 Die Schnittstelle: der Schlüssel zur Anwendung

Schutz des Sicherheitsbereiches vor Befehlen mit egal welchen Parametern

oder vor Befehlsfolgen. Dies bedeutet, dass auch wenn der Code auf dem
Host-System kompromittiert oder fehlerhaft ist, dies keine Auswirkung auf
das HSM und die kritischen Daten hat.

Übersicht über die aktuellen Schnittstellen

für HSM
Kommen wir nun zu den aktuell existierenden HSM-Schnittstellen. Zunächst
stellen wir Ihnen die international standardisierten Schnittstellen vor.

PKCS#11 Cryptographic Token Interface Standard

Bei diesem Standard (auch Cryptoki genannt) handelt sich um eine API zu Hard-
ware-Sicherheitsmodulen im weitesten Sinne, welche kryptografische Informa-
tionen speichert und kryptografische Operationen ausführt.
Grundsätzlich handelt es sich bei den PKCS um Public Key Cryptography Stan-
dards, die ab 1991 von den RSA-Laboratorien entwickelt wurden. Der PKCS#11
wurde bis zur Version 2.30 von RSA Labs entwickelt. Ab 2013 übernahm die Or-
ganisation for Advancement of Structured Information Standards (OASIS) die
Weiterentwicklung. Diese Schnittstelle ist die derzeit noch am meisten verbrei-
tete generische Schnittstelle für den Zugriff auf Sicherheitsmodule im weiteren
Sinne.

Vorteile:
Einer der wesentlichen Vorteile der PKCS#11-Schnittstelle ist die Interoperabili-
tät zwischen Anwendung und Sicherheitsmodul. Des Weiteren bietet der
PKCS#11 einen universellen Ansatz sowohl für symmetrische als auch asymme-
trische kryptografische Verfahren.

Nachteile:
So schön die oben angesprochene Interoperabilität auch sein mag: Viele Herstel-
ler haben bei der Umsetzung des PKCS#11 Erweiterungen, sogenannte Vendor
definied mechanisms, eingebaut und somit den Vorteil der Herstellerneutralität
ad absurdum geführt. Auch hat der Standard eine so hohe Komplexität ent-
wickelt, dass gerade Angriffe auf die Schnittstelle durch Abfolgen von Befehlen

23
 HSM für Dummies

sehr hohe Erfolgsquoten haben. Schauen Sie sich einmal den Artikel http://
www.dsi.unive.it/~focardi/Articoli/bmfs-ASA09.pdf an, der das
Problem sehr schön beschreibt.

JCE: Java Cryptography Extension

Bei der Java Cryptography Extension (JCE) handelt es sich um eine Schnittstelle
der Programmiersprache Java und gleichzeitig um ein Framework für krypto-
grafische Aufgaben wie Verschlüsselung, Signaturerstellung und Schlüsselver-
waltung. Seit dem JDK 1.4 ist sie Teil der Java-Plattform.

Die JCE ist ein Teil der JCA (Java Cryptography Architecture). Durch
die Aufteilung in JCE und JCA konnte in der Vergangenheit die Be-
schränkung der USA für Kryptografie eingehalten werden. Beinhaltete
die JCA nur Hashfunktionen, Schlüsselgeneratoren und so weiter,
durfte diese frei exportiert werden.

Die JCE basiert auf einem Provider-Konzept, mit dem es möglich ist, verschiede-
ne kryptografische Konzepte einzubinden. Die Java Cryptography Extension ist
(wie auch die Java Cryptography Architecture) von der Implementierung der
konkreten Algorithmen unabhängig. Über ein Service Provider Interface (SPI)
können unterschiedliche Implementierungen von unterschiedlichen Herstellern
gleichzeitig in die Java-Laufzeitumgebung eingebunden werden. Java wird ab
Version 1.4 mit einer JCE- und JCA-Implementierung ausgeliefert, andere Im-
plementierungen können aber einfach sowohl statisch als auch dynamisch nach-
geladen werden. Zu den bekanntesten JCE-Implementierungen gehört der IAIK-
JCE-Provider des Instituts für Angewandte Informationsverarbeitung und
Kommunikationstechnologie (IAIK) der Technischen Universität Graz.

Microsoft Cryptography API: Next Generation

Schauen wir uns zum Schluss noch in der Microsoft-Welt um. Hier ist die aktu-
elle Schnittstelle die Cryptography Next Generation (CNG). Sie wurde mit Win-
dows VistaTM eingeführt und ersetzt die CryptoAPI. Die CNG unterstützt die
heute gängigen symmetrischen und auch asymmetrischen Algorithmen sowie
Zufallszahlengenerierung und alle gängigen Hashfunktionen. Hierbei lehnt sich
Microsoft an Suite B an.

24
 3 Die Schnittstelle: der Schlüssel zur Anwendung

In Amerika hat die NSA 2005 einen Katalog – Suite B – von kryptogra-
fischen Algorithmen veröffentlicht. Diese Sammlung ist als Empfeh-
lung der NSA zu verstehen, wenn es um den Einsatz von kryptografi-
schen Verfahren sowie deren Schlüsselstärken geht. Parallel dazu hat
die NSA ebenfalls noch den Suite A-Katalog verfasst. Hierbei handelt
es sich um Algorithmen für den Einsatz im hochsensiblen Bereich.
Dieser Katalog wurde nicht veröffentlicht.

Aber was wäre die IT ohne ihre Ausnahmen? Auch im Bereich von Microsoft
haben wir noch eine weitere Schnittstelle für HSM im Bereich Datenbankserver.
Hierbei handelt es sich um die SQL-Serverdatenverschlüsselungsfunktion EKM
(Extensible Key Management). Diese Funktionsschnittstelle bietet die Möglich-
keit, die in vielen Anwendungsbereichen geforderte Datenbankverschlüsselung
mittels eines HSM zu realisieren. Grundsätzlich handelt es sich bei der EKM-
Schnittstelle um eine weitere Standardschnittstelle im Bereich Microsoft.

Weitere Standardschnittstellen
Die in diesem Buch vorgestellten Schnittstellen sind zum Zeitpunkt der Druck-
legung des Buches die aktuellen APIs für HSM, die am weitesten Verbreitung fin-
den. Hinzu kommen weitere Schnittstellen, die entweder herstellerspezifisch
sind, aber einen »Industrie«-Standard darstellen, oder auch weitere definierte
Schnittstellen wie zum Beispiel die Integration von HSM in die OpenSSL-Biblio-
thek. Bei OpenSSL handelt es sich um die Bibliothek für SSL (Secure Socket
Layer) und TLS (Transport Layer Security). Sie wird von vielen anderen Produk-
ten, wie auch der OpenCA, im Backend genutzt. Mit dem Engine-Konzept von
OpenSSL lassen sich für alle kryptografischen Prozesse ebenfalls Smartcards
und Hardware-Sicherheitsmodule einbinden. Somit stellt OpenSSL ebenfalls
eine gute Alternative zu den oben genannten Schnittstellen dar.

Einsatzzwecke von Schnittstellen

Leider ist die Schnittstelle zur Kommunikation mit kryptografischen Geräten
eine Achillesferse beim Einsatz von HSM. Gerade bei einem Hardware-Sicher-
heitsmodul handelt es sich um ein System, das die Möglichkeit bietet, eine sehr
hohe Komplexität abzubilden. Aus dieser Eigenschaft heraus wächst leider auch
die Möglichkeit, wesentliche Implementierungsfehler zu begehen und durch
eine Kombination aus unterschiedlichen Befehls- und Kommandostrukturen
einen erfolgreichen Angriff durchzuführen.

25
 HSM für Dummies

Eine sehr schöne Übersicht darüber, wie heute Angriffe auf Schnitt-
stellen aussehen, finden Sie bei der Universität Oldenburg unter:
http://www.uni-oldenburg.de/fileadmin/user_upload/
informatik/download/da.pdf.

Eine weitere große Fehlerquelle ist die Möglichkeit, Multi-Protokoll-Funktionen

in einem HSM laufen zu lassen. Dies hat dann zur Folge, dass Kommandointer-
aktionen zwischen den einzelnen Funktionsprotokollen zu potenziellen Fehlern
führen. Gerade im Einsatzbereich Banking finden wir heute diese Multi-Proto-
koll-Funktionen-HSM, die unterschiedliche Schnittstellen für diverse Anwen-
dungen bereitstellen.

Die richtige Schnittstelle auswählen

Eines der wichtigsten Kriterien bei der Auswahl der Schnittstelle eines HSM ist
immer die Bewertung der Anforderungen gemäß der Einsatzumgebung. Das be-
deutet, dass ich, wenn ich mich in einer rein von Microsoft geprägten Einsatz-
umgebung bewege, zu 90 Prozent nur reine Microsoft-definierte Schnittstellen,
wie zum Beispiel die CNG (Cryptography API: Next Generation), benötige. Es
kommt zudem immer darauf an, was die Anwendung, die Sie einzusetzen pla-
nen, schon für eine Schnittstelle zu einem HSM bietet. Gerade hier hat sich in
den letzten Jahren einiges entwickelt und immer mehr Hersteller von Standard-
Business-Anwendungen haben integrierte Schnittstellen zu HSM oder Security
Token. Hier eine Liste der bekanntesten Anwendungen:
Microsoft Windows Server 2012;
Active Directory Certificate Services (AD CS)
Microsoft Active Directory Rights Management Services (AD RMS)
Microsoft Internet Information Server (IIS)
Microsoft SQLEKM Provider
Bind 9 (Domain Name System)
OpenDNSSEC
Apache Tomcat
TrueCrypt
Oracle Database

26
 3 Die Schnittstelle: der Schlüssel zur Anwendung

Des Weiteren bieten natürlich die unterschiedlichen Sicherheitsanwendungen,

wie zum Beispiel eine PKI-Anwendung oder ein Kartenverwaltungssystem, die
Möglichkeit, ein HSM mittels einer definierten Schnittstelle einzubinden.

Im Anhang dieses Buches wird Ihnen der HSM-Simulator vorgestellt.

Unter anderem finden Sie hier auch weiterführende Informationen zu
der Möglichkeit der Integration von HSM in unterschiedliche Anwen-
dungen in Form von Integration Guides.

Entwerfen und realisieren Sie Ihre eigene API

Ja, auch das ist möglich! Fragen Sie Ihren HSM-Lieferanten nach dieser Mög-
lichkeit. Denn es gibt Einsatzbereiche und Anwendungsfelder, da ist eine klar
definierte anwendungsbezogene Schnittstelle von klarem Vorteil gegenüber
einer Standardschnittstelle à la PKCS#11 oder JCE. Wenn Sie in Ihrem Projekt
unter anderem folgende Anforderungen haben und diese einen sehr hohen Stel-
lenwert innerhalb Ihrer kritischen Erfolgsfaktoren einnehmen, dann sollten Sie
ernsthaft über eine eigens definierte Schnittstelle nachdenken:
Hohe Geschwindigkeit bei der Transaktionsverarbeitung
Auditierbarkeit der HSM-Integration
Zulassung durch Gutachter
Das HSM ist Bestandteil eines in sich abgeschlossenen Systems mit keinen
externen Schnittstellen

Aber Vorsicht: Der Entwurf und die Realisierung einer Security-API

sind nur durch versierte Experten durchzuführen. Es ist auch immer
das gesamte System, in dem diese Schnittstelle zur Anwendung
kommt, zu betrachten, damit beim Design und der Realisierung keine
grundlegenden Fehler gemacht werden. Es ist auch sehr hilfreich, ex-
terne Gutachter hinzuzuziehen.

27
 4
Zertifizierung – ein Gütesiegel,
und dann?
In diesem Kapitel
Welche Zertifizierungsschemata es heute für HSM gibt
Welche Vor- und Nachteile Zertifizierungen im Bereich HSM haben
Was Sie als Anwender in Bezug auf Zertifizierungen wissen müssen

U m die Güte und den Sicherheitslevel eines Geräts für Informationssicher-

heit bewerten zu können, wurden unterschiedliche Prüfvorschriften und
Anforderungskataloge definiert, nach denen eine Begutachtung und anschlie-
ßende Zertifizierung durchgeführt werden kann. Eigentlich ist es relativ ein-
fach, im Bereich HSM das Thema Zertifizierung zu behandeln. Grundsätzlich
gibt es nur zwei weltweit anerkannte Zertifizierungsschemata:
FIPS: Die sogenannten Federal Information Processing Standards Publica-
tions (FIPS PUBS) des National Institute of Standards and Technology.
Common Criteria: Bei der Common Criteria for Information Technology Se-
curity Evaluation handelt es sich um einen internationalen Standard zur
Prüfung und Bewertung der Sicherheitseigenschaften von IT-Produkten.
Aber wie immer ist es nicht ganz so einfach, wie es sich im ersten Schritt dar-
stellt. Denn zusätzlich zu den beiden weltweit gültigen Schemata gibt es diverse
Prüfvorschriften und Verfahren in den unterschiedlichen nationalen Branchen.
So haben wir zum Beispiel innerhalb des deutschen Kreditgewerbes eigene An-
forderungen an HSM für den Einsatz in den Netzwerken des Zahlungsverkehrs.
Im Bereich der Payment Card Industry werden ebenfalls eigene Definitionen für
Hardware-Sicherheitsmodule getroffen.

Der FIPS 140-Standard

Schauen wir uns den FIPS-Standard einmal genauer unter dem Aspekt des HSM
an. Im Rahmen des CMVP (Cryptographic Module Validation Program) wird die
Zertifizierung von Hardware-Sicherheitsmodulen gemäß FIPS 140-2 kontrol-
liert. Das CMVP-Programm wurde durch das US-amerikanische NIST und das
kanadische CSEC initiiert.

29
 HSM für Dummies

Schauen wir uns den FIPS-Standard etwas genauer an, so haben wir es mit vier
aufeinander aufbauenden Sicherheitsstufen, sogenannten Level, zu tun. Jede
Stufe hat eine höhere Sicherheitsfeature-Konzentration als der Vorgänger,
wobei diese Konzentration entsprechend dem Grad der zu erreichenden Sicher-
heitsanforderungen angepasst ist. Als Vorlage ging in den FIPS-Standard der
ISO/IEC 19790-Standard ein und definiert hier die grundlegenden Anforderun-
gen an die vier Sicherheitslevels. Betrachtet man aktuelle Tendenzen in der Wei-
terentwicklung des Standards, so ist ebenfalls die ISO/IEC 19790 in der Version
2.0 aus dem Jahr 2012 die Grundlage für weitere FIPS 140-Definitionen.

Abbildung 4.1: Webseite des CMVP

30
 4 Zertifizierung – ein Gütesiegel, und dann?

Auf der Webseite des CMVP finden Sie alle weiterführenden Informa-
tionen rund um den FIPS 140: http://csrc.nist.gov/groups/
STM/cmvp/index.html. Des Weiteren finden Sie in der Sektion
»Module Validation Lists« eine Übersicht der zertifizierten Geräte
nach Hersteller sortiert. In der Sektion »Modules in Process« finden
Sie alle Hersteller, deren Module sich derzeit in Evaluierung befinden.

Werfen wir mal einen kurzen Blick auf die ISO/IEC 19790. Die Norm spezifiziert
detailliert die Sicherheitsanforderungen an »Cryptographic Modules«, also Si-
cherheitsmodule. Es werden insgesamt elf Teilaspekte von Modulen betrachtet,
vom Design der Hardware über die Implementierung bis hin zur Kryptografie.
Der Umfang an Maßnahmen für diese Teilaspekte bestimmt dann den entspre-
chenden Sicherheitslevel.
Zurück zum FIPS-Standard. Mit FIPS 140-2 haben wir einen internationalen
Standard vorliegen, der wesentlich bei der Auswahl von Hardware-Sicherheits-
modulen zum Tragen kommt. Als Ergebnis einer erfolgreichen Zertifizierung
nach FIPS 140-2 wird nicht nur ein Gesamtsicherheitsniveau (Level 1 bis 4) be-
scheinigt, sondern auch individuelle Prüfergebnisse in verschiedenen Teilberei-
chen. Letztere sind für konkrete Anwendungsfälle wesentlich aussagekräftiger
als das Gesamtergebnis.

Mittelfristig plant die ISO, die Anforderungen der ISO/IEC 19790 in

die Systematik der ISO/IEC 15408 zu integrieren, wobei weiterhin
nicht nur eine Norm für die Evaluierung aller Sicherheitsprodukte
existieren wird.

Common Criteria und HSM

Schauen wir uns noch das zweite weit verbreitete Zertifizierungsschema an, die
Common Criteria.
Die Common Criteria, kurz auch CC genannt, sind aus den europäischen ITSEC
(Information Technology Security Evaluation Criteria), den amerikanischen Fe-
deral Criteria (FC) und den kanadischen CTCPEC (Canadian Trusted Computer
Product Evaluation Criteria) entstanden. Bei den CC handelt es sich im Grunde
um einen generellen Katalog von vordefinierten Funktionen und Funktionalitä-
ten, der die Vertrauenswürdigkeit von Produkten der IT-Sicherheit im Allgemei-
nen festlegt. Diese werden dann in vorevaluierten sogenannten Schutzprofilen
zusammengefasst, womit entsprechende Produktklassen definiert werden kön-

31
 HSM für Dummies

nen. Will man eine Prüfung nach CC durchführen, ist grundsätzlich, unabhän-
gig von dem jeweiligen Produkt, zwischen der Funktionalität des Systems und
dessen Vertrauenswürdigkeit zu unterscheiden. Denn der Grundgedanke der
Common Criteria ist, dass das Vertrauen in ein Produkt oder System durch die
Prüfung der Funktionalität entsteht.

Die Common Criteria umfassen drei Teile:

Einführung und allgemeines Modell / Introduction and General
Model
Funktionale Sicherheitsanforderungen / Functional Requirements
Anforderungen an die Vertrauenswürdigkeit / Assurance Require-
ments

Schaut man sich nun an, welche Schutzprofile bei Common Criteria für Hard-
ware-Sicherheitsmodule existieren, so wird man im ersten Schritt nur im Be-
reich von Security-Modulen fündig – wobei aber Achtung geboten ist, denn es
handelt sich hierbei ausschließlich um Security-Module in Form einer Smart-
card. Das einzige Schutzprofil (Protection Profile bzw. PP), das heute evaluiert
und veröffentlicht ist, ist das PP mit der Nummer BSI-CC-PP-0045 Cryptogra-
phic Modules, Security Level »Enhanced«. Dieses Protection Profile wurde vom
Bundesamt für Sicherheit in der Informationstechnik entwickelt und findet zum
Beispiel im Bereich der Infrastruktur des neuen Personalausweises seinen Ein-
satz.

Was bedeutet eine Zertifizierung für mein

Projekt?
Gerade im Bereich der Zertifizierung gibt es heutzutage immer wieder Missver-
ständnisse.
Durch die Anforderungen der Zertifizierungen im Bereich der Funktionali-
tät werden sehr oft auch die Funktionen von HSM eingeschränkt. Dies hat
zur Folge, dass viele Hersteller einen sogenannten »FIPS Mode« eingeführt
haben.
Auditoren erwarten sehr oft, dass Zertifizierungen eingehalten werden und
somit die Geräte im Betriebsmodus »FIPS Mode« betrieben werden.

32
 4 Zertifizierung – ein Gütesiegel, und dann?

Teilweise ist der Funktionsumfang eines HSM durch die zertifizierte Version
soweit eingeschränkt, dass kein Einsatz mit der entsprechenden Anwendung
möglich ist. Hier müssen Sie sich im Vorfeld der Produktauswahl im Klaren
sein, was Sie genau benötigen.

33
 A
Anhang
Der HSM-Simulator

Sie können noch heute beginnen, mit Ihrer eigenen HSM-»Software« zu arbei-
ten, indem Sie sich den voll funktionsfähigen Utimaco HSM-Simulator herun-
terladen. Das Simulatorpaket bietet eine zu 100 Prozent funktionstüchtige
HSM-Runtime, ferner sämtliche Werkzeuge, die Sie zur Verwaltung und Konfi-
gurierung benötigen. Auch eine umfassende Bibliothek mit Anleitungen zur
Einrichtung des HSM und zum Einstieg in die Bedienung werden Sie finden, so-
dass Sie das HSM unmittelbar in Ihre Standardanwendungen integrieren
können.
In diesem Kapitel erfahren Sie Schritt für Schritt, wie Sie den CryptoServer Si-
mulator downloaden, auf einem Computer installieren und initial in Betrieb
nehmen können. Es werden nicht alle möglichen Szenarien aufgeführt (zum
Beispiel finden Sie hier stellvertretend nur die Installation des Simulators unter
dem Betriebssystem Windows 7); der Text ist also eher als Ergänzung zum
Quickstart Guide im Simulator-Paket gedacht.
Genauere Informationen über das gesamte Spektrum an Einrichtungs- und
Konfigurationsoptionen finden Sie im CryptoServer Handbuch für Systemver-
walter.

Anmerkung: Das Software-Paket des CryptoServer Simulators ist so-

wohl für Windows als auch für Linux verfügbar.

Installation des CryptoServer Simulators

Um den HSM-Simulator herunterzuladen, gehen Sie auf die Website von Utima-
co unter https://hsm.utimaco.com. Dort gelangen Sie über eine Registrie-
rung zum Simulator-Download.

35
 HSM für Dummies

Abbildung A.1: Utimaco-Website, Utimaco-Portal

Nachdem Sie den Simulator registriert und heruntergeladen haben, beginnen

Sie mit dem Installationsvorgang, indem Sie CryptoServerSetup-x.xx.x.exe star-
ten.

36
 A Anhang – Der HSM-Simulator

Abbildung A.2: CryptoServer Setup

Während der Installation müssen Sie wählen, welche Komponenten Sie installie-
ren wollen. Wenn Sie Ihr Anwendungsgebiet kennen und Ihnen Ihre API be-
kannt ist, wählen Sie bitte Entsprechendes aus. Eine Installation mehrerer
Funktionsschnittstellen ist ebenfalls zulässig. Orientieren Sie sich dabei an fol-
gender Abbildung:

Abbildung A.3: Zu wählende Komponenten

Den CryptoServer Simulator starten

Ist der Installationsprozess abgeschlossen, erscheinen auf Ihrem Desktop meh-
rere neue Icons.

37
 HSM für Dummies

Um den Simulator zu starten, müssen Sie einen Doppelklick auf das »CryptoSer-
ver Simulator«-Icon ausführen. Nach dem Start sehen Sie das Statusfenster wie
in folgender Abbildung:

Abbildung A.4: Statusanzeige des CryptoServer Simulators

Die Verbindung zum CryptoServer Simulator via

CAT aufbauen
Mit dem CryptoServer Administration Tool (CAT) können Sie Ihr HSM mithilfe
einer grafischen Benutzeroberfläche bedienen und verwalten. Ebenso steht
Ihnen eine Kommandozeilenversion zur Verfügung. Als ersten Schritt müssen
Sie die Verbindung mithilfe des CAT und des Simulators aufbauen.

38
 A Anhang – Der HSM-Simulator

1. Starten Sie das CAT, indem Sie das Icon auf Ihrem Desktop anklicken.

Wenn Sie während des Installationsvorgangs die Option »launch CAT«

gewählt haben, ist das Tool schon gestartet.

2. Klicken Sie im CAT-Hauptfenster auf »Devices«.

3. Geben Sie für den CryptoServer Simulator folgende IP-Adresse in das Feld
»New Device« ein: 3001@127.0.0.1
(Der Simulator wir mit Localhost angesprochen.)
4. Klicken Sie auf »Add to List«.
5. Klicken Sie auf »Test«, damit das CAT die Verbindung zum CryptoServer Si-
mulator aufbauen kann.
6. Klicken Sie auf »OK«, um die Einstellungen zu speichern.

Wie Sie sich als Admin in den Simulator

einloggen
Um sich als Admin in den CryptoServer Simulator einzuloggen, können Sie auf
die im Simulator voreingestellte Schlüsseldatei (Keyfile) zurückgreifen (näheres
zum Thema Keyfiles finden Sie im »CryptoServer_Handbuch_Systemverwal-
ter.pdf; Kapitel 2.2.3«).
Aus Sicherheitsgründen sollten Sie die vordefinierten Keyfile-Einstel-
lungen durch Ihr selbst generiertes Keyfile ersetzen. Mehr zu diesem
Thema können Sie in dem Dokument »CryptoServer_Handbuch_Sys-
temverwalter.pdf« nachlesen. Die Keyfile-Datei finden Sie in Ihrem In-
stallationsverzeichnis in dem Ordner »CryptoServer/Administration/«.
Halten Sie sich an folgende Schritte:
1. Klicken Sie beim CAT auf »Log In/Log Off«.
2. Suchen Sie nach dem Benutzernamen »Admin«.
3. Klicken Sie auf »Log In«.
4. Klicken Sie auf »Keyfile«.
5. Wählen Sie den Pfad (der Standardpfad für Verwaltungszwecke ist vor-
definiert).
6. Wählen Sie den Ordner »ADMIN key«.
7. Klicken Sie auf »Open« (eine Passworteingabe ist nicht nötig).
8. Klicken Sie auf »OK«.

39
 HSM für Dummies

Abbildung A.5: Einloggen als Admin

Nach Ausführen dieser Schritte wird Ihr CryptoServer Simulator zuverlässig

funktionieren. Genauere Informationen über das gesamte Spektrum an Einrich-
tungs- und Konfigurationsoptionen sowie Informationen über mögliche Szena-
rien, die bei der Einrichtung auftreten können, finden Sie im Dokumentations-
verzeichnis des SecurityServer-Verzeichnisses auf Ihrem Computer. Hier noch
einige Lektüretipps:
CryptoServer LAN Handbuch für Systemverwalter
CryptoServer Handbuch P11 CAT
CryptoServer csadm Manual for System Administrators
Für die Einrichtung verschiedener Anwendungen konsultieren Sie bitte die Be-
dienungsanleitungen sowie die innerhalb des Verzeichnisses /CryptoServer/Do-
cumentation/ enthaltenen Best-Practice-Unterlagen und die umfangreiche Bi-
bliothek an Integrationsanleitungen.

40
Notizen

41
 Notizen

42
Notizen

43
 Notizen

44
Notizen

45
 Notizen

46
Notizen

47
 Notizen

48
 Hardware-Sicherheit h e rh e it smodule verstehen
Hard wa re -S ic
made in Germany

Sie erfahren:
Hardware-
)
• Wie HSM gebaut sind

odule (HSM
Sicherheitsm
• Welche Anwendungs-
schnittstellen heute verfüg-
bar sind

• Welche Zertifizierungen
Was Sie über Hardware- existieren

Sicherheitsmodule wissen • Wie Sie den Utimaco

HSM-Simulator nutzen
sollten! können

Kryptografische Anwendungen sind für das Absichern

von Datentransaktionen unverzichtbar. Nur durch den
Schutz und die gesicherte Aufbewahrung der verwende-
ten kryptografischen Schlüssel in Hardware-Sicherheits-
modulen ist es möglich, das Vertrauen in die Technik zu
gewährleisten.
Wir bei Utimaco stellen Ihnen diese komplexen Geräte
zur Verschlüsselung oder Signaturerstellung in Form eines Hardware-Sicherheit
kompletten und verständlichen Produktes zur Verfügung.
Dieses Buch ist ein praktischer Leitfaden für den Einsatz
Mach dich schlau:
Auf einen Blick: made in Germany
von HSM in Ihrer Infrastruktur. Sie müssen also kein
www.fuer-dummies.de • Z wischen den verschiedenen
Krypto-Experte sein um Hardware-Sicherheitsmodule
in vollem Umfang nutzen zu können. HSM-Technologien unterscheiden
•D
 as richtige HSM für Ihre
Anwendung wählen
• E rste Integrationen mit dem
HSM-Simulator starten

Andreas Philipp ist Vice President Business Development

Präsentiert von
bei Utimaco, dem führenden Hersteller von Hardware-
Sicherheitsmodulen. Mit mehr als 20 Jahren Erfahrung im
Bereich Hardware-Sicherheit ist Herr Philipp ein bekann-
ter Experte und regelmäßig gefragter Redner bei Konfe-
renzen der Sicherheitsindustrie. Andreas Philipp