Konzept und Aufbau einer prototypischen Public Key Infrastruktur

Transcription

Fachbereich Informatik
Prof. Dr. Johannes Buchmann
Institut für Theoretische Informatik
Technische Universität Darmstadt
Diplomarbeit
Konzept und Aufbau einer prototypischen
Public Key Infrastruktur auf Basis von FlexiTrust
Bei der Allgemeinen Deutschen Direktbank AG
von
Patrick Seiler
Betreuer
Alexander Wiesmaier
Oktober 2001
Ich bedanke mich bei allen, die mir bei der Erstellung dieser Arbeit geholfen haben. Insbesondere danke ich Alexander Wiesmaier, für Betreuung dieser Arbeit am Institut für Theoretische
Informatik der TU-Darmstadt; Oliver Becker von der Firma Becker Consulting, für die Förderung dieser Diplomarbeit; Zeljko Kaurin, für die freundliche Unterstützung bei der Allgemeinen Deutschen Direktbank AG; und allen Korrekturlesern, für ihre wertvollen
Verbesserungshinweise.
i
ii
Ehrenwörtliche Erklärung
Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder
ähnlicher Form noch keiner Prüfungsbehörde vorgelegen
Darmstadt, den 15. Oktober 2001
Patrick Seiler
iii
iv
Inhaltsverzeichnis
Abbildungsverzeichnis
ix
Tabellenverzeichnis
xi
1
Einleitung
1
2
Kryptographische Grundlagen
5
2.1 Symmetrische Verschlüsselungsverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Asymmetrische Verschlüsselungsverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Hybridverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Digitale Signaturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3
Public Key Infrastrukturen
3.1 Grundlegende Dienste einer PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Schlüsselmanagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Zertifikate nach X.509v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.1 Standardfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.2 Standarderweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.3 Erweiterungen im Sinne der Signaturverordnung . . . . . . . . . . . .
3.3.1.4 Erweiterungen von Netscape . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Trustcenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Struktur eines Trustcenters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Zertifikatswiderruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Vertrauensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Direct Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2 Web Of Trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.3 Hierarchical Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Schlüsselwiederherstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Escrowed Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Kryptographische Verfahren auf Public Key Basis . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1.1 Server Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1.2 Client Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1.3 Notwendige Zertifikaterweiterungen . . . . . . . . . . . . . . . . . . . . .
11
11
12
14
15
15
16
19
19
21
21
24
25
25
26
27
28
29
29
30
32
33
35
v
Konzept und Aufbau einer prototypischen Public Key Infrastruktur auf Basis von FlexiTrust
3.7.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.3 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.3.1 IPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.3.2 IKMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.3.3 Virtuelle private Netzwerke (VPN) mit IPSec . . . . . . . . . . . . . .
3.8 Verzeichnisdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.1 X.500. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2.1 Vom Protokoll zum Verzeichnis . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2.2 Das Informationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2.3 Das Namensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2.4 Das Sicherheitsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2.5 LDAP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Rechtliche Aspekte des PKI Betriebes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1 Gesetzliche Beschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.2 Gesetz zur digitalen Signatur (SigG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.3 Exportbeschränkungen der USA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
38
38
39
41
42
44
44
45
46
46
47
48
50
51
52
52
52
54
55
4
Bedarfsanalyse
4.1 Ermittlung des Ist-Zustandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Unternehmensstruktur DiBa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 Hard- und Softwareinfrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Ermittlung des Bedarfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Sicherer Intranetzugang für mobile Mitarbeiter . . . . . . . . . . . . . . . . . . . . .
4.2.2 Sichere Kommunikation mobiler Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Fernadministration des LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Konzept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Überblick über das Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Outsourcen oder Do-it-yourself?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Sicherer Intranetzugang für mobile Mitarbeiter . . . . . . . . . . . . . . . . . . . . .
4.3.5 Fernadministration des LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6 Sichere Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6.1 Dokumentenbasierte Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.7 Anforderungen an die Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Weitere Möglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
57
57
58
59
61
61
62
63
63
63
63
64
64
65
66
68
69
69
70
5
Untersuchung vorhandener Software auf Möglichkeiten zur Integration
5.1 Aufbau der Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Software für Zertifizierungsstellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Microsoft Certificate Server 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 FlexSecure FlexiTrust 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
71
73
74
76
78
vi
Inhaltsverzeichnis
5.3
5.4
5.5
5.2.3.1 FlexiTrust-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3.2 FlexiTrust-RA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3.3 FlexiTrust-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Microsoft Internet Information Server 4.0 . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Microsoft Exchange Server 5.5 mit Outlook Web Access 5.5 . . . . . . . . . .
5.3.3 OpenLDAP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4 Microsoft Windows 2000 Server als VPN-Gateway . . . . . . . . . . . . . . . . .
Client Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Microsoft Internet Explorer 5.x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2 Netscape Communicator 4.7x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.3 Microsoft Outlook 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.4 LDAP Browser\Editor 2.8.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
81
82
83
83
85
86
86
88
88
91
93
95
97
6
Umsetzung der Public Key Infrastruktur
99
6.1 Zertifizierungshierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2 Benutzergruppen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3 Konfiguration der Hard- und Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3.1 FlexSecure FlexiTrust 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3.2 Microsoft Internet Information Server 4.0 . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3.2.1 Erzeugen eines Serverzertifikates . . . . . . . . . . . . . . . . . . . . . . . 103
6.3.2.2 Installation des Root-CA Zertifikates . . . . . . . . . . . . . . . . . . . . 103
6.3.2.3 Serverkonfiguration für SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3.3 Microsoft Internet Explorer 5.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3.4 Microsoft Outlook 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.4 Allgemeiner Ablauf der Benutzerzertifizierung. . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.4.1 Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4.2 Schlüsselerzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4.3 Zertifizierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4.4 Schlüsselverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4.5 Sperrmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.4.6 Veröffentlichung von Zertifikaten und Widerrufslisten . . . . . . . . . . . . . . 109
6.4.7 Vier-Augen-Prinzip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7
Kommentar
zu den Zertifizierungsrichtlinien
7.1 Rechtliche Bedeutung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Einsatz von Registrierungsinstanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Sicherheit in einer hierarchischen Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Zertifizierung von Benutzern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Widerruf von Zertifikaten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
111
111
113
113
114
115
115
Bewertung und Ausblick
117
8.1 Gesamtbewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
vii
Anhang A Zertifizierungsrichtlinien: Policy
A.1 Identität der DiBa-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Zuständigkeitsbereich der DiBa-CA . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1 Rechtliche Bedeutung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.2 Die DiBa-Zertifizierungshierarchie . . . . . . . . . . . . . . . . . . . . . .
A.2.3 Registrierungsinstanz (RA) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Sicherheit der DiBa-CA-Ausstattung . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3.1 Sicherheitsanforderungen an die DiBa-CA . . . . . . . . . . . . . . . .
A.3.2 Sicherheitsanforderungen an die DiBa-RA . . . . . . . . . . . . . . . .
A.3.3 Sicherheitsanforderungen an Benutzer . . . . . . . . . . . . . . . . . . .
A.4 Zertifizierungsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.1 Regeln für die Zertifizierung von Benutzern . . . . . . . . . . . . . . .
A.5 Management von Zertifikaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6 Widerruf von Zertifikaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7 Schlüsselhinterlegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.8 Regeln für die Namensgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.9 Verschiedenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
119
120
120
120
121
121
121
122
122
123
124
125
125
126
127
128
Anhang B Installationsbeschreibungen
B.1 Erzeugen eines Serverzertifikates für den IIS 4 . . . . . . . . . . . . . . . . . .
B.2 Installation von CA-Zertifikaten im IIS 4 . . . . . . . . . . . . . . . . . . . . . .
B.3 Installation von Widerrufslisten (CRLs) im Netscape Communicator
B.4 Installation des MMC Zertifikat Snap-In . . . . . . . . . . . . . . . . . . . . . . .
129
129
130
133
133
Anhang C Abkürzungsverzeichnis
135
Anhang D Literaturverzeichnis
139
viii
Abbildungsverzeichnis
1
symmetrische Verschlüsselung ........................................................................................ 6
2
asymmetrische Verschlüsselung ...................................................................................... 7
3
hybride Verschlüsselung .................................................................................................. 8
4
Digitale Signatur .............................................................................................................. 9
5
Allgemeiner Aufbau eines digitalen Zertifikates ........................................................... 15
6
mögliche Struktur eines SigG-konformen Trustcenters................................................. 22
7
Vertrauensmodelle ......................................................................................................... 26
8
SSL setzt zwischen TCP und einem Anwendungsprotokoll an..................................... 30
9
SSLv3-Server: Authentifizierungsvorgang im Überblick.............................................. 33
10
SSLv3-Client: Authentifizierungsvorgang im Überblick .............................................. 34
11
IPSec verschlüsselt auf IP-Ebene................................................................................... 39
12
ESP Modi im Vergleich ................................................................................................. 40
13
IPSec mit ESP im Tunnelmodus.................................................................................... 40
14
X.500 Server .................................................................................................................. 45
15
LDAP Server als Gateway zum X.500 Server ............................................................... 46
16
Stand-Alone LDAP Server............................................................................................. 47
17
Das Informationsmodell: Einträge, Attribute und Werte............................................... 48
18
Ausschnitt eines fiktiven LDAP-Verzeichnisbaumes.................................................... 49
19
Authentifizierung per SASL .......................................................................................... 51
20
LDAP-Zugriff über Webbrowser................................................................................... 51
21
Unternehmensstruktur der Allgemeinen Deutschen Direktbank AG ............................ 59
22
Zugang zum Intranet über SSL ...................................................................................... 65
23
Fernadministration über ein VPN .................................................................................. 65
24
Kommunikations-Konzept A ......................................................................................... 66
25
Kommunikations-Konzept B ......................................................................................... 67
ix
26
Kommunikations-Konzept C ......................................................................................... 68
27
Aufbau der Testumgebung............................................................................................. 73
28
Zertifikatsanforderung über das Webinterface des Certificate Servers 1.0 ................... 77
29
Der interne Aufbau von FlexiTrust 2.0.......................................................................... 80
30
Zertifikatsantragsformular der FlexiTrust-RA............................................................... 81
31
Revokationsantragsformular der FlexiTrust-RA ........................................................... 82
32
Outlook Web Access für mobilen Zugriff auf Exchange Server,
dargestellt im Internet Explorer ..................................................................................... 85
33
Vordefinierte IPSec Richtlinien von Windows 2000..................................................... 88
34
Snap-In der MMC für die Zertifikats- und CRL-Verwaltung........................................ 89
35
Informationen zu ausgewählten Zertifikaten: links allgemeine Beschreibung,
rechts Details zu den Erweiterungen.............................................................................. 90
36
Die Zertifikatsverwaltung vom Netscape Communicator ............................................. 92
37
Akzeptanz widerrufener Zertifikate: links Internet Explorer 5, rechts Outlook 2000 ... 94
38
Outlook liefert Informationen über die Gültigkeit digitaler Signaturen ........................ 95
39
Suche nach Einträgen im LDAP-Baum ......................................................................... 96
40
Übernahme von Zertifikaten aus LDAP-Verzeichniseinträgen ..................................... 97
41
Die flache Zertifizierungshierarchie der DiBa-CA ...................................................... 100
42
Anordnung der Hard- und Software im Realbetrieb der Public Key Infrastruktur...... 102
43
IIS4: Importassistent der Zertifikatsverwaltung .......................................................... 131
44
IIS4: Wahl des richtigen Zertifikatsspeichers .............................................................. 131
45
IIS4: zugelassene Root-CAs für die Ausstellung von Clientzertifikaten..................... 132
x
Tabellenverzeichnis
1
Bedeutung der key usage Bits in X.509v3 Zertifikaten ................................................. 17
2
Bedeutung der netscape-cert-type Bits in X.509v3 Zertifikaten.................................... 21
3
SSLv3: unterstützte kryptographische Algorithmen...................................................... 31
4
Erläuterungen zum Verständnis der Tabellen [5], [6] und [8] ....................................... 35
5
notwendige Zertifikaterweiterungen für SSL Clientzertifikate ..................................... 36
6
notwendige Zertifikaterweiterungen für SSL Serverzertifikate..................................... 37
7
S/MIMEv3: kryptographische Algorithmen auf Sender- und Empfängerseite ............. 37
8
notwendige Zertifikaterweiterungen für S/MIME Benutzerzertifikate ......................... 38
9
Distinguished Name: Attribut-Typen und ihre Repräsentation als Zeichenfolge.......... 49
10
Zuordnung von Intranet-Diensten und Benutzergruppen .............................................. 62
11
FlexiTrust: unterstützte kryptographische Algorithmen ................................................ 79
xi
xii
Kapitel 1
Einleitung
„Es gibt eine einfache Methode mit der man herausfinden kann, ob eine Verschlüsselungssoftware sicher ist: Man verschlüsselt damit eine Morddrohung
und schickt sie an den amerikanischen Präsidenten. Wenn man nach ein paar
Tagen noch keinen Besuch bekommen hat, dann ist das Verfahren sicher.“
ALTE KRYPTOGRAPHENWEISHEIT
Motivation
Über Jahrtausende hinweg wurde Kryptographie hauptsächlich von Geheimdiensten und Militärs eingesetzt. Viele Regierungen - darunter auch die US-Regierung - sehen auch heute noch
den Einsatz von Verschlüsselung in einem engen Zusammenhang mit krimineller Energie. Die
Folge ist, dass starke Kryptographie in vielen Staaten gesetzlich beschränkt und in einigen gar
ganz verboten wurde. Einige Regierungen vertreten offensichtlich die These, dass ehrliche
Bürger nichts zu verbergen haben und ihre Kommunikation daher nicht schützen müssen.
Aber es gibt gute Gründe auch ohne kriminellen Hintergrund auf Kryptographie zu setzen.
Neben der wachsenden Bedeutung für sichere Netzwerkverbindungen, digitale Signatur und
E-Payment denke man nur an Unternehmen, die ihr wertvolles geistiges Eigentum vor Wirtschaftsspionage zu schützen gedenken. Die Möglichkeiten an derart brisante Informationen zu
gelangen sind vielfältig.
Echelon [JvBuu01] als weltweites Abhörsystem der US-amerikanischen Geheimdienste, liest
einen großen Teil der Internetkommunikation ungehindert mit. Und sogar die Schweiz gibt zu,
ein vergleichbares System mit dem Namen Satos (Satellite Observation) einzusetzen, um
sicherheitspolitisch bedeutsame Informationen zu beschaffen [FlRoe00]. Aber auch jene Internet-Service-Provider (ISP), über deren Rechner eine vertrauliche Nachricht auf dem Weg
durchs Internet läuft, sind in der Lage diese mitzulesen. Bedenkt man die unglaublichen bei
ISPs anfallenden Datenmengen, mag man die gezielte Suche nach einer bestimmten Information mit der Suche nach der berühmten Nadel im Heuhaufen vergleichen. Aber auch hier gibt
es schon Unterstützung in Form von Carnivore [FlRoe00]. Das Schnüffelsystem vom FBI wird
direkt im Rechenzentrum des ISP installiert und erlaubt die gezielte Überwachung von Personen. Dabei werden Daten, die bestimmten Kriterien genügen, aufgezeichnet - ohne dass der
1
Empfänger oder Sender der Daten es bemerkt [CHR00].
Man kommt zu dem Schluss, dass unverschlüsselte Kommunikation mit vertraulichen Daten,
beispielsweise dem wertvollen geistigen Eigentum von Unternehmen, erhebliche Risiken in
sich birgt.
Ziel
Ziel dieser Diplomarbeit ist es, ein einheitliches Sicherheitskonzept für die Allgemeine Deutsche Direktbank AG (DiBa) zu entwickeln, das mobilen Mitarbeitern eine geschützte Kommunikation, die sichere Abfrage von Intranetinhalten sowie Fernadministration des Firmen-LANs
über das Internet ermöglicht.
Um die Sicherheitsanforderungen zu erfüllen, wird eine sog. Public Key Infrastruktur (PKI)
aufgebaut, innerhalb derer ausgewählten Mitarbeitern und Servern elektronische Sicherheitsdienste zur Verfügung gestellt werden. Diese Sicherheitsdienste dienen dazu, elektronische
Dokumente und Daten zwischen Servern und Mitarbeitern über ein Netzwerk mit unsicheren
Leitungen nach fest definierbaren Sicherheitsbedürfnissen auszutauschen.
Eine Public Key Infrastruktur basiert auf kryptographischen Verfahren, die digitale Schlüssel
nutzen. Alle an dieser Infrastruktur teilnehmenden Mitarbeiter bekommen eigene Schlüsselpaare ausgehändigt, die sie für bestimmte Sicherungszwecke, wie beispielsweise Verschlüsselung und digitale Signaturen, verwenden müssen. Diese Schlüsselpaare bestehen jeweils aus
einem privaten und einem öffentlichen Schlüssel. Eine der Hauptaufgaben einer PKI besteht
darin die privaten Schlüssel geeignet an die Mitarbeiter zu verteilen sowie die öffentlichen
zweifelsfrei zuzuordnen und zu publizieren. Die Zuordnung der öffentlichen Schlüssel zu den
Mitarbeitern geschieht über digitale Zertifikate. Diese Zertifikate haben den gleichen Stellenwert wie Ausweise in der realen Welt und sind somit für das Vertrauen in deren Authentizität
verantwortlich.
Um dieses Ziel zu verwirklichen, fiel die Wahl auf die Trustcenter-Software FlexiTrust. Diese
wird in Zusammenarbeit mit der PKI-Forschungsgruppe von Professor Johannes Buchmann an
der Technischen Universität Darmstadt entwickelt und ermöglicht den Aufbau von PKIs in Firmen, Forschungseinrichtungen oder Behörden.
Beim Design der Software wurde auf Flexibilität der einzelnen Module geachtet. Ziel war es,
dass FlexiTrust leicht an unterschiedliche Anwendungsumgebungen anpassbar ist und die Einrichtung einer PKI ohne großen Aufwand möglich wird.
FlexiTrust ist vollständig in Java implementiert und somit plattformunabhängig. Die Software
kann auf allen gängigen Betriebssystemen (wie UNIX oder Windows NT/2000) ohne Veränderung eingesetzt werden und eignet sich so für den Betrieb in heterogenen Umgebungen.
Die Unterstützung gängiger Standards wie X509, LDAP, SSL, TLS, S/MIME, sowie JDBC
garantiert ein Höchstmaß an Interoperabilität mit PKI-fähigen Anwendungen. Von FlexiTrust
ausgestellte Zertifikate können beispielsweise in WWW-Anwendungen, für sichere Email oder
für den Zugang durch Firewalls verwendet werden. Die gängigen Programme von Netscape
oder Microsoft sowie weiterer Anbieter in diesen Bereichen werden dabei unterstützt.
2
Kapitel 1: Einleitung
Ein weiteres Plus von FlexiTrust ist die Skalierbarkeit. Die verschiedenen PKI-Module können
sowohl auf einem einzelnen Rechner als auch verteilt auf mehreren Rechnern installiert werden, sodass sich die Software gleichermaßen für den Aufbau kostengünstiger PKIs in kleineren
oder mittleren Unternehmen, wie für große Behörden oder Konzerne eignet.
Struktur der Arbeit
Die vorliegende Diplomarbeit gliedert sich in die folgenden Kapitel:
Kapitel 2 Erklärt notwendige theoretische Grundlagen kryptographischer Techniken wie
Public Key Verschlüsselung, digitale Signaturen usw., soweit sie zum Verständnis
der weiteren Kapitel hilfreich sind.
Kapitel 3 Befasst sich mit dem Konzept der Public Key Infrastrukturen. Dazu werden
Grundbegriffe wie Zertifikate, Trustcenter sowie Verfahren zur Verschlüsselung
erklärt und auf die rechtlichen Zusammenhänge eingegangen.
Kapitel 4 Eine Bedarfsanalyse ermittelt den konkreten Bedarf des Kunden und stellt
anschließend ein geeignetes Sicherheitskonzept auf Basis von PKI-Diensten auf.
Kapitel 5 Bereits beim Kunden im Einsatz befindliche, sowie (falls notwendig) zusätzliche
Software wird auf Möglichkeiten zur kryptographischen Absicherung hinsichtlich
einer Integration in die PKI untersucht.
Kapitel 6 Schildert die praktische Umsetzung der Zertifizierungsinfrastruktur.
Kapitel 7 Diskutiert einige interessante und z. T. bedenkliche Richtlinien der Policy mit
besonderem Augenmerk auf die speziellen Anforderungen des SigG.
Kapitel 8 Fasst noch einmal kurz die vorangegangenen Kapitel zusammen und gibt einen
Ausblick auf mögliche zukünftige Erweiterungen.
Anhang
Anhang A Definiert Zertifizierungsrichtlinien (die sog. Policy) nach denen die einzurichtende
Zertifizierungsinstanz Zertifikate ausstellt.
Anhang B Enthält nützliche Hinweise zur Einrichtung bestehender Softwarekomponenten,
welche für den Betrieb der PKI notwendig sind.
3
4
Kapitel 2
Kryptographische Grundlagen
In diesem Kapitel werden einige Grundlagen der klassischen Kryptographie vorgestellt, die für
das Verständnis der nachfolgenden Kapitel hilfreich sind. Die klassische Kryptographie bildet
die Basis für die kryptographischen Protokolle und Verfahren von Public Key Infrastrukturen
(PKI). Die im Folgenden besprochenen Grundlagen beschränken sich auf Verfahren zur Verschlüsselung von Daten (wie Nachrichten, Dokumenten oder Dateien), wobei zwischen symmetrischen und asymmetrischen Verfahren unterschieden wird. Abschließend folgt ein
Einblick in die digitale Signatur, dem elektronischem Äquivalent zur eigenhändigen Unterschrift.
Alice, Bob und Malory
In Büchern und Beispielen zur Kryptographie kommen immer wieder dieselben Personen vor,
um kryptographische Prinzipien zu veranschaulichen. Dabei handelt es sich um Alice und Bob,
die über das Internet Daten austauschen, sowie Malory, der die Rolle des Angreifers übernimmt und versucht, deren Daten zu manipulieren oder wenigstens mitzulesen. Diesen beispielhaften Vorgaben möchte ich mich mit dieser Arbeit anschließen. Bei Bedarf werden
weitere Personen eingeführt.
2.1
Symmetrische Verschlüsselungsverfahren
Bei symmetrischen Verschlüsselungsverfahren lässt sich der zum Entschlüsseln benutzte
Schlüssel leicht aus demjenigen zum Verschlüsseln berechnen (und umgekehrt). Sehr häufig
stimmen beide Schlüssel sogar überein. Man spricht daher meist von ein und demselben
Schlüssel.
Abbildung 1 zeigt, wie symmetrische Verschlüsselung prinzipiell funktioniert. Auf den Klartext (Plaintext), der die zu verschlüsselnden Daten repräsentiert, wird eine Verschlüsselungsfunktion in Abhängigkeit eines kryptographischen Schlüssels angewendet. Dieser Schlüssel
wird als geheimer Schlüssel bezeichnet. Der aus dieser Verschlüsselung resultierende Chiffretext (Ciphertext) lässt sich ausschließlich mit dem geheimen Schlüssel wieder entschlüsseln.
Vor dem Einsatz eines symmetrischen Verschlüsselungsverfahrens müssen sich Alice und Bob
5
auf einen gemeinsamen geheimen Schlüssel einigen. Alice benötigt für jeden Kommunikationspartner allerdings unterschiedliche gemeinsame Schlüssel. Bei n verschiedenen Personen,
die alle untereinander symmetrisch verschlüsselt kommunizieren möchten, werden n·(n-1)/2
Schlüssel benötigt. Für 100 Personen sind das schon 4950 zu vereinbarende, unterschiedliche
geheime Schlüssel. Problematisch stellt sich auch der eigentliche Austausch dieser gemeinsamen geheimen Schlüssel mit den Kommunikationspartnern dar. Diese könnten beim Transport
über unsichere Leitungen von Angreifern abgefangen werden.
Klartext
Klartext
Geheimer
Schlüssel
Geheimer
Schlüssel
Chiffretext
Abbildung 1 symmetrische Verschlüsselung
Zu den bekanntesten symmetrischen Verschlüsselungsverfahren gehören DES (Data Encryption Standard) und IDEA (International Data Encryption Algorithm). DES gilt aber nach heutigen Erkenntnissen nicht mehr als sicher. Aus diesem Grund wird das DES-Verfahren meist nur
noch in Form einer Dreifachverschlüsselung (Tripple-DES, auch 3DES genannt) verwendet.
Weitere symmetrische Verfahren, die heute zunehmend durch Tripple-DES ersetzt werden,
sind AES, RC2 und RC4.
2.2
Asymmetrische Verschlüsselungsverfahren
Asymmetrische Verschlüsselungsverfahren werden auch Public Key Verschlüsselungsverfahren genannt. Sie bedienen sich im Gegensatz zu den symmetrischen Verfahren zwei verschiedener Schlüssel zum Ver- und Entschlüsseln. Wobei sich keiner der beiden aus dem jeweiligen
anderen ermitteln lässt. Bei den beiden Schlüsseln, welche auch als Schlüsselpaar (key pair)
bezeichnet werden, handelt es sich um einen sog. öffentlichen (public key) und einen sog. privaten Schlüssel (private key).
Der öffentliche Schlüssel wird zur Verschlüsselung verwendet (siehe Abbildung 2) und muss
nicht geheim gehalten werden. Er kann an beliebig viele Personen weitergegeben oder in
einem Verzeichnis öffentlich zugänglich gemacht werden. Der private Schlüssel dient der Entschlüsselung, er muss daher privat, d. h. geheim gehalten werden.
Jeder der im Besitz des öffentlichen Schlüssels eines Schlüsselpaares ist, kann Daten verschlüsseln, die ausschließlich vom Besitzer des dazugehörenden privaten Schlüssels entschlüsselt werden können. Alice muss nur ihren öffentlichen Schlüssel bekannt geben, und schon
kann sowohl Bob, als auch der ihr unbekannte Zacharias, damit Daten verschlüsseln, die ausschließlich Alice mit ihrem privaten Schlüssel wieder entschlüsseln kann.
6
Kapitel 2: Kryptographische Grundlagen
Asymmetrische Verfahren vereinfachen das Schlüsselmanagement erheblich. Bei n verschiedenen Personen, die alle untereinander asymmetrisch verschlüsselt kommunizieren möchten,
werden nur n unterschiedliche Schlüsselpaare benötigt. Ungünstiger Weise sind die Rechenoperationen auf denen asymmetrische Verfahren aufbauen erheblich aufwändiger als diejenigen, welche bei symmetrischen Verfahren verwendet werden. Asymmetrische Verschlüsselung
ist damit wesentlich zeitintensiver als Symmetrische.
Klartext
Klartext
Öffentlicher
Schlüssel
Privater
Schlüssel
Chiffretext
Abbildung 2 asymmetrische Verschlüsselung
Zu den bekanntesten asymmetrischen Verschlüsselungsverfahren gehören RSA (das nach seinen Erfindern Rivest, Shamir und Adleman benannt wurde), ElGamal und Verfahren auf Basis
der Elyptic Curve Cryptography.
2.3
Hybridverfahren
Als hybride Verschlüsselungsverfahren werden jene Algorithmen bezeichnet, die symmetrische und asymmetrische Verfahren kombinieren, um die Vorteile beider nutzen zu können.
Ein zufälliger, symmetrischer Sitzungsschlüssel (session key) wird für die Verschlüsselung der
ganzen Sitzung verwendet. Der eigentliche Klartext wird z. B. mit IDEA unter diesem Sitzungsschlüssel verschlüsselt. Für jede weitere Sitzung wird ein neuer Sitzungsschlüssel generiert. Der Austausch des symmetrischen Sitzungsschlüssels erfolgt durch ein asymmetrisches
Verfahren wie RSA unter Verwendung des öffentlichen Schlüssels des Empfängers. Beide verschlüsselten Informationen (der Sitzungsschlüssel und der Chiffretext) werden zusammen an
den Empfänger übermittelt. Dieser muss als erstes den geheimen Sitzungsschlüssel mit seinem
privaten Schlüssel entschlüsseln und kann anschließend den eigentlichen Klartext mit dem Sitzungsschlüssel entschlüsseln. Abbildung 3 zeigt das Verfahren im Überblick.
Hybride Verfahren nutzen somit langsame, asymmetrische Verfahren ausschließlich zur Verund Entschlüsselung des relativ kurzen Sitzungsschlüssels. Der eigentliche, mit unter sehr
lange, Klartext wird mithilfe symmetrischer Verfahren verschlüsselt. Dadurch bedient man
sich neben dem Geschwindigkeitsvorteil symmetrischer, auch dem vereinfachten Schlüsselmanagement asymmetrischer Verfahren.
7
Sender
Empfänger
Klartext
Klartext
Geheimer
Sitzungsschlüssel
Öffentlicher
Schlüssel
Verschlüsselter
Sitzungsschlüssel
Geheimer
Sitzungsschlüssel
Privater
Schlüssel
Verschlüsselter
Sitzungsschlüssel
Chiffretext
Chiffretext
Abbildung 3 hybride Verschlüsselung
2.4
Digitale Signaturen
Als digitale Signatur bezeichnet man die Unterschrift (Verschlüsselung) mit dem privaten
Schlüssel eines asymmetrischen Verfahrens. Die Überprüfung (Entschlüsselung) der digitalen
Signatur erfolgt mit dem dazugehörigen öffentlichen Schlüssel. Damit die Unterschrift, die mit
dem privaten Schlüssel des Schlüsselinhabers erfolgt, auch die Authentizität und Integrität
eines Klartextes (z. B. eines Dokumentes, oder einer Nachricht) bezeugt, müssen folgende
Voraussetzungen erfüllt sein.

Fälschungssicherheit
Die digitale Signatur darf nicht zu fälschen sein. Damit wird bewiesen, dass nur
der Unterzeichner und kein anderer den Klartext unterschrieben hat.

Authentizität
Die Echtheit muss mit dem öffentlichen Schlüssel überprüfbar sein. Gelingt dies
nicht, wurde die Signatur entweder mit einem anderen privaten Schlüssel erzeugt
und ist damit nicht von der angegebenen Person, oder der Klartext wurde nach dem
Signieren verändert.

Nicht-Wiederverwendbarkeit
Die digitale Signatur darf nicht in anderen Dokumenten wiederverwendet werden
8
Kapitel 2: Kryptographische Grundlagen
können.

Integrität
Der dazugehörige Klartext darf nicht (unbemerkt) verändert werden können, ohne
dass die digitale Signatur ungültig wird.
Funktionsweise
Um dies zu erreichen, bedient sich die digitale Signatur einer Eigenschaft bestimmter asymmetrischer Verfahren: Ver- und Entschlüsselungsoperation sind kommutativ. D. h. Klartexte können auch mit dem privaten Schlüssel verschlüsselt werden, um sie anschließend mit dem
öffentlichen wieder zu entschlüsseln. Die Reihenfolge ist genau umgekehrt zu dem in
Abschnitt [2.2] vorgestellten Vorgehen. Klartexte, die auf diese Weise verschlüsselt sind, können von jedem wieder entschlüsselt werden, der in Besitz des öffentlichen Schlüssels ist.
Durch die Entschlüsselung mit dem öffentlichen Schlüssel erfolgt quasi eine Prüfung der
Unterschrift. Ist diese gültig, d. h. kann der Klartext entschlüsselt werden, dann kann niemand
anderes als der Inhaber des dazugehörigen privaten Schlüssels den Klartext verschlüsselt
(unterschrieben) haben.
Sender
Empfänger
Klartext
h(x)
Klartext
Hashfunktion
Hashwert
h(x)
11
00 10
01 01
01
11
00 10
01 01
01
Hashwert
Hashfunktion
==?
Privater
Schlüssel
Digitale Signatur
11
00 10
01 01
01
Hashwert
Öffentlicher
Schlüssel
Digitale Signatur
Abbildung 4 Digitale Signatur
U. a. weil Klartexte, die signiert werden sollen, mitunter recht lang werden können und asymmetrische Verfahren relativ langsam arbeiten, wird üblicherweise an Stelle des Klartextes
selbst nur dessen Hashwert unterschrieben. Dieser Hashwert (auch als Message Digest
bezeichnet) bildet große Klartexte mit beliebiger Länge auf sehr kurze Bitfolgen ab, aus denen
der ursprüngliche Klartext nicht wieder rekonstruiert werden kann. Zudem ist es unmöglich,
9
den Klartext so zu verfälschen, dass er nachher noch denselben Hashwert liefert. Häufig verwendete Hashfunktionen sind MD4 (Message Digest 4), MD5 (Message Digest 5), SHA-1
(Secure Hash Algorithm) sowie RIPEMD-160.
Die unterschriebenen Hashwerte bilden zusammen mit dem (unverschlüsselten) Klartext die
digitale Signatur. Der Empfänger entschlüsselt zuerst den unterschriebenen Hashwert mit dem
öffentlichen Schlüssel und generiert anschließend selbst den Hashwert des Klartextes, um ihn
mit dem vom Sender erzeugten Hashwert zu vergleichen. Sind beide identisch, bedeutet dies,
dass der Absender den Hashwert für genau den Klartext erzeugt hat, der auch beim Empfänger
zusammen mit der digitalen Signatur angekommen ist. Abbildung 4 stellt das Verfahren noch
einmal grafisch dar.
Digitale Signaturen spielen eine große Rolle bei der Ausstellung von Zertifikaten für Public
Key Infrastrukturen. Zertifizierung und PKI sind Inhalt des folgenden Kapitels.
Zu den bekanntesten Signaturverfahren gehören ElGamal und DSA (Digital Signature Algorithm) sowie das asymmetrische Verschlüsselungsverfahren RSA.
2.5
Zusammenfassung
In diesem Kapitel wurden die wichtigsten Grundlagen der klassischen Kryptographie vorgestellt, die für das Verständnis der folgenden Kapitel hilfreich sind.
Neben der symmetrischen Kryptographie mit ihrer vergleichsweise hohen Verarbeitungsgeschwindigkeit wurde die asymmetrische Kryptographie (auch Public Key Kryptographie
genannt) sowie Hybrid-Verfahren, die beides kombinieren, vorgestellt. Symmetrische Verfahren verwenden meist sowohl zur Ver- als auch zur Entschlüsselung denselben Schlüssel.
Asymmetrische Verfahren hingegen verwenden zwei unterschiedliche Schlüssel, einen Geheimen und einen Öffentlichen.
Digitale Signaturen dienen dazu, die Authentizität und Integrität von Dokumenten zu bestätigen. Sie sind das elektronische Äquivalent zur eigenhändigen Unterschrift.
10
Kapitel 3
Public Key Infrastrukturen
Die im vorangegangenen Kapitel vorgestellten kryptographischen Verfahren bilden die Grundlage für den Aufbau einer Public Key Infrastruktur (PKI). Eine PKI basiert auf kryptographischen Verfahren, die digitale Schlüssel nutzen. Zu den Aufgaben einer PKI gehört die
Generierung und anschließende Zertifizierung von Schlüsselpaaren sowie die Verteilung von
öffentlichen Schlüsseln.
Eine PKI lässt sich organisatorisch in mehrere Komponenten aufteilen. Dazu gehört eine Zertifizierungsstelle, welche Personen und Dienste (Rechner) zertifiziert (d. h. deren Schlüssel
beglaubigt) und somit für das Vertrauen in deren Authentizität verantwortlich ist. Zertifikate
einer solchen Infrastruktur haben den gleichen Stellenwert wie Ausweise in der realen Welt
und stellen damit so etwas wie elektronische Identitätsnachweise von Personen und Diensten
dar. Die zertifizierten digitalen Schlüssel werden u. a. dazu verwendet, digitale Signaturen auszustellen sowie Dokumente und den Datenverkehr zwischen Rechnern zu verschlüsseln. Eine
weitere Komponente ist die Registrierungsstelle, die als Teil der PKI die organisatorische
Schnittstelle zwischen Personen und der PKI einnimmt. Ebenso dazu gehören Verzeichnisse,
in denen ausgestellte Zertifikate öffentlich zur Verfügung gestellt werden und feste Richtlinien
(Policies), um technische, organisatorische, personelle sowie infrastrukturelle Maßnahmen zu
definieren.
In diesem Kapitel werden die dazu notwendigen Grundbegriffe und Standards besprochen. Am
Schluss folgt noch ein Einblick in die rechtlichen Aspekte, die den Betrieb einer PKI und die
Verwendung von Kryptographie im Allgemeinen betreffen.
3.1
Grundlegende Dienste einer PKI
Zu den Hauptaufgaben einer PKI gehört die Gewährleistung von Authentizität, Vertraulichkeit
und Integrität von Personen, Diensten oder Daten während und nach einer Kommunikation.
Man spricht dabei auch von den grundlegenden Diensten einer PKI.
Authentizität
Die Authentizität gewährleistet, dass eine Person die ist, für die sie sich ausgibt. Authentizität
11
ist notwendig, um sicheren Zugang zu exklusiven Diensten (wie vertraulichen Internetseiten)
zu ermöglichen. In solchen Fällen muss die Authentizität von Diensten gewährleistet werden,
um sicherzustellen, dass Personen mit dem „richtigen“ Dienst verbunden sind. In diesem
Zusammenhang ebenso wichtig ist die Sicherstellung der Authentizität der Personen selbst,
falls angebotene Dienste bestimmten Personengruppen vorbehalten sein sollen. Dieser Vorgang wird häufig auch als Authentisierung oder Authentifizierung bezeichnet und bedeutet
somit die Verifizierung der Identität der Kommunikationspartner. Authentizität ist weiterhin
notwendig, um zu gewährleisten, dass übertragene Daten auch tatsächlich vom richtigen Kommunikationspartner stammen.
Authentizität umfasst somit sowohl Subjekte (Personen und Dienste) als auch Objekte (Daten)
einer Kommunikation.
Vertraulichkeit
Vertraulichkeit gewährleistet, dass der Inhalt übertragener Daten nur autorisierten Personen
zur Kenntnis gelangt. Darunter fallen sowohl vertrauliche Dokumente (z. B. mit Kreditkarteninformationen oder Unternehmensgeheimnissen) als auch die Datenkommunikation zwischen
zwei Rechnern.
Integrität
Daten-Integrität steht für die Nichtveränderbarkeit von Daten. Bei der Übertragung vertraulicher Daten muss sichergestellt sein, dass diese unterwegs nicht verändert und dass keine Daten
hinzugefügt oder entfernt werden.
In Verbindung mit der Authentizität ermöglicht die Integrität eine Verbindlichkeit in dem
Sinne, dass Urheber von Dokumenten zweifelsfrei und eindeutig bestimmt werden können.
3.2
Schlüsselmanagement
Voraussetzung für den Einsatz eines Public Key Verschlüsselungsverfahrens ist ein funktionierendes Schlüsselmanagement. Unter Schlüsselmanagement versteht man die Generierung,
Speicherung, Verteilung und Anwendung kryptographischer Schlüssel. Es müssen Maßnahmen getroffen werden, um eine Kompromittierung von Schlüsseln zu verhindern. Für den Fall,
dass Angreifer in den Besitz geheimer Schlüssel gelangen, wird selbst das beste Kryptoverfahren nutzlos. Die Kompromittierung von privaten Anwenderschlüsseln stellt zugleich die größte
Schwachstelle einer PKI dar. Verglichen mit der Alternative eine aufwändige Kryptoanalyse
durchzuführen, ist die Kompromittierung - also z. B. der Diebstahl eines Schlüssels - meist mit
erheblich geringerem Aufwand erreichbar. Man erkennt, dass ein besonderes Augenmerk auf
die Sicherheitspolitik gelegt werden muss, um ein sicheres zentrales Management von Schlüsseln zu erreichen.
Zusammenfassend kann man sagen, dass es sicher einfacher ist, an geheime Schlüssel zu
gelangen, als ein Kryptoverfahren zu brechen.
Schlüsselgenerierung
Sicherheit beim Einsatz kryptographischer Schlüssel hängt nicht zuletzt von der Schlüssellänge ab. Schlüssellängen jenseits von 128 Bit gelten heute als Mindestvoraussetzung für den
12
Kapitel 3: Public Key Infrastrukturen
Einsatz symmetrischer Verschlüsselungsverfahren [PhZim99]. Die bisherigen 40 Bit und 56
Bit Exportversionen US-amerikanischer Softwareprodukte, wie etwa des Netscape Navigators
oder des Microsoft Internet Explorers, gelten als schwach und können von entschlossenen
Angreifern in kurzer Zeit überwunden werden. Eine Schlüssellänge von 1024 Bit gilt nach
Stand der Technik als sicher beim Einsatz asymmetrischer Verschlüsselungsverfahren wie
RSA. Die lange Zeit verwendeten 512 Bit RSA Schlüssel eignen sich heute nicht mehr für
Anwendungen mit hohen Sicherheitsanforderungen, da es schon 1999 gelungen ist, solche
Verschlüsselungen zu brechen [HtRiele99].
Entsprechend schreibt die Regulierungsbehörde für Telekommunikation und Post (RegTP) als
zuständige Behörde gemäß SigG (siehe Abschnitt [3.9.2]) eine Schlüssellänge für RSASchlüssel von 1024 Bit oder länger vor, wenn bis Ende 2003 die Sicherheit des Verfahrens
gewährleistet sein soll [RegTP-98].
Generell gilt, dass asymmetrische Schlüssel erheblich größer gewählt werden müssen als Symmetrische, um eine vergleichbare Sicherheit zu gewährleisten. Eine solche Abschätzung liefern
Lenstra und Verheul in [LenVerh99]. Allerdings sollte man, sowohl bei asymmetrischer, als
auch bei symmetrischer Verschlüsselung die Schlüssellänge nicht zu groß wählen, da die
Geschwindigkeit des Ver- und Entschlüsselns mit wachsender Schlüssellänge sinkt.
Schlüsselspeicherung
Der private Teil eines asymmetrischen Schlüsselpaares sollte möglichst sicher auf der Festplatte (oder Diskette) des Schlüsselinhabers gespeichert werden. Um dabei maximale Sicherheit zu gewährleisten, muss der Schlüssel wiederum selbst verschlüsselt abgelegt werden.
Üblicherweise erreicht man dies durch den Einsatz von symmetrischen Verschlüsselungsverfahren, wobei ein Passwort als Schlüssel dient. Erst nach Eingabe dieses Passwortes wird der
private Schlüssel für Anwendungsprogramme nutzbar. Mehr Sicherheit bietet der Einsatz von
Smartcards anstelle der Festplatte. Einige Smartcards geben den privaten Schlüssel auch nach
Eingabe der PIN nicht Preis und führen stattdessen die kryptographischen Operationen ausschließlich selbst aus.
Alte Schlüssel, die nicht mehr in Gebrauch sind und durch Neue ersetzt wurden, sollten auf
sichere Weise vom verwendeten Datenträger entfernt werden. Die Anforderung an ein sicheres
Entfernen geht üblicherweise über das einfache Löschen mittels Betriebssystemfunktionen
hinaus. Die Schlüsseldaten sollten vom Betriebssystem nicht einfach zum Überschreiben freigegeben werden. Eine Lösung bieten hier spezielle Tools, die zum Löschen freigegebene
Dateien vorher mehrfach mit sinnlosen Daten überschreiben, um zu verhindern, dass gelöschte
Speicherbereiche mit sensiblen Schlüsseldaten wieder hergestellt werden können.
Schlüsselanwendung
Der Geheimhaltung des eigenen privaten Schlüssels kommt eine große Bedeutung zu, mit ihr
steht und fällt letztlich die Vertraulichkeit bzw. die Zurechenbarkeit verschlüsselter oder
signierter Daten. Daher liegt die Verantwortung beim Umgang mit Schlüsselpaaren beim
Anwender selbst. Dieser muss entsprechend über die Bedeutung der Geheimhaltung bei der
Handhabung privater Schlüssel informiert bzw. geschult werden. Bei Verschlüsselungsverfahren auf Public Key Basis, welche innerhalb fester Firmenstrukturen eingesetzt werden, gehören dazu auch Arbeitsanweisungen, die von Mitarbeitern eingehalten werden müssen.
13
Schlüsselverteilung
Um die Verbreitung öffentlicher Schlüssel auf sichere und zuverlässige Weise zu ermöglichen,
wurden digitale Zertifikate geschaffen. Diesem Thema widmet sich der folgende Abschnitt.
3.3
Zertifikate
Funktion
Ein digitales Zertifikat ist eine signierte Datenstruktur, die neben einem öffentlichen Schlüssel
noch den Namen seines Besitzers enthält. Das Zertifikat sorgt somit für eine sichere Zuordnung des Schlüssels zu einem Subjekt1. Das Signieren selbst kann dabei von verschiedenen
vertrauenswürdigen Einrichtungen übernommen werden. Eine derartige Einrichtung muss das
Vertrauen aller an dieser Kommunikation beteiligter Personen genießen, inkl. des Zertifizierten
selbst. Auf Basis dieser Vertrauensbeziehung wird gewährleistet, dass der signierte öffentliche
Schlüssel auch wirklich zur zertifizierten Person gehört und für die sichere Kommunikation
mit dieser verwendet werden kann. Umgekehrt bedeutet dies: Schenkt ein Kommunikationspartner dieser Einrichtung kein Vertrauen, so vertraut er auch nicht deren Zertifikat - und somit
nicht der Zuordnung des Schlüssels zur Person. Dies wiederum hat zur Konsequenz, dass die
Verwendung des Schlüssels für ihn keine sichere Kommunikation gewährleisten würde. Sehr
häufig, aber nicht in allen Vertrauensmodellen (siehe Kapitel [3.5]), wird die Aufgabe einer
solchen Einrichtung von einem Trustcenter übernommen (mehr dazu in Kapitel [3.4]). Wenn
im Folgenden also von einer Zertifizierungsstelle gesprochen wird, kann dies neben einer vertrauten Person auch ein Trustcenter sein.
Allgemeiner Aufbau
Neben den Angaben zur zertifizierten Person enthält ein Zertifikat üblicherweise weitere Informationen, wie in Abbildung 5 zu sehen ist. Das Zertifikat selbst besitzt eine Seriennummer, um
es eindeutig von anderen unterscheiden zu können. Weiterhin ist ein Gültigkeitszeitraum vorgesehen, innerhalb dessen ein Zertifikat als vertrauenswürdig gilt (solange es nicht vorzeitig
widerrufen wurde, dazu später mehr in Kapitel [3.4.2]).
Folgendes Beispiel verdeutlicht die Notwendigkeit digitaler Zertifikate bei der Verteilung
asymmetrischer Schlüssel: Alice möchte mit Bob kommunizieren; Bob sendet dazu seinen
öffentlichen Schlüssel ungeschützt per Email an Alice; allerdings bemerkt Malory diesen Vorgang, fängt die Email ab, tauscht Bobs Schlüssel gegen seinen Eigenen aus und sendet diesen
an Alice weiter; Alice vertraut dem Schlüssel nun fälschlicherweise und verwendet ihn für jede
weitere Kommunikation mit Bob; Malory kann somit alle Emails von Alice an Bob entschlüsseln und lesen; um unauffällig zu bleiben, muss er nun noch die Emails neu, mit dem (richtigen) öffentlichen Schlüssel von Bob, verschlüsseln und an ihn weiterschicken. Dieser
Vorgang, den man als Man-in-the-middle-Attacke bezeichnet, kann durch den Einsatz digitaler
Zertifikate wirksam unterbunden werden.
1. Im weiteren Verlauf dieses Kapitel wird der Einfachheit halber von Personen gesprochen, obwohl allgemein als Subjekte auch Dienste wie Webserver o. ä. gemeint sein können.
14
Name des Zertifizierten:
Bob Offliner
Angaben zur zertifizierten
Person oder Einrichtung
Öffentlicher Schlüssel des Zertifizierten:
59A6 105D 17E1 CC72 9C35 15B8 0E96 6A56 6142 39DC
DEE4 D9E0 E521 118D 1A46 26DB 1C5F AA7E B0C6 ...
Angaben zum Zertifikat
Seriennummer des Zertifikats:
1234567890
Gültigkeitszeitraum:
01.03.2001-30.09.2001
Zertifikataussteller:
Allgemeine Deutsche Direktbank AG, Deutschland
Signatur des Zertifikatausstellers:
DEE4 D9E0 E521 118D 1A46 DCBA DFA5 022E 1D01 8388
26DB 1C5F AA7E B0C6 598E 8B8A D0B7 47C5 B0D1 ...
Zertifikat
Abbildung 5 Allgemeiner Aufbau eines digitalen Zertifikates
3.3.1
Zertifikate nach X.509v3
Einer der am weitesten verbreiteten Standards für digitale Zertifikate ist X.509v3. Zertifikate,
die dem X.509 Format entsprechen, sind eigentlich als Bestandteil des X.500 ISO-Standards
gedacht gewesen. X.500 definiert einen weltweiten, hierarchischen Verzeichnisbaum, in dem
alle Objekte wie Länder, Organisationen, Orte, Personen etc. eindeutige Namen erhalten. Die
Namen sind dabei global eindeutig definiert sowie hierarchisch strukturiert und relativ zur
Position im Verzeichnisbaum festgelegt. An dieser Stelle wird auf weitere Details verzichtet,
da Verzeichnisdienste wie X.500 im Abschnitt [3.8] ausführlich behandelt werden.
X.500 konnte sich bis heute nicht auf breiter Front durchsetzen. Der Zertifikatsstandard nach
X.509 hingegen schon, er liegt mittlerweile in Version 3 vor und bildet die Basis für viele
kryptographische Standards, zum Beispiel SSL und S/MIME. Beide werden im Kapitel [3.7]
eingehend besprochen. Eine Ausnahme bildet PGP (Kapitel [5.2.1]), welches sein eigenes Zertifikatformat verwendet.
3.3.1.1 Standardfelder
Wie bereits angesprochen, enthalten Zertifikate neben Angaben zur zertifizierten Person noch
weitere, z. B. Angaben zur Identifizierung der Zertifizierungsstelle sowie allgemeine Angaben,
um ein gewisses Maß an Sicherheit gewährleisten zu können. In der Datenstruktur von Zertifikaten nach dem X.509v3 Standard sind u. a. die im Folgenden genannten Felder enthalten
[RFC2459]. Um den Verwendungszweck einzelner Felder zu verdeutlichen, wird bei einigen
ein Beispiel in hervorgehobener Schrift angegeben.

Version (version)
Die Versionsnummer des verwendeten X.509-Standards: der Wert 0x0 entspricht
X.509v1, 0x1 entspricht X.509v2 und 0x2 entspricht der aktuellen Version 3.
Version = 0x2
15

Seriennummer des Zertifikates (serial number)
Alle von derselben Zertifizierungsstelle ausgestellten Zertifikate erhalten eine eindeutige, fortlaufende Seriennummer. Dadurch ist jedes Zertifikat über seine Seriennummer und die Zertifizierungsstelle eindeutig bestimmbar.
serial number = 123456

Bezeichnung des Signaturverfahrens (signature algorithm)
Angaben zum verwendeten kryptographischen Algorithmus, mit dem das Zertifikat von einer Zertifizierungsstelle signiert wurde. z. B. RSA, DSA oder ein Verfahren auf Basis elliptischer Kurven.
signature algorithm = md5RSA

Name der Zertifizierungsstelle (issuer)
Bezeichnet die Zertifizierungsstelle, welche das Zertifikat herausgegeben und
signiert hat. Der Name (Distinguished Name) kennzeichnet einen Eintrag im hierarchischen X.500- (oder LDAP-) Verzeichnisbaum und ist daher eine eindeutige
Identifizierung der Zertifizierungsstelle. Mit dem Namensmodell von LDAP-Verzeichnissen beschäftigt sich Kapitel [3.8.2.3].
issuer =

CN=DiBa-PrototypeCA,OU=IT,
O=Allgemeine Deutsche Direktbank AG,C=DE
Name des Zertifizierten (subject)
Name des Zertifikatinhabers gemäß dem X.500 Standard (siehe auch issuer).
subject =
CN=Bob Offliner,OU=Marketing,
O=Allgemeine Deutsche Direktbank AG,C=DE

Gültigkeitszeitraum (validity)
Ein Anfangs- und Enddatum kennzeichnet den Zeitraum, während dessen das Zertifikat Gültigkeit besitzt. Außerhalb dieses Zeitraumes kann der Zertifikatsaussage
nicht mehr vertraut werden und es muss ein neues Zertifikat beantragt werden.

Öffentlicher Schlüssel des Zertifizierten (subject public key info)
Enthält den öffentlichen Schlüssel und ermöglicht damit die Zuordnung zur zertifizierten Person.

Digitale Signatur der Zertifizierungsstelle (signature)
Die digitale Signatur bestätigt die Echtheit des Zertifikates, und ordnet damit den
darin enthaltenen öffentlichen Schlüssel eindeutig der als Zertifikatnehmer
benannten Person zu.
3.3.1.2 Standarderweiterungen
Um möglichst effektiv auf zukünftige Anforderungen reagieren zu können und nicht jedes Mal
eine neue Version des X.509 Standards definieren zu müssen, sieht X.509v3 die Möglichkeit
vor, das Format um eigene Felder, sog. generische Zertifikaterweiterungen (Extensions), zu
erweitern. Dazu wurde ein spezieller Syntax definiert, mit dessen Hilfe für eigene Anwendungen zusätzliche Informationen in ein Zertifikat einfügt werden können. Die Zertifikate können
so ohne großen Aufwand individuell an die Bedürfnisse eines Unternehmens oder einer Software angepasst werden.
16
Erweiterungen können zu diesem Zweck mithilfe eines sog. Critical Bits als kritisch oder
unkritisch eingestuft werden. Kritisch bedeutet in diesem Zusammenhang, dass die korrekte
Interpretation dieser Erweiterung für die Verwendung des Zertifikates eine notwendige Bedingung darstellt. Sobald eine Software diese Erweiterung nicht kennt, muss ein Zertifikat gemäß
dieser Theorie als ungültig betrachtet und zurückgewiesen werden, auch wenn das Zertifikat
an sich technisch korrekt ist. Unbekannte und gleichzeitig unkritische Erweiterungen hingegen
können von einer Software einfach ignoriert werden, ohne dass dies Auswirkungen auf das
gesamte Zertifikat hätte. Es lässt sich leider nicht verhindern, dass einige X.509v3 Zertifikate
durch kritische Erweiterungen zu einander inkompatibel sind.
Folgende Erweiterungen sind standardmäßig in Zertifikaten der Version 3 enthalten
[RFC2459]:

Zertifizierungspfad (basic constraints)
Diese Erweiterung besteht aus mehreren Feldern. Eines davon dient der Unterscheidung von Zertifikaten einer Zertifizierungsstelle (CA-Zertifikaten) und Zertifikaten von Personen oder Servern (Entity-Zertifikaten). Ein weiteres Feld enthält
Vorgaben für den Zertifizierungspfad, wie z. B. die maximal erlaubte Tiefe einer
Zertifizierungshierarchie. Eine Längenangabe im Zertifizierungspfad von 0 bedeutet für die Zertifizierungsstelle, dass nur Zertifikate für Personen bzw. Server ausgestellt werden dürfen, nicht jedoch für untergeordnete Zertifizierungsstellen. Erst
eine Angabe von 1 oder größer ermöglicht hierarchische Zertifizierungsmodelle,
wie sie in Abschnitt [3.5.3] besprochen werden.
basic constraints = critical, ca=TRUE, pathlen=0

Verwendungszweck des Schlüssels (key usage)
Die Richtlinien, nach denen eine Zertifizierungsstelle Zertifikate ausstellt, können
Einschränkungen bezüglich des Verwendungszweckes von Zertifikaten aufweisen.
Diese Erweiterung erlaubt daher den Verwendungszweck des in einem Zertifikat
enthaltenen Schlüssels anzugeben. Die Verwendung des Schlüssels kann - wenn
gewünscht - eingeschränkt werden, sodass dieser beispielsweise ausschließlich
zum Verifizieren von Widerrufslisten oder Zertifikaten aber nicht innerhalb eines
Schlüsselaustausches verwendet werden darf. Tabelle [1] zeigt die zur Verfügung
stehenden Verwendungsmöglichkeiten, welche in Form eines Bitstrings (mittels
Setzen einzelner Bits) miteinander kombiniert werden können. Allerdings ergeben
durchaus nicht alle Verwendungszwecke in Kombination miteinander einen Sinn,
wie beispielsweise keyAgreement in Verbindung mit encipherOnly.
Bit
Bezeichnung
Verwendungszweck des öffentlichen Schlüssels
0
digitalSignature
Prüfung von speziellen Signaturen zur Entity- und DatenquellenAuthentifizierung. Gilt nicht für die Verifizierung von Zertifikaten, CRLs und bewussten Signaturen (Bits 1, 5 und 6).
1
nonRepudiation
Keine Zurückweisung bei der Prüfung von Signaturen. Gilt nicht
für die Verifizierung von Zertifikaten und CRLs (Bits 5 und 6).
2
keyEncipherment
Verschlüsselung von Sitzungsschlüsseln (Schlüsselmanagement,
Schlüsselübertragung).
Tabelle 1 Bedeutung der key usage Bits in X.509v3 Zertifikaten
17
Bit
Bezeichnung
Verwendungszweck des öffentlichen Schlüssels
3
dataEncipherment
Verschlüsselung von Daten. Gilt nicht für Verschlüsselung von
Sitzungsschlüsseln (Bit 2).
4
keyAgreement
Schlüsselaustausch (mit Diffie-Hellman o. Ä.)
5
keyCertSign
Verifizierung von Zertifikaten.
6
cRLSign
Verifizierung von Widerrufslisten (CRLs).
7
encipherOnly
Innerhalb eines Schlüsselaustausches zur Verschlüsselung von
Daten (benötigt keyAgreement, Bit 4).
8
decipherOnly
Innerhalb eines Schlüsselaustausches zur Entschlüsselung von
Daten (benötigt keyAgreement, Bit 4).
Tabelle 1 Bedeutung der key usage Bits in X.509v3 Zertifikaten

Erweiterter Verwendungszweck des Schlüssels (extended key usage)
Diese Erweiterung kann an Stelle oder auch ergänzend zu key usage verwendet
werden und dient dazu die Verwendung des Schlüssels noch feiner einzuschränken. Softwarehersteller können dazu eigene Werte für diese Erweiterung registrieren lassen, wie es beispielsweise Netscape und Microsoft getan haben.

Weitere Namen des Zertifizierten (subject alternative name)
X.509 ermöglicht bis einschließlich der Version 2 nur Namen, die dem X.500 Standard entsprechen. Um diesen Einschränkungen zu entgehen (X.509 wird meist
unabhängig von X.500 eingesetzt), können in dieses Feld zusätzliche Namen des
Zertifizierten in einem beliebigen Format gespeichert werden. Möglich sind hier z.
B. Email-Adressen, URLs, IP-Adressen oder Host-Namen.

Weitere Namen der Zertifizierungsstelle (issuer alternative name)
wie subject alternative name, ermöglicht dies der Zertifizierungsstelle Namen zu
verwenden, die nicht dem X.500 Standard entsprechen.

Eindeutige Kennung des Zertifizierungsstellen-Schlüssels (authority key identifier)
Verwendet eine Zertifizierungsstelle mehrere Schlüssel zum Signieren von Zertifikaten, kann hier genau angegeben werden, welcher Schlüssel für dieses Zertifikat
verwendet wurde. Dies ist der Fall, wenn die Schlüssel z. B. routinemäßig gewechselt werden.

Eindeutige Kennung des zertifizierten Schlüssels (subject key identifier)
Ebenso kann die zertifizierte Person mehrere Schlüssel besitzen. Welcher davon
mit dem Zertifikat signiert wurde, wird hier festgelegt.

CRL Verteilungspunkte (crl distribution points)
Adresse einer oder mehrerer Certificate Revocation Listen (CRLs) der Zertifizierungsstelle, welche dieses Zertifikat signiert hat. Solche Listen dienen der Entscheidung, welche Zertifikate vor Ablauf ihrer Gültigkeit widerrufen wurden und
18
welche weiterhin gültig sind. Abschnitt [3.4.2] beschäftigt sich eingehend mit dem
Thema Zertifikatswiderruf.
crl distribution points = URI:http://localhost/ca.crl
Mittlerweile machen viele Firmen Gebrauch von den Erweiterungsmöglichkeiten der Zertifikate nach X.509v3, einige davon werden im Folgenden an Hand zweier Beispiele vorgestellt.
3.3.1.3 Erweiterungen im Sinne der Signaturverordnung
Im Zusammenhang mit dem in Kapitel [3.9.2] besprochenen Signaturgesetz (SigG), sind die
gemeinsam vom Bundesamt für Sicherheit in der Informationstechnik (BSI) und der Gesellschaft für mathematische Datenverarbeitung (GMD) entwickelten Erweiterungen interessant.
Die folgenden Zertifikatsfelder umfassen hauptsächlich rechtliche Fragen [BSI98]:

Nutzungsbeschränkung
Die Einschränkung der Zertifikatsnutzung ist nicht mit der Standarderweiterung
key usage zu verwechseln. Vielmehr handelt es sich hier um eine Einschränkung,
die festlegt, dass Zertifikate beispielsweise nur zum Signieren von Quittungen und
Belegen, nicht aber von Verträgen vorgesehen sind. Welche Fälle das im Einzelnen
sind, wird in einem separaten Attribut-Zertifikat angegeben.

Erstellungsdatum
Der Zeitpunkt der Zertifikatsausstellung wird durch einen Zeitstempel festgehalten. Dies dient der Bestätigung, dass der Zertifizierungsstelle zu einem bestimmten
Zeitpunkt die erforderlichen Daten vorgelegen haben.

Vertretungsmacht
Evtl. ist die zertifizierte Person im Besitz einer Vollmacht und darf für andere Personen das digitale Signieren von Dokumenten übernehmen. Ein Beispiel hierfür ist
ein Rechtsanwalt, welcher die Vertretungsmacht für einen Klienten in einem
bestimmten Rechtsfall besitzt und diesen vor Gericht vertreten darf. Neben der zertifizierten Person darf auch die hier genannte dritte Person die Sperrung des Zertifikates veranlassen ([SigG97-2] §9).

Zulassung
Diese Erweiterung bescheinigt dem Zertifizierten die Zugehörigkeit zu einer
bestimmten Berufsgruppe wie Arzt, Notar, Rechtsanwalt, o. Ä.

Monetäre Bedingungen
Bis zu welchem Geldbetrag der Zertifizierte für von ihm signierte Dokumente haftet, wird in dieser Erweiterung festgehalten.
3.3.1.4 Erweiterungen von Netscape
Die Firma Netscape hat für ihre Softwareprodukte wie dem Netscape Communicator eigene
(proprietäre) Erweiterungen zum X.509v3 Standard definiert [NS99-1]. Diese dienen sowohl
zur Authentifikation von SSL-Verbindungen des Navigator Browsers als auch zum digitalen
Signieren oder Verschlüsseln von Nachrichten im Emailprogramm Messenger. Zu dem Zeitpunkt, als Netscape seine Erweiterungen entwarf, fehlten dem X.509 Standard einige wichtige
19
Erweiterungen, welche heute als Standarderweiterungen enthalten sind (siehe weiter oben).
Aus diesem Grund überschneidet sich die Bedeutung einiger Netscapeerweiterungen mit
denen bestimmter Standarderweiterungen.
Netscapeerweiterungen sollten niemals als critical markiert werden. Die Softwareprodukte
anderer Firmen verarbeiten diese Erweiterungen nicht und somit werden Zertifikate mit diesen
kritischen Netscapeerweiterungen von nicht-Netscape Software als ungültig abgewiesen. Ein
SSL-Serverzertifikat, in dem der netscape-cert-type als kritisch markiert ist, würde beispielsweise vom Microsoft Internet Explorer zurückgewiesen werden [DFN00-1].

Kommentar (netscape-comment)
Enthält den Verwendungszweck des Zertifikates in Form eines beliebigen Textes.
Dieser kann dem Benutzer beim Anzeigen des Zertifikats mit ausgegeben werden.

Basis URL (netscape-base-url)
Basis WWW-Adresse für Zugriffe auf Verzeichnisdaten der Zertifizierungsstelle.
Alle nachfolgenden Adressen können, wenn gewünscht, relativ zu dieser Basisadresse angegeben werden. Ist dies der Fall, wird vor einem Zugriff auf die jeweilige Adresse die Basisadresse hinzugefügt.
netscape-base-url = https://localhost/cert

Adresse für Widerrufszwecke (netscape-revocation-url)
WWW-Adresse zur Online-Gültigkeitsprüfung von Entity-Zertifikaten.

Adresse für CA-Widerrufszwecke (netscape-ca-revocation-url)
Wie netcape-revocation-url. Diese Erweiterung ist allerdings nur im Zusammenhang mit CA-Zertifikaten gültig.

Adresse für Zertifikatserneuerungsanträge (netscape-cert-renewal-url)
WWW-Adresse für die Verlängerung von abgelaufenen Zertifikaten. Unter dieser
Adresse sollte dem Benutzer ein Formular angeboten werden, mit dessen Hilfe er
sein Zertifikat verlängern kann.

Adresse der Policy (netscape-ca-policy-url)
WWW-Adresse zum Nachlesen der für das Zertifikat gültigen Zertifizierungsrichtlinien im HTML-Format.
netscape-ca-policy-url = /Hilfe/AGB/

Name des zertifizierten SSL-Servers (netscape-ssl-server-name)
Host-Name des SSL-Servers, für den das Zertifikat ausgestellt wurde; dient der
Authentizitätsüberprüfung während des Verbindungsaufbaus als zusätzliche
Sicherheit. Der hier angegebene Host-Name wird mit dem tatsächlich zurückgelieferten Host-Namen verglichen. Stimmen diese nicht miteinander überein,
bekommt der Benutzer die Möglichkeit, die Verbindung zu beenden.
netscape-ssl-server-name = www.dem-bob-sein-sslserver.de

Zertifikatstyp (netscape-cert-type)
Ermöglicht die Einschränkung möglicher Anwendungsfälle, für die ein Zertifikat
eingesetzt werden darf. Aufbau: 8-Bit Wert für den Typ des Zertifikates, je 1 Bit
20
zum Kombinieren der folgenden Zertifikatstypen:
Bit
Zertifikatstyp
Bemerkung
0
SSL Clientauthentifizierung
Entity-Zertifikat (SSL-Client)
1
SSL Serverauthentifizierung
Entity-Zertifikat (SSL-Server)
2
S/MIME für den Client-Einsatz
Entity-Zertifikat (S/MIME-Client)
3
Code Signing (z. B. Java Applets)
Entity-Zertifikat (Sourcecode, Programme, Plugins usw.)
4
reserviert für zukünftige Erweiterungen
5
SSL Zertifizierungsstelle
CA-Zertifikat zur Zertifizierung von
Entity-Zertifikaten (SSL Server oder Benutzer)
6
S/MIME Zertifizierungsstelle
CA-Zertifikat zur Zertifizierung von
Entity-Zertifikaten (S/MIME Benutzer)
7
Object Signing Zertifizierungsstelle
CA-Zertifikat zur Zertifizierung
Entity-Zertifikaten (Sourcecode, Programme, Plugins usw.)
Tabelle 2 Bedeutung der netscape-cert-type Bits in X.509v3 Zertifikaten
Sobald eines der Bits 5, 6 oder 7 gesetzt ist, interpretieren Softwareprodukte von
Netscape das Zertifikat als Zertifikat einer Zertifizierungsstelle (CA-Zertifikat),
andernfalls wird angenommen, es sei ein Entity-Zertifikat.
Dieser Abschnitt hat gezeigt, dass Zertifikate digitalen Identitätsnachweisen entsprechen und
damit die Grundlage für viele sicherheitsrelevante Konzepte auf Signatur- und Verschlüsselungsbasis bilden. Im weiteren Verlauf dieser Arbeit werden diese daher noch häufig zum Einsatz kommen.
3.4
Trustcenter
Die Frage, von welcher Einrichtung Zertifikate signiert werden sollen, wurde schon im vorangegangenem Abschnitt gestellt. Diese Aufgabe kann u. a. von einzelnen Personen erledigt werden, denen alle Kommunikationspartner vertrauen. Im kleinen Kreis, z. B. bei der direkten
Kommunikation zwischen Alice, Bob und ein paar weiteren Freunden mag das praktikabel
sein. Dieser Ansatz scheitert aber schon bei kleinen bis mittleren Unternehmensnetzwerken
mit mehreren Dutzend Mitarbeitern. Dort kennt (und vertraut) man sich für gewöhnlich allenfalls noch innerhalb der eigenen Abteilung - vertrauensvolle Bindeglieder zwischen den verschiedenen Abteilungen sind aber eher unwahrscheinlich.
3.4.1
Struktur eines Trustcenters
Die gängigere Lösung ist eine unabhängige Instanz zu schaffen, der alle vertrauen: ein Trust-
21
center. Das Trustcenter innerhalb einer Public Key Infrastruktur ist eine Einrichtung zur Zertifizierung von Personen, Diensten oder Servern, sowie zur Speicherung, Bereitstellung und
Überprüfung von kryptographischen Schlüsseln. Aus diesem Grund, sollte ein Trustcenter ausschließlich von einer vertrauenswürdigen Stelle (bzw. Organisation) betrieben werden. In der
Literatur wird ein Trustcenter häufig auch als Trusted Third Party (TTP), bzw. als vertrauenswürdige dritte Partei bezeichnet.
Wie ein Trustcenter aufgebaut sein sollte, damit es weitestgehend den Anforderungen des deutschen Signaturgesetzes (SigG) [SigG01-1] entspricht, zeigt Abbildung 6.
2
Zertifizierungseinheit
CA
RA
Registrierungseinheit
1
Bob
Zertifikat
Zertifikat
Personalisierungseinheit
Personalisierungseinheit PS
geheimer
geheimer Schlüssel
Schlüssel
Chipkarte
Schlüsselgenerator
Schlüsselgenerator
KG
DIR
Verzeichnisdienst
Verzeichnisdienst
Trust Center
weitere
weitere Zertifikate...
Zertifikate...
Bobs
Bobs Zertifikat
Zertifikat
Malory
Alice
Abbildung 6 mögliche Struktur eines SigG-konformen Trustcenters
Ein derartiges Trustcenter besteht aus mehreren Komponenten, die untereinander in Beziehung
stehen. Deren Funktionsweise und ihre Abhängigkeiten voneinander lassen sich wie folgt charakterisieren.
Eine Registrierungseinheit (Registration Authority, kurz: RA) innerhalb eines Trustcenters
nimmt die Anträge auf Zertifizierung an und gibt die notwendigen Daten an die Zertifizierungseinheit weiter. Um größtmögliche Sicherheit zu gewährleisten, muss die zu zertifizierende Person persönlich vorsprechen und sich entsprechend ausweisen, beispielsweise durch
Vorlage des Personalausweises. Eine Registrierungseinheit ist nicht notwendigerweise zwischen Zertifizierungseinheit und den Benutzern geschaltet, die Zertifizierungseinheit kann
(abhängig vom Sicherheitsmodell) Zertifizierungsanträge auch direkt von den Benutzern
annehmen, ohne Umweg über eine RA.
22
Die Zertifizierungseinheit (Certification Authority, kurz: CA) nimmt Zertifizierungsanträge
von der RA oder den Benutzern selbst an und erhält für jeden zu zertifizierenden Benutzer vom
Schlüsselgenerator ein digitales Schlüsselpaar. Daraus erstellt die CA ein Zertifikat und
signiert es anschließend. Das Zertifikat wird zusammen mit dem privaten Schlüssel an die Personalisierungseinheit weitergereicht und zusätzlich (ohne den privaten Schlüssel) dem Verzeichnisdienst übergeben.
Schlüsselgenerator
Der Schlüsselgenerator (Key Generation, kurz: KG) übernimmt die Generierung von asymmetrischen Schlüsselpaaren, bestehend aus öffentlichen und privaten Schlüsseln. Alternative Zertifizierungsrichtlinien überlassen es dem Benutzer, für die Generierung des eigenen
Schlüsselpaares zu sorgen. Letztgenannte Methode bietet dem Benutzer mehr Sicherheit, niemand außer ihm persönlich kommt jemals direkt mit seinem privaten Schlüssel in Berührung.
Diese Vorgehensweise entspricht dem eigentlichen Sicherheitsgedanken, der hinter asymmetrischen Schlüsselpaaren steht. Der private Schlüssel soll schließlich geheim bleiben. Sie hat
allerdings mehrere Nachteile. Zum einen benötigt ein Benutzer die Infrastruktur (und das
Know-how) zum Erstellen von Schlüsselpaaren, zum anderen muss er den privaten Schlüssel
spätestens dann herausgeben, sobald er auf eine Chipkarte integriert werden soll.
Personalisierungseinheit
Die Personalisierungseinheit (Personalization, kurz: PS) liefert das von der CA erhaltende
Zertifikat und den geheimen Schlüssel zusammen auf einem geeigneten Datenträger - z. B.
einer Chipkarte oder Diskette - an den Benutzer aus.
Verzeichnisdienst
Ein Verzeichnisdienst (Directory, kurz: DIR) hält die signierten Zertifikate öffentlich zum
Abruf für andere Benutzer bereit und gewährleistet so eine gewisse Sicherheit, was die Aktualität von Zertifikatsinformationen betrifft. Weiterhin werden vom Verzeichnisdienst sog.
Widerrufslisten bereitgestellt, mehr dazu im nächsten Abschnitt.
Grundsätzlich besteht die Möglichkeit, Zertifizierungseinheit, Schlüsselgenerator und Personalisierungseinheit zu einer Einheit zusammenzufassen, wie in der Abbildung dargestellt. Alle
drei Komponenten sollten isoliert von jeglichem Intranet- oder Internetzugang installiert werden. Die Schnittstelle einer CA zum Netzwerk bilden ausschließlich das Zertifikatsverzeichnis
und die Registrierungseinheit. Nur Dienste der Zone 2 nehmen Anfragen vom Netzwerk entgegen, für Dienste der Zone 1 besteht keinerlei Netzkontakt zur Außenwelt. Eine Ausnahme bildet die Personalisierungseinheit, deren Kontakt beschränkt sich aber auf die persönliche
Übergabe der Zertifikatsdaten - ein Netzwerkzugang ist auch hierfür nicht notwendig. Dienste
der Zone 1 werden üblicherweise als dedizierte Rechner in einer besonders gesicherten Umgebung (wie einem Tresorraum) realisiert. Wo hingegen für die der Zone 2 eine Installation in der
DMZ (entmilitarisierte Zone) eines Unternehmens ausreichend Sicherheit gewährleistet.
23
3.4.2
Zertifikatswiderruf
Ein Zertifikatswiderruf (Sperrung) wird notwendig, wenn der Verdacht besteht, dass private
Schlüssel kompromittiert wurden. Dies ist beispielsweise der Fall, wenn Bob seine Chipkarte
verliert, oder Mallory die Festplatte entwendet, auf der Bobs privater Schlüssel gespeichert ist.
Damit verliert das zugehörige Zertifikat seine Vertrauenswürdigkeit. Private Schlüssel sind auf
Chipkarten oder Festplatten zwar üblicherweise durch PINs oder Passwörter vor unbefugten
Zugriffen geschützt. Setzt man allerdings ausreichend kriminelle Energie voraus, stellt auch
dies kein allzu großes Hindernis für potenzielle Angreifer dar. Bei einem entsprechenden Verdacht muss Bob unverzüglich bei seinem Trustcenter den Widerruf des Zertifikates veranlassen.
Ein äußerst kritisches Thema ist die Kompromittierung von CA-Schlüsseln. Zusammen mit
dem CA-Zertifikat verlieren auch alle von dieser CA ausgestellten Zertifikate ihre Vertrauenswürdigkeit.
Neben der Kompromittierung existieren weitere Gründe für den Widerruf von Zertifikaten. Als
Beispiel sei ein Mitarbeiter genannt, dem ein Zertifikat ausgestellt wurde, das die Zugehörigkeit zu seiner Firma bescheinigt. Auf Basis dieser Bescheinigung wird Zugang zu firmeninternen Informationen ermöglicht. Verlässt dieser nun seinen Arbeitgeber, so verliert die
eigentliche Zertifikataussage ihre Gültigkeit und das Zertifikat muss vom Trustcenter widerrufen werden.
Es gibt verschiedene Methoden, potenziellen Kommunikationspartnern mitzuteilen, welche
Zertifikate widerrufen sind:

Online-Abruf
Der Online-Abruf erfordert vor jeder einzelnen Verwendung eines Zertifikates den
Online-Zugriff zum Trustcenter. Dabei wird nachgefragt, ob das zu verwendende
Zertifikat noch Gültigkeit besitzt. Man erkennt, dass dies eine zuverlässige
Methode ist, denn es werden immer die aktuellsten Sperrinformationen vom Trustcenter verwendet. Die Nachteile sind der durch ständige Anfragen anfallende
Overhead beim Trustcenter sowie die nötige Online-Verbindung bei jeder einzelnen Transaktion.

Certificate Revocation List
Bei einer Certificate Revocation List (CRL) handelt es sich um eine Art schwarze
Liste (Blacklist): Das Trustcenter veröffentlicht in regelmäßigen Abständen eine
Liste mit den Seriennummern aller gesperrten Zertifikate. Damit reduziert sich der
notwendige Overhead z. T. erheblich, denn Übertragungen der jeweils aktuellsten
CRL werden nur in vorhersehbaren Zeitabständen erforderlich. Ein Nachteil dieser
Methode soll aber nicht verschwiegen werden. Zertifikate, die kurz nach Herausgabe einer solchen Liste gesperrt werden, sind erst mit der nächsten Aktualisierung
der Liste auch tatsächlich als gesperrt zu erkennen. Bei Veröffentlichungen im
Wochenrhythmus wären das bis zu sieben Tage - Zeit genug für Malory um mit
Bobs gestohlener Chipkarte eine Menge Unfug zu treiben.
Bei einer CRL handelt es sich somit um eine Form von Offline-Abruf, bei der nur
in regelmäßigen, fest definierten Abständen eine Online-Verbindung zum Trust-
24
center nötig wird. Mit kleinerem Zeitspannen beim Veröffentlichen bzw. Abrufen
der Liste nähert sich das Verfahren allerdings immer mehr dem Online-Abruf an.
Letztlich muss man einen Kompromiss zwischen Aktualität und Overhead eingehen.

3.5
Weiße Liste
Die weiße Liste ist das Gegenstück zu einer CRL, auf dieser werden nicht gesperrte
Zertifikate veröffentlicht. Weiße Listen werden allerdings nur selten verwendet, da
die Zahl der gültigen, nicht gesperrten Zertifikate meist wesentlich größer ist, als
die der Widerrufenen. Somit wird eine auf diesem Verfahren basierende Liste
erheblich umfangreicher als eine CRL.
Vertrauensmodelle
Zur Echtheitsbestätigung von Zertifikaten und um zu verhindern, dass Zertifikatinhalte nachträglich verändert werden können, werden Zertifikate digital signiert. Diese Signatur wird
anschließend dem Zertifikat beigefügt. Schon Kapitel [3.4] beschäftigt sich u. a. mit der Frage,
wer ausgestellte digitale Zertifikate signieren soll. An dieser Stelle wird daher näher auf die
verschiedenen verwendeten Varianten - auch Vertrauensmodelle genannt - eingegangen.
3.5.1
Direct Trust
Das einfachste Vertrauensmodell ist Direct Trust. Jeder Anwender muss dabei sein eigenes
Zertifikat selbst signieren. Allerdings hat ein vom Anwender selbst signiertes Zertifikat ungefähr die Glaubwürdigkeit eines selbst ausgestellten Personalausweises. Aus diesem Grund
wird bei Direct Trust häufig auf den Einsatz von Zertifikaten ganz verzichtet. Dieses Vorgehen
hat entscheidende Nachteile. Denn wie kann sich Alice sicher sein, wirklich Bobs öffentlichen
Schlüssel zu verwenden und nicht etwa den von Malory? Das hat zur Konsequenz, dass Alice um sicherzugehen - sich den Schlüssel persönlich von Bob besorgen müsste. Was im kleinen
Rahmen zwischen ein paar Freunden noch praktikabel klingt, wird bei umfangreichen Teilnehmergruppen immer unüberschaubarer, wenn nicht gar unmöglich wird. Der Grund dafür ist,
dass Alice und Bob ihre öffentlichen Schlüssel mit jedem Kommunikationspartner austauschen und diese anschließend auch noch selbst verwalten müssen.
Direct Trust ist somit das Modell, dem das geringste Vertrauen entgegengebracht wird. Die
Teilnehmer vertrauen ausschließlich Schlüsseln, die sie persönlich erhalten haben. Vorteilhaft
ist allerdings, dass Direct Trust so gut wie keinerlei Infrastruktur benötigt. Die größte Schwäche Direct Trusts ist, dass unter solchen Voraussetzungen nur sehr schwer einheitliche Sicherheitsrichtlinien durchsetzbar sind. Es ist beinahe unmöglich festzustellen, wer wem zu einem
bestimmten Zeitpunkt vertraut hat. Problematisch ist auch das Sperren von kompromittierten
Schlüsseln, denn wie soll man alle Teilnehmer von einmal im Umlauf befindlichen, ungültig
gewordenen öffentlichen Schlüsseln benachrichtigen? Negativ einzuordnen ist auch die fehlende rechtliche Sicherheit. Wenn jeder Teilnehmer nach Belieben neue Schlüsselpaare erzeugen kann, lässt sich praktisch nicht nachweisen, ob eine digitale Signatur und der dazugehörige
öffentliche Schlüssel vom Teilnehmer stammen.
Vor diesem Hintergrund eignet sich Direct Trust nahezu überhaupt nicht für den Einsatz in
Umgebungen, die auf eine exakte Durchsetzung von Sicherheitsrichtlinien, sowie Rechtssicherheit bei digitalen Signaturen angewiesen sind.
25
3.5.2
Web Of Trust
Das Vertrauensmodell Web Of Trust hebt einige der vorher genannten Einschränkungen auf,
indem digitale Zertifikate nicht mehr vom Besitzer des Schlüssels selbst signiert werden. Stattdessen darf jeder Teilnehmer die Zertifikate von Schlüsseln anderer Teilnehmer signieren. D.
h. Alice signiert das Zertifikat von Bob und Bob das von Alice. Anschließend vertraut Alice
nicht nur Bobs Schlüssel, sondern auch allen öffentlichen Schlüsseln anderer Anwender, die
Bob in einem Zertifikat signiert hat. Jeder Zertifikatsinhaber kann also selbst Zertifizierungsinstanz „spielen“. Dabei entsteht wie in Abbildung 7a eine ganze Kette von vertrauten Zertifikaten.
In der Abbildung sind Teilnehmer als dunkle Kreise dargestellt, wobei die Kürzel A, B, M
sowie Z für die allseits bekannten Teilnehmer Alice, Bob, Malory und Zacharias stehen. Unbenannte Kreise stellen beliebige weitere Teilnehmer dieses Vertrauensmodells dar. Pfeile zwischen Teilnehmern symbolisieren ausgestellte Zertifikate, wobei am Pfeilursprung der
Aussteller und am Pfeilende der Empfänger (Zertifizierte) steht.
CA
CA
M
!
B
A
Z
Legende:
CA
a) Web of Trust
b) flache Zertifizierungshierarchie
Teilnehmer
Teilnehmer vertraut Teilnehmer
CA zertifiziert Teilnehmer
Wurzel-CA
Wurzel-CA
CA
CA
CA
CA
RegTP
RegTP
CA
CA
CA
CA
c) strikt hierarchisches Modell
CA
CA
CA
CA
Deutsche
Deutsche
Post
Post AG
AG
Deutsche
Deutsche
Telekom
Telekom AG
AG
weitere
weitere CAs...
CAs...
d) zweistufige Hierarchie nach deutschem Signaturgesetz
Abbildung 7 Vertrauensmodelle
Wenn man Abbildung 7a genauer betrachtet, sieht man, dass Alice Bob vertraut. Bob wiederum vertraut weiteren Personen. Eine dieser Personen vertraut allerdings auch Malory. Die
Vertrauensbeziehung zwischen der nicht näher bezeichneten Person und Malory stellt zugleich
26
die Schwachstelle dieses Modells dar und ist deshalb in der Abbildung mit einem Ausrufezeichen als besonders brisant gekennzeichnet. Denn wenn Bob einer Person vertraut, die wiederum Malory vertraut, dann heißt das nichts anderes, als dass Bob von nun an auch dem
Schurken Malory vertraut (und damit auch allen anderen Personen, denen Malory vertraut).
Problematisch stellt sich auch die Kommunikation zwischen unbekannten Personen dar. Wenn
Alice an Zacharias eine verschlüsselte Email schicken möchte, diesen jedoch selbst nicht
kennt, ist sie darauf angewiesen, dass sein Zertifikat durch eine Kette von Signaturen auf
jemanden zurückzuführen ist, dem sie vertraut.
Ebenso wie beim bereits vorgestellten Vertrauensmodell Direct Trust ist es auch beim Web Of
Trust sehr schwierig eine durchgehend einheitliche Sicherheitspolitik durchzusetzen. Denn
wer kann schon genau bestimmen, unter welchen Voraussetzungen ein Benutzer für einen
anderen ein digitales Zertifikat ausstellt. Nicht anders sieht es bei der Sperrung von Zertifikaten aus. Bob muss jedem Teilnehmer bekannt geben, dass dieser sein Zertifikat nicht mehr verwenden soll, was organisatorisch bei einer größeren Teilnehmergruppe nahezu unmöglich ist.
Auf rechtlicher Seite bestehen die gleichen Probleme wie beim Vertrauensmodell Direct Trust.
Für die Verwendung im kommerziellen Umfeld ist dieses Modell daher nur bedingt geeignet.
3.5.3
Hierarchical Trust
Das leistungsfähigste Vertrauensmodell ist Hierarchical Trust, auch hierarchisches Modell
genannt. Im Unterschied zu den beiden zuvor Genannten, zertifizieren Teilnehmer dieses Vertrauensmodells weder sich selbst noch andere Teilnehmer. Zertifikate werden ausschließlich
von vertrauenswürdigen Instanzen (Trusted Third Parties) ausgestellt und signiert. Diese sind
Teil eines Trustcenters und werden i.A. als Zertifizierungsinstanz bezeichnet.
Das hierarchische Vertrauensmodell existiert in unterschiedlichen Ausprägungen bezüglich der
Hierarchietiefe.

Flache Zertifizierungshierarchie
Die einfachste Form ist die flache (einstufige) Zertifizierungshierarchie, wie sie in
Abbildung 7b dargestellt ist. Sie besteht aus vielen Teilnehmern, aber nur einer
einzigen CA.

Strikt hierarchisches Modell
Diese Form der Zertifizierungshierarchie (Abbildung 7c) enthält mehrere, hierarchisch angeordnete CAs, wobei jeder Benutzer üblicherweise nur bei einer registriert ist. CA-Zertifikate einer untergeordneten CA sind von einer übergeordneten
CA signiert. Am oberen Ende der Hierarchie steht die Wurzel-CA, deren Zertifikat
von ihr selbst signiert ist. Jedes Zertifikat dieser Hierarchie kann auf das Zertifikat
der Wurzel-CA zurückgeführt werden, in dem der Zertifizierungspfad entlang des
Baumes zurückverfolgt wird.
Ein Vorgang namens Crosszertifizierung ermöglicht es, voneinander unabhängige Zertifizierungshierarchien miteinander zu verbinden. Verwendung findet dies beispielsweise bei der
Fusion zweier Unternehmen, die jeweils über eigene Zertifizierungsstellen verfügen und diese
nun vereinen möchten. Dazu ist es nötig, dass sich die Wurzel-CAs beider Unternehmen
gegenseitig ein digitales Zertifikat ausstellen, um die Teilnehmer beider Hierarchien in das
jeweilige Vertrauensmodell mit einzuschließen.
27
Eine CA stellt das vertrauensvolle Bindeglied zwischen Teilnehmern einer Hierarchieebene
dar. Teilnehmer, welche von ein und derselben CA zertifiziert sind vertrauen sich gegenseitig vorausgesetzt natürlich, sie sehen die signierende CA als vertrauenswürdig an.
Vorteil dieses Modells gegenüber den beiden Vorherigen ist die vergleichsweise einfach durchzusetzende Sicherheitspolitik. Ein Trustcenter kann genau festlegen, welche Teilnehmer zertifiziert werden und unter welchen Umständen sowie zu welchem Zweck diese ein Zertifikat
ausgestellt bekommen.
Eine besondere Stellung nimmt die Zertifizierungshierarchie aus Abbildung 7d ein. Es stellt
die zweistufige Hierarchie nach deutschem Signaturgesetz (SigG) dar. Hier gibt es neben der
Wurzelinstanz, welche von der Regulierungsbehörde für Telekommunikation und Post
(RegTP) betrieben wird, nur noch eine Ebene darunter mit beliebig vielen, weiteren CAs.
Momentan gehören dazu u. a. die Trustcenter der Deutschen Telekom AG und der Deutschen
Post AG. Dieses Modell beseitigt den letzten Kritikpunkt der Vorangegangenen: die fehlende
Rechtssicherheit digitaler Signaturen. Mehr dazu in Abschnitt [3.9.2].
3.6
Schlüsselwiederherstellung
Verschlüsselung wichtiger Daten birgt immer ein enormes Risiko in sich. Wenn der zur Entschlüsselung notwendige Schlüssel verloren geht, sind die verschlüsselten Daten somit unwiederbringlich verloren. Vermeiden lässt sich der endgültige Verlust digitaler Schlüssel durch die
rechzeitige Hinterlegung eines Zweitschlüssels bei einer vertrauenswürdigen Instanz.
Gründe für den Einsatz einer sicheren Schlüsselhinterlegung, um bei berechtigtem Interesse
verschlüsselte Daten ohne den Original-Schlüssel zu entschlüsseln, sind vielfältig [AdaLlo99]:

Vergessenes Passwort
Einer der am häufigsten auftretenden Fälle, sind Benutzer, die Passwort/PIN zur
Freischaltung ihres privaten Schlüssels vergessen haben - wodurch dieser wertlos
wird.

Tod des Schlüsselbesitzers
Wie oben, der Entschlüsselungsschlüssel ist zwar weiterhin vorhanden, aber das
Passwort bzw. die PIN zur Freischaltung des Schlüssels sind anderen Personen
nicht bekannt.

Sabotage
Ein Mitarbeiter verlässt (beispielsweise auf Grund einer Kündigung) seine Firma
und vernichtet aus Rache seinen privaten Schlüssel - und damit vielleicht das
Ergebnis monatelanger Arbeit.

Verlust des Schlüssels
Der Verlust des privaten Schlüssels kann schon auf Grund eines fehlenden Backups nach einem Plattencrash eintreten; oder, falls Chipkarten verwendet werden,
ganz simpel durch deren Diebstahl oder Beschädigung.

Rechtsstaatliche Überwachung
Zur unbemerkten Überwachung von potenziellen Straftätern benötigen Ermitt-
28
lungsbehörden eine Kopie des bei der Verschlüsselung verwendeten Schlüssels.
Dieser müsste vom Opfer freiwillig bei der Ermittlungsbehörde hinterlegt werden.
3.6.1
Escrowed Encryption Standard
Die Hinterlegung eines Zweitschlüssels bei einer dafür vorgesehenen Instanz müsste auf freiwilliger Basis geschehen. Allerdings funktionieren auf freiwilliger Basis arbeitende Verfahren
nur dann, wenn alle Parteien sich daran beteiligen. Verstöße gegen Schlüsselwiederherstellungsprotokolle bleiben aber mit Sicherheit auch dann nicht aus, wenn sie mit hohen Strafen
belegt werden. Es sei denn, man sorgt durch ein geeignetes Verfahren dafür, dass ein solcher
Verstoß nicht möglich wird. Ein Beispiel für ein unter staatlicher Kontrolle stehendes Schlüsselwiederherstellungsverfahren, ist der von der NSA entwickelte und zeitweise von der USRegierung eingesetzte Escrowed Encryption Standard (EES) aus dem Jahr 1994.
Beim EES-Verfahren werden private Schlüssel bei zwei staatlichen Stellen (sog. Key-escrow
Agenturen) je zur Hälfte hinterlegt, um eine (vom Opfer unbemerkte) Überwachung des Nachrichtenverkehrs zu ermöglichen. Dabei wurde Wert darauf gelegt, dass nur in begründeten Fällen eine Schlüsselwiederherstellung von überwachender Seite (Ermittlungsbehörden,
Geheimdienst) möglich ist. Mithilfe einer richterlichen Genehmigung können die Strafverfolgungsbehörden den zur Entschlüsselung notwendigen, in zwei Teilschlüssel zerlegten Chipschlüssel wieder zusammensetzen.
Maximale Sicherheit sollte dabei eine Hardwarelösung bieten (Clipper-Chip oder Capstone).
EES konnte sich allerdings nicht durchsetzen, da im Laufe der Zeit eine Möglichkeit gefunden
wurde, die für das Verfahren wichtige Prüfsumme zu fälschen. Dennoch wurden die Einzelheiten des Hardwareverfahrens lange Zeit von der NSA weit gehend geheim gehalten. Mittlerweile wurde der verwendete Algorithmus als „unclassified“ erklärt und kann nun ungehindert
analysiert werden [JoPflue01].
Aber selbst, wenn man nicht eine Hintertür in Form der Prüfsumme gefunden hätte, wer hätte
Alice und Bob daran gehindert, einfach auf EES zu verzichten und stattdessen eine andere Verschlüsselungstechnologie zu verwenden?
3.7
Kryptographische Verfahren auf Public Key Basis
Dem TCP/IP Protokoll fehlt die Möglichkeit sichere2 Verbindungen aufzubauen. Nachfolgend
werden daher erst einmal einige kryptographische Verfahren vorgestellt, die von vorhandener
Software dazu verwendet werden, sichere Verbindungen aufzubauen. Für eine Beschreibung
des TCP/IP Protokolls wird auf [AnSTanen96] verwiesen.
Alle in diesem Abschnitt besprochenen kryptographischen Verfahren nutzen die Vorteile von
Zertifikaten, um Dienste wie Authentizität, Vertraulichkeit und Integrität auf TCP/IP-Ebene zu
implementieren. Im Einzelnen sind dies SSL, S/MIME sowie IPSec.
2. D. h. unter Wahrung von Authentizität, Vertraulichkeit und Integrität.
29
3.7.1
SSL
Secure Socket Layer (SSL) ist eine transparente Protokollschicht, die von der Firma Netscape
entwickelt wurde, um Dienste wie Vertraulichkeit und Integrität (mittels Verschlüsselung),
sowie Authentifizierung (durch Zertifikate) unterhalb der Anwendungsschicht des TCP/IPProtokollstacks anzubieten. Angesiedelt zwischen dem Transportprotokoll TCP und den darüber liegenden Anwendungsprotokollen (siehe Abbildung 8) kann SSL zur kryptographischen
Absicherung von Internet-Dienst-Protokollen wie HTTP, Telnet, FTP, POP3 oder LDAP eingesetzt werden. D. h. es ermöglicht eine abhörsichere Kommunikation und den Transport sicherheitsrelevanter Daten über das World Wide Web.
Host
Host
HTTP,
HTTP, Telnet,
Telnet,
FTP,
FTP, POP3,
POP3, ...
...
HTTP,
HTTP, Telnet,
Telnet,
FTP,
FTP, POP3,
POP3, ...
...
SSL
SSL
TCP
TCP
IP
IP
LAN,
LAN, PPP,
PPP, ...
...
SSL
SSL
TCP
TCP
Router
IP
IP
IP
IP
LAN,
LAN, PPP,
PPP, ...
...
LAN,
LAN, PPP,
PPP, ...
...
Abbildung 8 SSL setzt zwischen TCP und einem Anwendungsprotokoll an
Der allgemeine Ablauf bei Verbindung eines Clients mit einer per SSL gesicherten Webseite
ist folgender: Der Webserver sendet im ersten Schritt sein digitales Zertifikat. Sofern dieses
von einer CA ausgestellt und signiert wurde und deren digitales Zertifikat schon im Browser
des Clients gespeichert ist, erkennt dieser es als gültig an. Die Standardbrowser der Firmen
Microsoft und Netscape bringen schon von Hause aus einige Zertifikate von bekannten, großen CAs mit. Für den Fall, dass das Zertifikat der zertifizierenden CA dieser Webseite nicht
enthalten ist, bleibt dem Benutzer die Entscheidung überlassen, dem Webserverzertifikat zu
vertrauen. Dabei besteht natürlich die Gefahr, dass Benutzer jederzeit auch ungültige Zertifikate annehmen können und diesen dann in Zukunft fälschlicherweise Vertrauen schenken. Die
Sicherheit hängt in solchen Fällen alleine von den Benutzern selbst ab. Unternehmen, welche
aus wirtschaftlichen Interessen oder aus Gründen des Vertrauens eigene CAs betreiben, anstatt
ihre Server von einer der großen, bekannten CAs zertifizieren zu lassen, sind deshalb darauf
angewiesen, dass alle Clientrechner vor der ersten Verbindungsaufnahme mit dem Server, das
Zertifikat ihrer eigenen CA in die Liste vertrauenswürdiger CAs importieren.
Intern ist die SSL-Protokollschicht in fünf weitere Protokolle unterteilt:

Handshake-Protokoll
Das Handshake-Protokoll authentifiziert den Server und (optional auch) den Client
mittels X.509v3-Zertifikaten. Es handelt das anzuwendende Kryptoverfahren zwischen Client und Server aus und tauscht anschließend einen symmetrischen
30
Schlüssel (Sitzungsschlüssel) zwischen beiden aus.

Change-CipherSpec-Protokoll
Das Change-CipherSpec-Protokoll ermöglicht die vereinbarten Kryptoverfahren
während der Übertragung zu wechseln.

Alert-Protokoll
Das Alert-Protokoll versendet Fehler- und Warnmeldungen, für den Fall, dass ein
Datenaustausch außerplanmäßig verläuft.

ApplicationData-Protokoll
Das ApplicationData-Protokoll reicht die Daten der Anwendungsschicht an das
SSL-Record-Protokoll weiter.

SSL-Record-Protokoll
Das SSL-Record-Protokoll wendet auf die übergebenen Daten ein Hashverfahren
an und verschlüsselt (wenn gewünscht) diese anschließend symmetrisch zusammen mit dem Hashwert.
SSL ist nicht auf die Verwendung bestimmter kryptographischer Algorithmen festgelegt. Stattdessen haben Server und Client die Möglichkeit, sich beim Verbindungsaufbau mithilfe des
Handshake-Protokolls auf die zu verwendenden Verfahren zu einigen. Folgende Algorithmen
stehen dabei laut [NS98-1] zur Verfügung:
Verfahren
Algorithmus
Schlüsselaustausch
RSA und KEA
Verschlüsselung (symmetrisch)
RC2, RC4, DES, Triple-DES und SKIPJACK
Hashfunktion
SHA-1 und MD5
Signaturen
RSA und DSA
Tabelle 3 SSLv3: unterstützte kryptographische Algorithmen
Dem Server steht dabei die Möglichkeit offen, die für den Einsatz infrage kommenden Algorithmen einzuschränken. Dies ermöglicht u. a. die Festlegung einer Mindestschlüssellänge, die
ein verbindungswilliger Client vorweisen muss, damit eine SSL-Verbindung zu Stande kommt.
Bestenfalls einigen sich Server und Client darauf hin auf den kryptographisch stärksten Algorithmus, den beide gemeinsam unterstützen. Anderenfalls kann es aber auch vorkommen, dass
gar keine Einigung zu Stande kommt - und damit auch keine Verbindung. Dies ist beispielsweise der Fall, wenn der Client eine (veraltete) Software einsetzt, deren kryptographischen
Algorithmen noch durch die ehemaligen US-Exportbeschränkungen auf Schlüssellängen von
maximal 40-bit beschränkt sind, der Server aber eine höhere Sicherheit fordert (wie beispielsweise 128-bit). Der US-amerikanischen Exportpolitik bezüglich starker Kryptographie widmet
sich Kapitel [3.9.3].
Die Authentizität von Server und Client wird mithilfe der schon besprochenen X.509v3 Zerti-
31
fikate gewährleistet. Dabei kann sich sowohl der Server als auch der Client per Zertifikat
authentifizieren. In Abhängigkeit der Serverkonfiguration ist es ebenso möglich, dass sowohl
Client, als auch Server auf den Einsatz von Zertifikaten verzichten und öffentliche Schlüssel
verwenden, die nicht signiert sind. Weiterhin kann auf den Einsatz von Verschlüsselung ganz
verzichtet werden, für den Fall, dass die Gesetzgebung eines Staates den Einsatz von Verschlüsselung in öffentlichen Netzen nicht erlaubt. Frankreich z. B. beschränkt auch heute noch
den legalen Gebrauch von Verschlüsselungsverfahren ([BJKoops01] und [JoPflue01]).
3.7.1.1 Server Authentifizierung
Wie im Abschnitt [3.7.1] beschrieben, authentifiziert sich der Server gegenüber dem Client, in
dem er sein digitales Zertifikat sendet, welches vom Client dazu verwendet wird, die Identität
des Servers zu überprüfen.
Der Client erkennt die Zugehörigkeit des Zertifikates zum Server und damit die Identität desselben an, wenn sämtliche der in Abbildung 9 geforderten Bedingungen erfüllt werden.
M
Liegt das heutige Datum innerhalb des Gültigkeitszeitraumes?
Der Client vergleicht den Gültigkeitszeitraum des Server-Zertifikates mit dem heutigen Datum. Außerhalb dieses Zeitraumes ist das Zertifikat ungültig, d. h. der Zertifikatsaussage darf nicht vertraut werden.
N
Gehört die CA des Servers zu den vertrauenswürdigen CAs?
Jeder SSL-Client führt eine Liste mit Zertifikaten der für ihn vertrauenswürdigen
CAs. Der Inhalt dieser Liste entscheidet darüber, welche Serverzertifikate vom
Client akzeptiert werden und welche nicht. Dazu muss der Distinguished Name
(DN) auf dem Serverzertifikat dem DN einer CA dieser Liste entsprechen. Notfalls
wird versucht, eine übergeordnete CA zu finden, auf die dies zutrifft.
O
Erlaubt der öffentliche Schlüssel der CA die Überprüfung der CA Signatur?
Der Client überprüft an Hand des öffentlichen CA-Schlüssels, welcher im CA-Zertifikat (aus o. g. Liste) enthalten ist, ob die CA-Signatur im Serverzertifikat gültig
ist. Ist diese ungültig, weil beispielsweise das Zertifikat nachträglich verändert
wurde, oder passt der öffentliche CA-Schlüssel nicht zum Signieren verwendeten
privaten CA-Schlüssel, wird der Server nicht authentifiziert.
P
Stimmt der auf dem Zertifikat angegebene Domainname mit dem tatsächlichen Domainnamen überein?
Dieser Schritt überprüft, ob der Server auch tatsächlich die im Zertifikat angegebene Netzwerkadresse besitzt. Wenn der Domainname (bzw. die IP-Adresse) nicht
übereinstimmt, muss der Client die Verbindung zum Server ablehnen. Die Praxis
sieht allerdings ein wenig anders aus, die meisten Webbrowser informieren den
Anwender über diesen Missstand und überlassen ihm die Wahl, ob die Verbindung
wirklich abgebrochen werden soll.
Der Authentifizierungsprozess gilt als abgeschlossen und damit der Server als korrekt authentifiziert, wenn alle genannten Bedingungen erfüllt sind. Fordert der Server zusätzlich eine
Authentifikation des Clients, folgt anschließend die im nächsten Abschnitt beschriebene Prozedur zur Client-Authentifizierung.
32
Zertifikat des Servers
DN des Servers:
cn=IntranetDemo,o=diba,c=de
N
Zertifikat der ausstellenden CA
Öffentlicher Schlüssel des Servers:
59A6 105D 17E1 CC72 9C35
1A46 26DB 1C5F AA7E ...
01.01.2001-31.12.2003
Signatur der CA:
DEE4 D9E0 E521 118D 1A46 DCBA
26DB 1C5F AA7E B0C6 ...
Zertifikat einer beliebigen weiteren CA
...
DN der ausstellenden CA:
cn=PrototypeCA,o=diba,c=de
P
M
O
DN der CA:
Öffentlicher Schlüssel der CA:
8B8A D0B7 47C5 B0D1 1F0C
15B8 0E96 6A56 6142 ...
Signatur der CA:
26DB 1C5F AA7E B0C6 ...
...
Liste vertrauenswürdiger CAs des Clients
Abbildung 9 SSLv3-Server: Authentifizierungsvorgang im Überblick
Abschließend generiert der Client einen zufälligen Datenblock, verschlüsselt ihn mit dem privaten Schlüssel des Servers und sendet ihn an diesen. Ist der Server in der Lage, die Daten zu
entschlüsseln, beiweist dies, dass er auch im Besitz des zum Zertifikat gehörenden privaten
Schlüssels ist. Anderenfalls wird die Verbindung beendet.
3.7.1.2 Client Authentifizierung
Es wurde bereits angesprochen, dass ein SSL-Server so konfiguriert werden kann, dass sich
auch ein Client gegenüber dem Server authentifizieren muss. Das Wissen über die Identität des
Clients ermöglicht auf Serverseite eine Rechteverwaltung der Art, dass nur autorisierten Clients der Zugang zu bestimmten Ressourcen (mit möglicherweise unterschiedlichen Zugriffsrechten) gewährt wird, wohingegen nicht-autorisierten Clients der Zugang verwährt bleibt.
Der Client sendet vor Beginn des Authentifizierungsprozesses neben seinem Zertifikat noch
einen zufällig generierten Datenblock, digital signiert an den Server. Der Server nutzt die digital signierten Daten, um den im Zertifikat enthaltenen öffentlichen Schlüssel des Clients zu
überprüfen. Dies gibt ihm die Sicherheit, dass der Client auch im Besitz des privaten Schlüssels ist, welcher zum Zertifikat gehört.
33
Zertifikat des Clients
DN des Clients:
cn=Bob Offliner,o=diba,c=de
O
Zertifikat der ausstellenden CA
Öffentlicher Schlüssel des Clients:
59A6 105D 17E1 CC72 9C35
1A46 26DB 1C5F AA7E ...
01.01.2001-31.12.2003
Signatur der CA:
26DB 1C5F AA7E B0C6 ...
N
P
DN der CA:
Öffentlicher Schlüssel der CA:
8B8A D0B7 47C5 B0D1 1F0C
15B8 0E96 6A56 6142 ...
Signatur der CA:
26DB 1C5F AA7E B0C6 ...
...
Zufällige Daten des Clients
Datenblock:
0100 1011 1000 1010 1001 0101
Signatur des Clients:
B0C6 598E 8B8A D0B7 26DB 1C5F
AA7E B0C6 1010 03DE 9AD0 ...
...
DN der ausstellenden CA:
M
Liste vertrauenswürdiger CAs des Servers
Abbildung 10 SSLv3-Client: Authentifizierungsvorgang im Überblick
Ähnlich wie bei der Server-Authentifizierung muss nun der Server eine positive Antwort auf
die folgenden fünf Fragen des Client-Authentifizierungsprozesses erhalten, um einer Bindung
des öffentlichen Schlüssels an die Identität des Clients zu vertrauen.
M
Erlaubt der öffentliche Schlüssel des Clients die Überprüfung der Client
Signatur?
Der Server überprüft an Hand des öffentlichen Schlüssels, welcher im Client-Zertifikat enthalten ist, ob die Signatur des vorher gesendeten Geheimnisses validiert
werden kann. Gelingt dies nicht, wird die Verbindung abgebrochen.
N
Liegt das heutige Datum innerhalb des Gültigkeitszeitraumes?
Der Server vergleicht den Gültigkeitszeitraum des Zertifikates mit dem heutigen
Datum. Außerhalb dieses Zeitraumes ist das Zertifikat ungültig, d. h. der Zertifikatsaussage darf nicht vertraut werden.
O
Gehört die CA des Clients zu den vertrauenswürdigen CAs?
Jeder SSL-Server führt eine Liste mit Zertifikaten der für ihn vertrauenswürdigen
CAs. Der Inhalt dieser Liste entscheidet darüber, welche Zertifikate vom Server
akzeptiert werden und welche nicht. Dazu muss der Distinguished Name (DN) auf
dem Zertifikat dem DN einer CA dieser Liste entsprechen. Notfalls wird versucht,
eine übergeordnete CA zu finden, auf die dies zutrifft.
34
P
Erlaubt der öffentliche Schlüssel der CA die Überprüfung der CA Signatur?
Der Server überprüft an Hand des öffentlichen CA-Schlüssels, welcher im CAZertifikat (aus o. g. Liste) enthalten ist, ob die CA-Signatur im Client-Zertifikat
gültig ist. Ist diese ungültig, weil beispielsweise das Zertifikat nachträglich verändert wurde, oder passt der öffentliche CA-Schlüssel nicht zum Signieren verwendeten privaten CA-Schlüssel, wird der Client nicht authentifiziert.
Q
Ist der authentifizierte Client autorisiert auf die angeforderte Ressource zuzugreifen?
Der Server überprüft die Berechtigung an Hand sog. Zugangskontrolllisten
(Access Controll Listen, kurz: ACL) und liefert die Ressource dann mit individuellen Zugriffsrechten an den Client aus. Verschiedene Zugriffsstufen können hierzu
auf dem Server eingerichtet werden. Dazu gehören neben dem Vollzugriff ein eingeschränkter (nur lesen) Zugriff sowie die Möglichkeit dem Client den Zugriff auf
die angeforderte Ressource komplett zu verweigern (kein Zugriff).
Dies ermöglicht es beispielsweise einem Finanzinstitut, das Zertifikate sowohl an
Kunden als auch an Mitarbeiter ausgegeben hat, die Berechtigungen derart zu kontrollieren, dass Kunden ausschließlich Zugriff auf ihre eigenen Kontendaten erhalten. Mitarbeiter hingegen autorisiert sind, vertrauliche Konditionen vom
Webserver abzurufen. Die Authentifikation auf Zertifikatsbasis ersetzt damit die
sonst übliche Basic Authentification an Hand eines Benutzernamens mit dem dazugehörenden Passwort.
Eine Einführung ins SSL-Protokoll, sowie den verwendeten Verschlüsselungsverfahren und
Authentifikations-Mechanismen liefert Netscape in [NS98-1]. SSL gilt als das meistverwendete Verschlüsselungsprotokoll im Internet; außerdem ist es ideal für die kryptographische
Absicherung komplexer TCP/IP-Netze geeignet, wie sie in großen und mittelständischen
Unternehmen vorkommen [KlSchm98].
3.7.1.3 Notwendige Zertifikaterweiterungen
Wie bereits eingangs erwähnt, verwenden alle in diesem Abschnitt besprochenen kryptographischen Verfahren die Vorteile von Zertifikaten nach X.509v3, um eine sichere Authentifikation der Kommunikationspartner zu gewährleisten. Die Firma Netscape erklärt in [NS99-1],
welche Erweiterungen in Zertifikaten gesetzt sein sollten, damit sie von Standardsoftware für
den jeweiligen Einsatzzweck akzeptiert werden. Diese Informationen werden von der eingesetzten Trustcenter-Software benötigt, um gültige Zertifikate auszustellen.
Folgende Tabelle enthält Erläuterungen zu den folgenden Tabellen [5], [6] und [8] bezüglich
des Einsatzes der von Netscape geforderten Zertifikatserweiterungen.
Bemerkung Nr.
1
Erläuterung
Nur gültig in Verbindung mit mehrstufigen Hierarchien, beim Einsatz einer flachen Hierarchie gelten für das Wurzel CA Zertifikat die
Bedingungen für Zertifikate untergeordneter CAs.
Tabelle 4 Erläuterungen zum Verständnis der Tabellen [5], [6] und [8]
35
Bemerkung Nr.
Erläuterung
2
Netscape und Microsoft empfehlen den Einsatz dieser Erweiterung.
3
Netscape und Microsoft verlangen den Einsatz dieser Erweiterung.
4
Wird vom Netscape Communicator nicht benötigt.
5
Wird nur von Netscape beachtet, Microsoft beispielsweise ignoriert
meist sämtliche Netscape-spezifischen Erweiterungen.
6
Wird von einigen Netscape Servern benötigt.
7
IP-Adresse oder URI bei SSL-Servern, Email-Adresse bei S/MIME
8
Für Zertifikate, die zur S/MIME-Signatur vorgesehen sind.
9
Für Zertifikate, die zur S/MIME-Verschlüsselung vorgesehen sind.
Tabelle 4 Erläuterungen zum Verständnis der Tabellen [5], [6] und [8]
Erweiterungen für SSL-Clientzertifikate
Folgende Erweiterungen sollten in Zertifikaten gesetzt sein, damit diese sowohl von Produkten
der Firmen Netscape als auch Microsoft als gültig für SSL Clients angesehen und nicht zurückgewiesen werden.
Zertifikat der
Wurzel CA1
Zertifikat einer
untergeordneten CA
ausgestellte
Benutzerzertifikate
Bemerkung Nr.
authorityKeyIdentifier
2
basicConstraints:
CA = true
basicConstraints:
CA = true
3
cRLDistributionPoints
2+4
keyUsage:
keyCertSign, cRLSign
keyUsage:
keyUsage:
digitalSignature
netscape-cert-type:
SSL CA
netscape-cert-type:
SSL CA
netscape-cert-type:
SSL Client
5
subjectKeyIdentifier
2
Tabelle 5 notwendige Zertifikaterweiterungen für SSL Clientzertifikate
Erweiterungen für SSL-Serverzertifikate
der Firmen Netscape als auch Microsoft als gültig für SSL Server angesehen und nicht zurück-
36
gewiesen werden.
Zertifikat der
Wurzel CA1
Zertifikat einer
untergeordneten CA
ausgestellte
Benutzerzertifikate
Bemerkung Nr.
2
2+4
keyUsage:
keyUsage:
keyUsage:
keyEncipherment
netscape-cert-type:
SSL CA
netscape-cert-type:
SSL CA
netscape-cert-type:
SSL Client6, SSL Server
5
subjectAltName
7
2
Tabelle 6 notwendige Zertifikaterweiterungen für SSL Serverzertifikate
3.7.2
S/MIME
S/MIME (Secure MIME) ist ein Verschlüsselungsstandard der US-Firma RSA Security Inc. zur
Wahrung von Vertraulichkeit, Authentizität und Integrität elektronischer Nachrichten (Email).
S/MIME verwendet für die Unterteilung einer Nachricht das von den meisten Emailprogrammen unterstützte MIME-Format (Multipurpose Internet Mail Extensions). Nachrichten im
MIME-Format können aus mehreren Teilen zusammengesetzt sein, wobei jeder dieser Teile
aus einem anderen Datentyp bestehen darf (Texte, Bilder, Filme, Musik, etc.). S/MIME stellt
hierfür eigene sog. MIME-Typen zur Verfügung und unterstützt dabei die in Tabelle [7]
genannten kryptographischen Algorithmen für Verschlüsselung, digitale Signatur, Hashfunktionen sowie Schlüsselaustausch. In [RFC2633] wird festgelegt, welche Algorithmen dabei auf
Sender- und Empfängerseite unterstützt werden müssen und welche zusätzlich verwendet werden sollten, um die Kompatibilität zu älteren S/MIME Versionen zu ermöglichen.
Sender
Empfänger
Verfahren
muss unterstützt
werden
zusätzlich
möglich
muss unterstützt
werden
zusätzlich
möglich
Verschlüsselung
Tripple-DES
Digitale Signatur
DSS
RSA DSS
RSA
Schlüsselaustausch
Diffie-Hellman
RSA Diffie-Hellman
RSA
Hashfunktion
SHA-1
SHA-1
MD5
Tripple-DES
RC2/40
Tabelle 7 S/MIMEv3: kryptographische Algorithmen auf Sender- und Empfängerseite
37
Zudem werden Zertifikate nach dem X.509v3 Standard verwendet, um einen sicheren Austausch der öffentlichen Schlüssel zu gewährleisten. Mehr über die Funktionsweise von S/
MIMEv3 liefern [RFC2632] und [RSAFAQ]. S/MIME wird u. a. von den Firmen Microsoft
und Netscape in ihren Emailprogrammen unterstützt und eignet sich so hervorragend zur Verschlüsselung des elektronischen Nachrichtenverkehrs.
der Firmen Netscape als auch Microsoft als gültig für S/MIME Benutzerzertifikate angesehen
und nicht zurückgewiesen werden. Die in Tabelle [4] aufgeführten Erläuterungen gelten auch
für diese Erweiterungen.
Zertifikat der
Wurzel CA1
Zertifikat einer
untergeordneten CA
ausgestellte
Benutzerzertifikate
Bemerkung Nr.
2
2+4
keyUsage:
keyUsage:
keyUsage:
digitalSignature8,
keyEncipherment9
netscape-cert-type:
S/MIME CA
netscape-cert-type:
S/MIME CA
netscape-cert-type:
S/MIME
5
subjectAltName
7
2
Tabelle 8 notwendige Zertifikaterweiterungen für S/MIME Benutzerzertifikate
3.7.3
IPSec
IPSec (Internet Protokoll Security) ist eine Erweiterung für das IP-Protokoll, die durch den
Einsatz von Kryptographie Vertraulichkeit, Authentizität und Integrität gewährleistet. Im
Gegensatz zu SSL wird für IPSec keine neue Schicht ins TCP/IP Modell eingeführt, siehe
Abbildung 11. Stattdessen wird das IP-Protokoll selbst um einige Bestandteile wie Schlüsselaustausch, Verschlüsselung und Authentifikation erweitert. Für das momentan verwendete
IPv4 ist IPSec eine Ergänzung, während es im kommenden IPv6 schon enthalten ist.
IPSec ist allerdings kein einzelner Standard, sondern eher ein ganzes Framework von Standards und wird folglich von einer ganzen Reihe von RFCs beschrieben (u. a. die RFCs 24012412). Grundsätzlich gliedert es sich in die folgenden beiden Funktionsbereiche:

IPSP (IP Security Protokoll)
Der erste Bereich mit dem Namen IP Security Protokoll enthält die symmetrische
Verschlüsselung und die Authentifikation von IP-Paketen mithilfe einer schlüssel-
38
abhängigen Hashfunktion.

IKMP (Internet Key Management Protokoll)
Der zweite Bereich ist für das Schlüsselmanagement zuständig. Vom IETF wurde
dazu das IKMP (Internet Key Management Protokoll) entwickelt, das für den
Schlüsselaustausch mithilfe asymmetrischer Verfahren sorgt.
Host
Host
HTTP,
HTTP, Telnet,
Telnet,
FTP,
FTP, POP3,
POP3, ...
...
TCP
TCP
HTTP,
HTTP, Telnet,
Telnet,
FTP,
FTP, POP3,
POP3, ...
...
TCP
TCP
Router
IPSec
IPSec
IPSec
IPSec
IP
IP
LAN,
LAN, PPP,
PPP, ...
...
LAN,
LAN, PPP,
PPP, ...
...
LAN,
LAN, PPP,
PPP, ...
...
Abbildung 11 IPSec verschlüsselt auf IP-Ebene
3.7.3.1 IPSP
Der Funktionsbereich IPSP ist selbst zweigeteilt. Zwei unterschiedliche Übertragungsprotokolle können für den Transport der Daten eingesetzt werden. Die symmetrische Verschlüsselung von IP-Paketen wird vom Encapsulated Security Payload (ESP) genannten Protokoll zur
Verfügung gestellt. Welche Verschlüsselungsverfahren dafür verwendet werden, ist hierbei
nicht festgelegt, [RFC1829] schlägt beispielsweise DES vor. Soll auf Verschlüsselung verzichtet werden, kommt der Authentication Header (AH) zum Einsatz. Dieser ermöglicht durch eine
schlüsselabhängige Hashfunktion wie MD5 oder SHA1 die Integritätsprüfung von IP-Paketen
([RFC1828]).
ESP
Encapsulated Security Payload ([RFC2406]) bietet zwei unterschiedliche Arbeitsmodi. Im
Transportmodus werden ausschließlich die Nutzdaten eines IP-Paketes verschlüsselt. Der Header selbst bleibt unverändert, damit er für Router, die ein Paket durchläuft, lesbar ist. Im Tunnelmodus hingegen wird das gesamte IP-Paket (inkl. Header und Nutzdaten) verschlüsselt und
in den Nutzdatenteil eines neuen IP-Paketes gepackt (gekapselt), wie in Abbildung 12 zu sehen
([DaBachf01]). Durch diese Technik wird der Header, in dem u. a. die Sende- und Empfangsadresse eines Paketes untergebracht sind, unlesbar gemacht.
Nützlich ist der Tunnelmodus vor allem dann, wenn Pakete über unsichere Zwischensysteme
geschickt werden, also beispielsweise zwischen zwei Firewall-Systemen, welche die VPNVerbindung realisieren, wie in Abbildung 13 dargestellt. In solch einem Fall sind für einen
Lauscher im Zwischennetz nur die Informationen des äußeren Paketes sichtbar. D. h. als
Sende- und Empfangsadresse die beiden Firewalls, welche auch als VPN-Gateways oder Tunnelendpunkte bezeichnet werden. Ob das Paket vom Sender A oder B abgeschickt wurde und
welchen Empfänger es wirklich erreichen soll, kann ein Lauscher nicht erkennen. Die Firewall
des Empfängers hingegen, erhält die notwendigen Ziel-Informationen nach der Authentifizie-
39
rung und Entschlüsselung des eigentlichen (eingekapselten) IP-Paketes und kann dieses dann
ohne IPSec-Authentifizierung oder -Verschlüsselung an den richtigen Empfänger weiterleiten.
Orginal IP-Paket
IP Header
Daten
IP-Paket mit ESP im Transportmodus
IP Header
ESP Header
Daten
ESP Trailer
ESP Auth
verschlüsselt
authentifiziert
IP-Paket mit ESP im Tunnelmodus
neuer
IP Header
ESP Header
IP Header
Daten
ESP Trailer
ESP Auth
verschlüsselt
authentifiziert
Abbildung 12 ESP Modi im Vergleich
Der Header des umgebenden IP-Paketes wird von ESP allerdings nicht verschlüsselt oder
authentifiziert, sodass das Routing der IP-Pakete selbst im Tunnelmodus kein Problem für
Router oder Switches darstellt, welche IPSec selbst nicht implementieren. Der neue Tunnel-IPHeader dient somit zum Weiterleiten zwischen den beiden Tunnelendpunkten.
verschlüsselte
IP Pakete
unverschlüsselte
IP Pakete
Sender A
Empfänger A
Tunnel
Internet
VPN-fähige
Firewall A
VPN-fähige
Firewall B
Sender B
Empfänger B
Abbildung 13 IPSec mit ESP im Tunnelmodus
ESP im Tunnelmodus ähnelt dem NAT-Verfahren (Network Address Translation), das von einigen Firewalls verwendet wird, um ganze Subnetze hinter einer IP-Adresse zu verbergen. Da
beide Verfahren die ursprüngliche Quelladresse durch eine Neue ersetzen, gibt es Probleme,
wenn ESP im Tunnelmodus gleichzeitig mit NAT betrieben und das VPN-Gateway dabei hin-
40
ter der Firewall platziert wird. Eine Lösung besteht darin, dem IPSec VPN-Gateway eine
öffentliche IP-Adresse zu vergeben, sodass getunnelte IP-Pakete von NAT ausgenommen werden.
AH
Der Authentication Header ([RFC2402]) sieht im Gegensatz zu ESP keinerlei Verschlüsselung
vor, sondern soll ausschließlich die Integrität eines IP-Paketes sicherstellen. Dazu wird auf die
Nutzdaten und einige ausgewählte Header-Felder des Paketes eine schlüsselabhängige Hashfunktion angewendet, und deren Resultat in einem zusätzlichen Feld im Header vermerkt.
Steht das VPN Gateway hinter einer Firewall, die NAT implementiert, kann IPSec nicht mit
AH verwendet werden. AH erlaubt keine nachträglichen Änderungen an IP-Paketen, da sonst
die AH-Prüfsumme - welche die Integrität des IP-Paketes sicherstellen soll - nicht mehr korrekt ist. NAT ist allerdings darauf angewiesen, die Sender-IP-Adresse im Header zu verändern.
NAT und AH lassen sich daher nicht kombinieren.
Wie ESP kann auch AH sowohl im Transport- als auch im Tunnelmodus betrieben werden.
3.7.3.2 IKMP
Das Internet Key Management Protokoll (IKMP) ist, wie der Name schon andeutet, bei IPSec
für das Schlüsselmanagement zuständig. Es stehen zwei von einander unabhängig entwickelte
Verfahren zur Auswahl, um diese Aufgabe zu erfüllen. Zum einen SKIP, welches von der
Firma SUN entwickelt wurde, zum anderen das Gespann aus Oakley und ISAKMP, welches
beispielsweise bei der IPSec-Implementierung von Microsofts Windows 2000 Verwendung
findet.
SKIP
Das Simple Key Management Protokoll (SKIP) ermöglicht wie das im Folgenden besprochene
Oakley einen Diffie-Hellman-Schlüsselaustausch (key agreement). Dazu wurden die IP-Pakete
um spezielle Informationen, die der Empfänger zum Entschlüsseln oder Überprüfen des Hashwertes benötigt, im Header erweitert. Somit sind alle relevanten Informationen schon im
Datenpaket enthalten.
SKIP funktioniert im Prinzip folgendermaßen: Senderin (Alice) und Empfänger (Bob) berechnen mithilfe des Diffie-Hellman key agreement Verfahrens einen gemeinsamen geheimen
Schlüssel k. D. h., Alice verwendet den öffentlichen Schlüssel von Bob gx modp (beispielsweise aus einem X.509 Zertifikat) um mithilfe ihres privaten Schlüssels y den gemeinsamen
geheimen Schlüssel k zu berechnen.
k = gxy modp
Bob verfährt entsprechend umgekehrt und verwendet seinen eigenen privaten Schlüssel x und
den öffentlichen Schlüssel von Alice gy modp um denselben gemeinsamen Schlüssel k zu
erhalten.
k = gyx modp
41
Diese Prozedur ist prinzipbedingt nur einmal notwendig - solange weder Alice, noch Bob ihr
asymmetrisches Schlüsselpaar wechseln, muss der gemeinsame Diffie-Hellman-Schlüssel k
für eine zukünftige Kommunikation nicht neu berechnet werden.
Der ausgetauschte Schlüssel k wird allerdings nicht direkt zum Verschlüsseln der IP-Pakete
benutzt. Aus Sicherheitsgründen werden Nachrichten (welche üblicherweise aus mehreren
Paketen bestehen) mit unterschiedlichen Sitzungsschlüsseln verschlüsselt. Dazu wird vom ausgetauschten Schlüssel k der Hashwert h(k) berechnet, der als Master-Schlüssel
km = h(k)
für die Verschlüsselung der einzelnen Sitzungsschlüssel verwendet wird. Der so verschlüsselte
Sitzungsschlüssel ks wird dann als Bestandteil des SKIP-Headers im IP-Paket untergebracht
und mitversendet.
Oakley und ISAKMP sowie IKE
Das Internet Security Association and Key Management Protocol (ISAKMP) beschreibt, wie
Security Associations (SAs) zwischen Kommunikationspartnern auszuhandeln sind. SAs sind
temporäre Sicherheitsrichtlinien, die alle Parameter für eine sichere Verbindung enthalten, wie
etwa die zu verwendenden kryptographischen Algorithmen oder die Lebensdauer von Schlüsseln. Oakley beschreibt eine Serie von verschiedenen Schlüsselaustauschverfahren, die nacheinander angewendet werden und zur Authentifikation sowie beim Austausch von
Sitzungsschlüsseln zum Einsatz kommen.
Sowohl Oakley als auch ISAKMP sind ausschließlich Beschreibungen eines Frameworks - der
Internet Key Exchange (IKE, [RFC2409]) hingegen ist eine konkrete Implementierung von
Oakley/ISAKMP und umfasst neben dem Schlüsselaustausch auch die Authentifizierung von
Teilnehmern unter Benutzung von SAs.
IKE kommt somit beim Aufbau der gesicherten Verbindung zum Einsatz. In einer ersten Phase
sorgt IKE für den Austausch von gemeinsamen geheimen Schlüsseln und der Authentifikation
von Verbindungspartnern durch Zertifikate oder Shared Secrets. Dazu wird - wie bei IKMP das Diffie Hellman key agreement Verfahren verwendet. In der zweiten Phase werden zufällig
generierte, symmetrische Schlüssel ausgetauscht, um die eigentliche Verbindung zu verschlüsseln. In jeder Phase müssen sich die Verbindungspartner auf die jeweiligen zu verwendenden
kryptographischen Algorithmen einigen, wie beispielsweise DES- oder IDEA-Verschlüsselung. Kommt keine Einigung zu Stande, da die VPN-Verbindungspunkte unterschiedlich konfiguriert sind und einer der Verbindungspartner z. B. auf DES, der andere auf IDEA besteht,
wird der Verbindungsaufbau abgebrochen.
3.7.3.3 Virtuelle private Netzwerke (VPN) mit IPSec
IPSec in Verbindung mit ESP im Tunnelmodus eignet sich für die Einrichtung virtueller privater Netzwerke (VPN). Virtuelle private Netzwerke dienen dazu, Firmen mit mehreren Niederlassungen die Kommunikation und den gemeinsamen Zugriff auf zentrale Ressourcen zu
ermöglichen oder mobilen Mitarbeitern Zugang zum lokalen Netzwerk zu verschaffen. Der
Aufbau einer solchen Verbindung erfolgt i.A. über ein unsicheres (öffentliches) Transitnetzwerk wie dem Internet. Eine derartige Verbindung wird virtuell privat genannt, da es sich dabei
um eine übergeordnete Struktur handelt, die auf dem öffentlichen Netzwerk aufsetzt, um eine
42
private Verbindung herzustellen.
Die in den vorangegangenen Abschnitten vorgestellte Eigenschaft des Schutzes von IP-Paketen ermöglicht in einem solchen VPN den Schutz des Netzwerkverkehrs auf IP-Ebene3 vor folgenden Bedrohungen:

Unbemerkte Datenänderung während des Versendens
Beim Einsatz von IP-ESP oder IP-AH

Mitlesen von Daten
Beim Einsatz von IP-ESP.

Unautorisierter Datenzugriff
Bei Authentifikation mittels X.509 Zertifikaten, Kerberos oder Shared Secrets.
Die Verwendung von IPSec im Tunnelmodus erfolgt für Rechner, die nicht zum Senden oder
Empfangen eingesetzt werden, vollkommen transparent. D. h. Rechner, welche innerhalb des
Tunnels passiert werden und keinen Tunnelendpunkt bilden, müssen nicht über IPSec informiert werden. Ausschließlich Rechner am jeweiligen Tunnelende sind für die Sicherheit
zuständig.
Als Einsatzgebiet für eine IPSec-Implementierung wie sie beispielsweise Windows 2000 bietet, sind folgende Anwendungsfälle denkbar [MS00-3]:

LAN: Peer-to-Peer
Verbindungen innerhalb eines LANs zwischen zwei Client-Rechnern, ohne Vermittlung eines zusätzlichen IPSec-Gateways. Die Kommunikation wird ausschließlich zwischen den beiden Rechnern verschlüsselt, der restliche LANVerkehr bleibt dagegen weiterhin unverschlüsselt. Diese Konfiguration schützt vor
LAN-internen Angreifern, wie beispielsweise Mitarbeitern des eigenen Unternehmens und bietet die größte Sicherheit, da die Verbindung von Anfang bis Ende
(peer-to-peer) verschlüsselt wird.

LAN: Client/Server
Verbindungen innerhalb eines LANs zwischen einem sicheren Server und zugreifenden Client-Rechnern4. Die Kommunikation zwischen dem Server und den Clients erfolgt verschlüsselt, der restliche LAN-Verkehr bleibt dagegen weiterhin
unverschlüsselt. Diese Konfiguration schützt ebenso wie Peer-to-Peer vor LANinternen Angreifern, wie beispielsweise Mitarbeitern des eigenen Unternehmens.

WAN: Gateway-to-Gateway (z. B. Router-to-Router oder Firewall-to-Firewall)
Eine Verbindung von zwei LANs über ein möglicherweise unsicheres Zwischensystem (Transitnetz) wie das Internet. Die VPN-Gateways bilden die beiden Tunnelendpunkte, zwischen denen eine verschlüsselte IPSec-Verbindung aufgebaut
3. IPSec kann keine anderen Protokolle als TCP/IP tunneln, im Zweifelsfall muss ein Protokoll vorher in
IP eingepackt werden [DaBachf01].
4. Zum Einsatz kommt diese Variante beispielsweise, wenn ein Client innerhalb des LANs sicher auf eine
Datenbank mit sensiblen Informationen zugreifen möchte.
43
wird. Client-Rechner sowie Server, welche eine Verbindung über diese Gateways
aufbauen, müssen kein IPSec unterstützen. Allerdings bleibt bei der Gateway-toGateway Kommunikation die Verbindung der jeweiligen Rechner bis zum Gateway unverschlüsselt. Das unsichere Transitnetz unterscheidet sich sicherheitstechnisch nicht mehr von einer dedizierten WAN-Verbindung. Diese Konfiguration
bietet ausschließlich Schutz vor Angreifern aus dem Zwischensystem und im
Gegensatz zu den beiden Vorhergenannten keinerlei Sicherheit vor LAN-internen
Angreifern.

Remotezugriff: Client-to-Gateway (z. B. Client-to-Firewall oder Client-toRouter)
Die Verbindung mobiler Client-Rechner (außerhalb des LANs) über ein möglicherweise unsicheres Transitnetz mit dem LAN des Unternehmens (um Zugriff auf
Ressourcen und Server des Firmennetzes zu erhalten) wird auch als Remote-Access
bezeichnet. Die Kommunikation zwischen dem Gateway und den Clients erfolgt
verschlüsselt, die restliche LAN Kommunikation bleibt dagegen weiterhin unverschlüsselt. Diese Konfiguration bietet den gleichen Schutz vor externen Angreifern
wie eine Gateway-to-Gateway Lösung.
Die Komplexität des IPSec Standards ermöglicht eine flexible Anpassung an die jeweiligen
Sicherheitsbedürfnisse. Es können verschiedene Tunnel unterschiedlich konfiguriert oder
unterschiedliche kryptographische Algorithmen eingesetzt sowie zur Authentifikation auf Zertifikate verzichtet und stattdessen Kerberos verwendet werden. Diese Flexibilität hat allerdings
einen entscheidenden Nachteil. Die Vielzahl von Herstellern, die IPSec-fähige Router, Firewalls oder Betriebssysteme (bzw. -Erweiterungen) anbieten, verwenden z. T. inkompatible
IPSec-Implementierungen. Kompatibilitätsprobleme erschweren nicht nur den gleichzeitigen
Einsatz von Produkten unterschiedlicher Hersteller nebeneinander, sie erschweren auch eine
allgemein gültige Aussage darüber, welche Erweiterungen notwendig sind, damit Zertifikate
von den jeweiligen Produkten für IPSec akzeptiert werden.
An dieser Stelle wird daher auf eine tabellarische Auflistung der notwendigen Zertifikaterweiterungen verzichtet.
3.8
Verzeichnisdienste
Verzeichnisdienste bieten Zugriff auf Verzeichnisse und wurden bereits in Kapitel [3.4.1] im
Zusammenhang mit der öffentlichen Bereitstellung von Zertifikaten und Widerrufslisten
erwähnt. Verzeichnisse wie X.500 oder LDAP unterscheiden sich von üblichen Datenbanken
durch eine baumartig strukturierte Anordnung des verwalteten Datenbestandes. Verzeichnisse
sind darauf ausgelegt, weit gehend statische Daten zu verwalten, Änderungen am Datenbestand stellen gegenüber der reinen Abfrage von Daten eher die Ausnahme dar. Daten, die in
Verzeichnissen verwaltet werden, sind beispielsweise Namen, Adressen, Informationen über
Personen, Organisationen, Gruppen, Datenspeicher, Geräte, Dienste oder auch Zertifikate und
Widerrufslisten.
Im Folgenden werden die verbreitetsten Basisdienste und Technologien für die komfortable
Verwaltung von Zertifikaten und Widerrufslisten besprochen.
44
3.8.1
X.500
Der Verzeichnisdienst X.500 wird an dieser Stelle nur kurz umrissen, es werden insbesondere
die Unterschiede zu dem im nächsten Abschnitt besprochenen LDAP beschrieben. X.500 setzt
auf dem OSI-Schichtenmodell auf und sieht keine Benutzung vorhandener Kommunikationsprotokolle wie TCP/IP5 vor. Das OSI-Schichtenmodell erfordert einen erheblichen Mehraufwand bei der Entwicklung von Verzeichnisclients und -Servern und bietet für die öffentliche
Bereitstellung von Zertifikaten und Widerrufslisten keine Vorteile, sodass es im Allgemeinen
durch das „leichtgewichtigere“ LDAP ersetzt werden kann.
DAP
OSI
X.500 Client
X.500 Server
Verzeichnis
Abbildung 14 X.500 Server
X.500 definiert verschiedene Protokolle für die Bereitstellung des Verzeichnisses
[DWChad96], im Einzelnen sind dies:

DAP (Directory Access Protocol)
Definiert die Kommunikation zwischen X.500-Clients (Directory User Agents,
kurz: DUA) und X.500-Servern (Directory System Agents, kurz: DSA) und dient
dem Zugriff auf die im Verzeichnis enthaltenen Informationen (siehe Abbildung
14).

DSP (Directory System Protocol)
Definiert die Kommunikation zwischen verschiedenen X.500-Servern.

DISP (Directory Information Shadowing Protocol)
Definiert den Informationsaustausch zur verteilten Datenhaltung (Replikation)
mittels Master- und Slave-DSA.
Wesentliche Nachteile sind der hohe Implementierungsaufwand sowie der "schwergewichtige"
Zugriff über die o. g. Protokolle. Insbesondere DAP enthält mehr Funktionen, als für die meisten Anwendungsfälle benötigt werden. Hinzu kommt, dass die Kommunikation zwischen Client und Server im Regelfall recht hohe Netzlasten erzeugt.
5. TCP/IP ist im Gegensatz zum OSI-Schichtenmodell bereits Bestandteil der meisten Betriebssysteme.
45
3.8.2
LDAP
Das Lightweight Directory Access Protocol (LDAP) ist ebenso wie X.500 ein offener Standard
für Informationsdienste auf Basis einer baumähnlichen (hierarchischen) Datenbankstruktur
und ist z. B. in Microsofts Windows 2000 Server in Form des Active Directories integriert. Der
Vorteil gegenüber einer normalen Datenbank ist die attributsbezogene Speicherung von Informationen. LDAP ist aus dem im vorigen Abschnitt besprochenen X.500 Verzeichnisdienst entstanden, benutzt aber an Stelle des OSI Schichtenmodells einen gewöhnlichen TCP/IP
Protokollstack. Bei der Entwicklung von LDAP wurde nur ein Teil der DAP-Funktionen übernommen, allerdings reichen die Vorhandenen vollständig aus, um den Rest zu emulieren
[ThBend99]. Der Verzeichnisaufbau ist im Vergleich zu X.500 etwas vereinfacht worden, beispielsweise werden die Daten bei LDAP meist im Klartext abgelegt.
3.8.2.1 Vom Protokoll zum Verzeichnis
Das LDAP-Protokoll definiert eine Methode, um Abfragen von einem LDAP-Client zu einem
X.500-ähnlichen Verzeichnis direkt über den TCP/IP-Protokoll-Stack abzuwickeln. LDAP
definiert nicht das Verzeichnis selbst. In der Literatur findet man oft zwei unterschiedliche
Interpretationen, an einigen Stellen wird von LDAP-Verzeichnissen gesprochen, an anderen
wiederum nur von LDAP als Protokoll. Natürlich ist LDAP ein Protokoll - und zwar für die
Kommunikation zwischen LDAP-Client und -Server. Allerdings wird LDAP z. T. auch ohne
einen expliziten X.500 Server eingesetzt, indem sich der LDAP-Server für den Verzeichnisdienst verantwortlich zeigt. Im ersten Fall hat der LDAP-Server nur die Funktion eines Gateways, im letzten Fall die eines Verzeichnisservers.
LDAP als Gateway
Ursprünglich wurde LDAP ausschließlich zusammen mit X.500 Verzeichnissen eingesetzt.
Dazu kommunizieren LDAP Clientprogramme mit einen Gateway-Prozess (Proxy), der die
LDAP-Nachrichten übersetzt und an den X.500 Server weiterleitet, wie in Abbildung 15 zu
sehen.
LDAP Client
LDAP
DAP
TCP/IP
OSI
LDAP Server
X.500 Server
Verzeichnis
Abbildung 15 LDAP Server als Gateway zum X.500 Server
46
Dies ist notwendig, da LDAP Clientprogramme ausschließlich die Kommunikation über
LDAP-Nachrichten beherrschen, X.500 Server wiederum verstehen nur DAP. Mehr noch, es
kommen gar unterschiedliche Schichtenmodelle zum Einsatz (TCP/IP bzw. OSI).
In seiner Rolle als Gateway muss ein LDAP Server also zwei Kommunikationsprotokolle
beherrschen und sowohl als Client für den X.500 Server, als auch als Server für den LDAP Client auftreten. Der ursprüngliche Lösungsansatz hat zwar den Vorteil, dass LDAP Clients nun
über das weit verbreitete TCP/IP mit einem „leichtgewichtigerem“ Server kommunizieren
können - ein Unternehmen, welches ein derartiges Verzeichnis aufbaut, kann dennoch nicht auf
den Einsatz von OSI für den X.500 Server verzichten.
LDAP als Verzeichnisserver
In vielen Installationen wird daher komplett auf den X.500 Server verzichtet, womit auch die
Notwendigkeit entfällt, das OSI-Schichtenmodell zu unterstützen. Der LDAP Server muss
dann selbst für den Zugriff auf das Verzeichnis sorgen und nicht mehr nur als Vermittler zwischen Client und X.500 Server agieren (Abbildung 16). Natürlich ist solch ein LDAP Server
weit aus komplizierter aufgebaut, da er nun die komplette Verzeichnisverwaltungsarbeit übernehmen muss. Wenn auch die Verwaltung vergleichsweise einfach ausfällt, da LDAP nur einen
Teil der DAP-Funktionen implementiert.
Derartige Server werden meist auch als Stand-Alone LDAP Server bezeichnet, da sie nicht
mehr von X.500 Verzeichnisservern abhängig sind. Aus Sicht des Clients spielt die LDAP
Implementierung keine Rolle. Jeder Server, der das LDAP Protokoll implementiert, ist ein
LDAP Verzeichnisserver - unabhängig davon, ob er das Verzeichnis nun real verwaltet, oder
nur als Gateway den Zugriff auf X.500 Server vermittelt.
LDAP
TCP/IP
LDAP Client
LDAP Server
Verzeichnis
Abbildung 16 Stand-Alone LDAP Server
3.8.2.2 Das Informationsmodell
Die Basisinformationseinheit im LDAP Verzeichnis nennt sich Verzeichniseintrag. Ein Eintrag
ist aus verschiedenen Attributen aufgebaut, die z. T. schon vordefiniert sind. So existieren
Attribute für die Definition häufig verwendeter Objektklassen wie Firmen, Personen, Gruppen,
47
Lokationen, Organisationen, usw. Jedes Attribut hat einen Datentyp (z. B. Binärfeld, Zeichenkette, Datum, usw.) und einen oder mehrere Werte. Die Beziehung zwischen einem Verzeichniseintrag, seinen Attributen und ihren Werten zeigt Abbildung 17 [IBM98].
Eintrag
Attribut
Attribut
Attribut
Typ
Attribut
Attribut
Wert
Wert
Wert
Abbildung 17 Das Informationsmodell: Einträge, Attribute und Werte
Jede Objektklasse definiert ihre eigenen Attribute, die darüber entscheiden, welche Informationen ein Eintrag enthalten kann. Eine Objektklasse kann beispielsweise eine Telefonnummer,
einen öffentlichen Schlüssel oder ein Bild enthalten, wobei jede Objektklasse durch eigene
Attribute erweitert werden kann. Attribute können grundsätzlich bis auf wenige Ausnahmen
mehr als einen Wert enthalten. Bestimmte Attribute sind dabei als obligatorisch, andere nur als
optional anzusehen (d. h. sie müssen nicht unbedingt in der zugehörigen Objektklasse verwendet werden). Abbildung 18 zeigt dies an Hand eines Ausschnitts aus einem beispielhaften Verzeichnisbaum. Dort sieht man, das Attribut LocalityName L wird unterhalb von C=DE nur im
rechten Teilbaum verwendet, der Eintrag welcher durch den linken Teilbaum definiert wird,
verzichtet darauf.
Weiter oben wurde bereits erwähnt, dass ein Attribut mehr als nur einen Wert enthalten kann.
Dies ergibt durchaus Sinn, denn ein Attribut des Datentyps telephoneNumber beispielsweise
kann zwei Werte - einen mit der Privat- und einen mit der Geschäftstelefonnummer - aufnehmen, ohne dass ein weiteres Attribut desselben Typs in den Eintrag integriert werden müsste.
3.8.2.3 Das Namensmodell
Die in hierarchischen Einträgen abgelegten Daten besitzen global eindeutige Namen, welche
als Distinguished Name (DN) bezeichnet werden (vgl. Abschnitt [3.3.1]). Ein Eintrag im
LDAP-Baum sieht dann beispielsweise so aus:
cn=Bob Offliner, ou=IT, o=Becker Consulting GmbH, c=DE
Hierbei handelt es sich um die Person mit dem Namen Bob Offliner, die in der IT-Abteilung der Firma Becker Consulting GmbH in Deutschland angestellt ist. Die Zeichenfolgen cn, ou, o, und c bezeichnen vordefinierte Attribut-Typen. Tabelle [9] zeigt die am
häufigsten verwendeten Attribut-Typen und ihre Repräsentation als Zeichenfolge, wie sie in
[RFC2307] definiert sind.
48
Attribut-Typ
Zeichenfolge
üblicher Verwendungszweck
CommonName
cn
Name
OrganizationalUnitName
ou
Abteilung
OrganizationName
o
Firma, Organisation, Institut oder Behörde
LocalityName
l
Stadt
StateOrProvinceName
st
Bundesstaat oder Bundesland
CountryName
c
ISO-Ländercode:
z. B. DE für Deutschland, US für USA, usw.
StreetAddress
street
Straße
DomainComponent
dc
Teile eines Domainnamens:
z. B. DC=beco und DC=org für die Domain
beco.org
UserID
uid
Benutzername:
z. B. für die Objektklasse posixAccount
Tabelle 9 Distinguished Name: Attribut-Typen und ihre Repräsentation als Zeichenfolge
Verzeichnis-Wurzel
Verzeichnis-Wurzel
cc == DE
DE
cc == GB
GB
oo == Becker
Becker Consulting
Consulting
GmbH
GmbH
LL == Frankfurt
Frankfurt
ou
ou == IT
IT
oo == Allgemeine
Allgemeine Deutsche
Deutsche
Direktbank
Direktbank AG
AG
cn
cn == Bob
Bob Offliner
Offliner
ou
ou == IT
IT
cc == US
US
oo == National
National Security
Security
Agency
Agency
uid = bob
mail = bob@localhost
cn
cn == Alice
Alice I.I. Wunderland
Wunderland
uid = alice
mail = alice@localhost
Abbildung 18 Ausschnitt eines fiktiven LDAP-Verzeichnisbaumes
Abbildung 18 verdeutlicht die hierarchische Struktur von LDAP-Verzeichnissen an Hand einer
49
Anordnung der Einträge in Baumform. Die entsprechenden Knoten, welche zum Eintrag von
Bob gehören, sind farblich markiert. Weitere Einträge mit den Attributen c=GB und c=US sind
nur andeutungsweise dargestellt, um zu verdeutlichen, dass der gezeigte Ausschnitt Teil eines
erheblich umfangreicheren Verzeichnisbaumes sein kann.
3.8.2.4 Das Sicherheitsmodell
In einem LDAP Verzeichnis abgelegte Einträge können sowohl allgemein zugänglichen Informationen wie Zertifikate als auch vertrauliche Daten sein. Ein Hauptaugenmerk bei der Implementierung eines Verzeichnisdienstes gilt daher dem Thema Sicherheit. Je nach Grad der
Vertraulichkeit können bei LDAPv3 verschiedene Authentifizierungsmechanismen eingesetzt
werden.
Keine Authentifizierung
Dies ist die einfachste Methode. Sie wird benutzt, wenn das Verzeichnis nur aus allgemein
zugänglichen Informationen wie einem öffentlichen Telefonbuch, oder Zertifikaten besteht.
Zur Anmeldung werden keine Benutzerinformationen wie Loginname oder Passwort verlangt.
Die Verbindung zum LDAP Server wird folglich anonym hergestellt.
Einfache Authentifizierung
Bei dieser Methode wird zum Verbindungsaufbau der DN eines in diesem Verzeichnis enthaltenen Benutzers sowie das dazugehörende Passwort benötigt. Der Server kann entsprechend
konfiguriert werden, sodass nur bestimmte Benutzer autorisiert sind, auf sensible Daten schreibend bzw. lesend zuzugreifen. Diese sicherheitsrelevanten Authentifizierungsinformationen
werden allerdings unverschlüsselt zum Server übertragen, sodass in den meisten Fällen keine
ausreichende Sicherheit gewährleistet werden kann. Angreifer, welche den Netzwerkverkehr
zwischen Client und Server abhören, sind in der Lage die Authentifizierungsinformationen
abzufangen, um sich anschließend selbst unbefugten Zugang zu verschaffen.
Simple Authentication and Security Layer (SASL)
SASL ist eine Methode, die verbindungsorientierte Protokolle um Authentifikationsmechanismen erweitert. Ursprünglich entwickelt, um eine stärkere Authentifizierung für das IMAP-Protokoll zu erreichen, ist es nun auch für die Version 3 von LDAP verfügbar.
Nach der eigentlichen Authentifizierung durch SASL können die Kommunikationspartner
weitere Sicherheitsmechanismen wie Kerberos oder SSL zur Verschlüsselung der Übertragung
aushandeln.
Der Client ruft dazu den SASL-Treiber des Servers auf und nennt ihm den gewünschten
Sicherheitsmechanismus. Sofern der Server diesen unterstützt, verbindet sich der SASL-Treiber des Servers mit dem gewünschten Sicherheitssystem und leitet den Verbindungsaufbau ein.
Abbildung 19 zeigt die Beziehungen zwischen Client, Server und dem Authentifizierungssystem.
50
SASL
SASL
Authentisierungsanforderung
Authentisierungsanforderung
des
des Clients
Clients
SASL
SASL Treiber
Treiber
auf
auf dem
dem Server
Server
SASL
SASL
Authentifizierungssystem
Authentifizierungssystem
Anonym
Kerberos
SSL
Abbildung 19 Authentifizierung per SASL
3.8.2.5 LDAP URLs
Der LDAP Uniform Resource Locator (URL) erlaubt Zugriffe auf LDAP Verzeichnisse über
normale Webbrowser wie den Microsoft Internet Explorer oder den Netscape Navigator.
LDAP-URLs beginnen mit ldap:// (oder ldaps://, wenn die Verbindung mit SSL verschlüsselt wird) und können aus komplexen Suchanfragen zusammengebaut sein, wie in
Abbildung 20 zu sehen. Für dieses Beispiel wurde das LDAP Verzeichnis von www.openldap.com gewählt und nach der Person mit dem Benutzernamen mrv aus der Abteilung
people innerhalb der Domain openldap.org gesucht6. Die Suchanfrage wird dabei aus den
üblichen Attributen wie sie z. T. in Tabelle [9] beschrieben sind, aufgebaut. Für eine detaillierte Beschreibung des Syntax wird auf [RFC2255] verwiesen.
Abbildung 20 LDAP-Zugriff über Webbrowser
Moderne Emailprogramme und Webrowser nutzen diese Zugriffsmethode, um Informationen
wie Zertifikate oder CRLs direkt aus LDAP-Verzeichnissen zu empfangen. So kann der
Mechanismus zur Gültigkeitsprüfung von Zertifikaten durch diese Programme für den Nutzer
transparent erfolgen.
6. Um das Beispiel nachvollziehen zu können, muss bei einer evtl. vorhandenen Firewall mit Portfilter der
Port 389 für LDAP freigeschaltet sein. Eine Fehlermeldung vom Browser der Art „Verbindung konnte
nicht hergestellt werden / cannot connect“ ist sonst vorprogrammiert.
51
3.9
Rechtliche Aspekte des PKI Betriebes
Über Jahrtausende hinweg wurde Kryptographie hauptsächlich von Geheimdiensten und Militärs eingesetzt. Viele Regierungen - darunter auch die US-Regierung - sehen auch heute noch
den Einsatz von Verschlüsselung in einem engen Zusammenhang mit krimineller Energie. Die
Folge ist, dass starke Kryptographie in vielen Staaten gesetzlich beschränkt und in einigen gar
ganz verboten wurde.
3.9.1
Gesetzliche Beschränkungen
Die Möglichkeiten, den Einsatz von Kryptographie gesetzlich zu kontrollieren, sind vielfältig.
Vom einfachen Verbot, kryptographische Hard- und Software in andere Staaten zu exportieren,
über eine einschränkende Nutzung innerhalb des eigenen Staates, bis hin zum kompletten Verbot existieren verschiedene Varianten:

Verbote und Nutzungsbeschränkungen
Der Einsatz von Verschlüsselungsverfahren kann komplett oder teilweise gesetzlich verboten werden. So ist es möglich, die legale Nutzung von Verschlüsselung
auf Finanzdaten einzuschränken (d. h. auf den Bankenverkehr), oder Verschlüsselungslizenzen ausschließlich an Firmen und nicht an Privatpersonen herauszugeben. Letztere Einschränkung wird derzeit in Frankreich praktiziert.

Exportverbote und -beschränkungen
Aus den USA kommt folgende Beschränkung: Die Verbreitung von Kryptographie
im Inland ist dort nicht beschränkt, stattdessen wird Wert darauf gelegt, dies im
Ausland zu tun. Lange Zeit galt in den USA ein strenges Exportverbot für starke
Kryptographie, mehr dazu in Abschnitt [3.9.3].

Schlüsselwiederherstellung
Die dritte Möglichkeit Kryptographie gesetzlich zu regulieren wurde schon in
Abschnitt [3.6.1] näher besprochen: Daten dürfen zwar mit starker Kryptographie
verschlüsselt werden, jedoch müssen die notwendigen Schlüssel zur Entschlüsselung bei einer staatlichen Stelle hinterlegt werden.
In Deutschland wird derzeit die Verwendung von Kryptographie - zumindest was die Verschlüsselung betrifft - nicht durch Gesetze geregelt. Ein Gesetz, das auf andere Weise mit
Kryptographie zu tun hat, ist das schon mehrfach erwähnte Gesetz zur digitalen Signatur
(Signaturgesetz).
3.9.2
Gesetz zur digitalen Signatur (SigG)
Anfang des Jahres 2001 wurde das deutsche Signaturgesetz (SigG) aus dem Jahr 1997
[SigG97-1] an die europäische Signaturrichtlinie angepasst, um die europäische Vorgabe einer
rechtlichen Gleichstellung der elektronischen Signatur mit der eigenhändigen Unterschrift zu
erfüllen [SigG01-1]. Die dafür notwendigen Anpassungen an Formvorschriften im Privatrecht
[SigG01-2] sind seit August 2001 in Kraft. Damit ist die qualifizierte elektronische Signatur
(digitale Signatur) nun der gesetzlichen Schriftform in den meisten Fällen gleichgestellt.
Das vorher gültige deutsche SigG mit seinen hohen Sicherheitsanforderungen und den entspre-
52
chenden Verordnungen war nicht unumstritten. Auf der Suche nach einer europaweit allgemein rechtsgültigen Lösung für digitale Signaturen stieß man hauptsächlich auf den
Widerstand Großbritanniens. Der deutsche Ansatz wurde als zu teuer und die Anforderungen
als zu hoch kritisiert [CSH99]. Man befürchtete sogar, dass Zertifizierungsdienste weit gehend
in die Nische der Hochsicherheitsanwendungen verdrängt werden könnten [StKrem01]. Weiterhin gab es mit diesem Ansatz vielerorts keinen Anreiz, Lösungen für eine gesetzeskonforme
Signatur zu entwickeln, denn dem deutschen SigG fehlten jegliche Aussagen über evtl. Rechtsfolgen.
Großbritannien verfolgte daher einen anderen Rechtsansatz, der Sicherheit über Haftung definiert. Die neu geschaffene europäische Signaturrichtlinie, welche mit dem neuen SigG Anfang
2001 umgesetzt wurde, stellt nun auch einen Kompromiss zwischen der deutschen und der britischen Lösung dar: Haftung kombiniert mit hohen Sicherheitsstandards.
Für die Mehrheit der Rechtsgeschäfte in Deutschland hat der Gesetzgeber keine Schriftform
vorgesehen, d. h. fast alle Verträge können auch mündlich geschlossen werden (die Beweiskraft sei jetzt mal außen vor gelassen). Es gibt aber ein paar Ausnahmen: Bürgschaftserklärungen, Erteilung von Zeugnissen und Kündigungen von Arbeitsverträgen sind beispielsweise
Fälle, in denen auch heute noch die eigene Unterschrift erforderlich ist. Mit der Anpassung der
Formvorschriften im Privatrecht kann die schriftliche Form nun durch die elektronische Form
ersetzt werden, sofern dies nicht ausdrücklich durch ein Gesetz ausgeschlossen wird.
Für Rechtsgeschäfte im Internet werden diese wohl auch in Zukunft eine eher untergeordnete
Rolle spielen. Dort handelt es sich weit aus häufiger um Vereinbarungen, bei denen Verkäufer
von sich aus auf Schriftform bestehen, um ein Maximum an Rechtssicherheit zu erhalten.
Obgleich die Schriftform in diesen Fällen nicht gesetzlich vorgeschrieben wäre.
Die daraus hervorgehenden Auswirkungen auf Firmen, die den Aufbau einer Zertifizierungsinfrastruktur gemäß SigG planen, werden im Folgenden näher betrachtet.
Beweislastumkehr
Die Beweisführung im Falle einer, bezüglich der Echtheit, strittigen digitalen Signatur wurde
mit der Anpassung der Formvorschriften im Privatrecht zu Ungunsten der SignaturschlüsselInhaber geändert. Wenn eine digitale Unterschrift dem Signaturgesetz entspricht, gilt sie auch
als echt; zumindest solange nichts grundsätzlich dagegen spricht, dass sie mit dem Willen des
Signaturschlüssel-Inhabers abgegeben wurde. Bei realen Unterschriften muss bislang der
Empfänger beweisen, dass eine abgegebene Unterschrift auch tatsächlich vom Inhaber stammt.
Dies fällt nun auf den Signaturschlüssel-Inhaber zurück, d. h. dieser muss beweisen, dass es
anderen möglich war, die Signatur zu fälschen [UtRoos01].
Auswirkungen auf Zertifizierungsstellen
Mit der Anpassung des Signaturgesetzes an die europäische Signaturrichtlinie ergeben sich
auch rechtlich interessante Auswirkungen auf Zertifizierungsdienste. Das betrifft insbesondere
Firmen, die mit ihrer, derzeit noch firmenintern betriebenen, Zertifizierungsinfrastruktur an die
Öffentlichkeit gehen wollen, um auch der breiten Masse der Bevölkerung ihre Signaturen für
Rechtsgeschäfte anzubieten:
53

Haftung
Für Zertifizierungsdienste gilt jetzt eine Haftungsregelung, die besagt, dass sie im
Falle des eigenen Verschuldens für einen evtl. Schaden gegenüber Dritten aufkommen müssen, falls diese einem scheinbar gültigen Zertifikat vertraut haben (SigG
§11, Absatz 1). Um dies sicherzustellen, müssen Zertifizierungsdienste für eine
Deckungsvorsorge in Höhe von mindestens 500.000 DM sorgen, aus dieser dann
entsprechende Schäden Dritter ersetzt werden (SigG §12).

Bußgeld
Für Verstöße gegen das Signaturgesetz gilt jetzt eine Bußgeldregelung. Ordnungswidrigkeiten werden je nach Schwere mit einer Geldbuße von bis zu 100.000 DM
geahndet (SigG §21).

Genehmigungspflicht
Die bislang geltende Genehmigungspflicht für den Betrieb eines Zertifizierungsdienstes wurde zu Gunsten einer freundlicheren Anzeigepflicht ersetzt (SigG §4,
Absatz 1 und 3). Dadurch reduzieren sich die Kosten für den Aufbau einer Zertifizierungsinfrastruktur, was letztlich der Verbreitung digitaler Signaturen zu Gute
kommen wird.
Auch wenn die Genehmigungspflicht jetzt entfallen ist, kann dennoch nicht auf Kontrollmechanismen verzichtet werden, die überprüfen, ob bei einer Zertifizierungsstelle alle Sicherheitsanforderungen bedacht wurden. Nur so kann gewährleistet werden, dass eine
elektronische Unterschrift auch eine gewisse Beweiskraft hat. Aus diesem Grund sieht das
SigG eine freiwillige Prüfung (Akkreditierung) von Zertifizierungsstellen durch die zuständige
Behörde vor (SigG §15). Eine solche Akkreditierung umfasst neben einer Prüfung, ob das
Sicherheitskonzept bestimmten Voraussetzungen des SigG genügt auch eine Prüfung, ob alle
Vorschriften des Gesetzes entsprechend umgesetzt wurden.
3.9.3
Exportbeschränkungen der USA
Zu den Zeiten des kalten Krieges wurde Kryptographie von der US-amerikanischen Regierung
als Kriegsmaterial eingestuft und entsprechend starken Exportbestimmungen unterworfen. Da
Verschlüsselung damals fast ausschließlich in Militär- und Geheimdienstkreisen verwendet
wurde, stellte man militärisch verwendbare Verschlüsselungsgeräte und -Software auf eine
Stufe mit Waffen bzw. Munition und verbot deren Export. Erst in den 90er Jahren, als das
Internet immer populärer und Verschlüsselungsprodukte Massenware wurden, lockerte die
US-Regierung die Exportrestriktionen. US-Firmen wie Netscape und Microsoft erhielten die
Erlaubnis, Verschlüsselung mit bis zu 40 Bit Schlüssellänge für symmetrische Schlüssel zu
exportieren. Mitte der 90er Jahre wurden dann die Exportbeschränkungen von einem US-amerikanischen Gericht als teilweise verfassungswidrig erklärt. Kurz darauf wurde schließlich der
Export von Kryptographie mit 56 Bit Schlüssellänge erlaubt7.
1997 wurde dann die Ausfuhr von symmetrischer Kryptographie mit 128 Bit Schlüssellänge
erlaubt - allerdings nur an ausländische Finanzinstitute für die Verschlüsselung von Finanzdaten (beispielsweise bei der Übertragung von Kreditkarteninformationen).
7. Die Exportbeschränkungen galten schon damals nicht für die Ausfuhr von Büchern mit gedrucktem
Quellcode „free speech“. 1997 konnte auf diese Weise der Quellcode von PGP in Form eines Buches
exportiert werden - dieser musste anschließend für die internationale Version nur noch eingescannt und
neu compiliert werden.
54
Da die Verwendung von Kryptographie in den USA selbst nicht beschränkt wird, bieten Netscape und Microsoft ihre Webbrowser seitdem in zwei unterschiedlichen Versionen an: eine
Export Version und eine sog. Domestic Version. Diese ermöglichen in Abhängigkeit von dem
ihnen präsentierten Server-Zertifikat unterschiedliche Verschlüsselungsstärken. Die Kommunikation mit Browsern der Domestic Version konnte somit 128 Bit verschlüsselt werden, während Browser in der Export Version auf 40 oder 56 Bit Schlüssellänge beschränkt waren. Um
die zur Verschlüsselung von Finanzdaten erlaubten 128 Bit auch mit einer Export Version zu
erzwingen, wird für Server von Finanzinstituten ein besonderes - meist teuer angebotenes Zertifikat benötigt [TcTrust01], das bei Microsoft unter der Bezeichnung Server Gated Cryptography (SGC) bekannt ist, aber auch als Global Server ID oder Step Up Certificate bezeichnet
wird.
Seitdem wurde starke Kryptographie auch nicht mehr als Kriegsmaterial, sondern als DualUse Produkt angesehen. Dual-Use Produkte können sowohl für den militärischen, alsauch für
den zivilen Gebrauch eingesetzt werden. Deren Export an „bedenkliche“ Staaten wird durch
Ausfuhrlisten des Wassenaar-Abkommens [Wassenaar00] vom Dezember 1998 geregelt.
Da Standardsoftware wie Webbrowser oder Textverarbeitungsprogramme häufig aus den USA
kommen, zeigte die US-amerikanische Exportpolitik gerade auch in Deutschland lange Jahre
Wirkung. Ein Großteil der heute noch in Deutschland eingesetzten Standardsoftware ist mit
minderwertiger Verschlüsselungstechnologie ausgestattet.
Anfang des Jahres 2000 hat die US-amerikanische Regierung die Beschränkungen für den
Export von Verschlüsselungs-Produkten zumindest in die Mitgliedsstaaten der europäischen
Union praktisch abgeschafft. Die Exportbeschränkungen entfallen nun bei Produkten mit
schwacher Verschlüsselung (d. h. 56-Bit symmetrisch und 512-Bit asymmetrisch) sowie bei
Produkten mit starker Verschlüsselung die für den Massenmarkt bestimmt sind. Ob eine Hardoder Software nun als Produkt für den Massenmarkt gilt, entscheidet das US-amerikanische
Ausfuhramt (Bureau of Export Administration, kurz BXA) [CSH00]. Zeitgleich bekam Kryptographie den dafür neu geschaffenen Status als Krypto-Handelsware (Retail encryption commodities and software).
Neben der EU gilt die neue Regelung auch für die Schweiz, Norwegen, Ungarn, Tschechien
und Polen sowie Japan, Australien und Neuseeland [UlBantle00]. Ausgenommen von diesen
Exporterleichterungen bleiben aber weiterhin Kuba, Iran, Irak, Libyen, Nordkorea, Sudan und
Syrien sowie Serbien und Teile von Afghanistan.
3.10 Zusammenfassung
Dieses Kapitel berichtete über die Bestandteile einer Public Key Infrastruktur, der Notwendigkeit von Zertifikaten sowie den Basisdiensten von Trustcentern. Public Key Infrastrukturen
bieten Dienste zur Gewährleistung von Authentizität, Integrität und Vertraulichkeit für die
Übertragung sicherheitsrelevanter oder personenbezogener Daten über offene Netze. Grundlage dieser Sicherheitsinfrastruktur stellen öffentliche Schlüssel und Zertifikate dar. Ein Zertifikat enthält den öffentlichen Schlüssel, der von einer CA beglaubigt sowie digital signiert ist
und ermöglicht so den öffentlichen Schlüssel auf zuverlässige Weise einer Person zuzuordnen.
Trustcenter sind vergleichbar mit einer Ausweisbehörde und Zertifikate entsprechen einem
elektronischen Identitätsnachweis. Zertifikate sind ähnlich wie Ausweise der realen Welt nur
befristet gültig und können vor Ablauf ihrer Gültigkeit widerrufen werden, wenn z. B. der Verdacht auf Kompromittierung des privaten Schlüssels besteht.
55
Ein Schlüsselwiederherstellungsmechanismus ermöglicht den Zugriff auf verschlüsselte
Dokumente auch dann, wenn der zur Entschlüsselung notwendige Schlüssel verloren gegangen ist.
Kryptographische Verfahren auf Public Key Basis wie SSL, S/MIME oder IPSec ermöglichen
den Aufbau sicherer Verbindungen über den TCP/IP Protokoll Stack. SSL als Protokollschicht
oberhalb von TCP bewirkt eine Ende-zu-Ende (end-to-end) Sicherheit zwischen Anwendungsprogrammen, IPSec hingegen als Erweiterung des IP Protokolls eine Verbindungs-zu-Verbindungs (link-to-link) Sicherheit. Dokumentenbasierte Sicherheit auf Basis von Verschlüsselung
und digitaler Signatur bietet S/MIME.
Zu Schluss liefert dieses Kapitel einen Einblick in die rechtlichen Aspekte einer Public Key
Infrastruktur. Es werden Auswirkungen des SigG auf den Betrieb einer PKI besprochen sowie
die z. T. noch existierenden Einschränkungen der US-amerikanischen Exportkontrolle für
starke Kryptographie.
56
Kapitel 4
Bedarfsanalyse
Ziel dieser Diplomarbeit ist es, ein einheitliches Sicherheitskonzept für die Allgemeine Deutsche Direktbank AG (DiBa) zu entwickeln, das mobilen Mitarbeitern eine geschützte Kommunikation, die sichere Abfrage von Intranetinhalten sowie Fernadministration des Firmen-LANs
über das Internet ermöglicht.
In diesem Kapitel soll nun der konkrete Bedarf der DiBa in diesem Bereich ermittelt und
anschließend ein geeignetes Sicherheitskonzept auf Basis einer Public Key Infrastruktur (PKI)
aufgestellt werden.
4.1
Ermittlung des Ist-Zustandes
Um den Bedarf des Kunden an einem neuen Sicherheitskonzept zu klären, ist zu erst eine
Bestandsaufnahme notwendig. Dazu gehören neben der Definition einer Zielgruppe auch die
Analyse des bisherigen Sicherheitskonzeptes sowie eine Ermittlung der Hard- und Softwarebasis. Die konkrete Ermittlung des Bedarfs ist Thema des nächsten Abschnittes.
4.1.1
Unternehmensstruktur DiBa
Die Allgemeine Deutsche Direktbank AG ist durch Beteiligung der niederländischen INGGroup ein international tätiges Unternehmen. Die ING-Group gehört zu den größten Finanzinstituten Europas und ist mit einem Anteil von 49 Prozent Mitgesellschafter der DiBa1. Dazu
gehören weltweit verteilte Niederlassungen. Die DiBa selbst unterhält Niederlassungen an
zwei Standorten in Frankfurt und Hannover. Regelmäßig stattfindende Meetings mit Mitarbeitern und Partnern der ING ergeben die Notwendigkeit, Teile des Intranets sowie die interne
Kommunikation für mobile Mitarbeiter weltweit zu öffnen.
4.1.2
Zielgruppe
Die Zielgruppe für ein neues Sicherheitskonzept kann grob in drei Klassen (sog. Benutzergrup1. Zwischenzeitlich haben sich die Mehrheitsverhältnisse dahin gehend verändert, dass die ING-Group ab
1.1.2002 einen 51% Anteil der DiBa übernimmt und somit Hauptgesellschafter der DiBa wird.
57
pen) eingeteilt werden, jeweils mit unterschiedlichen zu gewährenden Zugriffsrechten:

Brokerage Administratoren
Diese Gruppe von Administratoren benötigt Zugriff auf die DMZ (entmilitarisierte
Zone) mit Applikationen wie Telnet-Clients zur Administration von UNIX Servern
oder FTP-Clients zum Up- und Download von Daten.
In Abbildung 21 sind diese als externe Brokerage Administratoren gekennzeichnet.

LAN Administratoren
Diese Gruppe von Administratoren benötigt Zugriff auf das LAN mit Applikationen wie PC Anywhere zur Administration der Windows-PCs, oder FTP-Clients
zum Up- und Download von Daten.
Hinzu kommt die Notwendigkeit zur Verwaltung von Benutzern, die komplett über
Formulare auf dem Intranet-Webserver erledigt werden kann. Daher benötigt diese
Gruppe Vollzugriff auf Webseiten des Intranets und natürlich Zugriff auf die
interne Email-Kommunikation.
In der Abbildung sind diese als mobile Mitarbeiter gekennzeichnet.

Exklusive Benutzer
Zu den exklusiven Benutzern zählen VIPs wie der DiBa Vorstand etc. Diese benötigen auf Geschäftsreisen im Ausland Zugriff auf die interne Email-Kommunikation sowie (eingeschränkten) Zugriff auf den Intranet-Webserver.
In der Abbildung sind diese ebenfalls als mobile Mitarbeiter gekennzeichnet.
Weitere Mitarbeiter der DiBa, wie z. B. normale Hotlinemitarbeiter oder Online-Broker müssen in einem neuen Sicherheitskonzept nicht berücksichtigt werden. Diese benötigen weder
administrativen Zugang vom Heimarbeitsplatz aus aufs interne Netzwerk, noch sind sie während Geschäftsreisen auf ihre persönliche Emailkorrespondenz angewiesen.
Mobile Mitarbeiter können in drei Gruppen unterteilt werden, wie Abbildung 21 zeigt. Nationale Mitarbeiter sind mobil in Deutschland unterwegs und haben Zugriff auf einen Euro-ISDN
Telefonzugang. Zu den Kontinentalen zählen jene Mitarbeiter, die in Teilen Europas unterwegs
sind, in denen der Telefonzugang über Euro-ISDN nicht möglich ist. Dazu gehören auch Mitarbeiter, denen innerhalb Deutschlands nur analoge Zugänge zur Verfügung stehen. Die dritte
Gruppe bilden Mitarbeiter, welche rund um die Welt (international) mobil sein müssen. Diese
benötigen immer eine Zugangsmöglichkeit, welche möglichst unabhängig von irgendwelchen
Telefonstandards ist.
4.1.3
Hard- und Softwareinfrastruktur
Wie Abbildung 21 zeigt, ist die Internetanbindung beider Standorte über Frankfurt geregelt.
Wobei die Hannoveraner über eine Standleitung nach Frankfurt geroutet werden und von dort
ins Internet gelangen. Das LAN der DiBa wird durch eine zweistufige, redundant ausgelegte
Firewall gegen unbefugte Zugriffe aus dem Internet gesichert.
Die DiBa Webseite (www.diba.de), welche u. a. Zugang zum Online-Brokerage bietet, wird
bei einem externen Dienstleister gehostet. Das eigentliche Brokerage-System befindet sich im
Unternehmensnetzwerk der DiBa, zwischen der ersten und zweiten Stufe der Firewall in der
DMZ. Mail- sowie Webserver für das Intranet befinden sich momentan im LAN der DiBa,
58
Kapitel 4: Bedarfsanalyse
außerhalb der DMZ, abgesichert durch die zweistufige Firewallkonstruktion.
Mobiler Mitarbeiter
Mobiler Mitarbeiter
Mobiler Mitarbeiter
(national)
(kontinental)
(international)
Internet
Externer
Brokerage Administrator
Hoster für DiBa
Internetauftritt
DiBa Standort Frankfurt
DiBa Standort Hannover
Firewalls
DMZ
Client
Client
Client
Online Brokerage
LAN
LAN
Standleitung
Client
Client
MailServer
WWWServer (Intranet)
Client
Client
Client
Abbildung 21 Unternehmensstruktur der Allgemeinen Deutschen Direktbank AG
Momentan basiert das Netzwerk auf einer MS Windows NT 4.0 Domäne. Serverseitig werden
Produkte wie MS Exchange 5.5 Server und MS Internet Information Server 4.0 eingesetzt, um
Mail- und Informationsdienste zu bedienen. Eine Migration auf eine MS Windows 2000
Domäne ist für das Jahr 2002 geplant. Wobei die Serverprodukte dann auf den jeweils neuesten
Stand mitgezogen werden sollen, d. h. Exchange 2000 sowie IIS 5. Allerdings ist dieser
Umstieg schon für einen Teil der Clientrechner, insbesondere die mobiler Mitarbeiter, vollzogen worden, d. h. diese wurden schon auf Windows 2000 Professional umgestellt.
4.1.4
Sicherheitskonzept
Das bisher eingesetzte Konzept zur Anbindung mobiler Mitarbeiter basiert auf zwei unterschiedlichen Lösungen. Sicheren Zugang zur persönlichen elektronischen Kommunikation
ermöglicht die Software Outlook Web Access (OWA) von Microsoft. Diese bietet Zugriff auf
Exchange Server über normale Webbrowser. Um administrative Aufgaben erledigen zu können, steht den LAN- und Brokerage-Administratoren zusätzlich ein Remote Access Server zur
Verfügung, der diesen uneingeschränkten Zugang zum DiBa-Netzwerk ermöglicht.
Momentan werden für beide Lösungen weder die Dienste digitaler Signaturen zum elektronischen Unterschreiben von Dokumenten noch Zertifikate zur sicheren Authentifikation von
Mitarbeitern genutzt.
59
Zugang zum LAN (Intranet und Fernadministration)
Der Zugang mobiler Mitarbeiter zum LAN der Allgemeinen Deutschen Direktbank AG wird
derzeit mithilfe eines Remote Access Servers (RAS) auf ISDN-Basis bereitgestellt. Dabei wird
die Rückruffunktionalität des Einwahlservers genutzt, wobei die Beschränkung auf bestimmte,
konfigurierbare Rückrufnummern als Basis für die Sicherheit eingesetzt wird. Die Rückrufnummer bildet somit eine rudimentäre Authentifikationsmöglichkeit, wobei davon ausgegangen wird, dass ausschließlich der verbindungswillige Mitarbeiter unter dieser Rückrufnummer
erreichbar ist.
Neben dem augenscheinlichen Vorteil, dass Informationen nicht über die Leitungen eines offenen Netzes transportiert werden und dadurch nur mit erheblichem Aufwand abgehört oder verfälscht werden können, hat dieses Verfahren allerdings erhebliche Nachteile für mobile
Mitarbeiter wie Administratoren gleichermaßen. Die Nachteile lassen sich auf zwei Eigenschaften des Einwahlservers zurückführen, die eigentlich dessen Vorteil ausmachen:

Die Rückruffunktionalität ist auf Euro-ISDN-Telefonzugänge beschränkt.
Diese Eigenschaft ist oft ungeeignet für mobile Mitarbeiter, welche sich auf
Geschäftsreisen häufig im europäischen Ausland aufhalten. Ein ISDN Telefonanschluss ist in vielen europäischen Ländern entweder gar nicht vorhanden oder
inkompatibel zum deutschen Standard. International-mobile Mitarbeiter werden
damit sogar ganz ausgeschlossen.

Die feste Rückrufnummer des Mitarbeiters muss bekannt sein.
Diese Eigenschaft ist relativ unkomfortabel für mobile Mitarbeiter, da eine Rückrufmöglichkeit entweder gar nicht existiert (bei der Einwahl mittels Laptop und
Handy), oder erst sehr kurzfristig ermittelt werden kann (bei einem Aufenthalt im
Hotelzimmer oder Konferenzraum).
Diese Art des LAN-Zuganges ist quasi nur für Mitarbeiter mit festen Heimarbeitsplätzen in
Deutschland sinnvoll einsetzbar, da diese üblicherweise über einen ISDN Zugang mit dauerhafter Rückrufnummer verfügen, die fest im RAS eingestellt werden kann.
Elektronischer Nachrichtenverkehr (Email)
Im diesem Bereich wird derzeit eine Outlook Web Access (OWA) 5.5 basierende Lösung von
Microsoft eingesetzt. Die neben der Emailfunktionalität auch Outlooks Eigenschaften als
Workgroup-Client berücksichtigt. OWA bietet eine Alternative zum standardmäßig bei der
DiBa eingesetzten, vollständigen Outlook-Client, in dem es u. a. die Funktionen des Postfachs,
der Kontakteverwaltung, des Kalenders sowie der öffentlichen Ordner über dynamische Webseiten bereitstellt.
OWA 5.5 basiert auf einer Exchange Server 5.5 und Internet Information Server (IIS) 4.0
Lösung. Clients können über einen normalen Webbrowser mittels des HTTP Protokolls auf
dynamisch generierte HTML Seiten auf den IIS zugreifen. Dieser wiederum kommuniziert mit
dem Exchange Server über ASP. Als Authentifizierungs- und Verschlüsselungsmethode wird
momentan eine Kombination aus SSL (mit dem Server-Zertifikat einer bekannten großen Zertifizierungsstelle) und der Standardauthentifizierung mittels Passwort eingesetzt.
60
Ziel war es, die von Outlook im LAN bereitgestellten Möglichkeiten des Emailpostfachs, der
Kontakte, des Kalenders usw. mobilen Mitarbeitern bereitzustellen. Die Lösung des Problems
über OWA war nicht nur schnell verfügbar, sie eignet sich auch für sämtliche (auch die international-mobilen) Mitarbeiter sowie zur Verwendung in Netzwerken mit hohen Latenzzeiten
[MS00-8].
Nachteilig an diesem Konzept ist hauptsächlich der gegenüber dem vollständigen Outlook eingeschränkte Bedienkomfort. Zum einen ist zum Verfassen einer einfachen Email eine durchgehende Online-Verbindung notwendig, denn OWA stellt keinerlei Offline-Funktionen zur
Verfügung. Zum anderen sind die Kontakte in der Version 5.5 nur sehr rudimentär implementiert, sie dienen ausschließlich dazu, Emails an einen Kontakt zu senden - Telefon oder Adressinformationen werden nicht angezeigt. Dokumentenbasierte Verschlüsselung oder Signaturen
sind mit OWA nicht möglich.
4.2
Ermittlung des Bedarfs
Ein Sicherheitskonzept für den Intranet- und Mailzugriff mobiler Mitarbeiter sowie die Fernadministration sollte möglichst einheitlich für alle Gruppen von Mitarbeitern ausgelegt werden, sodass unabhängig vom jeweiligen Aufenthaltsort über eine gemeinsame Strategie
Zugang gewährleistet wird. Der bisherige Remote Access Zugang über ISDN-Einwahlserver
soll aus diesem Grund von einem Zugang über das Internet abgelöst werden. Auf diesem Weg
soll die Notwendigkeit, mobile Mitarbeiter in standortabhängige Gruppen einzuteilen, entfallen.
Die Anforderungen an ein solches Konzept umfassen eine einfache, zentrale Administration
der Sicherheitsinfrastruktur. Weiterhin sollte das eingesetzte Sicherheitskonzept in der Lage
sein, mit künftigen Anforderungen an die Sicherheit zu wachsen, d. h. möglichst um neue
Komponenten erweiterbar sein. Falls sich eingesetzte Verfahren nachträglich als unsicher
erweisen, sollte es möglich sein, diese reibungslos, d. h. ohne großen Aufwand gegen Neue
Sichere auszutauschen.
Hinzu kommt, dass bestimmte Teile des Konzeptes in kurzer Zeit realisierbar sein müssen. Auf
Grund eines begrenzten Budgets sollen möglichst bereits vorhandene Technologien angepasst
oder wenn nötig ausschließlich Kostenfreie zusätzlich eingesetzt werden.
Die Realisierung des Konzeptes kann in mehreren Phasen geschehen. In einer ersten Phase
sollte der Intranetzugang realisiert werden. Mailzugriff, sowie Fernadministration können,
soweit notwendig, in späteren Phasen eingeführt werden.
4.2.1
Sicherer Intranetzugang für mobile Mitarbeiter
Für den Zugriff aufs Intranet müssen die Authentizität von Benutzern sowie die Vertraulichkeit
übertragener Informationen sichergestellt sein. Die dazu notwendigen Zugriffsbeschränkungen
für bestimmte Benutzergruppen erfolgen nach der erfolgreichen Authentifizierung an Hand
einer schon existierenden, unternehmensweit zuständigen Benutzerdatenbank. Je nach Zugehörigkeit zu einer bestimmten Benutzergruppe stehen dem Mitarbeiter einer oder mehrere der
folgenden Intranet-Dienste auf einem Internet Information Server 4.0 von Microsoft zur Verfü-
61
gung:
Intranet-Dienst
LAN
Admins
Exklusive
Benutzer
Brokerage
Admins
9
9
Zentrale Datenbank für Benutzermanagement
9
Aktuelle Unternehmensnachrichten
9
Benutzerhandbücher, Dokumentationen
9
Terminüberwachung
9
9
Workflow
9
9
Interne Informationen / vertrauliche Konditionen
9
9
Interne Anträge (Urlaubsanträge usw.)
9
9
Schwarzes Brett (Stellenausschreibungen etc.)
9
9
Mitarbeiterforum (Chat)
9
9
9
Tabelle 10 Zuordnung von Intranet-Diensten und Benutzergruppen
4.2.2
Sichere Kommunikation mobiler Mitarbeiter
Die Sicherstellung der Authentizität von Benutzern sowie die Authentizität, Integrität und
optional auch die Vertraulichkeit aller elektronischen Nachrichten, welche an mobile Mitarbeiter versendet werden, muss gewährleistet sein.
Authentizität und Integrität übertragener Nachrichten
Von mobilen Mitarbeitern erstellte und an mobile Mitarbeiter gesendete elektronische Dokumente sollen gegen unbemerkte Veränderungen (Ö Integrität) geschützt werden.
Weiterhin muss sichergestellt sein, dass die mobil erstellten Dokumente auch wirklich vom
angegebenen Mitarbeiter stammen (Ö Authentizität). D. h. Dokumente müssen eindeutig
ihrem Urheber zugeordnet werden können. In diesem Zusammenhang soll auch das elektronische Unterzeichnen von Dokumenten (beispielsweise wichtigen Verträgen) ermöglicht werden.
Vertraulichkeit übertragener Nachrichten
Vertraulichkeit bei der Übertragung elektronischer Kommunikation über Leitungen unsicherer
Netze wie das Internet muss gewährleistet sein. D. h. außerhalb des DiBa-Netzwerkes darf nur
der gewünschte Nachrichtenempfänger die übertragenen elektronischen Dokumente lesen können.
62
4.2.3
Fernadministration des LANs
Eine sichere Administrationsmöglichkeit des LANs über Anwendungen wie Telnet- und FTPClients sowie PCAnywhere soll gewährleistet sein. Dazu sollte es möglich sein, die Zugriffsberechtigungen der Mitarbeiter beliebig einzuschränken, abhängig von der Autorisierung der
jeweiligen Benutzergruppe. D. h. es muss möglich sein, über Filter bestimmten Mitarbeitern
beispielsweise Zugriff auf die DMZ zu gewährleisten, anderen jedoch nur den Zugriff aufs
LAN.
Grundanforderung einer Administrationsmöglichkeit ist die Gewährleistung einer sichereren
Authentifizierung der Administratoren sowie die vertrauliche Übertragung der Verbindungsdaten.
4.3
Konzept
An Hand der Anforderungen wurde ein Konzept entwickelt, bei dem Einzelaspekte in mehreren Varianten ausgewählt werden können. In diesem Abschnitt wird zu aller erst ein Überblick
über das Gesamtkonzept gegeben und danach die Frage gestellt, ob es sinnvoll erscheint, die
Ausführung des Konzeptes an einen externen Dienstleister zu übergeben, oder beispielsweise
eine eigene Public Key Infrastruktur selbst aufzubauen. Danach folgt die eigentliche Vorstellung der Teilkonzepte und Varianten.
4.3.1
Überblick über das Konzept
Die grundsätzlichen Anforderungen an ein neues Sicherheitskonzept bestehen darin, zwischen
dem LAN der DiBa und mobilen Mitarbeitern übermittelte elektronische Dokumente und
Daten sicher zu schützen. Dabei soll insbesondere die Vertraulichkeit, Integrität und Authentizität der Dokumente und Daten bei der Übermittlung sichergestellt sein.
Um diese Sicherheitsanforderungen zu erfüllen, wird eine Public Key Infrastruktur (PKI) aufgebaut, innerhalb derer ausgewählten Mitarbeitern und Servern elektronische Sicherheitsdienste zur Verfügung gestellt werden. Alle an dieser Infrastruktur teilnehmenden Mitarbeiter
bekommen eigene digitale Schlüsselpaare ausgehändigt, die sie für bestimmte Sicherungszwecke verwenden müssen. Dazu wird eine Zertifizierungsstelle eingerichtet, welche Server
und Mitarbeiter zertifiziert (d. h. deren Schlüssel beglaubigt) und somit für das Vertrauen in
deren Authentizität verantwortlich ist. Die zertifizierten digitalen Schlüssel werden dazu verwendet, digitale Signaturen auszustellen sowie Dokumente und den Datenverkehr zwischen
Clients und Servern zu verschlüsseln.
Die folgenden Abschnitte beschäftigen sich damit, welche Sicherheitsmechanismen mithilfe
kryptographischer Schlüssel im Einzelnen realisiert werden.
4.3.2
Outsourcen oder Do-it-yourself?
Zu erst soll noch die Frage geklärt werden, ob es sich lohnt eine solche Public Key Infrastruktur selbst aufzubauen, oder einen entsprechenden Auftrag an externe Dienstleister zu vergeben.
Dabei sollte bedacht werden, dass es sich bei einer PKI um eine kritische Anwendung in
Bezug auf Vertraulichkeit und Verfügbarkeit handelt.
63

Vertraulichkeit
Die beim Registrierungsprozess anfallenden vertraulichen Daten sollten meist
nicht in die Hände Dritter gelangen. Dies ist aber notwendig, wenn ein externer
Dienstleister die Ausstellung von Zertifikaten übernimmt. Zudem sollte man im
Hinterkopf behalten, dass ein solcher Zertifikatsaussteller in der Lage ist, sich
selbst (unbefugt) gültige Zertifikate auszustellen, um so widerrechtlich an geheime
Informationen zu gelangen.

Verfügbarkeit
Eine sichere Archivierung von Widerrufslisten und Verschlüsselungsschlüsseln
muss dauerhaft gewährleistet sein. Es besteht die Gefahr, dass ein Dienstleister
(aus Liquiditätsgründen, o. Ä.) seinen Dienst einstellt. In solch einem Fall wird es
u. U. schwierig an die archivierten Daten zu gelangen.
Weitere Gründe dieser und anderer Art liefert Moses in [TMoses97].
Letztendlich muss auch die Kostenfrage bei einer solchen Entscheidung berücksichtigt werden. Einige ältere Studien wie [IMachef98]2 gehen für die Outsource-Lösung bei einer Basis
von 5000 Nutzern in einem Zeitraum von 5 Jahren von Kosten zwischen 21 und 26 US-Dollar
pro Nutzer und Jahr aus. Wobei sich die Kosten pro Nutzer und Jahr bei einer Vervierfachung
der Nutzerzahl mehr als halbieren. Man kann davon ausgehen, dass bei einer entsprechend
kleineren Nutzerbasis, wie sie bei der DiBa angepeilt wird, die Kosten pro Nutzer und Jahr entsprechend (weitaus) höher ausfallen würden.
In Anbetracht dieser Tatsachen fiel die Entscheidung für einen Aufbau der Public Key Infrastruktur im Do-it-yourself-Verfahren relativ schnell.
4.3.3
Voraussetzungen
Beim Einsatz kryptographischer Standards wie SSL (bzw. TLS), S/MIME oder IPSec wird
vorausgesetzt, dass ausschließlich Versionen eingesetzt werden, die nicht durch die Gesetzgebung künstlich in ihrer Sicherheit beschränkt wurden. Mindestvoraussetzung für den Einsatz
symmetrischer Verschlüsselung sind kryptographische Schlüssel mit einer Länge von mindestens 128 Bit, wie sie auch vom Bundesamt für Sicherheit in der Informationstechnik (BSI)
empfohlen werden. Server-Software wird derart konfiguriert, dass ein Verbindungsaufbau von
Client-Software mit unzureichender Schlüssellänge verhindert wird.
4.3.4
Sicherer Intranetzugang für mobile Mitarbeiter
Authentifizierung und Vertraulichkeit
Die Vertraulichkeit von Intranetinhalten wird mittels Secure Socket Layer (SSL) und X.509v3Server-Zertifikaten gewährleistet, wobei die Daten ausschließlich verschlüsselt übertragen
werden. Siehe Abbildung 22.
2. Die Studie vergleicht die Kosten für digitale Zertifikate der PKI-Anbieter Verisign und Entrust in verschiedenen Szenarien, wie Benutzerauthentifikation mit Webbrowsern, sichere Email und Dateiverschlüsselung über einen Zeitraum von fünf Jahren.
64
Zusätzlich werden auf Seite der Benutzer X.509v3-Client-Zertifikate eingesetzt, um eine
sichere Benutzerauthentifizierung zu ermöglichen. Nur authentifizierte und autorisierte Benutzer bekommen Zugang zu einzelnen oder allen Angeboten des Intranets. Durch den Einsatz der
X.509v3-Client-Zertifikate entfällt die Notwendigkeit einer Passworteingabe.
HTTPS (HTTP über SSL)
Verschlüsselte Verbindung
IIS 4
Webbrowser
Authentifikation durch
Serverzertifikat
Clientzertifikate
Abbildung 22 Zugang zum Intranet über SSL
Diese Lösung kann für alle Benutzergruppen uneingeschränkt eingesetzt werden.
4.3.5
Fernadministration des LANs
Vertraulichkeit und Integrität von Datenkommunikation über das Internet soll mittels Verschlüsselung auf Routing-Ebene durch ein VPN (virtuelles privates Netzwerk) gewährleistet
werden, sofern nicht alle verwendeten Administrationswerkzeuge eine Ende-zu-Ende-Sicherung ermöglichen.
Zur Realisierung des VPNs wird der verbreitete Standard IPSec unter dem Betriebssystem
Windows 2000 verwendet. Dieses kann sowohl als VPN-Client als auch als VPN-Server
genutzt werden, um einen sicheren Tunnel zwischen zwei Rechnern über eine unsichere Leitung wie das Internet zu ermöglichen. Die zu verwendenden Softwareprodukte müssen somit
keine eigene kryptographische Sicherheit bieten und werden dennoch sicher (d. h. unter Wahrung von Integrität und Vertraulichkeit) über diesen sicheren Tunnel vom mobilen Rechner ins
LAN (und zurück) transportiert.
Virtuelles privates Netzwerk (VPN)
Windows
2000 Server
Serverzertifikat
Windows
2000 Client
Beliebige Anwendungen wie
PC Anywhere, VNC, Telnet
oder FTP usw...
Clientzertifikate
Abbildung 23 Fernadministration über ein VPN
65
Zur sicheren Authentifizierung von Mitarbeitern als autorisierte VPN-Clients werden
X.509v3-Client-Zertifikate sowie auf Seite des VPN-Servers X.509v3-Server-Zertifikate verwendet.
Für die Verwendung von IPSec als in Windows integrierter VPN-Lösung ist der Einsatz
zumindest eines Windows 2000 Servers3 im LAN und Windows 2000 als Betriebssystem auf
allen mobilen Clients notwendig. Vom Einsatz der in Windows NT 4.0 verwendeten proprietären VPN-Lösung auf Basis des microsoftschen PPTP Protokolls wird abgeraten. PPTP enthält
einen Designfehler im verwendeten Authentifizierungsprotokoll MS-CHAP. Dieser vereinfacht
es Angreifern mittels einer Brute-Force-Attacke das verwendete Verschlüsselungspasswort zu
berechnen ([PeSiering01] und [JoEisinger01]) und somit die Verbindung abzuhören.
4.3.6
Sichere Kommunikation
Da der Bereich sichere Kommunikation die Nutzung von besonderen Exchange Diensten
umfasst, kann hier nicht auf eine Standardlösung zurückgegriffen werden, wie sie für die anderen Bereiche vorhanden ist. Deshalb wurden drei z. T. recht unterschiedliche Konzepte entwickelt, welche bei Bedarf gegeneinander ausgetauscht werden können. Jedes dieser Konzepte
hat seine Vor- und Nachteile bezüglich Geschwindigkeit, Komfort und Funktionalität. Es
wurde darauf geachtet, dass trotz dieser Unterschiede, sämtliche Konzepte die gestellten
Anforderungen bezüglich der Sicherheit erfüllen.
Konzept A
Die bisher verwendete Lösung mittels Outlook Web Access (OWA) wird weiterhin eingesetzt
und um die Möglichkeit der sicheren Benutzerauthentifizierung über X.509v3-Client-Zertifikate erweitert. Die Notwendigkeit einer Passworteingabe entfällt damit. Sobald die Migration
des DiBa Netzwerkes zu einer Windows 2000 Domäne vollzogen ist, wird OWA entsprechend
auf die in Exchange 2000 enthaltene Version upgedated.
HTTPS (HTTP über SSL)
Exchange 5.5
Server
IIS 4 für OWA
Serverzertifikat
Webbrowser
Clientzertifikate
Abbildung 24 Kommunikations-Konzept A
Konzept A hat den Vorteil einer schnellen und einfachen Umsetzung, da relativ wenige Änderungen vorgenommen werden müssen und dennoch eine höhere Sicherheit gewährleistet wird
als mit der bisherigen Lösung.
3. Dieser kann zu Beginn auch innerhalb einer NT 4-Domäne betrieben werden
66
Konzept B
Die bisher eingesetzte Lösung mittels Outlook Web Access (OWA) wird durch MS Outlook
2000 abgelöst. Dabei wird von der Möglichkeit Gebrauch gemacht, POP3 und SMTP Verbindungen mithilfe von SSL abzusichern (POP3 über SSL und SMTP über SSL). Abruf und Versand der Emails sind durch die eingesetzte Verschlüsselung gegen Abhören oder Verändern
geschützt.
Auf Serverseite wird ein MS Exchange 5.5 Server auf Windows NT 4 Basis und als Client MS
Outlook 2000 auf Windows 2000 Basis eingesetzt. Der zwischen Client und Server stattfindende Nachrichtenverkehr wird mittels einer SSL-Verbindung gegen Abhören geschützt. Bei
der zusätzlichen dokumentenbasierten Absicherung durch Verschlüsselung und Signatur wird
der S/MIME Standard genutzt. D. h. sowohl die dokumentenbasierende Sicherheit (siehe
Abschnitt [4.3.6.1]) als auch die Client-Server Kommunikation verwenden Zertifikate nach
dem offenen X.509v3 Standard.
POP3 über SSL
Verschlüsselte Verbindungen
SMTP über SSL
Exchange 5.5
Server
Serverzertifikat
Outlook 2000
Clientzertifikate
Abbildung 25 Kommunikations-Konzept B
Der Nachteil dieser Lösung gegenüber Konzept A und C ist, dass die Nutzung weiterer
Exchange Dienste wie zentrale, servergespeicherte Mailverwaltung, Kontakte, Kalender, usw.
auf diese Weise nicht möglich ist. Diese Dienste müssen dann gegebenenfalls manuell offline
synchronisiert werden.
Konzept C
Die bisher eingesetzte Lösung mittels Outlook Web Access wird durch MS Outlook 2000
abgelöst. Auf Serverseite wird ein Windows 2000 Server und als Client Windows 2000 Professional von Microsoft eingesetzt. Das in Abschnitt [4.2.3] beschriebene virtuelle private Netzwerk (VPN)4 wird dazu benutzt, den zwischen Client und Server stattfindenden
Nachrichtenverkehr mittels Verschlüsselung gegen Abhören und Verfälschen zu schützen.
Zusätzlich wird eine dokumentenbasierte Absicherung mittels Verschlüsselung und Signaturen
wie in Abschnitt [4.3.6.1] beschrieben eingesetzt. Vorteil: Über eine solche VPN Verbindung
4. Die Infrastruktur einer VPN Verbindung zur Fernadministration (siehe Abschnitt 4.3.5) eignet sich für
beliebige Anwendungen, somit können sämtliche Funktionen von Outlook (auch die Workgroup-Funktionen) genutzt werden.
67
kann Outlook in voller Funktionalität verwendet werden.
Virtuelles privates Netzwerk (VPN)
Exchange
2000 Server
Serverzertifikat
Outlook 2000
Clientzertifikate
Abbildung 26 Kommunikations-Konzept C
Auswahl
Die Konzepte B und C haben einige gemeinsame Punkte, welche im Abschnitt dokumentenbasierte Sicherheit beschreiben werden.
Es wird eine Kombination aus Konzept A und C favorisiert. In einer ersten Ausbaustufe wird
Konzept A für alle Benutzergruppen realisiert. Der Umstieg auf Konzept C erfolgt in einer
späteren Phase, gemeinsam mit der Umstellung des DiBa Netzwerkes von Windows NT 4 auf
Windows 2000. Der Umstieg auf Konzept C wird nur für die Benutzer der Gruppen Brokerage
Administratoren sowie LAN Administratoren vorgenommen. Für Benutzer der Gruppe exklusive Benutzer ist der Umstieg nicht notwendig. Deren Zugang wird zu diesem Zeitpunkt lediglich auf die in Exchange 2000 enthaltene Version von OWA umgestellt.
4.3.6.1 Dokumentenbasierte Sicherheit
Authentizität und Integrität übertragener Nachrichten
Von mobilen Mitarbeitern erstellte Email-Nachrichten werden mit einer digitalen Signatur
nach dem verbreiteten S/MIME Standard, wie in Abschnitt [2.4] beschrieben, versehen. Diese
verhindert unbemerkte Veränderungen am Dokument (Ö Integrität) und stellt sicher, dass das
Dokument auch wirklich vom angegebenen Mitarbeiter stammt (Ö Authentizität). Auf dieser
Basis können Dokumente eindeutig ihrem Urheber zugeordnet werden, was u. a. auch das
elektronische Unterzeichnen von wichtigen Verträgen ermöglicht. Digitale Signaturen werden
mithilfe von X.509v3-Client-Zertifikaten von mobilen Mitarbeitern erzeugt und können von
allen Mitarbeitern verifiziert werden, auch dann, wenn diese selbst nicht zertifiziert sind.
Vertraulichkeit übertragener Nachrichten
Vertraulichkeit bei der Übertragung von Nachrichten wird durch Verschlüsselung einzelner,
ausgewählter Nachrichten (S/MIME) erzielt. Die Verschlüsselung basiert auf dem in X.509v3Client-Zertifikaten enthaltenen öffentlichen Schlüssel des Nachrichtenempfängers. Damit wird
gewährleistet, dass nur der gewünschte Nachrichtenempfänger diese lesen kann (Ö Vertrau-
68
lichkeit). Verschlüsselung einzelner Nachrichten wird bei der DiBa nur in Ausnahmefällen eingesetzt, falls Nachrichten DiBa-intern vor Mitarbeitern geschützt werden müssen. Möglich ist
der Einsatz von dokumentenbasierter Verschlüsselung in Outlook zudem nur, wenn sowohl
Sender, als auch Empfänger einer Nachricht zur Gruppe zertifizierter Personen gehört. D. h.
beide Kommunikationspartner müssen eigene Schlüsselpaare besitzen und über ein entsprechendes Zertifikat verfügen.5
4.3.7
Anforderungen an die Hardware
Der bereits vorhandene Webserver sowie das neu einzurichtende VPN-Gateway müssen nun
auch auf Anfragen außerhalb des DiBa-LANs antworten. Deshalb gilt es zu überlegen, beide
Server in die DMZ aufzunehmen. Aufgrund des redundant ausgelegten Firewallkonzeptes
müssten die beiden Server entweder ebenso redundant gehalten oder sehr kompliziert an die
Firewalls angebunden werden. Mit Rücksicht auf den daraus resultierenden Installationsaufwand, sowie die damit verbundenen Kosten und nicht zuletzt zur Vorbeugung eines Engpasses
im Bereich der inneren Firewalls6 wurde darauf zunächst verzichtet. Der Serverumzug kann
bei Bedarf in einer späteren Phase nachgezogen werden.
4.4
Weitere Möglichkeiten
In Abschnitt [4.2] wird gefordert, die Sicherheitskomponenten sowohl erweiter- als auch austauschbar zu planen. Die Erweiterbarkeit des Sicherheitskonzeptes bezieht sich auf die Erhöhung des Sicherheitsstandards und ist sowohl durch den Einsatz von Chipkarten (sog.
Smartcards) möglich als auch durch die Erhöhung der gewählten Schlüssellängen oder den
Austausch der verwendeten Algorithmen:
Schlüssellängen
Die Sicherheit von kryptographischen Verfahren hängt u. a. von der gewählten Schlüssellänge
ab. Die in diesem Sicherheitskonzept eingesetzten Verfahren und Schlüssellängen sind so
gewählt, dass sie nach dem derzeitigen Stand der Technik als sicher gelten. Sollten eingesetzte
Schlüssellängen in Zukunft nicht mehr als ausreichend sicher gelten oder wird ein höherer
Sicherheitsstandard gewünscht, besteht die Möglichkeit, vom Einsatz höherer Schlüssellängen
Gebrauch zu machen.
Smartcards
Das Sicherheitskonzept, wie es für die erste Phase geplant ist, sieht keine Realisierung kryptographischer Operationen in Hardware vor. Sämtliche Funktionen wie Schlüsselgenerierung,
Ver- und Entschlüsselung, digitale Signatur sowie Authentifikationsmechanismen werden ausschließlich in Form von Anwendungssoftware auf Server- und Clientrechnern ausgeführt.
Dazu notwendige Schlüsseldaten werden direkt auf der Festplatte des jeweiligen Rechners
gespeichert und sind entsprechend schwach gegen Angriffe geschützt.
Die Sicherheit ließe sich durch den Einsatz von Smartcards erheblich erhöhen. Diese Karten
enthalten den privaten Schlüssel und führen Signatur- und Entschlüsselungs-Operationen
direkt auf der Karte aus, sodass der private Schlüssel die Karte niemals verlässt.
5. Dies ist eine Eigenschaft von Microsoft Outlook 2000.
6. Die Hauptlast der Anfragen an den Webserver erfolgt weiterhin vom LAN aus.
69
Austauschbarkeit von Algorithmen
Ein Austausch von Sicherheitskomponenten wird notwendig, falls eingesetzte Verfahren in
Zukunft unsicher werden sollten und selbst die Erhöhung der Schlüssellängen keine ausreichende Sicherheit mehr gewährleisten kann. In diesem Fall lassen sich bei den gewählten Verfahren zur Absicherung der Sicherheitskomponenten (SSL, S/MIME sowie IPSec) die
eingesetzten Algorithmen zur Verschlüsselung problemlos durch andere ersetzen. Lösungen
für digitale Signaturen (in Form von sog. multiplen digitalen Signaturen [HartMase00]) und
verschlüsselten Dokumenten (in Form einer sog. Mehrfachverschlüsselung) sind bei der PKISoftware FlexiTrust in Planung und werden zu einem späteren Zeitpunkt nutzbar sein.
4.5
Zusammenfassung
In diesem Kapitel wurde ein Sicherheitskonzept auf Basis einer Public Key Infrastruktur entworfen, das mobilen Mitarbeitern der DiBa eine geschützte Kommunikation, die sichere
Abfrage von Intranetinhalten sowie die Fernadministration des Firmen-LANs über das Internet
erlaubt. Zwischen dem LAN der DiBa und mobilen Mitarbeitern übermittelte elektronische
Daten sowie Dokumente werden je nach Anwendungsfall entweder mit SSL, S/MIME oder
IPSec geschützt. Für das Schlüsselmanagement der dazu notwenigen kryptographischen
Schlüssel und die Zertifizierung von Benutzern und Unternehmensrechnern wird eine eigene
Public Key Infrastruktur innerhalb der DiBa aufgebaut.
70
Kapitel 5
Untersuchung vorhandener Software auf
Möglichkeiten zur Integration
Im vorangegangenen Kapitel wurde ermittelt, welchen Bedarf die Allgemeine Deutsche
Direktbank AG im Bezug auf ein Sicherheitskonzept für mobile Mitarbeiter besitzt. Aus diesem Bedarf heraus wurde ein Konzept für den Aufbau und Einsatz einer eigenen Public Key
Infrastruktur entwickelt.
Im nächsten Schritt muss nun die einzusetzende Software auf ihre kryptographische Eignung
hinsichtlich einer Verwendung in der Public Key Infrastruktur untersucht werden. Dazu werden die verschiedenen Programme für den server- sowie clientseitigen Einsatz und ihre kryptographischen Möglichkeiten betrachtet.
Aus wirtschaftlichen Gründen erhält dabei die weitere Verwendung bereits im Unternehmen
eingesetzter Software den Vorzug gegenüber der Anschaffung neuer.
5.1
Aufbau der Testumgebung
Für die ausführliche Untersuchung der einzusetzenden Softwareprodukte war es nötig, in einer
Testumgebung die derzeitige Softwareinfrastruktur der DiBa möglichst detailgetreu nachzubauen. Die ausgewählten Produkte wurden auf Basis des Sicherheitskonzeptes auf ihre Leistungsfähigkeit untersucht und sowohl auf Interoperabilität untereinander als auch auf
Handhabbarkeit getestet. Im Folgenden wird beschrieben, welche Software dabei zum Einsatz
gekommen ist.
Software für die Zertifizierungsstelle
Eine Software für Zertifizierungsstellen wie FlexiTrust 2.0 von FlexSecure wird bei der DiBa
derzeit noch nicht eingesetzt. Die Möglichkeiten dieser Software werden in der Testumgebung
unter dem Betriebssystem Windows 2000 Professional betrachtet. Siehe Abschnitt [5.2.3].
Um der weiten Verbreitung von Network Associates PGP Rechnung zu tragen, wird parallel
dazu eine Installation dieser Software vorgenommen. Siehe Abschnitt [5.2.1]
71
Anfangs war geplant, ausschließlich zur Zertifizierung des Internet Information Servers 4.0
einen Certificate Server 1.0 von Microsoft unter Windows NT 4 einzusetzen (siehe Abschnitt
[5.2.2]), da FlexiTrust zu Beginn dieser Arbeit nicht in der Lage war, die vom IIS selbst erstellten Schlüsselpaare zu zertifizieren. Rechzeitig vor Fertigstellung dieser Diplomarbeit wurde
dieses Feature allerdings noch in FlexiTrust 2.0 eingebaut. Eine Installation des - bei der DiBa
derzeit ohnehin nicht verwendeten - Certificate Servers ist für den Realbetrieb nun nicht mehr
nötig.
Software für Server (WWW, Mail, LDAP, VPN-Gateway)
Für die Bereitstellung der Intranet-Dienste wird von der DiBa derzeit ein Internet Information
Server 4.0 von Microsoft unter dem Betriebssystem Windows NT 4.0 Server betrieben. Die
Möglichkeiten in Bezug auf dessen weitere Verwendbarkeit werden in der Testumgebung
untersucht. Siehe Abschnitt [5.3.1].
Für die Bereitstellung von Diensten für den elektronischen Nachrichtenverkehr wird von der
DiBa momentan ein Exchange Server 5.5 von Microsoft unter Windows NT 4.0 Server betrieben. Auch in die Testumgebung wird solch ein Server integriert. Da allerdings sämtliche für
den Betrieb einer PKI relevanten Funktionen in der dazugehörigen Clientsoftware enthalten
sind, beschränkt sich die Untersuchung der Serversoftware auf die in Exchange Server 5.5
integrierte Komponente Outlook Web Access 5.5. Siehe Abschnitt [5.3.2].
Beim Umfang der momentanen Nutzerbasis ist der Betrieb eines LDAP-Verzeichnisservers
nicht unbedingt erforderlich, zumal die Installation von Benutzerzertifikaten in der DiBa meist
von Administratoren durchgeführt wird. Hinzu kommt, dass in der momentan vorliegenden
Version 2.0 von FlexiTrust die Unterstützung von LDAP-Servern nicht aktiviert ist und daher
derzeit keine Verwendung findet. Für die zukünftige Erweiterung auf eine größere Nutzerbasis
bietet sich allerdings der Einsatz eines OpenLDAP-Servers in der Version 2.0 unter S.u.S.E.
Linux 7.2 Professional auf X86 an, wie er in der Testumgebung bereits praktisch erprobt
wurde. Die Beschreibung der OpenLDAP-Installation der Testumgebung in Abschnitt [5.3.3]
beschränkt sich auf eine kurze Zusammenfassung.
Alternativ kann dazu auch auf die Möglichkeiten des Active Directory von Microsoft zurückgegriffen werden, das in seiner Eigenschaft als Verzeichnis ebenfalls per LDAP ansprechbar
ist.
Für den Betrieb des VPN-Gateways sollen in Zukunft die Möglichkeiten des Windows 2000
Server-Betriebssystems von Microsoft genutzt werden. Allerdings sind von FlexiTrust ausgestellte IPSec-Zertifikate derzeit noch nicht mit Windows 2000 kompatibel. Auf eine praktische
Untersuchung in der Testumgebung musste daher verzichtet werden. Eine eher theoretische
Betrachtung der Fähigkeiten findet sich allerdings in Abschnitt [5.3.4].
Software für Clients (WWW, Mail)
Der Internet Explorer 5.5 von Microsoft wird momentan von der DiBa als Webbrowser u. a.
zum Zugriff aufs Intranet verwendet (unter Windows 2000 Professional und Windows NT
4.0). Siehe Abschnitt [5.4.1].
Aufgrund einiger Schwächen, insbesondere im Bereich der Verwaltung von Widerrufslisten,
wird parallel dazu die Software Navigator 7.x von Netscape unter Windows 2000, Windows
72
Kapitel 5: Untersuchung vorhandener Software auf Möglichkeiten zur Integration
NT 4.0 und S.u.S.E. Linux 7.2 betrachtet (siehe Abschnitt [5.4.2]).
Als Email-Client und Workgroup-Lösung wird von der DiBa Outlook 2000 von Microsoft
unter Windows 2000 Professional und Windows NT 4.0 eingesetzt (siehe Abschnitt [5.4.3]). In
diesem Zusammenhang ist es interessant, wie verschlüsselte oder signierte Dateien, beim
Empfänger außerhalb der DiBa mit alternativen Emailprogrammen verarbeitet werden können.
Aus diesem Grund wird zusätzlich Netscapes Messenger 7.x untersucht (siehe Abschnitt
[5.4.2]).
A
A
Windows
Windows 2000
2000 WKS
WKS
B
B
Windows
Windows NT
NT 44 Server
Server
Server
S.u.S.E
S.u.S.E Linux
Linux 7.2
7.2 Prof.
Prof.
EE
Windows
Windows 2000
2000 WKS
WKS
FF
Windows
Windows 2000
2000 Server
Server
Active
Active Directory
Directory (LDAP)
(LDAP)
Netscape
Netscape Communicator
Communicator 7.8
7.8
Outlook
Outlook 2000
2000
LDAP
LDAP Browser\Editor
Browser\Editor 2.8.2
2.8.2
Internet
Internet Explorer
Explorer 5.5
5.5
Server
Server
OpenLDAP
OpenLDAP 2.0
2.0
Exchange
Exchange Server
Server 5.5
5.5
PKI
D
D
MS
MS Certification
Certification Server
Server
Windows
Windows NT
NT 44 Server
Server
Clients
Internet
Internet Explorer
Explorer 5.5
5.5
Netscape
Netscape Navigator
Navigator 7.8
7.8
Netscape
Netscape Messenger
Messenger 7.8
7.8
Outlook
Outlook 2000
2000
LDAP
LDAP Browser\Editor
2.8.2
PGP
PGP 7.0.3
7.0.3
PKI
FlexiTRUST
FlexiTRUST 22 (CA,
(CA, RA,
RA, IS)
IS)
Server
Internet
Internet Information
Information Server
Server 44
C
C
LDAP
LDAP Browser\Editor
2.8.2
Clients
Clients
Clients
Abbildung 27 Aufbau der Testumgebung
Abbildung 27 liefert einen Überblick über die Konfiguration der Hard- und Software, wie sie
in der Testumgebung aufgebaut wurde. Die einzelnen Testrechner sind durchnummeriert von A
bis F und mit dem jeweils installierten Betriebssystem gekennzeichnet. Die darauf installierte
Software wurde in drei Gruppen eingeteilt: Server, PKI (enthält Software für Zertifizierungsstellen) und Clients. Pfeile kennzeichnen Softwareprodukte, die einer Interoperabilitäts-Untersuchung unterworfen wurden. Bsp.: ein Pfeil ausgehend von der mit Internet Explorer 5.5 (IE)
bezeichneten Software auf Testrechner A zur Software Internet Information Server 4 (IIS) auf
Testrechner B bedeutet, dass der IE 5.5 unter Windows 2000 im Zusammenspiel mit dem IIS 4
unter Windows NT 4 getestet wurde. Auf Pfeile, welche die Beziehungen der Gruppe PKI
symbolisieren, wurde aus Gründen der Übersichtlichkeit verzichtet.
5.2
Software für Zertifizierungsstellen
In diesem Abschnitt werden die Softwarepakete für den Aufbau und Betrieb der Zertifizierungsstelle, Network Associates PGP, Microsoft Certificate Server und FlexSecure FlexiTrust
73
betrachtet.
5.2.1
PGP
Während der Entwurfsphase der Zertifizierungsstrategie wurde ich von einigen Mitarbeitern
der DiBa darauf angesprochen, dass PGP der etablierte Standard für elektronische Nachrichtenkommunikation sei. Darauf hin entstand die Überlegung, der weiten Verbreitung von PGP
Rechnung zu tragen und die bei einigen Mitarbeitern evtl. vorhandenen PGP-Benutzerschlüssel in die Zertifizierungs-Infrastruktur zu übernehmen. Im weiteren Verlauf dieses Abschnittes
folgen eine Abwägung der Vor- und Nachteile sowie der Grund weshalb PGP dann schließlich
doch nicht in das Zertifizierungskonzept aufgenommen wurde.
Geschichte
Die von Phil Zimmermann entwickelte Verschlüsselungssoftware Pretty Good Privacy (PGP)
entstand vor knapp zehn Jahren, als in der New York Times ein Gesetzesvorschlag für ein USamerikanisches Antiterrorgesetz veröffentlicht wurde. Dieser Vorschlag sah vor, dass alle
Anbieter von sicheren Kommunikationsdiensten eine Hintertür einbauen müssten, die der USRegierung den unverschlüsselten Zugriff auf die übertragenen Informationen ermöglichen
sollte. Die US-Regierung hatte damals wohl hauptsächlich kriminelle Gruppierungen als Zielgruppe von Kryptographiesoftware in Verdacht. Stattdessen fand PGP anfangs aber bei einer
gänzlich anderen Benutzergruppe viel mehr Beachtung: Menschenrechtsaktivisten aus nichtwestlichen Staaten wie Osteuropa oder Mittelamerika [RaBend01], die sich, mithilfe der Verschlüsselung ihrer Kommunikation untereinander, vor der Verfolgung durch die Regierung
schützen konnten.
Das erwähnte Antiterrorgesetz wurde zwar nie verabschiedet, dennoch geriet PGP oder besser
gesagt sein Entwickler mit dem US-Gesetz in Konflikt: Für die amerikanische Exportkontrollgesetzgebung galt starke Kryptographie als Kriegswaffe. Jemand der Kryptographiesoftware
aus den USA exportieren wollte, wurde daher so behandelt, als wollte er Waffen exportieren.
Mehr dazu in Kapitel [3.9.3].
Dennoch oder vielleicht gerade deshalb, hat PGP heute den größten Anteil unter den für die
zur Internet-Mail-Kommunikation eingesetzten Lösungen. Phil Zimmermann selbst beschreibt
die Situation so: „Wenn man sich die Internetbevölkerung als Kuchengrafik vorstellt, dann
nutzt nur ein kleiner Teil davon Verschlüsselung. Die Menschen in diesem kleinen Tortenstück
sind aber fast alle Nutzer von PGP.“ [RaBend01].
Mittlerweile entwickelt sich PGP zu einem Industriestandard für Email-Verschlüsselung. Das
auf PGPv5 basierende OpenPGP wurde als IETF-Standard vorgeschlagen [RFC2440].
Zertifikate
Der vielleicht grundlegendste Unterschied zwischen PGP und den nachfolgend besprochenen
Lösungen für Zertifizierungsstellen sind die zwei verschiedenen Standards für das Format der
Public Key Zertifikate (die nicht zueinander kompatibel sind). Während X.509v3 auf vertrauenswürdigen dritten Stellen zur Bestätigung der Authentizität des Schlüssels eines Zertifikatnehmers basiert (Kapitel [3.5.3]), baut PGP auf das Prinzip des Web of Trust aus Kapitel
[3.5.2].
74
Widerruf von Zertifikaten
Die in Abschnitt [3.4.2] vorgestellte Methode, widerrufene Zertifikate auf einer Widerrufsliste
zu veröffentlichen und damit bekannt zu geben, welche Zertifikate ungültig sind, wird von
PGP nicht unterstützt. D. h. PGP kennt kein solches Konzept, entsprechend gibt es auch keinerlei standardisiertes Format oder eine verbreitete automatische Abfragemöglichkeit für PGPClients, auf entsprechende Listen zuzugreifen. Versuche eine Widerrufsliste in eine Zertifizierungshierarchie zu integrieren scheitern meist am Aufwand den Benutzer dabei erbringen müssen:
1.
Web- oder FTP-Server einer CA nach einer PGP-Widerrufsliste durchsuchen.
2.
Widerrufsliste von Hand herunterladen.
3.
Integrität und Authentizität der Widerrufsliste prüfen
4.
Widerrufsliste auf enthaltene Rückrufe von Zertifikaten prüfen, die man selbst
besitzt.
5.
Zertifikat-Rückrufe berücksichtigen, d. h. von Hand die vorhandenen Zertifikate
als ungültig markieren.
Zur Erinnerung: für Zertifikate, welche dem X.509v3-Standard entsprechen, erledigt ein Webbrowser (oder Mailclient usw.) diesen Vorgang im Zusammenspiel mit Verzeichnissen quasi
vollautomatisch, da im X.509-Format von Anfang an Widerrufslisten vorgesehen waren. Jede
Software, die X.509-Unterstützung bietet muss mit diesen Listen umgehen können. Da selbst
das Format der Widerrufslisten standardisiert ist, konnten sich auch nicht derart unterschiedliche, individuelle Sperrlisten-Formate entwickeln, wie das bei PGP leider der Fall ist.
PGP bietet stattdessen zwei weniger mächtige Möglichkeiten herausgegebene Zertifikate zu
widerrufen. Da ist zum einen das Zertifikat-Widerrufszertifikat zu nennen. Neuere Versionen
von PGP „verstehen“ derartige Zertifikatwiderrufe und erlauben es dem Unterzeichner, eine
Signatur unter einem PGP Schlüssel nachträglich für ungültig zu erklären. Was einer Sperrung
des Zertifikates gleich kommt. Die zweite Möglichkeit sind sog. Schlüssel-Widerrufszertifikate. Jeder Benutzer erzeugt dazu vor der Zertifizierung ein selbst signiertes Zertifikat zum
Widerruf seines öffentlichen Schlüssels, das im Falle eines Missbrauches entsprechend von
ihm selbst veröffentlicht werden muss. Wird PGP in einer hierarchischen Struktur im Zusammenhang mit CAs benutzt, werden die Schlüssel-Widerrufszertifikate üblicherweise zusammen mit dem ursprünglichen Schlüsselzertifikat bei der CA gespeichert bzw. veröffentlicht.
PGP Zertifikate können i. M. also nicht hundertprozentig sicher (vollständig) widerrufen werden. Mit Widerrufszertifikaten besteht aber die Möglichkeit, Zertifikate im Falle des Widerrufs
über Keyserver oder über eigens eingerichtete Mailinglisten zu verteilen, um die Ungültigkeit
des eigenen öffentlichen Schlüssels anzukündigen. Besser ist der Ansatz, welcher in [KuSp99]
verfolgt wird, PGP-Zertifikate über X.500 Verzeichnisse zur Verfügung zu stellen.
Sicherheitslücke im Schlüsselformat von PGP und OpenPGP
Vor allem die Verbreitung von PGP spricht eigentlich für eine Aufnahme von PGP-Zertifikaten
75
in die Public Key Infrastruktur neben X.509v3. Allerdings wurde während dieser Diplomarbeit
eine gravierende Sicherheitslücke von PGP offenbart, die diesen Gedanken schnell wieder verwarf.
Das Sicherheitsproblem betrifft das von OpenPGP (also auch von PGP 7.0.3 und vom GNU
Privacy Guard) verwendete Format zur sicheren Speicherung privater Signaturschlüssel. Diese
werden verschlüsselt (mit AES, CAST5 oder IDEA) in einem sog. Keyring auf der Festplatte
oder einem anderen Datenträger des Benutzers abgelegt und sind erst nach Eingabe einer Passphrase für die jeweiligen PGP-Anwendungen lesbar. Allerdings werden einige der in der
Schlüsseldatei enthaltenen Informationen nicht ausreichend auf Integrität geprüft, sodass die
Möglichkeit besteht, einige Bytes des Keyrings derart zu verändern, dass darin enthaltene,
manipulierte private Schlüssel nachher weiterhin als gültig betrachtet werden. Durch eine
geschickte Manipulation gelingt es Angreifern, aus Emails, die mit einem solchen veränderten
Schlüssel signiert wurden, den privaten Schlüssel zu extrahieren.
Vlastimil Klima und Tomas Rosa beschreiben in [KlimaRosa01] den Angriff auf derart gespeicherte DSA- und RSA- Signaturschlüssel und liefern entsprechende Gegenmaßnahmen.
5.2.2
Microsoft Certificate Server 1.0
Der Microsoft Certificate Server 1.0 ist ein Zusatzprodukt für den Microsoft Internet Information Server 4.0 (IIS) auf Windows NT 4 Basis. Die Trustcenter Fähigkeiten beschränken sich
auf Erzeugung und Verteilung von Zertifikaten.
Der Certificate Server bearbeitet Zertifizierungsanforderungen vom IIS automatisiert über eine
Schnittstelle, über die es den öffentlichen Schlüssel vom IIS empfängt und das erteilte ServerZertifikat wieder zurücksendet. Über das Webinterface aus Abbildung 28 (links) können Zertifizierungsanfragen mithilfe eines herkömmlichen Formulars auf HTML-Basis an den Certificate Server übermittelt werden. Dieser generiert auf Wunsch notwendige Schlüsselpaare selbst
und zertifiziert diese anschließend.
Zertifikate
Folgende für den geplanten Einsatz relevante Zertifikatsformate werden unterstützt:

X.509v1 und X.509v3, Client-Zertifikate für SSL

X.509v3, Server-Zertifikate für SSL

X.509v3, S/MIME Zertifikate
Kryptographische Algorithmen
Die Schlüsselgenerierung kann wie schon erwähnt auch vom Certificate Server übernommen
werden, dabei stehen folgende kryptographische Algorithmen (Cryptographic Service Provider, CSP genannt) zur Verfügung:

Microsoft Base Cryptographic Provider
Entspricht dem RSA Algorithmus mit einer Schlüssellänge von 512 Bit und
76
demonstriert die Einschränkungen früherer Export-Versionen.

Microsoft Enhanced Cryptographic Provider
Entspricht dem RSA Algorithmus mit einer Schlüssellänge von 1024 Bit und bietet
damit eine nach heutigen Verhältnissen ausreichende Sicherheit.

Microsoft Strong Cryptographic Provider
Entspricht zumindest in der deutschen Version von Windows NT4 mit High
Encryption Pack dem RSA Algorithmus mit einer Schlüssellänge von 512 Bit. Der
Name „Strong Cryptographic“ lässt aber vermuten, dass bei Erreichen bestimmter
(exportbedingter) Vorgaben größere Schlüssellängen generiert werden können, wie
beispielsweise 2048 oder 4096 Bits.

Gemplus GemSAFE Card CSP v1.0
Dient der Unterstützung von Smartcards.

Schlumberger Cryptographic Service Provider
Dient der Unterstützung von Smartcards.
Abbildung 28 Zertifikatsanforderung über das Webinterface des Certificate Servers 1.0
Konfiguration
Abbildung 28 (rechts) zeigt, wie der Zertifizierungsprozess über spezielle Einstellungen beeinflusst werden kann. Neben den schon weiter oben genannten, obligatorischen Einstellungen
zum verwendeten Zertifikatsformat und dem kryptographischen Algorithmus nebst Schlüssellänge, erlaubt der Certificate Server weiteres Feintuning. Unter Algorithm versteckt sich der
zur Zertifikatssignierung verwendete Hash-Algorithmus (SHA-1, MD2 oder MD5). Die Einstellung Allow Keys to be Exported ermöglicht es, das generierte Zertifikat zusammen mit dem
privaten Schlüssel in einer PKCS#12 Datei über die Microsoft Management Console (MMS)
oder den Internet Explorer zu exportieren. Dies ist notwendig, um die lokal gespeicherten
77
Schlüsselpaare inkl. der zugehörigen Zertifikate manuell zum gewünschten Zielrechner zu
transportieren. Ohne diese Einstellung sind private Schlüssel fest an den Rechner gebunden,
von dem aus das Webinterface aufgerufen wurde - es lassen sich nur noch die Zertifikate (inkl.
der öffentlichen Schlüssel) exportieren. Use Existing Key Set ermöglicht die Zertifizierung von
anderweitig erstellten Schlüsseln, d. h. bei dieser Einstellung erzeugt der Certificate Server
kein neues Schlüsselpaar. In Verbindung mit Chipkarten ist Write Certifcate to CSP nützlich.
Die Zertifikate werden dann zusätzlich noch direkt auf die Karte geschrieben.
Üblicherweise wird die Zertifizierungsanfrage im Webbrowser auf dem Zielrechner selbst ausgeführt. Dies hat den Vorteil, dass generierte Zertifikate automatisch im lokalen Internet
Explorer registriert werden, d. h. sofort zur Verfügung stehen und nicht erst vom Administrator
umständlich von Hand installiert werden müssen. Alternativ kann die Zertifizierungsanfrage
auch von einem zentralen Rechner aus erfolgen, dann ist es allerdings erforderlich, die Zertifikate nachträglich zu exportieren und manuell zum Zielrechner zu übertragen.
Folgende Testumgebung wurde eingerichtet, in welcher der Certificate Server 1.0 erfolgreich
eingesetzt werden konnte: Windows NT 4 Server, Service Pack 6a, Windows NT 4 Option
Pack, Internet Information Server 4.0, Internet Explorer 5.5, High Encryption Pack für NT 4,
Certificate Server 1.0 inkl. dem notwendigem Certificate Server 1.0 Hotfix [MS00-1] für die
Zusammenarbeit mit SP 6a und den Einsatz höherer Schlüssellängen.
5.2.3
FlexSecure FlexiTrust 2.0
FlexiTrust ist eine modular aufgebaute und skalierbare Trustcenter-Software, die vollständig in
der Programmiersprache Java implementiert und damit weitestgehend Plattform-unabhängig
ist1. Alle Sicherheitsmechanismen werden über die Java-Cryptographic-Architecture (JCA)
bereitgestellt. FlexiTrust unterstützt Rückfallmechanismen. Sollte sich eine der heute verwendeten Sicherheitstechniken oder Policies aufgrund technischer oder wissenschaftlicher Fortschritte als unsicher erweisen, müssen alle Zertifikate und digitale Schlüssel der PKI
ausgetauscht und alle Signaturen erneuert werden. FlexiTrust ist bereits heute für das abgesicherte, transparente Umschalten der verwendeten kryptographischen Basisalgorithmen
vorbereitet.
Zertifikate
Folgende für den geplanten Einsatz relevante Zertifikats- und Sperrlistenformate werden
unterstützt:

X.509v3, Client-Zertifikate für SSL

X.509v3, Server-Zertifikate für SSL

X.509v3, S/MIME Zertifikate für Verschlüsselung und/oder Signatur

X.509v1, Sperrlisten (CRLs)
1. Die Software wurde bereits auf drei Plattformen erfolgreich eingesetzt (SUN Solaris, Linux, Windows
NT / 2000).
78
Kryptographische Algorithmen
Die JCA stellt Verschlüsselungs- sowie Signaturalgorithmen nur abstrakt zur Verfügung. Welche Sicherheitstechnik wirklich verwendet wird, hängt davon ab, welchen Crypto-Provider die
JCA gerade benutzt. Unterstützt wird beispielsweise der Microsoft Cryptographic-ServiceProvider (CSP) von Windows NT 4 und Windows 2000. Die folgende Tabelle liefert einen
Überblick über die unterstützten kryptographischen Algorithmen des von FlexiTrust standardmäßig verwendeten Providers (CDC2).
Verfahren
Algorithmus
Signaturverfahren
MD5/RSA in Soft- oder Hardware, SHA1/
RSA, RipeMD160/RSA, SHA1/ECDSA, DSS
Hashverfahren
MD4, MD5, SHA1, RipeMD128, RipeMD160
Schlüsselerzeugung
RSA (beliebige Schlüssellänge), DSA (512 und
1024 Bit nach DSS), ECDSA (bis 256 Bit),
ECElGamal
Verschlüsselung (symmetrisch)
IDEA (128 Bit), Triple-DES (168 Bit)
Verschlüsselung (asymmetrisch)
ECElGamal (bis 256 Bit), RSA, ElGamal
Tabelle 11 FlexiTrust: unterstützte kryptographische Algorithmen
Überblick
FlexiTrust besteht hauptsächlich aus drei Komponenten (Abbildung 29), die sämtliche, mit der
Erzeugung und Verwaltung von digitalen Schlüsseln und Zertifikaten anfallenden, Aufgaben
übernehmen:

FlexiTrust-RA (die Registrierungseinheit)
Regelt die Abwicklung von Antragsprozessen wie die Bearbeitung von Zertifikatsoder Revokationsanträgen und übernimmt die Kommunikation mit der CA.

FlexiTrust-CA (die Zertifizierungseinheit)
Erzeugt digitale Schlüssel, X.509-Zertifikate, personalisierte Geheimnisträger
(PSE) und Sperrlisten (CRL).

FlexiTrust-IS (der Infrastruktur Service)
Übernimmt die Kommunikation mit den Benutzern, die Bereitstellung von Zertifikaten und Widerrufslisten sowie regelmäßige Aufgaben wie beispielsweise die
Rezertifizierung.
Alle Komponenten von FlexiTrust können wahlweise getrennt oder zusammen betrieben wer2. CDC ist ein Java-Crypto-Provider entwickelt an der TU-Darmstadt. Die in der Tabelle mit ECxxx
bezeichneten Algorithmen basieren auf Elyptic Curve Cryptography.
79
den. Es ist beispielsweise möglich, die FlexiTrust-CA auf einem eigens dafür vorgesehenen
und besonders gesicherten (abgeschotteten) Rechner gemäß SigG-Anforderung offline sowie
alle Module zusammen auf einem einzigen (vernetzten) Rechner zu betreiben.
Registration Authority (RA)
verwalten
beantragen
(Zertifikats- und Revokationsanträge)
Certification Authority (CA)
zustellen
pflegen
Digitale Schlüssel
Zertifikate
Geheimnisträger (PSE)
Revokationen
Infrastructure Services (IS)
(regelmäßige Aufgaben)
Abbildung 29 Der interne Aufbau von FlexiTrust 2.0
5.2.3.1 FlexiTrust-CA
Die Zertifizierungseinheit von FlexiTrust ist als verteilte Applikation implementiert und stellt
alle Funktionen einer CA bereit:

Schlüsselerzeugung
Erzeugung asymmetrischer Schlüsselpaare mit kryptographischen Verfahren wie
RSA, DSA oder elliptischen Kurven.

Zertifizierung
Zertifizierung selbst erzeugter Schlüsselpaare sowie Zertifizierung von Fremdschlüsseln.

Revokation
Widerruf von ausgestellten Zertifikaten und Erstellung notwendiger Widerrufslisten.

Schlüsselarchivierung, Schlüsselwiederherstellung
Archivierung und Wiederherstellung von privaten Schlüsseln sowie Zertifikaten.
80
Abbildung 30 Zertifikatsantragsformular der FlexiTrust-RA
5.2.3.2 FlexiTrust-RA
Die Registrierungseinheit ist das Eingangsportal von FlexiTrust: eine skalierbare Software, die
alle Funktionen einer RA bereitstellt:

Kommunikation mit den Benutzern
Registrierung von Benutzern inkl. einer Authentitätsprüfung. Sammeln und verwalteten von Zertifizierungs- und Widerrufsanträgen, Prüfung von Antragsdaten
gemäß frei definierbaren Sicherheitsrichtlinien (Policies).

Kommunikation mit der CA
Weitergabe genehmigter Anträge in Form einer im PKCS#7-Format signierten
Zertifizierungsanforderung an die CA.
Java-Servlets generieren HTML3-Eingabeformulare für Zertifikats- und Widerrufsanträge aus
3. In zukünftigen Versionen werden XML-Eingabeformulare verwendet.
81
konfigurierbaren Datenbankeinträgen (SQL, JDBC) oder aus PKCS#10-Anträgen.
Abbildung 31 Revokationsantragsformular der FlexiTrust-RA
5.2.3.3 FlexiTrust-IS
Der Infrastruktur Service bildet die Kommunikationsschnittstelle zu den PKI-Benutzern und
erledigt regelmäßig wiederkehrende Verwaltungsaufgaben:

Kommunikation mit den Benutzern
Herausgabe von Schlüsselpaaren, Zertifikaten sowie Chipkarten an die Benutzer.

Bereitstellung
Öffentliche Bereitstellung von Zertifikaten und Widerrufslisten über LDAP-Verzeichnisdienste.

Key-Backup und -Recovery
FlexiTrust-IS sorgt auf Wunsch für die Möglichkeit von Key-Recovery.
Installation in der Testumgebung
Die Installation in der Testumgebung erfolgt für alle FlexiTrust-Komponenten (CA, RA sowie
IS) gemeinsam auf einem einzigen, vernetzten, nicht gesondert geschützten Rechner unter
Windows 2000. Entgegen den Forderungen der Policy in Abschnitt [A.3.1] wird im Rahmen
dieses Tests kein dedizierter Rechner für die einzelnen Module verwendet. Ein verteiltes Starten der Module ist aber möglich und wird im Realbetrieb auch angestrebt. Der Datenaustausch
zwischen den einzelnen Modulen erfolgt in der Testumgebung über Transferdateien auf der
Festplatte des gemeinsamen Rechners.
82
5.3
Server Software
In diesem Abschnitt wird Software für Informations- Kommunikations- und Sicherheitsdienste
auf Server-Basis besprochen. Dazu gehören ein Microsoft Internet Information Server, welcher
Zugang zu Intranetdiensten wie Benutzerverwaltung, Unternehmensnachrichten und Dokumentationen bietet; ein Microsoft Exchange Server als Kommunikationsplattform für Email-,
Termin- und Kontaktverwaltung; ein OpenLDAP-Server zur Bereitstellung von Zertifikatsund Widerrufsinformationen; und nicht zuletzt ein MS Windows 2000 Server, der die Dienste
für ein Virtual Private Network (VPN) mit IPSec bereitstellt.
5.3.1
Microsoft Internet Information Server 4.0
Der Webserver Internet Information Server 4.0 (IIS) von Microsoft ist als Zusatzprodukt für
Windows NT 4.0 Server aus dem frei erhältlichen Option Pack realisiert.
CA-Zertifikate
Voraussetzung für die Verwendung von SSLv3 im Microsoft Internet Information Server 4.0
ist die Installation des CA-Zertifikates jener CA, welche den SSL-Server-Schlüssel für den IIS
signiert hat, auf dem Server. Sollen zusätzlich SSL-Clientzertifikate einer davon abweichenden
(d. h. unterschiedlichen) CA eingesetzt werden, so muss deren CA-Zertifikat ebenso auf dem
Server installiert werden, damit der IIS diese als vertrauenswürdige Instanz für Client-Zertifikate anerkennt. Die Vorgehensweise für alle CA-Zertifikate ist identisch und in Anhang [B.2]
für einen Einsatz unter Windows NT mit Service Pack 6a exemplarisch beschrieben.
SSL Server-Zertifikate
Der IIS 4 generiert seine Schlüsselpaare auf Basis des RSA Algorithmus mithilfe des in den
Server integrierten Schlüssel-Managers selbst. Wobei in der getesteten Version ausschließlich
512, 768 oder 1024 Bit Schlüssellängen möglich sind. Zur Zertifizierung der selbst erstellten
Schlüsselpaare wird eine Base64-kodierte PKCS#10 Zertifikatsanforderungsdatei (*.req) über
den Schlüssel-Manager erzeugt, die anschließend von einer separaten CA zertifiziert werden
muss. Standardmäßig ist für diesen Vorgang der Microsoft Certificate Server 1.0 vorgesehen,
es kann allerdings jede beliebige CA verwendet werden, Voraussetzung ist nur der korrekte
Umgang mit der erstellten Zertifikatsanforderungsdatei. Die von der CA erzeugten Zertifikate
können anschließend als einzelne Zertifikatsdateien (Base64-kodiert, *.crt) oder gemeinsam
mit dem CA-Zertifikat mithilfe des Schlüssel-Managers in den IIS importiert werden.
SSL Client-Zertifikate
Ein Mechanismus zur Bindung von Client-Zertifikaten an Windows NT 4 Domänenbenutzerkonten erlaubt es, Benutzer an Hand des bei der Authentifizierung vorgelegten Zertifikates
gezielt zu erkennen und ihnen automatisch Rechte auf dem Server, basierend auf ihren Windows NT Benutzerkonten, zuzuweisen. Diese Bindung stellt somit eine Beziehung zwischen
dem Inhalt des Client-Zertifikates eines Benutzers und dem entsprechenden Windows NT
Benutzerkonto her.
Folgende Möglichkeiten zur Bindung stehen dabei zur Verfügung:
83

1-zu-1
Eine Funktion zum Laden eines spezifischen Client-Zertifikates im Base-64-Format (*.cer) in den Server ermöglicht die Zuordnung zu einem Windows NT Benutzerkonto.

n-zu-1
Ähnlich wie bei der 1-zu-1 Bindung werden bei der n-zu-1 Bindung mehrere Client-Zertifikate einem einzelnen Windows NT Benutzerkonto oder einer -Gruppe
zugeordnet.

Wildcards
Bei der Bindung über Wildcards werden keine individuellen Client-Zertifikate in
den Server geladen, stattdessen können Kriterien definiert werden an Hand derer
vorgelegte Zertifikate während des Webzugriffes bestimmten Windows NT Benutzerkonten zugeordnet werden. Ebenso ist es mit dieser Bindung möglich, Zertifikate nach bestimmten Kriterien komplett abzulehnen. Mögliche Kriterien für eine
Wildcard-Bindung sind beispielsweise die im Zertifikat untergebrachten Informationen über den Zertifikatsherausgeber oder andere auf dem DN basierende Kriterien.
Ohne weitere manuelle Einstellungen prüft der IIS 4 nicht, ob vom Client übergebene Zertifikate evtl. zwischenzeitlich von der herausgebenden CA widerrufen wurden. Dieser Prüfvorgang ist nach der Installation des Servers standardmäßig abgeschaltet und muss nachträglich in
der Registry mit folgendem Schlüssel aktiviert werden:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\CheckCertRevocation = 1
Laut Microsofts Aussagen in [MS99-2] versucht der IIS 4, nachdem ein solcher (DWORD-)
Schlüssel erstellt wurde, die entsprechende CRL zu beziehen. Voraussetzung dafür ist eine korrekt in das Zertifikat eingebrachte Erweiterung vom Typ CRL Distribution Point, welche auf
die CRL auf einem HTTP- oder LDAP-Server verweist. Allerdings war es im Verlauf dieser
Arbeit nicht möglich, den IIS 4 dazu zu bewegen, gültige Zertifikate mit CRL Distribution
Point-Erweiterung anzunehmen. Unabhängig davon, ob diese nun widerrufen waren oder
nicht, wies der IIS 4 solche Zertifikate bei aktiviertem CheckCertRevocation generell als
ungültig ab4. Die vom IIS an den Webbrowser übergebene Fehlermeldung 403.7 Verboten:
Clientzertifikat erforderlich ist wenig hilfreich, da dies auch der Fehlermeldung für den Fall
entspricht, dass überhaupt keine Benutzerzertifikate vorhanden sind. Erst nach Abschalten von
CheckCertRevocation akzeptierte der IIS 4 überhaupt wieder Zertifikate (gleich welcher Art,
d. h. sowohl gültige als auch widerrufene).
Dieses Verhalten zeigt sich ebenso bei manuell installierten Widerrufslisten, daher empfiehlt es
sich, CheckCertRevocation generell auf einen Wert von 0 zu setzen. Microsoft selbst bezeichnet das CheckCertRevocation-Feature beim IIS 4 als unsupported - vermutlich eine dezente
4. Eine Recherche in der Newsgruppe microsoft.public.inetserver.iis.security zeigte, dass dieses Problem
offensichtlich weit verbreit zu sein scheint.
84
Bezeichnung für nicht funktionsfähig.
5.3.2
Microsoft Exchange Server 5.5 mit Outlook Web Access 5.5
Um mobilen Zugriff auf den Exchange Server 5.5 zu ermöglichen wird in der DiBa momentan
die Software Outlook Web Access (OWA) 5.5 von Microsoft eingesetzt. OWA ist eine in den
Exchange Server 5.5 integrierte Komponente, die nicht dazu dient, Outlook 2000 zu ersetzen.
Lediglich ein Teil von Outlooks Funktionen wird bereitstellt, mit dem Ziel die Netzwerklast
(beispielsweise beim Zugriff über VPNs hinweg) zu verringern.
Abbildung 32 Outlook Web Access für mobilen Zugriff auf Exchange Server,
dargestellt im Internet Explorer
OWA 5.5 basiert auf einer Lösung, die den Exchange Server 5.5 mit einem Internet Information Server (IIS) 4.0 verknüpft. Clients können über einen normalen Webbrowser, wie den
Internet Explorer, mittels des HTTP Protokolls auf dynamisch generierte HTML Seiten auf
den IIS zugreifen. Dieser wiederum kommuniziert mit dem Exchange Server über ASP. Unter
diesem Aspekt ist OWA eigentlich eher ein Bestandteil des IIS, als des Exchange Servers.
Die Oberfläche, die dem Benutzer auf dem Client präsentiert wird (siehe Abbildung 32), weist
große Ähnlichkeit mit der Vollversion von Outlook auf. Tatsächlich wird neben der Mailfunktionalität auch ein Teil von Outlooks Workgroup-Funktionen angeboten. Allerdings fehlen
sämtliche Möglichkeiten zur dokumentenbasierten Sicherheit wie Verschlüsselung oder digitale Signatur. Zur Absicherung der Kommunikation zwischen Clients mit Webbrowsern und
dem OWA muss daher auf die in Abschnitt [5.3.1] besprochenen Möglichkeiten des IIS
zurückgegriffen werden. Verbindungen lassen sich so per SSL verschlüsseln und der Zugriff
mittels Authentifikation durch X.509 Client-Zertifikate auf autorisierte Benutzer beschränken.
85
5.3.3
OpenLDAP 2.0
OpenLDAP 2.0 von der OpenLDAP Foundation5 ist ein freier LDAP-Verzeichnisserver für
UNIX-Plattformen (wie beispielsweise Linux), der das Lightweight Directory Access Protocol
in den Versionen 2 und 3 unterstützt. OpenLDAP 2.0 ist ausschließlich ein Verzeichnisserver,
Funktionen für den Betrieb als Gateway zu einem X.500 Verzeichnis werden nicht bereitgestellt.
Die in Abschnitt [3.8.2.4] beschriebenen Sicherheitsmodelle keine Authentifizierung, einfache
Authentifizierung und SASL werden unterstützt. Um über SASL Verbindungen mittels TLS
oder SSL abzusichern, muss allerdings zusätzlich zu OpenLDAP die Software OpenSSL
installiert werden. Eine Zugriffskontrolle erlaubt es allen Benutzern Lese- sowie Schreibrechte
zuzuweisen oder den Zugriff auf authentifizierte Benutzer sowie Benutzer, die selbst im Verzeichnis eingetragen sind, zu beschränken. Dies ermöglicht es beispielsweise, das Recht auf
schreibende Zugriffe in wählbare Bereiche des Verzeichnisses ausschließlich LDAP-Administratoren zu gewähren, während anonyme Benutzer lediglich Leserechte erhalten.
In der Testumgebung wurde OpenLDAP entsprechend seiner Linux-Verfügbarkeit auf einem
Rechner mit S.u.S.E. Linux 7.2 Professional Betriebssystem auf X86-Basis in der von S.u.S.E.
mitgelieferten Version 2.0.11 installiert. Der Aufbau eines Verzeichnisses in Vorbereitung für
die Aufnahme von Benutzerzertifikaten und Sperrlisten lief erfolgreich, wurde allerdings mangels Unterstützung seitens FlexiTrust 2.0 ausschließlich mit LDAP-Clientprogrammen wie
dem unten beschriebenen LDAP Browser\Editor, dem Netscape Communicator und weiteren
von S.u.S.E mitgelieferten Tools6 funktional getestet.
5.3.4
Microsoft Windows 2000 Server als VPN-Gateway
Das Betriebssystem Windows 2000 Server von Microsoft unterstützt mit dem Layer-2-Tunneling-Protokoll (L2TP) den IPSec Standard zum sicheren Verbinden von Systemen (i. d. R. Clients auf Windows 2000 Basis) über VPNs. Als Authentifizierungsmechanismus können drei
unterschiedliche Methoden eingesetzt werden. Neben Kerberos V5 oder vordefinierten,
gemeinsamen, geheimen Schlüsseln sind auch X.509 Zertifikate möglich. Kerberos als
Authentifizierungsmechanismus verwendet man am besten ausschließlich innerhalb geschlossener Windows-2000-Infrastrukturen, da dann keine weitere Konfiguration des Protokolls auf
Clientseite mehr erfolgen muss (zentralisierte Administration). Im heterogenen Systemumfeld
oder wenn Zugriffe von außerhalb einer Windows-2000-Domäne (beispielsweise über das
Internet) erfolgen sollen, verwendet man besser Zertifikate nach X.509 zur Authentifikation.
Zum Aufbau einer IPSec Verbindung verwendet Windows 2000 (in der Server- oder Professional-Version) den Internet Key Exchange (kurz IKE, als Implementierung von ISAKMP/Oakley, siehe Abschnitt [3.7.3.2]).
Über IPSec-Regeln lässt sich das Kommunikationsverhalten auf Benutzer- oder Rechner- (Client-) Basis, für definierte Anwendungssituationen festlegen. Die Konfiguration dieser Regeln
erfolgt bei Windows 2000 über Richtlinien, die im Active Directory abgelegt werden. Für
5. bis 1996: University of Michigan
6. Dazu zählen: Web500gw (ein Gateway das Webbrowsern den direkten Zugriff auf das LDAP-Verzeichnis ermöglicht), kldap sowie QG (KDE sowie Gnome LDAP-Clients). Sämtliche genannten Programme
sind Bestandteil der S.u.S.E Linux 7.2 Professional Distribution.
86
Rechner, die nicht Mitglied einer Windows 2000 Domäne sind, werden die IPSec-Regeln in
der lokalen Registry des Clients gespeichert. Über derartige Richtlinien lassen sich Regeln für
unterschiedliche TCP-Ports oder Tunnels zu Servern definieren und je nach Anwendungsfall
miteinander kombinieren. Als Anwendungsfälle kommen die in Abschnitt [3.7.3.3] besprochenen Verbindungstypen infrage: Peer-to-Peer, Client/Server, Gateway-to-Gateway, Client-toGateway.
Beim Einsatz von X.509-Zertifikaten zur Authentifizierung lassen sich auf Clientseite neben
Rechnern auf Basis von Windows 2000 beispielsweise auch Linux-Clients verwenden. Bei
Clients, die nicht auf Windows 2000 basieren, muss allerdings auf die zentralisierte Verwaltung der Sicherheitsrichtlinien mithilfe des Active Directories verzichtet werden. Derartige
Clients verlangen nach einer individuellen Konfiguration.
Folgende Einstellungen sind für jede festzulegende Regel möglich:

Paketfilter
Über IP-Paketfilter kann bestimmt werden, wann Pakete unverschlüsselt weitergeleitet, blockiert oder mithilfe eines wählbaren kryptographischen Verfahrens verschlüsselt werden. Konfigurierbar ist in diesem Zusammenhang, welche IPAdressen (oder IP-Subnetze) diese Filter umfassen und auf welche TCP-Protokolle
oder Portnummern die Verbindung beschränkt sein soll.

Authentifizierungsmechanismus
Über die oben erwähnten Authentifizierungsmechanismen kann gezielt festgelegt
werden, nach welcher Methode die Authentifizierung erfolgen soll, damit Verbindungen nur mit autorisierten Benutzern (oder Rechnern) aufgebaut werden.

Tunnel
Für jede einzelne Verbindung kann eingestellt werden, ob diese im Tunnel- oder
Transportmodus erfolgen soll.

Verbindungstyp
Der Verbindungstyp ermöglicht unterschiedliche Konfigurationen für LAN- oder
DFÜ-Verbindungen.
Für Rechner innerhalb einer Windows 2000 Domäne sind bereits drei (kerberosbasierende)
Richtlinien vorkonfiguriert, die allerdings standardmäßig nicht aktiv sind und entsprechend
den eigenen Bedürfnissen angepasst werden können (siehe Abbildung 33):

Client (nur Antwort)
Diese Clientregel ermöglicht eine Kommunikation im Klartext (unverschlüsselt),
falls die Gegenstelle keine Sicherheit anfordert.

Server (Sicherheit anfordern)
Eine Serverregel, die versucht eine sichere Kommunikation zum Client aufzubauen. Falls dieser IPSec nicht unterstützt, werden allerdings auch ungesicherte
Verbindungen zugelassen.

Sicherer Server (Sicherheit erforderlich)
Diese Serverregel besteht darauf, ausschließlich sichere Sitzungen zur Kommuni-
87
kation mit Clients zu verwenden. Ungesicherte Kommunikation mit nicht vertrauenswürdigen Clients wird abgewiesen. Jeder Client, der eine Verbindung zu solch
einem Server herstellen möchte, muss daher IPSec unterstützen.
Abbildung 33 Vordefinierte IPSec Richtlinien von Windows 2000
Der in Kapitel [4.2.1] geforderte sichere Intranetzugang für mobile Mitarbeiter der DiBa
umfasst neben der Authentizität von Mitarbeitern, die Vertraulichkeit der übertragenen Informationen sowie notwendige Zugriffsbeschränkungen für bestimmte Benutzergruppen nach
einer erfolgreichen Authentifizierung. Es bietet sich an, das hierfür notwendige Regelwerk auf
Basis der vordefinierten „Sicherer Server“ Regel zu entwerfen. Die beiden erstgenannten
Regeln sind hierfür offensichtlich ungeeignet, da sie u. U. auch ungesicherte Verbindungen
von nicht authentifizierten Personen zulassen würden.
5.4
Client Software
Die im vorherigen Abschnitt genannte Software für Serverdienste verlangt auf Benutzerseite
nach entsprechender Client Software. Neben den bekannten Webbrowsern von Microsoft
(Internet Explorer) und Netscape (Communicator) werden Clientprogramme für den Kommunikationsbereich (Microsoft Outlook) sowie LDAP vorgestellt. Eine Beschreibung des Windows 2000 VPN Clients von Microsoft entfällt an dieser Stelle, da diese in der in [5.3.4]
genannten Beschreibung des VPN-Gateways enthalten ist.
5.4.1
Microsoft Internet Explorer 5.x
Der Internet Explorer (IE) unterstützt in den Versionen 5.x und 6.0 die Verschlüsselung von
Webseiten bei der Übertragung mittels SSLv2, SSLv3 sowie TLS. Die Authentifikation gegenüber Servern zu Beginn einer SSL-Kommunikation erfolgt auf Wunsch mit X.509v3-ClientZertifikaten. Das im IE-Paket enthaltene Emailprogramm Outlook Express wird an dieser
Stelle nicht näher betrachtet, da für die Nachrichtenkommunikation bei der DiBa das ebenfalls
von Microsoft stammende, separat erhältliche Programm Outlook 2000 vorgezogen wird.
Die folgenden Angaben beziehen sich hauptsächlich auf die Version 5.x unter den Betriebssystemen Windows NT 4.0 SP6a sowie Windows 2000 SP2. Zu berücksichtigen ist, dass sich das
Verhalten des Browsers unter Windows NT abhängig vom installierten Servicepack (SP)
ändern kann. Eine starke Verschlüsselung für den deutschen Markt (d. h. 128 Bit symmetrisch
sowie 1024 Bit asymmetrisch) wird unter NT beispielsweise erst ab Servicepack 6a möglich.
Unter beiden Systemen (NT und 2000) ist darauf zu achten, dass der IE den High Encryption
88
Pack von Microsoft enthält. Dieser muss notfalls separat nachinstalliert werden, sonst kann
eine SSL-Verbindung nur mit 40/56 Bit Verschlüsselung abgesichert werden. Leider ist das
Verhalten des IE in einzelnen Fällen abhängig davon, ob er unter Windows NT oder Windows
2000 als Hostumgebung läuft. Dazu aber später mehr.
Zertifikate
Zertifikate können entweder direkt im IE verwaltet werden7 oder über ein Snap-In der Microsoft Management Console (kurz: MMC, siehe Abbildung 34) in Windows 2000. Beide Möglichkeiten unterscheiden zwischen eigenen Benutzerzertifikaten (eigene Zertifikate),
Zertifikaten anderer Benutzer (andere Personen), CA-Zertifikaten (Zwischenzertifizierungsstellen) sowie Root-CA-Zertifikaten (vertrauenswürdige Stammzertifizierungsstellen).
Abbildung 34 Snap-In der MMC für die Zertifikats- und CRL-Verwaltung
Der Zugriff auf die Zertifikatsverwaltung über das Snap-In der MMC bietet mehr Möglichkeiten, als ein Zugriff über den IE. Neben personengebundenen Zertifikaten (Zertifikate - Aktueller Benutzer), die nur verfügbar sind, wenn der entsprechende Benutzer lokal am Rechner
angemeldet ist, kennt die MMC auch rechnergebundene Zertifikate (Zertifikate (Lokaler Computer)), wie sie beispielsweise für SSL- oder IPSec-Server benötigt werden. Diese Unterscheidung bietet folgende Möglichkeiten. Zum einen kann jeder Benutzer selbst entscheiden,
welchen CAs er Vertrauen schenkt und welchen nicht. Zum anderen muss ein Server auch
Zugriff auf seine Zertifikatseinstellungen haben, wenn kein Benutzer (wie beispielsweise der
Administrator) angemeldet ist.
7. Erreichbar über den Menüpunkt: Extras / Internetoptionen... / Inhalt / Zertifikate.
89
Benutzerzertifikate werden im Format PKCS#12 zusammen mit dem privaten Schlüssel
importiert und können auf diesem Wege auch wieder für eine anderweitige Verwendung exportiert werden. Zusammen mit dem eigentlichen Benutzerzertifikat besteht die Möglichkeit über
PKCS#12-Dateien auch gleich Zertifikate der ausstellenden CAs zu importieren. CA-Zertifikate sowie Zertifikate anderer Benutzer können alternativ auch einzeln in den IE eingebracht
werden, in dem sie entweder über den Assistenten der Zertifikatsverwaltung manuell geladen
werden, oder ein Webserver das entsprechende Zertifikat im binär codierten DER-Format mithilfe des MIME-Types application/x-509-ca-cert zum Download anbietet.
Der Assistent für die Zertifikatsverwaltung ermöglicht über ein Kontextmenü im Windows
Explorer (Zertifikat installieren) den Import von Zertifikaten in den Formaten PKCS#12
(*.p12), PKCS#7 (*.p7b) sowie DER-codiert (*.cer; Base-64 oder Binary). Beim Import
besteht die Möglichkeit, die Zertifikate als personen- oder rechnergebunden einzuordnen. Über
das erwähnte MMC-Snap-In lassen sich die Zertifikate nachträglich noch in die jeweilige
andere Kategorie einordnen.
Sowohl die Zertifikatsverwaltung vom IE als auch das Snap-In der MMC erlauben es, installierte Zertifikate anzuzeigen (Abbildung 35), zu exportieren sowie deren Verwendungszweck
nachträglich zu modifizieren. CA-Zertifikate beispielsweise können für die Zertifizierung von
S/MIME oder SSL als vertrauenswürdig definiert oder die Beschränkungen von Benutzerzertifikaten einzeln (de-) aktiviert werden.
Abbildung 35 Informationen zu ausgewählten Zertifikaten: links allgemeine Beschreibung,
rechts Details zu den Erweiterungen
Neben dem Import von Zertifikaten verfügt der IE über eine Funktion zur Schlüsselerzeugung
mit anschließender Online-Zertifizierung. In diesem Fall erzeugt der Browser das asymmetrische Schlüsselpaar selbst.
90
Widerrufslisten
Widerrufslisten (CRLs) können, ähnlich wie Zertifikate, über ein Kontextmenü im Windows
Explorer (Zertifikatsperrliste installieren) oder über eine im Zertifikat angegebene URL8
bezogen werden. Eine Zertifikatsprüfung erfolgt erst, wenn im Menü Extras / Internetoptionen... / Erweitert die Felder Auf zurückgezogene Serverzertifikate überprüfen, bzw. Zertifikate
von Herausgebern prüfen angewählt sind.
Allerdings konnte der IE in den Versionen 5.0, 5.5 und 6.0 (mit den jeweils aktuellsten Servicepacks und Patches) nicht dazu bewegt werden unter Windows NT oder Windows 2000
widerrufene Zertifikate als ungültig zu erkennen, wenn entsprechende CRLs über das Kontextmenü des Windows Explorer eingebracht wurden. Das Format der CRLs (X.509v1) war bei
diesen Tests das Gleiche, wie das in den Abschnitten [5.4.2] für den Netscape Communicator
und [5.4.3] für Outlook 2000 verwendete. Hinzu kommt, dass Outlook 2000 wie der IE die
Zertifikatsverwaltung von Windows verwendet und somit auf dieselbe installierte CRL zugreift. Dennoch erkannte der IE zurückgerufene Zertifikate, im Gegensatz zum Netscape Communicator und Outlook 2000, weiterhin als gültig.
An dieser Stelle unterscheidet sich das Verhalten des IE unter Windows 2000 von dem unter
Windows NT. Während unter Windows 2000 keine Auswirkungen beim (de-) aktivieren der
Felder Auf zurückgezogene Serverzertifikate überprüfen, bzw. Zertifikate von Herausgebern
prüfen feststellbar sind und alle Zertifikate weiterhin gültig bleiben, sieht der IE unter Windows NT sämtliche Zertifikate, von denen keine Widerrufslisten im System eingespielt sind,
als ungültig an. Selbst die im Browser mitgelieferten CA-Zertifikate von Standard-CAs werden als unüberprüfbar moniert und damit vom IE als ungültig bezeichnet, sobald diese Felder
unter Windows NT aktiviert sind.
5.4.2
Netscape Communicator 4.7x
Der im Netscape Communicator enthaltene Webbrowser Navigator unterstützt in der frei verfügbaren Version 4.77 die Verschlüsselung von Webseiten bei der Übertragung mittels SSLv2
und SSLv3, wobei als symmetrische Verschlüsselungsalgorithmen beispielsweise RC4 mit 128
Bit oder Triple-DES mit 168 Bit Schlüssellänge verwendet werden können. Die Authentifikation gegenüber Servern zu Beginn einer SSL-Kommunikation erfolgt auf Wunsch mit
X.509v3-Client-Zertifikaten. Der im Netscape Communicator enthaltene Emailclient Messenger unterstützt S/MIME sowohl mit RC2 und 128 Bit als auch Triple-DES mit 168 Bit.
Der Netscape Communicator verwendet - wohl auf Grund seiner Verfügbarkeit für unterschiedliche Betriebssystemplattformen - nicht die Zertifikatsverwaltung von Windows. Deshalb sind schon in Windows importierte Zertifikate und CRLs nicht automatisch in Netscape
verfügbar.
Netscape bietet daher eine eigene Zertifikatsverwaltung (siehe Abbildung 36), die über das
Menü Communicator / Tools / Security Info oder über das Schlosssymbol in der Symbolleiste
erreichbar ist. Diese unterscheidet bei Zertifikaten zwischen eigenen Benutzerzertifikaten
(yours), Zertifikaten anderer Benutzer (People), Servern (Web Sites), CA-Zertifikaten (signers)
und Object-Signing-Zertifikaten (Java/JavaScript).
8. Mittels der in Abschnitt [3.3.1.2] besprochenen X.509-Standarderweiterung crl distribution points.
91
Abbildung 36 Die Zertifikatsverwaltung vom Netscape Communicator
Zertifikate allgemein
Benutzerzertifikate werden im Format PKCS#12 (*.p12) zusammen mit dem privaten Schlüssel importiert und können auf diesem Wege auch wieder für eine anderweitige Verwendung
exportiert werden. Zusammen mit dem eigentlichen Benutzerzertifikat besteht die Möglichkeit
über PKCS#12-Dateien auch gleich Zertifikate der ausstellenden CAs zu importieren. CA-Zertifikate können alternativ auch einzeln in den Netscape Communicator eingebracht werden, in
dem sie entweder über das Menü „File/Open Page“ manuell geladen werden, oder ein Webserver das entsprechende Zertifikat im binär codierten DER-Format mithilfe des MIME-Types
application/x-509-ca-cert zum Download anbietet. SSL-Server- und Object-Signing-Zertifikate werden automatisch von kontaktierten Servern zu Beginn einer Kommunikation übertragen und über einen Dialog mit dem Benutzer in die Zertifikatsverwaltung installiert.
Die Zertifikatsverwaltung vom Netscape Communicator erlaubt es, CA-Zertifikate nachträglich für die Zertifizierung von S/MIME, SSL oder Object Signing als vertrauenswürdig zu
erklären. Standardmäßig ist allerdings keiner der drei Verwendungszwecke nach dem Import
von CA-Zertifikaten gesetzt. Damit eine Überprüfung von Benutzer-Zertifikaten überhaupt
erfolgreich verlaufen kann, muss nach dem Import somit erst der entsprechende Verwendungszweck aktiviert werden. Das kann zu Problemen führen, denn mit dieser Methode können für
CA-Zertifikate auch Zwecke akzeptiert werden, den die Erweiterungen im CA-Zertifikat nicht
unterstützen. Nach [DFN00-1] wird beispielsweise eine signierte Email vom Empfänger auf
Grund eines ungültigen Zertifikates zurückgewiesen, wenn diese ein S/MIME-Zertifikat zur
Grundlage hat, dessen CA für S/MIME akzeptiert wurde, obwohl das CA-Zertifikat ursprünglich nicht für diesen Zweck vorgesehen war.
Neben dem Import von Benutzerzertifikaten verfügt der Netscape Communicator über eine
Funktion zur Schlüsselerzeugung mit anschließender Online-Zertifizierung. In diesem Fall
erzeugt der Browser das asymmetrische Schlüsselpaar selbst.
92
Benutzerzertifikate für SSL
Für SSL-Clientzertifikate sind prinzipiell sämtliche der unter yours vorhandenen Zertifikate
einsetzbar, solange diese gültig sind und die in Abschnitt [3.7.1.3] beschriebenen notwendigen
Zertifikatserweiterungen gesetzt haben. Natürlich muss die herausgebende CA neben dem Client auch dem zu kontaktierenden Server als vertrauenswürdige CA für SSL-Clientzertifikate
bekannt sein, damit dieser das Clientzertifikat überprüfen kann.
Liegen mehrere Zertifikate vor, die alle genannten Bedingungen erfüllen, bietet Netscape ein
kleines Auswahlfenster an und überlässt die Auswahl des zu verwendenden Zertifikates dem
Anwender.
Benutzerzertifikate für S/MIME
Bei Zertifikaten für S/MIME gilt Ähnliches wie für SSL-Clientzertifikate. Prinzipiell sind
sämtliche der unter yours vorhandenen Zertifikate einsetzbar, solange sie gültig sind und die in
Abschnitt [3.7.2.1] beschriebenen notwendigen Zertifikatserweiterungen gesetzt haben. Allerdings wählt der Messenger zu verwendende Zertifikate an Hand der darin enthaltenen EmailAdresse aus. Diese muss mit der aktuell im Programm eingestellten Email-Adresse übereinstimmen. Von Zertifikaten, die alle genannten Bedingungen erfüllen, können maximal zwei für
S/MIME eingesetzt werden, da der Messenger bei Bedarf zwischen Signatur- und Verschlüsselungs-Zertifikaten unterscheidet.
Widerrufslisten
Netscape unterstützt ausschließlich binär codierte CRLs nach X.509v1 im DER-Format und
keine X.509v2 CRLs. Diese lassen sich weder offline in den Browser importieren, noch ist
anfangs überhaupt etwas zur Verwaltung von Widerrufslisten in der Zertifikatsverwaltung
sichtbar. CRLs müssen daher über einen Webserver per HTTP oder HTTPS gesendet werden.
Nachdem die erste CRL über diesen Weg in Netscape registriert ist, erscheint in der Zertifikatsverwaltung unter signers eine neue Schaltfläche, über die vorhandene CRLs angezeigt
oder erneuert werden können. Anhang [B.3] gibt eine detaillierte Anleitung zur Installation
von Widerrufslisten in den Netscape Communicator.
5.4.3
Microsoft Outlook 2000
Der Personal Information Manager Microsoft Outlook 2000 ist ein Client für den Exchange
Server von Microsoft. Die darin enthaltene Mailfunktionalität unterstützt die Verschlüsselung
per S/MIME sowohl mit RC2 als auch DES sowie Triple-DES. Für digitale Signaturen stehen
MD5 und SHA-1 als Hashalgorithmen zur Verfügung. Damit diese kryptographischen Algorithmen mit starker Kryptographie an Stelle der früher üblichen 40/56 Bit Varianten arbeiten,
ist für Outlook ein Update auf die High-Encryption (128 Bit) Version notwendig.
Zertifikate
Outlook 2000 verwendet ebenso wie der bereits besprochene Internet Explorer die Zertifikatsverwaltung von Windows.
Unterstützt werden Zertifikate nach X.509v3, wobei Outlook - ebenso wie der Netscape Mes-
93
senger 7.x - auf Wunsch zwischen Signatur- und Verschlüsselungs-Zertifikaten unterscheidet.
Weitere Parallelen zeigen sich auch bei der Akzeptanz von Benutzerzertifikaten. Auch Outlook
verwendet für diesen Einsatz ausschließlich Zertifikate, die der im Programm eingestellten
Email-Adresse entsprechen. Zertifikate anderer Benutzer werden direkt den Kontakten (so die
Outlook-eigene Bezeichnung für Empfänger) zugeordnet, wobei ebenfalls die darin enthaltene
Email-Adresse Beachtung findet.
Die automatische Verbreitung des eigenen Benutzerzertifikates unterstützt Outlook durch den
optionalen Versand des Zertifikates zusammen mit jeder signierten Email. Auf diese Weise
können Empfänger ohne große Umstände die Korrektheit von Signaturen überprüfen.
Widerrufslisten
Outlook unterstützt auf Grund der mit dem IE gemeinsam verwendeten Zertifikatsverwaltung
dieselben Widerrufslistenformate wie der IE. Mehr noch, im IE installierte CRLs müssen nicht
mehr in Outlook importiert oder registriert werden, wenn dies schon für den IE geschehen ist.
Verfügbare Widerrufsinformationen werden automatisch berücksichtigt. Zertifikate, welche
von der herausgebenden CA widerrufen wurden, werden schon beim Importversuch von Outlook mit einer Fehlermeldung zurückgewiesen (siehe Abbildung 37 rechts).
Abbildung 37 Akzeptanz widerrufener Zertifikate: links Internet Explorer 5, rechts Outlook 2000
Digitale Signaturen
Vorausgesetzt, das Zertifikat der ausstellenden CA liegt dem Empfänger vor und das Benutzerzertifikat des Senders wurde wie oben beschrieben mit der Email zusammen verschickt,
wird die Signatur eingehender Emails von Outlook noch vor dem Anzeigen der Email automatisch geprüft. Abbildung 38 zeigt die Informationen, die Outlook anschließend über die Korrektheit der Signatur bereitstellt.
94
Abbildung 38 Outlook liefert Informationen über die Gültigkeit digitaler Signaturen
Verschlüsselung
Eine Besonderheit tritt beim Versand verschlüsselter Emails auf. Obwohl zum Verschlüsseln
theoretisch lediglich das Verschlüsselungs-Zertifikat des Empfängers notwendig sein sollte,
verweigert Outlook kommentarlos die Verschlüsselung von Emails, sobald der Sender kein
eigenes Verschlüsselungs-Zertifikat besitzt. Das Einstellungsfeld für Verschlüsselung (und
digitale Signatur) wird in diesem Fall überhaupt nicht erst frei geschaltet. Dieses sonderbare
Verhalten begründet sich vermutlich aus der Tatsache, dass verschlüsselte Emails nach dem
Versand zusätzlich als Kopie im Ordner gesendete Objekte verschlüsselt abgespeichert werden
sollen. Diese Kopie muss aber mit dem Verschlüsselungs-Schlüssel des Senders verschlüsselt
werden, wenn dieser sie jemals wieder lesen möchte.
Probleme
Beim Interoperabilitätstest zeigt Outlook deutliche Schwächen im Bereich digitaler Signaturen. Vom Netscape Messenger oder Outlook Express digital signierte Mails konnten nur dann
gelesen werden, wenn die eigentliche Nachricht zusätzlich als Klartext beigefügt wurde. Das
derartige Nachrichten mit einer digitalen Signatur versehen sind, ist beim Empfang durch Outlook nicht erkennbar. Vermutlich wird die von fremden Programmen erzeugte digitale Signatur
seitens Outlook auch nicht auf Gültigkeit überprüft. Von einem Outlook Client erzeugte digitale Signaturen werden dagegen in anderen Outlook Clients korrekt als solche erkannt und
behandelt.
5.4.4
LDAP Browser\Editor 2.8.2
Der LDAP Browser\Editor 2.8.2 ist ein Java-Programm9, mit dem X.509 Zertifikate in LDAPVerzeichnisdiensten gesucht und für die weitere Verwendung in einer Anwendung gespeichert
werden können. Unterstützt werden hierzu LDAPv2 und v3 Server sowie anonyme oder
9. Läuft beispielsweise unter Windows, Linux oder Mac OS X und benötigt dazu lediglich ein installiertes
Java 1.2.2.
95
authentifizierte als auch verschlüsselte Verbindungen über SSL.
Zur Suche nach Verzeichniseinträgen können Filter eingesetzt werden, wie sie in [RFC1960]
und [RFC2254] beschrieben sind. Für das Beispiel aus Abbildung 39 wurde nach Einträgen
gesucht, welche den String Musterfrau als Bestandteil des Attributs CommonName (cn) enthalten.
Abbildung 39 Suche nach Einträgen im LDAP-Baum
Als Suchergebnis erhält man standardmäßig nur den Distinguished Name (DN) gefundener
Einträge angezeigt. Über ein Kontextmenü lassen sich aber ausgewählte Einträge mit ihren
Attributen anzeigen (siehe Abbildung 40) und evtl. darin enthaltene Zertifikate lokal speichern.
Der LDAP Browser\Editor eignet sich natürlich nicht nur zum Suchen von Zertifikaten. Es
können auch neue Verzeichniseinträge angelegt sowie eigene Zertifikate im PKCS #12 Format
eingespielt werden. Eine Möglichkeit zum Importieren komplexer Verzeichnisstrukturen in
bestehende Verzeichnisbäume ermöglicht die Funktion zum LDIF-Import. Somit erfüllt der
LDAP Browser\Editor auch administrative Anforderungen.
96
Abbildung 40 Übernahme von Zertifikaten aus LDAP-Verzeichniseinträgen
5.5
Zusammenfassung
Die Erfahrungen aus dem Betrieb der Testumgebung haben gezeigt, dass es möglich ist,
zusammen mit FlexiTrust und einiger Standardsoftware wie Outlook und dem Netscape Communicator eine funktionierende Public Key Infrastruktur aufzubauen. Auch der Internet Explorer, der leichte Schwächen im Bereich der Widerrufslisten zeigt, scheint geeignet für den
Einsatz im Realbetrieb einer PKI.
Lediglich der Internet Information Server, den die DiBa momentan noch in der Version 4
betreibt, sollte mittelfristig durch einen Webserver ersetzt werden, der in der Lage ist, widerrufene Clientzertifikate als solche zu erkennen. Ob dessen Nachfolger (der IIS 5) Widerrufslisten
korrekt behandelt, sollte noch vor einem entsprechenden Update im Zuge der Migration auf
ein Windows 2000 Netzwerk im Jahr 2002 geprüft werden. Es empfiehlt sich, bei dieser Gelegenheit auch alternative Webserver, wie den Apache10, einer genaueren Betrachtung zu unterziehen.
Zu Beginn der Diplomarbeit war der Wunsch des Kunden nach einem virtuellen privaten Netzwerk gegenüber dem sicheren Nachrichtentransfer und dem Zugriff aufs DiBa-Intranet relativ
gering. Die Prioritäten bei der Erstellung des Sicherheitskonzeptes und der Auswahl der nötigen Software waren daher vorrangig auf die beiden letzt genannten Wünsche ausgerichtet. Im
Laufe der Diplomarbeit zeigte sich allerdings, dass es sinnvoll wäre mobilen Mitarbeitern den
Zugang zu allen Funktionen des DiBa-LANs zu verschaffen.
Der Aufbau eines VPN würde dies ermöglichen, allerdings konnte die IPSec-Funktionalität
von Windows 2000 bisher auf Grund fehlender IPSec-Zertifikate seitens FlexiTrust ausschließlich theoretisch betrachtet werden. Die Integration eines VPNs in die PKI der DiBa
10. Apache (von der Apache Software Foundation) hat schon in [DFN00-1] seine PKI-Tauglichkeit bewiesen. Hinzu kommt der bessere Ruf im Vergleich zum IIS, was Sicherheitslücken betrifft. Weitere Informationen zum Open Source Webserver Apache sind unter http://www.apache.org zu finden.
97
muss daher leider zurückgestellt werden. Solange bis FlexiTrust in der Lage ist entsprechende
Zertifikate auszustellen.
98
Kapitel 6
Umsetzung der Public Key Infrastruktur
In den vorangegangenen fünf Kapiteln wurde die Basis für den Aufbau einer Public Key Infrastruktur in der Allgemeinen Deutschen Direktbank AG geschaffen.
Nach einer Ermittlung des konkreten Bedarfs und der Aufstellung eines Sicherheitskonzeptes
in Kapitel [4] wurden in Kapitel [5] Softwareprodukte unterschiedlicher Hersteller auf ihre
Eignung hinsichtlich des Einsatzes in der PKI untersucht. Im nächsten Schritt werden die einzelnen Ergebnisse dieser Arbeit zusammengefasst und beschrieben, wie die konkrete Realisierung einer PKI in der DiBa aussehen sollte.
Neben einer Beschreibung der Zertifizierungshierarchie liefert dieses Kapitel außerdem konkrete Konfigurationsvorschläge zu den, für den Einsatz ausgewählten, Softwareprodukten.
Diese sind neben der Einhaltung des gewünschten Sicherheitsstandards auch auf maximale
Interoperabilität und Benutzbarkeit ausgerichtet.
Der letzte Teil dieses Kapitels beschreibt den Ablauf der Benutzerzertifizierung, wie beispielsweise notwendige organisatorische Regelungen und Infrastrukturmaßnahmen.
6.1
Zertifizierungshierarchie
Eine zahlmäßig begrenzte Nutzerbasis sowie die Tatsache, dass sämtliche Mitarbeiter nach
denselben, einheitlichen Regeln zertifiziert werden, führte zu der Entscheidung eine flache (d.
h. einstufige) Zertifizierungshierarchie aufzubauen. Zudem wurde das flache Modell bereits in
der Testumgebung erfolgreich eingesetzt.
Abbildung 41 zeigt die Zertifizierungshierarchie der DiBa-CA. Diese besteht aus vier verschiedenen Einheiten, die wie folgt auf die Niederlassungen Frankfurt und Hannover verteilt
sind:

DiBa-CA
Eine Zertifizierungsinstanz in Frankfurt, zuständig für beide Niederlassungen.
99

DiBa-RA
Der DiBa-CA sind zwei lokale Registrierungsinstanzen zugeordnet, die den direkten organisatorischen Kontakt zu den Mitarbeitern beider Niederlassungen herstellen.

WWW
Ein oder mehrere Intranet-Server in Frankfurt mit SSL-Serverzertifikaten.

Mitarbeiter
Ausgewählte Mitarbeiter in den Niederlassungen Frankfurt und Hannover werden
entsprechend ihres Firmenstandortes einer RA zugeordnet und erhalten von der
gemeinsamen CA Client-Zertifikate für SSL und S/MIME (sowie später auch
IPSec).
Frankfurt
Hannover
DiBa-CA
DiBa-CA
DiBa-RA
DiBa-RA
Mitarbeiter
DiBa-RA
DiBa-RA
WWW
WWW
Mitarbeiter
Abbildung 41 Die flache Zertifizierungshierarchie der DiBa-CA
Aus den in Kapitel [5.1] genannten Gründen wird auf die Übernahme des VPN-Gateways in
die Zertifizierungshierarchie vorerst verzichtet. Da der Einsatz eines virtuellen privaten Netzwerkes aber für die Zukunft angestrebt wird, werden Zertifikate für VPN-Gateways und -Clients in den Zertifizierungsrichtlinien in Kapitel [A] unabhängig vom derzeitigen Einsatz
betrachtet.
6.2
Benutzergruppen
Eine Einteilung von Mitarbeitern in Benutzergruppen mit unterschiedlichen Rechten erfolgt
durch eine bei der DiBa vorhandene globale Benutzerdatenbank. Die Gruppenzugehörigkeit,
wie sie in Kapitel [4.1.2] besprochen wurde, wird daher nicht direkt die Zertifikate eingetragen.
Zertifikate werden personalisiert (d. h. personenbezogen) ausgestellt. Die Einstellung, zu welcher Rechtegruppe ein Benutzerzertifikat gehört, erfolgt über eine zentrale Administration
unter Zuhilfenahme der Benutzerverwaltungs-Datenbank (siehe [6.3.2.3]). Dies ermöglicht es,
einmal ausgestellte Zertifikate weiterzuverwenden, auch wenn Mitarbeiter auf Grund eines
Tätigkeitswechsels innerhalb der Firma veränderte Zugriffsrechte erhalten. Dies stellt einen
enormen Vorteil dar, denn würde die Gruppenzugehörigkeit in die Zertifikate aufgenommen,
100
Kapitel 6: Umsetzung der Public Key Infrastruktur
müssten diese in solch einem Fall zurückgerufen und entsprechend Neue dafür ausgestellt werden.
6.3
Konfiguration der Hard- und Software
In Kapitel 5 wurden Softwareprodukte unterschiedlicher Hersteller für den client- bzw. serverseitigen Einsatz in einer Public Key Infrastruktur untersucht. Die Produkte, die sich - bezogen
auf ihre (kryptographische) Leistungsfähigkeit, Handhabbarkeit und Interoperabilität - am
besten in das aufgestellte Sicherheitskonzept integrieren ließen, sollen nun auch im Realbetrieb eingesetzt werden. Im Einzelnen handelt es sich um:

Software für die Zertifizierungsstelle:
FlexSecure FlexiTrust 2.0 unter Windows 2000 Professional. Siehe Abschnitt
[6.3.1].

Software für Server (WWW):
Für die Bereitstellung der Intranet-Dienste wird der Microsoft Internet Information
Server 4.0 unter Windows NT 4.0 Server beibehalten und entsprechend auf die
Verwendung von SSL sowie der Bindung von Zertifikaten an Benutzer (-Gruppen)
konfiguriert. Siehe Abschnitt [6.3.2].

Software für Server (Email):
Die derzeit eingesetzte Mailserversoftware Microsoft Exchange Server 5.5 unter
Windows NT 4.0 Server wird beibehalten. Es sind keine besonderen Einstellungen
für den Einsatz von Verschlüsselung oder digitaler Signatur erforderlich, da diese
komplett in den Clientprogrammen vorgenommen werden. Wie in Abschnitt
[5.3.2] festgestellt, sind auch für den Betrieb der Exchange Server -Komponente
Outlook Web Access keine Änderungen gegenüber den bestehenden Einstellungen
notwendig.

Software für Server (VPN-Gateway):
Für den Betrieb des VPN-Gateways sollen in Zukunft die Möglichkeiten des Windows 2000 Server-Betriebssystems von Microsoft genutzt werden. Allerdings sind
von FlexiTrust 2.0 ausgestellte IPSec-Zertifikate derzeit noch nicht mit Windows
2000 kompatibel. Von einer Verwendung im Realbetrieb muss daher vorerst abgesehen werden.
Für sicherheitstechnische Überlegungen, welche die Konfiguration des VPN-Gateways - wie beispielsweise die Platzierung hinter, direkt auf, oder neben der Firewallkonstruktion - betreffen, lohnt es sich, einen Blick in [JuSch01-3] sowie
[MS01-2] zu werfen.

Software für Clients (WWW):
Microsoft Internet Explorer 5.5 unter Windows 2000 Professional. Siehe Abschnitt
[6.3.3].

Software für Clients (Email):
Microsoft Outlook 2000 unter Windows 2000 Professional. Siehe Abschnitt
[6.3.4].
101

Soft- / Hardware für die Firewalls
Eine detaillierte Darstellung der Änderung an der Firewall-Konfiguration ist nicht
Gegenstand dieser Arbeit.
Abbildung 42 zeigt die Anordnung der ausgewählten Produkte im Netzwerk der Allgemeinen
Deutschen Direktbank AG.
Mobiler Mitarbeiter
Internet
Firewalls und
Virenscanner
VPN-Gateway
(in Zukunft geplant)
<Frankfurt
(Outlook Web Access)
Mail-Server
WWW-Server
Hannover>
(Zertifikate + CRLs)
DiBa-RA + DiBa-IS
LDAP-Server
DiBa-RA
(in Zukunft geplant)
DiBa-CA
Abbildung 42 Anordnung der Hard- und Software im Realbetrieb der Public Key Infrastruktur
Einzelheiten zum Einsatz, sowie der Konfiguration der Produkte, liefern die folgenden
Abschnitte.
6.3.1
FlexSecure FlexiTrust 2.0
Die Installation von FlexiTrust erfolgt auf zwei Windows 2000-basierenden Rechnern. Auf
dem ersten Rechner befindet sich aus Sicherheitsgründen neben der eigentlichen CA nur das
notwendige Java 1.2.2. Die Installation der weiteren Einheiten wie RA und IS sowie einer
SQL-Datenbank1 erfolgen auf dem zweiten Rechner. Die Trennung dieser Dienste entspricht
den in der Policy (Abschnitt [A.3.1]) gestellten Sicherheitsanforderungen und ermöglicht es,
für die DiBa-CA einen Rechner ohne jeglichen Netzanschluss einzusetzen. Der zwischen CA
und RA/IS notwendige Datenaustausch wird von Mitarbeitern der DiBa-CA per Wechselme1. Empfohlen wird mySQL in der Version 3.23.39
102
dium vorgenommen.
Wurden in der Testumgebung noch universale Schlüsselpaare mit der gleichzeitigen Eigenschaft der Verschlüsselung und digitaler Signatur verwendet, werden aus Sicherheitsgründen
im Realbetrieb ausschließlich strikt getrennte Schlüsselpaare für Verschlüsselung und digitale
Signatur erzeugt (Policy, Abschnitt [A.4]). Diese Schlüssel dürfen nur für den jeweils für sie
vorgesehenen Einsatzzweck verwendet werden. Gute Gründe für den Einsatz zweier Schlüsselpaare bei unterschiedlichen Verwendungszwecken liefert [Entrust00-2].
Eine ausführliche Beschreibung des Ablaufs der Benutzerzertifizierung folgt in Abschnitt
[6.4].
6.3.2
Microsoft Internet Information Server 4.0
Der Internet Information Server 4.0 wird weiter wie bisher unter Windows NT 4.0 betrieben.
Allerdings ist es notwendig mindestens den NT Servicepack 6a sowie Internet Explorer 5.5
inkl. dem High Encryption Pack auf diesem System zu installieren, damit symmetrische Verschlüsselung mit 128 Bit und Asymmetrische mit 1024 Bit möglich wird.
Im Folgenden wird kurz beschrieben, welche Einstellungen am IIS vorgenommen werden
müssen, um die Voraussetzungen für den Einsatz in der Public Key Infrastruktur im Zusammenspiel mit FlexiTrust 2.0 zu erfüllen.
6.3.2.1 Erzeugen eines Serverzertifikates
Die Generierung des SSL-Serverschlüssels erfolgt durch den in den Server integrierten Schlüsselmanager.
Es wird empfohlen bei der Generierung des Schlüsselpaares für die Parameter Schlüsselname
und Allgemeiner Name den Domainnamen des Intranetservers zu verwenden. Um ausreichende Sicherheit zu gewährleisten, sollte die Bitlänge des Schlüssels mind. 1024 Bit betragen.
Die im Anschluss an die Schlüsselgenerierung erzeugte Zertifizierungsanforderung wird an die
DiBa-CA übergeben. Abschließend wird das von der DiBa-CA signierte Serverzertifikat in der
vorliegenden PEM-Version (*.pem.crt) in den IIS-Schlüsselmanager zu dem zugehörigen
Schlüssel installiert. Eine detaillierte Beschreibung des Ablaufes zeigt Anhang [B.1]:
6.3.2.2 Installation des Root-CA Zertifikates
Bei der Installation des DiBa-CA Zertifikates in die Zertifikatsverwaltung von Windows auf
dem IIS-Rechner genügt es nicht, die Voreinstellungen des Importassistenten zu übernehmen.
Damit der IIS 4 Clientzertifikate von eben dieser CA überprüfen kann, ist es notwendig, das
CA-Zertifikat als vertrauenswürdige Stammzertifizierungsstelle in den Speicher Lokaler Computer (an anderer Stelle auch Computerkonto genannt) zu installieren. Zertifikate, die stattdessen in den Speicher Eigenes Benutzerkonto (auch Registrierung genannt) installiert werden,
erlauben ausschließlich die SSL Serverauthentifizierung. Anhang [B.2] beschreibt diesen Vorgang Schritt für Schritt.
103
6.3.2.3 Serverkonfiguration für SSL
Nachdem die Voraussetzungen für den Einsatz von SSL geschaffen sind, kann die eigentliche
Konfiguration des IIS erfolgen. Webseiten, welche per SSL abgesichert werden sollen, sind
unbedingt so zukonfigurieren, dass Verbindungen von Clients, die keine starke Kryptographie
unterstützen, abgelehnt werden (128 Bit Verschlüsselung erforderlich).
Binden von Clientzertifikaten an Mitarbeiter
Um Zugriffe autorisierter Mitarbeiter von denen unautorisierter oder organisationsfremder Personen unterscheiden zu können, ist es erforderlich die SSL Clientauthentifizierung im IIS
explizit zu aktivieren (Clientzertifikate verlangen) und übergebene Zertifikate autorisierten
Mitarbeitern zuzuordnen (Client-Zertifikatszuordnungen aktivieren). Dabei besteht die Möglichkeit, Mitarbeiter in Gruppen mit unterschiedlichen Rechten einzuteilen. D. h. einzelnen
Mitarbeitern den Zugriff auf bestimmte Seiten zu erlauben, die anderen Mitarbeitern verwehrt
bleiben. Um den Server auf diese Art zu konfigurieren, müssen die Benutzerzertifikate von
autorisierten Mitarbeitern in den Server hinzugefügt und an die entsprechenden Windows NT
Domänenbenutzerkonten gebunden werden. Das beim eigentlichen Zugriff auf eine derart konfigurierte Seite übergebene Clientzertifikat wird nun automatisch vom IIS dem Domänenbenutzerkonto zugeordnet. Abhängig von den Rechten eines Domänenbenutzers erlaubt bzw.
verweigert der IIS anschließend den Zugriff auf die Seite.
Zugriff beschränken auf Clientzertifikate der DiBa-CA
Bestimmte Bereiche des Webservers sollen meist allen Mitarbeitern, die im Besitz eines DiBaCA Benutzerzertifikates sind, zugänglich sein. Um den Zugriff unautorisierter Personen (mit
Benutzerzertifikaten, die von anderen CAs ausgestellt wurden) zu unterbinden, können zwei
Regeln innerhalb der Clientzertifikatszuordnung erstellt werden:

Regel 1:
Der Zertifikatsaussteller DiBa-CA wird auf Zertifikat annehmen zur Anmeldeauthentifizierung eingestellt. Damit werden alle gültigen, von der DiBa-CA ausgestellten, Benutzerzertifikate für den Zugriff auf diesen Bereich akzeptiert und
automatisch an ein frei wählbares Benutzerkonto gebunden.

Regel 2:
Die nachfolgende Einstellung Alle vertrauten Zertifikataussteller den Zugriff verweigern unterbindet Zugriffe von Clients mit Benutzerzertifikaten anderer CAs.
Clients mit nicht-vertrauten bzw. unbekannten Zertifikatausstellern und Clients ohne Benutzerzertifikat wird automatisch der Zugriff verweigert, diesbezüglich ist keine besondere Einstellung notwendig. Diese Regeln lassen sich weiter verfeinern. Beispielsweise erlaubt die
Abfrage des im Zertifikat enthaltenen DN die Filterung nach Niederlassung oder Abteilung der
Mitarbeiter.
6.3.3
Microsoft Internet Explorer 5.5
Für den Betrieb des Internet Explorers in der Public Key Infrastruktur ist mindestens die Version 5.0 notwendig, empfohlen wird der Einsatz der Version 5.5 mit Servicepack 2 unter dem
104
Betriebssystem Windows 2000 (ebenfalls mit Service Pack 2). Es ist darauf zu achten, dass die
verwendete IE Version den High Encryption Pack von Microsoft enthält. Dieser muss notfalls
separat nachinstalliert werden, sonst kann eine SSL-Verbindung nur mit 40/56 Bit Verschlüsselung abgesichert werden.
Damit der Internet Explorer ungültige Zertifikate nicht fälschlicherweise als gültig erkennt,
müssen gegebenenfalls noch ein paar Voreinstellungen angepasst werden. Es ist darauf zu achten, dass folgende Einstellungen aktiv sind:

Auf zurückgezogene Serverzertifikate überprüfen

Auf zurückgezogene Zertifikate von Herausgebern überprüfen

Bei ungültigen Sitezertifikaten warnen
Das DiBa-CA Zertifikat sowie die Clientzertifikate der Mitarbeiter können anschließend
sowohl über den Internet Explorer selbst als auch über das Snap-In der MMC (wie in Abschnitt
[5.4.1] beschrieben) installiert werden.
6.3.4
Microsoft Outlook 2000
Für den Betrieb von Outlook 2000 in der Public Key Infrastruktur ist bei 40/56 Bit Systemen
das Outlook-Update auf die aktualisierte 128-Bit-Verschlüsselung notwendig, um starke Verschlüsselung auch innerhalb Outlooks zu ermöglichen.
Da Outlook ein Bestandteil von Microsofts Office 2000 ist, sollte die komplette Office Umgebung auf dem Stand von Service Release 1a sowie Service Pack 2 sein. Die angebotenen
Sicherheitsupdates, insbesondere jene zur Email-Sicherheit, sollten ebenfalls installiert werden.
Clientkonfiguration für S/MIME
Wurde bereits zuvor wie oben beschrieben der Internet Explorer installiert, sind das DiBa-CA
Zertifikat sowie die Clientzertifikate des Mitarbeiters automatisch für Outlook verfügbar. Nun
muss Outlook lediglich mitgeteilt werden, welches der Zertifikate für welchen Zweck (digitale
Signatur oder Verschlüsselung) verwendet werden soll. Zur Auswahl stellt Outlook sämtliche
für den jeweiligen Zweck geeigneten Zertifikate, welche in der Zertifikatsverwaltung von
Windows verfügbar sind. Für das Signaturzertifikat sollte der Hashalgorithmus SHA1 und für
das Verschlüsselungszertifikat der Verschlüsselungsalgorithmus 3DES ausgewählt werden.
Die gewählten Algorithmen werden beim digitalen Signieren bzw. Verschlüsseln von Emails
verwendet und sind unabhängig von den im Zertifikat angegebenen Algorithmen.
Ebenso wie beim Internet Explorer sollte darauf geachtet werden, dass bestimmte Einstellungen aktiv sind:

Signierte Nachrichten als Klartext senden

Signierten Nachrichten diese Zertifikate hinzufügen
105

Sicherheitsformat für Nachrichten = S/MIME
Installation fremder Benutzerzertifikate
Von der DiBa-CA erzeugte Benutzerzertifikate mit der Dateiendung *.crt liegen in dem von
Outlook gewünschten DER-codierten Format vor. Allerdings importiert Outlook Benutzerzertifikate ausschließlich dann in den Bereich Kontakte für fremde Mitarbeiter, wenn die Dateiendung auf *.cer lautet. Aus diesem Grund müssen Zertifikate vor dem Import momentan noch
entsprechend umbenannt werden. Zukünftige Versionen von FlexiTrust werden diese Dateiendung automatisch erzeugen. Es ist möglich, einem einzelnen Kontakt mehrere Zertifikate
zuzuordnen, falls dieser Kontakt verschiedene Email-Adressen enthält. Outlook verwendet
dann automatisch das zur Email-Adresse gehörende Zertifikat beim Senden einer verschlüsselten Nachricht an diesen Mitarbeiter.
Verschlüsselung und digitale Signatur bei ausgehenden Nachrichten
Damit Nachrichten beim Versand an andere Mitarbeiter automatisch ohne Zutun verschlüsselt
werden, empfiehlt es sich, die Option Nachrichteninhalte und Anlagen verschlüsseln zu aktivieren. Gleiches gilt für die Option Dig. Signatur ausgehenden Nachrichten hinzufügen, damit
werden ausgehende Nachrichten automatisch digital signiert.
Verschlüsselung und digitale Signatur bei eingehenden Nachrichten
Empfangene, verschlüsselte Nachrichten werden nicht im Vorschaufenster von Outlook angezeigt. Zum Lesen der Nachricht muss diese erst geöffnet werden. Über ein blaues SchlossSymbol im Nachrichtenfenster können Informationen, wie der Verschlüsselungsalgorithmus,
sowie das verwendete Verschlüsselungszertifikat eingesehen werden.
Empfangene, digital signierte Nachrichten werden hingegen im Vorschaufenster angezeigt,
solange die enthaltene Signatur gültig ist. Über das rote Signatursymbol im Nachrichtenfenster
können - ebenso wie bei der Verschlüsselung - Informationen zum verwendeten Signaturzertifikat eingesehen werden. Weiterhin liefert dieser Dialog Informationen bezüglich der Gültigkeit der digitalen Signatur, wie beispielsweise, ob die Nachricht unverändert ist, oder ob das
Signaturzertifikat gültig ist. Bei fehlerhaften Signaturen oder -Zertifikaten warnt Outlook vor
dem Öffnen der Nachricht den Benutzer entsprechend. Es wird empfohlen, diesen Warnhinweis nicht explizit auszuschalten, um kompromittierte Nachrichten schnell erkennen zu können. Weiterhin sollte beim Empfang signierter Nachrichten ausdrücklich das verwendete
Signaturzertifikat überprüft werden.
6.4
Allgemeiner Ablauf der Benutzerzertifizierung
Der folgende Abschnitt beschreibt den Ablauf der Benutzerzertifizierung. Dabei werden u. a.
Themen wie die Registrierung von Mitarbeitern, Erzeugung von kryptographischen Schlüsselpaaren, der Vorgang der Zertifizierung und Schlüsselverteilung / -Verwaltung, sowie die Sperrung von Zertifikaten berücksichtigt.
106
6.4.1
Registrierung
Registriert werden neben Mitarbeitern auch WWW-Server sowie später VPN-Gateways. Zur
Aufgabe der DiBa-RA gehört neben der Annahme und Prüfung von Zertifizierungsanträgen
auch die Vergabe eindeutiger Namen für Mitarbeiter und Server.
Anfragen von Mitarbeitern bezüglich der Aufnahme in die Zertifizierungsinfrastruktur und
eine damit verbundene Zuteilung von digitalen Schlüsseln und Zertifikaten erfolgen an administrative DiBa-RA Mitarbeiter (im Folgenden Administratoren genannt).
Personenbezogene Registrierungsdaten müssen bei der Registrierung nicht erhoben werden,
soweit diese Daten aus der zentralen Benutzerdatenbank der DiBa entnommen werden können.
Unter den Begriff personenbezogene Daten fallen u. a. Folgende:

Daten zur Zertifikatserzeugung
Identifikation des Mitarbeiters, wie beispielsweise Name und Adresse.

Daten des zugeordneten Arbeitsplatzes
u. a. Standort, Rechnername sowie IP-Adresse.

Daten zur Verwaltung und Sperrung von Zertifikaten
Notwendige Kennwörter etc.
Anfangs werden Registrierungsdaten noch manuell durch die Administratoren von der zentralen Benutzerdatenbank in das Registrierungsformular der DiBa-RA übernommen. Es ist denkbar, dass diese Aufgabe in Zukunft durch eine - noch zu schaffende - Schnittstelle zwischen
der DiBa-CA Datenbank und der Benutzerdatenbank automatisch erledigt werden kann. Dies
würde manuelle Eingriffe auf ein Minimum beschränken.
6.4.2
Schlüsselerzeugung
Benutzerschlüssel
Durch die DiBa-CA werden pro Mitarbeiter zwei getrennte asymmetrische Schlüsselpaare
erzeugt. Je eines für:

Verschlüsselung (S/MIME und SSL)
Anschließend erfolgt eine Sicherung des privaten Teils des Verschlüsselungsschlüssels dieses Schlüsselpaares zum Zweck der Schlüsselwiederherstellung.

Digitale Signatur (S/MIME)
Der private Teil des Signaturschlüsselpaares wird nur solange innerhalb der DiBaCA aufbewahrt bis er von Administratoren der DiBa-CA an den entsprechenden
Mitarbeiter ausgehändigt wurde (siehe Punkt [6.4.4]). Nach der Übergabe an den
Mitarbeiter wird dieser auf Seiten der DiBa-CA unwiderruflich gelöscht.
Die erstellten privaten Schlüssel der jeweiligen Schlüsselpaare werden in PKCS#12-Dateien
zusammen mit den Benutzerzertifikaten (siehe nächster Schritt) und dem DiBa-CA Zertifikat
untergebracht. Für jedes Schlüsselpaar wird eine solche Datei (auch PSE genannt) angelegt.
107
Die PSE wird mithilfe eines zufälligen Kennwortes gegen unbefugte Zugriffe durch Dritte
geschützt. Für beide PSEs eines Mitarbeiters kann dabei aus Gründen der Einfachheit dasselbe
Kennwort gewählt werden. Diese Kennwörter müssen dem Mitarbeiter bei Aushändigung
[6.4.4] der PSE mitgeteilt werden.
Serverschlüssel für SSL
Die Schlüsselerzeugung für den Internet Information Server 4 erfolgt innerhalb des IIS selbst
und nicht durch die Software FlexiTrust.
6.4.3
Zertifizierung
Benutzerzertifikate
Die DiBa-CA erstellt für jedes der beiden o. g. Schlüsselpaare ein getrenntes Zertifikat, in das
der jeweilige öffentliche Schlüssel mit aufgenommen wird, mit folgenden Eigenschaften:

Verschlüsselung (S/MIME und SSL)

Digitale Signatur (S/MIME)
Serverzertifikat für SSL
Der vom IIS selbst generierte öffentliche Schlüssel wird mithilfe der DiBa-CA zertifiziert und
in das erstellte Zertifikat mit aufgenommen.
6.4.4
Schlüsselverteilung
Verteilung der Benutzerschlüssel und -Zertifikate
DiBa-RA Administratoren verteilen die Schlüssel auf einem Wechseldatenträger in Form von
PKCS#12-Dateien zusammen mit den Benutzerzertifikaten, dem DiBa-CA Zertifikat und der
aktuellsten Sperrliste an die Mitarbeiter und nehmen deren Installation auf dem Rechner des
Mitarbeiters vor. Der Mitarbeiter muss sich davon überzeugen, dass die in den Zertifikaten enthaltenen persönlichen Daten korrekt sind. Anschließend erhält er eine Einweisung in die
Anwendung der vom Mitarbeiter zu verwendenden Produkte sowie den sorgsamen Umgang
mit privaten Schlüsseln und deren Bedeutung.
Nach der Übergabe des schlüsseltragenden Datenträgers an den Mitarbeiter bekommt dieser
die notwendigen Kennwörter für den Zertifikatswiderruf und zur Entschlüsselung der PSEs
vom Administrator ausgehändigt.
Verteilung des DiBa-CA Zertifikates
Zusätzlich zur konkreten Verteilung (s.u.) wird das DiBa-CA Zertifikat noch einmal zentral,
für jeden abrufbar in einem öffentlichen Bereich des Intranet-Webservers abgelegt. Sodass
auch Mitarbeiter, die nicht zertifiziert wurden, Zugriff auf das DiBa-CA Zertifikat haben, um
digitale Signaturen zu prüfen.
108
6.4.5
Sperrmanagement
Benutzerzertifikate können sowohl durch persönlichen Kontakt mit der RA als auch telefonisch oder per Email gesperrt werden.
Um die Authentizität des Sperrantrages zu überprüfen und sicherzustellen, dass der Mitarbeiter
berechtigt ist das Zertifikat zu sperren, ist von Seiten des Mitarbeiters die Nennung des Kennwortes für den Zertifikatswiderruf (s.o.) notwendig. Ohne Nennung des Kennwortes ist der
persönliche Kontakt mit einem RA-Mitarbeiter unter Vorlage des Personalausweises notwendig. Kontakt per Email oder Telefon ist in diesem Fall aus Sicherheitsgründen ausgeschlossen.
Konnte die Berechtigung des Mitarbeiters zum Sperren des Zertifikates festgestellt werden,
sperrt ein Administrator dieses Zertifikat unverzüglich unter Eingabe des Passwortes, der Seriennummer und evtl. eines Sperrgrundes. Die Erstellung einer aktualisierten Widerrufsliste
erfolgt dann ohne weiteres Zutun automatisch durch FlexiTrust.
6.4.6
Veröffentlichung von Zertifikaten und Widerrufslisten
In der ersten Phase ist der Einsatz eines LDAP-Verzeichnisdienstes zur Veröffentlichung von
Zertifikaten auf Grund der anfangs geringen Nutzerbasis noch nicht notwendig.
Die Veröffentlichung aller vorzeitig widerrufenen Zertifikate (deren Gültigkeitszeitraum noch
nicht abgelaufen ist)1 in Form von Widerrufslisten im X.509v1 Format erfolgt auf dem Intranet-Server der DiBa mittels HTTP-Protokoll. Von dieser Praxis sollte auch dann nicht abgewichen werden, wenn in Zukunft ein LDAP-Verzeichnisdienst zur Veröffentlichung von
Zertifikaten bereit gestellt wird. Microsoft weist in [MS01-3] auf Performanceeinbußen bei der
Bereitstellung von Widerrufslisten über LDAP-Verzeichnisdienste gegenüber HTTP-Servern
hin.
6.4.7
Vier-Augen-Prinzip
Schutz gegen den Missbrauch der DiBa-CA durch CA-Mitarbeiter (sog. Insidermissbrauch)
bietet die Einhaltung des Vier-Augen-Prinzips. Die Stelle des DiBa-CA Administrators sollte
immer doppelt besetzt werden. Der Zugriff auf wichtige Ressourcen wie dem CA-Signierschlüssel sollte immer nur zwei autorisierten Mitarbeitern gemeinsam möglich sein, sodass ein
Missbrauch nie von einem Mitarbeiter alleine ausgeübt werden kann.
Es bietet sich an, hierfür das Passwort zur Freigabe des Signierschlüssels schon bei der Generierung in zwei Teil-Passwörter aufzuteilen und jedem CA-Mitarbeiter nur jeweils einen Teil
des Passwortes auszuhändigen. Um den CA-Signierschlüssel zu verwenden, müssen somit
immer zwei Administratoren gleichzeitig zugegen sein, was einen gewissen Schutz vor Insider-Missbrauch ermöglicht.
1. Zusätzlich werden von der CA alle jemals widerrufenen (abgelaufene und nicht abgelaufene) Zertifikate
in Form einer Komplettliste archiviert.
109
110
Kapitel 7
Kommentar
zu den Zertifizierungsrichtlinien
Zertifizierungsrichtlinien (im Folgenden als Policy bezeichnet), definieren feste Regeln und
Richtlinien, nach deren Vorgaben die Zertifizierung durch die DiBa-CA zu erfolgen hat. Der
Sinn einer Policy ist es, den Mitarbeitern eine Einschätzung der durch die DiBa-CA ausgestellten Zertifikate zu ermöglichen.
In diesem Kapitel werden einige interessante und z. T. bedenkliche Stellen der Policy aus
Anhang [A] betrachtet. Dabei wird besonderes Augenmerk auf die speziellen Anforderungen
des SigG gelegt.
7.1
Rechtliche Bedeutung
Nachteil der fehlenden rechtlichen Bedeutung
Abschnitt [A.2.1]: „Eine Zertifizierung durch die DiBa-CA zieht keinerlei rechtliche
Bedeutung nach sich; ein gesetzlicher Anspruch auf Erteilung eines Zertifikates durch
die DiBa-CA besteht nicht.“
Die fehlende rechtliche Bedeutung der DiBa-CA-Zertifizierung schließt den Einsatz ausgestellter Zertifikate außerhalb des Unternehmens der Allgemeinen Deutschen Direktbank AG
aus. Bezahl- oder Bestellvorgänge mit diesen Zertifikaten im E-Commerce sowie der Datenaustausch mit Behörden, anderen Finanzinstituten oder Unternehmen führen daher zu Komplikationen bei der Beweisführung im Falle des Missbrauchs privater Schlüssel. Für diesen
Einsatzzweck sind Zertifikate der DiBa-CA allerdings auch nicht vorgesehen. Diese werden
ausschließlich für den unternehmensinternen Gebrauch mobiler DiBa-Mitarbeiter zum Zweck
der Authentifikation gegenüber Unternehmensservern im LAN sowie zur Absicherung deren
elektronischer Kommunikation eingesetzt. Für organisationsfremde Personen, sowie Mitarbeiter die nicht auf die mobile Kommunikation angewiesen sind, besteht daher kein Anspruch auf
die Erteilung eines Zertifikates durch die DiBa-CA.
111
Gründe gegen eine SigG-konforme Zertifizierung
Abschnitt [A.2.1]: „Die dieser Policy zugrunde liegenden Anforderungen an technische
Komponenten und Verfahren zur Zertifizierung sind derzeit nicht SigG-konform. Zertifikate der DiBa-CA entsprechen demnach nicht den qualifizierten Zertifikaten nach §2
Nummer 7 des Signaturgesetzes (SigG).“
Die DiBa-CA wird ihren Betrieb zunächst nicht als Zertifizierungsstelle nach dem deutschen
Signaturgesetz (SigG) aufnehmen. Zum einen übersteigen die Anforderungen des SigG an
organisatorische, technische, personelle sowie bauliche Maßnahmen den Rahmen dessen, was
im Zuge einer Diplomarbeit realisiert werden kann. Zum anderen ist derzeit noch nicht abzusehen, ob in naher Zukunft überhaupt ein Bedarf an SigG-konformer Zertifizierung entsteht, der
einen solchen Aufwand rechtfertigen würde.
Im Folgenden sind exemplarisch zwei Gründe dargestellt, die gegen den Einsatz einer SigGkonformen Lösung sprechen:

SigG §4, Abs. 2: „Einen Zertifizierungsdienst darf nur betreiben, wer die für den
Betrieb erforderliche Zuverlässigkeit und Fachkunde sowie eine Deckungsvorsorge nach § 12 nachweist (...). Die weiteren Voraussetzungen für den Betrieb
eines Zertifizierungsdienstes liegen vor, wenn die Maßnahmen zur Erfüllung der
Sicherheitsanforderungen nach diesem Gesetz ... praktisch umgesetzt sind.“
Weder die geforderte Fachkunde von DiBa-CA-Mitarbeitern noch das Einhalten
der notwenigen Sicherheitsanforderungen auf dem Level des SigG können im Rahmen dieser Arbeit gewährleistet werden. Hinzu kommt die Notwendigkeit, einer
entsprechenden Deckungsvorsorge (siehe Abschnitt [3.9.2]) für Schäden Dritter.

SigV 97 Begründung, §16 Abs. 2: „Die Signiertechnik wird in der Regel im
wesentlichen auf einer Chipkarte oder einem vergleichbaren Träger (z. B. PCMCIA-Karte) realisiert.“
Hardware-PSEs (Chipkarten) werden von der DiBa-CA in der ersten Phase nicht
eingesetzt, stattdessen wird eine Softwarelösung favorisiert. Digitale Signaturen
werden auf den Rechnern der Mitarbeiter erzeugt und private Schlüssel entsprechend auf Festplatte gespeichert. Dies entspricht nicht dem, für die Erzeugung qualifizierter Signaturen nach SigG, gefordertem Sicherheitsstandard.
Separate Signier- und Entschlüsselungsschlüssel
SigG §5, Abs. 4: „Eine Speicherung von Signaturschlüsseln außerhalb der sicheren
Signaturerstellungseinheit ist unzulässig.“
Signaturschlüssel dürfen laut SigG nur beim Mitarbeiter selbst auf den dafür vorgesehenen
Software- oder Hardwareeinheiten (PSEs wie beispielsweise Chipkarten) gespeichert werden.
Eine Speicherung in der Zertifizierungsstelle, wie sie für Key Recovery notwendig wäre, ist
nicht zulässig. Das SigG betrachtet allerdings ausschließlich Schlüssel zur Erstellung digitaler
Signaturen (Signierschlüssel). Für die bei der DiBa (zusätzlich) notwendigen Verschlüsselungsschlüssel ist aber ein Verfahren zur Wiederherstellung unerlässlich. Eine Lösung bietet
die Verwendung separater Signier- und Entschlüsselungsschlüssel.
Eine Funktionstrennung der Schlüssel nach diesem Muster bietet neben der SigG-Konformität
112
Kapitel 7: Kommentar zu den Zertifizierungsrichtlinien
auch noch Vorteile im Betrieb der PKI. Zum einen verringert sich das kryptographische Material, das Angreifern für eine Kryptoanalyse zur Verfügung steht, denn jeder der beiden Schlüssel wird seltener benutzt, als wenn nur ein Schlüssel für beide Aufgaben verwendet würde.
Zum anderen hat eine mögliche Schlüsselkompromittierung weniger Auswirkungen auf die
Sicherheit des Gesamtsystems, ein kompromittierter Schlüssel kann nur entweder zur Verschlüsselung einer Kommunikation oder für digitale Unterschriften benutzt werden - nicht aber
für beides.
7.2
Einsatz von Registrierungsinstanzen
Abschnitt [A.2.3]: „Allgemein lässt sich durch Einsatz solcher RAs die Zahl der organisationseigenen CAs überschaubar halten. RAs dürfen lediglich zur Registrierung und
Überprüfung von Benutzern eingesetzt werden. (...) Die DiBa-RA hat eine rein organisatorische Funktion, sie darf weder das asymmetrische Schlüsselpaar für Mitarbeiter
erzeugen, noch kann sie Mitarbeiter-Zertifikate erteilen oder widerrufen.“
Der Einsatz lokaler RAs verringert die Notwendigkeit zusätzlicher CAs, wenn die zuständige
CA weit von den zu zertifizierenden Mitarbeitern entfernt ist. Aufgrund der Tatsache, dass
RAs mit weniger Rechten (und Pflichten) als CAs ausgestattet sind, ergeben sich bei deren
Einsatz wichtige Vorteile:
7.3

Reduktion des Verwaltungsaufwandes
Die Administration einer RA ist unkomplizierter als die einer CA, da keine vergleichbar komplexe Hard- / Software-Infrastruktur eingesetzt werden muss. Der
Aufbau einer RA ist entsprechend mit einem wesentlich geringeren technischen
Aufwand zu erreichen.

Sicherheitsaspekt
Mitarbeiter einer RA benötigen weniger sicherheitstechnisches Wissen, als Mitarbeiter einer CA. Entsprechend geringer fällt der Schulungsaufwand für diese Mitarbeiter aus.
Sicherheit in einer hierarchischen Struktur
Abschnitt [A.3]: „Durch die Teilnahme an einer Public Key Infrastruktur entstehen für
Mitarbeiter bestimmte Anforderungen hinsichtlich der Sicherheit der eingesetzten Hardund Software einerseits sowie dem verantwortungsvollen Umgang mit kryptographischen Schlüsseln andererseits. Die Anforderungen an die DiBa-CA sind dabei naturgemäß höher, da der Missbrauch eines CA-Schlüssels allen untergeordneten Zertifikaten
die Vertrauenswürdigkeit entziehen würde.“
Werden in einer derartigen hierarchischen Struktur die erwähnten Sicherheitsmerkmale nicht
tatsächlich alle eingehalten, kann dies Auswirkungen auf andere Mitarbeiter dieser Hierarchie
haben. Insbesondere eine übergeordnete CA muss mit besonderer Aufmerksamkeit auf die
eigene Einhaltung der Sicherheitsanforderungen achten. Falls der CA-Schlüssel kompromittiert werden sollte, verlieren alle untergeordneten Instanzen (RAs, Mitarbeiter, WWW-Server,
etc.) der Hierarchie ihre Vertrauenswürdigkeit. Dies zieht eine erneute Zertifizierung des kompletten Teils dieser Hierarchie nach sich.
113
7.4
Zertifizierung von Benutzern
Überprüfung der Identität von Mitarbeitern
Abschnitt [A.4.1]: „Die DiBa-CA (bzw. RA) hat vor der Zertifizierung in geeigneter
Weise die Eindeutigkeit folgender Informationen zu überprüfen: 1) Zugehörigkeit des
Rechners zur Allgemeinen Deutschen Direktbank AG. 2) Identität des Mitarbeiters.“
An dieser Stelle unterscheidet sich die Policy der DiBa-CA ein wenig von Policies anderer
CAs wie beispielsweise der Low-Level Policy des DFN [DFN99-1]. Der diesbezügliche
Absatz dort fordert eine explizite Überprüfung der Identität an Hand des Personalausweises.
DFN-PCA, Low-Level Policy, Abschnitt [5.3]: „...hat sich der Benutzer persönlich vorzustellen, um der CA (bzw. RA) die Verifikation der Identität und die korrekte Zuordnung
einer erreichbaren Email-Adresse zu diesem Benutzer ... zu ermöglichen. Für den Prozeß
der Verifikation ist die Vorlage eines Personalausweises/Reisepasses bzw. eines vergleichbaren Dokumentes erforderlich.“
Eine derartig strenge Authentifikationsprüfung von Benutzern ist für die Teilnahme an der
Public Key Infrastruktur der DiBa nicht notwendig, da es sich bei diesen ausschließlich um
DiBa-Mitarbeiter und nicht um organisationsfremde Personen handelt. Sämtliche erforderlichen Daten, wie Name, Abteilung, Benutzerrechte, Email-Adresse usw. sind von allen Mitarbeitern zentral in einer Datenbank erfasst. Diese umfasst neben den notwendigen persönlichen
Daten aller Mitarbeiter auch Daten zu den, ihnen zur Verfügung gestellten (mobilen) Rechnern. Zudem nehmen Administratoren der DiBa die Installation von Schlüsseldaten und Zertifikaten auf den entsprechenden Rechnern vor. Eine Überprüfung, ob es sich bei der Person, die
den Zertifizierungsantrag stellt, um den angegebenen Mitarbeiter handelt, gewährleistet daher
ausreichende Sicherheit. Entsprechendes gilt für den ihm zur Verfügung gestellten Rechner.
Maximale Gültigkeitsdauer
Abschnitt [A.4.1]: „Zertifikate nach X.509v3 für Mitarbeiter haben eine Gültigkeitsdauer von maximal einem Jahr.“
Die im November 1997 in Kraft getretene Signaturverordnung (SigV) verlangt, dass Zertifikate eine Gültigkeitsdauer besitzen müssen [SigG97-2] §7. Mit einer Dauer von einem Jahr
wird die geforderte Höchstdauer von fünf Jahren eingehalten. Zum SigG aus dem Jahr 2001
existiert momentan (Mitte 2001) noch keine derartige Verordnung. Es ist aber zu erwarten,
dass diese entsprechende Passagen enthalten wird. Die reduzierte Gültigkeit von einem Jahr
wird durch den prototypischen Status der DiBa-CA begründet. Nach Ablauf der PrototypenTestphase wird entschieden, ob Folgezertifikate mit einer längeren Gültigkeit ausgestellt werden.
Schlüsselgenerierung innerhalb der Zertifizierungsinstanz
Abschnitt [A.4.1]: „Mitarbeiter, welche zertifiziert werden möchten, generieren selbst
kein eigenes asymmetrisches Schlüsselpaar, sondern übermitteln nur den Zertifizierungswunsch an die DiBa-RA. (...) Das asymmetrische Schlüsselpaar des Mitarbeiters wird
114
Kapitel 7: Kommentar zu den Zertifizierungsrichtlinien
ausschließlich von der DiBa-CA erzeugt“.
Die Schlüsselgenerierung erfolgt mithilfe der im SigG §2 Punkt 12 genannten technischen
Komponenten für Zertifizierungsdienste. Nur diese erlauben bei Erzeugung und Übertragung
die vom SigG §17 Absatz 3 geforderte Einmaligkeit und Geheimhaltung der Schlüssel. Die z.
T. von Zertifizierungsrichtlinien einiger anderer CAs erlaubte Möglichkeit, die Schlüsselgenerierung dem Mitarbeiter zu überlassen, würde dies u. U. nicht gewährleisten. Zumindest müsste jeder Mitarbeiter selbst über entsprechende Kenntnisse und Infrastrukturen verfügen. Eine
Schlüsselgenerierung im Zertifizierungsdienst nimmt dem Benutzer diese Bürde und ist für ihn
entsprechend unkompliziert. Gleichzeitig bietet sie den Vorteil, die Schlüsselhinterlegung
erheblich zu vereinfachen. Ein Nachteil darf allerdings nicht vergessen werden: die fehlende
Rechtssicherheit. Denn private Schlüssel der Mitarbeiter sind (zumindest zeitweise) im Besitz
mehrer Personen. Niemand kann hundertprozentig garantieren, dass eine erzeugte digitale
Signatur vom Mitarbeiter selbst stammt. Es ist denkbar, dass ein CA-Mitarbeiter in betrügerischer Absicht den Besitz fremder Mitarbeiterschlüssel ausnutzt um in fremden Namen digitale
Signaturen zu erzeugen.
7.5
Einsatz von Widerrufslisten
Abschnitt [A.6]: „Alle widerrufenen Zertifikate werden von der DiBa-CA auf einer
Widerrufsliste (Certificate Revocation List, CRL) veröffentlicht, welche allen Mitarbeitern zur Verfügung gestellt wird, um widerrufene Zertifikate nicht irrtümlicherweise zu
benutzen.“
In der Begründung zu §8 der Signaturverordnung [SigG97-3] wird explizit der Einsatz von
sog. Zertifikats-Sperrlisten für Großanwender vorgeschlagen. Was nichts anderes darstellt, als
die hier eingesetzte Widerrufsliste.
Wiedereinsetzung eines widerrufenen Zertifikates
Abschnitt [A.6]: „Einmal widerrufene Zertifikate können nicht erneuert oder verlängert
werden. Jedoch hat jeder Mitarbeiter grundsätzlich die Möglichkeit, ein neues Zertifikat
zu beantragen.“
Diese Handhabung entspricht den Vorgaben der Signaturverordnung von 1997 §9 Absatz 3.
Eine Sperrung muss endgültig sein, damit keine Zweifel aufkommen, ob und wann ein Zertifikat gesperrt war. Die Begründung zur Signaturverordnung spricht ausdrücklich von der Möglichkeit, bei Bedarf neue Zertifikate auszustellen.
7.6
Zusammenfassung
Bei der Festlegung der Zertifizierungsrichtlinien wurde Wert darauf gelegt, die gestellten
Sicherheitsanforderungen zu erfüllen und dabei den Alltagsbetrieb möglichst nicht durch
unzumutbare Regeln einzuschränken. Einige der dabei entstandenen Regeln und Richtlinien
wurden in diesem Kapitel noch einmal näher erläutert.
115
116
Kapitel 8
Bewertung und Ausblick
8.1
Gesamtbewertung
Tragfähigkeit des Konzeptes
Die Erfahrungen aus dem Betrieb der Testumgebung haben gezeigt, dass es möglich ist, mit
der prototypischen Trustcenter-Software FlexiTrust eine funktionierende Public Key Infrastruktur aufzubauen, welche die Anforderungen an ein einheitliches Sicherheitskonzept für die
Allgemeine Deutsche Direktbank AG erfüllen kann. Zusammen mit Standardsoftware anderer
Hersteller ist es möglich, die Kommunikation mobiler Mitarbeiter zu schützen sowie sicheren
Zugriff auf vertrauliche Intranetinhalte zu gewährleisten. Das Gesamtkonzept hat sich damit
als tragfähig erwiesen.
Verwendbarkeit der eingesetzten Software
Die Bedienerfreundlichkeit des FlexiTrust Produktes in Bezug auf die Installation war während des Verlaufes dieser Arbeit (bedingt durch die gleichzeitig fortschreitende Entwicklung)
starken Veränderungen unterworfen. Mittlerweile wurde die Installation wesentlich vereinfacht. Die Einrichtung und Grundkonfiguration einer neuen Root-CA gelingt allerdings noch
nicht ohne Mitwirken des Herstellers. Hier sollte für die Zukunft ein grafisches Benutzerinterface zur komfortablen Konfiguration geschaffen werden. Dieses sollte in der Release-Version
die momentan auf direkten Datenbankeingriffen und Scriptdateien basierende Konfigurationsmöglichkeit ersetzen (oder zumindest ergänzen).
Der Funktionsumfang des Trustcenter Produktes genügte bereits in der jetzigen Version in den
meisten Punkten den Anforderungen des Sicherheitskonzeptes. Lediglich Funktionen zum
Aufbau virtueller privater Netzwerke auf IPSec-Basis können derzeit nicht für die ausgewählte
Plattform (Windows 2000) bereitgestellt werden. Diese werden allerdings in der endgültigen
Version verfügbar sein.
Im Bereich der zusätzlich eingesetzten Standardsoftware zeigte der ausgewählte Internet
Explorer Schwächen beim Einsatz von Widerrufslisten. Als Ausweg aus dieser Misere bietet
sich ein Update auf den IIS5 an, möglicherweise auch der Einsatz eines alternativen Webser-
117
vers wie beispielsweise des Apache unter UNIX. Dieser würde zugleich mehr Sicherheit gegen
externe Angriffe bieten. Sollte die Weiterverwendung des derzeitigen IIS 4 gewünscht sein, ist
die ausdrückliche Bindung jedes einzelnen Zertifikates über die Clientzertifikatszuordnung an
den Webserver eine Möglichkeit, auf Widerrufslisten innerhalb des IIS zu verzichten. Widerrufenen Zertifikaten könnte man dann die Bindung entziehen, so wäre sichergestellt, dass ungültigen Zertifikaten kein Zugang gewährt würde.
8.2
Ausblick
Smartcards vs. Software-PSE
Das Sicherheitskonzept sieht derzeit keine Realisierung kryptographischer Operationen in
Hardware vor. Sämtliche Funktionen wie Schlüsselgenerierung, Ver- und Entschlüsselung,
digitale Signatur sowie Authentifikations-Mechanismen werden ausschließlich in Form einer
Softwareimplementierung auf Client- und Serverrechnern ausgeführt. Dazu notwendige
Schlüsseldaten werden direkt auf der Festplatte des jeweiligen Rechners gespeichert und sind
entsprechend schwach gegen Angriffe geschützt.
Die Sicherheit ließe sich durch den Einsatz von Smartcards erheblich erhöhen. Neben der
höheren Sicherheit bieten Smartcards weitere Vorteile. Sie eignen sich beispielsweise hervorragend zur Authentifikation von Mitarbeitern. So könnten Smartcards auch als Zugangsberechtigung zum PC eingesetzt werden. Auf diese Weise könnte man den fehlerträchtigen
Loginvorgang auf Passwortbasis ablösen.
Einbeziehung weiterer Mitarbeiter in die PKI
Die Zielgruppe für die Einführung des Sicherheitskonzeptes in Phase 1 umfasst ausschließlich
mobile Mitarbeiter. Im Zuge der Einführung von Smartcards und der damit verbundenen Möglichkeit der sicheren Authentifizierung im Bereich der Zugangsberechtigung am PC bietet es
sich an, sämtliche Mitarbeiter der DiBa in das Sicherheitskonzept zu integrieren.
Anpassung des Konzeptes an SigG-Konformität sowie Erweiterung des Nutzerkreises
auf Brokeragekunden
Solange Zertifikate der DiBa-CA ausschließlich innerhalb des Unternehmens der Allgemeinen
Deutschen Direktbank AG eingesetzt werden, besteht keine Notwendigkeit für den Einsatz
qualifizierter digitaler Signaturen nach SigG. Eine Umstellung auf ein SigG-konformes Konzept würde es allerdings ermöglichen, Signatur-Chipkarten im Bereich Onlinebanking und
Brokerage an Kunden herauszugeben und damit die bisherige PIN/TAN-basierte Lösung zu
ersetzen.
118
Anhang A
Zertifizierungsrichtlinien: Policy
Dies ist die Version 1.0 der Policy der DiBa-CA. Sie basiert zum Großteil auf der Policy der
FernUni-CA der FernUniversität Hagen [FUHagen01], der Medium-Level-Policy der DFNPCA [DFN99-1] sowie der Policy der Bundesverwaltung [BSI97]. Absätze und Formulierungen, welche die DiBa-CA betreffen, wurden den vorgenannten Policies entnommen bzw. auf
die DiBa-CA spezifischen Besonderheiten umgeschrieben.
Dieses Kapitel enthält die Zertifizierungsrichtlinien (die sog. Policy) der obersten Zertifizierungsinstanz der Allgemeinen Deutschen Direktbank AG - DiBa (DiBa-CA). Die DiBa-CA ist
zugleich Wurzelinstanz dieser Hierarchie (PCA), da sie derzeit selbst von keiner übergeordneten CA zertifiziert ist.
Der Sinn dieses Dokumentes ist es, Benutzern im Netzwerk eine Einschätzung der durch diese
CA ausgestellten Zertifikate zu ermöglichen. Benutzer im Sinne dieser Policy sind ausschließlich Mitarbeiter der Allgemeinen Deutschen Direktbank AG.
Die in diesem Dokument getroffenen Aussagen sind für die Arbeit der DiBa-CA bindend,
soweit sie nicht gesetzlichen Regelungen widersprechen. Die DiBa-CA zertifiziert ausschließlich nach den Richtlinien dieser Policy.
A.1
Identität der DiBa-CA
Adresse
DiBa-CA
Allgemeine Deutsche Direktbank AG
Baseler Straße 27-31
60329 Frankfurt/Main
Gültigkeit dieses Dokumentes
Diese Policy ist gültig vom 1. Oktober 2001 bis zum 31. Dezember 2002.
119
A.2
Zuständigkeitsbereich der DiBa-CA
Der Zuständigkeitsbereich der DiBa-CA umfasst alle Mitarbeiter der Allgemeinen Deutschen
Direktbank AG. Das vorrangige Ziel der DiBa-CA besteht in dem Aufbau einer firmenweiten
Public Key Infrastruktur zur Zertifizierung einzelner Mitarbeiter der Allgemeinen Deutschen
Direktbank AG. Eine solche Infrastruktur ist die Voraussetzung für die vertrauenswürdige
Kommunikation im Netzwerk der Allgemeinen Deutschen Direktbank AG. Realisiert durch
Sicherheitsdienste wie Integrität, Authentizität und Vertraulichkeit.
Die DiBa-CA wird in der ersten Phase ausschließlich Zertifikate für unternehmensinterne
Registrierungsinstanzen (RAs), DiBa Mitarbeiter, WWW-Server sowie VPN-Gateways, nicht
jedoch für untergeordnete Zertifizierungsinstanzen (CAs) sowie weitere Registrierungsinstanzen (RAs), oder andere Benutzer erteilen.
Die DiBa-CA unterstützt ausschließlich das Zertifikats-Format X.509v3, welches in aktuellen
Internet-Programmen für unterschiedliche Anwendungen (SSL, S/MIME sowie IPSec) eingesetzt wird.
A.2.1 Rechtliche Bedeutung
Eine Zertifizierung durch die DiBa-CA zieht keinerlei rechtliche Bedeutung nach sich; ein
gesetzlicher Anspruch auf Erteilung eines Zertifikates durch die DiBa-CA besteht nicht. Der
Sinn einer Public Key Infrastruktur liegt in der Schaffung der technischen Voraussetzungen für
eine gesicherte elektronische Kommunikation. Insbesondere die Allgemeine Deutsche Direktbank AG sowie die Projektmitarbeiter (Administratoren) der DiBa-CA übernehmen keine
Form der Gewährleistung. Alle Aufgaben werden von den Projektmitarbeitern nach bestem
Wissen und Gewissen durchgeführt.
Die dieser Policy zu Grunde liegenden Anforderungen an technische Komponenten und Verfahren zur Zertifizierung sind derzeit nicht SigG-konform. Zertifikate der DiBa-CA entsprechen demnach nicht den qualifizierten Zertifikaten nach §2 Nummer 7 des Signaturgesetzes
(SigG).
A.2.2 Die DiBa-Zertifizierungshierarchie
Die Zertifizierungshierarchie der DiBa-CA besteht aus fünf verschiedenen Einheiten:

eine Zertifizierungsinstanz (CA)

zwei Registrierungsinstanzen (RAs)

mehreren Intranet-Servern (WWW)

ein Virtual Private Network Gateway (VPN mit IPSec)

Mitarbeitern (Benutzern- / Client-Zertifikate für SSL, S/MIME sowie IPSec)
Der öffentliche Schlüssel der DiBa-CA ist in einem selbst signierten Zertifikat (Wurzel-Zertifikat), ausgestellt durch die DiBa-CA, enthalten. Alle Teilnehmer der Infrastruktur erhalten die-
120
Anhang A: Zertifizierungsrichtlinien: Policy
ses Wurzel-Zertifikat im Zuge der eigenen Zertifizierung und können somit die Authentizität
und Gültigkeit aller unterhalb der DiBa-CA erteilten Zertifikate überprüfen. Weiterhin wird
das Wurzel-Zertifikat veröffentlicht.
A.2.3 Registrierungsinstanz (RA)
Das Unternehmensnetzwerk der Allgemeinen Deutschen Direktbank AG ist derzeit räumlich
auf zwei Niederlassungen aufgeteilt: Frankfurter sowie Hannover. Die Registrierungsinstanz
(CA) wird ausschließlich in Frankfurt betrieben, ist aber für beide Standorte zuständig. Aufgrund der Tatsache, dass die auch für Hannover zuständige DiBa-CA weit entfernt von den zu
zertifizierenden Mitarbeitern lokalisiert ist, wird vom Einsatz zweier vertrauenswürdiger Registrierungsinstanzen (RAs) Gebrauch gemacht. RAs dürfen lediglich zur Registrierung und
Überprüfung von Benutzern eingesetzt werden.
Die Registrierungsinstanz übernimmt im Auftrag der DiBa-CA die Bearbeitung der Registrierungsaufträge anderer Benutzer vor deren Zertifizierung durch die DiBa-CA. Die DiBa-RA hat
eine rein organisatorische Funktion, sie darf weder das asymmetrische Schlüsselpaar für Mitarbeiter erzeugen, noch kann sie Mitarbeiter-Zertifikate erteilen oder widerrufen. Um einen
Missbrauch auszuschließen, muss jede elektronische Übermittlung von Identitätsinformationen des Mitarbeiters an die DiBa-CA durch die DiBa-RA digital signiert werden.
Empfängt die DiBa-CA den Zertifizierungswunsch eines Mitarbeiters durch eine vertrauenswürdige DiBa-RA, hat sie zunächst die Gültigkeit der DiBa-RA-Signatur zu verifizieren. Nach
diesem Kontakt wird das von der DiBa-CA neu ausgestellte Zertifikat an die DiBa-IS und von
dieser, unter Beachtung der Regeln aus Kapitel [A.4.1], weiter an den Mitarbeiter übermittelt.
A.3
Sicherheit der DiBa-CA-Ausstattung
Durch die Teilnahme an einer Public Key Infrastruktur entstehen für Mitarbeiter bestimmte
Anforderungen hinsichtlich der Sicherheit der eingesetzten Hard- und Software einerseits
sowie dem verantwortungsvollen Umgang mit kryptographischen Schlüsseln andererseits. Die
Anforderungen an die DiBa-CA sind dabei naturgemäß höher, da der Missbrauch eines CASchlüssels allen untergeordneten Zertifikaten die Vertrauenswürdigkeit entziehen würde.
A.3.1 Sicherheitsanforderungen an die DiBa-CA
Folgende Anforderungen werden an die DiBa-CA gestellt:

Für die Dienste der DiBa-CA wird ein Rechner ohne jeglichen Netzanschluss eingesetzt. Der Rechner befindet sich im Rechenzentrum der Allgemeinen Deutschen
Direktbank AG in der Niederlassung Frankfurt. Zu dieser Zone haben nur ausgewählte Mitarbeiter Zugang.

Jeglicher Datenaustausch mit vernetzten Rechnern wird von Mitarbeitern der
DiBa-CA per Wechselmedium vorgenommen; es findet keine automatisierte Bearbeitung der Daten statt. Sämtliche schlüsseltragenden Datenträger werden in unbenutztem Zustand an einem sicheren Ort verwahrt.

Geheime Schlüssel der DiBa-CA zur Erzeugung digitaler Signaturen werden von
121
den DiBa-CA-Mitarbeitern ausschließlich auf dem dedizierten Rechner erzeugt
und verwendet sowie auf externer Peripherie (Diskette bzw. Chipkarte) gespeichert. Der Zugriff auf diese Peripherie wird durch Passworte bzw. PINs geschützt,
welche nur den DiBa-CA-Mitarbeitern bekannt sind und niemals im Klartext abgelegt werden. Die Peripherie wird nicht auf anderen Rechnern eingesetzt.

Mit geheimen Signatur-Schlüsseln der DiBa-CA werden ausschließlich Mitarbeiter-Schlüssel (bzw. Server-Schlüssel) und Widerrufslisten (CRLs) unterschrieben.
Für jegliche Standard-Kommunikation werden geheime Signatur-Schlüssel nicht
verwendet.

Asymmetrische Schlüsselpaare der DiBa-CA zur Erzeugung von Signaturen haben
eine Länge von mindestens 2048 Bit RSA.

Die Schlüsselgenerierung erfolgt auf dem dedizierten DiBa-CA-Rechner.

Sämtliche bei der Zertifizierung anfallenden Daten werden von den DiBa-CA-Mitarbeitern vertraulich behandelt. Die für die DiBa-CA geltenden gesetzlichen
Datenschutzbestimmungen werden eingehalten.
A.3.2 Sicherheitsanforderungen an die DiBa-RA
Folgende Anforderungen werden an die von der DiBa-CA eingesetzte DiBa-RA gestellt:

Für die Dienste der DiBa-RA wird ein Rechner eingesetzt, der in geeigneter Weise
vor missbräuchlicher Benutzung geschützt ist.

Geheime Schlüssel der DiBa-RA zur Erzeugung digitaler Signaturen werden von
den CA-Mitarbeitern ausschließlich auf dem dedizierten Rechner verwendet. Der
Zugriff auf den geheimen Schlüssel wird durch Passworte bzw. PINs geschützt,
welche nur den DiBa-RA-Mitarbeitern bekannt sind und niemals im Klartext abgelegt werden.

Asymmetrische Schlüsselpaare der DiBa-RA zur Erzeugung von Signaturen haben
eine Länge von mindestens 2048 Bit RSA.
A.3.3 Sicherheitsanforderungen an Benutzer
Benutzer im Sinne dieser Policy sind ausschließlich einzelne Mitarbeiter der Allgemeinen
Deutschen Direktbank AG.
Der geheime Schlüssel des Benutzers muss ausreichend vor Missbrauch durch Unbefugte
geschützt und darf nicht weitergegeben werden; hierfür ist jeder Benutzer selbst verantwortlich.
Der Zugriff auf den geheimen Schlüssel wird durch nicht-triviale Passworte (Mindestlänge: 8
Zeichen) bzw. einer PIN geschützt, welche nur den jeweiligen Mitarbeitern bekannt sind. Passwort bzw. PIN dürfen niemals an andere Personen weitergegeben oder im Klartext abgelegt
bzw. über ungeschützte Netzwerkverbindungen gesendet werden.
122
Sicherheitsanforderungen an Benutzer (SSL, S/MIME, IPSec)

Das asymmetrische Schlüsselpaar des Benutzers muss eine minimale Länge von
1024 Bit RSA (oder vergleichbares Niveau) aufweisen. Die Wahl größerer Schlüssellängen wird dringend empfohlen und richtet sich nach der technischen Verfügbarkeit.

Das Verzeichnis bzw. die Dateien, in dem die kryptographischen Schlüssel von der
Applikation gespeichert werden, sind vom Benutzer nach Maßgabe der Möglichkeiten vor unbefugtem Missbrauch zu schützen. Dies kann z. B. durch das Setzen
bestimmter Zugriffsrechte geschehen, sofern das eingesetzte Betriebssystem dies
unterstützt. Die Speicherung der kryptographischen Schlüssel auf externen Datenträgern (z. B. Diskette) wird dringend empfohlen.
Sicherheitsanforderungen an WWW-Server und VPN-Gateways
A.4

Das asymmetrische Schlüsselpaar für WWW-Server muss eine minimale Länge
von 1024 Bit RSA (oder vergleichbares Niveau) aufweisen. Die Wahl größerer
Schlüssellängen wird dringend empfohlen und richtet sich nach der technischen
Verfügbarkeit.

Da der geheime Schlüssel üblicherweise fest auf den Server-Rechnern gespeichert
ist, ist der Rechner samt entsprechender Dateien und Verzeichnisse durch geeignete (auch physikalische) Maßnahmen vor missbräuchlicher Benutzung zu schützen. Dies sollte insbesondere durch das Setzen entsprechender Zugriffsrechte
geschehen.
Zertifizierungsregeln
Dieser Abschnitt beschreibt technische und organisatorische Richtlinien und Prozeduren, die
vor einer Zertifizierung von Benutzern zu beachten sind.
Sowohl Zertifizierungsinstanzen als auch Mitarbeiter werden innerhalb einer X.509-Hierarchie mit eindeutigen Namen – sog. Distinguished Names (DNs) – bezeichnet, deren korrekter
Wahl eine besondere Bedeutung zukommt. Die Wahl der Namen ist in Abschnitt [A.8]
beschrieben.
Jedes X.509v3-Zertifikat muss eine Seriennummer beinhalten, die von der DiBa-CA vergeben
wird. Dabei hat die DiBa-CA bei der Zertifizierung zu gewährleisten, dass von ihr keine Seriennummer mehrfach vergeben wird.
Um unerlaubte Zertifizierungswünsche zu erkennen, überzeugt sich die DiBa-CA vor jeder
Zertifizierung in geeigneter Weise durch technische und organisatorische Maßnahmen von der
Identität sowie Autorisierung desjenigen Mitarbeiters, welcher eine Zertifizierung wünscht. In
keinem Fall werden Zertifizierungswünsche automatisiert bearbeitet.
Schlüsselpaare, welche von der DiBa-CA zertifiziert werden sollen, werden ausschließlich von
der DiBa-CA, unter Einhaltung der Mindestlängen für kryptographische Schlüssel (Abschnitt
123
[A.3]), selbst generiert. Es werden mit Ausnahme des WWW-Schlüssels keine benutzereigenen Schlüssel von der DiBa-CA zertifiziert.
Bei der Schlüsselerzeugung wird von der DiBa-CA ein Passwort für den Widerruf des Zertifikates (siehe Abschnitt [A.6]) für den Mitarbeiter erzeugt.
Es werden getrennte Schlüsselpaare zum Verschlüsseln und Signieren erzeugt. Schlüssel dürfen nur für den jeweils für sie vorgesehenen Einsatzzweck verwendet werden. Für jedes
Schlüsselpaar wird ein eigenes Zertifikat erzeugt. Im Zertifikat selbst ist angegeben, welcher
Verwendungszweck dem jeweiligen Schlüsselpaar zugeordnet ist.
Das neu ausgestellte Zertifikat wird dem Zertifikatnehmer unmittelbar nach der Zertifizierung
beispielsweise per Email oder über eine URL übermittelt; der ebenfalls generierte private
Schlüssel und das Widerrufspasswort müssen aber persönlich übergeben werden. Der Zertifikatnehmer ist angehalten, die Korrektheit, der im eigenen Zertifikat enthaltenen Informationen, sofort zu verifizieren. Ein LAN-Administrator der DiBa nimmt anschließend die
Installation des DiBa-CA-Zertifikates, des Benutzerzertifikates sowie des privaten Schlüssels
vor und überzeugt sich davon, dass die geforderten Sicherungsmaßnahmen des Rechners eingehalten sind.
Zertifikate werden in der Regel nicht automatisch durch die DiBa-CA erneuert; Anträge auf
Re-Zertifizierung sind gegebenenfalls bei der zuständigen DiBa-RA zu stellen.
Zertifikat-Erweiterungen
X.509v3-Zertifikate zeichnen sich dadurch aus, dass jedes Zertifikat beliebige Erweiterungen
(certificate extensions) enthalten kann. Jede Erweiterung kann darüber hinaus durch das Setzen eines bestimmten Bits (critical flag) als besonders signifikant gekennzeichnet werden.
Zertifikat-Erweiterungen werden von der DiBa-CA bei der Zertifizierung in das Zertifikat aufgenommen. Es werden dabei nur Zertifikate nach X.509v3 erzeugt und verbreitete StandardErweiterungen unterstützt.
A.4.1 Regeln für die Zertifizierung von Benutzern
Zertifizierung von Benutzern
Mitarbeiter, welche zertifiziert werden möchten, generieren selbst kein eigenes asymmetrisches Schlüsselpaar, sondern übermitteln nur den Zertifizierungswunsch an die DiBa-RA. Von
der RA wird dieser Zertifizierungswunsch, zum Schutz digital signiert, an die DiBa-CA weitergeleitet; die DiBa-CA verifiziert vor der Zertifizierung die digitale Signatur der DiBa-RA.
Das asymmetrische Schlüsselpaar des Mitarbeiters wird ausschließlich von der DiBa-CA
erzeugt; wobei von der DiBa-CA die in Kapitel [A.3.1] beschriebenen Sicherheitsanforderungen einzuhalten sind.
Die DiBa-RA hat vor der Zertifizierung in geeigneter Weise die Eindeutigkeit folgender Informationen zu überprüfen:

Zugehörigkeit des Rechners zur Allgemeinen Deutschen Direktbank AG
124

Identität des Mitarbeiters
Zertifikate nach X.509v3 für Mitarbeiter haben eine Gültigkeitsdauer von maximal einem Jahr.
Regeln für die Zertifizierung von RAs
Die DiBa-RA besteht im Wesentlichen aus normalen Mitarbeitern, die im besonderen Auftrag
der DiBa-CA als Registrierungsinstanz (RA) fungieren.
Ein DiBa-RA-Zertifikat unterscheidet sich nicht von einem üblichen Mitarbeiter-Zertifikat.
Für die Zertifizierung von DiBa-RAs gelten daher die Regeln für die Zertifizierung von Benutzern.
Zusätzliche Regeln für die Zertifizierung von WWW-Server und VPN-Gateways
Zusätzlich zu den oben beschriebenen Zertifizierungsregeln für Benutzer gelten besondere
Richtlinien bei der Zertifizierung von WWW-Servern, welche nicht einer einzelnen Person,
sondern einem Rechner (-namen) zugeordnet sind.
Sollen WWW-Server zertifiziert werden, hat ein Administrator dieses Servers den Zertifizierungswunsch an die zertifizierende Instanz zu übermitteln. Diese hat vor der Zertifizierung in
geeigneter Weise die Eindeutigkeit folgender Informationen zu überprüfen:
A.5

Zugehörigkeit des Servers zur Allgemeinen Deutschen Direktbank AG

Identität des Server-Administrators
Management von Zertifikaten
Alle Teilnehmer der DiBa-Zertifizierungshierarchie erklären sich grundsätzlich mit der Veröffentlichung ihres Zertifikates einverstanden.
Die DiBa-IS ist für die Bereitstellung aller selbst ausgestellten Zertifikate verantwortlich. Von
der DiBa-CA neu ausgestellte Zertifikate und CRLs (siehe Abschnitt [A.6]) müssen innerhalb
einer angemessenen Zeitspanne (üblicherweise innerhalb eines Werktages) veröffentlicht werden.
Für die Bereitstellung von Zertifikaten werden von der DiBa-IS Informationsdienste (Verzeichnisse) eingerichtet (WWW- oder LDAP-Server), deren Aufgabe die öffentliche Verteilung von Zertifikaten und CRLs ist.
A.6
Die DiBa-CA kann von ihr erteilte Zertifikate jederzeit vor Ablauf der Gültigkeitsdauer ohne
Angabe expliziter Gründe widerrufen. Ursachen für den Widerruf eines Zertifikates können
beispielsweise das Bekanntwerden missbräuchlicher Handlungen eines DiBa-CA-Administrators oder das Nichtbefolgen einzelner Richtlinien dieser Policy sein. Andere Gründe sind beispielsweise das Ausscheiden eines Mitarbeiters aus der Firma oder die Änderung des Namens.
125
Jeder Zertifikatnehmer kann von der für ihn zuständigen DiBa-RA verlangen (notfalls auch
ohne Angabe von Gründen), dass diese ein für ihn ausgestelltes Zertifikat widerruft. Die DiBaCA hat diesem Verlangen innerhalb einer angemessenen Zeitspanne nachzukommen, sobald
sie sich durch geeignete Schritte davon überzeugt hat, dass der Antrag vom Zertifikatnehmer
selbst stammt bzw. von ihm autorisiert ist. Die Autorisierung kann an Hand des bei der Zertifizierung ausgegebenen Widerrufspasswortes erfolgen. Werden der Missbrauch oder die Kompromittierung des eigenen geheimen Schlüssels bekannt, muss jeder Teilnehmer unverzüglich
die zuständige DiBa-RA benachrichtigen und den Widerruf des eigenen Zertifikates veranlassen.
Widerruf von X.509v3-Zertifikaten
Alle widerrufenen Zertifikate werden von der DiBa-CA auf einer Widerrufsliste (Certificate
Revocation List, CRL) veröffentlicht, welche allen Mitarbeitern zur Verfügung gestellt wird,
um widerrufene Zertifikate nicht irrtümlicherweise zu benutzen. Diese CRL enthält u. a. das
Datum der CRL-Herausgabe (z. B. in Form eines Zeitstempels) und wird von der DiBa-CA
digital signiert. Widerrufene Zertifikate bleiben solange auf der CRL, bis die ursprüngliche
Gültigkeitsdauer überschritten wurde. Dabei werden auch solche Zertifikate auf einer CRL
veröffentlicht, gegen deren Veröffentlichung bei der Zertifizierung widersprochen wurde.
Einmal widerrufene Zertifikate können nicht erneuert oder verlängert werden. Jedoch hat jeder
Mitarbeiter grundsätzlich die Möglichkeit, ein neues Zertifikat zu beantragen.
Nach der Aufnahme des Betriebs mit einer leeren CRL muss die DiBa-CA in regelmäßigen
Abständen (z. B. wöchentlich) neue CRLs herausgeben, auch wenn in der Zwischenzeit keine
weiteren Zertifikate widerrufen wurden. Alte CRLs werden archiviert, um die Gültigkeit von
Zertifikaten auch zu einem späteren Zeitpunkt verifizieren zu können.
Für die Bereitstellung von CRLs werden von der DiBa-CA Informationsdienste (Verzeichnisse) eingerichtet, deren Aufgabe die öffentliche Verteilung von Zertifikaten und CRLs (vgl.
Abschnitt [A.5]) ist.
A.7
Schlüsselhinterlegung
Kopien der geheimen Schlüssel eines für Verschlüsselung vorgesehenen asymmetrischen
Schlüsselpaares werden von der DiBa-CA für Widerherstellungszwecke auf sichere Weise
archiviert. Asymmetrische Schlüsselpaare, welche ausschließlich für die Erstellung von Signaturen vorgesehen sind, betrifft diese Maßnahme nicht, da signierte Dokumente auch bei Verlust
des Signaturschlüssels weiterhin gelesen und verifiziert werden können. Aus diesem Grund
werden getrennte Zertifikate für digitale Signaturen und Verschlüsselung ausgegeben.
Alle Kopien geheimer Signaturschlüssel werden direkt nach Übergabe an den Mitarbeiter auf
Seiten der DiBa-CA endgültig gelöscht.
126
A.8
Regeln für die Namensgebung
Wahl einer X.509v3-Benutzer-ID
Allen Mitarbeitern wird ein eindeutiger Name (Distinguished Name, DN) nach X.500 zugeordnet, welcher bei der Ausstellung eines Zertifikates für einen Mitarbeiter als dessen Subjektname zu verwenden ist. Ein DN enthält eine Folge von eindeutig kennzeichnenden
Namensattributen, durch die alle Mitarbeiter einer Hierarchie referenziert werden können. Auf
unübliche Sonderzeichen innerhalb dieses Namens wird aus Gründen der Interoperabilität verzichtet. Die deutschen Umlautbuchstaben ä, ö, ü sowie ß werden durch die übliche Umschreibung ae, oe, ue sowie ss, andere akzentuierte Buchstaben durch entsprechende nichtakzentuierte Buchstaben ersetzt (beispielsweise é durch e).
Die DNs aller Mitarbeiter unterhalb der DiBa-CA enthalten die Attribute C=DE und O=Allgemeine Deutsche Direktbank AG. Vor der Zertifizierung wird die Korrektheit und Eindeutigkeit des angegebenen Namens von der DiBa-CA überprüft; es darf kein Name mehrfach
vergeben werden.
Der Name jedes Mitarbeiters soll folgendem Schema folgen:
C
O
L
OU
CN
EMAIL
=
=
=
=
=
=
DE,
Allgemeine Deutsche Direktbank AG,
<Stadt>,
<Abteilung>,
<Eindeutiger Name>,
<Email-Adresse>
Alternative Namen können bei Bedarf über Zertifikat-Erweiterungen im Zertifikat aufgenommen werden. Die DiBa-CA hat in diesem Fall vor der Zertifizierung den Inhalt dieser Erweiterungen auf Korrektheit zu überprüfen.
Das Attribut L= ist für alle Mitarbeiter obligatorisch und kommt genau einmal vor. Es enthält
den jeweiligen Unternehmensstandort (derzeit entweder L=Frankfurt oder L=Hannover).
Das Attribut OU= ist für alle Mitarbeiter obligatorisch und kommt genau einmal vor. Es enthält
die Abteilung, in der der Mitarbeiter beschäftigt ist (wie beispielsweise OU=IT).
Das Attribut CN= ist für alle Mitarbeiter obligatorisch und kommt genau einmal vor. Es enthält
den vollständigen Namen des Mitarbeiters.
Das Attribut EMAIL= ist obligatorisch und enthält eine gültige, eindeutige Email-Adresse des
Mitarbeiters innerhalb der Domain diba.de.
Kommt ein Name innerhalb der Allgemeinen Deutschen Direktbank AG mehrmals vor, ist es
die Aufgabe der DiBa-RA, durch geeignete Namenszusätze eindeutige Namen zu wählen (eine
Möglichkeit ist z. B. die innerhalb des DiBa Netzwerkes eindeutig vergebenen Login-ID). Die
DiBa-RA ist ferner dafür verantwortlich, die Zugehörigkeit des Mitarbeiters zu der betreffenden Abteilung zu überprüfen und sicherzustellen, dass alle zertifizierten Mitarbeiter über
127
unterschiedliche Namen verfügen.
Regeln für RAs
Da Registrierungsinstanzen innerhalb der Zertifizierungshierarchie den gleichen Status besitzen wie Mitarbeiter, unterscheidet sich auch die Wahl der zugehörigen Namen nicht.
Zusätzliche Regeln für WWW-Server und VPN-Gateways
Zertifikate für WWW-Server müssen im Attribut CN= einen eindeutigen Hostnamen enthalten.
Dieses Attribut darf keine Platzhalter (sog. Wildcards) und keine numerischen IP-Adressen
enthalten.
Das optionale Attribut EMAIL= muss eine gültige Email-Adresse, beispielsweise die des Server-Administrators, enthalten.
A.9
Verschiedenes
Dieses Dokument entstand im Rahmen einer Diplomarbeit an der TU-Darmstadt. Es wird
keine Haftung für die Korrektheit, Vollständigkeit oder Anwendbarkeit der enthaltenen Informationen und der vorgeschlagenen Maßnahmen übernommen. Ferner kann keine Haftung für
eventuelle Schäden, entstanden durch die Inanspruchnahme der Dienste der DiBa-CA, übernommen werden. Die Verantwortung für die Verwendung der oben beschriebenen Verfahren
und Programme liegt allein bei den die Installation durchführenden Personen.
Die DiBa-CA behält sich vor, Zertifizierungswünschen nicht nachzukommen. Ferner kann
keine Garantie für die Verfügbarkeit der DiBa-CA-Dienste übernommen werden. Aufgrund
des Diplomarbeitsstatus besteht derzeit keine Möglichkeit, die Dienste der DiBa-CA auf einer
24-Stunden-Basis anzubieten.
Dokumentation und Datenschutz
Alle Arbeiten im Rahmen dieser Policy werden, soweit technisch durchführbar, dokumentiert.
Die DiBa-CA muss die bei der Zertifizierung anfallenden Daten vertraulich behandeln und die
für sie geltenden Datenschutzrichtlinien einhalten.
Sämtliche Zertifikatnehmer stimmen der Speicherung und Verarbeitung ihrer bei der Zertifizierung anfallenden Daten durch die DiBa-CA zu.
Erklärung der Teilnehmer
Alle Teilnehmer der Public Key Infrastruktur haben vor ihrer Zertifizierung handschriftlich
eine Erklärung zu unterzeichnen, in der sie über ihre Rechte und Pflichten sowie über die Risiken und Gefahren beim Einsatz von Public Key-Systemen aufgeklärt wurden. Diese Erklärung, wird von der DiBa-CA verwahrt und beinhaltet in erster Linie die Zustimmung zu den
Richtlinien dieser Policy.
128
Anhang B
Installationsbeschreibungen
Dieses Kapitel liefert Hinweise zur Einrichtung bestimmter Softwarekomponenten, welche für
den Betrieb der Public Key Infrastruktur notwendig sind. Neben einer Erläuterung der Konfiguration des Internet Information Servers (IIS) sowie Hinweisen zur Installation von Widerrufslisten in den Netscape Communicator, wird das Einrichten der MMC für eine komfortable
Verwaltung von Zertifikaten unter Windows 2000 gezeigt.
Die Motivation für dieses Kapitel lieferten häufig gestellte Fragen von Beteiligten aus dem
Umfeld dieser Arbeit.
B.1
Erzeugen eines Serverzertifikates für den IIS 4
Im Folgenden wird die Generierung und Zertifizierung eines SSL-Serverschlüssels für den
Internet Information Server 4.0 unter Windows NT SP6a mithilfe von FlexiTrust 2.0 beschrieben.
Die Generierung des Schlüssels erfolgt durch den in den Server integrierten Schlüsselmanager.
Die im Anschluss an die Schlüsselgenerierung erzeugte Zertifizierungsanforderung wird an die
Software FlexiTrust übergeben, diese übernimmt die eigentliche Zertifizierung. Abschließend
wird das von FlexiTrust signierte Serverzertifikat in den IIS-Schlüsselmanager importiert:

Den IIS4-Schlüsselmanager hat Microsoft gut versteckt, ihn erreicht man über die
Eigenschaften des SSL-Verzeichnisses, von dort aus müssen folgende Dialoge ausgewählt werden: Verzeichnissicherheit / Sichere Kommunikation / Bearbeiten... /
Schlüssel-Manager... dort schließlich auf Neuen Schlüssel erstellen klicken.

Als Übergabemechanismus an FlexiTrust muss Anforderung als Datei speichern,
die an eine Instanz gesendet wird ausgewählt werden.

In das Feld Schlüsselname den Domainnamen des Webservers angeben.

Das zu vergebende Kennwort wird später für die Installation des generierten Zertifikates wieder benötigt.
129

Der einzig sinnvolle Wert für die Bitlänge beim getesteten IIS 4 beträgt 1024 Bit,
höhere Schlüssellängen wären wünschenswert (beispielsweise 2048 Bit).

In das Feld Allgemeiner Name wieder den Domainnamen des Webservers eintragen.

Nach Abschluss des Dialoges kann die erstellte Base-64 codierte PKCS#10-Anforderungsdatei an FlexiTrust zur Bearbeitung übergeben werden. Dieses konvertiert
die Anforderungsdatei mithilfe von OpenSSL in ein von FlexiTrust lesbares Format und zertifiziert anschließend den enthaltenen öffentlichen Schlüssel.

Nach dem Empfang des Zertifikates durch FlexiTrust wird die PEM-Version des
Zertifikates (*.pem.crt) im Schlüsselmanager beim zugehörigen Schlüssel installiert.

Anschließend für den Schlüssel eine Serververbindung zur Anschlussnummer 443
(SSL) einrichten.
B.2
Installation von CA-Zertifikaten im IIS 4
Im Folgenden wird die Installation von CA-Zertifikaten im Internet Information Server 4.0
unter Windows NT SP6a1 beschrieben.
Windows NT und Windows 2000 verfügen über einen Assistenten zur Installation von Zertifikaten, Import-Assistent für die Zertifikatsverwaltung genannt. Für die übliche Verwendung von
Zertifikaten in Clientprogrammen reicht das Akzeptieren der vom Assistenten gemachten Vorschläge aus, Zertifikate werden dann automatisch in den richtigen Speicher der Registry des
Benutzers importiert. Der Internet Information Server allerdings verlangt CA-Zertifikate im
entsprechenden Speicher direkt auf dem lokalen Computer.

Im Windows Explorer über das Kontextmenü der Zertifikatsdatei (*.cer) den
Menüpunkt Zertifikat installieren anwählen. Dies ruft den Import-Assistenten für
die Zertifikatsverwaltung auf.

Auf der zweiten Seite bei der Frage nach dem gewünschten Zertifikatsspeicher,
Alle Zertifikate in folgendem Speicher speichern auswählen und auf Durchsuchen
klicken. Siehe Abbildung 1.
1. Auf die Installation im Zusammenhang mit früheren Service Packs soll an dieser Stelle nicht weiter
eingegangen werden, das Dokument „How to Configure Certificate Server for Use with SSL on IIS“
[MS00-2] von Microsoft, beschreibt die Vorgehensweise in solch einem Fall.
130
Anhang B: Installationsbeschreibungen
Abbildung 1 IIS4: Importassistent der Zertifikatsverwaltung

Es öffnet sich eine Auswahlliste wie in Abbildung 2 gezeigt. In dieser Physikalischen Speicher anzeigen aktivieren und Vertrauenswürdige Stammzertifizierungsstellen1 öffnen, dort den Punkt Lokaler Computer auswählen.
Abbildung 2 IIS4: Wahl des richtigen Zertifikatsspeichers

Der Assistent verfügt nun über alle notwendigen Eingaben und kann beendet werden.
Neben den bereits im IIS fest voreingestellten Zertifikatsaustellern wie Verisign oder RSA Data
1. Dies gilt für Root-CA Zertifikate. Für Zertifikate untergeordneter CAs ist „Zwischenzertifizierungsstellen“ zu öffnen.
131
Security sollte nach der Installation des Root-CA Zertifikates nun auch die neue Root-CA dem
IIS als vertrauenswürdiger Zertifikatsaussteller für Client-Zertifikate bekannt sein. Siehe
Abbildung 14. Nur Client-Zertifikate von den IIS-bekannten Zertifikatsausstellern sind für clientseitige SSL-Authentifizierung zugelassen. Wurde der Assistent nicht korrekt ausgeführt,
beispielsweise der Zertifikatsspeicher automatisch - und damit falsch - gewählt, kann eine
SSL-Verbindung über den IIS nur mit Server-Zertifikaten abgesichert werden. Client-Zertifikate weist dieser dann kommentarlos (ohne weitere Fehlermeldung) als unsicher ab, da ihm im Gegensatz zum Webbrowser des Clients - der Zertifikatsaussteller unbekannt ist. Der Dialog zur Auswahl des für die SSL Verbindung zu nutzenden Client-Zertifikates im Webbrowser
bleibt dann leer. Selbst wenn gültige Clientzertifikate vorhanden sind, welche im Webbrowser
des Clients für SSL-Verbindungen des angemeldeten Benutzers registriert sind.
Wie Client-Zertifikate in Webbrowsern registriert werden, beschreibt Abschnitt [5.4].
Abbildung 3 IIS4: zugelassene Root-CAs für die Ausstellung von Clientzertifikaten
Nach dem obligatorischen Neustart des IIS kann folgendermaßen überprüft werden, ob der
Vorgang erfolgreich war und der hinzugefügte Zertifikatsaussteller dem IIS nun bekannt ist:

Über die Eigenschaften des SSL-Verzeichnisses folgende Dialogfolge aufrufen:
Verzeichnissicherheit / Sichere Kommunikation / Bearbeiten.... Dort schließlich die
Punkte Clientzertifikate verlangen sowie Client-Zertifikatszuordnungen aktivieren
anschalten.

Über einen Klick auf Bearbeiten erreicht man den Dialog für die Zuordnung von
Client-Zertifikaten an NT-Benutzerkonten. Auf der Seite Weitere Optionen nun
Clientzertifikatsübereinstimmung (mit Platzhalterzeichen) aktivieren und eine temporäre Regel mittels Hinzufügen... erstellen.

Im Regelfenster unter Herausgeber den Punkt Ausgewählte Zertifikatsaussteller
aktivieren und auf Auswählen klicken.
132
Anhang B: Installationsbeschreibungen

B.3
Der Dialog Instanzen für Clientzertifikate (siehe Abbildung 3) listet alle dem IIS
bekannten, vertrauten Zertifikataussteller auf, darunter sollte sich nun auch der
Aussteller des zuvor installierten CA-Zertifikates befinden. Die Testregel kann
anschließend wieder gelöscht werden.
Installation von Widerrufslisten (CRLs) im Netscape
Communicator
Im Folgenden wird die Installation von X.509v1-CRLs über HTTP-Server in den Netscape
Communicator 7.x beschrieben. X.509v2-CRLs werden nicht unterstützt.

CRLs müssen vom HTTP-Server mit dem MIME-Type application/x-pkcs7-crl im
DER-Format gesendet werden.

Mit dem Aufrufen der URL der Widerrufsliste wird diese automatisch, ohne weitere Nachfrage heruntergeladen und ebenso automatisch ohne Meldung installiert.

Über den Menüpunkt Communicator / Tools / Security Info steht nach erfolgreicher
Installation der ersten CRL im Bereich Signers die Schaltfläche View/Edit CRL’s
zur Verfügung. Darüber können vorhandene CRLs angezeigt oder erneuert bzw.
die Downloadadresse nachträglich editiert werden.
B.4
Installation des MMC Zertifikat Snap-In
Im Folgenden wird die Installation des MMC Zertifikat Snap-Ins in Windows 2000 beschrieben.

Der Aufruf der Microsoft Management Console (MMC) erfolgt über Start / Ausführen..., dort MMC eingeben und OK klicken.

Das Snap-In für Zertifikate wird anschließend über Konsole /
Snap-In hinzufügen/entfernen / hinzufügen... / Zertifikate hinzugefügt.

Zur Auswahl stehen drei Varianten des Zertifikat Snap-Ins (Dieses Snap-In verwaltet die Zertifikate für):

Eigenes Benutzerkonto,

Dienstkonto

Computerkonto
Es empfiehlt sich die Varianten Eigenes Benutzerkonto und Computerkonto beide
(nacheinander) hinzuzufügen.
133
134
Anhang C
Abkürzungsverzeichnis
AH
Authentication Header
AES
Advanced Encryption Standard
ASP
Active Server Pages
BSI
Bundesamt für Sicherheit in der Informationstechnik
CA
Certification Authority (Zertifizierungsinstanz)
CPS
Certification Practice Statement
CRL
Certificate Revocation List (Widerrufsliste)
CSP
Cryptographic Service Provider
CSR
Certificate Signing Request (Zertifizierungswunsch)
DAP
Directory Access Protocol (X.500)
DER
Distinguished Encoding Rules
DES
Data Encryption Standard
DFN
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
DH
Diffie Hellman Algorithm
DiBa
Allgemeine Deutsche Direktbank AG
DIR
Directory (Verzeichnis)
DMZ
Demilitarized Zone (Entmilitarisierte Zone)
DN
Distinguished Name (X.500- oder LDAP-Name)
DSig
Digital Signature Initative
DSP
Directory System Protocol
DSS
Digital Signature Standard
135
EES
Escrowed Encryption Standard
ESP
Encapsulated Security Payload
FTP
File Transfer Protokoll
GMD
Gesellschaft für mathematische Datenverarbeitung
HTML
Hyper Text Markup Language
HTTP
Hyper Text Transport Protokoll
HTTPS
Secure HTTP
ID
Identifier
IDEA
International Data Encryption Algorithm
IETF
Internet Engineering Task Force
IKMP
Internet Key Management Protokoll
IIS
Internet Information Server
IMAP
Internet Message Access Protokoll
ING
Internationale Nederlanden Group
IP
Internet Protokoll
IPSec
IP Security
IPSP
IP Security Protokoll
IKE
Internet Key Exchange
ISDN
Integrated Services Digital Network
ISO
International Organization for Standardization
ISP
Internet Service Provider
IT
Informationstechnologie
JCA
Java Cryptographic Architecture
JDBC
Java Database Connectivity
KEA
Key Exchange Algorithm
KG
Key Generation (Schlüsselgenerierung)
LAN
Local Area Network
LDAP
Lightweight Directory Access Protocol
LDAPS
Secure LDAP
MAC
Message Authentication Code
MAPI
Messaging Application Programming Interface
MD4
Message Digest 4
136
Anhang C: Abkürzungsverzeichnis
MD5
Message Digest 5
MIME
Multipurpose Internet Mail Extensions
MIT
Massachusetts Institute of Technology
NSA
National Security Agency
OSI
Open System Interconnection
OWA
Outlook Web Access
PCA
Policy Certification Authority (Wurzelinstanz)
PGP
Pretty Good Privacy
PIN
Personal Identification Number
PKCS#7
Public Key Cryptography Standard #7 (Cryptographic Message Syntax
Standard)
PKCS#10
Public Key Cryptography Standard #10 (Certification Request Syntax
Standard)
PKCS#11
Public Key Cryptography Standard #11 (Cryptographic Token Interface
Standard)
PKCS#12
Public Key Cryptography Standard #12 (Personal Information Exchange
Syntax Standard)
PKI
Public Key Infrastruktur
POP3
Post Office Protokol Version 3
PPP
Point-to-Point Protokol
PS
Personalization (Personalisierungseinheit)
PSE
Personal Security Environment
RA
Registration Authority (Registrierungsinstanz)
RC2
Rivest Cipher 2 (symmetrischer Verschlüsselungsalgorithmus der RSA)
RC4
Rivest Cipher 4
RegTP
Regulierungsbehörde für Telekommunikation und Post
RFC
Request For Comments
RSA
Rivest, Shamir, Adleman (Namen der Entwickler des RSA-Algorithmus)
S/MIME
Secure/Multipurpose Internet Mail Extensions
Satos
Satellite Observation
SGC
Server Gated Cryptography
SHA
Secure Hash Algorithm
SKIP
Simple Key Management Protokoll
137
SigG
Signaturgesetz
SigV
Signaturverordnung
SMTP
Simple Mail Transfer Protokol
SSL
Secure Sockets Layer
TCP
Transmission Control Protokol
TLS
Transport Layer Security
Tripple-DES
DES dreimal angewendet
TTP
Trusted Third Party
URL
Uniform Resource Locator
VIP
Very Important Person
VPN
Virtual Private Network
WAN
Wide Area Network
WWW
World Wide Web
X.500
Weltweit verteilter, hierarchischer Verzeichnisdienst
X.509
Zertifizierungsinfrastruktur basierend auf X.500
138
Anhang D
Literaturverzeichnis
[AdaLlo99]
CARLISLE ADAMS, STEVE LLOYD, Understanding Public-Key
Infrastructure, Macmillan Technical Publishing USA, 1999.
[AnSTanen96]
ANDREW S. TANENBAUM, Computer Networks, Prentice Hall, 1996.
[BJKoops01]
BERT-JAAP KOOPS, Crypto Law Survey, Overview per country,
<URL: http://cwis.kub.nl/~frw/people/koops/cls2.htm>, 2001.
[BrSchn96-1]
BRUCE SCHNEIER, Angewandte Kryptographie. Protokolle, Algorithmen und Sourcecode in C, Addison-Wesley 1996.
[BrSchn98-1]
BRUCE SCHNEIER, MUDGE, Cryptanalysis of Microsoft’s Point-toPoint Tunneling Protocol (PPTP), Proceedings of the 5th ACM
Conference on Communications and Computer Security, ACM
Press 1998.
[BrSchn99-1]
BRUCE SCHNEIER, MUDGE, Cryptanalysis of Microsoft’s PPTP
Authentication Extensions (MS-CHAPv2), <URL: http://
www.counterpane.com/pptpv2.pdf>, 1999.
[BrSchn99-2]
BRUCE SCHNEIER, NIELS FERGUSON, A Cryptographic Evaluation
of IPsec, <URL: http://www.counterpane.com/ipsec.pdf>, 1999.
[BSI97]
BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK,
Ende-zu-Ende-Sicherheit für elektronischen Dokumententausch Infrastruktur und Leitlinien für die Bundesverwaltung, <URL:
http://www.bsi.bund.de/literat/sphinx/endeende.htm>, 1997.
[BSI98]
BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK,
Schnittstellenspezifikation zur Entwicklung interoperabler Verfahren und Komponenten nach SigG/SigV - Zertifikate, 1998.
[CHR00]
HEISE, Bürgerrechtler: Studie sollte FBI-Schnüffel-Tool "reinwaschen", <URL: http://www.heise.de/newsticker/data/chr23.11.00-000/>, Heise Online News, 2000.
[CSH99]
CHRISTIANE SCHULZKI-HADDOUTI, Markt- oder Staatsmacht Streit um digitale Signaturen, c’t 1/99, S. 58ff, 1999.
139
[CSH00]
CHRISTIANE SCHULZKI-HADDOUTI, Kontrollierte Liberalisierung USA kündigen weitere Lockerungen für Kryptoexporte an, <URL:
http://www.heise.de/tp/deutsch/inhalt/te/5683/1.html>, Heise
Online News, 2000.
[CSH01]
CHRISTIANE SCHULZKI-HADDOUTI, Echelon-Ausschuss setzt auf
Open-Source, <URL: http://www.heise.de/tp/deutsch/special/ech/
7157/1.html>, 2001.
[DaBachf01]
DANIEL BACHFELD, Sicheres Netz im Netz - Der Aufbau von Virtual
Private Networks, c’t 17/01, S. 164ff, 2001
[DFN99-1]
STEFAN KELM, BRITTA LIEDTKE, DFN - PCA: Low-Level Policy Zertifizierungsrichtlinien für das PCA Projekt, <URL: http://
www.pca.dfn.de/dfnpca/policy/ lowlevel.html>, Universität Hamburg, 1999.
[DFN99-2]
STEFAN KELM, BRITTA LIEDTKE, DFN - PCA: Die World Wide Web
Policy - Zertifizierungsrichtlinien für das PCA Projekt, <URL:
http://www.pca.dfn.de/dfnpca/policy/wwwpolicy.html>, Universität Hamburg, 1999.
[DFN00-1]
INGMAR CAMPHAUSEN, STEFAN KELM, BRITTA LIEDTKE, LARS
WEBER, DFN-Bericht Nr. 89 - Aufbau und Betrieb einer Zertifizierungsinstanz, <URL: ftp://ftp.pca.dfn.de/pub/docs/PCA/DFNPCA/handbuch/ca-hb.pdf>, Hamburg 2000.
[DWChad96]
D. W. CHADWICK, Understanding X.500 - The Directory, <URL:
http://www.isi.salford.ac.uk/staff/dwc/Version.Web/Contents.htm>,
1996.
[Entrust00-1]
ENTRUST, Entrust/PKI, and Windows, 2000 IPSec Client Interoperability Guide using Entrust/WebConnector, 4.0a,
<URL: http://www.entrust.com/resources/pdf/
win2kipsec_interop.pdf>, 2000.
[Entrust00-2]
ENTRUST, Key Update and the Complete Story on the Need for Two
Key Pairs, <URL: http://www.entrust.com/resources/pdf/
2keypairs11.pdf>, 2000.
[FlRoe99]
FLORIAN RÖTZER, Auch die Schweiz hat ein Echelon-System,
<URL: http://www.heise.de/tp/deutsch/special/ech/6646/1.html>,
Telepolis, 1999.
[FlRoe00]
FLORIAN RÖTZER, Nichts mehr mit Pretty Good Privacy?, <URL:
http://www.heise.de/tp/deutsch/inhalt/te/4418/1.html>, Telepolis,
2000.
[FUHagen01]
FERNUNIVERSITÄT HAGEN, FernUni-CA: Policy, <URL: http://
www.fernuni-hagen.de/CA/policy.html>, 2001.
[GeLaga98]
GERHARD LAGA, Internet im rechtsfreien Raum? Die Anwendbarkeit bestehender Gesetze auf das Internet, im Zeitalter der Informationsgesellschaft, <URL: http://www.laga.at/Dissertation/
Diss.html>, Wien 1998.
[GnuPG00]
GNU PRIVACY GUARD, The GNU Privacy Guard Handbook (German) - Das GNU-Handbuch zum Schutze der Privatsphäre, <URL:
140
Anhang D: Literaturverzeichnis
http://www.gnupg.org/gph/de/manual.pdf>, 2000.
[GoRo97-1]
DAVID GOODMAN, COLIN ROBBINS, Understanding LDAP and
X.500, <URL: http://www.nexor.com/info/understandldap.htm>,
EEMA Directory Group 1997.
[GoRo00-1]
DAVID GOODMAN, COLIN ROBBINS, LDAP – Moving Forward,
Frequently Asked Questions Version 2.3, <URL: http://
www.nexor.com/info/LDAP-FAQ-23.htm>, EEMA Directory
Group 2000.
[GoRo00-2]
DAVID GOODMAN, COLIN ROBBINS, LDAP – Moving Forward,
RFCs & Internet Drafts Version 1.2, <URL: http://www.nexor.com/
info/LDAP-RFCs.htm>, EEMA Directory Group 2000.
[HaGie01]
HARTMUT GIESELMANN, CIA hört mit - und versteht, <URL: http://
www.heise.de/newsticker/data/hag-05.03.01-000/>, Heise Online
News, 2001.
[HartMase00]
MICHAEL HARTMANN, SÖNKE MASEBERG, Fail-Safe-Konzept für
FlexiPKI, Technical Report No. TI-11/00, TU Darmstadt 2000.
[HousPolk01]
RUSS HOUSLEY, TIM POLK, Planning for PKI - Best Practices
Guide for Deploying Public Key Infrastructure, Wiley Computer
Publishing 2001.
[HtRiele99]
HERMAN TE RIELE, Security of E-commerce threatened by 512-bit
number factorization, CWI press release, Amsterdam 1999.
[IBM98]
HEINZ JOHNER, LARRY BROWN, FRANZ-STEFAN HINNER, WOLFGANG REIS, JOHAN WESTMAN, Understanding LDAP, <URL: http://
www.redbooks.ibm.com/pubs/pdfs/redbooks/sg244986.pdf>, USA
1998.
[IETF-1]
IETF WORKING GROUP, Public-Key Infrastructure (X.509) (pkix),
<URL: http://www.ietf.cnri.reston.va.us/html.charters/pkix-charter.html>, 2001.
[IETF-2]
IETF WORKING GROUP, S/MIME Mail Security (smime) , <URL:
http://www.ietf.cnri.reston.va.us/html.charters/smime-charter.html>, 2001.
[IETF-3]
D. W. CHADWICK, S. LEGG, Internet Draft - Internet X.509 Public
Key Infrastructure, Additional LDAP Schema for PKIs and PMIs,
<URL: http://www.imc.org/draft-ietf-pkix-ldap-schema>, IETF
Working Group, 2000.
[IETF-4]
D.W.CHADWICK, Internet Draft - Internet X.509 Public Key Infrastructure, Operational Protocols - LDAPv3, <URL: http://
www.imc.org/draft-ietf-pkix-ldap-v3/>, IETF Working Group,
2000.
[IETF-5]
IETF WORKING GROUP, S/MIME Working Group, <URL: http://
www.imc.org/ietf-smime/>.
[IETF-6]
RODNEY THAYER, Internet Draft - PKI Requirements for IP Security, <URL: http://www.ietf.org/proceedings/99mar/I-D/draft-ietfipsec-pki-req-01.txt>, 1998.
141
[IN96]
INDIVIDUAL NETWORK E.V. , FAQ: Die Policy der Individual Network Zertifikationshierarchie, <URL: http://www.in-ca.individual.net/faq.html>, 1996.
[IN97]
INDIVIDUAL NETWORK E.V. , Certification Policy, <URL: http://
www.in-ca.individual.net/policy.html>, 1997.
[IMachef98]
IRA MACHEFSKY, A Total Economic Impact, Analysis of Two PKI
Vendors: Entrust and VeriSign, <URL://http://www.entrust.com/
resources/pdf/pki_tei_report.pdf>, Technical Report, Giga Information Group 1998.
[JoBuch99-1]
JOHANNES BUCHMANN, MARKUS RUPPERT, MARKUS TAK, FlexiPKI - Realisierung einer flexiblen, Public-Key-Infrastuktur, Technical Report No. TI-22/99, TU Darmstadt 1999.
[JoBuch99-2]
JOHANNES BUCHMANN, MARKUS MAURER, Wie sicher ist die Public-Key-Kryptographie? Technical Report No. TI-2/99, TU Darmstadt 1999.
[JoBuch00-1]
JOHANNES BUCHMANN, Einführung in die Kryptographie, Springer
Verlag Heidelberg, 2000.
[JoEisinger01]
JOCHEN EISINGER, Exploiting known security holes in Microsoft's,
PPTP Authentication Extensions (MS-CHAPv2), <URL: http://
mopo.informatik.uni-freiburg.de/pptp_mschapv2/
pptp_mschapv2.pdf>, Universität Freiburg 2001.
[JoPflue01]
JÖRG PFLÜGLER, Datenschutz und Datensicherheit - Kryptographische Sicherheit und Schlüssellängen, <URL: http://
igw.tuwien.ac.at/igw/Lehre/DuD2000_skripte/
DsDs2000Skript4.pdf>, Wien 2001.
[JuSch01-1]
JÜRGEN SCHMIDT, PGP-Sicherheitslücke bestätigt, <URL: http://
www.heise.de/newsticker/data/ju-22.03.01-001/>, Heise Online
News, 2001.
[JuSch01-2]
JÜRGEN SCHMIDT, PGP-Schlüssel lassen sich prüfen, <URL: http://
www.heise.de/newsticker/data/ju-23.03.01-000/>, Heise Online
News, 2001.
[JuSch01-3]
JÜRGEN SCHMIDT, PETER SIERING, Moderner Tunnelbau - Der Weg
zum eigenen Virtual Private Network, c’t 18/01, S. 182ff, 2001.
[JvBuu01]
JELLE VAN BUUREN, Holländische Regierung gibt Existenz von
Echelon zu... <URL: http://www.heise.de/tp/deutsch/special/ech/
4728/1.html>, Telepolis, 2001.
[KKLV98]
KAPPEL, KOLLAR, LEDERHILGER, VERHONIG, Zertifizierung und
Public Key- Infrastruktur, <URL: http://wicky.wu-wien.ac.at/
finanz/publications/Kapp98.pdf>, Wien 1998.
[KaFuhr00]
KAI FUHRBERG, Internet- Sicherheit. Browser, Firewalls und Verschlüsselung, Hanser Verlag 2000.
[KlimaRosa01] VLASTIMIL KLÍMA, TOMÁŠ ROSA, Attack on Private Signature
Keys, of the OpenPGP format, PGP programs and other applications, compatible with OpenPGP, <URL: http://www.i.cz/en/pdf/
142
openPGP_attack_ENGvktr.pdf>, Prag 2001.
[KlSchm98]
KLAUS SCHMEH, Safer Net - Kryptografie im Internet und Intranet,
dpunkt-Verlag Heidelberg, 1998.
[KlSchm01]
KLAUS SCHMEH, MATTHIAS NIESING, Schlüssel des Vertrauens Digitale Ausweise im Internet, c’t 4/01, Seite 224ff, 2001.
[KoMa01]
KONSTANTIN MALAKAS, Heilige Kuh - Gesetz zur elektronischen
Signatur, c’t 5/01, S. 47, 2001.
[KuSp99]
DR. KURT SPANIER, LDAP und die Ablage von PGP-Schlüsseln im
X.500-Direktory, <URL: http://wwwvs.informatik.fh-wiesbaden.de/
local/info/LDAP/LDAP-PGP.ps>, Universität Thübingen, 1999.
[LenVerh99]
ARJEN K. LENSTRA, ERIC R. VERHEUL, Selecting Cryptographic
Key Sizes, <URL: http://www.cryptosavvy.com/Joc.pdf>, 1999.
[MiKjoe01]
MICHAEL KJÖRLING, PGP 7.0 signature verication vulnerability,
<URL: http://www.net-security.org/text/bugs/
979055938,89332,.shtml>, Help Net Security 2001.
[MS99-1]
FRANCO MICHELA, MARKUS PALME, Microsoft Active Directory,
Microsoft Press Deutschland 1999.
[MS99-2]
MICROSOFT KNOWLEDGE BASE, Enabling Certificate Revocation
Checking in Internet Information Server 4.0 (Q232165), <URL:
http://support.microsoft.com/default.aspx?scid=kb;ENUS;q232165>, Microsoft Corporation 1999.
[MS00-1]
MICROSOFT, Certificate Server 1.0 Update - US Version,
<URL: ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/certserv/>, Microsoft Corporation 2000.
[MS00-2]
MICROSOFT KNOWLEDGE BASE, How to Configure Certificate
Server for Use with SSL on IIS (Q218445), <URL: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q218445>,
Microsoft Corporation 2000.
[MS00-3]
MICROSOFT, Microsoft Windows 2000 Netwerkinfrastruktur-Administration - Original Microsoft Training, Microsoft Press Deutschland 2000.
[MS00-4]
MICROSOFT, Microsoft Windows 2000 Server - Die technische Referenz: TCP/IP-Netzwerke. Microsoft Press Deutschland 2000.
[MS00-5]
MICROSOFT, Microsoft Windows 2000 Server - Die technische Referenz: Verteilte Systeme, Microsoft Press Deutschland 2000.
[MS00-6]
MICROSOFT, Microsoft Windows 2000 Server - Die technische Referenz: Internetworking, Microsoft Press Deutschland 2000.
[MS00-7]
MICROSOFT, Microsoft Windows 2000 Server - Die technische Referenz: Microsoft-Internet-Informationsdienste, Microsoft Press
Deutschland 2000.
[MS00-8]
MICROSOFT, Microsoft Exchange Server - Outlook Web Access in
Exchange 2000 Server: Whitepaper, Microsoft 2000.
[MS01-1]
MICROSOFT, Microsoft Windows 2000 Accelerated Training - Origi-
143
nal Microsoft Training, Microsoft Press Deutschland 2001.
[MS01-2]
MICROSOFT TECHNET, Virtual Private Networking with Windows
2000: Deploying Remote Access VPNs, <URL: http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/vpndeply.asp>, Microsoft Corporation 2001.
[MS01-3]
MICROSOFT KNOWLEDGE BASE, SSL (https) Connection Slow with
One Certificate but Faster with Others (Q295070), <URL: http://
support.microsoft.com/default.aspx?scid=kb;en-us;Q295070>,
Microsoft Corporation 2001.
[MiSt99]
MICHAEL STRÖDER, Einführung kryptographischer Techniken zur
gesicherten Nutzung des Internet bei der Propack Data GmbH,
<URL: http://www.stroeder.com/DA/DA.pdf>, Universität Karlsruhe, 1999.
[NS98-1]
NETSCAPE DEVEDGE, Introduction to SSL, <URL: http://developer.netscape.com/docs/manuals/security/sslin/index.htm>, Netscape Communications Corporation 1998.
[NS98-2]
NETSCAPE DEVEDGE, Introduction to Public-Key Cryptography,
<URL: http://developer.netscape.com/docs/manuals/security/pkin/
index.htm>, Netscape Communications Corporation 1998.
[NS99-1]
NETSCAPE DEVEDGE, Netscape Certificate Management System
Installation and Deployment Guide - Appendix B Certificate Extensions, <URL: http://developer.netscape.com/docs/manuals/cms/41/
dep_gide/ext.htm>, Netscape Communications Corporation 1999.
[OLDAP01]
OPENLDAP FOUNDATION, OpenLDAP - open source implementation of the Lightweight Directory Access Protocol, <URL: http://
www.openldap.org/>, 2001.
[PeSiering01]
PETER SIERING, Virtual Public Network - PPTP-Sicherheitslücke
als Einstiegsloch in Uni-Funknetze, c’t 16/01, S. 34, 2001.
[PhZim99]
PHIL ZIMMERMANN, Einführung in die Kryptographie, <URL:
http://www.datensicherheit.nrw.de/pki/manuals/general/>, 1999.
[PioHa99]
JAKUB PIOTROWSKI, TOBIAS HARTMANN, LDAP - Übersicht über
das Chaos, <URL: http://www.informatik.uni-bremen.de/grp/unitel/referat/ldap/ldap.html>, Universität Bremen 1999.
[RaBend01]
RALF BENDRATH, PGP - die ersten zehn Jahre, Telepolis, <URL:
http://www.heise.de/tp/deutsch/inhalt/te/7175/1.html>, 2001.
[RaSend01]
RALF SENDEREK, The Protection of Your Secret Key, Version 2.0,
<URL: http://senderek.de/security/secret-key.protection.html>,
2001.
[RegTP-98]
REGULIERUNGSBEHÖRDE FÜR TELEKOMMUNIKATION UND POST,
Geeignete Kryptoalgorithmen gemäß § 17 Abs. 2 SigV, Bekanntmachung im Bundesanzeiger Nr. 31, S. 1787f, 1998.
[RFC1777]
W. YEONG, T. HOWES, S. KILLE, RFC 1777 - Lightweight Directory
Access Protocol, <URL: ftp://ftp.isi.edu/in-notes/rfc1777.txt>,
1995.
144
[RFC1828]
P. METZGER, W. SIMPSON, RFC 1828 - IP Authentication using
Keyed MD5, <URL: http://sunsite.iisc.ernet.in/collection/rfc/
rfc1828.html>, 1995.
[RFC1829]
P. KARN, P. METZGER, W. SIMPSON, RFC 1829 - The ESP DESCBC Transform, <URL: http://sunsite.iisc.ernet.in/collection/rfc/
rfc1829.html>, 1995.
[RFC1960]
T. HOWES, A String Representation of LDAP Search Filters, <URL:
ftp://ftp.isi.edu/in-notes/rfc1960.txt>, 1996.
[RFC2251]
M. WAHL, T. HOWES, S. KILLE, RFC 2251 - Lightweight Directory
Access Protocol (v3), <URL: ftp://ftp.isi.edu/in-notes/rfc2251.txt>,
1997.
[RFC2254]
T. HOWES, The String Representation of LDAP Search Filters,
<URL: ftp://ftp.isi.edu/in-notes/rfc2254.txt>, 1997.
[RFC2255]
T. HOWES, M. SMITH, RFC 2255 - The LDAP URL Format, <URL:
ftp://ftp.isi.edu/in-notes/rfc2255.txt>, 1997.
[RFC2307]
L. HOWARD, RFC 2307 - An Approach for Using LDAP as a Network Information Service, <URL: http://sunsite.iisc.ernet.in/collection/rfc/rfc2307.html>, 1998.
[RFC2402]
S. KENT, R. ATKINSON, RFC 2402 - IP Authentication Header,
<URL: http://sunsite.iisc.ernet.in/collection/rfc/rfc2402.html>,
1998.
[RFC2406]
S. KENT, R. ATKINSON, RFC 2406 - IP Encapsulating Security
Payload (ESP), <URL: http://sunsite.iisc.ernet.in/collection/rfc/
rfc2406.html>, 1998.
[RFC2408]
D. MAUGHAN, M. SCHERTLER, M. SCHNEIDER, J. TURNER, RFC
2408 - Internet Security Association and Key Management Protocol
(ISAKMP), <URL: http://sunsite.iisc.ernet.in/collection/rfc/
rfc2408.html>, 1998.
[RFC2409]
D. HARKINS, D. CARREL, RFC 2409 - The Internet Key Exchange
(IKE), <URL: http://sunsite.iisc.ernet.in/collection/rfc/
rfc2409.html>, 1998.
[RFC2440]
DONNERHACKE, CALLAS, FINNEY, THAYER, RFC 2440 - OpenPGP
Message Format, <URL: ftp://ftp.ietf.org/rfc/rfc2440.txt>, 1998.
[RFC2459]
HOUSLEY, FORD, POLK, SOLO, RFC 2459 - Internet X.509 Public
Key Infrastructure, Certificate and CRL Profile, <URL: ftp://
ftp.isi.edu/in-notes/rfc2459.txt>, 1999.
[RFC2510]
C. ADAMS, S. FARRELL, RFC 2510 - Internet X.509 Public Key
Infrastructure, Certificate Management Protocols, <URL: ftp://
ftp.isi.edu/in-notes/rfc2510.txt>, 1999
[RFC2632]
B. RAMSDELL, RFC 2632 - S/MIME Version 3 Certificate Handling, <URL: ftp://ftp.ietf.org/rfc/rfc2632.txt>, 1999.
[RFC2633]
B. RAMSDELL, RFC 2633 - S/MIME Version 3 Message Specification, <URL: ftp://ftp.ietf.org/rfc/rfc2633.txt>, 1999.
[RSAFAQ]
RSA SECURITY INC., S/MIME Frequently Asked Questions, <URL:
145
http://www.rsasecurity.com/standards/smime/faq.html>.
[RSA93-1]
RSA SECURITY INC., PKCS #7 - Cryptographic Message Syntax
Standard, Version 1.5, <URL:ftp://ftp.rsasecurity.com/pub/pkcs/ps/
pkcs-7.ps.gz>, RSA Laboratories 1993.
[RSA93-2]
BURTON S., KALISKI JR., An Overview of the PKCS Standards,
<URL: ftp://ftp.rsasecurity.com/pub/pkcs/ascii/overview.asc>, RSA
Laboratories 1993.
[RSA99-1]
RSA SECURITY INC., PKCS #12 v1.0: Personal Information
Exchange Syntax, <URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs12/pkcs-12v1.pdf>, RSA Laboratories 1999.
[RSA99-2]
RSA SECURITY INC., Factorization of RSA-155, <URL: http://
www.rsasecurity.com/rsalabs/challenges/factoring/rsa155.html>,
RSA Laboratories 1999.
[RSA99-3]
RSA SECURITY INC., Factorization of RSA-155 - Frequently Asked
Questions, <URL: http://www.rsasecurity.com/rsalabs/challenges/
factoring/rsa155_faq.html>, RSA Laboratories 1999.
[RSA00-1]
RSA SECURITY INC., PKCS #10 v1.7: Certification Request Syntax
Standard, <URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs10v1_7.pdf>, RSA Laboratories 2000.
[RSA00-2]
RSA SECURITY INC. PKCS #11 v2.11 Draft 1: Cryptographic Token
Interface, Standard, <URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs11/v211/pkcs11v2-11d1.pdf>, RSA Laboratories 2000.
[SigG97-1]
DEUTSCHER BUNDESTAG, IuKDG, Artikel 3: Gesetz zur digitalen
Signatur (Signaturgesetz - SigG), <URL: http://www.iid.de/rahmen/
iukdgbt.html>, 1997.
[SigG97-2]
BUNDESREGIERUNG, Verordnung zur digitalen Signatur, (Signaturverordnung - SigV), <URL: http://www.iid.de/rahmen/sigv.html>,
1997.
[SigG97-3]
BUNDESMINISTERIUM FÜR BILDUNG, WISSENSCHAFT, FORSCHUNG
UND TECHNOLOGIE, Begründung zur Verordnung zur digitalen Signatur, <URL: http://www.iid.de/rahmen/sigv_begr.html>, 1997.
[SigG01-1]
DEUTSCHER BUNDESTAG, Gesetz über Rahmenbedingungen, für
elektronische Signaturen, und zur Änderung weiterer Vorschriften,
<URL: http://www.iid.de/iukdg/gesetz/SigAendG2.pdf>, 2001.
[SigG01-2]
BUNDESMINISTERIUM DER JUSTIZ, Gesetz zur Anpassung der Formvorschriften des Privatrechts und anderer Vorschriften an den modernen Rechtsgeschäftsverkehr, <URL: http://www.juramail.com/
news/gesetze/formtext.html>, Referentenentwurf 2001.
[SiLGarf94]
SIMSON L. GARFINKEL, PGP, O’Reilly 1994.
[StKrem01]
STEFAN KREMPL, Wer braucht digitale Signaturen? - Von der Public-Key-Infrastruktur zur Sicherungszwangsgesellschaft, c't 2/01, S.
60ff, 2001.
[TcTrust01]
TC-TRUSTCENTER AG, TC Server - Technische Informationen,
<URL: http://www.trustcenter.de/products/server/de/technik.htm>,
146
2001.
[ThBend99]
THOMAS BENDLER, Linux LDAP HOWTO, <URL: http://www.tuharburg.de/dlhp/HOWTO/DE-LDAP-HOWTO.html>, 1999.
[TMoses97]
DR. TIM MOSES, Bulding a public key infrastructure - in-source or
out-source, Entrust Technologies 1997.
[UlBantle00]
ULRICH BANTLE, USA lockert Export von Kryptografie, <URL:
http://www.tecchannel.de/news/20000718/thema200007182012.html>, tecChannel-News 2000.
[UtRoos01]
UTE ROOS, Digitale Unterschrift: fast wie eigenhändig, <URL:
http://www.heise.de/newsticker/data/ur-01.08.01-000/>, Heise
Online News, 2001.
[VoSchw01]
VOLKER SCHWABEROW, OpenLDAP-Praxis - Straffe Verwaltung,
<URL: http://www.linux-magazin.de/ausgabe/2001/05/OpenLDAP/
openldap.html>, Linux-Magazin 2001.
[Wassenaar00]
DIVERSE STAATEN, The Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies, <URL: http://www.wassenaar.org/docs/index1.html>, 2000.
[WoKopp98]
WOLFGANG KOPP, Rechtsfragen der Kryptographie und der digitalen Signatur, <URL: http://www.wolfgang-kopp.de/krypto.pdf>,
Universität München, 1998.
147
148

Konzept und Aufbau einer prototypischen Public Key Infrastruktur

Transcription

Similar documents

Flexible Anbindung von Smartcards an eine

PGP® Desktop 9.8 für Windows - Symantec SSL Certificates Support

Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

Lösung - Monitor

Fallstudie: Das drahtlose Netzwerk von Microsoft

KIT-CA - Liste der Teilnehmer der DFN-PKI - DFN

CCE Dateiformat - A-SIT