Konzept und Aufbau einer prototypischen Public Key ... · PDF fileTagen noch keinen Besuch bekommen hat, ... Konzept und Aufbau einer prototypischen Public Key Infrastruktur auf Basis

Fachbereich InformatikProf. Dr. Johannes BuchmannInstitut für Theoretische InformatikTechnische Universität Darmstadt

Diplomarbeit

Konzept und Aufbau einer prototypischenPublic Key Infrastruktur auf Basis von FlexiTrust

Bei der Allgemeinen Deutschen Direktbank AG

vonPatrick Seiler

BetreuerAlexander Wiesmaier

Oktober 2001

Ich bedanke mich bei allen, die mir bei der Erstellung dieser Arbeit geholfen haben. Insbeson-dere danke ich Alexander Wiesmaier, für Betreuung dieser Arbeit am Institut für TheoretischeInformatik der TU-Darmstadt; Oliver Becker von der Firma Becker Consulting, für die Förde-rung dieser Diplomarbeit; Zeljko Kaurin, für die freundliche Unterstützung bei der Allgemei-nen Deutschen Direktbank AG; und allen Korrekturlesern, für ihre wertvollenVerbesserungshinweise.

i

ii

Ehrenwörtliche Erklärung

Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den ange-gebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen ent-nommen 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 52.1 Symmetrische Verschlüsselungsverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Asymmetrische Verschlüsselungsverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Hybridverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Digitale Signaturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Public Key Infrastrukturen 113.1 Grundlegende Dienste einer PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Schlüsselmanagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 Zertifikate nach X.509v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.1.1 Standardfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.1.2 Standarderweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1.3 Erweiterungen im Sinne der Signaturverordnung . . . . . . . . . . . . 193.3.1.4 Erweiterungen von Netscape . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Trustcenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.1 Struktur eines Trustcenters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.2 Zertifikatswiderruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5 Vertrauensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5.1 Direct Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5.2 Web Of Trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5.3 Hierarchical Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6 Schlüsselwiederherstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6.1 Escrowed Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.7 Kryptographische Verfahren auf Public Key Basis . . . . . . . . . . . . . . . . . . . . . . . . 293.7.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7.1.1 Server Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7.1.2 Client Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.1.3 Notwendige Zertifikaterweiterungen . . . . . . . . . . . . . . . . . . . . . 35

v

Konzept und Aufbau einer prototypischen Public Key Infrastruktur auf Basis von FlexiTrust

3.7.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.7.2.1 Notwendige Zertifikaterweiterungen . . . . . . . . . . . . . . . . . . . . . 38

3.7.3 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.7.3.1 IPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.7.3.2 IKMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.7.3.3 Virtuelle private Netzwerke (VPN) mit IPSec . . . . . . . . . . . . . . 423.7.3.4 Notwendige Zertifikaterweiterungen . . . . . . . . . . . . . . . . . . . . . 44

3.8 Verzeichnisdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.8.1 X.500. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.8.2 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.8.2.1 Vom Protokoll zum Verzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . 463.8.2.2 Das Informationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.8.2.3 Das Namensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.8.2.4 Das Sicherheitsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.8.2.5 LDAP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.9 Rechtliche Aspekte des PKI Betriebes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.9.1 Gesetzliche Beschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.9.2 Gesetz zur digitalen Signatur (SigG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.9.3 Exportbeschränkungen der USA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 Bedarfsanalyse 574.1 Ermittlung des Ist-Zustandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.1 Unternehmensstruktur DiBa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.2 Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.3 Hard- und Softwareinfrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.1.4 Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2 Ermittlung des Bedarfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.1 Sicherer Intranetzugang für mobile Mitarbeiter . . . . . . . . . . . . . . . . . . . . . 614.2.2 Sichere Kommunikation mobiler Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . . 624.2.3 Fernadministration des LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3 Konzept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.1 Überblick über das Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.2 Outsourcen oder Do-it-yourself?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.3 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3.4 Sicherer Intranetzugang für mobile Mitarbeiter . . . . . . . . . . . . . . . . . . . . . 644.3.5 Fernadministration des LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3.6 Sichere Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.6.1 Dokumentenbasierte Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.7 Anforderungen an die Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.4 Weitere Möglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5 Untersuchung vorhandener Software auf Möglichkeiten zur Integration 715.1 Aufbau der Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2 Software für Zertifizierungsstellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2.1 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2.2 Microsoft Certificate Server 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.2.3 FlexSecure FlexiTrust 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

vi

Inhaltsverzeichnis

5.2.3.1 FlexiTrust-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.2.3.2 FlexiTrust-RA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2.3.3 FlexiTrust-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.3 Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.1 Microsoft Internet Information Server 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.2 Microsoft Exchange Server 5.5 mit Outlook Web Access 5.5 . . . . . . . . . . 855.3.3 OpenLDAP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.4 Microsoft Windows 2000 Server als VPN-Gateway . . . . . . . . . . . . . . . . . 86

5.4 Client Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.4.1 Microsoft Internet Explorer 5.x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.4.2 Netscape Communicator 4.7x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4.3 Microsoft Outlook 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.4.4 LDAP Browser\Editor 2.8.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6 Umsetzung der Public Key Infrastruktur 996.1 Zertifizierungshierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.2 Benutzergruppen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.3 Konfiguration der Hard- und Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6.3.1 FlexSecure FlexiTrust 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.3.2 Microsoft Internet Information Server 4.0 . . . . . . . . . . . . . . . . . . . . . . . . 103

6.3.2.1 Erzeugen eines Serverzertifikates . . . . . . . . . . . . . . . . . . . . . . . 1036.3.2.2 Installation des Root-CA Zertifikates . . . . . . . . . . . . . . . . . . . . 1036.3.2.3 Serverkonfiguration für SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.3.3 Microsoft Internet Explorer 5.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.3.4 Microsoft Outlook 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.4 Allgemeiner Ablauf der Benutzerzertifizierung. . . . . . . . . . . . . . . . . . . . . . . . . . 1066.4.1 Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.4.2 Schlüsselerzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.4.3 Zertifizierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.4.4 Schlüsselverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.4.5 Sperrmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.4.6 Veröffentlichung von Zertifikaten und Widerrufslisten . . . . . . . . . . . . . . 1096.4.7 Vier-Augen-Prinzip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7 Kommentarzu den Zertifizierungsrichtlinien 1117.1 Rechtliche Bedeutung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2 Einsatz von Registrierungsinstanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137.3 Sicherheit in einer hierarchischen Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137.4 Zertifizierung von Benutzern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.5 Widerruf von Zertifikaten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8 Bewertung und Ausblick 1178.1 Gesamtbewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

vii


Anhang A Zertifizierungsrichtlinien: Policy 119A.1 Identität der DiBa-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2 Zuständigkeitsbereich der DiBa-CA . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A.2.1 Rechtliche Bedeutung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.2.2 Die DiBa-Zertifizierungshierarchie . . . . . . . . . . . . . . . . . . . . . . 120A.2.3 Registrierungsinstanz (RA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

A.3 Sicherheit der DiBa-CA-Ausstattung . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.3.1 Sicherheitsanforderungen an die DiBa-CA . . . . . . . . . . . . . . . . 121A.3.2 Sicherheitsanforderungen an die DiBa-RA . . . . . . . . . . . . . . . . 122A.3.3 Sicherheitsanforderungen an Benutzer . . . . . . . . . . . . . . . . . . . 122

A.4 Zertifizierungsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123A.4.1 Regeln für die Zertifizierung von Benutzern . . . . . . . . . . . . . . . 124

A.5 Management von Zertifikaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125A.6 Widerruf von Zertifikaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125A.7 Schlüsselhinterlegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126A.8 Regeln für die Namensgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127A.9 Verschiedenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Anhang B Installationsbeschreibungen 129B.1 Erzeugen eines Serverzertifikates für den IIS 4 . . . . . . . . . . . . . . . . . . 129B.2 Installation von CA-Zertifikaten im IIS 4 . . . . . . . . . . . . . . . . . . . . . . 130B.3 Installation von Widerrufslisten (CRLs) im Netscape Communicator 133B.4 Installation des MMC Zertifikat Snap-In . . . . . . . . . . . . . . . . . . . . . . . 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 Ver-schlüsselungssoftware sicher ist: Man verschlüsselt damit eine Morddrohungund 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 Mili-tärs eingesetzt. Viele Regierungen - darunter auch die US-Regierung - sehen auch heute nochden Einsatz von Verschlüsselung in einem engen Zusammenhang mit krimineller Energie. DieFolge ist, dass starke Kryptographie in vielen Staaten gesetzlich beschränkt und in einigen garganz verboten wurde. Einige Regierungen vertreten offensichtlich die These, dass ehrlicheBü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 undE-Payment denke man nur an Unternehmen, die ihr wertvolles geistiges Eigentum vor Wirt-schaftsspionage zu schützen gedenken. Die Möglichkeiten an derart brisante Informationen zugelangen sind vielfältig.

Echelon [JvBuu01] als weltweites Abhörsystem der US-amerikanischen Geheimdienste, liesteinen großen Teil der Internetkommunikation ungehindert mit. Und sogar die Schweiz gibt zu,ein vergleichbares System mit dem Namen Satos (Satellite Observation) einzusetzen, umsicherheitspolitisch bedeutsame Informationen zu beschaffen [FlRoe00]. Aber auch jene Inter-net-Service-Provider (ISP), über deren Rechner eine vertrauliche Nachricht auf dem Wegdurchs Internet läuft, sind in der Lage diese mitzulesen. Bedenkt man die unglaublichen beiISPs anfallenden Datenmengen, mag man die gezielte Suche nach einer bestimmten Informa-tion mit der Suche nach der berühmten Nadel im Heuhaufen vergleichen. Aber auch hier gibtes schon Unterstützung in Form von Carnivore [FlRoe00]. Das Schnüffelsystem vom FBI wirddirekt im Rechenzentrum des ISP installiert und erlaubt die gezielte Überwachung von Perso-nen. 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 insich birgt.

Ziel

Ziel dieser Diplomarbeit ist es, ein einheitliches Sicherheitskonzept für die Allgemeine Deut-sche Direktbank AG (DiBa) zu entwickeln, das mobilen Mitarbeitern eine geschützte Kommu-nikation, 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 Sicherheits-dienste zur Verfügung gestellt werden. Diese Sicherheitsdienste dienen dazu, elektronischeDokumente und Daten zwischen Servern und Mitarbeitern über ein Netzwerk mit unsicherenLeitungen nach fest definierbaren Sicherheitsbedürfnissen auszutauschen.

Eine Public Key Infrastruktur basiert auf kryptographischen Verfahren, die digitale Schlüsselnutzen. Alle an dieser Infrastruktur teilnehmenden Mitarbeiter bekommen eigene Schlüssel-paare ausgehändigt, die sie für bestimmte Sicherungszwecke, wie beispielsweise Verschlüsse-lung und digitale Signaturen, verwenden müssen. Diese Schlüsselpaare bestehen jeweils auseinem privaten und einem öffentlichen Schlüssel. Eine der Hauptaufgaben einer PKI bestehtdarin die privaten Schlüssel geeignet an die Mitarbeiter zu verteilen sowie die öffentlichenzweifelsfrei zuzuordnen und zu publizieren. Die Zuordnung der öffentlichen Schlüssel zu denMitarbeitern geschieht über digitale Zertifikate. Diese Zertifikate haben den gleichen Stellen-wert wie Ausweise in der realen Welt und sind somit für das Vertrauen in deren Authentizitätverantwortlich.

Um dieses Ziel zu verwirklichen, fiel die Wahl auf die Trustcenter-Software FlexiTrust. Diesewird in Zusammenarbeit mit der PKI-Forschungsgruppe von Professor Johannes Buchmann ander Technischen Universität Darmstadt entwickelt und ermöglicht den Aufbau von PKIs in Fir-men, 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 Ein-richtung einer PKI ohne großen Aufwand möglich wird.

FlexiTrust ist vollständig in Java implementiert und somit plattformunabhängig. Die Softwarekann auf allen gängigen Betriebssystemen (wie UNIX oder Windows NT/2000) ohne Verände-rung 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 JDBCgarantiert ein Höchstmaß an Interoperabilität mit PKI-fähigen Anwendungen. Von FlexiTrustausgestellte Zertifikate können beispielsweise in WWW-Anwendungen, für sichere Email oderfür den Zugang durch Firewalls verwendet werden. Die gängigen Programme von Netscapeoder 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önnensowohl auf einem einzelnen Rechner als auch verteilt auf mehreren Rechnern installiert wer-den, sodass sich die Software gleichermaßen für den Aufbau kostengünstiger PKIs in kleinerenoder 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 wiePublic Key Verschlüsselung, digitale Signaturen usw., soweit sie zum Verständnisder weiteren Kapitel hilfreich sind.

Kapitel 3 Befasst sich mit dem Konzept der Public Key Infrastrukturen. Dazu werdenGrundbegriffe wie Zertifikate, Trustcenter sowie Verfahren zur Verschlüsselungerklärt und auf die rechtlichen Zusammenhänge eingegangen.

Kapitel 4 Eine Bedarfsanalyse ermittelt den konkreten Bedarf des Kunden und stelltanschließend ein geeignetes Sicherheitskonzept auf Basis von PKI-Diensten auf.

Kapitel 5 Bereits beim Kunden im Einsatz befindliche, sowie (falls notwendig) zusätzlicheSoftware wird auf Möglichkeiten zur kryptographischen Absicherung hinsichtlicheiner 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 mitbesonderem Augenmerk auf die speziellen Anforderungen des SigG.

Kapitel 8 Fasst noch einmal kurz die vorangegangenen Kapitel zusammen und gibt einenAusblick auf mögliche zukünftige Erweiterungen.

Anhang

Anhang A Definiert Zertifizierungsrichtlinien (die sog. Policy) nach denen die einzurichtendeZertifizierungsinstanz 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ürdas Verständnis der nachfolgenden Kapitel hilfreich sind. Die klassische Kryptographie bildetdie Basis für die kryptographischen Protokolle und Verfahren von Public Key Infrastrukturen(PKI). Die im Folgenden besprochenen Grundlagen beschränken sich auf Verfahren zur Ver-schlüsselung von Daten (wie Nachrichten, Dokumenten oder Dateien), wobei zwischen sym-metrischen und asymmetrischen Verfahren unterschieden wird. Abschließend folgt einEinblick in die digitale Signatur, dem elektronischem Äquivalent zur eigenhändigen Unter-schrift.

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 über-nimmt und versucht, deren Daten zu manipulieren oder wenigstens mitzulesen. Diesen bei-spielhaften Vorgaben möchte ich mich mit dieser Arbeit anschließen. Bei Bedarf werdenweitere Personen eingeführt.

2.1 Symmetrische Verschlüsselungsverfahren

Bei symmetrischen Verschlüsselungsverfahren lässt sich der zum Entschlüsseln benutzteSchlüssel leicht aus demjenigen zum Verschlüsseln berechnen (und umgekehrt). Sehr häufigstimmen beide Schlüssel sogar überein. Man spricht daher meist von ein und demselbenSchlüssel.

Abbildung 1 zeigt, wie symmetrische Verschlüsselung prinzipiell funktioniert. Auf den Klar-text (Plaintext), der die zu verschlüsselnden Daten repräsentiert, wird eine Verschlüsselungs-funktion in Abhängigkeit eines kryptographischen Schlüssels angewendet. Dieser Schlüsselwird als geheimer Schlüssel bezeichnet. Der aus dieser Verschlüsselung resultierende Chiffre-text (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 Kommunikati-onspartner allerdings unterschiedliche gemeinsame Schlüssel. Bei n verschiedenen Personen,die alle untereinander symmetrisch verschlüsselt kommunizieren möchten, werden n·(n-1)/2Schlüssel benötigt. Für 100 Personen sind das schon 4950 zu vereinbarende, unterschiedlichegeheime Schlüssel. Problematisch stellt sich auch der eigentliche Austausch dieser gemeinsa-men geheimen Schlüssel mit den Kommunikationspartnern dar. Diese könnten beim Transportüber unsichere Leitungen von Angreifern abgefangen werden.

Abbildung 1 symmetrische Verschlüsselung

Zu den bekanntesten symmetrischen Verschlüsselungsverfahren gehören DES (Data Encryp-tion Standard) und IDEA (International Data Encryption Algorithm). DES gilt aber nach heuti-gen Erkenntnissen nicht mehr als sicher. Aus diesem Grund wird das DES-Verfahren meist nurnoch 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üsselungsverfah-ren genannt. Sie bedienen sich im Gegensatz zu den symmetrischen Verfahren zwei verschie-dener Schlüssel zum Ver- und Entschlüsseln. Wobei sich keiner der beiden aus dem jeweiligenanderen 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. pri-vaten Schlüssel (private key).

Der öffentliche Schlüssel wird zur Verschlüsselung verwendet (siehe Abbildung 2) und mussnicht geheim gehalten werden. Er kann an beliebig viele Personen weitergegeben oder ineinem Verzeichnis öffentlich zugänglich gemacht werden. Der private Schlüssel dient der Ent-schlüsselung, er muss daher privat, d. h. geheim gehalten werden.

Jeder der im Besitz des öffentlichen Schlüssels eines Schlüsselpaares ist, kann Daten ver-schlüsseln, die ausschließlich vom Besitzer des dazugehörenden privaten Schlüssels entschlüs-selt werden können. Alice muss nur ihren öffentlichen Schlüssel bekannt geben, und schonkann sowohl Bob, als auch der ihr unbekannte Zacharias, damit Daten verschlüsseln, die aus-schließlich Alice mit ihrem privaten Schlüssel wieder entschlüsseln kann.

GeheimerSchlüssel

Klartext

Chiffretext

Klartext

GeheimerSchlüssel

6

Kapitel 2: Kryptographische Grundlagen

Asymmetrische Verfahren vereinfachen das Schlüsselmanagement erheblich. Bei n verschie-denen Personen, die alle untereinander asymmetrisch verschlüsselt kommunizieren möchten,werden nur n unterschiedliche Schlüsselpaare benötigt. Ungünstiger Weise sind die Rechen-operationen auf denen asymmetrische Verfahren aufbauen erheblich aufwändiger als diejeni-gen, welche bei symmetrischen Verfahren verwendet werden. Asymmetrische Verschlüsselungist damit wesentlich zeitintensiver als Symmetrische.

Abbildung 2 asymmetrische Verschlüsselung

Zu den bekanntesten asymmetrischen Verschlüsselungsverfahren gehören RSA (das nach sei-nen Erfindern Rivest, Shamir und Adleman benannt wurde), ElGamal und Verfahren auf Basisder Elyptic Curve Cryptography.

2.3 Hybridverfahren

Als hybride Verschlüsselungsverfahren werden jene Algorithmen bezeichnet, die symmetri-sche 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 derganzen Sitzung verwendet. Der eigentliche Klartext wird z. B. mit IDEA unter diesem Sit-zungsschlüssel verschlüsselt. Für jede weitere Sitzung wird ein neuer Sitzungsschlüssel gene-riert. Der Austausch des symmetrischen Sitzungsschlüssels erfolgt durch ein asymmetrischesVerfahren wie RSA unter Verwendung des öffentlichen Schlüssels des Empfängers. Beide ver-schlüsselten Informationen (der Sitzungsschlüssel und der Chiffretext) werden zusammen anden Empfänger übermittelt. Dieser muss als erstes den geheimen Sitzungsschlüssel mit seinemprivaten Schlüssel entschlüsseln und kann anschließend den eigentlichen Klartext mit dem Sit-zungsschlüssel entschlüsseln. Abbildung 3 zeigt das Verfahren im Überblick.

Hybride Verfahren nutzen somit langsame, asymmetrische Verfahren ausschließlich zur Ver-und Entschlüsselung des relativ kurzen Sitzungsschlüssels. Der eigentliche, mit unter sehrlange, Klartext wird mithilfe symmetrischer Verfahren verschlüsselt. Dadurch bedient mansich neben dem Geschwindigkeitsvorteil symmetrischer, auch dem vereinfachten Schlüsselma-nagement asymmetrischer Verfahren.

ÖffentlicherSchlüssel

Klartext

Chiffretext

Klartext

PrivaterSchlüssel

7


Abbildung 3 hybride Verschlüsselung

2.4 Digitale Signaturen

Als digitale Signatur bezeichnet man die Unterschrift (Verschlüsselung) mit dem privatenSchlüssel eines asymmetrischen Verfahrens. Die Überprüfung (Entschlüsselung) der digitalenSignatur erfolgt mit dem dazugehörigen öffentlichen Schlüssel. Damit die Unterschrift, die mitdem privaten Schlüssel des Schlüsselinhabers erfolgt, auch die Authentizität und Integritäteines Klartextes (z. B. eines Dokumentes, oder einer Nachricht) bezeugt, müssen folgendeVoraussetzungen erfüllt sein.

� FälschungssicherheitDie digitale Signatur darf nicht zu fälschen sein. Damit wird bewiesen, dass nurder Unterzeichner und kein anderer den Klartext unterschrieben hat.

� AuthentizitätDie Echtheit muss mit dem öffentlichen Schlüssel überprüfbar sein. Gelingt diesnicht, wurde die Signatur entweder mit einem anderen privaten Schlüssel erzeugtund ist damit nicht von der angegebenen Person, oder der Klartext wurde nach demSignieren verändert.

� Nicht-WiederverwendbarkeitDie digitale Signatur darf nicht in anderen Dokumenten wiederverwendet werden

Sender

GeheimerSitzungsschlüssel

Öffentlicher Schlüssel

Klartext

Chiffretext

Empfänger

GeheimerSitzungsschlüssel

Privater Schlüssel

Chiffretext

Klartext

VerschlüsselterSitzungsschlüssel

VerschlüsselterSitzungsschlüssel

8

Kapitel 2: Kryptographische Grundlagen

können.

� IntegritätDer dazugehörige Klartext darf nicht (unbemerkt) verändert werden können, ohnedass die digitale Signatur ungültig wird.

Funktionsweise

Um dies zu erreichen, bedient sich die digitale Signatur einer Eigenschaft bestimmter asymme-trischer Verfahren: Ver- und Entschlüsselungsoperation sind kommutativ. D. h. Klartexte kön-nen 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 inAbschnitt [2.2] vorgestellten Vorgehen. Klartexte, die auf diese Weise verschlüsselt sind, kön-nen 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 derUnterschrift. Ist diese gültig, d. h. kann der Klartext entschlüsselt werden, dann kann niemandanderes als der Inhaber des dazugehörigen privaten Schlüssels den Klartext verschlüsselt(unterschrieben) haben.

Abbildung 4 Digitale Signatur

U. a. weil Klartexte, die signiert werden sollen, mitunter recht lang werden können und asym-metrische Verfahren relativ langsam arbeiten, wird üblicherweise an Stelle des Klartextesselbst nur dessen Hashwert unterschrieben. Dieser Hashwert (auch als Message Digestbezeichnet) bildet große Klartexte mit beliebiger Länge auf sehr kurze Bitfolgen ab, aus denender ursprüngliche Klartext nicht wieder rekonstruiert werden kann. Zudem ist es unmöglich,

Sender

PrivaterSchlüssel

Empfänger

ÖffentlicherSchlüssel

Digitale Signatur

0011

0110

0101 Hashwert

0011

0110

0101Hashwert

Digitale Signatur

Klartext Klartext

0011

0110

0101Hashwert

HashfunktionHashfunktionh(x) h(x)

==?

9


den Klartext so zu verfälschen, dass er nachher noch denselben Hashwert liefert. Häufig ver-wendete 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 diedigitale 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 ihnmit 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ängerzusammen mit der digitalen Signatur angekommen ist. Abbildung 4 stellt das Verfahren nocheinmal grafisch dar.

Digitale Signaturen spielen eine große Rolle bei der Ausstellung von Zertifikaten für PublicKey Infrastrukturen. Zertifizierung und PKI sind Inhalt des folgenden Kapitels.Zu den bekanntesten Signaturverfahren gehören ElGamal und DSA (Digital Signature Algo-rithm) sowie das asymmetrische Verschlüsselungsverfahren RSA.

2.5 Zusammenfassung

In diesem Kapitel wurden die wichtigsten Grundlagen der klassischen Kryptographie vorge-stellt, die für das Verständnis der folgenden Kapitel hilfreich sind.

Neben der symmetrischen Kryptographie mit ihrer vergleichsweise hohen Verarbeitungsge-schwindigkeit wurde die asymmetrische Kryptographie (auch Public Key Kryptographiegenannt) sowie Hybrid-Verfahren, die beides kombinieren, vorgestellt. Symmetrische Verfah-ren verwenden meist sowohl zur Ver- als auch zur Entschlüsselung denselben Schlüssel.Asymmetrische Verfahren hingegen verwenden zwei unterschiedliche Schlüssel, einen Gehei-men und einen Öffentlichen.

Digitale Signaturen dienen dazu, die Authentizität und Integrität von Dokumenten zu bestäti-gen. Sie sind das elektronische Äquivalent zur eigenhändigen Unterschrift.

10

Kapitel 3

Public Key Infrastrukturen

Die im vorangegangenen Kapitel vorgestellten kryptographischen Verfahren bilden die Grund-lage für den Aufbau einer Public Key Infrastruktur (PKI). Eine PKI basiert auf kryptographi-schen Verfahren, die digitale Schlüssel nutzen. Zu den Aufgaben einer PKI gehört dieGenerierung 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 Zerti-fizierungsstelle, welche Personen und Dienste (Rechner) zertifiziert (d. h. deren Schlüsselbeglaubigt) und somit für das Vertrauen in deren Authentizität verantwortlich ist. Zertifikateeiner solchen Infrastruktur haben den gleichen Stellenwert wie Ausweise in der realen Weltund stellen damit so etwas wie elektronische Identitätsnachweise von Personen und Dienstendar. Die zertifizierten digitalen Schlüssel werden u. a. dazu verwendet, digitale Signaturen aus-zustellen sowie Dokumente und den Datenverkehr zwischen Rechnern zu verschlüsseln. Eineweitere Komponente ist die Registrierungsstelle, die als Teil der PKI die organisatorischeSchnittstelle 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 zudefinieren.

In diesem Kapitel werden die dazu notwendigen Grundbegriffe und Standards besprochen. AmSchluss folgt noch ein Einblick in die rechtlichen Aspekte, die den Betrieb einer PKI und dieVerwendung von Kryptographie im Allgemeinen betreffen.

3.1 Grundlegende Dienste einer PKI

Zu den Hauptaufgaben einer PKI gehört die Gewährleistung von Authentizität, Vertraulichkeitund 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 diesemZusammenhang ebenso wichtig ist die Sicherstellung der Authentizität der Personen selbst,falls angebotene Dienste bestimmten Personengruppen vorbehalten sein sollen. Dieser Vor-gang wird häufig auch als Authentisierung oder Authentifizierung bezeichnet und bedeutetsomit die Verifizierung der Identität der Kommunikationspartner. Authentizität ist weiterhinnotwendig, um zu gewährleisten, dass übertragene Daten auch tatsächlich vom richtigen Kom-munikationspartner 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 Personenzur Kenntnis gelangt. Darunter fallen sowohl vertrauliche Dokumente (z. B. mit Kreditkarten-informationen oder Unternehmensgeheimnissen) als auch die Datenkommunikation zwischenzwei Rechnern.

Integrität

Daten-Integrität steht für die Nichtveränderbarkeit von Daten. Bei der Übertragung vertrauli-cher Daten muss sichergestellt sein, dass diese unterwegs nicht verändert und dass keine Datenhinzugefügt oder entfernt werden.In Verbindung mit der Authentizität ermöglicht die Integrität eine Verbindlichkeit in demSinne, 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 funktionie-rendes Schlüsselmanagement. Unter Schlüsselmanagement versteht man die Generierung,Speicherung, Verteilung und Anwendung kryptographischer Schlüssel. Es müssen Maßnah-men 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 Kryptoverfah-ren nutzlos. Die Kompromittierung von privaten Anwenderschlüsseln stellt zugleich die größteSchwachstelle einer PKI dar. Verglichen mit der Alternative eine aufwändige Kryptoanalysedurchzuführen, ist die Kompromittierung - also z. B. der Diebstahl eines Schlüssels - meist miterheblich geringerem Aufwand erreichbar. Man erkennt, dass ein besonderes Augenmerk aufdie Sicherheitspolitik gelegt werden muss, um ein sicheres zentrales Management von Schlüs-seln zu erreichen.

Zusammenfassend kann man sagen, dass es sicher einfacher ist, an geheime Schlüssel zugelangen, als ein Kryptoverfahren zu brechen.

Schlüsselgenerierung

Sicherheit beim Einsatz kryptographischer Schlüssel hängt nicht zuletzt von der Schlüssel-lä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 56Bit Exportversionen US-amerikanischer Softwareprodukte, wie etwa des Netscape Navigatorsoder des Microsoft Internet Explorers, gelten als schwach und können von entschlossenenAngreifern in kurzer Zeit überwunden werden. Eine Schlüssellänge von 1024 Bit gilt nachStand der Technik als sicher beim Einsatz asymmetrischer Verschlüsselungsverfahren wieRSA. Die lange Zeit verwendeten 512 Bit RSA Schlüssel eignen sich heute nicht mehr fürAnwendungen mit hohen Sicherheitsanforderungen, da es schon 1999 gelungen ist, solcheVerschlüsselungen zu brechen [HtRiele99].

Entsprechend schreibt die Regulierungsbehörde für Telekommunikation und Post (RegTP) alszuständige Behörde gemäß SigG (siehe Abschnitt [3.9.2]) eine Schlüssellänge für RSA-Schlüssel von 1024 Bit oder länger vor, wenn bis Ende 2003 die Sicherheit des Verfahrensgewährleistet sein soll [RegTP-98].

Generell gilt, dass asymmetrische Schlüssel erheblich größer gewählt werden müssen als Sym-metrische, um eine vergleichbare Sicherheit zu gewährleisten. Eine solche Abschätzung liefernLenstra und Verheul in [LenVerh99]. Allerdings sollte man, sowohl bei asymmetrischer, alsauch bei symmetrischer Verschlüsselung die Schlüssellänge nicht zu groß wählen, da dieGeschwindigkeit 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 Fest-platte (oder Diskette) des Schlüsselinhabers gespeichert werden. Um dabei maximale Sicher-heit zu gewährleisten, muss der Schlüssel wiederum selbst verschlüsselt abgelegt werden.Üblicherweise erreicht man dies durch den Einsatz von symmetrischen Verschlüsselungsver-fahren, wobei ein Passwort als Schlüssel dient. Erst nach Eingabe dieses Passwortes wird derprivate Schlüssel für Anwendungsprogramme nutzbar. Mehr Sicherheit bietet der Einsatz vonSmartcards anstelle der Festplatte. Einige Smartcards geben den privaten Schlüssel auch nachEingabe der PIN nicht Preis und führen stattdessen die kryptographischen Operationen aus-schließlich selbst aus.

Alte Schlüssel, die nicht mehr in Gebrauch sind und durch Neue ersetzt wurden, sollten aufsichere Weise vom verwendeten Datenträger entfernt werden. Die Anforderung an ein sicheresEntfernen geht üblicherweise über das einfache Löschen mittels Betriebssystemfunktionenhinaus. Die Schlüsseldaten sollten vom Betriebssystem nicht einfach zum Überschreiben frei-gegeben werden. Eine Lösung bieten hier spezielle Tools, die zum Löschen freigegebeneDateien vorher mehrfach mit sinnlosen Daten überschreiben, um zu verhindern, dass gelöschteSpeicherbereiche 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 ihrsteht und fällt letztlich die Vertraulichkeit bzw. die Zurechenbarkeit verschlüsselter odersignierter Daten. Daher liegt die Verantwortung beim Umgang mit Schlüsselpaaren beimAnwender selbst. Dieser muss entsprechend über die Bedeutung der Geheimhaltung bei derHandhabung privater Schlüssel informiert bzw. geschult werden. Bei Verschlüsselungsverfah-ren 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üsselnoch den Namen seines Besitzers enthält. Das Zertifikat sorgt somit für eine sichere Zuord-nung des Schlüssels zu einem Subjekt1. Das Signieren selbst kann dabei von verschiedenenvertrauenswürdigen Einrichtungen übernommen werden. Eine derartige Einrichtung muss dasVertrauen aller an dieser Kommunikation beteiligter Personen genießen, inkl. des Zertifiziertenselbst. Auf Basis dieser Vertrauensbeziehung wird gewährleistet, dass der signierte öffentlicheSchlüssel auch wirklich zur zertifizierten Person gehört und für die sichere Kommunikationmit dieser verwendet werden kann. Umgekehrt bedeutet dies: Schenkt ein Kommunikations-partner dieser Einrichtung kein Vertrauen, so vertraut er auch nicht deren Zertifikat - und somitnicht der Zuordnung des Schlüssels zur Person. Dies wiederum hat zur Konsequenz, dass dieVerwendung des Schlüssels für ihn keine sichere Kommunikation gewährleisten würde. Sehrhäufig, aber nicht in allen Vertrauensmodellen (siehe Kapitel [3.5]), wird die Aufgabe einersolchen Einrichtung von einem Trustcenter übernommen (mehr dazu in Kapitel [3.4]). Wennim Folgenden also von einer Zertifizierungsstelle gesprochen wird, kann dies neben einer ver-trauten Person auch ein Trustcenter sein.

Allgemeiner Aufbau

Neben den Angaben zur zertifizierten Person enthält ein Zertifikat üblicherweise weitere Infor-mationen, wie in Abbildung 5 zu sehen ist. Das Zertifikat selbst besitzt eine Seriennummer, umes eindeutig von anderen unterscheiden zu können. Weiterhin ist ein Gültigkeitszeitraum vor-gesehen, innerhalb dessen ein Zertifikat als vertrauenswürdig gilt (solange es nicht vorzeitigwiderrufen wurde, dazu später mehr in Kapitel [3.4.2]).

Folgendes Beispiel verdeutlicht die Notwendigkeit digitaler Zertifikate bei der Verteilungasymmetrischer 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 Vor-gang, fängt die Email ab, tauscht Bobs Schlüssel gegen seinen Eigenen aus und sendet diesenan Alice weiter; Alice vertraut dem Schlüssel nun fälschlicherweise und verwendet ihn für jedeweitere Kommunikation mit Bob; Malory kann somit alle Emails von Alice an Bob entschlüs-seln und lesen; um unauffällig zu bleiben, muss er nun noch die Emails neu, mit dem (richti-gen) öffentlichen Schlüssel von Bob, verschlüsseln und an ihn weiterschicken. DieserVorgang, den man als Man-in-the-middle-Attacke bezeichnet, kann durch den Einsatz digitalerZertifikate wirksam unterbunden werden.

1. Im weiteren Verlauf dieses Kapitel wird der Einfachheit halber von Personen gesprochen, obwohl allge-mein als Subjekte auch Dienste wie Webserver o. ä. gemeint sein können.

14


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-Standardsgedacht gewesen. X.500 definiert einen weltweiten, hierarchischen Verzeichnisbaum, in demalle Objekte wie Länder, Organisationen, Orte, Personen etc. eindeutige Namen erhalten. DieNamen sind dabei global eindeutig definiert sowie hierarchisch strukturiert und relativ zurPosition 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 nachX.509 hingegen schon, er liegt mittlerweile in Version 3 vor und bildet die Basis für vielekryptographische 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 Zer-tifikatformat verwendet.

3.3.1.1 Standardfelder

Wie bereits angesprochen, enthalten Zertifikate neben Angaben zur zertifizierten Person nochweitere, 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 Zertifi-katen nach dem X.509v3 Standard sind u. a. die im Folgenden genannten Felder enthalten[RFC2459]. Um den Verwendungszweck einzelner Felder zu verdeutlichen, wird bei einigenein Beispiel in hervorgehobener Schrift angegeben.

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

Name des Zertifizierten:Bob Offliner

Zertifikat

Zertifikataussteller:Allgemeine Deutsche Direktbank AG, Deutschland

Öffentlicher Schlüssel des Zertifizierten:59A6 105D 17E1 CC72 9C35 15B8 0E96 6A56 6142 39DC DEE4 D9E0 E521 118D 1A46 26DB 1C5F AA7E B0C6 ...

Seriennummer des Zertifikats:1234567890

Gültigkeitszeitraum:01.03.2001-30.09.2001

Signatur des Zertifikatausstellers:DEE4 D9E0 E521 118D 1A46 DCBA DFA5 022E 1D01 8388 26DB 1C5F AA7E B0C6 598E 8B8A D0B7 47C5 B0D1 ...

Angaben zur zertifiziertenPerson oder Einrichtung

Angaben zum Zertifikat

15


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

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

� Name der Zertifizierungsstelle (issuer)Bezeichnet die Zertifizierungsstelle, welche das Zertifikat herausgegeben undsigniert hat. Der Name (Distinguished Name) kennzeichnet einen Eintrag im hier-archischen X.500- (oder LDAP-) Verzeichnisbaum und ist daher eine eindeutigeIdentifizierung der Zertifizierungsstelle. Mit dem Namensmodell von LDAP-Ver-zeichnissen 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 Zer-tifikat Gültigkeit besitzt. Außerhalb dieses Zeitraumes kann der Zertifikatsaussagenicht 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 zertifi-zierten Person.

� Digitale Signatur der Zertifizierungsstelle (signature)Die digitale Signatur bestätigt die Echtheit des Zertifikates, und ordnet damit dendarin enthaltenen öffentlichen Schlüssel eindeutig der als Zertifikatnehmerbenannten Person zu.

3.3.1.2 Standarderweiterungen

Um möglichst effektiv auf zukünftige Anforderungen reagieren zu können und nicht jedes Maleine neue Version des X.509 Standards definieren zu müssen, sieht X.509v3 die Möglichkeitvor, das Format um eigene Felder, sog. generische Zertifikaterweiterungen (Extensions), zuerweitern. Dazu wurde ein spezieller Syntax definiert, mit dessen Hilfe für eigene Anwendun-gen zusätzliche Informationen in ein Zertifikat einfügt werden können. Die Zertifikate könnenso ohne großen Aufwand individuell an die Bedürfnisse eines Unternehmens oder einer Soft-ware angepasst werden.

16


Erweiterungen können zu diesem Zweck mithilfe eines sog. Critical Bits als kritisch oderunkritisch eingestuft werden. Kritisch bedeutet in diesem Zusammenhang, dass die korrekteInterpretation dieser Erweiterung für die Verwendung des Zertifikates eine notwendige Bedin-gung 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 Zertifikatan sich technisch korrekt ist. Unbekannte und gleichzeitig unkritische Erweiterungen hingegenkönnen von einer Software einfach ignoriert werden, ohne dass dies Auswirkungen auf dasgesamte Zertifikat hätte. Es lässt sich leider nicht verhindern, dass einige X.509v3 Zertifikatedurch 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 Unter-scheidung von Zertifikaten einer Zertifizierungsstelle (CA-Zertifikaten) und Zerti-fikaten von Personen oder Servern (Entity-Zertifikaten). Ein weiteres Feld enthältVorgaben für den Zertifizierungspfad, wie z. B. die maximal erlaubte Tiefe einerZertifizierungshierarchie. Eine Längenangabe im Zertifizierungspfad von 0 bedeu-tet für die Zertifizierungsstelle, dass nur Zertifikate für Personen bzw. Server aus-gestellt werden dürfen, nicht jedoch für untergeordnete Zertifizierungsstellen. Ersteine 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önnenEinschränkungen bezüglich des Verwendungszweckes von Zertifikaten aufweisen.Diese Erweiterung erlaubt daher den Verwendungszweck des in einem Zertifikatenthaltenen Schlüssels anzugeben. Die Verwendung des Schlüssels kann - wenngewünscht - eingeschränkt werden, sodass dieser beispielsweise ausschließlichzum Verifizieren von Widerrufslisten oder Zertifikaten aber nicht innerhalb einesSchlüsselaustausches verwendet werden darf. Tabelle [1] zeigt die zur Verfügungstehenden Verwendungsmöglichkeiten, welche in Form eines Bitstrings (mittelsSetzen einzelner Bits) miteinander kombiniert werden können. Allerdings ergebendurchaus nicht alle Verwendungszwecke in Kombination miteinander einen Sinn,wie beispielsweise keyAgreement in Verbindung mit encipherOnly.

Bit Bezeichnung Verwendungszweck des öffentlichen Schlüssels

0 digitalSignaturePrüfung von speziellen Signaturen zur Entity- und Datenquellen-Authentifizierung. Gilt nicht für die Verifizierung von Zertifika-ten, CRLs und bewussten Signaturen (Bits 1, 5 und 6).

1 nonRepudiationKeine Zurückweisung bei der Prüfung von Signaturen. Gilt nicht für die Verifizierung von Zertifikaten und CRLs (Bits 5 und 6).

2 keyEnciphermentVerschlüsselung von Sitzungsschlüsseln (Schlüsselmanagement, Schlüsselübertragung).

Tabelle 1 Bedeutung der key usage Bits in X.509v3 Zertifikaten

17


� Erweiterter Verwendungszweck des Schlüssels (extended key usage)Diese Erweiterung kann an Stelle oder auch ergänzend zu key usage verwendetwerden und dient dazu die Verwendung des Schlüssels noch feiner einzuschrän-ken. Softwarehersteller können dazu eigene Werte für diese Erweiterung registrie-ren 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 Stan-dard entsprechen. Um diesen Einschränkungen zu entgehen (X.509 wird meistunabhängig von X.500 eingesetzt), können in dieses Feld zusätzliche Namen desZertifizierten 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 zuverwenden, die nicht dem X.500 Standard entsprechen.

� Eindeutige Kennung des Zertifizierungsstellen-Schlüssels (authority key identi-fier)Verwendet eine Zertifizierungsstelle mehrere Schlüssel zum Signieren von Zertifi-katen, kann hier genau angegeben werden, welcher Schlüssel für dieses Zertifikatverwendet wurde. Dies ist der Fall, wenn die Schlüssel z. B. routinemäßig gewech-selt werden.

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

� CRL Verteilungspunkte (crl distribution points)Adresse einer oder mehrerer Certificate Revocation Listen (CRLs) der Zertifizie-rungsstelle, welche dieses Zertifikat signiert hat. Solche Listen dienen der Ent-scheidung, welche Zertifikate vor Ablauf ihrer Gültigkeit widerrufen wurden und

3 dataEnciphermentVerschlü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 encipherOnlyInnerhalb eines Schlüsselaustausches zur Verschlüsselung von Daten (benötigt keyAgreement, Bit 4).

8 decipherOnlyInnerhalb eines Schlüsselaustausches zur Entschlüsselung von Daten (benötigt keyAgreement, Bit 4).

Bit Bezeichnung Verwendungszweck des öffentlichen Schlüssels

Tabelle 1 Bedeutung der key usage Bits in X.509v3 Zertifikaten

18


welche weiterhin gültig sind. Abschnitt [3.4.2] beschäftigt sich eingehend mit demThema Zertifikatswiderruf.crl distribution points = URI:http://localhost/ca.crl

Mittlerweile machen viele Firmen Gebrauch von den Erweiterungsmöglichkeiten der Zertifi-kate 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 diegemeinsam vom Bundesamt für Sicherheit in der Informationstechnik (BSI) und der Gesell-schaft für mathematische Datenverarbeitung (GMD) entwickelten Erweiterungen interessant.Die folgenden Zertifikatsfelder umfassen hauptsächlich rechtliche Fragen [BSI98]:

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

� ErstellungsdatumDer Zeitpunkt der Zertifikatsausstellung wird durch einen Zeitstempel festgehal-ten. Dies dient der Bestätigung, dass der Zertifizierungsstelle zu einem bestimmtenZeitpunkt die erforderlichen Daten vorgelegen haben.

� VertretungsmachtEvtl. ist die zertifizierte Person im Besitz einer Vollmacht und darf für andere Per-sonen das digitale Signieren von Dokumenten übernehmen. Ein Beispiel hierfür istein Rechtsanwalt, welcher die Vertretungsmacht für einen Klienten in einembestimmten Rechtsfall besitzt und diesen vor Gericht vertreten darf. Neben der zer-tifizierten Person darf auch die hier genannte dritte Person die Sperrung des Zerti-fikates veranlassen ([SigG97-2] §9).

� ZulassungDiese Erweiterung bescheinigt dem Zertifizierten die Zugehörigkeit zu einerbestimmten Berufsgruppe wie Arzt, Notar, Rechtsanwalt, o. Ä.

� Monetäre BedingungenBis zu welchem Geldbetrag der Zertifizierte für von ihm signierte Dokumente haf-tet, 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 sowohlzur Authentifikation von SSL-Verbindungen des Navigator Browsers als auch zum digitalenSignieren oder Verschlüsseln von Nachrichten im Emailprogramm Messenger. Zu dem Zeit-punkt, 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 mitdenen bestimmter Standarderweiterungen.Netscapeerweiterungen sollten niemals als critical markiert werden. Die Softwareprodukteanderer Firmen verarbeiten diese Erweiterungen nicht und somit werden Zertifikate mit diesenkritischen Netscapeerweiterungen von nicht-Netscape Software als ungültig abgewiesen. EinSSL-Serverzertifikat, in dem der netscape-cert-type als kritisch markiert ist, würde beispiels-weise 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 Basis-adresse angegeben werden. Ist dies der Fall, wird vor einem Zugriff auf die jewei-lige 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 Zusammen-hang 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 dieserAdresse sollte dem Benutzer ein Formular angeboten werden, mit dessen Hilfe ersein Zertifikat verlängern kann.

� Adresse der Policy (netscape-ca-policy-url)WWW-Adresse zum Nachlesen der für das Zertifikat gültigen Zertifizierungsricht-linien 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 derAuthentizitätsüberprüfung während des Verbindungsaufbaus als zusätzlicheSicherheit. Der hier angegebene Host-Name wird mit dem tatsächlich zurückgelie-ferten 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 Zertifikateingesetzt werden darf. Aufbau: 8-Bit Wert für den Typ des Zertifikates, je 1 Bit

20


zum Kombinieren der folgenden Zertifikatstypen:

Sobald eines der Bits 5, 6 oder 7 gesetzt ist, interpretieren Softwareprodukte vonNetscape 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 unddamit die Grundlage für viele sicherheitsrelevante Konzepte auf Signatur- und Verschlüsse-lungsbasis bilden. Im weiteren Verlauf dieser Arbeit werden diese daher noch häufig zum Ein-satz kommen.

3.4 Trustcenter

Die Frage, von welcher Einrichtung Zertifikate signiert werden sollen, wurde schon im voran-gegangenem Abschnitt gestellt. Diese Aufgabe kann u. a. von einzelnen Personen erledigt wer-den, denen alle Kommunikationspartner vertrauen. Im kleinen Kreis, z. B. bei der direktenKommunikation zwischen Alice, Bob und ein paar weiteren Freunden mag das praktikabelsein. Dieser Ansatz scheitert aber schon bei kleinen bis mittleren Unternehmensnetzwerkenmit mehreren Dutzend Mitarbeitern. Dort kennt (und vertraut) man sich für gewöhnlich allen-falls noch innerhalb der eigenen Abteilung - vertrauensvolle Bindeglieder zwischen den ver-schiedenen 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-

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, Pro-gramme, Plugins usw.)

4 reserviert für zukünftige Erweiterungen

5 SSL ZertifizierungsstelleCA-Zertifikat zur Zertifizierung von Entity-Zertifikaten (SSL Server oder -Benutzer)

6 S/MIME ZertifizierungsstelleCA-Zertifikat zur Zertifizierung von Entity-Zertifikaten (S/MIME Benut-zer)

7 Object Signing ZertifizierungsstelleCA-Zertifikat zur Zertifizierung Entity-Zertifikaten (Sourcecode, Pro-gramme, Plugins usw.)

Tabelle 2 Bedeutung der netscape-cert-type Bits in X.509v3 Zertifikaten

21


center. Das Trustcenter innerhalb einer Public Key Infrastruktur ist eine Einrichtung zur Zerti-fizierung von Personen, Diensten oder Servern, sowie zur Speicherung, Bereitstellung undÜberprüfung von kryptographischen Schlüsseln. Aus diesem Grund, sollte ein Trustcenter aus-schließlich von einer vertrauenswürdigen Stelle (bzw. Organisation) betrieben werden. In derLiteratur wird ein Trustcenter häufig auch als Trusted Third Party (TTP), bzw. als vertrauens-würdige dritte Partei bezeichnet.

Wie ein Trustcenter aufgebaut sein sollte, damit es weitestgehend den Anforderungen des deut-schen Signaturgesetzes (SigG) [SigG01-1] entspricht, zeigt Abbildung 6.

Abbildung 6 mögliche Struktur eines SigG-konformen Trustcenters

Ein derartiges Trustcenter besteht aus mehreren Komponenten, die untereinander in Beziehungstehen. Deren Funktionsweise und ihre Abhängigkeiten voneinander lassen sich wie folgt cha-rakterisieren.

Registrierungseinheit

Eine Registrierungseinheit (Registration Authority, kurz: RA) innerhalb eines Trustcentersnimmt die Anträge auf Zertifizierung an und gibt die notwendigen Daten an die Zertifizie-rungseinheit weiter. Um größtmögliche Sicherheit zu gewährleisten, muss die zu zertifizie-rende Person persönlich vorsprechen und sich entsprechend ausweisen, beispielsweise durchVorlage des Personalausweises. Eine Registrierungseinheit ist nicht notwendigerweise zwi-schen Zertifizierungseinheit und den Benutzern geschaltet, die Zertifizierungseinheit kann(abhängig vom Sicherheitsmodell) Zertifizierungsanträge auch direkt von den Benutzernannehmen, ohne Umweg über eine RA.

Bob

Malory Alice

ZertifizierungseinheitZertifizierungseinheit

SchlüsselgeneratorSchlüsselgenerator

PersonalisierungseinheitPersonalisierungseinheit

VerzeichnisdienstVerzeichnisdienst

Trust Center

ZertifikatZertifikat

Chipkarte

geheimer Schlüsselgeheimer Schlüssel

Bobs ZertifikatBobs Zertifikatweitere Zertifikate...weitere Zertifikate...

RegistrierungseinheitRegistrierungseinheit

KG

CA

DIR

PS

RA

1

2

22


Zertifizierungseinheit

Die Zertifizierungseinheit (Certification Authority, kurz: CA) nimmt Zertifizierungsanträgevon der RA oder den Benutzern selbst an und erhält für jeden zu zertifizierenden Benutzer vomSchlüsselgenerator ein digitales Schlüsselpaar. Daraus erstellt die CA ein Zertifikat undsigniert es anschließend. Das Zertifikat wird zusammen mit dem privaten Schlüssel an die Per-sonalisierungseinheit weitergereicht und zusätzlich (ohne den privaten Schlüssel) dem Ver-zeichnisdienst übergeben.

Schlüsselgenerator

Der Schlüsselgenerator (Key Generation, kurz: KG) übernimmt die Generierung von asymme-trischen Schlüsselpaaren, bestehend aus öffentlichen und privaten Schlüsseln. Alternative Zer-tifizierungsrichtlinien überlassen es dem Benutzer, für die Generierung des eigenenSchlüsselpaares zu sorgen. Letztgenannte Methode bietet dem Benutzer mehr Sicherheit, nie-mand außer ihm persönlich kommt jemals direkt mit seinem privaten Schlüssel in Berührung.Diese Vorgehensweise entspricht dem eigentlichen Sicherheitsgedanken, der hinter asymmetri-schen Schlüsselpaaren steht. Der private Schlüssel soll schließlich geheim bleiben. Sie hatallerdings mehrere Nachteile. Zum einen benötigt ein Benutzer die Infrastruktur (und dasKnow-how) zum Erstellen von Schlüsselpaaren, zum anderen muss er den privaten Schlüsselspätestens dann herausgeben, sobald er auf eine Chipkarte integriert werden soll.

Personalisierungseinheit

Die Personalisierungseinheit (Personalization, kurz: PS) liefert das von der CA erhaltendeZertifikat 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 zumAbruf für andere Benutzer bereit und gewährleistet so eine gewisse Sicherheit, was die Aktua-litä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 Perso-nalisierungseinheit zu einer Einheit zusammenzufassen, wie in der Abbildung dargestellt. Alledrei Komponenten sollten isoliert von jeglichem Intranet- oder Internetzugang installiert wer-den. Die Schnittstelle einer CA zum Netzwerk bilden ausschließlich das Zertifikatsverzeichnisund die Registrierungseinheit. Nur Dienste der Zone 2 nehmen Anfragen vom Netzwerk entge-gen, für Dienste der Zone 1 besteht keinerlei Netzkontakt zur Außenwelt. Eine Ausnahme bil-det die Personalisierungseinheit, deren Kontakt beschränkt sich aber auf die persönlicheÜbergabe der Zertifikatsdaten - ein Netzwerkzugang ist auch hierfür nicht notwendig. Diensteder Zone 1 werden üblicherweise als dedizierte Rechner in einer besonders gesicherten Umge-bung (wie einem Tresorraum) realisiert. Wo hingegen für die der Zone 2 eine Installation in derDMZ (entmilitarisierte Zone) eines Unternehmens ausreichend Sicherheit gewährleistet.

23


3.4.2 Zertifikatswiderruf

Ein Zertifikatswiderruf (Sperrung) wird notwendig, wenn der Verdacht besteht, dass privateSchlüssel kompromittiert wurden. Dies ist beispielsweise der Fall, wenn Bob seine Chipkarteverliert, 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 aufChipkarten oder Festplatten zwar üblicherweise durch PINs oder Passwörter vor unbefugtenZugriffen geschützt. Setzt man allerdings ausreichend kriminelle Energie voraus, stellt auchdies kein allzu großes Hindernis für potenzielle Angreifer dar. Bei einem entsprechenden Ver-dacht muss Bob unverzüglich bei seinem Trustcenter den Widerruf des Zertifikates veranlas-sen.

Ein äußerst kritisches Thema ist die Kompromittierung von CA-Schlüsseln. Zusammen mitdem CA-Zertifikat verlieren auch alle von dieser CA ausgestellten Zertifikate ihre Vertrauens-würdigkeit.

Neben der Kompromittierung existieren weitere Gründe für den Widerruf von Zertifikaten. AlsBeispiel sei ein Mitarbeiter genannt, dem ein Zertifikat ausgestellt wurde, das die Zugehörig-keit zu seiner Firma bescheinigt. Auf Basis dieser Bescheinigung wird Zugang zu firmeninter-nen Informationen ermöglicht. Verlässt dieser nun seinen Arbeitgeber, so verliert dieeigentliche Zertifikataussage ihre Gültigkeit und das Zertifikat muss vom Trustcenter widerru-fen werden.

Es gibt verschiedene Methoden, potenziellen Kommunikationspartnern mitzuteilen, welcheZertifikate widerrufen sind:

� Online-AbrufDer Online-Abruf erfordert vor jeder einzelnen Verwendung eines Zertifikates denOnline-Zugriff zum Trustcenter. Dabei wird nachgefragt, ob das zu verwendendeZertifikat noch Gültigkeit besitzt. Man erkennt, dass dies eine zuverlässigeMethode ist, denn es werden immer die aktuellsten Sperrinformationen vom Trust-center verwendet. Die Nachteile sind der durch ständige Anfragen anfallendeOverhead beim Trustcenter sowie die nötige Online-Verbindung bei jeder einzel-nen Transaktion.

� Certificate Revocation ListBei einer Certificate Revocation List (CRL) handelt es sich um eine Art schwarzeListe (Blacklist): Das Trustcenter veröffentlicht in regelmäßigen Abständen eineListe mit den Seriennummern aller gesperrten Zertifikate. Damit reduziert sich dernotwendige Overhead z. T. erheblich, denn Übertragungen der jeweils aktuellstenCRL werden nur in vorhersehbaren Zeitabständen erforderlich. Ein Nachteil dieserMethode soll aber nicht verschwiegen werden. Zertifikate, die kurz nach Heraus-gabe einer solchen Liste gesperrt werden, sind erst mit der nächsten Aktualisierungder Liste auch tatsächlich als gesperrt zu erkennen. Bei Veröffentlichungen imWochenrhythmus wären das bis zu sieben Tage - Zeit genug für Malory um mitBobs gestohlener Chipkarte eine Menge Unfug zu treiben.

Bei einer CRL handelt es sich somit um eine Form von Offline-Abruf, bei der nurin regelmäßigen, fest definierten Abständen eine Online-Verbindung zum Trust-

24


center nötig wird. Mit kleinerem Zeitspannen beim Veröffentlichen bzw. Abrufender Liste nähert sich das Verfahren allerdings immer mehr dem Online-Abruf an.Letztlich muss man einen Kompromiss zwischen Aktualität und Overhead einge-hen.

� Weiße ListeDie weiße Liste ist das Gegenstück zu einer CRL, auf dieser werden nicht gesperrteZertifikate veröffentlicht. Weiße Listen werden allerdings nur selten verwendet, dadie Zahl der gültigen, nicht gesperrten Zertifikate meist wesentlich größer ist, alsdie der Widerrufenen. Somit wird eine auf diesem Verfahren basierende Listeerheblich umfangreicher als eine CRL.

3.5 Vertrauensmodelle

Zur Echtheitsbestätigung von Zertifikaten und um zu verhindern, dass Zertifikatinhalte nach-träglich verändert werden können, werden Zertifikate digital signiert. Diese Signatur wirdanschließ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 dieverschiedenen verwendeten Varianten - auch Vertrauensmodelle genannt - eingegangen.

3.5.1 Direct Trust

Das einfachste Vertrauensmodell ist Direct Trust. Jeder Anwender muss dabei sein eigenesZertifikat selbst signieren. Allerdings hat ein vom Anwender selbst signiertes Zertifikat unge-fähr die Glaubwürdigkeit eines selbst ausgestellten Personalausweises. Aus diesem Grundwird bei Direct Trust häufig auf den Einsatz von Zertifikaten ganz verzichtet. Dieses Vorgehenhat entscheidende Nachteile. Denn wie kann sich Alice sicher sein, wirklich Bobs öffentlichenSchlü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 kleinenRahmen zwischen ein paar Freunden noch praktikabel klingt, wird bei umfangreichen Teilneh-mergruppen 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 austau-schen und diese anschließend auch noch selbst verwalten müssen.

Direct Trust ist somit das Modell, dem das geringste Vertrauen entgegengebracht wird. DieTeilnehmer vertrauen ausschließlich Schlüsseln, die sie persönlich erhalten haben. Vorteilhaftist 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 Sicher-heitsrichtlinien durchsetzbar sind. Es ist beinahe unmöglich festzustellen, wer wem zu einembestimmten Zeitpunkt vertraut hat. Problematisch ist auch das Sperren von kompromittiertenSchlüsseln, denn wie soll man alle Teilnehmer von einmal im Umlauf befindlichen, ungültiggewordenen öffentlichen Schlüsseln benachrichtigen? Negativ einzuordnen ist auch die feh-lende rechtliche Sicherheit. Wenn jeder Teilnehmer nach Belieben neue Schlüsselpaare erzeu-gen 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 inUmgebungen, die auf eine exakte Durchsetzung von Sicherheitsrichtlinien, sowie Rechtssi-cherheit 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. Statt-dessen 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 Alicenicht nur Bobs Schlüssel, sondern auch allen öffentlichen Schlüsseln anderer Anwender, dieBob in einem Zertifikat signiert hat. Jeder Zertifikatsinhaber kann also selbst Zertifizierungsin-stanz „spielen“. Dabei entsteht wie in Abbildung 7a eine ganze Kette von vertrauten Zertifika-ten.

In der Abbildung sind Teilnehmer als dunkle Kreise dargestellt, wobei die Kürzel A, B, Msowie Z für die allseits bekannten Teilnehmer Alice, Bob, Malory und Zacharias stehen. Unbe-nannte Kreise stellen beliebige weitere Teilnehmer dieses Vertrauensmodells dar. Pfeile zwi-schen Teilnehmern symbolisieren ausgestellte Zertifikate, wobei am Pfeilursprung derAussteller und am Pfeilende der Empfänger (Zertifizierte) steht.

Abbildung 7 Vertrauensmodelle

Wenn man Abbildung 7a genauer betrachtet, sieht man, dass Alice Bob vertraut. Bob wie-derum vertraut weiteren Personen. Eine dieser Personen vertraut allerdings auch Malory. DieVertrauensbeziehung zwischen der nicht näher bezeichneten Person und Malory stellt zugleich

B

A

M

!

a) Web of Trust b) flache Zertifizierungshierarchie

c) strikt hierarchisches Modell d) zweistufige Hierarchie nach deutschem Signaturgesetz

Legende:

CA

Teilnehmer

Teilnehmer vertraut Teilnehmer

CA zertifiziert Teilnehmer

CACA

RegTPRegTP

DeutscheTelekom AGDeutsche

Telekom AGDeutschePost AG

DeutschePost AG weitere CAs...weitere CAs...

CACA

CACA

CACA CACA

CACA

CACA

Wurzel-CAWurzel-CA

Z

26


die Schwachstelle dieses Modells dar und ist deshalb in der Abbildung mit einem Ausrufezei-chen als besonders brisant gekennzeichnet. Denn wenn Bob einer Person vertraut, die wie-derum Malory vertraut, dann heißt das nichts anderes, als dass Bob von nun an auch demSchurken Malory vertraut (und damit auch allen anderen Personen, denen Malory vertraut).Problematisch stellt sich auch die Kommunikation zwischen unbekannten Personen dar. WennAlice an Zacharias eine verschlüsselte Email schicken möchte, diesen jedoch selbst nichtkennt, ist sie darauf angewiesen, dass sein Zertifikat durch eine Kette von Signaturen aufjemanden zurückzuführen ist, dem sie vertraut.

Ebenso wie beim bereits vorgestellten Vertrauensmodell Direct Trust ist es auch beim Web OfTrust sehr schwierig eine durchgehend einheitliche Sicherheitspolitik durchzusetzen. Dennwer kann schon genau bestimmen, unter welchen Voraussetzungen ein Benutzer für einenanderen ein digitales Zertifikat ausstellt. Nicht anders sieht es bei der Sperrung von Zertifika-ten aus. Bob muss jedem Teilnehmer bekannt geben, dass dieser sein Zertifikat nicht mehr ver-wenden 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 Modellgenannt. Im Unterschied zu den beiden zuvor Genannten, zertifizieren Teilnehmer dieses Ver-trauensmodells weder sich selbst noch andere Teilnehmer. Zertifikate werden ausschließlichvon vertrauenswürdigen Instanzen (Trusted Third Parties) ausgestellt und signiert. Diese sindTeil eines Trustcenters und werden i.A. als Zertifizierungsinstanz bezeichnet.

Das hierarchische Vertrauensmodell existiert in unterschiedlichen Ausprägungen bezüglich derHierarchietiefe.

� Flache ZertifizierungshierarchieDie einfachste Form ist die flache (einstufige) Zertifizierungshierarchie, wie sie inAbbildung 7b dargestellt ist. Sie besteht aus vielen Teilnehmern, aber nur einereinzigen CA.

� Strikt hierarchisches ModellDiese Form der Zertifizierungshierarchie (Abbildung 7c) enthält mehrere, hierar-chisch angeordnete CAs, wobei jeder Benutzer üblicherweise nur bei einer regi-striert ist. CA-Zertifikate einer untergeordneten CA sind von einer übergeordnetenCA signiert. Am oberen Ende der Hierarchie steht die Wurzel-CA, deren Zertifikatvon ihr selbst signiert ist. Jedes Zertifikat dieser Hierarchie kann auf das Zertifikatder Wurzel-CA zurückgeführt werden, in dem der Zertifizierungspfad entlang desBaumes zurückverfolgt wird.

Ein Vorgang namens Crosszertifizierung ermöglicht es, voneinander unabhängige Zertifizie-rungshierarchien miteinander zu verbinden. Verwendung findet dies beispielsweise bei derFusion zweier Unternehmen, die jeweils über eigene Zertifizierungsstellen verfügen und diesenun vereinen möchten. Dazu ist es nötig, dass sich die Wurzel-CAs beider Unternehmengegenseitig ein digitales Zertifikat ausstellen, um die Teilnehmer beider Hierarchien in dasjeweilige Vertrauensmodell mit einzuschließen.

27


Eine CA stellt das vertrauensvolle Bindeglied zwischen Teilnehmern einer Hierarchieebenedar. 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 durch-zusetzende Sicherheitspolitik. Ein Trustcenter kann genau festlegen, welche Teilnehmer zerti-fiziert werden und unter welchen Umständen sowie zu welchem Zweck diese ein Zertifikatausgestellt bekommen.

Eine besondere Stellung nimmt die Zertifizierungshierarchie aus Abbildung 7d ein. Es stelltdie zweistufige Hierarchie nach deutschem Signaturgesetz (SigG) dar. Hier gibt es neben derWurzelinstanz, 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 DeutschenPost AG. Dieses Modell beseitigt den letzten Kritikpunkt der Vorangegangenen: die fehlendeRechtssicherheit 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 Ent-schlüsselung notwendige Schlüssel verloren geht, sind die verschlüsselten Daten somit unwie-derbringlich verloren. Vermeiden lässt sich der endgültige Verlust digitaler Schlüssel durch dierechzeitige Hinterlegung eines Zweitschlüssels bei einer vertrauenswürdigen Instanz.

Gründe für den Einsatz einer sicheren Schlüsselhinterlegung, um bei berechtigtem Interesseverschlüsselte Daten ohne den Original-Schlüssel zu entschlüsseln, sind vielfältig [AdaLlo99]:

� Vergessenes PasswortEiner der am häufigsten auftretenden Fälle, sind Benutzer, die Passwort/PIN zurFreischaltung ihres privaten Schlüssels vergessen haben - wodurch dieser wertloswird.

� Tod des SchlüsselbesitzersWie oben, der Entschlüsselungsschlüssel ist zwar weiterhin vorhanden, aber dasPasswort bzw. die PIN zur Freischaltung des Schlüssels sind anderen Personennicht bekannt.

� SabotageEin Mitarbeiter verlässt (beispielsweise auf Grund einer Kündigung) seine Firmaund vernichtet aus Rache seinen privaten Schlüssel - und damit vielleicht dasErgebnis monatelanger Arbeit.

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

� Rechtsstaatliche ÜberwachungZur 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 frei-williger Basis geschehen. Allerdings funktionieren auf freiwilliger Basis arbeitende Verfahrennur dann, wenn alle Parteien sich daran beteiligen. Verstöße gegen Schlüsselwiederherstel-lungsprotokolle bleiben aber mit Sicherheit auch dann nicht aus, wenn sie mit hohen Strafenbelegt werden. Es sei denn, man sorgt durch ein geeignetes Verfahren dafür, dass ein solcherVerstoß nicht möglich wird. Ein Beispiel für ein unter staatlicher Kontrolle stehendes Schlüs-selwiederherstellungsverfahren, ist der von der NSA entwickelte und zeitweise von der US-Regierung eingesetzte Escrowed Encryption Standard (EES) aus dem Jahr 1994.

Beim EES-Verfahren werden private Schlüssel bei zwei staatlichen Stellen (sog. Key-escrowAgenturen) je zur Hälfte hinterlegt, um eine (vom Opfer unbemerkte) Überwachung des Nach-richtenverkehrs zu ermöglichen. Dabei wurde Wert darauf gelegt, dass nur in begründeten Fäl-len eine Schlüsselwiederherstellung von überwachender Seite (Ermittlungsbehörden,Geheimdienst) möglich ist. Mithilfe einer richterlichen Genehmigung können die Strafverfol-gungsbehörden den zur Entschlüsselung notwendigen, in zwei Teilschlüssel zerlegten Chip-schlü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 gefundenwurde, die für das Verfahren wichtige Prüfsumme zu fälschen. Dennoch wurden die Einzelhei-ten des Hardwareverfahrens lange Zeit von der NSA weit gehend geheim gehalten. Mittler-weile wurde der verwendete Algorithmus als „unclassified“ erklärt und kann nun ungehindertanalysiert werden [JoPflue01].

Aber selbst, wenn man nicht eine Hintertür in Form der Prüfsumme gefunden hätte, wer hätteAlice und Bob daran gehindert, einfach auf EES zu verzichten und stattdessen eine andere Ver-schlüsselungstechnologie zu verwenden?

3.7 Kryptographische Verfahren auf Public Key Basis

Dem TCP/IP Protokoll fehlt die Möglichkeit sichere2 Verbindungen aufzubauen. Nachfolgendwerden daher erst einmal einige kryptographische Verfahren vorgestellt, die von vorhandenerSoftware dazu verwendet werden, sichere Verbindungen aufzubauen. Für eine Beschreibungdes TCP/IP Protokolls wird auf [AnSTanen96] verwiesen.

Alle in diesem Abschnitt besprochenen kryptographischen Verfahren nutzen die Vorteile vonZertifikaten, um Dienste wie Authentizität, Vertraulichkeit und Integrität auf TCP/IP-Ebene zuimplementieren. 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 Netscapeentwickelt wurde, um Dienste wie Vertraulichkeit und Integrität (mittels Verschlüsselung),sowie Authentifizierung (durch Zertifikate) unterhalb der Anwendungsschicht des TCP/IP-Protokollstacks anzubieten. Angesiedelt zwischen dem Transportprotokoll TCP und den dar-über liegenden Anwendungsprotokollen (siehe Abbildung 8) kann SSL zur kryptographischenAbsicherung von Internet-Dienst-Protokollen wie HTTP, Telnet, FTP, POP3 oder LDAP einge-setzt werden. D. h. es ermöglicht eine abhörsichere Kommunikation und den Transport sicher-heitsrelevanter Daten über das World Wide Web.

Abbildung 8 SSL setzt zwischen TCP und einem Anwendungsprotokoll an

Der allgemeine Ablauf bei Verbindung eines Clients mit einer per SSL gesicherten Webseiteist folgender: Der Webserver sendet im ersten Schritt sein digitales Zertifikat. Sofern diesesvon einer CA ausgestellt und signiert wurde und deren digitales Zertifikat schon im Browserdes Clients gespeichert ist, erkennt dieser es als gültig an. Die Standardbrowser der FirmenMicrosoft 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 nichtenthalten ist, bleibt dem Benutzer die Entscheidung überlassen, dem Webserverzertifikat zuvertrauen. Dabei besteht natürlich die Gefahr, dass Benutzer jederzeit auch ungültige Zertifi-kate annehmen können und diesen dann in Zukunft fälschlicherweise Vertrauen schenken. DieSicherheit hängt in solchen Fällen alleine von den Benutzern selbst ab. Unternehmen, welcheaus wirtschaftlichen Interessen oder aus Gründen des Vertrauens eigene CAs betreiben, anstattihre Server von einer der großen, bekannten CAs zertifizieren zu lassen, sind deshalb daraufangewiesen, dass alle Clientrechner vor der ersten Verbindungsaufnahme mit dem Server, dasZertifikat ihrer eigenen CA in die Liste vertrauenswürdiger CAs importieren.

Intern ist die SSL-Protokollschicht in fünf weitere Protokolle unterteilt:

� Handshake-ProtokollDas Handshake-Protokoll authentifiziert den Server und (optional auch) den Clientmittels X.509v3-Zertifikaten. Es handelt das anzuwendende Kryptoverfahren zwi-schen Client und Server aus und tauscht anschließend einen symmetrischen

HTTP, Telnet, FTP, POP3, ...HTTP, Telnet, FTP, POP3, ...

Router

SSLSSL

TCPTCP

IPIP

LAN, PPP, ...LAN, PPP, ...

IPIP


HTTP, Telnet, FTP, POP3, ...HTTP, Telnet,

FTP, POP3, ...

SSLSSL

TCPTCP

IPIP


Host Host

30


Schlüssel (Sitzungsschlüssel) zwischen beiden aus.

� Change-CipherSpec-ProtokollDas Change-CipherSpec-Protokoll ermöglicht die vereinbarten Kryptoverfahrenwährend der Übertragung zu wechseln.

� Alert-ProtokollDas Alert-Protokoll versendet Fehler- und Warnmeldungen, für den Fall, dass einDatenaustausch außerplanmäßig verläuft.

� ApplicationData-ProtokollDas ApplicationData-Protokoll reicht die Daten der Anwendungsschicht an dasSSL-Record-Protokoll weiter.

� SSL-Record-ProtokollDas SSL-Record-Protokoll wendet auf die übergebenen Daten ein Hashverfahrenan und verschlüsselt (wenn gewünscht) diese anschließend symmetrisch zusam-men mit dem Hashwert.

SSL ist nicht auf die Verwendung bestimmter kryptographischer Algorithmen festgelegt. Statt-dessen haben Server und Client die Möglichkeit, sich beim Verbindungsaufbau mithilfe desHandshake-Protokolls auf die zu verwendenden Verfahren zu einigen. Folgende Algorithmenstehen dabei laut [NS98-1] zur Verfügung:

Dem Server steht dabei die Möglichkeit offen, die für den Einsatz infrage kommenden Algo-rithmen einzuschränken. Dies ermöglicht u. a. die Festlegung einer Mindestschlüssellänge, dieein verbindungswilliger Client vorweisen muss, damit eine SSL-Verbindung zu Stande kommt.Bestenfalls einigen sich Server und Client darauf hin auf den kryptographisch stärksten Algo-rithmus, den beide gemeinsam unterstützen. Anderenfalls kann es aber auch vorkommen, dassgar keine Einigung zu Stande kommt - und damit auch keine Verbindung. Dies ist beispiels-weise der Fall, wenn der Client eine (veraltete) Software einsetzt, deren kryptographischenAlgorithmen noch durch die ehemaligen US-Exportbeschränkungen auf Schlüssellängen vonmaximal 40-bit beschränkt sind, der Server aber eine höhere Sicherheit fordert (wie beispiels-weise 128-bit). Der US-amerikanischen Exportpolitik bezüglich starker Kryptographie widmetsich Kapitel [3.9.3].

Die Authentizität von Server und Client wird mithilfe der schon besprochenen X.509v3 Zerti-

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

31


fikate gewährleistet. Dabei kann sich sowohl der Server als auch der Client per Zertifikatauthentifizieren. In Abhängigkeit der Serverkonfiguration ist es ebenso möglich, dass sowohlClient, als auch Server auf den Einsatz von Zertifikaten verzichten und öffentliche Schlüsselverwenden, die nicht signiert sind. Weiterhin kann auf den Einsatz von Verschlüsselung ganzverzichtet werden, für den Fall, dass die Gesetzgebung eines Staates den Einsatz von Ver-schlüsselung in öffentlichen Netzen nicht erlaubt. Frankreich z. B. beschränkt auch heute nochden 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, indem er sein digitales Zertifikat sendet, welches vom Client dazu verwendet wird, die Identitätdes Servers zu überprüfen.

Der Client erkennt die Zugehörigkeit des Zertifikates zum Server und damit die Identität des-selben an, wenn sämtliche der in Abbildung 9 geforderten Bedingungen erfüllt werden.

� Liegt das heutige Datum innerhalb des Gültigkeitszeitraumes?Der Client vergleicht den Gültigkeitszeitraum des Server-Zertifikates mit dem heu-tigen Datum. Außerhalb dieses Zeitraumes ist das Zertifikat ungültig, d. h. der Zer-tifikatsaussage darf nicht vertraut werden.

� 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ürdigenCAs. Der Inhalt dieser Liste entscheidet darüber, welche Serverzertifikate vomClient akzeptiert werden und welche nicht. Dazu muss der Distinguished Name(DN) auf dem Serverzertifikat dem DN einer CA dieser Liste entsprechen. Notfallswird versucht, eine übergeordnete CA zu finden, auf die dies zutrifft.

� 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-Zer-tifikat (aus o. g. Liste) enthalten ist, ob die CA-Signatur im Serverzertifikat gültigist. Ist diese ungültig, weil beispielsweise das Zertifikat nachträglich verändertwurde, oder passt der öffentliche CA-Schlüssel nicht zum Signieren verwendetenprivaten CA-Schlüssel, wird der Server nicht authentifiziert.

� Stimmt der auf dem Zertifikat angegebene Domainname mit dem tatsächli-chen Domainnamen überein?Dieser Schritt überprüft, ob der Server auch tatsächlich die im Zertifikat angege-bene Netzwerkadresse besitzt. Wenn der Domainname (bzw. die IP-Adresse) nichtübereinstimmt, muss der Client die Verbindung zum Server ablehnen. Die Praxissieht allerdings ein wenig anders aus, die meisten Webbrowser informieren denAnwender über diesen Missstand und überlassen ihm die Wahl, ob die Verbindungwirklich abgebrochen werden soll.

Der Authentifizierungsprozess gilt als abgeschlossen und damit der Server als korrekt authen-tifiziert, wenn alle genannten Bedingungen erfüllt sind. Fordert der Server zusätzlich eineAuthentifikation des Clients, folgt anschließend die im nächsten Abschnitt beschriebene Pro-zedur zur Client-Authentifizierung.

32


Abbildung 9 SSLv3-Server: Authentifizierungsvorgang im Überblick

Abschließend generiert der Client einen zufälligen Datenblock, verschlüsselt ihn mit dem pri-vaten Schlüssel des Servers und sendet ihn an diesen. Ist der Server in der Lage, die Daten zuentschlüsseln, beiweist dies, dass er auch im Besitz des zum Zertifikat gehörenden privatenSchlü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 sichauch ein Client gegenüber dem Server authentifizieren muss. Das Wissen über die Identität desClients ermöglicht auf Serverseite eine Rechteverwaltung der Art, dass nur autorisierten Cli-ents der Zugang zu bestimmten Ressourcen (mit möglicherweise unterschiedlichen Zugriffs-rechten) gewährt wird, wohingegen nicht-autorisierten Clients der Zugang verwährt bleibt.

Der Client sendet vor Beginn des Authentifizierungsprozesses neben seinem Zertifikat nocheinen zufällig generierten Datenblock, digital signiert an den Server. Der Server nutzt die digi-tal 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üs-sels ist, welcher zum Zertifikat gehört.

DN des Servers:cn=IntranetDemo,o=diba,c=de

DN der ausstellenden CA:cn=PrototypeCA,o=diba,c=de

Öffentlicher Schlüssel des Servers:59A6 105D 17E1 CC72 9C351A46 26DB 1C5F AA7E ...


Signatur der CA:DEE4 D9E0 E521 118D 1A46 DCBA26DB 1C5F AA7E B0C6 ...

Zertifikat des Servers

DN der CA:cn=PrototypeCA,o=diba,c=de

Öffentlicher Schlüssel der CA:8B8A D0B7 47C5 B0D1 1F0C15B8 0E96 6A56 6142 ...


Zertifikat der ausstellenden CA

Zertifikat einer beliebigen weiteren CA

...

...


�

�

�

�

Liste vertrauenswürdiger CAs des Clients

33


Abbildung 10 SSLv3-Client: Authentifizierungsvorgang im Überblick

Ähnlich wie bei der Server-Authentifizierung muss nun der Server eine positive Antwort aufdie folgenden fünf Fragen des Client-Authentifizierungsprozesses erhalten, um einer Bindungdes öffentlichen Schlüssels an die Identität des Clients zu vertrauen.

� Erlaubt der öffentliche Schlüssel des Clients die Überprüfung der ClientSignatur?Der Server überprüft an Hand des öffentlichen Schlüssels, welcher im Client-Zerti-fikat enthalten ist, ob die Signatur des vorher gesendeten Geheimnisses validiertwerden kann. Gelingt dies nicht, wird die Verbindung abgebrochen.

� Liegt das heutige Datum innerhalb des Gültigkeitszeitraumes?Der Server vergleicht den Gültigkeitszeitraum des Zertifikates mit dem heutigenDatum. Außerhalb dieses Zeitraumes ist das Zertifikat ungültig, d. h. der Zertifi-katsaussage darf nicht vertraut werden.

� 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ürdigenCAs. Der Inhalt dieser Liste entscheidet darüber, welche Zertifikate vom Serverakzeptiert werden und welche nicht. Dazu muss der Distinguished Name (DN) aufdem Zertifikat dem DN einer CA dieser Liste entsprechen. Notfalls wird versucht,eine übergeordnete CA zu finden, auf die dies zutrifft.

DN des Clients:cn=Bob Offliner,o=diba,c=de

DN der ausstellenden CA:cn=PrototypeCA,o=diba,c=de

Öffentlicher Schlüssel des Clients:59A6 105D 17E1 CC72 9C351A46 26DB 1C5F AA7E ...



Zertifikat des Clients

DN der CA:cn=PrototypeCA,o=diba,c=de

Öffentlicher Schlüssel der CA:8B8A D0B7 47C5 B0D1 1F0C15B8 0E96 6A56 6142 ...


Zertifikat der ausstellenden CA


...

...


�

�

�

�

Liste vertrauenswürdiger CAs des Servers

Signatur des Clients:B0C6 598E 8B8A D0B7 26DB 1C5F AA7E B0C6 1010 03DE 9AD0 ...

Datenblock:0100 1011 1000 1010 1001 0101

Zufällige Daten des Clients

34


� 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 CA-Zertifikat (aus o. g. Liste) enthalten ist, ob die CA-Signatur im Client-Zertifikatgültig ist. Ist diese ungültig, weil beispielsweise das Zertifikat nachträglich verän-dert wurde, oder passt der öffentliche CA-Schlüssel nicht zum Signieren verwen-deten privaten CA-Schlüssel, wird der Client nicht authentifiziert.

� Ist der authentifizierte Client autorisiert auf die angeforderte Ressource zuzu-greifen?Der Server überprüft die Berechtigung an Hand sog. Zugangskontrolllisten(Access Controll Listen, kurz: ACL) und liefert die Ressource dann mit individuel-len Zugriffsrechten an den Client aus. Verschiedene Zugriffsstufen können hierzuauf dem Server eingerichtet werden. Dazu gehören neben dem Vollzugriff ein ein-geschränkter (nur lesen) Zugriff sowie die Möglichkeit dem Client den Zugriff aufdie angeforderte Ressource komplett zu verweigern (kein Zugriff).Dies ermöglicht es beispielsweise einem Finanzinstitut, das Zertifikate sowohl anKunden als auch an Mitarbeiter ausgegeben hat, die Berechtigungen derart zu kon-trollieren, dass Kunden ausschließlich Zugriff auf ihre eigenen Kontendaten erhal-ten. Mitarbeiter hingegen autorisiert sind, vertrauliche Konditionen vomWebserver abzurufen. Die Authentifikation auf Zertifikatsbasis ersetzt damit diesonst übliche Basic Authentification an Hand eines Benutzernamens mit dem dazu-gehörenden Passwort.

Eine Einführung ins SSL-Protokoll, sowie den verwendeten Verschlüsselungsverfahren undAuthentifikations-Mechanismen liefert Netscape in [NS98-1]. SSL gilt als das meistverwen-dete Verschlüsselungsprotokoll im Internet; außerdem ist es ideal für die kryptographischeAbsicherung komplexer TCP/IP-Netze geeignet, wie sie in großen und mittelständischenUnternehmen vorkommen [KlSchm98].

3.7.1.3 Notwendige Zertifikaterweiterungen

Wie bereits eingangs erwähnt, verwenden alle in diesem Abschnitt besprochenen kryptogra-phischen Verfahren die Vorteile von Zertifikaten nach X.509v3, um eine sichere Authentifika-tion 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ürden jeweiligen Einsatzzweck akzeptiert werden. Diese Informationen werden von der einge-setzten Trustcenter-Software benötigt, um gültige Zertifikate auszustellen.

Folgende Tabelle enthält Erläuterungen zu den folgenden Tabellen [5], [6] und [8] bezüglichdes Einsatzes der von Netscape geforderten Zertifikatserweiterungen.

Bemer-kung Nr.

Erläuterung

1Nur gültig in Verbindung mit mehrstufigen Hierarchien, beim Ein-satz 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


Erweiterungen für SSL-Clientzertifikate

Folgende Erweiterungen sollten in Zertifikaten gesetzt sein, damit diese sowohl von Produktender Firmen Netscape als auch Microsoft als gültig für SSL Clients angesehen und nicht zurück-gewiesen werden.

Erweiterungen für SSL-Serverzertifikate

Folgende Erweiterungen sollten in Zertifikaten gesetzt sein, damit diese sowohl von Produktender Firmen Netscape als auch Microsoft als gültig für SSL Server angesehen und nicht zurück-

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.

5Wird 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.

Zertifikat derWurzel CA1

Zertifikat einer untergeordneten CA

ausgestellte Benutzerzertifikate

Bemer-kung Nr.

authorityKeyIdentifier authorityKeyIdentifier authorityKeyIdentifier 2

basicConstraints:CA = true

basicConstraints:CA = true

3

cRLDistributionPoints cRLDistributionPoints 2 + 4

keyUsage:keyCertSign, cRLSign


keyUsage:digitalSignature

netscape-cert-type:SSL CA


netscape-cert-type:SSL Client

5

subjectKeyIdentifier subjectKeyIdentifier subjectKeyIdentifier 2

Tabelle 5 notwendige Zertifikaterweiterungen für SSL Clientzertifikate

Bemer-kung Nr.

Erläuterung

Tabelle 4 Erläuterungen zum Verständnis der Tabellen [5], [6] und [8]

36


gewiesen werden.

3.7.2 S/MIME

S/MIME (Secure MIME) ist ein Verschlüsselungsstandard der US-Firma RSA Security Inc. zurWahrung von Vertraulichkeit, Authentizität und Integrität elektronischer Nachrichten (Email).S/MIME verwendet für die Unterteilung einer Nachricht das von den meisten Emailprogram-men unterstützte MIME-Format (Multipurpose Internet Mail Extensions). Nachrichten imMIME-Format können aus mehreren Teilen zusammengesetzt sein, wobei jeder dieser Teileaus einem anderen Datentyp bestehen darf (Texte, Bilder, Filme, Musik, etc.). S/MIME stellthierfü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, Hashfunk-tionen sowie Schlüsselaustausch. In [RFC2633] wird festgelegt, welche Algorithmen dabei aufSender- und Empfängerseite unterstützt werden müssen und welche zusätzlich verwendet wer-den sollten, um die Kompatibilität zu älteren S/MIME Versionen zu ermöglichen.




Bemer-kung Nr.





keyUsage:keyEncipherment



netscape-cert-type:SSL Client6, SSL Server

5

subjectAltName 7


Tabelle 6 notwendige Zertifikaterweiterungen für SSL Serverzertifikate

Sender Empfänger

Verfahren muss unterstützt werden

zusätzlichmöglich

muss unterstützt werden

zusätzlichmöglich

Verschlüsselung Tripple-DES Tripple-DES RC2/40

Digitale Signatur DSS RSA DSS RSA

Schlüsselaustausch Diffie-Hellman RSA Diffie-Hellman RSA

Hashfunktion SHA-1 SHA-1 MD5

Tabelle 7 S/MIMEv3: kryptographische Algorithmen auf Sender- und Empfängerseite

37


Zudem werden Zertifikate nach dem X.509v3 Standard verwendet, um einen sicheren Aus-tausch 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 Microsoftund Netscape in ihren Emailprogrammen unterstützt und eignet sich so hervorragend zur Ver-schlüsselung des elektronischen Nachrichtenverkehrs.


Folgende Erweiterungen sollten in Zertifikaten gesetzt sein, damit diese sowohl von Produktender Firmen Netscape als auch Microsoft als gültig für S/MIME Benutzerzertifikate angesehenund nicht zurückgewiesen werden. Die in Tabelle [4] aufgeführten Erläuterungen gelten auchfür diese Erweiterungen.

3.7.3 IPSec

IPSec (Internet Protokoll Security) ist eine Erweiterung für das IP-Protokoll, die durch denEinsatz von Kryptographie Vertraulichkeit, Authentizität und Integrität gewährleistet. ImGegensatz zu SSL wird für IPSec keine neue Schicht ins TCP/IP Modell eingeführt, sieheAbbildung 11. Stattdessen wird das IP-Protokoll selbst um einige Bestandteile wie Schlüs-selaustausch, Verschlüsselung und Authentifikation erweitert. Für das momentan verwendeteIPv4 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 Stan-dards und wird folglich von einer ganzen Reihe von RFCs beschrieben (u. a. die RFCs 2401-2412). 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 symmetrischeVerschlüsselung und die Authentifikation von IP-Paketen mithilfe einer schlüssel-




Bemer-kung Nr.





keyUsage:digitalSignature8,keyEncipherment9

netscape-cert-type:S/MIME CA

netscape-cert-type:S/MIME CA

netscape-cert-type:S/MIME

5

subjectAltName 7


Tabelle 8 notwendige Zertifikaterweiterungen für S/MIME Benutzerzertifikate

38


abhängigen Hashfunktion.

� IKMP (Internet Key Management Protokoll)Der zweite Bereich ist für das Schlüsselmanagement zuständig. Vom IETF wurdedazu das IKMP (Internet Key Management Protokoll) entwickelt, das für denSchlüsselaustausch mithilfe asymmetrischer Verfahren sorgt.

Abbildung 11 IPSec verschlüsselt auf IP-Ebene

3.7.3.1 IPSP

Der Funktionsbereich IPSP ist selbst zweigeteilt. Zwei unterschiedliche Übertragungsproto-kolle können für den Transport der Daten eingesetzt werden. Die symmetrische Verschlüsse-lung von IP-Paketen wird vom Encapsulated Security Payload (ESP) genannten Protokoll zurVerfügung gestellt. Welche Verschlüsselungsverfahren dafür verwendet werden, ist hierbeinicht festgelegt, [RFC1829] schlägt beispielsweise DES vor. Soll auf Verschlüsselung verzich-tet werden, kommt der Authentication Header (AH) zum Einsatz. Dieser ermöglicht durch eineschlüsselabhängige Hashfunktion wie MD5 oder SHA1 die Integritätsprüfung von IP-Paketen([RFC1828]).

ESP

Encapsulated Security Payload ([RFC2406]) bietet zwei unterschiedliche Arbeitsmodi. ImTransportmodus werden ausschließlich die Nutzdaten eines IP-Paketes verschlüsselt. Der Hea-der selbst bleibt unverändert, damit er für Router, die ein Paket durchläuft, lesbar ist. Im Tun-nelmodus hingegen wird das gesamte IP-Paket (inkl. Header und Nutzdaten) verschlüsselt undin 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 Empfangs-adresse eines Paketes untergebracht sind, unlesbar gemacht.

Nützlich ist der Tunnelmodus vor allem dann, wenn Pakete über unsichere Zwischensystemegeschickt werden, also beispielsweise zwischen zwei Firewall-Systemen, welche die VPN-Verbindung realisieren, wie in Abbildung 13 dargestellt. In solch einem Fall sind für einenLauscher im Zwischennetz nur die Informationen des äußeren Paketes sichtbar. D. h. alsSende- und Empfangsadresse die beiden Firewalls, welche auch als VPN-Gateways oder Tun-nelendpunkte bezeichnet werden. Ob das Paket vom Sender A oder B abgeschickt wurde undwelchen Empfänger es wirklich erreichen soll, kann ein Lauscher nicht erkennen. Die Firewalldes Empfängers hingegen, erhält die notwendigen Ziel-Informationen nach der Authentifizie-

HTTP, Telnet, FTP, POP3, ...HTTP, Telnet, FTP, POP3, ...

RouterTCPTCP

IPSecIPSec


IPIP


HTTP, Telnet, FTP, POP3, ...HTTP, Telnet,

FTP, POP3, ...

TCPTCP

IPSecIPSec


Host Host

39


rung und Entschlüsselung des eigentlichen (eingekapselten) IP-Paketes und kann dieses dannohne IPSec-Authentifizierung oder -Verschlüsselung an den richtigen Empfänger weiterleiten.

Abbildung 12 ESP Modi im Vergleich

Der Header des umgebenden IP-Paketes wird von ESP allerdings nicht verschlüsselt oderauthentifiziert, sodass das Routing der IP-Pakete selbst im Tunnelmodus kein Problem fürRouter oder Switches darstellt, welche IPSec selbst nicht implementieren. Der neue Tunnel-IP-Header dient somit zum Weiterleiten zwischen den beiden Tunnelendpunkten.

Abbildung 13 IPSec mit ESP im Tunnelmodus

ESP im Tunnelmodus ähnelt dem NAT-Verfahren (Network Address Translation), das von eini-gen Firewalls verwendet wird, um ganze Subnetze hinter einer IP-Adresse zu verbergen. Dabeide 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-

IP Header DatenESP Header ESP Trailer ESP Auth

IP Header Daten

neuerIP Header

DatenESP Header ESP Trailer ESP AuthIP Header

Orginal IP-Paket

IP-Paket mit ESP im Transportmodus

IP-Paket mit ESP im Tunnelmodus

verschlüsselt

authentifiziert

verschlüsselt

authentifiziert

Sender B

Internet

Empfänger A

verschlüsselteIP Pakete

Tunnel

VPN-fähigeFirewall A

VPN-fähigeFirewall B

Sender A

Empfänger B

unverschlüsselteIP Pakete

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 wer-den.

AH

Der Authentication Header ([RFC2402]) sieht im Gegensatz zu ESP keinerlei Verschlüsselungvor, sondern soll ausschließlich die Integrität eines IP-Paketes sicherstellen. Dazu wird auf dieNutzdaten und einige ausgewählte Header-Felder des Paketes eine schlüsselabhängige Hash-funktion 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 mitAH verwendet werden. AH erlaubt keine nachträglichen Änderungen an IP-Paketen, da sonstdie AH-Prüfsumme - welche die Integrität des IP-Paketes sicherstellen soll - nicht mehr kor-rekt 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 IPSecfür das Schlüsselmanagement zuständig. Es stehen zwei von einander unabhängig entwickelteVerfahren zur Auswahl, um diese Aufgabe zu erfüllen. Zum einen SKIP, welches von derFirma SUN entwickelt wurde, zum anderen das Gespann aus Oakley und ISAKMP, welchesbeispielsweise bei der IPSec-Implementierung von Microsofts Windows 2000 Verwendungfindet.

SKIP

Das Simple Key Management Protokoll (SKIP) ermöglicht wie das im Folgenden besprocheneOakley einen Diffie-Hellman-Schlüsselaustausch (key agreement). Dazu wurden die IP-Paketeum spezielle Informationen, die der Empfänger zum Entschlüsseln oder Überprüfen des Hash-wertes benötigt, im Header erweitert. Somit sind alle relevanten Informationen schon imDatenpaket enthalten.

SKIP funktioniert im Prinzip folgendermaßen: Senderin (Alice) und Empfänger (Bob) berech-nen mithilfe des Diffie-Hellman key agreement Verfahrens einen gemeinsamen geheimenSchlüssel k. D. h., Alice verwendet den öffentlichen Schlüssel von Bob gx modp (beispiels-weise aus einem X.509 Zertifikat) um mithilfe ihres privaten Schlüssels y den gemeinsamengeheimen Schlüssel k zu berechnen.

k = gxy modp

Bob verfährt entsprechend umgekehrt und verwendet seinen eigenen privaten Schlüssel x undden öffentlichen Schlüssel von Alice gy modp um denselben gemeinsamen Schlüssel k zuerhalten.

k = gyx modp

41


Diese Prozedur ist prinzipbedingt nur einmal notwendig - solange weder Alice, noch Bob ihrasymmetrisches Schlüsselpaar wechseln, muss der gemeinsame Diffie-Hellman-Schlüssel kfür eine zukünftige Kommunikation nicht neu berechnet werden.

Der ausgetauschte Schlüssel k wird allerdings nicht direkt zum Verschlüsseln der IP-Paketebenutzt. Aus Sicherheitsgründen werden Nachrichten (welche üblicherweise aus mehrerenPaketen bestehen) mit unterschiedlichen Sitzungsschlüsseln verschlüsselt. Dazu wird vom aus-getauschten 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üsselteSitzungsschlüssel ks wird dann als Bestandteil des SKIP-Headers im IP-Paket untergebrachtund mitversendet.

Oakley und ISAKMP sowie IKE

Das Internet Security Association and Key Management Protocol (ISAKMP) beschreibt, wieSecurity Associations (SAs) zwischen Kommunikationspartnern auszuhandeln sind. SAs sindtemporäre Sicherheitsrichtlinien, die alle Parameter für eine sichere Verbindung enthalten, wieetwa die zu verwendenden kryptographischen Algorithmen oder die Lebensdauer von Schlüs-seln. Oakley beschreibt eine Serie von verschiedenen Schlüsselaustauschverfahren, die nach-einander angewendet werden und zur Authentifikation sowie beim Austausch vonSitzungsschlüsseln zum Einsatz kommen.

Sowohl Oakley als auch ISAKMP sind ausschließlich Beschreibungen eines Frameworks - derInternet Key Exchange (IKE, [RFC2409]) hingegen ist eine konkrete Implementierung vonOakley/ISAKMP und umfasst neben dem Schlüsselaustausch auch die Authentifizierung vonTeilnehmern unter Benutzung von SAs.IKE kommt somit beim Aufbau der gesicherten Verbindung zum Einsatz. In einer ersten Phasesorgt IKE für den Austausch von gemeinsamen geheimen Schlüsseln und der Authentifikationvon Verbindungspartnern durch Zertifikate oder Shared Secrets. Dazu wird - wie bei IKMP -das Diffie Hellman key agreement Verfahren verwendet. In der zweiten Phase werden zufälliggenerierte, symmetrische Schlüssel ausgetauscht, um die eigentliche Verbindung zu verschlüs-seln. In jeder Phase müssen sich die Verbindungspartner auf die jeweiligen zu verwendendenkryptographischen Algorithmen einigen, wie beispielsweise DES- oder IDEA-Verschlüsse-lung. Kommt keine Einigung zu Stande, da die VPN-Verbindungspunkte unterschiedlich kon-figuriert 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 priva-ter Netzwerke (VPN). Virtuelle private Netzwerke dienen dazu, Firmen mit mehreren Nieder-lassungen die Kommunikation und den gemeinsamen Zugriff auf zentrale Ressourcen zuermöglichen oder mobilen Mitarbeitern Zugang zum lokalen Netzwerk zu verschaffen. DerAufbau einer solchen Verbindung erfolgt i.A. über ein unsicheres (öffentliches) Transitnetz-werk wie dem Internet. Eine derartige Verbindung wird virtuell privat genannt, da es sich dabeium 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-Pake-ten ermöglicht in einem solchen VPN den Schutz des Netzwerkverkehrs auf IP-Ebene3 vor fol-genden Bedrohungen:

� Unbemerkte Datenänderung während des VersendensBeim Einsatz von IP-ESP oder IP-AH

� Mitlesen von DatenBeim Einsatz von IP-ESP.

� Unautorisierter DatenzugriffBei Authentifikation mittels X.509 Zertifikaten, Kerberos oder Shared Secrets.

Die Verwendung von IPSec im Tunnelmodus erfolgt für Rechner, die nicht zum Senden oderEmpfangen eingesetzt werden, vollkommen transparent. D. h. Rechner, welche innerhalb desTunnels passiert werden und keinen Tunnelendpunkt bilden, müssen nicht über IPSec infor-miert werden. Ausschließlich Rechner am jeweiligen Tunnelende sind für die Sicherheitzuständig.

Als Einsatzgebiet für eine IPSec-Implementierung wie sie beispielsweise Windows 2000 bie-tet, sind folgende Anwendungsfälle denkbar [MS00-3]:

� LAN: Peer-to-PeerVerbindungen innerhalb eines LANs zwischen zwei Client-Rechnern, ohne Ver-mittlung eines zusätzlichen IPSec-Gateways. Die Kommunikation wird aus-schließlich zwischen den beiden Rechnern verschlüsselt, der restliche LAN-Verkehr bleibt dagegen weiterhin unverschlüsselt. Diese Konfiguration schützt vorLAN-internen Angreifern, wie beispielsweise Mitarbeitern des eigenen Unterneh-mens und bietet die größte Sicherheit, da die Verbindung von Anfang bis Ende(peer-to-peer) verschlüsselt wird.

� LAN: Client/ServerVerbindungen innerhalb eines LANs zwischen einem sicheren Server und zugrei-fenden Client-Rechnern4. Die Kommunikation zwischen dem Server und den Cli-ents erfolgt verschlüsselt, der restliche LAN-Verkehr bleibt dagegen weiterhinunverschlüsselt. Diese Konfiguration schützt ebenso wie Peer-to-Peer vor LAN-internen Angreifern, wie beispielsweise Mitarbeitern des eigenen Unternehmens.

� WAN: Gateway-to-Gateway (z. B. Router-to-Router oder Firewall-to-Fire-wall)Eine Verbindung von zwei LANs über ein möglicherweise unsicheres Zwischensy-stem (Transitnetz) wie das Internet. Die VPN-Gateways bilden die beiden Tun-nelendpunkte, 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 Gatewaysaufbauen, müssen kein IPSec unterstützen. Allerdings bleibt bei der Gateway-to-Gateway Kommunikation die Verbindung der jeweiligen Rechner bis zum Gate-way unverschlüsselt. Das unsichere Transitnetz unterscheidet sich sicherheitstech-nisch nicht mehr von einer dedizierten WAN-Verbindung. Diese Konfigurationbietet ausschließlich Schutz vor Angreifern aus dem Zwischensystem und imGegensatz zu den beiden Vorhergenannten keinerlei Sicherheit vor LAN-internenAngreifern.

� Remotezugriff: Client-to-Gateway (z. B. Client-to-Firewall oder Client-to-Router)Die Verbindung mobiler Client-Rechner (außerhalb des LANs) über ein mögli-cherweise unsicheres Transitnetz mit dem LAN des Unternehmens (um Zugriff aufRessourcen und Server des Firmennetzes zu erhalten) wird auch als Remote-Accessbezeichnet. Die Kommunikation zwischen dem Gateway und den Clients erfolgtverschlüsselt, die restliche LAN Kommunikation bleibt dagegen weiterhin unver-schlüsselt. Diese Konfiguration bietet den gleichen Schutz vor externen Angreifernwie eine Gateway-to-Gateway Lösung.


Die Komplexität des IPSec Standards ermöglicht eine flexible Anpassung an die jeweiligenSicherheitsbedürfnisse. Es können verschiedene Tunnel unterschiedlich konfiguriert oderunterschiedliche kryptographische Algorithmen eingesetzt sowie zur Authentifikation auf Zer-tifikate verzichtet und stattdessen Kerberos verwendet werden. Diese Flexibilität hat allerdingseinen entscheidenden Nachteil. Die Vielzahl von Herstellern, die IPSec-fähige Router, Fire-walls oder Betriebssysteme (bzw. -Erweiterungen) anbieten, verwenden z. T. inkompatibleIPSec-Implementierungen. Kompatibilitätsprobleme erschweren nicht nur den gleichzeitigenEinsatz von Produkten unterschiedlicher Hersteller nebeneinander, sie erschweren auch eineallgemein gültige Aussage darüber, welche Erweiterungen notwendig sind, damit Zertifikatevon den jeweiligen Produkten für IPSec akzeptiert werden.

An dieser Stelle wird daher auf eine tabellarische Auflistung der notwendigen Zertifikaterwei-terungen verzichtet.

3.8 Verzeichnisdienste

Verzeichnisdienste bieten Zugriff auf Verzeichnisse und wurden bereits in Kapitel [3.4.1] imZusammenhang mit der öffentlichen Bereitstellung von Zertifikaten und Widerrufslistenerwähnt. Verzeichnisse wie X.500 oder LDAP unterscheiden sich von üblichen Datenbankendurch eine baumartig strukturierte Anordnung des verwalteten Datenbestandes. Verzeichnissesind darauf ausgelegt, weit gehend statische Daten zu verwalten, Änderungen am Datenbe-stand stellen gegenüber der reinen Abfrage von Daten eher die Ausnahme dar. Daten, die inVerzeichnissen verwaltet werden, sind beispielsweise Namen, Adressen, Informationen überPersonen, Organisationen, Gruppen, Datenspeicher, Geräte, Dienste oder auch Zertifikate undWiderrufslisten.

Im Folgenden werden die verbreitetsten Basisdienste und Technologien für die komfortableVerwaltung von Zertifikaten und Widerrufslisten besprochen.

44


3.8.1 X.500

Der Verzeichnisdienst X.500 wird an dieser Stelle nur kurz umrissen, es werden insbesonderedie Unterschiede zu dem im nächsten Abschnitt besprochenen LDAP beschrieben. X.500 setztauf dem OSI-Schichtenmodell auf und sieht keine Benutzung vorhandener Kommunikations-protokolle wie TCP/IP5 vor. Das OSI-Schichtenmodell erfordert einen erheblichen Mehrauf-wand bei der Entwicklung von Verzeichnisclients und -Servern und bietet für die öffentlicheBereitstellung von Zertifikaten und Widerrufslisten keine Vorteile, sodass es im Allgemeinendurch das „leichtgewichtigere“ LDAP ersetzt werden kann.

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 dientdem Zugriff auf die im Verzeichnis enthaltenen Informationen (siehe Abbildung14).

� 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 mei-sten Anwendungsfälle benötigt werden. Hinzu kommt, dass die Kommunikation zwischen Cli-ent und Server im Regelfall recht hohe Netzlasten erzeugt.

5. TCP/IP ist im Gegensatz zum OSI-Schichtenmodell bereits Bestandteil der meisten Betriebssysteme.

X.500 Client X.500 Server

Verzeichnis

OSI

DAP

45


3.8.2 LDAP

Das Lightweight Directory Access Protocol (LDAP) ist ebenso wie X.500 ein offener Standardfür Informationsdienste auf Basis einer baumähnlichen (hierarchischen) Datenbankstrukturund ist z. B. in Microsofts Windows 2000 Server in Form des Active Directories integriert. DerVorteil gegenüber einer normalen Datenbank ist die attributsbezogene Speicherung von Infor-mationen. LDAP ist aus dem im vorigen Abschnitt besprochenen X.500 Verzeichnisdienst ent-standen, benutzt aber an Stelle des OSI Schichtenmodells einen gewöhnlichen TCP/IPProtokollstack. Bei der Entwicklung von LDAP wurde nur ein Teil der DAP-Funktionen über-nommen, allerdings reichen die Vorhandenen vollständig aus, um den Rest zu emulieren[ThBend99]. Der Verzeichnisaufbau ist im Vergleich zu X.500 etwas vereinfacht worden, bei-spielsweise 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 einemX.500-ähnlichen Verzeichnis direkt über den TCP/IP-Protokoll-Stack abzuwickeln. LDAPdefiniert nicht das Verzeichnis selbst. In der Literatur findet man oft zwei unterschiedlicheInterpretationen, an einigen Stellen wird von LDAP-Verzeichnissen gesprochen, an anderenwiederum nur von LDAP als Protokoll. Natürlich ist LDAP ein Protokoll - und zwar für dieKommunikation zwischen LDAP-Client und -Server. Allerdings wird LDAP z. T. auch ohneeinen expliziten X.500 Server eingesetzt, indem sich der LDAP-Server für den Verzeichnis-dienst verantwortlich zeigt. Im ersten Fall hat der LDAP-Server nur die Funktion eines Gate-ways, 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 dieLDAP-Nachrichten übersetzt und an den X.500 Server weiterleitet, wie in Abbildung 15 zusehen.

Abbildung 15 LDAP Server als Gateway zum X.500 Server

LDAP Client LDAP Server X.500 Server

Verzeichnis

TCP/IP OSI

LDAP DAP

46


Dies ist notwendig, da LDAP Clientprogramme ausschließlich die Kommunikation überLDAP-Nachrichten beherrschen, X.500 Server wiederum verstehen nur DAP. Mehr noch, eskommen gar unterschiedliche Schichtenmodelle zum Einsatz (TCP/IP bzw. OSI).

In seiner Rolle als Gateway muss ein LDAP Server also zwei Kommunikationsprotokollebeherrschen und sowohl als Client für den X.500 Server, als auch als Server für den LDAP Cli-ent auftreten. Der ursprüngliche Lösungsansatz hat zwar den Vorteil, dass LDAP Clients nunüber das weit verbreitete TCP/IP mit einem „leichtgewichtigerem“ Server kommunizierenkönnen - ein Unternehmen, welches ein derartiges Verzeichnis aufbaut, kann dennoch nicht aufden 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 dieNotwendigkeit entfällt, das OSI-Schichtenmodell zu unterstützen. Der LDAP Server mussdann selbst für den Zugriff auf das Verzeichnis sorgen und nicht mehr nur als Vermittler zwi-schen Client und X.500 Server agieren (Abbildung 16). Natürlich ist solch ein LDAP Serverweit aus komplizierter aufgebaut, da er nun die komplette Verzeichnisverwaltungsarbeit über-nehmen muss. Wenn auch die Verwaltung vergleichsweise einfach ausfällt, da LDAP nur einenTeil der DAP-Funktionen implementiert.

Derartige Server werden meist auch als Stand-Alone LDAP Server bezeichnet, da sie nichtmehr von X.500 Verzeichnisservern abhängig sind. Aus Sicht des Clients spielt die LDAPImplementierung keine Rolle. Jeder Server, der das LDAP Protokoll implementiert, ist einLDAP Verzeichnisserver - unabhängig davon, ob er das Verzeichnis nun real verwaltet, odernur als Gateway den Zugriff auf X.500 Server vermittelt.

Abbildung 16 Stand-Alone LDAP Server

3.8.2.2 Das Informationsmodell

Die Basisinformationseinheit im LDAP Verzeichnis nennt sich Verzeichniseintrag. Ein Eintragist aus verschiedenen Attributen aufgebaut, die z. T. schon vordefiniert sind. So existierenAttribute für die Definition häufig verwendeter Objektklassen wie Firmen, Personen, Gruppen,

LDAP Client LDAP Server

Verzeichnis

TCP/IP

LDAP

47


Lokationen, Organisationen, usw. Jedes Attribut hat einen Datentyp (z. B. Binärfeld, Zeichen-kette, Datum, usw.) und einen oder mehrere Werte. Die Beziehung zwischen einem Verzeich-niseintrag, seinen Attributen und ihren Werten zeigt Abbildung 17 [IBM98].

Abbildung 17 Das Informationsmodell: Einträge, Attribute und Werte

Jede Objektklasse definiert ihre eigenen Attribute, die darüber entscheiden, welche Informatio-nen ein Eintrag enthalten kann. Eine Objektklasse kann beispielsweise eine Telefonnummer,einen öffentlichen Schlüssel oder ein Bild enthalten, wobei jede Objektklasse durch eigeneAttribute erweitert werden kann. Attribute können grundsätzlich bis auf wenige Ausnahmenmehr als einen Wert enthalten. Bestimmte Attribute sind dabei als obligatorisch, andere nur alsoptional anzusehen (d. h. sie müssen nicht unbedingt in der zugehörigen Objektklasse verwen-det werden). Abbildung 18 zeigt dies an Hand eines Ausschnitts aus einem beispielhaften Ver-zeichnisbaum. Dort sieht man, das Attribut LocalityName L wird unterhalb von C=DE nur imrechten 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 beispielsweisekann zwei Werte - einen mit der Privat- und einen mit der Geschäftstelefonnummer - aufneh-men, 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, welcheals Distinguished Name (DN) bezeichnet werden (vgl. Abschnitt [3.3.1]). Ein Eintrag imLDAP-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-Abtei-lung der Firma Becker Consulting GmbH in Deutschland angestellt ist. Die Zeichenfol-gen cn, ou, o, und c bezeichnen vordefinierte Attribut-Typen. Tabelle [9] zeigt die amhäufigsten verwendeten Attribut-Typen und ihre Repräsentation als Zeichenfolge, wie sie in[RFC2307] definiert sind.

Eintrag

AttributAttribut

Attribut Attribut

Attribut

Wert

Wert

Wert

Typ

48


Abbildung 18 Ausschnitt eines fiktiven LDAP-Verzeichnisbaumes

Abbildung 18 verdeutlicht die hierarchische Struktur von LDAP-Verzeichnissen an Hand einer

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 Domainbeco.org

UserID uid Benutzername:z. B. für die Objektklasse posixAccount

Tabelle 9 Distinguished Name: Attribut-Typen und ihre Repräsentation als Zeichenfolge

Verzeichnis-WurzelVerzeichnis-Wurzel

c = DEc = DE

o = Becker Consulting GmbH

o = Becker Consulting GmbH

ou = ITou = IT

cn = Bob Offlinercn = Bob Offliner

o = Allgemeine DeutscheDirektbank AG

o = Allgemeine DeutscheDirektbank AG

c = USc = US

o = National Security Agency

o = National Security Agency

c = GBc = GB

ou = ITou = IT

L = FrankfurtL = Frankfurt

cn = Alice I. Wunderlandcn = Alice I. Wunderland

= bob= bob@localhost

uidmail

= alice= alice@localhost

uidmail

49


Anordnung der Einträge in Baumform. Die entsprechenden Knoten, welche zum Eintrag vonBob gehören, sind farblich markiert. Weitere Einträge mit den Attributen c=GB und c=US sindnur andeutungsweise dargestellt, um zu verdeutlichen, dass der gezeigte Ausschnitt Teil eineserheblich umfangreicheren Verzeichnisbaumes sein kann.

3.8.2.4 Das Sicherheitsmodell

In einem LDAP Verzeichnis abgelegte Einträge können sowohl allgemein zugänglichen Infor-mationen wie Zertifikate als auch vertrauliche Daten sein. Ein Hauptaugenmerk bei der Imple-mentierung eines Verzeichnisdienstes gilt daher dem Thema Sicherheit. Je nach Grad derVertraulichkeit können bei LDAPv3 verschiedene Authentifizierungsmechanismen eingesetztwerden.

Keine Authentifizierung

Dies ist die einfachste Methode. Sie wird benutzt, wenn das Verzeichnis nur aus allgemeinzugä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 enthal-tenen Benutzers sowie das dazugehörende Passwort benötigt. Der Server kann entsprechendkonfiguriert werden, sodass nur bestimmte Benutzer autorisiert sind, auf sensible Daten schrei-bend bzw. lesend zuzugreifen. Diese sicherheitsrelevanten Authentifizierungsinformationenwerden allerdings unverschlüsselt zum Server übertragen, sodass in den meisten Fällen keineausreichende Sicherheit gewährleistet werden kann. Angreifer, welche den Netzwerkverkehrzwischen Client und Server abhören, sind in der Lage die Authentifizierungsinformationenabzufangen, um sich anschließend selbst unbefugten Zugang zu verschaffen.

Simple Authentication and Security Layer (SASL)

SASL ist eine Methode, die verbindungsorientierte Protokolle um Authentifikationsmechanis-men erweitert. Ursprünglich entwickelt, um eine stärkere Authentifizierung für das IMAP-Pro-tokoll zu erreichen, ist es nun auch für die Version 3 von LDAP verfügbar.Nach der eigentlichen Authentifizierung durch SASL können die Kommunikationspartnerweitere Sicherheitsmechanismen wie Kerberos oder SSL zur Verschlüsselung der Übertragungaushandeln.

Der Client ruft dazu den SASL-Treiber des Servers auf und nennt ihm den gewünschtenSicherheitsmechanismus. Sofern der Server diesen unterstützt, verbindet sich der SASL-Trei-ber des Servers mit dem gewünschten Sicherheitssystem und leitet den Verbindungsaufbau ein.Abbildung 19 zeigt die Beziehungen zwischen Client, Server und dem Authentifizierungssy-stem.

50


Abbildung 19 Authentifizierung per SASL

3.8.2.5 LDAP URLs

Der LDAP Uniform Resource Locator (URL) erlaubt Zugriffe auf LDAP Verzeichnisse übernormale Webbrowser wie den Microsoft Internet Explorer oder den Netscape Navigator.LDAP-URLs beginnen mit ldap:// (oder ldaps://, wenn die Verbindung mit SSL ver-schlüsselt wird) und können aus komplexen Suchanfragen zusammengebaut sein, wie inAbbildung 20 zu sehen. Für dieses Beispiel wurde das LDAP Verzeichnis von www.open-ldap.com gewählt und nach der Person mit dem Benutzernamen mrv aus der Abteilungpeople 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 detail-lierte Beschreibung des Syntax wird auf [RFC2255] verwiesen.

Abbildung 20 LDAP-Zugriff über Webbrowser

Moderne Emailprogramme und Webrowser nutzen diese Zugriffsmethode, um Informationenwie Zertifikate oder CRLs direkt aus LDAP-Verzeichnissen zu empfangen. So kann derMechanismus zur Gültigkeitsprüfung von Zertifikaten durch diese Programme für den Nutzertransparent 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.

SASLAuthentifizierungssystem

SASLAuthentifizierungssystem

SASLAuthentisierungsanforderung

des Clients

SASLAuthentisierungsanforderung

des Clients

SASL Treiberauf dem ServerSASL Treiber

auf dem Server

Kerberos SSLAnonym

51


3.9 Rechtliche Aspekte des PKI Betriebes

Über Jahrtausende hinweg wurde Kryptographie hauptsächlich von Geheimdiensten und Mili-tärs eingesetzt. Viele Regierungen - darunter auch die US-Regierung - sehen auch heute nochden Einsatz von Verschlüsselung in einem engen Zusammenhang mit krimineller Energie. DieFolge ist, dass starke Kryptographie in vielen Staaten gesetzlich beschränkt und in einigen garganz 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 Ver-bot existieren verschiedene Varianten:

� Verbote und NutzungsbeschränkungenDer Einsatz von Verschlüsselungsverfahren kann komplett oder teilweise gesetz-lich verboten werden. So ist es möglich, die legale Nutzung von Verschlüsselungauf Finanzdaten einzuschränken (d. h. auf den Bankenverkehr), oder Verschlüsse-lungslizenzen ausschließlich an Firmen und nicht an Privatpersonen herauszuge-ben. Letztere Einschränkung wird derzeit in Frankreich praktiziert.

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

� SchlüsselwiederherstellungDie dritte Möglichkeit Kryptographie gesetzlich zu regulieren wurde schon inAbschnitt [3.6.1] näher besprochen: Daten dürfen zwar mit starker Kryptographieverschlüsselt werden, jedoch müssen die notwendigen Schlüssel zur Entschlüsse-lung bei einer staatlichen Stelle hinterlegt werden.

In Deutschland wird derzeit die Verwendung von Kryptographie - zumindest was die Ver-schlüsselung betrifft - nicht durch Gesetze geregelt. Ein Gesetz, das auf andere Weise mitKryptographie 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 einerrechtlichen Gleichstellung der elektronischen Signatur mit der eigenhändigen Unterschrift zuerfü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 allge-mein rechtsgültigen Lösung für digitale Signaturen stieß man hauptsächlich auf denWiderstand Großbritanniens. Der deutsche Ansatz wurde als zu teuer und die Anforderungenals zu hoch kritisiert [CSH99]. Man befürchtete sogar, dass Zertifizierungsdienste weit gehendin die Nische der Hochsicherheitsanwendungen verdrängt werden könnten [StKrem01]. Wei-terhin gab es mit diesem Ansatz vielerorts keinen Anreiz, Lösungen für eine gesetzeskonformeSignatur zu entwickeln, denn dem deutschen SigG fehlten jegliche Aussagen über evtl. Rechts-folgen.Großbritannien verfolgte daher einen anderen Rechtsansatz, der Sicherheit über Haftung defi-niert. Die neu geschaffene europäische Signaturrichtlinie, welche mit dem neuen SigG Anfang2001 umgesetzt wurde, stellt nun auch einen Kompromiss zwischen der deutschen und der bri-tischen Lösung dar: Haftung kombiniert mit hohen Sicherheitsstandards.

Für die Mehrheit der Rechtsgeschäfte in Deutschland hat der Gesetzgeber keine Schriftformvorgesehen, d. h. fast alle Verträge können auch mündlich geschlossen werden (die Beweis-kraft sei jetzt mal außen vor gelassen). Es gibt aber ein paar Ausnahmen: Bürgschaftserklärun-gen, Erteilung von Zeugnissen und Kündigungen von Arbeitsverträgen sind beispielsweiseFälle, in denen auch heute noch die eigene Unterschrift erforderlich ist. Mit der Anpassung derFormvorschriften im Privatrecht kann die schriftliche Form nun durch die elektronische Formersetzt 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 untergeordneteRolle spielen. Dort handelt es sich weit aus häufiger um Vereinbarungen, bei denen Verkäufervon 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 Zertifizierungsin-frastruktur gemäß SigG planen, werden im Folgenden näher betrachtet.

Beweislastumkehr

Die Beweisführung im Falle einer, bezüglich der Echtheit, strittigen digitalen Signatur wurdemit der Anpassung der Formvorschriften im Privatrecht zu Ungunsten der Signaturschlüssel-Inhaber geändert. Wenn eine digitale Unterschrift dem Signaturgesetz entspricht, gilt sie auchals echt; zumindest solange nichts grundsätzlich dagegen spricht, dass sie mit dem Willen desSignaturschlüssel-Inhabers abgegeben wurde. Bei realen Unterschriften muss bislang derEmpfä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 esanderen möglich war, die Signatur zu fälschen [UtRoos01].

Auswirkungen auf Zertifizierungsstellen

Mit der Anpassung des Signaturgesetzes an die europäische Signaturrichtlinie ergeben sichauch rechtlich interessante Auswirkungen auf Zertifizierungsdienste. Das betrifft insbesondereFirmen, die mit ihrer, derzeit noch firmenintern betriebenen, Zertifizierungsinfrastruktur an dieÖffentlichkeit gehen wollen, um auch der breiten Masse der Bevölkerung ihre Signaturen fürRechtsgeschäfte anzubieten:

53


� HaftungFür Zertifizierungsdienste gilt jetzt eine Haftungsregelung, die besagt, dass sie imFalle des eigenen Verschuldens für einen evtl. Schaden gegenüber Dritten aufkom-men müssen, falls diese einem scheinbar gültigen Zertifikat vertraut haben (SigG§11, Absatz 1). Um dies sicherzustellen, müssen Zertifizierungsdienste für eineDeckungsvorsorge in Höhe von mindestens 500.000 DM sorgen, aus dieser dannentsprechende Schäden Dritter ersetzt werden (SigG §12).

� BußgeldFür Verstöße gegen das Signaturgesetz gilt jetzt eine Bußgeldregelung. Ordnungs-widrigkeiten werden je nach Schwere mit einer Geldbuße von bis zu 100.000 DMgeahndet (SigG §21).

� GenehmigungspflichtDie bislang geltende Genehmigungspflicht für den Betrieb eines Zertifizierungs-dienstes wurde zu Gunsten einer freundlicheren Anzeigepflicht ersetzt (SigG §4,Absatz 1 und 3). Dadurch reduzieren sich die Kosten für den Aufbau einer Zertifi-zierungsinfrastruktur, was letztlich der Verbreitung digitaler Signaturen zu Gutekommen wird.

Auch wenn die Genehmigungspflicht jetzt entfallen ist, kann dennoch nicht auf Kontrollme-chanismen verzichtet werden, die überprüfen, ob bei einer Zertifizierungsstelle alle Sicher-heitsanforderungen bedacht wurden. Nur so kann gewährleistet werden, dass eineelektronische Unterschrift auch eine gewisse Beweiskraft hat. Aus diesem Grund sieht dasSigG eine freiwillige Prüfung (Akkreditierung) von Zertifizierungsstellen durch die zuständigeBehörde vor (SigG §15). Eine solche Akkreditierung umfasst neben einer Prüfung, ob dasSicherheitskonzept bestimmten Voraussetzungen des SigG genügt auch eine Prüfung, ob alleVorschriften des Gesetzes entsprechend umgesetzt wurden.

3.9.3 Exportbeschränkungen der USA

Zu den Zeiten des kalten Krieges wurde Kryptographie von der US-amerikanischen Regierungals Kriegsmaterial eingestuft und entsprechend starken Exportbestimmungen unterworfen. DaVerschlüsselung damals fast ausschließlich in Militär- und Geheimdienstkreisen verwendetwurde, stellte man militärisch verwendbare Verschlüsselungsgeräte und -Software auf eineStufe mit Waffen bzw. Munition und verbot deren Export. Erst in den 90er Jahren, als dasInternet immer populärer und Verschlüsselungsprodukte Massenware wurden, lockerte dieUS-Regierung die Exportrestriktionen. US-Firmen wie Netscape und Microsoft erhielten dieErlaubnis, Verschlüsselung mit bis zu 40 Bit Schlüssellänge für symmetrische Schlüssel zuexportieren. Mitte der 90er Jahre wurden dann die Exportbeschränkungen von einem US-ame-rikanischen Gericht als teilweise verfassungswidrig erklärt. Kurz darauf wurde schließlich derExport von Kryptographie mit 56 Bit Schlüssellänge erlaubt7.1997 wurde dann die Ausfuhr von symmetrischer Kryptographie mit 128 Bit Schlüssellängeerlaubt - allerdings nur an ausländische Finanzinstitute für die Verschlüsselung von Finanzda-ten (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 Nets-cape und Microsoft ihre Webbrowser seitdem in zwei unterschiedlichen Versionen an: eineExport Version und eine sog. Domestic Version. Diese ermöglichen in Abhängigkeit von demihnen präsentierten Server-Zertifikat unterschiedliche Verschlüsselungsstärken. Die Kommu-nikation mit Browsern der Domestic Version konnte somit 128 Bit verschlüsselt werden, wäh-rend Browser in der Export Version auf 40 oder 56 Bit Schlüssellänge beschränkt waren. Umdie zur Verschlüsselung von Finanzdaten erlaubten 128 Bit auch mit einer Export Version zuerzwingen, wird für Server von Finanzinstituten ein besonderes - meist teuer angebotenes -Zertifikat benötigt [TcTrust01], das bei Microsoft unter der Bezeichnung Server Gated Crypto-graphy (SGC) bekannt ist, aber auch als Global Server ID oder Step Up Certificate bezeichnetwird.Seitdem wurde starke Kryptographie auch nicht mehr als Kriegsmaterial, sondern als Dual-Use Produkt angesehen. Dual-Use Produkte können sowohl für den militärischen, alsauch fürden zivilen Gebrauch eingesetzt werden. Deren Export an „bedenkliche“ Staaten wird durchAusfuhrlisten des Wassenaar-Abkommens [Wassenaar00] vom Dezember 1998 geregelt.

Da Standardsoftware wie Webbrowser oder Textverarbeitungsprogramme häufig aus den USAkommen, zeigte die US-amerikanische Exportpolitik gerade auch in Deutschland lange JahreWirkung. Ein Großteil der heute noch in Deutschland eingesetzten Standardsoftware ist mitminderwertiger Verschlüsselungstechnologie ausgestattet.

Anfang des Jahres 2000 hat die US-amerikanische Regierung die Beschränkungen für denExport von Verschlüsselungs-Produkten zumindest in die Mitgliedsstaaten der europäischenUnion praktisch abgeschafft. Die Exportbeschränkungen entfallen nun bei Produkten mitschwacher Verschlüsselung (d. h. 56-Bit symmetrisch und 512-Bit asymmetrisch) sowie beiProdukten mit starker Verschlüsselung die für den Massenmarkt bestimmt sind. Ob eine Hard-oder Software nun als Produkt für den Massenmarkt gilt, entscheidet das US-amerikanischeAusfuhramt (Bureau of Export Administration, kurz BXA) [CSH00]. Zeitgleich bekam Kryp-tographie den dafür neu geschaffenen Status als Krypto-Handelsware (Retail encryption com-modities and software).

Neben der EU gilt die neue Regelung auch für die Schweiz, Norwegen, Ungarn, Tschechienund Polen sowie Japan, Australien und Neuseeland [UlBantle00]. Ausgenommen von diesenExporterleichterungen bleiben aber weiterhin Kuba, Iran, Irak, Libyen, Nordkorea, Sudan undSyrien sowie Serbien und Teile von Afghanistan.

3.10 Zusammenfassung

Dieses Kapitel berichtete über die Bestandteile einer Public Key Infrastruktur, der Notwendig-keit von Zertifikaten sowie den Basisdiensten von Trustcentern. Public Key Infrastrukturenbieten Dienste zur Gewährleistung von Authentizität, Integrität und Vertraulichkeit für dieÜbertragung sicherheitsrelevanter oder personenbezogener Daten über offene Netze. Grund-lage dieser Sicherheitsinfrastruktur stellen öffentliche Schlüssel und Zertifikate dar. Ein Zerti-fikat enthält den öffentlichen Schlüssel, der von einer CA beglaubigt sowie digital signiert istund ermöglicht so den öffentlichen Schlüssel auf zuverlässige Weise einer Person zuzuordnen.Trustcenter sind vergleichbar mit einer Ausweisbehörde und Zertifikate entsprechen einemelektronischen Identitätsnachweis. Zertifikate sind ähnlich wie Ausweise der realen Welt nurbefristet gültig und können vor Ablauf ihrer Gültigkeit widerrufen werden, wenn z. B. der Ver-dacht auf Kompromittierung des privaten Schlüssels besteht.

55


Ein Schlüsselwiederherstellungsmechanismus ermöglicht den Zugriff auf verschlüsselteDokumente auch dann, wenn der zur Entschlüsselung notwendige Schlüssel verloren gegan-gen ist.

Kryptographische Verfahren auf Public Key Basis wie SSL, S/MIME oder IPSec ermöglichenden Aufbau sicherer Verbindungen über den TCP/IP Protokoll Stack. SSL als Protokollschichtoberhalb von TCP bewirkt eine Ende-zu-Ende (end-to-end) Sicherheit zwischen Anwendungs-programmen, IPSec hingegen als Erweiterung des IP Protokolls eine Verbindungs-zu-Verbin-dungs (link-to-link) Sicherheit. Dokumentenbasierte Sicherheit auf Basis von Verschlüsselungund digitaler Signatur bietet S/MIME.

Zu Schluss liefert dieses Kapitel einen Einblick in die rechtlichen Aspekte einer Public KeyInfrastruktur. Es werden Auswirkungen des SigG auf den Betrieb einer PKI besprochen sowiedie z. T. noch existierenden Einschränkungen der US-amerikanischen Exportkontrolle fürstarke Kryptographie.

56

Kapitel 4

Bedarfsanalyse

Ziel dieser Diplomarbeit ist es, ein einheitliches Sicherheitskonzept für die Allgemeine Deut-sche Direktbank AG (DiBa) zu entwickeln, das mobilen Mitarbeitern eine geschützte Kommu-nikation, 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 undanschließ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 eineBestandsaufnahme notwendig. Dazu gehören neben der Definition einer Zielgruppe auch dieAnalyse des bisherigen Sicherheitskonzeptes sowie eine Ermittlung der Hard- und Softwareba-sis. 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 ING-Group ein international tätiges Unternehmen. Die ING-Group gehört zu den größten Finanzin-stituten Europas und ist mit einem Anteil von 49 Prozent Mitgesellschafter der DiBa1. Dazugehören weltweit verteilte Niederlassungen. Die DiBa selbst unterhält Niederlassungen anzwei Standorten in Frankfurt und Hannover. Regelmäßig stattfindende Meetings mit Mitarbei-tern und Partnern der ING ergeben die Notwendigkeit, Teile des Intranets sowie die interneKommunikation für mobile Mitarbeiter weltweit zu öffnen.

4.1.2 Zielgruppe

Die Zielgruppe für ein neues Sicherheitskonzept kann grob in drei Klassen (sog. Benutzergrup-

1. 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 AdministratorenDiese Gruppe von Administratoren benötigt Zugriff auf die DMZ (entmilitarisierteZone) mit Applikationen wie Telnet-Clients zur Administration von UNIX Servernoder FTP-Clients zum Up- und Download von Daten.In Abbildung 21 sind diese als externe Brokerage Administratoren gekennzeichnet.

� LAN AdministratorenDiese Gruppe von Administratoren benötigt Zugriff auf das LAN mit Applikatio-nen wie PC Anywhere zur Administration der Windows-PCs, oder FTP-Clientszum Up- und Download von Daten.Hinzu kommt die Notwendigkeit zur Verwaltung von Benutzern, die komplett überFormulare auf dem Intranet-Webserver erledigt werden kann. Daher benötigt dieseGruppe Vollzugriff auf Webseiten des Intranets und natürlich Zugriff auf dieinterne Email-Kommunikation.In der Abbildung sind diese als mobile Mitarbeiter gekennzeichnet.

� Exklusive BenutzerZu den exklusiven Benutzern zählen VIPs wie der DiBa Vorstand etc. Diese benö-tigen auf Geschäftsreisen im Ausland Zugriff auf die interne Email-Kommunika-tion 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üs-sen in einem neuen Sicherheitskonzept nicht berücksichtigt werden. Diese benötigen wederadministrativen Zugang vom Heimarbeitsplatz aus aufs interne Netzwerk, noch sind sie wäh-rend Geschäftsreisen auf ihre persönliche Emailkorrespondenz angewiesen.

Mobile Mitarbeiter können in drei Gruppen unterteilt werden, wie Abbildung 21 zeigt. Natio-nale Mitarbeiter sind mobil in Deutschland unterwegs und haben Zugriff auf einen Euro-ISDNTelefonzugang. Zu den Kontinentalen zählen jene Mitarbeiter, die in Teilen Europas unterwegssind, in denen der Telefonzugang über Euro-ISDN nicht möglich ist. Dazu gehören auch Mit-arbeiter, denen innerhalb Deutschlands nur analoge Zugänge zur Verfügung stehen. Die dritteGruppe bilden Mitarbeiter, welche rund um die Welt (international) mobil sein müssen. Diesebenötigen immer eine Zugangsmöglichkeit, welche möglichst unabhängig von irgendwelchenTelefonstandards 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 dortins Internet gelangen. Das LAN der DiBa wird durch eine zweistufige, redundant ausgelegteFirewall gegen unbefugte Zugriffe aus dem Internet gesichert.

Die DiBa Webseite (www.diba.de), welche u. a. Zugang zum Online-Brokerage bietet, wirdbei einem externen Dienstleister gehostet. Das eigentliche Brokerage-System befindet sich imUnternehmensnetzwerk der DiBa, zwischen der ersten und zweiten Stufe der Firewall in derDMZ. 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.

Abbildung 21 Unternehmensstruktur der Allgemeinen Deutschen Direktbank AG

Momentan basiert das Netzwerk auf einer MS Windows NT 4.0 Domäne. Serverseitig werdenProdukte wie MS Exchange 5.5 Server und MS Internet Information Server 4.0 eingesetzt, umMail- und Informationsdienste zu bedienen. Eine Migration auf eine MS Windows 2000Domäne ist für das Jahr 2002 geplant. Wobei die Serverprodukte dann auf den jeweils neuestenStand mitgezogen werden sollen, d. h. Exchange 2000 sowie IIS 5. Allerdings ist dieserUmstieg schon für einen Teil der Clientrechner, insbesondere die mobiler Mitarbeiter, vollzo-gen 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 unter-schiedlichen Lösungen. Sicheren Zugang zur persönlichen elektronischen Kommunikationermöglicht die Software Outlook Web Access (OWA) von Microsoft. Diese bietet Zugriff aufExchange Server über normale Webbrowser. Um administrative Aufgaben erledigen zu kön-nen, steht den LAN- und Brokerage-Administratoren zusätzlich ein Remote Access Server zurVerfügung, der diesen uneingeschränkten Zugang zum DiBa-Netzwerk ermöglicht.

Momentan werden für beide Lösungen weder die Dienste digitaler Signaturen zum elektroni-schen Unterschreiben von Dokumenten noch Zertifikate zur sicheren Authentifikation vonMitarbeitern genutzt.

Hoster für DiBaInternetauftritt

Online Brokerage

DiBa Standort Frankfurt DiBa Standort Hannover

ExternerBrokerage Administrator

Mobiler Mitarbeiter(national)

Mobiler Mitarbeiter(kontinental)

Mobiler Mitarbeiter(international)

Mail-Server

WWW-Server (Intranet)

ClientClient Client

Internet

LAN

Firew

alls

Standleitung

LAN

ClientClient

ClientClient Client

DMZ

59


Zugang zum LAN (Intranet und Fernadministration)

Der Zugang mobiler Mitarbeiter zum LAN der Allgemeinen Deutschen Direktbank AG wirdderzeit mithilfe eines Remote Access Servers (RAS) auf ISDN-Basis bereitgestellt. Dabei wirddie 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ückruf-nummer bildet somit eine rudimentäre Authentifikationsmöglichkeit, wobei davon ausgegan-gen wird, dass ausschließlich der verbindungswillige Mitarbeiter unter dieser Rückrufnummererreichbar ist.

Neben dem augenscheinlichen Vorteil, dass Informationen nicht über die Leitungen eines offe-nen Netzes transportiert werden und dadurch nur mit erheblichem Aufwand abgehört oder ver-fälscht werden können, hat dieses Verfahren allerdings erhebliche Nachteile für mobileMitarbeiter wie Administratoren gleichermaßen. Die Nachteile lassen sich auf zwei Eigen-schaften 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 aufGeschäftsreisen häufig im europäischen Ausland aufhalten. Ein ISDN Telefonan-schluss ist in vielen europäischen Ländern entweder gar nicht vorhanden oderinkompatibel zum deutschen Standard. International-mobile Mitarbeiter werdendamit sogar ganz ausgeschlossen.

� Die feste Rückrufnummer des Mitarbeiters muss bekannt sein.Diese Eigenschaft ist relativ unkomfortabel für mobile Mitarbeiter, da eine Rück-rufmöglichkeit entweder gar nicht existiert (bei der Einwahl mittels Laptop undHandy), oder erst sehr kurzfristig ermittelt werden kann (bei einem Aufenthalt imHotelzimmer oder Konferenzraum).

Diese Art des LAN-Zuganges ist quasi nur für Mitarbeiter mit festen Heimarbeitsplätzen inDeutschland sinnvoll einsetzbar, da diese üblicherweise über einen ISDN Zugang mit dauer-hafter 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 vonMicrosoft eingesetzt. Die neben der Emailfunktionalität auch Outlooks Eigenschaften alsWorkgroup-Client berücksichtigt. OWA bietet eine Alternative zum standardmäßig bei derDiBa eingesetzten, vollständigen Outlook-Client, in dem es u. a. die Funktionen des Postfachs,der Kontakteverwaltung, des Kalenders sowie der öffentlichen Ordner über dynamische Web-seiten bereitstellt.

OWA 5.5 basiert auf einer Exchange Server 5.5 und Internet Information Server (IIS) 4.0Lösung. Clients können über einen normalen Webbrowser mittels des HTTP Protokolls aufdynamisch generierte HTML Seiten auf den IIS zugreifen. Dieser wiederum kommuniziert mitdem Exchange Server über ASP. Als Authentifizierungs- und Verschlüsselungsmethode wirdmomentan eine Kombination aus SSL (mit dem Server-Zertifikat einer bekannten großen Zer-tifizierungsstelle) und der Standardauthentifizierung mittels Passwort eingesetzt.

60


Ziel war es, die von Outlook im LAN bereitgestellten Möglichkeiten des Emailpostfachs, derKontakte, 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 interna-tional-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 ein-geschränkte Bedienkomfort. Zum einen ist zum Verfassen einer einfachen Email eine durchge-hende Online-Verbindung notwendig, denn OWA stellt keinerlei Offline-Funktionen zurVerfügung. Zum anderen sind die Kontakte in der Version 5.5 nur sehr rudimentär implemen-tiert, sie dienen ausschließlich dazu, Emails an einen Kontakt zu senden - Telefon oder Adres-sinformationen werden nicht angezeigt. Dokumentenbasierte Verschlüsselung oder Signaturensind mit OWA nicht möglich.

4.2 Ermittlung des Bedarfs

Ein Sicherheitskonzept für den Intranet- und Mailzugriff mobiler Mitarbeiter sowie die Fern-administration sollte möglichst einheitlich für alle Gruppen von Mitarbeitern ausgelegt wer-den, sodass unabhängig vom jeweiligen Aufenthaltsort über eine gemeinsame StrategieZugang gewährleistet wird. Der bisherige Remote Access Zugang über ISDN-Einwahlserversoll aus diesem Grund von einem Zugang über das Internet abgelöst werden. Auf diesem Wegsoll die Notwendigkeit, mobile Mitarbeiter in standortabhängige Gruppen einzuteilen, entfal-len.

Die Anforderungen an ein solches Konzept umfassen eine einfache, zentrale Administrationder Sicherheitsinfrastruktur. Weiterhin sollte das eingesetzte Sicherheitskonzept in der Lagesein, mit künftigen Anforderungen an die Sicherheit zu wachsen, d. h. möglichst um neueKomponenten erweiterbar sein. Falls sich eingesetzte Verfahren nachträglich als unsichererweisen, sollte es möglich sein, diese reibungslos, d. h. ohne großen Aufwand gegen NeueSichere auszutauschen.

Hinzu kommt, dass bestimmte Teile des Konzeptes in kurzer Zeit realisierbar sein müssen. AufGrund eines begrenzten Budgets sollen möglichst bereits vorhandene Technologien angepasstoder wenn nötig ausschließlich Kostenfreie zusätzlich eingesetzt werden.

Die Realisierung des Konzeptes kann in mehreren Phasen geschehen. In einer ersten Phasesollte 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änkungenfür bestimmte Benutzergruppen erfolgen nach der erfolgreichen Authentifizierung an Handeiner schon existierenden, unternehmensweit zuständigen Benutzerdatenbank. Je nach Zuge-hörigkeit zu einer bestimmten Benutzergruppe stehen dem Mitarbeiter einer oder mehrere derfolgenden Intranet-Dienste auf einem Internet Information Server 4.0 von Microsoft zur Verfü-

61


gung:

4.2.2 Sichere Kommunikation mobiler Mitarbeiter

Die Sicherstellung der Authentizität von Benutzern sowie die Authentizität, Integrität undoptional auch die Vertraulichkeit aller elektronischen Nachrichten, welche an mobile Mitarbei-ter versendet werden, muss gewährleistet sein.

Authentizität und Integrität übertragener Nachrichten

Von mobilen Mitarbeitern erstellte und an mobile Mitarbeiter gesendete elektronische Doku-mente sollen gegen unbemerkte Veränderungen (� Integrität) geschützt werden.

Weiterhin muss sichergestellt sein, dass die mobil erstellten Dokumente auch wirklich vomangegebenen Mitarbeiter stammen (� Authentizität). D. h. Dokumente müssen eindeutigihrem Urheber zugeordnet werden können. In diesem Zusammenhang soll auch das elektroni-sche Unterzeichnen von Dokumenten (beispielsweise wichtigen Verträgen) ermöglicht wer-den.

Vertraulichkeit übertragener Nachrichten

Vertraulichkeit bei der Übertragung elektronischer Kommunikation über Leitungen unsichererNetze wie das Internet muss gewährleistet sein. D. h. außerhalb des DiBa-Netzwerkes darf nurder gewünschte Nachrichtenempfänger die übertragenen elektronischen Dokumente lesen kön-nen.

Intranet-Dienst LAN Admins

Exklusive Benutzer

Brokerage Admins

Zentrale Datenbank für Benutzermanagement �

Aktuelle Unternehmensnachrichten � � �

Benutzerhandbücher, Dokumentationen � �

Terminüberwachung � �

Workflow � �

Interne Informationen / vertrauliche Kondi-tionen �

Interne Anträge (Urlaubsanträge usw.) � �

Schwarzes Brett (Stellenausschreibungen etc.) � � �

Mitarbeiterforum (Chat) � �

Tabelle 10 Zuordnung von Intranet-Diensten und Benutzergruppen

62


4.2.3 Fernadministration des LANs

Eine sichere Administrationsmöglichkeit des LANs über Anwendungen wie Telnet- und FTP-Clients sowie PCAnywhere soll gewährleistet sein. Dazu sollte es möglich sein, die Zugriffs-berechtigungen der Mitarbeiter beliebig einzuschränken, abhängig von der Autorisierung derjeweiligen Benutzergruppe. D. h. es muss möglich sein, über Filter bestimmten Mitarbeiternbeispielsweise Zugriff auf die DMZ zu gewährleisten, anderen jedoch nur den Zugriff aufsLAN.Grundanforderung einer Administrationsmöglichkeit ist die Gewährleistung einer sichererenAuthentifizierung der Administratoren sowie die vertrauliche Übertragung der Verbindungsda-ten.

4.3 Konzept

An Hand der Anforderungen wurde ein Konzept entwickelt, bei dem Einzelaspekte in mehre-ren 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, dieAusführung des Konzeptes an einen externen Dienstleister zu übergeben, oder beispielsweiseeine eigene Public Key Infrastruktur selbst aufzubauen. Danach folgt die eigentliche Vorstel-lung der Teilkonzepte und Varianten.

4.3.1 Überblick über das Konzept

Die grundsätzlichen Anforderungen an ein neues Sicherheitskonzept bestehen darin, zwischendem LAN der DiBa und mobilen Mitarbeitern übermittelte elektronische Dokumente undDaten sicher zu schützen. Dabei soll insbesondere die Vertraulichkeit, Integrität und Authenti-zität der Dokumente und Daten bei der Übermittlung sichergestellt sein.

Um diese Sicherheitsanforderungen zu erfüllen, wird eine Public Key Infrastruktur (PKI) auf-gebaut, innerhalb derer ausgewählten Mitarbeitern und Servern elektronische Sicherheitsdien-ste zur Verfügung gestellt werden. Alle an dieser Infrastruktur teilnehmenden Mitarbeiterbekommen eigene digitale Schlüsselpaare ausgehändigt, die sie für bestimmte Sicherungs-zwecke verwenden müssen. Dazu wird eine Zertifizierungsstelle eingerichtet, welche Serverund Mitarbeiter zertifiziert (d. h. deren Schlüssel beglaubigt) und somit für das Vertrauen inderen Authentizität verantwortlich ist. Die zertifizierten digitalen Schlüssel werden dazu ver-wendet, digitale Signaturen auszustellen sowie Dokumente und den Datenverkehr zwischenClients und Servern zu verschlüsseln.

Die folgenden Abschnitte beschäftigen sich damit, welche Sicherheitsmechanismen mithilfekryptographischer 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 Infrastruk-tur 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 inBezug auf Vertraulichkeit und Verfügbarkeit handelt.

63


� VertraulichkeitDie beim Registrierungsprozess anfallenden vertraulichen Daten sollten meistnicht in die Hände Dritter gelangen. Dies ist aber notwendig, wenn ein externerDienstleister die Ausstellung von Zertifikaten übernimmt. Zudem sollte man imHinterkopf behalten, dass ein solcher Zertifikatsaussteller in der Lage ist, sichselbst (unbefugt) gültige Zertifikate auszustellen, um so widerrechtlich an geheimeInformationen zu gelangen.

� VerfügbarkeitEine sichere Archivierung von Widerrufslisten und Verschlüsselungsschlüsselnmuss dauerhaft gewährleistet sein. Es besteht die Gefahr, dass ein Dienstleister(aus Liquiditätsgründen, o. Ä.) seinen Dienst einstellt. In solch einem Fall wird esu. 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 wer-den. Einige ältere Studien wie [IMachef98]2 gehen für die Outsource-Lösung bei einer Basisvon 5000 Nutzern in einem Zeitraum von 5 Jahren von Kosten zwischen 21 und 26 US-Dollarpro Nutzer und Jahr aus. Wobei sich die Kosten pro Nutzer und Jahr bei einer Vervierfachungder Nutzerzahl mehr als halbieren. Man kann davon ausgehen, dass bei einer entsprechendkleineren Nutzerbasis, wie sie bei der DiBa angepeilt wird, die Kosten pro Nutzer und Jahr ent-sprechend (weitaus) höher ausfallen würden.

In Anbetracht dieser Tatsachen fiel die Entscheidung für einen Aufbau der Public Key Infra-struktur im Do-it-yourself-Verfahren relativ schnell.

4.3.3 Voraussetzungen

Beim Einsatz kryptographischer Standards wie SSL (bzw. TLS), S/MIME oder IPSec wirdvorausgesetzt, dass ausschließlich Versionen eingesetzt werden, die nicht durch die Gesetzge-bung künstlich in ihrer Sicherheit beschränkt wurden. Mindestvoraussetzung für den Einsatzsymmetrischer Verschlüsselung sind kryptographische Schlüssel mit einer Länge von minde-stens 128 Bit, wie sie auch vom Bundesamt für Sicherheit in der Informationstechnik (BSI)empfohlen werden. Server-Software wird derart konfiguriert, dass ein Verbindungsaufbau vonClient-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.509v3-Server-Zertifikaten gewährleistet, wobei die Daten ausschließlich verschlüsselt übertragenwerden. Siehe Abbildung 22.

2. Die Studie vergleicht die Kosten für digitale Zertifikate der PKI-Anbieter Verisign und Entrust in ver-schiedenen Szenarien, wie Benutzerauthentifikation mit Webbrowsern, sichere Email und Dateiverschlüs-selung über einen Zeitraum von fünf Jahren.

64


Zusätzlich werden auf Seite der Benutzer X.509v3-Client-Zertifikate eingesetzt, um einesichere Benutzerauthentifizierung zu ermöglichen. Nur authentifizierte und autorisierte Benut-zer bekommen Zugang zu einzelnen oder allen Angeboten des Intranets. Durch den Einsatz derX.509v3-Client-Zertifikate entfällt die Notwendigkeit einer Passworteingabe.

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 Ver-schlüsselung auf Routing-Ebene durch ein VPN (virtuelles privates Netzwerk) gewährleistetwerden, sofern nicht alle verwendeten Administrationswerkzeuge eine Ende-zu-Ende-Siche-rung ermöglichen.

Zur Realisierung des VPNs wird der verbreitete Standard IPSec unter dem BetriebssystemWindows 2000 verwendet. Dieses kann sowohl als VPN-Client als auch als VPN-Servergenutzt werden, um einen sicheren Tunnel zwischen zwei Rechnern über eine unsichere Lei-tung wie das Internet zu ermöglichen. Die zu verwendenden Softwareprodukte müssen somitkeine eigene kryptographische Sicherheit bieten und werden dennoch sicher (d. h. unter Wah-rung von Integrität und Vertraulichkeit) über diesen sicheren Tunnel vom mobilen Rechner insLAN (und zurück) transportiert.

Abbildung 23 Fernadministration über ein VPN

IIS 4

HTTPS (HTTP über SSL)

Webbrowser

Verschlüsselte Verbindung

Authentifikation durch Serverzertifikat

Authentifikation durch Clientzertifikate

Windows 2000 Server

Virtuelles privates Netzwerk (VPN)

Windows2000 Client




Beliebige Anwendungen wiePC Anywhere, VNC, Telnet oder FTP usw...

65


Zur sicheren Authentifizierung von Mitarbeitern als autorisierte VPN-Clients werdenX.509v3-Client-Zertifikate sowie auf Seite des VPN-Servers X.509v3-Server-Zertifikate ver-wendet.

Für die Verwendung von IPSec als in Windows integrierter VPN-Lösung ist der Einsatzzumindest eines Windows 2000 Servers3 im LAN und Windows 2000 als Betriebssystem aufallen 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älteinen Designfehler im verwendeten Authentifizierungsprotokoll MS-CHAP. Dieser vereinfachtes Angreifern mittels einer Brute-Force-Attacke das verwendete Verschlüsselungspasswort zuberechnen ([PeSiering01] und [JoEisinger01]) und somit die Verbindung abzuhören.

4.3.6 Sichere Kommunikation

Da der Bereich sichere Kommunikation die Nutzung von besonderen Exchange Dienstenumfasst, kann hier nicht auf eine Standardlösung zurückgegriffen werden, wie sie für die ande-ren Bereiche vorhanden ist. Deshalb wurden drei z. T. recht unterschiedliche Konzepte ent-wickelt, welche bei Bedarf gegeneinander ausgetauscht werden können. Jedes dieser Konzeptehat seine Vor- und Nachteile bezüglich Geschwindigkeit, Komfort und Funktionalität. Eswurde darauf geachtet, dass trotz dieser Unterschiede, sämtliche Konzepte die gestelltenAnforderungen bezüglich der Sicherheit erfüllen.

Konzept A

Die bisher verwendete Lösung mittels Outlook Web Access (OWA) wird weiterhin eingesetztund um die Möglichkeit der sicheren Benutzerauthentifizierung über X.509v3-Client-Zertifi-kate erweitert. Die Notwendigkeit einer Passworteingabe entfällt damit. Sobald die Migrationdes DiBa Netzwerkes zu einer Windows 2000 Domäne vollzogen ist, wird OWA entsprechendauf die in Exchange 2000 enthaltene Version upgedated.

Abbildung 24 Kommunikations-Konzept A

Konzept A hat den Vorteil einer schnellen und einfachen Umsetzung, da relativ wenige Ände-rungen vorgenommen werden müssen und dennoch eine höhere Sicherheit gewährleistet wirdals mit der bisherigen Lösung.

3. Dieser kann zu Beginn auch innerhalb einer NT 4-Domäne betrieben werden

Exchange 5.5 Server

IIS 4 für OWA

HTTPS (HTTP über SSL)

Webbrowser




66


Konzept B

Die bisher eingesetzte Lösung mittels Outlook Web Access (OWA) wird durch MS Outlook2000 abgelöst. Dabei wird von der Möglichkeit Gebrauch gemacht, POP3 und SMTP Verbin-dungen mithilfe von SSL abzusichern (POP3 über SSL und SMTP über SSL). Abruf und Ver-sand der Emails sind durch die eingesetzte Verschlüsselung gegen Abhören oder Veränderngeschützt.Auf Serverseite wird ein MS Exchange 5.5 Server auf Windows NT 4 Basis und als Client MSOutlook 2000 auf Windows 2000 Basis eingesetzt. Der zwischen Client und Server stattfin-dende Nachrichtenverkehr wird mittels einer SSL-Verbindung gegen Abhören geschützt. Beider zusätzlichen dokumentenbasierten Absicherung durch Verschlüsselung und Signatur wirdder S/MIME Standard genutzt. D. h. sowohl die dokumentenbasierende Sicherheit (sieheAbschnitt [4.3.6.1]) als auch die Client-Server Kommunikation verwenden Zertifikate nachdem offenen X.509v3 Standard.

Abbildung 25 Kommunikations-Konzept B

Der Nachteil dieser Lösung gegenüber Konzept A und C ist, dass die Nutzung weitererExchange Dienste wie zentrale, servergespeicherte Mailverwaltung, Kontakte, Kalender, usw.auf diese Weise nicht möglich ist. Diese Dienste müssen dann gegebenenfalls manuell offlinesynchronisiert werden.

Konzept C

Die bisher eingesetzte Lösung mittels Outlook Web Access wird durch MS Outlook 2000abgelöst. Auf Serverseite wird ein Windows 2000 Server und als Client Windows 2000 Profes-sional von Microsoft eingesetzt. Das in Abschnitt [4.2.3] beschriebene virtuelle private Netz-werk (VPN)4 wird dazu benutzt, den zwischen Client und Server stattfindendenNachrichtenverkehr mittels Verschlüsselung gegen Abhören und Verfälschen zu schützen.

Zusätzlich wird eine dokumentenbasierte Absicherung mittels Verschlüsselung und Signaturenwie 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-Funk-tionen) genutzt werden.

Exchange 5.5 Server

POP3 über SSLVerschlüsselte Verbindungen

SMTP über SSLOutlook 2000



67


kann Outlook in voller Funktionalität verwendet werden.

Abbildung 26 Kommunikations-Konzept C

Auswahl

Die Konzepte B und C haben einige gemeinsame Punkte, welche im Abschnitt dokumentenba-sierte Sicherheit beschreiben werden.

Es wird eine Kombination aus Konzept A und C favorisiert. In einer ersten Ausbaustufe wirdKonzept A für alle Benutzergruppen realisiert. Der Umstieg auf Konzept C erfolgt in einerspäteren Phase, gemeinsam mit der Umstellung des DiBa Netzwerkes von Windows NT 4 aufWindows 2000. Der Umstieg auf Konzept C wird nur für die Benutzer der Gruppen BrokerageAdministratoren sowie LAN Administratoren vorgenommen. Für Benutzer der Gruppe exklu-sive Benutzer ist der Umstieg nicht notwendig. Deren Zugang wird zu diesem Zeitpunkt ledig-lich 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 Signaturnach dem verbreiteten S/MIME Standard, wie in Abschnitt [2.4] beschrieben, versehen. Dieseverhindert unbemerkte Veränderungen am Dokument (� Integrität) und stellt sicher, dass dasDokument auch wirklich vom angegebenen Mitarbeiter stammt (� Authentizität). Auf dieserBasis können Dokumente eindeutig ihrem Urheber zugeordnet werden, was u. a. auch daselektronische Unterzeichnen von wichtigen Verträgen ermöglicht. Digitale Signaturen werdenmithilfe von X.509v3-Client-Zertifikaten von mobilen Mitarbeitern erzeugt und können vonallen 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.509v3-Client-Zertifikaten enthaltenen öffentlichen Schlüssel des Nachrichtenempfängers. Damit wirdgewährleistet, dass nur der gewünschte Nachrichtenempfänger diese lesen kann (� Vertrau-

Exchange 2000 Server

Virtuelles privates Netzwerk (VPN)

Outlook 2000




68


lichkeit). Verschlüsselung einzelner Nachrichten wird bei der DiBa nur in Ausnahmefällen ein-gesetzt, falls Nachrichten DiBa-intern vor Mitarbeitern geschützt werden müssen. Möglich istder Einsatz von dokumentenbasierter Verschlüsselung in Outlook zudem nur, wenn sowohlSender, 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 entspre-chendes Zertifikat verfügen.5

4.3.7 Anforderungen an die Hardware

Der bereits vorhandene Webserver sowie das neu einzurichtende VPN-Gateway müssen nunauch auf Anfragen außerhalb des DiBa-LANs antworten. Deshalb gilt es zu überlegen, beideServer in die DMZ aufzunehmen. Aufgrund des redundant ausgelegten Firewallkonzeptesmüssten die beiden Server entweder ebenso redundant gehalten oder sehr kompliziert an dieFirewalls angebunden werden. Mit Rücksicht auf den daraus resultierenden Installationsauf-wand, sowie die damit verbundenen Kosten und nicht zuletzt zur Vorbeugung eines Engpassesim Bereich der inneren Firewalls6 wurde darauf zunächst verzichtet. Der Serverumzug kannbei 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 aus-tauschbar 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 denAustausch der verwendeten Algorithmen:

Schlüssellängen

Die Sicherheit von kryptographischen Verfahren hängt u. a. von der gewählten Schlüssellängeab. Die in diesem Sicherheitskonzept eingesetzten Verfahren und Schlüssellängen sind sogewählt, dass sie nach dem derzeitigen Stand der Technik als sicher gelten. Sollten eingesetzteSchlüssellängen in Zukunft nicht mehr als ausreichend sicher gelten oder wird ein höhererSicherheitsstandard gewünscht, besteht die Möglichkeit, vom Einsatz höherer SchlüssellängenGebrauch zu machen.

Smartcards

Das Sicherheitskonzept, wie es für die erste Phase geplant ist, sieht keine Realisierung krypto-graphischer Operationen in Hardware vor. Sämtliche Funktionen wie Schlüsselgenerierung,Ver- und Entschlüsselung, digitale Signatur sowie Authentifikationsmechanismen werden aus-schließlich in Form von Anwendungssoftware auf Server- und Clientrechnern ausgeführt.Dazu notwendige Schlüsseldaten werden direkt auf der Festplatte des jeweiligen Rechnersgespeichert und sind entsprechend schwach gegen Angriffe geschützt.Die Sicherheit ließe sich durch den Einsatz von Smartcards erheblich erhöhen. Diese Kartenenthalten den privaten Schlüssel und führen Signatur- und Entschlüsselungs-Operationendirekt 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 inZukunft unsicher werden sollten und selbst die Erhöhung der Schlüssellängen keine ausrei-chende Sicherheit mehr gewährleisten kann. In diesem Fall lassen sich bei den gewählten Ver-fahren zur Absicherung der Sicherheitskomponenten (SSL, S/MIME sowie IPSec) dieeingesetzten Algorithmen zur Verschlüsselung problemlos durch andere ersetzen. Lösungenfür digitale Signaturen (in Form von sog. multiplen digitalen Signaturen [HartMase00]) undverschlüsselten Dokumenten (in Form einer sog. Mehrfachverschlüsselung) sind bei der PKI-Software 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 ent-worfen, das mobilen Mitarbeitern der DiBa eine geschützte Kommunikation, die sichereAbfrage von Intranetinhalten sowie die Fernadministration des Firmen-LANs über das Interneterlaubt. Zwischen dem LAN der DiBa und mobilen Mitarbeitern übermittelte elektronischeDaten sowie Dokumente werden je nach Anwendungsfall entweder mit SSL, S/MIME oderIPSec geschützt. Für das Schlüsselmanagement der dazu notwenigen kryptographischenSchlüssel und die Zertifizierung von Benutzern und Unternehmensrechnern wird eine eigenePublic 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 DeutscheDirektbank AG im Bezug auf ein Sicherheitskonzept für mobile Mitarbeiter besitzt. Aus die-sem Bedarf heraus wurde ein Konzept für den Aufbau und Einsatz einer eigenen Public KeyInfrastruktur entwickelt.

Im nächsten Schritt muss nun die einzusetzende Software auf ihre kryptographische Eignunghinsichtlich einer Verwendung in der Public Key Infrastruktur untersucht werden. Dazu wer-den die verschiedenen Programme für den server- sowie clientseitigen Einsatz und ihre krypto-graphischen Möglichkeiten betrachtet.

Aus wirtschaftlichen Gründen erhält dabei die weitere Verwendung bereits im Unternehmeneingesetzter 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 einerTestumgebung die derzeitige Softwareinfrastruktur der DiBa möglichst detailgetreu nachzu-bauen. Die ausgewählten Produkte wurden auf Basis des Sicherheitskonzeptes auf ihre Lei-stungsfähigkeit untersucht und sowohl auf Interoperabilität untereinander als auch aufHandhabbarkeit getestet. Im Folgenden wird beschrieben, welche Software dabei zum Einsatzgekommen ist.

Software für die Zertifizierungsstelle

Eine Software für Zertifizierungsstellen wie FlexiTrust 2.0 von FlexSecure wird bei der DiBaderzeit noch nicht eingesetzt. Die Möglichkeiten dieser Software werden in der Testumgebungunter dem Betriebssystem Windows 2000 Professional betrachtet. Siehe Abschnitt [5.2.3].

Um der weiten Verbreitung von Network Associates PGP Rechnung zu tragen, wird paralleldazu eine Installation dieser Software vorgenommen. Siehe Abschnitt [5.2.1]

71


Anfangs war geplant, ausschließlich zur Zertifizierung des Internet Information Servers 4.0einen 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 erstell-ten Schlüsselpaare zu zertifizieren. Rechzeitig vor Fertigstellung dieser Diplomarbeit wurdedieses Feature allerdings noch in FlexiTrust 2.0 eingebaut. Eine Installation des - bei der DiBaderzeit ohnehin nicht verwendeten - Certificate Servers ist für den Realbetrieb nun nicht mehrnötig.

Software für Server (WWW, Mail, LDAP, VPN-Gateway)

Für die Bereitstellung der Intranet-Dienste wird von der DiBa derzeit ein Internet InformationServer 4.0 von Microsoft unter dem Betriebssystem Windows NT 4.0 Server betrieben. DieMöglichkeiten in Bezug auf dessen weitere Verwendbarkeit werden in der Testumgebunguntersucht. Siehe Abschnitt [5.3.1].

Für die Bereitstellung von Diensten für den elektronischen Nachrichtenverkehr wird von derDiBa momentan ein Exchange Server 5.5 von Microsoft unter Windows NT 4.0 Server betrie-ben. Auch in die Testumgebung wird solch ein Server integriert. Da allerdings sämtliche fürden Betrieb einer PKI relevanten Funktionen in der dazugehörigen Clientsoftware enthaltensind, beschränkt sich die Untersuchung der Serversoftware auf die in Exchange Server 5.5integrierte Komponente Outlook Web Access 5.5. Siehe Abschnitt [5.3.2].

Beim Umfang der momentanen Nutzerbasis ist der Betrieb eines LDAP-Verzeichnisserversnicht unbedingt erforderlich, zumal die Installation von Benutzerzertifikaten in der DiBa meistvon Administratoren durchgeführt wird. Hinzu kommt, dass in der momentan vorliegendenVersion 2.0 von FlexiTrust die Unterstützung von LDAP-Servern nicht aktiviert ist und daherderzeit keine Verwendung findet. Für die zukünftige Erweiterung auf eine größere Nutzerbasisbietet 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 erprobtwurde. 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ück-gegriffen werden, das in seiner Eigenschaft als Verzeichnis ebenfalls per LDAP ansprechbarist.

Für den Betrieb des VPN-Gateways sollen in Zukunft die Möglichkeiten des Windows 2000Server-Betriebssystems von Microsoft genutzt werden. Allerdings sind von FlexiTrust ausge-stellte IPSec-Zertifikate derzeit noch nicht mit Windows 2000 kompatibel. Auf eine praktischeUntersuchung in der Testumgebung musste daher verzichtet werden. Eine eher theoretischeBetrachtung 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 NT4.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 Microsoftunter Windows 2000 Professional und Windows NT 4.0 eingesetzt (siehe Abschnitt [5.4.3]). Indiesem Zusammenhang ist es interessant, wie verschlüsselte oder signierte Dateien, beimEmpfä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]).

Abbildung 27 Aufbau der Testumgebung

Abbildung 27 liefert einen Überblick über die Konfiguration der Hard- und Software, wie siein der Testumgebung aufgebaut wurde. Die einzelnen Testrechner sind durchnummeriert von Abis F und mit dem jeweils installierten Betriebssystem gekennzeichnet. Die darauf installierteSoftware wurde in drei Gruppen eingeteilt: Server, PKI (enthält Software für Zertifizierungs-stellen) und Clients. Pfeile kennzeichnen Softwareprodukte, die einer Interoperabilitäts-Unter-suchung 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) aufTestrechner B bedeutet, dass der IE 5.5 unter Windows 2000 im Zusammenspiel mit dem IIS 4unter Windows NT 4 getestet wurde. Auf Pfeile, welche die Beziehungen der Gruppe PKIsymbolisieren, 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 Zertifizie-rungsstelle, Network Associates PGP, Microsoft Certificate Server und FlexSecure FlexiTrust

Windows NT 4 ServerWindows NT 4 ServerBB Windows NT 4 ServerWindows NT 4 ServerCC

Windows 2000 ServerWindows 2000 ServerFFS.u.S.E Linux 7.2 Prof.S.u.S.E Linux 7.2 Prof.DD

Windows 2000 WKSWindows 2000 WKS

Internet Information Server 4Internet Information Server 4 Exchange Server 5.5Exchange Server 5.5

OpenLDAP 2.0OpenLDAP 2.0 Active Directory (LDAP)Active Directory (LDAP)

Windows 2000 WKSWindows 2000 WKSEE

AA

MS Certification ServerMS Certification Server

Server

PK

I

Server

Netscape Communicator 7.8

LDAP Browser\Editor 2.8.2

Netscape Communicator 7.8

LDAP Browser\Editor 2.8.2

Server

Clien

ts

FlexiTRUST 2 (CA, RA, IS)FlexiTRUST 2 (CA, RA, IS)

Internet Explorer 5.5Netscape Navigator 7.8Netscape Messenger 7.8Outlook 2000LDAP Browser\Editor 2.8.2PGP 7.0.3

Internet Explorer 5.5Netscape Navigator 7.8Netscape Messenger 7.8Outlook 2000LDAP Browser\Editor 2.8.2PGP 7.0.3

PK

I C

lients

LDAP Browser\Editor 2.8.2LDAP Browser\Editor 2.8.2

Server

Clien

ts

Outlook 2000

Internet Explorer 5.5

Outlook 2000

Internet Explorer 5.5

Clien

ts

73


betrachtet.

5.2.1 PGP

Während der Entwurfsphase der Zertifizierungsstrategie wurde ich von einigen Mitarbeiternder DiBa darauf angesprochen, dass PGP der etablierte Standard für elektronische Nachrich-tenkommunikation sei. Darauf hin entstand die Überlegung, der weiten Verbreitung von PGPRechnung zu tragen und die bei einigen Mitarbeitern evtl. vorhandenen PGP-Benutzerschlüs-sel in die Zertifizierungs-Infrastruktur zu übernehmen. Im weiteren Verlauf dieses Abschnittesfolgen eine Abwägung der Vor- und Nachteile sowie der Grund weshalb PGP dann schließlichdoch 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 US-amerikanisches Antiterrorgesetz veröffentlicht wurde. Dieser Vorschlag sah vor, dass alleAnbieter von sicheren Kommunikationsdiensten eine Hintertür einbauen müssten, die der US-Regierung den unverschlüsselten Zugriff auf die übertragenen Informationen ermöglichensollte. Die US-Regierung hatte damals wohl hauptsächlich kriminelle Gruppierungen als Ziel-gruppe von Kryptographiesoftware in Verdacht. Stattdessen fand PGP anfangs aber bei einergänzlich anderen Benutzergruppe viel mehr Beachtung: Menschenrechtsaktivisten aus nicht-westlichen Staaten wie Osteuropa oder Mittelamerika [RaBend01], die sich, mithilfe der Ver-schlüsselung ihrer Kommunikation untereinander, vor der Verfolgung durch die Regierungschützen konnten.

Das erwähnte Antiterrorgesetz wurde zwar nie verabschiedet, dennoch geriet PGP oder bessergesagt sein Entwickler mit dem US-Gesetz in Konflikt: Für die amerikanische Exportkontroll-gesetzgebung galt starke Kryptographie als Kriegswaffe. Jemand der Kryptographiesoftwareaus 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 diezur Internet-Mail-Kommunikation eingesetzten Lösungen. Phil Zimmermann selbst beschreibtdie Situation so: „Wenn man sich die Internetbevölkerung als Kuchengrafik vorstellt, dannnutzt nur ein kleiner Teil davon Verschlüsselung. Die Menschen in diesem kleinen Tortenstücksind aber fast alle Nutzer von PGP.“ [RaBend01].

Mittlerweile entwickelt sich PGP zu einem Industriestandard für Email-Verschlüsselung. Dasauf PGPv5 basierende OpenPGP wurde als IETF-Standard vorgeschlagen [RFC2440].

Zertifikate

Der vielleicht grundlegendste Unterschied zwischen PGP und den nachfolgend besprochenenLösungen für Zertifizierungsstellen sind die zwei verschiedenen Standards für das Format derPublic Key Zertifikate (die nicht zueinander kompatibel sind). Während X.509v3 auf vertrau-enswürdigen dritten Stellen zur Bestätigung der Authentizität des Schlüssels eines Zertifikat-nehmers 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 Widerrufslistezu veröffentlichen und damit bekannt zu geben, welche Zertifikate ungültig sind, wird vonPGP nicht unterstützt. D. h. PGP kennt kein solches Konzept, entsprechend gibt es auch kei-nerlei standardisiertes Format oder eine verbreitete automatische Abfragemöglichkeit für PGP-Clients, auf entsprechende Listen zuzugreifen. Versuche eine Widerrufsliste in eine Zertifizie-rungshierarchie zu integrieren scheitern meist am Aufwand den Benutzer dabei erbringen müs-sen:

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 selbstbesitzt.

5. Zertifikat-Rückrufe berücksichtigen, d. h. von Hand die vorhandenen Zertifikateals ungültig markieren.

Zur Erinnerung: für Zertifikate, welche dem X.509v3-Standard entsprechen, erledigt ein Web-browser (oder Mailclient usw.) diesen Vorgang im Zusammenspiel mit Verzeichnissen quasivollautomatisch, da im X.509-Format von Anfang an Widerrufslisten vorgesehen waren. JedeSoftware, die X.509-Unterstützung bietet muss mit diesen Listen umgehen können. Da selbstdas Format der Widerrufslisten standardisiert ist, konnten sich auch nicht derart unterschiedli-che, individuelle Sperrlisten-Formate entwickeln, wie das bei PGP leider der Fall ist.

PGP bietet stattdessen zwei weniger mächtige Möglichkeiten herausgegebene Zertifikate zuwiderrufen. Da ist zum einen das Zertifikat-Widerrufszertifikat zu nennen. Neuere Versionenvon PGP „verstehen“ derartige Zertifikatwiderrufe und erlauben es dem Unterzeichner, eineSignatur unter einem PGP Schlüssel nachträglich für ungültig zu erklären. Was einer Sperrungdes Zertifikates gleich kommt. Die zweite Möglichkeit sind sog. Schlüssel-Widerrufszertifi-kate. Jeder Benutzer erzeugt dazu vor der Zertifizierung ein selbst signiertes Zertifikat zumWiderruf seines öffentlichen Schlüssels, das im Falle eines Missbrauches entsprechend vonihm selbst veröffentlicht werden muss. Wird PGP in einer hierarchischen Struktur im Zusam-menhang mit CAs benutzt, werden die Schlüssel-Widerrufszertifikate üblicherweise zusam-men 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 wer-den. Mit Widerrufszertifikaten besteht aber die Möglichkeit, Zertifikate im Falle des Widerrufsüber Keyserver oder über eigens eingerichtete Mailinglisten zu verteilen, um die Ungültigkeitdes 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 Diplomarbeiteine gravierende Sicherheitslücke von PGP offenbart, die diesen Gedanken schnell wieder ver-warf.

Das Sicherheitsproblem betrifft das von OpenPGP (also auch von PGP 7.0.3 und vom GNUPrivacy Guard) verwendete Format zur sicheren Speicherung privater Signaturschlüssel. Diesewerden verschlüsselt (mit AES, CAST5 oder IDEA) in einem sog. Keyring auf der Festplatteoder einem anderen Datenträger des Benutzers abgelegt und sind erst nach Eingabe einer Pas-sphrase für die jeweiligen PGP-Anwendungen lesbar. Allerdings werden einige der in derSchlüsseldatei enthaltenen Informationen nicht ausreichend auf Integrität geprüft, sodass dieMö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 einegeschickte Manipulation gelingt es Angreifern, aus Emails, die mit einem solchen verändertenSchlüssel signiert wurden, den privaten Schlüssel zu extrahieren.

Vlastimil Klima und Tomas Rosa beschreiben in [KlimaRosa01] den Angriff auf derart gespei-cherte 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 Informa-tion Server 4.0 (IIS) auf Windows NT 4 Basis. Die Trustcenter Fähigkeiten beschränken sichauf Erzeugung und Verteilung von Zertifikaten.

Der Certificate Server bearbeitet Zertifizierungsanforderungen vom IIS automatisiert über eineSchnittstelle, über die es den öffentlichen Schlüssel vom IIS empfängt und das erteilte Server-Zertifikat wieder zurücksendet. Über das Webinterface aus Abbildung 28 (links) können Zerti-fizierungsanfragen mithilfe eines herkömmlichen Formulars auf HTML-Basis an den Certifi-cate Server übermittelt werden. Dieser generiert auf Wunsch notwendige Schlüsselpaare selbstund 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 übernommenwerden, dabei stehen folgende kryptographische Algorithmen (Cryptographic Service Provi-der, CSP genannt) zur Verfügung:

� Microsoft Base Cryptographic ProviderEntspricht dem RSA Algorithmus mit einer Schlüssellänge von 512 Bit und

76


demonstriert die Einschränkungen früherer Export-Versionen.

� Microsoft Enhanced Cryptographic ProviderEntspricht dem RSA Algorithmus mit einer Schlüssellänge von 1024 Bit und bietetdamit eine nach heutigen Verhältnissen ausreichende Sicherheit.

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

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

� Schlumberger Cryptographic Service ProviderDient 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 beein-flusst werden kann. Neben den schon weiter oben genannten, obligatorischen Einstellungenzum verwendeten Zertifikatsformat und dem kryptographischen Algorithmus nebst Schlüssel-länge, erlaubt der Certificate Server weiteres Feintuning. Unter Algorithm versteckt sich derzur Zertifikatssignierung verwendete Hash-Algorithmus (SHA-1, MD2 oder MD5). Die Ein-stellung Allow Keys to be Exported ermöglicht es, das generierte Zertifikat zusammen mit demprivaten 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 zutransportieren. 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 vonanderweitig erstellten Schlüsseln, d. h. bei dieser Einstellung erzeugt der Certificate Serverkein 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 aus-geführt. Dies hat den Vorteil, dass generierte Zertifikate automatisch im lokalen InternetExplorer registriert werden, d. h. sofort zur Verfügung stehen und nicht erst vom Administratorumständlich von Hand installiert werden müssen. Alternativ kann die Zertifizierungsanfrageauch von einem zentralen Rechner aus erfolgen, dann ist es allerdings erforderlich, die Zertifi-kate nachträglich zu exportieren und manuell zum Zielrechner zu übertragen.

Folgende Testumgebung wurde eingerichtet, in welcher der Certificate Server 1.0 erfolgreicheingesetzt werden konnte: Windows NT 4 Server, Service Pack 6a, Windows NT 4 OptionPack, 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 dieZusammenarbeit 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 inder Programmiersprache Java implementiert und damit weitestgehend Plattform-unabhängigist1. Alle Sicherheitsmechanismen werden über die Java-Cryptographic-Architecture (JCA)bereitgestellt. FlexiTrust unterstützt Rückfallmechanismen. Sollte sich eine der heute verwen-deten Sicherheitstechniken oder Policies aufgrund technischer oder wissenschaftlicher Fort-schritte als unsicher erweisen, müssen alle Zertifikate und digitale Schlüssel der PKIausgetauscht und alle Signaturen erneuert werden. FlexiTrust ist bereits heute für das abgesi-cherte, transparente Umschalten der verwendeten kryptographischen Basisalgorithmenvorbereitet.

Zertifikate

Folgende für den geplanten Einsatz relevante Zertifikats- und Sperrlistenformate werdenunterstü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. Wel-che Sicherheitstechnik wirklich verwendet wird, hängt davon ab, welchen Crypto-Provider dieJCA gerade benutzt. Unterstützt wird beispielsweise der Microsoft Cryptographic-Service-Provider (CSP) von Windows NT 4 und Windows 2000. Die folgende Tabelle liefert einenÜberblick über die unterstützten kryptographischen Algorithmen des von FlexiTrust standard-mäßig verwendeten Providers (CDC2).

Überblick

FlexiTrust besteht hauptsächlich aus drei Komponenten (Abbildung 29), die sämtliche, mit derErzeugung und Verwaltung von digitalen Schlüsseln und Zertifikaten anfallenden, Aufgabenübernehmen:

� FlexiTrust-RA (die Registrierungseinheit)Regelt die Abwicklung von Antragsprozessen wie die Bearbeitung von Zertifikats-oder 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 Zertifi-katen und Widerrufslisten sowie regelmäßige Aufgaben wie beispielsweise dieRezertifizierung.

Alle Komponenten von FlexiTrust können wahlweise getrennt oder zusammen betrieben wer-

2. CDC ist ein Java-Crypto-Provider entwickelt an der TU-Darmstadt. Die in der Tabelle mit ECxxx bezeichneten Algorithmen basieren auf Elyptic Curve Cryptography.

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

79


den. Es ist beispielsweise möglich, die FlexiTrust-CA auf einem eigens dafür vorgesehenenund besonders gesicherten (abgeschotteten) Rechner gemäß SigG-Anforderung offline sowiealle Module zusammen auf einem einzigen (vernetzten) Rechner zu betreiben.

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 stelltalle Funktionen einer CA bereit:

� SchlüsselerzeugungErzeugung asymmetrischer Schlüsselpaare mit kryptographischen Verfahren wieRSA, DSA oder elliptischen Kurven.

� ZertifizierungZertifizierung selbst erzeugter Schlüsselpaare sowie Zertifizierung von Fremd-schlüsseln.

� RevokationWiderruf von ausgestellten Zertifikaten und Erstellung notwendiger Widerrufsli-sten.

� Schlüsselarchivierung, SchlüsselwiederherstellungArchivierung und Wiederherstellung von privaten Schlüsseln sowie Zertifikaten.

Registration Authority (RA)(Zertifikats- und Revokationsanträge)

Certification Authority (CA)Digitale Schlüssel

ZertifikateGeheimnisträger (PSE)

Revokationen

verw

alte

n

pfle

gen

Infrastructure Services (IS)(regelmäßige Aufgaben)

zust

elle

nbe

antr

agen

80


Abbildung 30 Zertifikatsantragsformular der FlexiTrust-RA

5.2.3.2 FlexiTrust-RA

Die Registrierungseinheit ist das Eingangsportal von FlexiTrust: eine skalierbare Software, diealle Funktionen einer RA bereitstellt:

� Kommunikation mit den BenutzernRegistrierung von Benutzern inkl. einer Authentitätsprüfung. Sammeln und ver-walteten von Zertifizierungs- und Widerrufsanträgen, Prüfung von Antragsdatengemäß frei definierbaren Sicherheitsrichtlinien (Policies).

� Kommunikation mit der CAWeitergabe genehmigter Anträge in Form einer im PKCS#7-Format signiertenZertifizierungsanforderung 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 underledigt regelmäßig wiederkehrende Verwaltungsaufgaben:

� Kommunikation mit den BenutzernHerausgabe von Schlüsselpaaren, Zertifikaten sowie Chipkarten an die Benutzer.

� BereitstellungÖffentliche Bereitstellung von Zertifikaten und Widerrufslisten über LDAP-Ver-zeichnisdienste.

� Key-Backup und -RecoveryFlexiTrust-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 sowieIS) gemeinsam auf einem einzigen, vernetzten, nicht gesondert geschützten Rechner unterWindows 2000. Entgegen den Forderungen der Policy in Abschnitt [A.3.1] wird im Rahmendieses Tests kein dedizierter Rechner für die einzelnen Module verwendet. Ein verteiltes Star-ten der Module ist aber möglich und wird im Realbetrieb auch angestrebt. Der Datenaustauschzwischen den einzelnen Modulen erfolgt in der Testumgebung über Transferdateien auf derFestplatte des gemeinsamen Rechners.

82


5.3 Server Software

In diesem Abschnitt wird Software für Informations- Kommunikations- und Sicherheitsdiensteauf Server-Basis besprochen. Dazu gehören ein Microsoft Internet Information Server, welcherZugang zu Intranetdiensten wie Benutzerverwaltung, Unternehmensnachrichten und Doku-mentationen bietet; ein Microsoft Exchange Server als Kommunikationsplattform für Email-,Termin- und Kontaktverwaltung; ein OpenLDAP-Server zur Bereitstellung von Zertifikats-und Widerrufsinformationen; und nicht zuletzt ein MS Windows 2000 Server, der die Dienstefü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ürWindows 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.0ist die Installation des CA-Zertifikates jener CA, welche den SSL-Server-Schlüssel für den IISsigniert 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 demServer installiert werden, damit der IIS diese als vertrauenswürdige Instanz für Client-Zertifi-kate 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 denServer integrierten Schlüssel-Managers selbst. Wobei in der getesteten Version ausschließlich512, 768 oder 1024 Bit Schlüssellängen möglich sind. Zur Zertifizierung der selbst erstelltenSchlüsselpaare wird eine Base64-kodierte PKCS#10 Zertifikatsanforderungsdatei (*.req) überden Schlüssel-Manager erzeugt, die anschließend von einer separaten CA zertifiziert werdenmuss. 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 korrekteUmgang mit der erstellten Zertifikatsanforderungsdatei. Die von der CA erzeugten Zertifikatekönnen anschließend als einzelne Zertifikatsdateien (Base64-kodiert, *.crt) oder gemeinsammit 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änenbenutzer-konten erlaubt es, Benutzer an Hand des bei der Authentifizierung vorgelegten Zertifikatesgezielt zu erkennen und ihnen automatisch Rechte auf dem Server, basierend auf ihren Win-dows NT Benutzerkonten, zuzuweisen. Diese Bindung stellt somit eine Beziehung zwischendem Inhalt des Client-Zertifikates eines Benutzers und dem entsprechenden Windows NTBenutzerkonto her.

Folgende Möglichkeiten zur Bindung stehen dabei zur Verfügung:

83


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

� n-zu-1Ähnlich wie bei der 1-zu-1 Bindung werden bei der n-zu-1 Bindung mehrere Cli-ent-Zertifikate einem einzelnen Windows NT Benutzerkonto oder einer -Gruppezugeordnet.

� WildcardsBei der Bindung über Wildcards werden keine individuellen Client-Zertifikate inden Server geladen, stattdessen können Kriterien definiert werden an Hand derervorgelegte Zertifikate während des Webzugriffes bestimmten Windows NT Benut-zerkonten zugeordnet werden. Ebenso ist es mit dieser Bindung möglich, Zertifi-kate nach bestimmten Kriterien komplett abzulehnen. Mögliche Kriterien für eineWildcard-Bindung sind beispielsweise die im Zertifikat untergebrachten Informa-tionen über den Zertifikatsherausgeber oder andere auf dem DN basierende Krite-rien.

Widerruf von Zertifikaten

Ohne weitere manuelle Einstellungen prüft der IIS 4 nicht, ob vom Client übergebene Zertifi-kate evtl. zwischenzeitlich von der herausgebenden CA widerrufen wurden. Dieser Prüfvor-gang ist nach der Installation des Servers standardmäßig abgeschaltet und muss nachträglich inder Registry mit folgendem Schlüssel aktiviert werden:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Inetinfo\Param-eters\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 kor-rekt in das Zertifikat eingebrachte Erweiterung vom Typ CRL Distribution Point, welche aufdie CRL auf einem HTTP- oder LDAP-Server verweist. Allerdings war es im Verlauf dieserArbeit nicht möglich, den IIS 4 dazu zu bewegen, gültige Zertifikate mit CRL DistributionPoint-Erweiterung anzunehmen. Unabhängig davon, ob diese nun widerrufen waren odernicht, wies der IIS 4 solche Zertifikate bei aktiviertem CheckCertRevocation generell alsungü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 Fallentspricht, dass überhaupt keine Benutzerzertifikate vorhanden sind. Erst nach Abschalten vonCheckCertRevocation 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 essich, CheckCertRevocation generell auf einen Wert von 0 zu setzen. Microsoft selbst bezeich-net 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 momentandie Software Outlook Web Access (OWA) 5.5 von Microsoft eingesetzt. OWA ist eine in denExchange 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 Informa-tion Server (IIS) 4.0 verknüpft. Clients können über einen normalen Webbrowser, wie denInternet Explorer, mittels des HTTP Protokolls auf dynamisch generierte HTML Seiten aufden IIS zugreifen. Dieser wiederum kommuniziert mit dem Exchange Server über ASP. Unterdiesem 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), weistgroße Ähnlichkeit mit der Vollversion von Outlook auf. Tatsächlich wird neben der Mailfunk-tionalität auch ein Teil von Outlooks Workgroup-Funktionen angeboten. Allerdings fehlensämtliche Möglichkeiten zur dokumentenbasierten Sicherheit wie Verschlüsselung oder digi-tale Signatur. Zur Absicherung der Kommunikation zwischen Clients mit Webbrowsern unddem OWA muss daher auf die in Abschnitt [5.3.1] besprochenen Möglichkeiten des IISzurückgegriffen werden. Verbindungen lassen sich so per SSL verschlüsseln und der Zugriffmittels 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ürUNIX-Plattformen (wie beispielsweise Linux), der das Lightweight Directory Access Protocolin 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 bereitge-stellt.

Die in Abschnitt [3.8.2.4] beschriebenen Sicherheitsmodelle keine Authentifizierung, einfacheAuthentifizierung und SASL werden unterstützt. Um über SASL Verbindungen mittels TLSoder SSL abzusichern, muss allerdings zusätzlich zu OpenLDAP die Software OpenSSLinstalliert werden. Eine Zugriffskontrolle erlaubt es allen Benutzern Lese- sowie Schreibrechtezuzuweisen oder den Zugriff auf authentifizierte Benutzer sowie Benutzer, die selbst im Ver-zeichnis eingetragen sind, zu beschränken. Dies ermöglicht es beispielsweise, das Recht aufschreibende Zugriffe in wählbare Bereiche des Verzeichnisses ausschließlich LDAP-Admini-stratoren zu gewähren, während anonyme Benutzer lediglich Leserechte erhalten.

In der Testumgebung wurde OpenLDAP entsprechend seiner Linux-Verfügbarkeit auf einemRechner 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ürdie Aufnahme von Benutzerzertifikaten und Sperrlisten lief erfolgreich, wurde allerdings man-gels Unterstützung seitens FlexiTrust 2.0 ausschließlich mit LDAP-Clientprogrammen wiedem unten beschriebenen LDAP Browser\Editor, dem Netscape Communicator und weiterenvon 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-Tunne-ling-Protokoll (L2TP) den IPSec Standard zum sicheren Verbinden von Systemen (i. d. R. Cli-ents auf Windows 2000 Basis) über VPNs. Als Authentifizierungsmechanismus können dreiunterschiedliche Methoden eingesetzt werden. Neben Kerberos V5 oder vordefinierten,gemeinsamen, geheimen Schlüsseln sind auch X.509 Zertifikate möglich. Kerberos alsAuthentifizierungsmechanismus verwendet man am besten ausschließlich innerhalb geschlos-sener Windows-2000-Infrastrukturen, da dann keine weitere Konfiguration des Protokolls aufClientseite mehr erfolgen muss (zentralisierte Administration). Im heterogenen Systemumfeldoder wenn Zugriffe von außerhalb einer Windows-2000-Domäne (beispielsweise über dasInternet) erfolgen sollen, verwendet man besser Zertifikate nach X.509 zur Authentifikation.

Zum Aufbau einer IPSec Verbindung verwendet Windows 2000 (in der Server- oder Professio-nal-Version) den Internet Key Exchange (kurz IKE, als Implementierung von ISAKMP/Oak-ley, siehe Abschnitt [3.7.3.2]).

Über IPSec-Regeln lässt sich das Kommunikationsverhalten auf Benutzer- oder Rechner- (Cli-ent-) Basis, für definierte Anwendungssituationen festlegen. Die Konfiguration dieser Regelnerfolgt bei Windows 2000 über Richtlinien, die im Active Directory abgelegt werden. Für

5. bis 1996: University of Michigan6. Dazu zählen: Web500gw (ein Gateway das Webbrowsern den direkten Zugriff auf das LDAP-Verzeich-nis 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 inder lokalen Registry des Clients gespeichert. Über derartige Richtlinien lassen sich Regeln fürunterschiedliche TCP-Ports oder Tunnels zu Servern definieren und je nach Anwendungsfallmiteinander kombinieren. Als Anwendungsfälle kommen die in Abschnitt [3.7.3.3] besproche-nen Verbindungstypen infrage: Peer-to-Peer, Client/Server, Gateway-to-Gateway, Client-to-Gateway.Beim Einsatz von X.509-Zertifikaten zur Authentifizierung lassen sich auf Clientseite nebenRechnern auf Basis von Windows 2000 beispielsweise auch Linux-Clients verwenden. BeiClients, die nicht auf Windows 2000 basieren, muss allerdings auf die zentralisierte Verwal-tung der Sicherheitsrichtlinien mithilfe des Active Directories verzichtet werden. DerartigeClients 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 weiterge-leitet, blockiert oder mithilfe eines wählbaren kryptographischen Verfahrens ver-schlüsselt werden. Konfigurierbar ist in diesem Zusammenhang, welche IP-Adressen (oder IP-Subnetze) diese Filter umfassen und auf welche TCP-Protokolleoder Portnummern die Verbindung beschränkt sein soll.

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

� TunnelFür jede einzelne Verbindung kann eingestellt werden, ob diese im Tunnel- oderTransportmodus erfolgen soll.

� VerbindungstypDer Verbindungstyp ermöglicht unterschiedliche Konfigurationen für LAN- oderDFÜ-Verbindungen.

Für Rechner innerhalb einer Windows 2000 Domäne sind bereits drei (kerberosbasierende)Richtlinien vorkonfiguriert, die allerdings standardmäßig nicht aktiv sind und entsprechendden 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 aufzu-bauen. Falls dieser IPSec nicht unterstützt, werden allerdings auch ungesicherteVerbindungen 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 vertrau-enswürdigen Clients wird abgewiesen. Jeder Client, der eine Verbindung zu solcheinem 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 DiBaumfasst neben der Authentizität von Mitarbeitern, die Vertraulichkeit der übertragenen Infor-mationen sowie notwendige Zugriffsbeschränkungen für bestimmte Benutzergruppen nacheiner erfolgreichen Authentifizierung. Es bietet sich an, das hierfür notwendige Regelwerk aufBasis der vordefinierten „Sicherer Server“ Regel zu entwerfen. Die beiden erstgenanntenRegeln sind hierfür offensichtlich ungeeignet, da sie u. U. auch ungesicherte Verbindungenvon nicht authentifizierten Personen zulassen würden.

5.4 Client Software

Die im vorherigen Abschnitt genannte Software für Serverdienste verlangt auf Benutzerseitenach entsprechender Client Software. Neben den bekannten Webbrowsern von Microsoft(Internet Explorer) und Netscape (Communicator) werden Clientprogramme für den Kommu-nikationsbereich (Microsoft Outlook) sowie LDAP vorgestellt. Eine Beschreibung des Win-dows 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 vonWebseiten bei der Übertragung mittels SSLv2, SSLv3 sowie TLS. Die Authentifikation gegen-über Servern zu Beginn einer SSL-Kommunikation erfolgt auf Wunsch mit X.509v3-Client-Zertifikaten. Das im IE-Paket enthaltene Emailprogramm Outlook Express wird an dieserStelle nicht näher betrachtet, da für die Nachrichtenkommunikation bei der DiBa das ebenfallsvon Microsoft stammende, separat erhältliche Programm Outlook 2000 vorgezogen wird.

Die folgenden Angaben beziehen sich hauptsächlich auf die Version 5.x unter den Betriebssy-stemen Windows NT 4.0 SP6a sowie Windows 2000 SP2. Zu berücksichtigen ist, dass sich dasVerhalten 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 symmetrischsowie 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 kanneine SSL-Verbindung nur mit 40/56 Bit Verschlüsselung abgesichert werden. Leider ist dasVerhalten des IE in einzelnen Fällen abhängig davon, ob er unter Windows NT oder Windows2000 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 Micro-soft Management Console (kurz: MMC, siehe Abbildung 34) in Windows 2000. Beide Mög-lichkeiten unterscheiden zwischen eigenen Benutzerzertifikaten (eigene Zertifikate),Zertifikaten anderer Benutzer (andere Personen), CA-Zertifikaten (Zwischenzertifizierungs-stellen) 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öglichkei-ten, als ein Zugriff über den IE. Neben personengebundenen Zertifikaten (Zertifikate - Aktuel-ler Benutzer), die nur verfügbar sind, wenn der entsprechende Benutzer lokal am Rechnerangemeldet ist, kennt die MMC auch rechnergebundene Zertifikate (Zertifikate (Lokaler Com-puter)), wie sie beispielsweise für SSL- oder IPSec-Server benötigt werden. Diese Unterschei-dung bietet folgende Möglichkeiten. Zum einen kann jeder Benutzer selbst entscheiden,welchen CAs er Vertrauen schenkt und welchen nicht. Zum anderen muss ein Server auchZugriff auf seine Zertifikatseinstellungen haben, wenn kein Benutzer (wie beispielsweise derAdministrator) angemeldet ist.

7. Erreichbar über den Menüpunkt: Extras / Internetoptionen... / Inhalt / Zertifikate.

89


Benutzerzertifikate werden im Format PKCS#12 zusammen mit dem privaten Schlüsselimportiert und können auf diesem Wege auch wieder für eine anderweitige Verwendung expor-tiert werden. Zusammen mit dem eigentlichen Benutzerzertifikat besteht die Möglichkeit überPKCS#12-Dateien auch gleich Zertifikate der ausstellenden CAs zu importieren. CA-Zertifi-kate sowie Zertifikate anderer Benutzer können alternativ auch einzeln in den IE eingebrachtwerden, in dem sie entweder über den Assistenten der Zertifikatsverwaltung manuell geladenwerden, oder ein Webserver das entsprechende Zertifikat im binär codierten DER-Format mit-hilfe des MIME-Types application/x-509-ca-cert zum Download anbietet.

Der Assistent für die Zertifikatsverwaltung ermöglicht über ein Kontextmenü im WindowsExplorer (Zertifikat installieren) den Import von Zertifikaten in den Formaten PKCS#12(*.p12), PKCS#7 (*.p7b) sowie DER-codiert (*.cer; Base-64 oder Binary). Beim Importbesteht die Möglichkeit, die Zertifikate als personen- oder rechnergebunden einzuordnen. Überdas erwähnte MMC-Snap-In lassen sich die Zertifikate nachträglich noch in die jeweiligeandere Kategorie einordnen.

Sowohl die Zertifikatsverwaltung vom IE als auch das Snap-In der MMC erlauben es, instal-lierte Zertifikate anzuzeigen (Abbildung 35), zu exportieren sowie deren Verwendungszwecknachträglich zu modifizieren. CA-Zertifikate beispielsweise können für die Zertifizierung vonS/MIME oder SSL als vertrauenswürdig definiert oder die Beschränkungen von Benutzerzerti-fikaten 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üsselerzeugungmit anschließender Online-Zertifizierung. In diesem Fall erzeugt der Browser das asymmetri-sche Schlüsselpaar selbst.

90


Widerrufslisten

Widerrufslisten (CRLs) können, ähnlich wie Zertifikate, über ein Kontextmenü im WindowsExplorer (Zertifikatsperrliste installieren) oder über eine im Zertifikat angegebene URL8

bezogen werden. Eine Zertifikatsprüfung erfolgt erst, wenn im Menü Extras / Internetoptio-nen... / Erweitert die Felder Auf zurückgezogene Serverzertifikate überprüfen, bzw. Zertifikatevon Herausgebern prüfen angewählt sind.

Allerdings konnte der IE in den Versionen 5.0, 5.5 und 6.0 (mit den jeweils aktuellsten Servi-cepacks und Patches) nicht dazu bewegt werden unter Windows NT oder Windows 2000widerrufene Zertifikate als ungültig zu erkennen, wenn entsprechende CRLs über das Kontext-menü des Windows Explorer eingebracht wurden. Das Format der CRLs (X.509v1) war beidiesen Tests das Gleiche, wie das in den Abschnitten [5.4.2] für den Netscape Communicatorund [5.4.3] für Outlook 2000 verwendete. Hinzu kommt, dass Outlook 2000 wie der IE dieZertifikatsverwaltung von Windows verwendet und somit auf dieselbe installierte CRL zugre-ift. Dennoch erkannte der IE zurückgerufene Zertifikate, im Gegensatz zum Netscape Commu-nicator und Outlook 2000, weiterhin als gültig.

An dieser Stelle unterscheidet sich das Verhalten des IE unter Windows 2000 von dem unterWindows NT. Während unter Windows 2000 keine Auswirkungen beim (de-) aktivieren derFelder Auf zurückgezogene Serverzertifikate überprüfen, bzw. Zertifikate von Herausgebernprüfen feststellbar sind und alle Zertifikate weiterhin gültig bleiben, sieht der IE unter Win-dows 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 wer-den als unüberprüfbar moniert und damit vom IE als ungültig bezeichnet, sobald diese Felderunter Windows NT aktiviert sind.

5.4.2 Netscape Communicator 4.7x

Der im Netscape Communicator enthaltene Webbrowser Navigator unterstützt in der frei ver-fügbaren Version 4.77 die Verschlüsselung von Webseiten bei der Übertragung mittels SSLv2und SSLv3, wobei als symmetrische Verschlüsselungsalgorithmen beispielsweise RC4 mit 128Bit oder Triple-DES mit 168 Bit Schlüssellänge verwendet werden können. Die Authentifika-tion gegenüber Servern zu Beginn einer SSL-Kommunikation erfolgt auf Wunsch mitX.509v3-Client-Zertifikaten. Der im Netscape Communicator enthaltene Emailclient Messen-ger 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 unter-schiedliche Betriebssystemplattformen - nicht die Zertifikatsverwaltung von Windows. Des-halb sind schon in Windows importierte Zertifikate und CRLs nicht automatisch in Netscapeverfügbar.Netscape bietet daher eine eigene Zertifikatsverwaltung (siehe Abbildung 36), die über dasMenü Communicator / Tools / Security Info oder über das Schlosssymbol in der Symbolleisteerreichbar 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üs-sel importiert und können auf diesem Wege auch wieder für eine anderweitige Verwendungexportiert werden. Zusammen mit dem eigentlichen Benutzerzertifikat besteht die Möglichkeitüber PKCS#12-Dateien auch gleich Zertifikate der ausstellenden CAs zu importieren. CA-Zer-tifikate können alternativ auch einzeln in den Netscape Communicator eingebracht werden, indem sie entweder über das Menü „File/Open Page“ manuell geladen werden, oder ein Webser-ver das entsprechende Zertifikat im binär codierten DER-Format mithilfe des MIME-Typesapplication/x-509-ca-cert zum Download anbietet. SSL-Server- und Object-Signing-Zertifi-kate werden automatisch von kontaktierten Servern zu Beginn einer Kommunikation übertra-gen und über einen Dialog mit dem Benutzer in die Zertifikatsverwaltung installiert.

Die Zertifikatsverwaltung vom Netscape Communicator erlaubt es, CA-Zertifikate nachträg-lich für die Zertifizierung von S/MIME, SSL oder Object Signing als vertrauenswürdig zuerklären. Standardmäßig ist allerdings keiner der drei Verwendungszwecke nach dem Importvon CA-Zertifikaten gesetzt. Damit eine Überprüfung von Benutzer-Zertifikaten überhaupterfolgreich verlaufen kann, muss nach dem Import somit erst der entsprechende Verwendungs-zweck aktiviert werden. Das kann zu Problemen führen, denn mit dieser Methode können fürCA-Zertifikate auch Zwecke akzeptiert werden, den die Erweiterungen im CA-Zertifikat nichtunterstützen. Nach [DFN00-1] wird beispielsweise eine signierte Email vom Empfänger aufGrund eines ungültigen Zertifikates zurückgewiesen, wenn diese ein S/MIME-Zertifikat zurGrundlage hat, dessen CA für S/MIME akzeptiert wurde, obwohl das CA-Zertifikat ursprüng-lich nicht für diesen Zweck vorgesehen war.

Neben dem Import von Benutzerzertifikaten verfügt der Netscape Communicator über eineFunktion zur Schlüsselerzeugung mit anschließender Online-Zertifizierung. In diesem Fallerzeugt der Browser das asymmetrische Schlüsselpaar selbst.

92


Benutzerzertifikate für SSL

Für SSL-Clientzertifikate sind prinzipiell sämtliche der unter yours vorhandenen Zertifikateeinsetzbar, solange diese gültig sind und die in Abschnitt [3.7.1.3] beschriebenen notwendigenZertifikatserweiterungen gesetzt haben. Natürlich muss die herausgebende CA neben dem Cli-ent auch dem zu kontaktierenden Server als vertrauenswürdige CA für SSL-Clientzertifikatebekannt sein, damit dieser das Clientzertifikat überprüfen kann.Liegen mehrere Zertifikate vor, die alle genannten Bedingungen erfüllen, bietet Netscape einkleines Auswahlfenster an und überlässt die Auswahl des zu verwendenden Zertifikates demAnwender.

Benutzerzertifikate für S/MIME

Bei Zertifikaten für S/MIME gilt Ähnliches wie für SSL-Clientzertifikate. Prinzipiell sindsämtliche der unter yours vorhandenen Zertifikate einsetzbar, solange sie gültig sind und die inAbschnitt [3.7.2.1] beschriebenen notwendigen Zertifikatserweiterungen gesetzt haben. Aller-dings wählt der Messenger zu verwendende Zertifikate an Hand der darin enthaltenen Email-Adresse aus. Diese muss mit der aktuell im Programm eingestellten Email-Adresse überein-stimmen. Von Zertifikaten, die alle genannten Bedingungen erfüllen, können maximal zwei fürS/MIME eingesetzt werden, da der Messenger bei Bedarf zwischen Signatur- und Verschlüsse-lungs-Zertifikaten unterscheidet.

Widerrufslisten

Netscape unterstützt ausschließlich binär codierte CRLs nach X.509v1 im DER-Format undkeine X.509v2 CRLs. Diese lassen sich weder offline in den Browser importieren, noch istanfangs überhaupt etwas zur Verwaltung von Widerrufslisten in der Zertifikatsverwaltungsichtbar. 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 Zertifi-katsverwaltung unter signers eine neue Schaltfläche, über die vorhandene CRLs angezeigtoder erneuert werden können. Anhang [B.3] gibt eine detaillierte Anleitung zur Installationvon Widerrufslisten in den Netscape Communicator.

5.4.3 Microsoft Outlook 2000

Der Personal Information Manager Microsoft Outlook 2000 ist ein Client für den ExchangeServer von Microsoft. Die darin enthaltene Mailfunktionalität unterstützt die Verschlüsselungper S/MIME sowohl mit RC2 als auch DES sowie Triple-DES. Für digitale Signaturen stehenMD5 und SHA-1 als Hashalgorithmen zur Verfügung. Damit diese kryptographischen Algo-rithmen 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 Zertifikats-verwaltung 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 Outlookverwendet für diesen Einsatz ausschließlich Zertifikate, die der im Programm eingestelltenEmail-Adresse entsprechen. Zertifikate anderer Benutzer werden direkt den Kontakten (so dieOutlook-eigene Bezeichnung für Empfänger) zugeordnet, wobei ebenfalls die darin enthalteneEmail-Adresse Beachtung findet.

Die automatische Verbreitung des eigenen Benutzerzertifikates unterstützt Outlook durch denoptionalen Versand des Zertifikates zusammen mit jeder signierten Email. Auf diese Weisekö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 Zertifikatsverwaltungdieselben Widerrufslistenformate wie der IE. Mehr noch, im IE installierte CRLs müssen nichtmehr in Outlook importiert oder registriert werden, wenn dies schon für den IE geschehen ist.Verfügbare Widerrufsinformationen werden automatisch berücksichtigt. Zertifikate, welchevon der herausgebenden CA widerrufen wurden, werden schon beim Importversuch von Out-look 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 Benut-zerzertifikat des Senders wurde wie oben beschrieben mit der Email zusammen verschickt,wird die Signatur eingehender Emails von Outlook noch vor dem Anzeigen der Email automa-tisch geprüft. Abbildung 38 zeigt die Informationen, die Outlook anschließend über die Kor-rektheit 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üsselntheoretisch lediglich das Verschlüsselungs-Zertifikat des Empfängers notwendig sein sollte,verweigert Outlook kommentarlos die Verschlüsselung von Emails, sobald der Sender keineigenes Verschlüsselungs-Zertifikat besitzt. Das Einstellungsfeld für Verschlüsselung (unddigitale Signatur) wird in diesem Fall überhaupt nicht erst frei geschaltet. Dieses sonderbareVerhalten begründet sich vermutlich aus der Tatsache, dass verschlüsselte Emails nach demVersand zusätzlich als Kopie im Ordner gesendete Objekte verschlüsselt abgespeichert werdensollen. Diese Kopie muss aber mit dem Verschlüsselungs-Schlüssel des Senders verschlüsseltwerden, wenn dieser sie jemals wieder lesen möchte.

Probleme

Beim Interoperabilitätstest zeigt Outlook deutliche Schwächen im Bereich digitaler Signatu-ren. Vom Netscape Messenger oder Outlook Express digital signierte Mails konnten nur danngelesen werden, wenn die eigentliche Nachricht zusätzlich als Klartext beigefügt wurde. Dasderartige Nachrichten mit einer digitalen Signatur versehen sind, ist beim Empfang durch Out-look nicht erkennbar. Vermutlich wird die von fremden Programmen erzeugte digitale Signaturseitens Outlook auch nicht auf Gültigkeit überprüft. Von einem Outlook Client erzeugte digi-tale Signaturen werden dagegen in anderen Outlook Clients korrekt als solche erkannt undbehandelt.

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 LDAP-Verzeichnisdiensten gesucht und für die weitere Verwendung in einer Anwendung gespeichertwerden 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ägengesucht, welche den String Musterfrau als Bestandteil des Attributs CommonName (cn) enthal-ten.

Abbildung 39 Suche nach Einträgen im LDAP-Baum

Als Suchergebnis erhält man standardmäßig nur den Distinguished Name (DN) gefundenerEinträge angezeigt. Über ein Kontextmenü lassen sich aber ausgewählte Einträge mit ihrenAttributen anzeigen (siehe Abbildung 40) und evtl. darin enthaltene Zertifikate lokal spei-chern.

Der LDAP Browser\Editor eignet sich natürlich nicht nur zum Suchen von Zertifikaten. Eskönnen auch neue Verzeichniseinträge angelegt sowie eigene Zertifikate im PKCS #12 Formateingespielt werden. Eine Möglichkeit zum Importieren komplexer Verzeichnisstrukturen inbestehende Verzeichnisbäume ermöglicht die Funktion zum LDIF-Import. Somit erfüllt derLDAP 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 Com-municator eine funktionierende Public Key Infrastruktur aufzubauen. Auch der Internet Explo-rer, der leichte Schwächen im Bereich der Widerrufslisten zeigt, scheint geeignet für denEinsatz im Realbetrieb einer PKI.

Lediglich der Internet Information Server, den die DiBa momentan noch in der Version 4betreibt, sollte mittelfristig durch einen Webserver ersetzt werden, der in der Lage ist, widerru-fene Clientzertifikate als solche zu erkennen. Ob dessen Nachfolger (der IIS 5) Widerrufslistenkorrekt behandelt, sollte noch vor einem entsprechenden Update im Zuge der Migration aufein Windows 2000 Netzwerk im Jahr 2002 geprüft werden. Es empfiehlt sich, bei dieser Gele-genheit auch alternative Webserver, wie den Apache10, einer genaueren Betrachtung zu unter-ziehen.

Zu Beginn der Diplomarbeit war der Wunsch des Kunden nach einem virtuellen privaten Netz-werk gegenüber dem sicheren Nachrichtentransfer und dem Zugriff aufs DiBa-Intranet relativgering. Die Prioritäten bei der Erstellung des Sicherheitskonzeptes und der Auswahl der nöti-gen Software waren daher vorrangig auf die beiden letzt genannten Wünsche ausgerichtet. ImLaufe der Diplomarbeit zeigte sich allerdings, dass es sinnvoll wäre mobilen Mitarbeitern denZugang zu allen Funktionen des DiBa-LANs zu verschaffen.Der Aufbau eines VPN würde dies ermöglichen, allerdings konnte die IPSec-Funktionalitätvon Windows 2000 bisher auf Grund fehlender IPSec-Zertifikate seitens FlexiTrust aus-schließ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 bewie-sen. Hinzu kommt der bessere Ruf im Vergleich zum IIS, was Sicherheitslücken betrifft. Weitere Informa-tionen 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 entsprechendeZertifikate 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 Infra-struktur in der Allgemeinen Deutschen Direktbank AG geschaffen.

Nach einer Ermittlung des konkreten Bedarfs und der Aufstellung eines Sicherheitskonzeptesin Kapitel [4] wurden in Kapitel [5] Softwareprodukte unterschiedlicher Hersteller auf ihreEignung hinsichtlich des Einsatzes in der PKI untersucht. Im nächsten Schritt werden die ein-zelnen Ergebnisse dieser Arbeit zusammengefasst und beschrieben, wie die konkrete Realisie-rung einer PKI in der DiBa aussehen sollte.

Neben einer Beschreibung der Zertifizierungshierarchie liefert dieses Kapitel außerdem kon-krete Konfigurationsvorschläge zu den, für den Einsatz ausgewählten, Softwareprodukten.Diese sind neben der Einhaltung des gewünschten Sicherheitsstandards auch auf maximaleInteroperabilität und Benutzbarkeit ausgerichtet.

Der letzte Teil dieses Kapitels beschreibt den Ablauf der Benutzerzertifizierung, wie beispiels-weise notwendige organisatorische Regelungen und Infrastrukturmaßnahmen.

6.1 Zertifizierungshierarchie

Eine zahlmäßig begrenzte Nutzerbasis sowie die Tatsache, dass sämtliche Mitarbeiter nachdenselben, einheitlichen Regeln zertifiziert werden, führte zu der Entscheidung eine flache (d.h. einstufige) Zertifizierungshierarchie aufzubauen. Zudem wurde das flache Modell bereits inder Testumgebung erfolgreich eingesetzt.

Abbildung 41 zeigt die Zertifizierungshierarchie der DiBa-CA. Diese besteht aus vier ver-schiedenen Einheiten, die wie folgt auf die Niederlassungen Frankfurt und Hannover verteiltsind:

� DiBa-CAEine Zertifizierungsinstanz in Frankfurt, zuständig für beide Niederlassungen.

99


� DiBa-RADer DiBa-CA sind zwei lokale Registrierungsinstanzen zugeordnet, die den direk-ten organisatorischen Kontakt zu den Mitarbeitern beider Niederlassungen herstel-len.

� WWWEin oder mehrere Intranet-Server in Frankfurt mit SSL-Serverzertifikaten.

� MitarbeiterAusgewählte Mitarbeiter in den Niederlassungen Frankfurt und Hannover werdenentsprechend ihres Firmenstandortes einer RA zugeordnet und erhalten von dergemeinsamen CA Client-Zertifikate für SSL und S/MIME (sowie später auchIPSec).

Abbildung 41 Die flache Zertifizierungshierarchie der DiBa-CA

Aus den in Kapitel [5.1] genannten Gründen wird auf die Übernahme des VPN-Gateways indie Zertifizierungshierarchie vorerst verzichtet. Da der Einsatz eines virtuellen privaten Netz-werkes aber für die Zukunft angestrebt wird, werden Zertifikate für VPN-Gateways und -Cli-ents in den Zertifizierungsrichtlinien in Kapitel [A] unabhängig vom derzeitigen Einsatzbetrachtet.

6.2 Benutzergruppen

Eine Einteilung von Mitarbeitern in Benutzergruppen mit unterschiedlichen Rechten erfolgtdurch 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 eingetra-gen.

Zertifikate werden personalisiert (d. h. personenbezogen) ausgestellt. Die Einstellung, zu wel-cher Rechtegruppe ein Benutzerzertifikat gehört, erfolgt über eine zentrale Administrationunter Zuhilfenahme der Benutzerverwaltungs-Datenbank (siehe [6.3.2.3]). Dies ermöglicht es,einmal ausgestellte Zertifikate weiterzuverwenden, auch wenn Mitarbeiter auf Grund einesTätigkeitswechsels innerhalb der Firma veränderte Zugriffsrechte erhalten. Dies stellt einenenormen Vorteil dar, denn würde die Gruppenzugehörigkeit in die Zertifikate aufgenommen,

WWWWWW

DiBa-RADiBa-RA

DiBa-CADiBa-CA

Frankfurt Hannover

Mitarbeiter

DiBa-RADiBa-RA

Mitarbeiter

100

Kapitel 6: Umsetzung der Public Key Infrastruktur

müssten diese in solch einem Fall zurückgerufen und entsprechend Neue dafür ausgestellt wer-den.

6.3 Konfiguration der Hard- und Software

In Kapitel 5 wurden Softwareprodukte unterschiedlicher Hersteller für den client- bzw. server-seitigen Einsatz in einer Public Key Infrastruktur untersucht. Die Produkte, die sich - bezogenauf ihre (kryptographische) Leistungsfähigkeit, Handhabbarkeit und Interoperabilität - ambesten in das aufgestellte Sicherheitskonzept integrieren ließen, sollen nun auch im Realbe-trieb 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 InformationServer 4.0 unter Windows NT 4.0 Server beibehalten und entsprechend auf dieVerwendung 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 unterWindows NT 4.0 Server wird beibehalten. Es sind keine besonderen Einstellungenfür den Einsatz von Verschlüsselung oder digitaler Signatur erforderlich, da diesekomplett in den Clientprogrammen vorgenommen werden. Wie in Abschnitt[5.3.2] festgestellt, sind auch für den Betrieb der Exchange Server -KomponenteOutlook Web Access keine Änderungen gegenüber den bestehenden Einstellungennotwendig.

� Software für Server (VPN-Gateway):Für den Betrieb des VPN-Gateways sollen in Zukunft die Möglichkeiten des Win-dows 2000 Server-Betriebssystems von Microsoft genutzt werden. Allerdings sindvon FlexiTrust 2.0 ausgestellte IPSec-Zertifikate derzeit noch nicht mit Windows2000 kompatibel. Von einer Verwendung im Realbetrieb muss daher vorerst abge-sehen werden.Für sicherheitstechnische Überlegungen, welche die Konfiguration des VPN-Gate-ways - wie beispielsweise die Platzierung hinter, direkt auf, oder neben der Fire-wallkonstruktion - 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 FirewallsEine detaillierte Darstellung der Änderung an der Firewall-Konfiguration ist nichtGegenstand dieser Arbeit.

Abbildung 42 zeigt die Anordnung der ausgewählten Produkte im Netzwerk der AllgemeinenDeutschen Direktbank AG.

Abbildung 42 Anordnung der Hard- und Software im Realbetrieb der Public Key Infrastruktur

Einzelheiten zum Einsatz, sowie der Konfiguration der Produkte, liefern die folgendenAbschnitte.

6.3.1 FlexSecure FlexiTrust 2.0

Die Installation von FlexiTrust erfolgt auf zwei Windows 2000-basierenden Rechnern. Aufdem ersten Rechner befindet sich aus Sicherheitsgründen neben der eigentlichen CA nur dasnotwendige Java 1.2.2. Die Installation der weiteren Einheiten wie RA und IS sowie einerSQL-Datenbank1 erfolgen auf dem zweiten Rechner. Die Trennung dieser Dienste entsprichtden 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 CAund RA/IS notwendige Datenaustausch wird von Mitarbeitern der DiBa-CA per Wechselme-

1. Empfohlen wird mySQL in der Version 3.23.39

<Frankfurt Hannover>

Mobiler Mitarbeiter

Mail-Server WWW-Server

Internet

VPN-Gateway(in Zukunft geplant)

LDAP-Server(in Zukunft geplant)

DiBa-RA + DiBa-IS DiBa-RA

DiBa-CA

(Outlook Web Access)

Firewalls undVirenscanner

(Zertifikate + CRLs)

102


dium vorgenommen.

Wurden in der Testumgebung noch universale Schlüsselpaare mit der gleichzeitigen Eigen-schaft der Verschlüsselung und digitaler Signatur verwendet, werden aus Sicherheitsgründenim Realbetrieb ausschließlich strikt getrennte Schlüsselpaare für Verschlüsselung und digitaleSignatur erzeugt (Policy, Abschnitt [A.4]). Diese Schlüssel dürfen nur für den jeweils für sievorgesehenen Einsatzzweck verwendet werden. Gute Gründe für den Einsatz zweier Schlüs-selpaare 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.5inkl. dem High Encryption Pack auf diesem System zu installieren, damit symmetrische Ver-schlüsselung mit 128 Bit und Asymmetrische mit 1024 Bit möglich wird.

Im Folgenden wird kurz beschrieben, welche Einstellungen am IIS vorgenommen werdenmüssen, um die Voraussetzungen für den Einsatz in der Public Key Infrastruktur im Zusam-menspiel 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üs-selmanager.

Es wird empfohlen bei der Generierung des Schlüsselpaares für die Parameter Schlüsselnameund Allgemeiner Name den Domainnamen des Intranetservers zu verwenden. Um ausrei-chende Sicherheit zu gewährleisten, sollte die Bitlänge des Schlüssels mind. 1024 Bit betra-gen.

Die im Anschluss an die Schlüsselgenerierung erzeugte Zertifizierungsanforderung wird an dieDiBa-CA übergeben. Abschließend wird das von der DiBa-CA signierte Serverzertifikat in dervorliegenden PEM-Version (*.pem.crt) in den IIS-Schlüsselmanager zu dem zugehörigenSchlü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 aufdem 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, dasCA-Zertifikat als vertrauenswürdige Stammzertifizierungsstelle in den Speicher Lokaler Com-puter (an anderer Stelle auch Computerkonto genannt) zu installieren. Zertifikate, die stattdes-sen in den Speicher Eigenes Benutzerkonto (auch Registrierung genannt) installiert werden,erlauben ausschließlich die SSL Serverauthentifizierung. Anhang [B.2] beschreibt diesen Vor-gang 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 eigentlicheKonfiguration des IIS erfolgen. Webseiten, welche per SSL abgesichert werden sollen, sindunbedingt so zukonfigurieren, dass Verbindungen von Clients, die keine starke Kryptographieunterstützen, abgelehnt werden (128 Bit Verschlüsselung erforderlich).

Binden von Clientzertifikaten an Mitarbeiter

Um Zugriffe autorisierter Mitarbeiter von denen unautorisierter oder organisationsfremder Per-sonen unterscheiden zu können, ist es erforderlich die SSL Clientauthentifizierung im IISexplizit zu aktivieren (Clientzertifikate verlangen) und übergebene Zertifikate autorisiertenMitarbeitern zuzuordnen (Client-Zertifikatszuordnungen aktivieren). Dabei besteht die Mög-lichkeit, Mitarbeiter in Gruppen mit unterschiedlichen Rechten einzuteilen. D. h. einzelnenMitarbeitern den Zugriff auf bestimmte Seiten zu erlauben, die anderen Mitarbeitern verwehrtbleiben. Um den Server auf diese Art zu konfigurieren, müssen die Benutzerzertifikate vonautorisierten Mitarbeitern in den Server hinzugefügt und an die entsprechenden Windows NTDomänenbenutzerkonten gebunden werden. Das beim eigentlichen Zugriff auf eine derart kon-figurierte Seite übergebene Clientzertifikat wird nun automatisch vom IIS dem Domänenbe-nutzerkonto 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 DiBa-CA Benutzerzertifikates sind, zugänglich sein. Um den Zugriff unautorisierter Personen (mitBenutzerzertifikaten, die von anderen CAs ausgestellt wurden) zu unterbinden, können zweiRegeln innerhalb der Clientzertifikatszuordnung erstellt werden:

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

� Regel 2:Die nachfolgende Einstellung Alle vertrauten Zertifikataussteller den Zugriff ver-weigern unterbindet Zugriffe von Clients mit Benutzerzertifikaten anderer CAs.

Clients mit nicht-vertrauten bzw. unbekannten Zertifikatausstellern und Clients ohne Benut-zerzertifikat wird automatisch der Zugriff verweigert, diesbezüglich ist keine besondere Ein-stellung notwendig. Diese Regeln lassen sich weiter verfeinern. Beispielsweise erlaubt dieAbfrage des im Zertifikat enthaltenen DN die Filterung nach Niederlassung oder Abteilung derMitarbeiter.

6.3.3 Microsoft Internet Explorer 5.5

Für den Betrieb des Internet Explorers in der Public Key Infrastruktur ist mindestens die Ver-sion 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 dieverwendete IE Version den High Encryption Pack von Microsoft enthält. Dieser muss notfallsseparat nachinstalliert werden, sonst kann eine SSL-Verbindung nur mit 40/56 Bit Verschlüsse-lung 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 ach-ten, 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ßendsowohl ü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 Systemendas Outlook-Update auf die aktualisierte 128-Bit-Verschlüsselung notwendig, um starke Ver-schlüsselung auch innerhalb Outlooks zu ermöglichen.

Da Outlook ein Bestandteil von Microsofts Office 2000 ist, sollte die komplette Office Umge-bung auf dem Stand von Service Release 1a sowie Service Pack 2 sein. Die angebotenenSicherheitsupdates, insbesondere jene zur Email-Sicherheit, sollten ebenfalls installiert wer-den.

Clientkonfiguration für S/MIME

Wurde bereits zuvor wie oben beschrieben der Internet Explorer installiert, sind das DiBa-CAZertifikat sowie die Clientzertifikate des Mitarbeiters automatisch für Outlook verfügbar. Nunmuss Outlook lediglich mitgeteilt werden, welches der Zertifikate für welchen Zweck (digitaleSignatur oder Verschlüsselung) verwendet werden soll. Zur Auswahl stellt Outlook sämtlichefür den jeweiligen Zweck geeigneten Zertifikate, welche in der Zertifikatsverwaltung vonWindows verfügbar sind. Für das Signaturzertifikat sollte der Hashalgorithmus SHA1 und fürdas Verschlüsselungszertifikat der Verschlüsselungsalgorithmus 3DES ausgewählt werden.Die gewählten Algorithmen werden beim digitalen Signieren bzw. Verschlüsseln von Emailsverwendet und sind unabhängig von den im Zertifikat angegebenen Algorithmen.

Ebenso wie beim Internet Explorer sollte darauf geachtet werden, dass bestimmte Einstellun-gen 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 vonOutlook gewünschten DER-codierten Format vor. Allerdings importiert Outlook Benutzerzer-tifikate ausschließlich dann in den Bereich Kontakte für fremde Mitarbeiter, wenn die Dateien-dung auf *.cer lautet. Aus diesem Grund müssen Zertifikate vor dem Import momentan nochentsprechend umbenannt werden. Zukünftige Versionen von FlexiTrust werden diese Dateien-dung automatisch erzeugen. Es ist möglich, einem einzelnen Kontakt mehrere Zertifikatezuzuordnen, falls dieser Kontakt verschiedene Email-Adressen enthält. Outlook verwendetdann automatisch das zur Email-Adresse gehörende Zertifikat beim Senden einer verschlüssel-ten Nachricht an diesen Mitarbeiter.

Verschlüsselung und digitale Signatur bei ausgehenden Nachrichten

Damit Nachrichten beim Versand an andere Mitarbeiter automatisch ohne Zutun verschlüsseltwerden, empfiehlt es sich, die Option Nachrichteninhalte und Anlagen verschlüsseln zu akti-vieren. Gleiches gilt für die Option Dig. Signatur ausgehenden Nachrichten hinzufügen, damitwerden ausgehende Nachrichten automatisch digital signiert.

Verschlüsselung und digitale Signatur bei eingehenden Nachrichten

Empfangene, verschlüsselte Nachrichten werden nicht im Vorschaufenster von Outlook ange-zeigt. Zum Lesen der Nachricht muss diese erst geöffnet werden. Über ein blaues Schloss-Symbol 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 Nachrichtenfensterkönnen - ebenso wie bei der Verschlüsselung - Informationen zum verwendeten Signaturzerti-fikat eingesehen werden. Weiterhin liefert dieser Dialog Informationen bezüglich der Gültig-keit der digitalen Signatur, wie beispielsweise, ob die Nachricht unverändert ist, oder ob dasSignaturzertifikat gültig ist. Bei fehlerhaften Signaturen oder -Zertifikaten warnt Outlook vordem Öffnen der Nachricht den Benutzer entsprechend. Es wird empfohlen, diesen Warnhin-weis nicht explizit auszuschalten, um kompromittierte Nachrichten schnell erkennen zu kön-nen. Weiterhin sollte beim Empfang signierter Nachrichten ausdrücklich das verwendeteSignaturzertifikat ü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üssel-paaren, der Vorgang der Zertifizierung und Schlüsselverteilung / -Verwaltung, sowie die Sper-rung von Zertifikaten berücksichtigt.

106


6.4.1 Registrierung

Registriert werden neben Mitarbeitern auch WWW-Server sowie später VPN-Gateways. ZurAufgabe der DiBa-RA gehört neben der Annahme und Prüfung von Zertifizierungsanträgenauch die Vergabe eindeutiger Namen für Mitarbeiter und Server.

Anfragen von Mitarbeitern bezüglich der Aufnahme in die Zertifizierungsinfrastruktur undeine damit verbundene Zuteilung von digitalen Schlüsseln und Zertifikaten erfolgen an admi-nistrative 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 ZertifikatserzeugungIdentifikation des Mitarbeiters, wie beispielsweise Name und Adresse.

� Daten des zugeordneten Arbeitsplatzesu. a. Standort, Rechnername sowie IP-Adresse.

� Daten zur Verwaltung und Sperrung von ZertifikatenNotwendige Kennwörter etc.

Anfangs werden Registrierungsdaten noch manuell durch die Administratoren von der zentra-len Benutzerdatenbank in das Registrierungsformular der DiBa-RA übernommen. Es ist denk-bar, dass diese Aufgabe in Zukunft durch eine - noch zu schaffende - Schnittstelle zwischender DiBa-CA Datenbank und der Benutzerdatenbank automatisch erledigt werden kann. Dieswü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üsselpaareerzeugt. Je eines für:

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

� Digitale Signatur (S/MIME)Der private Teil des Signaturschlüsselpaares wird nur solange innerhalb der DiBa-CA aufbewahrt bis er von Administratoren der DiBa-CA an den entsprechendenMitarbeiter ausgehändigt wurde (siehe Punkt [6.4.4]). Nach der Übergabe an denMitarbeiter wird dieser auf Seiten der DiBa-CA unwiderruflich gelöscht.

Die erstellten privaten Schlüssel der jeweiligen Schlüsselpaare werden in PKCS#12-Dateienzusammen mit den Benutzerzertifikaten (siehe nächster Schritt) und dem DiBa-CA Zertifikatuntergebracht. 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 Drittegeschützt. Für beide PSEs eines Mitarbeiters kann dabei aus Gründen der Einfachheit dasselbeKennwort 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 selbstund 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 dasder 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 undin 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 vonPKCS#12-Dateien zusammen mit den Benutzerzertifikaten, dem DiBa-CA Zertifikat und deraktuellsten Sperrliste an die Mitarbeiter und nehmen deren Installation auf dem Rechner desMitarbeiters vor. Der Mitarbeiter muss sich davon überzeugen, dass die in den Zertifikaten ent-haltenen persönlichen Daten korrekt sind. Anschließend erhält er eine Einweisung in dieAnwendung der vom Mitarbeiter zu verwendenden Produkte sowie den sorgsamen Umgangmit privaten Schlüsseln und deren Bedeutung.

Nach der Übergabe des schlüsseltragenden Datenträgers an den Mitarbeiter bekommt dieserdie notwendigen Kennwörter für den Zertifikatswiderruf und zur Entschlüsselung der PSEsvom 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. Sodassauch Mitarbeiter, die nicht zertifiziert wurden, Zugriff auf das DiBa-CA Zertifikat haben, umdigitale Signaturen zu prüfen.

108


6.4.5 Sperrmanagement

Benutzerzertifikate können sowohl durch persönlichen Kontakt mit der RA als auch telefo-nisch oder per Email gesperrt werden.

Um die Authentizität des Sperrantrages zu überprüfen und sicherzustellen, dass der Mitarbeiterberechtigt ist das Zertifikat zu sperren, ist von Seiten des Mitarbeiters die Nennung des Kenn-wortes für den Zertifikatswiderruf (s.o.) notwendig. Ohne Nennung des Kennwortes ist derpersönliche Kontakt mit einem RA-Mitarbeiter unter Vorlage des Personalausweises notwen-dig. 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 Seri-ennummer und evtl. eines Sperrgrundes. Die Erstellung einer aktualisierten Widerrufslisteerfolgt 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 vonZertifikaten auf Grund der anfangs geringen Nutzerbasis noch nicht notwendig.

Die Veröffentlichung aller vorzeitig widerrufenen Zertifikate (deren Gültigkeitszeitraum nochnicht abgelaufen ist)1 in Form von Widerrufslisten im X.509v1 Format erfolgt auf dem Intra-net-Server der DiBa mittels HTTP-Protokoll. Von dieser Praxis sollte auch dann nicht abgewi-chen werden, wenn in Zukunft ein LDAP-Verzeichnisdienst zur Veröffentlichung vonZertifikaten bereit gestellt wird. Microsoft weist in [MS01-3] auf Performanceeinbußen bei derBereitstellung von Widerrufslisten über LDAP-Verzeichnisdienste gegenüber HTTP-Servernhin.

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 sollteimmer doppelt besetzt werden. Der Zugriff auf wichtige Ressourcen wie dem CA-Signier-schlüssel sollte immer nur zwei autorisierten Mitarbeitern gemeinsam möglich sein, sodass einMissbrauch 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 Gene-rierung in zwei Teil-Passwörter aufzuteilen und jedem CA-Mitarbeiter nur jeweils einen Teildes Passwortes auszuhändigen. Um den CA-Signierschlüssel zu verwenden, müssen somitimmer zwei Administratoren gleichzeitig zugegen sein, was einen gewissen Schutz vor Insi-der-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

Kommentarzu den Zertifizierungsrichtlinien

Zertifizierungsrichtlinien (im Folgenden als Policy bezeichnet), definieren feste Regeln undRichtlinien, nach deren Vorgaben die Zertifizierung durch die DiBa-CA zu erfolgen hat. DerSinn einer Policy ist es, den Mitarbeitern eine Einschätzung der durch die DiBa-CA ausgestell-ten Zertifikate zu ermöglichen.

In diesem Kapitel werden einige interessante und z. T. bedenkliche Stellen der Policy ausAnhang [A] betrachtet. Dabei wird besonderes Augenmerk auf die speziellen Anforderungendes SigG gelegt.

7.1 Rechtliche Bedeutung

Nachteil der fehlenden rechtlichen Bedeutung

Abschnitt [A.2.1]: „Eine Zertifizierung durch die DiBa-CA zieht keinerlei rechtlicheBedeutung nach sich; ein gesetzlicher Anspruch auf Erteilung eines Zertifikates durchdie DiBa-CA besteht nicht.“

Die fehlende rechtliche Bedeutung der DiBa-CA-Zertifizierung schließt den Einsatz ausge-stellter Zertifikate außerhalb des Unternehmens der Allgemeinen Deutschen Direktbank AGaus. Bezahl- oder Bestellvorgänge mit diesen Zertifikaten im E-Commerce sowie der Daten-austausch mit Behörden, anderen Finanzinstituten oder Unternehmen führen daher zu Kompli-kationen bei der Beweisführung im Falle des Missbrauchs privater Schlüssel. Für diesenEinsatzzweck sind Zertifikate der DiBa-CA allerdings auch nicht vorgesehen. Diese werdenausschließlich für den unternehmensinternen Gebrauch mobiler DiBa-Mitarbeiter zum Zweckder Authentifikation gegenüber Unternehmensservern im LAN sowie zur Absicherung derenelektronischer Kommunikation eingesetzt. Für organisationsfremde Personen, sowie Mitarbei-ter die nicht auf die mobile Kommunikation angewiesen sind, besteht daher kein Anspruch aufdie 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 technischeKomponenten und Verfahren zur Zertifizierung sind derzeit nicht SigG-konform. Zertifi-kate der DiBa-CA entsprechen demnach nicht den qualifizierten Zertifikaten nach §2Nummer 7 des Signaturgesetzes (SigG).“

Die DiBa-CA wird ihren Betrieb zunächst nicht als Zertifizierungsstelle nach dem deutschenSignaturgesetz (SigG) aufnehmen. Zum einen übersteigen die Anforderungen des SigG anorganisatorische, technische, personelle sowie bauliche Maßnahmen den Rahmen dessen, wasim Zuge einer Diplomarbeit realisiert werden kann. Zum anderen ist derzeit noch nicht abzuse-hen, ob in naher Zukunft überhaupt ein Bedarf an SigG-konformer Zertifizierung entsteht, dereinen solchen Aufwand rechtfertigen würde.

Im Folgenden sind exemplarisch zwei Gründe dargestellt, die gegen den Einsatz einer SigG-konformen Lösung sprechen:

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

� SigV 97 Begründung, §16 Abs. 2: „Die Signiertechnik wird in der Regel imwesentlichen auf einer Chipkarte oder einem vergleichbaren Träger (z. B. PCM-CIA-Karte) realisiert.“Hardware-PSEs (Chipkarten) werden von der DiBa-CA in der ersten Phase nichteingesetzt, stattdessen wird eine Softwarelösung favorisiert. Digitale Signaturenwerden auf den Rechnern der Mitarbeiter erzeugt und private Schlüssel entspre-chend auf Festplatte gespeichert. Dies entspricht nicht dem, für die Erzeugung qua-lifizierter Signaturen nach SigG, gefordertem Sicherheitsstandard.

Separate Signier- und Entschlüsselungsschlüssel

SigG §5, Abs. 4: „Eine Speicherung von Signaturschlüsseln außerhalb der sicherenSignaturerstellungseinheit ist unzulässig.“

Signaturschlüssel dürfen laut SigG nur beim Mitarbeiter selbst auf den dafür vorgesehenenSoftware- oder Hardwareeinheiten (PSEs wie beispielsweise Chipkarten) gespeichert werden.Eine Speicherung in der Zertifizierungsstelle, wie sie für Key Recovery notwendig wäre, istnicht zulässig. Das SigG betrachtet allerdings ausschließlich Schlüssel zur Erstellung digitalerSignaturen (Signierschlüssel). Für die bei der DiBa (zusätzlich) notwendigen Verschlüsse-lungsschlüssel ist aber ein Verfahren zur Wiederherstellung unerlässlich. Eine Lösung bietetdie 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 Mate-rial, das Angreifern für eine Kryptoanalyse zur Verfügung steht, denn jeder der beiden Schlüs-sel 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 dieSicherheit des Gesamtsystems, ein kompromittierter Schlüssel kann nur entweder zur Ver-schlüsselung einer Kommunikation oder für digitale Unterschriften benutzt werden - nicht aberfür beides.

7.2 Einsatz von Registrierungsinstanzen

Abschnitt [A.2.3]: „Allgemein lässt sich durch Einsatz solcher RAs die Zahl der organi-sationseigenen CAs überschaubar halten. RAs dürfen lediglich zur Registrierung undÜberprüfung von Benutzern eingesetzt werden. (...) Die DiBa-RA hat eine rein organisa-torische Funktion, sie darf weder das asymmetrische Schlüsselpaar für Mitarbeitererzeugen, noch kann sie Mitarbeiter-Zertifikate erteilen oder widerrufen.“

Der Einsatz lokaler RAs verringert die Notwendigkeit zusätzlicher CAs, wenn die zuständigeCA weit von den zu zertifizierenden Mitarbeitern entfernt ist. Aufgrund der Tatsache, dassRAs mit weniger Rechten (und Pflichten) als CAs ausgestattet sind, ergeben sich bei derenEinsatz wichtige Vorteile:

� Reduktion des VerwaltungsaufwandesDie Administration einer RA ist unkomplizierter als die einer CA, da keine ver-gleichbar komplexe Hard- / Software-Infrastruktur eingesetzt werden muss. DerAufbau einer RA ist entsprechend mit einem wesentlich geringeren technischenAufwand zu erreichen.

� SicherheitsaspektMitarbeiter einer RA benötigen weniger sicherheitstechnisches Wissen, als Mitar-beiter einer CA. Entsprechend geringer fällt der Schulungsaufwand für diese Mit-arbeiter aus.

7.3 Sicherheit in einer hierarchischen Struktur

Abschnitt [A.3]: „Durch die Teilnahme an einer Public Key Infrastruktur entstehen fürMitarbeiter bestimmte Anforderungen hinsichtlich der Sicherheit der eingesetzten Hard-und Software einerseits sowie dem verantwortungsvollen Umgang mit kryptographi-schen Schlüsseln andererseits. Die Anforderungen an die DiBa-CA sind dabei naturge-mäß höher, da der Missbrauch eines CA-Schlüssels allen untergeordneten Zertifikatendie Vertrauenswürdigkeit entziehen würde.“

Werden in einer derartigen hierarchischen Struktur die erwähnten Sicherheitsmerkmale nichttatsächlich alle eingehalten, kann dies Auswirkungen auf andere Mitarbeiter dieser Hierarchiehaben. Insbesondere eine übergeordnete CA muss mit besonderer Aufmerksamkeit auf dieeigene Einhaltung der Sicherheitsanforderungen achten. Falls der CA-Schlüssel kompromit-tiert werden sollte, verlieren alle untergeordneten Instanzen (RAs, Mitarbeiter, WWW-Server,etc.) der Hierarchie ihre Vertrauenswürdigkeit. Dies zieht eine erneute Zertifizierung des kom-pletten 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 geeigneterWeise die Eindeutigkeit folgender Informationen zu überprüfen: 1) Zugehörigkeit desRechners zur Allgemeinen Deutschen Direktbank AG. 2) Identität des Mitarbeiters.“

An dieser Stelle unterscheidet sich die Policy der DiBa-CA ein wenig von Policies andererCAs wie beispielsweise der Low-Level Policy des DFN [DFN99-1]. Der diesbezüglicheAbsatz 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 vor-zustellen, um der CA (bzw. RA) die Verifikation der Identität und die korrekte Zuordnungeiner erreichbaren Email-Adresse zu diesem Benutzer ... zu ermöglichen. Für den Prozeßder Verifikation ist die Vorlage eines Personalausweises/Reisepasses bzw. eines ver-gleichbaren Dokumentes erforderlich.“

Eine derartig strenge Authentifikationsprüfung von Benutzern ist für die Teilnahme an derPublic Key Infrastruktur der DiBa nicht notwendig, da es sich bei diesen ausschließlich umDiBa-Mitarbeiter und nicht um organisationsfremde Personen handelt. Sämtliche erforderli-chen Daten, wie Name, Abteilung, Benutzerrechte, Email-Adresse usw. sind von allen Mitar-beitern zentral in einer Datenbank erfasst. Diese umfasst neben den notwendigen persönlichenDaten aller Mitarbeiter auch Daten zu den, ihnen zur Verfügung gestellten (mobilen) Rech-nern. Zudem nehmen Administratoren der DiBa die Installation von Schlüsseldaten und Zerti-fikaten auf den entsprechenden Rechnern vor. Eine Überprüfung, ob es sich bei der Person, dieden Zertifizierungsantrag stellt, um den angegebenen Mitarbeiter handelt, gewährleistet daherausreichende 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ültigkeits-dauer von maximal einem Jahr.“

Die im November 1997 in Kraft getretene Signaturverordnung (SigV) verlangt, dass Zertifi-kate eine Gültigkeitsdauer besitzen müssen [SigG97-2] §7. Mit einer Dauer von einem Jahrwird die geforderte Höchstdauer von fünf Jahren eingehalten. Zum SigG aus dem Jahr 2001existiert momentan (Mitte 2001) noch keine derartige Verordnung. Es ist aber zu erwarten,dass diese entsprechende Passagen enthalten wird. Die reduzierte Gültigkeit von einem Jahrwird durch den prototypischen Status der DiBa-CA begründet. Nach Ablauf der Prototypen-Testphase wird entschieden, ob Folgezertifikate mit einer längeren Gültigkeit ausgestellt wer-den.

Schlüsselgenerierung innerhalb der Zertifizierungsinstanz

Abschnitt [A.4.1]: „Mitarbeiter, welche zertifiziert werden möchten, generieren selbstkein eigenes asymmetrisches Schlüsselpaar, sondern übermitteln nur den Zertifizierungs-wunsch 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 technischenKomponenten für Zertifizierungsdienste. Nur diese erlauben bei Erzeugung und Übertragungdie 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üsselgene-rierung dem Mitarbeiter zu überlassen, würde dies u. U. nicht gewährleisten. Zumindest müs-ste jeder Mitarbeiter selbst über entsprechende Kenntnisse und Infrastrukturen verfügen. EineSchlüsselgenerierung im Zertifizierungsdienst nimmt dem Benutzer diese Bürde und ist für ihnentsprechend unkompliziert. Gleichzeitig bietet sie den Vorteil, die Schlüsselhinterlegungerheblich zu vereinfachen. Ein Nachteil darf allerdings nicht vergessen werden: die fehlendeRechtssicherheit. Denn private Schlüssel der Mitarbeiter sind (zumindest zeitweise) im Besitzmehrer Personen. Niemand kann hundertprozentig garantieren, dass eine erzeugte digitaleSignatur vom Mitarbeiter selbst stammt. Es ist denkbar, dass ein CA-Mitarbeiter in betrügeri-scher Absicht den Besitz fremder Mitarbeiterschlüssel ausnutzt um in fremden Namen digitaleSignaturen zu erzeugen.

7.5 Widerruf von Zertifikaten

Einsatz von Widerrufslisten

Abschnitt [A.6]: „Alle widerrufenen Zertifikate werden von der DiBa-CA auf einerWiderrufsliste (Certificate Revocation List, CRL) veröffentlicht, welche allen Mitarbei-tern zur Verfügung gestellt wird, um widerrufene Zertifikate nicht irrtümlicherweise zubenutzen.“

In der Begründung zu §8 der Signaturverordnung [SigG97-3] wird explizit der Einsatz vonsog. Zertifikats-Sperrlisten für Großanwender vorgeschlagen. Was nichts anderes darstellt, alsdie hier eingesetzte Widerrufsliste.

Wiedereinsetzung eines widerrufenen Zertifikates

Abschnitt [A.6]: „Einmal widerrufene Zertifikate können nicht erneuert oder verlängertwerden. Jedoch hat jeder Mitarbeiter grundsätzlich die Möglichkeit, ein neues Zertifikatzu 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 Zertifi-kat gesperrt war. Die Begründung zur Signaturverordnung spricht ausdrücklich von der Mög-lichkeit, bei Bedarf neue Zertifikate auszustellen.

7.6 Zusammenfassung

Bei der Festlegung der Zertifizierungsrichtlinien wurde Wert darauf gelegt, die gestelltenSicherheitsanforderungen zu erfüllen und dabei den Alltagsbetrieb möglichst nicht durchunzumutbare Regeln einzuschränken. Einige der dabei entstandenen Regeln und Richtlinienwurden 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, mitder prototypischen Trustcenter-Software FlexiTrust eine funktionierende Public Key Infra-struktur aufzubauen, welche die Anforderungen an ein einheitliches Sicherheitskonzept für dieAllgemeine Deutsche Direktbank AG erfüllen kann. Zusammen mit Standardsoftware andererHersteller ist es möglich, die Kommunikation mobiler Mitarbeiter zu schützen sowie sicherenZugriff auf vertrauliche Intranetinhalte zu gewährleisten. Das Gesamtkonzept hat sich damitals tragfähig erwiesen.

Verwendbarkeit der eingesetzten Software

Die Bedienerfreundlichkeit des FlexiTrust Produktes in Bezug auf die Installation war wäh-rend des Verlaufes dieser Arbeit (bedingt durch die gleichzeitig fortschreitende Entwicklung)starken Veränderungen unterworfen. Mittlerweile wurde die Installation wesentlich verein-facht. Die Einrichtung und Grundkonfiguration einer neuen Root-CA gelingt allerdings nochnicht ohne Mitwirken des Herstellers. Hier sollte für die Zukunft ein grafisches Benutzerinter-face zur komfortablen Konfiguration geschaffen werden. Dieses sollte in der Release-Versiondie momentan auf direkten Datenbankeingriffen und Scriptdateien basierende Konfigurations-möglichkeit ersetzen (oder zumindest ergänzen).

Der Funktionsumfang des Trustcenter Produktes genügte bereits in der jetzigen Version in denmeisten Punkten den Anforderungen des Sicherheitskonzeptes. Lediglich Funktionen zumAufbau virtueller privater Netzwerke auf IPSec-Basis können derzeit nicht für die ausgewähltePlattform (Windows 2000) bereitgestellt werden. Diese werden allerdings in der endgültigenVersion verfügbar sein.

Im Bereich der zusätzlich eingesetzten Standardsoftware zeigte der ausgewählte InternetExplorer Schwächen beim Einsatz von Widerrufslisten. Als Ausweg aus dieser Misere bietetsich 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 gegenexterne Angriffe bieten. Sollte die Weiterverwendung des derzeitigen IIS 4 gewünscht sein, istdie ausdrückliche Bindung jedes einzelnen Zertifikates über die Clientzertifikatszuordnung anden Webserver eine Möglichkeit, auf Widerrufslisten innerhalb des IIS zu verzichten. Widerru-fenen Zertifikaten könnte man dann die Bindung entziehen, so wäre sichergestellt, dass ungül-tigen Zertifikaten kein Zugang gewährt würde.

8.2 Ausblick

Smartcards vs. Software-PSE

Das Sicherheitskonzept sieht derzeit keine Realisierung kryptographischer Operationen inHardware vor. Sämtliche Funktionen wie Schlüsselgenerierung, Ver- und Entschlüsselung,digitale Signatur sowie Authentifikations-Mechanismen werden ausschließlich in Form einerSoftwareimplementierung auf Client- und Serverrechnern ausgeführt. Dazu notwendigeSchlüsseldaten werden direkt auf der Festplatte des jeweiligen Rechners gespeichert und sindentsprechend schwach gegen Angriffe geschützt.

Die Sicherheit ließe sich durch den Einsatz von Smartcards erheblich erhöhen. Neben derhöheren Sicherheit bieten Smartcards weitere Vorteile. Sie eignen sich beispielsweise hervor-ragend zur Authentifikation von Mitarbeitern. So könnten Smartcards auch als Zugangsbe-rechtigung zum PC eingesetzt werden. Auf diese Weise könnte man den fehlerträchtigenLoginvorgang auf Passwortbasis ablösen.

Einbeziehung weiterer Mitarbeiter in die PKI

Die Zielgruppe für die Einführung des Sicherheitskonzeptes in Phase 1 umfasst ausschließlichmobile Mitarbeiter. Im Zuge der Einführung von Smartcards und der damit verbundenen Mög-lichkeit der sicheren Authentifizierung im Bereich der Zugangsberechtigung am PC bietet essich an, sämtliche Mitarbeiter der DiBa in das Sicherheitskonzept zu integrieren.

Anpassung des Konzeptes an SigG-Konformität sowie Erweiterung des Nutzerkreisesauf Brokeragekunden

Solange Zertifikate der DiBa-CA ausschließlich innerhalb des Unternehmens der AllgemeinenDeutschen Direktbank AG eingesetzt werden, besteht keine Notwendigkeit für den Einsatzqualifizierter digitaler Signaturen nach SigG. Eine Umstellung auf ein SigG-konformes Kon-zept würde es allerdings ermöglichen, Signatur-Chipkarten im Bereich Onlinebanking undBrokerage an Kunden herauszugeben und damit die bisherige PIN/TAN-basierte Lösung zuersetzen.

118

Anhang A

Zertifizierungsrichtlinien: Policy

Dies ist die Version 1.0 der Policy der DiBa-CA. Sie basiert zum Großteil auf der Policy derFernUni-CA der FernUniversität Hagen [FUHagen01], der Medium-Level-Policy der DFN-PCA [DFN99-1] sowie der Policy der Bundesverwaltung [BSI97]. Absätze und Formulierun-gen, welche die DiBa-CA betreffen, wurden den vorgenannten Policies entnommen bzw. aufdie DiBa-CA spezifischen Besonderheiten umgeschrieben.

Dieses Kapitel enthält die Zertifizierungsrichtlinien (die sog. Policy) der obersten Zertifizie-rungsinstanz der Allgemeinen Deutschen Direktbank AG - DiBa (DiBa-CA). Die DiBa-CA istzugleich Wurzelinstanz dieser Hierarchie (PCA), da sie derzeit selbst von keiner übergeordne-ten CA zertifiziert ist.

Der Sinn dieses Dokumentes ist es, Benutzern im Netzwerk eine Einschätzung der durch dieseCA 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-CAAllgemeine Deutsche Direktbank AGBaseler Straße 27-3160329 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 DeutschenDirektbank AG. Das vorrangige Ziel der DiBa-CA besteht in dem Aufbau einer firmenweitenPublic Key Infrastruktur zur Zertifizierung einzelner Mitarbeiter der Allgemeinen DeutschenDirektbank AG. Eine solche Infrastruktur ist die Voraussetzung für die vertrauenswürdigeKommunikation im Netzwerk der Allgemeinen Deutschen Direktbank AG. Realisiert durchSicherheitsdienste wie Integrität, Authentizität und Vertraulichkeit.

Die DiBa-CA wird in der ersten Phase ausschließlich Zertifikate für unternehmensinterneRegistrierungsinstanzen (RAs), DiBa Mitarbeiter, WWW-Server sowie VPN-Gateways, nichtjedoch für untergeordnete Zertifizierungsinstanzen (CAs) sowie weitere Registrierungsinstan-zen (RAs), oder andere Benutzer erteilen.

Die DiBa-CA unterstützt ausschließlich das Zertifikats-Format X.509v3, welches in aktuellenInternet-Programmen für unterschiedliche Anwendungen (SSL, S/MIME sowie IPSec) einge-setzt wird.

A.2.1 Rechtliche Bedeutung

Eine Zertifizierung durch die DiBa-CA zieht keinerlei rechtliche Bedeutung nach sich; eingesetzlicher Anspruch auf Erteilung eines Zertifikates durch die DiBa-CA besteht nicht. DerSinn einer Public Key Infrastruktur liegt in der Schaffung der technischen Voraussetzungen füreine gesicherte elektronische Kommunikation. Insbesondere die Allgemeine Deutsche Direkt-bank AG sowie die Projektmitarbeiter (Administratoren) der DiBa-CA übernehmen keineForm der Gewährleistung. Alle Aufgaben werden von den Projektmitarbeitern nach bestemWissen und Gewissen durchgeführt.

Die dieser Policy zu Grunde liegenden Anforderungen an technische Komponenten und Ver-fahren zur Zertifizierung sind derzeit nicht SigG-konform. Zertifikate der DiBa-CA entspre-chen 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-Zertifi-kat), 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ätund Gültigkeit aller unterhalb der DiBa-CA erteilten Zertifikate überprüfen. Weiterhin wirddas Wurzel-Zertifikat veröffentlicht.

A.2.3 Registrierungsinstanz (RA)

Das Unternehmensnetzwerk der Allgemeinen Deutschen Direktbank AG ist derzeit räumlichauf zwei Niederlassungen aufgeteilt: Frankfurter sowie Hannover. Die Registrierungsinstanz(CA) wird ausschließlich in Frankfurt betrieben, ist aber für beide Standorte zuständig. Auf-grund der Tatsache, dass die auch für Hannover zuständige DiBa-CA weit entfernt von den zuzertifizierenden Mitarbeitern lokalisiert ist, wird vom Einsatz zweier vertrauenswürdiger Regi-strierungsinstanzen (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 Registrie-rungsaufträge anderer Benutzer vor deren Zertifizierung durch die DiBa-CA. Die DiBa-RA hateine rein organisatorische Funktion, sie darf weder das asymmetrische Schlüsselpaar für Mitar-beiter erzeugen, noch kann sie Mitarbeiter-Zertifikate erteilen oder widerrufen. Um einenMissbrauch auszuschließen, muss jede elektronische Übermittlung von Identitätsinformatio-nen des Mitarbeiters an die DiBa-CA durch die DiBa-RA digital signiert werden.

Empfängt die DiBa-CA den Zertifizierungswunsch eines Mitarbeiters durch eine vertrauens-würdige DiBa-RA, hat sie zunächst die Gültigkeit der DiBa-RA-Signatur zu verifizieren. Nachdiesem Kontakt wird das von der DiBa-CA neu ausgestellte Zertifikat an die DiBa-IS und vondieser, 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 bestimmteAnforderungen hinsichtlich der Sicherheit der eingesetzten Hard- und Software einerseitssowie dem verantwortungsvollen Umgang mit kryptographischen Schlüsseln andererseits. DieAnforderungen 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.

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 ein-gesetzt. Der Rechner befindet sich im Rechenzentrum der Allgemeinen DeutschenDirektbank AG in der Niederlassung Frankfurt. Zu dieser Zone haben nur ausge-wählte Mitarbeiter Zugang.

� Jeglicher Datenaustausch mit vernetzten Rechnern wird von Mitarbeitern derDiBa-CA per Wechselmedium vorgenommen; es findet keine automatisierte Bear-beitung der Daten statt. Sämtliche schlüsseltragenden Datenträger werden in unbe-nutztem 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 erzeugtund verwendet sowie auf externer Peripherie (Diskette bzw. Chipkarte) gespei-chert. Der Zugriff auf diese Peripherie wird durch Passworte bzw. PINs geschützt,welche nur den DiBa-CA-Mitarbeitern bekannt sind und niemals im Klartext abge-legt werden. Die Peripherie wird nicht auf anderen Rechnern eingesetzt.

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

� Asymmetrische Schlüsselpaare der DiBa-CA zur Erzeugung von Signaturen habeneine 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-Mit-arbeitern vertraulich behandelt. Die für die DiBa-CA geltenden gesetzlichenDatenschutzbestimmungen 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 Weisevor missbräuchlicher Benutzung geschützt ist.

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

� Asymmetrische Schlüsselpaare der DiBa-RA zur Erzeugung von Signaturen habeneine Länge von mindestens 2048 Bit RSA.

A.3.3 Sicherheitsanforderungen an Benutzer

Benutzer im Sinne dieser Policy sind ausschließlich einzelne Mitarbeiter der AllgemeinenDeutschen Direktbank AG.

Der geheime Schlüssel des Benutzers muss ausreichend vor Missbrauch durch Unbefugtegeschützt und darf nicht weitergegeben werden; hierfür ist jeder Benutzer selbst verantwort-lich.

Der Zugriff auf den geheimen Schlüssel wird durch nicht-triviale Passworte (Mindestlänge: 8Zeichen) bzw. einer PIN geschützt, welche nur den jeweiligen Mitarbeitern bekannt sind. Pass-wort bzw. PIN dürfen niemals an andere Personen weitergegeben oder im Klartext abgelegtbzw. ü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 von1024 Bit RSA (oder vergleichbares Niveau) aufweisen. Die Wahl größerer Schlüs-sellängen wird dringend empfohlen und richtet sich nach der technischen Verfüg-barkeit.

� Das Verzeichnis bzw. die Dateien, in dem die kryptographischen Schlüssel von derApplikation gespeichert werden, sind vom Benutzer nach Maßgabe der Möglich-keiten vor unbefugtem Missbrauch zu schützen. Dies kann z. B. durch das Setzenbestimmter Zugriffsrechte geschehen, sofern das eingesetzte Betriebssystem diesunterstützt. Die Speicherung der kryptographischen Schlüssel auf externen Daten-trägern (z. B. Diskette) wird dringend empfohlen.

Sicherheitsanforderungen an WWW-Server und VPN-Gateways

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

� Da der geheime Schlüssel üblicherweise fest auf den Server-Rechnern gespeichertist, ist der Rechner samt entsprechender Dateien und Verzeichnisse durch geeig-nete (auch physikalische) Maßnahmen vor missbräuchlicher Benutzung zu schüt-zen. Dies sollte insbesondere durch das Setzen entsprechender Zugriffsrechtegeschehen.

A.4 Zertifizierungsregeln

Dieser Abschnitt beschreibt technische und organisatorische Richtlinien und Prozeduren, dievor einer Zertifizierung von Benutzern zu beachten sind.

Sowohl Zertifizierungsinstanzen als auch Mitarbeiter werden innerhalb einer X.509-Hierar-chie mit eindeutigen Namen – sog. Distinguished Names (DNs) – bezeichnet, deren korrekterWahl 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 vergebenwird. Dabei hat die DiBa-CA bei der Zertifizierung zu gewährleisten, dass von ihr keine Seri-ennummer mehrfach vergeben wird.

Um unerlaubte Zertifizierungswünsche zu erkennen, überzeugt sich die DiBa-CA vor jederZertifizierung in geeigneter Weise durch technische und organisatorische Maßnahmen von derIdentität sowie Autorisierung desjenigen Mitarbeiters, welcher eine Zertifizierung wünscht. Inkeinem Fall werden Zertifizierungswünsche automatisiert bearbeitet.

Schlüsselpaare, welche von der DiBa-CA zertifiziert werden sollen, werden ausschließlich vonder 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 benutzereige-nen Schlüssel von der DiBa-CA zertifiziert.

Bei der Schlüsselerzeugung wird von der DiBa-CA ein Passwort für den Widerruf des Zertifi-kates (siehe Abschnitt [A.6]) für den Mitarbeiter erzeugt.

Es werden getrennte Schlüsselpaare zum Verschlüsseln und Signieren erzeugt. Schlüssel dür-fen nur für den jeweils für sie vorgesehenen Einsatzzweck verwendet werden. Für jedesSchlüsselpaar wird ein eigenes Zertifikat erzeugt. Im Zertifikat selbst ist angegeben, welcherVerwendungszweck dem jeweiligen Schlüsselpaar zugeordnet ist.

Das neu ausgestellte Zertifikat wird dem Zertifikatnehmer unmittelbar nach der Zertifizierungbeispielsweise per Email oder über eine URL übermittelt; der ebenfalls generierte privateSchlüssel und das Widerrufspasswort müssen aber persönlich übergeben werden. Der Zertifi-katnehmer ist angehalten, die Korrektheit, der im eigenen Zertifikat enthaltenen Informatio-nen, sofort zu verifizieren. Ein LAN-Administrator der DiBa nimmt anschließend dieInstallation des DiBa-CA-Zertifikates, des Benutzerzertifikates sowie des privaten Schlüsselsvor und überzeugt sich davon, dass die geforderten Sicherungsmaßnahmen des Rechners ein-gehalten sind.

Zertifikate werden in der Regel nicht automatisch durch die DiBa-CA erneuert; Anträge aufRe-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 Set-zen eines bestimmten Bits (critical flag) als besonders signifikant gekennzeichnet werden.

Zertifikat-Erweiterungen werden von der DiBa-CA bei der Zertifizierung in das Zertifikat auf-genommen. Es werden dabei nur Zertifikate nach X.509v3 erzeugt und verbreitete Standard-Erweiterungen 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 asymmetri-sches Schlüsselpaar, sondern übermitteln nur den Zertifizierungswunsch an die DiBa-RA. Vonder RA wird dieser Zertifizierungswunsch, zum Schutz digital signiert, an die DiBa-CA wei-tergeleitet; 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-CAerzeugt; wobei von der DiBa-CA die in Kapitel [A.3.1] beschriebenen Sicherheitsanforderun-gen einzuhalten sind.

Die DiBa-RA hat vor der Zertifizierung in geeigneter Weise die Eindeutigkeit folgender Infor-mationen 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 Auftragder 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 Benut-zern.

Zusätzliche Regeln für die Zertifizierung von WWW-Server und VPN-Gateways

Zusätzlich zu den oben beschriebenen Zertifizierungsregeln für Benutzer gelten besondereRichtlinien 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 Zertifizie-rungswunsch an die zertifizierende Instanz zu übermitteln. Diese hat vor der Zertifizierung ingeeigneter Weise die Eindeutigkeit folgender Informationen zu überprüfen:

� Zugehörigkeit des Servers zur Allgemeinen Deutschen Direktbank AG

� Identität des Server-Administrators

A.5 Management von Zertifikaten

Alle Teilnehmer der DiBa-Zertifizierungshierarchie erklären sich grundsätzlich mit der Veröf-fentlichung ihres Zertifikates einverstanden.

Die DiBa-IS ist für die Bereitstellung aller selbst ausgestellten Zertifikate verantwortlich. Vonder DiBa-CA neu ausgestellte Zertifikate und CRLs (siehe Abschnitt [A.6]) müssen innerhalbeiner angemessenen Zeitspanne (üblicherweise innerhalb eines Werktages) veröffentlicht wer-den.

Für die Bereitstellung von Zertifikaten werden von der DiBa-IS Informationsdienste (Ver-zeichnisse) eingerichtet (WWW- oder LDAP-Server), deren Aufgabe die öffentliche Vertei-lung von Zertifikaten und CRLs ist.

A.6 Widerruf von Zertifikaten

Die DiBa-CA kann von ihr erteilte Zertifikate jederzeit vor Ablauf der Gültigkeitsdauer ohneAngabe expliziter Gründe widerrufen. Ursachen für den Widerruf eines Zertifikates könnenbeispielsweise das Bekanntwerden missbräuchlicher Handlungen eines DiBa-CA-Administra-tors oder das Nichtbefolgen einzelner Richtlinien dieser Policy sein. Andere Gründe sind bei-spielsweise 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 auchohne Angabe von Gründen), dass diese ein für ihn ausgestelltes Zertifikat widerruft. Die DiBa-CA hat diesem Verlangen innerhalb einer angemessenen Zeitspanne nachzukommen, sobaldsie sich durch geeignete Schritte davon überzeugt hat, dass der Antrag vom Zertifikatnehmerselbst stammt bzw. von ihm autorisiert ist. Die Autorisierung kann an Hand des bei der Zertifi-zierung ausgegebenen Widerrufspasswortes erfolgen. Werden der Missbrauch oder die Kom-promittierung des eigenen geheimen Schlüssels bekannt, muss jeder Teilnehmer unverzüglichdie zuständige DiBa-RA benachrichtigen und den Widerruf des eigenen Zertifikates veranlas-sen.

Widerruf von X.509v3-Zertifikaten

Alle widerrufenen Zertifikate werden von der DiBa-CA auf einer Widerrufsliste (CertificateRevocation 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. dasDatum der CRL-Herausgabe (z. B. in Form eines Zeitstempels) und wird von der DiBa-CAdigital signiert. Widerrufene Zertifikate bleiben solange auf der CRL, bis die ursprünglicheGültigkeitsdauer überschritten wurde. Dabei werden auch solche Zertifikate auf einer CRLveröffentlicht, gegen deren Veröffentlichung bei der Zertifizierung widersprochen wurde.

Einmal widerrufene Zertifikate können nicht erneuert oder verlängert werden. Jedoch hat jederMitarbeiter 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äßigenAbständen (z. B. wöchentlich) neue CRLs herausgeben, auch wenn in der Zwischenzeit keineweiteren Zertifikate widerrufen wurden. Alte CRLs werden archiviert, um die Gültigkeit vonZertifikaten auch zu einem späteren Zeitpunkt verifizieren zu können.

Für die Bereitstellung von CRLs werden von der DiBa-CA Informationsdienste (Verzeich-nisse) 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 asymmetrischenSchlüsselpaares werden von der DiBa-CA für Widerherstellungszwecke auf sichere Weisearchiviert. Asymmetrische Schlüsselpaare, welche ausschließlich für die Erstellung von Signa-turen vorgesehen sind, betrifft diese Maßnahme nicht, da signierte Dokumente auch bei Verlustdes Signaturschlüssels weiterhin gelesen und verifiziert werden können. Aus diesem Grundwerden getrennte Zertifikate für digitale Signaturen und Verschlüsselung ausgegeben.

Alle Kopien geheimer Signaturschlüssel werden direkt nach Übergabe an den Mitarbeiter aufSeiten 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 zuge-ordnet, welcher bei der Ausstellung eines Zertifikates für einen Mitarbeiter als dessen Subjekt-name zu verwenden ist. Ein DN enthält eine Folge von eindeutig kennzeichnendenNamensattributen, durch die alle Mitarbeiter einer Hierarchie referenziert werden können. Aufunübliche Sonderzeichen innerhalb dieses Namens wird aus Gründen der Interoperabilität ver-zichtet. Die deutschen Umlautbuchstaben ä, ö, ü sowie ß werden durch die übliche Umschrei-bung ae, oe, ue sowie ss, andere akzentuierte Buchstaben durch entsprechende nicht-akzentuierte Buchstaben ersetzt (beispielsweise é durch e).

Die DNs aller Mitarbeiter unterhalb der DiBa-CA enthalten die Attribute C=DE und O=Allge-meine Deutsche Direktbank AG. Vor der Zertifizierung wird die Korrektheit und Eindeu-tigkeit des angegebenen Namens von der DiBa-CA überprüft; es darf kein Name mehrfachvergeben werden.

Der Name jedes Mitarbeiters soll folgendem Schema folgen:

C = DE,

O = Allgemeine Deutsche Direktbank AG,L = <Stadt>,

OU = <Abteilung>,CN = <Eindeutiger Name>,EMAIL = <Email-Adresse>

Alternative Namen können bei Bedarf über Zertifikat-Erweiterungen im Zertifikat aufgenom-men werden. Die DiBa-CA hat in diesem Fall vor der Zertifizierung den Inhalt dieser Erweite-rungen auf Korrektheit zu überprüfen.

Das Attribut L= ist für alle Mitarbeiter obligatorisch und kommt genau einmal vor. Es enthältden 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ältdie 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ältden vollständigen Namen des Mitarbeiters.

Das Attribut EMAIL= ist obligatorisch und enthält eine gültige, eindeutige Email-Adresse desMitarbeiters innerhalb der Domain diba.de.

Kommt ein Name innerhalb der Allgemeinen Deutschen Direktbank AG mehrmals vor, ist esdie Aufgabe der DiBa-RA, durch geeignete Namenszusätze eindeutige Namen zu wählen (eineMöglichkeit ist z. B. die innerhalb des DiBa Netzwerkes eindeutig vergebenen Login-ID). DieDiBa-RA ist ferner dafür verantwortlich, die Zugehörigkeit des Mitarbeiters zu der betreffen-den 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 besit-zen 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-Adressenenthalten.

Das optionale Attribut EMAIL= muss eine gültige Email-Adresse, beispielsweise die des Ser-ver-Administrators, enthalten.

A.9 Verschiedenes

Dieses Dokument entstand im Rahmen einer Diplomarbeit an der TU-Darmstadt. Es wirdkeine Haftung für die Korrektheit, Vollständigkeit oder Anwendbarkeit der enthaltenen Infor-mationen und der vorgeschlagenen Maßnahmen übernommen. Ferner kann keine Haftung füreventuelle Schäden, entstanden durch die Inanspruchnahme der Dienste der DiBa-CA, über-nommen werden. Die Verantwortung für die Verwendung der oben beschriebenen Verfahrenund Programme liegt allein bei den die Installation durchführenden Personen.

Die DiBa-CA behält sich vor, Zertifizierungswünschen nicht nachzukommen. Ferner kannkeine Garantie für die Verfügbarkeit der DiBa-CA-Dienste übernommen werden. Aufgrunddes Diplomarbeitsstatus besteht derzeit keine Möglichkeit, die Dienste der DiBa-CA auf einer24-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 diefür sie geltenden Datenschutzrichtlinien einhalten.

Sämtliche Zertifikatnehmer stimmen der Speicherung und Verarbeitung ihrer bei der Zertifi-zierung anfallenden Daten durch die DiBa-CA zu.

Erklärung der Teilnehmer

Alle Teilnehmer der Public Key Infrastruktur haben vor ihrer Zertifizierung handschriftlicheine Erklärung zu unterzeichnen, in der sie über ihre Rechte und Pflichten sowie über die Risi-ken 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 denRichtlinien dieser Policy.

128

Anhang B

Installationsbeschreibungen

Dieses Kapitel liefert Hinweise zur Einrichtung bestimmter Softwarekomponenten, welche fürden Betrieb der Public Key Infrastruktur notwendig sind. Neben einer Erläuterung der Konfi-guration des Internet Information Servers (IIS) sowie Hinweisen zur Installation von Wider-rufslisten in den Netscape Communicator, wird das Einrichten der MMC für eine komfortableVerwaltung von Zertifikaten unter Windows 2000 gezeigt.

Die Motivation für dieses Kapitel lieferten häufig gestellte Fragen von Beteiligten aus demUmfeld 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 denInternet Information Server 4.0 unter Windows NT SP6a mithilfe von FlexiTrust 2.0 beschrie-ben.

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 dieSoftware FlexiTrust übergeben, diese übernimmt die eigentliche Zertifizierung. Abschließendwird das von FlexiTrust signierte Serverzertifikat in den IIS-Schlüsselmanager importiert:

� Den IIS4-Schlüsselmanager hat Microsoft gut versteckt, ihn erreicht man über dieEigenschaften des SSL-Verzeichnisses, von dort aus müssen folgende Dialoge aus-gewä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 Zerti-fikates 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 eintra-gen.

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

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

� 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.0unter Windows NT SP6a1 beschrieben.

Windows NT und Windows 2000 verfügen über einen Assistenten zur Installation von Zertifi-katen, Import-Assistent für die Zertifikatsverwaltung genannt. Für die übliche Verwendung vonZertifikaten in Clientprogrammen reicht das Akzeptieren der vom Assistenten gemachten Vor-schläge aus, Zertifikate werden dann automatisch in den richtigen Speicher der Registry desBenutzers importiert. Der Internet Information Server allerdings verlangt CA-Zertifikate imentsprechenden Speicher direkt auf dem lokalen Computer.

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

� Auf der zweiten Seite bei der Frage nach dem gewünschten Zertifikatsspeicher,Alle Zertifikate in folgendem Speicher speichern auswählen und auf Durchsuchenklicken. 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 Physikali-schen Speicher anzeigen aktivieren und Vertrauenswürdige Stammzertifizierungs-stellen1 ö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 wer-den.

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 „Zwischenzertifizierungss-tellen“ zu öffnen.

131


Security sollte nach der Installation des Root-CA Zertifikates nun auch die neue Root-CA demIIS als vertrauenswürdiger Zertifikatsaussteller für Client-Zertifikate bekannt sein. SieheAbbildung 14. Nur Client-Zertifikate von den IIS-bekannten Zertifikatsausstellern sind für cli-entseitige SSL-Authentifizierung zugelassen. Wurde der Assistent nicht korrekt ausgeführt,beispielsweise der Zertifikatsspeicher automatisch - und damit falsch - gewählt, kann eineSSL-Verbindung über den IIS nur mit Server-Zertifikaten abgesichert werden. Client-Zertifi-kate weist dieser dann kommentarlos (ohne weitere Fehlermeldung) als unsicher ab, da ihm -im Gegensatz zum Webbrowser des Clients - der Zertifikatsaussteller unbekannt ist. Der Dia-log zur Auswahl des für die SSL Verbindung zu nutzenden Client-Zertifikates im Webbrowserbleibt dann leer. Selbst wenn gültige Clientzertifikate vorhanden sind, welche im Webbrowserdes 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 derVorgang 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 diePunkte Clientzertifikate verlangen sowie Client-Zertifikatszuordnungen aktivierenanschalten.

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

� Im Regelfenster unter Herausgeber den Punkt Ausgewählte Zertifikatsausstelleraktivieren und auf Auswählen klicken.

132

Anhang B: Installationsbeschreibungen

� Der Dialog Instanzen für Clientzertifikate (siehe Abbildung 3) listet alle dem IISbekannten, vertrauten Zertifikataussteller auf, darunter sollte sich nun auch derAussteller des zuvor installierten CA-Zertifikates befinden. Die Testregel kannanschließend wieder gelöscht werden.

B.3 Installation von Widerrufslisten (CRLs) im Netscape Communicator

Im Folgenden wird die Installation von X.509v1-CRLs über HTTP-Server in den NetscapeCommunicator 7.x beschrieben. X.509v2-CRLs werden nicht unterstützt.

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

� Mit dem Aufrufen der URL der Widerrufsliste wird diese automatisch, ohne wei-tere Nachfrage heruntergeladen und ebenso automatisch ohne Meldung installiert.

� Über den Menüpunkt Communicator / Tools / Security Info steht nach erfolgreicherInstallation der ersten CRL im Bereich Signers die Schaltfläche View/Edit CRL’szur 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 beschrie-ben.

� Der Aufruf der Microsoft Management Console (MMC) erfolgt über Start / Aus-fü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 verwal-tet 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 SyntaxStandard)

PKCS#10 Public Key Cryptography Standard #10 (Certification Request SyntaxStandard)

PKCS#11 Public Key Cryptography Standard #11 (Cryptographic Token InterfaceStandard)

PKCS#12 Public Key Cryptography Standard #12 (Personal Information ExchangeSyntax 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, Algo-rithmen und Sourcecode in C, Addison-Wesley 1996.

[BrSchn98-1] BRUCE SCHNEIER, MUDGE, Cryptanalysis of Microsoft’s Point-to-Point 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 Ver-fahren und Komponenten nach SigG/SigV - Zertifikate, 1998.

[CHR00] HEISE, Bürgerrechtler: Studie sollte FBI-Schnüffel-Tool "rein-waschen", <URL: http://www.heise.de/newsticker/data/chr-23.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 Ham-burg, 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>, Universi-tät Hamburg, 1999.

[DFN00-1] INGMAR CAMPHAUSEN, STEFAN KELM, BRITTA LIEDTKE, LARS WEBER, DFN-Bericht Nr. 89 - Aufbau und Betrieb einer Zertifi-zierungsinstanz, <URL: ftp://ftp.pca.dfn.de/pub/docs/PCA/DFN-PCA/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 Interoper-ability 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 Anwend-barkeit bestehender Gesetze auf das Internet, im Zeitalter der Infor-mationsgesellschaft, <URL: http://www.laga.at/Dissertation/Diss.html>, Wien 1998.

[GnuPG00] GNU PRIVACY GUARD, The GNU Privacy Guard Handbook (Ger-man) - 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, WOLF-GANG 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-char-ter.html>, 2001.

[IETF-2] IETF WORKING GROUP, S/MIME Mail Security (smime) , <URL: http://www.ietf.cnri.reston.va.us/html.charters/smime-char-ter.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 Infra-structure, 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 Secu-rity, <URL: http://www.ietf.org/proceedings/99mar/I-D/draft-ietf-ipsec-pki-req-01.txt>, 1998.

141


[IN96] INDIVIDUAL NETWORK E.V. , FAQ: Die Policy der Individual Net-work Zertifikationshierarchie, <URL: http://www.in-ca.indivi-dual.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 Informa-tion Group 1998.

[JoBuch99-1] JOHANNES BUCHMANN, MARKUS RUPPERT, MARKUS TAK, Flex-iPKI - Realisierung einer flexiblen, Public-Key-Infrastuktur, Tech-nical Report No. TI-22/99, TU Darmstadt 1999.

[JoBuch99-2] JOHANNES BUCHMANN, MARKUS MAURER, Wie sicher ist die Pub-lic-Key-Kryptographie? Technical Report No. TI-2/99, TU Darm-stadt 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 - Kryptogra-phische 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 Ver-schlüsselung, Hanser Verlag 2000.

[KlimaRosa01] VLASTIMIL KLÍMA, TOMÁŠ ROSA, Attack on Private Signature Keys, of the OpenPGP format, PGP programs and other applica-tions, 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;EN-US;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/cert-serv/>, Microsoft Corporation 2000.

[MS00-2] MICROSOFT KNOWLEDGE BASE, How to Configure Certificate Server for Use with SSL on IIS (Q218445), <URL: http://sup-port.microsoft.com/default.aspx?scid=kb;EN-US;q218445>, Microsoft Corporation 2000.

[MS00-3] MICROSOFT, Microsoft Windows 2000 Netwerkinfrastruktur-Admin-istration - Original Microsoft Training, Microsoft Press Deutsch-land 2000.

[MS00-4] MICROSOFT, Microsoft Windows 2000 Server - Die technische Ref-erenz: TCP/IP-Netzwerke. Microsoft Press Deutschland 2000.

[MS00-5] MICROSOFT, Microsoft Windows 2000 Server - Die technische Ref-erenz: Verteilte Systeme, Microsoft Press Deutschland 2000.

[MS00-6] MICROSOFT, Microsoft Windows 2000 Server - Die technische Ref-erenz: Internetworking, Microsoft Press Deutschland 2000.

[MS00-7] MICROSOFT, Microsoft Windows 2000 Server - Die technische Ref-erenz: 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.micro-soft.com/technet/itsolutions/network/deploy/depovg/vpnde-ply.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 Karls-ruhe, 1999.

[NS98-1] NETSCAPE DEVEDGE, Introduction to SSL, <URL: http://devel-oper.netscape.com/docs/manuals/security/sslin/index.htm>, Nets-cape 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 Exten-sions, <URL: http://developer.netscape.com/docs/manuals/cms/41/dep_gide/ext.htm>, Netscape Communications Corporation 1999.

[OLDAP01] OPENLDAP FOUNDATION, OpenLDAP - open source implementa-tion 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/uni-tel/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, Bekanntma-chung 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 DES-CBC 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 Net-work Information Service, <URL: http://sunsite.iisc.ernet.in/collec-tion/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 Han-dling, <URL: ftp://ftp.ietf.org/rfc/rfc2632.txt>, 1999.

[RFC2633] B. RAMSDELL, RFC 2633 - S/MIME Version 3 Message Specifica-tion, <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/pkcs-12/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/pkcs-10v1_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/pkcs-11/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, (Signatur-verordnung - 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 Sig-natur, <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 Form-vorschriften des Privatrechts und anderer Vorschriften an den mod-ernen 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 Pub-lic-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.tu-harburg.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/thema20000718-2012.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 Con-trols for Conventional Arms and Dual-Use Goods and Technolo-gies, <URL: http://www.wassenaar.org/docs/index1.html>, 2000.

[WoKopp98] WOLFGANG KOPP, Rechtsfragen der Kryptographie und der digi-talen Signatur, <URL: http://www.wolfgang-kopp.de/krypto.pdf>, Universität München, 1998.

147


148

Documents

Konzept und Aufbau einer prototypischen Public Key ... · PDF fileTagen noch keinen Besuch bekommen hat, ... Konzept und Aufbau einer prototypischen Public Key Infrastruktur auf Basis