Mobile Geräte als Terminal für sicherheitsrelevante Transaktionen

Transcription

Mobile Geräte als Terminal für
sicherheitsrelevante Transaktionen
Diplomarbeit
ausgeführt am
Lehrstuhl für Datenverarbeitung
Technische Universität München
Prof. Dr. techn. J. Swoboda
von
Albert Deindl
Betreuer:
Dipl.-Ing. Andreas Pilz,
Dipl.-Ing. Michael Pramateftakis
Beginn:
Abgabe:
22. November
2. Oktober
2000
2001
ii
iii
Erklärung:
Hiermit erkläre ich, daß ich die Diplomarbeit selbständig verfaßt und
keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
München, den 2. Oktober 2001
Albert Deindl
iv
Kurzfassung
Durch die zunehmende Automatisierung vieler Vorgänge im täglichen Leben gewinnt
eine zuverlässige und sichere maschinelle Feststellung der Identität einer Person zunehmende Bedeutung. Dafür existieren derzeit viele verschiedene Systeme wie z.B.
Chipkarten, PINs, Login-/Passwortkombinationen, mechanische Schlüssel, u.v.m..
Alle diese Systeme sind mit Vor- und Nachteilen behaftet; in jedem Fall stellt jedoch
die Anzahl der unterschiedlichen Sicherheitstoken ein Problem dar. Es wäre wünschenswert mit einem System alle Authentifikationsaufgaben abdecken zu können. Intelligente
mobile Geräte wie z.B. Mobiltelefone oder PDAs bieten sich, besonders aufgrund ihrer
hohen Verbreitung, als Plattform für ein derartiges System an. Sie verfügen darüberhinaus über die Ressourcen, um neben der Authentifikation auch als sicheres Terminal
für beliebige Aufgaben dienen zu können.
Aufgabe dieser Diplomarbeit war es neben der Einarbeitung in die Grundlagen der
Kryptologie, lokalen Übertragungstechnologien und Protokollen, die Eignung der derzeitig am Markt verfügbaren mobilen Geräte als Plattform zur mobilen Authentifikation zu diskutieren, sowie notwendige Änderungen und Erweiterungen vorzuschlagen.
Auf diesen Erkenntnissen aufbauend sollte ein Systemkonzept entwickelt werden, welches vor allem die Flexibilität und gleichzeitig die Sicherheit eines solchen Vorhabens
berücksichtigt. Abschließend sollte dieses Konzept anhand eines Demonstrationssystems prototypenhaft in die Praxis umgesetzt werden.
Die Untersuchung ergab, daß prinzipiell alle heute auf dem Markt befindlichen mobilen Geräte die Voraussetzungen mitbringen, ein derartiges System zu realisieren. Aus
Sicherheitsgründen ist zur Speicherung der persönlichen Schlüssel und zur Ausführung
sicherheitsrelevanter kryptographischer Operationen jedoch eine Chipkarte vorzusehen.
Da heute kaum ein mobiles Gerät über die notwendige Lese-Hardware verfügt, müssen
die Geräte um diese Komponente erweitert werden. Darüberhinaus ist eine Infrastruktur mit Trustcentern zur Sicherstellung der Benutzer-Identitäten aufzubauen.
Mein Konzept spezifiziert die einzelnen Systemkomponenten, sowie ihr Zusammenwirken. Damit Geräte unterschiedlichster Hersteller zusammenarbeiten können, entstand
zur Abwicklung des Authentifikationsvorgangs ein hardwareunabhängiges Protokoll.
Die zentrale personifizierende Komponente des Systementwurfs ist die Chipkarte, deren Funktionen und Schnittstellen ebenfalls festgelegt worden sind. Der Benutzer kann
somit - solange er diese Karte verwendet - unterschiedliche mobile Geräte benutzen,
v
vi
um sich an beliebigen kompatiblen Stellen zu authentifizieren.
Das Ergebnis dieser Arbeit ist ein flexibles Konzept, sowie ein Satz von Kommunikationsprotokollen und Schnittstellen, mit Hilfe welcher auf heute verfügbaren Technologien ein mobiles auf lokalen Übertragungsmedien basierendes Authentifikationsystem
realisiert werden kann. Nach erfolgreicher Authentifikation besteht eine gesicherte und
verschlüsselte Verbindung zwischen den beiden Kommunikationspartnern, auf die beliebige sicherheitsrelevante Anwendungen aufsetzen können.
Zur Demonstration des Systementwurfs entstand ferner eine Implementierung dieses
Konzepts in Form einer drahtlosen Rechneranmeldung basierend auf einem Handspring
Visor PDA.
Inhaltsverzeichnis
Einleitung
1
I
3
Theoretischer Teil
1 Grundlagen
1.1
1.2
1.3
5
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1.1
Ausgangssituation
. . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1.2
Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Authentifizierungssysteme . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2.1
Allgemeiner Authentifikationsprozeß . . . . . . . . . . . . . . .
7
1.2.2
Sicherheitstoken . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2.2.1
Untergliederung . . . . . . . . . . . . . . . . . . . . . .
8
1.2.2.2
Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Überblick - Mobile Geräte . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.3.1
Leistungsmerkmale handelsüblicher mobiler Geräte . . . . . . .
10
1.3.1.1
Mobiltelefone . . . . . . . . . . . . . . . . . . . . . . .
10
1.3.1.2
Handhelds . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.3.1.3
Digitalkameras . . . . . . . . . . . . . . . . . . . . . .
14
1.3.1.4
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Lokale Übertragungstechnologien . . . . . . . . . . . . . . . . .
16
1.3.2.1
IrDA
16
1.3.2.2
Wireless LAN
1.3.2
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
vii
17
viii
INHALTSVERZEICHNIS
1.4
1.3.2.3
Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.3.2.4
Weitere Verfahren . . . . . . . . . . . . . . . . . . . .
21
1.3.2.5
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Kryptologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.4.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.4.2
Kryptographische Grundverfahren . . . . . . . . . . . . . . . . .
23
1.4.2.1
Stromverschlüsselung . . . . . . . . . . . . . . . . . . .
23
1.4.2.2
Blockverschlüsselung . . . . . . . . . . . . . . . . . . .
23
1.4.2.3
Symmetrische Verfahren . . . . . . . . . . . . . . . . .
24
1.4.2.4
Asymmetrische Verfahren . . . . . . . . . . . . . . . .
24
1.4.2.5
Hybride Verfahren . . . . . . . . . . . . . . . . . . . .
25
1.4.2.6
Hash Funktionen . . . . . . . . . . . . . . . . . . . . .
25
1.4.2.7
Digitale Signatur . . . . . . . . . . . . . . . . . . . . .
26
Ausgewählte Algorithmen . . . . . . . . . . . . . . . . . . . . .
26
1.4.3.1
DES . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.4.3.2
IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
1.4.3.3
RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
1.4.3.4
ElGamal Methode . . . . . . . . . . . . . . . . . . . .
28
1.4.3.5
EEC elliptische Kurven . . . . . . . . . . . . . . . . .
28
1.4.4
Kryptoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
1.4.5
Kryptographische Protokolle . . . . . . . . . . . . . . . . . . . .
30
1.4.5.1
Schlüsseltausch - Diffie-Hellmann Verfahren . . . . . .
30
1.4.5.2
Authentifikation - Challenge-Response Methode . . . .
30
Zertifikate - PKI Infrastruktur . . . . . . . . . . . . . . . . . . .
31
Chipkarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
1.5.1
Entstehungsgeschichte . . . . . . . . . . . . . . . . . . . . . . .
33
1.5.2
Arten von Chipkarten . . . . . . . . . . . . . . . . . . . . . . .
33
1.5.3
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
1.5.4
Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
1.4.3
1.4.6
1.5
INHALTSVERZEICHNIS
1.5.5
ix
Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Das OBEX Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
1.6.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
1.6.2
Session Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . .
39
1.6.3
Objektmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
1.6.4
Application Framework . . . . . . . . . . . . . . . . . . . . . . .
45
1.6.5
Authentifikation . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
1.6.6
Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
1.6.7
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
1.7
Das Konzept mSign . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
1.8
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
1.8.1
Anforderungen an ein universelles Authentifizierungstoken . . .
47
1.8.2
Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
1.6
2 Konzept
51
2.1
Zielsetzung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
2.2
Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
2.3
Systembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
2.4
Aufgaben der mAuth Systemkomponenten . . . . . . . . . . . . . . . .
56
2.4.1
Das Trustcenter . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
2.4.2
Die Chipkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
2.4.3
Das mobile Gerät . . . . . . . . . . . . . . . . . . . . . . . . . .
59
2.4.3.1
Hardware . . . . . . . . . . . . . . . . . . . . . . . . .
60
2.4.3.2
Software . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Der PoA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
2.4.4.1
Hardware . . . . . . . . . . . . . . . . . . . . . . . . .
61
2.4.4.2
Software . . . . . . . . . . . . . . . . . . . . . . . . . .
62
2.4.4.3
Übergeordnetes Institut oder Organisation . . . . . . .
64
2.5 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
2.4.4
2.5.1
Zertifikatsaustellung . . . . . . . . . . . . . . . . . . . . . . . .
64
x
INHALTSVERZEICHNIS
2.6
2.7
2.8
2.5.2
Authentifikationsprozess . . . . . . . . . . . . . . . . . . . . . .
66
2.5.3
Anmelden bei PoAs . . . . . . . . . . . . . . . . . . . . . . . . .
68
2.5.4
Peer Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Kommunikationsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . .
71
2.6.1
Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
2.6.2
Benutzer - Trustcenter . . . . . . . . . . . . . . . . . . . . . . .
72
2.6.3
Trustcenter - Chipkarte . . . . . . . . . . . . . . . . . . . . . . .
73
2.6.4
Benutzer - mobiles Gerät . . . . . . . . . . . . . . . . . . . . . .
73
2.6.5
Mobiles Gerät - Chipkarte . . . . . . . . . . . . . . . . . . . . .
74
2.6.6
PTD - PoA . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
2.6.7
Benutzer - PoA . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
2.6.8
Zusammenwirken . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
2.7.1
Chipkarte - Kartenlesegerät Schnittstelle . . . . . . . . . . . . .
78
2.7.2
Mensch - Maschine Schnittstelle . . . . . . . . . . . . . . . . . .
80
2.7.3
PoA - PTD-Schnittstelle . . . . . . . . . . . . . . . . . . . . . .
85
Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
2.8.1
Chipkarten APDU Format . . . . . . . . . . . . . . . . . . . . .
85
2.8.1.1
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . .
85
2.8.1.2
Command codes . . . . . . . . . . . . . . . . . . . . .
87
2.8.1.3
Parameter . . . . . . . . . . . . . . . . . . . . . . . . .
87
2.8.1.4
Daten . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
2.8.1.5
Responses . . . . . . . . . . . . . . . . . . . . . . . . .
91
Zertifikatsformat . . . . . . . . . . . . . . . . . . . . . . . . . .
93
2.8.2.1
Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
2.8.2.2
Format . . . . . . . . . . . . . . . . . . . . . . . . . .
94
2.8.2.3
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . .
96
Erweitertes OBEX Protokoll - mAuth OBEX . . . . . . . . . .
97
2.8.3.1
97
2.8.2
2.8.3
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . .
INHALTSVERZEICHNIS
2.9
II
xi
2.8.3.2
Befehle . . . . . . . . . . . . . . . . . . . . . . . . . .
99
2.8.3.3
Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
2.8.4
Chipkarten-Applikation - Zustände und Automat . . . . . . . . 107
2.8.5
PTD-Anwendung - Zustände und Automat . . . . . . . . . . . . 108
2.8.6
PoA-Server - Zustände und Automat . . . . . . . . . . . . . . . 109
Application Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2.9.1
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2.9.2
Applikationsmodelle . . . . . . . . . . . . . . . . . . . . . . . . 113
2.9.3
Verwendung des mAuth-OBEX Protokolls . . . . . . . . . . . . 114
Praktischer Teil
3 Grundlagen des Demonstrationssytems
115
117
3.1
Die praktische Umsetzung des Konzepts . . . . . . . . . . . . . . . . . 117
3.2
Die IrDA-Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.3
IrDA-Unterstützung auf Personal Computern
3.4
3.5
3.6
. . . . . . . . . . . . . . 120
3.3.1
Bau eines IrDA-Transceivers für den PC . . . . . . . . . . . . . 121
3.3.2
Linux-IrDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Die Pluggable Authentification Modules - PAM . . . . . . . . . . . . . 126
3.4.1
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.4.2
PAM Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.4.3
Anforderungen an ein PAM Modul . . . . . . . . . . . . . . . . 130
Giesecke und Devrient Sm@rtcafé Javacard . . . . . . . . . . . . . . . . 131
3.5.1
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.5.2
Javacard Applikationen . . . . . . . . . . . . . . . . . . . . . . . 132
3.5.3
Leistungsmerkmale der Sm@rtcafé Karte . . . . . . . . . . . . . 134
3.5.4
Die Sm@rtcafé Entwicklungsumgebung . . . . . . . . . . . . . . 134
3.5.5
Das Main Loader Konzept . . . . . . . . . . . . . . . . . . . . . 135
Chipkarten-Lesegerät Towitoko Chipdrive micro 100 . . . . . . . . . . . 137
3.7 PalmOS-PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
xii
INHALTSVERZEICHNIS
3.8
3.9
3.7.1
Entwicklungsgeschichte . . . . . . . . . . . . . . . . . . . . . . . 138
3.7.2
Unterschiede zwischen Handspring- und Palm-Modellen . . . . . 140
3.7.3
Der Handspring Visor Platinum . . . . . . . . . . . . . . . . . . 141
Programmentwicklung unter PalmOS . . . . . . . . . . . . . . . . . . . 142
3.8.1
Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.8.2
Einschränkungen und Besonderheiten . . . . . . . . . . . . . . . 142
3.8.3
Speicherorganisation . . . . . . . . . . . . . . . . . . . . . . . . 144
3.8.4
Ereignis gesteuerte Programmausführung . . . . . . . . . . . . . 146
3.8.5
Das User Interface . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.8.6
Das PRC-Format . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.8.7
Libraries unter PalmOS . . . . . . . . . . . . . . . . . . . . . . 150
3.8.7.1
PalmOS-Version 2 shared Libraries - SysLib . . . . . . 151
3.8.7.2
GNU GLib Shared Libraries . . . . . . . . . . . . . . . 152
GNU-PalmOS-Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . 153
3.9.1
Alternative Entwicklungs-Tools . . . . . . . . . . . . . . . . . . 153
3.9.2
Verschiedene Versionen des PalmOS-SDKs . . . . . . . . . . . . 153
3.9.3
PRC-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.9.3.1
Verschiedene Versionen . . . . . . . . . . . . . . . . . . 154
3.9.4
Der Pilot Resource Compiler PilRC . . . . . . . . . . . . . . . . 155
3.9.5
Handspring-spezifische Erweiterungen des PalmOS
. . . . . . . 156
3.10 Der PalmOS-Emulator POSE . . . . . . . . . . . . . . . . . . . . . . . 157
3.10.1 Entwicklungsgeschichte . . . . . . . . . . . . . . . . . . . . . . . 157
3.10.2 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3.10.3 Probleme beim Ansprechen der emulierten seriellen Schnittstelle 160
3.10.4 Auslesen eines ROM Images aus dem Visor . . . . . . . . . . . . 161
3.10.5 Schwierigkeiten bei der Ausführung eines Handspring Visor Platinum ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.11 Anschluß des Chipkarten-Lesegeräts an den PDA . . . . . . . . . . . . 163
3.11.1 Die serielle Schnittstelle des Handspring Visors
. . . . . . . . . 163
3.11.2 Kopplung über serielles Cradle mit RS-232-Pegelwandler . . . . 163
INHALTSVERZEICHNIS
xiii
3.11.3 Direkte Kopplung . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4 Das mAuth Demonstrationssystem
4.1
4.2
169
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.1.1
Implementierte Systemkomponenten . . . . . . . . . . . . . . . 169
4.1.2
Implementierte Funktionalität . . . . . . . . . . . . . . . . . . . 169
Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.2.1
Die Chipkartenapplikation . . . . . . . . . . . . . . . . . . . . . 170
4.2.2
Der PoA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.2.3
4.2.2.1
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.2.2.2
Das PAM Modul . . . . . . . . . . . . . . . . . . . . . 175
4.2.2.3
Modifikation des Mingetty Programms . . . . . . . . . 175
Der PTD-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.2.3.1
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.2.3.2
Anpassung der SCEZ Chipcard Library . . . . . . . . 177
4.2.3.3
Probleme bei der gleichzeitigen Verwendung von IrDA
und der seriellen Schnittstelle . . . . . . . . . . . . . . 178
4.2.3.4
SSLeay Crypto-Library für PalmOS
4.2.3.5
Entwicklung eigener IrDA-Funktionen in Form der
MyIrLib . . . . . . . . . . . . . . . . . . . . . . . . . . 180
. . . . . . . . . . 180
4.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
4.3.1
4.3.2
Chipkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
4.3.1.1
notwendige Tools . . . . . . . . . . . . . . . . . . . . . 185
4.3.1.2
Übersetzen und Installieren . . . . . . . . . . . . . . . 186
PTD-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.3.2.1
notwendige Tools . . . . . . . . . . . . . . . . . . . . . 187
4.3.2.2
4.3.3
PoA-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
4.3.4
Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . 188
4.3.4.1
4.4 Bedienung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
xiv
INHALTSVERZEICHNIS
4.4.1
Chipkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
4.4.1.1
Ändern von PIN und Schlüssel . . . . . . . . . . . . . 190
4.4.1.2
Modifikation der Main Loader Sicherheitsoptionen . . . 190
4.4.2
PoA-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
4.4.3
PTD-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.4.3.1
Normaler Authentifikations Ablauf . . . . . . . . . . . 193
4.4.3.2
Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . 198
5 Zusammenfassung und Ausblick
203
5.1
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
EINLEITUNG
1
Einleitung
Leistungsfähige mobile elektronische Geräte wie z.B. Mobiltelefone, elektronische Terminplaner oder Digitalkameras werden immer mehr zu unseren alltäglichen Wegbegleitern. Dabei nimmt ihre Leistungsfähigkeit und ihr Funktionsumfang ständig zu.
Annähernd jedes mobile Gerät besitzt heute schon eine drahtlose Schnittstelle wie z.B.
IrDA1 oder Bluetooth zur Kommunikation mit seinem Umfeld. Zudem ist abzusehen,
daß diese Geräte in Zukunft zu einer Einheit zusammenwachsen werden. Erste multifunktionale mobile Begleiter sind bereits auf der Cebit 2001 vorgestellt worden. In
Anbetracht der Wachstumsraten auf dem Mobilfunksektor ist es nicht utopisch davon auszugehen, daß in sehr naher Zukunft annähernd jeder einen solchen universellen
PDA2 bei sich tragen wird.
Da diese Geräte trotz ihrer geringen Größe über eine Rechenleistung und Erweiterungsmöglichkeiten verfügen wie sie vor nicht allzulanger Zeit nur von PCs geboten
wurden, eröffnen sich damit neue Anwendungsbereiche, die weit über die derzeitige
Nutzung hinausreichen.
Als neue Einsatzmöglichkeiten bieten sich zunächst Aufgaben an, zu deren
Durchführung es bisher notwendig war, weitere Gegenstände mit sich zu führen. Solche
Gegenstände sind insbesondere die wachsende Anzahl an persönlichen Sicherheitstoken.
Es ist heute üblich eine Vielzahl an kartenbasierenden Token wie Kreditkarten, ECKarten, Bibliotheksausweise, Krankenversicherungskarte sowie diverse Magnetstreifenoder Chipkarten als Zugangskontrolle bei sich zu tragen. Ein Blick in die eigene Brieftasche wird dies in den meisten Fällen verifizieren. Dabei ist diese Aufzählung oftmals
noch lange nicht vollständig. Dazu kommen noch konventionelle, mechanische Schlüssel
und wissensbasierende Token wie PINs und Login/Passwort-Kombinationen.
Intelligente mobile Geräte sind die optimale Plattform, um diese Token in ein System
mit adäquater Sicherheit zu vereinen. Zudem ergibt sich durch die dabei entstehende
vertrauenswürdige Mensch-Maschine-Schnittstelle“ ein weiterer Mehrwert. Selbst eine
”
Schnittstelle zur Kommunikation mit Systemen, welche ansonsten direkten Kontakt mit
entsprechenden Token gehabt hätten, ist bereits in den meisten Fällen vorhanden.
1
2
Infrared Data Associaton
Personal Digital Assistant
2
EINLEITUNG
Das Ziel der Arbeit ist die Entwicklung eines allgemeines Konzept zur Verwirklichung
eines universellen mobilen Authentifikationssystems.
Dafür werden zuerst unterschiedliche mobile Gerät im Hinblick auf ihre Tauglichkeit zur
Verwirklichung dieser Idee untersucht, sowie eventuell dazu notwendige Erweiterungen
diskutiert. Im ersten Kapitel des theoretischen Teils der Arbeit sind diese Ergebnisse,
sowie die Grundlagen der für dieses Projekt relevanten Technologien und Protokolle
zusammengefaßt.
Auf diesen Erkenntnissen aufbauend wird ein konkretes Konzept für ein mobiles Authentifikationsystems entworfen. Die Beschreibung aller Systembestandteile ebenso wie
die Spezifikation der verwendeten Kommunikationsprotokolle und aller Systemablaufe
sind im darauffolgenden Kapitel dargestellt.
Abschließend ist die praktische Implementierung eines Demonstrationssystems dieses
Konzepts beschrieben. Damit ist die Anmeldung an ein Rechnersystem mittels eines
elektronischen Terminplaners möglich.
Teil I
Theoretischer Teil
3
5
Kapitel 1
Grundlagen
1.1
1.1.1
Einführung
Ausgangssituation
Bereits heute sind im alltäglichen Leben viele verschiedene Sicherheitstoken notwendig.
Diese Entwicklung weist eine wachsender Tendenz auf. So verschieden diese Token sind,
so verschieden ist auch deren Sicherheit. Allen gemeinsam ist jedoch die Tatsache, daß
sie in der Regel für eine spezielle Anwendung konzipiert und ausschließlich für diese
nutzbar sind. So paßt ein Schlüssel in der Regel nur genau in ein Schloß.
SmartCard
SmartCard
SmartCard
Magnetstreifenkarte
Magnetstreifenkarte
Magnetstreifenkarte
Login-Passwort
Login-Passwort
Kombinationen
Kombinationen
BANKOMAT
EC
Abbildung 1.1: Vielzahl spezialisierter Sicherheitstoken
6
KAPITEL 1. GRUNDLAGEN
Abgesehen von dem Aufwand alle, diese Token ständig mit sich zu tragen und dem
Problem, dabei leicht den Überblick zu verlieren, verleitet eine so große Menge den
Anwender dazu, leichtfertiger mit geheimen Daten umzugehen. So soll es vorgekommen sein, daß sich Personen die geheime PIN Nummer direkt auf ihrer EC Karte notiert
haben, da sie sich nicht alle Geheimnummern merken konnten. Dies ist natürlich ein
extremer Fall, jedoch zeigt dieses Beispiel, daß ein Bedarf existiert, Authentifizierungsprozesse für den Benutzer einfach zu halten, ohne dabei jedoch Abstriche im Bereich
der Sicherheit zu machen.
Es wäre daher vorteilhaft, möglichst viele Token auf ein gemeinsames, multifunktionales
System zu vereinen.
Öffentliche Terminals wie z.B. an Geldautomaten, an denen sicherheitsrelevante Transaktionen durchgeführt werden, stellen immer ein Risiko für den Benutzer dar. Der Anwender hat keinerlei Wissen noch Kontrolle über das benutzte Gerät. Manipulationen
an Teilen oder gar am gesamten Gerät sind für ihn kaum zu erkennen. Dadurch wird das
Ausspähen oder Verändern geheimer Daten möglich. Dies stellt ein erheblich größeres
Problem als der Verlust oder Diebstahl eines Sicherheitstoken dar. In letzterem Falle
kann der Benutzer Maßnahmen wie die Sperrung einer EC-Karte oder den Austausch
von Schlössern vornehmen, um weiteren Mißbrauch zu verhindern. Werden jedoch geheime sicherheitsrelevante Daten an manipulierten Terminals erspäht, so geschieht das,
ohne daß der Anwender es bemerkt. Somit wird er auch keine Gegenmaßnahmen einleiten. Es gab Fälle, in welchen ein kompletter EC Geldautomat durch einen Nachbau,
der alle Kundendaten direkt an den Betrüger übermittelte, ersetzt wurde.
Daher wäre es wünschenswert, persönliche sicherheitsrelevante Daten nur in Geräte
eingeben zu müssen, welche sich im persönlichen Besitz befinden und über die der
Nutzer selbst die Kontrolle hat.
1.1.2
Aufgabe
Mobile Geräte wie z.B. Mobiltelefone, welche immer mehr zu Gegenständen des alltäglichen Gebrauchs werden, scheinen als Plattform zur Lösung dieser beiden Probleme
geeignet zu sein.
Aufgabe dieser Diplomarbeit ist es zu untersuchen, inwieweit mobile Geräte bereits
heute zur Erfüllung dieser Aufgabe geeignet sind und wie sie gegebenenfalls erweitert
werden müssen. Auf Grundlage dieser Ergebnisse ist ein Konzept entstanden, welches
mobile Geräte zu einer Plattform für ein universelles Authentifikationsystem und ver”
trauenswürdiges“ Terminal erweitert.
1.2. AUTHENTIFIZIERUNGSSYSTEME
1.2
7
Authentifizierungssysteme
Um die Anforderungen für ein solches Vorhaben zu definieren, ist es notwendig die
einzelnen Schritte und die beteiligten Komponenten an einem Authentifikationsprozeß
zu analysieren.
1.2.1
Allgemeiner Authentifikationsprozeß
Für jede Art von sicherheitsrelevanten Vorgängen ist ein Authentifizierungsprozeß notwendig. Im einfachsten Falle sind daran beteiligt:
• Benutzer
• Token
• Point of Authentification
• Interaktions-Medium
Je nach Anwendungsfall und geforderter Sicherheit weist sich der Nutzer gegenüber dem
Point of Authentification (PoA) mittels eines Tokens als berechtigt aus und umgekehrt.
Einfacher Authentifikationsprozeß anhand
eines einfachen Beispiels
Allgemeines Authentifikations-Schema
Benutzer
PoA
Point of Authentication
Benutzer
initieren
Point of Authentication
Token
Token
authentifiziert
sich mittels
Authentifikation
beim
überprüfen
überprüfen
Authentifikation
überprüft Token
agieren
gewährt Zutritt
Token
InteraktionsMedium
agieren
Abbildung 1.2: Authentifizierung Grundschema
Eine Partei, in der Regel der Benutzer, initiiert den Authentifizierungsprozeß. Dies
kann wie in Abbildung 1.2 durch direkten mechanischen Einsatz des Tokens am PoA
geschehen. Nach erfolgreicher Überprüfung der Authentizität durch den PoA, kann
zwischen Benutzer und PoA jede Form von Interaktion stattfinden. Im obigen Beispiel
ist dies die Entscheidung zwischen dem Auf- oder Abschließen einer Türe. Sie findet
hier durch die Drehrichtung des Schlüssels statt. Sie kann aber auch einen komplexen
Vorgang wie die Bedienung eines Geldautomaten beinhalten. Schließlich findet am Ende
des Prozesses eine Reaktion statt. Im Beispielfall das Öffnen bzw. Schließen der Türe.
8
Die einzelnen Schritte eines Authentifikationsprozesses sind somit:
• initiieren
• überprüfen
• interagieren
• reagieren
Der gesamte Vorgang erfordert die Kommunikation von Benutzer und PoA. Dazu ist
eine Form von Interaktions-Medium notwendig, welches im Abbildung 1.2 als breiter
gelber Pfeil dargestellt ist.
Bei erhöhten Sicherheitsanforderungen kann die Authentifikation auch gegenseitig erfolgen (mutual Authentification), indem auch der PoA seine Identität dem Benutzer
gegenüber nachweisen muß.
1.2.2
Sicherheitstoken
1.2.2.1
Untergliederung
Der einfachste und natürlichste Authentifizierungsfall ist jener, bei dem eine Person
der anderen persönlich bekannt ist und sie alleine an ihrem Aussehen erkannt wird. Da
dies jedoch in den seltensten Fällen möglich ist, führt man standardisierte, meist auch
maschinenlesbare Token ein, welche die Authentifizierung ermöglichen.
Dabei können grob zwei Gruppen von Token unterschieden werden:
• gegenständliche Token
• personengebundene Token
Die gebräuchlichste Form sind heute gegenständliche Token. Allein deren Besitz
wird als Authentifizierungsmerkmal herangezogen. Beispiele hierfür sind Schlüssel,
Magnetstreifen-Karten oder der Studentenausweis.
Personengebundene Token identifizieren eine Person durch Merkmale, welche nur sie
haben kann. Dies wird heute meist in Form wissensbasierender Token realisiert. Das
Wissen einer eindeutigen Kennung und eines geheimen Passworts beweist die Berechtigung der Person. Zu dieser Gruppe gehören auch die biometrischen Verfahren, welche
unveränderliche und eindeutige physikalische Merkmale einer Person wie z.B. Fingerabdruck, Sprachspektrum oder das Muster der Augeniris auswerten. Diese Verfahren
zählen zu den sichersten und vielversprechendsten für die Zukunft. Sie sind im Augenblick jedoch noch weitgehend Gegenstand der Forschung.
Für Systeme, in welchen erhöhte Sicherheit gefordert ist, wird meist eine Kombination
aus gegenständlichen und wissensbasierenden Token eingesetzt. So ist zum Betrieb eines
1.2. AUTHENTIFIZIERUNGSSYSTEME
9
Mobiltelefons der Besitz einer Chipkarte und das Wissen einer geheimen PIN Nummer
notwendig.
1.2.2.2
Beispiele
• Magnetstreifen-Karte
Magnetstreifen-Karten bestehen aus einem Plastik-Trägermaterial mit einem auf
ihrer Rückseite angebrachten Magnetstreifen, welcher auf 3 Spuren permanent
Informationen speichern kann. Diese sind ohne weitere Sicherheitsvorkehrungen
zu lesen und zu beschreiben.
Da Kartenleser und Leerkarten“ frei erhältlich sind, ist es problemlos möglich
”
einfache Magnetkarten zu kopieren. Zur Erhöhung der Sicherheit wurde bei den
EC-Karten ein zusätzliches moduliert maschinenfähiges Merkmal“ (MM) außer”
halb des Magnetstreifens in das Kartenträgermaterial eingebracht. Dieses Merkmal kann weder trivial kopiert noch ausgelesen werden. Da die darin enthaltenen
Informationen in die Berechnung einer Prüfsumme über die auf der Karte gespeicherten Daten einfließen, kann der Karteninhalt auch nicht unbemerkt verändert
werden. Dieses Merkmal wird jedoch an Geldautomaten im Ausland nicht überprüft, womit auch dies kein wirksamer Schutz vor Betrug ist.
• wissensbasierende Token
Wissensbasierende Token sind zwar in hohem Maße personengebunden, jedoch
weisen sie in der realen Nutzung erhebliche Schwachpunkte auf. Aus Gründen
der einfacheren Merkbarkeit wählen viele Nutzer oft schwache“ Paßwörter, wel”
che mit geringem Wissen aus dem persönlichem Umfeld der jeweiligen Person
leicht durch raten herauszufinden sind. Beispiele hierfür sind z.B. Namen der
Frau/Freundin, Geburtsdaten oder Telefonnummern. Dazu kommt, daß diese
Paßwörter in irgendeiner Form in den PoA eingegeben werden müssen. Da dies
meist über frei zugängliche Tastaturen erfolgt, ist hier auch das Ausspähen ein
ernstzunehmendes Problem.
• mechanische Schlüssel
Das unerlaubte Kopieren konventioneller Schlüssel kann zwar durch mechanische Maßnahmen erheblich erschwert, jedoch, genügend technischen Aufwand
und handwerkliches Geschick vorausgesetzt, nicht verhindert werden. Da allein
der Besitz des Schlüssels zur Authentifikation ausreicht, ist hier keinerlei Personenbindung vorhanden.
10
1.3
Überblick - Mobile Geräte
Ein wichtiger Bestandteil dieser Arbeit ist die Bestandsaufnahme der heute im mobilen Bereich verfügbaren Technologien sowie die Untersuchung ihrer Tauglichkeit als
Plattform für ein zentrales Authentifizierugssystem. Dazu werden in diesem Abschnitt
typische Vertreter aus den einzelnen Gerätebereichen kurz vorgestellt und die relevanten Ergebnisse am Ende in tabellarischer Form zusammengefaßt.
Vielfach sind in mobilen Geräten bereits lokale Übertragungstechnologien integriert,
die sich zur Kommunikation mit dem PoA nutzen lassen. Auch diese werden jeweils in
Form einer kurzen Einführung behandelt.
1.3.1
Leistungsmerkmale handelsüblicher mobiler Geräte
Dieser Abschnitt soll keine einzelnen Produkte vollständig vorstellen. Vielmehr werden
gezielt Eigenschaften, welche im Hinblick auf ein Authentifizierungssystem relevant
sind, herausgegriffen. Die Auswahl der betrachteten Geräte erfolgte zwar mit der Vorgabe, für die einzelnen Gerätebereiche repräsentative Vertreter zu finden, ansonsten
aber vollkommen willkürlich. Anstelle der hier vorgestellten, hätten mit der selben
Berechtigung ebenso Geräte anderer Hersteller untersucht werden können.
Die Betrachtung erfolgte dabei im Hinblick auf folgende Merkmale:
• Fähigkeiten zum Benutzerdialog
• Marktverbreitung
• Chipkartenleser
• Hardware-Erweiterungsmöglichkeiten
• lokale Kommunikationsschnittstellen
• Programmierbarkeit
1.3.1.1
Mobiltelefone
Mobiltelefone haben von all den untersuchten Geräten die größte Verbreitung in der
Bevölkerung. Laut Forester Research gibt es zum Entstehungszeitpunkt dieser Arbeit
allein in Europa 117 Millionen Mobiltelefonbenutzer. Darüberhinaus besitzen diese, als
einzige Geräteklasse, bereits eindeutige Identifizierungsmerkmale in Form der persönlichen Daten der SIM Karte und der IMEI Gerätenummer.
Auch wenn die meisten Mobiltelefone heute bereits das WAP 1.1 Protokoll unterstützen, sind die Darstellungsmöglichkeiten ihrer Displays noch sehr beschränkt.
Durchschnittlich können sie 4 bis 6 Zeilen Text zu je 16 bis 20 Zeichen darstellen.
1.3. ÜBERBLICK - MOBILE GERÄTE
11
Neuere Geräte haben vermehrt graphikfähige Displays und eine menugestützte Bedienungsführung.
Eine Infrarotschnittstelle zur Kommunikation mit anderen Geräten ist bei Mobiltelefonen ab Geräten der Mittelklasse Standardaustattung. Noch nicht alle Hersteller
unterstützen dabei auch IRDA OBEX, jedoch setzt sich dieser Standard auch hier
immer mehr durch.
Mittels seperat erhältlicher Datenkabel steht bei den Vielfach auch eine serielle RS232
Schnittstelle zur Verfügung.
Abbildung 1.3: Beispiele weit verbreiteter Mobiltelefone
Abbildung 1.3 zeigt mit dem Siemens S35 und dem Nokia 6210 zwei weitverbreitete
Vertreter dieser Gerätekathegorie. Die Besonderheit des Nokia 6210 ist seine Erweiterbarkeit um eine Bluetooth Schnittstelle. Dies geschieht, wie bei Nokia üblich, durch
einen Funktions-Akku“. Es gehöhrt damit zu einem der ersten Mobiltelefone, welche
”
den Bluetooth Standard unterstützen.
1.3.1.2
Handhelds
Handhelds waren ursprünglich als elektronischer Ersatz für Terminplaner, Notizblock
und Adreßbuch gedacht. Sie entwickelten sich jedoch schnell zu universellen und leistungsfähigen Taschencomputern. Heute besitzen solche Geräte leistungsfähige Betriebssysteme, graphische Bedienoberflächen, Schnittstellen zur Hardwareerweiterung,
genügend Arbeitsspeicher und Rechenleistung auch für komplexere Anwendungen und
es existieren ausgezeichnete Werkzeuge zur Entwicklung eigener Software.
PalmOS-Geräte
1996 kamen die ersten Geräte der Palm Serie auf den Markt. Ursprünglich von U.S.
Robotics entwickelt, wurden sie nach Übernahme der Firma durch 3COM unter de-
12
ren Namen weitervertrieben. Die Geräte basieren auf der Motorola Dragonball CPU,
welche im Grunde ein Prozessor aus der 68000er Reihe mit etlichen integrierten Peripheriecontrollern ist.
Die Eingabe erfolgt über eine Handschrifterkennung. Bis heute sind einige neue Generationen dieser Modellreihe entwickelt worden. So verfügen aktuelle Geräte über 8
MB Speicher, Standard-Infrarotschnittstelle mit Unterstützung des OBEX Protokolls,
Erweiterungsmodule sowie schnellere CPUs. Das Betriebsystem PalmOS ist eine Eigenentwicklung des Herstellers. Da es speziell auf die Anforderungen mobiler Geräte
ausgelegt ist, kennzeichnen es eine sehr effiziente Nutzung der vorhandenen Resourcen
und eine hohe Stabilität.
Abbildung 1.4: Beispiele von PalmOS-Geräten
Auch von anderen Herstellern wie z.B. Handspring werden Geräte, welche PalmOS als
Betriebsystem nutzen, hergestellt. Die Handspring-Geräte zeichenen sich durch eine
sehr gute Erweiterbarkeit mittels eines integrierten Expansionsslots aus. Es existieren
dafür bereits Module, die einen solchen PDA zum vollständigen Mobiltelefon erweitern.
An Geräte, welche nicht über diesen speziellen Slot verfügen, können Erweiterungsmodule über die RS232 Schnittstelle angeschlossen werden. Die PalmOS-Geräte gehören
heute zu den am weit verbreitetsten PDAs.
WindowsCE-Geräte
Handhelds, die WindowsCE als Betriebsystem verwenden, sind im Sektor der Pocket
PCs angesiedelt. Sie tendieren vom Leistungsumfang und Preis mehr zu Notebooks.
Ein typischer Vertreter dieser Geräteklasse ist der Compaq iPAQ. Mit einer CPUTaktfrequenz von 206 MHz (Intel StrongARM SA-1110 32-Bit-RISC-Prozessor), 16 MB
13
Hauptspeicher und 16 MB Flash Memory liegt er deutlich über den Leistungsdaten der
Palm PDAs.
Abbildung 1.5: Beispiele von WindowsCE-Geräten
Auch diese Geräte sind mit einer Standard-Infrarotschnittstelle und OBEX Unterstützung ausgestattet. Desweiteren verfügen sie über serielle RS232 und USB Ports.
Mittels sogenannter Expansionpacks, auch Jackets genannt, lassen sie sich prinzipiell
um beliebige Hardware erweitern. Diese Jackets sind Plastikhüllen, in welche das gesamte Gerät eingesteckt wird. Sie enthalten die Erweiterungshardware. Mit den derzeit
erhältlichen Jackets läßt sich der iPAQ um die Fähigkeit PC-Cards1 und CF-Cards2 verwenden zu können erweitern. Damit ist z.B. die Unterstützung des Bluetooth-Standards
jederzeit realisierbar.
EPOC-Geräte
EPOC ist ein 32-Bit-Multitasking-Betriebsystem und wurde von der Firma Psion für
deren Handheld Geräteserie entwickelt. Der auffälligste Unterschied zu den anderen
Handhelds ist die vollwertige alphanumerische Tastatur dieser Geräte. Zusätzlich ist
auch die Eingabe mittels Pen“ und Touchscreen“ möglich.
”
”
Von Rechenleistung und Speicheraustattung liegen sie zwischen den PalmOS und den
WindowsCE-Geräten. Zur Kommunikation stehen IrDA und RS232 Schnittstelle zur
Verfügung.
Mittels eines Compact Flashcard Slots kann ihre Speicherfähigkeit erweitert werden.
Weitere Erweiterungsports existieren jedoch nicht.
1
2
PCMCIA
Compact Flash Cards
14
Abbildung 1.6: Beispiele von EPOC-Geräten
Obwohl EPOC-Geräte sehr gut auf die mobilen Anforderungen zugeschnitten sind,
haben sie nicht zuletzt wegen ihres vergleichsweise hohen Preises keine so große Verbreitung gefunden wie ihre Mitbewerber.
1.3.1.3
Digitalkameras
Digitalkameras erfahren seit kurzem durch den Preisverfall und die verbesserte Bildqualität bei Privatanwendern einen Verkaufsboom. Auch diese Geräte bringen grundsätzlich die notwendigen technischen Voraussetzungen mit, welche sie für ein mobiles
Autentifizierungssystem geeignet machen.
Sehr viele dieser Kameras besitzen ein relativ hochauflösendens Farbdisplay zur Begutachtung der aufgenommenen Bilder. Darauf ist eine sehr gute Darstellung von Informationen möglich.
Abbildung 1.7: Beispiel einer Digitalkamera
Durch die wenigen Bedientasten ist nur eine menügeführte Eingabe sinnvoll. Damit
gibt es keine Möglichkeit, eine PIN Nummer direkt mittels eines Zifferntastenblocks
einzugeben. Die Rechenleistung der integrierten CPU dürfte (hier waren leider keine
Herstellerangaben über die verwendeten Typen, den zur Verfügung stehenden Infor-
15
mationsmaterialien zu entnehmen) problemlos für Authentifikationsanwendungen ausreichen.
Zur Kommunikation mit dem Heim PC verfügen Digitalkameras über serielle RS232
oder USB Schnittstellen. Diese können, geeignete Firmware vorausgesetzt, auch zur
Erweiterung um andere Hardwarekomponenten genutzt werden.
Manche Kameras bieten darüberhinaus auch eine IrDA Schnittselle.
1.3.1.4
Fazit
Grundsätzlich bringen alle betrachteten Geräte die Voraussetzungen für eine mobile
Authentifikation mit sich. Jedoch bedarf es in allen Fällen zusätzlicher Software bzw.
Erweiterungen der integrierten Firmware.
Siemens S35
Nokia 6210
Palm Vx
Compaq
iPAQ H3100
Cannon
Powershot
S20
(Mobiltelefon)
(Mobiltelefon)
(PDA)
(PDA)
(Digitalkamera)
Dialogfähigkeit
gut (ausreichnd.
Display, Zifferntastatur)
gut (ausreichnd.
Display, Zifferntastatur)
sehr gut
sehr gut
eingeschränkt
(nur
wenige
Bedientasten)
Marktverbreitung
sehr hoch
sehr hoch
relativ hoch steigende Tendenz
relativ hoch steigende Tendenz
eher gering - jedoch steigend
Chipkartenleser
vorhanden - nur
SIM
vorhanden - nur
SIM
nicht vorhanden
- erweiterbar
nicht vorhanden
- erweiterbar
nicht vorhanden
- theoretisch erweiterbar
Hardware Erweiterbarkeit
eingeschränkt
eingeschränkt
gut
gut
sehr
eingeschränkt
lokale Kommunikationsschnittstellen
IrDA
IrDA und Bluetooth
IrDA
IrDA
keine
Programmierbarkeit
nur SIM Toolkit
nur SIM Toolkit
sehr gut
sehr gut
keine
Tabelle 1.1: Vergleich verschiedener mobiler Gräte
Aufgrund der freien Programmierbarkeit läßt sich dies am einfachsten mit PDAs realisieren. Die notwendige Software kann einfach in Form einer neuen Applikation installiert werden. Darüberhinaus besitzt diese Geräteklasse auch die beste HardwareErweiterungsfähigkeit und die, abgesehen von Laptops, welche aufgrund ihrer Größe
gar nicht erst in die Betrachtung einbezogen wurden, komfortabelste Mensch-Maschine
Schnittstelle.
Digitale Kameras werden voraussichtlich trotz steigender Verkaufszahlen wie auch nor”
male“ Fotoapparate nicht zum täglichen mobilen Begleiter werden. Aus diesem Grund
und wegen ihrer relativ schlechten Eingabemöglichkeiten scheinen sie als mobiles Authentifzierungssystem wenig erfolgversprechend.
16
Mobiltelefone sind die derzeit weit verbreitetsten mobilen Geräte. Zwar sind sie nicht
so einfach programmierbar und ihr human Interfaces“ ist nicht so flexibel wie das
”
der PDAs, jedoch im ausreichendem Maße geeignet. Notwendige Software muß derzeit
noch als Erweiterung der Firmware realisiert werden.
Mit dem absehbaren Zusammenwachsen der Produktgruppen PDA und Mobiltelefon
wird diese neue Gerätegeneration die optimale Plattform für ein System zur mobilen
Authentifikation sein. Der Mobiltelefonhersteller Sagem hat mit dem Modell WA 3050
bereits ein derartiges Gerät vorgestellt. Es handelt sich um eine Kombination aus GSM
Mobiltelefon und WindowsCE basierendem Pocket PC.
1.3.2
Lokale Übertragungstechnologien
Nahezu alle PDAs und immer mehr Mobiltelefone sind mit lokalen Übertragungstechnologien ausgerüstet. Diese werden heute meist zum drahtlosen Anschluß von Peripheriegeräten wie z.B. Modem oder Drucker, zum Austausch von Datenobjekten oder zur
Synchronisation mit dem PC genutzt. Entsprechend ausgerüstete Mobiltelefone können
auf diese Weise PDAs als Modem dienen. Die Möglichkeiten lokaler Kommunikation
gehen jedoch weit über die heutige Verwendung hinaus.
1.3.2.1
IrDA
Die IrDA Technologie ist hiervon die bisher am weitesten verbreitete Technik. Sie wurde ursprünglich von der Firma Hewlett-Packard ins Leben gerufen, welche immer noch
das Patent auf die physikalische Schicht des Protokolls besitzt. Die weitere Entwicklung
wird von der Infrared Data Association, einem Konsortium aus Hard- und Softwareherstellern, getragen.
Sie hat zum Ziel eine kostengünstige, zuverlässige, energiesparende und herstellerübergreifend-kompatible Technologie zu etablieren, mittels welcher Computer und
Peripheriegeräte, ohne Kabel verbunden werden können
Das physikalische Medium zur Kommunikation ist Infrarotstrahlung. Es existieren zwei
Standards zur Implementierung der physikalischen Schicht. IrDA SIR3 ermöglicht eine
asynchrone halb-duplex Verbindung mit Datenraten von 2400 bis 115200 Bit/s. Dagegen ermöglicht FIR4 einen synchronen Datenaustausch mit bis zu 4 MBit/s. Es gibt
bisher nur sehr wenige Geräte, welche den FIR Standard unterstützen. Der große Erfolg
von IrDA SIR läßt sich mit der sehr einfachen und kostengünstigen Hardwareimplementierung erklären. Neben dem eigentlichen Ir-Transceiverbaustein ist ein serieller
UART5 Baustein notwendig. Ein solcher UART ist bereits in den meisten Geräten, die
mit einer serielle Schnittstelle wie z.B. RS-232 ausgestattet sind, vorhanden.
3
Serial Infrared
Fast (Serial) Infrared
5
Universal Asynchronous Receiver-Transmitter
4
17
Mittels IrDA können Daten bis zu einer Entfernung von maximal zwei Meter übertragen werden. Darüberhinaus ist eine direkte Ausrichtung der beiden IrTransceiver
aufeinander sowie freie Sichtverbindung notwendig. Die exakten Spezifikationen sind
in [PQT98] nachzulesen.
Applications
IrLAN
OBEX
IrCOMM
IAS
Tiny TP
IrLMP
IrLAP
physical layer
Abbildung 1.8: IrDA Protokoll-Stack
Fester Bestandteil einer IrDA konformen Implementierung sind auch die beiden Protokolle IrLAP [WHN+ 96] und IrLMP [SWN96] auf Schicht zwei des ISO/OSI Netzwerkmodells. Darüberhinaus existieren noch eine Vielzahl an weiteren Protokollspezifikationen auf höheren Schichten, die ein weites Feld an Einsatzmöglichkeiten abdecken
[MSK].
1.3.2.2
Wireless LAN
Die Entwicklung des Wireless LAN Standards hatte zum Ziel, den Zugriff auf LAN
Infrastrukturen unabhängig von Kabeln zu ermöglichen. 1997 veröffentlichte das IEEE6 dazu den endgültigen Entwurf mit der Bezeichnung IEEE 802.11 [oEE99a]. Wie
bereits seine Bezeichnung zeigt, stellt dies eine Erweiterung des bekannten EthernetStandards auf eine drahtlose Variante dar.
Zur Implementierung der physikalischen Übertragung existieren Spezifikationen für
zwei unterschiedliche Medien.
• Infrarotstrahlung
• Funkwellen
Die auf Infrarot basierende physikalische Schicht nutzt, ähnlich wie bei IrFIR, PPM7
zur Übertragung und erlaubt Datenraten bis zu 2 MBit/s. Diese Technik hat jedoch
heute kaum Bedeutung.
6
7
Institute of Electrical and Electronic Engineering
Pulse Position Modulation
18
Die Übertragungstechnik via Funk arbeitet im 2,4 GHz ISM8 Band, welches weltweit
lizenzfrei genutzt werden darf. Diese Nutzung ist an einige Auflagen gebunden. Abgesehen davon, daß die Sendeenergie beschränkt ist, muß sie auch gleichmäßig über das
gesammte dafür vorgesehene Spektrum verteilt werden.
Um das zu erreichen, erlaubt IEEE 802.11 zwei sogenannte Spread Spectrum Verfahren.
• FHSS:9 Diese Technik nutzt herkömmliche Schmalband-Übertragungsverfahren, wechselt jedoch, einem dem Sender und Empfänger bekannten Schema folgend, die Übertragungsfrequenz. Es müssen 79 unterschiedliche Trägerfrequenzen verwendet werden, wobei die maximale Verweildauer auf einer Frequenz 20
ms beträgt. Der Betrieb mehrerer unabhängiger Funk LANs, innerhalb gegenseitiger Reichweite, ist durch die Verwendung unterschiedlicher Sprungsequenzen
möglich. Die angewendete Modulationstechnik ist GFSK10
• DSSS:11 Hierbei wird die Bandbreite des Nutzsignals künstlich verbreitert, indem man es mit einem Spreizcode faltet. IEEE 802.11 verwendet dazu eine sog.
Barker-Sequence, dabei wird jedes Nutzbit durch eine 11 Bit lange Sequenz repräsentiert, wodurch die Information über das gesammte Spektrum verteilt wird.
Durch Kenntnis des Spreizcodes kann der Empfänger aus dem, unter dem Rauschpegel liegendem Übertragungssignal, das Nutzsignal wiedergewinnen. Der gegenseitig störungsfreie Betrieb unterschiedlicher WLANs12 ist durch unterschiedliche
Barker-Sequenzen möglich. Es können BPSK13 und QPSK14 als Modulationstechniken verwendet werden.
Mittels beider Verfahren kann eine maximale Datenrate von 2 MBit/s erreicht werden.
Die Spezifikation beinhaltet neben der physikalischen Schicht auch die beiden Schicht2-Protokolle MAC15 und LLC16 . Während in diesen unteren Schichten viele Besonderheiten des drahtlosen Mediums berücksichtigt werden müssen, verhalten sich IEEE
802.11 Netzwerkkarten für Anwendungen oberer Schichten wie normale kabelgebundene Ethernet-Schnittstellen.
Im September 1999 wurde mit dem Standard IEEE 802.11b [oEE99c] eine Erweiterung der physikalischen Schicht verabschiedet. Diese beschränkt sich auf das DSSS
Verfahren und erhöht durch ein weiterentwickeltes Kodierungsverfahren CCK17 die
Übertragungsdatenrate auf bis zu 11 MBit/s.
8
Industry, Scientific, and Medical - 2,402 bis 2,480 GHz
Frequency Hopping Spread Spectrum
10
Gaussian Frequency Shift Keying
11
Direct Sequence Spread Spektrum
12
Wireless LANs
13
Binary Phase Shift Keying
14
Quadrature Phase Shift Keying
15
Media Access Control
16
Logical Link Control
17
Complementary Code Keying
9
19
Applications
OBEX
HTTP
SMTP ...
TCP/IP
Logical Link Control (LLC)
Medium Access Control (MAC)
DSSS
physical
FHSS
physical
IR
physical
Abbildung 1.9: IEEE 802.11 Wireless LAN Protokoll-Stack
Darüberhinaus existiert die Norm IEEE802.11a [oEE99b], welche eine Übertragung
im 5 GHz Band mit bis zu 54 MBit/s definiert. Bisher waren Hersteller, vor allem aus
Kostengründen, sehr zurückhaltend derartige Geräte zu entwickeln. Mit der Verfügbarkeit preisgünstiger geeigneter Chipsets in CMOS Technologie in naher Zukunft wird
sich dies voraussichtlich rasch ändern.
IEEE 802.11 konforme Geräte verschiedener Hersteller sind, sofern sie dieselbe Übertragungstechnik nutzen, prinzipiell untereinander kompatibel, was sich jedoch in der
Praxis oft als schwierig erweist.
1.3.2.3
Bluetooth
1994 wurde bei der Firma Erricson eine Studie in Auftrag gegeben welche Technologien zum drahtlosen Ersatz von Verbindungskabeln zwischen elektronischen Geräten
untersuchen sollte. Aufgrund der vielversprechenden Ergebnisse wurde 1998 die Bluetooth SIG18 gegründet. Gründungsmitglieder waren die Firmen Erricson, Nokia, IBM,
Toshiba und Intel. Diese veröffentlichten im September 1999 die verbindlichen Spezifikationen [SIG01a] [SIG01b] in der Version 1.0.
Der Name Bluetooth rührt im übrigen vom Harald Blåtand (engl. Bluetooth) einem Vikingerkönig des 10. Jahrhunderts her, welcher große Teile Skandinaviens christianisierte. Diese Namensgebung zollt dem großen skandinavischen Anteil an der Entwicklung
Tribut.
Der ursprüngliche Einsatzzweck dieser Technologie ähnelt dem von IrDA sehr. Ihr
Ansatz ist jedoch universeller und soll als Kabelersatz für alle Informationen transportierenden Kabelverbindungen dienen. Durch die Verwendung von Funkwellen als Kommunikationsmedium umgeht es die Einschränkungen, der direkten Sichtverbindung und
18
Special Interest Group
20
der exakten Ausrichtung der Kommunikationspartner, welche IrDA anhaften. Im Gegensatz zu IrDA unterstützt Bluetooth auch Point-to-Multipoint Verbindungen und
bietet mit etwa 1 MBit/s im Vergleich zu IrDA SIR eine wesentlich höhere Übertragungsgeschwindigkeit. Wie IrDA ist Bluetooth als Technologie für den Einsatz in
Massenprodukten“ konzipiert. Daher wurde auf eine preisgünstige Implementierung
”
Wert gelegt. Komplette Bluetooth Module kosten heute zwischen 20 und 30 US Dollar.
In einer erwarteten Massenproduktion wird der Preis auf einen Bruchteil davon sinken.
Zudem sind mehrere Betriebsmodi spezifiziert, mittels welcher sich der Stromverbrauch
auf das minimal Benötigte beschränken läßt. Dies ist im Haupteinsatzbereich, den mobilen Geräten, äußerst wichtig.
Bluetooth arbeitet wie auch Wireless LAN IEEE 802.11 im lizenzfreien 2,4 GHz ISM
Band. Die Verteilung der Sendeenergie wird hier ausschließlich durch das Frequenzsprung Verfahren FHSS erreicht. Eine weitere Gemeinsamkeit mit IEEE 802.11 ist die
GFSK Modulation des Signals. Innerhalb des gegeben Rahmens von drei Leistungsklassen lassen sich mit Bluetooth-Geräten Reichweiten zwischen 10 cm und 100 m
erreichen. Der typische Einsatzradius liegt bei etwa 10 m, wobei die Auslegung auf die
Kommunikation im Nahfeld deutlich wird.
Bluetooth spezifiziert verschiedene Übertragungskanäle. Eine Kommunikationsverbindung kann aus bis zu 3 synchronen Kanälen SCO19 mit jeweils 64 kBit/s und einem
asynchronen Kanal ACL20 mit typischerweise 721 kBit/s und 57,6 kBit/s in der Gegenrichtung bestehen. Der asynchrone Kanal kann wahlweise auch symmetrisch mit
432,6 kBit/s in beiden Richtungen betrieben werden. Die synchronen Kanäle sind
hauptsächlich zur Sprachübertragung gedacht. Auf ihnen findet bei Paketverlust, im
Gegensatz zum ACL Kanal, keine Neuübertragung statt.
Applications
JINI
SDP
OBEX
TCP/IP
RFCOMM
L2CAP
Link Manager
ACL
SCO
baseband
bluetooth radio
Abbildung 1.10: Bluetooth Protokoll Stack
Bluetoothfähige Geräte haben die Eigenschaft selbständig zu erkennen, ob ein geeigneter Kommunikationspartner in Reichweite ist, um automatisch eine Verbindung zu
19
20
Synchronous Connection Orientated
Asynchronous Connectionless
1.4. KRYPTOLOGIE
21
diesem aufzubauen. Einen Zusammenschluß von Geräten, die auf dem selben Übertragungskanal arbeiten, bezeichnet man als Piconet. Ein solches Piconet kann aus maximal
8 Geräten bestehen. Ein Gerät ist hierbei immer der Master, welcher die Kommunikation der übrigen Slaves steuert. Mehrere Piconet können sich zu einem Scatternet
zusammenschließen, indem sie einen gemeinsamen Slave zur Kommunikation nutzen.
Insgesamt bietet Bluetooth, durch eine hohe Frequenzsprungfrequenz und einer im Vergleich zu Wireless LAN kürzeren Packetlänge, eine sehr robuste Übertragungstechnik.
Bei einer hohen Verbreitung von Bluetooth Anwendungen ist daher im Nahbereich eher
mit Störungen von IEEE 802.11 Installationen zu rechnen als umgekehrt.
1.3.2.4
Weitere Verfahren
Weitere in diesem Zusammenhang nennenswerte lokale Übertragungsverfahren sind:
• HyperLAN2
• HomeRF
Aufgrund der derzeit geringen Verbreitung dieser Technologien werden diese hier nicht
weiter betrachtet.
1.3.2.5
Fazit
Prinzipiell sind alle vorgestellten Verfahren als Kommunikationsmittel für ein Authentifizierungsystem nutzbar. Wireless LAN ist von seiner Zielsetzung mehr auf klassische
LAN Anwendungen ausgelegt und daher mit einem durchschnittlichen Preis von derzeit ca. 300 DM pro Netzwerkadapter für Geräte der betrachteten Kategorie weniger
geeignet.
IrDA und Bluetooth sind von ihren Eigenschaften gleichermaßen gut einsetzbar. Wobei IrDA kurzfristig aufgrund seiner bereits hohen Verbreitung die aussichtsreichere
Technologie ist. Bluetooth ist dagegen die universellere und komfortablere Variante.
Sie hat die Voraussetzungen in Zukunft weitgehend IrDA abzulösen. Während einer
Übergangsphase werden beide Technologien nebeneinander existieren.
1.4
1.4.1
Kryptologie
Einführung
Kryptologie ist der Oberbegriff für die beiden wissenschaftlichen Disziplinen Kryptographie und Kryptoanalyse. Während die Kryptologie Verfahren entwickelt, die
es ermöglichen, Nachrichten über öffentliche Kanäle zwischen Parteien auszutauschen,
22
ohne daß Unbefugte den Inhalt erfahren können, versucht die Kryptoanalyse diese
Verfahren zu brechen.
Die Verschlüsselung ist der Vorgang, welcher die ungeschützte Nachricht im Klartext (Plaintext) in den Chiffretext (Cipertext) überführt. Die Entschlüsselung
kehrt dies wieder um.
Damit zwei Partner auf diese Weise sicher miteinander kommunizieren können, müssen
sie sich zuvor über ein einheitliches Verschlüsselungsverfahren geeinigt haben.
Darüber hinaus benötigen sie ein Geheimnis, den sogenannten Schlüssel. Ob Sender
und Empfänger über ein gemeinsames Geheimnis verfügen müssen, hängt vom eingesetzten Verfahren ab. Die Menge aller, für ein Verfahren möglicher Schlüssel, heißt
Schlüsselraum.
Es ist immer davon auszugehen, daß ein möglicher Angreifer Kenntnis über den zur
Verschlüsselung verwendeten Algorithmus erlangen wird, daher prägte bereits im 19.
Jahrhundert Kerckhoff die Maxime:
Die Sicherheit eines Kryptosystems darf nicht von der Geheimhaltung des
Algorithmus abhängen. Die Sicherheit gründet sich nur auf die Geheimhaltung des Schlüssels.
Abgesehen von der reinen Verschlüsselung, sind mit den Methoden der Kryptographie
auch folgende wichtige Sicherheitsdienste zu realisieren:
• Vertraulichkeit: Dies ist obig beschriebene Grundmotivation der Kryptologie.
Der Inhalt eines Dokuments oder einer Nachricht ist vor unbefugter Kenntnisnahme zu schützen.
• Authentikation: Der Empfänger muß sich von der Identität des Absenders oder
Verfassers einer Nachricht, zweifelsfrei überzeugen können.
• Integrität: Wichtig ist hierbei auch die Sicherstellung, daß der Inhalt einer Nachricht während der Übertragung nicht, etwa durch Einwirkung Dritter, verändert
worden ist.
• Verbindlichkeit: Ist die Identität eines Verfassers festgestellt, soll er auch nicht
die Möglichkeit besitzen sie zu leugnen.
Kryptographische Verfahren sind die Grundlage zur Authentikation und zur sicheren
Kommunikation zwischen Nutzer und PoA im Konzept dieser Arbeit. Dieses Kapitel
soll einen Überblick über die Methoden der Kryptologie vermitteln, indem es wichtige
Verfahren kurz vorstellt.
Es erhebt keinen Anspruch auf Vollständigkeit. Eine umfassendere Betrachtung dieses
Gebietes und vor allem auch der mathematischen Grundlagen ist in [Beu91] und [ldv00]
zu finden.
1.4. KRYPTOLOGIE
1.4.2
23
Kryptographische Grundverfahren
Die in der Einführung erwähnten Dienste, werden durch die verschiedenen kryptographischen Methoden und deren Kombinationen realisiert.
1.4.2.1
Stromverschlüsselung
Stromverschlüsselungsverfahren behandeln den Eingabetext zeichen- bzw. bitweise. Sie
sind gut in Hardware implementierbar und eigenen sich besonders zur Verschlüsselung
in Echtzeit. Ein Beispiel hierfür ist der Vernam-Ciper. Er basiert auf der Theorie des
one-time-pads. Ein one-time-pad bietet theoretisch und praktisch vollkommene Sicherheit. Jedes Bit der Nachricht wird mit einem zufällig erzeugtem Bit verknüpft. Das
hat jedoch zur Folge, daß der zur Dekodierung notwendige Schlüssel dieselbe Länge wie
die Nachricht selbst hat. Zudem ist es notwendig, diesen Schlüssel auf sicherem Wege
zu übertragen, was den Sinn der Verschlüsselung weitgehend in Frage stellen würde,
da mit demselben Aufwand auf dem sicheren Kanal die Nachricht selbst hätte übertragen werden können. Daher wird keine echte Zufallsfolge erzeugt, sondern ein PseudoZufallsgenerator mit bekannten Konfigurationsparametern verwendet. Diese Parameter
reichen zur Reproduktion der Zufallsfolge auf der Empfängerseite aus. Somit sind sie
der verwendete Schlüssel, womit sich die Sicherheit wieder auf die Kenntnis dieses
Schlüssels reduziert.
1.4.2.2
Blockverschlüsselung
In diese Kategorie fallen die meisten heute gebräuchlichen Verschlüsselungsmethoden.
Dabei wird der Klartext in Blöcke gleicher Größe aufgeteilt, welche dem verwendeten
Algorithmus als Eingabe dienen. Da gleiche Klartextblöcke in gleiche Chiffretextblöcke
überführt werden, ließen sich Rückschlüsse auf den Nachrichteninhalt ziehen. Bei der
Verschlüsselung von Kommunikationsprotokollen treten in Form von Paket-Headern in
regelmäßigen Abständen gleiche Informationen auf. Um diese offensichtliche Schwachstelle zu umgehen gibt es verschiedene Verfahren der Blockbildung:
• ECB (Electronic Code Book): Hier werden keinerlei Maßnahmen gegen dieses
Problem unternommen. Das hat den Vorteil, daß jeder Block unabhängig vom
anderen ist, und Übertragungsfehler sich nur auf den aktuellen Block beziehen.
• CBC (Ciper Block Chaining): Bei diesem Verfahren wird das Ergebnis der Verschlüsselung des vorhergehenden Blocks in die Verschlüsselung des nächsten miteinbezogen. Dadurch wird erreicht, daß gleiche Klartextblöcke niemals in gleichen
Cipertext Blöcken resultieren. Von Übertragungsfehlern sind jeweils der aktuelle
und der darauffolgende Block betroffen.
• CFB (Ciper Feedback): Dies ist eine stromorientierte Variante des CBC Verfahrens. Der vorangehende Chiffreblock dient als Eingabe. Das Ergebnis wird mit
24
einem Teil des nächsten Klartextblockes verknüpft. Die Eigenschaften sind ähnlich dem CBC, jedoch ist die Fehlerfortpflanzung nur noch die Blocklänge plus
der Länge des Teils des Klartextblockes.
• OFB (Output Feedback ): Auch dies ist eine stromorientierte Variante des CBC,
jedoch ohne Fehlerfortpflanzung.
Der Empfänger muß selbstverständlich neben dem korrekten Schlüssel auch über eine
entsprechend inverse Implementierung der Blockbildung verfügen, um den Klartext
wiederherzustellen.
1.4.2.3
Symmetrische Verfahren
Symmetrische Verschlüsselungen sind die am längsten bekannten Verfahren. Sie beruhen darauf, daß sowohl Sender als auch Empfänger über den selben Schlüssel verfügen,
welcher zum Ver- und Entschlüsseln benutzt wird. Es ist notwendig dieses Geheimnis
einmal auf sicherem Wege ausgetauscht zu haben, bevor eine verschlüsselte Kommunikation möglich wird. Ein Nachteil ist dabei, daß, sobald eine große Personengruppe
auf diese Weise miteinander kommunizieren möchte, eine sehr hohe Zahl an Schlüsseln
auszutauschen sind. Möchten
N
Personen jeweils mit jeder Person auf diese Weise
N
Nachrichten versenden, sind 2 = N (N2−1) Schüssel notwendig. Bei 1000 Personen sind
das bereits 499500 Schlüssel, die auf sicherem Wege übertragen worden sein müssen. Eine spontane Kommunikation mit bisher unbekannter Partnern ist damit, ohne spezielle
Schlüsselaustausch-Protokolle, unmöglich.
1.4.2.4
Asymmetrische Verfahren
Asymmetrische Verfahren können diese beiden Probleme lösen und ermöglichen erst
Dienste wie z.B. die digitale Signatur. Mit ihrer Entdeckung“ 1976 durch Whitfield
”
Diffie und Martin Hellmann sind sie eine relativ junge Technologie.
Jeder Teilnehmer eines asymmetrischen Verschlüsselungssystems benötigt zwei
Schlüssel. Einen geheimen private key, den nur er kennt und einen öffentlichen publickey. Das Verfahren wird deshalb als asymmetrisch bezeichnet, da eine, mit einem der
beiden Schlüssel kodierte Nachricht, nicht mit dem selben Schlüssel wieder dekodierbar
ist, sondern nur mit dem zugehörigem anderen Schlüssel. Der public-key kann somit
bedenkenlos veröffentlicht, und etwa in Form einer telefonbuchartigen Datenbank jedermann zugänglich gemacht werden. Möchten nun zwei Partner A und B miteinander
kommunizieren, so benötigen sie gegenseitig die jeweils öffentlichen Schlüssel. Wenn A
nun eine Nachricht mit dem public-key von B verschlüsselt, kann nicht einmal er selbst
sie wieder entschlüsseln, sondern nur B mit seinem private-key. Ein Kreis von N Personen benötigt somit nur noch 2N Schlüssel. Davon werden jeweils nur die öffentlichen
Schlüssel getauscht, wofür kein sicherer Kanal notwendig ist.
1.4. KRYPTOLOGIE
25
Zwischen private- und public-key besteht ein mathematischer Zusammenhang. Damit
das Verfahren sicher ist, muß das zugrundeliegende Problem jedoch so komplex sein, daß
eine Ableitung des privaten Schlüssels auch bei Einsatz hoher Rechenleistung nicht in
angemessener Zeit berechenbar ist (z.B. mehr als 109 Jahre in Anspruch nähme). Solche
komplexen Probleme sind z.B. die Faktorisierung großer Zahlen oder die Berechnung
des diskreten Logartithmus.
1.4.2.5
Hybride Verfahren
Alle heute bekannten asymmetrischen Algorithmen besitzen den Nachteil, daß sie sehr
viel Rechenleistung benötigen, und daher besonders auf Systemen mit eingeschränkten Resourcen langsam sind. Hybride Verfahren umgehen diesen Nachteil und erhalten trotzdem die Vorteile asymmetrischer Verfahren. Sie nutzen asymmetrische Verschlüsselung zu Beginn der Kommunikation um einen, zufällig gewählten, Session Key
für die folgende Übertragung auszutauschen. Dieser Session Key wird als Schlüssel für
die synchrone Verschlüsselung der eigentlichen Übertragung eingesetzt. Durch seine,
im Vergleich zur eigentlichen Nachricht mit 56 bis 128 Bit geringen Länge, ist dessen
asymmetrische Verschlüsselung nicht zeitkritisch.
1.4.2.6
Hash Funktionen
Einwege-Hash Funktionen bilden zu einer beliebig langen Nachricht eine individuelle
Prüfsumme fester Länge. Diese Prüfsumme ist eine Art einmaliger Fingerabdruck einer Nachricht, mittels welcher die Integrität der Nachricht nachgewiesen werden kann.
Typische Längen für einen Hashwert sind zwischen 64 und 256 Byte. Damit ein Algorithmus als Einwege-Hash Funktion brauchbar ist, muß er folgenden Anforderungen
genügen:
• Es darf nicht möglich sein, ausgehend von einem gegebenen Hashwert, eine passende Nachricht zu konstruieren!
• Der Hashwert muß von der gesamten Nachricht abhängen!
• Eine kleine Änderung im Nachrichtentext muß eine große Änderung im Hashwert
verursachen!
• Die Funktion soll kollisonsfrei sein, d.h. es soll praktisch nicht möglich sein zwei
Nachrichten zu finden, die den selben Hashwert haben!
Eine Sonderform einer Hash Funktion stellt der MAC (Message Authentification
Code) dar. Dieser benötigt zur Bildung des Hashwerts einen geheimen Schlüssel. Somit ist neben der Integrität auch die Authentizität sichergestellt. Jede Einwege-Hash
Funktion kann zu einer MAC Funktion erweitert werden, indem ihr Ergebnis mit einem
Kryptoalgorithmus verschlüsselt wird.
26
1.4.2.7
Digitale Signatur
Mit den Methoden der Hashwert-Bildung und asymmetrischer Verschlüsselung lassen
sich die Dienste Integrität, Authentikation und Verbindlichkeit erreichen. Dies sind die
geforderten Leistungen für eine elektronische Unterschrift (digitale Signatur). Um eine
Nachricht zu unterzeichnen, wird von dieser der Hashwert gebildet und mittels dem
privaten Schlüssel seines Urhebers chiffriert. Der Unterschied zu einem auf symmetrischer Verschlüsselung basierendem MAC besteht darin, daß die digitale Signatur von
jedermann mittels dem öffentlichen Schlüssel des Verfassers verifiziert werden kann.
Eine derartige Signatur ist darüberhinaus untrennbar mit der eigentlichen Nachricht
verknüpft und wird nicht, wie die handschriftliche Unterschrift, nur hinzugefügt. Um
das Verfahren wirklich gegen Betrug abzusichern, ist unbedingt sicherzustellen, daß der
veröffentlichte public key auch wirklich an die Person des Verfassers gebunden ist (siehe
dazu 1.4.6).
1.4.3
Ausgewählte Algorithmen
1.4.3.1
DES
DES21 ist ein symmetrischer Blockverschlüsselungs-Algorithmus. Er verwendet in seiner ursprünglichen Form eine Blocklänge von 64 Bit und einen 56 Bit langen Schlüssel.
Die Verschlüsselung beruht auf einer Folge von Transpositionen und Substitutionen,
die in mehreren Verschlüsselungsrunden durchgeführt werden. Das Verfahren wurde
ursprünglich von IBM entwickelt und 1974 veröffentlicht. Nach ausgiebiger öffentlicher Diskussion und einigen Verbesserungen wurde es 1977 vom NBS22 zum StandardVerschlüsselungsalgorithmus der USA erklärt.
DES ist einer der am weitesten verbreiteten Kryptoalgorithmen. Es existieren viele
Implementierungen in Hardware, jedoch ist dieser Algorithmus auch in Software ausreichend schnell. Die geringe Schlüssellänge von nur 56 Bit macht ihn allerdings, mit
den heute verfügbaren Rechenleistungen, für Brute-Force Attacken anfällig, so daß DES
mit 56 Bit Schlüssel heute als nicht mehr sicher angesehen werden kann.
Triple-DES (3DES) erhöht die Schlüssellänge auf das zwei- bzw. dreifache. 3DES
führt das bekannte DES Verfahren dreimal hintereinander durch, womit jedoch nicht
nur die Sicherheit, sondern auch die Verarbeitungszeit stark ansteigen. Durch Verwendung heute bekannter Angriffsmethoden und gemessen an der voraussichtlichen
Entwicklung der Rechnertechnik, ist diese Schlüssellänge für absehbare Zeit als sicher
anzusehen.
21
22
Data Encryption Standard
National Bureau of Standards
1.4. KRYPTOLOGIE
1.4.3.2
27
IDEA
IDEA23 ist wie DES eine symmetrische Blockchiffre mit einer Blocklänge von 64 Bit. Im
Gegensatz zu DES nutzt dieser aber 128 Bit lange Schlüssel. Dieser Algorithmus wurde 1990 von Xuejia Lai und James Massey entwickelt und 1991 in einer verbesserten
Version standardisiert. Er ist weitgehend resistent gegen Brute-Force Attacken und differentielle Kryptoanalyse. Trotz seines geringen Alters wurde er schon vielen Analysen
unterzogen und könnte ein möglicher Nachfolger des DES Verfahrens werden.
1.4.3.3
RSA
Beim RSA24 Verfahren handelt es sich um eine asymmetrische Verschlüsselung (publickey-Kryptosystem). Die Namensgeber des Verfahrens setzten damit 1978 die Idee
eines asymmetrischen Kryptosystems, wie es von Diffie und Hellmann 1976 vorgeschlagen wurde, mittels klassischer Zahlentheorie um. Obwohl es eine Reihe weiterer
Implementierungen asymmetrischer Kryptosysteme gibt, ist RSA das bekannteste und
am meisten diskutierte Verfahren. Es beruht im wesentlichen auf dem Satz von Euler.
Es verwendet einen öffentlichen Schlüssel, bestehend aus dem eigentlichen publickey e und dem Modul n. Die Wahl von e ist nicht von Bedeutung und kann somit
auf einen, die Berechnungen vereinfachenden, Wert von z.B.
e = 216 + 1 = 65537 = 10001h
festgesetzt werden. Das Modul n ist das Produkt zweier Primzahlen p und q. Seine
Länge bildet die eigentliche Schlüssellänge. Es ist für die Sicherheit relevant, daß p und
q echte Zufallszahlen sind und sich in ihrer Länge um mindestens 20 Bit unterscheiden.
Zwischen dem Modul n und dem private-key d besteht über die Euler’sche Funktion
Φ(n) ein Zusammenhang:
Φ(n) = (p − 1)(q − 1)
e · d ≡ 1 mod Φ(n)
Die Sicherheit des Verfahrens hängt damit von der Schwierigkeit der Faktorisierung
des Moduls n, d.h. von der Ermittlung der beiden Primzahlen p und q ab. Eine solche
Faktorisierung ist, bei genügend großem n, ein mathematisch schwierig zu lösendes
Problem. Ab einer bestimmten Größe von n ist eine Berechnung nicht mehr in einem praktikablen Zeitraum durchzuführen. 1999 wurde erstmals eine 512 Bit lange
Zahl mittels 300 Computern in 7 Monaten faktorisiert. Schüssel, ab einer Länge von
768 Bit, werden heute für weniger kritische Anwendungen als ausreichend sicher eingeschätzt. Bei erhöhten Anforderungen sollten Schlüssellängen zwischen 1024 und 2048
Bit verwendet werden.
23
24
International Data Encryption Algorithm
Rivest, Shamir und Adleman
28
Auch RSA ist ein Blockalgorithmus. Die Blocklänge darf dabei maximal der Länge des
Moduls n entsprechen. Jeder Nachrichtenblock m wird als natürliche Zahl interpretiert
und gemäß:
c = (me ) mod n
kodiert
d
e d
(c ) mod n = (m ) mod n = m
dekodiert
Im Vergleich zu symmetrichen Algorithmen sind hier, zur Erreichung der gleichen Sicherheit, wesentlich längere Schlüssel notwendig. Das resultiert aus der Tatsache, daß
während bei symmetrischer Verschlüsselung i.d.R. nur Brute-Force Attacken 1.4.4 anwendbar sind, zur Faktorisierung großer Zahlen im Vergleich dazu relativ effektives
Verfahren existieren.
1.4.3.4
ElGamal Methode
Auch der 1985 von Taher El Gamal entwickelte Algorithmus ist ein asymmetrisches
Verfahren. Seine Sicherheit beruht auf dem Problem des diskreten Logarithmus, welches
noch schwieriger zu lösen ist, als die Faktorisierung großer Zahlen. Daher werden derzeit
bei dieser Methode bereits Schlüssellängen von mehr als 512 Bits als sicher eingestuft.
Eine Variante dieses Verfahrens zur digitalen Signatur wurde 1991 von der NIST25 zum
einheitlichen DSS26 der USA erklärt.
1.4.3.5
EEC elliptische Kurven
Seit etwa 1985 befaßt sich die Kryptologie mit Verschlüsselungsverfahren basierend auf
elliptischen Kurven über endliche Körper. Eine elliptische Kurve ist eine mathematische
Struktur mit den Parametern a und b der Menge von Punkten, welche eine Gleichung
der Form:
y 2 = x3 + ax + b
erfüllen. Als Nebenbedingung muß die Diskriminante 4a3 + 27b2 6= 0 sein.
Die Kurve E(k), ein Punkt P auf dieser Kurve und der eigentliche öffentliche Schlüssel
Q (ebenfalls ein Kurvenpunkt) werden zur Verschlüsselung verwendet. Q ist dabei aus
P durch mehrfache Addition um den Faktor k auf der Kurve hervorgegangen. Nur mit
Kenntnis von k ist eine Entschlüsselung möglich. k ist somit der private Schlüssel in
diesem Verfahren.
Das Problem k aus den öffentlich bekannten Parametern zu berechnen, ist ähnlich wie
beim ElGamal Verfahren, das des (additiven) diskreten Logarithmus. Da jedoch für
die Berechnung des diskreten Logarithmus in einer Punktegruppe elliptischer Kurven
25
26
National Institute of Standards and Technology
Digital Signature Standard
1.4. KRYPTOLOGIE
29
nur sehr allgemeine Verfahren existieren, sind die bisher bekannten schnellen diskreten
Logarithmus Algorithmen hier nicht anwendbar. Somit reichen wesentlich geringere
Schlüssellängen aus, um eine, zu anderen asymmetrischen Verfahren äquivalente, Sicherheit zu bieten. Ein 97 Bit langer Schlüssel eines EEC Verfahrens ist schwieriger zu
brechen, als ein 512 Bit Schlüssel einer, auf dem Problem der Faktorisierung basierenden Methode.
Diese Tatsache macht EEC Verfahren besonders für Plattformen, auf denen nur sehr
beschränkte Resourcen an Speicherplatz und Rechenleistung zur Verfügung stehen wie
z.B. bei Mobiltelefonen interessant.
1.4.4
Kryptoanalyse
Kryptoanalyse ist ein wichtiger Bestandteil der Kryptologie. Erst wenn bewiesen ist,
daß ein Verschlüsselungsverfahren gegen alle bekannten Angriffsformen immun ist, kann
es als sicher eingestuft werden. Je nach den gegebenen Voraussetzungen existieren
folgende Angriffsmethoden:
• Cipertext-only-Attack: Dies ist der klassische Angriff. Dem Angreifer steht
ein, z.B. durch Abhören erbeutetes, Stück des verschlüsselten Textes zur
Verfügung.
• Known-plaintext-Attack: Hier ist neben dem verschlüsselten Text auch das
zugehörige Stück des Klartextes vorhanden.
• Choosen-plaintex-Attack: Bei dieser Form des Angriffs verfügt der Gegner
über Zugang zum Verschlüsselungssystem mit dem Schlüssel k. Er kann k jedoch
nicht auslesen, aber beliebige Texte damit verschlüsseln. Durch geschickte Wahl
der Eingabetexte lassen sich so leichter Rückschlüsse auf den Schlüssel ziehen.
• Choosen-cipertext-Attack: Dies ist ähnlich dem Choosen-plaintex-Attack, nur
daß hier Zugang zum Entschlüsselungsystem besteht.
• Brute-Force-Attack: Diese Form des Angriffs ist eigentlich ein Spezialfall der
Cipertext-only-Attack. Wegen seiner Bedeutung ist er hier jedoch separat aufgeführt. Wie der Name schon andeutet ist dies kein sonderlich intelligentes Verfahren, sondern probiert systematisch alle möglichen Schlüssel durch, bis ein sinnvoller Klartext gefunden wird. Ist dies der Fall, ist der gesuchte Schlüssel gefunden.
Diese Methode ist prinzipiell auf jedes Verschlüsselungsverfahren anwendbar. Es
ist nur eine Frage der Zeit, bis der Schlüssel gefunden ist.
30
1.4.5
Kryptographische Protokolle
1.4.5.1
Schlüsseltausch - Diffie-Hellmann Verfahren
Ein Schlüsselaustausch ist immer dann notwendig, wenn zwei Parteien zum ersten Mal
(in der Praxis finden sogenannte Session-Keys Verwendung, welche nicht nur bei der
ersten Kommunikation getauscht werden, sondern aus Sicherheitsgründen vor jeder
Kommunikation neu) mittels symmetrischer Verschlüsselung kommunizieren möchten.
Ist dafür bei Verbindungsaufbau noch kein sicherer Kanal vorhanden, benötigt man
Verfahren welche trotzdem einen sicheren Austausch gewährleisten.
Mittels asymmetrischer Verfahren ist dies möglich. Eine Partei wählt eine Zufallszahl
als Session-Key, verschlüsselt diese mit dem öffentlichen Schlüssel der anderen Partei
und überträgt das Ergebnis. Nur die entsprechende Gegenstelle kann mittels seinem
private key den Session-Key entschlüsseln.
g ∈ [2,n-1] ∈ GF(p) sind öffentlich bekannt
A
k=
a
B
wählt Zufallszahl a
und berechnet
=g a mod p
wählt Zufallszahl b
und berechnet
=g b mod p
berechnet
mod p=g ab mod p
berechnet
k= b mod p=g ab mod p
Abbildung 1.11: Diffie-Hellmann Schlüsseltausch
Bei diesem Verfahren muß einer der Kommunikationspartner die aktive Rolle ergreifen
und einen Session-Key bestimmen. Das Diffie-Hellmann Verfahren dagegen erreicht
beim Schlüsseltausch völlige Gleichberechtigung beider Partner. Das 1976 erstmals
veröffentlichte Protokoll arbeitet auf der Basis des diskreten Logarithmus. Zu dessen
Durchführung müssen eine Primzahl p und eine Basis g öffentlich bekannt sein. Beide
Partner wählen dann eine Zufallszahl. Nach Beendigung des Protokolls besitzen beide
einen gemeinsamen geheimen Schlüssel k, welcher aus diesen Parametern entsteht. Ein
Angreifer erfährt durch Abhöhren dieser Austauschs jedoch keine brauchbaren Informationen. In [ldv00] ist der Ablauf anschaulich dargestellt.
1.4.5.2
Authentifikation - Challenge-Response Methode
Dieses Verfahren bietet die Möglichkeit einen Benutzer zu authentifizieren, ohne geheime Schlüssel zu übertragen. Es löst damit das Problem jemanden vom Besitz eines
Geheimnisses zu überzeugen, ohne dabei das Geheimnis preisgeben zu müssen.
1.4. KRYPTOLOGIE
31
Dazu sendet das Authentikationsystem eine Zufallszahl (Challenge) an den Benutzer. Diese wird mit dem geheimen Schlüssel k des Benutzers verschlüsselt und an das
Authentifikationssystem zurückgesendet (Response). Das Authentikationsystem kann
nun durch die Entschlüsselung der Antwort mit dem selben Schlüssel k und dem anschließenden Vergleich, die Authentizität feststellen.
A
B
wählt Zufallszahl r
challenge = r
berechnet crypt (r)
response = crypt (r)
überprüft ob
r = crypt-1(response)
Abbildung 1.12: Das Challenge-Response Verfahren
Somit ist dieses Verfahren im Grunde ein two-way protocol. Handelt es sich jedoch
um eine Mehrbenutzersystem, ist es zusätzlich notwendig in einem vorangehenden
Schritt eine eindeutige Benutzer ID zu senden, damit das Zugangssystem den korrekten Schlüssel auswählen kann. Durch die Verwendung von Zufallszahlen ist ein Angriff
durch Mithören und Wiederausenden der Response unmöglich, da sich die Zufallszahlen
von mal zu mal ändern.
Dieses Verfahren funktioniert sowohl mit symmetrischer, als auch mit asymmetrischer
Verschlüsselung. Im letzteren Falle verschlüsselt der Benutzer die challenge mit seinem
private key und das Anmeldesystem entschlüsselt mit dem korrespondierenden public
key.
1.4.6
Zertifikate - PKI Infrastruktur
Eine bisher noch nicht besprochene aktive Angriffsmethode macht asymmetrische Verschlüsselungsysteme verwundbar. Ein Angreifer, dem es gelingt einem Kommunikationspartner seinen öffentlichen Schlüssel anstelle des public-keys des eigentlichen Partners unterzuschieben, kann dadurch sowohl, mittels falscher Identität, eine geheime
Kommunikation führen, als auch gefälschte digitale Signaturen ausstellen.
Es ist somit von außerordentlicher Wichtigkeit von der Bindung eines öffentlichen
Schlüssels an eine Person überzeugt sein zu können. Die Einbeziehung eines vertrauenswürdigen Dritten reduziert dieses Problem auf das Vertrauen in diese Stelle.
Eine sogenannte Zertifizierungsinstanz CA27 nimmt eine Identitätsbestätigung eines Benutzer A vor. Durch die digitale Signatur dessen öffentlichen Schlüssels eA ,
zusammen mit eindeutigen Identifikationsdaten (IDA , IDCA ) des Nutzer und der CA
27
Certification Authority
32
und einer Gültigkeitsdauer T , wird ein öffentlicher Schlüssel eindeutig und verbindlich
einer Person zugeordnet. Tabelle 1.2 zeigt den minimalen Inhalt eines solchen Zertifikats. Durch den öffentlichen Schlüssel der CA können Zertifikate jederzeit überprüft
Cert(CA, A) = {IDCA , IDA , eA , T, sigCA }
sigCA = dCA [h(IDCA , IDA , eA , T )]
CA:
A:
IDCA :
IDA :
eA :
T:
dCA :
sigCA
Zertifikatsstelle (Certification Authority)
Benutzer A
eindeutige Bezeichnung der CA
eindeutige Bezeichnung des Benutzers
öffentlicher Schlüssel von A
Gültigkeitsdauer
private key der CA
digitale Signatur der CA
Tabelle 1.2: Bestandteile eines Zertifikats
werden. Die Sicherheit dieses Systems hängt zu einem großen Teil von der Sicherheit
des privaten Schlüssels dCA der Zertifizierungsinstanz ab. Er muß daher ausreichend
lang und gut geschützt sein.
Der öffentliche Schlüssel der CA muß dazu überall bekannt sein. Die Zertifikate selbst
können in Form eines öffentlichen Verzeichnisses bereitgestellt werden oder vom Benutzer selbst gespeichert werden.
Bei großen Benutzergruppen wird eine einzige Zertifizierungsstelle schon aus organisatorischen Gründen nicht ausreichen. In Systemen mit mehreren CAs muß das Vertrauen untereinander sichergestellt werden. Dazu gibt es hierarchische Modelle, welche auf
einer Root CA, von der ausgehend weitere untergeordnete CAs authorisiert werden,
basieren und ein gleichberechtigtes“ Modell auf der Basis von Cross-Certificates.
”
Beide Strukturen bilden eine sogenannte PKI28 .
Über diese Aufgaben hinaus kann eine Zertifizierungsinstanz noch weitergehende Aufgaben übernehmen. Das Schlüsselmanagement ist hierbei eine der wichtigsten. Es umfaßt folgende Funktionen:
• Schlüsselgenerierung
• Schlüsselspeicherung
• Schlüsselrücknahme (Revocation)
28
Public Key Infrastructure
1.5. CHIPKARTEN
33
• Schlüsselverteilung
• Schlüssellöschung
Zertifizierungsinstanzen, welche auch solche Funktionen abdecken, werden auch als
Trustcenter bezeichnet.
1.5
1.5.1
Chipkarten
Entstehungsgeschichte
Obwohl Chipkarten erst seit gut einem Jahrzehnt weite Verbreitung im täglichen Leben gefunden haben, ist diese Technologie keineswegs neu. Bereits 1968 erhielten die
deutschen Erfinder Jürgen Dethloff und Helmut Gröttrup das Patent mit der Nummer
DE 19 45 777 C3 auf einen kartenbasierenden Identikanden, welcher eine integrierte
”
Schaltung enthalten sollte“. In die Praxis umgesetzt werden konnte diese Idee jedoch
erst mit der Weiterentwicklung der Mikroelektronik in den folgenden Jahren. 1974
wurde dem französischen Wirtschaftsjournalisten Roland Moreno ein Patent auf ein
System zur Speicherung von Daten in einem unabhängigen tragbaren Gegenstand“
”
erteilt. Seit dieser Zeit begann der Siegeszug der Chipkarten weltweit. Noch bevor in
Deutschland erstmals, mit der Einführung der Telefonkarte im Jahre 1985, Chipkarten
weite Verbreitung in der Bevölkerung fanden, setzten sich in Frankreich Chipkarten
vom Typ CP 8 der Firma Bull durch. Mittlerweile wird diese Technologie auf vielfältige Weise verwendet. Krankenversicherungskarten, GSM Mobilfunkkarten, Geldkarten
und Pay-TV-Karten nutzen diese Technik. In Zukunft sind noch eine Vielzahl weiterer
Anwendungen denkbar.
1.5.2
Arten von Chipkarten
Speicherkarten
Speicherkarten haben, wie bereits der Name andeutet, nur die Fähigkeit zur Speicherung von Daten. Diese können gelesen und geschrieben werden. Erweiterte Formen
dieser Kartenart besitzen eine Sicherheitslogik, um den Zugriff zu beschränken. Damit
ist es z.B. möglich nur das Lesen oder, wie bei den Telefonkarten, nur die Erniedrigung
eines Zählers, nicht aber dessen Erhöhung zu erlauben.
Durch diese eingeschränkten Fähigkeiten sind Speicherkarten nicht sehr flexibel jedoch
billig. Ihr Hauptvorteil ist somit der geringe Preis.
34
Smartcards
Hierbei handelt es sich um intelligente Chipkarten, welche auch als Prozessorkarten bezeichnet werden. Sie bestehen aus einer CPU mit Speicher und Ein-/Ausgabeeinheit.
Spezielle Varianten besitzen Coprozessoren, um die Berechnung von synchronen und
asynchronen Verschlüsselungs Algorithmen zu beschleunigen. Alle modernen Prozessorkarten verfügen über eigene Betriebssysteme. Das Karten Betriebsystem regelt die
Verwaltung und den Schutz des Speichers und der Daten, steuert die Kommunikation
mit dem Kartenterminal und kontrolliert die Ausführung der eigentlichen Chipkartenanwendungen. Moderne Bertiebssysteme erlauben das Unterbringen und gezielte
Ausführung mehrerer Anwendungen auf einer Karte. Aufgrund der sehr begrenzten
Resourcen einer Prozessorkarte, ist das Betriebsystem sehr klein und auf seine Umgebung optimiert. Es ist auf dem internen ROM der Karte untergebracht. Darüberhinaus verfügt eine SmartCard über RAM zur Ablage von Zwischenergebnissen oder
temporären Daten und einem EEPROM zur Speicherung der Anwendung.
Diese Art von Karten ist durch ihre freie Programmierbarkeit universell einsetzbar. Dadurch, daß solche Karten geheime Schlüssel, vor unbefugtem Zugriff geschützt, sicher
speichern können und gleichzeitig die Fähigkeit besitzen, kryptographische Algorithmen direkt auszuführen, eignen sie sich besonders für Authentifizierungsanwendungen.
Der geheime Schlüssel darf hierbei die sichere Karte nie verlassen.
1.5.3
Aufbau
Der physikalische Aufbau von Chipkarten ist in den ISO29 Normen 7816-2 und 7816-3
spezifiziert. Eine Karte besteht im wesentlichen aus drei Komponenten. Das Trägermaterial aus Plastik hat die Abmessungen 85,6mm x 53,98mm x 0,76mm. Darüberhinaus existiert noch ein kleineres plug-in Format, welches vor allem für den Einsatz in
kleinen Mobiltelefonen geschaffen wurde. In diesen Trägerkörper wird der eigentliche
Mikrokontroller eingesetzt. Darauf wird eine gedruckte Schaltung aufgebracht, die
im wesentlichen aus 8 Kontaktfläche besteht, welche zum einen den Chip nach oben
abschließen und schützen und zum anderen den Kontakt zur Außenwelt“ herstellen.
”
Neben der Kommunikationsfähigkeit muß der Chip über diese Kontakte auch mit Spannung und Taktfrequenz versorgt werden. Typische Taktfrequenzen für Chipkarten liegen heute zwischen 3 und 10 MHz. Daneben existieren auch kontaktlose Chipkarten.
Sie stellen die Verbindung zum Terminal über kapazitive oder induktive Koppelung
her. Ihre Reichweite liegt typischerweise bei 10 cm.
Die Kartenhardware wird durch verschiedene Maßnahmen gegen Angriffe und unerlaubtes Abhören geschützt. So wird keiner der internen Adress- oder Datenbusse nach
außen geführt. Busleitungen werden grundsätzlich mehrfach überkreuzt und die Stromaufnahme ist für die Ausführung jedes Befehls gleich.
29
International Standardisation Organisation
1.5. CHIPKARTEN
1.5.4
35
Lebenszyklus
Beginnend mit der Herstellung der Karte bis zum Wegwerfen kann ihr Lebenszyklus
in fünf Phasen eingeteilt werden.
• Herstellungsphase: Diese Phase umfaßt die Herstellung des eigentlichen Chips.
Diese erfolgt unter stengen Sicherheitsvorkehrungen. Zudem wird auf jedem Chip
eine Hersteller ID aufgebracht. Diese ID wird von einem Herstellerschlüssel abgeleitet und ist für jeden Chip einzigartig. Mit der Auslieferung des Chips an den
Kartenhersteller endet diese Phase.
• Vor-Personalisierungsphase: In dieser Phase bringt der Kartenhersteller den
Mikrokontroller in das Kartenträgermaterial ein und verschließt es mit den Kontaktflächen. Die Hersteller ID wird durch eine Personalisierungs ID ersetzt.
Gleichzeitig werden die Befehle zum physikalischen Speicherzugriff deaktiviert.
Fortan kann der Speicher nur noch mittels logischer Adressen angesprochen werden.
• Personalisierungsphase: Diese Phase führt der Aussteller der Karten durch.
Hier werden die Anwendungen und die benötigten Datenstrukturen im EEPROM
der Karte untergebracht. Auch sicherheitsrelevante Daten wie Schlüssel oder PINs
werden in dieser Phase gespeichert.
• Nutzungsphase: Dies ist die eigentliche Benutzung der Karte. Hier werden die
Anwendungen ausgeführt sowie Daten geschrieben und gelesen.
• Beendigungsphase: Diese Phase schließt den Lebenszyklus ab. Das kann auf
verschiedene Art und Weise geschehen. Aus Sicherheitsgründen wird bei mehrmaliger Falscheingabe von PIN30 und PUK31 die Karte dauerhaft deaktiviert, da
in diesem Falle von einem Diebstahl auszugehen ist. Es ist auch möglich, daß eine
Karte eine vorherbestimmte Gültigkeit besitzt. Nach deren Ablauf versetzen die
internen Anwendung die Karten in diese Lebensphase. Der naheliegendste Weg
den Lebenszyklus einer Karte zu beenden, ist schlicht dessen Zerstörung.
1.5.5
Protokolle
Die Kommunikation mit Prozessorkarten erfolgt seriell und asynchron über einen Kontakt. Die Bitübertragungsschicht verwendet ein Startbit und zwei Stopbits sowie ein
Paritätsbit zur Fehlererkennung. Sie ist in der ISO Norm 7816-3 spezifiziert und arbeitet üblicherweise mit einer Übertragungsrate von 9600 Bit/s.
Für die Sicherungsschicht (OSI-Referenzmodell Schicht 2) definiert ebenfalls ISO
7816-3 16 verschiedene Protokollvarianten (T0 bis T15). Hiervon sind derzeit nur
30
31
Personal Identification Number
Personal Unblocking Key
36
die Protokolle T0, T1 und T14 von Bedeutung. T14 wird von Telefonkarten der deutschen Telekom genutzt. GSM SIM Karten kommunizieren über T0. Von immer grösser
werdender Bedeutung ist das international genormte T1 Protokoll. Es ist weit verbreitet und im Gegensatz zum byteorientierten T0 blockorientiert. Welches Protokoll
letztendlich benutzt wird, legt das Kartenbetriebsystem fest und teilt dies beim ATR32 ,
mit welchem jede Kommunikation mit einer Chipkarte beginnt, dem Terminal mit.
Auch für die Struktur der Kommunikation auf der Anwendungsschicht gibt es mit ISO
7816-4 eine internationale Norm. Eine Kommunikation geht immer vom Kartenterminal aus. Es sendet Befehle, auf welche die Karte antwortet. Somit stehen beide in
einer strengen Master-Slave Beziehung zueinander. Dieses Verfahren wird auch als
Command-Response Modell bezeichnet. Eine so definierte APDU33 besteht, sofern
es sich um einen Befehl handelt, aus einem Header und einem Body. Der Header
enthält neben dem Befehlscode selbst, bis zu zwei Parameter. Der Body besteht aus
der Angabe der Länge des Datenfelds und den Daten selbst. Ein Befehl hat folgendes
Format:
ClassByte
(1 Byte)
Instruction
(1 Byte)
Par1
Par2
Length
Data
(1 Byte) (1 Byte) (1 Byte) (n Byte)
Tabelle 1.3: Befehls APDU
Die Antwort enthält einen Returncode, bestehend aus zwei Status-Bytes (SW1
und SW2), die Auskunft über das Ergebnis der Befehlsausführung geben, und gegebenenfalls einem Datenblock.
Data
(n Byte)
SW1
SW2
(1 Byte) (1 Byte)
Tabelle 1.4: Antwort APDU
32
33
Answer to Reset
Application Protocol Data Unit
1.6. DAS OBEX PROTOKOLL
1.6
1.6.1
37
Das OBEX Protokoll
Einführung
Im Rahmen der Standardisierungsbemühungen der Infrared Data Association entstand
1997 aus der Motivation heraus, eine einfache und flexible Möglichkeit zum Austausch
von Datenobjekten zwischen IrDA fähigen Geräten zu schaffen, das OBEX34 Protokoll.
Sein Konzept ist auf Push and Pull-Applikation“ ausgelegt und kann als eine Art
”
binäres http-Protokoll angesehen werden. OBEX ist dabei jedoch kompakter und
nicht so einseitig auf Pull Aktionen ausgelegt. Da es vornehmlich auf mobilen Geräten
mit eingeschränkten Resourcen zum Einsatz kommen sollte, wurde darauf geachtet,
OBEX möglichst einfach zu halten und nur sehr wenige Operationen verbindlich vorzuschreiben. Das ermöglicht sehr kompakte Implementierung. OBEX ist dabei aber
flexibel genug, um bei Bedarf auch umfangreiche und komplexe Applikationen realisieren zu können.
Application
Application
OBEX Session Protocol
OBEX Session Protocol
RFCOMM
SDP
Tiny TP / Ultra
Transports
IAS
Service
LMP
L2CAP
Baseband
Bluetooth
IrLAP
IrLMP
IrPHY
IrDA
Abbildung 1.13: Eingliederung von OBEX in den IrDA and Bluetooth Protokollstack
OBEX ist ein Session Protokoll und somit keinesfalls auf die Anwendung in IrDAfähigen Geräten beschränkt. Es kann nahezu auf jedes beliebige Transportprotokoll
aufgesetzt werden. Durch die Konzeption als offener Standard“ ist dies auch ge”
wollt. Die IrDA weist in der Spezifikation zu OBEX sogar explizit darauf hin. Es
existiert z.B. eine Definition für OBEX über TCP/IP und auch die Bluetooth SIG hat
OBEX in die Core Specification des Bluetooth Standards mit aufgenommen. Abbildung
1.13 zeigt die Einordnung in den IrDA und den Bluetooth Protokollstack.
Durch diese Unabhängigkeit von Protokollen tieferer Schichten, und damit von der
eingesetzten Übertragungstechnologie, ist OBEX für die Entwicklung plattformübergreifender und weitgehend herstellerunabhängiger Anwendungen geeignet. Da sowohl
34
Object Exchange
38
IrDA als auch Bluetooth, die auf absehbare Zeit dominierenden lokalen Übertragungstechniken in mobilen Geräten, dieses Protokoll unterstützen, bildet es die Grundlage
des Kommunikationsprotokolls im Konzept dieser Diplomarbeit.
Die exakten Spezifikationen sind in [MSK99] nachzulesen. Dort werden auch folgende
Designziele von OBEX definiert:
• Einfache Anwendungsentwicklung
• Kompaktheit
• Plattformunabhängigkeit
• Intelligenter Umgang mit Datenobjekten
• Einfache Eingliederung in Internet Protokolle
• Erweiterbarkeit
• Einfach zu testen und debuggen
OBEX
Application Framework
•Stellt das Zusammenarbeiten von Geräten, die OBEX nutzen, sicher
•Strafft die Verwendung des sehr flexibel definierten Protokolls
•definiert einen Satz von Standarddiensten
z.B. default OBEX Server, INBOX Service, Capability Service
Session Level Protocol
OSI-ISO Model – Schicht 5
Modell zur Objektdarstellung
•Informationen über Objekte
•Einfach zu parsende Header
•Das eigentliche Objekt selbst
Session Protokoll
•Strukturvorgabe für den Dialog
der Geräte
•binäres, paketbasierendes,
Client / Server,
Request / Response Modell
Abbildung 1.14: OBEX - Bestandteile
Die OBEX Spezifikation definiert ein Session Protokoll, das den Dialog der Geräte
regelt, ein Objekt Modell, welches die Darstellung der Objekte festlegt und ein Application Framework. Das Framework gibt Richtlinien zur Implementierung von
OBEX konformen Diensten vor, um die Zusammenarbeit verschiedenster Geräte auch
auf Applikations-Ebene sicherzustellen. Dabei spezifiziert es einige Grunddienste und
Erweiterungsmöglichkeiten.
1.6.2
39
Session Protokoll
Das Session Protokoll folgt einem strengen Request-Response Modell. Der Client
sendet Request Pakete aus, auf die der Server mit einem Response Paket antworten
muß. Jedem Request Paket muß unmittelbar ein Response Paket folgen, bevor das
nächste Paket ausgesandt werden darf. Ein solches Paar wird als Operation bezeichnet. Alle Operationen werden immer vom Client initiiert.
OBEX
Request
Server
Client
Response
Abbildung 1.15: OBEX Request-Response Modell
In der Spezifikation zu OBEX sind hierfür keine Timeouts festgelegt, jedoch deren
Verwendung auch nicht untersagt. In manchen Fällen z.B. in Anwendungen, die über
kein Userinterface verfügen, kann es aber zweckmäßig sein, angemessene Timeouts zu
definieren, um eine Blockierung der Anwendung zu verhindern.
Paketformat
Request:
Kommando
Länge
1 Byte
2 Byte
Request
Daten
Header
...
Header
n Byte
optional
Response:
Response Code
Länge
1 Byte
2 Byte
Antwort Daten
n Byte
Abbildung 1.16: Aufbau von OBEX Paketen
Jeder Request besteht aus einem 1 Byte langen Befehl, gefolgt von einer 2 Byte großen
Längenangabe über die Länge des gesamten Pakets, einschließlich dem Befehlscode
und der Längenangabe selbst. Daran anschließend sind, je nach verwendetem Befehl,
noch weitere Datenfelder vorhanden. Der Rest ist eine Folge von optionalen Headern (siehe 1.6.3). Das eigentliche Objekt, der Payload, ist in speziellen Headern
enthalten. Tabelle 1.5 zeigt eine Übersicht der wichtigsten OBEX Kommandos und
deren Kodierung.
40
Opcode
0x80
0x81
0x02
0x03
0x85
0xFF
0x10 to 0x1F
Befehl
CONNECT
DISCONNECT
PUT
GET
SETPATH
ABORT
User definable
Bedeutung
Verbindungsaufbau, Parameter Aushandlung
Aufforderung zum Verbindungsabbau
Objekt senden
Objekt anfordern
Pfad auf Empfängerseite setzen
Abbruch der aktuellen Operation
frei definierbar
Tabelle 1.5: OBEX Befehle
Der Aufbau der Response ist ähnlich. Anstelle des Befehls steht hier ein 1 Byte langer
Response-Code. Dieser ist von den HTTP Status-Codes übernommen worden. Die
dreistelligen ASCII Codes sind bei OBEX binär in 7 Bit kodiert. In Tabelle 1.6 sind die
wichtigsten Response-Codes aufgeführt. Diesem Code folgt auch hier eine Längenangabe des gesamten Pakets sowie optionale Daten oder Header.
Response Code
(mit final Bit)
0x10 (0x90)
0x20 (0xA0)
0x41 (0xC1)
0x51 (0xD1)
0x53 (0xD3)
korrespondierender
HTTP Status Code
100
200
401
501
503
Bedeutung
Continue
OK, Success
Unauthorisized
Not Implimented
Service Unavailable
Tabelle 1.6: OBEX Response-Codes
Sowohl bei Opcodes als auch bei Response-Codes hat das höchstwertige Bit eine besondere Bedeutung. Dies ist das sogenannte Final Bit. Während es bei Response-Paketen
in der derzeitigen OBEX Spezifikation immer gesetzt ist, kennzeichnet es bei RequestPaketen das letzte Paket eines aus mehreren Paketen bestehenden Requests.
Wichtige Request-Befehle
• CONNECT
Ein CONNECT-Request ist das erste Paket einer Kommunikation bei der verbindungsorientierten Variante von OBEX.
0x80
Paket
Versions
Länge Nummer
(1 Byte) (2 Byte) (1 Byte)
Flags
max. OBEX
Paketlänge
(1 Byte)
(2 Byte)
Tabelle 1.7: OBEX Connect Request
opt.
Header
(n Byte)
Response
Code
(1 Byte)
Paket
Versions
Länge Nummer
(2 Byte) (1 Byte)
41
Flags
max. OBEX
Paketlänge
(1 Byte)
(2 Byte)
opt.
Header
(n Byte)
Tabelle 1.8: OBEX Connect Response
Dieser Request kann neben verbindungsrelevanter Parameter wie der maximalen
Paketlänge, Header enthalten, die weitergehende Informationen über Kommunikationspartner liefern, oder zur Authentifizierung notwendig sind.
Nur der Response-Code 0xA0 kennzeichnet einen erfolgreichen Verbindungsaufbau. Alles Andere bedeutet einen Fehlschlag. Der Server teilt im Response u.a. die
maximale von ihm akzeptierte Paketlänge mit. Die OBEX Spezifikation empfiehlt
dabei die Unterstützung minimaler Standardparameter, welche gewissermaßen
den kleinsten gemeinsamen Nenner aller Obex konformen Geräte darstellen, um
auch eine Kommunikation ohne vorangegangene Connect Operation zu ermöglichen.
• DISCONNECT
Ein DISCONNECT-Request und eine erfolgreiche Antwort darauf schließen eine
OBEX Verbindung. Außer dem Opcode bzw. dem Response-Code können noch
Header enthalten sein.
• PUT und GET
PUT und GET dienen zum Senden bzw. Anfordern von Objekten. Übersteigt die
Größe des Objekts die maximale Paketlänge, wird die Übertragung auf mehrere
Pakete aufgeteilt. Im Falle einer PUT-Operation, kennzeichnet das nicht gesetzte
Final Bit das Folgen weiterer Pakete.
Benötigt eine GET-Operation mehrere Pakete, so sendet der Server den
Continue-Response-Code, was den Client veranlaßt durch einen weiteren
GET-Request diese Pakete anzufordern.
• ABORT
Der ABORT Befehl bildet die einzige Ausnahme im strengen Request-Response
Prinzip. Er kann von Client und Server zu einem beliebigen Zeitpunkt der
Kommunikation gesendet werden und bewirkt den Abbruch der gerade laufenden Operation. Er beendet jedoch nicht die Verbindung.
• USER definable
Für die Anforderungen spezieller OBEX Applikationen sind einige KommandoCodes reserviert, um bei Bedarf benutzerspezifische Erweiterungen zu ermöglichen, die durch die standardisierten Codes nicht abgedeckt werden.
42
Beispielhafter Kommunikationsablauf
Abbildung 1.17 zeigt eine OBEX Kommunikation am Beispiel einer, auf mehrere Pakete
aufgeteilten, PUT-Operation.
Client
Server
CONNECT Request + optionale Header
CONNECT Response mit final Bit
PUT ohne final Bit mit Body Header
CONTINUE mit final Bit
...
PUT mit final Bit
SUCCESS mit final Bit
DISCONNECT
SUCCESS
Abbildung 1.17: Beispiel einer OBEX PUT Operation
1.6.3
Objektmodell
Das Objektmodell beschreibt wie in OBEX Objekte dargestellt werden. Es verwendet
dazu eine Folge von Headern. Das eigentliche Objekt ist dabei im Body Header enthalten, während weitere Header Informationen über das Objekt liefern. Darüberhinaus
können Header auch zum Transport protokollrelevanter Daten genutzt werden wie z.B.
der Authentication Header.
OBEX Header
Ein Header besteht aus der Header ID (HI) und der Header value (HV). Die
1 Byte lange Header Id beschreibt den Inhalt des Headers, dabei legen die höchstwertigen 2 Bit die Kodierung fest und die übrigen 6 Bit beschreiben seine Art. Das Header
Value ist abgesehen von seiner Kodierung nicht weiter spezifiziert. Sein Aufbau muß
dem Kommunikationspartner durch die HI bekannt sein.
Die Verwendung aller Header ist optional. Durch ihren Aufbau aus HI und HV sind sie
für den Empfänger einfach zu erkennen und zudem unabhängig in ihrer Reihenfolge.
Unbekannte Header-Typen können so einfach übersprungen werden.
43
HI, Header ID
HV, Header Value
1 Byte
1..n Byte
Bits 8 and
7 of HI
00
(0x00)
length
Unicode text
0x00
2 Byte
n Byte
1 Byte
length
01
(0x40)
Byte sequence
2 Byte
10
(0x80)
n Byte
1 Byte quantity
1 Byte
11
(0xC0)
4 Byte quantity
4 Byte
Header Identifier HI
Bits 8 and 7
Bits 0 to 6
Header encoding
Header meaning
Abbildung 1.18: Aufbau von OBEX Headern
Durch die Verwendung von Headern stehen dem Kommunikationspartner viele Informationen über das Objekt zur Verfügung, wodurch eine sehr effiziente Weiterverarbeitung empfangener Daten möglich wird. Tabelle 1.10 enthält die wichtigsten Header
zusammen mit einer Kurzbeschreibung ihrer Funktionen.
Triplet 1
Triplet 2
Triplet ...
Tag1 Length Value Tag2 Length Value Tag2 Length Value
Tabelle 1.9: TLV-Triplet
Soll in einem Header-Value mehr als nur ein Wert“ übertragen werden, wird oft ei”
ne als TLV35 -Triplet bezeichnete Struktur verwendet. Ihr Aufbau ist in Tabelle 1.9
dargestellt. Die Tag-Werte unterscheiden die einzelnen Bestandteile des Header-Value
und müssen nur innerhalb dieses Headers eindeutig sein. Das Length-Feld ist genau
wie der Tag 1 Byte groß, was die maximale Länge der Triplet-Value auf 255 Byte
beschränkt. Solche Strukturen werden z.B. beim Application Parameter- und Authentification Challenge-Header verwendet.
35
Tag-Lenght-Value
44
HI
0x01
0x42
0xC3
0x46
0x48
0x49
0x4A
Name
Name
Type
Length
Target
Body
End of Body
Who
0xCB
0x4C
Connection Id
App. Parameter
0x4D
Auth. Challenge
0x4E
Auth. Response
0x30 to 0x3F User definable
Bedeutung
Objektname z.B. Filename
MIME Type
Objektlänge in Bytes
Auswahl des Zieldienstes
Ein Teil des Objekts
Letzter Objektteil
Bestätigung der Dienstauswahl als Antwort auf Target
Session-level multiplexing
Daten von Applikationen oder
Protokollen höherer Schichten
Pfad auf Empfängerseite setzen
Abbruch der aktuellen Operation
Frei definierbar (hierin sind
auch alle Kombinationen der höchtswertigen 2 Bit eingeschlossen
Tabelle 1.10: Wichtige OBEX Header
Objekte
Objekte sind in OBEX beliebige binäre Dateneinheiten. Jeder verschiedene Objekttyp
wird durch einen zugeordneten MIME36 -Type identifiziert. OBEX verwendet dabei die
von der IANA37 registrierten Typen und erweitert sie durch eigene Typ-Definitionen.
Alle in OBEX definierten oder dem OBEX Protokoll zuzuordnenden MIME-TypeDefinitionen beginnen mit x-obex/“.
”
In OBEX sind auch einige eigene Objektstrukturen definiert:
• Folder Listing Object: Dieses Objekt dient der Übertragung des detailierten
Inhaltes eines Verzeichnisses. Seine Syntax ist XML38 .
• Capability Object: Auch dieses Objekt ist in XML aufgebaut. Es enthält Informationen über das Gerät und dessen Fähigkeiten, sowie eine Auflistung der
unterstützten Objekt-Typen.
• Object Profile Object: In Zusammenhang mit dem Capability Object beschreibt es die Struktur einzelner Objekte.
Weitere oft in Verbindung mit OBEX verwendete Objekte sind vCard, vCalendar und
vMessage. Sie gehen alle auf die IrMC39 Arbeitsgruppe zurück und spielen eine wichtige
36
Multipart Internet Mail Extension
Internet Assigned Numbers Authority
38
Extensible Markup Language
39
Infrared Mobile Communications
37
45
Rolle im Bereich der mobilen Geräte.
1.6.4
Das Application Framework versucht durch die Festlegung einiger Regeln und Standarddiensten das Zusammenarbeiten OBEX-basierender Applikationen sicherzustellen.
Default OBEX Server
Auf einem Transportprotokoll setzen unterschiedliche Session Protokolle auf. Auch
mehrere unterschiedliche OBEX Server sind hier denkbar. Der default OBEX Server
ist der Standard Server“. Er wird über einen festgelegten Bezeichner“ im Trans”
”
portprotokoll, vergleichbar mit dem Port 80 bei TCP/IP basierenden HTTP Servern,
angesprochen. Im Falle von IrOBEX ist dies der IAS40 Class-Name OBEX“. Der Ba”
sisdienst des default OBEX Servers ist der Inbox Service.
Inbox Service
Seine Aufgabe ist es, beliebige Objekte zu empfangen und abzulegen. Er berücksichtigt dabei die mitgesendeten Informationen. Fehlen genauere Angaben, verwendet er
Standardvorgaben. Durch einen GET Request ohne Typenangabe kann er aufgefordert
werden, sofern vorhanden, Default Objekte wie z.B. eine vCard, auszusenden.
Capability Service
Dieser Dienst bietet einen standardisierten Weg Informationen über das betreffende Gerät und seine Fähigkeiten zu erfragen. Die Grundlage dazu bilden die Objekte Capability-Object und Object-Profile-Object. Er wird über den default OBEX
Server mittels eines GET-Requests mit einem Type-Header vom MIME-Type
x-obex/capability angesprochen.
1.6.5
Authentifikation
Mittels der beiden Header Authentification Challenge und Authentification Response
kann eine OBEX Verbindung authentifiziert werden. Dies geschieht gewöhnlich in
der Connect-Phase. Durch Hinzufügen dieser Header zu beliebigen PUT- oder GETRequests kann aber auch jede einzelne Operation authentifiziert werden.
1.6.6
Multiplexing
Um verschiedene OBEX Dienste gleichzeitig auf einem Gerät verwirklichen und unterscheiden zu können, existieren folgende Möglichkeiten:
40
Information Access Service
46
• Multiplexing auf Transportschicht Ebene:
Hier findet die Unterscheidung außerhalb von OBEX, eine Protokollschicht tiefer,
statt. Durch verschiedene Bezeichner“ auf Transportschicht-Ebene werden un”
terschiedliche OBEX Server angesprochen. Der Bezeichner des entsprechenden
Servers muß dem Kommunikationspartner dabei bekannt sein.
• Multiplexing auf OBEX Kommando Ebene:
Mittels Target, Who und Connection Id Header kann ein OBEX Server, meist
der default Server, verschiedene Dienste unterscheiden und betreffende Pakete dementsprechend behandeln. Dieses Verfahren hat den Vorteil, daß es unabhängig von den Mechanismen unterer Protokollschichten und damit plattformunabhängig ist. Weiterhin benötigt es nur einen gemeinsamen OBEX Parser.
Die Umlenkung einer einzelnen Operation wird als directed operation“ be”
zeichnet. Dies geschieht durch Einfügen eines Target Headers in einen Request.
Er enthält einen eindeutigen Bezeichner für den gewünschten Service. Verfügt
der Kommunikationspartner über den passenden Dienst, sendet er in der Antwort einen Who Header mit demselben Bezeichner zurück.
Sollen mehrere Operationen umgelenkt werden, ist die Verwendung einer directed connection effizienter. Dazu enthält bereits der CONNECT-Request einen
Target Header. Die erfolgreiche Antwort besteht aus einem entsprechenden Who
Header und einem Connection Id Header. Dieser Connection Id Header wird
im weiteren bei jedem Request mitgesendet. So entsteht eine virtuelle Ver”
bindung“.
1.6.7
Fazit
OBEX ist ein sehr flexibles Protokoll. Fast alle Spezifikationen sind optional. Ein minimaler OBEX Server umfaßt die Befehle CONNECT und entweder PUT oder GET. Eine
solche eingeschränkte Implementierung ist mit weniger als 1 KByte Programmcode
möglich, und damit hervorragend für den Einsatz in mobilen Geräten mit beschränkten Resourcen geeigent.
Durch die vorgesehene Erweiterungsmöglichkeit um benutzerdefinierte Kommandos
und Header, eignet sich OBEX als Protokoll für spezielle Anwendungen, wobei es die
grundlegende Struktur für die Kommunikation bildet. Derartige OBEX Applikationen dürfen aber bei der Transportschicht nicht als default OBEX Server“ registriert
”
werden.
1.7. DAS KONZEPT MSIGN
1.7
47
Das Konzept mSign
Das mobile Electronic Signature Consortium mSign“ versucht einen Standard
”
für digitale mobile Signatur zu schaffen. Dieser Organisation gehören große Mobilfunkanbieter, Mobiltelefonhersteller, Trustcenterbetreiber und Kreditinstitute an.
Auf den ersten Blick mag diese Zielsetzung [msi00a] dieser Diplomarbeit ähneln, bei
genauerer Betrachtung werden jedoch grundsätzliche Unterschiede deutlich.
MSign spricht in seiner Konzeptbeschreibung zwar allgemein vom Einsatz mobiler
Geräte, beschränkt sich jedoch in den weiteren Ausführungen ausschließlich auf Mobiltelefone als Plattform. Das zentrale Element in diesem Entwurf ist immer der Mobilfunkbetreiber. Über ihn wird die gesamte Kommunikation abgewickelt. Darüberhinaus
ist vorgesehen, daß dieser noch zusätzlich sicherheitskritische Aufgaben übernimmt, wie
z.B. die Re-Encryption“ von digitalen Signaturen zur Anpassung an eingeschränkte
”
Fähigkeiten von Endgeräten. Dazu müssen beim Mobilfunkbetreiber sensible Daten
hinterlegt werden, die eigentlich beim Endanwender bleiben sollten.
Während sich diese Diplomarbeit auf eine reine lokale Kommunikation beschränken
soll, basiert der Ansatz von mSign immer auf der Nutzung von GSM/UMTS oder
ähnlichen Systemen, mit den damit verbundenen Kosten und eventuellen Sicherheitsrisiken. Im Gegensatz zum Konzept von mSign verfolgt diese Arbeit ein dezentrales
Konzept.
Desweiteren ist das Design von mSign nur auf die digitale Signatur zum Zwecke des
eCommerce ausgelegt. Zwar erfüllt die Signatur auch viele Anforderungen, die an einen
allgemeinen Authentifizierungsprozeß gestellt werden, dafür ist mSign jedoch nicht vorgesehen. Der Ansatz in dieser Arbeit ist somit universeller.
Zum Zeitpunkt der Entstehung der Diplomarbeit existierte nur eine sehr wage Systembeschreibung von mSign. Einzig die Spezifikation der Kommunikation zwischen PSP41
und MSP42 waren in Form eines Protokollentwurfs [msi00b] verfügbar.
1.8
1.8.1
Zusammenfassung
Anforderungen an ein universelles Authentifizierungstoken
Das Vorhaben viele Authentifizierungsprozeße auf ein zentrales Token zu vereinen,
stellt besondere Anforderungen an dieses. Herkömmliche Token erscheinen dafür wenig
geeignet. Diese Forderungen sind im einzelnen:
41
42
Primary Service Provider - z.B. eine Bank
Mobile Service Provider - der Mobilfunkanbieter
48
1. Wahrung eines hohen Sicherheitsstandards
Die Konzentration aller Token auf ein System birgt auch Gefahren in sich. Es
entsteht ein zentraler Angriffspunkt, der, falls er geknackt“ wird, Zugang zu
”
allen unterstützten Systemen ermöglichen würde. Daher ist bei der Entwicklung
besonders auf einen hohen Sicherheitsstandard zu achten. Dabei kommt es, neben
der Anforderungen an den Authenifikationsprozeß selbst, insbesondere auf die
sichere Verwahrung der verwendeten Geheimnisse“ an.
”
2. universelle Einsetzbarkeit und Erweiterbarkeit
Ein solches Vorhaben macht nur dann Sinn, wenn es wirklich alle, oder zumindest
einen Großteil der bisher notwendigen Token ersetzen kann. Weiterhin ist es notwendig, daß es jederzeit um neue Authentifikationsanwendungen erweitert werden kann. Dies soll ähnlich einfach erfolgen können, wie konventionelle Schlüssel
einem Schlüsselbund hinzugefügt werden können.
3. Interaktionsmöglichkeit
Bei einem zentralen Token ist allein durch dessen Anwendung nicht mehr eindeutig bestimmt, an welchem System die Authentifizierung erfolgen soll, noch
welche Aktionen konkret ausgeführt werden sollen. Dazu muß eine Form der Interaktion möglich sein. Desweiteren eröffnet dies die Möglichkeit nach erfolgter
Authentifizierung komplexere Vorgänge zu steuern, in etwa die Bedienung eines
Geldautomaten.
4. einfache Bedienung
Es ist das Ziel dem Nutzer den täglichen Umgang mit Sicherheitssystemen zu erleichtern. Dazu muß deren Bedienung so einfach und intuitiv wie möglich gestaltet
werden. Der Nutzer soll zwar soviel Informationen und Interaktionsmöglichkeiten
wie notwendig erhalten, jedoch von den komplexen Vorgängen der Authentifizierung weitgehend abgeschirmt werden.
5. Minimaler zusätzlicher Hardwareaufwand
Die eingesetzte Technologie darf weder große räumliche Abmessungen aufweisen, noch für den Endnutzer hohe Kosten verursachen, um als mobiler Begleiter
Akzeptanz zu finden. Idealerweise setzt es auf bereits vorhandene und weitverbreitete Technologien auf und erweitert diese nur.
6. Unterstützung eines einheitlichen Interaktions-Mediums
Für ein zentrales Token muß es einen für alle PoAs einheitlichen Weg geben,
die zur Authentifikation notwendigen Informationen mit diesem auszutauschen.
Wegen sehr unterschiedlicher Voraussetzungen verschiedener PoAs und vor allem aufgrund der Bedienfreundlichkeit wäre hier eine drahtlose Schnittstelle sehr
wünschenswert.
1.8. ZUSAMMENFASSUNG
1.8.2
49
Lösungsansatz
Die ersten beiden Forderungen könnten sehr gut durch die Technologie intelligenter
Chipkarten in Verbindung mit den Methoden der Kryptologie gelöst werden. Ein Problem, welches Chipkarten jedoch prinzipiell anhaftet, ist die fehlende Mensch-Maschine
Schnittstelle. Der Anwender muß dem System aus Karte und Kartenterminal blind“
”
vertrauen. Er hat weder eine Möglichkeit in das Geschehen einzugreifen, noch kann er
nachvollziehen was vor sich geht. Darüberhinaus ist es immer ein Risiko eine Chipkarte
in ein fremdes“, eventuell manipuliertes Terminal, einzuführen.
”
Da es für ein zentrales Authentifizierungsystem jedoch, wie in Punkt 3 und 4 gefordert,
der Interaktion mit dem Nutzer bedarf, ist ein solches human Interface“ zwingend
”
vorzusehen. Schon diese Tatsache erfordert Geräte, welche über ein Eingabemedium
und ein Display verfügen. Durch Chipkarten alleine kann diese Aufgabe nicht gelöst
werden.
Somit ist es notwendig, zusätzliche Hardware einzusetzen. Diese muß über eine gewisse
Rechenleistung verfügen und eine Schnittstelle zur Chipkarte bieten. Dazu soll es jedoch
nicht notwendig sein, zusätzliche Geräte mit sich zuführen.
Mobile Geräte als Plattform lösen diese Probleme. Sie haben bereits heute einen hohen
Verbreitungsgrad erreicht und besitzen das geforderte human Interface“. Vielfach sind
”
diese Geräte schon zu einem hohen Maße personalisiert. Vor allem Mobiltelefone, zu
deren Betrieb eine vom Mobilfunkbetreiber bereitgestellte SIM Karte erforderlich ist,
sind dadurch an eine Person gebunden. Durch die SIM Kartennummer ist ihr Besitzer
identifizierbar. Im Gegensatz zu anderen mobilen Geräten besitzen Handys bereits ein
Chipkarten Lesegerät. Bei mobilen Telefonen und PDAs ist zudem eine klare Tendenz
erkennbar, die ein Zusammenwachsen dieser Technologien in naher Zukunft erwarten
läßt.
Obwohl all diese Technologien bereits existieren, gibt es bis heute kein derartiges System. Es bedarf im Grunde nur einiger Erweiterungen handelsüblicher Geräte und eines
gemeinsamen standardisierten Interfaces. Dies Auszuarbeiten ist Aufgabe des folgenden
Kapitels 2.
50
51
Kapitel 2
Konzept
2.1
Zielsetzung
Im Rahmen dieser Arbeit soll ein System entworfen werden, welches mobile Geräte personalisiert, d.h. sie eindeutig und nachprüfbar einer Person zuordenbar macht. Durch
diese Eigenschaft soll ihr Funktionsumfang um die Fähigkeit erweitert werden, als universelles Token für beliebige Autentifikationsprozesse dienen zu können.
SmartCard
SmartCard
SmartCard
Magnetstreifen
Magnetstreifen
Magnetstreifenkarte
karte
karte
Login-Passwort
Kombinationen
Interagieren
SmartCard
PTD - Client
Benutzer
BANKOMAT
EC
PoA Server
Abbildung 2.1: Zusammenführung vieler Token auf ein intelligentes System
Desweiteren soll nach erfolgreicher Authentifikation eine gesicherte Verbindung zum
Authentifikationspunkt bestehen. Das mobile Gerät wird damit zum vertrauenswürdigen Terminal und kann so zur Ein- und Ausgabe sensibler Daten genutzt werden.
52
KAPITEL 2. KONZEPT
Die Kommunikation mit dem PoA soll drahtlos stattfinden. Dazu werden ausschließlich lokale Übertragungstechnologien wie z.B. IrDA oder Bluetooth verwendet. Die
Verfügbarkeit von Mobilfunknetzen wie GSM oder UMTS ist hierfür nicht erforderlich und deren Nutzung nicht vorgesehen. Dadurch ist das System auch an Orten ohne
Netzabdeckung wie z.B. in U-Bahnhöfen oder in dünn besiedelten ländlichen Gegenden
verwendbar. Zudem entstehen keine Verbindungskosten.
Das Konzept muß dabei, die in Abschnitt 1.8.1 definierten Anforderungen, in allen
Punkten erfüllen.
2.2
Gliederung
In meiner Arbeit entstand nach diesen Vorgaben ein allgemeiner Systementwurf für
ein mobiles Authentifikationssystem mAuth.
Darin werden alle benötigten Komponenten und deren Aufgaben, sowie die SystemInfrastruktur und das Zusammenwirken aller Komponenten beschrieben. Alle, zur
Kommunikation der einzelnen Bestandteile, eingesetzten Kommunikationsprotokolle, sowie Datenformate und Schnittstellen sind dort definiert. Damit wird ein Zusammenarbeiten und eine Austauschbarkeit aller, sich an diese Vorgaben haltender
Komponenten, sichergestellt. Die Definitionen lassen dabei jedoch genügend Raum für
anwendungsspezifische Erweiterungen.
Die Spezifikation der Systemabläufe beschränkt sich auf die Durchführung des
Authentifikationsprozesses und den Aufbau einer anwendungstransparenten und verschlüsselten Verbindung. Die daran anknüpfenden Anwendungen sind in ihren Anforderungen und ihrer Komplexität sehr unterschiedlich und deren Spezifikation nicht mehr
Gegenstand dieser Arbeit.
Zur Realisierung eines Gesamtsystems ist auch eine Spezifikation dieser Anwendungen
notwendig. Die Auswahl dieser Anwendungen erfolgt bereits während des Authentifikationsvorgangs. Daher ist bereits in diesem Konzept eine Schnittstelle dafür vorhanden.
In Abschnitt 2.9 werden in Form eines Application Frameworks Richtlinien zur Anwendungsentwicklung vorgeschlagen, auf welche weitere Arbeiten aufbauen könnten.
Dieses System wird im weiteren mit dem Namen mAuth-System bezeichnet.
2.3
Systembeschreibung
Um ein Gerät zu personalisieren, muß es mit eindeutigen, nicht verfälschbaren und nicht
kopierbaren Merkmalen versehen werden. Wie bereits in den Grundlagen beschrieben
ist, sind mobile Geräte auf Grund ihrer Beschaffenheiten dazu alleine nicht geeignet.
53
2.3. SYSTEMBESCHREIBUNG
Zertifikatsausstellung
CK-Anwendung
installieren
Trustcenter
Chipkarte
Durchreichen der
Authentifikationsdaten
Authentifikation
drahtlose Kommunikation
verschlüsselte Verbindung
PoA
oft eine Einheit
betreibt und kommuniziert
ID-,SchlüsselHinterlegung
mobiles Gerät
Institut,
Organisation
Anmeldung
Benutzer
Interaktion
PTD
(Personal Trusted Device)
Kartenausgabe
persönliche
Vorstellung
CK-Anwendungen
prüfen und signieren
optional
Abbildung 2.2: Systemübersicht
54
KAPITEL 2. KONZEPT
Schon daher sind zusätzliche Komponenten notwendig. Das Gesamtsystem besteht aus
folgenden Bestandteilen:
Bestandteile
• Die Chipkarte stellt das eigentliche Token des Systems dar. Sie ist das personalisierende Merkmal und dient der sicheren Verwahrung aller geheimen Daten. Die
Chipkarte mitsamt zugehörigem Lesegerät ist Bestandteil des mobilen Gerätes.
• Das mobile Gerät ist das vertrauenswürdige human Interface“ zur Chipkar”
te. Durch diese Kombination entsteht ein Personal Trusted Device (PTD).
Das PTD ist die Schnittstelle zum Benutzer und zum PoA. In ihm ist auch die
Übertragungstechnik zur Kommunikation mit dem PoA enthalten.
• Der Point of Authentifikation ist jede Art von System, gegenüber dem eine Authentifikation durchgeführt werden soll. Wichtigster Bestandteil des PoA
ist der PoA-Server. Dieser kommuniziert mit dem PTD und muß somit die selbe Übertragungstechnologie und die korrespondierenden Protokolle unterstützen.
Der PoA verfügt über eine Datenbank, in der er die Identifikationsmerkmale zugangsberechtigter PTDs speichert. Das Hinzufügen neuer Zugangsberechtigungen
ist möglich.
• In Zusammenhang mit dem PoA kann noch eine weitere Systemkomponente hinzutreten. Institutionen oder Organisationen können mehrere PoAs als eine
logische Einheit zuordnenbar sein. Ein Beispiel dafür sind Banken, die viele Geldautomaten betreiben. Die Zugangsberechtigungen werden in diesem Falle zentral
in einer Datenbank der entsprechenden Einrichtung verwaltet. Die PoAs sind mit
diesem Datenbestand vernetzt und beziehen von dort ihre Authentifikationsinformationen.
• Das Trustcenter ist der Bestandteil des Systems, dem alle Komponenten Vertrauen entgegenbringen. Neben der Kartenausgabe besteht seine Aufgabe in der
Vergabe einer eindeutigen Kennung und der Zertifikatsausstellung. Gegebenenfalls übernimmt diese Einrichtung auch die Schlüsselgenerierung. Moderne Karten, wie sie in diesem System eingesetzt werden sollen, können mehrere Anwendungen enthalten. Diese Anwendungen müssen vom Trustcenter geprüft und signiert worden sein, bevor sie auf der Karte installiert werden können.
Ablauf
Nach Personalisierung und Aushändigung der Chipkarte und gegebenenfalls nach
persönlicher Vorstellung beim Trustcenter zur Zertifikatsausstellung, kann der Benutzer
sich bei PoAs anmelden.
2.3. SYSTEMBESCHREIBUNG
55
Dieser Anmeldevorgang erfolgt in der Regel persönlich und muß vom Betreiber“
”
des PoA autorisiert werden. Der Benutzer kann mittels seinem PTD die Authentifikationsdaten an die PoA-Datenbank übermitteln. Es sind auch Anwendungen denkbar
die keine vorangehende Anmeldung erfordern. Dazu gehören z.B. das bargeldlose Bezahlen oder das digitale Signieren. In jedem dieser beidem Fälle sind jedoch Zertifikate
zwingende Voraussetzung.
Bevor sicherheitsrelevante Aktionen ausgeführt werden können, muß der Benutzer seine
Identität gegenüber der Chipkarte durch Eingabe einer persönlichen PIN Nummer bestätigen.
Sobald die Authentifikations-Anwendung auf dem PTD aktiv ist, findet ein permanenter Scanvorgang nach in Reichweite liegenden PoAs statt. Der Benutzer kann
auswählen mit welchem er kommunizieren möchte.
Benutzer
Initiiert
Prozeß
PTD - Client
Auth.
PoA - Server
Drahtlose Kommunikation mittels
angepasstes OBEX Protokoll
Authentication
PIN
Direkter
mechanischer
Kontakt, z.B. durch
Tastendrücken
Challenge-Response
Verfahren
Interaktion
Verschlüsselte Transaktion
Überprüfen der
Auth. Daten
erfolgreich ?
Interaktion
fertig ?
Reaktion
Abbildung 2.3: Der Authentifikationsablauf
Zum gewählten PoA wird eine Verbindung aufgebaut. In der Verbindungsphase
findet neben der Verhandlung der Kommunikationsparameter auch die Authentifizierung statt. Dies geschieht mittels dem Challenge-Response Verfahrens. Da vor
Durchführung des Challenge-Response Verfahrens noch die Nutzer ID übertragen werden muß, benötigt ein Authentifikationsvorgang im mAuth System mindestens drei
Schritte. In diesem Vorgang werden auch die Session-Keys für die Verschlüsselung der
folgenden Kommunikation vereinbart.
Nach erfolgreichem Aufbau der Verbindung ist der Nutzer des PTD beim PoA authentifiziert und es besteht ein sicherer Kommunikationskanal zwischen beiden Partnern.
56
2.4
2.4.1
KAPITEL 2. KONZEPT
Aufgaben der mAuth Systemkomponenten
Das Trustcenter
Zertifikat ausstellen
Chipkarte ausgeben
Trustcenter
Benutzer
Chipkartenanwendungen
überprüfen und signieren
Abbildung 2.4: Aufgaben des Trustcenters
Zur Authentifikation ist das Vorhandensein eindeutiger Kennungen (IDs), wie in Abschnitt 2.5.2 näher ausgeführt, eine zwingende Voraussetzung. Die Sicherstellung dieser
Eindeutigkeit ist eine Aufgabe dieser Einrichtung. Im einfachsten Falle bedeutet das
nur die Vergabe einer eindeutigen Seriennummer für die Chipkarte. Da diese
Seriennummern weltweit einmalig sein muß, wird den einzelnen Trustcentern von einer zentralen Instanz, z.B. einer Standardisierungsorganisation wie der ISO, ein fester
Nummern-Block zugewiesen, aus dem sie eigenverantwortlich IDs vergeben können,
ohne daß es zu Überlappungen“ kommen kann.
”
Das Vertrauen in die Integrität der mAuth-Chipkartenanwendung ist von zentraler Bedeutung für die Sicherheit des gesamten Systems. Daher wird diese direkt vom Trustcenter erstellt oder zumindest geprüft und zusammen mit der Benutzer ID auf die Karte
aufgebracht. Abschließend mit der Ausgabe der Karte an den Benutzer übernimmt das
Trustcenter damit die Personalisierungsphase im Lebenszyklus einer Chipkarte (vergleiche Abschnitt 1.5.4).
Für Anwendungen mit geringen Sicherheitsanforderungen ist damit die Rolle des Trustcenters erfüllt. Der Benutzer muß zur Kartenausgabe nicht einmal unbedingt persönlich
dort erscheinen, sondern kann seine Chipkarte auch auf anderen Wege erhalten, solange
nur sichergestellt ist, daß sie vom Trustcenter ausgestellt worden ist.
Für sehr viele Anwendungen ist jedoch eine feste Bindung und Zuordnenbarkeit des
PTD an die Person des Benutzers gefordert. Dies ist mit den bisher beschriebenen
Maßnahmen noch nicht erfüllt. Dazu ist es eine weitere Aufgabe des Trustcenters die
Identität des Benutzers, zumindest einmal persönlich festzustellen. Dabei werden seine kryptographischen öffentlichen Schlüssel verbindlich seinen persönlichen Kenndaten
2.4. AUFGABEN DER MAUTH SYSTEMKOMPONENTEN
57
zugeordnet. Das Zertifikat bestätigt diese Verknüpfung. Durch seine Ablage auf der
Chipkarte wird dieser Zusammenhang für alle überprüfbar.
Das Trustcenter übernimmt bei Bedarf auch die Generierung der kryptographischen
Schlüssel(paare). Dabei muß der Anwender auf die sichere Löschung seiner Schlüsseldaten aus den Systemen des Trustcenters nach der Speicherung auf seiner Chipkarte
vertrauen. Bei vorhandenen Schlüsseln überprüft es den Besitz des privaten Schlüssels,
ohne diesen auszulesen und stellt basierend auf dem zugehörigen öffentlichen Schlüssel
das Zertifikat aus (Abschnitt 2.5.1).
In der Realität wird es nicht nur eine Zertifizierungsinstanz geben, sondern mehrere
Organisationen, die die Funktionalität eines Trustcenters übernehmen. Aus organisatorischen Gründen werden zudem davon mehrere lokale Zweigstellen existieren. Zweigstellen nehmen alle Informationen auf, leiten sie aber zur Zertifikatsaustellung an die
Zentrale weiter.
Mögliche Betreiber von Trustcentern sind z.B. Mobilfunkanbieter. Sie müssen zum
Betrieb ihres Netzes ohnehin schon eine vergleichbare Funktionalität gewährleisten und
besitzen daher bereits die notwendige Infrastruktur. Im Sinne eines allgemeineren und
unabhängigeren Ansatzes her wäre es auch denkbar, daß diese Funktion von staatlichen
Organen wie etwa den Einwohnermeldeämtern übernommen werden könnte.
Es können mehrere dieser Möglichkeiten nebeneinander existieren, es bedarf jedoch
einer gewissen Koordination.
Die öffentlichen Schlüssel aller vertrauenswürdigen Trustcenter müssen den Systemteilnehmern, welche Zertifikate prüfen wollen, bekannt sein. Wegen der beschränkten
Resourcen einer Chipkarte, ist ein Ablegen von Zertifikatsketten auf der Karte nicht
vorgesehen. Die Vertrauenswürdigkeit unbekannter Trustcenter kann aber dennoch mit
Hilfe von Crosszertifikaten hergestellt werden. Dazu muß der PoA, der das fremde Zertifikat prüfen möchte, zumindest zu einer seiner vertrauenswürdigen Zertifikatsstellen eine Kommunikationsverbindung besitzen. Existiert dort ein Crosszertifikat für die fremde Zertifikatsstelle, kann deren Vertauenswürdigkeit und deren öffentlicher Schlüssel
daraus entnommen werden.
Sollen neben der default“ Chipkartenanwendung noch weitere anwendungsspezifische
”
Applikationen auf der Karte untergebracht werden, müssen derartige Programme zuerst vom Trustcenter überprüft werden. Bei erfolgreicher Prüfung werden sie mit einer
Signatur versehen. Nur mit dieser können sie auf der Chipkarte installiert werden.
2.4.2
Die Chipkarte
Die Chipkarte ist die Systemkomponente, welche fest an eine Person gebunden ist. Sie
personalisiert das mobile Gerät und macht es so zum PTD. Dabei ist für die Identifizierung eines Benutzers nur die Karte relevant, nicht das mobile Gerät. Durch die
58
KAPITEL 2. KONZEPT
sichere Speicherung
und Verwaltung
geheimer Daten
Chipkarte
Ausführen autentifikationsrelevanter kryptographischer
Operationen
Abbildung 2.5: Chipkarte - Aufgaben
Standardisierung der Kartenfunktionen und ihrer Schnittstellen ist sie unter verschiedenen mobilen Geräten austauschbar.
Auf ihr werden alle personenbezogenen Identifikationsdaten und die kryptographischen
Schlüssel gespeichert, sowie eine Kennung der ausstellenden Instanz und optional deren
öffentlicher Schlüssel.
Diese Daten könnten theoretisch auch direkt auf dem mobilen Gerät gespeichert werden. Jedoch sind diese Geräte meist frei programmierbar und bieten keine wirksamen
Speicherschutzmechanismen. Das Risiko des böswilligen Ausspähens dieser geheimen
Daten, z.B. durch Einschleusen dafür manipulierter Programme (Trojaner), wäre somit
viel zu groß.
Die Geheimhaltung der Schlüssel ist jedoch unbedingt notwendig (siehe Abschnitt 1.4).
Die Chipkarte gewährleistet die sichere Verwahrung dieser sensiblen Daten.
Bei der verwendeten Chipkarte handelt es sich um eine Prozessorkarte mit der Fähigkeit kryptographische Algorithmen auszuführen. Sämtliche kryptographischen Operationen, welche den geheimen Schlüssel des Benutzers benötigen, werden direkt auf der
Karte ausgeführt. Der Schlüssel muß und darf so die Chipkarte nie verlassen! Karten,
die mehr als einen Verschlüsselungsalgorithmus unterstützen, müssen Speichermöglichkeiten für alle jeweils benötigten Schlüssel, sowie bei Verwendung asymmetrischer Algorithmen, optional zusätzlich für Zertifikate bereitstellen.
Spezielle Anwendungsmodelle (vergleiche Abschnitt 2.9) können neben den in der
mAuth Chipkartenapplikation vorhandenen Identifikationsdaten, zusätzliche Schlüssel,
Daten und Funktionen benötigen. Diesen Anforderungen wird das mAuth System durch
die optionale Möglichkeit, neben der default“ mAuth Chipkartenanwendung noch wei”
tere anwendungspezifische Applikationen zu instalieren, gerecht. Diese Chipkartenanwendungen dürfen die Sicherheit des Gesamtsystems keinenfalls beeinträchtigen. Karten, die diese Fähigkeit bieten, müssen daher durch das Design ihres Betriebsystems
gewährleisten, daß alle Anwendungen in sicher getrennten Umgebungen ablaufen und
keine Möglichkeit besitzen, auf die Daten oder den Code der anderen Applikation zuzugreifen.
59
Chipkarten Betriebssystem
Installations-Kontrollapplikation
mAuth Applikation
Daten:
•ID1, ID2,...
•Cert1, Cert2,...
•Key(pair)1,Key(pair2),...
Funktionen:
Custom
App.
1
Custom
App.
2
...
Custom
App.
n
•Verify PIN1, PIN2, ...
•Add Data ...
•(de/en)crypt Algo1, Algo2,..
Abbildung 2.6: Mehrere Applikationen auf einer mAuth Chipkarte
Ebenso müssen sie Sicherheitsmechanismen, welche die Installation zusätzlicher Anwendungen kontrollieren, besitzen. Das ist notwendig, da trotz aller Schutzsmechanismen
des Kartenbetriebsystems, immer die Gefahr besteht, daß fremde Applikationen die Sicherheit gefährdenden Programmcode enthalten. Diese Sicherheitsmechanismen sorgen
dafür, daß nur geprüfte und mit einer gültigen Signatur eines Trustcenters versehene Anwendungen installiert werden können. An solche Anwendungen wird ein, über
den Programmcode generierter Hashwert, der mit einem dafür vorgesehenen geheimen
Schlüssel des Trustcenters verschlüsselt worden ist, angehängt. Dies ist dem MACVerfahren (siehe Abschnitt 1.4.2.6) ähnlich. Die Karte verfügt über den passenden
Schlüssel und kann so entscheiden ob sie eine Anwendung akzeptiert.
Um die Identität des Benutzers gegenüber der Karte sicherzustellen, erfordert der Zugriff auf die meisten Funktionen der Karte die Eingabe einer PIN. Dabei sind die bei
Chipkarten üblichen Sicherheitsmechanismen, wie Fehlbedienungszähler und PUK1 implementiert (vergleiche Abschnitt 1.5). Der Benutzer kann seine PIN Nummern frei
wählen und jederzeit ändern.
Über eine weitere PIN werden die Verwaltungsfunktionen der Chipkarte zugänglich.
Sie erlauben das Speichern und Ändern personenbezogener Daten und Schlüssel. Das
Auslesen des privaten Schlüssel ist jedoch nie möglich. Auch diese PIN kann vom
Benutzer geändert werden.
2.4.3
Das mobile Gerät
Das mobile Gerät ist das Bindeglied zwischen Benutzer, Chipkarte und PoA. Es besitzt
zu jeder dieser Komponenten die passenden Schnittstellen und nimmt so eine zentrale
Rolle im Gesamtsystem ein.
1
Personal Unblocking Key
60
KAPITEL 2. KONZEPT
„Human Interface“
Benutzer
Verschlüsselung
der Verbindung zum PoA
mobiles Gerät
Peer Discovery
Drahtlose Kommunikation
mit dem PoA
PoA
Abbildung 2.7: Mobiles Gerät - Aufgaben
2.4.3.1
Hardware
Das mobile Gerät besitzt ein Display und Eingabemöglichkeiten zur Interaktion mit
dem Benutzer. Auch die lokale Übertragungstechnik zur Kommunikation mit dem PoA
ist darin integriert. Im Vergleich zur Chipkarte verfügt es über mehr Resourcen an
Rechenleistung und Speicher, so daß damit die Ausführung komplexerer Anwendungen, die Abwicklung von aufwendigen Übertragungsprotokollen und die Verschlüsselung
größerer Datenmengen in ausreichender Geschwindigkeit möglich sind. Das Chipkartenlesegerät ist fester Bestandteil des mobilen Gerätes.
2.4.3.2
Software
Auf dem mobilen Gerät wird die mAuth-Client Anwendung ausgeführt. Sie ist die
Gegenstelle zum PoA-Server (Abschnitt 2.4.4). Der Start der Anwendung wird normalerweise vom Benutzer initiiert, er kann unter bestimmten Bedingungen aber auch vom
Gerät automatisch erfolgen (Abschnitt 2.5.4).
In der Inititalisierungsphase wird neben der Überprüfung der PIN und der Abfrage
der Karteneigenschaften auch die Kommunikationsschnittstelle initialisiert. Daraufhin
startet bei Erfolg das Peer Discovery (Abschnitt 2.5.4) und die gesammelten Informationen werden dem Benutzer dargestellt.
Desweiteren wird von der mAuth Client Anwendung der Authentifikationsablauf
(Abschnitt 2.5.2) und der Anmeldevorgang an neuen PoAs (Abschnitt 2.5.3) gesteuert. Die Abwicklung, der zur Kommunikation mit den einzelnen beteiligten Komponenten notwendigen Protokolle, gehört ebenfalls zu den Aufgaben dieser Anwendung.
61
Darin ist auch die Verschlüsselung der anwendungsspezifischen Kommunikation eingeschlossen.
In ihrer Rolle als Schnittstelle zwischen Mensch und Maschine gehört die Darstellung relevanter, vom PoA-Server übermittelter Informationen für den Benutzer zu den
Hauptaufgaben dieser Anwendung. Diese Darstellungsform ist von den Ressourcen des
mobilen Gerätes abhängig und soll auf diese bestmöglich angepaßt sein. Von der Komplexität dieser Anwendung hängt der Funktionsumfang und damit die Flexibilität der
unterstützten Applikationsmodelle nach erfolgreicher Authentifikation ab (vergleiche
Abschnitt 2.9).
Optional kann eine Funktion zur Generierung der kryptographischen Schlüssel vorhanden sein. Die Erzeugung der Schlüssel vom Benutzer selbst, ist einer Erzeugung
durch eine dritte Instanz vorzuziehen. Selbst wenn dieser, wie im Falle eines Trustcenters, Vertrauen entgegengebracht wird, kann sich der Benutzer dabei nie sicher sein, ob
wirklich alle geheimen Schlüsseldaten gelöscht worden sind. Da jedoch auch auf mobilen
Geräten, z.B durch manipulierte Software, immer die Gefahr des Ausspähens besteht,
bleiben die Risiken und Vorteile beider Möglichkeiten gegeneinander abzuwägen.
Optimal wäre eine Schlüsselerzeugung auf der Chipkarte selbst, die notwendigen Zufallswerte könnten von Außen“ zugeführt werden. Da dies jedoch ein sehr recheninten”
siver Vorgang ist, werden vermutlich erst zukünftige Karten diese Möglichkeit bieten.
2.4.4
Der PoA
Als Point of Authentifikation wird jedes System bezeichnet, gegenüber welchem eine
Authentifikation stattfinden soll. Diese Systeme können in ihrer Funktion und Komplexität sehr unterschiedlich sein.
Um das Zusammenarbeiten mit den Komponenten dieses Entwurfs sicherzustellen, muß
nur die Funktionsgruppe des PoA, die mit dem PTD kommuniziert, standardisiert
werden. Diese Komponennte wird als PoA-Server bezeichnet.
2.4.4.1
Hardware
Der PoA-Server steht über Aktoren mit dem Rest des PoA-Systems in Verbindung und
kann damit Aktionen, wie z.B. das mechanische Öffnen einer Türe, ausführen.
Um die Kommunikation mit vielen unterschiedlichen PTDs zu ermöglichen, kann der
Server mehrere verschiedene physikalische Übertragungstechnologien unterstützen. Je
nach Aufgabenstellung des PoA kann es jedoch notwendig sein, gleichzeitig immer nur
jeweils eine aktive Verbindung zuzulassen.
Der PoA-Server verfügt über ausreichend Ressourcen, um wie das PTD, alle Protokolle
und kryptographischen Operationen ausführen zu können.
62
KAPITEL 2. KONZEPT
Verifizieren der
Authentifikationsdaten
Hinzufügen und Ablegen
neuer Zugangsberechtigungen
Point of
Authentication
Benutzer
verschlüsselte,
drahtlose Kommunikation
mit dem PTD
Ausführen von Aktionen
nach erfolgreicher Auth.
mobiles Gerät
PTD
Abbildung 2.8: Point of Authentifikation - Aufgaben
In einer Benutzer-Datenbank sind alle authentifikations-relevanten Daten der zugangsberechtigten Benutzer gespeichert. Zur Kontrolle des Hinzufüges, Änderns oder
Löschens dieser Daten muß ein Administrator-Interface vorhanden sein. Über dieses
Interface kann der PoA-Administrator die, vom PTD übermittelten Daten überprüfen
und in Anbhängigkeit davon die Anmeldung entweder akzeptieren oder ablehnen. Die
physikalische Auführung dieses Interfaces soll nicht weiter spezifiziert werden. Denkbare Realisierungen reichen von einem kleinen LCD Panel mit Ziffern-Tastenblock, bishin
zu einer Workstation mit graphischer Oberfläche.
Der PoA-Server kann gegebenenfalls über weitere Kommunikationsverbindungen, z.B.
zu zentralen Datenbanken oder zu Trustcentern verfügen.
Eine am PoA angebrachtes, für den Benutzer sichtbares, Display zur Anzeige des aktiven Kommunikationspartners, kann zur Überprüfung einer korrekten Verbindung sinnvoll sein. Dies kann z.B. in Räumen, in denen mehrere Geldautomaten nebeneinander
stehen, notwendig sein, um festzustellen an welchem davon die Geldausgabe erfolgen
wird.
2.4.4.2
Software
PoA-Server-Applikation und PTD-Client-Anwendung verwenden dasselbe Kommunikationsprotokoll. Die PoA-Server-Anwendung reagiert auf Anfragen des PTD und steuert
das Verhalten des PoA.
Die Art der kryptographischen Algorithmen sind im mAuth System nicht fest vorgeschrieben. Sie können sich vielmehr je nach Kostenfaktor der eingesetzten Komponenten und der technischen Entwicklung ändern. Um ein möglichst breites Feld verschie-
63
dener Chipkarten und mobiler Geräte abzudecken, kann ein PoA-Server daher mehrere
Verschlüsselungs-Algorithmen unterstützen. Die tatsächlich eingesetzten Algorithmen
werden in der Verbindungsphase ausgehandelt. (Abschnitt 2.5.2).
Bei einem eingehenden Authentifikationswunsch überprüft die PoA-Server-Anwendung
die empfangenen Authentifikationsdaten mit den in der PoA-Datenbank gespeicherten
Informationen. In dieser Datenbank sind die Kenndaten eines jeden zugangsberechtigten Benutzers abgelegt. Diese Kenndaten bestehen mindestens aus einer eindeutigen
Kennung des Benutzers, sowie dessen (öffentlichen) Schlüssel. Abgesehen davon können
noch weitere benuzterspezifische Daten in diesem Datensatz vorhanden sein. Je nach
Aufgabe des PoAs, kann dies, z.B. bei einem Anmeldesystem für einen Rechnerpool,
der Loginname des Benutzers sein.
Eine Ausnahme von diesen Minimalanforderungen für einen Benutzerdatensatz bildet die Verwendung von Zertifikaten und Trustcenter-Keys. Dabei müssen nicht die
Schlüssel oder kompletten Zertifikate gespeichert werden. Es reicht eine eindeutige
Kennung eines Zertifikats in der Datenbank abzulegen. Der Benutzer-Schlüssel kann
dem vom PTD übermittelten Zertifikat während des Authentifikationsprozesses (siehe
2.5.2) entnommen werden. Es ist dabei unbedingt zu fordern, daß die Integrität des
Zertifikats vorher verifiziert worden ist.
Bei erfolgreicher Authentifikation kann über die gesicherte Verbindung eine beliebige
Interaktion stattfinden. Der PoA kann mittels seiner Aktoren darauf reagieren. Andernfalls beendet der Server die Verbindung. Der PoA-Server kann wie der PTD-Client
mehrere verschiedene Applikationsmodelle unterstützen. Die Verschlüsselung der Kommunikationsverbindung ist ebenfalls Aufgabe der PoA-Server-Software.
Der PoA-Server muß für seine Zugangs-Datenbank auch Verwaltungsfunktionen bereitstellen. Ein Administrator muß die Annahme neuer Berechtigungen kontrollieren
können. Dabei soll sowohl eine manuelle Eingabe der Daten, als auch eine Übertragung vom PTD möglich sein.
Darüberhinaus müssen vorhandene Zugangsberechtigungen jederzeit wieder gelöscht
werden können. Auch das Hinzufügen, Ändern und Löschen von Trustcenter-PublicKeys und -IDs soll damit möglich sein. Der PoA-Server muß dabei über Sicherheitsmechanismen verfügen, die diese Administratorfunktionen nur berechtigten Personen
gewähren.
Die Überprüfung von Zertifikaten unbekannter Trustcenter kann durch eine Kommunikationsverbindung zu bekannten Trustcentern mittels dort vorhandener CrossCertificates erfolgen. Diese optionale Verbindung liegt im Verantwortungsbereich von
Trustcenter und PoA und wird in dieser Arbeit nicht spezifiziert.
64
2.4.4.3
KAPITEL 2. KONZEPT
Übergeordnetes Institut oder Organisation
Es ist nicht davon auszugehen, daß die Benutzerdatenbank immer direkt im PoA selbst
implementiert sein wird.
Bei einem Verbund zusammengehöriger PoAs soll nicht die Anmeldung an jedem einzelnen Gerät notwendig sein, sondern vielmehr an zentraler Stelle, bei der Betreiberorganisation der PoAs, erfolgen. Beispiele für solche Verbunde von PoAs sind Geldautomaten
einer Bank oder der Zugang zu einem Rechnersytemen einer Universität oder Firma.
Der Betrieb der Benutzerdatenbank, die Verwaltung der Daten und auch die Anmeldung neuer Nutzer erfolgt dabei an zentraler Stelle. Wird der Benutzer von dieser Stelle
autorisiert, kann er ohne weitere Anmeldungen alle PoAs, die zu dieser Organisation
gehören, nutzen.
2.5
2.5.1
Prozesse
Zertifikatsaustellung
Eine Zertifikatsaustellung ist nur bei Verwendung von Chipkarten, die auch asymmetrische Verschlüsselungsverfahren unterstützen, möglich. Das Zertifikat verknüpft
überprüfbar die Person des Benutzers mit seinem öffentlichen Schlüssel. Das Truscenter bestätigt durch die Zertifiakatsaustellung diesen Zusammenhang. Daher muß der
Benutzer persönlich beim Trustcenter zur Ausstellung erscheinen.
Falls der Benutzer noch keine geeigente mAuth Chipkarte besitzt, erhält er diese direkt
dort. Das Truscenter kann dann auch, falls notwendig die Schlüsselgenerierung übernehmen. Die Übertragung der Schlüssel auf die Karte erfolgt direkt über ein Chipkartenlesegerät des Trustcenters. Es wäre auch denkbar, die generierten Schlüssel drahtlos
über das PTD auf die Chipkarte zu transferieren, jedoch müsste das PTD dazu ein
zero-knowledge Protokoll“ zum Session-Schlüsselaustausch beherrschen, da zu diesem
”
Zeitpunkt noch keine Schlüssel auf der Karte vorhanden sind, um einen sicheren Übertragungskanal aufzubauen. Eine solche Möglichkeit ist derzeit im mAuth System nicht
spezifiziert und kann im Rahmen zukünftiger Erweiterungen realisiert werden.
Die Übertragung über ein Chipkartenterminal am Trustcenter stellt jedoch keine nennenswerte Einschränkung des Bedienkomforts dar, da dieser Vorgang nur einmal erfolgen und der Benutzer dazu ohnehin persönlich anwesend sein muß. Desweiteren ist, falls
dies mit der verwendeter Karte oder PTD möglich ist, eine direkte Schlüsselerzeugung
durch den Benutzer ohnehin vorzuziehen.
Ein Mitarbeiter des Trustcenters nimmt die Feststellung der Identität des Nutzers vor.
Das kann z.B. durch die Vorlage und Überprüfung eines Lichtbildausweises, erfolgen.
Er nimmt auch die, für die Zertifikatsaustellung notwendigen Daten auf und liest
2.5. PROZESSE
65
den öffentlichen Schlüssel aus der Karte aus. Gleichzeitig überprüft er mittels eines
Challenge-Response Verfahrens, ob die Karte tatsächlich über den passenden privaten
Schlüssel verfügt. Da bei diesen Vorgängen keine geheimen Informationen übertragen
werden, kann die Kommunikation mit der Karte nun auch über die drahtlose Schnittstelle des mobilen Geräts erfolgen.
Das Truscenter verwendet zu diesem Zwecke einen PoA-Server. Das Auslesen
des öffentlichen Schlüssels und der KartenID erfolgt mittels eines normalen PoAAnmeldeprozesses (wie in Abschnitt 2.5.3 beschrieben). Anschließend muß der Benutzer mit seinem PTD einen Authentifikationsprozess zu diesem PoA-Server durchführen
(vergleiche Abschnitt 2.5.2). Gelingt diese Authentifikation mit den vorher ausgelesenen Daten, ist der Besitz des zum öffentlichen Schlüssel zugehörigen privaten Schlüssels
nachgewiesen und das Zertifikat kann erstellt werden.
Chipkarte
Benutzer
Trustcenter
Kartenausgabe
Schlüsselgenerierung
Schlüsselablage auf Karte
Übermittlung von KartenID und
öffentlichen Schlüssel
Challenge
Response
PoA
Anmeldeprozeß
Authentifikationsprozeß
Identitätsnachweis z.B. durch
Vorlage des Personalausweises
Zertifikatserstellung
Authorisation der
Zertifikatsablage
Ablage des Zertifikats
optional
Abbildung 2.9: Ablauf der Zertifikatsausstellung
Der Inhalt und genaue Aufbau, der in diesem System verwendeten Zertifikate, ist in
Abschnitt 2.8.2 beschrieben. In der derzeitigen Spezifikation des mAuth Systems erfolgt
die Übertragung des fertigen Zertifikats auf die Chipkarte direkt durch ein Chipkartenterminal des Truscenters. Um eine drahtlose Übertragung zu ermöglichen, müsste dieser Anwendungsfall zum einen speziell durch die PTD-Client-Anwendung unterstützt
und zum anderen eine Authentifizierung des PoAs beim PTD vorgesehen werden. Eine
derartige Authentifizierung ist notwendig, um sicherzustellen, daß nur von berechtigter Stelle Zertifikate akzeptiert werden. Eine Authentifikation des Servers beim Client
66
KAPITEL 2. KONZEPT
wird derzeit jedoch noch nicht unterstüzt, da dies nur für sehr wenige Anwendungsfälle
notwendig ist. In zukünftigen Erweiterungen kann diese Möglichkeit realisiert werden.
Bei Chipkarten, die mehrere asymmetrische Verfahren unterstützen, sind für jeden
Algorithmus unterschiedliche Schlüsselpaare notwendig. Für jedes dieser Paare muß
daher ein eigenes Zertifikat erstellt werden.
Der Benutzer muß das Aufbringen neuer Daten auf die Chipkarte durch die Eingabe der
dafür vorgesehenen PIN autorisieren. Eine Kopie des Zertifikats wird in der Datenbank
des Trustcenters abgelegt.
2.5.2
Authentifikationsprozess
Die Kommunikation zwischen PTD und PoA findet über einen zu Beginn unsicheren
Kanal statt. Daher müssen zur Authentifizierung Methoden der Kryptologie benutzt
werden.
Als kryptographisches Protokoll wird dazu das Challenge-Response Verfahren eingesetzt (siehe Abschnitt 1.4.5.2). Es sollen sowohl asymmetrische als auch symmetrische
Algorithmen verwendet werden können. Es ist dabei durchaus möglich, daß sowohl
PoA als auch PTD mehrere Verfahren unterstützen. In der Verbindungsaufbauphase
handeln Server und Client den tatsächlich verwendeten Algorithmus aus. Das Protokoll
erlaubt dabei den einzelnen Möglichkeiten Prioritäten zuzuordnen, so daß der sicherste
Algorithmus, den beide gemeinsam unterstützen, ausgewählt werden kann.
So weit als möglich sollen nur asymmetrische Algorithmen verwendet werden. Bei symmetrischen Verfahren verfügt nicht nur die Karte, sondern mindestens auch ein PoA
über den geheimen Schlüssel. Der Schlüssel muß dabei die Karte verlassen und auf
irgendeine Art übertragen werden. Bei asymmetrischen Verfahren ist das nicht notwendig, weshalb sie als wesentlich sicherer einzustufen sind.
Symmetrische Kryptomethoden werden nur unterstützt, um die kostengünstige Realisierung von Systemen geringer Sicherheitsanforderungen und sehr beschränkten Resourcen zu ermöglichen. Viele PoAs werden die Verwendung symmetrischer Verfahren
ablehnen und einige Anwendungen sind ohne asymmetrische Verschlüsselung überhaupt nicht möglich. Karten, die nur symmetrische Algorithmen unterstützen, werden
ein sehr eingeschränktes Einsatzfeld haben.
Die Authentifizierung findet in der Verbindungsaufbauphase zwischen PTD und PoA
statt.
Da PoAs in der Regel Zugangsberechtigungen für mehr als eine Person verwalten,
ist es notwendig eine eindeutige Benutzerkennung zu Beginn des Prozesses zu übermitteln. Dazu ist im ersten CONNECT-Paket zumindest die Chipkarten-Seriennummer
und, falls vorhanden, auch ein oder mehrere Zertifikate enthalten. Diese ID Informationen müssen in der Reihenfolge ihrer bevorzugten Verwendung gesendet werden. Die
2.5. PROZESSE
67
PTD
PoA
CONNECT Request [supported Capabilities, ID1, ID2]
CONNECT Response UNAUTHORISIZED [choosen Capabilities]
...
CONNECT Request [supported Capabilities, IDn]
Berechnung
der Response
passende
ID gefunden
CONNECT Response UNAUTHORISIZED [choosen Capabilities,Challenge, Session-Key]
CONNECT Request [choosen Capabilities Ack, IDn, Response, Session-Key Ack]
Response
paßt zur
Challenge
CONNECT Response OK/SUCCESS [choosen Capabilities]
Abbildung 2.10: Authentifikations Ablauf
favorisierte Kennung zuerst. Es obliegt dem PoA zu entscheiden, aufgrund welcher
ID er seine Datenbank referenziert. Die Übermittlung der IDs kann auch auf mehrere aufeinanderfolgende CONNECT-Pakete verteilt sein. Der Client erkennt am Empfang
einer RESPONSE, welche nur den Response-Code UNAUTHORISIZED enthält, aber keine
CHALLENGE, daß die ausgesendete ID nicht aktzepiert worden ist. Er sendet solange neue
CONNECT REQUESTS, aus bis eine passende ID gefunden oder alle vorhandenen bereits
gesendet worden sind.
Die Zertifikate implizieren zwar den zugehörigen Verschlüsselungsalgorithmus, da ihre
Verwendung jedoch optional ist, ist es zusätzlich notwendig in diesem Schritt auch
die Typen der unterstützten Verschlüsselungsmethoden mitzusenden. Auch hier ist die
Reihenfolge von Bedeutung. Das am meisten priorisierte Verfahren ist das erste. Auf
die gleiche Weise werden die zur Kommunikationsverschlüsselung vorhandenen Arten
von Algorithmen übermittelt.
Im Antwortpaket des PoA lehnt dieser, falls er keine unauthentifizierten Verbindungen
zuläßt, den Verbindungsaufbau zuerst ab. In diesem Paket sind eine genügend lange Zufallszahl, die sogenannte Nonce zur Durchführung des Challenge-Response Verfahrens,
sowie die Kennung des, vom PoA gewählten, Authentifikations-Algorithmus enthalten.
Auch der Session-Key, für die Kommunikationsverschlüsselung und der Typ des dazu
verwendeten Algorithmus, wird in dieser Phase übertragen. Der Session-Key ist dabei
mit dem (öffentlichen) Schlüssel des PTD verschlüsselt und kann nur von diesem wieder
dechiffriert werden.
Der Empfang dieser Antwort veranlaßt das PTD eine erneute CONNECT-Anfrage auszusenden. Diese enthält die, mit seinem (private) Key verschlüsselte Nonce. Kann der PoA
die chiffrierte Nonce mit dem korrespondierenden Key dechiffrieren und stimmt sie mit
der ursprünglich ausgesendeten überein, so ist das PTD authentifiziert. Anderweitig
wird die Verbindung beendet.
68
KAPITEL 2. KONZEPT
Können keine übereinstimmenden Methoden zur Authentifizierung oder zur Kommunikationsverschlüsselung gefunden werden oder fehlt der Eintrag des PTD in der Zugangsdatenbank des PoA, findet kein Verbindungsaufbau statt.
Eine Authentifizierung des PoA beim PTD ist nicht vorgesehen. Dazu müßten Schlüssel
auf dem PTD abgelegt werden. Die Zielsetzug dieses Systems ist die Authentifikation
mit dem PTD an einem PoA, nicht umgekehrt. Zudem ist es im Rahmen dieser Spezifikation für Anwendungen, die diese Funktionalität fordern möglich, dies durch anwendungsspezifische Chipkartenapplikationen zu verwirklichen. Die Implementierung des
Verfahrens ist dem Dienstanbieter dieser Applikationen überlasssen.
2.5.3
Anmelden bei PoAs
Um neue Zugangsberechtigungen zu erlangen, werden bei konventionellen mechanischen Schlüsseln, Schlüssel dem Schlüsselbund des Benutzers hinzugefügt. Im Gegensatz dazu erweitert der Benutzer bei diesem System die Zugangsdatenbank des neuen PoA um seinen Schlüssel. Unabhängig von der Anzahl der Zugangsberechtigungen
besitzt der Nutzer immer nur sein persönliches Schlüssel(paar). Bei Karten, welche
mehrere Algorithmen unterstützen, sind natürlich Schlüssel für jeden Algorithmus vorhanden.
Um Zugang zu neuen PoAs zu erhalten, muß er seinen Schüssel und seine persönliche ID
an den PoA übermitteln. Diese Anmeldung geschieht mittels eines leicht modifizierten
Authentifikationsprozeß. Die PTD-Anwendung muß diese Betriebsart unterstützen.
Der Benutzer kann in der Auswahlliste verfügbarer PoAs neben dem normalen Authentifikationsvorgang auch die Option Anmelden wählen. Der Unterschied besteht darin,
daß hier zusätzlich zu den Identifikationsdaten auch noch der (public) Key mit übertragen wird. Der PoA-Server ist dazu von seinem Administrator in einen Modus versetzt
worden, in dem er nicht-authentifizierte Verbindungen akzeptiert, jedoch außer der Anzeige der empfangenen Daten zur Überprüfung für den Administrator, keine weiteren
Aktionen ausführt.
PTD
PTD befindet
sich im „Neuanmeldemodus“
PoA
CONNECT Request [supported Capabilities, ID1, (public) Key]
CONNECT Response OK/SUCCESS
DISCONNECT Request
DISCONNECT Response OK/SUCCESS
PoA Admin überprüft die
Anmeldedaten
Bestätigte ID & Key
werden in die Datenbank
aufgenommen
Abbildung 2.11: Ablauf einer Neuanmeldung bei einem PoA
2.5. PROZESSE
69
Hat sich der Administrator persönlich von der Identität des neuen Benutzers und der
Korrektheit seiner Daten überzeugt, genehmigt er das Hinzufügen der Zugangsdaten
zur PoA-Datenbank. Anschließend wird zur Sicherheit ein Authentifikationsvorgang
durchgeführt, der positiv verlaufen muß.
Bei der Verwendung von Zertifikaten kann die persönliche Identitätsprüfung auch entfallen. Betreiber-Institute oder Organisationen von PoAs (vergleiche Abschnitt 2.4.4.3)
haben meist bereits die persönlichen Daten ihrer Benutzer“ erfaßt. Hier kann, sofern
”
Zertifikate eingesetzt werden, eine Zugangsberechtigung während des ersten Authentifikationsvorgangs ohne expliziten Anmeldevorgang erfolgen.
Die Identität ist mit dem Zertifikat eindeutig bestätigt und beglaubigt. Darüberhinaus
ist darin der öffentliche Schlüssel enthalten. Befindet sich ein, zu den Zertifikatsdaten
passender Benutzer bereits in der Datenbank, kann sofort der Zugang gewährt und evtl.
der Schlüssel oder das Zertifikat hinzugefügt werden. Das Hinzufügen von Zertifikaten
und den darin enthaltenen eindeutigen Kennungen, kann die Datenbankabfrage bei
weiteren Authentifikationsvorgängen beschleunigen.
Zu Beginn der Kommunikation verfügen beide Kommunikationspartner über keinerlei
Schlüssel voneinander. Die initiale Übertragung ist also unverschlüsselt. Besonders in
diesem Falle tritt der Nachteil der Verwendung symmetrischer Verschlüsselung bei Authentifikationsvorgängen zu Tage. Der geheime Schlüssel muß dabei einmal auf einem
unsicheren Kanal übertragen werden.
Durch die Verwendung von zero-knowledge-Protokollen, wie z.B. dem Diffie-Hellmann
Verfahren, könnte durchaus auch ohne Kenntnis irgendwelcher Schlüssel des Kommunikationspartners ein Session-Key vereinbart werden und damit die Übertragung
gesichert werden. Da symmetrische Authentifikation jedoch nur auf Geräten, die auf
Grund ihrer geringen Resourcen oder ihres geringen Preises keine andere Möglichkeit
haben, eingesetzt werden sollen, werden diese normalerweise auch nicht die Fähigkeit
besitzen ein zero-knowledge-Protokoll auszuführen. In diesem Falle sollte, auch wenn
das den Bedienkomfort einschränkt, ein Einlesen der notwendigen Daten über ein Chipkartenterminal am PoA einer drahtlosen Übertragung vorgezogen werden.
2.5.4
Peer Discovery
Durch den Einsatz drahtloser Kommunikation zwischen PTD und PoA kann mehr als
nur ein PoA in Reichweite des PTD liegen. Der Benutzer muß die Möglichkeit besitzen,
den gewünschten Kommunikationspartner auszuwählen. Es ist die Aufgabe der PTDAnwendung, im Operationsradius liegende PoAs aufzuspüren, Informationen über sie
abzufragen und sie dem Nutzer zur Auswahl darzustellen. Dieser Vorgang wird als
Peer Discovery bezeichnet.
Anders als das eigentliche Kommunikationsprotokoll (siehe Abschnitt 2.8.3), welches
auf der Applikationsschicht angesiedelt ist, um unabhängig von der verwendeten Über-
70
KAPITEL 2. KONZEPT
PoA
PoA
sammelt die Informationen in einer Datenbank
PTD
Database
PoA
Peer Discovery Pakete
PoA
PoA
PoA
Reichweitengrenze der
eingesetzten
Übertragungstechnologie
PoA
Abbildung 2.12: Peer Discovery Prinzip
tragungstechnologie zu sein, ist der Peer Discovery-Prozeß von den unteren Protokollschichten abhängig und muß auf deren Funktionen zurückgreifen. Die Implementierung
dieses Verfahrens und seine Fähigkeiten hängen somit von der eingesetzten Übertragungstechnologie ab.
Lokale Übertragungstechnologien sind meist auf eine Ad Hoc“ Kommunikation aus”
gelegt. Das bedeutet, es bedarf keiner manuellen Konfiguration der Kommunikationspartner, sondern sie besitzen die Möglichkeit die benötigten Parameter dynamisch über
ihre unteren Protokollschichten auszutauschen, um eine Verbindung auf Schicht 2 (Link
Level) des ISO-OSI Modells aufzubauen.
Dazu findet auf dieser Ebene ein Discovery-Vorgang statt. Damit werden alle in Reichweite liegenden, empfangsbereiten Geräte, welche eine kompatible Übertragungstechnik
nutzen, aufgespürt. Ihre Link-Level-Adressen sowie diverse Zusatzinformationen werden in einer Datenbank des Übertragungsprotokollstack abgelegt. Die Ausführung dieses Discovery-Vorgangs ist Aufgabe der Protokollstacks des jeweils eingesetzten Übertragungsverfahrens.
Das Peer Discovery-Verfahren dieses Systementwurfs setzt das Vorhandensein eines
solchen Basisdiensts voraus und nutzt dessen Datenbank. Sobald die AuthentifikationsClient-Anwendung aktiv ist, liest sie die Einträge dieser Datenbank aus und versucht
zu jedem dort aufgeführten Gerät eine Verbindung aufzubauen.
Dieser Verbindungsaufbau erfolgt zunächst auf Link-Level. Die Abfrage der PoAInformationen geschieht dann auf Applikationsschicht mittels eines speziellen REQUESTPakets (siehe Abschnitt 2.8.3), ohne jedoch einen kompletten Verbindungsaufbau zu
durchlaufen. Auf diese Request Pakete darf ein PoA-Server immer antworten, selbst
wenn er sich gerade in einer Kommunikation mit einem anderen PTD befindet und
2.6. KOMMUNIKATIONSMODELLE
71
nicht mehrere gleichzeitige Verbindungen unterstützt. Auf ein derartiges Paket wird
nur ein PoA-Server korrekt antworten. Alle anderen Geräte mit passender Übertragungstechnik, welche sich auch noch in Reichweite befinden, können dadurch bereits
ausgesondert werden.
PTD
mAuth OBEX
Application Layer
PoA
Link Layer
Link Layer
mAuth OBEX
Application Layer
... ...
Link Layer
Discovery
Database
Link Layer Discovery
periodisch
Link Layer Discovery
Abhängig von
der
eingesetzten
...
mAuth OBEX Peer Discovery Request
mAuth OBEX Peer Discovery Response
Hardware
unabhängig
Abbildung 2.13: Peer Discovery-Ablauf
Die Informationen sammelt das PTD in einer eigenen Datenbank der AuthentifikationsAnwendung. In den Antwortpaketen sind neben einem Bezeicher des PoA auch seine
Fähigkeiten enthalten. Dadurch können PoAs, deren Anforderungen vom PTD, oder
umgekehrt nicht erfüllt werden können, in der Auswahlliste entsprechend gekennzeichnet oder gar nicht erst aufgenommen werden.
Je nach den Fähigkeiten des Discovery-Protokolls auf Link-Layer sollte, wenn möglich
bereits auf dieser Ebene eine eindeutige Kennung des jeweiligen PoAs mitgesendet werden. Das eigentliche Peer Discovery findet nur dann statt, wenn die AuthentifikationsAnwendung bereits gestartet ist. Das Discovery auf unteren Protokollschichten ist dagegen Aufgabe des Betriebssystems und wird laufend durchgeführt. Es wäre damit
möglich, bei Annäherung an dafür freigegebene PoAs, die Authentifikationsanwendung
automatisch zu starten und den Authentifikationsvorgang zu diesem PoA zu aktivieren. So könnte damit z.B. das automatische Aufschließen der Haustüre oder des eigenen
Autos bei Annäherung realisiert werden.
2.6
2.6.1
Kommunikationsmodelle
Übersicht
Die Gesamtfunktionalität des Systems wird nur durch das Zusammenwirken der Einzelbestandteile erreicht. Hierfür müssen die Komponenten miteinander kommunizieren.
72
KAPITEL 2. KONZEPT
Abhängig von den Kommunikationspartnern und ihrer Aufgabenstellung findet diese Kommunikation über unterschiedliche Medien und mittels verschiedener Protokolle
statt. Die Kommunikationsmedien und Protokolle müssen spezifiziert und standardisiert werden, um ein reibungloses Zusammenarbeiten zu gewährleisten.
Tabelle 2.1 zeigt eine Übersicht der einzelnen Kommunikationsvorgänge und ihrer Eigenschaften.
Kom. Partner
Medium
Beziehung
Protokoll
Benutzer - Trustcenter
pers. Kontakt
gleichberechtigt
natürlichsprachlicher
Dialog
Trustcenter - Chipkarte
galvanischer
Kontakt
Request - Response
T=1 und ISO 7816-4
Benutzer - mobiles Gerät
Display/Tastatur
gleichberechtigt
Mensch-Maschine
Kommunikation
mobiles Gerät - Chipkarte
galvanischer
Kontakt
Request - Response
T=1 und ISO 7816-4
PTD - PoA
Benutzer - PoA
drahtlos
Client - Server
erweitertes OBEX
pers. Kontakt
unidirektional
–
Tabelle 2.1: Kommunikationsbeziehungen der Systemkomponenten
2.6.2
Benutzer - Trustcenter
Benutzer
Trustcenter
natürlichsprachlicher Dialog
persönlicher Kontakt
Abbildung 2.14: Kommunikationsbeziehung zwischen Benutzer und Trustcenter
Die Kommunikation zwischen Benutzer und Trustcenter findet mit einem Mitarbeiter
des Trustcenters statt und ist damit eine Kommunikation zwischen zwei Menschen. Als
Kommunikationsprotokoll wird die natürliche menschliche Sprache verwendet. Zusätzlich zur sprachlichen Konversation ist die Vorlage von Gegenständen, wie z.B. eines
Lichtbildausweises und gegebenenfalls das Aushändigen der Chipkarte notwendig.
Ziele dieses Dialoges sind:
• Aufnahme der persönlichen Identifikationsdaten
• Überprüfung der Identität
2.6.3
73
Trustcenter - Chipkarte
Das Trustcenter muß sowohl Daten aus der Chipkarte des Benutzers auslesen, als auch
darauf ablegen.
Trustcenter
Chipkarte
Request
SmartCard
Response
Chipcard
Reader
galvanischer Kontakt
zwischen Karte und Reader
Abbildung 2.15: Kommunikationsbeziehung zwischen Trustcenter und Chipkarte
Zur Kommunikation mit der Karte besizt das Trustcenter ein Chipkarten-Lesegerät,
ein sogenanntes Chipkarten-Terminal. Ist die Karte in das Kartenterminal eingelegt,
besteht zwischen beiden ein direkter galvanischer Kontakt. Da es sich hier um eine
Kommunikation zwischen zwei Maschinen handelt, muß das Format und Ablauf der
Kommunikation genau spezifiziert werden, damit auch Geräte unterschiedlicher Hersteller nahtlos zusammenarbeiten.
Auf Link-Level wird dafür das T1 Protokoll eingesetzt (vergleiche Abschnitt 1.5.5).
Das Applikationsprotokoll verwendet die in ISO 7816-4 spezifizierten Mechanismen.
Es herrscht dabei eine strenge Master - Slave Beziehung, wobei die Chipkarte den
Slave darstellt. Das Terminal sendet Befehle und die Karte muß darauf antworten. Die
eingesetzten Befehle sowie deren genaues Format sind in den Abschnitten 2.7.1 und
2.8.1 beschrieben.
Der Zweck dieser Kommunikation ist:
• Die Schüsselablage (optional)
• Das Auslesen des (öffentlichen) Schüssels und der Karten ID
• Das Überprüfen des Besitzes des korrekten privaten Schlüssels
• Die Zertifikatsablage
2.6.4
Benutzer - mobiles Gerät
Bei dieser Kommunikationsbeziehung handelt es sich um einen Mensch-Maschine
Dialog. Als Kommunikationsmittel dienen ein Display und ein Eingabemedium. Die
Fähigkeiten dieser Bestandteile des mobilen Gerätes können sehr unterschiedlich sein.
Derzeit sind die Displays vieler mobiler Geräte noch verhältnissmäsig klein und in ihren
Darstellungsmöglichkeiten eingeschränkt. Die Eingabe findet meist über eine Tastatur,
74
KAPITEL 2. KONZEPT
Handschrifterkennung, Touchscreen oder einer Kombination daraus statt. Zukünftig ist
auch Spracherkennung als Eingabemöglichkeit denkbar.
Benutzer
mobiles Gerät
Dateneingabe - Auswahl
Informationsdarstellung
Display & Eingabemedium
Abbildung 2.16: Kommunikationsbeziehung zwischen Benutzer und mobilem Gerät
Die Realisierung dieser Schnittststelle hängt daher stark von dem verwendeten mobilen Gerät ab und ist an die gegebenen Bedingungen angepaßt. Sie muß jedoch die in
Abschnitt 2.7.2 definierte Funktionalität bieten. Die Darstellung soll, falls möglich, graphisch erfolgen. Von ihrer Qualität hängt entscheidend der Bedienkomfort des Systems
ab.
Diese Kommunikationsbeziehung ist die zentrale Schnittstelle zwischen dem Gesamtsystem und dem Benutzer.
Ihre Aufgaben sind:
• Die Darstellung relevanter Informationen
• Die Steuerung aller nicht automatisch ablaufender Vorgänge
2.6.5
Mobiles Gerät - Chipkarte
Diese Kommunikation verwendet dasselbe Kommunikationsmedium und dieselben Protokolle wie das in Abschnitt 2.6.3 beschriebe Modell. Das Chipkartenlesegerät ist Bestandteil des mobilen Geräts und die Chipkarte steht in direktem galvanischem Kontakt
zu ihm.
mobiles Gerät
Chipkarte
Request
SmartCard
Response
Chipcard
Reader
galvanischer Kontakt
zwischen Karte und Reader
Abbildung 2.17: Kommunikationsbeziehung zwischen mobilem Gerät und Chipkarte
Diese Kommunikationsverbindung wird zur Durchführung des Authentifikationsprozesses benötigt. Alle sicherheitsrelevanten Daten werden auf diesem Wege vom mobilen
75
Gerät zur Chipkarte und zurück übertragen. Das mobile Gerät steuert diese Konversation, sie nimmt also die Rolle des Masters ein.
2.6.6
PTD - PoA
Diese Kommunikation findet drahtlos statt und ist daher besonders anfällig für Angriffe
Dritter wie z.B. das Abhören und Verfälschen. Die eingesetzten Protokolle müssen derart konzipiert sein, daß sie dem Rechnung tragen und Mißbrauch ausschließen. Geheime
Informationen dürfen nur verschlüsselt übertragen werden.
PTD
PoA
Request
Response
drahtlose lokale
Client
Server
Abbildung 2.18: Kommunikationsbeziehung zwischen PTD und PoA
Um möglichst große Unabhängigkeit von der eingesetzten Übertragungstechnologie zu
erreichen, ist das verwendete Protokoll auf der Appliaktionsschicht angesiedelt. Es basiert auf den Spezifikationen des OBEX Protokolls (siehe Abschnitt 1.6) und erweitert
es, um die, für dieses System geforderte, Funktionalität zu erhalten.
Die Client - Server Beziehung des OBEX Protokolls wird beibehalten. Das mobile Gerät ist der Client dessen Befehle vom PoA-Server ausgeführt und beantwortet
werden.
Die Ziele dieser Kommunikation sind:
• Das Aufspüren in Reichweite befindlicher PoAs
• Die Durchführung der Authentifizierung
• Die Datenübertragung und Steuerung von Anwendungen des PoA
2.6.7
Benutzer - PoA
Diese Kommunikationsbeziehung beschreibt den Kontakt zwischen Benutzer und dem
Administrator eines PoAs.
Sie hat zum Ziel die Identität des Benutzers sicherzustellen und entscheidet, ob die
übertragenen Anmeldedaten in die Zugangsdatenbank des PoAs aufgenommen werden.
Dieser Nachweis erfolgt durch persönliche Anwesenheit des Benutzers und eventueller
Vorlage eines Lichtbildausweises.
76
KAPITEL 2. KONZEPT
Benutzer
PoA
persönliche Vorstellung
natürlichsprachliche Kommunikation
persönlicher Kontakt
Administrator
Abbildung 2.19: Kommunikationsbeziehung zwischen Benutzer und PoA
Diese Kommunikationsbeziehung hat zwei extreme Ausprägungen.
Zum einen kann der Benutzer und der Serveradministrator die selbe Person sein. Das ist
z.B. bei der Autorisierung des Zutritts zu seinem eigenen Haus der Fall. Hierbei findet
im eigentlichen Sinne keine Kommunikation statt, sondern der Benutzer authorisiert
seinen Zugang zum betreffenden PoA selbst.
Im anderen Fall wird durch die Verwendung von Zertifikaten, wie in Abschnitt 2.5.3
näher beschrieben, ein zusätzlicher Identitätsnachweis überflüssig. Damit kann diese
Kommunikation vollständig entfallen.
2.6.8
Zusammenwirken
Abbildung 2.20 zeigt das Zusammenwirken aller Systemkomponenten im zeitlichen Ablauf. Die Darstellung ist als beispielhaft zu verstehen. Sie deckt nicht alle im reellen
Einsatz auftretenden Zusammenhänge und Abläufe ab.
Aus Gründen der Übersichtlichkeit sind einige Vorgänge vereinfacht dargestellt. Beim
Vorgang der Zertifikatsausstellung ist die Verwendung eines Chipkartenterminals des
Trustcenters zur Kommunikation mit der Chipkarte angenommen. Wird hier ein PoAServer verwendet, erweitert sich der Vorgang um einen Authentifikationsprozeß, wie
er im unteren Drittel der Abbildung illustriert ist. Desweiteren sind die zu jeder Abfrage der Chipkarten notwendigen Request-Response Paare meist auf einen Pfeil in
Übertragungsrichtung zusammengefaßt. Die detailierten Einzelabläufe gehen aus den
Protokollspezifikationen hervor.
Die Abbildung zeigt die drei zentralen Systemabläufe:
• Zertifikatsausstellung
• Anmeldung beim PoA
• Authentifikationsvorgang
Daraus ist sowohl der Ablauf, die beteiligte Systemkomponenten und die Art der ausgetauschten Informationen ersichtlich.
Trustcenter
Benutzer
77
Chipkarte
mobiles Gerät
PoA
Kartenausgabe
persönliche Daten
Identitätsnachweis
Chip
Verwaltungs PIN
kart
en &
öffentliche und private Schlüssel
Zert
öffentlicher Schlüssel
ifika
tsau
sste
llun
Challenge-Response - priv. Key überprüfen
Zertifikat
Anwendung starten & PIN Eingabe
Anm
PIN Weiterg. & ID+ pub Key Req.
eldu
ng b
ID - pub. Key (& Cert)
eim
PoA
ID Daten, Schlüssel, (Cert.)
persönlicher Identitätsnachweis
Challenge-Response zum Test des Besitz von priv. key
Anwendung starten & PIN Eingabe
PIN & Abfrage der
Leistungsmerkmale
Leistungsmerkmale
Darstellung der gefundenen Peers in Auswahlliste
Peer Discovery
Wahl des PoA
ID Daten Request
Aut
hen
tifik
ID Daten
atio
ns V
org
Nonce
ang
verschlüsselte Nonce
(optional) Anfragen an
anwendungsspezifische
Chippkarten Applikationen
Benutzer Dialog
(anwendungsspezifisch)
CONNECT Request
(ID, Cert, vorh. App IDs)
RESPONSE (Nonce,
Session-Key, App ID)
CONNECT Request
(verschl.. Nonce, App ID)
RESPONSE (SUCESS)
anwendungsspezifische
verschlüsselte Kommunikation
Beendingung der Kommunikation
DISCONNECT Req + Resp.
Abbildung 2.20: Beispielhafter Kommunikationsablauf
g
78
KAPITEL 2. KONZEPT
2.7
Schnittstellen
2.7.1
Chipkarte - Kartenlesegerät Schnittstelle
Chipkarten im mAuth-System können, wie bereits erwähnt, mehrere Chipkarten Applikationen enthalten. Die für den Authentifikationsvorgang notwendige Applikation muß
jedoch in jedem Fall vorhanden sein. Diese default mAuth-Application muß folgende
Funktionen implementieren um für dieses System geeignet zu sein.
Name
GetID
GetCert
GetpubKey
GetCap
SetKey
SetCert
SetPIN
VrfPIN
EnCrypt
DeCrypt
Para1
Para2
Para3
AlgoType
AlgoType
–
AlgoType
AlgoType
PINType
PINType
AlgoType
AlgoType
–
–
–
keyType
–
–
–
keyType
keyType
–
–
–
Key
Cert
PIN
PIN
Data
Data
Antwort
ID
Zertifikat
public Key
Capabilities
OK/failed
OK/failed
OK/failed
OK/failed
OK/failed
OK/failed
Funktion
ID auslesen
Zertifikat auslesen
Public Key ausl.
Fähigkeiten ausg.
Schlüssel speichern
Zertifikat speichern
PIN Ändern
PIN überprüfen
Daten verschlüsseln
Daten entschlüsseln
Tabelle 2.2: Chipkarten-Funktionen - Übersicht
• GetID () → ID
Diese Funktion liefert die Karten-Seriennummer zurück. Sie muß weltweit eineindeutig sein, da sie als Merkmal zur Identifikation eines Nutzers verwendet wird.
• GetCert (AlgoType) → Cert
Da Zertifikate durch den, in ihnen enthaltenen öffentlichen Schlüssel, an ein Verschlüsselungsverfahren gebunden sind, sind für jeden unterstützten Kryptoalgorithmus eigene Zertifikate notwendig. Chipkarten können daher die Möglichkeit
bieten, mehrere Zertifikate zu speichern.
Die Auswahl des gewünschten Zertifikats geschieht durch Angabe des betreffenden Verschlüsselungsalgorithmus mittels dem Parameter AlgoType. Der Aufruf
dieser Funktion liefert als Response das gewünschte Zertifikat zurück.
• GetpubKey (AlgoType) → pubKey
Diese Funktion wird zur Neuanmeldung an PoAs und zur Zertifikatsausstellung
benötigt. Ihr Aufruf gibt den öffentlichen Schlüssel, der zu dem durch AlgoType
gewählten Algorithmus gehört, aus. Bezeichnet AlgoType einen symmetrischen
Algorithmus liefert diese Funktion den zugehöhrigen geheimen Schlüssel zurück.
2.7. SCHNITTSTELLEN
79
• GetCap () → Capabilities
Nich alle mAuth Chipkarten unterstützen den selben Funktionsumfang. In einer
internen Capability Datenbank“ sind die Fähigkeiten der Chipkarte abgelegt.
”
Neben den unterstützten Algorithmen ist dort auch vermerkt, zu welchen dieser
Algorithmen Schlüssel und Zertifikate vorhanden sind. Mit GetCap können diese
Eigenschaften abgefragt werden.
• SetKey (AlgoType, keyType, Key) → OK/failed
Durch diesen Aufruf kann ein Schlüssel auf der Karte abgelegt werden. Dieser
Vorgang findet nach der Schlüsselgenerierung statt. AlgoType spezifiziert den
Algorithmus, zu welchem der, mit Key übergebene Schlüssel, gehört. Der Parameter keyType bezeichnet die Art des Schlüssels. Bei asymmetrischen Verfahren
wird damit zwischen public und private Key unterschieden. Bei Erfolg wird ein
entsprechender Eintrag in der Capability Datenbank vorgenommen. Als Ergebnis
wird der Status der Funktionsausführung zurückgegeben.
• SetCert (AlgoType, Cert) → OK/failed
SetCert legt das zu Algorithmus AlgoType gehörige Zertifikat Cert auf der Chipkarte ab. Gleichzeitig vermerkt diese Funktion das Vorhandensein eines Zertifikats
in der Capability Datenbank der Karte.
• SetPIN (PINType, PIN) → OK/failed
SetPIN dient zum ändern der persönlichen PIN Nummer. Eine mAuth-Karte
besitzt mindestens zwei PIN Nummern. Der Parameter PINType kennzeichnet
welcher PIN der, mit dem Parameter PIN spezifizierte, neue Wert zugeordnet
werden soll. Als Ergebnis wird der Status der Aktion zurückgeliefert.
• VrfPIN (PINType,PIN) → OK/failed
Dies Funktion prüft, ob die, mit PIN übergebene Ziffernfolge, mit der auf der Karte gespeicherten und mittels Type spezifizierten, übereinstimmt. Bei erfolgreicher
Überprüfung ändert sich der innere Zustand der Karten-Anwendung (siehe Abschnitt 2.8.4).
• EnCrypt (AlgoType, keyType, Data) → crypted Data
EnCrypt verschlüsselt die in dem Parameter Data angegebenen Daten. AlgoType
wählt den dazu verwendeten Algorithmus aus und keyType gibt bei asymmetrischen Verfahren an, ob dies mit dem öffentlichen oder privaten Schlüssel geschehen soll. Der Parameter keyType wird bei symmetrischen Algorithmen ignoriert.
Die verschlüsselten Daten werden als Ergebnis zurückgegeben.
• Decrypt (AlgoType, keyType, Data) → decrypted Data
Diese Funktion ist das Gegenstück zu EnCrypt und entschlüsselt die übergebenen
Daten.
80
2.7.2
KAPITEL 2. KONZEPT
Mensch - Maschine Schnittstelle
Die Form der Realisierung dieser Schnittstelle hängt sehr stark von den Fähigkeiten des
mobilen Gerätes ab und wird je nach eingesetztem Gerätetyp unterschiedlich aussehen.
Es ist durchaus gewollt, daß die Darstellung an das jeweilige Look and Feel“ angepaßt
”
ist. Das erleichtert dem Benutzer die Eingewöhnungsphase an diese neue“ Anwendung.
”
Um die Grundfunktionalität der Anwendung sicherzustellen, muß diese Schnittstelle
jedoch ein bestimmtes Minimum an Informationen darstellen können und angemessene
Interaktionsmöglichkeiten für den Nutzer bieten. Abbildung 3.14 zeigt am Beispiel des
PoA-Auswahldialoges zwei mögliche, beispielhafte Realisierungen auf einem PDA
und einem Mobiltelefon.
Abbildung 2.21: Unterschiedliche Darstellung der Dialoge
Für die Implementierung einer mAuth-PTD-Anwendung sind die folgende Grunddialogsformen verbindlich vorgesehen.
Zusätzlich zu den dort definierten Eigenschaften, ist für alle Dialoge das Vorhandensein
einer Tastatur oder äquivalenten Eingabemediums gefordert. Die in den Dialogformen
definierten Bedienelemente können sowohl als GUI Elemente oder auch als physikalische
Tasten ausgeführt sein.
PIN-Dialog:
PINDialog (Type) −→ PIN
An verschiedenen Stadien der Anwendungsausführung ist die Eingabe einer PIN erforderlich. Mit diesem Dialog wird der Benutzer aufgefordert, seine PIN einzugeben. Da
2.7. SCHNITTSTELLEN
81
es mindestens zwei verschiedene PINs im mAuth-System gibt, muß zusätzlich angezeigt werden auf welche PIN sich der Dialog bezieht. Diese Information wird von der
Anwendung an den Dialog übergeben.
Wenn möglich, sollte die maximale Länge einer PIN durch entsprechende Markierungen
eines Eingabebereichs visualisiert werden. Für die Eingabe der einzelnen Ziffern soll
eine optische Rückmeldung in Form der Anzeige eines maskierten Zeichens, z.B. eines
*“ erfolgen.
”
• Übergabedaten:
– Art der PIN
• Anzeigeelemente:
– Aufforderung zur PIN-Eingabe
– Anzeige der PIN Art
– Darstellung eines Eingabefeldes
• Bedienelemente:
– OK-Knopf
– Korrektur-Knopf
• Ergebnisse:
– PIN
Mit dem Korrektur-Button werden alle bisher eingegebenen Ziffern gelöscht. Der
OK-Button bestätigt die Eingabe und beendet den Dialog.
PoA-Auswahldialog:
PoAChooser (Peer Discovery-Info-List) −→ gewählter PoA, Vorgangsart
Dieser Dialog greift auf dem vom Peer Discovery-Vorgang gesammelten Datenbestand
zurück und erzeugt daraus eine Auswahlliste, in der alle in Reichweite liegende PoAs
aufgeführt sind. In dieser Liste soll als minimale Information zu jedem PoA der im
PeerDisc-Paket enthaltene Description String (siehe Abschnitt 2.8.3.2) angezeigt
werden.
Sind zu einem PoA weitere Informationen aus dem Discovery-Vorgang bekannt, können
diese, den Anzeigemöglichkeiten des mobilen Gerätes angemessen, genutzt werden, um
einen ausagekräftigeren Eintrag für die Auswahlliste zu generieren. Es ist auch denkbar, mittels eines dafür vorgesehenen Buttons oder eines Menü-Eintrags, die Anzeige
genauerer Informationen zu ermöglichen.
Die Einträge der Liste müssen anwählbar sein und die aktuelle Auswahl soll visuell
hervorgehoben sein. Können nicht alle Einträge auf dem Display dargestellt werden,
muß die Liste scrollbar sein.
– Alle vom Peer Discovery-Prozeß gesammelten Daten
82
KAPITEL 2. KONZEPT
– Aufforderung zur Auswahl
– Auswahlliste mit Namen der in Reichweite liegender PoAs
– Optional Anzeige erweiterter Informationen über den gewählten PoA
• Bedienelemente:
– Listenauswahl
– Authentifikations-Knopf
– Anmelde-Knopf
– Beenden-Knopf
• Ergebnisse:
– Kommunikationspartner
– Art der gewünschten Aktion
Dies ist der zentrale Dialog der PTD-Anwendung. Er ist nach der Initialisierungsphase und der PIN Abfrage aktiv und dorthin kehrt die Anwendung nach Beendigung eines Authentifikation- oder Anmeldeprozesses auch wieder zurück. Daher ist
hier ein Bedienelement zum Beenden der Anwendung vorzusehen. Daneben existieren
ein Anmelde- und Authentifikations-Button, mittels welcher die gewünschte Aktion
zum aktuell gewählten PoA initiiert wird.
Abbildung 3.14 zeigt mögliche Realisierungen dieses Dialoges auf zwei unterschiedlichen
Gerätetypen.
Ergebnis/Fehler Dialog:
ResultDisplay (Status) −→ -
Das Ergebnis vieler Vorgänge des Systems sind für den Benutzer nicht direkt erfahrbar.
Daher sollen alle auftretenden Fehlerfälle und Ergebnisse von Vorgängen wie z.B. der
Erfolg einer PIN Änderung, der Status eines PoA-Anmeldevorgang usw. in Form eines
Ergebnis Dialoges dargestellt werden. Die Anzeige soll dabei, in sinnvollem Rahmen,
so ausführlich wie möglich geschehen.
– Ergebnis/Fehler
– Anzeige des Ergebnisses/Fehlers eines Vorgangs
• Bedienelemente:
– Bestätigungs-Knopf
• Ergebnisse:
– Keine
Mittels eines Bestätigungs-Buttons wird dieser Dialog beendet.
2.7. SCHNITTSTELLEN
83
PIN-Ändern Dialog:
ChangePIN (Type) −→ NewPIN
Zur Änderung einer PIN bedarf es aus Sicherheitsgründen eines im Vergleich zum
PIN-Dialog erweitertem User-Interfaces. Um zu gewährleisten, daß nur ein berechtigte
Benutzer die PIN ändern kann und nicht etwa jemand, der das Gerät in eingeschalteten,
bereits PIN-authentifiziertem Zustand gefunden oder gestohlen hat, muß hier zuerst
die alte“ PIN nochmals eingegeben werden.
”
Die neue Ziffernfolge muß, um Tippfehler auszuschließen, zweimal eingegeben werden.
Die Eingabe aller PINs erfolgt entweder ohne Anzeige oder wird durch maskierte Zeichen visualisiert.
– Art der PIN
– Anzeige des Vorgangstyps (PIN Änderung)
– Eingabeaufforderung: alte PIN
– Zweifache Eingabeaufforderung der neuen PIN
– Darstellung der Eingabefelder
• Bedienelemente:
– OK-Knopf
– Korrektur-Knopf
– Abbrechen-Knopf
• Ergebnisse:
– Neue PIN
Die Art der Darstellung ist ähnlich dem PIN-Dialog zusätzlich existiert hier noch ein
Abbrechen-Button, mit welchem der Vorgang ohne Änderung der PIN beendet werden
kann. Der OK-Button initiiert die Änderung.
Schlüsselgenerierungs Dialog (optional)
GenKey (supported Algo.) −→ keyType, keyLength, RandomData
Mobile Geräte, die über die Möglichkeit verfügen die kryptographischen Schlüssel selbst
zu generieren, sollen dazu als Benutzerschnittstelle diesen Dialog implementieren.
Die Schlüsselgenerierung ist eine optionale Funktion der Authentifikationsanwendung.
Wenn sie jedoch vorhanden ist, muß sie einen derartigen Dialog bereitstellen.
Der Name jedes Algorithmus, für den diese Funktion zur Verfügung steht, soll zusammen mit der maximalen Schlüssellänge in einer Auswahlliste aufgeführt sein. Aus einer
weiteren Liste sollen je nach gewählten Algorithmus alle unterstützten Schlüssellängen
wählbar sein.
84
KAPITEL 2. KONZEPT
– Unterstützte Algorithmen
– Jeweils unterstützte Schlüssellänge
– Auswahlliste: Algorithmus
– Auswahlliste: Schlüssellänge
• Bedienelemente:
– Listenauswahl
– Schlüssel generieren-Knopf
– Schlüssel speichern-Knopf
– Abbrechen-Knopf
– (Optional) Eingabefeld zur Erzeugung von Zufallswerten z.B. aus
Bewegungen des Eingabe Stifts über diesem Feld.
• Ergebnisse:
– Algorithmus
– Schlüssellänge
– Art der Aktion (Erzeugen/speichern)
– (Optional) Zufallswerte
Der Schlüssel generieren-Button setzt den Schlüsselerzeugung-Vorgang mit dem
gewählten Parametern in Gang. Nach erfolgreicher Durchführung kann der Schlüssel
mittels dem Schlüssel speichern-Button, auf der Chipkarte abgelegt werden. Diese beiden Bedienelemente können auch auf ein Einziges zusammengelegt werden. Die
Generierung der Schlüssel bedingt damit auch automatisch eine Ablage auf der Karte.
Zur Schlüsselerzeugung werden für viele Algorithmen Zufallswerte benötigt. Diese
können optional, falls die Resourcen des mobilen Gerätes dies erlauben, innerhalb
dieses Dialoges erzeugt werden. Die Koordinatenfolge eines über ein Eingabefeld oder
einen Touchscreen geführten Stifts oder sonstigem Eingabe-Zeigegeräts“ können die
”
nötigen Zufallswerte liefern. Weitere Möglichkeiten liegen im Ermessen des Geräteherstellers.
Anwendungs Dialog
Der Anwendungsdialog ist abhängig von der jeweiligen PoA-Authentifikationsapplikation. Als PoA-Authentifikationsapplikation werden in diesem Zusammenhang die
Abläufe bezeichnet, welche nach erfolgreicher Authentifikation beim PoA ablaufen.
Deren Ausführung ist zwar Aufgabe der mAuth-Client Anwendung (siehe Abschnitt
2.9), ihre Spezifikation ist jedoch nicht mehr Gegenstand dieser Arbeit.
2.8. SPEZIFIKATIONEN
2.7.3
85
PoA - PTD-Schnittstelle
Jeder PoA-Server muß folgende Befehle verstehen und entsprechend darauf antworten
können.
• PeerDisc
Damit werden einerseits Informationen über das PTD an den PoA versendet und
gleichzeitig der PoA aufgefordert seinerseits Informationen über sich zurückzusenden. Der minimale Inhalt dieses Kommandos ist eine 16 stellige Bezeichnung
des jeweiligen Gerätes in ASCII kodierung. Optional können noch viele weitergehende Informationen darin enthalten sein.
• Connect
Dieser Befehl dient dem Verbindungsaufbau. Alle verbindungsrelevanten Parameter werden damit ausgetauscht. Im Verbindungsaufbau findet auch die eigentliche
Authentifikation statt. Daher sind in diesem Befehl auch alle dazu notwendigen
Daten enthalten. Darüberhinaus werden damit auch der Session-Key für die Verschlüsselung der folgenden anwendungsspezifischen Kommunikation vereinbart.
• Abort
Mit Abort kann jede laufende Operation abgebrochen werden.
• Put
Put dient zum senden beliebiger binärer Objekte an den Server.
• Get
Mit diesem Befehl werden Objekte vom Server angefordert.
• Disconnect
Disconnect signalisiert den Wunsch die Verbindung zu beenden.
2.8
Spezifikationen
2.8.1
Chipkarten APDU Format
2.8.1.1
Allgemeines
Der Zugriff auf die Chipkartenfunktionen (vergleiche Abschnitt 2.7.1) erfolgt über ein
Chipkarten Lesegerät. Als Transport Protokoll wird das in ISO 7816-4 definierte T=1
Protokoll verwendet. Auf der Applikationsschicht (Layer 7 des OSI Modells) setzt das
mAuth System das APDU-Format ein, welches ebenfalls in ISO 7816-4 spezifiziert ist.
Ein Funktionsaufruf erfolgt durch Aussenden einer Befehls APDU, auf welche die Karte
86
KAPITEL 2. KONZEPT
unmittelbar durch ein Antwort Datenpaket reagieren muß (vergleiche hierzu Abschnitt
1.5.5).
Eine solche APDU besteht aus einem Befehlscode, der die gewünschte Funktion spezifiziert, sowie den zugehörigen Parametern und Übergabedaten.
Das Ergebnis der Funktion wird in Form eines Antwortpakets zurückgeliefert. Bei den
meisten Befehlen werden Daten sowohl von, als auch zu der Karte übertragen. Dazu wird das APDU Format im CASE 4 eingesetzt. Eine CASE 4 APDU ist wie folgt
aufgebaut:
Aufbau einer CASE 4 Befehls APDU:
ClassByte
(1 Byte)
Instruction
(1 Byte)
Par1
Par2
Lc
Data
(1 Byte) (1 Byte) (1 Byte) (n Byte)
Le
(1 Byte)
Tabelle 2.3: Befehls APDU Format
Befehle, die nur Daten zurückliefern, benutzen APDUs im Format CASE 2. Hierbei
fehlen die Felder Lc und Data.
Das Class Byte ist bei Chipkarten dieses mAuth Systems immer auf den Wert 0x80
gesetzt. Dieser Wert ist in der ISO Chipkarten Norm für private Nutzung reserviert und
signalisiert somit, daß es sich hierbei um keine Standard-ISO-Chipkarten-Anwendung
handelt.
Das Feld Instruction kennzeichnet mittels eines 1 Byte großen Befehlscodes die Art
des Befehls. Die Zuordnung dieser Codes zu den Funktionen ist in Abschnitt 2.7.1 zu
finden.
Die Feldern Par1 und Par2 bieten Platz für 2 jeweils 1 Byte große Befehlsparameter.
Benötigt eine Funktion darüberhinaus weitere Übergabedaten oder passen diese aufgrund ihrer Länge nicht in ein Parameterfeld, werden sie im Datenfeld Data übergeben.
Die Länge dieses Datenblocks in Byte wird in dem 1 Byte großen Feld Lc angegeben.
Das begrenzt die Länge der in einer APDU transportierbaren Datenmenge auf 255
Byte und 2 Parameter-Bytes.
Mit Le wird die Länge der erwarteten Antwortdaten angegeben. Im mAuth System soll
dieser Wert immer auf 0x00 gesetzt sein, was jede beliebige Antwortlänge bis zu 255
Byte zuläßt.
Benötigen Funktionen Übergabedaten mit mehr als 255 Byte Länge, müssen diese in
einer Folge mehrerer Requests übertragen werden. Die eigentliche Funktion wird erst
nach Empfang des, besonders gekennzeichneten, letzten Datenblocks auf der Chipkarte
ausgeführt.
Falls Rückgabewerte länger als 255 Bytes sind, werden auch sie in mehreren Schritten
transportiert. Da die Karte von sich aus aber keine Paketübertragung initieren darf,
87
muß jedes Paket durch einen Request vom Terminal angefordert werden. Erkennt das
Terminal, daß sich eine Antwort über mehrere Pakete erstreckt, sendet es entsprechende
Requests an die Karte bis das letzte Paket empfangen worden ist.
2.8.1.2
Command codes
Name
GetID
GetCert
GetpubKey
GetCap
SetKey
SetCert
SetPIN
VrfPIN
EnCrypt
DeCrypt
reserved
APDU Kommandos
Command Par 1
Par 2
0x10
0x11
AlgoType
BlockNr
0x12
AlgoType
BlockNr
0x13
–
–
0x20
AlgoType
BlockNr
& KeyType
0x21
AlgoType
BlockNr
0x22
PINType
–
0x30
PINType
–
0x40
AlgoType
BlockNr
& keyType
0x41
AlgoType
BlockNr
& keyType
0x50-0xFF
Daten
–
–
–
Key
Response
ID
Zertifikat
public Key
Capiabilities
OK/failed
Cert
PIN
PIN
Data
OK/failed
OK/failed
OK/failed
OK/failed
Data
OK/failed
Tabelle 2.4: Chipkarten CommandCodes
Tabelle 2.4 zeigt die Zuordnung von APDU Command-Codes zu den in Tabelle 2.2
aufgeführten Chipkarten Funktionen.
2.8.1.3
Parameter
Tabelle 2.4 zeigt bereits die Zuordnung der Parameter der Chipkartenfunktionen auf
die Parameter Felder und das Datenfeld einer APDU. Ihre jeweilige Bedeutung und
ihre Kodierung wird im folgenden Abschnitt erklärt.
BlockNr:
Blockfolge Nummern sind notwendig, da nicht alle Requests und Responses aufgrund
ihrer Größe in einer einzelnen APDU transportiert werden können. Mit Hilfe dieser
Nummern sind die, zu einer Operation zusammengehöhrenden APDUs erkennbar. Da
je APDU knapp unter 256 Byte Daten transportiert werden können, sollte eine maximale Folge von 256 APDUs ausreichend sein, um auch die Datenübertragung zu
zukünftigen Chipkartengenerationen mit höheren Speicherkapazitäten problemlos abwickeln zu können.
88
KAPITEL 2. KONZEPT
Das letzte Paket einer Übertragungsfolge ist daher immer mit der BlockNr 0xFF gekennzeichnet. Das Vorhandensein einer BlockNr ungleich 0xFF bedeutet immer das
Folgen weiterer Daten. Die Blockfolgenummer wird dabei beginnende bei 0x00 mit
jedem weiteren Paket erhöht.
Ein Befehl wird von der Karte erst nach Empfang einer APDU, mit der Markierung als
letzter Datanblocks, ausgeführt. Trifft ein Request mit der falschen Folgenummer ein,
wird dieser mit einer Fehler-Response beantwortet und die Übertragung muß wieder
mit dem ersten Datenblock beginnen.
Der Empfang einer Response mit einer BlockNr ungleich 0xFF veranlaßt das Terminal
weitere Request an die Karte zu senden, um die restlichen Datenblöcke abzufragen.
Dieser Request besitzt denselben Befehlscode wie der ursprüngliche Befehl, nur enthält
er außer der korrekten Blockfolge Nummer keine weiteren Parameter oder Daten.
Die BlockNr des neuen Requests wird im Vergleich zur Nummer des letzten empfangenen Requests jeweils um eins inkrementiert. Eine falsche Reihenfolge der BlockFolgenummer bedeutet auch hier einen Fehler und der folgende Request enthält die
BlockNr 0x00 zusammen mit allen Parametern und Daten. Das veranlasst die Karte
dazu, die Übertragung erneut zu beginnen.
Da beim Absenden des ersten Requests die Länge der Antwort noch nicht zwangsläufig
feststeht, macht die Verwendung einer Folgenummer hier noch keinen Sinn. Sie wird
daher auf 0xFF gesetzt. Damit kann, falls notwendig, ein neuer Befehl von der Anforderung weiterer Daten eines vorangegangenen Befehls unterschieden werden.
AlgoType:
AlgoType bezeichnet verschiedene Krypotoalgorithmen.
AlgoType
Code
Algorithmus
0x01
DES
0x02
3DES
0x03
IDEA
0x04
Blowfish
0x10
RSA
0x11
ElGammal
0x12
Elliptische Kurven
0x40-0xFF not used
Tabelle 2.5: Kryptographische Algorithmen des mAuth Systems
Für die symmetrischen Algorithmen sind die Werte 0x00 bis 0x0F vorgesehen, für asymmetrische Verfahren die Werte darüber bis 0x3F. Die höchstwertigen 2 Bit dürfen nicht
verwendet werden, da hierin bei Bedarf zusätzliche Informationen kodiert werden. Der
Werteraum bietet genügend Platz für zukünftige Erweiterungen. Sollen neue Algorithmen in das mAuth System aufgenommen werden, muß die Zuordnung des AlgoType
89
Codes für das gesamte System einheitlich erfolgen und in die Systemspezifikation aufgenommen werden.
KeyType
KeyType spezifiziert die Art eines Schlüssels. Bei asymmetrischen Verfahren wird damit zwischen öffentlichen und privaten Schlüssel unterschieden. Für symmetrische
Schlüssel ist zwar ein Wert definiert, jedoch ist hier dieser Parameter eigentlich nicht
notwendig und auf seine Auswertung kann deshalb bei Implementierungen verzichtet
werden.
KeyType
Code Schlüsseltyp
0x40 public
0x80 private
0xC0 symmetrisch
Tabelle 2.6: Schlüsseltypen
KeyType wird immer zusammen mit AlgoType verwendet und ist in dessen höchstwertigen 2 Bit kodiert. Die Werte in Tabelle 2.6 sind so gewählt, daß sie einfach auf dem
Code des entsprechenden Algorithmus aufaddiert werden können.
PinType:
Derzeit werden nur zwei verschiedene Arten von PINs im mAuth System verwendet.
Ihr Typ wird mit diesem Parameter angegeben und wie in Tabelle 2.7 spezifiziert
codiert. Die Kartenzugriffs-PIN ist die Standard PIN Nummer des Systems. Sie
muß beim Start der Anwendung eingegeben werden, um den Zugriff auf die Chipkarte
zu ermöglichen.
PINType
Code
PIN Art
0x00
Kartenzugriff
0x01
Karten-Verwaltungsfkt.
0x02-0xFF reserved
Tabelle 2.7: PIN Typen
Die zweite PIN wird benötigt, um Zugang zu den Verwaltungsfunktionen der Chipkarte
zu erhalten. Damit können neue Schlüssel und Zertifikate abgespeichert und Schlüssel
zur Anmeldung an neue PoAs oder zur Zertifikatsaustellung ausgelesen werden.
90
KAPITEL 2. KONZEPT
2.8.1.4
Daten
Das Datenfeld kann zur Übergabe beliebiger binärer Daten genutzt werden. Das Darstellungsformat dieser Datenstruktur muß jedoch beiden Kommunikationspartnern bekannt sein, um deren Inhalt richtig interpretieren zu können. Dieses Datenformat kann
je nach betreffender Funktion unterschiedlich sein. Der Befehls-Code der APDU legt
somit das Datenformat fest und die Chipkarte kann die empfangenen Informationen
entsprechend verarbeiten.
Im folgenden ist der Aufbau der verschiedenen Datenstrukturen spezifiziert.
Key
Die Struktur vom Typ Key kann beliebige kryptographische Schlüssel representieren. Bei asymmetrischen Algorithmen wie dem RSA Verfahren besteht der öffentliche Schlüssel aus 2 Komponenten, dem Exponenten und dem Modulus. Eine einfache
Länge-Daten-Kodierung ist zur Schlüsseldarstellung also nicht ausreichend.
Die Key-Struktur ist daher wie folgt aufgebaut:
AlgoType
& keyType
(1 Byte)
KeyComponent
Triplet1
(n Byte)
KeyComponent
Triplet1
(n Byte)
KeyComponent
Triplet1
(n Byte)
Tabelle 2.8: Key Format
AlgoType und KeyType spezifizieren mit den in den Tabellen 2.5 und 2.6 definierten Kodierungen den Algorithmus zu dem dieser Schlüssel gehört sowie seine Art.
Der eigentliche Schlüssel wird aus einer Folge von mindestes einem KeyComponentTriplet dargestellt.
Tag
Length
Data
(1 Byte) (2 Byte) (n Byte)
Tabelle 2.9: KeyComponent-Triplet
Diese Triplets sind wie die in der OBEX Spezifikation (vergleiche Abschnitt 1.6) definierten Tag-Lenght-Value-Triplets aufgebaut.
Der Tag spezifiziert die Art dieser Schlüsselkomponente. Bisher sind dafür folgende
Codes definiert:
91
KeyComponent Tag
Wert
Bedeutung
0x00
single key
0x01
exponent
0x02
modulus
0x03-0xFF reserved
Tabelle 2.10: KeyComponent-Triplet Tags
Das Feld Length gibt die Länge, in Bytes, der im Data-Feld folgenden Schlüsselkomponente an. Da besonders bei asymmetrischen Algorithmen durchaus sehr lange
Schlüssel verwendet werden, ist das Length-Feld 2 Byte groß. Das höherwertige Byte
wird dabei zuerst übertragen.
Cert
Mit Cert wird ein Zertifikat bezeichnet. Es wird in der in Abschnitt 2.8.2 definierten
Struktur direkt in das Datnbfeld einer APDU eingebettet.
PIN
Eine PIN wird ziffernweise codiert. Jede Ziffer einer PIN wird in einem Byte in ASCII
Kodierung dargestellt.
DATA
Die Struktur Data bezeichnet einen Datenblock, welcher der Chipkarte zum Ent- oder
Verschlüsseln übergeben wird. Er beinhaltet die betreffenden Daten in ihrer binären
Form, ohne sie umzukodieren.
2.8.1.5
Responses
Die Ergebnisse auf Befehls-APDUs werden in Form von Response APDUs zurück an
das Chipkarten Terminal übertragen. Die Rückgabewerte sind im Feld Data dieses
Pakets untergebracht. Die letzten beiden Bytes eines Antwortpakets SW1 und SW2
enthalten das sogenannte Status Word“. Daraus ist der Status einer Befehlsausführung
”
zu entnehmen. Die minimale Antwort auf einen Befehl besteht aus diesen beiden Status
Bytes.
Response APDU:
BlockNr
(1 Byte)
Data
(n Byte)
SW1
SW2
(1 Byte) (1 Byte)
Tabelle 2.11: Antwort APDU
Auch hier muß, wie bei den Datenstrukturen der Befehls APDUs, der Aufbau des Antwort Datenblocks spezifiziert sein. Da Antworten unmittelbar auf jeden Befehl folgen
92
KAPITEL 2. KONZEPT
müssen, bevor der nächste Befehl ausgesandt werden darf, ist durch den vorangegangenen Befehl der Typ der Rückgabe Daten bekannt.
ID
Darin ist die Kartenseriennummer in der Form, wie sie auch auf der Karte gespeichert
ist, binär enthalten.
Zertifikat
Diese Struktur enthält ein Zertifikat in dem Format wie es in Abschnitt 2.8.2 definiert
ist.
Schlüssel
Die Darstellungsform dieses Rückgabewertes ist identisch zur Darstellung des Keys
aus Abschnitt 2.8.1.4 (Tabellen 2.8, 2.9 und 2.10).
Capabilities
Capabilities geben Auskunft über den Funktionsumfang einer Chipkarte. Sie spezifizieren die unterstützten kryptographischen Algorithmen. Weiterhin ist ihnen zu entnehmen, zu welchen Algorithmus Schlüssel oder Zertifikate auf der Karte abgelegt sind.
Diese Information ist für jedes Verfahren in einem CapTriplet codiert. In der Antwort
ist für jeden unterstützten Algorithmus ein solches Triplet enthalten. Um die Antwort
leichter parsen zu können, gibt das erste Byte die Gesamtlänge der folgenden Triplets
an.
Length CapTriplet 1
(1 Byte)
(n Byte)
CapTriplet 2
(n Byte)
CapTriplet n
(n Byte)
Tabelle 2.12: Capability Response Format
Ein CapTriplet hat folgenden Aufbau:
AlgoType
(1 Byte)
PrKey PrCert
(1 Byte) (1 Byte)
Tabelle 2.13: CapTriplet Format
AlgoType spezifiziert den Verschlüsselungsalgorithmus mit der in Tabelle 2.5 vereinbarten Kodierung.
93
Die Tags PrKey und PrCert zeigen an, ob Schlüssel oder Zertifikate dazu vorhanden sind bzw. deren Speicherung auf der Chipkarte überhaupt unterstützt wird. Die
Bedeutung ihrer Kodierung zeigt Tabelle 2.14.
PrKey und PrCert
Wert Bedeutung
0x00 nicht gesetzt
0x01 vorhanden
0xFF nicht unterstützt
Tabelle 2.14: Bedeutung der Felder prKey und prCert
OK/failed
Viele Chipkarten Kommandos bewirken nur einen internen Vorgang auf der Karte und
liefern keine Rückgabedaten zurück. Für die aufrufende Applikation ist jedoch der
Erfolg der Befehlsausführung interessant.
Die ohnehin immer in einer Response vorhandenen Status Bytes reichen zu diesem
Zweck völlig aus. Es wird die in ISO 7816 spezifizierte Statusword Kodierung verwendet. Einzig die Statusbyte Kombination 0x90 0x00 kennzeichnet eine erfolgreiche
Befehlsausführung, jeder andere Wert bedeutet einen Fehler!
2.8.2
Zertifikatsformat
2.8.2.1
Inhalt
Die im mAuth System verwendeten Zertifikate beinhalten im wesentlichen die Komponenten, die bereits in Abschnitt 1.4.6 beschrieben worden sind. Das sind:
• User ID
• Trustcenter ID
• Seriennummer
• Ablaufdatum
• Öffentlicher Schlüssel
• Signatur des Trustcenters
Die Kombination aus User ID und Trustcenter ID muß dabei weltweit eindeutig sein und kann von PoAs anstelle der Kartenseriennummer als BenutzerIdentifikationsmerkmal verwendet werden. Diese Kombination ist aussagekräftiger als
eine Kartenseriennummer und sollte, sofern vorhanden, bevorzugt werden. Ein weiterer
94
KAPITEL 2. KONZEPT
Vorteil ist, daß sie personen- und nicht kartengebunden ist, d.h. dieses Identifikationsmerkmal kann bei Verlust einer Karte auf die neuen Karte übernommen werden. Eine
Neuanmeldung an den PoAs ist damit nicht notwendig.
Die Seriennummer steht in keinem Zusammenhang mit der Kartenseriennummer.
Sie kann bei Rückruf von Zertifikaten und Neuaustellung als Unterscheidungsmerkmal
dienen.
Zertifikate sind aus Sicherheitsgründen immer nur für einen begrenzten Zeitraum gültig.
Das Ablaufdatum gibt die maximale Gültigkeit des Zertifikats an.
Aufgabe eines Zertifikats ist die Bindung eines öffentlichen Schlüssels an eine Person.
Der öffentliche Schlüssel des Benutzers, muß daher auch im Zertifikat enthalten sein.
Die Korrektheit und Integrität der Daten eines Zertifikats bestätigt das Trustcenter
durch die digitale Signatur dieser genannten Bestandteile. Diese Signatur wir ans
Ende des Zertifikats angefügt.
2.8.2.2
Format
Um den beschränkten Resourcen mobiler Geräte Rechnung zu tragen, wurde zur Darstellung des Zertifikats eine binäre Form gewählt. Dadurch ist eine effiziente Speicherung und Übertragung von Zertifikaten sichergestellt. Zudem kann der Zertifkat mit
ähnlichen Parsern aufgeschlüsselt werden, wie sie auch für die übrigen definierten Datenstrukturen verwendet werden.
Die Zertifikatsbestandteile werden wie in Tabelle 2.15 illustriert zu einem Bytestrom
verkettet.
User
ID
(n Byte)
Trustcenter
ID
(n Byte)
Seriennummer
(1 Byte)
Ablaufpublic
datum
key
(8 Byte) (n Bytes)
Signatur
(n Bytes)
Tabelle 2.15: Zertifikatsformat Format
User ID:
Eine User ID besteht aus Name, Vorname, Geburtsdatum und Geburtsort eines
Benutzers. Diese Bestandteile zusammen müssen innerhalb der, von einem Trustcenter
vergebenen Zertifikate, einmalig sein. Sollten zwei Nutzer in allen gebannten Punkten
übereinstimmen, muß z.B. durch Anfügen einer laufenden Nummer an den Vornamen,
wieder Eindeutigkeit hergestellt werden.
Länge
Name
(1 Byte) (n Byte)
Länge Vorname
(1 Byte) (n Byte)
Geb. Datum
(8 Byte)
Tabelle 2.16: Aufbau der User ID
Länge Geb. Ort
(1 Byte) (n Byte)
95
Das Geburtsdatum wird in der Form YYYYMMDD, d.h. einer vierstellige Jahreszahl,
gefolgt von einer jeweils zweistelligen Monats- und Tageszahl, angegeben. Jede Ziffer
wird in ASCII Kodierung dargestellt. Das vollständige Datumsformat benötigt somit
8 Byte.
Die übrigen Bestandteile haben variable Länge. Daher wird jedem ein Byte, das dessen Länge angibt, vorangestellt. Auch die Darstellung dieser Komponenten erfolgt in
ASCII-Code. Auf eine Kodierung in Unicode wurde zu Gunsten des geringeren Speicherbedarfs verzichtet.
Trustcenter ID:
Eine Trustcenter ID setzt sich aus einer 2 Byte langen Kennung des Landes, in welchem das Trustcenter seinen Sitz hat und einer 4 Byte langen ID-Nummer zusammen.
Die Länderkennung ist in ASCII-Code kodiert und verwendet die zweibuchstabigen
ISO-Länderbezeichnungen, wie sie auch aus dem Internet DNS System zur Länderbezeichnung bekannt sind.
Die ID-Nummer sollte, wie bereits in Abschnitt 2.4.1 für die Kartenseriennummern
vorgeschlagen, von einer weltweit anerkannten Organisation, wie z.B. der ISO zentral
vergeben werden.
ISO Länderkennung
(2 Byte)
ID
(4 Byte)
Tabelle 2.17: Aufbau der Trustcenter ID
Seriennummer:
Die Repräsentation der Zertifikatsseriennummer erfolgt binär mittels eines Bytes.
Ablaufdatum
Das Ablaufdatum ist wie das Geburtsdatum als 8 Ziffern in ASCII-Darstellung in der
Form YYYYMMDD aufgebaut.
public Key:
Zur Darstellung des öffentlichen Schlüssels wird dasselbe Format verwendet, wie es
bereits in Abschnitt 2.8.1.4 spezifiziert worden ist. Ein 2 Byte großes Feld gibt vorangestellt die Gesamtlänge des Schlüssels an.
Length Schlüsselformat wie in 2.8.1.5
(2 Byte)
(n Byte)
Tabelle 2.18: public Key Format
96
KAPITEL 2. KONZEPT
Signatur:
Um eine Signatur verarbeiten zu können, ist es notwendig, den zur Erstellung verwendeten Hash- und Verschlüsselungsalgorithmus, zu kennen. Diese beiden Daten sind in
den ersten beiden Byte des Signaturformats enthalten.
Daran anschließend folgt das eigentliche Zertifikat als binärer Datenblock. Seine Länge
wird mittels zwei, den Signaturdaten vorangestellten Byte, spezifiziert.
AlgoType
(1 Byte)
HashType
(1 Byte)
Length
Data
(2 Byte) (n Byte)
Tabelle 2.19: Signatur Format
Die Kodierung des verwendeten Krypto-Algorithmus wird mittles AlgoType“ gemäß
”
Tabelle 2.5 angegeben.
Für die zur Hash-Bildung benutzten Verfahren werden folgende Kodierungen vereinbart.
HashType
Code
Algorithmus
0x01
MD2
0x02
MD5
0x03
SHA1
0x04-0xFF reserved
Tabelle 2.20: Hash Algorithmen
2.8.2.3
Beispiel
Der Aufbau eines Beispiel Zertifikats sieht gemäß dieser Regeln und Darstellungsvereinbarungen folgendermaßen aus:
Benutzer:
Geburtsdatum:
Geburtsort:
Sitz des ausstellenden Trustcenters:
Trustcenter ID:
Zertifikatsseriennummer:
Ablaufdatum:
Öffentlicher Schlüssel:
Signatur-Verschlüsselung:
Signatur Hash-Algorithmus:
Albert Deindl
12. Februar 1974
Mainburg
Deutschland
0xAB 0xCD 0xEF 0x12
1
31. Dezember 2005
RSA Key
RSA
MD5
97
Zertifikat:
-----------------------------------------------------> 06 41 6C 62 65 72 74 06 44 65 69 6E 64 6C 31 39
LL A l b e r t LL D e i n d l 1 9
-->
37 34 30 32 31 32 08 4D 61 69 6E 62 75 62 67 44
7 4 0 2 1 2 LL M a i n b u r g D
-->
45 AB CD EF 12 01 32 30 30 35 31 32 33 31 08 20
E |---ID----| SS 2 0 0 5 1 2 3 1 LL LL
-->
31 00 01 08 00 < 2048 Bit
AT KT MO LL LL
-->
02 00 18 < 24 Bit
EX LL LL
public Key modulus >
Exponent > 01 02 08 00
AT HT LL LL
--> <2048 Bit Signatur>
----------------------------------------------------
Zur besseren Lesbarkeit sind hier unter den eigentlichen Daten Orientierungszeichen
angegeben. Das eigentliche Zertifikat besteht nur aus den Bytes der mit --> gekennzeichneten Zeilen!
Kennzeichnet eine Längenangabe
Seriennummer
AlgoType
KeyType
Modulus
Exponent
HashType
ASCII Zeichen sind unter dem jeweiligen Bytewert angegeben
<..> Schlüssel oder Signaturen sind aufgrund ihrer großen Länge
nur symbolisch dargestellt angegeben
LL
SS
AT
KT
MO
EX
HT
2.8.3
Erweitertes OBEX Protokoll - mAuth OBEX
2.8.3.1
Allgemeines
Zur Kommunikation zwischen PTD und POA wird ein an OBEX (vergleiche Abschnitt
1.6) angelehntes Protokoll verwendet. OBEX hat sich auf den meisten mobilen Geräten,
unabhängig von deren lokalen Übertragungstechnologien, als Protokoll zum spontanen
Datenaustausch durchgesetzt. Die dort verwendeten OBEX Parser können mit relativ geringen Modifikationen auch für das mAuth Kommunikationsprotokoll verwendet
98
KAPITEL 2. KONZEPT
werden.
Das PTD ist in dieser Kommunikationsbeziehung der Client und der PoA der Server.
OBEX bildet zwar die Grundlage dieses Protokollentwurfs, es ist aber nicht das Ziel des
mAuth Systems auch die OBEX Services anzubieten. Der OBEX Server des PoA darf
und soll sich deshalb auch nicht als default OBEX Server bei der TransportprotokollSchicht registrieren.
MAuth OBEX wird somit bereits beim Verbindungsaufbau auf Transportschicht-Ebene
mit einem anderen Dienstbezeichner angesprochen. Dadurch ist es sehr unwahrscheinlich, daß beim Peer Discovery-Vorgang auch andere OBEX Geräte als solche, die dem
mAuth Standard entsprechen, antworten werden. Spätestens an der Art der Antwort ist
eine geeigente Gegenstelle eindeutig von anderen OBEX Geräten“ zu unterscheiden.
”
Je nach Art des darunter liegenden Transportmediums wird dieser Transportschicht
Dienst-Bezeichner anders realisiert werden. Bei TCP/IP als Transportprotokoll entspräche dies der Zuweisung einer anderen Port-Nummer als der des default OBEX
Services 650.
Für IrDA als Übertragungsmedium ist für das mAuth System ein IAS Eintrag in folgender Form vorgesehen:
Class OBEX:mAuth { IntergerIrDA:TinyTP:LsapSel }
Das IrDA LMP OBEX Hint-Bit soll beim Server jedoch gesetzt werden.
Es erscheint wenig sinnvoll für PoA-Server auch default OBEX Server Dienste anzubieten. Sollte dies für eine spezielle Anwendung benötigt werden, spricht jedoch nichts dagegen. Aufgrund der unterschiedlichen Bezeichner auf Transportschicht-Ebene können
mAuth und default OBEX Server jederzeit nebeneinander existieren.
Der Client wird mit großer Wahrscheinlichkeit auch die default OBEX Server Dienste
unterstützen.
Für die Implementierung der mAuth-Client Anwendung auf dem PTD muß eine evtl.
bereits vorhandene Standard OBEX Library erweitert werden. Ihre Grundmechanismen
wie Befehls und Header Parser können jedoch mit großer Wahrscheinlichkeit weiterverwendet werden.
Die Erweiterungen des OBEX Protokolls zu mAuth-OBEX bestehen aus einem
zusätzlichem Befehl und mehreren neuen Header-Typen.
Desweiteren ist die Unterstützung einer minimalen Paketlänge von 1 KByte gefordert. Das ist notwendig, da gemäß der OBEX Spezifikationen ein Connect-Request
sich nicht über mehrere Pakete erstrecken darf. Der Authentifikationsvorgang findet
jedoch in der Verbindungsaufbauphase statt und die dazu notwendigen Informationen
werden innerhalb der Connect Pakete ausgetauscht.
99
Ein Connect-Request Paket muß also genügend Platz für mindestens ein vollständiges
Zertifikat bieten. Eine Response muß die Authentification-Challenge und den SessionKey aufnehmen können. Dies sind die umfangreichsten Daten in der Connect Phase,
darüberhinaus sind noch weitere Informationen unterzubringen.
Bei der Annahme eines Zertifikats als größte der hier genannten Strukturen, mit einer
Schlüssel und Signaturlänge von jeweils 2048 Bit, ergibt sich allein daraus zusammen
mit den weiteren Daten eines Zertifikats ein Platzbedarf von etwas über 512 Byte. Die
übrigen Daten eines Connects sind im Vergleich dazu eher gering, so daß eine minimale
Paketgröße von 1 KByte ausreichend ist.
Durch die Möglichkeit der Übertragung mehrerer ID Informationen in einem Paket
läßt sich der Verbindungsaufbau vereinfachen und beschleunigen. Die Unterstützung
größerer Paketlängen ist daher empfehlenswert. Geeigneter Wert liegen zwischen 2 bis
4 KByte
2.8.3.2
Befehle
Das mAuth-OBEX verwendet die in Tabelle 2.21 aufgelisteten Befehle.
OpCode
0x90
0x80
0x81
0xFF
0x02 (0x82)
0x03 (0x83)
mAuth OBEX Befehle
Name
Beschreibung
PEERDISC
Informationsabfrage empfangsbereiter Peers
CONNECT
Verb. Aufbau, Parameter Verh., Authentifikation
DISCONNECT Signal zum Verbindungsabbau
ABORT
Abbruch der laufenden Operation
PUT
Objekt senden
GET
Objekt anfordern
Tabelle 2.21: mAuth OBEX Befehle
PEERDISC
PEERDISC-Pakete werden während der Peer Discovery-Phase (vergleiche 2.5.4) ausgesendet. Das Ziel des Peer Discoverys ist das schnelle Auffinden und das Sammeln
rudimentärer Informationen über in Reichweite liegender PoA-Server.
Diese Pakete können auch ohne vorangehenden Verbindungsaufbau verarbeitet werden.
PEERDISC-REQUEST werden in jedem Zustand des Servers angenommen und
beantwortet; selbst dann, wenn schon eine Verbindung zu einem anderen Client besteht.
0x90
Paket Description
Länge
String
(1 Byte) (2 Byte)
(16 Byte)
max. mAuth-OBEX
Paketlänge
(2 Byte)
Tabelle 2.22: mAuth-OBEX PeerDisc Request
opt.
Header
(n Byte)
100
KAPITEL 2. KONZEPT
Tabelle 2.22 zeigt das Format eines solchen Request Pakets.
Der Description String ist ein 16 stelliger ASCII String, der eine möglichst aussagekräftige Bezeichnung des mAuth Clients enthält. Der PoA-Server kann diese Information z.B. für seine Log-Dateien oder zur Anzeige auf einem Status Display nutzen.
Bereits in dieser Phase wird die maximale mAuth-OBEX Paketlänge ausgetauscht, damit bereits bei einem Verbindungsaufbau die Pakete korrekt formatiert
werden können.
Der Description String liefert nur sehr begrenzte Informationen über den jeweiligen
Kommunikationspartner. Mittels optionaler Header können daher weitergehende Informationen übermittelt werden. Die Verarbeitung dieser Header ist jedoch nicht verpflichtend.
Die PEERDISC-RESPONSE ist analog zum Request aufgebaut.
response
code
(1 Byte)
Paket Description
Länge
String
(2 Byte)
(16 Byte)
max. mAuth-OBEX
Paketlänge
(2 Byte)
opt.
Header
(n Byte)
Tabelle 2.23: mAuth-OBEX PeerDisc Response
Der Description String enthält eine Kurz-Bezeichnung des PoA-Servers. Der PTD
kann diese Information im PoA-Auswahldialog anzeigen.
Mittels dem Peer Description-Headers können auch weitere Informationen über den
PoA zurückgesendet werden. Je nach Fähigkeiten des PTD-Anwendung können diese mit in die Auswahlliste aufgenommen, separat anzeigbar sein oder auch ignoriert
werden.
In der Peer Discovery-Operation können außerdem noch die Header CapAuth, CapLink
und CapApp vorhanden sein.
CONNECT
In der OBEX Spezifikation (vergleiche Abschnitt 1.6.2) ist für diesen Befehl nur die
Auswertung der ersten 7 Byte verpflichtend vorgeschrieben. Für den Authentifikationsprozeß ist jedoch die Auswertung der Header in diesem Request unbedingt notwendig.
Für das mAuth System ist daher die Verarbeitung aller bis zur maximalen Paketlänge
vorhandenen Header im Connect-Request gefordert!
Eine mAuth CONNECT-Operation kann zusätzlich zu den in der OBEX Spezifikation erlaubten Header folgende Header-Typen enthalten: mAuthID, mAuthChallenge,
mAuthResponse, mAuthSessionKey, CapAuth, CapLink und CapApp.
DISCONNECT, ABORT, PUT, GET
Aufbau und Verwendung dieser Befehls entsprechen der OBEX Spezifikation (vergleiche
Abschnitt 1.6.2).
2.8.3.3
101
Header
Ein Großteil der Funktionalität des mAuth Protokolls wird durch zusätzliche Header
erreicht. Header bieten eine einfach zu parsende Möglichkeit strukturierte Informationen zu übertragen.
Anstelle der Capability Header hätte auch ein, dem in OBEX definiertem Capability
Service ähnlicher Mechanismus, verwendet werden können. Dort werden gerätespezifische Informationen mittels XML2 Objekte, die mit GET Requests angefordert werden
können, abgebildet.
Für die hier benötigten Zwecke ist eine Darstellung in Form von dafür spezialisierten Headern jedoch vorteilhaft. Sie ermöglicht bei ausreichender Funktionalität eine
wesentlich schlankere, Resourcen schonendere Implementierung.
In Tabelle 2.24 sind die mAuth spezifischen Header-Typen in einer Übersicht aufgeführt.
HI
0x70
0x71
0x72
0x73
0x74
0x75
0x76
0x77
0xB8
mobileAuth OBEX Header
Name
Beschreibung
mAuthID
vorhandene IDs: SerNr., Zertifikate
mAuthChallenge
AlgoType & Nonce
mAuthResponse
AlgoType & verschl. Nonce
mAuthSessionKey AlgoType & verschl. Nonce
CapAuth
unterstütze Auth. Algorth.
CapLink
unterstützte Linkversch. Algorth.
CapApp
unterstützte Anwendungsmodelle
PeerDescription
Beschreibung des KommPartners
Crypt
AlgoType, alles folgende
bis Paketende ist verschlüsselt
Tabelle 2.24: Erweiterte Headertypen
Eine bereits in der OBEX Spezifikation eingeführte Struktur ist das Tag-LenghtValue Triplet. Damit lassen sich innerhalb eines Headers fexibel unterschiedliche
Komponenten unterbringen.
Tag
Length
Value
Tabelle 2.25: Header Parameter Triplet
Der Tag charakterisiert die Art der Komponente und das Feld Length gibt die Länge
der eigentlichen Komponente, der Value an.
2
Extensible Markup Language
102
KAPITEL 2. KONZEPT
mAuthID
Der mAuthID Header ist in CONNECT-Request Paketen enthalten. Er enthält eine
oder mehrere Benutzeridentifikationsmerkmale. Der PoA-Server wertet diesen Header
aus, um den betreffenden Nutzer in seiner Zugangsdatenbank zu lokalisieren.
0x70
Header
ID
Length Triplet 1
ID
Triplet 2
(n Byte)
ID
Triplet n
(n Byte)
Tabelle 2.26: mAuthID Header
Durch seinen Aufbau aus Triplets kann dieser Header eine beliebige Anzahl und verschiedene Arten von IDs befördern. Abhängig von der verwendeten Chipkarte und der
auf ihr zur Verfügung stehenden Daten, kann es sinnvoll sein, mehr als nur eine Kennung auszusenden.
Es ist vorstellbar, daß ein Benutzer zuerst nur die Seriennummer seiner Karte zur
Identifikation verwendet. Zu einem späteren Zeitpunkt entschließt er sich jedoch, um
erweiterte Dienste nutzen zu können, sich ein Zertifikat ausstellen zu lassen.
Das Zertifikat ist aus Sicherheitsgründen das bevorzugte ID-Merkmal. Neue Anmeldungen an PoAs werden ab diesem Zeitpunkt mittels dem Zertifikat durchgeführt. Es
ist jedoch nicht zumutbar, daß sich der Benutzer nun sofort auch an allen PoAs, an
welchen er bisher nur mit seiner Kartenseriennummer angemeldet war, ummeldet.
Es muß nun, je nach PoA, die eine oder andere ID verwendet werden. Der PTDClient sendet daher im Verbindungsaufbau alle IDs, welche die Karte enthält aus. Die
bevorzugte Kennung wird dabei als erste übertragen.
mAuth Triplet Tags
Code
Bedeutung
0x00
Karten Seriennummer
0x01
Zertifikat
0x02-0xFF reserved
Tabelle 2.27: mAuth Triplet Tags
Unterschiedliche IDs können an ihren Triplet Tags erkannt und entsprechend verarbeitet werden.
Können nicht alle IDs aufgrund einer zu geringen maximalen unterstützen mAuthOBEX Paketlänge eines Kommunikationspartner im ersten CONNECT Paket untergebracht werden, werden diese in einzelnen, aufeinanderfolgenden CONNECT-Request
Paketen übertragen.
Durch einen fehlenden mAuthChallenge-Header in der CONNECT-Response erkennt
der Client eine nicht akzeptierte ID und sendet daher solange neue Requests aus, bis
103
entweder eine Kennung akzeptiert wurde, oder bereits alle vorhandenen IDs einmal
übertragen worden sind.
mAuthChallenge
MAuthChallenge Header enthalten die zur Durchführung des Challenge-Response Verfahrens notwendigen Daten.
Da sich im mAuth-System der PTD-Client beim PoA-Server authentifizieren muß,
ist dieser Header in einer Response des Servers vorhanden. Gewöhnlich enthält das
Response Paket auf den CONNECT-Request, der als erstes eine passende ID enthalten
hat diesen Header.
0x71
Header Length
(1 Byte)
(2 Byte)
AlgoType
(1 Byte)
Nonce
(n Byte)
Tabelle 2.28: mAuthChallenge Header
Neben dem Typ des zur Authentifikation gewünschten Krypto-Algorithmuses ist darin
eine vom Server erzeugte Zufallszahl in binärer Form enthalten. Diese Zahl wird auch
als Nonce“ bezeichnet.
”
mAuthResponse
Dieser Header enthält die Antwort auf einen mAuthChallenge Header.
Gemäß dem Authentifikationsablauf wird auch ein CONNECT-Request, der eine passende ID enthalten hat, mit einem Response-Code Unauthorisized abgelehnt. Der
Client antwortet darauf mit einem erneuten CONNECT-Request, welcher diesmal den
mAuthResponse-Header beinhaltet. Darin ist die mit dem geheimen Schlüssel des
Benutzers chiffrierte Nonce“ enthalten.
”
0x72
Header Length
(1 Byte)
(2 Byte)
AlgoType
(1 Byte)
encrypted nonce
(n Byte)
Tabelle 2.29: mAuthResponse Header
Dieser Header ist analog zum mAuthChallenge Header aufgebaut.
mAuthSessionKey
Bei Verwendung asymmetrischer Methoden könnte der Schlüsseltausch gleichzeitig auch zur Authentifikation verwendet werden. Die Nonce“ im mAuthChallenge
”
104
KAPITEL 2. KONZEPT
Header wäre der mit dem public Key des Kommunikationspartner verschlüsselte
Session-Key.
Die mAuthResponse zu dieser Challenge wäre die entschlüsselte und diesesmal mit
dem private Key verschlüsselte Nonce. Damit wäre die Authentizität überprüft und
ein geheimer Session-Key ausgetauscht.
Da jedoch bei der Verwendung symmetrischer Verfahren die Nonce“ in der Challenge
”
unverschlüsselt übertragen werden muß, um den Dienst der Authentifikation zu erbringen, kann diese nicht gleichzeitig als Session-Key verwendet werden.
Zu diesem Zweck existiert dieser zusätzliche Header. Er dient zur Vereinbarung eines
Session-Keys und wird zur Vereinheitlichung auch bei Verwendung asymmetrischer
Methoden benutzt.
0x73
Header AlgoType T
Länge
(1 Byte) (2 Byte)
(1 Byte)
AlgoType K
(1 Byte)
encrypted
Session-Key
(n Byte)
Tabelle 2.30: mAuthResponse Header
Der Session-Key wird vom PoA-Server vorgeschlagen“ und ist daher in einer
”
CONNECT-Response enthalten. Er ist mit einem Schlüssel des Benutzers, den der
PoA-Server entweder in seiner Datenbank hat oder in Form eines Zertifikats übermittelt bekommen hat, verschlüsselt.
Der dazu verwendete Algorithmus ist normalerweise derselbe, welcher auch zur Authentifikation verwendet wird. Sein Typ ist zur Vollständigkeit auch nochmals in diesem
Header im Feld AlgoType T angegeben.
AlgoType K spezifiziert dagegen den Typ des Linkverschlüsselungs-Algorithmus. Dieser Algorithmus wird nicht auf der Karte, sondern direkt im mobilen Gerät ausgeführt.
Der Session-Key wird dafür als Schlüssel verwendet.
CapAuth
Dieser Header wird wie alle Capability Header hauptsächlich in PEERDISC-Request
und Response eingesetzt. Er enthält eine Folge aller von dem aussendenden Gerät zur
Authentifizierung unterstützten Kryptoalgorithmen.
0x74
Header Length
(1 Byte)
(2 Byte)
AlgoType 1
(1 Byte)
AlgoType 2
(1 Byte)
AlgoType n
(1 Byte)
Tabelle 2.31: CapAuth Header
Die Kodierung erfolgt gemäß Tabelle 2.5. Die Reihenfolge der Übertragung bestimmt
die Priorisierung der einzelnen Verfahren. Der bevorzugte Algorithmus wird zuerst
gesendet.
105
CapLink
CapLink ist in Aufbau und Einsatz zum CapAuth-Header identisch. Er spezifiziert
jedoch nicht die unterstützten Authentifikations-Algorithmen sondern die Fähigkeiten
zur Verschlüsselung der Kommunikationsverbindung.
0x75
Header Length
(1 Byte)
(2 Byte)
AlgoType 1
(1 Byte)
AlgoType 2
(1 Byte)
AlgoType n
(1 Byte)
Tabelle 2.32: CapLink Header
CapApp
Nach erfolgreicher Authentifikation sollen je nach PoA verschiedene Funktionen ausgeführt und gesteuert werden können (siehe Abschnitt 2.9). Die mAuth-PTD-Client
Anwendung muß diese unterstützen.
Mittels diesem Header können bereits in der Peer Discovery-Phase Client und Server
ihre Fähigkeiten und Anforderungen dahingehend abgleichen und im Falle, daß keine Übereinstimmung gefunden werden kann, den Verbindungsaufbau von vornherein
ausschließen.
0x76
Header Length
(1 Byte)
(2 Byte)
AppID 1
(2 Byte)
AppID 2
(2 Byte)
AppID n
(2 Byte)
Tabelle 2.33: CapApp Header
Der CapApp-Header muß darüberhinaus im CONNECT-Request und Response enthalten sein um den verwendeten Anwendungsfall“ festzulegen. In der Connect Pha”
se übermittelt damit der PoA-Server die von ihm geforderte Anwendung, der PTD
bestätigt, falls er die Anwendung unterstützt, dies mit einem identischen CapAppHeader im folgendem Request.
Eine Auflistung vorgeschlagener Applikationstypen samt zugeordneter AppIDs ist in
Abschnitt 2.9 zu finden.
PeerDescription
Der PeerDescription Header ist eigentlich zur Verwendung in PeerDisc-Operationen
gedacht, um optional zusätzlich zum dort enthaltenen Description String weitergehende
Informationen über das betreffende Gerät zu liefern.
Er kann bei Bedarf jedoch auch in CONNECT-Operationen benutzt werden.
Die Informationen sind in der schon bekannten Tag-Length-Value Struktur kodiert.
Tabelle 2.35 enthält die bisher definierten Informationstypen.
106
KAPITEL 2. KONZEPT
0x70
Header
Info
Länge Triplet 1
Info
Triplet 2
(n Byte)
Info
Triplet n
(n Byte)
Tabelle 2.34: PeerDescription Header
Dieser Header-Typ ist hauptsächlich dazu gedacht, dem Client Informationen über
den Server zu übermitteln. Er kann jedoch auch für den umgekehrten Weg eingesetzt
werden.
PeerDescription Triplet Tags
Code
Inhalt
0x00
Typ
0x10
Bezeichnung
0x11
Standort: Straße
0x12
Standort: Ort
0x13
Standort: Land
0x20
Betreiber
0x30
Hersteller
0x31
Seriennummer
0x32
Herstellungsjahr
0x40-0xFF reserved
Tabelle 2.35: PeerDescription Triplet Tags
Einige Tags, wie z.B. der Standort-Tag sind jedoch nur bei einem PoA-Servern sinnvoll.
Crypt
Der Crypt Header ist das Signal dafür, daß der Bytestrom ab diesem Header bis zum
Endes des Pakets verschlüsselt ist.
Er besteht aus der Header-Kennung und einem weiteren Byte. In diesem Byte ist der
Typ des verwendeten Verschlüsselungsalgorithmus in der in Tabelle 2.5 beschriebenen
Kodierung und die Art der Blockbildung enthalten. Der Typ des Blockbildungsalgorithmus ist in den höchstwertigen 2 Bit kodiert.
0xB8
AlgoType & Blockcode
(1 Byte)
(1 Byte)
Tabelle 2.36: Crypt Header
Den endgültigen Wert, der Kryptoalgorithmus und zugehörige Blockbildung charakterisiert, erhält man durch einfaches Aufaddieren der entsprechenden beiden Codes.
107
Blockbildungs Arten
Code Typ
0x40 ECB
0x80 CBC
0xC0 reserved
Tabelle 2.37: Kodierung von Blockbildungsarten
Die, diesem Header folgenden verschlüsselten Daten, müssen vom Empfänger erst entschlüsselt werden bevor sie weiter geparst werden können.
Mit diesem Headers wird sie Kommunikationsverschlüsselung realisiert. Die dazu notwendigen Schlüssel müssen in der Verbindungsaufbauphase ausgehandelt worden sein.
2.8.4
Chipkarten-Applikation - Zustände und Automat
Die default Chipkarten-Applikation im mAuth-System kennt drei Zustände in denen sie
sich befinden kann. Nach dem Start der Applikation befindet sie sich im niedrigst privilegierten Zustand. Durch Eingabe der entsprechenden PIN Nummern kann in andere
Zustände gewechselt werden.
Im Startzustand, nach einem Kartenreset, können außer der Abfrage der ChipkartenFähigkeiten und der Eingabe einer PIN, keine weiteren Aktionen ausgeführt werden.
wait(command)
change state
command
not allowed
done
check state
change request
PIN Ok
change state
command allowed
execute
Abbildung 2.22: Chipkarten Zustandsautomat
108
KAPITEL 2. KONZEPT
Die Eingabe der Standard PIN“ versetzt die Karte in den normalen“ Betriebszu”
”
stand. Dort dürfen alle Befehle, bis auf das Setzten oder Ändern von Daten auf der
Karte ausgeführt werden.
Das ist im Verwaltungs-Zustand nach erfolgreicher Eingabe der Verwaltungs PIN
erlaubt. Auch der (öffentliche) Schlüssel darf nur in diesem Zustand ausgelesen werden.
Zur Neuanmeldung an PoAs und zur Zertifikatsaustellung muß sich die Karte also in
diesem Betriebszustand befinden.
Wie jede Chipkarten-Applikation ist auch diese Anwendung passiv. Sie wartet auf eingehende Befehls APDUs, welche sie verarbeitet und mit einer entsprechenden Response
beantwortet.
Noch vor der Befehlsausführung wird überprüft, ob das empfangene Kommando im
aktuellen Sicherheits-Level überhaupt zugelassen ist. Ist das nicht der Fall, wird ein
entsprechender Status zurückgesendet und die Karte geht wieder in den Zustand
wait(command) über.
Ist das entsprechende Kommando erlaubt, wird es ausgeführt und beantwortet.
Eine Sonderform bildet das VrfPIN Kommando, welches nur die interne Sicherheitsstufe
der Karte ändert und dann wieder in den Wartezustand zurückkehrt.
2.8.5
PTD-Anwendung - Zustände und Automat
Beim Start der PTD-Client-Anwendung wird der Chipkartenleser initialisiert, die Kommunikation zur Karte aufgebaut und die mAuth default Chipkarten-Applikation selektiert. Tritt in der Initialisierung ein Fehler auf, erfolgt nach Anzeige des Fehlers unmittelbar die Beendigung der Anwendung.
Andernfalls folgt die Darstellung des PIN Dialoges zur Eingabe der Standard PIN und
das Aussenden eines VrfPIN Kommandos an die Karte. Nur bei positiver Antwort
der Karte wird die Anwendung fortgesetzt. Ansonsten verweilt sie im PIN-Dialog und
fordert zur erneuten Eingabe auf. Ist der Fehlbedienungszähler der Karte abgelaufen
kann nur noch der PUK eingegeben werden. Ist auch dieser falsch, beendet sich die
Anwendung, ist er korrekt beginnt die PIN-Abfrage von Neuem.
Ist die korrekte PIN überprüft worden, beginnt der Peer Discovery-Vorgang. Die gefundenen PoAs werden dem Benutzer im darauffolgendem PoA-Auswahldialog dargestellt.
In regelmäßigen Abständen wird im Hintergrund ein neues Peer Discovery durchgeführt
und die Anzeige entsprechend aktualisiert.
Die Anwendung verweilt in diesem Dialog solange, bis der Nutzer einen PoA und
eine Aktion gewählt hat. Hieraus kann die Anwendung auf Benutzerwunsch jederzeit
beendet werden.
109
error
init
retry
error
too many
failures
enter PIN
get card cap
peer discovery
refresh
exit
peer selected
select peer
exit
user accepted/rejected
auth failed
peer selected
new user
apply
auth
execute App
Abbildung 2.23: PTD-Zustandsautomat
Darüberhinaus kann der Nutzer zwischen Neuanmeldung an einem PoA oder der
Authentifizierung wählen. Während die Neuanmeldung die dazu notwendigen Daten
überträgt, den Status anzeigt und wieder in den Auswahldialog zurückkehrt, startet
die Authentifikation im Erfolgsfall das entsprechende Applikationsmodell (vergleiche
Abschnitt 2.9). Schlägt die Authentifikation fehl, teilt die mAuth Anwendung das dem
Nutzer mit und geht ebenfalls wieder in den Auswahldialog über.
2.8.6
PoA-Server - Zustände und Automat
Der Grundzustand des PoA-Servers ist das Hören“ auf eingehende Pakete. Der Zu”
standsautomat 2.24 geht davon aus, daß immer ein derartiger Prozeß“ zur Verfügung
”
File: J:\diplomarbeit Bilder\Eigene Dateien\server3.mdl
23:16:40 Dienstag, 12. Juni 2001
State Diagram: PTD Page 1
110
KAPITEL 2. KONZEPT
steht, d.h. bei einem Verbindungsaufbau umgehend ein neuer Prozeß gestartet wird,
welcher neue Verbindungswünsche bearbeiten kann.
Das stellt auch sicher, daß PEERDISC-Requests immer bearbeitet und beantwortet werden können.
Viele PoA-Server werden darüberhinausgehend jedoch keine gleichzeitigen Verbindungen zu mehreren Clients erlauben. Daher muß bei jedem eingehenden Verbindungswunsch überprüft werden, ob der Server bereits mit einem anderen Client verbunden
ist, und ob eine weitere Verbindung zulässig ist.
Ist ein Verbindungsaufbau zulässig, startet der CONNECT-Vorgang wie in Abschnitt
2.8.3 definiert. Wenn keine weiteren Verbindungen erlaubt sind, wird der Verbindungswunsch mit einem Response-Code Service Not Available“ abgelehnt.
”
peer disc
listen
no more allowed
request
timeout
connect
auth failed
reject user
if another
connection
allowed
accept user
new user
user known
check auth
disconnect
timeout
auth
Abbildung 2.24: PoA-Zustandsautomat
Ist in einem CONNECT-Request keine, dem PoA bekannte Benutzerkennung vorhanden, überprüft der PoA-Server, ob er von seinem Administrator in einem Zustand zur
2.9. APPLICATION FRAMEWORK
111
Neuanmeldung von Nutzern versetzt worden ist. Ist das der Fall, stellt er die neue
Benutzerkennug auf seinem Administrator-Terminal dar. Falls der PoA-Administrator
diese Benutzeranmeldung authorisiert, werden diese Daten in die Benutzerdatenbank
des PoA-Servers aufgenommen.
Dabei findet jedoch kein vollständiger Verbindungsaufbau statt. Der Server geht, wie
auch bei der Ablehnung einer ID, sofort wieder in den Zustand listen über.
Ist der PoA-Server nicht zur Aufnahme neuer Kennungen bereit oder fehlen zur Neuanmeldung wichtige Daten, lehnt er den Verbindungswunsch ab, und kehrt ebenfalls
in den Zustand listen zurück.
Befindet sich in der Zugangsdatenbank des PoA-Servers bereits ein zur Kennung passender Eintrag, wird der Verbindungsvorgang mit der Authentifizierung fortgesetzt.
Treffen bei diesem Vorgang längere Zeit keine notwendigen Pakete vom Client mehr
ein, erfolgt nach Ablauf einer angemessenen Wartezeit (< 30sec) ein Übergang in den
Zustand listen durch TIMEOUT.
Der selbe Übergang findet bei einer fehlgeschlagenen Authentifizierung statt. Ein Verbindungsaufbau kann auch durch nicht übereinstimmende Applikationsmodelle oder
fehlende oder falsche Session-Keys abgelehnt werden.
Verläuft die Authentifikation jedoch erfolgreich, ist der Verbindungsaufbau damit beendet, die beiden Kommunikationspartner sind verbunden und der Server befindet sich
im Zustand authenticated.
An dieser Stelle wird nun das ausgehendelte Anwendungsmodell ausgeführt. Nach dessen Beendigung wird die Verbindung mittels eines DISCONNECT-Requests vom PTDClient beendet.
Falls der Client, z.B. durch eine fehlerhafte Implementierung keinen DISCONNECTRequest aussendet, oder die physikalische Verbindung abreißt“, muß auch hier ein
”
Übergang in den Zustand listen durch TIMEOUTS vorgesehen werden, um eine Blockierung des Servers zu verhindern. Dieser TIMEOUT muß jedoch bedeutend länger angesetzt
werden, da hier Interaktionen mit dem Benutzer stattfinden, und neue Pakete oft erst
nach Benutzereingaben übertragen werden. Ein angemessene Zeitspanne dürfte zwei
bis fünf Minuten betragen.
2.9
2.9.1
Allgemeines
Gewöhnlich ist die erfolgreiche Authentifikation die Voraussetzung, nicht aber das Ziel
der Ausführung der mAuth PTD-Client-Anwendung.
112
KAPITEL 2. KONZEPT
Je nach PoA sollen verschiedene Aktionen und Interaktionen stattfinden. Das PTD
dient dabei als sicheres Terminal der Kommunikation mit dem PoA und steuert diesen.
Dazu muß die PTD-Client-Applikation wissen, um welche Art von PoA-Anwendung es
sich handelt, damit die dazu notwendige Funktionalität bezüglich User-Interface und
Kommunikationsprotokoll bereit gestellt werden.
Die genaue Definition dieser Anwendungsmodelle ist nicht mehr Aufgabe dieses Systementwurf. Da jedoch zumindest der Anwendungs-Auswahl-Mechanismus“ Teil der
”
Verbindungsaufbauphase ist und somit in diesem Konzept spezifiziert worden ist, sollen
in Form dieses Application Frameworks Richtlinien und Vorschläge für eine Spezifikation von Anwendungsmodellen vorgegeben werden.
Die unterschiedlichen Funktionalitäten der PoA-Server werden in sogenannten Applikationsmodellen erfaßt.
Der Typ eines Applikationsmodells wird in den CapAPP-Headern mittels 2 Bytes kodiert. Das erste Byte in Übertragungsreihenfolge spezifiziert die Art des Applikationsmodells. Das zweite Byte dessen Versionsnummer.
Es ist zu erwarten, daß sich die Anforderungen an Applikationsmodelle im Laufe der
Zeit ändern werden und somit deren Umfang und Komplexität zunehmen wird. Im
Vergleich zur Grunddefinition erweiterte Fähigkeiten eines Applikationsmodells werden
durch Erhöhung der Versionsnummer gekennzeichnet. Dabei ist gefordert, daß Geräte,
die ein bestimmtes Applikationsmodell unterstützen, immer zur Grunddefinition mit
der Versionsnummer 0x00 abwärts kompatibel bleiben. Dadurch ist sichergestellt, daß
eine Kommunikation, wenn auch mit eingeschränkten Fähigkeiten, auch mit älteren
Geräten möglich ist.
Applikation Identifier
Typ
Version Bedeutung
0x00
0x00
Zugang
0x01
0x00
Öffnen/Schließen
0x02
0x00
Geldautomat
0x03
0x00
Point of Sale
0x04
0x00
Trustcenter
0x05
0x00
Datentransfer
0x06
0x00
elektronische Unterschrift
0x07
0x00
XML Browser Darst“.
”
0x08
0x00
dynamische Client Applets
0x09-0xFF 0x00
reserved for future use
Tabelle 2.38: mAuth Application Identifier
Um ein einheitliches Zusammenarbeiten zu gewährleisten, müssen neue Applikationsmodelle, wie auch neue Versionen öffentlich bekanntgemacht und in die Spezifikation
aufgenommen werden.
2.9. APPLICATION FRAMEWORK
113
Tabelle 2.38 enthält eine Zuordnung von AppIDs zu den vorgeschlagenen Applikationsmodellen.
2.9.2
Applikationsmodelle
Zugang
Dieses Modell ist das einfachste Applikationsmodell. Es beschreibt Vorgänge, in denen
eigentlich nur die erfolgreiche Authentifikation erforderlich ist und keine weitere Interaktion mit dem Benutzer. Dies ist z.B. die Anmeldung an Rechnersysteme oder der
Zutritt zu Büro/Laborräume. Als Bedienelement kann hier ein Bestätigungs Button
vorhanden sein und evtl. der Name des PoA-Systems angezeigt werden.
Öffnen/Schließen
Dies ist die Erweiterung des Modells Zugang um die Fähigkeit des Abschließens“.
”
Damit lassen sich konventionelle Schlüssel ersetzen und Aufgaben wie z.B. das Öffnenund Schließen von Haustüre oder Auto realisieren. Die Interaktion mit dem Benutzer
beschränkt sich auf die Auswahl der Aktion (Öffnen oder Schließen).
Geldautomat
Die Bedienung von Geldautomaten erfordert dagegen mehr Interaktion zwischen Nutzer
und PoA-Server. Das Applikationsmodell muß diese Funktionalität bieten.
Point of Sale
Point of Sale Anwendung sollen das bargeldlose Bezahlen realisieren. Die Liste mit den
eingekauften Artikeln soll am PTD angezeigt und zu Verwaltungszwecken gespeichert
werden können. Ist die Auflistung korrekt, bestätigt der Kunde dies, signiert diese
Rechnung mit seiner elektronischen Unterschrift und sendet sie an den PoA-Server des
PoS zurück.
Trustcenter
Die Schlüsselüberprüfung, die drahtlose Übertragung von Zertifikaten oder sonstigen
Informationen zwischen Trustcenters und PTD, sowie die dazu notwendige Interaktion
mit dem Nutzer werden in diesem Anwendungs-Modell erfaßt.
Datentransfer
Damit soll es möglich sein, beliebige elektronische Dokumente auf sicherem Wege zu
übertragen. Eine Mögliche Anwendung ist z.B. die Übertragung der persönlichen Kontoauszüge von einem Bank-PoA.
elektronische Unterschrift
Der Benutzer kann die elektronische Unterschrift als universelle Methode zum Ausweisen seiner Identität verwenden.
114
KAPITEL 2. KONZEPT
XML- Browser“ Darstellung
”
Eine Einschränkung der bisher definierten Modelle ist, daß sie die geforderte Steuerfunktionen und Anzeigeelemente nur statisch zur Verfügung stellen, der PoA kann
damit die Darstellung und Interaktion nicht individuell gestalten.
PTDs die über genügend Leistungsfähigkeit verfügen, können mit diesem Modell eine
Art Browser“ implementieren. Dieser Browser“ ist vergleichbar mit den vom WWW
”
”
bekannten HTML Browsern. Zur Stukturierung der übertragenen Daten soll jedoch
das wesentlich flexiblere XML zusammen mit den Layoutbeschreibungen CSS3 oder
XSL4 verwendet werden. Der PoA-Server kann damit die Darstellung der Bedien- und
Anzeigeelemente auf dem PTD-Client bestimmen.
Diese Modell besitzt Ähnlichkeit mit der aus dem Internet bekannten Kombination aus
HTML Browser und HTTP Server mit CGI Unterstützung.
dynamische Client Applets
Dieses Applikationsmodell erweitert das XML Modell um die Fähigkeit, vom PoAServer übertragene, Programme auf dem PTD auszuführen. Diese Funktionalität ist
vergleichbar mit HTML Browsern, welche Java Applets ausführen können.
Die Art der PTD-Applets soll hier nicht weiter spezifiziert werden, die Verwendung
von Java würde sich jedoch anbieten. Bei der Implementierung ist darauf zu achten,
daß die Applets in einer abgesicherten Umgebung mit genau defierten Berechtigungen
ablaufen.
Dies ist zwar das komplexeste und Resourcen-intensivste Modell, jedoch auch das
universellste. PTD und PoAs, welche dieses Modell unterstützen, können ohne Unterstützung weitere Applikationsmodelle voraussichtliche jeden Anwendungsfall abdecken.
2.9.3
Verwendung des mAuth-OBEX Protokolls
Auch diese Anwendungen nutzen zur Kommunikation zwischen PTD und PoA das
mAuth OBEX Protokoll. Sie tauschen ihre Daten mittels der PUT und GET Befehle aus.
Die Daten-Objekte werden dabei mit Body-Headern übertragen. In jedem Paket soll
der Crypt-Header zur Kommunikationsverschlüsselung benutzt werden. Dieser Header
soll spätestens vor dem Body-Header enthalten sein.
Die Auswahl und Kennzeichnung der unterschiedlichen Datenobjekte erfolgt mittels
der Type und Name Header. Weiterhin kann die Verwendung von Count, Description
und Length Header sinnvoll sein. Es ist den Entwicklern der Anwendungen überlassen,
ob und wie sie diese einsetzen.
3
4
Cascading Style Sheets
Extensible Style Language
Teil II
Praktischer Teil
115
117
Kapitel 3
Grundlagen des
Demonstrationssytems
3.1
Die praktische Umsetzung des Konzepts
Neben der theoretischen Ausarbeitung eines Konzepts war es eine weitere wichtige
Aufgabe dieser Diplomarbeit, dieses Konzept in Form eines Demonstrationsystems zu
realisieren. Das Demonstrationssystem sollte die praktische Einsatzfähigkeit der theoretischen Spezifikationen zeigen, jedoch nicht zwangsläufig das Konzept in vollem Umfang
implementieren.
Meine Umsetzung des Konzepts beschränkt sich daher auf ein einfaches Applikationsmodell vom Typ Zugang“ und verwendet weder Zertifikate, noch die Autorität eines
”
Trustcenters.
Die mAuth Systemkomponenten sind dabei auf folgender Hardware umgesetzt worden:
mobiles Gerät:
Chipkarte:
Chipkarten Lesegerät:
PoA:
lokale Übertragungstechnik
Handspring Visor Platinum PDA
Giesecke & Devrient Sm@rtcafé Javacard
Towitoko Chipdrive micro 100
Linux (Suse 7.1) PC
IrDA
Als mobiles Gerät wäre die Implementierung auf einem Mobiltelefon besonders interessant und wünschenswert gewesen, da diese Geräte derzeit die größte Verbreitung in der
Bevölkerung besitzen. Dazu wäre jedoch die Modifikation seines Betriebssystems unabdingbare Voraussetzung gewesen, da Mobiltelefone heute noch nicht wie z.B. PDAs
die Möglichkeit bieten, Programme außer der eigenen Firmware auszuführen.
Alle Mobiltelefon-Hersteller, mit denen wir in Kontakt getreten sind, hatten jedoch
118
KAPITEL 3. GRUNDLAGEN DES DEMONSTRATIONSSYTEMS
Sicherheitsbedenken, die Sourcen und die Entwicklungsumgebung für ihre Telefone
herauszugeben. Als beste Alternative bot sich ein PDA zur Verwendung als Systemkomponente mobiles Gerät“ an.
”
Das Chipkarten-Lesegerät ist anders als in der theoretischen Spezifikation hier als eigene Komponente aufgeführt. Da keiner der zum Zeitpunkt der Erstellung dieser Arbeit
am Markt erhältlichen PDAs bereits einen integrierten Chipkarten-Reader besaß, war
es notwendig, ein externes Gerät zu verwenden.
Die lokale Übertragungstechnik“ ist streng genommen gemäß dem Konzept auch keine
”
eigenständige Systemkomponente, sondern Bestandteil des mobilen Geräts und des
PoA-Servers. Das ist auch in der praktischen Umsetzung so; sie wurde nur zum Zwecke
der besseren Übersicht einzeln aufgeführt.
Die Auswahl der verwendeten Komponenten erfolgte aufgrund folgender Argumente:
• Handspring Visor Platinum:
– Freie Programmierbarkeit
– Gute Hardware-Erweiterbarkeit
– Für PDAs schneller Prozessor
– Unterstützung des weit verbreiteten PalmOS
– IrDA-Port
• Giesecke und Devrient Sm@rtcafé Javacard:
– Relativ neue und innovative Technologie
– Möglichkeit, mehrere Applikationen auf einer Karte zu installieren
– Gute Sicherheitsmechanismen
– Unterstützung mehrerer unterschiedlicher Kryptoalgorithmen
– Durch Verwendung der Java-Sprache vertraute“ Programmierumgebung
”
• Towitoko Chipdrive 100:
– Kompakte Bauweise
– Gute Unterstützung von vorhandenen Chipkarten-Libraries
– Günstiger Preis
– Gute Dokumentation und Bastelanleitungen“ aus dem Internet vorhanden
”
• Linux (Suse 7.1) PC:
– Freie Programmierbarkeit
– Sehr einfach um Infrarot-Hardware zu erweitern
3.2. DIE IRDA-TECHNOLOGIE
119
– IrDA-Protokoll-Unterstützung im Basissystem vorhanden
– Login Prozeß leicht zu modifizieren
– Verfügbarkeit der Sourcen zu allen Systemkomponenten
3.2
Die IrDA-Technologie
Das Demonstrationsystem verwendet als lokale Übertragungstechnik die von der IrDA
spezifizierte Technologie. In diesem Abschnitt sollen einige wichtige Aspekte des IrDAProtokolls näher erläutert werden, die über das bereits in Abschnitt 1.3.2.1 Besprochene
hinausgehen.
IrDA-Verbindungen sind, wie fast alle lokalen Übertragungstechnologien, auf spontane
Kommunikation mit - bis dahin unbekannten Partnern - ausgelegt. Daher besitzen sie
die Möglichkeit, die zur Kommunikation notwendigen Parameter selbständig auszutauschen, um eine Verbindung aufzubauen.
Jede IrDA-Implementierung muß folgende 3 Schichten in ihrem Protokollstack implementieren:
• Physical Layer PHY: spezifiziert die physikalischen Charakteristika einer
IrDA-Verbindung, wie z.B. Impulsform und -länge, sowie die Bit-Kodierung und
Prüfsummenbildung.
• Link Access Protocol LAP: erbringt den Dienst der zuverlässigen Datenübertragung durch Mechanismen wie Übertragungswiederholung, Fehlererkennung
und Flußkontrolle. Darüberhinaus findet diese Schicht durch einen Discovery”
Prozeß“ in Reichweite liegende IrDA-Geräte.
• Link Management Protocol LMP: erlaubt das Multiplexing mehrerer Dienste über eine LAP-Verbindung und ermöglicht weitergehende“ Discovery”
Mechanismen durch die IAS-Datenbank.
Auf diesen Sockel“ setzen alle höheren Protokollschichten, wie z.B. im mAuth System
”
TinyTP und mAuth-OBEX, auf.
Um eine Verbindung durch diese drei Schichten herzustellen, müssen mindestens die
Parameter IrDA-Geräte-Adresse und der LSAP1 Selector des gewünschten Dienstes
bekannt sein.
Die 32 Bit langen IrDA-Adressen kennzeichnen die Endpunkte einer IrDA-LAPVerbindung. Sie sind nicht wie bei anderen Netzwerktechnologien wie z.B. Ethernet
oder Wireless LAN fest an die Hardware eines Gerätes gebunden, sondern werden von
den IrDA-Geräten selbstständig dynamisch gewählt und können sich dadurch ändern.
1
Logical Service Access Point
120
Der LAP-Discovery-Mechanismus spürt nicht nur in Reichweite liegende Kommunikationspartner auf, sondern erträgt auch deren jeweils aktuelle“ Adresse.
”
Sollten innerhalb einer kommunizierenden Gruppe zufällig zwei Geräte die selbe Adresse gewählt haben, kann dieser Konflikt mit den Mitteln der LMP-Schicht gelöst werden.
Deren erweiterte Discovery-Funktionen können einen Kommunikationspartner veranlassen eine neue IrDA-LAP-Adresse zu generieren, und das Problem damit lösen.
LSAP-Selectoren kennzeichnen die Endpunkte kommunizierender Dienste. Sie haben
nur eine Länge von 8 Bit. Desweiteren sind bestimmte Wertebereiche davon für
besondere Dienste reserviert. Daher können auch diese Dienstbezeichner nicht statisch bestimmten Diensten zugeordnet werden. Verschiedenen Services sind daher, anstatt fester Nummern, eindeutige und veröffentlichte Namen“ zugewiesen. Mittels des
”
LMP-IAS können die aktuell einem Namen zugeordneten LSAP-Selektoren erfragt werden.
Der IAS kann als eine Art Gelbe Seiten“ eines IrDA fähigen Gerätes betrachtet werden
”
und ist Teil der LMP-Schicht des IrDA-Stacks. Er verwaltet in einer Art Datenbank
relevante, die IrDA-Funktionalität des jeweiligen Geräts betreffende Informationen.
Ein IAS-Server betreibt und aktualisiert die IAS-Datenbank und weiß auf die Anfragen eines IAS-Client zu antworten. Die meisten IrDA-Realisierungen implementieren
sowohl Client als auch Server.
Die IAS-Datenbank beschreibt jeden angebotenen Service in Form eines Objects. Ein
IAS-Object besteht aus einem class name und einem oder mehreren Attributen. Die
class names von Diensten sollen fest sein und werden öffentlich bekannt gemacht. Das
mAuth System verwendet den class name OBEX:mAuth. Das wichtigste Attribut eines
IAS-Objects ist der aktuell zugeordnete LSAP-Selector für diesen Dienst.
Ein Kommunikationspartner, der eine Verbindung zu diesem Dienst aufbauen möchte,
benötigt diesen Wert. Daher startet der IAS-Client des Partners eine entsprechende den
Klassennamen betreffende Anfrage. Der Server liefert den gesuchten LSAP-Selector in
Form eines Attributs zurück. Die dazu verwendete IAS-Operation wird als GetValueByClass bezeichnet. Damit spezifiziert der Client den class name und das gesuchte
Attribut.
IAS-Attribute können je nach gegebenen Anforderungen weit mehr als nur den LSAP
Selector eines Services enthalten. Für die Zwecke dieses Projekts ist hier jedoch nur
der LSAP Selectors relevant !
3.3
IrDA-Unterstützung auf Personal Computern
Seit geraumer Zeit sind die meisten Mainboards von Personal Computern mit der
notwendigen Elektronik zum Betrieb eine IrDA-SIR-Schnittstelle ausgerüstet. Aufgrund der Konzeption der physikalischen Schicht der IrDA-SIR-Schnittstelle [PQT98]
3.3. IRDA-UNTERSTÜTZUNG AUF PERSONAL COMPUTERN
121
kann dazu der für den Betrieb des seriellen RS-232-Ports vorhandene UART Baustein genutzt werden. Die eingesetzten Impulslängen entsprechen Vielfachen der auf der
RS-232-Schnittstelle verwendeten Impulse. Es ist somit nur wenig zusätzliche AnsteuerHardware notwendig.
Im BIOS des PC kann in der Regel zwischen dem Betrieb eines zweiten COM-Ports
oder einer IrDA-Schnittstelle gewählt werden. Da in beiden Fällen der selbe UART
Baustein verwendet wird, ist beides gleichzeitig nicht möglich.
Abbildung 3.1 zeigt ein Blockschaltbild der Hardware einer IrDA-SIR-Schnittstelle.
Abbildung 3.1: IrDA physikalische Schnittstelle Schema (Quelle [PQT98])
Außer Laptops sind derzeit jedoch noch kaum PCs von Werk aus auch mit dem notwendigen Infrarot Transceiver-Modul ausgestattet. Diese werden von diversen Herstellern
als Zubehör - zu nicht immer angemessenen Preisen - angeboten.
3.3.1
Bau eines IrDA-Transceivers für den PC
Da, wie bereits erwähnt, moderne PC Mainboards bereits alle Komponenten einer
IrDA-Schnittstelle bis auf den Transceiverbaustein besitzen, ist ein Selbstbau dieser
Komponente einfach und günstig möglich.
Der Transceiver entspricht der äußerst rechten Baugruppe im Blockschaltbild 3.1. Der
Anschluß an das PC Motherboard erfolgt, je nach Board-Hersteller, meist über einen
4 poligen Pfostenstecker mit den Signalen RX und TX sowie VCC und GND.
Ein geeigneter Transceiver Baustein ist z.B. der TFDS 4500 von Vishay Telefunken.
Er beinhaltet Infrarot Sende- und Empfangsdiode sowie die notwendige Treiber- und
Reglerbeschaltung (siehe Abbildung 3.2). Damit läßt sich mit nur wenigen zusätzlichen
Bauteilen ein dem IrDA-1.2-SIR-Standard entsprechendes Tranceivermodul aufbauen.
122
Abbildung 3.2: Blockschaltbild des TFDS4500(Quelle [Tel99])
Auf der Webseite [Rei01] ist dazu eine sehr umfangreiche Beschreibung und Stoffsammlung vorhanden. Unter anderem finden sich dort Anleitungen zu den Anschlußmöglichkeiten an unterschiedliche Mainboard Typen.
Der Schaltplan 3.3, welcher ebenfalls von dieser Webseite stammt, diente mir als Vorlage für den Aufbau des Moduls.
Abbildung 3.3: Schaltplan IrDA-Adapter (Quelle [Rei01])
Diese Beschaltung entspricht eigentlich der von Vishay Telefunken im Datenblatt zum
TFDS 4550 vorgeschlagenen Referenzbeschaltung. Sie wurde nur um einen PufferKondensator C3 gegen instabile Versorgungsspannung und eine Sendekontroll-LED
ergänzt. Die LED blinkt, sobald das Modul etwas aussendet.
Die Kombination aus C1, C2 und R2 dient der Glättung der Versorgungsspannung und
dem Ausfiltern hochfrequentem Rauschens. Bei einer stabilen Spannungsversorgung,
wie sie bei den meisten Mainboards vorhanden ist, könnte eigentlich darauf und auf
den Puffer-Elko auch verzichtet werden. Ich entschied mich jedoch, diese Baugruppen
zur Sicherheit mit zu integrieren.
Zur Kontrolle der Verbindung zum Mainboard habe ich die Beschaltung aus 3.3 noch
um eine weitere LED ergänzt. Diese liegt mitsamt passenden Vorwiderstand direkt
zwischen VCC und GND und zeigt durch ihr Leuchten die Betriebsbereitschaft an.
Die Schaltung wurde auf einem kleinen Stück Lochrasterplatine aufgebaut. Damit das
123
Abbildung 3.4: PC-IrDA-Adapter
gesamte Modul in einem Gehäuse eines Parallelport-Steckers Platz fand, und zum
sauberen Abschluß der Gehäusevorderseite, montierte ich den TFDS4500 Transceiver
auf einem seperaten Platinenstreifen im rechten Winkel zur anderen Platine.
Die Gehäuseoberseite wurde mit zwei Bohrungen zur Durchführung der LEDs versehen
und die Oberfläche der Platine an der Front des Gehäuses mit schwarzen Klebeband
überzogen.
Als Anschlußkabel diente ein ausgedientes Datenkabel mit genügend Leitungen und
einer Schirmung aus Drahtgeflecht. Die Wahl der Verbindungsleitung zwischen Transceivermodul und Mainboard dürfte jedoch bei einer Länge unter etwa zwei Metern
relativ unkritisch sein, so daß die Schirmung nicht unbedingt notwendig gewesen wäre.
3.3.2
Linux-IrDA
IrDA-Unterstützung des Betriebsystems Linux ist in Form eines Kernelmoduls und
einiger Userspace“-Programme verwirklicht.
”
Die Entwicklung am Linux/IrDA-Projekt begann Ende 1997. Seit Kernelversion 2.2.0
ist es fester Teil des Linux-Kernels. Mit Veröffentlichung der Kernelversion 2.2.10 wurde
es erstmals unter der Bezeichnung “stabil“ und nicht mehr experimentell“ geführt.
”
124
Bei einer Neu-Übersetzung des Kernel kann die IrDA-Unterstützung wahlweise fest
mit einkompiliert oder als Kernelmodul gebaut werden. Die meisten Distributionen,
so auch das von mir eingesetzte Suse 7.1, haben den IrDA-Support als Kernelmodul
realisiert.
Neben dieser Kernkomponente existiert noch das Paket IrDA-Utils. Darin sind Dienstprogramme enthalten, mittels welcher des Verhalten des IrDA-Subsystems gesteuert
und analysiert werden kann. Es besteht im wesentlichen aus den Komponenten:
• irattach: verbindet ein IrDA fähiges tty mit dem Kernelmodul und startet somit
den eigentlichen IrDA-Service.
• irdaping: damit ist es möglich, die Verbindung zu einem anderen IrDA fähiges
Gerät - sofern dies IrDA-Test-Frames unterstützt - ähnlich dem von Unix bekannten Tool ping zu Testen. Als Zieladresse muß eine 32 Bit IrDA-LAP-Adresse
angegeben werden.
• irdadump: zeigt alle ausgesendeten und empfangenen Frames an. Dies ist besonders nützlich, um Fehler im Kommunikationsablauf aufzuspüren und eigene
Anwendungen zu testen. Die Anzeige kann mittels tcpdump ähnlichen Filterfunktionen auf die gewünschten Informationen eingeschränkt werden.
Darüber hinaus existiert noch das OpenOBEX Projekt. Es war früher Teil des
Linux/IrDA-Projekts und wurde dann ausgegliedert. Es verfolgt das Ziel, eine API
und einige Dienstprogramme zur Unterstützung des OBEX Protokolls zur Verfügung
zu stellen.
Im Verlauf meiner Arbeit stellte sich jedoch heraus, daß diese Library nicht wie zuerst
angenommen für das mAuth-Demosystem verwendet werden konnte. Die implementierten Funktionen beschränkten sich auf die wichtigsten Standard OBEX Funktionen. Da
mAuth-OBEX Erweiterungen enthält, hätte ich Funktionen auf tieferen Level benötigt,
wie z.B. allgemeine Kommando- bzw Headerparser. Die Einarbeitung in den Code, um
evtl. Teile davon verwenden zu können, hätte einen ungleich größeren Aufwand bedeutet, als die geforderte Funktionalität selbst von Grund auf zu programmieren.
Die Dokumentation von Linux/IrDA beschränkt sich hauptsächlich auf die Installation
und Inbetriebnahme sowie der Gebrauchsanleitung der enthaltenen Dienstprogramme.
Brauchbare Informationen zur eigenen Programmentwicklung waren eigentlich nur der
entsprechenden Header Datei irda.h und den Sourcen einiger Beispielprogramme zu
entnehmen.
IrDA ist im Linux-Kernel als Netzwerktreiber implementiert. Die Programmierung erfolgt wie auch bei TCP/IP Verbindungen mittels dem Berkeley Socket Mechanismus.
Im Anfangsstadium meiner Arbeit installierte ich auf einem Rechner des LDV Labor Suse Linux 7.1. Nach der Konfiguration der darin enthaltenen Linux-IrDAUnterstützung und mit Hilfe des selbstgebauten Infrarot-Transceiver Moduls entstanden einige einfache Programme zur Einarbeitung in diese Technologie. Damit war es
125
u.A. möglich, eine Verbindung zu einem OBEX fähigen Mobiltelefon herzustellen.
#include
#include
#include
#include
#include
#include
#include
#include
<stdlib.h>
<fcntl.h>
<sys/stat.h>
<string.h>
<unistd.h>
<netinet/in.h>
"linux/irda.h"
<sys/socket.h>
#define AF_IRDA 23
void main() {
struct
struct
int
int
sockaddr_irda ladr = {AF_IRDA, LSAP_ANY,0,"OBEX"};
sockaddr_irda padr;
padrlen=sizeof(struct sockaddr_irda);
socket1, s2;
while(1) {
socket1 = socket(AF_IRDA, SOCK_STREAM, 0);
if (socket1 < 0) {
close(socket1);
exit(-1);
}
else {printf ("socket created ! \n");}
if (bind(socket1, (struct sockaddr *)&ladr,sizeof(struct sockaddr_irda))<0) {
close(socket1);
exit(-1);
}
if(listen(socket1,1)<0) {
close(socket1);
exit(-1);
}
s2=accept(socket1, (struct sockaddr *)&padr,&padrlen);
printf ("connected !! \n");
}
}
Dieser einfache Programmcode meldet connected !!“, sobald ein OBEX konformes
”
Gerät versucht, etwas zu übertragen. Dies entspricht noch keinem OBEX Connect, sondern nur einem gelungenen Verbindungsaufbau bis zur TinyTP Schicht. Ein korrekt
implementiertes OBEX Gerät wird somit hier auch einen fehlgeschlagenen Verbindungsaufbau melden.
Bei weiteren Versuchen habe ich dabei jedoch herausgefunden, daß einige Geräte die
OBEX Response-Codes nicht immer korrekt auswerten. Das Siemens S25 Mobiltelefon
126
führt z.B. eine Übertragung einer vCard vollkommen unabhängig von den empfangenen
Response-Codes durch. Solange es überhaupt irgendeine Response empfängt, fährt es
mit der Übertragung fort.
3.4
3.4.1
Die Pluggable Authentification Modules - PAM
Allgemeines
Die zunehmende Vernetzung unterschiedlicher Computersystemen zu großen, offenen
und heterogenen Netzen macht immer anspruchsvollere Authentifizierungsmechanismen notwendig. Die Einführung einer neuen Authentifizierungstechnologie, wie z.B.
Einmal-Paßwörter oder Chipkarten, bedingt jedoch jedesmal die Anpassung und NeuÜbersetzung aller Programme, welche eine Nutzerauthentifikation fordern.
Weiterhin ist es oft gewollt, daß verschiedene Dienste unterschiedliche Authentifikationsmechanismen nutzen, z.B. könnte es sinnvoll sein, daß das login Programm Nutzer
nach der lokalen /etc/passwd Datei, dagegen das ftpd Programm die Nutzer über
eine SQL Datenbank authentifizieren soll.
Um diesen unterschiedlichen Anforderungen flexibel gerecht zu werden, und dennoch
eine einfache und überschaubare Konfiguration des Gesamtsystems zu ermöglichen,
begann SUN Microsystems im Jahre 1995 ein Authentifizierungsystem zu entwickeln,
das den Authentifikationsprozeß von den ihn fordernden Anwendungen abtrennt. Aus
dieser Anstrengung heraus entstand das Pluggable Authentification Modules“ System
”
oder kurz PAM.
PAM lagert die Authentifizierung in Bibliotheken aus, das aufrufende Programm
erfährt davon lediglich, ob der Zugang gewährt oder abgelehnt wurde. Die Art und
Weise, wie die Authentifizierung geschieht, ist der PAM Bibliothek und ihren Modulen
überlassen. Ein PAM-System besteht aus den Komponenten:
• PAM Library: Dies ist die zentrale Bibliothek. Ihre Funktionen werden von
den PAM Anwendungen aufgerufen. Sie liest das Konfigurationsfile und leitet
den eigentlichen Authentifikationsprozeß, gemäß den dort festgelegten Regeln, an
das entsprechende Modul weiter. Gegen diese Library müssen alle Anwendungen,
welche PAM nutzen wollen, gelinkt werden.
• PAM Module: Sie implementieren die unterschiedlichen Authentifikationsmethoden.
• PAM Konfiguration: Hierin ist festgelegt, welche PAM Module für eine bestimmte Anwendung in welcher Reihenfolge durchlaufen werden müssen.
• PAM konforme Anwendungen: Dies sind alle Anwendungen, deren Nutzung
einer Authentifizierung bedarf. Sie führen jedoch den Authentifikationsprozeß
3.4. DIE PLUGGABLE AUTHENTIFICATION MODULES - PAM
127
Anwendung
Anwendung
login
login
xdm
xdm
su
su
ftpd
ftpd
PAMPAMBibliothek
Bibliothek
Konfigurationsdatei
Konfigurationsdatei
/etc/pam.d/login:
/etc/pam.d/login:
auth
auth requisite
requisite
auth
auth required
required
......
pam_unix.so
pam_unix.so
pam_env.so
pam_env.so
/etc/pam.d/xdm
/etc/pam.d/xdm
/etc/pam.d/su
/etc/pam.d/su
/etc/pam.d/ftpd
/etc/pam.d/ftpd
......
PAM-Module
PAM-Module
Konfigurationsdateien
Konfigurationsdateiender
derModule
Module
pam_unix.do
pam_unix.do
pam_env.so
pam_env.so
/etc/securetty
/etc/securetty
/etc/security/pam_env.conf
/etc/security/pam_env.conf
......
......
Abbildung 3.5: Bestandteile eines PAM Systems (Quelle [odi00])
nicht mehr selbst aus, sondern enthalten entsprechende Aufrufe an die PAM Library, und gegen welche sie gelinkt sind. Das Authentifikationsverhalten jedes
Programms, das derartig konzipiert wurde, kann zentral über die PAM Konfiguration verwaltet werden.
Soll mit diesem System eine neue Form der Authentifikation realisiert werden, z.B.
eine biometrische Methode wie die Fingerabruckerkennung, muß nur ein entsprechendes
PAM Modul entwickelt werden, das diesen Vorgang durchführen kann. Alle auf PAM
vorbereiteten Programme können dann sofort, ohne Änderung der Anwendungen selbst,
diese Methode nutzen.
Der Zeit existieren PAM Implementierungen für folgende Systeme:
• SUN Solaris ab Version 2.6
• HPUX ab Version 11
• Annähernd alle aktuellen Linux-Distributionen
• Free BSD ab Version 3.1
Darüber hinaus existieren Bemühungen PAM auch auf weitere Systeme zu portieren.
3.4.2
PAM Konfiguration
Zur Konfiguration der PAM Bibliothek existieren zwei verschiedene Ansätze. Je nach
PAM Implementierung kann die Konfiguration über eine Datei, welche meist unter
128
/etc/pam.conf abgelegt ist, oder über einen Satz von Dateien in einem meist als
/etc/pam.d/ bezeichneten Verzeichnis erfolgen.
Die erste Variante wird hauptsächlich von der SUN PAM Implementierung genutzt.
Hier sind die Parameter für jede PAM Anwendung enthalten. Daher beginnt jede Zeile
dieser Datei mit dem Namen der Anwendung, auf die sie sich die jeweilige Anweisung
bezieht.
Die zweite Variante verwendet für jede PAM Anwendung eine eigene Datei, die den
Namen der jeweiligen Anwendung trägt. Die meisten Linux-Distributionen verwenden
diese Methode. Der Aufbau der Konfigurationsdateien ist, bis auf das Fehlen der ersten
Spalte mit dem Namen des betreffenden Dienstes, welche hier überflüssig ist, mit dem
Aufbau der /etc/pam.conf Datei identisch.
Diese Datei(en) sind gemäß folgendem Format aufgebaut:
#(service-name)
#
# z.B.
modul-type
control-flag
module-path
arguments
login
login
login
auth
auth
account
requisite
required
required
pam_unix.so
nullok
pam_securetty.so
pam_unix.so
login
login
password
session
required
required
pam_unix.so
pam_limits.so
nullok
Zu einem Dienst sind meist mehrere PAM Modul-Einträge vorhanden. Diese werden der
Reihe nach abgearbeitet. So kann z.B. ein Modul eine Username/Paßwort-Überprüfung
durchführen, das nächste lokale Sicherheitsoptionen überprüfen, und ein anderes benutzerspezifische Einstellungen vornehmen.
• service-name: Dieser Eintrag ist nur bei Verwendung einer zentralen Konfigurationsdatei vorhanden. Er spezifiziert, auf welchen Dienst sich der folgende
Eintrag bezieht. Der service-name“ ist fest im Programmcode der betreffenden
”
Anwendung einkodiert und stimmt meist, jedoch nicht zwangsläufig, mit deren
Namen überein.
• modul-type: PAM kennt derzeit 4 verschiedene Modul-Typen. Dieser Eintrag
bestimmt, in welcher Phase des Authentifikationsprozeß das betreffende Modul
zum Einsatz kommt. Es wird zwischen folgenden Phasen und somit Modul-Typen
unterschieden:
– auth: Ein Authentifizierungsmodul überprüft die Identität eines Benutzers. Die klassische Methode ist die Abfrage eines Benutzernamens und
Passworts.
– account: Accounting-Module beschränken den Zugang ohne einen Authentifikationsvorgang, z.B. anhand bestimmter Tageszeiten oder auf spezielle
3.4. DIE PLUGGABLE AUTHENTIFICATION MODULES - PAM
129
Terminals.
– session: Module dieses Typs erledigen Logging-Aufgaben und können benutzerspezifische Aktionen vor und nach dem Einloggen ausführen, wie z.B.
das mounten“ von Verzeichnissen o.Ä.
”
– password: Um das jeweilige Authentifizierungs-Token wie z.B. ein Passwort
zu ändern, werden Module diese Typs aufgerufen.
Ein PAM Modul kann dabei mehrere dieser Funktionstypen beinhalten.
• control-flag: Wie bereits erwähnt werden alle PAM Modul-Einträge in einer Konfigurationsdatei zu einem Service der Reihe nach abgearbeitet. Die
controll-flags legen fest, was passiert. wenn eines der Module keinen Erfolg zurück
liefert.
– required: Ein Modul, welches mit diesem flag“ gekennzeichnet ist, muß
”
erfolgreich durchlaufen werden. Bei einem Fehlschlag werden jedoch noch
weitere evtl. vorhandene Module abgearbeitet, bevor die aufrufende Applikation über die mißglückte Authentifizierung unterrichtet wird.
– requisite: Ist die Ausführung eines derartigen Moduls nicht erfolgreich,
wird sofort eine mißglückte Authentifizierung gemeldet und die Abarbeitung
weiterer Module abgebrochen!
– sufficient: Falls zuvor kein als required markiertes Modul fehlgeschlagen ist,
führt die erfolgreiche Ausführung eines Moduls mit dem control-flag sufficient sofort zu einer positiven Authentifikation und Rückkehr zur aufrufenden Anwendung. Falls ein solches Modul fehlschlägt, hat das keine weiteren
Auswirkungen, und die Liste der Module wird weiter abgearbeitet.
– optional: Wie der Name bereits andeutet, wird ein solches Modul zwar
ausgeführt, sein Ausgang spielt jedoch keine Rolle für den an die Anwendung
zurückgelieferten Status.
• module-path: Hiermit wird der genaue Ort des betreffenden Moduls im Filesystem spezifiziert. Falls das Modul im Standard Verzeichnis /lib/security/
liegt, reicht die Angabe des Modul-Namens, ansonsten muß hier der komplette
Pfad stehen.
• arguments: Die Liste der hier angegebenen Argumente werden an das entsprechende Modul übergeben. Die Argumente sind damit modulspezifisch und können
auch komplett fehlen.
Tiefergehende Informationen sind [Mor99] zu entnehmen.
130
3.4.3
Anforderungen an ein PAM Modul
Aufgrund der Verbreitung in aktuellen Linux-Distributionen und der großen Flexibilität des PAM-Systems entschied ich mich, die PoA-Server-Funktionalität vom Typ
Rechnerzugang“ des mAuth Demosystems in Form eins PAM-Moduls zu verwirkli”
chen.
Ein PAM Modul ist eine ausführbare binäre Datei, die von der PAM Bibliothek geladen
werden kann. Sie ist in der Regel als dynamisch ladbare Objektdatei ausgeführt, kann
unter besonderen Umständen aber auch statisch zur PAM Bibliothek gelinkt sein.
Die PAM Bibliothek erwartet von einem Modul die Implementierung 6 verschiedener
Funktionen. Diese Funktionen können in 4 Gruppen eingeteilt werden, welche die Funktionalität der 4 verschiedenen Modultypen widerspiegeln. Ein korrekt implementiertes
PAM-Modul sollte mindestens alle Funktionen einer Gruppe enthalten.
• auth
PAM_EXTERN int pam_sm_authenticate( pam_handle_t *pamh, int flags, \
int argc, const char **argv )
Diese Funktion führt den Authentifikationsprozeß durch. Jeder andere Rückgabewert außer PAM SUCCESS bedeutet einen Fehlschlag der Authentifikation.
PAM_EXTERN int pam_sm_setcred( pam_handle_t *pamh, int flags, \
Verfügt das Authentifikationsmodul über weitere Informationen über den User
als nur das Authentifikations-Token selbst, so kann es diese Informationen mit
dieser Funktion der aufrufenden Anwendung verfügbar machen.
• account
PAM_EXTERN int pam_sm_acct_mgmt( pam_handle_t *pamh, int flags, \
Diese Funktion wird gewöhnlich nach erfolgreicher Ausführung der Authentifikation aufgerufen, und prüft weitere Zugangskriterien wie z.B. der Uhrzeit oder
abgelaufenen Passwörtern.
• session
Diese beiden Funktionen können dazu genutzt werden, Logfile-Einträge über die
Systembenuzung zu schreiben oder benutzerspezifische Aktionen auszuführen.
PAM_EXTERN int pam_sm_open_session( pam_handle_t *pamh, int flags, \
Wird zu Beginn einer Sitzung aufgerufen.
3.5. GIESECKE UND DEVRIENT SM@RTCAFÉ JAVACARD
131
PAM_EXTERN int pam_sm_close_session( pam_handle_t *pamh, int flags, \
Wird bei Beendigung einer Sitzung aufgerufen.
• passwd
PAM_EXTERN int pam_sm_chauthtok( pam_handle_t *pamh, int flags, \
Aufgabe dieser Funktion ist es, ein Authentifizierungs-Token wie z.B. ein
Passwort zu ändern.
Dabei ist zu beachten, daß die Funktionen der einzelnen Gruppen voneinander unabhängig sein sollen.
Ein Modul kann über verschiedene Funktionsaufrufe mit der PAM Bibliothek kommunizieren. Die einzige in meinem Demonstrationssystem zu diesem Zweck genutzte
Funktion ist
extern int pam_set_item(pam_handle_t *pamh, int item_type, const void *item)
Mit PAM USER als item type wirde damit der Benutzername, welcher hier nicht vom
Anwender eingegeben werden soll, sondern aus der Zugangsdatenbank ausgelesen wird,
der PAM Bibliothek und damit wiederum der Anwendung mitgeteilt.
Es besteht darüberhinaus auch ein Kommunikationsmechanismus direkt zur aufrufenden Anwendung. Dessen Benutzung sollte aber soweit als möglich vermieden, und wenn
überhaupt, dann nur mit äußerster Umsicht eingesetzt werden.
Eine detailierte Beschreibung und Einführung in die PAM Module Programmierung
ist in [Mor01] zu finden.
3.5
3.5.1
Giesecke und Devrient Sm@rtcafé Javacard
Allgemeines
Die Sm@rtcafé Chipkarte des Herstellers Giesecke und Devrient ist eine zum Javacard
2.1 Standard [jc-99c] und [jc-99b] der Firma SUN konforme Realisierung einer in Java
programmierbaren Chipkarte. Ein großer Vorteil von Javacards ist die (theoretische)
Verwendbarkeit des Anwendungscodes auf alle diesem Standard entsprechenden Smartcards, auch wenn diese von verschiedenen Herstellern stammen. Bisher gebräuchliche
Chipkarten besaßen alle eigene proprietäre Programmierinterfaces.
Während bei anderen Chipkarten die Anwendung in der Regel bereits in der
Produktions- bzw. Ausstellungsphase auf die Karte aufgebracht wird, und die Karte
damit abgeschlossen ist“, erlauben Javacards die Installation weiterer Applikationen
”
auch zu einem Zeitpunkt, in welchem sich die Karte bereits in Benutzung befindet.
132
Die Daten der einzelnen Applikationen sind durch ein striktes Firewallkonzept voneinander getrennt. Somit ist bei umsichtiger Programmierung die Sicherheit und Integrität
der Anwendungsdaten gewährleistet. Keine Applikation kann auf die Daten der Anderen zugreifen, es sei denn, diese erlaubt dies explizit.
3.5.2
Javacard Applikationen
Die Javacard Applikationen können in jeder gewohnten Java Entwicklungsumgebung
entwickelt werden. Die Javacard API [jc-99b] besteht aus den Klassen der Packages:
• java.lang: Dies ist eine Untergruppe der normalen“ Java-Sprache und enthält
”
alle grundlegenden Funktionen der Javacard Technologie.
• javacard.framework: Hierin sind die Kernfunktionen zur Programmierung eines Javacard Applets zusammengefaßt.
• javacard.security: Dies ist das Package aller sicherheitsrelevanter Operationen.
Darin sind Verschlüsselungs- und Signieralgorithmen ebenso wie Funktionen zur
Schlüsselverwaltung und zur Erzeugung von Zufallszahlen enthalten.
• javacard.crypto: Ist ein abstraktes Interface zur Implementierung von kryptographischen Algorithmen.
Diese Klassen müssen im Klassenpfad des Java Compilers, welcher zum Übersetzten
der Chipkarten Anwendung verwendet wird, liegen, oder explizit mit dem -classpath
Argument angegeben werden. Die Kryptofunktionen und einige spezielle auf diesen
Kartentyp bezogene Funktionen sind bei der Sm@rtcafé Karte, abweichend vom Javacard 2.1 Standard, in den Packages
• com.gieseckedevrient.javacard.framework
• com.gieseckedevrient.javacardx.crypto
• com.gieseckedevrient.javacardx.cryptox
definiert.
Zum Übersetzen von Sm@tcafé Applets sollte ein Java SDK mit Version 1.1.7 oder
neuer eingesetzt werden.
Wie auch Abbildung 3.6 zu entnehmen ist, müssen die vom Compiler erzeugten .classDateien erst noch in das .cap-Format umgewandelt werden, bevor sie auf der Karte
installiert werden können. Dies, sowie auch die Installation auf der Karte, geschieht
mit der Sm@rtcafé Entwicklungsumgebung Sm@rtcafé Professional (vergleiche Abschnitt 3.5.4).
Die Abkürzung CAP steht für converted Applet. Jede Javacard-Anwendung wird als
Applet bezeichnet. Sie kann aus einer oder mehreren Klassen bestehen. Eine CAP
Datei enthält alle Klassen eines packages, jedoch maximal eine applet class. Der CAP
133
Abbildung 3.6: Schritte der Javacard Anwendungs-Erstellung (Quelle [jc-99a])
File-Converter wandelt den Standard Java Bytecode in einen Javacard Bytecode um,
überprüft die Einhaltung der Javacard Richtlinien und pre-linkt“ alle Elemente der
”
Eingabedateien eines Packages.
Bei der Entwicklung von Javacard Applets sind im Vergleich zum Standard Java einige
Einschränkungen der Javacard Virtual Machine zu beachten. Die Wichtigsten davon
sind:
• Keine Garbage collection !
• Keine komplexen Datentypen wie int, long oder double !
• Keine Threads !
• Nur eindimensionale Arrays !
• 16 Bit System, mit 16 Bit Stack Size
• Nur 64 KByte Speicherplatz je Package
• Anzahl der Instanzen und Felder einer Klasse beschränkt !
• Ein Array kann maximal 32767 Felder besitzen !
• Der Stack kann maximal 127 Feldelemente aufnehmen !
• Eine switch-Anweisung kann maximal 655767 Fälle unterscheiden !
134
3.5.3
Leistungsmerkmale der Sm@rtcafé Karte
Die Giesecke & Devrient Sm@rtcafé Javacard ist derzeit auf Basis eines EinchipMikrocomputers der Familie Siemens SLE66 mit 1280 Byte RAM, 32 KByte ROM
und 8 bis 16 KByte EEPROM mit einer Taktfrequenz von maximal 7,5 MHz realisiert.
Folgende kryptographische Funktionen sind darauf implementiert:
• DES / 3DES
• SHA-1 Hash-Bildung
• Session Key Services
• RSA 1024 Bit
• Signature gemäß ISO/IEC 14888-3
• Zufallszahlengenerator
Um den RSA Algorithmus direkt ansprechen zu können, konnte ich jedoch keine geeigneten Methoden in der API finden. Die Dokumentation dazu ist in der derzeitigen
Version sehr dürftig und bestimmte Teile sind gänzlich undokumentiert. Offenbar wird
der RSA Algorithmus im Moment nur zur digitalen Signatur genutzt, zu welcher gut
dokumentierte Methoden existieren.
Für mein Demonstrationsystems ist jedoch ein direktes Ansprechen der Ver- und Entschlüsselungsfunktionen notwendig. Deshalb entschied ich mich, den 3DES Algorithmus zu verwenden. Für das Demonstrationsystem sind die mit der Verwendung eines
symmetrischen Algorithmus verbundenen Sicherheitsrisiken und Einschränkungen vertretbar.
3.5.4
Die Sm@rtcafé Entwicklungsumgebung
Die Funktionalität der Sm@rtcafé Entwicklungsumgebung reicht über das Erzeugen
der .cap-Dateien und dem Upload auf die Karte hinaus. Als Eingabe für ein neues
Projekt dienen sowohl die .java Quelldateien als auch die zugehörigen bereits übersetzen
.class-Dateien. In unterschiedlichen Fenstern kann der Bytecode und der Sourcecode
inspiziert werden.
Die Entwicklungsumgebung kann eine Sm@rtcafé Karte komplett simulieren, so daß
für erste Tests weder ein Kartenterminal noch eine reale Javacard notwendig ist. Zum
Debuggen einer Anwendung kann sie im Einzelschrittmodus ausgeführt werden. Weitere
Debug-Mechanismen, wie z.B. das Setzen von Breakpoints, sind ebenfalls möglich. In
weiteren Fenstern werden Heap- und Stack-Inhalt während der Anwendungsausführung
dargestellt.
135
Abbildung 3.7: Die Sm@artcaf’e Entwicklungsoberfläche
Ein sehr nützlicher Mechanismus ist der APDU-Skript-Editor. Damit ist es möglich,
eine Reihe von APDUs mit frei definierbaren Parametern und Daten zusammenzustellen, und diese auf Wunsch an die Karte zu senden. Die Antwort der Karte wird in
einem eigenen Fenster dargestellt. Diese Funktionalität stellte sich als äußerst hilfreich
zum Testen der korrekten Funktion der Chipkarten-Anwendung heraus.
Auch die Kommandos zum Installieren und Selektieren eines Applets (vergleiche Abschnitt 3.5.5) werden mit dem Skripteditor ausgelöst.
Leider ist diese Entwicklungsumgebung derzeit nur für Windows erhältlich. Fast die
gesamte Entwicklung des mAuth Demo-Systems erfolgte unter Linux. Nur zum konvertieren der .class-Dateien in das .cap-Format und zum komfortablen Testen des Javacard
Applets war die Windows-Plattform notwendig. Zur Installation der .cap-Files existieren auch Tools unter Unix.
3.5.5
Das Main Loader Konzept
Der Main Loader ist die default Applikation, welche nach einem Kartenreset automatisch selektiert, und damit aktiviert wird. Obwohl er sich prinzipiell wie ein normales
136
Applet verhält, nimmt er eine Sonderstellung ein. Der Main Loader verwaltet und
kontrolliert das Laden neuer Applikationen auf die Karte.
Die Bedingung für die Ausführung der sicherheitsrelevanten Kommandos läßt sich für
jedes Kommando einzeln definieren. Folgende Bedingungen sind möglich:
• niemals
• immer
• nur nach korrekter PIN Eingabe
Abbildung 3.8: Eingliederung des Main Loaders in die Javacard Struktur (Quelle
[jc-99d])
Die PIN Abfrage ist der einzige Authentifikations-Mechanismus, den der Main Loader dafür unterstützt. Es existiert dazu nur eine PIN. Nach deren korrekter Eingabe
dürfen alle Kommandos, die mit der Bedingung nur nach korrekter PIN Eingabe“
”
markiert wurden, ausgeführt werden.
Für das Laden neuer Applikation lassen sich zusätzliche Schutzmechanismen aktivieren.
Es können 4 verschiedene Sicherheitsstufen definiert werden:
• no security check:
• signature check:
• decrypt method:
• signature check + decrypt method:
An eine .cap-Datei kann eine Signatur angehängt werden, um Manipulationen zwischen der Fertigstellung der Applikation und Installation auf der Karte zu erkennen.
Ist der Main Loader so konfiguriert, daß er den Signature Check fordert, können nur
Applikationen mit gültiger Signatur auf die Karte übertragen werden.
3.6. CHIPKARTEN-LESEGERÄT TOWITOKO CHIPDRIVE MICRO 100
137
Eine weitere Erhöhung der Sicherheit bietet das Verschlüsseln der gesamten .cap-Datei.
Ist dies vom Main Loader gefordert, können nur verschlüsselte Dateien geladen werden,
welche von der Karte dann in ihre ursprüngliche Form dekodiert werden. Diese Option
ist auch zusammen mit der Signaturüberprüfung möglich.
Die für diese Operationen benötigten Schlüssel werden in der Erstellungsphase des
Main Loaders gesetzt.
Ein MainLoader wird zwar nicht wie ein normales Applet auf die Karte geladen, denoch besitzt eine fabrikneue Karte noch keinen funktionsfähigen Main Loader. Er muß
erst mit dem Kommando CREATE ML erzeugt und konfiguriert werden. In dieser Phase
werden die beschriebenen Sicherheitsanforderungen definiert und - falls benötigt - die
kryptographischen Schlüssel gesetzt.
Ein existierender Main Loader kann auch wieder gelöscht werden. Das ist nur möglich,
wenn sich kein anderes Applet mehr im EEPROM befindet, und die notwendige Sicherheitsstufe zur Ausführung des Löschkommandos erfüllt ist. Nur auf diesem Wege
ist es möglich, einmal definierte Sicherheitsoptionen zu ändern.
Mit den Sicherheitsmechanismen des Sm@rtcafé Main Loaders lassen sich die im Konzept des mAuth-Systems vorgeschlagenen Sicherheitsanforderungen zur Installation anwendungsspezifischer Chipkarten Applikationen neben der mAuth default Anwendung
in ausreichendem Maße realisieren.
Nach einem erfolgreichen Ladevorgang ist das Applet noch nicht aktiv. Erst durch
Aufruf des INSTALL Kommandos wird der Installationsprozeß abgeschlossen, und die
Anwendung kann mittels SELECT ausgewählt und benutzt werden. Der Main Loader
Befehl INSTALL ruft die install()-Methode des Applets auf. Er erzeugt eine Instanz des
Applets, legt die notwendige Objekte an und reserviert benötigten Speicher. Bei Aufruf
der install() Methode muß ein korrektes Applet auch die Methode register() aufrufen,
welche die Anwendung erst richtig aktiviert und anhand seiner AID selektierbar macht.
3.6
Chipkarten-Lesegerät Towitoko Chipdrive micro 100
Da es zum Entstehungszeitpunkt dieser Arbeit keinen PDA mit integriertem
Chipkarten-Lesegerät auf dem Markt gab, war es notwendig, ein externes Gerät zu verwenden. Die wichtigsten Anforderungen an ein geeignetes Lesegerät waren kompakte
Abmessungen und eine möglichst große Marktverbreitung, was die Wahrscheinlichkeit der Unterstützung durch eine verfügbare Chipkarten Programmier-Library
erhöhte.
Beide Bedingungen werden von den Geräten der Firma Towitoko erfüllt. Die Produktreihe Chipdrive micro war aufgrund ihrer kleinen Bauweise die bevorzugte Wahl.
138
Alle diese Chipkartenterminals sind zum Anschluß an einen Personal Computer mit
RS-232-Schnittstelle ausgelegt. Da die RS-232-Schnittstelle jedoch keine explizite Versorgungsspannung zur Verfügung stellt, muß das Terminal und die Karte auf anderen
Wegen mit Spannung versorgt werden. Die drei Modelle der Chipdrive micro Familie unterscheiden sich hauptsächlich in der Art und Weise, wie dieses Problem gelöst
wurde.
Das Chipdrive micro 100 und 110 beziehen ihre Versorgungsspannung über einen separarten Anschluß an den PS/2 Port des PC. Das Modell 110 ermöglicht zudem die
gemeinsame Nutzung des RS-232-Ports mit einer seriellen Maus.
Das Modell 120 benötigt außer der seriellen Schnittstelle keinen weiteren Anschluß.
Hier ist das Problem der Spannungsversorgung mit einem integrierten Akku gelöst,
welcher über die Signalleitungen der RS-232-Schnittstelle gespeist wird, und höheren
Strombedarf abpuffern“ kann.
”
Alle drei Kartenterminal unterstützen die Kommunikationsprotokolle T=0, T=1,
2-Wire, 3-Wire, I2C sowie Protokolle von über 40 verschiedenen Memorycards.
Für meine Arbeit verwendete ich das Modell Chipdrive micro 100, welches von einem
großen Elektronik Versandhaus sehr günstig unter der Bezeichnung chipdrive micro fun
vertrieben wird. Das Problem der Spannungsversorgung mußte an einem PDA ohnehin
anderweitig gelöst werden (vergleiche dazu Abschnitt 3.11), und die anderen beiden
Modelle hatten für diese Zwecke keine weiteren Vorteile zu bieten.
Laut Datenblatt ist das Chipdrive 100 auf eine fixe Datenrate von 13000 Baud beschränkt. In meinen Versuchen arbeitet es jedoch auch mit 9600 Baud problemlos.
Daneben stand mir noch ein Chipdrive extern zur Verfügung. Dies ist eine größere und
stabilere Bauform der Chipdrive Gerätereihe. Es diente mir hauptsächlich zum Zugriff
mit dem PalmOS-Emulator (siehe auch Abschnitt 3.10) auf die Chipkarte. Das Gerät
war daher fest an einen Desktop PC angeschlossen. Auch das Installieren und Testen der
Chipkartenapplikationen mittels der Sm@rtcafé Professional Entwicklungsumgebung
wurde damit durchgeführt.
3.7
3.7.1
PalmOS-PDAs
Entwicklungsgeschichte
Die Entwicklung des ersten Palm PDAs geht auf Jeff Hawkins zurück. Seine Idee war
es, bereits lange vor der Markteinführung des ersten Palm Pilot im April 1996, einen
etwa Hemdtaschen großen Computer zu entwickeln. Dieses Gerät sollte als Ergänzung
zum heimischen PC auch unterwegs Papier überflüssig machen und die digitalen Daten
einfach mit dem Computer zuhause oder im Büro abgleichen können.
3.7. PALMOS-PDAS
139
Abbildung 3.9: Der Handspring Visor Platinum
Was die Palm PDAs auch heute noch von Konkurrenzgeräten abhebt ist das Programm Graffiti. Es dient der Erkennung handschriftlicher Eingaben. Sein Ziel war
es nicht, möglichst sicher viele verschiedene natürliche“ Handschriften, sondern eine
”
leicht erlernbare, der Handschrift nachempfundene, jedoch standardisierte Musterfolge
zu erkennen. Dies gründete auf der Erkenntnis der Entwickler:
Menschen sind klüger als Maschinen. Sie können lernen. Menschen können
”
lernen, mit Werkzeugen umzugehen. Computer sind Werkzeuge.“
Damit ist es möglich, schnell und sicher handschriftliche Eingaben zu erkennen, ohne
dabei enorme Anforderungen an die Rechenleistung zu stellen.
Der erste Palm Pilot war gerade mal mit 256 KByte Speicher ausgestattet und nutzte
als Betriebsystem PalmOS 1.0. Als Display besaß er ein monochromes 160x160 Pixel
großes LCD Panel. Palm PDAs besitzen keine Festplatte als Speichermedium, sondern
benutzen das im Gerät eingebaute RAM als Massenspeicher“-Medium.
”
Mittlerweile sind mehrere neue Generationen der Palm PDAs auf den Markt gekommen.
Aktuelle Geräte verfügen über 8 MB Speicher, schnellere Prozessoren, Farbdisplay,
IrDA und andere Erweiterungen.
Das Betriebsystem PalmOS liegt mittlerweile in der Version 4.0 vor. Obwohl neuere
Geräte mit schnelleren Prozessoren ausgestattet wurden, werden bis heute Prozessoren
der Motorola 68k Familie eingesetzt. Dies und die Abwärtskompatibilität des Betriebsystems sichert die Weiterverwendbarkeit alter Software.
Der Palm Pilot wurde ursprünglich von Jeff Hawkins Firma Palm Computing Inc.
entwickelt. Bevor der erste Pilot auf den Markt kam, wurde seine Fima von US Ro-
140
botics gekauft. Kurz darauf übernahm 3COM US Robotics. Der Palm wurde daher
unter mehreren verschiedenen Firmennamen vertrieben, bevor im Jahr 2000 Palm Inc.
als eigene Aktiengesellschaft gegründet wurde. Aus rechtlichen Gründen verwendet die
Firma Palm Inc. heute die Bezeichnung Pilot nicht mehr in ihren Produktnamen. Eine
ausführliche Darstellung der Entwicklungsgeschichte des Palm Pilots und den daran
beteiligten Personen ist in [Dil98] nachzulesen.
Auch wenn es mittlerweile viele Konkurrenzprodukte gibt, gilt der Palm Pilot immer
noch als Urvater der PDAs, und Palm ist noch immer Marktführer in diesem Segment.
Im Jahr 2000 lag der Marktanteil von PalmOS basierenden Geräten am PDA Markt
zwischen 80 und 90 %. Dies liegt nicht zuletzt an der großen Menge zum Teil auch frei
im Internet verfügbaren Software sowie zahlreichen Hardware-Zubehörteilen für diese
Plattform.
3.7.2
Unterschiede zwischen Handspring- und Palm-Modellen
Da die Ansichten über den Fortgang der Entwicklung der Palm Plattform zwischen
Jeff Hawkins, Donna Dubinski und Ed Colligan, den 3 Personen, die maßgeblich für die
Entwicklung und Markteinführung des Ur-Palm Pilots verantwortlich waren, einerseits,
und der Geschäftsleitung von Palm Computing Inc., das nunmehr unter der Kontrolle
von 3 COM stand, andererseits immer weiter auseinander drifteten, gründeten die
Urväter“ des Pilots 1998 mit Handspring Inc. ihre eigene Firma.
”
Handspring lizensierte die Verwendung von PalmOS für ihre Produkte. Ziel der Firmengründer war es, mit ihrer eigenen PDA Hardware die Ideen zu verwirklichen, zu
denen Ihnen bei Palm nicht die Möglichkeit gegeben wurde.
Ihre Geräte sind sowohl von den Abmessungen, den Bedienelementen und dem Display
den Modellen der Palm Serie sehr ähnlich. Die Handspring-Produkte unterscheiden sich
im wesentlichen durch folgende Punkte von den Palm PDAs:
• Erweiterungsslot für Springboardmodule
• USB Anschluß: zur Synchronisation mit dem PC
• Betriebsystem auf ROM: nicht updatebar !
• Kein vollwertiger RS-232-Port
• Schnellere Prozessoren
• Eingebautes Mikrofon
Die wichtigste Neuerung der Handspring-Modelle ist ihre Ausbaufähigkeit durch sogenannte Springboard Module. Springboard Module sind Hardware-Erweiterungen in
Form von kasettenartigen Einschüben mit etwas den Abmessungen 54 x 57 x 9 mm.
Das Interface zum Handspring-PDA entspricht von der physikalischen Ausführung einem PCMCIA Anschluß. Es hat jedoch eine dazu völlig unterschiedliche Belegung.
3.7. PALMOS-PDAS
141
Auf dieses Interface werden 24 Adressleitungen und 16 Datenleitungen sowie diverse
Status- und Steuersignale geführt. Auch die Versorgungsspannung für das Modul sowie
der Anschluß zum eingebauten Mikrofon sind in diesem Port enthalten. Die Speicheradressen der Module werden dabei direkt in den Adreßraum der CPU abgebildet. Mittels der 24 Adressleitungen und zweier Chip-Select Signale können auf einem Modul
maximal 32 MB Speicher adressiert werden.
Die Module können sowohl eigene Applikationen als auch zusätzliche Hardwarefunktionen enthalten. Das Konzept sieht dabei ein wirkliches Plug and Play vor, d.h. Module
können zu jedem beliebigen Zeitpunkt des Betriebs eingesetzt und entfernt werden.
Das Betriebssystem erkennt dies und reagiert entsprechend darauf.
Über dieses Interface wäre es auch denkbar, einen aufsteckbaren Chipkartenreader zu
realisieren. Leider gab es zum Entstehungszeitpunkt noch kein entsprechendes Modul.
Da die Eigenentwicklung eines Chipkartenmoduls den Rahmen der Diplomarbeit bei
weitem gesprengt hätte, entschloß ich mich zu einer anderen Variante, den PDA um
die Fähigkeit Chipkarten zu lesen zu erweitern (vergleiche Abschnitt 3.11).
Vor allem um diese Besonderheiten der Handspring-PDAs zu unterstützen, läuft auf
diesen Geräten ein angepasstes und etwas erweitertes PalmOS.
3.7.3
Der Handspring Visor Platinum
Der Handspring Visor Platinum war zum Zeitpunkt des Beginns dieser Arbeit das
leistungsstärkste Modell der Handspring-Produktfamilie.
Sein Kernstück ist die Motorola MC68VZ328 Dragonball-VZ CPU, die mit 33
MHz getaktet wird. So gut wie alle Peripherie-Controller, sogar der Controller zur
Ansteuerung des LCD Panels, sind in diesen Mikroprozessor integriert.
Der Visor Platinum besitzt 8 MB Hauptspeicher, der jedoch über entsprechende
Springboard Module bis auf 32 MB erweiterbar ist.
Zur Kommunikation mit externen Geräten ist eine IrDA kompatible Schnittstelle an
der linken Geräteseite vorhanden.
Im Gegensatz zu den neueren Modellen sind im Handspring Platinum weder Akkus
integriert, noch ist das Cradle mit einer Ladeelektronik ausgestattet.
Als Betriebssystem kommt ein angepaßtes PalmOS 3.5 zum Einsatz. Auf dem Handspring Platinum meldet es sich mit Version 3.5.2. Außer einigen Anpassungen an die
Hardware des Handspring sind auch noch einige im Vergleich zum Original PalmOS
erweiterte Anwendungsprogramme wie z.B. ein wissenschaftlicher Taschenrechner und
ein komfortablerer Kalender enthalten.
142
3.8
3.8.1
Programmentwicklung unter PalmOS
Allgemeines
Die Entwicklung von PalmOS-Applikationen erfordert im Vergleich zur Entwicklung
von Anwendungen für Desktop Betriebssysteme die Beachtung einiger Besonderheiten.
Zum einen sind die Ressourcen an Speicher und Rechenleistung sehr beschränkt. Zum
anderen hat ein PDA eine andere Aufgabenstellung als ein Desktop-System, und damit
verbunden haben PDA Anwendungen andere Ansprüche der Nutzer zu erfüllen. Es ist
vor allem darauf zu achten, daß die Anwendungen schnell starten und auch während
des Betriebs keine langen Wartezeiten dem Benutzer abfordern.
Die Benutzung eines PDAs erfolgt oft spontan, z.B. um sich Notizen zu machen oder
einen Termin nachzusehen. Die Anwendungen sind somit auf häufiges Öffnen und
Schließen auszulegen.
Dazu kommt daß sie einfach und selbsterklärend zu bedienen sein sollen. Ein PDA
soll ein intuitives Werkzeug sein und nicht das Studium langer Anleitungen erfordern.
Dies ist besonders beim Entwurf des User Interfaces zu beachten. Insbesondere die Art
und der Umfang der darzustellenden Information ist wegen des kleinen Displays genau
abzuwägen, um ein Überladen des Userinterface zu vermeiden. Dies kann z.B. durch
eine geschickte Aufteilung auf mehrere umschaltbare Darstellungen erfolgen.
3.8.2
Einschränkungen und Besonderheiten
PalmOS wurde speziell auf die Anforderungen des PDA Betriebs hin entwickelt und
optimiert. Die Entwickler versuchten das Betriebsystem so einfach und leichtgewichtig
wie möglich zu halten. Die wichtigsten Eigenschaften des PalmOS sind:
• Single Tasking
• Single Threaded
• Event Driven
Als Massenspeichermedium existiert weder eine integrierte Harddisk, noch ist ein externer Anschluß dafür vorgesehen. Palm PDAs verwenden zu diesem Zwecke nur das eingebaute RAM. Es existieren einige PalmOS kompatible Geräte, wie z.B. die HandspringGerätereihe, welche um externe RAM Speichermodule erweitert werden können.
Die Programmentwicklung für PalmOS erfolgt in der Regel in der Programmiersprache
C, obwohl auch andere Sprachen verfügbar sind (siehe Abschnitt 3.9.1).
Zu beachten ist hierbei, daß die ANSI Standard C Library Funktionen nicht verfügbar
sind. Einige dieser Funktionen sind zwar im GNU-Palm-Entwicklungspaket in Form
3.8. PROGRAMMENTWICKLUNG UNTER PALMOS
143
einer separaten Library vorhanden, jedoch sollten diese soweit möglich nur zu DebugZwecken eingesetzt werden, da ihre Verwendung den Programmcode vergrößert. Es
existiert auch eine GLib Shared Library Version der LibC, jedoch sollten bevorzugt die
PalmOS eigenen Systemfunktionen verwendet werden.
Für die meisten Zwecke besitzt das PalmOS eigene Funktionen, welche allerdings zur
Unterscheidung mit anderen Namen bezeichnet sind. Die Entsprechung der ANSI C
String Funktion strtoa ist bei PalmOS der Systemaufruf StrToA. So gibt es für viele
String Funktionen entsprechende Palm Betriebsystem Aufrufe. Ihre Verwendung vergrößert den Programmcode nicht, und sie sind sehr effizient auf die Palm Plattform
optimiert.
Von der vertrauten C Programmierung auf Desktop Plattformen ist hier eine gewisse
Umgewöhnung nötig. Während dort z.B. eine einfache Textausgabe mit der Funktion
printf("Text");
zu realisieren ist, erfordert dieselbe Ausgabe in einem Textfeld auf dem Palm-Display
wesentlich mehr Programmcode:
FormPtr
FieldPtr
Handle
CharPtr
frm
= FrmGetActiveForm();
fldhdl = FrmGetObjectPtr(frm, FrmGetObjectIndex(frm,fPIN));
txhdl = FldGetTextHandle(fldhdl);
FldSetTextHandle(fldhdl,NULL);
txtptr = MemHandleLock((VoidHand)txhdl);
memcpy(txtptr,"Text",4);
MemHandleUnlock((VoidHand)txhdl);
FldSetTextHandle(fldhdl,txhdl);
FldDrawField(fldhdl);
Die PalmOS-Funktionen sind in Gruppen gegliedert. Eine Gruppe ist jeweils für einen
bestimmten Aufgabenbereich zuständig und wird als Manager bezeichnet. Allen Funktionen eines Managers ist ein Kürzel der Manager-Bezeichnung vorangestellt. So existieren z.B. ein SerialManager und ein MemoryManager. Die Namen der darin enthaltenen Funktionen beginnen jeweils entsprechend mit Ser oder Mem, z.B. SerSend oder
MemHandleNew.
Um mich in diese und weitere Besonderheiten der Programmentwicklung auf der PalmPlattform einzuarbeiten, entstanden in der Anfangsphase der Diplomarbeit mehrere
kleine Programme.
Auch die im Vergleich zu Desktop-Systemen geringe Rechenleistung dieser Geräte ist
bei der Programmentwicklung zu berücksichtigen. Selbst aktuelle Modelle werden nur
mit Taktfrequenzen zwischen 20 und 33 MHz betrieben. Verbunden mit der Tatsache,
daß PDA Anwender nicht lange auf Reaktionen ihres Gerätes warten möchten, ist
genau zu bedenken wie, Rechenzeit intensive Vorgänge zu realisieren sind. So weit als
144
möglich sollen diese auf den Heim PC ausgelagert, und nur die Daten mittels der Palm
Hotsync-Funktionalität abgeglichen werden.
Die Synchronisation von Anwendungen mit dem Heim PC wird durch sogenannte Conduits realisiert. Für die Aufgabenstellung dieser Arbeit war diese Funktionalität jedoch
nicht notwendig. Eine gute Erklärung zur Conduit-Entwicklung sowie zu der PalmProgrammentwicklung insgesamt ist in [pal00], [Pog99] oder [Fos00] zu finden.
3.8.3
Speicherorganisation
Der Speicher der Palm Plattform ist auf sogenannten Cards enthalten. Derzeit existiert
davon nur eine Card0, in neueren Versionen kann sich dies jedoch ändern.
Je nachdem, ob es sich bei betreffenden Speicher um RAM oder ROM handelt, wird
zwischen RAM Storage und ROM Storage unterschieden.
Der Arbeitsspeicher ist dabei in dynamic RAM und storage RAM unterteilt. Das
dynamic RAM entspricht dabei dem Arbeitsspeicher eines Desktop PCs, während das
storage RAM als ein Analogon zu einer Festplatte gesehen werden kann.
Ältere PalmOS-Versionen unterteilten diese zwei Bereiche weiter in ein, oder mehrere 64 KByte große Speicher Blöcke, sogenannte Heaps auf. Seit der Version 3.0 des
Betriebsystems existiert diese 64 KByte Grenze nicht mehr, und das gesamte dynamic
RAM auf einer Karte entspricht einem Heap. Das gleiche gilt für das storage RAM,
das auch hier pro Card als ein Heap organisiert ist.
Die kleinste von einem Benutzer allozierbare Speichereinheit wird als Chunk bezeichnet. Ein Chunk ist ein zusammenhängender Speicherbereich innerhalb eines Heaps. Er
kann zwischen 1 und knapp unter 64 KByte groß sein.
Es existieren bewegliche und unbewegliche Chunks. Um die wertvolle Ressource
Arbeitsspeicher möglichst effizient zu nutzen, kann das PalmOS bewegliche Chunks
innerhalb eines Heaps frei verschieben, um eine Fragmentierung des Speichers zu verhindern.
Ob ein Chunk beweglich oder unbeweglich ist, bestimmt der Programmierer. Speicherbereiche, welche über einen Pointer adressiert werden sollen, sind unbeweglich. Einen
solchen Chunk erzeugt der Systemaufruf MemPtrNew.
Die MemoryManager Funktion MemHandleNew alloziert dagegen einen beweglichen
Chunk. Als Referenz wird hier kein Pointer, sondern ein Handle zurückgegeben.
Ein Handle ist eine Referenz auf einen Pointer. Die physikalische Adresse dieses Chunks
kann sich durch die automatische Defragmentierung ständig ändern. Das Handle verweist daher fest auf einen Eintrag in der master pointer table im Header eines Heaps,
in der die jeweils gültige reale Speicheradresse des Chunks vermerkt ist. Durch entsprechende MemoryManager Funktionen kann ein Handle gesperrt“, d.h. als nicht
”
145
beweglich markiert werden, und ist für die Dauer der Sperrung über einen Pointer
ansprechbar.
Soweit als möglich sollten nur Handles verwendet werden, da dies eine effiziente Nutzung des Speichers gewährleistet.
Zum Zugriff auf das storage Heap und dynamic Heap existieren jeweils unterschiedlich Betriebsystem-Manager. Dies trägt der unterschiedlichen Aufgabe dieser beiden
Bereiche Rechnung. Der dynamic Heap wird über die Funktionen des MemoryManager angesprochen, während der Zugriff auf das storage Heap vom DataManager
kontrolliert wird.
Der DataManager implementiert daher Funktionen, die eher mit dem Zugriff auf Dateien als mit Speicherzugriffen zu vergleichen sind. Dateien auf einem Desktop System entsprechen hier Databases. Eine Database besteht aus einer Liste von Speicher-Chunks
und einem Header. Im Header stehen neben anderen Information auch der Name der
Database. Ein Chunk als Bestandteil einer Database wird als Record bezeichnet.
Der DataManager bietet mehr Schutzfunktionen gegen unbeabsichtigtes Überschreiben bestimmter Bereiche als der MemoryManager. Wie von regulären Dateien gewohnt,
müssen Databases erst geöffnet werden, bevor sie bearbeitet werden können, und nach
Gebrauch wieder geschlossen. Dabei sind Zugriffsrechte definierbar.
Im storage Heap sind neben Daten auch die Anwendungsprogramme abgelegt. Anders
als bei Desktop Systemen werden die Programme jedoch an Ort und Stelle ausgeführt
und nicht zuerst in den Arbeitsspeicher kopiert. Es ist sinnvoll und empfehlenswert,
genauso auch mit Daten zu verfahren. Da es sich physikalisch auch beim storage Heap
um RAM handelt, ist die Erstellung einer Kopie zur Bearbeitung nicht notwendig.
Datenbearbeitung direkt an ihrem Speicherort ist allein schon dadurch sinnvoll, da die
Größe des dynamic Heap sehr beschränkt ist, und der Programmierer schnell an dessen
Grenzen stoßen kann. Das dynamic RAM teilen sich Betriebsystem, Libraries und
Anwendungen u.A. für temporäre Dateien, globale Variablen, dynamische Speicher
Zuweisungen und dem Anwendungs-Stack. Größe des dynamic heap ist von der Größe
des gesamten Arbeitspeichers des Gerätes und der Version des PalmOS abhängig.
Eine typische Aufteilung des dynamic Heap eines Palm PDAs mit 4MB RAM, TCP/IP
und IrDA Unterstützung unter PalmOS 3.5 ist:
gesamter dynamic Heap 256 KByte
System Globals
TCP/IP
übrig für Anwendung
bis PalmOS 3.0
40 KByte
32 KByte
184 KByte
Anwendungs-Stack statisch 4 KByte
Vor allem die geringe Größe des Anwendungs-Stacks kann schnell zum Problem werden.
In der Entwicklungsphase meiner Palm Anwendung war der Programmcode nach einer
146
eigentlich unwesentlich erscheinenden Änderung nicht mehr auszuführen und führte
zu Systemabstürzen. Nach einiger Fehlersuche führte ich das auf das Überlaufen des
Stacks zurück.
Mein Programm verwendete zu diesem Zeitpunkt viele globale Variablen und große
lokale Puffer in Funktionen. Nachdem sowohl die globalen Variablen als auch die Puffern
in dynamisch allozierte Strukturen verlagert und die lokalen Variablen auf ein Minimum
reduziert waren, trat dieses Problem nicht wieder auf.
Die Optimierung des Programmcode sollte daher immer als oberstes Ziel die optimale Nutzung des dynamic Heap haben, dann erst auf die Ausführgeschwindigkeit und
zuletzt auf die Größe hin erfolgen.
Im Hinblick auf eine sparsame Nutzung des dynamic Heaps sollten bei der Programmentwicklung folgende Punkte beachtet werden:
• Soweit als möglich Handels statt Pointer verwenden!
• Speicher Chunks allozieren, anstatt globale Variablen zu verwenden!
• Keine Dialogboxen stapeln! Besser zwischen verschiedenen Forms umschalten!
• Database Records immer an Ort und Stelle bearbeiten. Keine Kopien erstellen!
• Beachten, daß jede Library zusätzlich dynamischen Speicher beansprucht!
• Keine großen Strukturen (z.B. lokale Variablen) auf dem Stack ablegen!
• Rekursiven Funktionen mit Bedacht verwenden!
• Allgemein umsichtig mit dem dynamic Heap umgehen!
3.8.4
Ereignis gesteuerte Programmausführung
Das PalmOS ist ein ereignisgesteuertes, single tasking Betriebsystem. Sobald eine neue
Anwendung gestartet wird, wird die zuvor laufende beendet.
Der Rumpf einer typischen PalmOS-Anwendung besteht aus folgenden Funktionen:
• PilotMain
• StartApplication
• EventLoop
• StopApplication
Beim Start einer Anwendung wird dieser ein Launch Code mit übergeben. Dieser
Code gibt die Art und den Grund des Starts an. Eine Anwendung kann regulär durch
Eingabe des Benutzers gestartet werden, oder aber durch das Betriebsystem als Reaktion auf ein Ereignis wie z.B einem Alarm oder einem Hotsync-Vorgang.
147
Dieser LaunchCode wird der Funktion PilotMain als Argument übergeben. PilotMain
entspricht der main-Funktion eines ANSI C Programms und muß in jeder ausführbaren
Anwendung vorhanden sein. Ihre Hauptaufgabe ist es, den Launch Code zu überprüfen
und passend darauf zu reagieren. Handelt es sich um einen regulären Programmstart,
werden von ihr die übrigen Grundfunktionen aufgerufen.
AppLaunch
LaunchCode
PilotMain()
StartApplication()
SysHandleEvent()
Event
MenuHandleEvent()
EventLoop
ApplicationHandleEvent()
StopApplication()
Abbildung 3.10: Ablauf einer typischen PalmOS-Anwendung
StartApplication initialisiert die Anwendung. Hier können die benötigten Datenbanken und Libraries geöffnet oder Grundeinstellungen eingelesen werden. Zuletzt lädt
diese Funktion die erste FORM des User Interfaces.
EventLoop ist die Funktion, die während der gesamten Programmausführung wiederholt abgearbeitet wird. Tritt ein Ereignis, ein stellt das Betriebsystem dieses Event in
eine Warteschlange. Aufgabe der EventLoop ist es, der Reihe nach die Events aus dieser
Schlange zu entnehmen und zu verarbeiten. Die Funktion ApplicationHandleEvent
filtert dabei die für die Anwendung interessanten Ereignisse heraus, und führt entsprechende Aktionen aus. Die übrigen Events werden dem Betriebssystem zur Verarbeitung
weitergereicht.
Bevor eine Anwendung beendet wird, werden die Anweisungen in StopApplication
abgearbeitet. Ihre wichtigste Aufgabe ist es, geöffnete Dateien und Libraries wieder zu
schließen, sowie allozierten Speicher und genutzte Hardware freizugeben.
Folgender Programmcode zeigt die Realisierung dieses Grundgerüstes in der Programmiersprache C:
static Err StartApplication( void ) {
FrmGotoForm(MainForm);
148
}
static void StopApplication( void ) {
...
}
static Boolean MainFormHandleEvent(EventPtr event) {
...
}
static Boolean ApplicationHandleEvent(EventPtr event) {
FormPtr form;
if (event->eType == frmLoadEvent) {
form = FrmInitForm(event->data.frmLoad.formID);
FrmSetActiveForm(form);
switch (event->data.frmLoad.formID) {
case MainForm:
FrmSetEventHandler(form, MainFormHandleEvent);
break;
default:
break;
}
}
}
static void EventLoop(void) {
EventType event;
Word
error;
do {
EvtGetEvent(&event, evtWaitForever);
if (SysHandleEvent(&event))
continue;
if (MenuHandleEvent(CurrentMenu, &event, &error))
continue;
if (ApplicationHandleEvent(&event))
continue;
FrmDispatchEvent(&event);
}
while (event.eType != appStopEvent);
}
DWord PilotMain(Word launchCode, Ptr cmdBPB, Word launchFlags) {
StartApplication();
EventLoop();
StopApplication();
}
3.8.5
149
Das User Interface
Das User Interface einer Palm Anwendung besteht aus einer oder mehrerer FORMS.
Eine FORM ist eine Gruppierung von UI2 Elementen, die einem gemeinsamen Zweck
dienen. Sie ist vergleichbar mit einem Fenster eines Desktop Betriebsystems.
Die meisten Elemente einer FORM sind statisch vordefiniert. Bei Bedarf können jedoch
auch Veränderungen zur Laufzeit vorgenommen werden. Gebräuchliche UI Objekte
sind:
• Title
• Fields
• Buttons
• Menu
• Checkbox
• List
Zur Definition des User Interfaces existieren graphische und textbasierende Werkzeuge.
Die UI Elemente stellen in einer Palm Resource Database eine eigene RessourcenGruppe dar und werden in einem post-linking Prozeß“ zum Programmcode dazuge”
bunden.
3.8.6
Das PRC-Format
Palm Databases sind eindeutig durch die beiden 32 Bit Felder Type und CreatorID
in ihrem Header gekennzeichnet. Der Type appl“ bezeichnet dabei ein ausführbares
”
Programm. Derartige Databases werden im Gegensatz zu den Data Databases, welche
in der Regel Daten von Anwendungsprogrammen beherbergen, wie z.B. Adressen oder
Notizen, auch Resource Databases genannt.
Nur Resource Databases vom Typ appl werden im FileManger“ des Palm dargestellt,
”
und können ausgeführt werden. Daher ist ihr einziges Unterscheidungsmerkmal die
CreatorID, welche somit eindeutig sein muß. Um diese Eindeutigkeit zu gewährleisten,
bietet Palm Inc. den Entwicklern auf ihrer Webpage die Möglichkeit, für ihre Anwendung eine ID zu registrieren. CreatorIDs mit ausschließlich Kleinbuchstaben sind für
die Verwendung von Palm Inc. vorbehalten.
Resource Databases enthalten Bitmaps, Programmcode, UI Objekte, usw.. Eine
.prc-Datei ist die Abbildung dieser Struktur auf eine Datei eines Desktop Computersystems. Dieses Format wird bei der Erstellung eines Programms erzeugt und kann
2
User Interface
150
dann z.B. mittels eines Hotsync Vorgangs vom Entwicklungs-PC auf den Palm übertragen werden.
Der vom gcc Compiler erzeugte Programmcode ist noch nicht in diesem Format und
könnte nicht direkt auf dem PDA ausgeführt werden. Mittels eines im Entwicklungssystem enthaltenen Utility obj-res wird er zunächst in die 5 Ressourcen einer Palm
Anwendung aufgebrochen:
• code0
• code1
• data0
• rloc0
• pref0
Die code1 Resource enthält dabei den eigentlichen Programmcode. Inhalt und Aufgabe
der restlichen Ressourcen ist offiziell nicht dokumentiert. Im Anhang von [How97] ist
jedoch eine gute Zusammenstellung von Informationen zu diesem Thema zu finden.
Zusammen mit den UI Ressourcen wird daraus mittels des build-prc Utilities in einem post-linking Prozeß schließlich das fertige .prc-File erzeugt. Diese Trennung von
Programmcode und UI hat den Vorteil, daß z.B. Sprachanpassungen jederzeit ohne
Neuübersetzung der Programm-Quelltexte möglich sind.
Die hier beschriebenen Schritte und Werkzeuge beziehen sich auf die Verwendung der
GNU-PRC-Tools als Entwicklungsumgebung (vergleiche Abschnitt 3.9.3).
3.8.7
Libraries unter PalmOS
Die Motorola Dragonball Prozessoren können maximal relative Sprünge über eine
Distanz von 32 KByte ausführen. Es existieren zwar einige Möglichkeiten diese Beschränkung zu umgehen, jedoch wird die maximale Größe einer Code Resource immer
noch durch das Hotsync Protocol auf maximal 64 KByte beschränkt.
Die Auslagerung von Funktionen in shared Libraries ist eine Methode, um diese
Begrenzung der maximalen Anwendungsgröße zu umgehen. Zwar existiert in neueren
Versionen der PRC-Tools die Möglichkeit, eine Applikation in mehrere einzelne Code
Ressourcen aufzuteilen, jedoch sind Libraries in jedem Fall immer dann sinnvoll, wenn
mehrere verschiedene Programme auf dieselbe Funktionalität zugreifen wollen.
Die Auslagerung dieser Funktionalitäten in eine Library macht den Programmcode der
darauf zugreifenden Anwendungen schlanker und hilft damit insgesamt Speicherplatz
einzusparen, da nicht immer derselbe Code zu jedem Programm gelinkt werden muß.
3.8.7.1
151
PalmOS-Version 2 shared Libraries - SysLib
Dies ist die traditionelle“ Art, shared Libraries auf der Palm Plattform zu realisieren.
”
Die System Libraries wie z.B. die serielle Library oder die IrDA-Library sind derartige
Bibliotheken.
SysLib Libraries sind Resource Databases mit einem Resource Type libr“. Im Ge”
gensatz zu den 5 Ressourcen einer Palm Anwendung besitzt eine SysLib nur eine libr
Resource, die genau der code1 Resource einer Anwendung entspricht.
Eine SysLib kann weder ein data- noch ein bss-Segmemt enthalten. Daher können
keine globalen oder statischen Variablen bei der Programierung solcher Bibliotheken
verwendet werden. Im Unterschied zu einer Anwendung wird zu einer shared Library
die C-Laufzeitbibliothek crt0 nicht hinzugelinkt.
Um die Funktionen der Bibliothek aufrufen zu können, exportiert eine PalmOS-SysLib
eine Dispatch Table. Dies entspricht einer Liste mit Adressen der einzelnen Funktionen.
Ein Nachteil von SysLibs ist, daß diese Dispatch Table am Anfang des Programmcodes mittels einer in Assembler geschriebenen Sprungtabelle vom Programmierer selbst
angelegt werden muß.
Jede derartige Bibliothek muß zusätzlich folgende 4 Funktionen enthalten. Diese mußten die ersten Einträge in der Dispatch Table darstellen:
• open: Initialisiert die Bibliothek
• close: Hierin wird allozierter Speicher wieder freigegeben, bevor die Bibliothek
geschlossen wird.
• sleep: Wenn der PDA ausgeschaltet wird, ruft das System diese Funktion auf.
• wake: Diese Funktion wird vom System für jede shared Library aufgerufen, nachdem das Gerät eingeschaltet wurde.
Eine fertig erstelle SysLib Bibliothek wird in Form einer .prc-Datei in einem Hotsync
Vorgang auf den PDA übertragen.
Um eine derartige Bibliothek zu nutzen, muß sie in der loaded Library Table des Systems eingetragen sein. Dies geschieht mit Hilfe des Systemaufrufs SysLibLoad. Um
Funktionen einer SysLib aufrufen zu können, ist ihre Referenznummer notwendig. Die
Betriebssystem-Funktion SysLibFind findet eine Library in der loaded Library Table
und gibt deren Referenz zurück. Diese Referenznummer muß jeder Bibliotheksfunktion
als erstes Argument übergeben werden.
152
3.8.7.2
GNU GLib Shared Libraries
GLibs stellen im Vergleich zu den PalmOS-Version 2 SysLibs eine wesentlich komfortablere Methode shared Libraries zu erstellen und zu verwenden dar.
Genau wie SysLibs sind auch GLibs als Palm Resource Database realisiert und werden in Form vom .prc-Dateien auf den PDA übertragen. Sie sind mit dem Resource
Type GLib“ gekennzeichnet und enthalten gewöhnlich drei Ressourcen: GLib0, data0
”
und rloc0. Die GLib0 Resource entspricht hier der code1 Resource einer normalen
Anwendung.
Im Gegensatz zu SysLibs können GLibs statische und globale Daten enthalten. Globale Daten können derzeit jedoch noch nicht an die aufrufende Applikation exportiert
werden.
Es ist relativ einfach, eine statischen Bibliothek, welche mit dem ar-Tool erzeugt worden ist, in eine GLib shared Library umzuwandeln. Zuerst wir mittels exportlist eine
Liste der exportierten Funktionen aus der statischen Library extrahiert. Aus dieser
Liste werden mit dem Utility stubgen zwei Stub Files erzeugt.
Das eine Stub-File wird zur statischen Bibliothek dazugelinkt. Anschließend werden
daraus mit obj-res die drei Ressourcen einer GLib extrahiert und mittels build-prc
zu einem installierbaren .prc-File zusammengesetzt. Dies ist die Shared Library, welche
auf dem PDA installiert werden kann.
Aus dem zweiten Stub-File wird eine Stub Library generiert. Eine solche Datei besitzt
die Endung .sa. Im Vergleich zur entsprechenden statischen Library ist diese Stub
Library sehr klein.
Die Benutzung von GLibs ist sehr einfach. Es ist kein explizites Öffnen oder Schließen der Library notwendig. Anwendungen, die die Bibliothek nutzen wollen, können
genauso gelinkt werden, wie sie auch gegen die entsprechende statische Library gelinkt
werden würden. Findet der Compiler anstelle des .a-Files auch eine .sa-Datei linkt er
automatisch gegen diese Stub-Library.
Derartige Anwendungen greifen somit auf die Funktionen der shared Library zu. Voraussetzung dafür ist natürlich, daß die betreffende Bibliothek auf dem PalmOS-Gerät
installiert ist, ansonsten tritt ein Laufzeitfehler auf, welcher auf die fehlende Bibliothek
hinweist.
GLibs sind im allgemeinen der elegantere und einfachere Weg für den Programmierer,
shared Libraries auf dem Palm zu verwirklichen. Allerdings unterstützen nicht alle
Compiler diese Methode (vergleiche dazu 3.9.3.1).
3.9. GNU-PALMOS-ENTWICKLUNGSWERKZEUGE
3.9
153
GNU-PalmOS-Entwicklungswerkzeuge
Obwohl auch Compiler auf der Palm Plattform selbst existieren, findet die Entwicklung
einer Palm Anwendung in der Regel auf einem Desktop-System mittels einer CrossDevelopment Umgebung statt.
Ich entschied mich zur Verwendung der GNU-PalmOS-Entwicklungswerkzeuge. Wie
alle unter der GNU-Lizenz stehenden Programme ist dies eine freie, nichtkommerzielle
Entwicklungsumgebung. Sie besteht aus einem gcc Compiler für dem Motorola m68k
Prozessor und einigen Palm-spezifischen Zusatzprogrammen.
Außer der Nichtkommerzialität war die der Programmentwicklung unter Unix sehr
ähnliche Umgebung und überhaupt die Verfügbarkeit für Linux für diese Entscheidung
auschlaggebend.
3.9.1
Alternative Entwicklungs-Tools
Die bekannteste alternative und gleichzeitig die offiziell von Palm Inc. unterstützte
Entwicklungsumgebung ist der CodeWarrier der Firma Metroworks. Diese IDE3 hat
ihren Ursprung auf der Macintosh Plattform. Sie ist jedoch mittlerweile auch für Windows erhältlich.
Darüberhinaus existieren noch viele andere Tools und Programmiersprachen für
PalmOS, darunter auch Basic und Java Compiler sowie mit Pila ein freier Assembler.
3.9.2
Verschiedene Versionen des PalmOS-SDKs
Sowohl gcc als auch CodeWarrier verwenden dieselbe API. Zu jeder neuen Version
des PalmOS veröffentlicht Palm Inc. das zugehörige SDK. Dieses besteht neben der
zugehörigen Dokumentation im wesentlichen aus Header Files zu den Betriebssystem
Funktionen.
Mittlerweile ist das SDK 4.0 veröffentlicht. Zu Beginn der Arbeit war die Version
3.5 aktuell. Es ist prinzipiell empfehlenswert, zur Entwicklung einer Anwendung das
jeweils aktuellste SDK einzusetzen. Von Version 3.0 auf 3.5 hat Palm den Aufbau
der Verzeichnisstruktur und teilweise auch die Bezeichnungen von Datentypen und
Funktionen teilweise erheblich verändert.
Abgesehen von der Tatsache, daß ich in meinem Projekt einige Libraries verwenden
wollte, welche noch mit einem älteren SDK entwickelt wurden, und die somit teilweise
erheblicher Anpassungen bedurft hätten, muß das SDK auch in die Entwicklungsumgebung integriert werden.
3
Integrated Development Environment
154
Da ich, aus in Abschnitt 3.9.3.1 beschriebenen Gründen, eine relativ alte Version der
PRC-Tools verwenden mußte, das SDK 3.5 aber auf die neuere Version 2.0 der PRCTools ausgelegt war, stellte sich die Integration als äußerst schwierig heraus.
Da ich keine der in der Version 3.5 eingeführten Funktionen dringend benötigte, entschied ich mich, unter dem SDK in der Version 3.0 zu entwickeln.
3.9.3
PRC-Tools
Die Zusammenstellung der GNU gcc-Entwicklungs-Tools für PalmOS wird auch als
PRC-Tools bezeichnet. Sie bestehen im wesentlichen aus:
• Modifiziertem m68k gcc Compiler
• GDB Debugger
• Post-Linker Tools
– obj-res: konvertiert ein mit gcc kompiliertes, ausführbares Programm oder
eine Objekt Datei in PalmOS kompatible Resource Files
– build-prc: Kombiniert die als Eingabe übergebenen Resource Dateien zu
einer auf den PDA ladbaren .prc-Datei
– stubgen: Erzeugt die für GLibs notwendigen Stub-Files
– ar: Erzeugt statische Bibliotheken
Die Erzeugung einer Palm Anwendung durchläuft damit folgende Schritte:
1. Übersetzung der Sourcen mit dem m68k gcc Compiler zu Object-Files
2. Linken der Object-Files zu einem GNU BFD-Format
3. Auflösen dieses Formats in PalmOS kompatible Ressourcen mittels obj-res
4. Zusammenfügen der einzelnen Resource-Dateien zu einem .prc-File durch
build-prc
3.9.3.1
Verschiedene Versionen
Die PRC-Tools von Version 0.1.0 bis 0.5.0 wurden federführend von Jeff Dionne entwickelt. Hauptverantwortlich für die Portierung des gcc Compilers zeichnete sich Kresten Krab Thorup unter Mitwirkung von Jeff Dionne, Ian Goldberg und anderen.
Diese stellten jedoch 1997 die Entwicklungsarbeiten an den PRC-Tools ein. Die Weiterführung des Projekts übernahm John Marshall, ein Angestellter von Palm Inc..
Die daraus entstandene neue Generation von PRC-Tools basiert auf einer aktuelleren
Version des gcc Compilers und weicht auch von der Handhabung und ihrer gesamten
3.9. GNU-PALMOS-ENTWICKLUNGSWERKZEUGE
155
Konzeption relativ stark von der ursprünglichen Version ab. Um dies zu verdeutlichen,
wurde ein Sprung der Versionsnummer von 0.5.0 auf 2.0 für angemessen erachtet.
Trotz vieler Vorteile ist in der zu Beginn meiner Arbeit aktuellen Version noch keine
Unterstützung für GLib shared Libraries verwirklicht. Dies ist erst für die Veröffentlichung der Version 2.1 angekündigt.
Zwei, der für meine Arbeit benötigten, Bibliotheken waren als GLibs ausgelegt.
Während es kein allzu großes Problem gewesen wäre, die Chipkarten Library auf den
unbedingt notwendigen Funktionsumfang zu reduzieren und dann statisch zu linken,
wäre dies mit der DES-Crypto Library aufgrund ihrer Größe nicht möglich gewesen.
Abgesehen davon erschien mir eine Realisierung mit Libraries einfach eleganter und
sinnvoller, so daß ich auf diese Fähigkeit nicht verzichten wollte. Daher entschied ich
mich, zur Entwicklung des mAuth-PTD-Demo-Clients die PRC-Tools in der Version
0.5.0 zu verwenden.
3.9.4
Der Pilot Resource Compiler PilRC
Wie bereits erwähnt wird gewöhnlich ein Großteil des User Interfaces bereits bei der
Programmentwicklung statisch festgelegt. Diese Daten stellen eine oder mehrere eigenständige PalmOS-UI-Ressourcen dar, welche mittels dem build-prc Werkzeug zu
den restlichen Ressourcen der Anwendung dazugebunden werden.
Um diese UI Ressourcen zu Erzeugen entwickelte Wes Cherry den PilRC4 . Das User
Interface wird hierbei in einer textbasierenden Beschreibungssprache definiert.
Zu einer funktionalen Gruppe wie z.B. einer FORM, einer Dialog- oder Alert-Box
gehörende UI-Elemente werden von den Schlüsselwörtern BEGIN und END eingeschlossen. Abgesehen von wenigen Ausnahmen bestehen die Einträge für jeweils ein Bedienelement aus dem Bezeichner des Elements, seiner Beschriftung, einer ID, mit welcher das Element im Programmtext referenziert werden kann, und einer Positionsangabe. Darüber hinaus sind je nach UI Objekt-Typ und Einsatzzweck noch weitere
optionale Argumente möglich.
Beschreibung einer FORM im PilRC-Format:
FORM ID MainForm AT ( 0 0 160 160 ) USABLE
MENUID mainMenuID
BEGIN
TITLE "mAuth System PTD-Client"
BUTTON "PeerDisc" ID PDButtonID AT (20 90 AUTO AUTO) FRAME
BUTTON "Authenticate" ID AuthButtonID AT (PREVRIGHT+10 PREVTOP AUTO AUTO) FRAME
END
4
Pilot Resource Compiler
156
Beschreibung einer ALERT-Box im PilRC-Format:
ALERT ID alert1FormID
ERROR
BEGIN
TITLE "READER ERROR"
MESSAGE "Error accessing the CardReader !"
BUTTONS "OK"
END
Es existiert auch ein kleines Tool, das ein derartiges Textfile als Eingabe verwendet
und eine Vorschau des User Interface auf dem PC Monitor darstellt.
Die Datei mit der fertigen Beschreibung des User Interfaces dient PilRC als Eingabe.
PilRC erzeugt daraus die passenden UI Ressourcen für das PalmOS.
3.9.5
Handspring-spezifische Erweiterungen des PalmOS
Die Firma Handspring hat das PalmOS, welches auf ihren Geräten zum Einsatz kommt,
um einige Eigenschaften erweitert und angepaßt. Das betrifft vor allem die Springboard
und USB Unterstützung.
Um als Programmierer diese neuen Fähigkeiten nutzen zu können, bietet Handspring
auf ihrer Webseite die sogenannten Handspring-Extension als Ergänzung des jeweils
aktuellen PalmOS-SDKs zum Download an. Diese bestehen aus einigen Header Dateien,
welche in den include-Verzeichnisbaum des Palm SDKs eingebunden werden.
Das Problem dabei ist, daß Handspring zwar die gcc Entwicklungstools unterstützt,
jedoch ausschließlich auf der Windows Plattform. Offensichtlich bestehen aber zwischen
der gcc Version unter Unix und der unter Windows doch einige Unterschiede.
Bei der Entwicklung meines Prototypen hätte ich gerne einige dieser erweiterten Funktionen genutzt. In der Anfangsphase der Entwicklung verwendete ich das serielle Cradle
zur Kommunikation mit dem Chipkarten-Lesegerät. Sobald der Visor in das Cradle eingesetzt wurde, konnte ich jedoch den seriellen Port nicht mehr öffnen, da die Library
meldete, die Schnittstelle sei bereits in Verwendung.
Das resultiert daraus, daß auf dem Handspring ein sogenannter Keyboard-Daemon
mittels eines dafür vorgesehenen PINs am Cradle Connector feststellt, ob ein externes
Keyboard an den Visor angeschlossen wurde, und dann die serielle Library nutzt, um
mit diesem zu kommunizieren. Jedoch nutzt auch das serielle Cradle diese Funktion,
und belegt durch das entsprechende Signal auf diesem PIN sofort die serielle Schnittstelle, womit diese für meine Applikation nicht mehr nutzbar ist.
Mit der erweiterten Handspring-API wäre es möglich, dieses Verhalten via Software
zu deaktivieren. Jedoch war es mir auch nach langen Versuchen nicht möglich, ein
Programm mit einem Aufruf der entsprechenden Funktion zu übersetzten. Ich führte
3.10. DER PALMOS-EMULATOR POSE
157
die Compiler Fehlermeldungen schließlich auf eine Unverträglichkeit zwischen Windows
und Unix PRC-Tools Versionen zurück.
Als Notlösung behalf ich mir damit, das betreffende PIN mit einem Klebestreifen zu
isolieren. Da ich in der endgültigen Version des Prototypen kein Cradle mehr verwendete, stellte dies ohnehin kein weiteres Problem mehr dar.
3.10
Der PalmOS-Emulator POSE
3.10.1
Entwicklungsgeschichte
Der PalmOS-Emulator entstand wie viele der frei verfügbaren Entwicklungstools auf
Initiative eines Programmierers hin, der den Bedarf einer solchen Anwendung erkannte.
Greg Hegwill begann im Juni 1996 mit der Entwicklung des damals noch als Pilotsim
bezeichneten Emulators. Sein Ziel war es, die CPU und die komplette Hardware eines
Palm Pilots auf einem Desktop Computer zu emulieren, um somit neue Anwendungen
komfortabel testen und debuggen zu können.
Als Grundlage diente ihm die Emulation der Motorola 68k CPU des UAE5 von Bernd
Schmidt. Ohne Dokumentation der Hardware und ohne Sourcen des PalmOS entwickelte Greg den Emulator, nur durch systematische Analyse eines PalmOS-ROMImages und kleiner Analyse-Programme auf der Palm Hardware, bis zum Herbst 1996
zu einer stabilen Version.
Er veröffentlichte die Version 1.0 des nun Copilot genannten Programms inklusive der
Sourcen im Internet. Dadurch wurde der Copilot sehr schnell durch unterschiedliche
Entwicklerteams von der ursprünglichen Windows Version auf andere Plattformen portiert. Heute existieren zwei Versionen für den Macintosh und Portierungen auf Linux,
BeOS, OS/2 und sogar Windows CE.
Nach mehreren neuen Versionen und Verbesserungen mußte Greg Hegwill u.A. aus Zeitmangel gegen Ende 1997 die Entwicklungsarbeit einstellen. Palm Inc. zeigte aber mittlerweile Interesse an diesem Projekt und stellte eigens einen Mitarbeiter zu Fortführung
des Emulator-Projekts ab.
Seit Anfang 1998 ist daher Keith Rollin von Palm Inc. für die Weiterentwicklung
des Emulators verantwortlich. Seine anfängliche Arbeit bestand darin, die Sourcen
der mittlerweile zahlreichen Portierungen zu einem einheitlichen Programmierstil zu
vereinheitlichen und besser zu dokumentieren.
Weiterhin wurden die neuesten UAE Quellen zur Emulation des CPU Kerns eingebaut. Da Keith im Gegensatz zu Greg sowohl die Hardware Dokumentation als auch
die PalmOS-Sourcen zur Verfügung standen, konnte er einige Details der Motorola
5
Unix Amiga Emulator
158
Dragonball-Emulation verbessern. Zu den wichtigsten Neuerungen zählt auch die Unterstützung von externen Debuggern. Damit ist es den Programmierern, möglich
ihren vertrauten und bevorzugten Debugger einzusetzen
Da Palm Inc. die Bezeichnung Pilot in ihren neueren Produkten nicht mehr verwendet,
änderte sich auch der Name des Emulators von Copilot in POSE6 .
3.10.2
Allgemeines
Mit dem PalmOS-Emulator ist es möglich annähernd die komplette Hardware eines
Palm PDAs auf einem Desktop Computer System zu emulieren. Er benötigt dazu ein
Image des PalmOS, das er dann auf der simulierten Hardware ausführt. Dabei wird
nicht nur die CPU emuliert. Die Ausgabe auf das LCD Display wird auf dem Monitor
des PC angezeigt, wobei das Display sogar von einer originalgetreuen Abbildung eines
Palm Gehäuses eingerahmt wird.
Abbildung 3.11: Start einer POSE Sitzung
Die Eingabe mit dem Pen wird durch die Mausbewegung und -klicks des PCs ersetzt,
und die Eingabe in Textfeldern kann direkt mit der PC-Tastatur vorgenommen werden.
6
PalmOS Emulator
159
Die serielle Schnittstelle des Palm leitet der Emulator direkt auf einen wählbaren seriellen Port des PC um. Soweit mir bekannt ist, ist die Durchleitung des Palm IrDA-Ports
auf die entsprechende PC-Hardware (noch) nicht möglich.
Zum Auslesen des PalmOS-ROMs aus dem PDA in eine Image Datei für den Emulator
ist in ein kleines Palm Programm enthalten, welches, auf dem PDA installiert und
gestartet, den Transfer ermöglicht. Der Palm muß dazu im seriellen Cradle eingesetzt,
und somit mit dem PC verbunden sein. Mit dem Download-Button im Start-Fenster
einer neuen Emulatorsitzung wird der Download Dialog gestartet.
Dem Emulator muß dann nur noch der Ort des ausgelesenen Images im Filesystem
sowie das Modell und der Speicherausbau des zu emulierenden Gerätes mitgeteilt werden.(siehe auch Abbildung 3.11).
Der Emulator ist bei der Entwicklung von PalmOS-Anwendungen ein nahezu unentbehrliches Hilfsmittel. Seine wichtigsten Vorteile sind dabei:
• Schnelles Testen verschiedener Programmversionen durch einfaches Laden der
Programme durch drag & drop in das Emulator Fenster ohne Hotsync Vorgang.
• Einfaches Debuggen durch Unterstützung externer Debugger
• Teilweise Programmausführung zu Debugzwecken noch nach Fehlern möglich, die
ein reales PalmOS zum Absturz gebracht hätten.
• Direkter Einsprung in den Debugger nach PalmOS-Systemfehler
• Emulator überprüft Anwendung auf guten Programmierstil und warnt bei direkten Zugriffen auf Dragonball Register, Zugriff auf System-, oder Display Speicher
u.v.m.. Damit soll sichergestellt werden, daß Anwendungen auch auf zukünftigen
PalmOS-Versionen und Palm Modellen noch lauffähig sind.
• Umfangreiche Logging Funktionen
• Testen der Anwendung mittels Gremlins. Gremlins erzeugen zufällige Benutzereingaben und führen diese dem Programm als Eingabe zu. Damit lassen sich
bei realer Nutzung kaum vorkommende Situationen erzeugen, und eventuell dabei
auftretende Fehler finden.
• Programmentwicklung und Tests sind auch ohne entsprechende Hardware
möglich. Das ist vor allem interessant, um die Funktionalität auf verschiedenen
Modellen zu testen.
In der aktuellen Version kann POSE alle Geräte der Palm Modellreihe sowie den Handspring Visor emulieren. Die Emulation schließt dabei alle Besonderheiten der Hardware der einzelnen Modelle ein. Zu den meisten Modellen sind sogar sogenannte Skins
vorhanden, die für das originalgetreue Aussehen des jeweiligen Geräts auf dem PC
Bildschirm sorgen (siehe Abbildung 3.12).
160
Abbildung 3.12: Emulation verschiedener Palm Modelle
3.10.3
Probleme beim Ansprechen der emulierten seriellen
Schnittstelle
Während meiner Entwicklungsarbeit nutzte ich den Palm-Emulatur sehr ausgiebig. Zu
Beginn der Arbeit verfügte ich noch über keine PDA Hardware so daß der Emulator
die einzige Möglichkeit bot, erste eigene Anwendungen zu testen.
Später stand mir zwar bereits ein Handspring Visor zur Verfügung, jedoch bereitet
der physikalische Anschluß eines Chipkarten-Lesegerät an den PDA Probleme (näheres
dazu in Abschnitt 3.11.
Da der Emulator die Aufrufe an die serielle Schnittstelle des Palm an den RS-232-Port
des PCs weiterleitet, und ich über ein Chipkarten-Lesegerät für den PC verfügte, wollte
ich die ersten Versuche, mit einer Palm-Anwendung auf eine Chipkarte zuzugreifen, mit
dem Emulator durchführen.
Trotz korrekter Konfiguration des Emulators konnte ich jedoch das Chipkartenterminal nicht ansprechen. Nachdem ich Fehler in der Verkabelung und im Programmcode
meiner Anwendung ausgeschlossen hatte, glaubte ich zuerst, das Problem auf eine fehlerhafte Emulation der seriellen Schnittstelle zurückgeführt zu haben. Hier war die
Logging-Funktionalität des POSE sehr hilfreich. Diesen Informationen war zu entnehmen, daß der Emulator die serielle Schnittstelle des PCs nicht öffnen konnte.
Da meine bisherigen Versuche ausschließlich unter Windows stattfanden, beschloß ich,
den Emulator auf dem selben Rechner unter Linux zu testen. Zu meiner Überraschung
funktionierte der Zugriff auf das Chipkartenterminal unter diesem Betriebssystem auf
161
Anhieb.
Der Emulator Quellcode ist auf beiden Plattformen weitgehend identisch. Zwar sind die
Module, welche die serielle Schnittstelle ansprechen, bei Windows und Linux-Version
unterschiedlich, da die Emulation der seriellen Schnittstelle jedoch schon seit der ersten
Version des Emulators zu seinem Funktionsumfang gehört, erschien mir ein Fehler darin
unwahrscheinlich.
Die vorkompilierte Linux-POSE-Version hatte jedoch noch keine Unterstützung für
Handspring-Geräte, eine neuere Version, die diese Funktionalität besaß, lag mir nur im
Source Code vor. Nachdem Probleme mit falschen Versionen einiger Linux-Bibliotheken
auf meinem System gelöst waren, konnte ich die neue POSE Version erfolgreich übersetzen. Leider stellte sich heraus, daß in dieser Version das Programmodul zur Umleitung
der seriellen Schnittstelle auf das entsprechende Linux-Device tatsächlich nicht funktionierte. Ob dies ein allgemeiner Fehler ist, oder nur bei meinem System auftrat, habe
ich nicht weiter überprüft. Es gelang mir zwar, eine funktionsfähige Version zu erzeugen, indem ich den Code der seriellen Emulation der neuen POSE-Version“ durch den
”
funktionierenden Quelltext der alten Version ersetzte, jedoch wollte ich, um weitere
Fehlerquellen auszuschließen mit der unmodifizierten Windows Version weiterarbeiten.
Im Unterschied zu Linux, das vom Chipkartenterminal-Hersteller Towitoko nicht explizit unterstützt wird, waren auf der Windows Plattform, die von Towitoko mitgelieferten
Treiber für das Chipkartenterminal geladen. Wie sich durch Versuche herausstellte, belegen diese Treiber, auch wenn keine der Towitoko Anwendungen aktiv ist, die serielle
Schnittstelle des PCs. Damit kann sie von anderen Programmen wie dem Emulator
nicht mehr geöffnet werden. Nach der Deinstallation dieser Treiber konnte der Emulator auch unter Windows die simulierte serielle Schnittstelle problemlos ansprechen.
3.10.4
Auslesen eines ROM Images aus dem Visor
Da, wie schon mehrmals erwähnt, auf den Geräten der Firma Handspring ein modifiziertes PalmOS zum Einsatz kommt, hielt ich es für wünschenswert, auch ein entsprechendes ROM Image zur Emulation zu verwenden.
Da ROM Images aus Copyright Gründen nicht frei im Internet zum Download zur
Verfügung stehen, wollte ich das Image aus dem Handpring Visor Platinum auslesen.
Für die Geräte vom Palm Inc. ist dies mittels des Emulators und eines kleinen Programms für den Palm wie in Abschnitt 3.10.2 beschrieben relativ einfach möglich.
Durch diese Methode verfügte ich bereits über ein ROM Image eines Palm V, das ich
aus dem Gerät eines Freundes transferiert hatte.
Der Visor verfügt im Gegensatz zu den Palm Modellen jedoch über ein Cradle mit
USB Anschluß. Die ROM-Transfer Funktion des POSE erwartet aber ein Cradle mit
seriellem Anschluß. Doch selbst mit dem als Zubehör erhältlichen seriellen Cradle ist
ein Auslesen des Visor-ROMs mit dem Emulator nicht möglich.
162
Eine Lösung dieses Problems war im Internet zu finden. In den HandspringEntwicklungs-Tools, welche auf deren Webseite zum freien Download angeboten werden, aber leider auch nur ausschließlich für Windows verfügbar sind, ist auch eine
modifizierte Version des Palm Debuggers enthalten, die Verbindungen zum PDA über
den USB Port unterstützt. Damit ist es möglich, den Ausschnitt aus dem Speicher des
Visors, der das ROM beherbergt, auf den PC zu transferieren.
Der Visor muß sich dazu im Cradle befinden und mittels der Eingabe des
Shortcut-Symbols, zwei Punkten und der Ziffer 1
in der Merkzettel-Anwendung in den Debug-Modus versetzt werden. Im Debugger muß
zuvor USB“ als Verbindung zum PDA ausgewählt worden sein.
”
Durch Eingabe von
save "ImageName.rom" 10000000 200000
wird das ROM ausgelesen und unter dem angegeben Namen auf dem PC gespeichert.
Durch Eingabe von reset im Debugger-Fenster wird der Visor anschließend wieder aus
dem Debugmodus geholt.
3.10.5
Schwierigkeiten bei der Ausführung eines Handspring
Visor Platinum ROMs
Laut Dokumentation des POSE werden von diesem zwar die Handspring-Geräte
unterstützt, wie sich herausstellte jedoch nur die Modelle Deluxe und Prism. Die
Ausführung eines Visor Platinum ROMs erzeugt bereits beim Bootvorgang auf dem
Emulator eine Menge an Warnmeldungen und Fehlern.
Das ROM bootet zwar abgesehen von diesen Meldungen vollständig, und meine TestAnwendung startet auch, jedoch gelang es mir damit nicht, die serielle Schnittstelle
anzusprechen. Auf eine Nachfrage in der POSE Entwickler Newsgruppe erhielt ich von
einem der Entwickler die Auskunft, daß die Unterstützung des Platinum ROM erst in
künftigen Versionen des POSE vorgesehen ist..
Da mir mittlerweile ein realer Handspring Platinum zur Verfügung stand, beschloß
ich, alle Versuche auf dem Emulator mittels des Palm V ROM durchzuführen, und
die endgültigen Tests auf Verträglichkeit mit den Besonderheiten des Visor Platinum
direkt am realen Gerät vorzunehmen.
3.11. ANSCHLUSS DES CHIPKARTEN-LESEGERÄTS AN DEN PDA
163
3.11
Anschluß des Chipkarten-Lesegeräts an den
PDA
3.11.1
Die serielle Schnittstelle des Handspring Visors
Die PDAs der Firma Handspring besitzen im Gegensatz zu den Palm Geräten keine vollwertige RS-232-Schnittstelle. Da sie eigentlich zum Anschluß über den USB
Port gedacht sind, sind auf ihrem Cradle Connector nur die Signale RX und TX eines
herkömmlichen seriellen Ports“ vorhanden und keine Steuersignale.
”
Dazu kommt, daß diese seriellen Sende- und Empfangssignale nicht den RS-232-Pegeln
entsprechen, sondern nur 3,3 Volt TTL7 -Pegel liefern und erwarten.
Um trotzdem auch eine Kommunikation mit PCs ohne USB Port zu ermöglichen, bietet
Handspring ein serielles Cradle als Zubehör an. Ein darin enthaltenes Pegelwandler IC
vom Typ MAX3232 des Herstellers Maxim setzt mittels einer Ladungspumpe die TTLPegel des Visors in RS-232 konforme Signale für den PC um und umgekehrt. Aufgrund
der fehlenden Steuersignale wie u.A. RTS oder CTS ist jedoch nur eine Datenübertragung
mit verhältnismäßig geringer Geschwindigkeit möglich.
3.11.2
Kopplung über
Pegelwandler
serielles
Cradle
mit
RS-232-
Zur Kommunikation mit dem Chipkartenterminal reicht aber eine Geschwindigkeit
von 9600 Baud problemlos aus. Der erste Ansatz, den Handspring Visor um einen
Chipkarten-Reader zu erweitern, bestand daher in der Verwendung des seriellen Cradles
als Hilfsmittel.
Da sowohl die jeweils 9-poligen Stecker von Chipkarten-Lesegerät und Cradle zum Anschluß an einen PC gedacht sind, müssen beide über einen Adapter gekoppelt werden.
In diesem Adapter werden wie bei einem Nullmodem-Kabel“ die Sende- und Emp”
fangssignale überkreuzt. Die Belegung einiger Steuersignale habe ich von der Beschaltung eines Nullmodem-Adapters übernommen, obwohl sie für diesen Zweck gar nicht
notwendig gewesen wären. Sie stören jedoch auch nicht.
Zur Versorgung des Chipkartenterminals ist eine Gleichspannung von 5 Volt notwendig.
Diese muß von einer externen Quelle bereitgestellt werden. Ich verwendete dazu 4 Stück
1,5 Volt Mignon Batterien. Die daraus resultierende Betriebsspannung von 6 Volt liegt
innerhalb des Toleranzbereichs der Chipkarten-Leserelektronik.
7
Transistor Transistor Logic
164
Adapter seriell 9 pol. Sub-D
von
Visor Cradle auf Towitoko micro 100
1
1
RX
RX
TX
TX
DTR
Handspring Signal Ground
Visor
DSR
ChipSignal Ground drive
100
RTS
RTS
CTS
+
-
+
Spannungsversorgung
Chipdrive micro 100
Abbildung 3.13: Adapter zwischen seriellen Cradle und Chipdrive
Erste Versuche, über diesen Aufbau mit der Chipkarte zu kommunizieren, schlugen jedoch fehl. Der Grund dafür war, daß Cradleelektronik die vom MAX3232 Pegelwandler
benötigte Versorgungsspannung von 3,3 bis 5 Volt nicht wie zuerst von mir angenommen vom Visor bezieht, sondern vom PC. Die Versorgungsspannung für das Cradle
muß daher über den Adapter eingeschliffen werden. Der PC versorgt das Cradle über
Signal Ground und RTS mit Spannung. Genau diese Pins schloß ich auf der CradleSeite des Adapters an den Batteriepack, welcher auch das Chipkartenterminal versorgt,
an.
Der Anschluß der Chipkarten-Reader Spannungsversorgung erfolgt über die vorgesehenen PINs dessen PS/2 Steckers.
Wie bereits in Abschnitt 3.9.5 erwähnt, ist es bei dieser Lösung notwendig, das Keyboard
Detect-PIN 2 auf dem Cradle-Connector zu isolieren, um eine Blockierung der seriellen
Schnittstelle zu verhindern.
Der Nachteil dieses Lösung ist der relativ unhandliche Aufbau. Da der PDA hier immer
im Cradle eingesetzt sein muß, und verhältnismäßig viele Verbindungskabel und Adapter notwendig sind, machte der Prototyp keinen sehr repräsentativen Eindruck. Der
Vorteil dabei ist, daß keinerlei Verbindungkabel umgebaut oder gar zerstört werden
müssen, so daß die spätere Verwendung von Cradle und Chipkartenterminal an einem
PC jederzeit wieder möglich gewesen wäre.
Nachteilig ist darüberhinaus der, durch die Pegelwandlung der seriellen Signale bedingte, unnötig hohe Stromverbrauch.
165
Abbildung 3.14: Aufbau bei Anschluß über serielles Cradle
Dazu kam, daß nach einiger Betriebszeit zwei Transistoren im Cradle durch thermische
Überlastung zerstört wurden. Ich konnte den Grund dafür nie genau feststellen. Da ich
ohnehin eine bessere Lösung anstrebte, verwendete ich auch nicht allzuviel Zeit mit der
Ursachenerforschung.
Eine elegantere Lösung ist die direkte Kopplung des Chipkartenterminals an den
Handspring-PDA ohne dazwischengeschaltetes RS-232-Cradle.
3.11.3
Direkte Kopplung
Da die Elektronik des Chipdrives mit großer Wahrscheinlichkeit intern nicht mit RS232-Pegeln, sondern ebenfalls wie der Ausgang des Visors mit TTL Signalpegeln arbeitet, schien eine direkte Kopplung dieser beiden Geräte erfolgversprechend zu sein..
Das Problem dabei war, daß ich über keinerlei Unterlagen zur Hardware des Towitoko
Chipdrives verfügte. Der Hersteller beschränkt sich auf die Angabe der wichtigsten
technischen Daten. Informationen über den verwendeten Controller-Chip, geschweige
166
denn der gesamte Schaltplan des Lesegerätes, waren nicht zu bekommen.
Eine Recherche im Internet lieferte zwar nicht die erhofften technischen Unterlagen,
jedoch einen Erfahrungsbericht eines Anwenders [Kah] der genau diese Kopplung, allerdings mit einem Chipdrive micro 110 erfolgreich realisiert hatte. Auf der Seite waren allerdings leider keine Beschaltungsskizzen enthalten, sondern nur sehr unscharfe
Aufnahmen der umgebauten Chipkarten-Leser Platine. Die Beschreibung enthielt aber
viele hilfreiche Anhaltspunkte, die mir als Basis für eigene Versuche dienten.
Als Anschluß zum Visor-Cradle-Connector sollte ein umgebautes USB Kabel dienen.
Als ersten Schritt trennte ich den USB Stecker von diesem Kabel ab. Wie sich hierbei herausstellte, führte das Kabel nur die drei Signalleitungen, welche zur USBKommunikation benötigt werden.
Towitoko Chipdrive 100
Anschlußschema
LED
Cable connector
1
1
Towitoko
Chipcard
Controller
74HC125
Towitoko
Chipdrive micro 100
Elko
RTS
VCC +5 V
TX TTL
RX
inv TTL
GND
Abbildung 3.15: Anschlußschema der Chipkarten-Leser Platine
Zur Verbindung mit dem Chipkartenterminal reichten diese aber gerade aus. Nur die
Belegung am Stecker für den Visor-Cradle-Connector mußte geändert werden. Ich
benötigte die Signale RX, GND und TX vom Visor. Diese liegen auf den PINs 1, 4 und
8 des Cradle-Connectors. Am geöffneten Stecker lötete ich die vorhandenen Signalleitungen von den USB Pins einfach auf die für mein Vorhaben benötigten Anschlüsse
um.
Als nächstes galt es, die entsprechenden Anschlüsse auf der Platine des Chipdrive
micro 100 ausfindig zu machen. Abbildung 3.15 zeigt schematisch ihre Bestückung.
Der RS-232- und der PS/2-Stecker sind normalerweise über den als Cable-Connector
bezeichneten Pfostenstecker auf der Platine angeschlossen. Da diese Anschlüsse nicht
mehr benötigt wurden, entfernte ich diesen Stecker. Zuvor bestimmte ich noch aus dem
167
bekannten PIN Layout der beiden Standard-Stecker die Belegung des Cable-Connectors
auf der Platine.
Direkte Kopplung zwischen
Handspring Visor und Towitoko Chipdrive 100
Oberseite
Pin 1
RX inv
Pin 4
TX
RX
GND
VCC
zum
Chipdrive
RTS
TX
VCC
GND
GND
Pin 8
Handspring
Visor
+
-
= 4,8 - 6 V
Abbildung 3.16: Beschaltungsschema bei der direkte Kopplung zwischen Visor und
Chipdrive 100
Über diesen Anschluß sollte die Stomversorgung des Chipkartenterminals realisiert werden. Die eigentliche Schwierigkeit bestand darin, herauszufinden, an welcher Stelle die
seriellen Ein- und Ausgangssignale auf die Platine zu führen waren.
Obwohl die Platinen des Chipdrive micro 110 und 100 nicht identisch sind, nahm ich an,
daß beide zumindest das selbe Chipkarten-Controller IC verwenden. Christian Kahlo
beschreibt in seinem Bericht [Kah] PIN 1 und 2 des Controller ICs als TTL Ein- bzw.
Ausgang des Towitoko Chipdrive micro 110.
Dabei ist zu beachten, daß der Controller auf seinem Eingang ein invertiertes Signal
erwartet. Daher ist auf einer kleinen externen Platine ein Standard TTL Inverter IC
auf dem Signalweg zwischen seriellem Ausgang des Visor und Eingang des Chipdrive
Controllers untergebracht. Die Stromversorgung des Inverters erfolgt aus dem selben
Batteriepack, der auch das Lesegerät speist. Gleichzeitig dient die Inverter-Platine zur
physikalischen Verbindung zwischen dem vom Visor kommenden umgebauten USB
Kabel und den Anschlußleitungen zum Chipdrive.
Mit diesem Aufbau gelang es mir jedoch noch nicht, die Chipkarte anzusprechen. Erst
nachdem das RTS-Signal am ursprünglichen RS-232-Cable-Connector des Chipkartenterminals auf VCC gelegt wurde, führte das zum gewünschten Erfolg.
168
Abbildung 3.17: Aufbau bei direktem Anschluß des Towitoko Chipdrive micro 100 and
den Handspring Visor Platinum
Abbildung 3.17 zeigt dabei die Realisierung dieser Kopplung. Die RX und TX Anschlüsse
lötete ich direkt auf die entsprechenden PINs des Conrollers auf. Das FlachbandAnschlußkabel für Signale und Versorgungsspannung wird dabei über eine separat angebrachte Öffnung aus dem Gehäuse geführt, um die Originalöffnung zu erhalten, falls
das Lesegerät später mal wieder an einem PC verwendet werden sollte.
169
Kapitel 4
Das mAuth Demonstrationssystem
4.1
4.1.1
Aufbau
Implementierte Systemkomponenten
Zielsetzung bei der Entwicklung des Demonstrationssystems war nicht eine möglichst
vollständige Umsetzung des mAuth Konzepts, sondern die Realisierung eines einfachen
Anwendungsbeispiels, mit dem die Funktionalität und Praxistauglichkeit des Konzepts
veranschaulicht werden konnte.
Das Demonstrationssystem besteht aus den Komponenten:
• Mobiles Gerät
• Chipkarte
• PoA
Auf die Komponente Trustcenter und damit auch auf die Verwendung von Zertifikaten wurde zur Vereinfachung verzichtet. Der PoA ist als einzelnes Gerät mit
eigener Benutzerdatenbank realisiert. Eine zentrale Benutzerdatenbank, wie sie von
PoA-Betreiber Organisation verwendet werden würde, hätte das Demonstrationsystem nur unnötig verkompliziert, ohne einen großen Nutzen für die Anschaulichkeit zu
erbringen.
4.1.2
Implementierte Funktionalität
Das Demonstrationssystem ermöglicht die Anmeldung an einen Linux-Rechner mittels
einem mobilen Gerät gemäß dem mAuth Protokoll. Es verwirklicht damit das Applikationsmodell vom Typ Zugang (vergleiche Abschnitt 2.9).
170
KAPITEL 4. DAS MAUTH DEMONSTRATIONSSYSTEM
Die Authentifizierung des PTD am Linux-PoA erfolgt über das Challenge-Response
Verfahren mit einem symmetrischen Kryptoalgorithmus. Da die Chipkartenapplikation nur den symmetrischen 3DES Algorithmus unterstützt, bietet sie auch nicht die
Möglichkeit Zertifikate abzuspeichern. PTD und PoA müssen somit über den selben
geheimen Schlüssel verfügen.
Dieser Schlüssel ist zusammen mit der ID und weiteren Daten des Benutzers in der
Zugangsdatenbank des Linux-PoA-Servers abgelegt. Die Datenbank ist als ASCIITextdatei realisiert.
Da das Demonstrationsystem keine Neuanmeldung bei der Nutzerdatenbank über ein
drahtloses Medium unterstützt, muß der PoA-Server auch über kein spezielles Administratorinterface verfügen. Neue Zugangsberechtigungen werden durch manuelles
Eintragen der Daten in die entsprechende Datei des Servers vergeben.
4.2
4.2.1
Entwicklung
Die Chipkartenapplikation
Da als Chipkarte eine Sm@rtcafé Javacard verwendet wird, ist die mAuth default Chipkartenanwendung in der Programmiersprache Java verfaßt. Sie ist weitgehend gemäß
dem Zustandsautomat aus Abschnitt 2.8.4 aufgebaut. Ihr Quellcode besteht aus den
beiden Dateien:
• mAuthDeclarations.java : In diesem Interface sind die wichtigsten Konstanten
definiert. Es erfüllt einen einer Header Datei in der Sprache C vergleichbaren
Zweck.
• mAuth.java : Dies ist der eigentliche Programmcode der Chipkartenanwendung.
Die Datei mAuth.java enthält die Klasse mAuth, welche von der Superklasse aller
Javacard-Anwendungen Applet erbt. Sie implementiert folgende 3 Methoden:
• install(byte[] buffer,short offset,byte length) : Diese Methode wird
nur einmal aufgerufen und zwar direkt nach dem Ladevorgang des Applets auf die
Chipkarte. Erst dann ist die Anwendung selektierbar. In meiner Anwendung ist
die einzige Aufgabe dieser Methode die Bildung einer Instanz der Klasse mAuth.
• mAuth() : Der Konstruktor wird bei der durch install initiierten Instantierung der Klasse ausgeführt. Hierin werden hauptsächlich Daten und Variablen
initialisiert. Schließlich wird durch Aufruf der Methode register der Installationsvorgang der Anwendung abgeschlossen.
• process(APDU apdu) throws ISOException : Bei jedem Empfang einer APDU
wird diese Methode ausgeführt. Sie wertet das empfangene Datenpaket aus, reagiert entsprechend und sendet eine Antwort zurück.
4.2. ENTWICKLUNG
171
Als Benutzer ID verwendet meine Applikation die Seriennummer der Chipkarte. Sie
kann damit nicht beliebig verändert werden, sondern ist fest an eine bestimmte Karte
gebunden.
Befehl
GetID
GetCap
VrfPIN
Encrypt
DeCrypt
SetKey
SetPIN
Code
0x10
0x13
0x30
0x40
0x41
0x20
0x23
Par1
–
–
Type
At+Kt
At+Kt
At+Kt
Type
Par2
–
–
–
BlNr
BlNr
BlNr
–
Daten
–
–
PIN
Data
Data
Key
PIN
Antwort
0xFF <ID> SW1 SW2
0xFF <Cap> SW1 SW2
SW1 SW2
BlNr <ciper Data> SW1 SW2
BlNr <plain Data> SW1 SW2
SW1 SW2
SW1 SW2
Case
2
2
4
4
4
4
4
Tabelle 4.1: Übersicht über die implementierten Funktionen der mAuth Chipkarte
0xFF :
SW1 :
SW2 :
At+Kt :
BlNr :
Blockende, da hier immer nur ein Antwortpaket!
Status Word (erstes Byte)
Status Word (zweites Byte)
Algorithmus Typ & Key Typ
Block Nummer
In Tabelle 4.1 sind alle implementierten Kommandos aufgeführt. Ebenso zeigt sie deren
Format und den Aufbau der Rückantwort auf jeden Befehl.
Als kryptographischer Algorithmus wird ausschließlich Tripple-DES im ECB Modus
eingesetzt. Da dafür bereits im Programmcode ein default Schlüssel eingetragen ist,
der mit dem entsprechenden Befehl jedoch jederzeit später geändert werden kann, sind
auch die Karten-Capabilities schon hier statisch definiert.
Durch den Verzicht auf asymmetrische Algorithmen und Zertifikate passen die Nutzerdaten problemlos in jeweils eine APDU. Die Unterstützung mehrteiliger APDUs und
somit der Blocknummerierung ist damit nicht notwendig, und auch nicht implementiert. Die Blocknummern-Felder BlNr in den Request APDUs werden ignoriert. Bei
Antworten enthält das entsprechende Feld immer den Wert 0xFF.
4.2.2
Der PoA
4.2.2.1
Überblick
Als Demonstrations-PoA dient ein Linux-PC. Die Reaktion auf einen erfolgreichen
Authentifikationsprozeß ist die Gewährung des Zugangs zu diesem Rechner. Um diese
Authentifikation möglichst flexibel zu gestalten, ist der PoA-Server in Form eines PAMModuls (vergleiche hierzu Abschnitt 3.4) umgesetzt worden.
172
Die Entwicklung und Erprobung der Server-Software fand auf dem in Abbildung 4.1
dargestellten Laptop statt. Die Software sollte jedoch auch auf jedem anderen LinuxPC mit IrDA- und PAM-Unterstützung lauffähig sein.
Abbildung 4.1: Der Demonstrations PoA-Server
Der Quellcode ist in folgende Dateien aufgegliedert:
• poa Server.c : Hierin ist annähernd die gesamte Funktionalität des Servers enthalten. Die zentrale Funktion darin ist mAuth. Sie initialisiert den Serversocket,
hört auf eingehende Verbindungen und bearbeitet die empfangenen Befehle. Nur
bei einer erfolgreichen Authentifizierung gibt sie die Kontrolle mit einem entsprechenden Rückgabewert an die aufrufende Funktion zurück.
• poa Server.h : Hierin sind die Definitionen wichtiger Konstanten und Strukturen
ausgelagert.
• poa test.c : Mit diesem Programm ist das Testen der Funktionalität des Servers auch ohne PAM Umgebung möglich. Es enthält im Prinzip nur die Funktion
main(), welche wiederum mAuth() aus poa Server.c aufruft. Damit kann der
Server von der Kommandozeile aus gestartet werden. Eine erfolgreiche Authentifizierung beendet das Programm.
• pam mauth.c : Das ist der Quellcode des PAM Moduls (siehe Abschnitt 4.2.2.2).
Der Programmablauf ist dabei an den, im mAuth Konzept in Abschnitt 2.8.6 vorgestellten, Automaten angelehnt. Die von mAuth aufgerufene Funktion poaConnect
initialisiert die Infrarot-Verbindungsparameter und wartet auf eingehende Anfragen eines Clients. Sobald eine TinyTP Verbindung besteht wird die Funktion poaProcess
aufgerufen. Sie empfängt eingehende Befehle und reagiert darauf entsprechend dem
Befehlscode und dem Server-Betriebszustand.
4.2. ENTWICKLUNG
173
Der Server kennt folgende drei Zustände:
• not connected : Das ist der initiale Zustand unmittelbar nach dem Start.
• connected : Nach einem mAuthOBEX Verbindungsaufbau und einer Übereinstimmung der empfangenen Nutzer ID mit einem Eintrag in der PoA-Datenbank
befindet sich der Server in diesem Zustand.
• authenticated : In diesen Zustand tritt der Server nach einer erfolgreicher
Durchführung des Challenge-Response Verfahrens ein.
Sind in einem Request auch Header enthalten, so werden diese durch die Funktion
parseHeader der Reihe nach abgearbeitet. Abhängig von dieser Auswertung können
Aktionen wie das Durchsuchen der Datenbank nach einer Benutzer ID, das Erzeugen
einer Challenge, das Überprüfen einer Response, usw. ausgelöst werden. Diese Abläufe
sind ebenfalls in eigene Funktionen gekapselt. Je nach Ausgang dieser Aktionen ändert
sich der Server-Zustand.
Der Betriebszustand, sowie sitzungsspezifische Daten wie z.B die Challenge oder der
Session-Key sind in einer Datenstruktur gespeichert. Diese Daten müssen, um keine Sicherheitslücken zu schaffen, bei Beendigung einer Sitzung gelöscht und neu initialisiert
werden.
Die Beendigung einer physikalischen Verbindung ist bei diesem Demonstrationsystem
jedoch nicht unbedingt mit einem Ende der Sitzung gleichzusetzen. Aus in Abschnitt
4.2.3.3 näher erläuterten Gründen muß der hier verwendete PTD die Infrarotverbindung zwischen dem Aussenden der ID und dem zweiten Connect-Request mit gültiger
Response kurz unterbrechen. Der Server darf jedoch in diesem Falle seine SitzungsDatenstruktur nicht neu initialisieren, sondern muß zumindest die Challenge beibehalten.
Dieser Fall eines Verbindungsabbruchs kann daran erkannt werden, daß dieser Abbruch
unmittelbar nachdem der Server in den Betriebszustand connected gewechselt hat die Nutzer ID also akzeptiert und eine Challenge ausgesandt wurde - auftritt. Nur
unter diesen Voraussetzungen behält der Server die Datenstruktur bei und wartet auf
eine neue Verbindung.
Dieses Verhalten stellt aber einen Schwachpunkt des Systems dar, und kann für einen
Angriff genutzt werden. Daher sollte es in einer endgültigen Realisierung so nicht beibehalten werden. Bedingt durch die verwendete PDA Hardware, war dieser Kompromiß
jedoch notwendig und für ein Demonstrationsystem auch vertretbar.
Der Server reagiert nur auf Verbindungsanfragen, die an den LSAP-Selektor des
Dienstes, welcher beim IAS auf den Namen mAuth:OBEX registrierten wurde, gerichtet sind. Die OBEX Hintbits sind dabei gesetzt. Alle in den Tabellen 4.2 und 4.3
aufgeführten Befehle und Header werden vom Server erkannt.
174
Code
0x90
0x80
0x81
0xFF
0x82
mAuthOBEX Befehl
PeerDisc
Connect
Disconnect
Abort
Put
Anmerkungen
nur mit final Bit!
keine Unterstützung für Objekte, die
sich über mehrere Pakete erstrecken.
Tabelle 4.2: Die vom Server unterstützten mAuthOBEX Befehle
Code
0x70
0x71
0x72
0x73
0x74
0x75
0x76
0x77
0xB8
mAuthOBEX Header
mAuthID
mAuthChallenge
mAuthResponse
mAuthSessionKey
CapAuth
CapLink
CapApp
PeerDescription
Crypt
Tabelle 4.3: Die vom Server erkannten mAuthOBEX Header
Zur Durchführung kryptographischer Funktionen werden die, im Programmpaket
OpenSSL (http://www.openssl.org) enthaltenen, Routinen der Crypto-Bibliothek
verwendet.
Da dort mehrere Varianten des 3DES Algorithmus existieren, war nicht
eindeutig klar, welche Methode von der Javacard zur Verschlüsselung verwendet wird. Durch kleine Testprogramme, mit denen ich versuchte einen
von der Chipkarte verschlüsselten Text zu dechiffrieren, konnte ich die korrekte Variante ( des ecb2 encrypt(des cblock *input, des cblock *output,
des key schedule ks1, des key schedule ks2, int enc) ) ermitteln.
Die Zugangsdatenbank des PoA-Servers ist vergleichbar der Unix Passwort Datei als
ASCII Textfile ausgeführt. Jeder Eintrag eines Nutzers entspricht einer Zeile in dieser
Datei. Die einzelnen Felder sind mittels Doppelpunkte voneinander abgetrennt.
LOGIN_NAME
:
ID
:
KEY
Neben ID und KEY, welche beide in ASCII-Darstellung ihrer Hexadezimalewerte abgelegt werden, muß zu jedem Eintrag die zugehörige Unix Kennung vorhanden sein.
Die Datei sollte nur für den Systemverwalter root les- und schreibbar sein.
4.2. ENTWICKLUNG
4.2.2.2
175
Das PAM Modul
Da der PoA-Server nur die PAM Funktion auth unterstützen soll, war in der Quelldatei
des PAM Moduls pam mauth.c nur die Funktion
PAM_EXTERN int pam_sm_authenticate( pam_handle_t *pamh, int flags, \\
zu implementieren. Die übrigen fünf PAM-Funktionsaufrufe enthalten keinen Progragrammcode und liefern immer PAM SUCCESS als Return-Wert zurück.
Die Funktion pam sm authenticate ruft die Routine mAuth auf und überprüft deren
Rückgabewert. Signalisiert dieser eine erfolgreiche Authentifizierung, muß der PAM
Bibliothek und darüber den PAM nutzenden Anwendung wie z.B. dem Programm
Login der betreffende Unix Benutzername mitgeteilt werden.
Die Funktion mAuth übergibt diesen Namen an das PAM Modul. Dieses reicht ihn
mittels dem Aufruf pam set item an die PAM Bibliothek weiter.
Das mAuth Konzept sieht für den PoA die Implementierung von timeouts vor. Damit
soll ein Blockieren des Servers durch nicht korrekt beendete Verbindungen verhindert
werden. Diese Timeouts sind im Demonstrationsystem nicht explizit realisiert. Die
PAM Bibliothek startet jedoch ein Authentifizierungsmodul, das 60 Sekunden nach
seinem Aufruf keine Rückmeldung erbracht hat, automatisch neu. Über diesen Mechanismus wird auch der PoA-Server regelmäßig neu initialisiert, und darüber die geforderte Funktionalität erbracht.
4.2.2.3
Modifikation des Mingetty Programms
Der Login Vorgang an einer Textkonsole eines Linux-Systems wird meist von dem
Programm mingetty kontrolliert. Zur Überprüfung der Zugangsberechtigung ruft dies
das Programm login auf, das seinerseits wiederum die Benutzerauthentifikation an
PAM übergibt.
Durch eine entsprechende Modifikation der PAM Konfiguration wird login veranlasst,
zur Authentifikation anstatt des Unix Passwort Moduls das mAuth PAM Modul zu
verwenden.
Das Problem dabei ist nur, daß die erste Aufforgerung zur Eingabe eines Benutzernamens von mingetty direkt erfolgt. Mit diesem Namen als Parameter ruft es dann login
auf. Dadurch würde der mAuth Server erst nach Eingabe irgendeines Nutzernamens
gestartet. Um das zu verhindern habe ich die Sourcen vom mingetty so verändert,
daß diese Abfrage deaktiviert wird. Das modifizierte Programm startet nun sofort das
mAuth PAM Modul, und wartet auf eingehende Verbindungen.
176
4.2.3
Der PTD-Client
4.2.3.1
Überblick
Das PTD des Demonstrationssystems besteht aus einem Handspring Visor Platinum
PDA mit angeschlossenen externen Chipkarten-Lesegerät Towitoko Chipdrive micro
100 (vergleiche dazu die Abschnitte 3.7.3 und 3.11).
Die Entwicklung der PTD-Client-Software erfolgte auf einem Linux-System mit dem
GNU-PalmOS-Entwicklungswerkzeugen (vergleiche Abschnitt 3.9). Auch hier ist die
Implementierung an den Referenzautomaten aus Abschnitt 2.8.5 angelehnt.
Abbildung 4.2: Der Demonstrations PTD-Client
Mein PTD-Client unterstützt ausschließlich das Applikationsmodell Zugang. Um das
System einfach und überschaubar zu halten, wurden auf Verwaltungsfunktionen wie
das Ändern der Karten PIN oder die drahtlose Übertragug der Anmeldedaten zu neuen PoAs oder zu einem Trustcenter, verzichtet. Dies erschien mir gerechtfertigt, da
diese Funktionen zwar im praktischen Betrieb für den Benutzer wichtig sind, jedoch
4.2. ENTWICKLUNG
177
keinen wesentlichen Beitrag zur Demonstration der Funktionalität des mAuth Konzepts liefern.
Abbildung 4.2 zeigt das mobile Gerät mit dem Chipkarten-Lesegerät sowie dem umgebauten USB Verbindungskabel und dem externen Batteriepack. Die Platine mit dem
Signalinverter befindet sich im Bild unter den Batterien und hinter dem ChipkartenReader. Die im Bild links befindliche Kombination aus Chipkartenterminal, Batteriepack und Inverter-Elektronik ist an der Springboard-Schachtabdeckung des Visor
Platinums befestigt, und kann auf dessen Rückseite aufgeschoben werden.
Neben den, in Abschnitt 3.8 bereits beschriebenen, Besonderheiten bei der Programmentwicklung für PalmOS waren noch weitere Schwierigkeiten zu lösen. Da derzeit noch
keine PDAs auf die Integration von Chipkarten-Lesegeräten vorbereitet sind, fehlt auch
eine entsprechende Unterstützung in der API ihrer Betriebsysteme. Da hier das Lesegerät über den seriellen Port angeschlossen ist, erfolgt der Zugriff darauf mit den
Funktionen des PalmOS-Serial Managers.
4.2.3.2
Anpassung der SCEZ Chipcard Library
Zur Ansteuerung des Kartenterminals sowie zur Kommunikation mit der Karte selbst,
sind Protokolle notwendig. Da diese vom Typ der Karte und dem Hersteller des Lesegerätes abhängig sind, ist es sinnvoll diese Funktionalität aus dem Programmcode der
Anwendung auszulagern.
Matthias Bürstle schuf zu diesem Zwecke die SCEZ Chipcard Library. Diese Programmierbibliothek unterstützt eine Vielzahl von Chipkarten-Lesegeräten, und bietet eine
API für die gebräuchlichsten Karten. Sie läßt sich für viele Betriebssysteme - darunter
auch Linux - übersetzen und ist sogar auch auf PalmOS portiert. Für PalmOS ist die
Bibliothek in Form von GLib shared Libraries realisiert.
Sie ist in aufeinander aufbauende Funktionsmodule strukturiert. Beginnend bei dem
untersten“ Modul setzt sich die Bibliothek aus folgenden Teilen zusammen:
”
• serial Input/Output: Diese Modul stellt die Basisfunktionen zum Aussenden
und Empfangen von Daten über die serielle Schnittstelle zur Verfügung.
• Kartenlesegerät-Treiber: Sie enthalten die Kommandosequenzen, um Funktionen des jeweiligen Kartenterminals anzusteuern.
• Chipkarten Kommunikationsprotokolle: Diese Module wickeln die Kommunikationsprotokolle wie z.B. T=1 oder T=0 mit der Chipkarte ab.
• Kartenspezifische Treiber: Das sind Interfaces, mit Hilfe deren Funktionen
bestimmte Karten komfortabler, als über das selbständige Zusammenstellen und
Aussenden entsprechender APDUS angesprochen werden können.
• Allgemeines Programmier-Interface: Diese Sammlung von Funktionen stellt
das allgemeine Interface für die Basis-Funktionalität der Library dar. Zur reel-
178
len Ausführung ruft es die entsprechenden tieferliegenden Module auf. Dadurch
können unabhängig von der eingesetzten Karte und Terminal immer die gleichen
Funktionen verwendet werden.
Durch diese übersichtliche Struktur sind eigene Anpassungen leicht möglich. Dies
und die Tatsache, daß in dieser Bibliothek bereits sowohl ein Treiber für die Towitoko Chipkarten-Lesegeräte sowie ein Interface und kleine Dienstprogramme für die
Sm@rtcafé Javacard enthalten sind, waren für mich ausschlaggebend die SCEZ Chipcard Library zu verwenden. Genauere Informationen zur den einzelnen Modulen und
zur Programmierung damit sind in [Bü00] nachzulesen.
Während der Entwicklungsarbeit für das Demonstrationssystem reduzierte ich die
Sourcen der SCEZ Bibliothek auf die von mir benötigte Funktionalität. Im Vorfeld
der Entwicklung diente mir das, im SCEZ Paket enthaltene und für meine Zwecke angepaßte, kleine PalmOS-Demoprogramm scdir, für Versuche mit der Kopplung aus
Palm und Chipdrive sowie zum Sammeln von Erfahrungen im Umgang mit Programmierung der Bibliothek.
Ich entwickelte ein eigenes SCEZ Chipkarten-Modul, mit dem alle Funktionen der
mAuth Chipkarte des Demosystems mittels C-Funktionen aufgerufen werden können.
Aufgabe dieses Moduls ist die Zusammenstellung der übergebenen Daten zu entsprechenden APDUs, ihr Aussenden an die Chipkarte sowie die Auswertung der Antwort
darauf. Sollte in einer späteren Version die Übertragung von Daten, die auf Grund ihrer Größe mehrere APDUs zum Transport benötigen, realisiert werden, wird in diesem
Modul die Aufteilung auf die einzelnen Blöcke sowie die Überwachung der korrekten
Reihenfolge umgesetzt werden. Weiterhin entstand ein kleines Linux-Programm mit
dem die Funktionen meiner Chipkarten-Applikation getestet werden können.
4.2.3.3
Probleme bei der gleichzeitigen Verwendung von IrDA und der
seriellen Schnittstelle
Wegen einer Besonderheit der Hardware des Handspring Platinums, waren noch weitere Veränderungen an den Sourcen der Library notwendig. Der Handspring Platinum
besitzt nur einen UART Controller. Da dieser sowohl von der Infrarotschnittstelle, als
auch vom seriellen Port genutzt wird, ist deren gleichzeitige Verwendung nicht möglich.
Zwar ist beim Start der Anwendung noch keine Infrarot-Kommunikation notwendig,
sodaß die Initialisierung der Chipkarte mitsamt der PIN Überprüfung noch problemlos
möglich ist. Später beim eigentlichen Authentifikationsprozeß werden jedoch eigentlich
beide Schnittstellen gleichzeitig benötigt. Grundsätzlich kann keine der beiden Kommunikationsprozesse problemlos unterbrochen und wiederaufgenommen werden.
Ein Schließen der Infrarot Library zur Freigabe des UARTs für den seriellen Port
führt zwangsläufig zum Abreissen der IrDA-LAP-Verbindung und damit nach kurzer
Zeit auch zu einem Verbindungsabbau der darüberliegenden Schichten. Da sich dieses
Problem aber mit der gegebenen Hardware nicht umgehen läßt, wurde der PoA-Server
4.2. ENTWICKLUNG
179
entsprechend modifiziert, um diesen speziellen Fall zu berücksichtigen. Er ermöglicht
nun einen neuen Kommunikationsaufbau und die Fortsetzung des Protokolls im selben
Serverzustand, selbst nachdem die Verbindung unterbrochen worden ist. Dies ist für
ein Demonstrationssystem akzeptabel, sollte aber bei einer engültigen Implementierung
aus Sicherheitsgründen auf keinen Fall beibehalten werden.
Ein Abbruch der Kommunikation mit der Chipkarte, sollte dagegen weniger Probleme
bereiten. Im Idealfall registriert die Chipkarte gar keine Veränderung. Das Chipkartenterminal empfängt für die Zeit, in der der serielle Port geschlossen ist, einfach keine
neuen Befehle. Sowohl Karte als auch Terminal verweilen im gerade aktuellen Zustand.
Wird der Port wieder geöffnet, sollte die Kommunikation an der unterbrochenen Stelle
fortgesetzt werden können.
Zu diesem Zwecke erweiterte ich das serielle Input/Output-Modul und den Towitoko
Chipkartenterminal-Treiber der SCEZ Library um zwei Funktionen:
• SerSuspend: Schließt die serielle Schnittstelle, und gibt somit den UART für die
Infrarot-Kommunikation frei.
• SerReaktivate: Öffnet den seriellen Port wieder.
Nach der Initialisierung der Karte und der PIN Überprüfung gibt SerSuspend den
UART für das IrDA basierende PeerDiscovery und für die Initialisierung eines Authentifikationsprozesses frei. Nach Empfang der Server-Challenge muß jedoch die Chipkarte
die entsprechende Response berechnen. Dazu ist eine Kommunikation mit der Karte
unbedingt notwendig. Nach dem Schließen der Infrarot-Library wird die serielle Schnittstelle daher mit SerReaktivate wieder geöffnet. Wurde die Response berechnet und
an das mobile Gerät zurückgeliefert, wird der serielle Port wieder stillgelegt und die
Infrarot-Kommunikation an der unterbrochenen Stelle fortzusetzen.
Dieses Verfahren funktioniert auf dem PalmOS-Emulator einwandfrei. In der Praxis auf dem realen Visor - war es jedoch nicht möglich die einmal unterbrochene Kommunikation mit dem Chipkartenterminal wieder aufzunehmen. Durch Versuche stellte
sich heraus, daß der Visor offenbar nach dem Schließen der seriellen Schnittstelle noch
irgendwelche Signale auf den seriellen Port schickt. Diese versetzen das Chipkartenterminal in einen undefinierten Zustand. Der Grund für dieses Verhalten konnte nicht
eindeutig geklärt werden. Ich vermute jedoch die Ursache im bereits beschriebenen
Handspring Keyboard-Daemon.
Zieht man das serielle Kabel sofort nach der Deaktivierung des Ports ab, und steckt es
erst kurz vor der Reaktivierung wieder an, funktioniert dieser Prozeß. Das läßt zumindest darauf schließen, daß es sich wirklich um ausgesandte Signale auf dem deaktivierten
Port handelt und nicht um ein Problem des Chipkartenterminals.
180
Als Lösung, schließe ich in der SerSuspend Funktion nicht nur die Schnittstelle, sondern
baue die Kommunikation zum Chipkartenterminal vollständig ordnungsgemäß ab. Im
Gegenzug dazu muß die Funktion SerReaktivate die komplette Kommunikation zum
Terminal neu aufbauen. Das bedeutet u.a. ein Karten-Reset durchzuführen, die mAuth
Applikation zu selektieren und die PIN erneut zu verifizieren. Dazu ist es notwendig
die PIN nach der ersten Eingabe temporär im mobilen Gerät gespeichert zu halten.
Auch dieses potentielle Sicherheitsrisiko würde sich beim Einsatz einer Hardware mit
zwei separaten UARTs erübrigen.
4.2.3.4
SSLeay Crypto-Library für PalmOS
Gemäß dem mAuth Konzept ist die Verschlüsselung der Kommunikation auch beim
Demonstrationssystem die Aufgabe des mobilen Gerätes. Dazu muß die mAuth Anwendung auf dem Palm PDA kryptographische Algorithmen ausführen. Diese Funktionalität ist nicht im PalmOS enthalten, und muß durch eigene Routinen zur Verfügung
gestellt werden.
Mit pilotSSLeay Version 2.01 existiert eine Portierung der SSLeay Crypto-Library
auf PalmOS. SSLeay ist ein Vorgänger der OpenSSL-Bibliothek, welche auch bei der
Programmierung des PoA-Servers eingesetzt worden ist. PilotSSLeay-2.01 basiert auf
SSLeay-0.8.1.
Ian Goldberg hat die wichtigsten kryptographischen Funktionen daraus auf PalmOS portiert, und diese in Form mehrerer GLib shared Libraries unter dem Namen
PilotSSLeay-2.01 veröffentlicht. Zumindest die API der von mir benötigten 3DES Funktionen blieb bis zur neusten Version der OpenSSL Bibliothek weitgehend unverändert.
So konnte ich die Funktionen zur Verarbeitung von mAuthOBEX Crypt-Headern, welche ich bereits für den PoA-Server entwickelt hatte, auch auf dem PDA Client verwenden.
4.2.3.5
Entwicklung eigener IrDA-Funktionen in Form der MyIrLib
Zur Kommunikation mit dem PoA mußte auch auf dem Client das mAuthOBEX Protokoll implementiert werden. Das PalmOS unterstützt IrOBEX durch den Exchange
Manager. Die API des Exchange Manager bietet aber nur Funktionen zum Austausch
von Datenobjekten an. Die dazu notwendigen OBEX Kommandos wickelt der Exchange
Manager intern - für den Anwendungsprogrammierer nicht beeinflußbar - ab. Somit war
es damit weder möglich den erweiterten Verbindungsaufbau des mAuthOBEX, noch
das Peer Discovery oder die erweiterten Header einzubinden.
PalmOS bietet jedoch mit der IrLibrary eine API um auf die IrDA-Grundfunktionen zuzugreifen. Allerdings ist diese API sehr low level“ und erfordert relativ genaue Kennt”
nisse des IrDA-Protokolls, um damit Anwendungen zu realisieren. Der Programmierer
4.2. ENTWICKLUNG
181
muß sich um Vorgänge wie das LAP Peer Discovery, IAS Queries und den Verbindungsaufbau aller darauf aufsetzenden Schichten selbst kümmern.
Für meine Zwecke wäre eine API, die einen Verbindungsaufbau auf TinyTP Ebene
ermöglicht und Routinen zum Senden und Empfangen von Daten zur Verfügung stellt,
wünschenswert gewesen. Um diese Abstraktion zu erreichen, müssen die “low level“
Funktionen der PalmOS-IrLibrary in eigene Routinen gekapselt werden, welche sich
um die notwendigen Aufrufe und die Abwicklung des Verbindungsaufbaus in allen
unteren Schichten - beginnend bei LAP - kümmern.
Mein Ziel war es ein benutzerfreundlicheres Interface zum Aufbau von IrDAVerbindungen zu schaffen, das von seiner Anwendung an den Berkeley Socket Mechanismus angelehnt ist. Im einzelnen entstanden dazu folgende Funktionen:
• int MyIrOpen ( ): Initialisiert alle Datenstrukturen und öffnet die IrLibrary des
PalmOS.
• int MyIrDiscover ( IrDeviceAddr *dev, int timeout ):
Führt
einen
IrDA-LAP-Discovery-Vorgang durch und liefert eine Liste der gefundenen
Geräteadressen zurück.
• int MyIrConnect ( IrDeviceAddr deviceAddr, char *service, int
timeout ): Baut zu der angegeben IrDA-LAP-Adresse eine TinyTP Verbindung
auf.
• int MyIrSend ( BYTE *data, int len, int timeout ): Sendet über eine bestehende Verbindung einen beliebigen, übergebenen Bytestrom aus.
• int MyIrReceive ( BYTE *data, int *len, int timeout ): liefert einen
empfangenen Bytestrom zurück. Sind bei Aufruf keine Daten im Empfangspuffer,
wartet die Funktion bis ein Paket angekommen ist oder bis der Timeout eintritt.
• int MyIrDisconnect ( int timeout ): Baut die bestehende Verbindung aller
Schichten ab.
• int MyIrClose ( ): Gibt den allozierten Speicher frei und schließt die IrLibrary.
Bei der Verfolgung diese Konzepts ergaben sich jedoch mehrere Probleme. PalmOS
ist ein ereignisgesteuertes Betriebssystem. Der zentrale Teil aller Palm Anwendungen ist daher die Event Loop. Während sich das Programm in dieser Schleife befindet, auf eingehende Events wartet, diese auswertet und abarbeitet, werden auch die
Betriebssystem-Funktionen ausgeführt. Meine IrDA-Routinen sollen jedoch nach ihrem Aufruf, erst nachdem sie das gewünschte Ergebnis geliefert haben, wieder in den
Programmablauf zurückkehren. Die Ausführung der Event Loop wäre damit so lange
unterbrochen.
182
Disconnected
Medium busy
initiate LAP Connect
pending
timeout
LAP
disconnected
wait for IrCallback
timeout
LAP
connected
LAP
disconnected
Medium busy
initiate IAS Query
LAP
disconnected
pending
timeout
wait for IASCallback
Medium busy
LSAP
selector
returned
initiate TinyTP
timeout
pending
timeout
wait for IrCallback
TP
connected
timeout
Connected
SUCCESS
Abbildung 4.3: Automat der MyIrConnect Funktion
4.2. ENTWICKLUNG
183
Alle Aufrufe von IrLibrary Kommandos können auch scheitern. Der häufigste Grund
hierfür ist eine Medium Busy Fehlermeldung, welche besagt, daß gerade ein anderes
IrDA-Gerät das Medium für sich nutzt. Daher muß der Rückgabewert jedes Funktionsaufrufs überprüft und das Kommando solange neu abgesetzt werden, bis es eine
erfolgreiche Rückmeldung erzeugt. Eine positive Rückmeldung besagt aber nur, daß
die betreffende Funktion gestartet werden konnte; das Ergebnis wird meist durch eine
Callback Funktion zurückgegeben.
Hat eine Funktion ein IrLibrary Kommando erfolgreich starten können, muß auf den
Aufruf dieser Callback Funktion gewartet werden, um das Ergebnis zu erhalten. Das
Problem dabei ist, daß während des Wartens die IrDA-Library ausgeführt werden muß.
Das ist normalerweise bei einer Rückkehr in die Event Loop der Anwendung kein
Problem. Da meine Funktionen jedoch erst nach ihrer vollständigen Ausführung zur
normalen Anwendung“ zurückkehren, mußte ich dafür sorgen, das die Palm IrLibrary
”
innerhalb“ meiner Routinen ausgeführt wird.
”
Dazu besitzt jede Funktion eine kleine interne EventLoop“. Innerhalb dieser Schleife
”
wird bei jedem Durchlauf überprüft, ob das betreffende IrLibrary-Kommando erfolgreich gestartet werden konnte und bei Bedarf erneut aufgerufen. Desweiteren werden
mittels EventGetEvent anstehende Ereignisse aus der Event-Queue entnommen und
SysHandleEvent sowie die IrLibrary interne Funktion IrHandleEvent zu deren Verarbeitung aufgerufen. Damit ist sichergestellt, daß die IrLibrary ausgeführt wird und die
Callback Funktion aufgerufen werden kann. Der Aufruf der Callback Funktion setzt
entsprechend seines Ergebnises ein Flag, das von der eben beschriebenen Schleife erkannt wird und diese bei erfolgreichen Ergebnis zum Verlassen veranlaßt.
Da die Callback Funktion jedoch nicht zwangläufig einen Erfolg zurückmeldet, mußte zusätzlich ein Timeout Mechanismus in den Funktionsaufrufe vorgesehen werden.
Beim Funktionsaufruf wird die maximale Ausführzeit als Parameter übergeben. Der
EvtGetEvent Aufruf erfolgt so, daß, falls nach 100 ms kein Ereignis eingetreten ist,
ein NilEvent generiert wird. Somit ist sichergestellt, daß ein Schleifendurchlauf nur
unwesentlich länger als maximal 0,1 Sekunden dauert. Durch einen einfachen Zähler
kann so die Überschreitung der vorgegebenen Ausführzeit bestimmt werden. Ist nach
Ablauf des Timeouts noch keine erfolgreiche Rückmeldung durch die Callback Funktion erfolgt, wird die Schleife dennoch verlassen. Die Funktion liefert als Rückgabewert
jedoch einen entsprechenden Fehlercode zurück.
Abbildung 4.3 zeigt am Beispiel der Struktur der MyIrConnect Funktion diesen Mechanismus. Da im Connect-Vorgang mehrere PalmOS-IrLibrary-Funktionen, deren
Ausführung voneinander abhängt, aufgerufen werden müssen, ist diese die komplizierteste Struktur der MyIr-Routinen.
Die Realisierung einer Event Loop innerhalb der MyIr-Funktionen stellte sich in der
Praxis jedoch als kritisch heraus. Es bedurfte ausgiebiger Tests und wiederholter Änderungen und Optimierungen des Programmcodes, um eine stabile Ausführung zu erreichen. Bei den ersten Versionen kam es vor allem oft zu Systemabstürzen des Pal-
184
mOS mit der Fehlermeldung Pen queue out of sync“. Das Problem liegt vermut”
lich in der Entnahme von Pen-Events aus der Warteschlange außerhalb der HauptEventschleife. Eigentlich sollte dies kein Problem darstellen, da die in dieser Zeit aufgelaufene Pen-Events für die Programmausführung uninteressant sind, jedoch scheint
das betriebssysteminterne Probleme zu verursachen. Dieses Verhalten konnte weitgehend durch den Aufruf der Funktion EvtFlushPenQueue nach der Abarbeitung der
MyIr-EventLoop beseitigt werden.
Ursprünglich plante ich diese Funktionen in Form einer GLib shared Library umzusetzen. Die Bibliothek ließ sich auch problemlos kompilieren und wird in der aktuellen
Version auch noch mitübersetzt, jedoch traten bei ihrer Benutzung zur Laufzeit Fehler auf, die zum Systemabsturz führten. Ich vermute die Probleme in der Verwendung
globaler Variablen und in der eventuell auftretenden Veränderung der Callback Startadresse bei wiederhohlten Aufruf der Funktionen. Da die MyIr Funktionensammlung
jedoch sehr klein ist, entschloß ich mich, um eine zeitaufwendige Fehlersuche zu vermeiden, die Objektdatei direkt zum Programmcode des PTD-Clients zu linken; anstelle
eine Bibliothek zu erzeugen und diese einzubinden.
4.3. INSTALLATION
4.3
185
Installation
Sämtliche Programme, die im Rahmen dieser Arbeit entstanden, liegen als Source Code
vor. Mittels dem Makefile im Hauptverzeichnis des Source-Verzeichnisbaumes können
- durch Eingabe von make - alle Anwendungen übersetzt werden. Voraussetzung dafür
ist, daß die in den folgenden Abschnitten aufgeführten Systemvorausetzungen erfüllt
und die notwendigen Tools installiert sind.
Es ist auch möglich, alle Systemteile unabhängig voneinander zu kompilieren. Jede
Komponente enthält dafür in dem betreffendem Verzeichnis ein eigenes Makefile. In
jedem Verzeichnis ist darüberhinaus eine README Datei vorhanden, die den Übersetzungsvorgang und den Aufbau der Sourcen näher beschreibt.
Der Source-Verzeichnisbaum ist wie folgt aufgebaut:
• PTD-Client/: Sourcen des PalmOS-Clients
– MyIrLib/: meine IrDA-Funktionen
– scez-20010519/: angepaßte und erweiterte Quellen der SCEZ Chipcard Library
– pilotSSLeay-2.01/: Bibliothek mit kryptographischen Funktionen für PalmOS
• PoA-Server/: Sourcen des PoA-Servers
– mingetty/: Angepasste Quellen des mingetty Programms
• Chipcard/: Quellcode zur mAuth Javacard Anwendung
Die Entwicklung erfolgte größtenteils auf einem Linux-System. Nur für wenige, spezielle
Aufgaben mußte auf die Windows Platform ausgewichen werden. Die Makefiles sind für
die Übersetzung auf einem Unix System ausgelegt. Sollten Teile oder die kompletten
Quellen unter einer anderen Entwicklungs-Plattform neu übersetzt werden, können
Anpassungen notwendig sein.
4.3.1
Chipkarte
4.3.1.1
notwendige Tools
Die Quellen der mAuth Chipkarten Applikation sind im Verzeichnis Chipcard/ enthalten. Das Kompilieren des Quellcodes kann auf einem beliebigen Rechnersystem, für
welches das Java SDK verfügbar ist, geschehen.
Im einzelnen setzt eine Neuübersetzung und die Installation der Anwendung auf der
Chipkarte folgende Komponenten voraus:
• Giesecke & Devrient Sm@rtcafé Javacard mit Krypto Funktionalität
186
• Chipkartenterminal
• Entwicklungs PC
• Java SDK ab Version 1.1.7
• G&D Smartcafe Professional incl. G&D Javacard Klassen
Giesecke & Devrient, der Hersteller der Sm@rtcafé Karte, hat die Klassen seiner Javacard im Vergleich zur original Javacard-API von SUN Microsystems etwas erweitert.
Diese Klassen werden zur Übersetzung benötigt und müssen sich im CLASSPATH
des Java Compilers befinden. Sie gehören zum Lieferumfang der Sm@rtcafé Professional Entwicklungsumgebung. Sie sind jedoch auch im Verzeichnisbaum meiner Sourcen
mitenthalten.
Zum Übertragen der in Bytecode übersetzten und in das .cap-Format umgewandelten,
Anwendung wird ein an den Entwicklungsrechner angeschlossenes Chipkartenterminal
benötigt. Die Sm@rtcafé Professional Entwicklungsumgebung akzeptiert dabei u.U.
nur ganz bestimmte Terminal-Fabrikate und -Typen. Ich verwendete erfolgreich das
Chipdrive extern des Herstellers Towitoko.
Der Upload von Chipkartenanwendungen ist jedoch auch mit dem in der SCEZ Bibliothek enthaltenen Programm cafeman möglich. Dieses und weitere Hilfeprogramme
können durch Eingabe von make Linux im SCEZ Verzeichnis erzeugt werden. Dabei
ist zu beachten, daß zuvor mit make clean eventuell noch vorhandene Objekt Dateien aus einem vorangegangenen Übersetzungsvorgang für die Palm-Plattform gelöscht
worden sind. Übersetzt man diese Hilfsprogramme zum ersten mal, müssen vor deren Verwendung noch mittels make install die notwendigen Linux-Libraries in das
System eingebunden werden. Dazu sind root-Rechte erforderlich. Mit cafeman können
Javacard Anwendungen im .cap-Format mit jedem, von dieser Bibliothek unterstützen
Kartenterminal, auf die Karte transferiert werden.
4.3.1.2
Übersetzen und Installieren
Vor dem Start eines Compilerlaufs ist gegebenenfalls das Makefile im Verzeichnis
Chipcard an die Umgebung des eingesetzten Entwicklungssystem anzupassen. Das gilt
vor allem für den Pfad des Java Compilers und den Klassenpfad der G&D Javacard
Klassen. Letzterer sollte, bei Verwendung der im Source-Verzeichnisbaum enthaltenen
Klassen, keiner Anpassung bedürfen.
Durch das Kommando make wird die Übersetzung gestartet. Die dabei erzeugten
.class-Dateien befinden sich anschließend im Unterverzeichnis mauth. Die Konvertierung in das .cap-Format muß mit dem, im Sm@artcafé Professional Programmpaket
enthaltenen, CAP-File-Konverter erfolgen. Der anschließende Upload auf die Karte
kann entweder direkt aus der Entwicklungsumgebung oder mit dem Tool cafeman erfolgen.
4.3. INSTALLATION
4.3.2
PTD-Client
4.3.2.1
notwendige Tools
187
Der Übersetzungsvorgang für die PTD-Anwendung findet, wie bereits erwähnt, auf
einem Cross-Developmentsystem statt. Dafür ist ein Entwicklungs-PC mit entsprechender Software notwendig. Im einzelnen werden folgende Komponenten benötigt:
• PalmOS-PDA ab OS Version 3.3
• Entwicklungs PC (vorzungsweise Linux)
• PRC-Tools 0.5.0
• PalmOS-SDK 3.3
• (SCEZ Chipkarten Bibliothek) - im Quellenbaum enthalten
• (PilotSSLeay-2.01) - im Quellenbaum enthalten
• Pinstall1 (oder sonstige Hotsync Software)
Vor dem Start des Kompilierens ist sicherzustellen, das die korrekte Version der PRCTools und des PalmOS SDKs installiert sind. Das SDK muß korrekt in die Verzeichnisstruktur der PRC-Tools eingebunden sein. Bei der Verwendung von neueren SDKs
können Probleme beim Übersetzten auftreten und Anpassungen des Quellcodes erforderlich sein. Der Einsatz neuerer PalmOS-Versionen auf dem PDA ist jedoch unkritisch.
Ältere Releases als 3.3 können jedoch, wegen der dort fehlenden IrDA-Unterstützung,
nicht verwendet werden.
4.3.2.2
Die PTD-Anwendung wird normalerweise durch Aufruf des Kommandos make im PTDClient Verzeichnis kompiliert. Dadurch werden die Makefiles der Programmkomponenten in deren Unterverzeichnissen in der korrekten Reihenfolge aufgerufen. Die einzelnen
Komponenten können durch diesen Aufbau falls gewünscht jedoch auch getrennt übersetzt werden. In den Makefiles sind gegebenenfalls die Pfade zu den PRC-Tools der
lokalen Systeminstallation anzupassen.
Nach dem Übersetzungsvorgang befinden sich die erzeugten .prc-Dateien im Verzeichnis
palminstall. Dort liegen sowohl die eigentliche Anwendung, als auch die Installationsdateien der benötigten shared Libraries. Alle Dateien in diesem Verzeichnis müssen auf
den Palm PDA übertragen werden. Das kann zum einen mit kleinen Hilfeprogrammen,
welche sowohl für Unix, als auch Windows und Macintosh zur Verfügung stehen, oder
mit dem Palm Desktop in einem normalen Hotsync-Vorgang erfolgen.
1
Pilot Install http://pinstall.envicon.com
188
4.3.3
PoA-Server
4.3.4
Voraussetzungen
Da der PoA-Server in Form eines PAM Moduls realisiert ist, sollte er theoretisch auf
jedem System, welches PAM zur Authentifikation benutzt, verwendet werden können.
Die IrDA-Kommunikation ist jedoch auf die Linux-IrDA-Implementierung ausgelegt.
Bei einem Einsatz auf anderen Systemen sind höchstwahrscheinlich Anpassungen in
den Kommunikationsfunktionen des Servers notwendig.
Der Quellcode des Demonstrations PoAs setzt folgende Komponenten voraus:
• Linux-System
• PAM
• Gcc-Compiler
• Openssl Bibliothek
• IrDA-Kernelmodul
• Root Systemzugang
Die IrDA-Funktionalität kann in Form eines dynamisch ladbaren Kernelmoduls realisiert, oder fest in den Kernel eingebunden sein. Weiterhin muß das IrDA-Subsystem
korrekt konfiguriert sein, das bedeutet u.a., daß das korrekte Device für den IrDATransceiver angegeben sein muß. Die Konfiguration erfolgt gewöhnlich durch eine Datei im /etc/ Verzeichnis. Bei einem Suse-Linux Systems ist dies die Datei
/etc/rc.config.
Desweiteren ist darauf zu achten, daß das IrDA-Subsystem auch gestartet wird. Um
IrDA automatisch beim Systemstart zu aktivieren, muß bei Suse-Linux die Variable
START IRDA in der zentralen Systemkonfigurationsdatei /etc/rc.config auf yes gesetzt werden.
4.3.4.1
Der Übersetzungsvorgang ist ähnlich einfach wie bei den übrigen beiden Komponenten
des Demonstrationssystems. Nachdem die Pfade im Makefile den lokalen Gegebenheiten
angepaßt worden sind, wird die Übersetzung mit make im Verzeichnis PoA-Server/ in
Gang gesetzt.
Im Anschluß daran befinden sich in diesem Verzeichnis das PAM Modul mit der Bezeichnung pam mauth.so und zu Testzwecken eine von der Kommandozeile ausführbare
Version des PoA-Servers zu mit dem Namen poa test.
4.3. INSTALLATION
189
Das Verzeichnis mingetty-0.9.4/ enthält eine modifizierte Version des mingetty Programms, welches ohne initiale Abfrage des Usernamens sofort das Programm login
und damit das PAM Modul aufruft (vergleiche dazu Abschnitt 4.2.2.3). Diese Version
des mingetty Programms trägt den Namen mAuthgetty und befindet sich nach dem
Übersetzen in diesem Verzeichnis.
Nachdem die Bestandteile des PoA-Servers übersetzt worden sind, müssen sie in das
Unix System eingebunden werden. Dazu sind Systemverwalterrechte notwendig. Alle
weiteren Schritte sind daher als Benutzer root durchzuführen.
Das mAuthgetty Programm sollte in den Systemordner kopiert werden, in welchem sich
auch das normale mingetty Programm befindet. In vielen Fällen ist dies das Verzeichnis
/sbin/ oder /usr/sbin/. Desweiteren ist dem System mitzuteilen, auf welcher virtuellen Konsole das mAuthgetty Programm gestartet werden soll. Diese geschieht mittels
der Datei /etc/inittab. Darin sind u.a. die Eigenschaften für alle Systemkonsolen
abgelegt. Auf meinem Versuchsystem habe ich alle Textkonsolen, mit der Ausnahme
der, auf welcher mAuthgetty gestartet wurde, deaktiviert. Ein entsprechender Eintrag
in /etc/inittab sieht wie folgt aus:
#
#
#
#
getty-programs for the normal runlevels
<id>:<runlevels>:<action>:<process>
The "id" field MUST be the same as the last
characters of the device (after "tty").
2:2345:respawn:/sbin/mAuthgetty tty2
Anschließend muß das System noch aufgefordert werden, diese Änderungen zu übernehmen. Das erfolgt durch den Befehl kill -HUP 1, der ein HUP Signal an den Init-Prozeß
sendet. Der Init-Prozeß sollte normalerweise immer die PID2 1 besitzen. Es empfiehlt
sich jedoch, dies z.B. durch Eingabe von ps axu |grep init zu überprüfen und gegebenenfalls die PID im kill Befehl anzupassen.
Als nächstes muß das PAM Subsystem so konfiguriert werden, daß es das mAuth
Modul zur Authentifikation beim Loginvorgang auf dieser Konsole nutzt. Das mingetty Programm initiiert nicht selbst einen Authentifikationsprozeß, sondern startet für
den Loginvorgang das Programm login. Dies ruft wiederum zur Authentifikation das
entsprechende PAM Modul auf. Es müssen somit die PAM Einstellungen für das Programm login geändert werden. Zuvor wird das mAuth PAM Modul pam mauth.so aus
dem Source-Verzeichnis in das Verzeichnis der PAM Module kopiert. Bei dem von mir
verwendeten Suse-Linux-System befanden sich die Module unter /lib/security/.
Die PAM Konfigurationsdateien liegen dagegen im Verzeichnis /etc/pam.d/. Dort muß
die Datei login folgenden Inhalt besitzen:
#%PAM-1.0
auth
required
2
Process ID
/lib/security/pam_mauth.so
190
Als letzter Schritt ist sicherzustellen, das die Nutzerdatenbank mauthpasswd einen,
oder mehrere gültige Einträge enthält. Diese Datei ist abschließend in das Verzeichnis
/etc/ zu kopieren. Als Beispiel für ihr Format ist die Datei mauthpasswd.sample im
Quellverzeichnis des PoA-Servers enthalten.
4.4
Bedienung
4.4.1
Chipkarte
4.4.1.1
Ändern von PIN und Schlüssel
Da die Chipkarte selbst kein Mensch-Maschine Interface besitzt, ist es die Aufgabe
des mobilen Gerätes, dieses Interface zu den Verwaltungsfunktionen der Chipkarte zur
Verfügung zu stellen. Im Demonstrationsystem ist diese Funktionalität jedoch nicht
integriert.
Änderungen der persönlichen Daten auf der Chipkarte müssen daher im Source-Code
der Kartenapplikation vorgenommen werden. Anschließend werden die Quellen neu
übersetzt und die geänderte Anwendung neu auf der Karte installiert.
• private byte defkey[] =: legt den 3DES Key der Karte fest
• static byte std PIN VALUE[] =: definiert die Standard PIN
Daneben existiert mit static byte full PIN VALUE[] eine PIN zum Zugang zu den
Karten Verwaltungsfunktionen. Da diese Funktionalität jedoch im Demonstrations Client nicht verwirklicht ist, kommt diesem Wert nur Bedeutung für zukünftige Erweiterungen zu.
4.4.1.2
Modifikation der Main Loader Sicherheitsoptionen
Die Installation einer Chipkartenanwendung mit der Sm@rtcafé Professional Umgebung erzeugt einen Main Loader ohne gesetzte Sicherheitsoptionen. Sollen jedoch die
in Abschnitt 3.5.5 beschriebenen Sicherheitsmechanismen genutzt werden, können diese
mit dem im SCEZ Paket enthaltenen Tool cafeman aktiviert werden.
Dazu ist es notwendig einen neuen Main Loader zu erzeugen. Als erstes müssen dazu
alle Anwendungen auf der Karte gelöscht werden. Das ist mit dem Kommando cafeman
-C möglich. Dann wird durch cafeman -d der bestehende Main Loader gelöscht.
Beim Anlegen eines neuen Main Loaders wird für die Kommandos:
• INSTALL
• LOAD APPLET
4.4. BEDIENUNG
191
• DELETE ML
• CLEAR MEMORY
• PUT KEY
• SET PIN
in dieser Reihenfolge jeweils die Kondition ihrer Ausführung festgelegt. Möglich sind
die Konditionen:
• n(ever)
• a(lways)
• p(in)
Ein Main Loader wird also z.B. mit dem Befehl cafeman -c aapppp angelegt. Diese Konfiguration erlaubt ohne Bedingungen das Laden und Installieren von Applets.
Der Ausführung aller anderen Befehle muß jedoch die Eingabe einer korrekten PIN
vorausgegengen sein.
Wird mit z.B. mit cafeman -e 0123456789ABCDEF ein hexadezimaler Schlüssel
in ASCII-Darstellung angegeben, können später nur Applets installiert werden,
die mit diesem Schlüssel verschlüsselt worden sind. Durch z.B. cafeman -s
0123456789ABCDEF kann auf gleiche Weise ein weiterer Schlüssel spezifiziert werden.
Damit wird die Prüfsumme über einen Applet-Programmcode berechnet. Es werden
dann nur noch Applets zur Installation akzeptiert, welche den korrekten MAC besitzen.
Sind diese Sicherheitsoptionen festgelegt, muß die eigentliche Anwendung neu installiert werden. Dieser Intallationsvorgang kann ebenfalls mit dem Programm cafeman
erfolgen. Dabei müssen nun bereits alle zuvor festgelegten Sicherheitsanforderungen
erfüllt werden.
4.4.2
PoA-Server
Die Bedienung des PoA-Servers beschränkt sich im wesentlichen auf das Hinzufügen
neuer Zugangsberechtigungen. Diese werden in die Datei /etc/mauthpasswd eingetragen. Da diese Datei nur für den Benutzer root les- und editierbar sein sollte, sind zur
Änderung Systemverwalterrechte notwendig.
Neue Zugangsberechtigungen werden einfach durch das Anhängen einer weiteren Zeile
zu dieser Datei mit den Kenndaten des Benutzers vergeben. Zur Übernahme der dieser
Daten muß der Server nicht neu gestartet werden, da er bei jedem Authentifikationsvorgang die Zugangsdatenbank neu durchsucht und so die Änderungen übernimmt.
Ansonsten ist zum Betrieb des Demonstrations-PoA keine weitere Bedienung notwendig. Es ist jedoch darauf zu achten, daß auf dem Linux-System die Konsole, an welche
192
das modifizierte mingetty Programm gebunden worden ist aktiviert ist, d.h. deren Ausgabe auf dem Monitor erscheint. Es ist empfehlenswert alle anderen Textkonsolen zu
deaktivieren, um Verwechslungen auszuschließen. Auf der Textkonsole werden wichtige
Schritte des Authentifikationsprozesses zur Kontrolle und Veranschaulichung ausgegeben. Abbildung 4.4 zeigt einen Screenshot eines typischen Anmeldevorgangs.
Abbildung 4.4: Bildschirmausgabe eines typischen Anmeldevorgangs an dem
Demonstrations-PoA-Server
4.4. BEDIENUNG
193
4.4.3
PTD-Client
4.4.3.1
Normaler Authentifikations Ablauf
Nach der korrekten Installation der PTD-Client-Anwendung auf dem PalmOS-PDA
erscheint das Icon mit dem Symbol TUM“ und dem Namen mAuthClient in der
”
Anwendungsauswahl des PalmOS.
Abbildung 4.5: Palm Programmübersicht
Durch einfaches Antippen wird das Programm wie jede andere Palm Anwendung auch
gestartet. Während die Start-Form (Abbildung 4.6) auf dem Display erscheint wird der
Chipkarten-Reader und die Chipkartenapplikation initialisiert.
Abbildung 4.6: mAuth Client Start-Form
194
Ist dieser Initialisierungsprozeß erfolgreich abgeschlossen, wird der Anwender zur Eingabe seiner persönlichen PIN aufgefordert, um damit seine Identität gegenüber dem
PTD nachzuweisen. Die Eingabe erfolgt in der, in Abbildung 4.7 dargestellten, PINForm.
Abbildung 4.7: mAuth Client PIN-Form
Die einzelnen Ziffern werden dabei durch Antippen der entsprechenden Felder eingegeben. Das Graffiti System kann hiefür nicht genutzt werden. Jede Ziffer wird symbolisch
durch ein *“-Symbol im Feld PIN repräsentiert. Nach dreimaliger Falscheingabe der
”
PIN wird die Karte gesperrt. Die Anzahl der verbleibenden Versuche wird im Feld Trys
angezeigt.
Tippfehler können durch Drücken des Korrektur-Buttons behoben werden. Dabei werden alle bereits eingegebenen Ziffern gelöscht und die PIN-Eingabe muß erneut beginnen. Der OK-Button bestätigt die PIN und sendet sie zur Überprüfung an die Karte.
War die PIN korrekt, wechselt die mAuth Client-Anwendung in die Haupt-Form. Wie
in Abbildung 4.8 zu sehen ist, ist das Display in drei Hauptteile untergliedert. Im oberen
Drittel befindet sich ein Listenauswahl-Fenster, in dem alle in einem Peer-Discovery
Vorgang gefundenen PoAs mit deren Kurzbezeichnung aufgeführt sind. Die Abbildung
zeigt das Display unmittelbar nach der Aktivierung der Anwendung und noch vor dem
Start eines Discovery-Vorgangs. Daher ist die Anzeige noch leer.
Im Mittelteil sind die Bedienelemente angebracht. Mit dem Button PeerDisc wird
ein Peer-Discovery-Prozeß in Gang gesetzt. Das Ergebnis wird im PoA-AuswahlFenster darüber dargestellt. Durch Antippen des Authenticate-Buttons wird ein
Authentifikations-Vorgang zu dem im PoA-Auswahl-Fenster selektierten PoA gestartet. Die beiden vertikalen Pfeile am rechten Displayrand dienen zum auf- und abwärts
scrollen der Debug-Ausgaben im unteren Drittel der Form.
Da viele der Vorgänge im mAuth System vom Anwender verborgen ablaufen, entschied
4.4. BEDIENUNG
195
Abbildung 4.8: mAuth Client Haupt-Form
ich mich, beim Demonstrations Client wichtige Ereignisse und Abläufe durch Textausgaben in einem Debug-Bereich der Haupt-Form anzuzeigen. Durch die beschränkte Anzahl an Zeilen für die Textausgabe scrollt die Anzeige automatisch nach oben. Mittels
den beiden Pfeil-Buttons im Mittelteil der Form kann jedoch vor- und zurückgeblättert
werden.
Abbildung 4.9: Erfolgloses Peer Discovery
Im mAuth Demonstrations Client findet das Peer Discovery nicht automatisch im
Hintergrund statt, sondern muß vom Benutzer explizit durch Drücken des PeerDiscButtons gestartet werden. Konnten in einem Discovery-Vorgang keine mAuth kompatiblen Geräte in Reichweite gefunden werden, wird dies durch eine Meldung wie in
Abbildung 4.9 dem Anwender mitgeteilt. Das PoA-Auswahl-Fenster enthält in diesem
196
Fall nur den Eintrag no suitable PoAs in range!“.
”
Werden dagegen bei einem Peer-Discovery geeignete PoAs gefunden, werden diese der
Reihe nach im Auswahl-Fenster aufgeführt. In Abbildung 4.10 ist dies anhand eines
Beispiels dargestellt.
Abbildung 4.10: PoA-Auswahlliste
Der Benutzer kann nun, indem er einfach den entsprechenden Eintrag antippt, den PoA,
an welchen er sich anmelden möchte, auswählen. Der eigentliche Authentifikationsprozeß beginnt nach dem Drücken des Authenticate-Buttons. Die wichtigsten internen
Abläufe sind dabei, wie auch schon beim Peer-Discovery, anhand der Debug-Ausgaben
zu beobachten.
Abbildung 4.11: PoA bereits belegt
4.4. BEDIENUNG
197
Abbildung 4.11 zeigt einen Fall, in dem ein PoA-Server im Moment keine weiteren
Verbindungen mehr annimmt. Das kann vorkommen, wenn bereits ein anderer Benutzer mit dem gewählten PoA kommuniziert und der PoA nicht mehrere Verbindungen
gleichzeitig akzeptiert.
Abbildung 4.12: erfolgreiche Authentifizierung
Akzeptiert der Server jedoch die Verbindung und ist der Authentifikationsvorgang erfolgreich, meldet das der Demonstrations Client durch eine in Abbildung 4.12 dargestellte Meldung. Da das Demonstrationsystem das Applikationsmodell Rechnerzu”
gang“ realisiert, bietet diese Dialogbox zusätzlich die Auswahl den Loginprozeß abzubrechen oder sich am System einzuloggen.
Abbildung 4.13: erfolgreicher Loginvorgang
Entscheidet sich der Benutzer für das Einloggen und konnte dieser Befehl erfolgreich
198
übertragen werden, so erfolgt die Bestätigung durch die in Abbildung 4.13 gezeigte
Meldung.
4.4.3.2
Fehlermeldungen
Abgesehen von den Ausgaben im Debug-Fenster“ habe ich versucht alle, für den Be”
nutzer relevanten, zur Laufzeit auftretenden, Fehler in Form von Dialogboxen auszugeben. Im Fehlerfall erscheint eine Mitteilung, welche eine Beschreibung des Fehlers
beinhaltet und einen Button zur Bestätigung besitzt. Je nach Art und Schwere des
Problems, beendet sich die Anwendung anschließend, oder kehrt einfach zum Ausgangszustand vor der den Fehler verursachenden Aktion zurück.
Abbildung 4.14: Fehlermeldungen beim Kartenzugriff
In Abbildung 4.14 sind die Fehlermeldungen zusammengefaßt, welche in Zusammenhang mit dem Zugriff auf die Chipkarte auftreten können. Da die ersten beiden Fehlermeldungen auf ein Problem in der Hardware hinweisen, treten sie meist schon bei der
Initialisierung der Anwendung auf. Sie führen zum Abbruch des Programms, da eine
Programmausführung ohne Zugriff auf die Chipkarte nicht möglich ist.
4.4. BEDIENUNG
199
Die Dialogbox links unten in Abbildung 4.14 weist auf eine fehlerhafte mAuth
Chipkarten-Anwendung hin. Entweder implementiert die Karte einen oder mehrere Befehle, die die mAuth PTD-Anwendung verwendet, nicht, oder sie reagierte unerwartet
auf einen Request. In beiden Fällen ist die Kartenanwendung zu überprüfen.
Die Meldung rechts unten tritt dagegen bei dem Versuch auf, einen Befehl an die
Chipkarte zu senden, ohne vorher die zu dessen Ausführung notwendige PIN eingegeben
zu haben. Eine typische Situation dafür wäre ein Änderungsversuch der persönlichen
PIN ohne vorangegangener Eingabe der Verwaltungs-PIN.
Abbildung 4.15: Fehlermeldungen der IrDA-Verbindung
Während der IrDA-Kommunikation können verschiedene Probleme auftreten. Die erste
in Abbildung 4.15 dargestellte Fehlermeldung deutet auf Probleme beim Öffnen der
PalmOS-IrDA-Library hin. Das kann zum einen bedeuten, daß die serielle Schnittstelle
noch geöffnet und somit den UART belegt ist, oder zum anderen daß die IrDA-Library
nicht vorhanden ist wie z.B. bei PalmOS-Versionen vor 3.3. In ersteren Falle sollte der
PDA resettet und ein neuer Versuch gestartet werden. Im letzteren Falle muß das PDA
200
Betriebssystem auf eine neuere Version aktualisiert werden. Die IrLibrary ist für die
mAuth Client Anwendung zwingend erforderlich.
Kann keine mAuthOBEX Verbindung zum gewählten PoA aufgebaut werden, wird die
Meldung in Abbildung 4.15 unten rechts angezeigt. Dieses Problem kann u.a. aufgrund
einer schlechten physikalischen IrDA-Verbindung auftreten. Eine genauere Ausrichtung
der IrDA-Hardware zwischen PTD und PoA kann hier Abhilfe schaffen.
Aus dem gleichen Grund kann es zu der Meldung links unten in der Abbildung kommen.
Sie kann an einer beliebigen Stelle der Kommunikation auftreten. Die Auslöser sind
meist ein Verbindungsabriß auf TinyTP- oder LAP-Ebene, oder Timeouts in den von
mir entwickelten MyIr-Funktionen.
Abbildung 4.16: Fehlermeldungen beim Authentifikationsprozeß
Konnte eine Verbindung zum PoA-Server hergestellt werden, beginnt der eigentliche
Authentifikationsprozeß. Ist keine der vom PTD übermittelten IDs in der Zugangsdatenbank des PoA-Servers, lehnt dieser sofort den Zugang ab. Dem Benutzer wird das
durch eine Dialogbox, wie in Abbildung 4.16 links oben abbgebildet, mitgeteilt.
Der gesamte Authentifikationsprozeß muß gemäß dem im mAuth Konzept spezifizierten
Protokoll erfolgen. Empfängt der Client eine davon abweichende Antwort des Servers,
4.4. BEDIENUNG
201
bricht er die Authentifikation ab und informiert den Nutzer durch eine Meldung wie in
Abbildung 4.16 rechts oben dargestellt.
Läuft der Authentifikationsvorgang zwar gemäß dem Protokoll ab, schlägt die Überprüfung der RESPONSE jedoch fehl, zeigt eine Fehlermeldung das Scheitern der Authentifikation an. Die entsprechende Dialogbox ist in Abbildung 4.16 unten zu sehen.
Abbildung 4.17: Fehlermeldungen in Zusammenhang mit der PIN Eingabe
Im Zusammenhang mit der PIN Überprüfung sind zwei Fehlermeldungen relevant. Die
Eingabe einer falschen PIN resultiert in einer Fehlermeldung, welche auch die noch
verbleibenden Versuche bis zur Sperrung der Karte anzeigt. Der zweite Fehler, der hier
Auftreten kann, ist die Betätigung des OK-Buttons ohne zuvor eine PIN eingetippt zu
haben.
202
203
Kapitel 5
Zusammenfassung und Ausblick
5.1
Zusammenfassung
Das im Rahmen dieser Diplomarbeit entstandene Demonstrationsystem zeigt, daß bereits heute intelligente, mobile Geräte die Voraussetzungen mitbringen als universelle Authentifizierungs Token und sichere Terminals zu dienen. Ihre drahtlosen lokalen
Übertragungstechnologien (IrDA, Bluetooth) eignen sich hervorragend zur Verbindung
mit den Authentifikationssystemen, ohne Kosten durch die Nutzung eines Mobilfunknetzes zu verursachen.
Allerdings fehlt fast allen derzeit am Markt erhältlichen Geräten ein Chipkarteninterface. Da die Chipkarte zur Gewährleistung der Systemsicherheit unbedingt notwendig
ist, muß die entsprechende Hardware im Moment noch extern angeschlossen werden.
Zum praktischen Einsatz sind jedoch Geräte mit integriertem Lesegerät erforderlich.
Es ist jedoch zu erwarten, daß zukünftige Generationen von mobilen Geräten diese
Funktionalität besitzen werden.
Ein solches Authentifizierungsystem ist nur dann sinnvoll, wenn unterschiedliche Clients und Server zusammenarbeiten können. Der in dieser Arbeit entstandene Systementwurf spezifiziert die Aufgaben und Schnittstellen der einzelnen Komponenten und
legt ein gemeinsames Protokoll zur Kommunikation fest. Dieser Protokollentwurf soll
als Grundlage zur Realisierung von Authentifikationsanwendungen dienen. Der gesamte
Authentifikationsprozeß und die notwendige Infrastruktur sind darin spezifiziert. Dadurch ist ein Zusammenwirken aller sich an diese Vorgaben haltenden Anwendungen
sichergestellt.
Das ebenfalls in dieser Diplomarbeit entwickelte Demonstrationssystem veranschaulicht
dieses Konzept und weist dessen Funktionalität nach. Es wurde deutlich, daß mobile
Geräte prinzipiell für ein solches System geeignet sind, obgleich für einen Einsatz in
der Praxis noch einige Anpassungen - vor allem im Bereich der Hardware - von den
Geräteherstellern notwendig sind.
204
KAPITEL 5. ZUSAMMENFASSUNG UND AUSBLICK
Im Gegensatz zum Demonstrationssystem, welches auf Basis eines PalmOS-PDAs verwirklicht wurde, muß ein solches Authentifikationsystem heute unbedingt in Mobiltelefone integriert werden, um sich als Standard durchzusetzen. Mobiltelefone haben von
allen intelligenten mobilen Geräten derzeit die größte Verbreitung in der Bevölkerung.
Um ein solches System am Markt zu etablieren ist daher eine Realisierung auf dieser
Plattform unumgänglich. Der Systementwurf ist jedoch so allgemein gehalten, daß er
auf annähernd jeder Art von intelligenten mobilen Geräten umsetzbar ist.
5.2
Ausblick
Ziel meiner Diplomarbeit war es, die Möglichkeiten zur Verwirklichung eines mobilen
Authentifikationsystem zu untersuchen und zu diskutieren, sowie Realisierungsmöglichkeiten auszuarbeiten und daraus ein Demonstrationsystem zu entwickeln.
Daher versteht sich diese Diplomarbeit nicht als vollständige, umfassende Ausarbeitung
zu diesem Thema, sondern vielmehr als Grundlage für Erweiterungen und Ergänzungen.
Folgende Ansatzpunkte wären dafür denkbar:
Konzept:
• Ausarbeitung der Applikationsmodelle
Meine Arbeit spezifiziert nur den Authentifikationsprozeß. Der eindeutige Nachweis der Identität eines Benutzers ist jedoch nur die Voraussetzung für die folgenden Anwendungen. Erst die unterschiedlichen Anwendungen wie z.B. das bargeldlose Bezahlen, die Bedienung eines Geldautomaten, das Öffnen und Schließen
der Haustüre, usw. machen das System für einen Anwender interessant.
Damit auch hier unterschiedliche Geräte zusammenarbeiten können bedarf es
einer genauen Spezifikation. Die in Abschnitt 2.9 vorgeschlagenen Applikationsmodelle zeigen nur einen groben Entwurf hierfür auf. Dieser Ansatz müsste genau
ausgearbeitet und definiert werden. Dies würde die wichtigste Erweiterung zur
Vervollständigung meines Konzept darstellen.
• Untersuchung und Anpassung des Peer-Discovery-Prozesses auf Bluetooth
Das mAuth Konzept ist - soweit wie möglich - unabhängig von der Hardware gehalten. Doch der Peer-Discovery Mechanismus muß sich zwangsläufig der
Funktionen unterer Protokollschichten bedienen. In meiner Arbeit habe ich dazu
nur das IrDA Protokoll untersucht. Da es jedoch absehbar ist, daß sich in naher
Zukunft Bluetooth mehr und mehr als Übertragungstechnologie im Nahbereich
5.2. AUSBLICK
205
durchsetzen wird, wäre eine Betrachtung der betreffenden Funktionen dieses Protokolls sehr wünschenswert.
• Untersuchung der Möglichkeiten und Risiken anwendungsspezifischer
Chipkartenapplikationen auf der mAuth Karte
Die im mAuth System verwendeten Chipkarten sollen die Möglichkeit bieten
neben der mAuth-default Anwendung weitere anwendungsspezifische Applikationen unterbringen zu können. Betreiber von PoAs können damit z.B. ihre eigenen
Schlüssel und kryptographischen Funktionen realisieren. Ein besonderes Augenmerk ist dabei jedoch auf die Sicherheit zu legen. So müssten die Risiken, ob
sich Anwendungen gegenseitig beeinflussen oder gar Daten ausspähen könnten,
untersucht werden. Es sollte ein System entwickelt werden, das nur die Installation von geprüften und berechtigten Anwendungen erlaubt, gleichzeitig den PoABetreibern aber auch genügend Freiheit läßt, ihre Anforderungen zu verwirklichen. Weiterhin müsste eine Schnittstelle definiert werden, um diese Anwendungen zu selektieren und ihre Funktionen ansprechen zu können. Dabei muß eine
Rückkehr zu mAuth-default Applikation nach Beendigung der Kommunikation
mit dem PoA sichergestellt sein.
Demonstrationssystem:
• Verbesserung der PalmOS-IrDA-Funktionen
Die von mir entwickelten Funktionen zum Aufbau einer IrDA-Kommunikation,
kapseln die low level“-Routinen der PalmOS-IrLibrary zu einem komfortable”
ren Interface. Diese Schnittstelle funktionierte gegen Ende meiner Arbeit zwar
zufriedenstellend, jedoch wären noch weitere Optimierungen wünschenswert. Da
meiner Einschätzung nach ein Bedarf für eine einfach zu handhabende API zur
IrDA-Programierung vorhanden, jedoch bisher nicht verfügbar ist, wäre eine derartige Realisierung ein sinnvolles Vorhaben. Denkbar wäre ein Satz von Funktionen, die den Programmierer von der Überprüfung des Aufrufstatus der IrLibrary
Kommandos und der Auswertung der Callback Funktionen entbinden. Dies könnte in Form einer statischen und/oder dynamischen Bibliothek umgesetzt werden.
• Lösung der Probleme beim Mehrkonsolenbetrieb am PoA-Server
Bei einem Linux System sind in der Regel mehrere Textkonsolen vorhanden, zwischen denen vom Benutzer umgeschaltet werden kann. In der derzeitigen Version
des PoA-Servers ist die Anmeldung via IrDA zwar fest an eine Konsole gebunden. Es ist jedoch beim Mehrkonsolenbetrieb nicht zwangsläufig sichergestellt,
daß diese auch der gerade aktivierten Konsole entspricht. Damit wäre es denkbar, falls gerade eine normale“ - nicht mAuth taugliche - Textkonsole aktiv ist,
”
daß ein Benutzer einen erfolgreichen mAuth Anmeldevorgang durchführt, jedoch
aufgrund keiner erkennbaren Reaktion auf dem Bildschirm den Rechener wegen
206
einer vermuteten Fehlfunktion wieder verläßt. Er bleibt allerdings auf der verborgenen Konsole eingeloggt. Ein Dritter kann so, vorsätzlich oder zufällig, Zugriff
auf dessen Daten und dessen Benutzerkennung erhalten. Auch wenn der Angreifer
damit nicht die Möglichkeit hat, sich erneut unter falschem Namen anzumelden,
kann er damit viel Schaden anrichten.
Es wäre daher eine wichtige Erweiterung, den Demonstrations-Server für den
Mehrkonsolenbetrieb tauglich zu machen. Dazu müsste sichergestellt werden, daß
die mAuth Anmeldung immer an die gerade aktive Textkonsole gebunden ist,
d.h. es müsste für die IrDA-Hardware ein ähnlicher Mechanismus implementiert
werden, der auch Tastatur und Bildschirm immer an die gerade aktive Konsole
bindet.
• Realisierung weiterer Applikationsmodelle und PoA-Server
Das Demonstrationssystem in meiner Arbeit realisiert nur das Applikationsmodell Rechnerzugang“. Um die universelle Funktionalität des mAuth Systems bes”
ser zu verdeutlichen, wären verschiedene PoA-Server, die unterschiedliche Funktionen, wie z.B. das Auf- und Abschließen von Türen oder die Bedienung eines
Geldautomaten simulieren, hilfreich. Der PTD-Client müßte im selben Zuge,um
all diese Applikationen abzudecken, erweitert werden.
• Realisierung eines Chipkarten-Lesegerätes als Visor SpringboardModul
Die Anbindung eines externen Chipkarten-Lesegeräts ist für ein Demonstrationssystem zwar akzeptabel, für ein marktreifes Gerät jedoch keinesfalls. Doch auch
zu Vorführzwecken wäre es schöner, wenn das Lesegerät in das mobile Gerät integriert wäre. Die Erweiterbarkeit der Handspring Visor PDAs bietet sich geradezu
dafür an, dies zu realisieren. Die Abmessungen des Springboard-Modulschachts
sind ausreichend um eine Chipkarten-Lesegerät-Mechanik samt zugehöriger Elektronik aufzunehmen. Allerdings müßte dafür ein passendes Gehäuse und eventuell
auch eine eigene Controller-Elektronik entwickelt werden. Die Schaltungsentwicklung bezieht sich vor allem auf das Interface zur Springboard-Schnittstelle des
Visors. Da bei der Ankopplung des Chipkarten-Lesegeräts über das SpringboardInterface der interne UART nicht belegt werden würde, wäre damit auch das
Problem des gleichzeitigen Zugriffs auf Chipkarte und Infrarotschnittstelle gelöst.
• Implementierung eines Demonstrationssystems auf einem Mobiltelefon
Wie bereits erwähnt, muß das mAuth System, um praxistauglich zu werden, aufgrund der hohen Marktabdeckung unbedingt auf Mobiltelefonen implementiert
werden. Ein Demonstrations-Client, der dies realisiert, wäre zur Veranschaulichung der Flexibilität des Konzepts von Vorteil. Sollte durch die Zusammenarbeit mit der Industrie ein Entwicklungssystem für ein Mobiltelefon zur Verfügung
stehen, sollte dieses Vorhaben verwirklicht werden.
5.2. AUSBLICK
207
Das Konzept kann nur erfolgreich in die Praxis umgesetzt werden, wenn es die Unterstützung von großen Mobiltelefon- und PDA-Herstellern findet. Es macht langfristig
nur Sinn, wenn sich im Bereich der mobilen Authentifikation ein Standard durchsetzt.
Mehrere proprietäre Systeme schränken die Anwendbarkeit durch Inkompatibilitäten
untereinander ein.
Entscheidend dabei ist auch die Unterstützung und Akzeptanz von potentiellen PoABetreibern. Neben den persönlichen PoAs wie z.B. Haustürschließsystemen und Autos,
sind vor allem die PoAs öffentlicher Diensteanbieter wie der Banken oder des Einzelhandels für den Anwender interessant.
Die technische Machbarkeit eines mobilen Authentifikationsystems ist durch diese Arbeit nachgewiesen, die Umsetzbarkeit in die Praxis wird durch die Akzeptanz der Anwender und die Kooperationsbereitschaft der Industrie entschieden werden.
208
Literaturverzeichnis
[Beu91]
Albrecht Beutelspacher. Kryptologie. Vieweg & Sohn Verlagsgesellschaft,
2 edition, 1991.
[Bü00]
Matthias Bürstle. SCEZ Apllication Programmer’s Manual, 1.0 edition,
2000.
[Dil98]
Pat Dillon. The Next Small Thing. Fast Company, (15):97, June 1998.
[Fos00]
Lonnon R. Foster. Palm OS Programming Bible. IDG Books Worldwide,
Inc., 2000.
[How97]
Andrew Howlett. GNU Pilot SDK Tutorial. Ottawa, Canada, June 1997.
[jc-99a]
Getting Started with Sm@rtcafé Professional Toolkit 1.1. Giesecke & Devrient GmbH, Prinzregentenstraße 159, Postfach 80 07 29, D-81607 München,
03/99 edition, 1999.
[jc-99b]
Java Card 2.1 Application Programming Interface. Sun Microsystems Inc.,
901 San Antonio Road, Palo Alto, CA 94043 USA, June 1999.
[jc-99c]
Java Card 2.1 Runtime Environment (JCRE) Specification. Sun Microsystems Inc., 901 San Antonio Road, Palo Alto, CA 94043 USA, June 1999.
[jc-99d]
Sm@rtcafé 1.1 Card Reference Manual. Giesecke & Devrient GmbH, Prinzregentenstraße 159, Postfach 80 07 29, D-81607 München, 05/99 edition,
1999.
[Kah]
Christian Kahlo. Handspring Visor + Towitoko Chipdrive Micro + SCEZ
(+ Lewis). http://gsho.fnordic.de/cdv/index.html.
[ldv00]
Kryptologie - Skript Version SS 2000. Lehrstuhl für Datenverarbeitung,
2000.
[Mor99]
Andrew G. Morgan. The Linux-PAM System Administrators´ Guide, November 1999.
[Mor01]
Andrew G. Morgan. The Linux-PAM Module Writers´ Guide, Jannuary
2001.
[msi00a]
mSign Business White Paper. http://www.msign.org, 2000.
209
210
LITERATURVERZEICHNIS
[msi00b]
mSign Protocol Specification. http://www.msign.org, October 2000.
[MSK]
Patrick J. Megowan, David W. Suvak, and Charles d. Knutson. IrDA
Infrared Communications: An Overview.
[MSK99]
Pat Megowan, Dave Suvak, and Doug Kogan. IrDA Object Exchange Protocol IrOBEX - Version 1.2, March 1999.
[odi00]
odi. Sesam öffne dich! Flexible Authentifizierung mit PAM. Ct, (2):216–
219, 2000.
[oEE99a]
The Institute of Electrical and Electronics Engineers. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. 3
Park Avenue, New York, NY 10016-5997,USA, August 1999.
[oEE99b]
The Institute of Electrical and Electronics Engineers. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Highspeed Physical Layer in the 5 GHz Band. 3 Park Avenue, New York, NY
10016-5997,USA, August 1999.
[oEE99c]
The Institute of Electrical and Electronics Engineers. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications:
Higher-Speed Physical Layer Extension in the 2.4 GHz Band. 3 Park Avenue, New York, NY 10016-5997,USA, September 1999.
[pal00]
Palm OS Programmer’s Companion. Palm Inc., 5400 Bayfront Plaza, Santa
Clara, CA 95052 USA, March 2000.
[Pog99]
David Pogue. Palm Programming: The Developer’s Guide. O’Reilly &
Associates, Inc., 1999.
[PQT98]
John Petrilla, Raymond Quek, and Joe Tjanai. Serial Infrared Physical
Layer Specification - Version 1.3, October 1998.
[Rei01]
Dschen Reinecke. Dschen Reineckes Infrarotport-Bauanleitung. http://
www.infrarotport.de/ir-modul.HTML, Mai 2001 2001.
[SIG01a]
Bluetooth SIG. Specification of Bluetooth System - Core, 1.1 edition, February 2001.
[SIG01b]
Bluetooth SIG. Specification of Bluetooth System - Profiles, 1.1 edition,
February 2001.
[SWN96]
Andy Seaborne, Stuart Williams, and Frank Novak. Serial Infrared Link
Management Protocol - Version 1.1, Jannuar 1996.
[Tel99]
Vishay Telefunken. TFDS4500 Serial Infrared Transceiver - Description,
July 1999.
211
[WHN+ 96] Timothy Williams, Peter Hortensius, Frank Novak, Kevin Smith, David
Suvak, and Mike Cremer. Serial Infrared Access Protocol (IrLAP)- Version
1.1, June 1996.
212
Abbildungsverzeichnis
1.1
Vielzahl spezialisierter Sicherheitstoken . . . . . . . . . . . . . . . . . .
5
1.2
Authentifizierung Grundschema . . . . . . . . . . . . . . . . . . . . . .
7
1.3
Beispiele weit verbreiteter Mobiltelefone . . . . . . . . . . . . . . . . .
11
1.4
Beispiele von PalmOS-Geräten . . . . . . . . . . . . . . . . . . . . . . .
12
1.5
Beispiele von WindowsCE-Geräten . . . . . . . . . . . . . . . . . . . .
13
1.6
Beispiele von EPOC-Geräten . . . . . . . . . . . . . . . . . . . . . . . .
14
1.7
Beispiel einer Digitalkamera . . . . . . . . . . . . . . . . . . . . . . . .
14
1.8
IrDA Protokoll-Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.9
IEEE 802.11 Wireless LAN Protokoll-Stack . . . . . . . . . . . . . . . .
19
1.10 Bluetooth Protokoll Stack . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.11 Diffie-Hellmann Schlüsseltausch . . . . . . . . . . . . . . . . . . . . . .
30
1.12 Das Challenge-Response Verfahren . . . . . . . . . . . . . . . . . . . .
31
1.13 Eingliederung von OBEX in den IrDA and Bluetooth Protokollstack . .
37
1.14 OBEX - Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
1.15 OBEX Request-Response Modell . . . . . . . . . . . . . . . . . . . . .
39
1.16 Aufbau von OBEX Paketen . . . . . . . . . . . . . . . . . . . . . . . .
39
1.17 Beispiel einer OBEX PUT Operation . . . . . . . . . . . . . . . . . . .
42
1.18 Aufbau von OBEX Headern . . . . . . . . . . . . . . . . . . . . . . . .
43
2.1
Zusammenführung vieler Token auf ein intelligentes System . . . . . . .
51
2.2 Systemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
2.3
Der Authentifikationsablauf . . . . . . . . . . . . . . . . . . . . . . . .
55
2.4
Aufgaben des Trustcenters . . . . . . . . . . . . . . . . . . . . . . . . .
56
213
214
ABBILDUNGSVERZEICHNIS
2.5
Chipkarte - Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
2.6
Mehrere Applikationen auf einer mAuth Chipkarte
. . . . . . . . . . .
59
2.7
Mobiles Gerät - Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . .
60
2.8
Point of Authentifikation - Aufgaben . . . . . . . . . . . . . . . . . . .
62
2.9
Ablauf der Zertifikatsausstellung . . . . . . . . . . . . . . . . . . . . . .
65
2.10 Authentifikations Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . .
67
2.11 Ablauf einer Neuanmeldung bei einem PoA . . . . . . . . . . . . . . . .
68
2.12 Peer Discovery Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
2.13 Peer Discovery-Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
2.14 Kommunikationsbeziehung zwischen Benutzer und Trustcenter . . . . .
72
2.15 Kommunikationsbeziehung zwischen Trustcenter und Chipkarte . . . .
73
2.16 Kommunikationsbeziehung zwischen Benutzer und mobilem Gerät . . .
74
2.17 Kommunikationsbeziehung zwischen mobilem Gerät und Chipkarte . .
74
2.18 Kommunikationsbeziehung zwischen PTD und PoA . . . . . . . . . . .
75
2.19 Kommunikationsbeziehung zwischen Benutzer und PoA . . . . . . . . .
76
2.20 Beispielhafter Kommunikationsablauf . . . . . . . . . . . . . . . . . . .
77
2.21 Unterschiedliche Darstellung der Dialoge . . . . . . . . . . . . . . . . .
80
2.22 Chipkarten Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . 107
2.23 PTD-Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.24 PoA-Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.1
IrDA physikalische Schnittstelle Schema (Quelle [PQT98]) . . . . . . . 121
3.2
Blockschaltbild des TFDS4500(Quelle [Tel99]) . . . . . . . . . . . . . . 122
3.3
Schaltplan IrDA-Adapter (Quelle [Rei01]) . . . . . . . . . . . . . . . . 122
3.4
PC-IrDA-Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.5
Bestandteile eines PAM Systems (Quelle [odi00])
3.6
Schritte der Javacard Anwendungs-Erstellung (Quelle [jc-99a]) . . . . . 133
3.7
Die Sm@artcaf’e Entwicklungsoberfläche . . . . . . . . . . . . . . . . . 135
3.8
Eingliederung des Main Loaders in die Javacard Struktur (Quelle [jc-99d])136
3.9
Der Handspring Visor Platinum . . . . . . . . . . . . . . . . . . . . . . 139
. . . . . . . . . . . . 127
215
3.10 Ablauf einer typischen PalmOS-Anwendung . . . . . . . . . . . . . . . 147
3.11 Start einer POSE Sitzung . . . . . . . . . . . . . . . . . . . . . . . . . 158
3.12 Emulation verschiedener Palm Modelle . . . . . . . . . . . . . . . . . . 160
3.13 Adapter zwischen seriellen Cradle und Chipdrive . . . . . . . . . . . . . 164
3.14 Aufbau bei Anschluß über serielles Cradle . . . . . . . . . . . . . . . . 165
3.15 Anschlußschema der Chipkarten-Leser Platine . . . . . . . . . . . . . . 166
3.16 Beschaltungsschema bei der direkte Kopplung zwischen Visor und Chipdrive 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.17 Aufbau bei direktem Anschluß des Towitoko Chipdrive micro 100 and
den Handspring Visor Platinum . . . . . . . . . . . . . . . . . . . . . . 168
4.1
Der Demonstrations PoA-Server . . . . . . . . . . . . . . . . . . . . . . 172
4.2
Der Demonstrations PTD-Client . . . . . . . . . . . . . . . . . . . . . . 176
4.3
Automat der MyIrConnect Funktion . . . . . . . . . . . . . . . . . . . 182
4.4
Bildschirmausgabe eines typischen Anmeldevorgangs an dem
Demonstrations-PoA-Server . . . . . . . . . . . . . . . . . . . . . . . . 192
4.5
Palm Programmübersicht
. . . . . . . . . . . . . . . . . . . . . . . . . 193
4.6 mAuth Client Start-Form . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.7 mAuth Client PIN-Form . . . . . . . . . . . . . . . . . . . . . . . . . . 194
4.8 mAuth Client Haupt-Form . . . . . . . . . . . . . . . . . . . . . . . . . 195
4.9 Erfolgloses Peer Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 195
4.10 PoA-Auswahlliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
4.11 PoA bereits belegt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
4.12 erfolgreiche Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . 197
4.13 erfolgreicher Loginvorgang . . . . . . . . . . . . . . . . . . . . . . . . . 197
4.14 Fehlermeldungen beim Kartenzugriff . . . . . . . . . . . . . . . . . . . 198
4.15 Fehlermeldungen der IrDA-Verbindung . . . . . . . . . . . . . . . . . . 199
4.16 Fehlermeldungen beim Authentifikationsprozeß . . . . . . . . . . . . . . 200
4.17 Fehlermeldungen in Zusammenhang mit der PIN Eingabe . . . . . . . . 201
216
Tabellenverzeichnis
1.1
Vergleich verschiedener mobiler Gräte . . . . . . . . . . . . . . . . . . .
15
1.2
Bestandteile eines Zertifikats . . . . . . . . . . . . . . . . . . . . . . . .
32
1.3
Befehls APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
1.4
Antwort APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
1.5
OBEX Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
1.6
OBEX Response-Codes . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
1.7
OBEX Connect Request . . . . . . . . . . . . . . . . . . . . . . . . . .
40
1.8
OBEX Connect Response . . . . . . . . . . . . . . . . . . . . . . . . .
41
1.9
TLV-Triplet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
1.10 Wichtige OBEX Header . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.1
Kommunikationsbeziehungen der Systemkomponenten . . . . . . . . . .
72
2.2
Chipkarten-Funktionen - Übersicht . . . . . . . . . . . . . . . . . . . .
78
2.3
Befehls APDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
2.4
Chipkarten CommandCodes . . . . . . . . . . . . . . . . . . . . . . . .
87
2.5
Kryptographische Algorithmen des mAuth Systems . . . . . . . . . . .
88
2.6
Schlüsseltypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
2.7
PIN Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
2.8
Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
2.9
KeyComponent-Triplet . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
2.10 KeyComponent-Triplet Tags . . . . . . . . . . . . . . . . . . . . . . . .
91
2.11 Antwort APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
2.12 Capability Response Format . . . . . . . . . . . . . . . . . . . . . . . .
92
217
218
TABELLENVERZEICHNIS
2.13 CapTriplet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
2.14 Bedeutung der Felder prKey und prCert . . . . . . . . . . . . . . . . .
93
2.15 Zertifikatsformat Format . . . . . . . . . . . . . . . . . . . . . . . . . .
94
2.16 Aufbau der User ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
2.17 Aufbau der Trustcenter ID . . . . . . . . . . . . . . . . . . . . . . . . .
95
2.18 public Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
2.19 Signatur Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
2.20 Hash Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
2.21 mAuth OBEX Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
2.22 mAuth-OBEX PeerDisc Request . . . . . . . . . . . . . . . . . . . . . .
99
2.23 mAuth-OBEX PeerDisc Response . . . . . . . . . . . . . . . . . . . . . 100
2.24 Erweiterte Headertypen . . . . . . . . . . . . . . . . . . . . . . . . . . 101
2.25 Header Parameter Triplet . . . . . . . . . . . . . . . . . . . . . . . . . 101
2.26 mAuthID Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.27 mAuth Triplet Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.28 mAuthChallenge Header . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.29 mAuthResponse Header . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.30 mAuthResponse Header . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.31 CapAuth Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.32 CapLink Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
2.33 CapApp Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
2.34 PeerDescription Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.35 PeerDescription Triplet Tags . . . . . . . . . . . . . . . . . . . . . . . . 106
2.36 Crypt Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.37 Kodierung von Blockbildungsarten . . . . . . . . . . . . . . . . . . . . 107
2.38 mAuth Application Identifier
. . . . . . . . . . . . . . . . . . . . . . . 112
4.1
Übersicht über die implementierten Funktionen der mAuth Chipkarte . 171
4.2
Die vom Server unterstützten mAuthOBEX Befehle . . . . . . . . . . . 174
4.3
Die vom Server erkannten mAuthOBEX Header . . . . . . . . . . . . . 174

Mobile Geräte als Terminal für sicherheitsrelevante Transaktionen

Transcription

Similar documents

Wi-Fi-Sicherheit – WEP, WPA und WPA2

Orientierungshilfe zu "Anforderungen zur informationstechnischen

Linux Login mit RSA SmartCard

Ein Ritt auf der Rasierklinge

Vergleich verschiedener XML-GUI-Standards

Handout

ERNW Newsletter 34 /November 2010

kryptobuch-ertel-folien, 1.7 MB