Diplomarbeit Sicherheitsuntersuchung des Hardware

Transcription

Rheinisch-Westfälische Technische Hochschule Aachen
Fachbereich Informatik
Diplomarbeit
Sicherheitsuntersuchung
des Hardware-Sicherheitsmoduls
CryptoServerr für den Einsatz als
SecurityServer in unsicheren Netzen
Michael Schüler
21. März 2007
Erstprüfer: Prof. Dr.-Ing. Felix Freiling
Zweitprüfer: Prof. Dr.-Ing. Heiko Mantel
Betreuer: Dipl.-Ing. Andreas Philipp, Utimaco Safeware AG
2
Ich versichere, dass ich die Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlich gemacht habe.
Aachen, 21. März 2007
(Michael Schüler)
4
Zusammenfassung
Diese Arbeit beschreibt die Analyse des Hardware-Sicherheitsmoduls Safeguard CryptoServerr der Utimaco Safeware AG in Bezug auf dessen Eignung als SecurityServer in
unsicheren Netzen. Im Rahmen dieser Analyse wurde das Security-API der Utimaco, das
Cryptographic Services Interface (CSI), per Fernzugriff einem ausführlichen Black-Box-Test
unterzogen.
Zunächst wurden die in den letzten Jahren entstandenen Angriffe auf Security-APIs zusammengetragen. Die auf den CryptoServerr anwendbaren Angriffe wurden genauer analysiert. Nur unter Umgehung der im CSI zwingend notwendigen Authentisierung, konnten
zwei dieser Angriffe den CryptoServerr kompromittieren.
Daher wurden in einem zweiten Schritt neue, speziell an das CSI angepasste Angriffsszenarien entwickelt und anschließend auf den CryptoServerr angewendet. Einer dieser Angriffe konnte den CryptoServerr unter bestimmten Voraussetzungen kompromittieren.
6
Abstract
This work describes the analysis of Utimaco’s hardware security module Safeguard CryptoServerr concerning its suitability as a SecurityServer in unattended networks. This analysis
is performed as a remote black box test on Utimaco’s Security API – the Cryptographic
Services Interface (CSI).
At first, recent attacks on Security APIs are brought together. Those attacks that are applicable to the CryptoServerr are further analyzed. Only two of those attacks have been
successful. Even though in both cases it has been necessary to circumvent the authentication, which is mandatory for using the CSI, beforehand.
Thus, new attacks are developed in a second step, that are well adapted for Utimaco’s CSI.
Afterwards, these attacks are applied to the CryptoServerr . Under special circumstances,
one of these attacks may compromise Utimaco’s CryptoServerr .
Inhaltsverzeichnis
Inhaltsverzeichnis
8
Abbildungsverzeichnis
10
Tabellenverzeichnis
11
1 Einleitung
1.1 Motivation . . . . .
1.2 Problemstellung . .
1.2.1 Zielsetzung
1.2.2 Abgrenzung
1.3 Ergebnisse . . . . .
1.4 Struktur der Arbeit
.
.
.
.
.
.
12
12
13
13
13
14
14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
15
16
17
17
17
18
19
19
20
21
22
23
24
24
.
.
.
.
.
.
25
25
25
25
26
34
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Hintergrund
2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . .
2.2 Vorarbeiten zur Analyse kryptografischer Systeme
2.2.1 Kryptanalyse und Protokollanalyse . . . .
2.2.2 Angriffe auf Seitenkanäle . . . . . . . . . .
2.2.3 API-Angriffe . . . . . . . . . . . . . . . . .
2.3 Hardware-Sicherheitsmodule . . . . . . . . . . . .
2.3.1 Definition . . . . . . . . . . . . . . . . . . .
2.3.2 Arten . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Hersteller . . . . . . . . . . . . . . . . . . .
2.3.4 Schnittstellen . . . . . . . . . . . . . . . . .
2.4 Der CryptoServerr . . . . . . . . . . . . . . . . . .
2.4.1 Aufbau . . . . . . . . . . . . . . . . . . . . .
2.4.2 Das Cryptographic Services Interface (CSI) . .
2.4.3 Policy . . . . . . . . . . . . . . . . . . . . . .
2.4.4 Was ist ein SecurityServer? . . . . . . . . . .
2.5 Zusammenfassung . . . . . . . . . . . . . . . . . .
3 Angriffe
3.1 Einleitung . . . . . . . . . . . . .
3.2 Bekannte Angriffe . . . . . . . . .
3.2.1 Angriffe auf Finanz-APIs
3.2.2 Allgemeine Angriffe . . .
3.3 Neue Angriffsszenarien . . . . .
3.3.1 Session Hijacking . . . . .
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
37
37
4 Analyse des CryptoServersr
4.1 Einleitung . . . . . . . . . . . . . . . . . . .
4.2 Bekannte Angriffe . . . . . . . . . . . . . . .
4.2.1 Type System/Key Separation Attack
4.2.2 Meet-in-the-Middle Attack . . . . .
4.2.3 Key Import Attack . . . . . . . . . .
4.2.4 Differential Protocol Analysis . . . .
4.2.5 Timing Attacks . . . . . . . . . . . .
4.2.6 Known Keys in the System . . . . .
4.3 Neue Angriffsszenarien . . . . . . . . . . .
4.3.1 Session Hijacking . . . . . . . . . . .
4.3.2 Man-in-the-Middle . . . . . . . . . .
4.3.3 Buffer Overflow . . . . . . . . . . . .
4.3.4 Lunchtime Attack . . . . . . . . . . .
4.4 Zusammenfassung . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
39
41
41
41
41
42
43
43
47
48
51
52
5 Zusammenfassung und Ausblick
5.1 Aufgabenstellung . . . . . . .
5.2 Ergebnisse . . . . . . . . . . .
5.3 Schwierigkeiten . . . . . . . .
5.4 Ausblick . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
53
54
55
3.4
3.3.2 Man-in-the-Middle
3.3.3 Buffer Overflow . .
3.3.4 Lunchtime Attack .
Zusammenfassung . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A Verwendete Schlüssel im CryptoServerr
56
B Taof: fuzz.xml
58
Literaturverzeichnis
65
Glossar
67
9
Abbildungsverzeichnis
10
2.1
2.2
2.3
2.4
2.5
Arten von Hardware-Sicherheitsmodulen . . . . . .
Foto des CryptoServersr . . . . . . . . . . . . . . . .
Schichten des CryptoServersr . . . . . . . . . . . . .
Foto des CryptoServerr LAN . . . . . . . . . . . . .
Schematische Darstellung des CryptoServerr LAN
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
20
21
22
23
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Anweisungsblock: GetChallenge . . . . . . . . . . . .
Antwortblock: Challenge . . . . . . . . . . . . . . . . .
Anweisungsblock: GetSessionKey (SHA-1-Passwort)
Antwortblock: Session Information . . . . . . . . . . .
Anweisungsblock: GetSessionKey (RSA Signatur) . .
Anweisungsblock: Secure Messaging . . . . . . . . . .
Antwortblock: Secure Messaging . . . . . . . . . . . .
Taof – The art of fuzzing . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
44
44
45
45
45
46
49
Tabellenverzeichnis
2.1
Hersteller von Hardware-Sicherheitsmodulen . . . . . . . . . . . . . . . . . . 19
3.1
Übersicht: Anwendbarkeit allgemeiner Angriffe . . . . . . . . . . . . . . . . . 38
A.1 Verwendete Schlüssel im CryptoServerr . . . . . . . . . . . . . . . . . . . . . 57
11
1 Einleitung
1.1 Motivation
„Das Internet ist vom reinen Kommunikationsmedium zur zentralen Schnittstelle vernetzter Geschäftsprozesse geworden. Vielfältige Arten von Transaktionen werden heute elektronisch abgewickelt und gesteuert.“ [Uti06b] Dazu gehören die Datenerfassung und Datenbearbeitung in CRM- und ERP-Systemen, die Einkaufsorganisation, die Korrespondenz
via E-Mail, elektronische Finanztransaktionen und die elektronische Steuererklärung.
Auch im privaten Bereich werden Transaktionen vermehrt elektronisch abgewickelt. Als
Beispiele seien hier das Online-Shopping und Online-Banking, das Aufladen von PrepaidKarten am Geldautomaten und die Bearbeitung von Patientendaten mit der elektronischen
Gesundheitskarte (eGK) genannt.
Diese Umstellung auf elektronische Geschäftsprozesse bringt, verstärkt durch die zunehmende Auslagerung ganzer Anwendungen an Application Service Provider (ASP), neue
Angriffspunkte für Datendiebstahl und Wirtschaftsspionage. Die zum Einsatz kommenden
Anwendungen und die in Unternehmen vorhandene IT-Infrastruktur wird immer komplexer, wodurch zunehmend mehr Schwachstellen entstehen. Die Absicherung dieser Prozesse
ist heutzutage daher unverzichtbar.
Das Basiswerkzeug zur Sicherung elektronischer Systeme ist die Kryptografie. Eines der
wichtigsten Elemente der Kryptografie ist der kryptografische Schlüssel. Jedes der oben
genannten Systeme benutzt mindestens einen, viele sogar mehrere Schlüssel – und alle
wären ohne kryptografische Schlüssel undenkbar. Das Problem ist, dass die Sicherheit, die
kryptografische Systeme bieten, mit der Sicherheit der verwendeten Schlüssel steigt und
fällt. Daher müssen auch diese Schlüssel selbst wieder abgesichert werden: "They have to
be stored securely, used securely, and then destroyed securely." [Sch04]
Dieses Problem der sicheren Speicherung, sicheren Benutzung und sicheren Zerstörung
kryptografischer Schlüssel versuchen Hardware-Sicherheitsmodule zu lösen. Diese erzeugen und speichern intern Schlüssel und bieten kryptografische Funktionen – unter Benutzung dieser Schlüssel – über definierte Schnittstellen (so genannte Security-APIs) nach außen an.
12
1 Einleitung
In den letzten Jahren wurden viele Schwachstellen in solchen Security-APIs aufgedeckt und
konkrete Angriffe auf diese Schwachstellen entwickelt. Kaum ein Hersteller von HardwareSicherheitsmodulen, dessen Security-API analysiert wurde, blieb dabei von der Aufdekkung von Schwachstellen in seinem Produkt verschont.
1.2 Problemstellung
Der SafeGuard CryptoServerr , ein insbesondere in Deutschland weit verbreitetes Hardware-Sicherheitsmodul der Utimaco Safeware AG, und dessen proprietäres Security-API,
das Cryptographic Services Interface (CSI), soll im Rahmen dieser Diplomarbeit untersucht
werden. Ein besonderer Fokus soll dabei auf Schwachstellen im Bezug auf die Einsatztauglichkeit des CryptoServersr als SecurityServer in unsicheren Netzen liegen.
1.2.1 Zielsetzung
Der Untersuchung des CryptoServersr liegt ein Szenario zu Grunde, in dem der potentielle
Angreifer lediglich entfernten (engl.: remote) Zugriff auf das Gerät hat. Er ist aber sehrwohl
in der Lage den Netzwerkverkehr zum und vom CryptoServerr mitzuschneiden und ggf.
auch zu manipulieren (in der Literatur oft als man-in-the-middle bezeichnet). Zudem hat er
in gewissen zeitlichen Grenzen (Szenario „Mittagspause“) direkten physikalischen Zugriff
auf weitere Rechner im Netzwerk, die mit dem CryptoServerr kommunizieren.
Die zu untersuchende Software ist vollständig closed source, d.h. die Quelltexte sind nicht
öffentlich verfügbar. Auch ein potentieller Angreifer hat keinen Zugriff auf diese. Daher
sollen auch alle Untersuchungen im Rahmen dieser Arbeit als reine Black-Box-Tests, d.h.
ohne Kenntnis der Quelltexte, durchgeführt werden.
Ziel der Untersuchung ist es nun herauszufinden, ob – und wenn ja inwieweit und unter
welchen Voraussetzungen – ein Angreifer in diesem Szenario an vertrauliche Informationen, die innerhalb des CryptoServersr gespeichert sind (wie etwa kryptografische Schlüssel), gelangen kann.
1.2.2 Abgrenzung
In dem in Abschnitt 1.2.1 beschriebenen Szenario hat der Angreifer keinen direkten physikalischen Zugriff auf den CryptoServerr . Dadurch können nicht alle Klassen von Angriffen (diese werden in Abschnitt 2.2 aufgeführt) angewandt werden. Insbesondere entfällt
der Großteil der in Abschnitt 2.2.2 aufgeführten Angriffe auf Seitenkanäle. So ist weder
13
1 Einleitung
eine Leistungsanalyse, noch eine Analyse der elektromagnetischen Strahlung, noch eine
Fehlerfallanalyse möglich. Zeitmessungen werden über ein Netzwerk zwar ungenauer als
direkte Messungen, können aber dennoch eine ausreichende Präzision aufweisen [BB03].
Darüber hinaus soll der Bereich des sogenannten Social Engineerings in dieser Arbeit nicht
näher betrachtet werden.
1.3 Ergebnisse
Unter der Voraussetzung, dass die zur Benutzung des Cryptographic Services Interfaces
(CSI) des CryptoServersr zwingend erforderliche vorherige Authentisierung bereits umgangen wurde, können mit Hilfe der in Abschnitt 4.2.2 analysierten Meet-in-the-Middle Attack 56 Bit lange DES-Schlüssel geknackt werden. Die Key Import Attack (Abschnitt 4.2.3)
führt unter dieser Voraussetzung ebenfalls zu (dem Angreifer) bekannten Schlüsseln innerhalb des CryptoServersr . Ohne eine vorherige Authentisierung vorauszusetzen ist ausschließlich der in Abschnitt 4.3.2 untersuchte Man-in-the-Middle Angriff erfolgreich: Dem
Benutzer des CSI kann damit ein bekannter Sitzungsschlüssel untergeschoben werden,
was unter bestimmten Voraussetzungen zu einem dem Angreifer bekannten Schlüssel im
CryptoServerr führen kann. Für den Einsatz des CryptoServersr als SecurityServer in unsicheren Netzen ist dieser Man-in-the-Middle Angriff daher besonders kritisch.
1.4 Struktur der Arbeit
Nach der allgemeinen Einleitung in diesem Kapitel (Kapitel 1) präsentiert Kapitel 2 zunächst eine Übersicht über die Methoden zum Angriff kryptografischer Systeme. Im weiteren Verlauf werden das Konzept der Hardware-Sicherheitsmodule und der CryptoServerr
im speziellen vorgestellt.
In Kapitel 3 werden bekannte Angriffe auf Security-APIs vorgestellt und deren Anwendbarkeit auf den CryptoServerr untersucht. Anschließend werden spezifisch für das CryptoServerr CSI neue Angriffsszenarien entwickelt.
Kapitel 4 beschäftigt sich schließlich mit der eigentlichen Analyse des CryptoServersr . Hier
werden die in Kapitel 3 vorgestellten Angriffe auf den CryptoServerr angewendet und die
Ergebnisse ausgewertet.
Eine Zusammenfassung der im Rahmen dieser Arbeit gewonnenen Erkenntnisse findet sich
in Kapitel 5, welches abschließend auch Auskunft zu möglichen Folgearbeiten gibt.
14
2 Hintergrund
2.1 Einleitung
In diesem Kapitel wird das Hintergrundwissen vermittelt, welches für das Verständnis der
in den beiden folgenden Kapiteln präsentierten und analysierten Angriffe auf Hardware-Sicherheitsmodule notwendig ist. Dazu geht es zunächst auf Vorarbeiten im Bereich der Analyse kryptographischer Systeme, allgemein und im Speziellen der Analyse von SecurityAPIs, ein (Abschnitt 2.2). In Abschnitt 2.3 folgt eine Erläuterung des Konzepts HardwareSicherheitsmodul. Das Kapitel schließt in Abschnitt 2.4 mit einer detaillierten Beschreibung
des Hardware-Sicherheitsmoduls CryptoServerr der Utimaco Safeware AG, welches der
Gegenstand der in dieser Arbeit durchgeführten Sicherheitsuntersuchung ist.
2.2 Vorarbeiten zur Analyse kryptografischer Systeme
Kryptografische Systeme und Angriffe auf diese Systeme gibt es schon seit vielen tausend
Jahren [Kah96]. Die verschiedenen heute bekannten Angriffsmethoden sollen im Folgenden kurz vorgestellt werden. Den Anfang bilden die ältesten Methoden Kryptanalyse und
Protokollanalyse (Abschnitt 2.2.1). Es folgen die Angriffe auf Seitenkanäle (Abschnitt 2.2.2). Abschließend wird das noch recht junge Feld der API-Angriffe beleuchtet (Abschnitt 2.2.3).
2.2.1 Kryptanalyse und Protokollanalyse
Die älteste Methode kryptografische Systeme anzugreifen ist die Kryptanalyse: „the science
and art of breaking [cryptographic ciphers]“ [And01, S. 74], also die Wissenschaft und
Kunst kryptografische Codes zu brechen. Obgleich bereits die alten Ägypter und auch Julius Caesar einfache Verschlüsselungsalgorithmen verwendeten, stammt die erste schriftlich
belegte Kryptanalyse erst aus dem 9. Jahrhundert: „A Manuscript on Deciphering Cryptographic Messages“ von Abu Yusuf Yaqub ibn Ishaq al-Sabbah Al-Kindi (vgl. [Ren04, S.
100f]).
15
2 Hintergrund
Aktuellere Beispiele der Kryptanalyse sind die 1993 von Biham et al. [BS93] und Preneel
et al. [PNRB93] vorgestellten Angriffe auf den Data Encryption Standard (DES). Die Analyse des Advanced Encryption Standards (AES) respektive des zugrunde liegenden RijndaelAlgorithmus ist Gegenstand aktueller Forschung [SPQ03, DKR04, Kel04]. Weitere Verfahren werden in [And01] und [MOV96] beschrieben.
Werden nicht direkt kryptografische Primitiven angegriffen, sondern Protokolle, die diese
verwenden, spricht man von Protokollanalyse. Aktuelle Forschungsbeispiele hierzu sind die
Überlegungen Meadows zu kryptografisch sicheren Protokollen [Mea03] und die Analyse
des Kerberos-Protokolls durch Long et al. [LF06].
2.2.2 Angriffe auf Seitenkanäle
Ein Seitenkanal (engl.: side-channel [KSWH00]) entsteht, wenn bei der Benutzung einer Implementierung einer kryptografischen Funktion zusätzliche, nicht beabsichtigte Informationen austreten. Diese zusätzlichen Informationen können sehr verschiedener Natur sein.
Bei den von Kocher [Koc96] beschriebenen Angriffen über Zeitmessungen (engl.: timing
attacks) lassen sich Informationen über einen kryptografischen Schlüssel daraus ableiten,
wie lange ein Algorithmus exakt für eine Operation mit einem privaten Schlüssel (z.B.
dem Verschlüsseln einer Nachricht) benötigt. Ähnlich wird auch bei der von Kocher et al.
[KJJ98, KJJ99] entwickelten Leistungsanalyse (engl.: power analysis) verfahren. Nur wird in
letzterem Fall nicht die Zeit gemessen, die für eine Operation benötigt wird, sondern die
elektrische Leistung, die während dieser Operation verbraucht wird.
Eine wiederum völlig andere Klasse ist die Fehlerfall-Analyse (engl.: fault analysis), welche
1997 zunächst von Boneh et al. [BDL97] für Public-Key Verfahren vorgestellt und kurz darauf von Biham et al. [BS97] auf symmetrische Verschlüsselungsverfahren ausgeweitet wurde. Hierbei werden absichtlich Fehler in eine kryptografische Operation oder Berechnung
eingebracht. Dies kann etwa dadurch geschehen, dass ein Kabel/eine Leiterbahn durchtrennt oder eine einzelne Speicherzelle (z.B. durch einen Laser- oder Röntgenstrahl) zerstört
wird.
Ein weiterer Seitenkanal kann elektromagnetische Strahlung sein, welche bei der Berechnung kryptografischer Funktionen entsteht. Erste Ergebnisse der elektromagnetischen Analyse (engl.: electromagnetic analysis) stellten Rao et al. [RR01] im Mai 2001 vor, die ersten
konkreten Angriffe lieferten wenige Tage später Gandolfi et al. [GMO01].
Einen detaillierteren Überblick über die verschiedenen Seitenkanäle einschließlich ihrer
Angriffe bietet [Clu03a, S. 10-21].
16
2 Hintergrund
2.2.3 API-Angriffe
Gerade bei der Betrachtung Hardware-basierter Sicherheit wurden in den letzten Jahren
die Security-APIs verschiedener sogenannter Hardware-Sicherheitsmodule (HSM) unterschiedlicher Hersteller kompromittiert. Den Grundstein zu diesen Forschungen legte Anderson 2000 im Rahmen eines Workshops zum Thema „Security Protocols“ mit seinem Artikel „The Correctness of Crypto Transaction Sets“ [And00].
Der erste Angriff auf eine Security-API, die Common Cryptographic Architecture (CCA)
der IBM 4758 [IBM], gelang Bond Ende 2000 [Bon00]. Anfang 2001 folgten weitere Angriffe
auf die IBM CCA und das Visa Security Module [Bon01].
In den folgenden Jahren entwickelten insbesondere Bond und Clulow immer neue Angriffe, die detailliert in [Bon04] bzw. [Clu03a] beschrieben sind. Einen guten Überblick bietet
[ABCS06].
2.3 Hardware-Sicherheitsmodule
2.3.1 Definition
Ein Hardware-Sicherheitsmodul (HSM) ist ein manipulationssicherer (engl.: tamper-resistant)
kryptografischer Prozessor, der über einen (zumindest kleinen) internen und ebenfalls manipulationssicheren Speicher verfügt.
Seine Funktionen bietet er über eine definierte externe Schnittstelle an. Diese Funktionen
können zum Beispiel das Erzeugen kryptografischer Schlüssel, das Ver- oder Entschlüsseln
von Nachrichten unter Benutzung eines intern gespeicherten Schlüssels oder die Verifikation einer PIN sein.
Sämtliche Berechnungen führt das HSM intern durch. Der Benutzer der Schnittstelle erhält
lediglich das Ergebnis der Berechnung (z.B. die Mitteilung, dass ein neuer Schlüssel erzeugt
wurde, die verschlüsselte Nachricht, eine Meldung ob die PIN korrekt war, etc.).
Eingesetzt werden HSMs u.a. beim elektronischen Zahlungsverkehr in Banken, im Telekommunikationswesen, bei der Mauterfassung, der elektronischen Gesundheitskarte und
beim Bezahlfernsehen (Pay-TV).
17
2 Hintergrund
2.3.2 Arten
Hardware-Sicherheitsmodule existieren in verschiedenen Ausführungen. Die zur Zeit am
weitesten verbreitete Variante ist die Smartcard. Dabei handelt es sich um eine Plastikkarte
mit integriertem Chip, in dem ein Mikroprozessor und ein kleiner Speicher enthalten sind.
Solche Karten werden beispielsweise beim Online-Banking via HBCI, beim Pay-TV und
zunehmend auch beim elektronischen Zahlungsverkehr im Einzelhandel eingesetzt.
USB-Token unterscheiden sich hauptsächlich in der hardwareseitigen Schnittstelle und somit in der äußeren Form von Smartcards. Auf funktioneller Seite sind sie dagegen nahezu
identisch. Diese Token werden unter anderem zur Authentifikation eines Benutzers am PC
und bei der elektronischen Steuererklärung verwendet.
Etwas leistungsfähiger als Smartcards und Token sind die Trusted Platform Modules (TPM).
Diese finden sich zunehmend fest verdrahtet in neueren PCs. Anwendungsgebiete sind
insbesondere das digitale Rechtemanagement (DRM) bei online erworbenen Musikstücken
und Filmen. Sie können aber auch für eigene digitale Signaturen oder die Verschlüsselung
von Daten eingesetzt werden.
Die „großen“ Hardware-Sicherheitsmodule unterscheiden sich im Formfaktor, besonders
aber in ihrer Leistungsfähigkeit und dem zur Verfügung stehenden Speicherplatz deutlich
von ihren kleineren Artgenossen. Sie existieren meist als Steckkarte mit PCI oder PCI-X
Schnittstelle oder als externes Gerät mit LAN-Anschluss. Diese HSMs werden vor allem
beim elektronischen Zahlungsverkehr in Banken, aber auch zum Beispiel im Telekommunikationswesen und bei der Mauterfassung eingesetzt.
Im Rahmen dieser Arbeit soll ein großes HSM untersucht werden. Daher liegt der Fokus im Folgenden ausschließlich auf diesen Modulen. Die verschiedenen Varianten von
Hardware-Sicherheitsmodulen sind in Abbildung 2.1 dargestellt.
(a) Smartcard & Token
(b) TPM
(c) HSM
Abbildung 2.1: Arten von HSMs (Quelle: Utimaco Safeware AG)
18
2 Hintergrund
2.3.3 Hersteller
Der Pionier bei der kommerziellen Entwicklung von HSMs war IBM, die 1974 die auf
Finanz-Transaktionen spezialisierte 3600er Serie herausbrachte [Bon04, S. 45-47]. Bis zu diesem Zeitpunkt waren Hardware-Sicherheitsmodule ausschließlich im militärischen Umfeld
anzutreffen. Das erste HSM mit Unterstützung für DES-Schlüssel folgte 1977 mit dem IBM
3845.
Die ersten Konkurrenzprodukte folgten erst 1985 mit dem von Racal SPS (heute zu Thales gehörend) produzierten Visa Security Module und der von Eracom (heute zu SafeNet
gehörend) auf dem Markt gebrachten PC crypto card.
Auch heute gibt es weltweit nur ein knappes Dutzend Hersteller großer Hardware-Sicherheitsmodule. Die Wichtigsten sind in Tabelle 2.1 aufgelistet.
Hersteller
aep Networks
Futurex
IBM
HP Atalla
nCipher
Prism
SafeNet
Thales e-Security
Utimaco Safeware
Homepage
http://www.aepnetworks.com/products/products.aspx
http://www.futurex.com/index.php?Itemid=38
http://www-03.ibm.com/security/cryptocards/
http://www.hp.com/go/atalla/
http://www.ncipher.com/cryptographic_hardware/
http://www.prism.co.za/incognito.aspx
http://www.safenet-inc.com/products/pki/index.asp
http://www.thales-esecurity.com
http://www.utimaco.de/hsm/
Tabelle 2.1: Hersteller von Hardware-Sicherheitsmodulen
2.3.4 Schnittstellen
Wie in Abschnitt 2.3.1 erwähnt, bieten Hardware-Sicherheitsmodule ihre Funktionen über
definierte Schnittstellen, so genannte Application Programming Interfaces (APIs), an. Es gibt
inzwischen eine Vielfalt solcher APIs.
Diese reichen von sehr allgemeinen Standard-APIs – wie dem Public-Key Cryptography Standard (PKCS) #11 der RSA Laboratories [RSA04], Suns Java Cryptography Extension (JCE)
[Sun], Microsofts CryptoAPI [Micb] und Cryptographic API: Next Generation (CNG) [Mica],
sowie dem OpenSSL Toolkit des OpenSSL Project [Ope] – bis hin zu hochspezialisierten
APIs – beispielsweise der auf Finanz-Transaktionen spezialisierten Electronic Funds Transfer
at Point of Sale (EFTPOS) API.
19
2 Hintergrund
Aufgrund des Protokoll-Overheads der Standard-Schnittstellen (PKCS #11, CSP, ...) bieten
viele HSM-Hersteller selbst proprietäre APIs an. Die bekannteste ist IBMs Common Cryptographic Architecture (CCA) [IBM03]. Aber auch andere Hersteller, wie nCipher mit der nCore
API [nCi05a, nCi05b] und Utimaco mit dem Cryptographic Services Interface (CSI) [BH06a],
bieten eigene APIs an. Bei diesen Schnittstellen handelt es sich in der Regel um allgemeine
APIs zur Bereitstellung von Security-relevanten Funktionen.
Eine Besonderheit stellt die IBM CCA dar. Hierbei handelt es sich um eine allgemeine API,
die sukzessive um Finanz-Transaktionen erweitert wurde.
Das CSI der Utimaco, welches aufgrund seiner Beschränkung auf das Wesentliche und der
daraus resultierenden Übersichtlichkeit ebenfalls eine Besonderheit darstellt, wird in Abschnitt 2.4.2 genauer beschrieben.
2.4 Der CryptoServerr
In diesem Abschnitt soll der SafeGuard CryptoServerr , das Hardware-Sicherheitsmodul
der Utimaco Safeware AG [Utib], genauer beschrieben werden. Abbildung 2.2 zeigt ein
Foto dieses HSMs.
Abbildung 2.2: Der CryptoServerr (Quelle: Utimaco Safeware AG)
20
2 Hintergrund
2.4.1 Aufbau
Der CryptoServerr existiert in zwei Varianten: Die PCI-Version ist zum Einbau in Einzelplatzsysteme gedacht. Die LAN-Version ist eine erweiterte Variante zum direkten Betrieb
des CryptoServersr im Netzwerk und kann direkt über TCP/IP angesprochen werden.
Da im Inneren des CryptoServerr LAN wiederum der CryptoServerr PCI zum Einsatz
kommt, betrachten wir hier zunächst die PCI-Variante.
Die PCI-Variante besteht im Wesentlichen aus einem Prozessor (CPU) mit internem Speicher, weiterem zusätzlichen Speicher (RAM und Flash Memory), einem Zufallszahlengenerator, einer Echtzeituhr, zwei seriellen Schnittstellen und einer Batterie. Mit Ausnahme
der seriellen Schnittstellen und der Batterie sind alle Komponenten zusammen von einem
Metallschild und einer speziellen – Manipulationen-erkennenden – Folie (engl.: tamper detection foil) umhüllt und in einer Keramik eingegossen. Die Batterie dient dazu, intern gespeicherte kryptografische Schlüssel auch bei deaktivierter externer Stromversorgung zu
erhalten. Abbildung 2.3 zeigt die verschiedenen Schichten des CryptoServersr .
Abbildung 2.3: Schichten des CryptoServersr (Quelle: Utimaco Safeware AG)
Je nach Anwendungsgebiet bietet der CryptoServerr eine wohldefinierte externe SoftwareSchnittstelle. Das Software-Konzept des CryptoServersr ist modular und besteht aus verschiedenen Firmware-Modulen, die jeweils verschiedene interne und/oder externe Schnittstellen bieten. Es gibt Module, die auf jedem CryptoServerr vorhanden sein müssen, wie
etwa das Betriebssystem, aber auch solche, die spezielle Kundenwünsche implementieren.
Einzelne Firmware-Module können vom Kunden geladen, ersetzt oder gelöscht werden.
Dieser benötigt hierzu den – kundenspezifischen – Initialisierungsschlüssel.
21
2 Hintergrund
Der SafeGuard CryptoServerr LAN (Abbildung 2.4) vereint einen oder mehrere CryptoServerr PCI in einer Kommunikationseinheit. Diese Kommunikationseinheit basiert auf
einem gehärteten (engl.: hardened) Linux und erweitert den CryptoServerr um die Fähigkeit der Kommunikation in Netzwerken.
Abbildung 2.4: Der CryptoServerr LAN (Quelle: Utimaco Safeware AG)
Neben TCP/IP unterstützt der CryptoServerr LAN auch UDP/IP und IP-Multicast. Aufgrund seiner höheren Verlässlichkeit ist TCP/IP jedoch das bevorzugte Protokoll.
Zur Konfiguration des Linux-Betriebssystems und zur Statusanzeige enthält der CryptoServerr LAN ein kleines Display und 6 Tasten. Außerdem verfügt er über eine LANSchnittstelle (Ethernet) sowie serielle Schnittstellen (u.a. zum Anschluss eines Pinpads).
Abbildung 2.5 zeigt eine schematische Übersicht.
Weitere Informationen zum Aufbau des CryptoServersr hält [OKH06] bereit, der CryptoServerr LAN ist ausführlich in [LDVH06] beschrieben.
2.4.2 Das Cryptographic Services Interface (CSI)
Das Cryptographic Services Interface (CSI) ist eine der verfügbaren externen Software-Schnittstellen des CryptoServersr . Es besteht aus zwei Ebenen: Der Transportebene und einem
API für C. Auf der Transportebene können Byte-Ströme, die Anweisungen und/oder Antworten enthalten, direkt an das PCI-Interface des CryptoServersr geschickt werden. Das
API bietet diese Funktionen auf einer höheren Ebene an und setzt die Funktionsaufrufe
wiederum in Byte-Ströme um. Auch die LAN-Variante des CryptoServersr kann mit diesem API angesprochen werden.
22
2 Hintergrund
Abbildung 2.5: Schematische Darstellung des CryptoServerr LAN (Quelle: Utimaco Safeware
AG)
Das CSI bietet kryptografische Funktionen wie Schlüsselgenerierung, symmetrische Verund Entschlüsselung von Daten, Signieren von Daten, Verifikation von Signaturen, HashAlgorithmen und Zufallszahlengenerierung. Eine Benutzerverwaltung bietet das CSI selbst
nicht, hierzu existieren jedoch weitere Schnittstellen auf Transportebene und als C APIs
[Her06, Her03a].
Eine vollständige Beschreibung des CSI findet sich in [BH06a].
2.4.3 Policy
Die Sicherheits-Policy des CryptoServersr unterscheidet sich zwar je nach Anwendungsgebiet leicht, ist im Wesentlichen aber doch immer ähnlich: Nur autorisierte Personen dürfen die Funktionen des CryptoServersr benutzen, nicht-autorisierte Personen dürfen insbesondere keinerlei Erkenntnisse über die intern gespeicherten Schlüssel erlangen können.
Autorisierte Personen sind in diesem Fall jene, die sich mit einem Benutzernamen sowie
entweder einem Passwort, einem passwortgeschützten kryptografischen Schlüssel oder einer pingeschützten Smartcard authentifizieren können und auf dem CryptoServerr über
entsprechende Berechtigungen verfügen.
Um diese Berechtigungen durchsetzen zu können, speichert die Benutzerverwaltung des
CryptoServersr intern einen Authentifikations-Zustand, aufgeschlüsselt in acht Gruppen
(Gruppe 0 bis Gruppe 7). Jedem Benutzer wiederum kann in jeder dieser acht Gruppen
23
2 Hintergrund
ein Authentifikations-Level von 0 (keine Berechtigungen) bis 3 (maximale Berechtigungen) zugewiesen werden. Für Aufgaben der Benutzerverwaltung ist beispielsweise ein
Authentifikations-Level von 2 in Gruppe 7 nötig, zur Benutzung von Funktionen aus dem
CSI ein Authentifikations-Level von 2 in Gruppe 1. Die Berechtigungen zweier gleichzeitig angemeldeter Benutzer summieren sich dabei, so dass beispielsweise auch zwei gleichzeitig angemeldete Benutzer mit einem Authentifikations-Level von 1 in Gruppe 7 eine
Benutzung der Benutzerverwaltung erlauben. So wird der Einsatz des 4-Augen-Prinzips
ermöglicht. Weitere Informationen zum Thema Authentifikation im CryptoServerr finden
sich in [Her03a].
2.4.4 Was ist ein SecurityServer?
Der SecurityServer ist ein Produkt-Paket, welches aus einem CryptoServerr (wahlweise als
PCI- oder LAN-Version), einem Pinpad und einer Produkt-CD [Utia] besteht. Die ProduktCD enthält neben der Dokumentation zum CryptoServerr und Administrations-Tools insbesondere auch verschiedene Schnittstellen, über die der CryptoServerr angesprochen
werden kann. Zu diesen Schnittstellen gehören eine zum Public Key Cryptography Standard #11 (PKCS #11) der RSA Laboratorien kompatible Schnittstelle, ein Crypto Service
Provider (CSP) für Microsoft’s CryptoAPI, sowie das proprietäre CSI. In Zukunft soll außerdem ein zur JavaTM Cryptographic Extension (JCE) kompatibles API mitgeliefert werden.
2.5 Zusammenfassung
Am Anfang dieses Kapitels wurde ein geschichtlicher Hintergrund über die Analyse kryptografischer Systeme gezeichnet. Es folgte eine Definition des Konzepts Hardware-Sicherheitsmodul. Die verschiedenen Arten von HSMs wurden erläutert. Ebenso wurden die
unterschiedlichen Hersteller und Schnittstellen von Hardware-Sicherheitsmodulen aufgezeigt. Abschließend wurden mit dem CryptoServerr und dem Cryptographic Services Interface (CSI) ein spezielles HSM und dessen Security-API genauer beschrieben. Damit ist
nun das – zum Verständnis der im folgenden Kapitel beschriebenen Angriffe notwendige –
Hintergrundwissen vorhanden.
24
3 Angriffe
3.1 Einleitung
Dieses Kapitel beschäftigt sich mit konkreten Angriffen auf Hardware-Sicherheitsmodule.
Im ersten Schritt (Abschnitt 3.2) werden bereits bekannte, von anderen Autoren entwickelte
Angriffe vorgestellt und die Anwendbarkeit dieser Angriffe auf den CryptoServerr untersucht. Im zweiten Schritt (Abschnitt 3.3) werden neue Angriffsszenarien entwickelt, welche
die Eigenheiten des CryptoServersr und seiner Security-API CSI berücksichtigen.
3.2 Bekannte Angriffe
Betrachtet man nun die Angriffsmöglichkeiten auf Security-APIs, so existieren zwei verschiedene Kategorien von Angriffen.
Die erste Kategorie umfassst solche Angriffe, die nur auf Finanz-APIs (vgl. Abschnitt 2.3.4)
angewendet werden können. Diese werden in Abschnitt 3.2.1 aufgelistet.
Die zweite Kategorie bilden die auch auf allgemeine Security-APIs anwendbaren Angriffe. Diese werden in Abschnitt 3.2.2 kurz beschrieben und deren Anwendbarkeit auf den
CryptoServerr bzw. das CSI untersucht. Detailliertere Informationen zu allen beschriebenen Angriffen finden sich in [Bon04] und [Clu03a].
3.2.1 Angriffe auf Finanz-APIs
Insbesondere viele der von Clulow entdeckten Angriffe können nur auf Finanz-APIs angewendet werden. Beim CSI handelt es sich jedoch nicht um eine spezielle Finanz-API. Daher
sind diese Angriffe hierauf nicht anwendbar und sollen hier nur der Vollständigkeit halber
aufgelistet werden. Das Ziel eines solchen Angriffs ist fast immer das Ausspähen der PIN
zu einer bestimmten Kontonummer. Genauere Informationen können [Clu03a] entnommen
werden, die jeweiligen Seiten sind in Klammern angegeben.
• Decimalisation Table Attack (S. 70-80), [Bon04, S. 28-29, 107-114]
25
3 Angriffe
• Exhaustive Pin Search (S. 73)
• The Code Book Attack (S. 73)
• ANSI X9.8 (ISO-0) Attack (S. 75-76)
• Extended ANSI X9.8 Attack (S. 76-78)
• Key Separation Attack #1 (S. 80-82)
• Key Separation Attack #2 (S. 82-84)
• Clulow’s Check Value Attack(S. 84-85)
3.2.2 Allgemeine Angriffe
Die nicht auf spezielle API-Typen zugeschnittenen Angriffe sollen in diesem Abschnitt kurz
erläutert und deren Anwendbarkeit auf den CryptoServerr (CS) bzw. das CSI geklärt werden. Diese Angriffe stammen ebenfalls ausnahmslos aus den Federn von Bond und Clulow.
XOR to Null Key Attack
Viele Security-APIs besitzen eine Funktion zum Importieren eines kryptografischen Schlüssels aus zwei (evtl. verschlüsselten) Schlüsselhälften. Dabei wird der eigentliche Schlüssel
aus den beiden Hälften gewonnen, in dem die beiden Hälften ggf. zunächst entschlüsselt
und anschließend per XOR zu einem Schlüssel vereinigt werden. Übergibt man einer solchen Funktion nun zweimal die gleiche Schlüsselhälfte (egal, ob verschlüsselt oder nicht)
führt dies – nach der Definition von XOR – zwangsläufig zu einem Schlüssel, der nur aus
Nullen besteht. Somit erhält man einen bekannten Schlüssel im System.
Das CSI enthält eine solche Funktion nicht. Daher ist dieser Angriff nicht anwendbar. Das
Master-Box-Key-Management des CryptoServersr bietet zwar eine entsprechende Funktion, nimmt die beiden Schlüsselhälften jedoch jeweils nur von einer Smartcard entgegen.
Das entsprechende Pinpad muss dazu direkt an die serielle Schnittstelle des CryptoServersr angeschlossen werden – somit ist ein physischer Zugang zum CS zwingend erforderlich.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
ja
26
(bei physischem Zugang)
3 Angriffe
Type System/Key Separation Attack
Hardware-Sicherheitsmodule unterscheiden intern häufig verschiedene Schlüsseltypen. So
wird etwa zwischen Datenschlüsseln (engl.: data keys) – mit denen benutzerdefinierte Daten verund entschlüsselt werden dürfen – und Transportschlüsseln (engl.: key encryption keys (KEK)) – zum verschlüsselten Im-/Export eines anderen Schlüssels – differenziert.
Häufig existieren zudem verschiedene Benutzergruppen, so dass bestimmte Benutzer zwar
Daten verund entschlüsseln, aber keine Schlüssel importieren dürfen.
Unterscheidet nun ein HSM nicht streng zwischen diesen beiden Schlüsseltypen, könnte ein solcher Benutzer beispielsweise einen exportierten Schlüssel als Daten der Funktion zum Entschlüsseln übergeben. Als Schlüssel könnte er den entsprechenden Transportschlüssel wählen. Das Ergebnis wäre dann der Schlüssel im Klartext. Der Benutzer hätte
somit unter Umständen einen bekannten Schlüssel innerhalb des HSM.
Das CSI verwendet ein solches Typensystem. Dieser Angriff muss daher untersucht werden. Auf das Key-Management des CryptoServersr selbst ist der Angriff nicht anwendbar,
da hier kein entsprechendes Typensystem existiert.
Anwendbar auf CSI:
ja
Anwendbar auf CS:
nein
Meet-in-the-Middle Attack
Die Idee der Meet-in-the-Middle Attack ist, dass es oftmals genügt, einen Schlüssel eines
bestimmten Typs zu kennen, um alle Schlüssel dieses Typs zu kompromittieren. Der erste
Schritt ist daher, eine große Anzahl verschiedener Schlüssel eines Typs zu erzeugen. Um
einen einfachen DES-Schlüssel zu knacken, sollten etwa 216 Schlüssel erzeugt werden.
Im zweiten Schritt verschlüsselt man den gleichen bekannten Klartext mit jedem dieser
Schlüssel und berechnet einen Hash-Wert zu jedem Ergebnis. Diese Hash-Werte werden
schließlich, zusammen mit einem Verweis auf den jeweiligen Schlüssel, in einer HashTabelle gespeichert.
Im Anschluss führt man eine vereinfachte Brute-Force Suche durch: Der bekannte Klartext wird mit dem aktuellen Schlüssel verschlüsselt und der zugehörige Hash-Wert berechnet. Abschließend vergleicht man den aktuellen Hash-Wert mit allen Werten in der HashTabelle. Wird eine Übereinstimmung gefunden, so hat man einen bekannten Schlüssel im
System.
27
3 Angriffe
Der zu durchsuchende Schlüsselraum, bei einfachen DES-Schlüsseln 256 , verringert sich so
256
216
= 240 Schlüssel. Im Durchschnitt wird ein solcher Schlüssel damit nach
Iterationen gefunden.
auf
240
2
= 239
Dieser Angriff ist auf das CSI anwendbar und muss daher untersucht werden. Auf das KeyManagement des CryptoServersr ist der Angriff nicht anwendbar, da hier nie mehr als ein
Schlüssel eines Typs existieren kann. Der alte Schlüssel wird hier grundsätzlich durch den
neuen Schlüssel ersetzt.
Anwendbar auf CSI:
ja
Anwendbar auf CS:
nein
Key Conjuring Attack
Die sogenannten monotonen HSMs (engl.: monotonic HSMs) bilden eine spezielle Klasse
von Hardware-Sicherheitsmodulen. Module dieser Klasse speichern nur wenige MasterSchlüssel intern. Alle übrigen Schlüssel werden extern auf dem Host-Computer abgelegt,
verschlüsselt unter einem der Master-Schlüssel. Ein Beispiel für ein solches HSM ist die
IBM 4758. Die extern abgelegten Schlüssel müssen dann bei Verwendung als Parameter an
das HSM übergeben werden.
Module dieser Klasse sind „anfällig für nicht-autorisierte Schlüsselgenerierung“ [Bon04].
Dies ist insbesondere bei Schlüsseln aus der DES-Familie leicht möglich. Hier genügt es,
einen Zufallswert entsprechender Länge als verschlüsselten Schlüssel anzugeben. Das vom
HSM entschlüsselte Ergebnis ist dann wiederum zufällig und hat mit einer Wahrscheinlichkeit von 1 : 28 die korrekte Parität.
Der CryptoServerr gehört nicht zu den monotonen HSMs, er speichert alle Schlüssel intern. Daher ist dieser Angriff auf den CS nicht anwendbar.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
nein
3DES Key Binding Attack
Es existieren drei verschiedene Varianten des DES-Algorithmus: Das einfache DES mit einer
Schlüssellänge von 56 Bit, sowie 3DES mit 112 bzw. 168 Bit Schlüssellänge. In den Anfängen
von Hardware-Sicherheitsmodulen wurde häufig nur das einfache DES unterstützt. Einige Hersteller haben später eine 3DES-Unterstützung nachgerüstet. Dazu kombinierten sie
zwei bzw. drei einfache DES-Schlüssel zu einem 3DES-Schlüssel. Die Teile wurden als linke
28
3 Angriffe
und rechte Hälfte bzw. linkes, mittleres und rechtes Drittel markiert und separat gespeichert. Einfache DES-Schlüssel konnten mit Hilfe eines 112-Bit 3DES-Schlüssels simuliert
werden, bei dem beide Hälften identisch waren.
In einigen HSMs war es nun aufgrund einer unzureichenden Bindung der zwei Schlüsselhälften eines 112-Bit 3DES-Schlüssels möglich, auch „echte“ 3DES-Schlüssel mit identischen Schlüsselhälften zu erzeugen. Unter Benutzung der zuvor bereits beschriebenen
Meet-in-the-Middle Attack lässt sich ein solcher 3DES-Schlüssel mit dem nur doppelten
des für einfache DES-Schlüssel nötigem Aufwand berechnen [Bon04, S. 28]. Clulow nennt
diesen Angriff Key Integrity Attack [Clu03a, S. 43-44].
Sowohl jeder Master-Key, als auch jeder mit Hilfe des CSI erzeugte 3DES-Schlüssel, wird
im CryptoServerr als eine Einheit gespeichert. Daher kann dieser Angriff auf den CryptoServerr nicht angewandt werden.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
nein
Related Keys Attack
Ähnliche Schlüssel (engl.: related keys) sind nach der Definition von Bond [Bon04, S. 88]
zwei oder mehr Schlüssel, bei denen die Differenz bitweise bekannt ist. Bei einer Gruppe
ähnlicher Schlüssel hängt die Sicherheit aller Schlüssel dieser Gruppe an der Sicherheit
jedes einzelnen. Außerdem sind solche Gruppen nach [Bon04] anfälliger für Brute-ForceAngriffe, wie etwa der Meet-in-the-Middle Attack.
Zwei ähnliche Schlüssel in einem HSM können durch das häufig vorhandene Kommando
zum Import eines Schlüssel aus mehreren Schlüsselteilen gewonnen werden. Dazu ändert
man einen Teil geringfügig und importiert den vollständigen Schlüssel dann einmal mit
dem korrekten und einmal mit dem verändertem Teil.
Nur das Master-Box-Key-Management des CryptoServersr verfügt über eine solche Funktion. Der Master-Box-Key (MBK) wird jedoch grundsätzlich von seinem Nachfolger überschrieben. Es kann daher keine Gruppe ähnlicher Schlüssel im CS erzeugt werden.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
nein
29
3 Angriffe
Bond’s Check Value Attack
Fast alle Security-APIs bieten eine Funktion zur Berechnung von Kontrollwerten (engl.:
check values) über einzelne Schlüssel. Zur Berechnung dieser Kontrollwerte wird – bei symmetrischen Schlüsseln – intern häufig eine konstante Zeichenkette mit dem entsprechenden
Schlüssel verschlüsselt und das Ergebnis, vollständig oder gekürzt, als Kontrollwert ausgegeben. Insbesondere ungekürzte Kontrollwerte über einfache DES-Schlüssel erlauben einen
vereinfachten Brute-Force- oder Meet-in-the-Middle-Angriff.
Das CSI bietet keine Funktion zur Berechnung von Kontrollwerten, daher kann dieser Angriff auf den CryptoServerr nicht angewendet werden.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
nein
Key Import Attack
Dieser Angriff macht sich eventuelle Schwächen im Typensystem bei exportierten Schlüsseln zunutze. Ist der Typ eines exportierten Schlüssels nicht fest kryptografisch in diesem verankert, so ist es möglich, einen solchen Schlüssel unter einem anderen als dem
ursprünglichen Typ wieder zu importieren.
War der Schlüssel beispielsweise ursprünglich vom Typ KEK und importiert man ihn anschließend als Datenschlüssel, so ist es nun möglich, jeden beliebigen – unter dem Schlüssel exportierten – Schlüssel mit einer einfachen Entschlüsselungsoperation zu dechiffrieren.
Eine evtl. vorhandene Zugangskontrolle zu einem Klartext-Export kann so umgangen werden.
Das CSI benutzt ein solches Typensystem und bietet Funktionen sowohl zum Im- und
Export von Schlüsseln als auch zum Dechiffrieren von verschlüsselten Daten. Das KeyManagement des CS selbst bietet dagegen keine Möglichkeiten zum Entschlüsseln – hier
ist der Angriff daher nicht anwendbar.
Anwendbar auf CSI:
ja
Anwendbar auf CS:
nein
Import/Export Loop Attack
IBMs Common Cryptographic Architecture unterscheidet zwischen Key Encryption Keys
für den Import (IMPORTER) und für den Export (EXPORTER) von Schlüsseln. Der zu einem
EXPORTER passende IMPORTER ist dabei in der Regel nicht auf dem selben HSM verfügbar,
30
3 Angriffe
da diese Schlüsseltypen nur für den Austausch von Schlüsseln zwischen verschiedenen
HSMs gedacht sind. (Die IBM 4758 speichert ohnehin fast alle Schlüssel extern auf dem
Host-Rechner, so dass solche Schlüssel zu Backup-Zwecken auch nicht benötigt werden.)
Die im vorherigen Abschnitt beschriebene Key Import Attack ist im Kontext der IBM CCA
daher in der Form nur mit exportierten Schlüsseln eines anderen Hardware-Sicherheitsmoduls möglich. Die Import/Export Loop Attack erweitert diesen Angriff nun dahin gehend,
dass die von einem HSM exportierten Schlüssel am selben HSM – unter einem anderen Typ
– wieder importiert werden können.
Dieser Angriff nutzt spezielle Eigenheiten des Typensystems der IBM CCA aus, welches
sich (da patentgeschützt) stark von den Typensystemen anderer HSMs unterscheidet. Außerdem ist ein vorheriges Key Conjuring erforderlich, welches beim CryptoServerr nicht
möglich ist. Daher soll der Angriff hier nicht näher erläutert und statt dessen auf [Bon04, S.
97] verwiesen werden.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
nein
Combined Attack
Dieser Angriff kombiniert die Meet-in-the-Middle Attack mit der Related Key Attack mit dem
Ziel, so auch 168-Bit 3DES-Schlüssel kompromittieren zu können.
Da die Related Key Attack im Umfeld des CryptoServersr nicht anwendbar ist, stellt dieser
Angriff keine Gefahr für CryptoServerr dar.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
nein
Exhaustive Key Search
Unter der Bezeichnung Exhaustive Key Search beschreibt Clulow in [Clu03a, S. 72] eine simple Brute-Force-Suche.
Erfolg verspricht diese Suche einzig bei einfachen DES-Schlüsseln. Bei Schlüsseln mit größeren Schlüssellängen (ab etwa 112 Bit) ist ein solcher Angriff mit der heutigen Rechenleistung jedoch praktisch unmöglich.
Im CryptoServerr kommen praktisch nur 3DES-Schlüssel mit mindestens 112 Bit Schlüssellänge oder stärkere Schlüssel vor. Daher soll dieser Angriff, obwohl theoretisch anwendbar, in dieser Arbeit nicht weiter untersucht werden.
31
3 Angriffe
Anwendbar auf CSI:
ja
(aber praktisch unmöglich)
Anwendbar auf CS:
ja
(aber praktisch unmöglich)
Differential Protocol Analysis
Bei diesem Angriff handelt es sich um einen der in Kapitel 2.2.2 erwähnten Angriffe auf
Seitenkanäle aus dem Bereich der Fehlerfall-Analyse. Dabei werden die Eingabeparameter,
die den Funktionen der zu untersuchenden API übergeben werden, methodisch variiert
und eventuelle Veränderungen in den Ausgabeparametern beobachtet. Anhand dieser Veränderungen wird dann versucht, auf ein Geheimnis zu schließen.
Der von Bond in [Bon04, S. 89-91] beschriebene Angriff ist auf Finanz-APIs ausgerichtet
und kann somit auf das CSI nicht direkt angewendet werden. Daher soll er hier nicht genauer beschrieben werden. Prinzipiell ist ein solcher Angriff jedoch auch auf den CryptoServerr möglich und muss daher durchaus weiter untersucht werden.
Anwendbar auf CSI:
ja
Anwendbar auf CS:
ja
Timing Attacks
Auch die Timing Attacks gehören zu den Angriffen auf Seitenkanäle. Dieser Angriff nutzt
aus, dass Vergleichsoperationen über lange Zeichenketten oft als Schleifen oder unter der
Benutzung der C-Funktion memcpy() implementiert sind. Die Zeitunterschiede für die
Berechnung bei verschiedenen Eingaben sind dabei oft messbar. Durch diese Messungen
kann unter Umständen auf ein Geheimnis (in der Regel ein kryptografischer Schlüssel)
geschlossen werden.
Dieser Angriffstyp ist insbesondere in der – rechenintensiveren – asymmetrischen Kryptografie problematisch. Hier sind aber bereits Gegenmaßnahmen bekannt. Insbesondere ist
hier das so genannte Blinding [Clu03a, S. 14], [Her03b, S. 33] zu erwähnen, das auch im
CryptoServerr eingesetzt werden kann.
Da Blinding im CryptoServerr nicht standardmäßig eingeschaltet ist, sind Angriffe über
Zeitmessungen auf das CSI prinzipiell möglich. Direkte Angriffe auf das Master-Box-KeyManagement sind allerdings nicht möglich, da hier zum einen ausschließlich symmetrische
Schlüssel zum Einsatz kommen und zum anderen eine exakte Zeitmessung aufgrund der
erforderlichen Benutzerinteraktion schwierig wird.
Anwendbar auf CSI:
ja
Anwendbar auf CS:
nein
32
3 Angriffe
Dual Security Officer Attack
Einige Hardware-Sicherheitsmodule verlangen für bestimmte, besonders kritische Operationen, wie den Austausch eines Master-Keys, die Autorisation durch zwei Sicherheitsbeauftragte. Für andere Operationen, wie z.B. das Reaktivieren nach einem Stromausfall, ist
jedoch die Autorisation durch einen Sicherheitsbeauftragten ausreichend.
Die durch die Doppel-Autorisation erreichte Sicherheit soll durch diesen Angriff aufgebrochen werden. Dabei tauscht der Angreifer zunächst das echte Hardware-Sicherheitsmodul samt evtl. vorhandener Pinpads, etc. gegen gefälschte, unter seiner Kontrolle befindliche, Modelle aus. Anschließend behauptet er gegenüber einem der Sicherheitsbeauftragten, dass, z.B. nach einem selbst ausgelösten Feueralarm, ein Stromausfall aufgetreten ist
und bittet ihn das Modul erneut zu aktivieren. Diese Autorisation wird von dem gefälschten Modul als erster Teil einer Doppel-Autorisation an das echte Modul weitergeleitet. Hat
der erste Sicherheits-Beauftragte den Raum wieder verlassen, wendet sich der Angreifer
unter dem gleichen Vorwand schließlich an den zweiten Sicherheits-Beauftragten. Auch
dessen Autorisation wird – von ihm unbemerkt – automatisch an das echte HSM weitergeleitet, welches nun auch für besonders sicherheitskritische Operationen autorisiert ist.
Dieser Angriff ist nicht direkt auf den CryptoServerr übertragbar und erfordert sowohl
Social Engineering als auch physischen Zugang zum HSM. Daher soll dieser Angriff in der
vorliegenden Arbeit nicht näher untersucht werden.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
nein
M-of-N Security Officer Attack
Dieser Angriff bedient sich der Tatsache, dass HSMs häufig nicht über ein vertrauenswürdiges Display (engl.: trusted display) verfügen. Eine Authentifikation via Smartcard erfolgt
daher fast immer über ein externes Pinpad – welches von einem Angreifer gegen ein gefälschtes Modell ausgetauscht werden kann.
Das gefälschte Pinpad kann dann zum Beispiel in definierten Abständen vorgeben, die
eingesteckte Smartcard nicht lesen zu können oder eine falsche PIN erhalten zu haben,
und daraufhin zu einem neuen Versuch auffordern. Ist zur Autorisierung einer Operation
die Authentifikation mehrerer Sicherheitsbeauftragter (m − aus − n Smartcards-Schema)
erforderlich, so kann die Autorisierung aus dem zweiten Versuch als erster Teil in eine
nächste Autorisierungsrunde übernommen werden.
33
3 Angriffe
Folgendes Beispiel aus [Bon04, S. 153] für m = 4 veranschaulicht diesen Angriff (X steht für
Autorisierung durch Person X, * für eine vollständige Autorisierung und X’ für einen aus
einer vorherigen Runde übernommenen Autorisierungsversuch):
1. ABCD*D
2. D’ABC*CD
3. C’D’AB*BCD
4. B’C’D’A*ABCD*
Dieser Angriff ist zwar auf den CryptoServerr übertragbar, erfordert jedoch physischen
Zugang zum HSM. Daher soll er hier nicht weiter untersucht werden.
Anwendbar auf CSI:
nein
Anwendbar auf CS:
ja
(bei physischem Zugang)
Known Keys in the System
Hierbei handelt es sich nicht um einen klassischen Angriff, sondern um eine „Was-wärewenn-Analyse“. Clulow betrachtet unter dieser Überschrift in [Clu03a, S. 40] die Risiken,
die durch einen bekannten Schlüssel eines bestimmten Typs im HSM entstehen.
Die größte Gefahr birgt seiner Meinung nach ein bekannter EXPORTER, da mit dessen Hilfe alle im HSM vorhandenen (und exportierbaren) Schlüssel unter ihm exportiert und anschließend mit ihm entschlüsselt werden könnten. Zudem könnten so weitere Schlüssel mit
den gewünschten Eigenschaften im HSM erzeugt und als exportierbar markiert werden.
Diese Analyse ist auch im Hinblick auf den CryptoServerr selbst und das CSI interessant.
Anwendbar auf CSI:
ja
Anwendbar auf CS:
ja
3.3 Neue Angriffsszenarien
Viele der im vorherigen Abschnitt beschriebenen Angriffe sind auf den CryptoServerr und
dessen Cryptographic Services Interface nicht oder nur eingeschränkt anwendbar, da sich
insbesondere das CSI schon in seiner Komplexität stark von anderen Security-APIs, wie
zum Beispiel IBM’s Common Cryptographic Architecture, unterscheidet. Um trotzdem eine möglichst umfassende Sicherheitsuntersuchung zu gewährleisten, war es erforderlich
neue Angriffsszenarien zu erarbeiten. Diese werden im Folgenden vorgestellt.
34
3 Angriffe
3.3.1 Session Hijacking
Sollen Befehle über das Cryptographic Services Interface an den CryptoServerr gesendet
werden, so muss zunächst eine Session aufgebaut werden. Dies geschieht über eine Folge
von fünf Befehlen:
1. Zunächst wird mit dem Befehl cs_open() eine Verbindung zum CryptoServerr (lokal oder im LAN) aufgebaut. Neben der Adresse des CS wird der Funktion ein Zeiger
auf einen Integer-Wert als Parameter übergeben. Letzterer enthält nach erfolgreichem
Verbindungsaufbau eine Zahl, welche die Verbindung eindeutig kennzeichnet und
bei allen weiteren Befehlen angegeben werden muss.
2.-4. In diesen Schritten werden die drei Kommandos cs_push_cmds(), cs_push_sm()
und cs_push_auth() ausgeführt. Hierdurch werden auf dem Host verschiedene
Module des CSAPI, u.a. das Authentifikationsmodul des CryptoServersr , geladen.
5. Mit einem der Befehle cs_login_pwd() bzw. cs_login_sign() erfolgt schließlich die Authentifikation mittels Benutzername und Passwort bzw. Benutzername
und RSA Signatur. Beide Befehle liefern einen Sitzungskontext (engl.: session context)
als Parameter zurück, der auch den Sitzungsschlüssel (engl.: session key) enthält, mit
dessen Hilfe alle weiteren Kommandos authentifiziert werden.
Annahme 1: Ein Benutzer baut eine gültige Session zu einem CryptoServerr LAN auf.
Annahme 2: Der Angreifer hat die Möglichkeit, den gesamten Netzwerkverkehr zwischen
dem Benutzer und dem CS LAN mitzuschneiden. Außerdem kann er eigene Pakete sowohl
an den Benutzer als auch den CS LAN senden.
Frage: Kann der Angreifer die Session übernehmen und
(a) parallel zu dem Benutzer Befehle an den CS senden?
(b) die Verbindung aus Sicht des Benutzers trennen und an dessen Stelle mit dem CS
kommunizieren?
Dieses Szenario folgt aus dem vorherigen durch eine Erweiterung von Annahme 2 und
stellt einen klassischen Man-in-the-Middle (MITM) Angriff dar:
Annahme 2’: Der Angreifer hat die Möglichkeit, den gesamten Netzwerkverkehr zwischen
dem Benutzer und dem CS LAN mitzuschneiden und alle Pakete nach Belieben und transparent für die beiden Kommunikationspartner zu modifizieren bevor sie den jeweiligen
35
3 Angriffe
Empfänger erreichen. Außerdem kann er eigene Pakete sowohl an den Benutzer als auch
an den CS LAN senden.
Die Fragestellung entspricht der im zuvor beschriebenen Szenario.
3.3.3 Buffer Overflow
Über die Hälfte aller kritischen Sicherheitslücken in Software beruhen inzwischen auf einem Pufferüberlauf (engl.: buffer overflow) [VM01]. Bill Gates titulierte diesen Angriffstyp
gar als "attack of the decade" (engl., „Angriff des Jahrzehnts“).
Es existieren zwei Varianten des Buffer Overflows. Die einfachere und ältere ist der Stack
Overflow [One96]. Die ersten Angriffe, die einen Stack Overflow ausnutzten, fanden bereits
1988 statt [KPSS01]. Heutzutage sind die etwas komplizierteren Heap Overflows verbreiteter
[Lin06].
Das Grundprinzip ist jedoch bei allen Pufferüberläufen gleich: Durch ein „unglückliches
Zusammenspiel von schlechten Programmiersprachen und schlechter Programmierung“
[Fre05] können mehr Daten in einen Puffer geschrieben werden, als der zugehörige Speicherbereich eigentlich fassen kann. Dadurch werden Informationen im nachfolgenden Speicherbereich überschrieben. Da dieser Speicherbereich nicht notwendigerweise auch für Daten vorgesehen ist, sondern beispielsweise eine Rücksprungadresse enthalten kann, führen
solche Fehler häufig zu Sicherheitslöchern.
Eine ausführliche Beschreibung von Buffer Overflows würde den Rahmen dieser Arbeit
sprengen. Für weitere Informationen zum Thema Buffer Overflows sei daher an die in diesem Abschnitt bereits erwähnte Literatur verwiesen.
Im vorliegenden Fall des Cryptographic Services Interface (CSI) und der mit dieser API
angesprochenen Module im CryptoServerr sind, wie in Abschnitt 1.2.1 erläutert, keine
Quelltexte verfügbar. Dies erschwert eine manuelle Suche nach potentiellen Buffer Overflows erheblich.
Aus diesem Grund soll hierfür das sogenannte Fuzzing (auch: Fuzz testing) angewandt werden. "Fuzzing is the art of automatic bug finding" [Spr05], also die Kunst, automatisch Sicherheitslücken aufzudecken. Dazu bedient es sich einer Variante der in Abschnitt 2.2.2
beschriebenen Fehlerfall-Analyse, der fault injection: Durch das automatisierte Variieren
der Eingabeparameter der zu testenden Funktion wird versucht, Sicherheitslücken aufzudecken [Jur06].
36
3 Angriffe
3.3.4 Lunchtime Attack
Die Authentifikation der Benutzer gegenüber dem CSI kann per Passwort oder RSA Signatur erfolgen. Bevorzugt wird dabei die RSA Signatur verwendet. Zur Berechnung der
Signatur ist ein privater RSA Schlüssel erforderlich für dessen Geheimhaltung der jeweilige
Benutzer respektive die den Schlüssel verwendende Anwendung verantwortlich ist.
Hieraus entstehen verschiedene Probleme: Benutzer sind häufig nicht ausreichend auf die
Wichtigkeit der Geheimhaltung solcher privater Schlüssel sensibilisiert. Anstatt auf spezialisierte Speichermodule – wie z.B. USB-Token – werden die Schlüssel oft einfach auf der
Festplatte des eigenen PCs gespeichert.
Zur Berechnung der für die Authentifikation benötigten Signatur muss die Anwendung
(bzw. API) den privaten Schlüssel in den Arbeitsspeicher laden – dies geschieht in der Regel
im Klartext.
Die meisten Benutzer lassen ihre PCs (beispielsweise) während der Mittagspause eingeschaltet. Häufig werden sie während dessen nicht einmal gesperrt. Ein Angreifer könnte
sich also während dieser Zeit physikalischen Zugang zu einem solchen PC verschaffen –
etwa als Techniker „verkleidet“ ist dies in vielen Unternehmen leicht möglich.
Die zu klärende Frage lautet nun: Ist es in der kurzen, dem Angreifer zur Verfügung stehenden, Zeit möglich, den privaten Schlüssel in einer möglicherweise großen Menge von
Daten – auf der Festplatte oder im Arbeitsspeicher – zu lokalisieren und zu extrahieren?
Dieser Angriff basiert auf einer Idee aus dem Artikel „Playing hide and seek with stored
keys“ von Adi Shamir und Nicko van Someren [SS99].
3.4 Zusammenfassung
In diesem Kapitel wurden bekannte und neue Angriffe auf Hardware-Sicherheitsmodule
vorgestellt.
Die in Abschnitt 3.2 beschriebenen bekannten Angriffe wurden zudem auf ihre Anwendbarkeit auf den CryptoServerr untersucht. Dabei wurde zwischen der Anwendbarkeit eines Angriffs auf die Schlüsselverwaltung (key management, KM) des CryptoServersr und
der Anwendbarkeit eines Angriffs auf das Cryptographic Services Interface (CSI) unterschieden.
Die Entwicklung neuer Angriffe war nötig, da sich das CSI stark von anderen SecurityAPIs unterscheidet und viele der bekannten Angriffe hier daher nicht anwendbar sind.
Diese neuen Angriffe wurden in Abschnitt 3.3 ausführlich beschrieben.
37
3 Angriffe
Tabelle 3.1 gibt einen Überblick über die Anwendbarkeit der bekannten Angriffe. Dabei
besagt +, dass ein Angriff angewandt werden kann, ein - zeigt an, dass er nicht angewendet
werden kann. Die neuen Angriff sind allesamt auf das CSI anwendbar, da sie speziell an
Type System Attack
Meet-in-the-Middle Attack
Key Conjuring Attack
3DES Key Binding Attack
Related Keys Attack
Bond’s Check Value Attack
Key Import Attack
Import/Export Loop Attack
Combined Attack
Exhaustive Key Search
Differential Protocol Analysis
Timing Attacks
Dual Security Officer Attack
M-of-N Security Officer Attack
Known Keys in the System
Anwendbar
auf:
CSI
KM
XOR to Null Attack
dessen Eigenheiten angepasst wurden.
+
+
-
+
-
-
-
-
-
+
-
-
-
+
+
+
+
+
-
-
+
+
+
Tabelle 3.1: Übersicht: Anwendbarkeit allgemeiner Angriffe
Obwohl theoretisch anwendbar, werden die XOR to Null Attack und die M-of-N Security
Officer Attack nicht weiter untersucht. Diese erfordern physischen Zugang zum CryptoServerr , was in dem hier untersuchten Szenario aber ausgeschlossen wurde (vgl. Abschnitt
1.2.2). Die Exhaustive Key Search wird ebenfalls nicht genauer untersucht, da es sich hierbei um eine einfache Brute-Force-Suche handelt und diese bei der im CryptoServerr fast
ausschließlich verwendeten Schlüssellänge von mindestens 112 Bit praktisch unmöglich
ist.
Die übrigen anwendbaren bekannten sowie die neu entwickelten Angriffe werden im nächsten Kapitel nun weitergehend in Bezug auf die von Ihnen ausgehende Gefahr für den
CryptoServerr analysiert.
38
4.1 Einleitung
Dieses Kapitel befasst sich mit der Analyse des CryptoServersr . Untersucht werden die im
vorangegangenen Kapitel beschriebenen Szenarien, sofern diese auf den CryptoServerr
anwendbar sind.
Die Gliederung orientiert sich dabei an der von Kapitel 3. Somit werden zunächst die Ergebnisse zur Untersuchung der bekannten Angriffe vorgestellt (Abschnitt 4.2). Anschließend
werden die neu entwickelten Angriffsszenarien analysiert (Abschnitt 4.3).
Erfolgreich war der in Abschnitt 4.3.2 diskutierte Man-in-the-Middle Angriff, sowie – mit
Einschränkungen – die Meet-in-the-Middle Attack (Abschnitt 4.2.2) und die Key Import
Attack (Abschnitt 4.2.3).
4.2 Bekannte Angriffe
In diesem Abschnitt dokumentiere ich die Ergebnisse der Untersuchung des CryptoServersr bzgl. der in Abschnitt 3.2 beschriebenen und auf den CS bzw. das CSI anwendbaren
Angriffe (vgl. [Sch07]).
Für alle diese Angriffe – ob erfolgreich oder nicht – gilt eine Einschränkung. Das CSI verfügt über eine Zugangskontrolle, über die jedes einzelne Kommando abgesichert wird. Die
folgenden Untersuchungen nehmen an, dass diese Zugangskontrolle bereits überwunden
wurde. Ohne diese Annahme wäre keiner der Angriffe erfolgreich durchführbar.
4.2.1 Type System/Key Separation Attack
Wie im vorherigen Kapitel erläutert, ist dieser Angriff ausschließlich auf das CSI anwendbar. Innerhalb des CSI müssen alle Funktionen untersucht werden, bei denen der Typ eines
verwendeten Schlüssels sicherheitsrelevant ist. Im einzelnen sind dies die folgenden Funktionen:
39
1. Wrap Key: cs_wrap_key()
2. Unwrap Key: cs_unwrap_key()
3. DES Encryption in ECB Mode: cs_DEScryptECB()
4. DES Encryption in CBC Mode: cs_DEScryptCBC()
5. AES Encryption in ECB Mode: cs_AEScryptECB()
6. AES Encryption in CBC Mode: cs_AEScryptCBC()
7. DES MAC Calculation: cs_DEScalc_mac()
8. AES MAC Calculation: cs_AEScalc_mac()
9. Sign Data with RSA: cs_RSAsign()
10. Verify RSA Signature: cs_RSAverify()
11. Sign Data with ECDSA: cs_ECDSAsign()
12. Verify ECDSA Signature: cs_ECDSAverify()
Die in den ersten beiden Funktionen zur Verschlüsselung benutzen Schlüssel müssen vom
Typ KEK, die verschlüsselten Schlüssel müssen als exportierbar markiert sein. Die in den
übrigen Funktionen verwendeten Schlüssel dürfen dagegen nicht vom Typ KEK sein.
Ergebnisse
Die Funktionen cs_wrap_key() und cs_unwrap_key() akzeptieren zum Verschlüsseln
ausschließlich Schlüssel vom Typ KEK. Exportiert werden außerdem nur Schlüssel, die als
exportierbar markiert sind.
Die symmetrischen Funktionen cs_DEScryptECB() und cs_DEScryptCBC() akzeptieren ausschließlich DES-Schlüssel, die nicht vom Typ KEK sind. Auch die Funktionen
cs_AEScryptECB() und cs_AEScryptCBC() arbeiten nur mit AES-Schlüsseln, welche
nicht vom Typ KEK sind. Die Funktionen cs_DEScalc_mac() bzw. cs_AEScalc_mac()
akzeptieren nur reine DES- bzw. AES-Datenschlüssel.
Die asymmetrischen Funktionen cs_RSAsign() und cs_RSAverify(), beziehungsweise cs_ECDSAsign() und cs_ECDSAverify() arbeiten ausschließlich mit RSA- beziehungsweise ECDSA-Schlüsseln, welche nicht vom Typ KEK sind.
Das CSI überprüft also grundsätzlich penibel den Typ und Algorithmus eines jeden Schlüssels. Es ist damit gegen die Type System/Key Separation Attack immun.
40
4.2.2 Meet-in-the-Middle Attack
Der CryptoServerr kann intern über 50.000 3DES-Schlüssel speichern [Uti05]. Da diese
Schlüssel mindestens die doppelte Länge von einfachen DES-Schlüsseln aufweisen, muss
der interne Speicher für mindestens 100.000 einfache DES-Schlüssel ausreichen. Zum Knakken eines einfachen DES-Schlüssels mit Hilfe der Meet-in-the-Middle Attack ist es erforderlich 216 = 65.536 DES-Schlüssel zu erzeugen. Dies ist im CryptoServerr problemlos möglich. Außerdem können über das CSI Message Authentication Codes berechnet werden,
welche die Hash-Werte aus dem originalen Angriff von Bond [Bon04] ersetzen können.
Das CSI des CryptoServersr ist somit anfällig für die Meet-in-the-Middle Attack. In leicht
abgewandelter Form kann sie problemlos angewandt werden.
4.2.3 Key Import Attack
Der Schlüssel mit der ID 2222 1124 ist ein exportierbarer KEK (siehe Anhang A). Mit
Hilfe der Funktion cs_wrap_key() kann dieser Schüssel exportiert werden (z.B. nach
d:\temp\kek.wrap). Die Funktion cs_unwrap_key() verlangt schließlich den Typ des
zu importierenden Schlüssel als Parameter. Hier kann nun problemlos auch ein anderer
als der ursprüngliche Typ angegeben werden. Im Beispiel wurde der exportierte Schlüssel
unter der ID 2222 2222 erneut als exportierbarer Datenschlüssel importiert.
Ab sofort kann jeder unter dem KEK mit der ID 2222 1124 exportierte Schlüssel mit Hilfe
des Schlüssels mit der ID 2222 2222 entschlüsselt werden. Für diesen Angriff ist das CSI
somit anfällig.
4.2.4 Differential Protocol Analysis
Die im Kapitel 3.3.3 beschriebene Methode des Fuzzings bedient sich einer Variante der
Differential Protocol Analysis. Daher soll letztere an dieser Stelle nicht gesondert betrachtet
werden. Es sei stattdessen auf Abschnitt 4.3.3 verwiesen.
Zur Anfälligkeit des CSI und des CryptoServersr selbst für diesen Angriffstyp kann an
dieser Stelle daher noch keine Aussage gemacht werden.
4.2.5 Timing Attacks
Dieser Seitenkanalangriff wurde nicht näher untersucht, da dies den Rahmen der Diplomarbeit gesprengt hätte.
41
4.2.6 Known Keys in the System
Welchen Nutzen kann ein Angreifer aus einem ihm bekannten Schlüssel im CryptoServerr
ziehen? Diese Frage lässt sich nicht generell beantworten, sondern hängt von der Art des
Schlüssels ab, den der Angreifer kennt. Es sind drei Fälle zu unterscheiden:
Der Angreifer kennt...
a) einen Datenschlüssel
b) einen Key Encryption Key (KEK)
c) den Master Box Key (MBK)
Diese drei Fälle werden im Folgenden separat untersucht.
Bekannter Datenschlüssel
Ein bekannter Datenschlüssel ist zunächst einmal – verglichen mit anderen Schlüsseltypen
– am wenigsten problematisch. Je nachdem ob es sich bei dem bekannten Schlüssel um
einen symmetrischen oder asymmetrischen Schlüssel handelt, können mit diesem Schlüssel
zwar verschlüsselte Daten dechiffriert oder digitale Signaturen gefälscht werden.
Allerdings ist dieses Problem nach Bekanntwerden dieses Missstandes relativ einfach und
schnell zu beheben. Es genügt, den kompromittierten Schlüssel zu löschen und durch einen
neuen Schlüssel zu ersetzen. (Zusätzlich sollten natürlich Nachforschungen betrieben werden, um herauszufinden, wie der Schlüssel überhaupt kompromittiert werden konnte. Anschließend sollten entsprechende Gegenmaßnahmen eingeleitet werden.)
Ernster wird die Lage, falls der kompromittierte Schlüssel exportiert werden kann und die
verwendete Security-API, wie das CSI, anfällig für die in Kapitel 3.2.2 beschriebene Key
Import Attack ist. In diesem Fall ist es dem Angreifer möglich einen bekannten KEK zu
erhalten. In diesem Fall gelten alle der im folgenden Abschnitt beschriebenen Erkenntnisse
analog.
Bekannter Key Encryption Key
Ein bekannter Key Encryption Key (häufig auch EXPORTER genannt) unterminiert die Sicherheit aller als exportierbar markierten Schlüssel im CryptoServerr .
42
Als erste Gegenmaßnahme müssen alle als exportierbar markierten Schlüssel einschließlich des kompromittierten Key Encryption Keys ausgetauscht werden. Außerdem sind natürlich auch die im vorherigen Abschnitt beschriebenen zusätzlichen Maßnahmen höchst
ratsam, um einen erneuten Angriff nach dem gleichen Schema abwehren zu können.
Bekannter Master Box Key
Der Master Box Key, ein symmetrischer Schlüssel mit einer Länge von 24 Bytes (3DES oder
AES), ist eine Besonderheit des CryptoServersr und hat zwei verschiedene Anwendungsgebiete. Zum einen kann er innerhalb des CSI als Key Encryption Key zum Sichern und
Wiederherstellen sämtlicher vom CSI benutzter Schlüssel dienen. Zum anderen kann er,
völlig unabhängig vom CSI, zum vollständigen Sichern der Benutzerdatenbank des CryptoServersr verwendet werden.
Eine weitere Besonderheit dieses Schlüssels ist, dass er nicht im CryptoServerr selbst, sondern in einem an diesen angeschlossenen Pinpad erzeugt und verteilt auf zwei Smartcards
gespeichert wird. Anschließend kann er von diesen beiden Smartcards in den CryptoServerr geladen werden. Der Vorteil dieser Methode ist, dass er problemlos auch in weitere CryptoServerr geladen werden kann, was den Schlüssel- und Benutzerkontenaustausch
zwischen verschiedenen Modulen ermöglicht.
Eine Kompromittierung dieses Schlüssels birgt daher noch größere Risiken, als das Bekanntwerden eines „normalen“ KEK. Neben den als exportierbar markierten Schlüsseln
ist hier auch die Benutzerdatenbank gefährdet – ggf. sind sogar mehrere CryptoServerr
auf einmal kompromittiert. Unter Benutzung der mit Version 1.2.3 des CSI [BH06b] eingeführten Backup-Funktion können mit Hilfe des MBK sogar nicht als exportierbar markierte
Schlüssel gesichert werden. Eine vollständige Neu-Initialisierung der betroffenen Module
ist in diesem Fall ratsam.
4.3 Neue Angriffsszenarien
Dieser Abschnitt widmet sich der Analyse der selbst entwickelten Angriffsszenarien, welche in Abschnitt 3.3 vorgestellt wurden.
4.3.1 Session Hijacking
Wie der Aufbau einer Session auf API-Ebene abläuft ist bereits in Abschnitt 3.3.1 beschrieben. Für den Angriff auf diesen Verbindungsaufbau wichtiger und interessanter ist aber,
43
welche Informationen dabei auf der Byteebene zwischen Host und CryptoServerr ausgetauscht werden.
So werden beispielsweise beim Laden der Module des CSAPI (Schritte 2.-4.) überhaupt
keine Informationen ausgetauscht. Die Authentifizierung sowie der eigentliche Aufbau der
Session erfolgen erst durch einen der Befehle cs_login_pwd() bzw. cs_login_sign().
Dazu werden (unter der Annahme, dass kein Fehler auftritt) insgesamt vier TCP-Datenpakete ausgetauscht.
Aufbau einer Session
Zunächst schickt der Host eine Challenge-Anfrage (GetChallenge) an den CryptoServerr
(Abbildung 4.1).
ACH
00 00 08H
02H
00 00 00H
1 Byte
3 Bytes
1 Byte
3 Bytes
Abbildung 4.1: GetChallenge
Daraufhin erhält er die 8 Byte lange Challenge zusammen mit einer diese eindeutig kennzeichnenden ID zurückgeschickt (Abbildung 4.2).
AAH
00 00 10H
02H
CH-ID
00 00H
Challenge
1 Byte
3 Bytes
1 Byte
1 Byte
2 Bytes
8 Bytes
Abbildung 4.2: ChallengeResponse
Im zweiten Schritt sendet der Host den Namen des zu authentisierenden Nutzers, die ID
der Challenge, einen Hash über die letzten Length2 Bytes des Datenpakets konkateniert
mit der empfangenen Challenge und dem Passwort des Benutzers, sowie seinen Wert aus
der ersten Phase des Diffie-Hellman-Schlüsselaustausches [DH76, RSA93] an den CS (Abbildung 4.3).
ACH
Length1
01H
user
00H
CH-ID
00 14H
hash
00 00 00H
1 Byte
3 Bytes
1 Byte
8 Bytes
1 Byte
1 Byte
2 Bytes
20 Bytes
3 Bytes
···
9CH
Length2
00 83H
0AH
00H
03 01 04H
dh_y_host
1 Byte
3 Bytes
2 Bytes
1 Byte
1 Byte
3 Bytes
(Length2 - 11) Bytes
···
mit
hash
20 Bytes
:=
SHA-1(
9CH
···
dh_y_host
Challenge
password
1 Byte
···
8 Bytes
16 Bytes
Abbildung 4.3: GetSessionKey (SHA-1-Passwort)
44
)
Der CryptoServerr antwortet mit der Session-ID, der ersten Sequenz-Nummer der Session
und seinem Wert aus der ersten Phase des Diffie-Hellman-Protokolls (Abbildung 4.4).
9AH
Length
ID
seq_nr
dh_y_cs
1 Byte
3 Bytes
2 Bytes
16 Bytes
(Length - 22) Bytes
Abbildung 4.4: Session Information
In der zweiten Phase des Diffie-Hellman-Protokolls berechnen Host und CS nun – unabhängig von einander – den gemeinsamen geheimen Schlüssel K aus dem eigenen geheimen
(x bzw. y) und dem vom jeweils anderen erhaltenen öffentlichen Wert (gy bzw. g x ):
K := ( g x )y = g xy = gyx = ( gy ) x mit Diffie-Hellman-Parameter g
Neben der Authentisierung mittels Passwort unterstützt das CSI auch die Authentisierung
mittels RSA-Signatur. In diesem Fall unterscheidet sich das dritte Datenpaket minimal von
dem in Abbildung 4.3 dargestellten. Anstelle des Hash-Werts wird die Signatur über die
Konkatenation der letzten Length2 Bytes des Pakets mit der Challenge gesendet (Abbildung 4.5).
ACH
Length1
01H
user
00H
CH-ID
ksize
signature
00 00 00H
1 Byte
3 Bytes
1 Byte
8 Bytes
1 Byte
1 Byte
2 Bytes
ksize Bytes
3 Bytes
···
9CH
Length2
00 83H
0AH
00H
03 01 04H
dh_y_host
1 Byte
3 Bytes
2 Bytes
1 Byte
1 Byte
3 Bytes
···
Abbildung 4.5: GetSessionKey (RSA Signatur)
Übertragen von Befehlen und Daten
Alle folgenden Kommandos an den CryptoServerr , die kryptografische Dienste anfordern,
werden von nun an ausschließlich verschlüsselt übertragen (Abbildung 4.6). Dabei wird
der zuvor im Rahmen des Diffie-Hellman-Protokolls berechnete Schlüssel K verwendet.
ECH
Length
ID
01 00H
MAC
filler
Enc. Command Data
1 Byte
3 Bytes
2 Bytes
2 Bytes
8 Bytes
lf Bytes
n Bytes
mit lf=8-lp, wobei
Enc. Command Data
MAC
n Bytes
8 Bytes
:=
eK (
Pad
Command Data
00H . . . 00H
lp Bytes
m Bytes
8 Bytes
)
mit lp, so dass n=(lp+m) ein Vielfaches von 8 ist.
Abbildung 4.6: Secure Messaging: Anweisung
45
Die Antworten auf solche Befehle werden ebenfalls verschlüsselt übermittelt (Abbildung
4.7). Verschlüsselung und Berechnung der MAC erfolgen analog zu Abbildung 4.6.
EAH
Length
ID
01 00H
MAC
filler
Enc. Answer Data
1 Byte
3 Bytes
2 Bytes
2 Bytes
8 Bytes
lf Bytes
n Bytes
Abbildung 4.7: Secure Messaging: Antwort
Angriffsmöglichkeiten
Belauscht der Angreifer den Netzwerkverkehr zwischen Host und CryptoServerr während des Aufbaus der Sitzung, so kennt er zwar die ID der Session und die erste Sequenznummer (aus der er die aktuelle Sequenznummer berechnen kann). Um übertragene Befehle und Daten verstehen und eigene Befehle und Daten an den CryptoServerr senden zu
können, benötigt er aber außerdem den Schlüssel K der Sitzung (engl.: session key).
An diesen Schlüssel gelangt der Angreifer aber nur, wenn es ihm gelingt das Diffie-Hellman-Protokoll zu kompromittieren. Bei nicht ausreichend sorgsamer Implementierung des
Diffie-Hellman-Protokolls, ist dies nach [RS00] durchaus möglich. Allerdings ist es nach
Raymond et al. in den meisten Szenarien ebenso möglich den Angriff zu verhindern.
Möglich ist eine Kompromittierung beispielsweise dann, wenn einer der Werte dh_y_host
und dh_y_cs aus der ersten Phase des Diffie-Hellman-Protokolls 1 ist. Sei dh_y_host = g x
und dh_y_cs = g x mit geheimen Werten x und y, dann gilt mit g x = 1 und y beliebig:
( g x ) y = 1y = 1
Für gy = 1 und x beliebig gilt dies analog.
Der Angreifer selbst kann im hier betrachteten Szenario keine zwischen dem Host und dem
CryptoServerr ausgetauschten Datenpakete löschen oder ändern. Er kann diese Pakete
nur mitlesen und muss daher darauf hoffen, dass einer der beiden oben genannten Werte
zufällig 1 ist. Aufgrund der vom CSI verwendeten Länge für diese Werte von 128 Bit ist
dies jedoch hinreichend unwahrscheinlich.
Eine Kompromittierung des hier eingesetzten Diffie-Hellman-Protokolls ist also durch reines Mithören nicht möglich. Somit ist auch die Übernahme der Session ebenso wenig möglich, wie das parallele Nutzen dieser Session. Das hier erprobte Session hijacking ist somit
nicht erfolgreich.
46
Wie in Abschnitt 3.3.2 beschrieben, erhält der Angreifer in diesem Szenario – verglichen
mit dem zuvor beschriebenen – nun zusätzlich die Fähigkeit, zwischen dem Host und dem
CryptoServerr ausgetauschte Datenpakete zu löschen und zu verändern.
Das bedeutet, dass der Angreifer beispielsweise einen oder beide der DiffieHellman-Werte
dh_y_host und dh_y_cs austauschen kann. Insbesondere kann er diese durch den Wert
1 ersetzten.
Angriff 1
Der Wert dh_y_host kann mit Hilfe entsprechender Tools (hier kam der Winsock Packet
Editor Pro [Bra] zum Einsatz) durch 1 ersetzt werden. Aufgrund der Absicherung der Integrität dieses Wertes mittels Hash-Wert (in dem unter anderem auch das – dem Angreifer
nicht bekannte – Passwort des Nutzers eingeflochten ist, vgl. Abbildung 4.3) bemerkt der
CryptoServerr diese Manipulation jedoch sofort. Die Verbindung mit dem Host wird daraufhin mit dem Fehlercode 0xB0830013 („authentication failed“) beendet. Der Angriff ist
nicht erfolgreich.
Angriff 2
Für den vom CryptoServerr kommenden Wert dh_y_cs ist dieser Angriff dagegen – zumindest teilweise – erfolgreich. Das CSI überprüft den ankommenden Wert nicht wie in
[RS00] empfohlen und setzt daraufhin den aktuellen Session key auf 1. Die Kommunikation mit dem CryptoServerr funktioniert allerdings auch in diesem Fall nicht, da der CS
mit dem korrekten Session key verschlüsselte Kommandos erwartet. Aus seiner Sicht ist
das Diffie-Hellman-Protokoll ja unverändert abgelaufen. Er weist daher alle (aus seiner
Sicht) falsch verschlüsselt ankommenden Befehle mit dem Fehlercode 0xB0830021 („secure messaging failed“) ab.
Einen kleinen Nutzen kann der Angreifer aber trotzdem aus diesem Angriff ziehen: Wenn
er verhindert, dass nachfolgende Pakete vom Host den CryptoServerr erreichen und er
selbst statt dessen mit einem gültigen Fehlercode [Uti06a] antwortet, kann er unter Umständen eigentlich für den CS gedachte Informationen mitlesen.
Sicherheitskritisch ist dies insbesondere dann, wenn der Benutzer mit dem Kommando
cs_import_key() einen neuen Schlüssel im Klartext importieren will. Der Angreifer
fängt das erste Paket ab, schickt dem Host den Fehlercode 0xB0830024 („internal buffer
overflow“) zurück und beendet abschließend die Verbindung. Unternimmt der Benutzer
47
anschließend einen zweiten Versuch, lässt der Angreifer alle Pakete unverändert passieren und erhält so einen bekannten Schüssel im CryptoServerr . Die daraus resultierenden
Gefahren wurden bereits in Abschnitt 4.2.6 diskutiert.
Die Session selbst kann auch als „man in the middle“ nicht vollständig übernommen werden. Dem Host kann jedoch ein bekannter Schlüssel untergeschoben werden. Dieser Angriff ist damit teilweise erfolgreich.
Gegenmaßnahmen
Als erste Gegenmaßnahme müssen, wie in [RS00] empfohlen, die im Rahmen des DiffieHellman-Protokolls ausgetauschten Nachrichten vom CSI auf ungewöhnliche Werte überprüft werden. Insbesondere darf weder dh_y_host noch dh_y_cs noch K den Wert 1
haben. Weiterhin müssen sowohl dh_y_host als auch dh_y_cs kleiner p − 1 und größer
als 1 sein (2 ≤ g ≤ p − 2). Dies ist wichtig, da im Diffie-Hellman-Protokoll grundsätzlich
modulo p gerechnet wird. Alle gα·( p−1)· x und alle gα·( p−1)·y mit α ≥ 1 sind damit äquivalent
zu 1 modulo p (mit g x = dh_y_host und gy = dh_y_cs).
Als zweite Möglichkeit kann zusätzlich auch der vom CryptoServerr kommende Wert
dh_y_cs kryptografisch abgesichert werden. Im Falle der Authentifikation mittels Passwort kann ein Hash-Wert über dh_y_cs und das Passwort (respektive dessen Hash-Wert)
berechnet werden. Findet die Authentifikation via RSA-Signatur statt, kann der CryptoServerr seinen Wert dh_y_cs verschlüsselt übermitteln – der öffentliche Schlüssel des
Nutzers ist ihm bekannt und darf in diesem Fall auch ausschließlich ihm und dem Nutzer
bekannt sein.
4.3.3 Buffer Overflow
Wie in Abschnitt 3.3.3 erläutert, soll zur Untersuchung des CSI auf mögliche Buffer Overflows die Technik des Fuzzings angewendet werden.
Es macht dabei wenig Sinn, die Funktionen des APIs selbst zu fuzzen. Denn diese werden zunächst lokal ausgewertet und in Bytefolgen umgewandelt, welche schließlich an den
CryptoServerr LAN geschickt werden. Das Ergebnis wäre daher mehr ein Test des lokal
laufenden Teils des API, als des – wesentlich interessanteren – Teils des CSI, welcher im
CryptoServerr selbst läuft.
Aus diesem Grund setzt die Analyse direkt auf der Ebene der Byteströme an: Es wird direkt
die Payload der an den CryptoServerr LAN gesendeten TCP-Pakete gefuzzt. Zu diesem
Zweck kamen zwei Tools zum Einsatz.
48
Analyse mit Taof
Den Anfang machte das in Python geschriebene Tool Taof – The art of fuzzing von Rodrigo
Marcos in der Version 0.3 [Mar07]. Dabei handelt es sich um einen generischen Fuzzer für
Netzwerkprotokolle. Der Fuzzing-Prozess verläuft hier in drei Phasen.
Die erste Phase dient der Datensammlung. Taof schaltet sich hier als eine Art Man-in-theMiddle in die Datenübertragung zwischen Host und Zielrechner (im vorliegenden Fall dem
CryptoServerr ) und protokolliert sämtliche übertragenen Daten. Dazu lauscht er auf einem benutzerdefinierten Port und leitet die Pakete nach der Protokollierung an das anzugebende Ziel weiter (vgl. Abbildung 4.8(a)). Bei jeder Protokollierung legt Taof für die
Protokolldateien einen neuen Ordner an, dessen Name den aktuellen Jahrestag sowie die
aktuelle Uhrzeit enthält.
(a) Netzwerk-Einstellungen
(b) Fuzzing-Positionen
Abbildung 4.8: Taof – The art of fuzzing
In der zweiten Phase präsentiert Taof sämtliche abgefangenen Pakete vom Host zum Zielrechner. Dabei zeigt er ausschließlich die Payload des Pakets an. Hier kann der Benutzer nun beliebige Bereiche markieren und für jeden einzelnen Bereich angeben, welche
Pufferüberlauf-Testfälle angewendet werden sollen (vgl. Abbildung 4.8(b)). Diese Angaben speichert Taof im XML-Format im jeweiligen Protokollordner, so dass diese wiederverwendbar sind. Anhang B zeigt die im Rahmen dieser Arbeit verwendete Konfiguration.
49
Zum Schluss ist nur noch ein Knopfdruck nötig, um dass Fuzzing selbst zu starten. Taof
spielt nun sämtliche intern gespeicherten Szenarien an den vom Benutzer festgelegten Positionen durch und protokolliert den gesamten Prozess, einschließlich der Antworten vom
Zielrechner, in einer einfachen Textdatei.
Zur einfacheren Analyse dieser Textdatei wurde ein eigenes Tool geschrieben, welches diese Datei in ein für Menschen leichter lesbares Format konvertiert.
Untersucht wurde der gesamte Prozess, der durchlaufen wird, wenn ein CSI-Befehl an den
CryptoServerr geschickt wird. Dieser Prozess besteht aus fünf TCP-Paketen in Richtung
des CryptoServersr :
1. Verbindungsaufbau
2. Anfordern einer Challenge
3. Authentifikation und Übermittlung des eigenen Diffie-Hellman Wertes
4. Senden des verschlüsselten Befehls
5. Beenden der Session
Die Konfiguration der Fuzz-Punkte entspricht denen in der in Anhang B dargestellten
XML-Datei.
Zur Auswertung der von Taof während des Fuzzens generierten Report-Datei kamen die
bereits erwähnte Eigenentwicklung sowie das Tool GREP for Windows (eine Portierung des
Unix-Tools GNU grep zur zeilenbasierten Textsuche und Textfilterung) von Tim Charron
[Cha01] zum Einsatz.
Ergebnis: Es wurden keine Sicherheitslücken gefunden.
Analyse mit CSI Fuzz
Als zweites kam eine CSI Fuzz getaufte Eigenentwicklung zum Einsatz. Diese Entwicklung
war notwendig, da im Laufe der Auswertung der von Taof generierten Report-Datei klar
wurde, dass der CryptoServerr die von Taof generierten Pakete nur bis zu der in den Bytes 2 bis 4 der Payload kodierten Längenangabe interpretiert hat. Der über diese Länge
hinausgehende Teil wurde schlicht verworfen und Taof selbst bot keine Möglichkeit diese
automatisch anzupassen.
Bei CSI Fuzz handelt es sich nun um ein in C geschriebenes Tool für Linux, welches dieses Manko behebt. Die zum Fuzzen benutzen Integer-, String- und Format-String-Listen
50
wurden dabei aus dem Taof-Quelltext übernommen. Zusätzlich enthält CSI Fuzz eine Liste zu überprüfender MACs. Bei den enthaltenen TCP-Routinen handelt es sich um leicht
angepasste Varianten der TCP-Bibliothek des Fuzzing-Tools SPIKE [Ait02, Ait].
CSI Fuzz ist konkret auf das Fuzzing des CSI der Utimaco spezialisiert und erwartet daher
als einzigen Parameter die IP-Adresse und optional den Port des anzugreifenden CryptoServersr .
Dazu wird zunächst eine gültige Session aufgebaut. Das eigentliche Fuzzing erfolgt dann
auf das TCP-Paket mit den eigentlichen (verschlüsselten) Anweisungen. Dabei wird zunächst die Session-ID verändert. In einem zweiten Schritt wird eine gültige Session-ID festgelegt und stattdessen der Message Authentication Code (MAC) gefuzzt. Abschließend
wird der Kommandoblock selbst gefuzzt, wobei dies mit verschiedenen MACs durchgespielt wird.
Bei der Auswertung der von CSI Fuzz generierten Report-Datei kam das im vorherigen
Abschnitt bereits erwähnte Tool GNU grep zum Einsatz. Zusätzlich wurde das Unix-Tool
GNU sed, ein Editor zur nicht-interaktiven Textbearbeitung, verwendet.
Ergebnis: Es wurden keine Sicherheitslücken gefunden.
4.3.4 Lunchtime Attack
Aus zeitlichen Gründen verweise ich an dieser Stelle nur auf die Arbeiten von Janssens et al.
[JBP+ 00, Jan00]. Hier wurde ein dem in Abschnitt 3.3.4 sehr ähnliches Szenario angenommen. Untersucht wurden der Apache SSL Server (Version 1.3.12) unter Linux, sowie der
Microsoft Internet Explorer (Version 5.01), Microsoft Outlook Express (Version 5.01), der
Netscape Navigator (Version 4.76) und der Netscape Messenger (Version 4.76) unter Microsoft Windows 2000. Außerdem wurde das Windows 2000 Encrypted File System (EFS)
untersucht. In allen Fällen war es möglich, die von diesen Anwendungen verwendeten privaten Schlüssel (es wurden nur RSA-Schlüssel untersucht) im Hauptspeicher des Rechners
oder der Windows-Auslagerungsdatei (Swap-File) in kurzer Zeit zu lokalisieren.
Die privaten Signatur-Schlüssel, die vom CSI verwendet werden, wurden zwar nicht explizit untersucht. Da es sich aber auch hierbei um RSA-Schlüssel handelt, ist die Wahrscheinlichkeit groß, dass sich die Ergebnisse aus [JBP+ 00] direkt auf diesen Fall übertragen
lassen.
51
4.4 Zusammenfassung
In diesem Kapitel wurde der CryptoServerr in Bezug auf die in Kapitel 3 beschriebenen
und auf den CS anwendbaren Angriffe analysiert. Nicht genauer untersucht wurden dabei die Timing Attacks und die Lunchtime Attack, da dies den Rahmen der Diplomarbeit
gesprengt hätte.
Der Schwerpunkt lag stattdessen auf der Analyse des Session Hijackings, des Man-in-theMiddle Angriffs und der Buffer overflows. Erfolgreich war hier ausschließlich der Man-inthe-Middle Angriff.
Außerdem wurden die Type System/Key Separation Attack, die Meet-in-the-Middle Attack und die Key Import Attack unter die Lupe genommen. Die beiden zuletzt genannten
Angriffe sind dabei erfolgreich – allerdings nur unter der Voraussetzung, dass die beim CSI
zwingend erforderliche Authentisierung bereits umgangen wurde.
Auch die Frage, welchen Nutzen ein Angreifer aus einem ihm bekannten Schlüssel im
CryptoServerr ziehen kann, wurde in diesem Kapitel beantwortet.
Das nächste und letzte Kapitel fasst die in dieser Arbeit gewonnenen Erkenntnisse zusammen und schließt mit einem Ausblick auf weiterführende Arbeiten.
52
5.1 Aufgabenstellung
Im Rahmen der Diplomarbeit wurde der SafeGuard CryptoServerr der Utimaco Safeware AG auf seine Eignung als SecurityServer in unsicheren Netzen untersucht. Dazu wurde
das Cryptographic Services Interface (CSI), das proprietäre Security-API der Utimaco, einer ausführlichen Sicherheitsüberprüfung unterzogen. Die Untersuchung war als reiner
Blackbox-Test ausgelegt und erfolgte ausschließlich per Fernzugriff (engl.: remote access)
auf das Untersuchungsobjekt, da ein solches Szenario die Möglichkeiten eines potentiellen
Angreifers in einem unsicheren Netz bestmöglich nachbildet.
5.2 Ergebnisse
In einem ersten Schritt wurden zunächst die in den vergangenen Jahren von Bond und
Clulow entwickelten Angriffe zusammengestellt und deren Anwendbarkeit auf das CSI
überprüft (Abschnitt 3.2). Dabei wurde schnell klar, dass ein Großteil dieser Angriffe ausschließlich auf solche APIs anwendbar ist, die über explizite Funktionen für Finanztransaktionen verfügen. Das CSI verfügt jedoch nicht über solche Funktionen. Außerdem deckten
diese Angriffe nicht die Besonderheiten des CSI beim Verbindungsaufbau sowie der Benutzerauthentifizierung ab. Daher wurden die vier neuen Angriffsszenarien Session Hijacking,
Man-in-the-Middle, Buffer Overflow und Lunchtime Attack entwickelt (Abschnitt 3.3).
Die von Bond und Clulow entwickelten Angriffe setzen voraus, dass zur Benutzung der
anzugreifenden Security-API keine Benutzerauthentifizierung erforderlich ist. Daher konnten
diese Angriffe nur unter der Annahme analysiert werden, dass diese Authentifizierung
bereits erfolgreich umgangen wurde. Der CryptoServerr ist in diesem Fall verwundbar für
die Meet-in-the-Middle Attack (Abschnitt 4.2.2) und die Key Import Attack (Abschnitt 4.2.3).
Allerdings hat der Angreifer unter diesen Voraussetzungen ohnehin die volle Kontrolle
über das CSI. Der Erfolg dieser Angriffe ist daher in der Praxis ohne Bedeutung.
53
An der Benutzerauthentifizierung selbst sowie an dem gesamten Prozess des Verbindungsaufbaus setzten die neuen Angriffsszenarien an. Erfolgreich war hier nur der Man-in-theMiddle Angriff. Das Session Hijacking und die Suche nach Buffer Overflows waren dagegen nicht erfolgreich.
Die Lunchtime Attack wurde nicht näher untersucht, da dies den Rahmen der Diplomarbeit
gesprengt hätte. Die Ergebnisse einer anderen Arbeit, in der ein sehr ähnliches Szenario
untersucht wurde, legen jedoch nahe, dass dieser Angriff durchaus erfolgsversprechend ist
(Abschnitt 4.3.4).
Zu den erfolgreichen neuen Angriffsszenarien, und damit nur im Hinblick auf den Manin-the-Middle Angriff, wurden Gegenmaßnahmen aufgezeigt. In Bezug auf die von Bond
und Clulow entwickelten Angriffe war dies nicht notwendig, da die zur Verwendung des
Cryptographic Services Interfaces zwingend erforderliche Benutzerauthentifizierung hier
bereits einen ausreichenden Schutz bietet.
Sobald die empfohlenen Gegenmaßnahmen zur Verhinderung des Man-in-the-Middle Angriffs implementiert wurden und ggf. sichergestellt wird, dass die Lunchtime Attack nicht
erfolgreich ist, ist der SafeGuard CryptoServerr für den Einsatz als SecurityServer in unsicheren Netzen geeignet.
Wünschenswert ist aus Sicht des Autors allerdings eine Erweiterung der Benutzerverwaltung des CSI dahin gehend, dass verschiedene Benutzergruppen mit unterschiedlichen
Rechten unterstützt werden. In der derzeitigen Version des CSI haben alle Benutzer die
gleichen, und zwar alle, Rechte. Jeder Benutzer kann so zum Beispiel Schlüssel exportieren
und importieren. Das Typensystem des CSI wird damit, unter Berücksichtigung der Key
Import Attack, teilweise hinfällig und schützt allenfalls vor versehentlichen Fehlern.
Betrachten wir beispielsweise eine Policy, welche eine strikte Trennung zwischen den Personen, die kryptografische Schlüssel verwalten, und denen, die mit Hilfe dieser Schlüssel
Signaturen erzeugen, fordert. Eine solche Policy ist zum Beispiel in Zertifizierungsstellen
(engl.: certification authority, CA) durchaus denkbar. Im CSI ist sie derzeit aber nicht umsetzbar.
5.3 Schwierigkeiten
Zu Beginn der Literaturrecherche entdeckte der Autor schnell die ausführlichen und in dieser Arbeit viel zitierten Arbeiten von Bond (insbesondere [Bon04]) und Clulow (insbesondere [Clu03a]). Mit fortschreitender Analyse kristallisierte sich jedoch heraus, das viele der
54
dort beschriebenen Angriff – entgegen erster Erwartungen – nicht auf den CryptoServerr
anwendbar sind (siehe auch Abschnitt 5.2).
Die Schwierigkeiten beim Man-in-the-Middle Angriff waren hauptsächlich technischer Natur. Das Problem war hier, ein Möglichkeit zu finden, TCP-Pakete abfangen und während
der Übertragung (engl.: on-the-fly) ändern zu können. Nachdem mit dem Winsock Packet
Editor Pro [Bra] ein entsprechendes Tools aufgetan worden war, vereinfachte sich dieser
Prozess erheblich.
Sehr zeitaufwendig war die Analyse der Buffer overflows mittels Fuzzing. Es existiert inzwischen zwar eine Vielzahl von Tools und Frameworks zum Fuzzen verschiedenster Software (vgl. [Thr]) – viele dieser Tools und Frameworks sind jedoch schlecht dokumentiert
und/oder für die Analyse des CSI nicht geeignet. Letzteres hing damit zusammen, dass das
CSI eigene Längenangaben in der Payload transportiert, die allesamt auch Teile der Payload einschließen, welche vor dieser Längenangabe stehen. Mit der Konstruktion solcher
TCP-Pakete waren alle untersuchten Fuzzer überfordert. Somit war hier eine zeitraubende
Eigenentwicklung erforderlich.
5.4 Ausblick
Sollte das CSI irgendwann einmal eine differenziertere Zugangskontrolle (z.B. verschiedene Benutzergruppen mit unterschiedlichen Rechten innerhalb des CSI) anbieten, muss
darauf geachtet werden, dass insbesondere die Key Import Attack dann nicht mehr möglich ist. Dies wäre beispielsweise realisierbar, indem zu jedem Schlüssel auch dessen Typ
(kryptografisch abgesichert) mit exportiert wird.
Wie im vorherigen Abschnitt erwähnt, wurde die Lunchtime Attack in dieser Arbeit nicht
näher untersucht. Die Ergebnisse aus [JBP+ 00] legen jedoch nahe, dass ein solcher Angriff
durchaus erfolgsversprechend ist. Eine genaue Untersuchung, zum Beispiel im Rahmen
einer Studienarbeit, wäre daher durchaus interessant. Gleiches gilt für Angriffe über Zeitmessungen, die in der vorliegenden Diplomarbeit ebenfalls nicht näher betrachtet wurden.
Nach [BB03] sind Timing Attacks auch über ein Netzwerk durchaus möglich.
In dieser Arbeit wurde ausschließlich das proprietäre Cryptographic Services Interface des
SafeGuard CryptoServersr untersucht. Das Paket SecurityServer umfasst aber noch weitere Security-APIs (vgl. Abschnitt 2.4.4). PKCS #11 wurde in seiner allgemeinen Form bereits
von Clulow analysiert [Clu03b], die konkrete zu diesem Standard kompatible Implementierung der Utimaco wurde von ihm jedoch nicht betrachtet. Gezielte Analysen dieser Implementierung, wie auch der Implementierungen der JCE und des CSP für den CryptoServerr
stehen daher noch aus.
55
Die Tabelle zeigt die zur Analyse des CryptoServersr verwendeten Schlüssel. Ein X in einer
der beiden letzten Spalten bedeutet, dass das entsprechende Attribut gesetzt ist.
Typ
Länge
ID
DES
8 Byte
1111 1111
KEK?
X
1111 1112
16 Byte
1111 1113
X
1111 1114
X
X
1111 1123
X
1111 1124
X
16 Byte
X
1111 1133
X
1111 1134
X
X
2222 1113
X
2222 1114
X
X
2222 1123
X
2222 1124
X
512 Bit
X
2222 1133
X
2222 1134
X
X
3333 1111
3333 1112
56
X
2222 1131
2222 1132
RSA
X
2222 1121
2222 1122
32 Byte
X
2222 1111
2222 1112
24 Byte
X
1111 1131
1111 1132
AES
X
1111 1121
1111 1122
24 Byte
Exportable?
X
Typ
Länge
ID
KEK?
RSA
512 Bit
3333 1113
X
3333 1114
X
1024 Bit
X
3333 1123
X
3333 1124
X
X
3333 1133
X
3333 1134
X
192 Bit
X
3333 1143
X
3333 1144
X
X
4444 1113
X
4444 1114
X
X
4444 1123
X
4444 1124
X
X
4444 1133
X
4444 1134
X
X
4444 1141
X
4444 1142
521 Bit
X
4444 1131
4444 1132
384 Bit
X
4444 1121
4444 1122
256 Bit
X
4444 1111
4444 1112
224 Bit
X
3333 1141
3333 1142
ECDSA
X
3333 1131
3333 1132
2048 Bit
X
3333 1121
3333 1122
1536 Bit
Exportable?
4444 1143
X
4444 1144
X
X
4444 1151
X
4444 1152
4444 1153
X
4444 1154
X
X
Tabelle A.1: Verwendete Schlüssel im CryptoServerr
57
B Taof: fuzz.xml
<?xml version="1.0" ?>
<conversation
dest_host="10.17.0.147" dest_port="288"
local_host="0.0.0.0" local_port="288"
proto="tcp" time="11:53:34"
>
<request ID="1" as_is="0" time="11:53:37">
<fuzz bo="1" checklen="0" dict="0" from="4" fs="0"
lformat="0" lfrom="0" lto="0" lvalue="0" obo="1" to="6"/>
</request>
</request>
58
B Taof: fuzz.xml
</request>
</request>
</request>
</conversation>
59
[ABCS06] A NDERSON , R OSS, M IKE B OND, J OLYON C LULOW und S ERGEI S KOROBOGA TOV : Cryptographic Processors – A Survey. Proceedings of the IEEE, 94(2):357–369,
Februar 2006.
[Ait]
A ITEL ,
D AVE:
SPIKE
–
a
Fuzzer
Creation
http://www.immunitysec.com/resources-freesoftware.shtml
(Letzter
Kit.
Zu-
griff: 15.03.2007).
[Ait02]
A ITEL , D AVE: The Advantages of Block-Based Protocol Analysis for Security Testing.
Technischer Bericht, Immunity, Inc., New York, NY, USA, Februar 2002.
[And00]
A NDERSON , R OSS: The Correctness of Crypto Transaction Sets. Security Protocols:
8th International Workshops Cambridge, UK, LNCS 2133:125–141, April 2000.
[And01]
A NDERSON , R OSS: Security Engineering – A Guide to Building Dependable Distributed Systems. John Wiley & Sons, Inc, Cambridge, UK, Januar 2001.
[BB03]
B RUMLEY, D AVID und D AN B ONEH: Remote Timing Attacks are Practical. In:
Proceedings of the 12th USENIX Security Symposium, Seiten 1–14, Washington,
DC, USA, August 2003. Stanford University.
[BDL97]
B ONEH , D AN, R ICHARD A. D E M ILLO und R ICHARD J. L IPTON: On the importance of checking cryptographic protocols for faults. Journal of Cryptology, 14(2):101–
119, 1997.
[BH06a]
B OLLICH , C HRISTIAN und R AINER H ERBERTZ: CryptoServer – Cryptographic
Service Interface — Firmware Module CSI – Interface Specification, Version 1.2.1.
Utimaco Safeware AG, Aachen, Deutschland, August 2006.
[BH06b]
B OLLICH , C HRISTIAN und R AINER H ERBERTZ: CryptoServer – Cryptographic
Service Interface — Firmware Module CSI – Interface Specification, Version 1.2.3.
Utimaco Safeware AG, Aachen, Deutschland, November 2006.
[Bon00]
B OND , M IKE: A Chosen Key Difference Attack on Control Vectors. University of
Cambridge, November 2000.
[Bon01]
B OND , M IKE: Attacks on Cryptoprocessor Transaction Sets. In: K OÇ , Ç ETIN K AYA,
D AVID N ACCACHE und C HRISTOF PAAR (Herausgeber): Cryptographic Hardware and Embedded Systems – CHES 2001, Third International Workshop, Band 2162
60
der Reihe Lecture Notes in Computer Science, Seiten 220–234, Paris, France, Mai
2001. Springer.
[Bon04]
B OND , M ICHAEL: Understanding Security APIs. Doktorarbeit, University of
Cambridge, Cambridge, UK, Januar 2004.
[Bra]
B RADYOK: Winsock Packet Editor Pro.
http://wpepro.net/ (Letzter Zugriff:
15.03.2007).
[BS93]
B IHAM , E LI und A DI S HAMIR: Differential Cryptanalysis of the Full 16-Round
DES. Lecture Notes in Computer Science, 740:487–496, 1993.
[BS97]
B IHAM , E LI und A DI S HAMIR: Differential Fault Analysis of Secret Key Cryptosystems. Advances in Cryptology - Crypto ’97, LNCS 1294:513–525, 1997.
[Cha01]
C HARRON ,
T IM:
GREP
for
Windows,
Version
2.0d.
http://www.interlog.com/~tcharron/grep.html (Letzter Zugriff: 15.03.2007),
Januar 2001.
[Clu03a]
C LULOW, J OLYON: The Design and Analysis of Cryptographic Application Programming Interfaces for Security Devices. Masterthesis, University of Natal, Durban,
Südafrika, Januar 2003.
[Clu03b]
C LULOW, J OLYON: On the Security of PKCS #11. In: C. D. WALTER
ET AL .
(Her-
ausgeber): CHES Workshop 2003, LNCS 2779, Seiten 411–425. Springer-Verlag
Berlin Heidelberg, September 2003.
[DH76]
D IFFIE , W HITFILED und M ARTIN E. H ELLMAN: New Directions in Cryptography.
IEEE Transaction on Information Theory, 22(6):644–654, November 1976.
[DKR04]
D OBBERTIN , H ANS, L ARS R. K NUDSEN und M ATTHEW J. B. R OBSHAW: The
Cryptanalysis of the AES - A Brief Survey. In: D OBBERTIN , H ANS, V INCENT R IJ MEN
und A LEKSANDRA S OWA (Herausgeber): Advanced Encryption Standard –
AES, 4th International Conference, AES 2004, Band 3373 der Reihe Lecture Notes
in Computer Science, Seiten 1–10, Bonn, Deutschland, Mai 2004. Springer.
[Fre05]
F REILING , F ELIX C. ( GEB . G ÄRTNER ): Teil 12: Privilegeskalation.
In: Folien
zur Vorlesung „Verlässliche Verteilte Systeme 1“. RWTH Aachen, Wintersemester
2004/2005.
[GMO01]
G ANDOLFI , K ARINE, C HRISTOPHE M OURTEL und F RANCIS O LIVIER: Electromagnetic Analysis: Concrete Results. Cryptographic Hardware and Embedded
Systems - CHES 2001, LNCS 2162:251–261, Mai 2001.
[Her03a]
H ERBERTZ , R AINER: CryptoServer 2000 – Firmware Module CMDS – Interface Specification, Version 1.00.03. Utimaco Safeware AG, Aachen, Deutschland, Mai
2003.
61
[Her03b]
H ERBERTZ , R AINER: CryptoServer 2000 – Firmware Module VRSA – Interface Specification, Version 1.1.0. Utimaco Safeware AG, Aachen, Deutschland, Oktober
2003.
[Her06]
H ERBERTZ , R AINER: CryptoServer – Application Interface (CSAPI), Version 1.2.0.
Utimaco Safeware AG, Aachen, Deutschland, Juni 2006.
[IBM]
IBM: Homepage for Cryptographic Hardware Products.
http://www-
03.ibm.com/security/cryptocards/ (Letzter Zugriff: 15.03.2007).
[IBM03]
IBM: IBM PCI Cryptographic Coprocessor – CCA Basic Services Reference and Guide
Release 2.41. IBM Corporation, Charlotte, NC, USA, September 2003.
[Jan00]
J ANSSENS , D IRK: KeyGrab T00. Proposed Solution, November 2000.
[JBP+ 00]
J ANSSENS , D IRK, R ONNY B JONES, B ART P RENEEL, J OOS VANDERWALLE und
J ORIS C LAESSENS: KeyGrab T00 – The search for keys continues... Whitepaper,
Utimaco Safeware AG, KU Leuven, Dezember 2000.
[Jur06]
J URANI Ć , L EON: Using fuzzing to detect security vulnerabilities. Technischer Bericht INFIGO-TD-01-04-2006, Infigio Information Security, Zagreb, Kroatien,
April 2006.
[Kah96]
K AHN , D AVID: The Codebreakers – The Comprehensive History of Secret Communication from Ancient Times to the Internet. Scribner, New York, NY, USA, 2. Auflage, 1996.
[Kel04]
K ELIHER , L IAM: Refined Analysis of Bounds Related to Linear and Differential Cryptanalysis for the AES. In: D OBBERTIN , H ANS, V INCENT R IJMEN und A LEKSAN DRA
S OWA (Herausgeber): AES Conference, Band 3373 der Reihe Lecture Notes in
Computer Science, Seiten 42–57. Springer, 2004.
[KJJ98]
K OCHER , PAUL C., J OSHUA J AFFE und B ENJAMIN J UN: Introduction to Differential Power Analysis and Related Attacks. Technischer Bericht, Cryptography
Research, Inc., San Francisco, CA, USA, 1998.
[KJJ99]
K OCHER , PAUL C., J OSHUA J AFFE und B ENJAMIN J UN: Differential Power Analysis. Advances in Cryptology - Crypto ’99, LNCS 1666:388–397, 1999.
[Koc96]
K OCHER , PAUL C.: Timing Attacks on Implementations of Diffie-Hellman, RSA,
DSS, and Other Systems. Advances in Cryptology - Crypto ’96, LNCS 1109:104–
113, 1996.
[KPSS01]
K ALLNIK , S TEPHAN, D ANIEL PAPE, D ANIEL S CHRÖTER und S TEFAN S TROBEL:
Das Sicherheitsloch – Buffer-Overflows und wie man sich davor schützt. c’t - magazin
für computertechnik, 23/2001:216ff, 2001.
62
[KSWH00] K ELSEY, J OHN, B RUCE S CHNEIER, D AVID WAGNER und C HRIS H ALL: Side
Channel Cryptanalysis of Product Ciphers. Journal of Computer Security, 8(23):141–158, 2000.
[LDVH06] L INNEWEBER , F RANK, B ERND D OETSCH, R ALF V ENNEMANN und R AINER
H ERBERTZ: CryptoServer LAN – User Manual, Version 2.1.1. Utimaco Safeware
AG, Aachen, Deutschland, Januar 2006.
[LF06]
L ONG , B ENJAMIN W. und C OLIN J. F IDGE: Formally Analysing a Security Protocol for Replay Attacks. In: 17th Australian Software Engineering Conference (ASWEC
2006), Seiten 171–180, Sydney, Australien, Januar 2006. IEEE Computer Society.
[Lin06]
L INDNER , F ELIX "FX": Ein Haufen Risiko – Pufferüberläufe auf dem Heap und wie
man sie ausnutzt. c’t - magazin für computertechnik, 9/2006:186–192, 2006.
[Mar07]
M ARCOS ,
R ODRIGO:
Taof
–
The
art
of
fuzzing,
Version
0.3.
http://sourceforge.net/projects/taof/ (Letzter Zugriff: 15.03.2007), Februar
2007.
[Mea03]
M EADOWS , C ATHERINE: What Makes a Cryptographic Protocol Secure? The Evolution of Requirements Specification in Formal Cryptographic Protocol Analysis. In:
D EGANO , P IERPAOLO (Herausgeber): Programming Languages and Systems: 12th
European Symposium on Programming, ESOP 2003, Band 2618 der Reihe Lecture
Notes in Computer Science, Seiten 10–21, Warschau, Polen, April 2003. Springer.
[Mica]
M ICROSOFT:
Cryptography
API:
Next
Generation.
http://msdn2.microsoft.com/en-us/library/aa376210.aspx (Letzter Zugriff:
15.03.2007).
[Micb]
M ICROSOFT: Cryptography: CryptoAPI.
http://msdn2.microsoft.com/en-
us/library/aa380255.aspx (Letzter Zugriff: 15.03.2007).
[MOV96]
M ENEZES , A LFRED J., PAUL C.
VAN
O ORSCHOT und S COTT A. VANSTONE:
Handbook of Applied Cryptography. CRC Press, Boca Raton, FL, USA, 5. Auflage,
Dezember 1996.
[nCi05a]
N C IPHER :
CipherTools nCore Developer Guide, Version 4.0.73. nCipher Corporati-
on Ltd., Cambridge, UK, September 2005.
[nCi05b]
N C IPHER : CipherTools nCore Developer Reference, Version 4.0.102.
nCipher Corpo-
ration Ltd., Cambridge, UK, Dezember 2005.
[OKH06]
O TT, G ESA, S VEN K ALTSCHMIDT und R AINER H ERBERTZ: CryptoServer – Administration Guide, Version 1.2.8. Utimaco Safeware AG, Aachen, Deutschland,
Juni 2006.
[One96]
O NE , A LEPH: Smashing The Stack For Fun And Profit. Phrack, 7(49), November
1996.
63
[Ope]
O PEN SSL P ROJECT: Homepage des OpenSSL Project. http://www.openssl.org/
(Letzter Zugriff: 15.03.2007).
[PNRB93] P RENEEL , B ART, M ARNIX N UTTIN, V INCENT R IJMEN und J OHAN B UELENS:
Cryptanalysis of the CFB mode of the DES with a reduced number of rounds. In:
S TINSON , D. (Herausgeber): Advances in Cryptology, Proceedings Crypto’93, Seiten 212–223. Springer-Verlag Heidelberg, Oktober 1993.
[Ren04]
R ENES , J OSEPH M.: Frames, Designs, and Spherical Codes in Quantum Information Theory. Doktorarbeit, University of New Mexico, Albuquerque, NM, USA,
April 2004.
[RR01]
R AO , J OSYULA R. und PANKAJ R OHATGI: EMpowering Side-Channel Attacks.
Technischer Bericht 2001/037, IBM T.J. Watson Research Center, Yorktown
Heights, NY, USA, Mai 2001.
[RS00]
R AYMOND , J EAN -F RANÇOIS und A NTON S TIGLIC: Security Issues in the DiffieHellman Key Agreement Protocol. Dezember 2000.
[RSA93]
RSA L ABORATORIES: PKCS #3: Diffie-Hellman Key-Agreement Standard. RSA Laboratories, Redwood City, CA, USA, November 1993.
[RSA04]
RSA L ABORATORIES: PKCS #11 v2.20: Cryptographic Token Interface Standard.
RSA Laboratories, Redwood City, CA, USA, Juni 2004.
[Sch04]
S CHNEIER , B RUCE: Secrets & Lies – Digital Security in a Networked World. Wiley
Publishing, Inc., Indianapolis, Indiana, USA, 2. Auflage, 2004.
[Sch07]
S CHÜLER , M ICHAEL: Anwendung bekannter Angriffe auf den CryptoServerr . Technischer Bericht, Utimaco Safeware AG, Aachen, Deutschland, Februar 2007.
[SPQ03]
S TANDAERT, F RANCOIS -X AVIER, G ILLES P IRET und J EAN -J ACQUES Q UISQUA TER :
Cryptanalysis of Block Ciphers: A Survey. Technischer Bericht CG-2003/2,
UCL Crypto Group, Laboratoire de Microélectronique, Université catholique
de Louvain, Louvain-la-Neuve, Belgien, Mai 2003.
[Spr05]
S PRUNDEL , I LJA VAN: Fuzzing: Breaking software in an automated fashion. In: 22nd
Chaos Communication Congress (22C3), Dezember 2005.
[SS99]
S HAMIR , A DI und N ICKO
VAN
S OMEREN: Playing ’Hide and Seek’ with Stored
Keys. In: F RANKLIN , M ATTHEW K. (Herausgeber): Financial Cryptography, Third
International Conference, FC ’99, Anguilla, British West Indies, Band LNCS 1648,
Seiten 118–124. Springer-Verlag, Februar 1999.
[Sun]
S UN
M ICROSYSTEMS:
Java
Cryptography
Extension
(JCE)
Homepage.
http://java.sun.com/products/jce/index.jsp (Letzter Zugriff: 15.03.2007).
[Thr]
T HREAT M IND: FuzzingTools. http://www.scadasec.net/secwiki/FuzzingTools
(Letzter Zugriff: 15.03.2007).
64
[Utia]
U TIMACO S AFEWARE AG: CryptoServer. Produkt-CD.
[Utib]
U TIMACO
S AFEWARE
AG:
Homepage
für
Hardware
Sicherheitsmodule.
http://www.utimaco.de/hsm/ (Letzter Zugriff: 15.03.2007).
[Uti05]
U TIMACO: CryptoServer – Product brochure. Utimaco Safeware AG, 2005.
[Uti06a]
U TIMACO: CryptoServer – Error Reference.
Utimaco Safeware AG, Aachen,
Deutschland, August 2006.
[Uti06b]
U TIMACO: HSM Lösungsbroschüre. Utimaco Safeware AG, 2006.
[VM01]
V IEGA , J OHN und G ARY M C G RAW: Building Secure Software – How to Avoid Security Problems the Right Way. Addison-Wesley Professional, September 2001.
65
66
Glossar
Begriff
Beschreibung
CRM
Customer Relationship Management. Verwaltung von
Kundenbeziehungen in einem Unternehmen.
ERP
Enterprise Recource Planning. Unternehmerische Aufgabe, betriebliche Resourcen möglichst effizient zu einzuplanen.
HBCI
Homebanking Computer Interface. Ein offener Standard für den Bereich Online-Banking.
Java
Eine objektorientierte Programmiersprache, die auf allen Systemen läuft.
LAN
Local Area Network. Lokales Computernetzwerk in
Firmen oder Privathaushalten.
MAC
Message Authentication Code. Code zur Sicherstellung von Integrität und Authentizität elektronischer
Nachrichten.
Payload
Die Nutzdaten in einem IP- oder TCP-Paket.
PIN
Personal Identifikation Number. Ziffernfolge, die als
Passwort benutzt wird.
Pinpad
Lesegerät für Smartcards mit integrierter Tastatur zur
PIN-Eingabe.
Policy
(Sicherheits-)Richtlinie in einem Unternehmen oder einer Organisation.
Smartcard
Plastikkarte mit integriertem Mikroprozessor und
Speicher.
67
Glossar
Begriff
Beschreibung
TCP
Transmission Control PProtocol. Protokoll zum verbindungsorientierten Austausch von Daten zwischen
Computern.
Zertifizierungsstelle
68
Organisation, die digitale Zertifikate ausgibt.

Diplomarbeit Sicherheitsuntersuchung des Hardware

Transcription

Similar documents

Guide 1 von hdro-der

Edward II

Keylogger - von Christian Koch