Entwurf und Strategie der Einführung einer fachbereichsweiten

Transcription

Fachhochschule Wiesbaden
Fachbereich Design Informatik Medien
Studiengang Allgemeine Informatik
Diplomarbeit
zur Erlangung des akademischen Grades
Diplom-Informatiker (FH)
Entwurf und Strategie der
Einführung einer fachbereichsweiten
Public Key Infrastruktur
vorgelegt von:
Hans-Georg Winkler
am:
22.06.06
Referent:
Prof. Dr. Gergeleit
Koreferent:
Prof. Dr. Kröger
II
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, daß ich die vorliegende Diplomarbeit selbständig und nur unter Verwendung der angegebenen Hilfsmittel und Literaturquellen verfaßt habe.
Ort, Datum
Unterschrift Diplomand
Erklärung zur Verbreitungsform
Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten
Verbreitungsformen dieser Diplomarbeit:
Verbreitungsform
ja
nein
Einstellung der Arbeit in die Bibliothek der FHW X
Veröffentlichung des Titels der Arbeit im Internet
X
Veröffentlichung der Arbeit im Internet
X
Ort, Datum
Unterschrift Diplomand
III
IV
Vorwort
Die hier vorliegende Arbeit wurde am Fachbereich Design Informatik Medien
(DCSM) der Fachhochschule Wiesbaden geschrieben und ist im Rahmen der
Überlegungen zur Einführung einer fachbereichweiten Public Key Infrastruktur
die erste Arbeit in diese Richtung. Dabei werden in diesem Dokument Ansätze
entwickelt und eine erste praktische Anwendung zur Umsetzung gebracht.
Danksagung
Mein Dank gilt an erster Stelle Jesus Christus der mich mit Gott versöhnt
und mir ein neuen Leben geschenkt hat. Ohne Ihn und seine Führung wäre ich
nicht sehr weit gekommen. Dank auch an meine Eltern die mir dieses Studium
ermöglicht und mich dazu ermutigt haben. Weiter möchte ich mich bei meinen beiden betreuenden Professoren Herrn Dr.Gergeleit und Herrn Dr.Kröger
für die Unterstützung und Zeit bedanken die sie mir zur Verfügung gestellt
haben. Das Diplomarbeitsthema hat mir bei der Bearbeitung ganz neue Perspektiven, auch für meinen weiteren Werdegang aufgezeigt. Vielen Dank für die
Unterstützung bei technischen Fragen an die Labor-Ingenieure Carlos Henriques dos Santos, Daniel Kloos und Bent Ahrens. Bedanken möchte ich mich in
ganz besonderer Weise bei den Entwicklern von OpenCA und der Open-SourceCommunity. In diesem Zusammenhang möchte ich mich auch bei Oliver Welter
bedanken der mir in den Anfängerproblemen bei OpenCA und schwierigeren
Fragestellungen mit viel Geduld weiter geholfen hat. Auch möchte ich mich bei
den Mitgliedern der Mailinglist von OpenCA bedanken, da hier, bei schwierigeren Problemen schnell geholfen wurde. Bedanken möchte ich mich bei meiner
Schwester Franziska, meinen Cousins Leonhard und Sebastian Boitz, weiter
danke ich Rainer Schölles, Karsten Berthold und Heinrich Hintenberger. All
denn eben genannten sei nochmals mein Dank für ihre Zeit und Mühen ausgesprochen, meine Diplomarbeit gegen gelesen zu haben, um diese von den vielen
Rechtschreibfehler und umgangssprachlichen Floskeln zu reinigen. Des Weite-
V
ren noch einmal vielen Dank an Heinrich Hintenberger und ”JoHi Webservices”
für das Drucken dieser Diplomarbeit. Weiter möchte ich mich bei den Professoren des Fachbereichs bedanken. Die Zeit meines Studiums war zwar schwer
und oft war ich gefordert jedoch konnte ich in dieser Zeit sehr viel Neues lernen. Vielen Dank!
Abschließend möchte ich mich bei den Entwicklern von LATEX für dieses System
und die geniale Integration in Mac OS X bedanken. Ohne diese Entwicklung
wäre meine Diplomarbeit in dieser Form nicht möglich gewesen.
Vielen Dank an alle :)
Mainz der 21. Juni 2006
Hans-Georg Winkler, [email protected]
VI
Inhaltsverzeichnis
1. Einleitung
1
1.1. Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2. Kapitel Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2. Grundlagen
5
2.1. Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2. Eigenschaften von Schlüsseln . . . . . . . . . . . . . . . . . . . .
7
2.3. Symmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . 10
2.4. Asymmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . 12
2.5. Hybridverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6. Einführung digitaler Signaturen . . . . . . . . . . . . . . . . . . 17
2.7. Einführung digitaler Zertifikate und der PKI . . . . . . . . . . . 20
2.8. Grundlagen und Begriffserklärung zur PKI . . . . . . . . . . . . 21
2.8.1. Zertifizierungsstelle - CA . . . . . . . . . . . . . . . . . . 23
2.8.2. PKI zugelassene Anwendungen - PKA . . . . . . . . . . 25
2.8.3. Persönliche Sicherheitsumgebung - PSE . . . . . . . . . . 26
2.9. Prozesse innerhalb der PKI . . . . . . . . . . . . . . . . . . . . 26
2.9.1. Erstellung von Zertifikaten . . . . . . . . . . . . . . . . . 26
2.9.2. Verifizieren von Zertifikaten . . . . . . . . . . . . . . . . 28
2.9.3. Signieren . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9.4. Verschlüsseln . . . . . . . . . . . . . . . . . . . . . . . . 32
2.10. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VII
3. Analyse
35
3.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.1. Teilnehmer der Zertifizierungsinfrastruktur . . . . . . . . 37
3.1.2. Oberste Zertifizierungsstelle (PCA) . . . . . . . . . . . . 38
3.1.3. Zertifizierungsstellen (CA) . . . . . . . . . . . . . . . . . 39
3.1.4. Registrierungsstellen (RA) . . . . . . . . . . . . . . . . . 40
3.1.5. Zertifikatnehmer - CP . . . . . . . . . . . . . . . . . . . 41
3.1.6. Zertifikatantragprüfer - CP
. . . . . . . . . . . . . . . . 42
3.1.7. Weitere Teilnehmer - CP . . . . . . . . . . . . . . . . . . 42
3.2. Anwendungsbereich - CP . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1. Geeignete Zertifikatnutzung . . . . . . . . . . . . . . . . 43
3.2.2. Untersagte Zertifikatnutzung . . . . . . . . . . . . . . . . 43
3.3. Verwaltung der Richtlinien - CP . . . . . . . . . . . . . . . . . . 44
3.4. Veröffentlichungen und Verzeichnisdienst . . . . . . . . . . . . . 44
3.4.1. Veröffentlichung von Informationen . . . . . . . . . . . . 44
3.4.2. Aktualisierung der Informationen . . . . . . . . . . . . . 46
3.4.3. Zugang zu den Informationsdiensten . . . . . . . . . . . 46
3.5. Identifizierung und Authentifizierung . . . . . . . . . . . . . . . 47
3.5.1. Namen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.2. Identitätsüberprüfung bei Neuantrag - CP . . . . . . . . 51
3.5.3. Authentifizierung einer natürlichen Person . . . . . . . . 52
3.5.4. Identifizierung und Authentifizierung bei einer Zertifikaterneuerung - CP . . . . . . . . . . . . . . . . . . . . . . 53
3.5.5. Identifizierung und Authentifizierung bei einem Widerruf 53
3.6. Ablauforganisation . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.6.1. Ablauf der Zertifizierung . . . . . . . . . . . . . . . . . . 55
3.6.2. Zertifikatantrag . . . . . . . . . . . . . . . . . . . . . . . 58
3.6.3. Bearbeitung von Zertifikatanträgen - CP . . . . . . . . . 60
3.6.4. Zertifikatausstellung . . . . . . . . . . . . . . . . . . . . 61
3.6.5. Zertifikatakzeptanz . . . . . . . . . . . . . . . . . . . . . 61
VIII
3.6.6. Verwendung des Schlüsselpaares und des Zertifikats - CP 62
3.6.7. Zertifikaterneuerung / Re-Zertifizierung - CP . . . . . . 63
3.6.8. Zertifikaterneuerung / Re-Key - CP . . . . . . . . . . . . 65
3.6.9. Zertifikatmodifizierung - CP . . . . . . . . . . . . . . . . 66
3.6.10. Widerruf und Suspendierung von Zertifikaten . . . . . . 66
3.6.11. Gründe für einen Widerruf - CP . . . . . . . . . . . . . . 67
3.6.12. Wer kann widerrufen - CP . . . . . . . . . . . . . . . . . 67
3.6.13. Beendigung des Vertragsverhältnisses durch den Zertifikatnehmer - CP . . . . . . . . . . . . . . . . . . . . . . . 68
3.7. Infrastrukturelle, organisatorische und personelle Sicherheitsmaßnahmen - CPS . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.7.1. Infrastrukturelle Sicherheitsmaßnahmen
. . . . . . . . . 69
3.7.2. Organisatorische Sicherheitsmaßnahmen . . . . . . . . . 70
3.7.3. Personelle Sicherheitsmaßnahmen . . . . . . . . . . . . . 74
3.7.4. Kompromittierung und Wiederherstellung . . . . . . . . 75
3.7.5. Reguläre Einstellung des Betriebs . . . . . . . . . . . . . 76
3.8. Technische Sicherheitsmaßnahmen - CPS . . . . . . . . . . . . . 77
3.8.1. Schlüsselerzeugung und Installation . . . . . . . . . . . . 77
3.8.2. Schutz des privaten Schlüssels . . . . . . . . . . . . . . . 78
3.8.3. Weitere Aspekte des Schlüsselmanagements . . . . . . . 79
3.9. Konformitätsprüfung - CP . . . . . . . . . . . . . . . . . . . . . 80
3.10. Rahmenvorschriften - CP . . . . . . . . . . . . . . . . . . . . . . 81
4. Praktische Umsetzung
83
4.1. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2. Eigenschaften von OpenCA . . . . . . . . . . . . . . . . . . . . 84
4.2.1. Funktionsübersicht . . . . . . . . . . . . . . . . . . . . . 84
4.2.2. Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . 85
4.2.3. Aufbau von OpenCA . . . . . . . . . . . . . . . . . . . . 86
IX
4.3. Planung einer Zertifizierungsstelle . . . . . . . . . . . . . . . . . 89
4.3.1. Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.2. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4.1. Configure . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4.2. make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4.3. Die config.xml-Datei . . . . . . . . . . . . . . . . . . . . 101
4.4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 102
4.5. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.5.1. CSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.5.2. PKCS#10 Requests . . . . . . . . . . . . . . . . . . . . . 107
4.5.3. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.5.4. Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . 109
4.5.5. Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . 111
4.5.6. Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.5.7. LOA (Level of Assurance) . . . . . . . . . . . . . . . . . 113
4.6. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.6.1. Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . 116
4.6.2. OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.6.3. OpenCA . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.6.4. Anpassungen . . . . . . . . . . . . . . . . . . . . . . . . 120
4.7. Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.7.1. Vorbemerkung . . . . . . . . . . . . . . . . . . . . . . . . 125
4.7.2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.7.3. Datenimport
. . . . . . . . . . . . . . . . . . . . . . . . 126
4.7.4. Quickimport . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.7.5. Konfiguration der Import-/Export-Funktion . . . . . . . 128
4.7.6. Durchführen des Batch-Prozesses . . . . . . . . . . . . . 129
4.7.7. Automatische Generierung des Batch-Import . . . . . . . 130
4.8. Benachrichtigung der Nutzer . . . . . . . . . . . . . . . . . . . . 132
X
4.8.1. Probleme mit der PIN . . . . . . . . . . . . . . . . . . . 132
4.8.2. Probleme mit der CRIN . . . . . . . . . . . . . . . . . . 133
4.8.3. E-Mail Benachrichtigung . . . . . . . . . . . . . . . . . . 135
4.9. Shell Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.9.1. Datenaustausch zwischen verschiedenen Ebenen der Zertifizierungsstelle . . . . . . . . . . . . . . . . . . . . . . . 136
4.9.2. Automatisierung der Erstellung eines Batch-Imports zur
automatischen Erstellung neuer Studentenzertifikate . . . 137
4.9.3. Automatische Verarbeitung der durch den Batch-Prozess
erstellten PKCS#12-Dateien . . . . . . . . . . . . . . . . 138
4.9.4. CSR Handhabung . . . . . . . . . . . . . . . . . . . . . . 139
4.10. Anwendungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . 142
4.10.1. Erstinitialisierung der CA . . . . . . . . . . . . . . . . . 142
4.10.2. Erstinitialisierung der RA . . . . . . . . . . . . . . . . . 145
4.10.3. Datenaustausch CA zu RA . . . . . . . . . . . . . . . . . 145
4.10.4. Reguläre Zertifikatbeantragung . . . . . . . . . . . . . . 148
4.10.5. Sperren von Zertifikaten . . . . . . . . . . . . . . . . . . 156
4.10.6. Verlängern von Zertifikaten . . . . . . . . . . . . . . . . 158
5. Erfahrungen mit Client Software
165
5.1. Mozilla (Thunderbird) . . . . . . . . . . . . . . . . . . . . . . . 166
5.1.1. Adressbuch . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.1.2. Import/Export von Zertifikaten und CRLs . . . . . . . . 167
5.2. KMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.2.1. Adressbuch . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.3. Microsoft Outlook Express . . . . . . . . . . . . . . . . . . . . . 174
XI
6. Zusammenfassung und Ausblick
179
6.1. Entwicklung von OpenCA . . . . . . . . . . . . . . . . . . . . . 181
A. Technischer Anhang
183
A.1. config.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
A.1.1. Generelle Einstellungen . . . . . . . . . . . . . . . . . . . 183
A.1.2. Webserver Konfiguration . . . . . . . . . . . . . . . . . . 185
A.1.3. LDAP-Server Konfiguration . . . . . . . . . . . . . . . . 186
A.1.4. Datenbank Konfiguration . . . . . . . . . . . . . . . . . . 187
A.1.5. Module Konfiguration . . . . . . . . . . . . . . . . . . . 189
A.1.6. Konfiguration der relativen und absoluten Pfade . . . . . 189
A.1.7. Datenaustausch Konfiguration . . . . . . . . . . . . . . . 190
A.2. Anpassung Apache . . . . . . . . . . . . . . . . . . . . . . . . . 191
A.2.1. Symbolische Links . . . . . . . . . . . . . . . . . . . . . 191
A.2.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
A.3. Wichtige Konfigurationsdateien . . . . . . . . . . . . . . . . . . 193
A.4. OpenCA Konfiguration . . . . . . . . . . . . . . . . . . . . . . . 194
A.4.1. Zusätzliche Attribute bei CSRs . . . . . . . . . . . . . . 194
A.4.2. Channel verification
. . . . . . . . . . . . . . . . . . . . 195
A.4.3. Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
A.4.4. ACLs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
A.4.5. Datenaustausch Konfiguration . . . . . . . . . . . . . . . 198
A.5. LDAP Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . 200
A.5.1. OpenCA-Teil . . . . . . . . . . . . . . . . . . . . . . . . 200
A.5.2. LDAP Teil . . . . . . . . . . . . . . . . . . . . . . . . . . 201
A.6. Batchimport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
A.6.1. Batch-System Import New User Format . . . . . . . . . 203
A.6.2. Batch-System Import New Process Format . . . . . . . . 204
A.6.3. Batch-System Import New Process Format . . . . . . . . 204
A.7. Batch Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
XII
A.7.1. Anpassen des Batch-Prozessors . . . . . . . . . . . . . . 206
B. Organisatorischer Anhang
211
B.1. Inhalt der DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
B.2. Inbetriebnahme des Prototypen . . . . . . . . . . . . . . . . . . 211
B.2.1. Verzeichnisstruktur . . . . . . . . . . . . . . . . . . . . . 213
B.2.2. Vergebene Passwörter . . . . . . . . . . . . . . . . . . . . 214
B.3. Benutzeranleitung OpenCA . . . . . . . . . . . . . . . . . . . . 214
B.3.1. PUB Interface . . . . . . . . . . . . . . . . . . . . . . . . 215
B.3.2. RA-Interface
. . . . . . . . . . . . . . . . . . . . . . . . 220
B.3.3. CA-Interface . . . . . . . . . . . . . . . . . . . . . . . . . 223
B.3.4. NODE-Interface . . . . . . . . . . . . . . . . . . . . . . . 225
B.3.5. LDAP-Interface . . . . . . . . . . . . . . . . . . . . . . . 229
B.3.6. Handhabung der Zertifikate . . . . . . . . . . . . . . . . 231
B.4. Erstinitialisierung der CA . . . . . . . . . . . . . . . . . . . . . 233
B.4.1. Erstellen des ersten Administrators . . . . . . . . . . . . 233
B.4.2. Erstellen des ersten RA-Zertifikates . . . . . . . . . . . . 234
Abbildungsverzeichnis
236
Tabellenverzeichnis
239
Listings
241
Abkürzungsverzeichnis
245
Literaturverzeichnis
250
Internetquellen
253
Index
255
XIII
1. Einleitung
Heute, am Anfang des 21sten Jahrhunderts, besteht in den Industrienationen
eine fast flächendeckende IT-Vernetzung mit Internet-Anbindung. Immer mehr
kritische Daten werden in Computer-Netzen wie dem Internet übertragen, verarbeitet und gespeichert. Parallel zu dieser Entwicklung nimmt das Internet
im Alltag vieler Menschen eine immer wichtiger Rolle ein. Hierbei zeigt eine
aktuelle Studie der ”Arbeitsgemeinschaft Online Forschung”1 zur Internetbenutzung innerhalb Deutschlands, dass 57,8 Prozent der Deutschen ab 14 Jahren das Internet regelmäßig nutzen. Dies entspricht einer Zahl von ca. 37,51
Millionen Nutzern in Deutschland [AGO06]. Durch die wachsende Nutzung
des Internet wird das Thema der E-Security, der sicheren Übertragung und
Speicherung von Daten, ein immer wichtigeres Thema im Umgang mit dem
Medium Internet. Dabei stützen sich viele Strategien in diesem Gebiet auf
einen effizienten Einsatz kryptographischer Verfahren. In diesem Zusammenhang steht auch die hier vorgelegte Diplomarbeit. Darin geht es in erster Linie
um das Thema der Gewährleistung sicheren Datenübertragung. Der Schlüssel
hierzu ist die Public-/Private-Key Kryptographie. Dabei stellt das darauf basierende Konzept der Public Key Infrastruktur, kurz als PKI bezeichnet, die
eigentliche Herausforderung und den Fokus dieser Arbeit dar. In diesem Zusammenhang sollen die auftretenden Fragen nach den angewandten Technologien, Verfahren, Konzepten und Regelungen näher betrachtet und ausgewertet
werden, um am Ende auch praktische Lösungsansätze bieten zu können. Im
1
http://www.agof.de/
1
1.1. Ziel der Arbeit
Kapitel 1. Einleitung
Folgenden wird in diesem Kapitel kurz auf die Ziele dieser Arbeit eingegangen,
um anschließend eine Übersicht für den inhaltlichen Rahmen aufzuzeigen.
1.1. Ziel der Arbeit
Gegenstand der Diplomarbeit ist die Analyse und Umsetzung einer Public Key
Infrastruktur für den Fachbereich Design-Infomatik-Medien (DCSM) mit Blick
auf eine Erweiterung für die gesamte Fachhochschule Wiesbaden. Es sollen zunächst die zugrunde liegenden Techniken in der Theorie betrachtet und auf
Basis dieser Informationen anschließend die Analyse anhand der RFC 3647
[OSSIVCGL+ 03] erarbeitet werden, worin die PKI in ihrem Aufbau und Regelungen näher erläutert wird. Schwerpunktmäßig sollen, für die spätere praktische Umsetzung, brauchbare Vorschläge und Empfehlungen sowie mögliche
Lösungskonzepte für den Aufbau einer effektiven Infrastruktur geliefert werden. Dabei wird die Analyse den möglichen Aufbau einer fachbereichsweiten
PKI betrachten. Die daraus gewonnenen Erfahrungen werden anschließend im
praktischen Teil dieser Arbeit ausgewertet und in die Errichtung eines funktionsfähige Prototypen einer Zertifizierungsstelle mit einfließen.
1.2. Kapitel Übersicht
In diesem Abschnitt wird ein Überblick über die Inhalte der nachfolgenden
Kapitel gegeben.
In Kapitel 2 wird dem Leser ein grundlegender Einstieg in das Thema gegeben
und Grundwissen vermittelt, auf das in den späteren Kapiteln aufgebaut wird.
Dabei wird die Notwendigkeit der Einführung einer Public Key Infrastruktur
aufgezeigt.
Kapitel 3 beschäftigt sich mit der Analyse einer möglichen Umsetzung. Hierbei
wird als Grundlage die RFC 3647 verwendet, welche als eine Empfehlung und
Regelwerk für die Umsetzung eine PKI gesehen werden kann.
2
Kapitel 1. Einleitung
1.2. Kapitel Übersicht
Kapitel 4 beschäftigt sich mit der praktischen Umsetzung der in der Analyse gemachten Aussagen. Dabei geht es um die Planung und Einrichtung eines
Prototypen für eine Zertifizierungsstelle. Besondere Aufmerksamkeit wurde auf
die detailgenaue Darstellung von Vorgehensweisen und Anpassungen gelegt um
ein späteres Nachvollziehen für Außenstehende so einfach wie möglich zu halten.
Kapitel 5 gibt einen Überblick über mögliche Anwendungsszenarien um die
Einbindung der PKI in bestehende Applikationen zu prüfen.
Kapitel 6 fasst die gewonnenen Erfahrungen zusammen und gibt einen Ausblick auf die weitere Entwicklung.
Der Anhang gliedert sich in die drei Teile technischer-, organisatorischer- und
sonstiger-Anhang. Im technischen Anhang werden wichtige zusätzliche Detailinformationen zur Konfiguration des Prototypen geliefert. Im organisatorischen
Anhang befindet sich eine Auflistung der auf der DVD enthaltenen Dateien,
eine Anleitung zur Inbetriebnahme der virtuellen Maschinen sowie weitere Details zum Umgang mit den Interfaces des Prototypen. Im sonstigen Anhang ist
ein Abbildungs- und Abkürzungsverzeichnis sowie eine Tabellen- und Listingübersicht aufgeführt. Zwei getrennte Verzeichnisse für Bücher und Internetquellen sowie ein Index befinden sich ganz am Ende dieses Dokumentes.
3
4
2. Grundlagen
Dieses Kapitel gibt eine Einführung in die Thematik und Hintergrundinformationen. Dabei wird sich nicht mit der komplexen Mathematik beschäftigt, die
sich hinter jedem Verschlüsselungsalgorithmus verbirgt. Vielmehr wird auf die
Grundsätze und -bausteine sowie Funktionsweisen und Zusammenhänge der
Kryptographie eingegangen.
2.1. Situation
Was ist Kryptographie? Kryptographie (aus dem griechischen kryptós, ”verborgen”, und gráphein, ”schreiben”) ist ”die Wissenschaft der Ver- und Entschlüsselung von Informationen zum Zweck der Geheimhaltung gegenüber Dritten”
[Cla03].Damit macht sie es möglich, die Aufbewahrung von Information in einer Form zu gewährleisten, die es erlaubt, diese Information nur denjenigen zu
offenbaren, die sie erfahren sollen, während sie für alle anderen unerreichbar
bleibt [URL1]. Dabei verfolgt die moderne Kryptographie wesentlich die im
Folgenden angeführten vier Hauptziele [NDJB02], die in ihren Aussagen den
Schutzzielen der Computersicherheit sehr ähneln [Cla03].
• Vertraulichkeit der Nachricht:
Nur der gewünschte Empfänger soll in der Lage sein, den Inhalt einer
verschlüsselten Nachricht zu lesen. Weiterhin soll es nicht möglich sein,
Information über den Nachrichteninhalt zu erlangen1 .
1
Beispielsweise eine statistische Verteilung bestimmter Zeichen.
5
2.1. Situation
Kapitel 2. Grundlagen
• Datenintegrität der Nachricht:
Der Empfänger soll in der Lage sein, festzustellen ob die Nachricht bei
ihrer Übertragung verändert wurde.
• Authentifizierung:
Der Empfänger soll den Absender eindeutig identifizieren können. Weiterhin soll überprüfbar sein, ob die Nachricht tatsächlich von diesem
Absender stammt.
• Verbindlichkeit:
Der Absender soll nicht in der Lage sein, zu bestreiten dass er die Nachricht gesendet hat.
Kryptographie wandelt Klartext in Chiffretext2 um. Dabei bleibt dem Nutzer die Möglichkeit erhalten, den ursprünglichen Klartext aus dem Chiffretext wieder herzustellen. Diese Wiederherstellung ist jedoch nur durch den
Besitz eines gemeinsamen ”Geheimnisses” zwischen Sender und Empfänger
möglich [Bra02]. Heutzutage gibt es für die Verschlüsselung von Informationen zwei wesentliche kryptographische Verfahren, das symmetrische und das
asymmetrische. Beide besitzen individuelle Stärken und Schwächen. Aus diesem Grund benutzen alle modernen kryptographischen Systeme beide Typen,
um die Nachteile des einen Verfahrens durch die Vorteile des anderen zu kompensieren. Im Folgenden wird die symmetrische und asymmetrische Verschlüsselung näher betrachtet, des Weiteren wird auf Hybridmethoden eingegangen.
Diese Überlegungen sollen im Ganzen zu der Notwendigkeit der Einführung
einer Public Key Infrastruktur (kurz PKI) hinführen.
2
Der Verschlüsselte Klartext.
6
2.2. Eigenschaften von Schlüsseln
Bevor auf die eigentlichen kryptographischen Verfahren eingegangen wird, soll
der Schlüssel, der den wesentlichen Bestandteil bei einer Verschlüsselung darstellt, einer näheren Betrachtung unterzogen werden. Dabei soll der folgende
Abschnitt zur Erklärung dienen [BP01].
Eine Verschlüsselung nimmt Klartext und erzeugt mit Hilfe eines kryptographischen Schlüssels eine verschlüsselte Version des Klartextes, den Chiffretext.
Dabei ist der kryptographische Schlüssel vergleichbar einem physikalischen
Schlüssel, z.B. einem Haustürschlüssel. Dieser besitzt gewisse Eigenschaften
die ihn als ”Haustürschlüssel” einzigartig machen. Das sind z.B. die Form des
Schlüssels, die Art der Fräsung der Rillen oder seine Länge. Dabei kann es sein,
dass der Schlüssel in verschiedene Schlösser passt. Aber nur in einem kann auch
geschlossen und geöffnet werden. Kryptographische Schlüssel ähneln in vielerlei Hinsicht ihren physikalischen Vorbildern. So müssen die Schlüssel für die
Verwendung mit einem kryptographischen Algorithmus z.B. die richtige Länge besitzen. Man kann den Algorithmus mit den verschiedensten Schlüsseln
füttern, ähnlich dem Probieren von physischen Schlüsseln in einem Haustürschloss. Doch nur der Schlüssel mit dem richtigen Bitmuster bringt das gewünschte Ergebnis der Entschlüsselung des Geheimnisses.
Der erste Punkt, der die Güte eines Schlüssels ausmacht, ist die Wahl eines
guten Zufallszahlengenerators. Grund dafür ist die Erzeugung der symmetrische wie asymmetrische kryptographische Schlüssel, die auf Basis einer Quelle
von Zufälligkeit generiert werden. Bei der symmetrischen Verschlüsselung ist
dies die Wahl einer Zufallszahl der richtigen Länge, bei der asymmetrischen
Schlüsslgenerierung ist dieser Vorgang ungleich komplexer, da zwei Schlüssel
erzeugt werden müssen. Jedoch ist auch hier eine ”gute” Quelle der Zufälligkeit
Voraussetzung für die Schlüsselgenerierung. Dabei versteht man unter ”gut”,
dass in den gewählten Zufallszahlen nicht irgendein Muster nachgewiesen werden kann, nach welchem die Zahlen ausgewählt wurden.
7
Soll nun ein solcher kryptographischer Schlüssel geknackt werden, ist das in
etwa damit zu vergleichen, einen Schlüssel für ein physisches Schloss ohne die
Kenntnis des inneren Aufbaus herzustellen. Ist diese Information nicht verfügbar, bleibt nichts anderes übrig, als eine Unzahl verschiedener Schlüssel
herzustellen, um sie in dem fraglichen Schloss auszuprobieren. Ähnlich ist die
Herangehensweise bei kryptographischen Schlüsseln. Allerdings übersteigt dort
die Anzahl der möglichen Variationen, je nach verwendeter Schlüssellänge, die
eines physischen Schlüssels bei weitem. Bei solch einem Versuch3 muss, statistisch gesehen, die Hälfte aller möglichen Schlüssel innerhalb des Schlüsselraums
durchprobiert werden, um den richtigen Schlüssel zu ermitteln. Je länger dieser Schlüssel ist um so mehr vergrößert sich der Schlüsselraum und damit die
Anzahl der möglichen Kombinationen die durchprobiert werden müssen. Deshalb ist die verwendete Schlüssellänge auch von entscheidender Bedeutung für
die Güte des Schlüssels. Die Länge muss so gewählt werden, dass selbst das
Durchprobieren der Hälfte aller möglichen Schlüssel für einen Angreifer unpraktikabel wäre [NDJB02].
Eine weiterer wichtiger Punkt in der Frage nach der Sicherheit eines Schlüssels ist die Wahl des kryptographischen Algorithmus. Dabei kann dieser Punkt
nicht pauschal beantwortet werden, da die Ergebnisse, je nachdem in welcher
Kombination Schlüssellängen und Algorithmen verwendet werden, stark variieren können. Der folgende tabellarische Überblick 2.1 verdeutlicht dies. In
dieser Tabelle [URL2] werden verschiedener Schlüssellängen in Bezug zu den
verwendeten kryptographischen Algorithmen gesetzt. Dabei werden verwendete Schlüssellängen symmetrischer Algorithmen zwei asymmetrischen Verfahren
(dem ECC und RSA) gegenübergestellt4 .
In dieser Tabelle aus dem Jahr 2000 wird davon ausgegangen, dass für die Beschaffung von Computerhardware $10 Millionen zur Verfügung stehen und ein
3
4
Zum Beispiel ein Brute-Force-Angriff.
RSA Laboratorien Bulletin Nr.13 http://www.rsasecurity.com
8
Sym Key
ECC Key
RSA Key
Zeit zur Mani-
Rechner Speicher
pulation
56 bit
112 bit
430 bit
weniger als 5 Mi-
105
Trivial
nuten
80 bit
160 bit
760 bit
600 Monate
4300
4GB
96 bit
192 bit
1020 bit
3 Millionen Jah-
114
170GB
0,16
120TB
re
128 bit
256 bit
1620 bit
1016 Jahre
Tabelle 2.1.: Schlüssellängen im Vergleich zur Sicherheit
Megabyte Speicher jeweils $0,5 kostet. Diese Hardware wiederum soll für den
Brute-Force-Angriff auf entsprechende Schlüssellängen und kryptographische
Algorithmen eingesetzt werden. Wie man in Zeile vier sieht, können bei symmetrischer Verschlüsselung und einer Schlüssellänge von 128 bit mit $10 Millionen nur 16% der benötigten Rechnerkapazität erbracht werden. Hochgerechnet
würden bei einer Verfügbarkeit von 100% trotzdem 100.000.000.000.000.000
Jahre (100 Billiarden) zum Knacken des Schlüssels benötigt werden. Mit anderen Worten: Eine Verschlüsselung bei einer symmetrischen Schlüssellänge
von 128 Bit und einer asymmetrischen Schlüssellänge jenseits der 1024 bit
ist zur Zeit unknackbar. Ähnlich verhält sich dies für eine Schlüssellänge von
96/1020 Bit für symmetrische/asymmetrische Verschlüsselung, wobei im besten Fall immer noch 3.000.000 Jahre darauf verwendet werden müssten, um
zum Ziel zu gelangen. Alle anderen Schlüssellängen sollten für heutige sicherheitsrelevante Anwendungen nicht mehr in Betracht gezogen werden, da diese
in einem überschaubaren Zeitraum mit entsprechenden technischen Aufwand
geknackt werden können.
9
2.3. Symmetrische Verschlüsselung
Symmetrische Algorithmen existieren in zwei verschiedenen Typen. Zum einen
als Block- und zum anderen als Datenstromalgorithmen. Blockalgorithmen verschlüsseln ihre Daten in kleinen Blöcken fester Länge, die typischerweise meist
eine Länge von 8 oder 16 Byte haben. Die bekanntesten Vertreter sind Digital Encryption Standard (DES)5 , RC2, RC5 und RC6 (RC = Ron’s Code).
Datenstromalgorithmen werden im Gegensatz zu Blockalgorithmen nicht auf
Datenblöcke fester, sondern auf solche beliebiger Länge angewandt. Zu den bekanntesten Vertretern dieser Art gehört unter anderen der RC4-Algorithmus.
Steht ein symmetrischer Algorithmus sowie ein gemeinsamer Schlüssel zur Verfügung, ist der Vorgang der Ver- und Entschlüsselung in der Abbildung 2.1
einfach zu erklären.
Geheimnis
symmetrische
Verschlüsselung
Geheimnis
(verschlüsselt)
symmetrischer
Schlüssel
Abbildung 2.1.: Vorgang der symmetrischen Verschlüsselung
Der Klartext wird mit Hilfe eines Schlüssels symmetrisch verschlüsselt, wobei sich dieser Vorgang mit dem gleichen Schlüssel und Algorithmus jederzeit
wieder umkehren lässt. Dieses Konzept besteht schon seit einiger Zeit6 . Dabei
sind heutzutage verwendeten symmetrischen Algorithmen sicher und vor allem schnell. Weiterhin erzeugen symmetrischen Algorithmen einen kompakten
5
6
Erweitert auf 3-DES.
Schon Caesar benutzte zur Verschlüsselung wichtiger Botschaften, einen eigens von ihm
entworfenen Algorithmus, der auch als ”Caesar-Chiffre” [URL3] in die Geschichte eingegangen ist.
10
Chiffretext, was bedeutet das die verschlüsselte Nachricht in etwa die gleiche
Größe aufweist wie das Original. Diese Eigenschaft wiederum ermöglicht die
Verschlüsselung großer Datenmengen in relativer kurzer Zeit. Deswegen eignen
sich symmetrischen Algorithmen besonders für die sichere Übertragung einer
hohen Anzahl von Daten. Jedoch gibt es ein schwerwiegendes Problem: Ein
Einbrecher darf auf keinen Fall in den Besitz des symmetrischen Schlüssels
gelangen. Diese Gefahr ist vor allem dann gegeben, wenn der Schlüssel für die
Entschlüsselung über ein unsicheres Medium zum Ziel übertragen wird. Des
Weiteren gibt es das Problem der Schlüsselverteilung innerhalb einer Gruppe.
Gäbe es z.B. in einer Gruppe 10 Mitglieder, so müsste jeder der Gruppenmitglieder jeweils den symmetrischem Schlüssel des anderen besitzen. Das heißt,
jeder müsste 9 Schlüssel zur Ver- und Entschlüsselung verwenden. Das sind
10x(10-1) Schlüssel für eine Gruppe von 10 Mitgliedern. Dabei steigt der Bedarf an Schlüsseln ca. dem Quadrat der Anzahl der Mitglieder der Gruppe.
Daraus ergibt sich ein komplexes, unüberschaubares und dadurch nicht tragbares Schlüsselmanagement [NDJB02].
Einerseits sind also die symmetrischen Algorithmen zur Verschlüsselung großer
Datenmengen gut geeignet, andererseits ist die Schlüsselverwaltung und Übermittlung als äußerst sicherheitskritisch zu betrachten. Folglich müsste man bei
einer symmetrischen Verschlüsselung den Schlüssel nur einmal verwenden, was
wiederum das Schlüsselmanagement um ein Vielfaches verkomplizieren würde.
Im Folgenden sollen nun noch einmal kurz die eben besprochenen Vor und
Nachteile aufgezeigt werden [NDJB02]:
Vorteile
• schnell
• sicher
• die verschlüsselten Daten sind im Vergleich zum Original in etwa genau
so groß
Nachteile
11
2.4. Asymmetrische Verschlüsselung
• gleicher Schlüssel für Ver- und Entschlüsselung
• komplexes Schlüssel-Management
• sichere Übertragung des gemeinsamen Schlüssels notwendig
Die asymmetrischen Algorithmen unterscheiden sich von den symmetrischen
Algorithmen in einem wichtigen Punkt. Asymmetrische Verfahren verwenden
für die Ver- und Entschlüsselung zwei Schlüssel die gleichzeitig generiert werden jedoch unabhängig voneinander existieren (je nach Verwendung zur Verbzw. Entschlüsselung). Dabei gelten für die Güte einer asymmetrische Verschlüsselung die gleichen Kriterien wie auch für die symmetrische, dass z.B.
eine gute Quelle der Zufälligkeit verwendet wird. Bei symmetrischen Verfahren wird der Schlüssel durch eine Zufallszahl fester Länge generiert. Bei der
asymmetrischen Schlüsselgenerierung ist dieser Vorgang komplexer, da zwei
Schlüssel generiert werden. Auch hier stellt eine Quelle guter Zufälligkeiten
die Basis für eine sichere Schlüsselgenerierung dar [BP01].
Einer der bekanntesten und erfolgreichsten asymmetrischen Verschlüsselungsalgorithmen ist der RSA-Algorithmus. Dieser wird typischerweise mit einer
Schlüssellänge von 1024 Bit eingesetzt, was in etwa der Sicherheit einer symmetrischen Verschlüsselung von 128 Bit entspricht. Wie man sieht ist also für
die Erreichung eines etwa gleichen Sicherheitsniveaus wie bei einer symmetrischen Verschlüsselung im Allgemeinen ein längerer Schlüssel erforderlich7 . Die
zwei generierten Schlüssel sind völlig unabhängig voneinander, jedoch mathematisch verwandt [NDJB02]. Ist der Prozess der Schlüsselgenerierung abgeschlossen, stehen zwei Schlüssel zur Verfügung: öffentlicher Schlüssel (Public
Key) und persönlicher Schlüssel (Private Key). Der öffentliche Schlüssel muss
für alle zugänglich sein, der persönliche Schlüssel unter Verschluss gehalten
7
Siehe Abschnitt 2.2 ”Eigenschaften von Schlüsseln”.
12
werden. Soll nun eine Nachricht verschlüsselt werden kommt es zu folgenden
Ablauf in Abbildung 2.2:
Geheimnis
Öffentlicher
Schlüssel
Bob
Alice
asymmetrische
Verschlüsselung
Geheimnis
asymmetrische
Verschlüsselung
Privater
Schlüssel
Geheimnis
Geheimnis
(verschlüsselt)
(verschlüsselt)
Abbildung 2.2.: Vorgang der asymmetrische Verschlüsselung
In diesem Szenario verschlüsselt Bob mit Hilfe des öffentlichen Schlüssels von
Alice eine wichtige Nachricht, die nur Alice lesen darf8 . Nach der Verschlüsselung der Nachricht ist einzig Alice dazu fähig, mithilfe ihres privaten Schlüssels
die Nachricht von Bob wieder zu entschlüsseln. Soweit ist dieses System sicher,
doch ergibt sich bei näherer Betrachtung ein Problem. Für einen Angreifer ist
es unter Verwendung des öffentlichen Schlüssels möglich, Alice eine Nachricht
mit verändertem Inhalt, im Namen von Bob zu senden. Damit ist die Integrität
und Authentizität der Nachricht nicht mehr gewährleistet. Aus diesem Grund
wird ein Verfahren erforderlich, mit dem sich die Authentizität der Nachricht
überprüfen lässt.
8
Anmerkung: Alice und Bob sind Synonyme für typische Personen, die verwendet werden,
um Erklärungen auf den Gebieten der Kryptographie zu vereinfachen.
13
Durch die Natur der asymmetrischen Verschlüsselung (mit ”public” verschlüsseln mit ”private” entschlüsseln) besteht kein Problem des Schlüsselmanagements, welches unter der symmetrischen Verschlüsselung auftritt. Jeder Teilnehmer einer Gruppe muss nur seinen öffentlichen Schlüssel zentral veröffentlichen. Daraus resultiert, dass eine Gruppe von 10 Personen jeweils nur 10
statt 90 Schlüssel austauschen muss. Dadurch wird der Aufwand des Schlüsselmanagements wesentlich vereinfacht. Da für den Absender nur die Kenntnis
des öffentlichen Schlüssels nötig ist, der von einer für alle zugänglichen Stelle
bezogen werden kann, ist es ohne weiteres möglich, ohne vorherigen Kontakt
oder Schlüsselaustausch zwischen zwei Personen einen verschlüsselten Kontakt
aufzubauen. Jedoch sind der asymmetrischen Verschlüsselung auch Grenzen
gesetzt. Zum einen ist dies eine vergleichsweise langsame Verschlüsselung (ca.
10 bis 100mal langsamer als vergleichbare symmetrische Verfahren), welche
die asymmetrischen Verfahren für die Verschlüsselung großer Datenmengen
unbrauchbar macht. Zum anderen ist es eine Eigenschaft asymmetrischer Verschlüsselung, dass die verschlüsselte Datenmenge ungleich größer ist als das
unverschlüsselte Original. Wie man sieht, gibt es auch bei den asymmetrischen Verfahren entscheidende Vor- und Nachteile, die sich folgendermaßen
zusammenfassen lassen [Cla03]:
Vorteile
• keine Übertragung von geheimen Schlüsseln nötig
• sicher
• keine direkte Kontaktaufnahme notwendig
• geringe Anzahl von Schlüsseln beim Schlüsselmanagement, dadurch vergleichsweise geringer Aufwand.
Nachteile
• langsam
• verschlüsselte Nachricht größer als das Original
14
2.5. Hybridverfahren
In den letzten beiden Abschnitten wurden die symmetrischen sowie asymmetrischen Verschlüsselungsverfahren mit ihren Eigenschaften betrachtet. In diesem
Abschnitt sollen die Hybridverfahren vorgestellt werden.
Vergleicht man die Listen der oben genannten Vor- und Nachteile, kann man
etwas Interessantes feststellen. In jedem Bereich, in dem das eine Verfahren
seine Stärken hat, hat das andere Verfahren seine Schwächen. Daraus ergibt
sich die einzigartige Möglichkeit einer Kombination beider Technologien. Dabei kommen auf den ersten Blick folgende neue Eigenschaften zum Tragen
[NDJB02]:
• die Lösung ist sicher
• die Verschlüsselung ist schnell
• die verschlüsselten Daten sind kompakt
• die Lösung lässt sich auf eine große Gruppe anwenden
• es gibt keine unsichere Übertragung von Schlüsseln
• eine vorherige Kontaktaufnahme ist nicht nötig
Die nachstehende Abbildung 2.3 stellt die Funktionsweise von Hybridverfahren
dar.
Der Vorgang der Übertragung des Geheimnisses von Bob zu Alice beginnt
mit der symmetrischen Verschlüsselung des Geheimnisses durch einen zufällig genierten Schlüssel, der nur für die Ver- und Entschlüsselung dieser einen
Nachricht verwendet wird (auch Session Key genannt). Danach wird dieser
Schlüssel mit dem öffentlichen Schlüssel von Alice über einen asymmetrischen
Algorithmus verschlüsselt, so dass nur Alice zur Reproduktion in der Lage ist,
da sie den dazugehörigen privaten Schlüssel besitzt. Anschließend werden nun
15
Geheimnis
1.1
symmetrische
Verschlüsselung
1.3
Geheimnis
(verschlüsselt)
1.2
3.1
Zufälliger
Sym. Schlüssel
Bob
Nachricht
3.2
2.2
Öffentlicher
Schlüssel
Geheimnis
2.1
3.3
asymmetrische
Verschlüsselung
symmetrische
Verschlüsselung
2.3
Sym. Schlüssel
(verschlüsselt)
3.1
Geheimnis
(verschlüsselt)
3.2
1.1
entschlüsselter
Sym. Schlüssel
Alice
Nachricht
2.3
Privater
Schlüssel
2.2
asymmetrische
Verschlüsselung
1.2
2.1
Sym. Schlüssel
(verschlüsselt)
Abbildung 2.3.: Vorgang der Hybriden Verschlüsselung
die beiden verschlüsselten Teile9 zusammen an Alice verschickt. Diese packt
die beiden Teile‚ aus und entschlüsselt mithilfe ihres privaten Schlüssels den
Session Key10 . Ist dieser entschlüsselt, kann über diesen die Nachricht in Klartext zurückgewandelt werden. Anschließend wird der symmetrische Schlüssel
9
10
Das symmetrisch verschlüsselte Geheimnis und der asymmetrisch verschlüsselte symmetrische Schlüssel.
Der gemeinsame symmetrische Schlüssel zum Ver- und Entschlüsseln der Nachricht.
16
2.6. Einführung digitaler Signaturen
verworfen, da dieser nicht mehr gebraucht wird. Durch diese Kombination
der Verfahren ergibt sich folgende Arbeitsteilung innerhalb der Hybridverfahren: Die symmetrische Verschlüsselung bringt Geschwindigkeit und kompakte
Daten, die asymmetrische sorgt für Skalierbarkeit des Schlüsselmanagements
sowie Widerstandsfähigkeit gegen Angriffe auf die Schlüssel. Darüber hinaus
erweitert die Verwendung der asymmetrischen Verschlüsselung die Hybridverfahren um die Möglichkeit der digitalen Signaturen und damit der Nichtabstreitbarkeit einer Verschlüsselung11 [PB04].
Soweit ist dieses Verfahren äußerst effektiv und skalierbar. Der symmetrische
Schlüssel ist geschützt und eine vorherige Kontaktaufnahme ist nicht nötig,
da der öffentliche Schlüssel von einer öffentlichen Stelle bezogen werden kann.
Jedoch wurde ein entscheidender Nachteil der asymmetrischen Verschlüsselung
an die Hybridverfahren vererbt. Weiterhin besteht die Möglichkeit für einen
Angreifer, den Prozess, den Bob für die Verschlüsselung des Geheimnisses vollzieht, auch für die Verschlüsselung einer falschen Nachricht nachzuvollziehen.
Fängt der Angreifer dann anschließend die Nachricht ab, die Bob an Alice
schickt, kann er seine eigene verfälschte Nachricht an Alice weiterleiten, ohne
dass diese die Manipulation feststellen kann. Um solch eine Art von Manipulation zu verhindern, muss eine neue Art von Sicherung eingeführt werden. Diese
Sicherung wird über das Verfahren der digitalen Signatur umgesetzt.
Bevor auf das Verfahren der digitaler Signatur näher eingegangen werden kann,
muss an dieser Stelle ein Einschub zum Thema Hashing stattfinden.
Hashing: Das Hash-Verfahren ist entscheidend für den Einsatz digitaler Signaturen und soll an dieser Stelle kurz etwas genauer beleuchtet werden, um das
Verständnis für dessen Einsatz innerhalb von digitalen Signaturen zu erleich11
Siehe Abschnitt 2.6 ”Einführung digitaler Signaturen”.
17
tern. Ein Hashalgorithmus nimmt einen großen Datenblock und komprimiert
diesen in den so genannten Fingerabdruck12 . Dieser Fingerabdruck hat die
Eigenschaft, dass er absolut eindeutig ist. Das heißt, jeder durch einen Hash
komprimierte Datenblock besitzt einen eigenen Fingerabdruck. Dieser ändert
sich, sobald auch nur ein Bit das Datenblocks verändert wurde. Weiterhin ist
ein Hashalgorithmus eine mathematische Einwegfunktion. Es ist also unmöglich, durch Umkehrung der Hashfunktion den Klartext oder Rückschlüsse auf
die ursprüngliche Art des Inhaltes zu ermitteln [PB04]. Verwendet wird dieses Verfahren z.B. auch, um Klartext-Passwörter in einer Konfigurationsdatei
zu verschlüsseln. Bekannteste Vertreter dieses Verfahrens sind u.a. der SHA1(secure Hash Algorithm) oder der MD5- Algorithmus (Message Digest Algorithm).
Digitale Signaturen sind das digitale Gegenstück für analoge Unterschriften
auf Papier. Ihr Einsatz hat zum Ziel, das oben beschriebene Problem des Unterschiebens falscher Informationen durch Dritte zu verhindern13 . Bevor nun
auf das Verfahren der digitalen Signatur eingegangen wird, soll Abbildung 2.3
die Anschaulichkeit des Prozesses verdeutlichen.
Wie man in dieser Abbildung sehen kann, wird mit der Hybridverschlüsselung zunächst die Nachricht für andere unlesbar gemacht. Danach beginnt erst
der eigentliche Vorgang der Signierung. Als Erstes wird aus der ursprüngliche
Nachricht durch einen Hashalgorithmus ein Fingerabdruck erzeugt. Dieser Fingerabdruck ist, wie der Name schon andeutet, eine eindeutige Prüfsumme, die
nur mit der unveränderten Nachricht in Kombination mit dem Hashalgorithmus erzeugt werden kann. Wenn sich also nur ein Bit der Nachricht ändert,
ändert sich auch die durch den Hash erzeugte Prüfsumme. Diese Prüfsumme wird nun mit dem privaten Schlüssel von Bob verschlüsselt und an die
Nachricht angehängt. Somit ist die Signatur abgeschlossen. Nachdem Alice die
12
13
Fingerprint oder auch Digest genannt.
Anmerkung: Aus der Sicht des Autors sind digitale Unterschriften bei richtiger Umsetzung
und Anwendung ungleich schwieriger zu manipulieren als eine analoge Unterschrift.
18
Geheimnis
1.1
Hybrid
Verschlüsselung
Privater
Schlüssel
von Bob
Hash
2.2
Geheimnis
Nachricht
Bob
2.1
Digest
(Prüfsumme)
1.2
4
3.2
3.1
1.2
asymmetrische
Verschlüsselung
Hybrid
Verschlüsselung
3.3
Digest
(verschlüsselt)
1.1
Nachricht
2.1
Alice
3.1
Digest
(verschlüsselt)
2.2
Hash
Öffentlicher
Schlüssel
von Bob
3.2
2.3
asymmetrische
Verschlüsselung
2.4
Aktueller
Digest
4.1
=?
4.2
entschlüsselter
Digest
Abbildung 2.4.: Vorgang der digitalen Signierung
Nachricht empfangen hat, trennt sie diese in den verschlüsselten Nutzteil und
die Signatur14 auf und entschlüsselt als Erstes mit Hilfe des Hybridverfahrens
die Nachricht von Bob. Um nun sicherzugehen, dass diese Nachricht nicht unterwegs verändert wurde, erzeugt sich Alice durch die Verwendung desselben
Hashalgorithmus wie Bob eine aktuelle Prüfsumme aus der entschlüsselten
Nachricht. Ist dieser Vorgang abgeschlossen, nimmt Alice die von Bob mit sei14
Die mit dem privaten Schlüssel von Bob verschlüsselte Prüfsumme.
19
2.7. Einführung digitaler Zertifikate und der PKI
nem privaten Schlüssel verschlüsselte Prüfsumme und entschlüsselt diese mit
dem öffentlich verfügbaren Schlüssel von Bob. Nach diesem Vorgang besitzt
Alice zwei Prüfsummen. Die aktuell selbst erzeugte und die durch Bob erzeugte Prüfsumme. Vergleicht Alice diese Prüfsummen, bekommt sie zwei mögliche
Situationen. Erstens, die Prüfsummen sind gleich: dies bedeutet, die Nachricht
ist unverändert. Zweitens, die Prüfsummen sind ungleich: es muss von einer
Manipulation ausgegangen werden.
Soweit ist dieses System ”wasserdicht”. Bis auf eine kleine Schwachstelle, die es
möglich macht, das System zu unterwandern. Diese Schwachstelle ist der öffentliche Schlüssel. Ist es einem Angreifer möglich, auf dem Server einzudringen,
auf dem z.B. die öffentlichen Schlüssel einer ganzen Gruppe abgelegt sind, ist es
möglich, diese durch eigene öffentliche Schlüssel zu ersetzen. Ist dies gelungen,
kann der Angreifer seine eigenen Nachrichten als die von Bob ausgeben und
so den gesamten verschlüsselten Datenverkehr manipulieren [NDJB02]. Diese
offensichtliche Schwachstelle macht es nötig, einen zusätzlichen Mechanismus
einzuführen, um die Integrität der öffentlichen Schlüssel zu gewährleisten. An
diesem Punkt kommt die Technik der digitalen Zertifikate zum Tragen.
2.7. Einführung digitaler Zertifikate und der PKI
Das digitale Zertifikat stellt eine Verknüpfung zwischen einer Identität und einem Schlüsselpaar her. Mit anderen Worten besagt ein digitales Zertifikat im
einfachsten Falle nichts anderes, als ”dass garantiert wird, dass dieser öffentliche Schlüssel der des Nutzers XY ist!” [NDJB02] In der simpelsten Form listet
dabei das Zertifikat den Besitzer auf und enthält zusätzlich dessen öffentlichen
Schlüssel.
Das Ganze wiederum macht keinen Sinn, wenn die Zertifikate nicht Verwaltet
werden, da so kein Vertrauen aufgebaut werden kann. Vertrauen aber stellt
die Basis für sichere Kommunikation dar. Der Begriff ”Vertrauen” wird in der
2000er Version von X.509 [URL4] folgendermaßen definiert: ”Im Allgemeinen
20
2.8. Grundlagen und Begriffserklärung zur PKI
kann man davon ausgehen, dass ein Teilnehmer einem anderen Teilnehmer
vertraut, wenn der erste Teilnehmer annimmt, das sich der zweite Teilnehmer
genauso verhalten wird, wie der erste Teilnehmer es erwartet”15 [NDJB02].
Um dieses Vetrauen zu gewährleisten, muss es zentrale, für alle Teilnehmer
vertrauenswürdige Instanzen geben, die die Zertifikate signieren, um ihre Unverfälschtheit garantieren zu können. Weiterhin müssen diese Zertifikate von
dieser Stelle auch verwaltet und deren Integrität garantiert werden. Die Notwendigkeit der Verwaltung und der Aufbau gewisser Vertrauensketten zieht
nun die Einführung einer effektiven Architektur nach sich. Diese Architektur
wurde in dem Standard X.509 (der Network Working Group) für die Form von
digitalen Zertifikaten konkretisiert [RLNVC02].
X.509 wurde erstmals im Jahre 1988 veröffentlicht. Dabei stand im Zusammenhang mit dessen anfänglicher Entwicklung die Verbindung mit dem X.500Standard16 . Diese Anlehnung schlug sich am Ende in einem strikten hierarchischen System nieder, in dem vertrauenswürdige Zertifizierungsstellen die ihnen
anvertrauten Zertifikate verwalten. Diese Infrastruktur auf Basis der X.509
Zertifikate wird auch als Public Key Infrastruktur, oder kurz PKI, bezeichnet.
Wenn im Folgenden die Begriffe PKI oder Public Key Infrastruktur verwendet
werden, ist damit immer die gleiche Infrastruktur auf Basis des X.509 Standards gemeint. Dieser Standard und die damit implementierbare Infrastruktur
soll im folgenden Abschnitt in ihren Grundbausteinen näher betrachtet werden.
Mit dem X.509 Standard werden Zertifikatformate, -felder, Verteilungsprozesse
und Vorschriften zur Verteilung der Zertifikate beschrieben [BP01]. Um diese Zertifikate zu verwalten, kommt das Konzept der PKI zum Tragen. Dabei
15
16
ITU-T Empfehlung X.509
Beschreibt den Aufbau eines Verzeichnisdienstes [URL5].
21
ist die primäre Rolle der Implementierung einer PKI der Aufbau von digital
vertrauenswürdigen Identitäten. Das Problem der Erzeugung einer vertrauenswürdigen Identität besteht nun in der Tatsache, eine Instanz zu finden, die eine
ausreichende Vertrauenswürdigkeit für eine Gruppe von Nutzern aufweist, um
Identitäten zu bestätigen. Diese Aufgabe übernimmt in der richtigen Welt z.B.
eine Behörde, um etwa einer natürlichen Person einen Ausweis auszustellen,
der sie als Staatsangehörigen eines bestimmten Landes mit Namen, Adresse,
Geburtstag usw. ausweist. In der digitalen Welt übernimmt diese Rolle die
Zertifizierungsstelle (Certification Authority oder CA). Diese ist innerhalb einer PKI die vertrauenswürdige Autorität, die digitale Identitäten ausstellt.
Basis dafür ist ein absolutes Vertrauen der Nutzer auf die Integrität der Zertifizierungsstelle. Ohne dieses Vertrauen ist das ganze Konzept hinfällig! Das
Schaubild 2.5 gibt einen Überblick über die Prozesse und Interaktionen innerhalb einer PKI [PB04].
Bei zertifikatsbasierten Systemen, wie einer PKI, erhält jeder Benutzer ein digitales Zertifikat, welches seine Identität bestätigt und den öffentlichen Schlüssel
enthält. Jedes dieser Zertifikate ist von einer ausgebenden Zertifizierungsstelle
beglaubigt, die ihrerseits wieder von höheren Stellen autorisiert sein kann. Dabei ist das Vertrauenssystem streng hierarchisch aufgebaut. Die gemeinsame
Vertrauensbasis bildet hierbei das so genannte Wurzelzertifikat (Root Certificate), dass von jeder Zertifizierungsstelle extra veröffentlicht wird. Durch dieses
Wurzelzertifikat wird es möglich, die durch die Zertifizierungsstelle veröffentlichten Zertifikate auf ihre Integrität zu prüfen. Bevor nun weiter die einzelnen
Prozesse innerhalb einer PKI besprochen werden, soll an dieser Stelle auf die
einzelnen Komponenten näher eingegangen werden.
22
Antrag
genehmigt
SignaturServer
CA
Signierung
Veröffentlichung
RA
Public
Zertifikatspeicher
Zertifizierungsantrag von Alice
Zertifizierungsantrag von Bob
Bob
Zertifikate
Anfragen
PSE
Gültigkeit der
Zertifikate prüfen
SecurityMechanismus
Applikation z.B.
E-Mail-Client
Alice
PSE
SecurityMechanismus
Kommunikation
Applikation z.B.
E-Mail-Client
PKA
PKA
Abbildung 2.5.: Grundlegender Aufbau einer PKI
2.8.1. Zertifizierungsstelle - CA
Die CA (Certification Authority) besteht aus mehreren untergeordneten Komponenten oder Diensten, die in den folgenden Abschnitten besprochen werden.
Dabei vergibt die CA eindeutige Identitäten und verwaltet für jeden Teilnehmer ein oder mehrere Zertifikate. Jedes durch die CA erzeugte Zertifikat verbindet den öffentlichen Schlüssel des Teilnehmers mit dessen Namen und wei-
23
teren Daten, wie Gültigkeitsdatum und Seriennummer. Durch die Verwaltung
der Zertifikate können die öffentlichen Attribute der Teilnehmer, wie Position,
Namen, Rechte usw. einfach verifiziert werden. Darüber hinaus legt die CA
Prozeduren, Richtlinien und Regeln innerhalb ihres Geltungsbereichs fest, mit
deren Hilfe Nutzer und Antragsteller sichergehen können, dass die durch die
CA ausgestellten Identitäten für das angestrebte Sicherheitsniveau ausreichend
sind. Diese Regeln werden in der sogenannten Certification Policy (CP) und
dem dazugehörigen Certification Practice Statement (CPS) festgelegt. Nähere
Informationen dazu liefert das Kapitel 3 ”Analyse”.
Registrierungsstelle - RA
Die RA (Registration Authority) bildet die Schnittstelle zwischen den Teilnehmern bzw. Antragstellern und der CA, an die sie die Anträge weiterleitet. Dabei kann die Aufgabe der RA von einem menschlichen Operator erfüllt werden.
Hauptaufgabe ist es, die Anträge auf Zertifizierung zu erfassen, die Identität
der Antragsteller entsprechend den eigenen Richtlinien zu prüfen sowie anschließend die Anträge anhand der Richtlinien abzulehnen oder anzunehmen.
Wird ein Antrag angenommen, wird dieser zum digitalen Unterschreiben an
die entsprechende Stelle der CA weitergeleitet.
Zertifizierungsserver
Der Zertifizierungsserver ist die Komponente, die innerhalb der CA für die
Herausgabe von Zertifikaten auf Basis der durch die RA erhobenen Daten
zuständig ist. Hier wird der öffentliche Schlüssel des Antragstellers von der
CA digital signiert.
Zertifikatsspeicher
Ausgestellte Zertifikate müssen, bevor sie benutzt werden, von der CA veröffentlicht werden. Hierfür stehen verschiedene Möglichkeiten zur Verfügung.
Zum einen können die Zertifikate in einer internen Datenbank abgelegt und
24
über ein Webinterface veröffentlicht werden. Zum anderen kann die Verwaltung
einer CA einen eigenen Directory Service betreiben. Hier werden die als gültig
zertifizierten öffentlichen Schlüssel der Teilnehmer über einen LDAP-Zugriff
(Lightweight Directory Access Protocol) durch entsprechende Applikationen,
die dies unterstützen (wie z.B. E-Mail und Adressprogramme), zum Abruf bereitgehalten. Es können auch zurückgezogene oder gesperrte Schlüssel in einer
Sperrliste veröffentlicht werden.
Public Interface
Unter einem Public Interface versteht man eine zentrale Instanz innerhalb
einer CA, die dem Nutzer alle nötigen Informationen zur Nutzung der PKI zur
Verfügung stellt. Dabei werden über das Public Interface nicht nur Zertifikate
veröffentlicht. Weiter können darüber die CP und CPS sowie die das RootZertifikat der CA herausgegeben werden. Günstig erscheint auch, über diese
Schnittstelle das Beantragen und Sperren von Zertifikaten abzuwickeln. Die
Einsatzmöglichkeiten sind vielfältig und ändern sich je nach Einsatzgebiet der
CA.
2.8.2. PKI zugelassene Anwendungen - PKA
Als PKA (PKI-enabled Application) wird eine Anwendung bezeichnet, die auf
der Grundlage der von der PKI zur Verfügung gestellten Dienste (Zertifikate, LDAP etc.) eine entsprechende vertrauenswürdige Nutzung ermöglicht17 .
Dabei bildet eine PKI die Sicherheitsgrundlage für die vertrauenswürdige Nutzung von Anwendungen wie z.B.
• E-Mail
• Dokumentenverschlüsselung
• Transaktionen im Bankbereich
17
Beispiel für eine PKA ist z.B. ein SSL-fähiger Browser.
25
2.9. Prozesse innerhalb der PKI
• SSL (Secure Sockets Layer) Kommunikation
• VPN (Virtual Private Network) Kommunikation
• Identifikation und Authentisierungsprozesse
2.8.3. Persönliche Sicherheitsumgebung - PSE
PSE (Personal Security Environment) ist in der realen Welt mit einem großen
Schlüsselbund vergleichbar. In der digitalen Welt ist dies die Ansammlung
aller sicherheitsrelevanten Daten eines Teilnehmers der PKI. Dazu gehören
unter anderen private Schlüssel, Zertifikate der Kommunikationspartner und
die öffentlichen Schlüssel der CA18 .
In diesem Abschnitt sollen die grundlegenden Prozesse, die die Funktionsweise
einer PKI ausmachen, näher betrachtet werden. Dazu gehören u.a. Erstellung
und Abgleich von Zertifikaten sowie Signieren und Verschlüsseln von Nachrichten auf Basis der, von der PKI zur Verfügung gestellten Dienste.
2.9.1. Erstellung von Zertifikaten
Den ersten Schritt in diesem Szenario unternimmt der Nutzer, indem er sich
selbst ein Schlüsselpaar generiert. Ist dies geschehen, erzeugt er sich einen digitalen Antrag (Certification Request CSR), in dem notwendige Informationen
für die RA sowie der eigene öffentliche Schlüssel abgelegt werden. Dieser Antrag wird an die RA der Zertifizierungsstelle geschickt, durch die zertifiziert
werden soll. Nach Erhalt dieses Antrages prüft die RA die Angaben im Antrag
auf Richtigkeit. Sind diese Angaben nach den festgelegten Regeln der CA verifiziert, wird der Antrag an den Zertifizierungsserver weitergereicht, der diesen
18
Ein Beispiel für die Anwendung wäre z.B. der Keystore eines Browsers oder der Schlüsselbund unter Mac OS X.
26
digital signiert. Dadurch wird nach der Signierung durch den Zertifizierungsserver aus dem Antrag ein Zertifikat. Im Folgenden sollen die Schritte der
Signierung eines Antrages genauer erläutert werden.
1. Der Zertifizierungsserver nimmt das nicht unterschriebene Zertifikat, also
den Antrag, und generiert daraus mit einer Hashfunktion eine eindeutige
kryptographische Prüfsumme.
2. Anschließend wird diese kryptographische Prüfsumme mit dem privaten
Schlüssel der CA verschlüsselt.
3. Um das Zertifikat zu unterschreiben, wird die oben verschlüsselte Prüfsumme im Antrag hinterlegt. Damit wird aus dem Antrag ein Zertifikat
Das Zertifikat enthält nach der Signierung folgende Basisinformationen:
1. die Kennung der Zertifizierungsstelle, die das Zertifikat erstellt hat,
2. die Kennung des Nutzers, für den das Zertifikat erstellt wurde,
3. seinen öffentlichen Schlüssel,
4. die Gültigkeitsdauer des Zertifikats.
Nachstehende Abbildung 2.6 verdeutlicht den eben beschriebenen Vorgang.
Prinzip einer Zertifizierung: Das Zertifikat wird von der Zertifizierungsinstanz, die es erstellt hat, digital signiert. Jeder Nutzer, der den öffentlichen
Schlüssel der Zertifizierungsinstanz besitzt, kann damit überprüfen, ob der
öffentliche Schlüssel des Nutzers19 wirklich von der Zertifizierungsinstanz ausgegeben wurde. Die Zertifizierungsinstanz veröffentlicht Zertifikate mit öffentlichen Schlüsseln von Nutzern, die deren Zugehörigkeit zur PKI bestätigen. Ist
die Zertifizierungsinstanz vertrauenswürdig, ist auch ein von ihr zertifizierter
öffentlicher Schlüssel und der damit verbundene Nutzer vertrauenswürdig. Die
daraus entstehenden Beziehungen nennt man auch Vetrauenskette.
19
Hinterlegt im Zertifikat.
27
Alice
1) Alice erzeugt sich ein Schlüsselpaar,
anschließend einen CSR und schickt diesen
an die RA der PKI
Signiertes Zertifikat
Signatur des Zertifikates
Kennung der
Zertifizierungsinstanz
Kennung des
Benutzers
Gültigkeitsdauer
des Zertifikates
Public Key des
Inhabers
Zertifikatsantrag (CSR)
Hash
2) nach der Prüfung und Freigabe
durch die RA signiert die CA den
Antrag.
2.1) Hashfunktion
auf CSR anwenden
Public Key Verfahren
z.B. RSA
Prüfsumme
2.1) Prüfsumme mit
Private Key der CA
verschlüsseln
Private Key
der CA
Signieren des CRS
Abbildung 2.6.: Erstellung eines Zertifikates
2.9.2. Verifizieren von Zertifikaten
Nach dem Erhalt eines Zertifikates muss als Erstes geprüft werden, ob dieses
Zertifikat vertrauenswürdig ist. Dazu werden folgende Schritte, wie in Abbildung 2.7, vom Sicherheitssystem, z.B. eines E-Mail-Clienten, durchgeführt.
28
Signiertes Zertifikat
Signatur des Zertifikates
Kennung der
Kennung des
Benutzers
Gültigkeitsdauer
des Zertifikates
Public Key des
Inhabers
Zertifikatsantrag (CSR)
1) Hashfunktion anwenden
Hash
Public Key
der CA
Public Key
Verfahren z.B. RSA
2) Prüfsumme
entschlüsseln
Aktuelle
Prüfsumme
3) Prüfsumme auf
Gleichheit prüfen
Ursprüngliche
Prüfsumme
Vergleich
?
Gleichheit = an der CA zugelassen und sicher
Ungleich = nicht zugelassen oder kompromittiert
Abbildung 2.7.: Prüfung eines Zertifikates
1. Es wird die aktuelle kryptographische Prüfsumme durch Einsatz einer
Hashfunktion über das Zertifikat berechnet.
29
2. Aus dem Zertifikat wird die Signatur extrahiert und mit dem öffentlichen
Schlüssel der CA unter Anwendung des Public Keys in die ursprüngliche
kryptographische Prüfsumme zurückberechnet.
3. Stimmen die Prüfsummen überein, wird damit die Zugehörigkeit des
Nutzers zu der CA bestätigt und die Unversehrtheit und Echtheit des
im Zertifikat enthaltenen öffentlichen Schlüssels garantiert. Mit anderen
Worten: der öffentliche Schlüssel des Nutzers, mit dem man in Verbindung treten möchte, ist auch der, für den er sich ausgibt, so dass E-Mails,
die mit diesen Schlüssel verschlüsselt oder signiert werden, nicht durch
Dritte verändert werden können.
2.9.3. Signieren
Im folgenden Abschnitt wird näher auf den praktischen Nutzen der oben beschriebenen Verfahren eingegangen und das digitale Signieren einer Nachricht
genauer betrachtet. Zuerst wird dazu ein grober Überblick über den Prozess
der E-Mail-Signierung gegeben. Es soll verdeutlicht werden, inwieweit, wo und
wie auf die Komponenten der PKI zugegriffen und mit diesen interagiert wird.
Ziel ist es dabei einen Überblick über die Abläufe innerhalb der PKI zu geben.
Anschließend wird detailliert jeder Schritt der Signierung und Verschlüsselung
aufgezeigt. Betrachtet man dabei den Ablauf der E-Mail-Signierung, ergibt
sich folgendes Bild in Abbildung 2.8: Will Bob eine signierte Nachricht an
Alice schicken, signiert er diese mit seinem, von der CA ”XY” zugelassenen
privaten Schlüssel und überträgt die Nachricht an Alice. Bekommt Alice diese
Nachricht, muss sie, will sie der Nachricht vertrauen, als Erstes mit Hilfe der
von der CA veröffentlichten Zertifikate prüfen, ob die digitale Signatur von
Bob stammt. Dazu wird zunächst das Zertifikat von Bob und der darin enthaltene Schlüssel unter Anwendung des Wurzelzertifkates der zuständigen CA
auf seine Integrität geprüft. Ist dieser Test erfolgreich, kann Alice auf Basis
30
des Zertifikates von Bob die Signatur der Nachricht auf Manipulationen hin
prüfen. Dieser Prozess stellt sich im Detail folgendermaßen dar:
1) über den Inhalt der E-Mail eine
kryptographische Prüfsumme berechnen
E-Mail
Hash
PKI
2) mit Private Key
Verschlüsseln
Public Key
Verfahren z.B. RSA
Prüfsumme
Private Key
von Bob
Signatur
Bob
5) Zrt. von Bob
aus der PKI
beziehen und
auf Gültigkeit
prüfen
E-Mail
(in Klartext)
3) Signatur an E-Mail anhängen
Signatur
4) E-Mail an Alice verschicken
6) Signatur mit Public Key von
Bob entschlüsseln
Public Key
von Bob
Ungleich = E-Mail
wurde kompromittiert
=?
ursprüngliche
Prüfsumme
8) auf Gleichheit prüfen
Gleich = E-Mail OK
Public Key
Verfahren z.B. RSA
Alice
Signatur
7) mit gleicher Hashfunktion wie
Bob über den Inhalt der E-Mail eine
kryptographische Prüfsumme
berechnen
aktuelle
Prüfsumme
Hash
Abbildung 2.8.: Signierung einer E-Mail
31
E-Mail
1. Bob berechnet über den Inhalt der E-Mail einen Hashwert und bildet
damit einen eindeutigen Fingerabdruck.
2. Bob verschlüsselt den Hashwert mit Hilfe seines geheimen Schlüssels und
bildet damit die elektronische Signatur.
3. Bob verschickt die Nutzdatei und die Signaturdatei zusammen.
4. Alice erhält die Nachricht und die Signaturdatei.
5. Alice entschlüsselt die Signatur mit Hilfe des öffentlichen Schlüssels von
Bob (aus dem vorher mit dem Wurzelzertifikat der CA verifizierten Zertifikat) und erhält damit den von Bob erzeugten Hashwert.
6. Alice berechnet den Hashwert über den Inhalt der E-Mail erneut und
bekommt damit einen aktuellen Fingerabdruck.
7. Alice vergleicht die beiden Hashwerte20 : sind diese identisch, dann wurde
die Datei vom richtigen Absender verschickt (Authentifizierung, Authentizität) und nicht verändert (Integrität). Dies wiederum setzt voraus,
dass nur der gewünschte Absender im Besitz des geheimen Schlüssels
ist21 .
2.9.4. Verschlüsseln
Abschließend zu den praktischen Grundlagen einer PKI soll hier die Verschlüsselung von Nachrichten betrachtet werden. Dabei ist diese eigentlich nur noch
ein Aufsatz, der nach dem Signieren der Nachricht vollzogen wird. Zum einen
ist, im Unterschied zur Signierung, die Information nach dem Verschlüsseln
nicht mehr für Dritte einsehbar, zum anderen braucht der Absender (Bob) vor
20
21
Aktueller Fingerabdruck gegen den entschlüsselten Fingerabdruck von Bob.
Hinweis: Der Inhalt einer Datei wird durch eine Signatur nicht verschlüsselt. Die signierte Datei ist weiter lesbar und auch veränderbar. Eine elektronische Signatur, zumindest
wenn dafür entsprechende Verfahren wie asymmetrische Verschlüsselung eingesetzt werden, dient lediglich zur Erkennung, ob die Datei nach der Signierung verändert wurde.
32
2.10. Zusammenfassung
dem Verschlüsseln der E-Mail den Public Key des Empfängers (Alice). Bob
muss sich also vor dem Verschlüsseln das Zertifikat von Alice bei der PKI besorgen und dieses verifizieren. Ist das geschehen, kann nach dem Signieren die
Nachricht für Alice mit deren Public Key verschlüsselt werden. Alice wiederum benutzt ihren Privat Key um die Nachricht zu entschlüsseln. Zusätzlich
dazu wird die Nachricht danach, wie oben schon beschrieben, auf Änderungen
geprüft. Ist diese negativ, kann man von einer absolut sicheren Übertragung
ausgehen.
In diesem Kapitel wurden Vorüberlegungen zu den Entwicklungen der Verschlüsselungstechnologien hin zur Einführung einer Public Key Infrastruktur
vermittelt. Dabei wurden grundlegende Prinzipien und Vorgänge der einzelnen Verfahren erläutert, um auf Basis dieses Wissens die Notwendigkeit der
Einführung einer PKI zu verdeutlichen. In einem weiteren Schritt wurden die
Grundbausteine, Prinzipien und Prozesse innerhalb einer PKI veranschaulicht.
33
34
3. Analyse
Dieses Kapitel dokumentiert die Erarbeitung von Regelungen, Abläufen und
Vorgaben innerhalb der fachbereichsweiten Public Key Infrastruktur.
3.1. Einleitung
Im Rahmen dieser Diplomarbeit geht es im Folgenden um die Analyse der geplanten Public Key Infrastruktur. Dabei wird sich in erster Linie an der RFC
3647 [OSSIVCGL+ 03] orientiert. Diese RFC gibt dem Entwickler der PKI ein
Gerüst von Überschriften, Themen-Gebieten und Problemstellungen, die in der
Planung einer PKI Berücksichtigung finden sollen. Dabei entsteht, hält man
sich an die Vorgaben, ein aussagekräftiges Dokument, welches alle nötigen Informationen über die PKI beinhaltet. Dieser Abschnitt, der auch als Policy
bezeichnet wird, stellt die Grundlage für fast alle Aktionen der Zertifizierungsstelle (Certification Authority - CA) dar und legt darüber hinaus Richtlinien
fest, die von den unterhalb der CA zertifizierten SubCAs und Benutzern einzuhalten sind. Damit dient sie auch gleichzeitig der Kontrolle der Anwender über
die Qualität der erteilten Zertifikate. Mit anderen Worten: Mit der Qualität
und Einhaltung der Policy steht und fällt die Vertrauenswürdigkeit einer CA
und die daraus resultierende PKI.
Normalerweise wird die Policy und die darin enthaltene ”Zertifizierungsrichtlinie” (Certification Policy - CP) und ”Erklärung zum Zertifizierungsbetrieb”
(Certificate Practice Statements - CPS) in zwei getrennten Dokumenten von
der CA auf einem für die Öffentlichkeit erreichbaren Platz bereitgestellt. Da
35
3.1. Einleitung
Kapitel 3. Analyse
diese Praxis (die Teilung des Dokumentes) jedoch die Lesbarkeit der Arbeit unnötig verkomplizieren würde, wird die CP und CPS zusammen in allen nötigen
Einzelheiten in diesem Kapitel abgehandelt. Dabei wird der Fokus in erster Linie auf eine Studie für die Umsetzung einer möglichen PKI an dem Fachbereich
Design Informatik Medien (DCSM)1 gelegt. Eine mögliche Ausweitung auf die
gesamte Fachhochschule Wiesbaden im Speziellen wird ebenfalls bei der Betrachtung mit berücksichtigt. Um die Trennung der Dokumente CP und CPS
trotzdem weitgehend zu verdeutlichen, wird durch entsprechende Überschriften und Kommentare auf die Zugehörigkeit einzelner Abschnitte hingewiesen.
Innerhalb der FB-PKI können verschiedene Zertifizierungsstellen existieren,
die Zertifikate für verschiedene Sicherheitsniveaus ausstellen. Die dabei angewandten Verfahren können dabei unterschiedlich sein, wenn sie der Zertifizierungsrichtlinie und der Erklärung zum Zertifizierungsbetrieb der FB-PKI
entsprechen. Ein möglicher Aufbau der FB-PKI ist in Abbildung 3.1 dargestellt.
Die hier vorgelegte CP und CPS ist, wie anfänglich erwähnt, auf Basis der Anforderungen der RFC 3647 entworfen. Außerdem wurde sich an der CP-Classic
[DFN05b] und CPS-Classic [DFN05a] der Public Key Infrastruktur des deutschen Forschungsnetzes orientiert2 . Es wird darauf hingewiesen, dass die hier
gemachten Aussagen keinen Anspruch auf Vollständigkeit erheben. Die hier
vorgetragenen Punkte sollten vor dem Einsatz in einer produktiven PKI nochmals überprüft und gegebenenfalls angepasst werden.
In der CP und CPS sind die Bedingungen für die Ausstellung von Zertifikaten entsprechend der internationalen Norm X.509 [RLNVC02] festgelegt.
Dabei beschreibt diese Analyse die Eigenschaften der ausgestellten Zertifikate
und geltenden Sicherheitsvorgaben (CP-Teil), die Vorgänge innerhalb der PKI
sowie detaillierte Informationen über Spezifikationen, die Prozesse der Zertifi-
1
2
FB-PKI
http://www.dfn-cert.de/
36
Kapitel 3. Analyse
3.1. Einleitung
zierungsstellen und die Sicherheitsmaßnahmen (CPS-Teil). Es ist möglich für
die gesamte PKI Zertifikate auf Basis dieser Dokumente zu erstellen. Dabei
sind die darin gemachten Aussagen für alle Teilnehmer bindend3 . Die an dieser Stelle dargelegte CP/CPS kann als RootCP/CPS der FB-PKI Verwendung
finden und damit an die in der FB-PKI existierenden untergeordneten Zertifizierungsstellen (SubCAs) vererbt werden. Dabei kann das hier definierte Niveau von diesen untergeordneten Zertifizierungsstellen modifiziert werden. Es
ist jedoch darauf zu achten, dass folgende Einschränkungen gelten: Es dürfen
weder technische, organisatorische, infrastrukturelle noch personelle Maßnahmen negativ verändert werden. Das heißt, die eben genannten Teile sind als
Standard anzusehen, um Qualität und Wirksamkeit zu wahren. Ändert eine
Zertifizierungsstelle die CP/CPS im Rahmen ihrer Möglichkeiten, muss sie die
Änderungen dabei gesondert veröffentlichen.
3.1.1. Teilnehmer der Zertifizierungsinfrastruktur
Im Folgenden geht es um den grundlegenden Aufbau und die Teilnehmer der
FB-PKI, dabei vermittelt die Abbildung 3.1 eine Übersicht über deren Aufbau.
FB RootCA
Externe CA
ExtMitar.A
ExtMitar.B
User CA
User.A
User.B
Technische
CA
VPN
WebServer
Abbildung 3.1.: Aufbau der Fachbereich-PKI
3
Wenn sie den geltenden Gesetzen entsprechen.
37
3.1. Einleitung
Kapitel 3. Analyse
An dieser Stelle der Studie soll darauf eingegangen werden, wie die PKI auf
die gesamte Fachhochschule angewendet werden kann. Die Abbildung 3.2 soll
dabei zur Konkretisierung dienen.
FH RootCA
Studenten CA
StudentA
StudentB
Mitarbeiter CA
Mitarb.A
Mitarb.B
Technische
CA
VPN
WebServer
Abbildung 3.2.: Aufbau der Fachhochschul-PKI
3.1.2. Oberste Zertifizierungsstelle (PCA)
CP
Die Policy Certification Authority (PCA - RootCA) ist die oberste Instanz
der PKI und besitzt ein selbstsignierendes Zertifikat (Root Zertifikat). Alle
Nutzer der PKI können sich dieses Zertifikat öffentlich herunterladen, um so
die Integrität der durch die PCA zertifizierten Zertifizierungsstellen zu verifizieren. Dabei ist zu beachten, dass die PCA nur unmittelbar untergeordnete
Zertifizierungsstellen zertifizieren darf.
Anmerkung: Gilt die hier dargelegte CP/CPS für alle durch die PCA ausgestellten Zertifikate, so ist sie ebenfalls gültig für alle davon abgeleiteten Zertifikate innerhalb der PKI. Somit gibt die CP/CPS der RootCA den Rahmen
und die Mindestanforderungen für das Sicherheitsniveau der gesamten PKI
vor. Dabei kann die CP und das dazugehörige CPS, wie oben schon erwähnt,
durch untergeordnete Zertifizierungsstellen entsprechenden Bedürfnissen angepasst werden. Dabei darf sich jedoch auf keinen Fall das Sicherheitsniveau
38
Kapitel 3. Analyse
3.1. Einleitung
durch die gemachten Änderungen abschwächen.
CPS
Die RootCA besitzt ein selbstsigniertes Zertifikat (Root-Zertifikat), das den
öffentlichen Schlüssel der RootCA enthält. Mit diesem Zertifikat ist es den
Teilnehmern der FB-PKI/FH-PKI möglich, die Authentizität und Gültigkeit
der unterhalb dieses Root-Zertifikates ausgestellten Zertifikate zu überprüfen.
Dabei ist darauf zu achten, dass die PCA ausschließlich Zertifikate von unmittelbar untergeordneten Zertifizierungsstellen zertifiziert.
3.1.3. Zertifizierungsstellen (CA)
CP
Die Zertifizierungsstellen innerhalb der FB-PKI/FH-PKI, die unterhalb der
PCA angesiedelt und durch diese zertifiziert worden sind, können Zertifikate
für natürliche Personen und Serverdienste ausstellen. Wobei eine klare Unterscheidung zwischen den technischen und personellen CAs getroffen werden
muss. Bei Ausweitung der Organisationsstruktur sollte es möglich sein, weitere
untergeordnete Zertifizierungsstellen zu etablieren.
CPS
Unterhalb der PCA werden folgende Zertifizierungsstellen betrieben:
Fachbereichsweite Anwendung
• User CA: Zertifizierungsstelle, unter der die Mitglieder des Fachbereichs
verwaltet werden. Dabei muss der Standort und die Zuständigkeit für die
CA vom Fachbereich festgelegt werden.
• Externe CA: Zertifizierungsstelle für die externen Mitarbeiter des Fachbereichs. Dabei müssen der Standort und die Zuständigkeit für die CA
vom Fachbereich festgelegt werden.
• Technische CA: Zertifizierungsstelle für die Datenverarbeitungssysteme des Fachbereichs. Dabei müssen der Standort und die Zuständigkeit
39
3.1. Einleitung
Kapitel 3. Analyse
für die CA von dem jeweils zuständigen Mitarbeitern des Fachbereichs
festgelegt werden.
Fachhochschulweite Anwendung
• Studenten CA: Zertifizierungsstelle, unter der die Studenten der Fachhochschule verwaltet werden.
• Mitarbeiter CA: Zertifizierungsstelle für die Mitarbeiter und Professoren der Fachhochschule.
• Technische CA: Zertifizierungsstelle für die Datenverarbeitungssysteme der Fachhochschule.
Anmerkung: Die Standorte der Hardware der jeweiligen CAs und deren Zuständigkeitsbereiche müssen von der Fachhochschule oder der jeweils betreuenden Stelle festgelegt und verwaltet werden. Dabei können Zertifikate für
nachgeordnete Zertifizierungsstellen vergeben werden.
3.1.4. Registrierungsstellen (RA)
CP
Die Zertifizierungsstellen innerhalb der FB-PKI/FH-PKI haben die Möglichkeit, beliebig viele Registrierungsstellen für die Prüfung der Identität und Authentizität der Zertifikatnehmer zu betreiben. Diese Registrierungsstellen dürfen wiederum auch direkt untergeordnete Zertifizierungsstellen registrieren und
durch die zur RA zugehörigen Zertifizierungsstelle zertifizieren lassen.
CPS
Folgende Registrierungsstellen sind vorgesehen:
• User RA: Für die Prüfung von Anträgen der Mitglieder des Fachbereichs muss eine entsprechende Stelle eingerichtet werden.
40
Kapitel 3. Analyse
3.1. Einleitung
• Externe RA: Für die Prüfung von Anträgen fachbereichexterner Mitarbeiter sollte eine entsprechende Stelle eingerichtet werden. Es ist möglich
diese mit der zuständigen Stelle der User RA zusammenzulegen.
• Technische RA: Für die Prüfung von Anträgen auf die Zertifizierung
der Datenverarbeitungssysteme sollte ein vertrauenswürdiger Mitarbeiter innerhalb des Fachbereichs zuständig sein.
• Studenten RA: Für die erstmalige Beantragung und Prüfung ist das
Studentensekretariat bei der Immatrikulation zuständig. Für einen nachträglichen Antrag sollte eine in der Fachhochschule oder dem jeweiligen
Fachbereich zuständige Stelle eingerichtet werden.
• Mitarbeiter RA: Für die Prüfung der Anträge der Mitarbeiter benötigt
jeder Fachbereich eine entsprechende Stelle.
• Technische RA: Für die Prüfung von Anträgen auf die Zertifizierung
von Datenverarbeitungssystemen ist eine spezielle Stelle innerhalb der
Fachhochschule zuständig.
3.1.5. Zertifikatnehmer - CP
Dieser Abschnitt soll genauere Aussagen über die Nutzer machen, die innerhalb
der FB-PKI/FH-PKI ein Zertifikat erhalten dürfen.
Zum Erhalt eines FB-Zertifikates sind alle natürlichen Personen innerhalb des
Fachbereichs Design Informatik Medien berechtigt. Die Gruppe der Zertifikatnehmer gliedert sich in drei Gruppen. Zum einen die Mitglieder des Fachbereichs: Studenten, Mitarbeiter und Professoren. Sie werden zusammen unter
der User CA verwaltet. Zum anderen ist es möglich, Zertifikate an technische Systeme (Server und Dienste) zu vergeben. Sie werden unter der zweiten
41
3.1. Einleitung
Kapitel 3. Analyse
Gruppe der technischen CA verwaltet. Die dritte Gruppe rekrutiert sich ausschließlich aus externen Mitarbeitern, die in einer gesonderten CA verwaltet
werden. Außerdem ist vorgesehen, die FB-PKI um weitere Organisationseinheiten (RA, CA) erweitern zu können. Zu diesem Zweck ist es den entsprechenden
übergeordneten CAs erlaubt, Zertifikate zu vergeben.
Alle natürlichen Personen innerhalb der Fachhochschule Wiesbaden sind berechtigt zum Erhalt eines FH-Zertifikates. Die Gruppe der Zertifikatnehmer
gliedert sich wieder in drei Gruppen auf. Zum einen die Studenten der Fachbereiche, zum anderen die Mitarbeiter. Innerhalb der dritten Gruppe ist es
möglich, Zertifikate an technische Systeme (Server und Dienste) zu vergeben.
Weiterhin ist vorgesehen, die FH-PKI um weitere Organisationseinheiten (RA,
CA) zu erweitern. Zu diesem Zweck können von den entsprechenden übergeordneten CAs Zertifikate vergeben werden.
3.1.6. Zertifikatantragprüfer - CP
Ein Antragprüfer ist eine natürliche Person, die für diesen Zweck von dem
Fachbereich bzw. der Fachhochschule bestimmt wird, um die Identität eines
Zertifikatnehmers zu überprüfen. Zu diesem Zweck ist der Antragprüfer berechtigt, vom Zertifikatnehmer Informationen entgegenzunehmen oder ihm zukommen zu lassen. Es muss hierbei darauf geachtet werden, dass der Mitarbeiter nach den Kriterien der Zuverlässigkeit, Verschwiegenheit und Kompetenz
ausgewählt wird. Ein Zertifikatprüfer kann, muss aber nicht Teilnehmer der
FB-PKI/FH-PKI sein.
3.1.7. Weitere Teilnehmer - CP
Dieser Abschnitt soll konkretisieren welche Nutzer außerhalb des Fachbereich
bzw. der Fachhochschule ein Zertifikat erhalten dürfen.
42
Kapitel 3. Analyse
3.2. Anwendungsbereich - CP
Externe Teilnehmer der FB-PKI sind nur dann zugelassen, wenn sie für den
Fachbereich wichtige Dienstleistungen anbieten, die eine gesicherte Kommunikation rechtfertigen; z.B. das Studentensekretariat zur Übermittlung der Studentenlisten oder die Übermittlung der Notenlisten an höhere Stellen innerhalb
der Fachhochschule. Diese externen Teilnehmer sollten unter einer eigenen CA
verwaltet werden da so eine klare Trennung zwischen internen und externen
Nutzern getroffen werden kann.
Externe Teilnehmer der FH-PKI sind in der momentanen Planungsphase bis
auf weiteres nicht vorgesehen.
3.2. Anwendungsbereich - CP
Dieser Abschnitt soll einen Überblick über die geplanten Anwendungsbereiche
der Zertifikate geben.
3.2.1. Geeignete Zertifikatnutzung
Die im Rahmen dieser CP und der darauf basierenden PKI erstellten Zertifikate können für E-Mail-Verschlüsselung und -Signierung sowie für -Authentifizierung
verwendet werden. Die Zertifikatnehmer sind dabei für das Einbinden und die
Prüfung der Zertifikate in der Anwendungssoftware selbst zuständig.
3.2.2. Untersagte Zertifikatnutzung
Jede Zertifikatnutzung ist erlaubt. Allerdings ist darauf zu achten, dass keine
weiteren untergeordneten Zertifizierungsstellen durch ein ausgestelltes FB/FHZertifikat zertifiziert werden. Dies ist den offiziellen Zertifizierungsstellen der
FB-PKI/FH-PKI vorbehalten.
43
3.3. Verwaltung der Richtlinien - CP
Kapitel 3. Analyse
3.3. Verwaltung der Richtlinien - CP
Unter diesem Abschnitt sollten Basisinformationen in der CP wie Postanschrift, Telefon, E-Mail und entsprechende URLs angegeben werden, die dem
Nutzer über die zuständigen Stellen informieren, an die er sich beispielsweise
im Falle eines kompromittierten Schlüssels wenden kann. Zusätzlich sollten jeweils in der CP und CPS die Kontaktinformationen für die zuständige Stelle
angegeben werden, die die jeweilige Policy verwaltet. Im Normalfall ist das
direkt die Zertifizierungsstelle, z.B. die User CA.
3.4. Veröffentlichungen und Verzeichnisdienst
In diesem Abschnitt geht es in erster Linie um die Fragen, wie und an welcher
Stelle der Nutzer auf Informationen innerhalb der PKI zugreifen kann. Dabei
sollte darauf geachtet werden, eine Implementierung des öffentlichen Teiles
für den Nutzer so transparent wie möglich zu gestalten. Das bedeutet, dass
dem Nutzer der PKI so weit wie möglich Abläufe, die ein spezielles Vorwissen
erfordern, abgenommen werden, um so eine breite Akzeptanz zu erreichen.
3.4.1. Veröffentlichung von Informationen
CP
Jede Zertifizierungsstelle innerhalb der FB-PKI/FH-PKI muss dafür sorgen,
dass Informationen zur Überprüfung der Gültigkeit von Zertifikaten bereitgestellt werden. Deshalb ist darauf zu achten, dass ein Dienst angeboten wird,
der außerhalb wie innerhalb des FB-/FH-Netzes die Möglichkeit der Abrufbarkeit der oben genannten Informationen4 anbietet. Zusätzlich sollte jede Zertifizierungsstelle innerhalb der FB-PKI/FH-PKI folgende Informationen zur
Verfügung stellen:
• das Root Zertifikat der FB-PKI/FH-PKI (PCA)
4
Siehe Abschnitt 3.3 ”Verwaltung der Richtlinien - CP”.
44
Kapitel 3. Analyse
• das Root Zertifikat der Zertifizierungsstelle und, wenn vorhanden, die
Zertifikate der dazugehörigen Registrierungsstellen
• die CP und CPS, die der Zertifizierungsstelle zugrunde liegen
CPS
Jede Zertifizierungsstelle sollte ihr eigenes Online-Portal besitzen. Auf ihm sollten unter anderem, wenn vorhanden, die Zertifikate der übergeordneten CAs5 ,
die eigene CP und CPS, das eigene Zertifikat, die gültigen ausgestellten Zertifikate sowie entsprechende CRLs zum Download bereitstehen. Am Beispiel
der RootCA wird an dieser Stelle verdeutlicht, welche Informationen auf jeden
Fall abrufbar sein müssen6 .
Folgende Informationen sollten an dieser Stelle durch die RootCA veröffentlicht werden:
• Online Adresse, an welcher Stelle das Zertifikat der RootCA bezogen
werden kann.
• Online Adresse, an welcher Stelle die zertifizierten Zertifikate der RootCA bezogen werden können.
• Online Adresse, an welcher Stelle die CRL der RootCA bezogen werden
kann.
• Online Adresse, an welcher Stelle CP und CPS der RootCA bezogen
werden können.
• Online Adresse einer Liste aller untergeordneten Zertifizierungsstellen.
5
6
Um die Vertrauenskette zu prüfen.
Das Beispiel lässt sich auch auf die SubCAs der RootCA übertragen.
45
Kapitel 3. Analyse
3.4.2. Aktualisierung der Informationen
CP
Die Aktualisierung der Informationen zur Prüfung der Gültigkeit von Zertifikaten muss regelmäßig erfolgen. Zum Abstand, der zwischen zwei Aktualisierungen liegen sollte, wird auf die CPS verwiesen.
CPS
Folgende Abstände sind für die Veröffentlichung von Informationen vorgesehen:
• Zertifikate: umgehend nach ihrer Ausstellung
• Widerrufslisten: mindestens einmal pro Monat
• Richtlinien: nach Bedarf
• Weitere Informationen: nach Bedarf
3.4.3. Zugang zu den Informationsdiensten
CP
Der lesende Zugriff auf alle in den obigen Abschnitten angeführten Informationen darf keiner Zugangskontrolle unterliegen. Dagegen darf der schreibende
Zugriff nur berechtigten Personen gewährt werden. Weitere Informationen sind
der CPS zu entnehmen.
CPS
Der lesende Zugriff auf die Verzeichnisdienste sowie die Online-Ressourcen
der Zertifizierungsstellen unterliegt keinerlei Einschränkungen. Der schreibende Zugriff erfolgt nur durch die berechtigten Zertifizierungsstellen und deren
Mitarbeiter.
46
Kapitel 3. Analyse
3.5. Identifizierung und Authentifizierung
Dieser Abschnitt beschreibt die Vorgehensweise, die von der CA und RA verwendet wird um Zertifikat-Antragsteller zu authentifizieren. Dabei wird die
Frage der Namensgebung behandelt. Außerdem soll auf das Thema der Neuund Wiederzertifizierung näher eingegangen werden.
3.5.1. Namen
Im Folgenden wird es um die Regelungen zur Art der Namensgebung von Zertifikatnehmern gehen. Es ist dabei zu beachten, dass diese Regelungen konsequent angewendet werden sollten, um die Konsistenz der PKI zu gewährleisten.
Namensform
CP
Es wird eine einheitliche Namenshierarchie verwendet. Die in der FB-PKI/FHPKI erstellten Zertifikate beinhalten einen eindeutigen Namen (Distinguished
Name - DN) entsprechend dem Namensschema X.500 [ICSbCfNRI+ 93]. Dieses
bildet die Basis für die Vergabe von voll qualifizierten Namen für Zertifikatinhaber und -aussteller. Dadurch wird es möglich, Informationen innerhalb des
Zertifikates zu speichern, die eine eindeutige Zuordnung des Zertifikatinhabers
in eine bestimmte Hierarchie7 der FB-PKI/FH-PKI ermöglichen. Es ist darauf
zu achten, dass jede Zertifizierungsstelle nur innerhalb ihres eindeutig definierten Namensraumes Zertifikate ausstellt. Dabei liegt die Verantwortlichkeit der
Eindeutigkeit der Namen innerhalb der ausstellenden Zertifizierungsstelle8 .
CPS
Der Distinguished Name (DN) eines jeden Zertifikatnehmers unterhalb der
RootCA des Fachbereichs wird nach folgendem Schema vergeben:
7
8
Rollen basierte Identifizierung [NDJB02] Seite 118.
Beispielsweise bei der RA.
47
Kapitel 3. Analyse
C = de
L = Fachhochschule - Wiesbaden ,
O = < Fachbereich > ,
O = < Zertifizierungsstelle > ,
OU = < User > ,
CN = < Eindeutiger Name des Zertifikatinhabers > ,
Listing 3.1: DN für Mitarbeiter, Professoren, Studenten und externe
Mitarbeiter
C = de
O = < Fachbereich > ,
OU = < Dienst >
CN = < URL des Servers > ,
Listing 3.2: DN für Datenverarbeitungssysteme
Anmerkung: Die hier gemachten Vorschläge werden in der Umsetzung des
Prototypen wegen dem momentan andersartigen Aufbau des fachbereichsinternen LDAP-Server nicht 1:1 wiedergegeben. Die Frage stellt sich dabei, ob die
Daten der CAs im selben Baum wie der Nutzerverwaltung oder besser in einem separaten Teil des LDAP-Server abgelegt werden sollten. Da der Prototyp
in erster Linie als Vorgabe zu der Implementierung einer Zertifizierungsstelle innerhalb der aktuellen Infrastruktur des Fachbereichs dienen soll, wurde
er teilweise an die aktuellen Gegebenheiten angepasst9 . Für spätere Betrachtungen ist diese Änderung nicht ausschlaggebend, sollte aber an dieser Stelle
zumindest erwähnt werden.
Der Distinguished Name (DN) eines jeden Zertifikatnehmers unterhalb der
RootCA der Fachhochschule wird nach folgendem Schema vergeben:
9
Für nähere Informationen siehe dazu Kapitel 4 ”Praktische Umsetzung”.
48
Kapitel 3. Analyse
C = de
OU = < User > ,
CN = < Eindeutiger Name des Zertifikatinhabers > ,
Listing 3.3: DN für Mitarbeiter, Professoren und Studenten
C = de
OU = < Dienst >
CN = < URL des Servers > ,
Listing 3.4: DN für Datenverarbeitungssysteme
Aussagekraft von Namen
CP
Der Distinguished Name (DN) muss einen Zertifikatnehmer eindeutig identifizieren. Bei der Namensvergabe gelten folgende Regeln: Die Zertifikate dürfen
nur auf einen zulässigen Namen des Zertifikatnehmers ausgestellt werden. Dabei müssen Zertifikate für technische Systeme erkennbar sein. Weiter ist darauf
zu achten, dass bei der Vergabe von Namen für Organisationseinheiten und
technische Systeme eine Verwechslung mit natürlichen Personen ausgeschlossen werden kann und bei der Vergabe von Zertifikaten für technische Systeme
für den Namen grundsätzlich der voll qualifizierte Domain-Name verwendet
wird. Abschließend sollte jedem Zertifikat eine Seriennummer zugeteilt werden, die den Zertifikatnehmer und das Zertifikat eindeutig identifiziert.
CPS
Namen müssen den Zertifikatnehmer eindeutig identifizieren und in einer verständlichen Form vorliegen. Dabei gelten folgende Regelungen:
• Datenverarbeitungssysteme: der CN (Common Name) ist der voll
qualifizierte Domain-Name.
49
Kapitel 3. Analyse
• Natürliche Personen: Namen werden in der im Fachbereich üblichen
Namenskennung (z.B. Hans-Georg Winkler -> hwink001) abgespeichert.
• Organisationseinheiten: Hier sollte im CN mit einer Endung auf die
Art der Organisationseinheiten hingewiesen werden (z.B. -RA, -CA).
Pseudonyme - CP
Pseudonyme bzw. Fantasienamen sind bei natürlichen Personen nicht erlaubt.
Bei technischen Systemen und Organisationseinheiten sind Pseudonyme bzw.
Fantasienamen nur erlaubt, wenn sie in der ursprünglichen Bezeichnung vorkommen.
Eindeutigkeit von Namen
CPS
Vor einer Zertifizierung durch die Zertifizierungsstelle muss die Korrektheit
und Eindeutigkeit des im Antrag angegebenen Namens durch die Registrierungsstelle überprüft werden. Es ist zu beachten, dass der DN eines Zertifikatnehmers eindeutig ist und nicht bereits an andere Zertifikatnehmer vergeben
wurde. Kommt es zu einer Namensdoppelung, wird der erste Antrag bedient.
Um Probleme mit verschiedenen Zeichen-Codierungen zu vermeiden ist für die
Vergabe der Namen darauf zu achten, dass Umlaute vermieden werden.
CPS
Es ist darauf zu achten, dass der Account-Name und der vergebene DN innerhalb der CN übereinstimmt10 . Das ist wichtig insofern die Verwaltung der Zertifikate innerhalb desselben Baumes wie die Nutzerverwaltung betrieben wird.
Für die Vergabe der Studenten-CNs gelten dabei besondere Bestimmungen.
Diese sollen an dieser Stelle näher betrachtet werden. Namen für Studenten
werden nach folgender Praxis gebildet:
10
Siehe Abschnitt 3.5.1 ”Namensform”.
50
Kapitel 3. Analyse
• 1. Zeichen: 1. Buchstabe Vorname
• 2-5. Zeichen: 2.-5. Buchstabe Nachname
• 6-8. Zeichen: Die Ziffer, die den Namen eindeutig macht, wird im Verhältnis zu dem zuletzt bei gleichen Zeichen (1-5) gewählten Zahlencode
um eins erhöht.
Beispiel: hwink001 existiert, Hans Winkelmann erhält deshalb den Namen
hwink002, da hwink001 durch Hans-Georg Winkler belegt ist.
Anmerkung: Die Vergabe der Studenten-Namen nach diesem Konzept ist
notwendig, da die gesamte Account-Verwaltung der Studenten des Fachbereichs so funktioniert. Sollen die Zertifikate und die Nutzerverwaltung auf einem LDAP-Server in ein und dem selben Baum abgelegt werden, müssen die
Namen in den Zertifikaten denen in der Nutzerverwaltung entsprechen (siehe
dazu auch Kapitel 4 Abschnitt 4.6 ”LDAP”).
3.5.2. Identitätsüberprüfung bei Neuantrag - CP
Es gelten für die Identitätsüberprüfung eines Zertifikatnehmers die folgenden
Regeln:
Natürliche Personen:
Damit die Angaben in einem Antrag durch eine Zertifizierungsstelle beglaubigt werden können, muss die Identität und Authentizität einer natürlichen
Person mittels geeigneter Verfahren durch die zuständige Registrierungsstelle
überprüft werden. Weitere Details werden im Abschnitt 3.5.3 ”Authentifizierung einer natürlichen Person” abgehandelt.
Technische Systeme:
Die Angaben zur Vergabe eines Zertifikates werden durch die zuständige Registrierungsstelle geprüft und an die entsprechende Zertifizierungsstelle weitergeleitet. Überdies gelten die gleichen Regelungen wie in Abschnitt 3.5.3
51
Kapitel 3. Analyse
”Authentifizierung einer natürlichen Person”. Die natürliche Person wird in
dem Falle durch den Administrator des technischen Systems dargestellt.
Organisationseinheiten:
Die Angaben über die Vergabe eines Zertifikates für eine neue CA oder RA
wird innerhalb der PKI geregelt. Dabei wird der Antrag der zuständigen Registrierungsstelle vorgelegt und auf die Richtigkeit der angegeben Daten geprüft.
Ist diese Prüfung erfolgreich, wird der Antrag an die entsprechende Zertifizierungsstelle weitergeleitet. Sie fungiert dann als Wurzel der neuen Organisationseineit. Außerdem gelten die gleichen Regelungen wie in Abschnitt 3.5.3
”Authentifizierung einer natürlichen Person”. Wobei die natürliche Person in
dem Falle durch den Administrator der neuen Organisationseinheit (z.B. einer
CA/RA) dargestellt wird.
3.5.3. Authentifizierung einer natürlichen Person
CP
Für die Identitätsprüfung einer natürlichen Person sind folgende Vorgehensweisen erlaubt: Der Zertifikatnehmer muss persönlich bei der ausstellenden
Zertifizierungsstelle oder der zuständigen Registrierungsstelle erscheinen. Dabei wird durch einen Mitarbeiter der CA oder RA die Identität anhand eines
amtlichen Nachweises wie ein Personalausweis, Pass oder Führerschein nachgeprüft. Des Weiteren kann die Authentifizierung einer natürlichen Person durch
eine geeignete externe Stelle11 durchgeführt werden.
CPS
Die Verfahren der Identitätsprüfung einer natürlichen Person sind der entsprechenden CP zu entnehmen. Dabei sind mindestens folgende Informationen für
11
Studentensekretariat oder die Verwaltung der Fachhochschule.
52
Kapitel 3. Analyse
einen erfolgreichen Antrag von der RA einzuholen: Name und Vorname des
Antragstellers sowie zur Ausstellung eines Zertifikats die E-Mail Adresse.12
3.5.4. Identifizierung und Authentifizierung bei einer
Zertifikaterneuerung - CP
In diesem Abschnitt wird näher auf die Möglichkeiten der Zertifikaterneuerung
eingegangen.
Routinemäßige Zertifikaterneuerung - CP
Die Zertifikaterneuerung eines abgelaufenen Zertifikates setzt voraus, dass der
Zertifikatnehmer über ein gültiges Zertifikat der zuständigen Zertifizierungsstelle verfügt. Bei einer routinemäßigen Erneuerung braucht der Zertifikatnehmer keine Nachweise zu erbringen. Er muss allerdings auf die Zertifikaterneuerung hingewiesen werden, um die Gültigkeit der Angaben innerhalb
des Zertifikates zu bestätigen. Überdies sollte der Zertifikatnehmer bei einer
außerplanmäßigen Erneuerung gegenüber der zuständigen Zertifizierungsstelle vor der Ausstellung eines neuen Zertifikats die Gültigkeit der Angaben im
Zertifikat bestätigen.
Zertifikaterneuerung nach dem Widerruf - CP
Bei einem Widerruf des Zertifikats erfolgt keine Zertifikaterneuerung. Das
heißt, es ist ein neues Zertifikat nach den geltenden Regeln zu beantragen.
3.5.5. Identifizierung und Authentifizierung bei einem
Widerruf
CPS
Für den Widerruf eines Zertifikates muss die ausstellende Zertifizierungsstelle
12
Autorisierungsinformation zum Sperren des Zertifikats und Verwendungszweck des Zertifikats werden von der CA vergeben.
53
Kapitel 3. Analyse
oder die zuständige Registrierungsstelle ein Verfahren zur Verfügung stellen,
um es dem Zertifikatnehmer zu ermöglichen, schnell und unkompliziert sein
Zertifikat zu widerrufen.
CPS
Für den Widerruf eines Zertifikates ist immer die Registrierungsstelle zuständig, bei der das Zertifikat beantragt wurde. Ein Widerruf kann folgendermaßen ablaufen: Übergabe eines unterzeichneten Sperrantrags mit Angabe der
Autorisierungsinformation bzw. einer Identitätsprüfung13 . Übersendung eines
unterzeichneten Sperrantrags per Post mit Angabe der Autorisierungsinformation, einer digital signierten formlosen E-Mail oder einer nicht digital signierten
formlosen E-Mail mit Angabe der Autorisierungsinformation. Weiter sollte es
möglich sein, dass der Nutzer über einen telefonischen Anruf mit Angabe der
Autorisierungsinformation das Zertifikat sperren lassen kann. Weiterhin kann
eine Möglichkeit zum Sperren eines Zertifikates über das Online Interface der
RA realisiert werden14 .
13
14
Siehe Abschnitt 3.5.2 ”Identitätsüberprüfung bei Neuantrag - CP”.
Dies ist die auf dem Prototypen angewandte Methode.
54
Kapitel 3. Analyse
3.6. Ablauforganisation
In diesem Abschnitt werden die Abläufe und Prozesse innerhalb der PKI einer
näheren Betrachtung unterzogen.
3.6.1. Ablauf der Zertifizierung
An dieser Stelle wird ein Gesamtüberblick über den Ablauf der verschiedenen
Zertifizierungsprozesse gegeben, die in der FB-PKI möglich sind. In den darauf folgenden Abschnitten wird detaillierter auf die Einzelheiten der gezeigten
Prozesse eingegangen.
Student
1) Immatrikulation des Studenten
Studenten
Sekretariat
(RA)
2) Weiterleitung der notwendigen Daten aller
immatrikulierten Studenten an die zuständige Instanz
innerhalb des Fachbereichs
Technische
Instanz
3) Übergabe der Daten an einen Batch-Prozess
Batch
4) Automatische Erzeugung der Anträge
und Zertifikate
User CA
Home
Verzeichnisse
Erstellung Zertifikat
und Private Key
5) Ablage des Zertifikat und Private Key
in verschlüsselter Form als PKCS12
LDAP
Veröffentlichung
6) Veröffentlichung der Zertifikate
auf dem internen LDAP-Server
und auf einem Webinterface
Webinterface
Abbildung 3.3.: Automatischen Zertifikaterstellung bei Studenten
55
Kapitel 3. Analyse
Die automatische Zertifikaterstellung, wie in Abbildung 3.3 gezeigt, wird nur
für neu immatrikulierte Studenten angewandt. Dabei fungiert das Studentensekretariat, das die Studenten während ihrer Erstimmatrikulation betreut und
alle nötigen Daten aufnimmt, als Registrierungsstelle der User CA des Fachbereichs. Nach der Immatrikulation bekommt der Fachbereich eine Liste der
immatrikulierten Studenten. Diese Liste wird unter anderem dazu verwendet,
für die neuen Studenten entsprechende Accounts einzurichten. Unter der User
CA wird dieselbe Liste dazu verwendet, um eine Konfigurationsdatei für den
Batch-Prozessor der User CA zu erzeugen. Mit ihm wird anschließend für die
neuen Studenten ein Schlüsselpaar und ein Zertifikat erzeugt. Das Zertifikat
wird im LDAP-Server und dem öffentlichen Teil der User CA veröffentlicht
und der private Schlüssel mit dem öffentlichen signierten Schlüssel zusammen
in einer PKCS#12 Datei15 , geschützt durch das Masterpasswort, in dem jeweiligen Home-Verzeichnis des Studenten abgelegt. Dabei wird im Kapitel 4
”Praktische Umsetzung” weiter auf den Batch-Prozess eingegangen.
Das nächste Szenario in Abbildung 3.4 gilt für alle Professoren, Mitarbeiter
und nachträglich zu zertifizierende Studenten. Dabei stellt der Nutzer über das
öffentlichen Portal der User CA einen Antrag auf Zertifizierung. So kann das
Schlüsselpaar Client- oder Server-seitig erzeugt werden. Ist die Schlüsselerzeugung erfolgreich abgeschlossen, wird der Zertifikatsantrag (Certificate Signing
Request - CSR) an die Registrierungsstelle der User CA geschickt. Sie prüft
die Angaben innerhalb des Antrages auf Richtigkeit und verifiziert diese anhand der in der Policy festgelegten Regelungen. Ist der Antrag genehmigt,
wird er von der User CA digital signiert und im LDAP-Server sowie dem öffentlichen Portal veröffentlicht. Wurde eine Server-seitige Schlüsselerzeugung
initiiert, kann der private Schlüssel unter Angabe des im Antrags-Formular
angegebenen Passwortes heruntergeladen werden. Nähere Informationen sind
15
PKCS#12 definiert ein Dateiformat, das benutzt wird, um den privaten Schlüssel zusammen mit dem zugehörigen Zertifikat passwortgeschützt in einem Container zu speichern.
56
Kapitel 3. Analyse
Mitglied
des FB
1) Besuchen des Public Interfaces der User CA
Public
2) Erzeugen des Schlüsselpaares und Abschicken
des Elektronischen Antrages an die
Registrierungsstelle der User CA
User RA
3) Prüfen auf Richtigkeit der Angaben; eventuell persönliche
Vorstellung um die Daten zu verifizieren
Erstellung
Zertifikat
User CA
4) Signieren des Antrages durch die
User CA
LDAP
Benachrichtigung
der Antragstellers
Veröffentlichung
5) Benachrichtigung des Antragstellers und
Veröffentlichung der Zertifikate auf dem
internen LDAP-Server und auf einem
Webinterface
Webinterface
Abbildung 3.4.: Reguläre Zertifikaterstellung für Professoren, Mitarbeiter und
Studenten
bitte dem Kapitel 4 ”Praktische Umsetzung” zu entnehmen.16
In Abbildung 3.5 ist der Ablauf einer Zertifizierung eines Datenverarbeitungssystem zu sehen. Dabei muss zunächst der Administrator selbst das Schlüsselpaar und den Antrag erzeugen. Anschließend wird im öffentlichen Portal
der Antrag importiert und an die technische Registrierungsstelle geschickt. Sie
prüft die Angaben innerhalb des Antrages auf Richtigkeit und verifiziert sie
anhand der in der Policy festgelegten Regelungen. Ist der Antrag genehmigt,
16
Das oben beschriebene Szenario gilt in gleicher Weise für externe Mitarbeiter. Der einzige
Unterschied: Für die externen Nutzer ist die ”Externe CA” zuständig ist.
57
Kapitel 3. Analyse
1) Selbständige Erstellung der Schlüssel durch den
Administrator des Datenverarbeitungssystems.
Admin
2) Besuchen des Public Interfaces der Technischen CA
Public
3) Abschicken des elektronischen Antrages an die
Registrierungsstelle der technischen CA
technische RA
4) Prüfen auf Richtigkeit der Angaben, eventuell persönliche
Vorstellung des Administrators, um Daten zu verifizieren
Erstellung
Zertifikat
technische CA
5) Signieren des Antrages durch die CA
LDAP
Benachrichtigung
der Antragstellers
Veröffentlichung
6) Benachrichtigung des Antragstellers und
Veröffentlichung der Zertifikate auf dem
internen LDAP-Server und auf einem
Webinterface
Webinterface
Abbildung 3.5.: Zertifikaterstellung für Datenverarbeitungssysteme
wird er von der technischen CA digital signiert und im LDAP-Server sowie
dem öffentlichen Portal veröffentlicht.
3.6.2. Zertifikatantrag
In diesem Anschnitt werden allgemeine Regelungen bezüglich eines CSR behandelt.
Wer ein Zertifikat beantragen kann - CP
Innerhalb der FH-PKI können Zertifikate an alle Zertifikatnehmer ausgestellt
werden, die im Abschnitt 3.1.5 ”Zertifikatnehmer - CP” aufgeführt werden.
58
Kapitel 3. Analyse
Überdies können der PCA untergeordnete Zertifizierungsstellen den Umfang
der berechtigten Zertifikatnehmer weiter eingrenzen.
Registrierungsprozess
CP
Ein Zertifikat kann durch eine Zertifizierungsstelle nur signiert werden, wenn
der entsprechende Registrierungsprozess bei der zuständigen Registrierung erfolgreich abgeschlossen wurde.
CPS
Es gibt zwei Arten der Registrierung:
Automatische Registrierung:
Diese Art der Registrierung kommt zur Anwendung, wenn ein Student erstmalig an der Fachhochschule immatrikuliert wird. Dabei fungiert das Studentensekretariat als RA und prüft die Angaben des Studenten. Nach erfolgreicher
Immatrikulation kann von der entsprechenden Stelle innerhalb des Fachbereichs automatisch ein Schlüsselpaar und ein dazugehöriges Zertifikat für den
Studenten erzeugt werden.
Reguläre Registrierung:
Die reguläre Registrierung kommt zur Anwendung, wenn ein Professor oder
ein Mitarbeiter (intern und extern) ein Zertifikat benötigt, ein Zertifikat widerrufen wurde, ein Datenverarbeitungssystem ein Zertifikat benötigt oder eine
neue untergeordnete Organistationseinheit erstellt werden soll. Dabei müssen
folgende Schritte durchlaufen werden:
1. Prüfung der Dokumente und der CSRs hinsichtlich Vollständigkeit und
Korrektheit.
2. Prüfung der Eindeutigkeit des DN im CSR.
3. Übermittlung der für die Zertifizierung notwendigen Informationen an
die zuständige Zertifizierungsstelle.
59
Kapitel 3. Analyse
3.6.3. Bearbeitung von Zertifikatanträgen - CP
In diesem Abschnitt wird die Abarbeitung der CSRs durch die entsprechenden
Stellen näher betrachtet.
Durchführung der Identifikation und Authentifizierung
Die zuständige Registrierungsstelle führt die Identifikation und Authentifizierung des Zertifikatnehmers nach dem im Abschnitt 3.5.2 ”Identitätsüberprüfung bei Neuantrag - CP” genannten Verfahren durch.
Annahme oder Abweisung von Zertifikatanträgen
Ein Zertifizierungsantrag wird erst von der zuständigen Registrierungsstelle angenommen, wenn die Vorlage der notwendigen Dokumente17 erfolgreich nachgeprüft wurden. Nach der Durchführung der Identifikation und Authentifizierung wird der Zertifizierungsantrag durch die ausstellende Zertifizierungsstelle
weiter bearbeitet und signiert. Sollte eine Prüfung der gerade genannten Kriterien oder die Identifikation und Authentifizierung eines Zertifikatnehmers
nicht erfolgreich sein, wird der Zertifizierungsantrag nicht weiter bearbeitet
und der Status umgehend dem Zertifikatnehmer unter Angaben von Gründen
mitgeteilt
Bearbeitungsdauer
Um die Akzeptanz der PKI bei den Nutzern zu erhöhen soll die Dauer der
Bearbeitung, nach Annahme der Daten, nicht länger als eine Woche betragen.
17
Siehe Unterabschnitt ”Registrierungsprozess” im Abschnitt 3.6.2 ”Wer ein Zertifikat beantragen kann - CP”.
60
Kapitel 3. Analyse
3.6.4. Zertifikatausstellung
Nach erfolgreicher Prüfung eines Zertifizierungsantrags wird umgehend durch
die Zertifizierungsstelle ein Zertifikat ausgestellt und der Zertifikatnehmer über
diesen Vorgang informiert.
Benachrichtigung des Antragstellers
CP
Nach der Zertifikatausstellung wird der Zertifikatnehmer darüber informiert,
dass der Antrag durch die Zertifizierungsstelle ausgestellt wurde. Dabei ist darauf zu achten, dass die in der Übertragung enthaltenen persönlichen Angaben
oder Autorisierungsinformationen angemessen geschützt werden.
CPS
Das Zertifikat wird je nachdem, welche Registrierung durchgeführt wurde, verschieden an den Zertifikatnehmer ausgeliefert.
• Automatisch: Der Zertifikatnehmer bekommt das Zertifikat und den
privaten Schlüssel, gesichert durch sein Masterpasswort, als PKCS#12
Datei in sein Home-Verzeichnis abgelegt.
• Regulär: Der Zertifikatnehmer kann bei Client-seitiger Generierung der
Schlüssel sein Zertifikat im PEM-, TXT- oder CRT-Format und bei
Server-seitiger Generierung der Schlüssel sein Zertifikat im PKCS#12
Format (geschützt mit einem Passwort) von dem öffentlichen Portal der
entsprechenden Zertifizierungsstelle herunterladen.
3.6.5. Zertifikatakzeptanz
Bei der Ausstellung eines Zertifikates durch eine Zertifizierungsstelle ist der
Zertifikatnehmer verpflichtet, nach Erhalt des eigenen Zertifikats sowie auch
des Zertifikates der ausstellenden Zertifizierungsstelle alles auf Richtigkeit der
Daten zu prüfen.
61
Kapitel 3. Analyse
Annahme des Zertifikats
CP
Zertifikate werden durch den Zertifikatnehmer angenommen, wenn folgende
Punkte erfüllt sind:
• Das Zertifikat wird/wurde verwendet.
• Innerhalb eines in der CPS festgelegten Zeitraums wird kein Widerspruch
gegen das Zertifikat eingelegt.
CPS
Das Zertifikat wird akzeptiert, wenn es angewendet wird oder nach 14 Tagen
kein Widerspruch erfolgte. Dabei ist darauf zu achten, dass gemeldete fehlerhafte Zertifikate umgehend von der zuständigen Zertifizierungsstelle zu sperren
sind.
Veröffentlichung des Zertifikats
Hier gelten die Regelungen die in Abschnitt 3.4 ”Veröffentlichungen und Verzeichnisdienst” aufgeführt wurden.
3.6.6. Verwendung des Schlüsselpaares und des Zertifikats CP
Anwendungsbereiche der Schlüssel auf Basis dieser CP sind dem Abschnitt 3.2
”Anwendungsbereich - CP” zu entnehmen.
Nutzung des privaten Schlüssels und des Zertifikats
Durch die Annahme eines Zertifikats der FB-PKI/FH-PKI versichert der Zertifikatnehmer den Teilnehmern der FB-PKI/FH-PKI, die sich auf die Vertrauenswürdigkeit der Informationen innerhalb des Zertifikates verlassen,
• dass ein grundlegendes Verständnis der Anwendung und des Einsatzes
von Zertifikaten besteht,
62
Kapitel 3. Analyse
• dass sämtliche Angaben und Erklärungen im Bezug auf die im Zertifikat
enthaltenden Informationen vollständig der Wahrheit entsprechen,
• dass der private Schlüssel in jedem Fall geschützt aufbewahrt wird,
• dass kein unbefugter Dritter Zugang zu dem privaten Schlüssel gewährt
wird,
• dass das Zertifikat ausschließlich in Übereinstimmung mit dieser CP eingesetzt wird,
• dass das Zertifikat sofort widerrufen wird, wenn die Angaben im Zertifikat nicht mehr zutreffen oder der private Schlüssel verloren, kompromittiert oder gestohlen wurde und
• dass die Zertifizierung weiterer Zertifikate nur durch die entsprechende
Zertifizierungsstelle durchgeführt wird.
Nutzung von öffentlichen Schlüsseln und Zertifikaten
Jeder Person der ein Zertifikat innerhalb der FB-PKI/FH-PKI ausgestellt wurde und, jede Person die Zertifikate sowie öffentliche Schlüssel zur Überprüfung
einer Signatur oder für die Zwecke der Authentifizierung oder Verschlüsselung
verwendet, sollte ein grundlegendes Verständnis der Anwendung und des Einsatzes von Zertifikaten aufweisen, sowie vor der Nutzung eines Zertifikats dieses
auf seine Gültigkeit prüfen. Des Weiteren ist das Zertifikat nur für autorisierte
und legale Zwecke in Übereinstimmung mit dieser CP einzusetzen.
3.6.7. Zertifikaterneuerung / Re-Zertifizierung - CP
Bei einer Re-Zertifizierung wird dem Zertifikatnehmer ein neues Zertifikat unter Beibehaltung des alten Schlüsselpaars ausgestellt. Diese Regelung18 gilt
nur, wenn kein Verdacht auf Kompromittierung des privaten Schlüssels vorliegt, die im Zertifikat enthaltenen Informationen unverändert bleiben und die
18
Beibehaltung der Schlüssel.
63
Kapitel 3. Analyse
kryptographischen Verfahren zum Zeitpunkt der Erstellung der Schlüssel noch
ausreichen. Dabei sollten bei einer Zertifikaterneuerung bzw. Re-Zertifizierung
folgende Fragen und Punkte Beachtung finden:
• Gründe für eine Zertifikaterneuerung
Eine Erneuerung kann nur erfolgen, wenn das alte Zertifikat abgelaufen
ist.
• Wer kann eine Zertifikaterneuerung beantragen
Alle Zertifikatnehmer, die ein Zertifikat durch die FB-PKI/FH-PKI ausgestellt bekommen haben können eine Zertifikaterneuerung bzw. ReZertifizierung beantragen. Dabei kann die Beantragung explizit direkt
durch den Zertifikatnehmer erfolgen oder implizit durch eine entsprechende automatische Erneuerung.
• Ablauf der Zertifikaterneuerung
Der Vorgang einer Zertifikaterneuerung entspricht den Regelungen im
Abschnitt 3.6.4 ”Zertifikatausstellung”. Für eine Identifizierung und Authentifizierung gelten die Regelungen im Abschnitt 3.5.4 ”Routinemäßige
Zertifikaterneuerung - CP”.
• Benachrichtigung des Zertifkatnehmers
Der Zertifikatnehmer muss über die Erneuerung seines Zertifikates in
Kenntnis gesetzt werden.19
• Annahme einer Zertifikaterneuerung
Es gelten die Regelungen wie im Abschnitt 3.6.5 ”Annahme des Zertifikats”.
• Veröffentlichung einer Zertifikaterneuerung
Es gelten die Regelungen des Abschnitt 3.6.5 ”Veröffentlichung des Zertifikats”.
19
Siehe Abschnitt 3.6.4 ”Benachrichtigung des Antragstellers”.
64
Kapitel 3. Analyse
In der Abbildung 3.7 soll der Prozess der Vorgehensweise einer Zertifikaterneuerung aufgezeigt werden: In diesem Szenario20 muss der Zertifikatinhaber
Zertifikatinhaber
Antrag um Verlängerung des Zertifikates
RA
Prüfen des Antrages
CA
Neusignierung
LDAP
Benachrichtigung
der Zertifikatnehmers
Veröffentlichung
Webinterface
Abbildung 3.6.: Zertifikaterneuerung
selbst die Initiative ergreifen und vor Ablauf des Zertifikates einen Antrag auf
Zertifikaterneuerung an die jeweils zuständige RA stellen. Nach der Antragstellung wird dieser auf seine Zulässigkeit geprüft und an die Zertifizierungsstelle
weitergeleitet. Diese signiert neu, informiert den Antragsteller und veröffentlicht das neue Zertifikat anstelle des alten.
21
3.6.8. Zertifikaterneuerung / Re-Key - CP
Es gelten die gleichen Regelungen wie im Abschnitt 3.6.7 ”Zertifikaterneuerung / Re-Zertifizierung - CP” mit dem Unterschied, dass neue Schlüssel er20
21
Das für Zertifikate der FB-PKI gilt.
Anmerkung: Da eine ständige Erneuerung der Zertifikate bei den Studenten einen unnötig großen Aufwand verursachen würde, sollten die Zertifikate der Studenten schon am
Anfang mit einer geeigneten Gültigkeitsdauer veröffentlicht werden.
65
Kapitel 3. Analyse
zeugt und verwendet werden. Darüber hinaus sollten auch folgende Punkte
hier Beachtung finden:
• Benachrichtigung des Zertifkatnehmers
Es gelten die Regelungen wie im Abschnitt 3.6.4 ”Benachrichtigung des
Antragstellers”.
• Annahme einer Zertifikaterneuerung
Es gelten die Regelungen wie im Abschnitt 3.6.5 ”Annahme des Zertifikats”.
• Veröffentlichung einer Zertifikaterneuerung
Es gelten die Regelungen wie im Abschnitt 3.6.5 ”Veröffentlichung des
Zertifikats”.
3.6.9. Zertifikatmodifizierung - CP
Ein Zertifikat wird nur verändert, wenn Angaben innerhalb des Zertifikats
nicht mehr der Wahrheit entsprechen. Dabei ist darauf zu achten, dass bei
der Änderung der Identität des Inhabers (z.B. Änderung des Nachnamens) ein
Neuantrag auf Zertifizierung gestellt wird. Betreffen die Änderungen nicht die
Identität des Zertifikatinhabers, so wird wie in Abschnitt 3.6.7 ”Zertifikaterneuerung / Re-Zertifizierung - CP” und 3.6.8 ”Zertifikaterneuerung / Re-Key
- CP” verfahren.
3.6.10. Widerruf und Suspendierung von Zertifikaten
An dieser Stelle wird näher auf die Möglichkeit des Widerrufs von Zertifikaten
eingegangen. Bei der Suspendierung22 von Zertifikaten ist im Moment keine
weitere Behandlung des Themas vorgesehen. Das heißt, es ist nicht möglich
einmal widerrufene Zertifikate zu erneuern oder zu verlängern. Stattdessen
werden sie nur neu beantragt.
22
Eine zeitliche Aussetzung des Zertifikats.
66
Kapitel 3. Analyse
Für die Certificate Revocation List (CRL) gilt die Regelung, dass die Veröffentlichung von CRLs mindestens einmal pro Monat geschehen muss. Dabei sollte
bei einer Veränderung der CRL diese unverzüglich veröffentlicht werden23 .
3.6.11. Gründe für einen Widerruf - CP
Zertifikate werden lediglich von der zuständigen Zertifizierungsstelle widerrufen. Dabei muss für den Widerruf mindestens einer der folgenden Gründe
bekannt sein:
• Das Zertifikat enthält Angaben, die nicht mehr gültig sind.
• Der private Schlüssel des Zertifikatnehmers wurde geändert, verloren, gestohlen, offen gelegt oder anderweitig kompromittiert bzw. missbraucht.
• Der Zertifikatnehmer hat seine Berechtigungsgrundlage für die Nutzung
des Zertifikates verloren24 .
• Der Zertifikatnehmer hält sich nachweislich nicht an die innerhalb der
CP und CPS geltenden Regeln.
• Die zuständige Zertifizierungsstelle bzw. eine Registrierungsstelle hält
sich nachweislich nicht an die innerhalb der CP und CPS geltenden Regeln.
• Der Zertifikatnehmer benötigt kein Zertifikat mehr.
• Der Zertifizierungsbetrieb wird eingestellt.
3.6.12. Wer kann widerrufen - CP
Zertifikate werden ausschließlich von der ausstellenden Zertifizierungsstelle widerrufen. Dabei kann jeder Zertifikatnehmer von der Zertifizierungsstelle, die
23
24
Quellenangaben der CRLs für die Prüfung des Status von Zertifikaten stehen unter dem
Abschnitt 3.4 ”Veröffentlichungen und Verzeichnisdienst” zur Verfügung.
Siehe Abschnitt 3.1.5 ”Zertifikatnehmer - CP”.
67
Kapitel 3. Analyse
sein Zertifikat erstellt hat, unter Angaben von Gründen25 verlangen, dass das
für ihn ausgestellte Zertifikat widerrufen wird. Voraussetzung für einen erfolgreichen Widerruf ist eine erfolgreiche Identifizierung und Authentifizierung
des Zertifikatnehmers entsprechend dem Abschnitt 3.5.5 ”Identifizierung und
Authentifizierung bei einem Widerruf”.
3.6.13. Beendigung des Vertragsverhältnisses durch den
Zertifikatnehmer - CP
Die Dauer eines Vertragsverhältnisses ergibt sich durch die im Zertifkat angegebene Gültigkeitsdauer. Die Aufbewahrungsdauer von Zertifikaten und Dokumenten des Zertifikatnehmers ist abhängig von den Regelungen innerhalb
des Fachbereiches, der Fachhochschule bzw. den datenschutzrechtlichen Bestimmungen des Landes Hessen.
25
Siehe Abschnitt 3.6.11 ”Gründe für einen Widerruf - CP”.
68
3.7. Infrastrukturelle, organisatorische und personelle Sicherheitsmaßnahmen
Kapitel 3. Analyse
- CPS
3.7. Infrastrukturelle, organisatorische und
personelle Sicherheitsmaßnahmen - CPS
Sicherheitstechnische Anforderungen an die infrastrukturellen, organisatorischen und personellen Sicherheitsmaßnahmen einer Zertifizierungs- und Registrierungsstelle sind durch die Vorgaben der RootCA bestimmt. Diese Regelungen, die an die untergeordneten SubCAs vererbt werden, können angepasst,
jedoch niemals abgeschwächt werden.
3.7.1. Infrastrukturelle Sicherheitsmaßnahmen
Im folgenden Abschnitt wird auf die Regeln zu den Sicherheitsmaßnahmen bezüglich der Sicherheit der CA-Infrastruktur eingegangen26 . Dabei handelt es
sich hierbei um Empfehlungen, die im Laufe dieser Studie erarbeitet wurden.
Die hier vorgestellten Maßnahmen orientieren sich an den Möglichkeiten des
Fachbereichs Informatik und an den existierenden Regelungen für die vorhandenen Server und Räumlichkeiten. Für die Entwicklung der CPS einer laufenden PKI im produktiven Einsatz sollte auf jeden Fall noch eine Anpassung der
Regeln in Erwägung gezogen werden.
Die Betrachtung soll mit dem Standort der Hardware beginnen. Die Hardware
sollte in den Server-Räumen des Fachbereichs Informatik der FH-Wiesbaden
aufgestellt und gewartet werden. Diese Räume bieten die entsprechende Infrastruktur und Sicherheit zum Betrieb von Servern. Dabei ist der Zutritt zu
den Serverräumen des Fachbereichs Informatik nur Mitarbeitern gestattet, die
für den Umgang mit den Server vom Fachbereich autorisiert worden sind. Die
Stromversorgung entspricht den erforderlichen Normen für den Betrieb von
Servern und eine Klimatisierung der Räume für die technische Infrastruktur
26
Anmerkung: Von dem Umgang und der Umsetzung der Sicherheitsregeln einer CA hängt
die Vertraulichkeit der Dienstleistungen einer CA bzw. der gesamten PKI ab.
69
- CPS
Kapitel 3. Analyse
ist vorhanden. Die Datenträger werden in geschlossenen Schränken und Sensible Datenträger in einem Tresor aufbewahrt.
3.7.2. Organisatorische Sicherheitsmaßnahmen
Dieser Abschnitt behandelt die Frage der Verteilung von sicherheitsrelevanten Aufgaben innerhalb einer Zertifizierungsstelle. Weiter werden verschiedene
Szenarien der Kompromittierung dargestellt sowie die Vorgehensweise besprochen, wie bei der Einstellung des Betriebes einer CA verfahren werden soll.
Sicherheitsrelevante Rollen
Um einen ordnungsgemäßen Betrieb einer Zertifizierungsstelle zu realisieren,
ist eine entsprechende Aufgabenverteilung und Funktionstrennung vorzunehmen. Aus diesem Grunde werden die Gruppen der sicherheitsrelevanten Rollen
definiert, die im Rahmen des Zertifizierungsprozesses erforderlich sind. Jede
Rolle ist einer bestimmten Tätigkeiten zugeordnet.
• Registrierungsdienst (RD)
Der Registrierungsdienst ist die Schnittstelle zum Zertifikatnehmer und
wird durch die RA implementiert. Dabei erfüllt dieser Dienst folgende
Aufgaben: Entgegennahme von Zertifikatanträgen; Identifizierung, Authentifizierung und Prüfung der Autorisierung der Zertifikatnehmer, Prüfung des Zertifikatantrags auf Vollständigkeit und Korrektheit, Archivierung von Dokumenten, wenn erforderlich; Entgegennahme von Sperranträgen; Freigabe und Übermittlung von Zertifikatanträgen und Sperrbzw. Widerrufsanträgen an die zuständige Zertifizierungsstelle.
• Zertifizierungsdienst (ZD)
Der Zertifizierungsdienst wird durch die CA implementiert und erfüllt
folgende Aufgaben innerhalb der PKI: Ausstellen von Zertifikaten und
Widerrufslisten; Erzeugung und Verwahrung der CA-Schlüssel.
70
Kapitel 3. Analyse
- CPS
• Systemadministrator (SA)
Der Systemadministrator ist für den laufenden Betrieb der Systeme verantwortlich und für die Installation, Konfiguration, Administration und
Wartung zuständig. Dabei verfügt er ausschließlich über die AdministratorPasswörter der Systeme.
• Systemoperator (SO)
Der Systemoperator ist für die Betreuung der Anwendungen zuständig.
Darüber hinaus hat er Zugriff auf die kryptographischen Schlüssel und
deren Passwörter für Zertifizierungsprozesse und dem Zertifikat- und
Sperrmanagement der CA.
Anmerkung: Die Rolle des Systemadministrators und des Systemoperators sollten nicht von einer Person eingenommen werden. Eine Trennung
der Aufgaben wird empfohlen.
• Sicherheitsbeauftragter (SB)
Der Sicherheitsbeauftragte ist für die Definition und Einhaltung der Sicherheitsbestimmungen zuständig, Er überprüft die Mitarbeiter der PKI
und vergibt die Berechtigungen. Des Weiteren ist er erster Ansprechpartner für sicherheitsrelevante Fragen, die die PKI betreffen.
Involvierte Mitarbeiter pro Arbeitsschritt
An dieser Stelle werden die oben eingeführten Rollen den vorhandenen Tätigkeiten der PKI zugeordnet27 . Dies soll in der Tabelle 3.1 konkretisiert werden.
27
Es wird noch einmal darauf hingewiesen, dass diese Ausführungen eine Empfehlung sind,
die im Rahmen dieser Arbeit aufgestellt wurden.
71
- CPS
Kapitel 3. Analyse
Aufgabe
Rolle
Annahme von Zertifikatsanträgen
RD
Identifizierung und Authentifizierung von Zertifikatnehmern
RD
Prüfung der Autorisierung von Zertifikatnehmern
RD
Verifikation von Dokumenten
RD
Belehrung der Zertifikatnehmer
RD
Prüfung des DN (Distinguish Name)
RD
Annahme und Prüfung von Sperranträgen
RD
Prüfung der Anträge hinsichtlich Vollständigkeit und Korrektheit
RD
Archivierung von Dokumenten (wenn erforderlich)
RD
Freigabe und Übermittlung von Zertifikat- und Sperranträgen an
RD
die zuständige Zertifizierungsstelle
Starten von Prozessen zur Erzeugung von Schlüsselpaaren für Zer-
ZD
tifikatnehmer
Starten von Prozessen zum Ausstellen von Zertifikaten und Wider-
ZD
rufslisten
Übertragen von Zertifikatanträgen zum Zertifizierungsrechner
RD
Veröffentlichen von Zertifikaten und Widerrufslisten
ZD
Schlüsselhinterlegung von privaten CA-Schlüsseln der CAs
SO
Kenntnis von Administrator Passwörtern
SA
Starten und Stoppen von Prozessen (z.B. Web-Server, Datensiche-
SA
rung)
Austauschen von Soft- und Hardwarekomponenten für Zertifizie-
SA
rungssysteme
Austauschen von Soft- und Hardwarekomponenten für andere Sys-
SA
teme der PKI
Überprüfen von Protokolldateien
SA/SO
Vergabe von physikalischen Berechtigungen an PKI Rechnern
Vergabe von Systemberechtigungen an PKI Rechnern
72
SB
SB/SA
Kapitel 3. Analyse
- CPS
Fortschreiben des Betriebs- bzw. Sicherheitskonzepts
SB
Vorbereiten des Batch-Prozesses
SO
Ausführen des Batch-Prozesses
ZD
Tabelle 3.1.: Sicherheitsrelevante Rollen und ihre Aufgaben
Trennung von Aufgaben
An dieser Stelle (Tabelle 3.2) wird ausgeführt, welche Rollen miteinander verträglich und welche unverträglich sind. Die Verträglichkeit ist eine ”Kann”Bestimmung. Um ein ausreichendes Sicherheitsniveau zu erreichen, ist es in
erster Linie wichtig, darauf zu achten, dass bei der Aufteilung der Rollen der
jeweiligen Person keine miteinander unverträglichen Rollen zugewiesen werden.
Rolle
verträglich
unverträglich
Registrierungsdienst (RD)
ZD, SO
SB, SA
Zertifizierungsdienst (ZD)
RD, SO
SB, SA
Systemadministrator (SA)
SO
RD, ZD, SB
Systemoperator (SO)
-
SO, RD, SB, SA
Sicherheitsbeauftragter (SB)
-
RD, ZD, SA, SO
Tabelle 3.2.: Sicherheitsrelevante Rollen und ihre Verträglichkeiten
In der folgenden Abbildung 3.7 soll die eben beschriebene Rollenverteilung
noch einmal zum besseren Verständnis visuell dargestellt werden.
Anmerkung zur Abbildung: Die Pfeilquelle besitzt eine höhere Priorität
bzw. Vertrauensstufe als das Ziel. Beispielsweise kann nur eine Person die die
73
- CPS
Kapitel 3. Analyse
Sicherheitsbeauftragter
Zertifizierungsdienst
Registrierungsdienst
System
Administrator
System
Operator
Abbildung 3.7.: Rollenmodell
Stufe der Vertauenswürdigkeit des ZD erreicht hat auch die Aufgaben des SO
einnehmen, aber nicht umgekehrt28 .
3.7.3. Personelle Sicherheitsmaßnahmen
In diesem Abschnitt wird auf Regelungen, in Bezug auf das Personal, näher
eingegangen.
Anforderungen an die Mitarbeiter
Mitarbeiter der FB-PKI/FH-PKI müssen alle Anforderungen hinsichtlich Vertrauenswürdigkeit, Integrität, Zuverlässigkeit und Fachkundigkeit erfüllen. Die
Mitarbeiter sollten neben der allgemeinen Ausbildung in Informatik über angemessene Fachkenntnisse in ihren zugeteilten Rollen verfügen.
Dokumente für die Mitarbeiter
Den Mitarbeitern der FB-PKI/FH-PKI sollten folgende Dokumente zur Verfügung stehen. Die Zertifizierungsrichtlinie (CP), die Erklärung zum Zertifizierungsbetrieb (CPS), die Prozessbeschreibungen und die Formulare für den
28
ZD ist beispielsweise in erster Linie ZD und dann erst SO.
74
Kapitel 3. Analyse
- CPS
regulären Betrieb, die Verfahrensanweisungen für den Notfall und die Dokumentation der IT-Systeme.
Sicherheitsüberwachung
In diesem Abschnitt soll es um die Umsetzung einer ständigen Sicherheitsüberwachung gehen, die einen nachträglichen Schutz vor der unbemerkten
Kompromittierung bieten soll. Dabei sollte eine Überprüfung der Protokolldaten regelmäßig stattfinden und das zu einem festgelegten Zeitpunkt (z.B.
jeden 1. eines Monats). Die Protokolldaten müssen dabei mit geeigneten Mitteln gegen Zugriff, Löschung und Manipulation geschützt werden, wobei eine
Schwachstellenuntersuchung regelmäßig durch die Administratoren der entsprechenden Instanzen selbst durchgeführt wird. Kommt es zu schwerwiegenden sicherheitstechnischen Ereignissen, wird unverzüglich der Sicherheitsbeauftragte informiert. Bei schwerwiegenden technischen Ereignissen wird der
System-Administrator informiert.
3.7.4. Kompromittierung und Wiederherstellung
In diesem Abschnitt wird die Vorgehensweise bei Kompromittierung und Wiederherstellung behandelt.
Prozeduren bei IT-Systemen
Werden innerhalb der Zertifizierungsstelle fehlerhafte oder manipulierte Rechner festgestellt, die Auswirkungen auf die Prozesse der Zertifizierungsstelle
haben, wird der Betrieb des entsprechenden Systems sofort eingestellt. Nach
der Einstellung des Betriebes der betroffenen Komponente muss diese umgehend ersetzt werden. Außerdem sollte das fehlerhafte System auf die Möglichkeit einer vorsätzlichen Handlung geprüft werden, um eventuell entsprechende
Schritte einzuleiten.
75
- CPS
Kapitel 3. Analyse
Kompromittierung von privaten Schlüsseln der Zertifizierungsstelle
Wenn der private Schlüssel der Zertifizierungsstelle nachweislich kompromittiert wurde oder ein begründeter Verdacht auf eine Kompromittierung besteht,
muss sofort der Sicherheitsbeauftragte der Zertifizierungsstelle informiert werden. Er sollte umgehend die festgestellte Kompromittierung oder den Verdacht
prüfen und, wenn nötig den Widerruf der betroffenen Zertifikate in die Wege
leiten. Ist dieses ”Worst Case Scenario” eingetreten, müssen folgende Maßnahmen ergriffen werden:
• Die direkt betroffenen Zertifikatnehmer werden unverzüglich informiert.
• Das Zertifikat der Zertifizierungsstelle und alle Zertifikate, die zertifiziert
wurden sind zu widerrufen.
• Um inkorrekte oder ungültige Aussagen durch die Dienste zu verhindern,
kann eine Abschaltung der Verzeichnisdienste und der damit verbundenen öffentlichen Dienste (z.B. das Online-Portal der Zertifizierungsstelle)
in Erwägung gezogen werden.
• Erstellen eines neuen Schlüsselpaars und eines Zertifikats für die Zertifizierungsstelle.
• Veröffentlichen des Zertifikats der Zertifizierungsstelle.
• Ausstellen neuer Zertifikate für die Zertifikatnehmer.
3.7.5. Reguläre Einstellung des Betriebs
Wenn es zur regulären Einstellung des Zertifizierungsbetriebs kommt, werden
folgende Maßnahmen ergriffen: Alle Zertifikatnehmer und Registrierungsstellen der betroffenen Instanz werden informiert. Dabei ist ein angemessener Zeitraum für die Information der Teilnehmer zu wählen (z.B. drei Monate vor Einstellung der Tätigkeit). Weiter müssen alle Zertifikate rechtzeitig widerrufen
und die privaten Schlüssel der Zertifizierungsstelle zerstört werden.
76
Kapitel 3. Analyse
3.8. Technische Sicherheitsmaßnahmen - CPS
Dieser Abschnitt beschreibt die Sicherheitsmaßnamen für den Schutz des privaten Schlüssel. Des Weiteren wird auf den Umgang und die Auslieferung der
Schlüsselpaare eingegangen sowie Gültigkeitszeiträume für die Nutzung der
Zertifikate festgelegt.
3.8.1. Schlüsselerzeugung und Installation
Dieser Abschnitt wird die Erzeugung des Schlüsselpaares und deren Installation sowie den Umgang mit den privaten Schlüsseln näher betrachten.
Schlüsselerzeugung
Die Erzeugung der Schüsselpaare der RootCA und der Zertifizierungsstellen
wie auch der für die PKI eingesetzten Datenverarbeitungssysteme sollte auf
Systemen durchgeführt werden, die über keinen Netzwerkzugang verfügen.
Übermittlung des privaten Schlüssels an den Zertifikatnehmer
Die Übermittlung der Zertifikate und der privaten Schlüssel wird in zwei Fällen gestattet.
Für die automatische Zertifikaterzeugung:
Dabei wird dem Zertifikatnehmer das Zertifikat und der private Schlüssel in
einem mit dem Masterpasswort gesicherten PKCS#12 Container zugestellt.
Die Zustellung erfolgt entweder mit der Ablage des Containers im jeweiligen
Home-Verzeichnis des Zertifikatnehmers oder mit dem Versand des Containers
per signierter E-Mail.
Für die Server-seitige Schlüsselgenerierung:
Dabei wird dem Zertifikatnehmer das Zertifikat und der private Schlüssel in
77
Kapitel 3. Analyse
einem PKCS#12 Container im öffentlichen Portal der jeweiligen Zertifizierungsstelle bereitgestellt29 .
Auslieferung des öffentlichen Schlüssels an den Zertifikataussteller
Der Zertifizierungsantrag des Zertifikatnehmers wird durch die zuständige Registrierungsstelle der Zertifizierungsstelle übermittelt. Dabei können Übertragungsmedien wie Wechseldatenträger (CDROM, USB Stick etc.) oder eine gesicherte Netzwerkverbindung (SSH, SSL, VPN) verwendet werden.
Auslieferung des öffentlichen CA-Schlüssels
Die Teilnehmer der FB-PKI/FH-PKI können die öffentlichen Schlüssel, eingebettet in ein entsprechendes Zertifikat, von allen Instanzen (inklusive der
RootCA) über die im Abschnitt 3.4 ”Veröffentlichungen und Verzeichnisdienst”
angegeben Quellen beziehen.
Schlüssellängen
Als Signaturverfahren wird der RSA-Algorithmus verwendet. Die Schlüssellänge sollte bei Zertifizierungsstellen mind. 2048 Bit und bei den restlichen
Schlüsseln mindestens 1024 Bit betragen.
3.8.2. Schutz des privaten Schlüssels
Wird der private Schlüssel der Zertifizierungsstelle auf einem vernetzen System
eingesetzt, so muss dieser Schlüssel für nicht autorisierte Personen unlesbar im
Dateisystem abgelegt werden. Eine Teilung des privaten Schlüssels zwischen
der RootCA und den untergeordneten Zertifizierungsstellen ist nicht erlaubt.
29
Der PKCS#12 Container ist durch ein Passwort gesichert das bei der Antragstellung
angegeben wurde.
78
Kapitel 3. Analyse
Aktivierung der privaten Schlüssel
Private Schlüssel werden durch eine PIN gesichert. Die Aktivierung des privaten Schlüssels erfolgt erst durch die Eingabe des PIN. Um eine zusätzliche
Sicherheit zu erlangen, kann bei privaten Schlüsseln, die über die RA ausgeliefert werden, ein zusätzlicher PIN vor dem herunterladen abgefragt werden.
3.8.3. Weitere Aspekte des Schlüsselmanagements
In diesem Abschnitt werden weitere Themen in Bezug auf das Schlüsselmanagement näher betrachtet.
Archivierung öffentlicher Schlüssel
Öffentliche Schlüssel müssen im Verzeichnisdienst und auf den Onlineportalen
regelmäßig für die Datensicherung archiviert werden. Dafür zuständig sind die
jeweiligen Systemadministratoren der Instanzen der PKI.
Gültigkeit von Zertifikaten und Schlüsselpaaren
Die RootCA und deren untergeordnete Zertifizierungsstellen und ausgestellten
Zertifikate sind für folgenden Gültigkeitszeiträumen vorgesehen:
• Wurzel-Zertifikat der RootCA: max. 13 Jahre
• Zertifikate für untergeordnete Zertifizierungsstellen: max. 7 Jahre
• alle anderen Zertifikate außer den der Studenten: max. 2 Jahre
• die Gültigkeitsdauer der Studenten-Zertifikate: die Regelstudienzeit plus 4 Semester (6 + 4 Semester = 5 Jahre).
Hinweis: Da es nicht möglich ist, ein Zertifikat auszustellen, das mit der
eigenen Lebensdauer die der Zertifizierungsstelle überschreitet, ergibt sich folgendes Bild für die Re-Zertifzierung, will man die maximale Lebensdauer der
79
3.9. Konformitätsprüfung - CP
Kapitel 3. Analyse
ausgestellten Zertifikate ausschöpfen. Die RootCA muss nach 6 Jahren und
untergeordnete Zertifizierungsstellen nach 2 Jahre erneuert werden.
Aktivierungsdaten
Für die Passwörter bzw. PINs zur Aktivierung von privaten Schlüsseln sollten
keine einfachen Kombinationen aus alphanumerischen Zeichen und Sonderzeichen gewählt werden. Die Länge muss mindestens 8 Zeichen betragen30 . Nähere
Informationen zu dem Thema PIN siehe Kapitel 4 ”Praktische Umsetzung”.
3.9. Konformitätsprüfung - CP
Konformität bedeutet, dass jede Zertifizierungsstelle innerhalb der FB-PKI/FHPKI in allen Abläufen den Regeln der CP und CPS entsprechen muss. Die
Frequenz und die Umstände der Überprüfung wird durch die zuständigen Zertifizierungsstellen geregelt. Darüber hinaus kann eine Zertifizierungsstelle die
untergeordneten Zertifizierungs- und Registrierungsstellen auf die Einhaltung
der von ihr vorgegebenen Regeln prüfen. Das heißt, sie kann den Prüfer selbst
stellen oder von einem Dritten anfordern31 . Dies liegt ganz im Ermessen der
jeweiligen Zertifizierungsstelle. Des Weiteren sollten die zu überprüfenden Bereiche von der Zertifizierungsstelle festgelegt werden, wobei kritische Bereiche
regelmäßig einer Prüfung unterzogen werden sollten. Dabei auftretende Mängel müssen in Übereinstimmung mit der zuständigen Stelle umgehend beseitigt
werden. Die Prüfung der RootCA wird durch eine, noch festzulegende, Instanz
des Fachbereichs bzw. der Fachhochschule durchgeführt.
30
Anmerkung: Für die PINs der RootCA und der untergeordneten Zertifizierungsstellen
muss bei der Vergabe besondere Umsicht walten. Empfohlen wird eine Länge von min-
31
destens 10 Zeichen.
Eine Selbstprüfung ist nicht erlaubt.
80
Kapitel 3. Analyse
3.10. Rahmenvorschriften - CP
3.10. Rahmenvorschriften - CP
In den Rahmenvorschriften geht es in erster Linie um rechtliche Fragen und
Verpflichtungen, die von der herausgebenden Zertifizierungsstelle garantiert
werden. Dies gehört in den Bereich der Rechtswissenschaft und wird deshalb
in dieser Arbeit nicht weiter behandelt.
In dem zurückliegenden Kapitel 3 ”Analyse” wurden Regelungen und Fragen
besprochen die in der Planung einer produktiven Public Key Infrastruktur
mit einfließen sollten. Dabei wurden Aussagen über den Aufbau, und die Anwendungsbereiche der PKI sowie über die Identifizierung, Authentifizierung
und Veröffentlichung von Zertifikaten gemacht. Weiter wurde näher auf eine
mögliche Ablauforganisation und das Thema der Sicherheitsmaßnamen eingegangen. Betrachtet man diese Themen als Ganzes, ergibt sich ein Gesamtbild
für die Umsetzung einer PKI. Dabei soll an dieser Stelle angemerkt werden,
dass Aufgrund der Komplexität und Umfang dieses Themas nicht alle Teile,
die in der RFC vorgegeben wurden, in letzter Konsequenz behandelt werden
konnten32 . Darunter fiel unter anderen eine genauere Prüfung der sicherheitstechnischen Maßnahmen und die Festlegung von Regelungen in Bezug auf das
Personal sowie die Verantwortlichkeiten innerhalb der PKI oder die Fragen
nach einer Archivierung der Daten und Logdateien. Des Weiteren wurde das
Thema der möglichen Vorgaben und Erweiterungen innerhalb der Zertifikate
und CRLs ausgeblendet (Certificate and CRL Profile) und die Fragen nach
einer Konformitätsprüfung sowie die Rahmenvorschriften nur am Rande behandelt. Wie schon weiter oben mehrmals erwähnt, müssen demzufolge für die
Umsetzung einer produktiven PKI innerhalb des Fachbereichs oder der gesamten Fachhochschule, die in diesem Kapitel gemachten Aussagen einer weiteren
32
Nicht alle Themen waren in der momentanen Planungsphase relevant.
81
Kapitel 3. Analyse
Kontrolle unterzogen und für das jeweilige Anwendungsfeld weiter verfeinert
und erweitert werden.
82
4. Praktische Umsetzung
Dieses Kapitel dokumentiert die Arbeiten am Prototypen einer Zertifizierungsstelle. Für die Entwicklung wird ein Laborrechner verwendet. Dieser ist mit
einer Intel Pentium 4 CPU 2,6GHz Taktfrequenz sowie 1GByte Hauptspeicher
und 80GByte Festplattenspeicher ausgestattet. Weiter ist als Betriebssystem
Windows XP Professional (Version 2002) mit Service Pack 2 installiert. Auf
Basis dieser Ausstattung ist VMWare 4.5 mit einer 365-Tage-Lizenz aufgespielt
welches für die Umsetzung des Prototypen, verteilt auf mehreren virtuellen Maschinen, eingesetzt wird. In jeder virtuellen Maschine läuft eine SuSE Linux
Version 9.31 .
4.1. Einführung
In einem ersten Schritt wurden verschiedene Lösungsansätze im Open SourceBereich betrachtet, die sich mit der Umsetzung und Handhabung der Prozesse
in einer PKI beschäftigen. Dabei wurden TinyCA und XCA getestet, die jeweils ein Interface für OpenSSL implementieren. Bei vertiefenden Tests der
beiden Lösungen auf ihre Anwendbarkeit in größeren Infrastrukturen wurde jedoch festgestellt, dass sie für den beabsichtigten Zweck völlig ungeeignet sind. Grund dafür waren die nicht vorhandene LDAP-Unterstützung, aber
auch der offensichtlich fehlende Ansatz einer Philosophie des Einsatzes in großflächigen Infrastrukturen. Die nun folgenden Ausführungen beziehen sich auf
1
Für weitere Informationen zu den Voraussetzungen bitte den Abschnitt 4.2.2 ”Voraussetzungen” einsehen
83
4.2. Eigenschaften von OpenCA
Kapitel 4. Praktische Umsetzung
die Umsetzung des Prototypen einer Zertifizierungsstelle unter Verwendung
von OpenCA. Dieses Projekt bietet den bisher einzigen ernst zu nehmenden
Ansatz für die Implementierung großer Public Key Infrastrukturen im Open
Source-Bereich.
Das OpenCA-Projekt wird seit 1999 vorangetrieben und ist seit der Version
0.9.02 im produktiven Einsatz. Ziel der Entwicklung ist das Erreichen eines
Maximums an Flexibilität, um große Organisationen wie eine Universität, öffentliche Einrichtungen oder Firmen zu unterstützen. Das System wird bereits
produktiv eingesetzt, z.B. an der T.U. München3 , an der Fakultät Elektrotechnik und Informationstechnik der Humboldt Universität Berlin4 und der City
of Sunderland / UK5 .
4.2.1. Funktionsübersicht
In erster Linie ist OpenCA webbasiert. Dies gibt dem System im Netzwerk die
nötige Flexibilität, um dezentral in eine existente Infrastruktur eingebettet zu
werden. Diese Flexibilität ist auch eine der größten Stärken der Anwendung.
Es besteht die Möglichkeit, alle Interfaces, Datenbanken und den LDAP-Server
auf einer Maschine zu betreiben. Man kann aber auch jedes Interface auf einem
eigenen Server mit eigenen Datenbanken und LDAP betreiben. Mit anderen
Worten: Das System ist äußerst skalierbar und somit für kleine wie auch große
Netzwerke einsetzbar. Im Folgenden werden kurz ein paar der wichtigsten Features aufgeführt.
2
3
4
5
Veröffentlicht im Jahr 2002, zur Zeit dieser Arbeit befindet sich die Entwicklung beim
Stand 0.9.2.5.
http://www.ldv.ei.tum.de
http://ca.hu-berlin.de/
http://www.diginus.co.uk/
84
• PUBLIC-Interface
• LDAP-Interface
• RA-Interface
• CA-Interface
• SCEP-Unterstützung
• OCSP-Unterstützung
• IP-Filter für Interfaces
• Passwort-basierendes Login
• Zertifikat-basierendes Login
• Rollen-basierte Zugriffskontrolle
• Unterstützung für alle gängigen Browser
• Client-seitige Schlüsselerzeugung
• Server-seitige Schlüsselerzeugung
4.2.2. Voraussetzungen
OpenCA ist auf jedem Unix/Linux basierenden Betriebssystem lauffähig, wenn
folgende Systemvoraussetzungen gegeben sind:
Grundsätzliche Software-Voraussetzungen:6
• Apache
• mod_ssl
• OpenSSL + OpenSSL devel + PerlOpenSSL
6
Aus [CB05] entnommen.
85
• OpenLDAP
• MySQL
• Perl
Die folgenden Ausführungen zu den Softwarevoraussetzungen beziehen sich
speziell auf die SuSE Distribution7 , unter der der Prototyp aufgesetzt wurde:
Installierte Paketgruppen unter SuSE:
• Compiler-Werkzeuge
• einfacher Webserver mit Apache
• LDAP-Server und Werkzeuge
• Netzwerkserver
Zusätzlich:
• Grafisches Grundsystem
• phpMyAdmin
4.2.3. Aufbau von OpenCA
OpenCA ist modular aufgebaut und bietet so die Möglichkeit der dynamischen
Verteilung der einzelnen Komponenten in eine schon existierende Infrastruktur. Dieser Abschnitt soll dazu dienen, dem Leser einen Überblick über den
Aufbau der einzelnen Komponenten und deren Zusammenhänge innerhalb von
OpenCA zu geben. Dabei soll die Abbildung 4.1 als Basis für die weiteren
Betrachtungen dienen.8
7
8
Gilt für die SuSE 9.3.
Für weitere Information der Möglichkeiten der Interfaces von OpenCA wird auf den
organisatorischen Anhang Abschnitt B.3 ”Benutzeranleitung OpenCA” hingewiesen.
86
CA
Nutzerdaten
PKCS#12
CA
Batch
Zertifikate manuell ausstellen,
zurückrufen,CRLs erstellen
Zertifikate automatisch
ausstellen und zurückrufen
Zertifikate
CRLs
Node
Daten export/import
von und zur RA/CA
RA
LDAP
Zertifikate
CRLs
Zertifikate
CRLs
RA
Anträge annehmen und
freigeben.
PUB
SCEP
eigene Zertifikate verwalten
fremde Zertifikate suchen
CA Informationen abrufen
Zertifikate beantragen und
herunterladen sowie CRLs
beziehen.
Zertifikate
CRLs, Keys
CRT
CRLs
CRTs
Abbildung 4.1.: Interner Aufbau von OpenCA
PUB
Das PUBLIC-Interface ist die zentrale Anlaufstelle für alle Zertifikatnehmer
der Zertifizierungsstelle. Dabei stellt es dem Nutzer alle wichtigen Dienstleistungen zur Verfügung, z.B. das Beantragen eine Zertifikates, das Einsehen aller
gültigen und verworfenen Zertifikate der Zertifizierungsstelle, das Herunterladen von CRLs und den Wurzelzertifikaten sowie das Einsehen der Policy.
SCEP
Der SCEP-Dienst (Cisco Simple Certificate Enrollment Protocol) dient zum
automatischen Abrufen von Zertifikaten und Zertifikat-Sperrlisten (CRLs) durch
87
Netzwerkkomponenten, die das SCEP-Protokoll9 unterstützen.
RA
Das RA-Interface stellt alle wichtigen Dienste für den Betrieb einer Registration Authority (RA) innerhalb der Zertifizierungsstelle zur Verfügung und ist
sozusagen die Schnittstelle für die Annahme von Anträgen und die Veröffentlichung der Zertifikate.
NODE
Die Node ist zum einen ein Interface, von dem aus man alle anderen Schnittstellen der Zertifizierungsstelle erreichen kann. Zum anderen kann man darüber den Datenaustausch zwischen verschiedenen Ebenen der Hierarchie einer
Zertifizierungsstelle abwickeln. Eine weitere wichtige Aufgabe besteht in administrativen Zwecken wie Initialisierung der Datenbank oder auch Backup- und
Wiederherstellungsfunktionen.
CA
Das CA-Interface stellt alle wichtigen Dienste für den Betrieb einer Certification Authority (CA) innerhalb der Zertifizierungsstelle zur Verfügung und ist
sozusagen die Schnittstelle für das Signieren und Sperren der Zertifikate sowie
das Erstellen entsprechender CRLs.
BATCH
Die Batch ist eine Status-Maschine zum vollautomatischen Generieren von
Schlüsselpaaren inklusive Zertifkaten. Weiterhin existiert ein BATCH-Interface,
mit dem man die Aktionen des Batch-Prozessors steuern kann.
9
Ist ein von Cisco und VeriSign entwickeltes Protokoll zur Verteilung von Zertifikaten.
88
4.3. Planung einer Zertifizierungsstelle
In diesem Abschnitt wird am Beispiel der User CA die interne Infrastruktur
einer einzelnen Zertifizierungsstelle auf Basis einer Umsetzung mit OpenCA
behandelt. Zunächst wird dabei auf die verfügbaren Komponenten eingegangen
und danach auf den eigentlichen Aufbau der internen Struktur.
4.3.1. Komponenten
Die interne Infrastruktur einer Zertifizierungsstelle gliedert sich in folgende
Komponenten:
• CA (Zertifizierungsstelle)
Manuelles ausstellen und zurückrufen von Zertifikaten sowie erstellen der
CRLs.
• BATCH
Automatisches ausstellen der Zertifikate.
• RA (Registrierungsstelle)
Annehmen und freigeben von Anträgen sowie weiterleiten dieser an die
CA.
• PUB (Public-Interface)
Verwalten der eigenen Zertifikate, suchen fremder Zertifikate, abrufen
der CA-Informationen, einsehen der Policy, erstellen von Anträge etc.
• LDAP
Ablage für Zertifikate und CRLs in einem zentralen LDAP-Server.
• NODE
Schnittstelle zwischen den verschiedenen Ebenen der Hierarchie bei Offline/ Onlinetrennung.
• MYSQL-Datenbank
Zentraler Speicher für Zertifikate, CSRs, CRRs und CRLs.
89
4.3.2. Aufbau
Bei der Vorstellung einer praktikablen Lösung des Aufbaus einer Zertifizierungsstelle sollen in erster Linie die Darstellung der Zusammenhänge Abbildung 4.2 und die Verteilung der einzelnen Komponenten innerhalb der Zertifizierungsstelle Abbildung 4.3 verdeutlicht werden.
Online RA
Zugriff von Extern:
Anträge, CRLs etc.
IP = *.*.*.*1
DNS = melchior
Export/Import der der CRLs,
CRTs, CRRs, CSRs über das
Node. Medium = Diskette,
USB-Stick oder SCP
Offline CA
IP = *.*.*.*0
DNS = kaspar
Interface:
PUB, RA, LDAP,
SCEP, NODE
Interface:
CA, BATCH,
NODE
Dienste
MYSQL
Dienste
MYSQL
Zertifizierungsstelle
EXTERN
Veröffentlichung aus RA
der Zertifikate und CRLs in
internen LDAP des
FAchbereiches
IP = *.*.*.*2
DNS = balthasar
Dienste:
DNS
LDAP
Abbildung 4.2.: Aufbau der Zertifizierungsstelle
In diesem Szenario wird von einem hohen Sicherheitsniveau ausgegangen. Die
CA ist als eine Offline-CA implementiert und verfügt über keinerlei Netzwerkanbindung10 . Ist der Rechner, auf dem sich die CA befindet, auch in einem
Bereich aufgestellt, der strengen Kontrollen unterworfen ist, kann man von einem hohen Grad an Sicherheit ausgehen, da wirklich nur autorisierte Personen
Zugriff auf diesen Teil der Infrastruktur bekommen. Weiterhin sind die Datenbanken der einzelnen Hierarchien strikt voneinander getrennt und können
10
Alternativ können die Netzwerkverbindungen bei Bedarf (z.B. Import/Export) automatisch gestartet und wieder gestoppt werden Ähnlich dem Öffnen und Schließen einer
Zugbrücke.
90
nur über einen manuellen Import und Export von Daten mittels eines physikalischen Mediums (Diskette/ USB-Stick; oder wie beim Prototypen der Fall
SSH/SCP) abgeglichen werden.
Anmerkung: Das PUBLIC-Interface sollte auf dem RA-Server laufen, kann
aber aus Gründen der Sicherheit (Kompromittierung des RA-Servers) auf einen
eigenen Server, der von außen erreichbar ist, ausgelagert werden. Dabei ist jedoch zu beachten, dass diese öffentliche Instanz über eine eigenen Datenbank
verfügen müsste, die wiederum mit der Datenbank des RA-Servers abgeglichen
werden muss, um zugelassene Zertifikate, CSRs und CRLs zu veröffentlichen.
Was wiederum einen zusätzlichen Aufwand bedeuten würde.
Um nun die internen Details der einzelnen Prozesse innerhalb der Zertifizierungsstelle aufzuzeigen, soll im Folgenden der Gegebene Aufbau in Abbildung
4.3 konkretisiert werden.
Online-RA
Die Online-RA ist die Schnittstelle zwischen den Nutzern der Zertifizierungsstelle und der Offline-CA. Der Austausch von Informationen z.B. Zertifikate, CRLs, Policy etc., erfolgt ausschließlich über das PUBLIC-Interface. Dieses wiederum bezieht seine Daten aus der lokalen Datenbank (Zertifikate,
CRLs) und dem /OPENCADIR/var/ Verzeichnis (Policy und Root Zertifikate). Die im PUBLIC-Interface gestellten Zertifikatsanträge oder Anträge auf
Sperrung werden in der lokalen Datenbank der RA abgespeichert. Durch das
RA-Interface, hat der RA-Operator die Möglichkeit, die eingegangen Anträge zu prüfen und gegebenenfalls anzupassen. Ist anschließend der Antrag genehmigt, wird dies in der Datenbank vermerkt11 . Sollen nun die Daten an
die Offline-CA weitergereicht werden, geschieht das über das NODE-Interface.
Mit diesem Interface kann der RA-Operator alle relevanten Daten (im Speziellen die Zertifikatanträge) an die Offline-CA exportieren (Export in eine
11
Dieser Vermerk wird erst für die CA wieder interessant.
91
Online-RA
Zugriff von
Extern: Anträge,
CRLs, Zertifikate
Policy, Root Zert.
etc.
Download CAZert. und CRLs
PUB
Veröfentlichung
und Download
der Zertifikate
IP = *.*.*.*1
DNS = melchior
/var
Import von CA
CSRs, CRRs usw.
NODE
Import/Export von/zu CA
MYSQL
Zulassen der
CSRs und
CRRs
RA
Veröffentlichen
derZertifikate und
CRLs
LDAP
Import der
Batch
Konfiguration
BATCH
PKCS#12
Rollout
/var
Export zu RA
Ablage der
erstellten
Zertifikate
NODE
Import/Export von/zu RA
CA
MYSQL
Signieren der
CSRs, erstellen
der CRLs
Offline-CA
IP = *.*.*.*0
DNS = kaspar
EXTERN
IP = *.*.*.*2
DNS = balthasar
Dienste:
DNS
LDAP
der interne LDAP-Server
des Fachbereichs
Abbildung 4.3.: Interner Aufbau der Zertifizierungsstelle
höhere Ebene der Hierarchie). Dazu bezieht der Exportprozess die benötigten
Daten aus der lokalen Datenbank und erzeugt daraus ein Archiv. Ist dieser
Prozess abgeschlossen, muss das Archiv anschließend an die Offline-CA übertragen werden. Weiterhin gibt das auf der Online-RA laufende LDAP-Interface
92
dem RA-Operator die Möglichkeit, alle in der lokalen Datenbank befindlichen
Zertifikate und CRLs auf einem LDAP-Server zu veröffentlichen.
Offline-CA
Die Offline-CA ist der zentrale Bereich der Zertifizierungsstelle, der nur von
autorisierten Personen erreicht werden darf12 . Dabei stellt das NODE-Interface
die Schnittstelle zur Außenwelt dar. Über dieses finden die Importe/Exporte
von/zur RA statt. Kommt es zu einem Import so werden die Daten (z.B. CSRs
oder CRRs) aus dem Archiv extrahiert und in die lokale Datenbank übertragen. Anschließend können nun z.B. die neuen Anträge vom CA-Operator im
CA-Interface eingesehen und signiert werden wobei die signierten Zertifikate
wiederum in der lokalen Datenbank abgelegt werden13 . Sollen die von der CA
signierten Zertifikate veröffentlicht werden, muss wieder im NODE-Interface
ein Export an eine niedrigere Ebene der Hierarchie ausgelöst werden. Das daraus entstandene Archiv wird daraufhin zur Veröffentlichung an die Online-RA
übertragen, die dieses in ihrem eigenen NODE-Interface wiederum importiert.
Damit werden durch diesen Prozess die Daten in die eigene lokale Datenbank
der Online-RA eingespielt und somit für die Öffentlichkeit über das PUBLICInterface erreichbar.
EXTERN
Der EXTERN-Host stellt externe Dienste zur Verfügung, welche die Zertifizierungsstelle in Anspruch nimmt. In erster Linie ist dies ein Verzeichnisdienst,
der den zentralen LDAP-Server innerhalb des Fachbeichs darstellt. Dieser wird
über OpenLDAP realisiert und besitzt als Wurzel DC=fh-wiesbaden, DC=de.
Weiter wird der Baum für die Nutzung an der Zertifizierungsstelle folgendermaßen aufgespannt: OU=Users, DC=cs, DC=fh-wiesbaden, DC=de.
12
13
Je nach Sicherheitsniveau kann sich dabei die CA innerhalb eines Netzwerkes befinden.
Wird ein Batch-Prozess angestoßen so werden die dabei erzeugten Zertifikate auch in der
Datenbank abgelegt.
93
4.4. Installation
4.4. Installation
Die folgenden Abschnitte behandeln die Arbeiten an dem Prototypen und dessen praktischer Umsetzung. Als erstes wird auf die Installation von OpenCA
eingegangen.
Die erstmalige Installation und Konfiguration von OpenCA stellte sich als eine sehr langwierige und aufwendige Arbeit heraus. Aus diesem Grund sollen
in diesem und den folgenden Abschnitten die gewonnenen Erkenntnisse und
Erfahrungen erläutert werden, um so das spätere Nachvollziehen der Installation und Konfiguration so einfach wie möglich zu gestalten. Da es jedoch
keine deutschsprachige Beschreibung des Installations-Prozesses gibt, stützen
sich die Ausführungen hauptsächlich auf die englischen Dokumentationen von
OpenCA14 [CB05].
Zu Beginn sind die aktuellen Sources von OpenCA unter www.openca.org zu
beziehen15 . Nach dem Herunterladen und Entpacken des Paketes müssen die
drei üblichen Schritte configure ,make und make install durchgeführt werden.
Da aber einige Eigenheiten und Optionen zu beachten sind, soll in den folgenden Unterabschnitten näher auf die Details eingegangen werden.
4.4.1. Configure
In diesem Abschnitt wird auf die Beschreibung der Optionen eingegangen, die
configure mit übergeben werden können, um die Installation auf die Gegebenheiten des Systems, auf dem OpenCA aufgesetzt werden soll, anzupassen.
–with-openssl-prefix=DIR
Als Parameter wird die Pfadangabe von OpenSSL angegeben16 . Wenn der Pfad
von OpenSSL in die globalen Pfade eingetragen ist, ist diese Angabe notwendig.
14
15
16
Diese ist in vielen Punkten nicht aktuell oder unvollständig.
Zur Zeit der Erstellung dieses Dokumentes ist die aktuelle Version 0.9.2.5.
Bei SuSE ist OpenSSL unter /usr/bin/ zu finden.
94
4.4. Installation
–with-language=LANGUAGE
Hier kann eine spezielle Sprache angegeben werden, in der OpenCA installiert
werden soll. Folgende Übersetzungen stehen zur Verfügung17 :
• de_DE = Deutsch
• es_ES = Spanisch
• fr_FR = Französisch
• it_IT = Italienisch
–with-openca-user=ARG / -group=ARG
OpenCA installiert eine Reihe von Dateien, die nicht vom Webserver her zugänglich sein sollten. Normalerweise werden diese für den User Root und die
Gruppe Root installiert. Wenn dies nicht der Fall sein soll und z.B. ein spezieller User oder eine spezielle Gruppe für OpenCA existiert, kann hier der
User (-user=ARG) und die Gruppe (-group=ARG) angegeben werden, welchem/welcher der Zugriff gestattet werden soll.
Dateisystem Pfade
–with-module-prefix=DIR
Dieser Parameter ist eine Pfadangabe für den Installationsort der Perlmodule, die von OpenCA verwendet werden sollen. Diese Angabe ist insbesonders
nützlich, wenn OpenCA zu einem späteren Zeitpunkt wieder entfernt oder auf
einem System mehrere Versionen von OpenCA installieren werden sollen18 .
–with-openca-prefix=DIR
OpenCA enthält eine Verzeichnisstruktur, die alle Daten an einem zentralen
Ort speichert. Dieser Ort kann durch die Angabe von –with-openca-prefix=DIR
spezifiziert werden. Weiterhin kann man, wenn dies gewünscht ist, durch die
17
18
Ohne die Angabe einer Sprache wird OpenCA Standardmäßig in Englischer Sprache
installiert.
Ohne die Angabe des module-prefix werden alle Module unter /usr/lib/perl5/ installiert.
95
4.4. Installation
Prefixe –with-etc-prefix=DIR, –with-lib-prefix=DIR und –with-var-prefix=DIR
die Pfade für die Verzeichnisse /etc, /lib und /var auf die verwendete Distribution anpassen. Werden diese Schalter nicht verwendet, werden die für die
/etc, /lib und /var vorgesehenen Dateien in das Heimatverzeichnis, das mit
–with-openca-prefix angegeben wurde, abgelegt.
Um Übersichtlichkeit und eine saubere Deinstallation von OpenCA zu gewährleisten wird vom Autor empfohlen, alle Dateien für OpenCA in einem einzigen
Verzeichnis zu halten.
Angabe der IDs für die Module
Mit den folgenden Optionen kann man den Zahlenraum und die ID der einzelnen Module vorgeben, die unter OpenCA verwendet werden sollen. Wird diese
Option nicht verwendet, werden den Modulen Standard-IDs zugewiesen. Näher darauf eingegangen wird im technischen Anhang Abschnitt A.1.5 ”Module
Konfiguration”.
• –with-module-shift=INT
Hier wird der Zahlenraum angegeben, in dem die IDs für die Module
vergeben werden sollen.
• –with-ra-module-id=INT
Hier wird eine ID für das RA-Modul im oben angegeben Zahlenraum
angegeben.
• –with-pub-module-id=INT
Hier wird eine ID für das PUB-Modul im oben angegeben Zahlenraum
angegeben.
Anmerkung: Es ist möglich, die ID noch nachträglich in der config.xml abzuändern. Weitere Informationen zu diesem Thema können im technischen
Anhang Abschnitt A.1 ”config.xml” entnommen werden.
96
4.4. Installation
Spezielle Webserver Optionen
Die Webserver-Konfiguration besitzt für die Konfiguration eines normalen Webservers vier Basisoptionen. Will man OpenCA in ein schon vorhandenes Portal
eingliedern, stehen zusätzlich auch Optionen zur Verfügung, um die Installation detailliert an das vorhandene System anzupassen.
Server-Informationen
Jeder Webserver benötigt Basisinformationen wie den Hostnamen oder Angaben über die Gruppe oder den User, welche/welcher auf dem System den
Webserver ausführen dürfen. Diese Optionen werden im Folgenden näher behandelt.
• –with-web-host=HOST
Hostname des Webservers, auf dem OpenCA betrieben werden soll.
• –with-httpd-user=USER
User, mit dem der Webserver Server-seitig z.B. PHP-Scripte ausführen
darf oder auf Bereiche des Filesystems lesend und schreibend zugreift.
• –with-httpd-group=GROUP
Gruppe, mit der der Webserver Server-seitig z.B. PHP-Scripte ausführen
darf oder auf Bereiche des Filesystems lesend und schreibend zugreift.
• –with-httpd-fs-prefix=DIR
Pfadangabe, in welchem sich Apache innerhalb des Filesystems befindet.
Filesystem-Pfade
In den Optionen für die Pfade innerhalb des Filesystems kann angegeben werden, wohin der Inhalt der verschiedenen Interfaces und Module eingespielt
werden soll. Dabei stehen folgende Hauptoptionen zur Verfügung:
• –with-cgi-fs-prefix=DIR
Angabe des durch den Webserver verwendeten CGI-Verzeichnisses.
97
4.4. Installation
• –with-htdocs-fs-prefix=DIR
Angabe des durch den Webserver verwendeten HTDOCS-Verzeichnisses.
Anmerkung: ohne die Angabe der Präfixe werden die Daten in /usr/local/apache/
gespeichert.
Angepasste Installation
OpenCA ist für den Einsatz in großen Organisationen entwickelt. Diese haben
gewöhnlich Online-Portale für ihre Mitarbeiter und Kunden. Wenn vorgesehen
ist, OpenCA in ein solches Portal zu integrieren, ist es ist nicht nötig, Pfade und
Links per Hand zu setzen. Der Ort für die CGI- und HTDOCS-Verzeichnisse
für jedes Interface von OpenCA können separat angegeben werden. Die Option
- –with-
ca-|ra-|ldap-|pub-|node-|scep-
-
cgi-|htdocs-
-
fs-prefix
stellt dies zur Verfügung. Dadurch bekommt man die Flexibilität, zu entscheiden, an welche Stelle in der eigenen Infrastruktur Teile von OpenCA abgelegt
werden. Somit wird eine bestmögliche Integration in schon bestehende OnlinePortale gewährleistet.
Verwendete Optionen bei der Installation des Prototypen
In diesem Abschnitt werden die für die Erstinstallation des Prototypen verwendeten Optionen dokumentiert. Der Aufruf19 von configure ist im Listing
4.1 aufgeführt.
19
Achtung: bei den Pfadangaben kein ”/” am Ende angeben da es sonst mit der Konfiguration von OpenCA Probleme gibt.
98
4.4. Installation
./ configure -- with - language = de \ _DE -- with - module - prefix =/ srv / openca / modules
-- with - openca - prefix =/ srv / openca -- with - httpd - user = wwwrun
-- with - httpd - group = www -- with - cgi - fs - prefix =/ srv / www / cgi - bin
-- with - htdocs - fs - prefix =/ srv / www / htdocs
Listing 4.1: Aufruf von ./configure für den Prototypen
Zur näheren Erklärung werden nun die Komponenten des Aufrufs einzeln betrachtet:
• –with-language=de_DE
OpenCA wird in Deutsch installiert.
• –with-module-prefix=/srv/openca/modules
Die Module werden in das Basisverzeichnis /srv/openca von OpenCA
abgelegt.
• –with-openca-prefix=/srv/openca
Das Basisverzeichnis für alle Module.
• –with-httpd-user=wwwrun
Unter SuSE wird Apache mit dem User ”wwwrun” ausgeführt.
• –with-httpd-group=www
Unter SuSE wird Apache unter der Gruppe ”www” ausgeführt.
• –with-cgi-fs-prefix=/srv/www/cgi-bin
Angabe des zentralen CGI-Verzeichnisses, in dem alle Module abgelegt
werden.
• –with-htdocs-fs-prefix=/srv/www/htdocs
Angabe des zentralen HTDOCS-Verzeichnisses, in dem alle Interfaces
abgelegt werden.
99
4.4. Installation
4.4.2. make
Nachdem mit configure die Vorbereitung für den eigentlichen Kompiliervorgang
abgeschlossen ist, kann dieser mit dem Befehl make ausgelöst werden. Ist der
Kompiliervorgang erfolgreich durchlaufen, können anschließend die einzelnen
OpenCA-Komponenten an ihren vorgesehenen Ort installiert werden. Dazu
stehen folgende Optionen zur Verfügung:
• make install-ca
installiert nur die CA.
• make install-ext
hat die gleiche Bedeutung wie install-online. Diese Option hat den Status
deprecated.
• make install-ldap
installiert nur das LDAP-Interface.
• make install-node
installiert nur die NODE.
• make install-offline
installiert CA, BATCH und NODE.
• make install-online
installiert RA, LDAP, PUB, SCEP und NODE.
• make install-pub
installiert nur das PUBLIC-Interface.
• make install-ra
installiert nur die RA.
• make install-scep
installiert nur SCEP.
100
4.4. Installation
• make install-doc
installiert nur die Dokumentation.
Nach der Installation befindet sich das Basisverzeichnis, wenn nicht unter –
with-openca-prefix geändert, unter /usr/local/openca.
4.4.3. Die config.xml-Datei
Nach der Installation sind alle notwendigen Dateien installiert und korrekt im
Dateisystem abgelegt. OpenCA ist jedoch in diesem Zustand noch nicht lauffähig, da die Anpassung der Konfigurationsdateien erst abgeschlossen werden
muss. Es gibt Hunderte von Dateien mit der Endung *.template. Diese Dateien sind jedoch nur Platzhalter für die richtigen Konfigurationsdateien, welche
erst durch das Konfigurieren der /OPENCADIR/etc/config.xml und das anschließende Ausführen des Skriptes /OPENCADIR/etc/configure_etc.sh erzeugt werden müssen. Dabei benutzt das Skript configure_etc.sh die config.xml
als Eingabedatei, wertet diese aus und erstellt mit den erhaltenen Daten die
richtigen Konfigurationsdateien. Dabei ist anzumerken, dass die in der config.xml festgelegten Einstellungen für die Erstinstallation von zentraler Bedeutung sind. Jedoch müssen dabei nicht alle Felder bindend ausgefüllt werden.
Die Hauptaufgabe der config.xml und configure_etc.sh besteht darin, erstmalig
alle Konfigurationsdateien mit sinnvollen Werten zu füllen, um so dem Nutzer
unnötigen Aufwand bei der Erstinstallation zu ersparen. Eine nachträgliche
Änderung und Anpassung der Konfiguration von OpenCA ist nötig20 .
Anmerkung: Es sollte darauf geachtet werden, dass bei jeder neuen Ausführung des configure_etc.sh Skriptes alle Konfigurationsdateien und auch die
darin von Hand vorgenommenen Änderungen überschrieben werden. Deshalb
sollte von einem nachträglichen Durchlauf von configure_etc.sh abgesehen werden, will man die von Hand gemachten Änderungen nicht verlieren.
20
Die wichtigsten, durch configure_etc.sh, erzeugten Konfigurationsdateien werden im technischen Anhang Abschnitt A.3 behandelt.
101
4.4. Installation
Zur näheren Information über die Inhalte der config.xml Datei wird an dieser
Stelle auf den technischen Anhang Abschnitt A.1 ”config.xml” verwiesen.
Anmerkung zur Installation unter SuSE 9.3
Durch einen Fehler im Installationsprozess fehlen Skripte in /usr/local/bin
die zur Ausführung von configure_etc.sh benötigt werden. Diese müssen von
Hand aus dem OpenCA-Source unter src/scripts/ in /usr/local/bin/ umkopiert werden. Zusätzlich sollte vor dem Umkopieren darauf geachtet werden,
die Scripte auch ausführbar zu machen. Dies erreicht man mit dem Aufruf
chmod -R 755, der auf das gesamte Skriptverzeichnis angewendet werden sollte.
4.4.4. Zusammenfassung
In den letzten Abschnitten wurden die einzelnen Optionen, das Kompilieren
und Installieren von OpenCA sowie die anschließende Erst-Konfiguration besprochen. Um den Überblick zu bewahren, soll dem Leser in diesem Abschnitt
noch einmal ein Überblick über den gesamten Prozess der Installation gegeben werden. Dieser kann auf jeden Teil von OpenCA (ob nun Offline- oder
Online-Teil) angewendet werden.
Allgemeine Vorbereitung
1. Installieren der nötigen Pakete (siehe 4.2.2 ”Voraussetzungen”)
2. Starten der Dienste Apache und MySQL
3. Erstellen einer leeren Datenbank für OpenCA
4. Erstellen eines OpenCA Datenbank-Users
Quick Installation
1. Entpacken des OpenCA Archives
2. ./configure + Optionen
102
4.5. Konfiguration
3. make
4. make install-offline|online...
5. Anpassen der config.xml
6. Ausführen des configure_etc.sh Skriptes
7. Starten des OpenCA Servers mit /OPENCADIR/etc/openca_rc start 21
4.5. Konfiguration
OpenCA lässt sich über die durch das configure_etc.sh Skript erzeugten *.conf
Dateien nachträglich anpassen und konfigurieren. Dabei kann in diesem Abschnitt das volle Spektrum der gebotenen Möglichkeiten unmöglich abgehandelt werden. Jedoch soll exemplarisch am Beispiel wichtiger, zu konfigurierender Elemente die grundsätzliche Konfiguration von OpenCA dem Leser näher
gebracht werden22 .
4.5.1. CSRs
Über einen CSR (Certificate Signing Request) wird an eine Zertifizierungsstelle
von einem User der Antrag auf die Erteilung eines Zertifikates gestellt. Dieser Teil wird bei OpenCA über das PUBLIC-Interface abgewickelt. Der nun
folgenden Abschnitt soll sich um die Konfiguration der Felder innerhalb eines
Antrages beschäftigen.
21
22
Stoppen/Neustart des Servers mit openca_rc stop/restart.
Für weitere Detailinformationen sei auf die Dokumentation [CB05], die Onlineresourcen unter [URL6] und dir sehr hilfreiche Mailinglist unter http://www.mailarchive.com/[email protected]/ und den technischen Anhang verwiesen.
103
4.5. Konfiguration
Zertifikatsanträge werden in erster Linie aus dem PUBLIC-Interface an die RA
bzw. CA gestellt. Dabei ist unter anderem der Inhalt, der bei einer Antragstellung abgefragt wird, auch entscheidend für das spätere Einpflegen der Zertifikate in einen LDAP-Server. Die zentrale Konfiguration der unter dem PUBLICInterface verwendeten Zertifikatsanträge befindet sich unter /OPENCADIR/etc
/server/ in der Konfigurationsdatei pub.conf Diese Datei wird nun etwas näher betrachtet23 .
Im Listing 4.2 ist der für die Erstellung der verschiedenen Antragsarten zuständige Ausschnitt aus der pub.conf aufgeführt.
Basic_CSR_Keysizes " 1024 " " 2048 " " 4096 " " 512 " " 768 "
DN_TYPES " BASIC " " SPKAC " " IE "
## = = = = = = = = = = == = = = = = = [ DN_TYPE ::= BASIC ] = = = = = = = = = = = = = = = = = = = = =
DN_TYPE_BASIC_BODY " YES "
D N _ T Y P E _ B A S I C _ K E Y G E N_ M O D E
DN_TYPE_BASIC_BASE
" SERVER "
" OU " " DC " " DC " " DC "
DN _T YP E_ BAS IC _E LE MEN TS " emailAddress " " UID "
DN_TYPE_BASIC_NAME
" Basic User Request "
DN_TYPE_BASIC_BASE_1 " Users "
DN_TYPE_BASIC_BASE_3 " cs "
DN_TYPE_BASIC_BASE_4 " fh - wiesbaden "
DN_TYPE_BASIC_BASE_5 " de "
"E - Mail "
D N_ T YP E _B AS I C_ E LE M EN T_ 1
DN_TYPE_BASIC_ELEMENT_1_MINIMUM_LENGTH 7
DN_TYPE_BASIC_ELEMENT_1_REQUIRED
" YES "
DN_TYPE_BASIC_ELEMENT_1_CHARACTERSET
" EMAIL "
D N_ T YP E _B AS I C_ E LE M EN T_ 2
" Nutzer Name "
DN_TYPE_BASIC_ELEMENT_2_MINIMUM_LENGTH 3
DN_TYPE_BASIC_ELEMENT_2_REQUIRED
" YES "
DN_TYPE_BASIC_ELEMENT_2_CHARACTERSET
" _LETTERS "
DN_TYPE_BASIC_SUBJECTALTNAMES
23
" email " " IP " " DNS " " DNS "
In der Datei ca.conf finden sich ähnliche Teile der Konfiguration, da bei der Initialisierungsphase der CA Anträge für die Zertifizierung der ersten Nutzer über das CA-Interface
erstellt werden können.
104
DN_TYPE_BASIC_SUBJECTALTNAME_1
4.5. Konfiguration
" alternative email "
DN_TYPE_BASIC_SUBJECTALTNAME_1_MINIMUM_LENGTH 3
DN_TYPE_BASIC_SUBJECTALTNAME_1_REQUIRED
" NO "
...
## = = = = = = = = = = = == = = = = = [ DN_TYPE ::= SPKAC ] = = = = = = = = = = = = = = = = = = = = =
DN_TYPE_SPKAC_BODY " YES "
D N _ T Y P E _ S P K A C _ K E Y GE N _ M O D E
" SPKAC "
...
## = = = = = = = = = = = == = = = = = [ DN_TYPE ::= IE ] = = = = = = = = = = = = = = = = = = = = =
DN_TYPE_IE_BODY " YES "
DN _T YP E_ IE _KE YG EN _M ODE
" IE "
...
Listing 4.2: Exemplarischer Ausschnitt der pub.conf
• Basic_CSR_Keysizes
Der Basic_CSR_Keysizes definiert die verfügbaren Schlüssellängen.
• DN_TYPES
Der DN_TYPES gibt an, welche Arten von Anträgen im Pub zur Verfügung gestellt werden sollen.
• DN_TYPE_* DN_TYPE_*
Der DN_TYPE_* DN_TYPE_* spezifiziert die Namensräume, an denen die einzelnen Antragsarten mit ihren Optionen erkannt werden. Bspw.
DN_TYPES ”BASIC” gibt an, dass ein Basisantrag im Pub zur Verfügung
gestellt wird. Die im Basisantrag verfügbaren Eingabefelder werden in
DN_TYPE_BASIC_* definiert.
• DN_TYPE_BASIC_KEYGEN_MODE
Der DN_TYPE_BASIC_KEYGEN_MODE spezifiziert, wo der CSR
generiert werden soll (Client- oder Server-seitig). Folgende Browser werden für die Client-seitige Schlüsselerzeugung unterstützt: Opera, Mozilla,
Netscape und Internet Explorer. Dabei gilt SPKAC für die Benutzung
105
4.5. Konfiguration
von Opera, Mozilla und Netscape, IE für Internet Explorer und SERVER
für alle anderen Situationen24 .
• DN_TYPE_BASIC_BASE
Der BASE-Teil gibt an, welche Elemente durch den Nutzer nicht verändert werden können und in den Antrag übernommen werden. Durch die
Angabe von ”OU” ”DC” ”DC” ”DC” wird festgelegt, dass drei Objekte
vom Typ ”Domain” und ein Objekt vom Typ ”Organisation Unit” die
Basis definieren.
• DN_TYPE_BASIC_BASE_*
Die BASE_numbers gehören zum BASE-Teil und definieren die Werte
für die Elemente, die in dem nicht veränderbaren Teil verwendet werden sollen. Im obigen Beispiel wird der Antrag immer mit der Basis-DN
OU=Users, DC=cs, DC=fh-wiesbaden, DC=de erzeugt. Dies sollte auf jeden Fall beachtet werden, will man später die aus dem Antrag erzeugten
Zertifikate auf einen LDAP-Server übertragen. In diesem Fall sollten die
hier definierten Pfade mit denen des LDAP-Server übereinstimmen.
• DN_TYPE_BASIC_ELEMENTS
Der ELEMENTS-Teil ist der Bereich, dessen Inhalte der Nutzer durch
den Antrag beeinflussen kann. Durch die Angabe von emailAddress UID
wird festgelegt, dass ein Objekt vom Typ ”UID” mit einem Attribut
”emailAddress” angelegt wird. Die korrekte Angabe der Elemente wird
besonders bei der Verwendung eines LDAP-Server sehr wichtig, da die
Reihenfolge den Pfad auf dem LDAP-Server beschreibt, wo die Zertifikate abgelegt werden.
• DN_TYPE_BASIC_ELEMENT_*
Die ELEMENT_numbers gehören mit zum ELEMENTS-Teil und definieren die Werte für die Elemente im veränderbaren Teil. Sie erscheinen
24
Details zu den Antragsarten sind dem Abschnitt 4.9.4 ”CSR Handhabung” zu entnehmen.
106
4.5. Konfiguration
im Antragsformular und werden vom Nutzer bei der Antragsstellung mit
ausgefüllt.
• DN_TYPE_BASIC_SUBJECTALTNAMES
Die SUBJECTALTNAMES sind Teile des Antrages, die nicht ausgefüllt
werden müssen, aber optional vom Nutzer ausgefüllt werden können.
• DN_TYPE_BASIC_SUBJECTALTNAME_*
SUBJECTALTNAME_numbers haben genau die gleiche Aufgabe wie
ELEMENT_numbers.
4.5.2. PKCS#10 Requests
Systeme, die PKCS#10 Zertifikate verwenden, sind z.B. Apache, OpenLDAP,
IMAPD, POPD und SMTPD. Diese Systeme generieren den privaten Schlüssel
selbst. Das heißt, der Administrator generiert den Schlüssel und anschließend
den PKCS#10 Antrag25 . Hat der Administrator den PKCS#10 Antrag erzeugt, wendet er sich damit an die RA.
Die entsprechende Konfiguration in der pub.conf und der Prozess, der nach
Empfang des Antrages stattfindet, wird nun an dieser Stelle beschrieben. Dabei
dient Listing 4.3 als Konfigurations-Beispiel für die Behandlung von PKCS#10
Anträgen im PUBLIC-Interface der RA.
D N _ T Y P E _ P K C S 1 0 _ R E Q U I R E D _ E L E M E N T S " CN " " OU " " O " " C "
DN_TYPE_PKCS10_BASE
"O" "C"
DN_ TYPE _PKC S10_ BASE_ 1 " FH - Wiesbaden "
DN_ TYPE _PKC S10_ BASE_ 2 " de "
Listing 4.3: Exemplarischer Ausschnitt der Konfiguration für PKCS#10
• DN_TYPE_PKCS10_REQUIRED_ELEMENTS
Definition der Struktur des Subjektes des Antrages.
25
Bei diesem Prozess findet keine Interaktion mit CA oder RA statt.
107
4.5. Konfiguration
• DN_TYPE_PKCS10_BASE
Definition des Suffix des Zertifikates, das durch das Interface akzeptiert
wird. So kann verhindert werden, dass fehlerhaft ausgestellte Anträge
(z.B. mit fehlerhaftem Suffix) in das System gelangen.
• DN_TYPE_PKCS10_BASE_*
Definition des Inhaltes des Suffix
Hat der Administrator den PKCS#10-Request nach den Vorgaben der RA erstellt, lädt er diesen mithilfe des vorgesehenen Online-Formulars am PUBLICInterface der zuständigen RA hoch. Ist dieser Vorgang abgeschlossen, prüft
OpenCA anhand des oben gegebenen Konfigurationssauschnittes die Richtigkeit der im PKCS#10 Request angegebenen Daten. Ist der Test erfolgreich,
wird der Request in der Datenbank der RA abgelegt. Somit kann der RAOperator bei der nächsten Einsicht in das RA-Interface den Antrag nach dessen
Genehmigung zum Signieren an die CA weiter senden.
4.5.3. OpenSSL
In OpenCA existieren drei Möglichkeiten für OpenSSL-Einstellungen.
1. Unter /OPENCADIR/etc/openssl/ in der Datei openssl.cnf werden die
Einstellungen für die CA vorgenommen. Diese Datei wird für die Generierung des Initial CA-CSR, dem selbstsignierenden Zertifikat (wenn eine
RootCA betrieben wird) und den CRLs verwendet. Des Weiteren können
hier globale Einstellungen zu Attributen wie Gültigkeitsdauer von Zertifikaten, Standard-Länge der Schlüssel und Zertifikat-Erweiterungen wie
z.B. Verwendungszweck und CRL Bezugsquellen (crlDistributionsPoints)
angegeben werden.
2. Das Verzeichnis /OPENCADIR/etc/openssl/openssl/ beinhaltet die verschiedenen Konfigurationen für die verwendeten Rollen innerhalb von
OpenCA die im Zertifikatantrag gewählt werden können. Darin werden
108
4.5. Konfiguration
spezifisch zu den Rollen ähnliche Punkte wie in der openssl.conf abgehandelt. Dabei ist zu beachten, dass die relevanten Dinge, wie z.B. die
Laufzeit der Zertifikate oder der Algorithmus, der für das Signieren der
Zertifikate verwendet wird, mit der Policy verglichen und gegebenenfalls
angepasst werden sollten.
3. Die im Verzeichnis /OPENCADIR/etc/openssl/extfiles/ abgelegten Konfigurationsdateien definierte entsprechende Zertifikat-Erweiterungen, die
in den Rollen unter OpenCA Verwendung finden.
4.5.4. Datenaustausch
Wird eine PKI mit OpenCA umgesetzt und wird eine klare Trennung zwischen
den verschiedenen Ebenen (Offline/Online Instanzen) von OpenCA betrieben,
so sieht man aus Sicht der Datenbank, dass OpenCA wie ein Baum organisiert
ist. Jeder Knoten stellt eine eigenständige Datenbank mit den entsprechenden Interfaces dar. Um nun den Datenaustausch zwischen diesen getrennten
Knoten zu ermöglichen, wurde das NODE-Interface entwickelt. Das NODEInterface kann Daten von einer höheren Ebene zu den niedrigeren Ebenen der
Hierarchie und umgekehrt, exportieren bzw. importieren.
Exportiert man Daten zu einem höheren Level der Hierarchie (Export RA zu
CA), dann nennt man dies UPLOAD (Hochladen) von Daten. Werden Daten von einer höheren Ebene importiert (Import CA zu RA), so wird dies als
DOWNLOAD (Herunterladen) von Daten bezeichnet. Bei einem Import aus
einem niedrigeren Level (Import RA zu CA) bezeichnet man dies als RECEIVE
(Empfangen) von Daten, beim Export zu einem niedrigeren Level (Export CA
zu RA) als ENROLL (Ausrollen). Dabei wird während des Datenaustausches
das Überschreiben von existierenden Objekten nur bei einem DOWNLOAD
(Import von CA zu RA) von CA-Zertifikaten, CRLs, CSRs und CRRs erlaubt. In allen anderen Situationen ist dies verboten.
Im Folgenden soll durch ein Beispiel ein Überblick über die Möglichkeiten der
109
4.5. Konfiguration
sehr flexiblen Datenaustausch-Konfigurationsmöglichkeiten von OpenCA gegeben werden26 .
Export-/Import-Konfiguration (Export/Import zu/von einem niedrigeren
Level der Hierarchie CA <-> RA)
Die ”dataexchange-section” innerhalb der node.conf ist der zentrale Teil der
Export-/Import-Funktion der CA/RA. Darin wird festgelegt, wohin zu exportierende Daten transportiert bzw. woher zu importierende Daten bezogen
werden. Im Listing 4.4 ist ein Beispiel aus dem Prototypen und dem Datenaustausch von CA zu RA aufgeführt.
## dataexchange with a lower level of the hierarchy
E X P O R T _ I M P O R T _ D O W N _ DE V I C E " openca . tar "
# Das Archiv , in dem die exportierten Daten abgelegt werden .
E X PO R T _ IM P O R T _D O W N _S T A R T
""
E XP O RT _ IM PO R T_ D OW N _S TO P
""
# Hier können je nach Bedarf Laufwerke an - oder abgemeldet werden .
E X P O R T _ I M P O R T _ D O W N _ EX P O R T " / bin / tar - cvpf / srv / openca / var / tmp / @__DEVICE__@
-C @__SRC__@ . " " mv / srv / openca / var / tmp / @__DEVICE__@
/ srv / openca / datenaustausch / "
E X P O R T _ I M P O R T _ D O W N _ IM P O R T " / bin / tar - xvf / srv / openca / var / tmp / @__DEVICE__@ -C
@__DEST__@ "
E XP O RT _ IM PO R T_ D OW N _T ES T
" / bin / tar - tvf / srv / openca / var / tmp / @__DEVICE__@ "
Listing 4.4: Exemplarischer Ausschnitt für Export/Import zu/von einem
niedrigeren Level
Die Export-/Import-Technologie selbst ist ein wichtiger Aspekt von OpenCA.
Es ist möglich, OpenCA für verschiedene Methoden des Datenaustausches mit
höheren und niedrigeren Leveln zu konfigurieren. Daher gibt es verschiedene
Optionen für die Vor- und Nachbereitung von I/O Operationen. Dies ist nötig,
will man für Ex- oder Import spezielle Netzwerkinterfaces oder Laufwerke anbzw. nach der Operation wieder abmelden. Weiter gibt es Optionen für den
26
Die
Konfigurationsdatei
des
oder
der
/OPENCADIR/etc/servers/node.conf.
110
NODE-Interfaces
findet
man
unter
4.5. Konfiguration
EXPORT und IMPORT der Daten und eine Option zum Testen des Ergebnisses der entsprechenden Operation. Des Weiteren kann EXPORT, IMPORT,
START und STOP mehr als ein Argument übergeben werden. Kommt es zur
Abarbeitung der Argumente, wird dabei jedes separat ausgeführt.Die Parameter @__SRC__@ und @__DEST__@ sind Bezeichner für die zu exportierenden
bzw. importierenden Daten und sollten als solche unverändert verwendet werden. Der Parameter @__DEVICE__@ wird durch den String ersetzt, der unter
der Variablen EXPORT_IMPORT_DOWN_DEVICE angegeben wurde.
In dem Listing 4.5 wird nun beim Export durch den Befehl
/ bin / tar - cvpf / srv / openca / var / tmp / @__DEVICE__@ -C @__SRC__@ .
Listing 4.5: Exemplarischer Ausschnitt für den Export-Befehl
die Daten aus @__SRC__@ in das, in @__DEVICE__@ angegebene, Archiv
openca.tar gespeichert und anschließend aus dem temporären Verzeichnis nach
/srv/openca/datenaustausch/ verschoben. Beim Import wiederum werden die
Daten mit dem Befehl
/ bin / tar - xvf / srv / openca / var / tmp / @__DEVICE__@ -C @__DEST__@
Listing 4.6: Exemplarischer Ausschnitt für den Import-Befehl
aus dem openca.tar Archiv extrahiert und an entsprechender Stelle durch die
Import-Funktionen von OpenCA in das System eingespielt.
4.5.5. Zugriffskontrolle
OpenCA beinhaltet seit Version 0.9.2a eine sehr leistungsstarke Zugriffskontrolle. Die Konfiguration dieser ist komplett XML-basierend. Das Root-Element
des XML-Dokumentes ist das openca-Element. Die komplette Konfiguration
der Zugriffskontrolle befindet sich im access_control-Element. Jedes Interface
besitzt dabei seine eigene Konfiguration für die Zugriffskontrolle. Zu finden sind
111
4.5. Konfiguration
die jeweiligen Konfigurationsdateien unter /OPENCADIR/etc/access_control/.
Nachfolgend soll Listing 4.7 zur Erklärung dienen.
< openca >
< access_control >
Die komplette Zugriffskontroll - Konfiguration wird hier
abgelegt .
</ access_control >
</ openca >
Listing 4.7: Exemplarischer Ausschnitt für den Aufbau einer ACL
Die Konfiguration der Zugriffskontrolle besteht aus vier Teilen der ”channel
verification”, dem ”login”, dem ”session management” und der eigentlichen
ACL. Eine weitere Behandlung dieses Themas findet sich im technischen Anhang Abschnitt A.4 ”OpenCA Konfiguration”.
4.5.6. Rollen
OpenCA bietet die Möglichkeit, innerhalb einer Zertifizierungsstelle Rollen zu
definieren. D.h. in diesen Rollen werden verschiedene Parameter (z.B. Lebensdauer, Schlüssellängen oder Algorithmus) für die auszustellenden Zertifikate
festgelegt. So kann an einer Zertifizierungsstelle nicht nur ein Typ von Zertifikaten vergeben werden.
Im Kapitel 3 ”Analyse” wurden schon gewisse Aussagen in Bezug auf Rollen
innerhalb der FB-PKI gemacht. Jedoch wurden diese nicht konkretisiert, um
einen gewissen Handlungsspielraum innerhalb der Umsetzung zu lassen. Da
OpenCA nun die Definition von Rollen ermöglicht, sollen diese für die Umsetzung des Prototypen in der Tabelle 4.1 weiter konkretisiert werden:
112
4.5. Konfiguration
Rolle
Gültigkeit
Algorithmus
Schlüssel
CA-Operator
2 Jahre
RSA
2048
RA-Operator
2 Jahre
RSA
2048
Mitarbeiter
2 Jahre
RSA
1024
Student
5 Jahre
RSA
1024
technische Systeme
2 Jahre
RSA
2048
Tabelle 4.1.: Definition der Rollen innerhalb des Prototypen
Die Basiskonfiguration der verwendeten Rollen wird dabei über drei Konfigurationsdateien geregelt:
• roles.xml
In der Datei roles.xml unter /OPENCADIR/etc/rbac/ werden die Namen
der verwendeten Rollen definiert.
• /OPENCADIR/etc/openssl/openssl/Rollenname.conf
In den Rollenname.conf Dateien werden die Parameter und Attribute
der dem Namen zugehörigen Rolle definiert.
• /OPENCADIR/etc/openssl/extfiles/Rollenname.ext
In den Rollenname.ext Dateien werden die Zertifikat-Erweiterungen der
dem Namen zugehörigen Rolle definiert.
4.5.7. LOA (Level of Assurance)
In Kapitel 3 den Abschnitt 3.5 ”Identifizierung und Authentifizierung” geht
es in erster Linie um die Identitätsprüfung. Dabei wird, um ein hohes Maß
an Sicherheit zu gewährleisten, immer das direkte Prüfen der Identität vorgeschrieben. Dies bedeutet, dass alle durch diese Policy ausgestellten Zertifika-
113
4.5. Konfiguration
te ein gleiches Maß der Vertrauenswürdigkeit besitzen. Geht man von dieser
Basis aus, sollte es auch möglich sein, Zertifikate für verschiedene Vertrauensstufen innerhalb einer Zertifizierungsstelle auszustellen. Hier kommt das
LOA-Konzept ins Spiel. LOA bedeutet ”Grad des Vertrauens” und gewährleistet zusätzlich zu dem Maß des innerhalb der Policy festgelegten Vertrauens
die Möglichkeit der Einführung einer zusätzlichen ”Qualität” der ausgestellten Zertifikate, bezüglich der Identitätsprüfung. Genau genommen besitzt also
eine Policy, wie sie z.B. in der Analyse besprochen wurde, indirekt einen festgelegten ”Level of Assurance”. Müssen nun in einer Policy zusätzlich mehrere
LOAs eingeführt werden, sollten zu jedem LOA dessen Richtlinien in einer
eigenen Sub-Policy, z.B. unterhalb der Root-Policy, festgelegt werden.
Root Policy
Medium
Basic
High
Abbildung 4.4.: Mögliche Aufteilung bei der Einführung von LOA
Ein Beispiel: der Level LOA Medium und High kann z.B. nur an die Rolle
”Mitarbeiter” vergeben werden. Wenn nun ein Mitarbeiter über das PUBLICInterface einen Antrag stellt, wird an dieser Stelle, wenn nicht anders gewünscht, der LOA Medium als Basis verwendet. Dies bedeutet, dass die in
der Sub-Policy zum LOA Medium festgelegten Regelungen gelten und z.B. die
im Antrag befindlichen Daten nicht weiter verifiziert werden müssen. An der
RA wiederum wird anhand des LOA entschieden, was weiter mit dem Antrag
geschehen soll. Im Falle eines LOA Medium wird ohne weitere Prüfung der
Antrag von der RA genehmigt und von der CA zertifiziert. Natürlich können
mit diesem, auf der Basis von LOA Medium ausgestellten Zertifikat, nicht
die gleichen sicherheitskritischen Funktionen erfüllt werden wie z.B. mit ei-
114
4.5. Konfiguration
nem unter LOA High ausgestellten Zertifikat. Diese Einsatzgebiete mit ihren
Einschränkungen, Berechtigungen und Erweiterungen müssen wiederum in der
jeweiligen Policy bzw. Sub-Policy festgelegt werden.
Alles in allem erweitert also das LOA-Konzept eine PKI um eine zusätzliche
Ebene der ”Qualität”. Jedoch ist mit der Einführung von LOA ein enormer
zusätzlicher administrativer Mehraufwand in der Verwaltung der Policies wie
auch der RA und CA verbunden, so dass die Notwendigkeit des Einsatzes genau bedacht werden sollte27 .
In OpenCA lässt sich der ”Level of Assurance” durch die Konfigurationsdatei
loa.xml unter /OPENCADIR/etc/ konfigurieren. Dabei unterscheidet OpenCA
in seiner Orginalkonfiguration zwischen 5 Leveln, die im Folgenden aufgelistet
werden.
• test
• rudimentary
• basic
• medium
• high
Wie diese Level eingesetzt werden, liegt bei den Vorgaben, die in den einzelnen Policies gemacht wurden. Da im Prototypen nur von ”einem” Level des
Vertrauens ausgegangen wird, wurde LOA in der Konfiguration von OpenCA
deaktiviert. Dies wurde erreicht, indem in den Konfigurationsdateien für die
Interfaces PUBLIC, CA, RA und BATCH das Attribut USE_LOA auf NO
gesetzt wurde.
27
Weitere Informationen zu LOA siehe auch [URL7] und [URL8].
115
4.6. LDAP
4.6. LDAP
OpenCA stellt ein LDAP-Interface zur Verfügung, das es dem Operator erlaubt, Zertifikate zusätzlich in einem zentralen LDAP-Repository zu halten.
Doch bevor die Zertifikate und CRLs in dem Verzeichnisdienst ablegt werden
können, muss ein entsprechender Dienst installiert und konfiguriert werden. Zu
diesem Zweck wird der LDAP-Server des OpenLDAP-Projektes28 verwendet.
Um den LDAP-Server den Anforderungen anzupassen, wurde als Basis für das
Verständnis die Funktionsweise und Konfiguration eines LDAP-Dienstes das
Buch [Ban01] verwendet. An dieser Stelle wird für detailliertere Informationen
auf die sehr ausführliche Dokumentation von OpenLDAP [URL9] hingewiesen.
4.6.1. Voraussetzungen
Folgende Voraussetzungen gelten für den Betrieb von OpenCA an einen OpenLDAPServer:
• installierter OpenLDAP-Server
• installierte Schemata: core.schema, cosine.schema, inetorgperson.schema
und openca.schema 29
• eine definierte RootDN
• ein angelegter Administrator mit Passwort
4.6.2. OpenLDAP
In der Konfigurationsdatei sldap.conf unter /etc/openldap/ müssen folgende
Dinge festgelegt werden:
28
29
www.openldap.org
Man findet das Schema unter /OPENCAARCHIV/contrib/openldap/).
116
4.6. LDAP
1. Einbinden der Schemata-Dateien für die verwendeten Objektklassen
include
/ etc / openldap / schema / core . schema
include
/ etc / openldap / schema / cosine . schema
include
/ etc / openldap / schema / inetorgperson . schema
include
/ etc / openldap / schema / openca . schema
2. Festlegen der Wurzel-DN des LDAP-Server
suffix
" dc = fh - wiesbaden , dc = de "
3. Festlegen des Superusers mit seinem Passwort30
rootdn
" cn = admin , dc = fh - wiesbaden , dc = de "
rootpw
katakis
4. Starten des LDAP-Server
Gestartet wird der OpenLDAP-Server unter SuSE Linux mit rcldap start.
Soll der LDAP-Dienst auch beim Hochfahren des Rechners automatisch
gestartet werden, muss unter YAST -> System -> Runlevel-Editor die
Startoptionen entsprechend angepasst werden.
5. Initialisierung der Wurzel-DN
Anlegen einer LDIF-Datei mit folgendem Inhalt:
dn : dc = fh - wiesbaden , dc = de
objectClass : domain
objectClass : dcObject
dc : fh - wiesbaden
Anschließend muss das LDIF mit dem Aufruf ldapadd -x -h localhost -D
”cn=admin,dc=fh-wiesbaden,dc=de” -f ldap-init.ldif -W in den LDAP30
Das Passwort kann auch verschlüsselt werden, dieses Feature wurde aber hier nicht angewendet.
117
4.6. LDAP
Server eingespielt werden. Damit ist die RootDN eingerichtet und bereit,
Daten aufzunehmen.
Anpassung an die Original-Nutzerverwaltung
Um den LDAP-Server soweit wie möglich der Original-Nutzerverwaltung des
Fachbereichs unter dem Pfad OU=Users, DC=cs, DC=fh-wiesbaden, DC=de
nachzuempfinden, wurden zusätzlich zu den oben gemachten Aussagen die
fachbereichs-internen Schemata fhw.schema und fhwstudent.schema eingebunden sowie Nutzer nach dem im Listing 4.8 vorgegebenen LDIF im entsprechenden Pfad erzeugt.
dn : uid = hwink001 , ou = Users , o = User - CA , dc = cs , dc = fh - wiesbaden , dc = de
givenName : ?
sn : ?
loginShell : / usr / local / bin / bash
gidNumber : 1000
uidNumber : 1280
objectClass : posixAccount
objectClass : shadowAccount
objectClass : top
objectClass : person
objectClass : organizationalPerson
objectClass : inetOrgPerson
objectClass : FHWFBIStudent
objectClass : sambaSamAccount
cn : ?
homeDirectory : / local / hwink001
Masterpasswort : xxx
ErstellDatum : 2001 -08 -22
SperrDatum : 0000 -00 -00
FBUserTyp : 4
Pruefungsordnung : 96
Studiengang : 0
sambaLogonTime : 0
sambaLogoffTime : 2147483647
sambaKickoffTime : 2147483647
sambaPwdMustChange : 2147483647
displayName : System User
sambaSID : S -1 -5 -21 -298626460 -1979496719 -3450519667 -3560
118
4.6. LDAP
sambaPasswordHistory :
00000000000000000000000000000000000000000000000000000000
sambaAcctFlags : [ U
]
sambaPwdCanChange : 1111404292
sambaLMPassword : xxx
sambaNTPassword : xxx
sambaPwdLastSet : 1111404292
userPassword : xxx
Matrikelnummer : 137537
uid : hwink001
mail : hwink001@stud . informatik . fh - wiesbaden . de
Existiert : 1
BelegSemester : 12
Listing 4.8: Inhalt des User Account von hwink001
4.6.3. OpenCA
Nachdem die oben beschriebene Prozedur ausgeführt wurde, muss anschließend
OpenCA an die Gegebenheiten des LDAP-Servers angepasst werden. Dafür
müssen die drei Konfigurationsdateien OPENCADIR/etc/servers/node.conf,
OPENCADIR/etc/servers/ldap.conf und OPENCADIR/etc/ldap.xml nachträglich bearbeitet werden.
Anmerkung: Unter dem Verzeichnis /OPENCADIR/etc/ in der Konfigurationsdatei config.xml gibt es einen LDAP-Teil, der in erster Instanz vor dem
Konfigurationsdurchlauf mit configure_etc.sh ausgefüllt werden sollte. Diese
Konfiguration ist für die groben Einstellungen ausreichend. Doch sollten für
genauere Anpassungen die oben genannten Konfigurationsdateien benutzt werden. Es ist darauf zu achten, dass bei einem erneuten Konfigurationsdurchlauf
mit configure_etc.sh alle Konfigurationsdateien und die darin gemachten Änderungen überschrieben werden. Des Weiteren sollte darauf geachtet werden,
dass Neuerungen in den Konfigurationsdateien des OpenCA-Servers erst nach
einem Neustart (openca_rc restart) erkannt werden.
Die Konfiguration ist in zwei Teile aufgespalten, den OpenCA-Teil und den
LDAP-Teil. Der OpenCA-Teil beinhaltet drei Optionen: die LDAP-Aktivierung,
119
4.6. LDAP
automatisches LDAP-Update während eines Imports und die DN-Manipulation
für CA-Zertifikate. Diese Optionen können in den Interface-Konfigurationen
/OPENCADIR/etc/server/*.conf bearbeitet werden. Für weitere Informationen sei an dieser Stelle auf den technischen Anhang im Abschnitt A.5 ”LDAP
Konfiguration” verwiesen.
4.6.4. Anpassungen
In diesem Abschnitt geht es im Speziellen um Anpassungen, die an OpenCA vorgenommen wurden, um es auf den Betrieb an der Fachbereichweiten
LDAP-User-Verwaltung vorzubereiten. Dabei mussten die Anträge sowie einige interne Funktionen angepasst werden. Des Weiteren werden die daraus
resultierenden Schwierigkeiten und Einschränkungen näher besprochen, um
Wege zur Lösung dieser Probleme aufzuzeigen.
Anpassungen für den DN
Im Ausgangszustand ist OpenCA bei der RootDN auf z.B. O=University, C=de
ausgelegt. Da aber die Verwaltung der Zertifikate und die fachbereichsweite Nutzer-Verwaltung in ein und demselben Baum unter OU=Users, DC=cs,
DC=fh-wiesbaden, DC=de betrieben werden sollen und die Angabe des DN im
Zertifikat ausschlaggebend für die Verwaltung desselben im LDAP ist, musste
der DN, der für die Zertifikate von OpenCA vergeben wird, entsprechend angepasst werden. Um dies zu erreichen, wurden die Konfigurationen für die Zertifikatanträge und einige interne Kommandos von OpenCA angepasst. Um z.B.
einen CSR und das daraus resultierende Zertifikat für den Nutzer hwink001
mit dem DN UID=hwink001, OU=Users, DC=cs, DC=fh-wiesbaden, DC=de zu
erstellen, muss die pub.conf Konfigurationsdatei in der ”Basic CSR Section”
der RA entsprechend angepasst werden. Am Listing 4.9 des Basis-Antrages
werden diese Änderungen verdeutlicht31 .
31
Genauere Informationen sind im Abschnitt 4.5 ”Konfiguration” Unterabschnitt 4.5.1
”CSRs” einzusehen.
120
DN_TYPE_BASIC_BASE
4.6. LDAP
" OU " " DC " " DC " " DC "
DN _T YP E_ BA SIC _E LE ME NTS " emailAddress " " UID "
DN_TYPE_BASIC_NAME
" Basic User Request "
DN_TYPE_BASIC_BASE_1 " Users "
DN_TYPE_BASIC_BASE_2 " cs "
DN_TYPE_BASIC_BASE_3 " fh - wiesbaden "
DN_TYPE_BASIC_BASE_4 " de "
Listing 4.9: Exemplarischer Ausschnitt für den Basisantrag
Diese Änderungen müssen an allen Interfaces und deren Konfigurationsdateien durchgeführt werden, die in der Lage sind, Anträge aufzunehmen. Darunter
fällt das PUBLIC-Interface der Online-RA und das CA-Interface der OfflineCA. Die dazugehörigen Konfigurationsdateien befinden sich im System unter
OPENCADIR/etc/servers/*.conf.
Da nach der Änderung für die Zertifikate statt CN als Blattobjekt UID verwendet wird, kommt es bei unveränderter Benutzung dazu, dass in der Auflistung
der Zertifikate wie auch dem Einsehen der Einzelheiten auf den Webinterfaces der Common-Name des Zertifikates, also der Name des Zertifikatinhabers, nicht angezeigt wird. Grund dafür sind die internen Kommandos unter
/OPENCADIR/lib/cmds/, viewCert und listCerts, die für das Auslesen der Werte des Zertifikates davon ausgehen, dass das Blattobjekt vom Typ CN ist. Um
dieses Anzeigeproblem zu beheben, wurden die eben genannten Funktionen
viewcert und listcert angepasst. Dazu musste bei dem Kommando viewCert in
der Zeile 155 der CN durch UID ersetzt werden (siehe Listing 4.10).
$info_list - >{ BODY } - >[ $info_pos ++] - >[1] = ( $parsedCert - >{ DN_HASH } - >{ UID }[0]
or gettext ( " n / a " ) ) ;
Listing 4.10: Anpassung des Kommandos viewCert
Ebenso musste bei dem Kommando listCerts vorgegangen werden. Dazu wurde dort in der Zeile 89 der Wert CN durch UID ersetzt (siehe Listing 4.11).
121
4.6. LDAP
$item_list - >{ BODY } - >[ $pos ] - >[1] = ( $cert - > getParsed () - >{ DN_HASH } - >{ UID }[0]
|| " < CENTER > - - - </ CENTER > " ) ;
Listing 4.11: Anpassung des Kommandos listCerts
Diese Prozedur wurde auf der Offline-CA wie auch der Online-RA durchgeführt, die jeweils nach der erfolgreichen Änderung neu gestartet wurden.
Nachdem dieser Prozess erfolgreich abgeschlossen war, konnte der Name anhand der UID von OpenCA ausgelesen und im Webinterface wiedergegeben
werden. Als letztes musste die ra.conf so angepasst werden, dass das Attribut userCertificate nicht, wie standardmäßig vorgesehen, unterhalb des UIDObjektes in ein Blattobjekt namens serialNumber abgelegt wird. Was erreicht
werden sollte, war die Ablage des Zertifikats direkt im UID-Objekt des Nutzers.
Dies wurde umgesetzt, indem in der Konfigurationsdatei ra.conf die Option
SET_CERTIFICATE_SERIAL_IN_DN auf NO gesetzt wurde32 .
Probleme mit den DN
Das Problem, das durch die Verwendung des Distinguished Name UID=Username,
OU=Users, DC=cs, DC=fh-wiesbaden, DC=de entsteht, ist rein organisatorischer Natur und schon oben bei der Anpassung von OpenCA, zum Auslesen
des Namen durch die UID, angeklungen. Dabei geht es in erster Linie um die
Interpretation des DN innerhalb der Anwendungssoftware. Ein E-Mail-Client
wie z.B. Thunderbird zeigt den Inhalt eines Zertifikates für den Nutzer in einer
Zusammenfassung, wie in Abbildung 4.5 zu sehen, an.
Wie man an dem Beispiel des Zertifikates des RA-Operator sehen kann, wird
der DN des Inhaber (CN=RA-Operator-Informatik, OU=User-CA, O=Fachbereich
DCSM, DC=cs, DC=fh-wiesbaden, DC=de) wie auch der DN des Herausgebers (CN=User-CA, OU=Informatik, O=Fachbereich DCSM, DC=cs, DC=fhwiesbaden, DC=de) dazu verwendet, um dem Nutzer schnell und unkompli32
Nähere Informationen siehe im technischen Anhang im Abschnitt A.5 ”LDAP Konfiguration”.
122
4.6. LDAP
Abbildung 4.5.: Übersicht über ein Zertifikat unter Mozilla Thunderbird
ziert die wichtigsten Informationen des Zertifikates zu präsentieren. Das Problem, das nun durch die Verwendung des Distinguished Name UID=Username,
OU=Users, DC=cs, DC=fh-wiesbaden, DC=de auftritt, ist dieses, dass die Felder Allgemeiner Name (CN) und Organisation (O) für den Inhaber leer bleiben
(siehe Abbildung 4.6). Da hier eine andere Struktur verwendet wird, können
Mozilla wie auch die meisten anderen E-Mail-Clients und Keystores mit DC
und UID im Distinguished Name nichts anfangen. So muss der Nutzer für nähere Informationen über das Zertifikat die Details aufrufen.
Es ist nicht möglich an dieser Problematik etwas zu ändern, da der DN im
Zertifikat gleichzeitig den Pfad darstellt, an dem das Zertifikat auf dem LDAPServer abgelegt wird. Wird nun die Nutzer- und die Zertifikatverwaltung im
selben Baum betrieben, sind die Vorgaben klar ersichtlich. Der vergebene DN
innerhalb des Zertifikates kann nicht nach eigenen Wünschen abgeändert werden, da sonst die Ablage des Zertifikates in der Nutzerverwaltung unmöglich
wäre. Ein Ausweg wäre, die Nutzer- und die Zertifikatverwaltung zu trennen
123
4.6. LDAP
und damit die Zertifikate in einem Baum zu speichern, dessen DN kompatibel
ist, oder die Wurzel und den DN der Nutzerverwaltung entsprechend anzupassen.
Anmerkung: Diese Arbeit orientiert sich im weiteren an den Vorgaben, die
durch die Nutzerverwaltung gegeben sind. Da aber die Nutzerverwaltung im
Laufe der nächsten Jahre eventuell einigen Änderungen unterworfen sein wird,
wird an dieser Stelle auf diese Problemstellung aufmerksam gemacht. Somit
können die eben angestellten Überlegungen mit berücksichtigt werden und gegebenenfalls mit in die Planungen einfließen.
Abbildung 4.6.: Übersicht über ein Zertifikat unter Mozilla Thunderbird bei
Verwendung des DN für die Nutzer-Verwaltung
124
4.7. Batch
4.7. Batch
In diesem Abschnitt wird der Batch-Prozessor, zum automatischen erstellen
von Schlüsselpaaren und Zertifikaten, einer näheren Betrachtung unterzogen.
4.7.1. Vorbemerkung
In der aktuellen Version von OpenCA ist die Dokumentation des Batch-Systems
nicht vorhanden. Es stellte sich heraus, dass es in früheren Versionen von OpenCA in der Anleitung ein Kapitel 16 zum Batch-System gegeben hat. Aus diesem Grund wurde eine ältere Version heruntergeladen und untersucht. Die
nun folgenden Ausführungen basieren auf der Dokumentation von OpenCA
0.9.2.1, Stand Herbst 2004, sowie aus einschlägigen Beiträgen der Mailinglist
für OpenCA.
4.7.2. Design
Der Kern des OpenCA-Batch-Systems ist eine Statusmaschine33 (oder auch
Automat). Diese besitzt eine Konfiguration mit definierten Zuständen, Funktionen und Workflows. Dabei liest sie in jedem Schritt die Konfiguration des
Nutzers, überprüft den aktuellen Status und berechnet die nächste Funktion des Workflows. Im einfachsten Fall wird jeder Schlüssel in einem eigenen
Workflow bearbeitet. Weiterhin sollte beachtet werden, dass die Statusmaschine eine zweiteilige Konfiguration besitzt. Es existiert eine XML-Datei,
die die Position der Kern-Konfigurationsdateien und die Optionen der BatchSystemfunktionen beinhaltet. Die eigentlichen Kern-Konfigurationsdateien sind
wiederum einfache Textdateien, welche eine bestimmte Struktur in Form von
Listen zum schnellen Parsen beinhalten. Dabei sind folgende Teile in den KernKonfigurationsdateien enthalten:
33
Ist ein Modell des Verhaltens, bestehend aus Zuständen, Zustandsübergängen und Aktionen.
125
4.7. Batch
• eine Liste der existierenden Prozesse
• eine Liste aller bekannten Funktionen
• eine Liste aller bekannten Zustände
• ein Verzeichnis, welches die Startkonfiguration der Zustände aller Funktionen beinhaltet
4.7.3. Datenimport
Bevor das Batch-System von OpenCA genutzt werden kann, müssen die Daten
für die Statusmaschine importiert werden. Dazu gibt es im Standardverfahren
drei verschiedene Importaktionen:
1. Import der neuen Nutzer
(batch_new_user.txt)
2. Import der zu den neuem Nutzern dazugehörigen Prozesse
(batch_new_process.txt)
3. Import der zu den Prozessen dazugehörigen Daten
(batch_process_data.txt)
Anmerkung: Da das Standardverfahren im Normalfall nicht zur Anwendung
kommt, soll es an dieser Stelle nur erwähnt werden. Für weiter gehende Informationen zum Standard-Import und dem Syntax der Eingabe-Dateien sei
an dieser Stelle auf den technischen Anhang Abschnitt A.6 ”Batchimport”
verwiesen.
4.7.4. Quickimport
Die Vorgehensweise des einzelnen Importierens der User, Prozesse und Prozessdaten beschreibt den klassischen Datenimport in das Batch-System34 . Dabei
34
Siehe dazu auch im technischen Anhang Abschnitt A.6 ”Batchimport”.
126
4.7. Batch
hat das getrennte Einlesen von Usern, Prozessen und Daten vor allem den Vorteil, besser auf Fehler reagieren zu können. Da diese Methode sich aber für den
produktiven Einsatz als zu umständlich erwiesen hat, stellt OpenCA zusätzlich zu der klassischen Methode den Quickimport zur Verfügung. Durch den
Quickimport wird es möglich, die Statusmaschine mit einer zentralen Konfigurationsdatei, der batch_process_data.txt, zu füttern. Dadurch werden User,
Prozesse und Daten in einem Zug eingelesen. Dies ist für den normalen Gebrauch wesentlich komfortabler und wird für den einfachen Betrieb empfohlen. Für die Fehlersuche in den Importdateien sollte die klassische Methode
favorisiert werden. Im Folgenden wird auf die Verwendung der QuickimportFunktion anhand eines Beispieles eingegangen.
1. Es sollte eine Datei namens batch_process_data.txt mit folgendem Inhalt erstellt werden:
USER hwink001
PROCESS neues_zertifikat
set_state new_process
ROLE User
SUBJECT_ALT_NAME_1 email : HG . Winkler@Web . de
SUBJECT UID = hwink001 , OU = Users , DC = cs , DC = fh - wiesbaden , DC = de
LOA_MODE IGNORE
Listing 4.12: Exemplarischer Ausschnitt aus der batch_process_data.txt
2. Diese Datei wird anschließend unter /OPENCADIR/batch/ abgelegt und
mit dem Befehl tar -cvf exchange.tar batch_process_data.txt für den Import in das Batch-System gepackt.
3. Unter dem BATCH-Interface, Batch-System -> Workflow Management
-> Quickimport werden die neuen User, Prozesse und Daten importiert. Nach dem Import kann man die User unter dem BATCH-Interface,
127
4.7. Batch
Batch-System -> Workflow Management -> Anzeigen der Nutzer einsehen35 .
4.7.5. Konfiguration der Import-/Export-Funktion
Unter /OPENCADIR/etc/servers/ in der Konfigurationsdatei batch.conf muss
vor der Verwendung der Batch die Importsektion den Gegebenheiten angepasst
werden. Im Listing 4.13 ”## local dataexchange (batchprocessors)” ist die
Konfiguration beispielhaft aufgeführt.
## local dataexchange ( batchprocessors ) ’ ’
E X P O R T _ I M P O R T _ L O C A L _ D E V I C E " / srv / openca / batch / "
E X P O R T _ I M P O R T _ L O C A L _S T A R T
""
E X PO R T _ IM P O R T _L O C A L_ S T O P
""
E X P O R T _ I M P O R T _ L O C A L _ I M P O R T " / bin / tar - xvf @ _ _ D E V I C E _ _ @ e x c h a n g e . tar -C
@__DEST__@ "
E X PO R T _ IM P O R T _L O C A L_ T E S T
" / bin / tar - tvf @ _ _ D E V I C E _ _ @ e x c h a n g e . tar "
Listing 4.13: Ausschnitt der Batch Import-/Export-Sektion
In der Datei exchange.tar befinden sich beim Standard-Import-Verfahren die
Dateien batch_new_user.txt, batch_new_process.txt und batch_process_
data.txt. Wird der Quickimport verwendet, beinhaltet das Archiv nur die
batch_process_data.txt. Bei einem Import verwendet das System die benötigten Dateien. Das heißt, es extrahiert sich aus dem Archiv exchange.tar
bei einem Userimport die batch_new_user.txt, bei einem Prozessimport die
batch_new_process.txt und bei einem Datenimport oder Quickimport die
batch_process_data.txt und führt den Import aufgrund der in diesen Dateien
gefundenen Daten durch.
35
Der neue Prozess von hwink001 wurde unter:
/OPENCADIR/var/bp/users/h/w/i/n/k/0/0/1/workflows/neues_zertifikat/ angelegt
128
4.7. Batch
4.7.6. Durchführen des Batch-Prozesses
Nachdem die User mit ihren Prozessen und Daten in das Batch-System importiert wurden kann nun der eigentliche Batch-Prozess zum Erzeugen der Zertifikate gestartet werden. Dazu geht der Operator unter dem BATCH-Interface
in Batch-System -> Workflow Management -> Durchführen von Operationen für die Workflows und wählt als erstes alle 16 Iterationen. Als nächstes
wird für den ”CA-Key” und ”Key of the batch system” jeweils Yes angegeben. Nach dem Bestätigen wird für CA- und Batch-Key jeweils das Passwort
verlangt. Ist die Passwortabfrage erfolgreich, durchläuft daraufhin der BatchProzessor für jeden Userprozess seine Zustände, wobei am Ende ein Zertifikat
in der lokalen Datenbank der CA und eine exportierte PKCS#12 Datei unter /OPENCADIR/var/bp/dataexchange/pkcs12/ erstellt wird36 . Weiter sollten anschließend die PINs, die zum Schutz der PKCS#12-Container von OpenCA generiert wurden, im BATCH-Interface unter Batch-System -> Workflow
Management -> Exportieren von PINs exportiert werden37 .
Anmerkung: Batch- und CA-Key sind bei der Installation von Batch und CA
auf einem Rechner identisch, können aber in den /server/*.conf Einstellungen unter Certificates Section und Batch-Processors geändert werden. Weiter
sollte ab OpenCA Version 0.9.2.4 darauf geachtet werden, in der batch.conf
die Variable ”lockFile /OPENCADIR/lock” einzutragen und zusätzlich eine
leere lock-Datei in dem entsprechenden Pfad anzulegen. Wird dies nicht getan,
bricht der Batch-Prozessor in der create_cert Funktion mit einer Fehlermeldung ab.
36
37
Weiter wird auf den Workflow der Statusmaschine im technischen Anhang Abschnitt A.7
”Batch Workflow” eingegangen.
Die PINs werden unter /OPENCADIR/var/bp/dataexchange/pin_list abgelegt.
129
4.7. Batch
4.7.7. Automatische Generierung des Batch-Import
Wie schon weiter oben erklärt, benötigt der Batch-Prozessor eine spezielle
Konfigurationsdatei, um die User mit ihren Prozessen anlegen zu können. Diese Konfigurationsdatei kann auch automatisch erstellt werden. Dazu wurde im
Lauf der Arbeit ein Skript entwickelt, das ermöglicht, aus der Studentenliste
des Fachbereiches ein Archiv für den Import in den Batch-Prozessor zu erzeugen38 . Um die Funktionsweise des Skriptes näher zu erläutern, wird als Erstes
auf den Aufbau der Studentenliste näher eingegangen. Diese Liste wird dem
Fachbereich vom Studentensekretariat zur Verfügung gestellt und beinhaltet
alle am Fachbereich eingeschriebenen Studenten. Dabei werden in jeder Zeile
Daten zu einem Studenten abgelegt.
Eine Zeile hat folgenden Aufbau:
137537; Winkler ; Hans - Georg ;3;1996; II
• MatrikelNummer = 137537
• Nachname = Winkler
• Vorname = Hans-Georg
• Semester = 12
• Prüfungsordnungsversion = 1996
• Studiengang = II
Studiengangbedeutung
• Allgemeine-Informatik Diplom = II
• Medien-Informatik Diplom = ID
• Allgemeine-Informatik Bachelor = IIB
38
Siehe auch Abschnitt 4.9 ”Shell Skripte”.
130
4.7. Batch
• Medien-Informatik Bachelor = IDB
• Master = IIM
Bildung des Usernamen
Da der Username, der später z.B. für die Anmeldung an das fachbereichsinterne Netzwerk genutzt wird, noch nicht vorhanden ist, muss er erst gebildet
werden. Ein Beispiel: Hans-Georg Winkler wird zu hwink001. Dabei steht das
”h” für Hans, ”wink” für Winkler und ”001” für die eindeutige Kennung (bei
gleicher ID wird das Ende um eins erhöht 001 -> 002). Dieser Username wird
wiederum als Bezeichner für die UID des Studenten unter OU=Users, DC=cs,
DC=fh-wiesbaden, DC=de im fachbereichsweiten LDAP-Server verwendet. Da
die Zertifikate im selben Baum abgelegt werden sollen, muss man sich an diese
Vorgaben halten.
Funktionsweise
Wird diese Datei als Eingabe für das Skript user2batch.sh verwendet, werden
die einzelnen Zeilen gescannt und geprüft, ob ein Student im ersten Semester ist. Ist dies der Fall, kommt es zur weiteren Verarbeitung. Diese besteht
darin, als erstes zu prüfen welchen Username dem Studenten zugewiesen wurde. Dazu wird anhand der Matrikelnummer die Userkennung aus dem LDAPServer extrahiert39 . Wurde die UID erfolgreich bezogen, wird aus den Daten
des Users für diesen ein neuer Eintrag in der batch_process_data.txt erzeugt.
Ist der Durchlauf abgeschlossen, wird als letztes das batch_process_data.txt
gepackt und in das Importverzeichnis des Batch-Prozessors abgelegt. Nach erfolgreichen Ausführen des Skriptes ist es nun möglich, alle neuen Studenten im
ersten Semester in die Batch zu importieren, um anschließend vollautomatisch
für sie jeweils ein Zertifikat inklusive privaten Schlüssel in einem PKCS#12Container zu erzeugen sowie das Zertifikat nach dem Export an die RA zu
veröffentlichen40 .
39
40
Voraussetzung ist, dass die Nutzer vorher schon von anderer Stelle in den LDAP-Server
eingepflegt wurden.
Nähere Informationen dazu siehe Abschnitt 4.10 ”Anwendungsszenarien”.
131
4.8. Benachrichtigung der Nutzer
In diesem Abschnitt geht es in erster Linie um die Fragestellung des Schutzes
und der sicheren Übertragung der für den Nutzer wichtigen Informationen.
Dabei handelt es sich zum einen um den Aktivierungscode für die durch den
Batch-Prozess erzeugte PKCS#12-Container, zum anderen um die Autorisierungsinformation für den Rückruf von Zertifikaten.
4.8.1. Probleme mit der PIN
Sobald die PKCS#12-Container im Batch-Prozess erfolgreich generiert und
die PINs in die pin_list unter /OPENCADIR/var/bp/dataexchange/ extrahiert
wurden41 müssen diese Container und die zugehörigen PINs an die User übermittelt werden.
Sichere Übermittlung des PIN an den Nutzer
Soll die generierte PIN der Batch verwendet werden, muss dem User seine PIN
auf sichere Weise mitgeteilt werden. Im Falle des Fachbereichs empfiehlt es sich,
die PIN zusammen mit dem Masterpasswort auf dem entsprechenden Bescheid,
den sich jeder Student im Dekanat abholen muss, persönlich zu übergeben.
Es könnte auch eine Veröffentlichung per E-Mail gewählt werden, doch ist
davon abzuraten, da die notwendige Ver- und Entschlüsselung eine unnötige
Belastung des Nutzers nach sich ziehen würde.
Nachträgliche Vergabe einer eigenen PIN
Soll der PKCS#12 Container nachträglich mit dem Masterpasswort verschlüsselt werden muss dieses im Klartext verfügbar sein42 . Das Masterpasswort zu
jedem Studenten ist in der Nutzerverwaltung auf dem LDAP-Server des Fach41
42
Siehe auch Abschnitt 4.10.4 ”Automatische Zertifikaterstellung”.
Ein Passwort in Form eines Digest ist nicht verwendbar (Siehe auch Kapitel 2 ”Grundlagen” im Abschnitt 2.5 ”Hybridverfahren” Hashing).
132
bereiches unter OU=Users, DC=cd, DC=fh-wiesbaden, DC=de im Blattobjekt
UID=user in dem Attribut ”Masterpasswort” abgelegt. Dabei handelt es sich
um eine unverschlüsselte Variante. Diese Gegebenheit macht es möglich, den
PKCS#12-Container eines jeden Studenten nachträglich mit seinem Masterpasswort zu versehen43 . Zu diesem Zweck wurde das Script pkcs2user.sh entwickelt. Dieses ermöglicht es, das zu dem jeweiligen Studenten im LDAP-Server
abgelegten Masterpasswort zu beziehen, um damit den PKCS#12-Container
vor der Auslieferung an den Studenten mit dessen Masterpasswort zu verschlüsseln. Ist dieser Prozess erfolgreich, können die Container in die entsprechenden
Home-Verzeichnisse der Studenten eingespielt werden. Die Studenten wiederum können anschließend die Container unter Angabe ihres Masterpasswortes
z.B. in den Keystore eines Browsers oder E-Mail-Programmes importieren.
4.8.2. Probleme mit der CRIN
CRIN ist die Autorisierungsinformation für den Rückruf eines Zertifikates über
das PUBLIC-Interface der RA (Siehe auch Abschnitt 4.10.5 ”Sperren von Zertifikaten”). Sie ist ein String, bestehend aus einer zufälligen Zeichenfolge, die
während des Signierens des Zertifikates durch die CA erzeugt und neben dem
Zertifikat, unter der Bezeichnung PIN, als Hash (SHA1) in der Datenbank abgelegt wird. In den Standardeinstellungen von OpenCA ist vorgesehen, diese
CRIN als eine mit dem Zertifikat des Nutzers verschlüsselten E-Mail an den
Inhaber des Zertifikates zu versenden.
Da für den Einsatz im Fachbereich kein E-Mail-Versand vorgesehen ist, wird
die persönliche Zustellung der CRIN in schriftlicher Form empfohlen, z.B. zusammen mit der Ausgabe des Masterpasswortes. Ein weiterer wichtiger Punkt
dabei ist, dass OpenCA bei der Erstellung der CRIN so vorgeht, dass diese
nur kurz nach der Generierung bis zur Erstellung der E-Mail an den Inhaber im Klartext verfügbar ist. Ist dieser Prozess abgeschlossen, wird die CRIN
43
Voraussetzung dafür ist, dass der Student mit Passwort schon angelegt wurde.
133
anschließend, wie schon weiter oben erwähnt, in verschlüsselter Form in der Datenbank abgelegt, so dass eine nachträgliche Auslieferung nicht möglich ist. Aus
diesem Grunde musste in den Quellcode von OpenCA eingegriffen werden. Dazu wurde die Bibliothek crypto-utils.lib unter /OPENCADIR/lib/funktions/
in der Funktion crypto_add_pin_to_header so angepasst, dass die CRIN im
Klartext während des Erzeugens der E-Mail in die crin.db im Verzeichnis
/OPENCADIR/var/pin/ abgelegt wird44 .
Die Datei crin.db hat dabei folgenden Aufbau:
--- START - CRIN - - 15
UID = hwink001 , OU = Users , DC = cs , DC = fh - wiesbaden , DC = de
9 OoE37Auv + Ozc / tW2CXFew
--- END - CRIN - - -
Listing 4.14: Aufbau der crin.db
• Zeile 1: Start
• Zeile 2: serielle Nummer des Zertifikates
• Zeile 3: DN des Zertifikates
• Zeile 4: zugehörige CRIN
• Zeile 5: Ende
Durch dieses spezielle Extrahieren der CRIN wird es nun möglich, diese auch
nachträglich außerhalb des Prozesses der Zertifikatgenerierung den Zertifikatinhabern zukommen zu lassen.
44
Die Veränderungen wurden durch entsprechende Kommentare im Quellcode kenntlich
gemacht.
134
4.8.3. E-Mail Benachrichtigung
OpenCA ist so ausgelegt, dass es seinen Nutzern die nötigen Informationen per
E-Mail zukommen lässt. Dabei wird zum Versand der E-Mails der sendmailBefehl genutzt. Das setzt jedoch voraus, dass der Host eine Verbindung zum
Internet besitzt. Da das aber für die Zertifizierungsstellen im Fachbereich nicht
vorgesehen ist, muss ein anderer Weg zur Information der Zertifikatinhaber
genutzt werden. Dieser kann z.B. darin bestehen, dem Inhaber die nötigen Informationen, wie weiter oben schon einmal vorgeschlagen, in Papierform direkt
auszuhändigen.
Wird die Möglichkeit der Information der Zertifikatinhaber über einen Bescheid auf Papier in Betracht gezogen, müssen die Daten, welche OpenCA
für den E-Mail-Betrieb generiert, noch einmal zusätzlich für den eigenen Gebrauch abgelegt werden. Um das zu erreichen, wurden zu den Änderungen im
Abschnitt 4.8.2 ”Probleme mit der CRIN”, die crypto-utils.lib in der Funktion crypto_add_pin_to_header soweit angepasst, dass die generierte CRINE-Mail in Klartext unter /OPENCAIDR/var/messages/ mit der Bezeichnung
Serial_*.CRIN-MESSAGE.txt abgespeichert wird. Weiter wurde die Funktion crypto_send_info_mail so verändert, dass die Informationsmail, die nach
dem Erstellen eines Zertifikates zusätzlich zu der CRIN-E-Mail an den Inhaber versandt wird, unter /OPENCAIDR/var/messages/ mit der Bezeichnung
Serial_*.CONFIRM-CERT-SIGN-MESSAGE.txt abgelegt wird.
Mit diesen nachträglich herausgefilterten Daten unter /OPENCAIDR/var/pin/
und /OPENCAIDR/var/messages/ ist es nun möglich, den Nutzer über eigene
Wege außerhalb der E-Mail-Zustellung die nötigen Daten zukommen zu lassen.
135
4.9. Shell Skripte
4.9. Shell Skripte
Im Verlauf der Arbeiten an OpenCA wurden an bestimmten Stellen, um Prozesse zu automatisieren oder Konfigurationsdateien zu generieren, eigene Skripte geschrieben. Diese werden nun näher betrachtet. Insgesamt wurden drei
verschiedene Problemstellungen mit Hilfe von Bash-Scripten bearbeitet.
4.9.1. Datenaustausch zwischen verschiedenen Ebenen der
Zertifizierungsstelle
Da OpenCA vom Offlinebetrieb der CA ausgeht, sehen die originären Einstellungen bezüglich des Datenaustausches den Ex- und Import über Wechselmedien vor. Da ein reines Offlinesystem im Prototyp nicht vorgesehen ist,
wird damit auch der Datenaustausch über diese Medien überflüssig. OpenCA
räumt in seiner Datenaustauschkonfiguration dem Nutzer einen großen Spielraum für nutzbare Medien ein. Deshalb wurde der Datenaustausch insofern
verändert, dass das Archiv mit den zu exportierenden Daten nicht, wie normal
vorgesehen, auf Diskette oder USB-Stick, sondern direkt in das Dateisystem
geschrieben wird. Ist der Export erfolgreich abgeschlossen, kommt an dieser
Stelle das Skript sync.sh zum Einsatz. Es hat die Aufgabe, das Archiv über
eine SSH-Verbindung zu seinem Ziel zu kopieren und danach im Dateisystem
aufzuräumen. Der Aufruf gestaltet sich folgendermaßen:
/ OPENCADIR / sh - tools / sync . sh [ ZIELIP ] [ SOURCEPFAD ] [ ZIELPFAD ] [ BACKUPPFAD ]
• ZIELIP ist der Host des zu erreichenden Zielrechners,
• SOURCEPFAD der Pfad zu dem zu exportierenden Archiv (im Prototyp
immer unter dem Pfad /OPENCADIR/datenaustausch/).
• ZIELPFAD ist der Pfad auf dem Zielsystem, in dem das Archiv eingespielt werden soll. Aus diesem Pfad nimmt das auf dem Zielsystem
laufende OpenCA anschließend den Import vor.
136
4.9. Shell Skripte
• Der abschließende BACKUPPFAD gibt ein Verzeichnis an, an dem das
aktuell zu exportierende Archiv gesichert werden kann (im Prototyp immer unter /OPENCADIR/backup/datenaustausch/).
4.9.2. Automatisierung der Erstellung eines Batch-Imports
zur automatischen Erstellung neuer
Studentenzertifikate
Der Fachbereich bekommt am Anfang eines jeden Semester vom Studentensekretariat eine Liste aller aktuell eingeschriebenen Studenten des Fachbereiches
zugesandt. Diese Liste ist die Basis für die Erstellung der Accounts neu eingeschriebener Studenten.
Da der Batch-Prozessor einen eigenen Importprozess für die Erstellung neuer
Zertifikate zur Verfügung stellt, ist es möglich, eine Importdatei völlig automatisch zu generieren. Hier findet das user2batch.sh-Skript seine Anwendung.
Dieses Skript wurde geschrieben, um aus der Studentenliste eine für den BatchProzessor verwertbare Konfigurationsdatei zu generieren. Dabei werden für die
Verarbeitung nur die Studenten berücksichtigt, die sich im ersten Semester
befinden, da nur diese für die automatische Generierung von Zertifikaten vorgesehen sind45 . Für den Start des Prozesses muss folgender Syntax beachtet
werden:
/ OPENCADIR / sh - tools / user2batch . sh [ INPUTFILE ] [ OUTPUTPFAD ] [ BATCHIMPORTPFAD ]
• Beim INPUTFILE handelt es sich um besagte Liste.
• OUTPUTPFAD ist der Pfad, an dem die generierte Konfigurationsdatei
abgelegt wird46 .
45
46
Siehe auch Kapitel 3 ”Analyse” Abschnitt 3.6 ”Ablauforganisation”.
Nach dem Ausführen des Skriptes kann an dieser Stelle noch geprüft werden, ob alles
ordnungsgemäß erzeugt wurde.
137
4.9. Shell Skripte
• Der BATCHIMPORTPFAD ist der Pfad, an dem der Batch-Prozessor
den Import vornimmt. Dabei wird die im OUTPUTPFAD generierte
Konfigurationsdatei gepackt und in das angegebene Importverzeichnis
der Batch eingespielt.
Wird nun nach dem erfolgreichen ausführen des Skriptes user2batch.sh der
Import des Batch-Prozessors gestartet, werden alle Studenten, die in die Konfigurationsdatei übertragen wurden, importiert und können so anschließend
dem Batch-System übergeben werden.
4.9.3. Automatische Verarbeitung der durch den
Batch-Prozess erstellten PKCS#12-Dateien
Ist der Batch-Prozess erfolgreich, spielt das System die erzeugten PKCS#12Dateien unter dem Pfad /OPENCADIR/var/bp/dataexchange/pkcs12/ in das
Dateisystem ein. Diese PKCS#12-Dateien beinhalten den privaten Schlüssel
des jeweiligen Studenten sowie den durch die CA signierten öffentlichen Schlüssel. Da diese Daten als sicherheitskritisch anzusehen sind, schützt OpenCA sie
mit einer während des Batch-Prozesses erzeugten PIN47 . Diese PIN ist für den
Schutz des privaten Schlüssels geeignet. Bestimmte Vorgaben können jedoch
vor der Auslieferung der PKCS#12-Dateien an die Studenten ihre nachträgliche Änderung notwendig machen. Hierfür wurde das Skript pkcs2user.sh entwickelt. Aufgabe dieses Skriptes ist es, dem Studenten seine PKCS#12-Datei mit
einem nachträglich vergebenen Passwort (z.B. dem eigenen Masterpasswort)
zu schützen. Für die Anwendung des Skriptes ist folgende Syntax vorgesehen48 .
/ OPENCADIR / sh - tools / pkcs2user . sh [ OPENCAPFAD ]
47
48
Die jeweils zu einem Prozess gehörende PIN kann unter der pin_list im Verzeichnis
/OPENCADIR/var/bp/dataexchange/ eingesehen werden.
Voraussetzung ist der vorher erfolgreich abgeschlossene Batch-Prozess und das anschließende Exportieren der PINs im BATCH-Interface unter Batch-System -> Workflow Management -> Exportieren von PINs.
138
4.9. Shell Skripte
Einzig anzugebende Option ist der Installationspfad von OpenCA. Bei erfolgreichem Ausführen des Skripts werden die neu erzeugten PKCS#12-Dateien
unter /OPENCADIR/batch/export-user-pkcs12/ abgelegt und können von hier
aus weiter in die Home-Verzeichnisse der Studenten verteilt werden.
4.9.4. CSR Handhabung
X.509 Zertifikate sind weit verbreitet und haben sich als Standard etablieren
können. Doch in den ersten Jahren gab es Probleme mit den CSRs. Der Grund
dafür war ein fehlendes einfaches Protokoll für die Übermittlung der CSRs vom
Client Interface. Das Resultat dieser Entwicklung war ein Standard CSR und
ein proprietäres Format. Das Standard Antrags-Format ist PKCS#10, das von
Servern (Apache, E-Mail, VPN) und dem Internet Explorer unterstützt wird.
Das proprietäre Format ist das von Netscape entwickelte SPKAC. Dieses Format wird von Mozilla und Opera verwendet.
Erstaunlicherweise gibt es eine Menge an Software, die Zertifikate und private
Schlüssel für die Verschlüsselung z.B. für E-Mails oder HTTPS Verbindungen
verwenden. Doch keine der Softwarelösungen unterstützt das Erzeugen von
Anträgen und Zertifikaten. Was benötigt wird, ist die Erzeugung des Antrages
auf der einen Seite, aber auch die Übermittlung des Antrages ist ein nicht zu
unterschätzender Teil der Aufgabenstellung. Dabei gliedert sich die Art der
Anwendungen in zwei Teile. Der erste Teil des Szenarios sind die Browser.
Heutzutage kennen diese zwei Wege. Microsofts CAPI (Microsoft Internet Explorer) und Netscapes ”keygen”-tag (Mozilla, Netscape, Opera). Einen dritten
Weg geht Konqueror, indem vom User verlangt wird, alle nötigen Schritte
selbst zu erledigen. Der zweite Teil sind die Server. Viele Server wie z.B. Apache verhalten sich wie Konqueror, d.h. der Nutzer muss selbst die Schlüssel
und Anträge generieren, sich an die PKI wenden und zertifizieren lassen, um
anschließend die Zertifikate von Hand ins System einzupflegen. Andere Server wiederum, wie z.B. VPN Server, können ihre Schlüssel und Anträge selbst
139
4.9. Shell Skripte
generieren. Weiter ist es möglich die Anträge auf eine Floppy oder einen USBStick zu kopieren und diese der PKI von Hand zu übermitteln, oder man nutzt
das SCEP, um die Kommunikation mit der PKI automatisch aushandeln zu
lassen. Wie man also sieht gibt es vom Erzeugen der Schlüssel bis zum fertigen
Zertifikat viele Wege.
Möglichkeiten von OpenCA
OpenCA kennt fünf verschiedene Antragsarten, wobei die Schlüsselgenerierung
je nach Situation Server oder Client-seitig durchgeführt werden kann. Ist die
Generierung erfolgreich, wird der Antrag in der Datenbank der RA gespeichert
und im nächsten Schritt vom RA-Operator eingesehen, der diesen dann an die
CA weiterreichen kann49 . Die folgenden Abschnitte sollen nun die verschiedenen Möglichkeiten der Antragstellung unter OpenCA aufzeigen.
Mircrosoft-Client-Antrag
Auf der ersten Seite des Antrages sollten alle nötigen Informationen eingegeben werden. Dabei muss darauf geachtet werden, dass nur Bitlänge von 512,
1024 und 2048 bits für die Schlüssel verwendet werden50 . Nach einem Klick
auf OK können auf der nächsten Seite die zusammengefassten Informationen
noch einmal einsehen werden. Diese sollten gründlich überprüft werden. Ist bei
der Eingabe ein Fehler geschehen, kann man auf die erste Seite wechseln und
diesen korrigieren. Nach dem Klicken auf den OK-Button auf der zweiten Seite
generiert der Internet Explorer das Schlüsselpaar und den neuen Antrag. Ist
die Operation erfolgreich verlaufen, zeigt anschließend OpenCA eine Seite mit
dem Antrag und der generierten Seriennummer. Diese wird an keiner Stelle
gesichert, daher sollte sie sich der Benutzer merken, bevor er den generierten
Antrag im nächsten Schritt an die RA weiter schickt.
49
50
Weitere Informationen siehe Abschnitt 4.10.4 ”Reguläre Zertifikatbeantragung”.
Für eine hohe Sicherheit sollte mindestens eine Schlüssellänge von 1024 bit verwendet
werden.
140
4.9. Shell Skripte
SPKAC-Antrag
SPKAC-Anträge werden von Netscape, Mozilla and Opera benutzt. Alle drei
Browser unterstützen einen speziellen ”keygen”-tag [URL10], der zur Generierung des Schlüsselpaares und des Antrages verwendet wird. Auf der ersten
Seite des Antrages sollten alle nötigen Informationen eingegeben werden. Nach
einem Klick auf den OK-Button zeigt die zweite Seite alle eingegebenen Information nochmals an. Diese sollten gründlich überprüft werden. Als nächstes
muss die verwendete Schlüssellänge angegeben werden. Klickt man anschließend auf OK, so startet der Browser die Generierung der Schlüssel und des
Antrages. Ist die Operation erfolgreich verlaufen, zeigt OpenCA eine Seite mit
dem Antrag und der generierten Seriennummer. Diese wird nicht gesichert,
daher sollte sie sich der Benutzer merken, bevor er den Antrag im nächsten
Schritt endgültig an die RA weiterleitet.
Vorbereiteter PKCS#10-Antrag
Will man den PKCS#10-Antrag über das Webinterface einreichen, kann man
dies über das PUBLIC-Interface der RA tun. Wenn es möglich ist, sollte der
RA-Operator entsprechende Einschränkungen anlegen, um zu verhindern, dass
die RA mit falsch ausgestellten Anträgen überschwemmt wird.51
Server-seitige Schlüssel und Antragsgenerierung
Die Server-seitige Schlüssel und Antragsgenerierung nutzt dieselben Seiten, wie
die Anträge für Microsoft-Internet-Explorer oder Mozilla. Doch gibt es hier
einen entscheidenden Unterschied. Bei der Generierung des Antrages durch
den Internet Explorer oder Mozilla generiert der Browser alle nötigen Daten
und schickt nur den fertigen Antrag an die RA. Bei Server-seitiger Erzeugung
schickt das Interface alle eingegebenen Daten an den Server, der für den Client
die Schlüssel und den Antrag erzeugt. Dieser Weg kann genutzt werden, wenn
51
Weitere Informationen sind im Abschnitt ”Konfiguration” Unterabschnitt 4.5.1 ”CSRs”
einzusehen.
141
4.10. Anwendungsszenarien
der Nutzer nur ein geringes Wissen über PKIs besitzt oder man einen Browser
verwendet, der keine Client-seitige Erzeugung von Schlüsseln und Anträgen
unterstützt.
Handhabung
Auf der ersten Seite des Antrages sollten alle nötigen Informationen eingegeben werden. Nach dem klicken auf OK kann man auf dem nächsten Bildschirm
die zusammengefassten Informationen noch einmal einsehen. Nach dem wiederholten Klicken auf den OK-Button werden alle Informationen an den Server
gesendet, der die Schlüssel und den Antrag generiert. Ist die Operation erfolgreich verlaufen, zeigt anschließend OpenCA eine Seite mit dem Antrag und
der generierten Seriennummer.
Dieser Abschnitt erleichtert den ersten Einstieg und Umgang mit OpenCA und
gibt dem Operator wie auch dem regulären Anwender Hilfestellung. Diese Ausführung wird mit der ersten Inbetriebnahme von CA und RA beginnen. Dabei
soll im weiteren Verlauf das Aufzeigen mehrerer kompletter Arbeitsabläufe eine
Hilfe im Umgang mit den Interfaces von OpenCA bieten52 .
4.10.1. Erstinitialisierung der CA
Im CA-Interface unter Allgemein -> Initialisierung finden sich drei Punkte für
die Erstinitialisierung der CA welche in Abbildung 4.7 dargestellt ist.
Initialisieren der Zertifizierungsstelle
1. Show SQL statements for database initialization
Hier können die SQL-Statements, die für die Erstinitialisierung der Datenbank verwendet werden, eingesehen werden.
52
Bei den Beschreibungen wird von der Umsetzung und Konfiguration des Prototypen
ausgegangen.
142
Abbildung 4.7.: CA-Interface Erstinstallation
2. Initialisierung der Datenbank
Erstinitialisierung der leeren Datenbank für den Betrieb an OpenCA.
3. Erzeugen des privaten Schlüssels der CA
Hier wird der private Schlüssel, der zentrale Bestandteil der gesamten
Vertrauenskette, erzeugt. Dabei wurden für den privaten Schlüssel des
Prototypen folgende Einstellungen verwendet:
• Verschlüsselungsalgorithmus = DES3
• asymmetrischer Algorithmus = RSA
143
• Schlüssellänge = 4096 bit
• Passwort = Hier sollte ein sicheres Passwort gewählt werden.
4. Erzeugen eines neuen CA-Zertifizierungsantrages (Benutzen des
generierten Schlüssels)
Hier wird der Zertifikatsantrag für das selbstsigierte Zertifikat der Zertifizierungsstelle erzeugt. Will man den DC-Style verwenden, können im
ersten Teil des Antrages die Felder leer gelassen werden. Erst im zweiten
Teil sollte die DN eingetragen werden. Dabei muss für den geplanten Einsatz eines LDAP-Server darauf geachtet werden, dass der Pfad korrekt
angegeben wird. Die Angabe für die Initialisierung des Prototypen sieht
folgendermaßen aus:
emailAddress = RootZertifik a t V1 @ c s . informatik . de , CN = User - CA ,
OU = Informatik , O = Fachbereich DCSM , DC = cs , DC = fh - wiesbaden , DC = de
Anmerkung: DC, CN usw. müssen groß geschrieben werden (OpenSSL
ist case sensitive).
Nach dem Abschicken des Antrags erscheint eine Passwortabfrage, um
den Antrag durch die CA anzunehmen. Dazu muss das Passwort des
privaten Schlüssels der CA angegeben werden.
5. Selbstsigniertes CA-Zertifikat
Hier wird der Antrag von der CA selbst signiert. Dazu muss, nach der
Angabe der Laufzeit zur Signierung des Wurzelzertifikates, das Passwort
des privaten Schlüssels eingegeben werden.
6. Signiert von einer anderen CA
Durch die folgenden Punkte wird es möglich, die CA auch als eine SubCA einer übergeordneten CA zu betreiben. Als Erstes muss dazu der
oben erstellte Antrag exportiert (Format PKCS#10) und an die für die
übergeordnete CA zuständige RA übermittelt werden. Diese prüft den
144
Antrag und leitet ihn an die CA weiter. Die übergeordnete CA signiert
den Antrag und schickt ihn an die untergeordnete CA zurück. Nun kann
das signierte Zertifikat an dieser Stelle importiert werden.
7. Exportieren des Zertifizierungsantrages der CA
Für den Betrieb einer Sub-CA kann hier der Antrag zum Zertifizieren an
einer übergeordneten CA exportiert werden.
8. Importieren des CA-Zertifikates (ausgestellt durch eine andere
CA)
Hier kann das durch eine übergeordnete CA ausgestellte Zertifikat importiert werden.
Für weitere Informationen zu den Initialisierungsphasen sei an dieser Stelle auf
die Benutzeranleitung im organisatorischen Anhang Abschnitt B.3 ”Benutzeranleitung OpenCA” verwiesen.
4.10.2. Erstinitialisierung der RA
Dieser Punkt ist von Bedeutung, wenn die CA als Offline-CA betrieben wird
bzw. RA und CA getrennte Datenbanken besitzen. Ist dies der Fall, muss unter
dem NODE-Interface der RA der Punkt Administration -> Server Initialisierung -> Initialisierung der Datenbank ausgeführt werden. Dadurch wird eine
eigene Datenbank für die RA initialisiert. Voraussetzung ist der richtig konfigurierte Datenbankzugriff (Siehe Abschnitt 4.4.4 ”Zusammenfassung”).
4.10.3. Datenaustausch CA zu RA
Ist die CA erfolgreich initialisiert, muss als erstes ein Export von der OfflineCA an die Online-RA erfolgen. Dabei werden das CA-Zertifikat und die eventuell erzeugten neuen Userzertifikate, für CA- und RA-Operator, veröffentlicht53 . Um einen Datenaustausch von CA zu RA einzuleiten, muss sich der
53
Erst durch die Veröffentlichung des CA-Zertifikates ist es der RA möglich, Anträge anzunehmen.
145
CA-Operator unter dem CA-Interface Allgemein -> Kontenverwaltung auf das
NODE-Interface begeben. Dort wiederum unter Administration -> Datenaustausch gelangt der Operator auf das zentrale Datenaustausch-Interface (siehe
Abbildung 4.8).
Abbildung 4.8.: Datenaustausch
1. Da die Offline-CA die höchste Ebene innerhalb einer Zertifizierungsstelle darstellt, gelten für den Export an die RA die Punkte unterhalb des
146
Abschnitts Exportieren von Daten zu einer niedrigeren Ebene der Hierarchie. Hier sollte man für den erstmaligen Export an die RA ”Alle”
anwählen. Nach dem Export ist es möglich, das generierte Archiv openca.tar unter /srv/openca/datenaustausch/ einzusehen.
2. Als nächstes muss das exportierte Archiv an die Online-RA übertragen
werden. Hierbei kommt das Skript sync.sh unter /OPENCADIR/sh-tools/
zum Einsatz54 . Durch den Aufruf
./ sync . sh 192.168.1.51 / srv / openca / datenaustausch / openca . tar
/ srv / openca / datenaustausch / srv / openca / backup / datenaustausch
wird das zu exportierende Archiv auf die Online-RA übertragen. Bei
Bedarf kann anschließend eine Sicherung des Archives im Verzeichnis
/OPENCADIR/backup/datenaustausch/ automatisch abgelegt werden.
3. Der nächste Schritt muss vom Operator der Online-RA durchgeführt werden. Auch dieser muss sich auf das NODE-Interface (Kontenverwaltung)
begeben und dort unter Administration -> Datenaustausch im Abschnitt
Download data from a higher level of the hierarchy mit ”Alle” den Import
starten. Bei diesem Import werden das CA-Zertifikat und die eventuell bei der Erstinitialisierung erstellten Zertifikate der Operatoren überspielt. Dabei werden die Nutzerzertifikate in die lokale Datenbank und
das CA-Zertifikat in das Verzeichnis /OPENCADIR/var/crypto/cacerts/
der Online-RA eingespielt. Weiter werden die neuen Nutzerzertifikate unter OU=Users, DC=cs, DC=fh-wiesbaden, DC=de auf dem LDAP-Server
veröffentlicht55 . Ist dieser Vorgang abgeschlossen kann auf die Zertifikate
im PUBLIC-Interface der RA und im LDAP-Server zugegriffen werden.
54
55
Nähere Informationen zu der Anwendung siehe Abschnitt 4.9 ”Shell Skripte”.
Die automatische Veröffentlichung auf dem LDAP-Server ist nur aktiv, wenn in der
node.conf das Attribut updateLDAPautomatic auf YES gesetzt ist. Ist dies nicht der
Fall, muss die LDAP-Aktualisierung manuell über das LDAP-Interface der Online-RA
durchgeführt werden.
147
Nach dem erfolgreichen Import ist nun die RA in der Lage, Zertifikatsanträge (CSRs) anzunehmen und Informationen über die CA auf dem
PUBLIC-Interface zu veröffentlichen.
4.10.4. Reguläre Zertifikatbeantragung
Dieser Abschnitt ist in zwei Teile unterteilt. Zum einen in die Sicht des Nutzers,
der einen Antrag auf Zertifizierung stellt, und zum anderen in die Sicht des
RA- und CA-Operators, der die Zertifizierung durchführt.
Nutzer Teil 1
Der Nutzer ruft auf dem PUBLIC-Interface der RA unter Nutzer den Punkt
Beantragen eines Zertifikates auf. Hier stehen ihm drei mögliche Antragsarten
zur Verfügung (siehe Abbildung 4.9).
Welche der möglichen Antragsarten gewählt wird, hängt davon ab, welchen
Browser der Antragsteller verwendet56 . In diesem Szenario wird davon ausgegangen, dass der Nutzer einen SPKAC-fähigen Browser verwendet. Deshalb wird der Antrag unter dem Link Netscape-Zertifizierungsantrag gewählt
(Anmerkung: der Inhalt der Anträge ist überall identisch). In dem sich nun
öffnenden Dialog muss der Nutzer seine Basisinformationen für die Zertifizierung eingeben. In diesem Beispielszenario werden dabei folgende Daten für den
Nutzer hwink001 angegeben:
• E-Mail = [email protected]
• Nutzername = hwink001
• Name (Vor- und Nachname) = Winkler Hans-Georg
56
An dieser Stelle sei auf den Abschnitt 4.9.4 ”CSR Handhabung” verwiesen: dort stehen
genauere Informationen über die möglichen Antragsarten.
148
Abbildung 4.9.: Antrag auf Zertifizierung
• Rolle = Student
• Registrierungsinstanz (RA) = Trustcenter selbst
• PIN = Hier muss ein sicheres Passwort vergeben werden mit dem später der private Schlüssel bzw. der PKCS#12 Container gesichert ist. Im
Testlauf des Prototyp wurde das Passwort ”supermario” angegeben.
• Schlüssellänge = 1024
Wird der Antrag anschließend abgeschickt, generiert als erstes das interne
Verschlüsselungs-Modul von Mozilla ein Schlüsselpaar, erzeugt daraus den Antrag, speichert den privaten Schlüssel im Browser des Nutzers und schickt den
Antrag an die RA ab. Ist dieser Prozess erfolgreich abgeschlossen, erscheint eine
Seite (Abbildung 4.10) die noch einmal alle Einzelheiten des Antrages auflis-
149
tet. Dabei ist die Seriennummer des Antrages von besonderer Bedeutung. Diese
Abbildung 4.10.: Abgeschlossener Antrag
sollte unbedingt notiert werden, da ohne der Kenntnis der Seriennummer das
am Ende ausgestellte Zertifikat nicht angenommen werden kann.
Operator Teil
Wurde der Antrag vom Nutzer abgeschickt, kann nun der RA-Operator diesen auf dem RA-Interface unter Aktive CSRs -> Neu einsehen. Durch Klicken
auf die Seriennummer gelangt man zu den Details des Antrages. Dabei ist es
150
dem RA-Operator möglich, den Antrag wenn nötig nachträglich zu bearbeiten.
Wird der Antrag angenommen, so kann dieser Vorgang über den Button Antrag genehmigen eingeleitet werden. Dabei ist es möglich, bei einem installierten Nutzerzertifikat den CSR zusätzlich durch den RA-Operator zu signieren.
Als nächstes muss der genehmigte Antrag aus der lokalen Datenbank der
Online-RA an die Datenbank der Offline-CA übertragen werden. Dazu werden Daten zu einer höheren Ebene der Hierarchie exportiert. Dies erreicht der
RA-Operator über das NODE-Interface unter Administration -> Datenaustausch -> Exportieren von Daten zu einer höheren Ebene der Hierarchie ->
Alle 57 . Verlief der Exportprozess erfolgreich, muss anschließend das Archiv mit
dem sync.sh Skript an die Offline-CA übertragen werden. In diesem Szenario
lautet der Aufruf:
./ sync . sh 192.168.1.50 / srv / openca / datenaustausch / openca . tar
/ srv / openca / datenaustausch / srv / openca / backup / datenaustausch
Ist der Transport zur Offline-CA gelungen, kommt an dieser Stelle der CAOperator ins Spiel. Er importiert das neue Archiv über das NODE-Interface
der CA unter Administration -> Datenaustausch -> Importieren von Daten
von einer niedrigeren Ebene der Hierarchie -> Alle. Ist der Import abgeschlossen, wird der neue CSR in die Datenbank der Offline-CA geschrieben und
ist somit für den CA-Operator unter dem CA-Interface einsehbar. Soll nun
der Zertifikatantrag durch die CA signiert werden, kann der CA-Operator unter dem CA-Interface Normale Operationen -> Genehmigte Zertifizierungsanträge den Zertifikatantrag durch Klicken auf die Seriennummer des Antrages
einsehen und diesen entweder löschen oder das Zertifikat ausstellen. Soll das
Zertifikat ausgestellt werden, muss das Passwort des privaten Schlüssels der
CA eingegeben werden. Ist der Prozess der Zertifizierung erfolgreich, wird das
57
Um Komplikationen beim Import und Export zu vermeiden, sollte darauf geachtet werden, dass nach dem Datenaustausch das Verzeichnis /OPENCADIR/datenaustausch/ immer geleert wird.
151
neu ausgestellte Zertifikat in die Datenbank der Offline-CA geschrieben. Um
nun dieses der Öffentlichkeit verfügbar zu machen, muss wiederum unter dem
NODE-Interface ein Export von Daten zu einer niedrigeren Ebene der Hierarchie eingeleitet werden. Danach werden die Daten mithilfe des sync-sh Skriptes
wieder an die Online-RA übertragen und dort vom RA-Operator importiert.
Bei diesem Vorgang wird nicht nur das Zertifikat auf der lokalen Datenbank der
Online-RA veröffentlicht, sondern auch im LDAP-Server unter UID=hwink001,
OU=Users, DC=cs, DC=fh-wiesbaden, DC=de. Nach dem Import kann der RAOperator die neuen Zertifikate unter dem RA-Interface Informationen -> Zertifikate -> Gültig einsehen. Bei Server-seitiger Schlüsselgenerierung kann an
dieser Stelle noch zusätzlich, je nach Einstellung in der ra.conf, eine zusätzliche PIN für die Auslieferung des PKCS#12-Containers an den Antragsteller
festgelegt werden. Will dann der Nutzer diesen herunterladen, muss als erstes
die PIN für den privaten Schlüssel und als zweites die PIN für die Auslieferung
eingegeben werden. Erst dann erhält der Nutzer sein Schlüsselpaar58 .
Nutzer Teil 2
Nachdem der Nutzer von der RA informiert wurde, dass sein Zertifikat bereitsteht, begibt er sich auf das PUBLIC-Interface unter Nutzer -> Laden des
beantragten Zertifikates. Wichtig ist dass der Nutzer mit genau demselben
Browser, mit dem das Zertifikat beantragt wurde, den Vorgang des Ladens
des beantragten Zertifikates durchführt. Dies ist notwendig da erstellte private Schlüssel im Keystore des Browser abgelegt wurde und nur durch das Laden
des Zertifikates aktiviert werden kann. Zum Laden des Zertifikates kann man
entweder die Seriennummer des Zertifikates oder die Seriennummer des Antrages verwenden. In diesem Beispiel ist die Seriennummer des Antrags die
Zahl 800. Nach Eingabe und Bestätigung unter dem PUBLIC-Interface der
RA Nutzer -> Laden des beantragten Zertifikates wird das Zertifikat in den
Keystore des Browsers übertragen und zusammen mit dem dazugehörigen pri58
Siehe dazu im organisatorischen Anhang Abschnitt B.3.6 ”Download eines Zertifikates”.
152
vaten Schlüssel abgelegt. Will der Nutzer nachsehen, ob der Import erfolgreich
stattgefunden hat, kann er das unter Einstellungen -> Erweitert -> Zertifikate verwalten -> ihre Zertifikate nachprüfen59 . Dort muss ein neues Zertifikat
unter dem Namen hwink001 erscheinen. Dieses Zertifikat nebst dem privaten Schlüssel kann vom Nutzer als PKCS#12-Datei exportiert und in andere
Anwendungen (z.B. ein E-Mail-Programm oder ein anderer Browser) wieder
importiert werden. Damit ist der Prozess der Beantragung und Ausstellung
eines Zertifikates abgeschlossen.
Anmerkung zur Server-seitigen Schlüsselgenerierung
Müssen die Schlüssel komplett Server-seitig generiert werden, da z.B. der Browser nicht unterstützt wird, kann der private Schlüssel nebst dem Zertifikat nach
der Veröffentlichung auf dem PUBLIC-Interface als PKCS#12-Datei heruntergeladen werden. Weitere Informationen dazu, werden im organisatorischen
Anhang Abschnitt B.3.6 ”Handhabung der Zertifikate” gegeben.
Abschließend wird in Abbildung 4.11 ein Überblick über den eben beschriebenen Prozess gegeben.
Export zu
CA
erstellen der
Schlüssel
Nutzer
Antrag mit
Browser
Genehmigung
durch RA
Signieren durch
CA
Export zu
RA
Nutzer
Zertifikat incl.
Private Key
befindet sich im
Keystore des
Nutzers
Annehmen des
Zert. im Pub
Import in
Keystore
Abbildung 4.11.: Prozess Zertifikat Antrag
59
Es wurde der Browser Firefox verwendet.
153
Automatische Zertifikaterstellung
Der Vorgang der Automatische Zertifikaterstellung wird vollständig vom Operator der CA und RA durchgeführt. Dabei beginnt der Prozess (siehe Abbildung 4.12) mit dem Erhalt der Studentenliste des Fachbereiches vom Studentensekretariat der Fachhochschule60 . Diese Liste wird unter anderem an den
Operator der CA weitergereicht. Dieser muss als erstes den geplanten BatchProzess (Import aller neu eingeschriebenen Studenten des Fachbereichs in die
User CA) vorbereiten. Dies bedeutet, dass aus der Studentenliste die Datei
batch_process_data.txt für den Batch-Prozessor generiert und für den Import
in das Batch-System vorbereitet werden muss. Dieser Vorgang wird durch das
Skript user2batch.sh erledigt, welches speziell für diese Anwendung geschrieben wurde.
Der erste Schritt des CA-Operators besteht also in folgendem Aufruf:
/ OPENCADIR / sh - tools / user2batch . sh / OPENCADIR / batch / import / user . txt
/ OPENCADIR / batch / backup / batchimport / OPENCADIR / batch
Dadurch wird die Liste user.txt in /OPENCADIR/batch/import/ als Eingabedatei verwendet. Die daraus erzeugte batch_process_data.txt und die dazugehörige Importdatei wird unter /OPENCADIR/backup/batchimport/ im Unterverzeichnis userimport_um_DATUM abgelegt. Weiter wird die erzeugte
Importdatei nochmal im Importpfad der Batch (/OPENCADIR/batch/) eingespielt.
Nach der erfolgreichen Ausführung des Skriptes sollte eine nachträgliche Prüfung der in /OPENCADIR/backup/batchimport/userimport_vom_DATUM abgelegenen batch_process_data.txt vorgenommen werden, um eventuelle Fehlfunktionen des Skriptes rechtzeitig erkennen zu können. Ergibt die Prüfung
keine Fehler, kann der CA-Operator über das BATCH-Interface der OfflineCA den Import der User mit ihren Prozessen in das Batch-System vornehmen.
60
Nähere Informationen zur Studentenliste siehe Abschnitt 4.7 ”Batch”.
154
Dazu wird unter dem BATCH-Interface Batch-System -> Workflow Management der Punkt ”Quickimport - see manual !” ausgeführt. Nach dem erfolgreichen Import können die importierten Nutzer mit ihren Prozessdaten unter
/OPENCADIR/var/bp/users/ eingesehen werden.
Um nun den Batch-Prozess des Erzeugens der Schlüsselpaare und der Zertifikate zu starten, wählt der CA-Operator den Punkt ”Durchführen von Operationen für die Workflows”. Die darauf erscheinende Auswahl sollte insofern
verändert werden, dass die Anzahl der Schritte für das Batch-System auf 16 gesetzt wird und ”CA key” und ”Key of the batch system” jeweils auf Yes gesetzt
werden. Nach dem OK wird zweimal das CA-Passwort des privaten Schlüssels
abgefragt und der Batch-Prozess beginnt. Durch den Prozess wird für jeden
Nutzer ein Schlüsselpaar und ein dazugehöriges Zertifikat erzeugt. Das Zertifikat wird in der lokalen Datenbank und der private Schlüssel nebst dem Zertifikat als PKCS#12-Datei unter /OPENCADIR/bar/bp/dataexchange/pkcs12/
im Dateisystem der Offline-CA abgelegt. Diese PKCS#12-Datei ist wiederum
mit einer PIN gesichert, die während des Batch-Prozesses erzeugt wird. Um
an diese PIN zu gelangen, muss der CA-Operator den Punkt ”Exportieren
von PINs” unterhalb von ”Workflow Management” ausführen. Dabei wird eine
pin_list unter /OPENCADIR/bar/bp/dataexchange/ erzeugt. Hier kann zum
jeweiligen Userprozess die dazugehörige PIN abgefragt werden61 . Damit ist die
Arbeit des CA-Operators, abgesehen vom Verteilen der PKCS#12-Dateien an
die entsprechenden Nutzer, soweit abgeschlossen. Es verbleibt nur noch der
Export der Zertifikate an die RA über das NODE-Interface. Ist auch dieser
Schritt abgeschlossen, können die neuen Zertifikate nach dem Import durch
den RA-Operator von den Nutzern im PUBLIC-Interface eingesehen werden.
61
Was nun mit der PIN geschieht und wie diese dem Studenten mitgeteilt wird, wird im
Abschnitt 4.8.1 ”Probleme mit der PIN” diskutiert.
155
Import zu
Batch
user2batch
Studentenliste
batch_process_
data.txt
Batch-Prozess
Export zu
RA
Import in
Keystore
Nutzer
Zertifikat incl.
Private Key als
PKCS#12 als
Import in
Keystore
Auslieferung der
PKCS#12
Container
Abbildung 4.12.: Prozess der automatischen Zertifikaterstellung
4.10.5. Sperren von Zertifikaten
Auch dieser Abschnitt ist in zwei Teile aufgeteilt. Der erste Teil stellt die Sicht
des Nutzers, der sein Zertifikat sperren lassen will dar, der Zweite die Sicht
des RA- und CA-Operators, der die Sperrung durchführt.
Nutzer Teil 1
Tritt der Fall ein, dass ein Zertifikat vor Ablauf seiner Gültigkeit kompromittiert oder nicht mehr gebraucht wird, muss es der Inhaber im eigenen Interesse
sperren lassen. Dazu begibt er sich auf das PUBLIC-Interface der Zertifizierungsstelle, die sein Zertifikat verwaltet. Unter dem Punkt Nutzer -> Zertifikat
zurückrufen hat er die Möglichkeit, dieses unter Angabe der Seriennummer, eines Grundes und der CRIN62 zu tun.
Operator Teil
Unter dem RA-Interface kann nun der RA-Operator unter Aktive CRRs ->
neu den Antrag auf Sperrung einsehen, gegebenenfalls anpassen und durch die
Genehmigung an die CA weiterleiten. Bevor aber die CA auf den Sperrantrag
zugreifen kann, muss vorher ein Export/Import von der RA zur CA über das
62
Certificate Revocation Number; siehe auch Abschnitt 4.8.2 ”Probleme mit der CRIN”.
156
NODE-Interface stattfinden. Ist dieser erfolgreich, kann der CA-Operator auf
dem CA-Interface unter Normale Operationen -> Genehmigte Rückrufe das
Zertifikat sperren. Nach Abschluss dieses Schrittes muss die CRL unter Normale Operationen -> Erstellen einer neuen CRL aktualisiert werden. Damit ist
die Sperrung durch die CA aktiv und wird durch den nächsten Datenaustausch
zwischen RA und CA zur Veröffentlichung gebracht.
Nutzer Teil2
Damit der Nutzer erkennen kann, ob ein Zertifikat gesperrt ist oder nicht,
muss er unter dem PUBLIC-Interface der RA CA-Informationen -> ZertifikatsRückruf-Listen die aktuelle CRL herunterladen und in seine Applikation importieren63 . Erst dann ist es der entsprechenden Applikation möglich, zwischen
gültigen und gesperrten Zertifikaten zu unterscheiden. Die gesperrten Zertifikate können aber auch manuell unter dem PUBLIC-Interface Zertifikate ->
zurückgerufen eingesehen werden.
Nutzer
Sperrantrag mit
Browser
Genehmigung
durch RA
Export zu
CA
Sperrung,
Erneuerung CRL
Export zu
RA
Nutzer
herunterladen
der CRL
Importieren der
CRL
Import in
Keystore
Abbildung 4.13.: Prozess der Sperrung von Zertifkaten
63
Zusätzlich können die Quellen für die CRLs aus dem Feld ”X509v3 CRL Distribution
Points” des Zertifikates entnommen werden.
157
4.10.6. Verlängern von Zertifikaten
Nutzerzertifikate
Das Verlängern der Zertifikate ist eine Aufgabe, um die sich der Zertifikatinhaber kaum kümmern muss. Das Einzige, was dieser zwei Wochen vor dem
Ablauf tun soll, ist eine formlose E-Mail an den zuständigen RA-Operator zu
senden um eine Verlängerung des Zertifikates zu beantragen. Für den Rest
dieser Operation ist der RA-Operator verantwortlich, der für das Zertifikat
eines Nutzers, wenn es abgelaufen ist, die Neusignierung in die Wege leitet.
Dazu muss der RA-Operator nach dem Ablauf des Zertifikates dieses im RAInterface unter Informationen -> Zertifikate -> Abgelaufen einsehen. Ist das
Zertifikat aufgerufen, wird auch die Seriennummer des CSR angezeigt. Dieser
ist ein Link. Folgt man diesem, wird man zu dem dazugehörigen CSR weitergeleitet. Ist nun das Zertifikat abgelaufen, gibt OpenCA dem RA-Operator die
Möglichkeit, den CSR erneut zu genehmigen. Wird dies ausgewählt, wird der
CSR wieder als aktiver Antrag in die Datenbank geschrieben und beim nächsten Export an die Offline-CA überspielt. Signiert nun der CA-Operator den
CSR, kommt das einer Zertifikatsverlängerung gleich, da das alte Zertifikat
in der Datenbank überschrieben und das neue beim nächsten Export an die
Online-RA veröffentlicht wird. Ist dieser Prozess erfolgreich durchlaufen, sollte
der Nutzer über die üblichen Wege von der Erneuerung in Kenntnis gesetzt
werden.
CA-Zertifikate
Ein CA-Zertifikat muss meist vor seinem eigenen Ende der Gültigkeit erneuert werden. Dies ist deshalb der Fall, da nur Zertifikate abgezeichnet werden
können, die mit ihrer Lebenszeit nicht die des CA-Zertifikates überschreiten.
Ist nun z.B. das CA-Zertifikat auf 12 Jahre ausgelegt und werden innerhalb
der CA Zertifikate mit bis zu einer Lebensdauer von 5 Jahren vergeben, muss
das CA-Zertifikat spätestens 5 Jahre vor seinem Ablauf, also nach 7 Jahren,
158
erneuert werden.
Muss nun das CA-Zertifikat erneuert werden, sollte eine Neu-Erstellung des
Schlüsselpaares aus sicherheitstechnischer Sicht mit in Betracht gezogen werden. OpenCA bietet in der Hinsicht des CA-Schlüsselwechsels keine Automatiken an, so dass an dieser Stelle von RA und CA-Operator selbst Hand angelegt
werden muss. Zu diesem Zweck wurden für die Sicherung des alten Schlüsselpaar und CA-Zertifkats auf der Offline-CA unter /OPENCADIR/crypto/ die
Verzeichnisse cacerts-old/ und keys-old/ erstellt. Auf der Online-RA wurde ebenfalls zur Sicherung das Verzeichnis cacerts-old/ erstellt. Mit diesen
Voraussetzungen ergibt sich für den CA-Schlüsselwechsel folgender Ablauf.
CA-Operator
1. Sichern des alten Schlüsselpaares und CA Zertifikates
Es muss als Erstes im Verzeichnis /OPENCADIR/crypto/ der Inhalt von
cacerts/ nach cacerts-old/ und keys/ zu keys-old/ kopiert werden.
2. Entfernen des alten Schlüsselpaares
Nach dem Sichern des alten Schlüsselpaares und CA Zertifikates können
nun folgende Dateien gelöscht werden:
• cacerts/: cacert.der, cacert.pem, cacert.txt
• chain/: den gesamten Inhalt außer das makefile
• keys/: cakey.pem
Ist dieser Vorgang abgeschlossen, muss als Letztes das alte CA-Zertifikat
aus der Datenbank der CA entfernt werden. Dazu muss man in der Datenbank der CA in der Tabelle ca_certificate den entsprechenden Eintrag
löschen.
3. Neuerstellung des Schlüsselpaares
Jetzt ist die CA ohne Schlüsselpaar und CA-Zertifikat, so dass im CAInterface unter Allgemein -> Initialisierung -> Phase1, angefangen mit
159
dem ”Schlüsselsetup”, ein neues Schlüsselpaar mit dazugehörigem Zertifikat erzeugt werden kann. Weiter sollte bei der Erzeugung eines neuen
Antrages für das CA-Zertifikat ein anderer DN als der vorherige verwendet werden, um auf dem LDAP-Server eine Unterscheidung zwischen
altem und neuem Zertifikat treffen zu können. Im Falle des Prototypen
wurde im Attribut [email protected] von
V1 auf V2 gewechselt.
4. Veröffentlichung
Nach der erfolgreichen Generierung des neuen Schlüsselpaares und CAZertifikates sollte vor dem Export noch eine neue CRL generiert werden, da die alte auf Grund des Schlüsselwechsels ihre Gültigkeit verloren
hat. Nachdem dies geschehen ist, müssen als nächstes über das NODEInterface der CA die neuen Daten an die RA exportiert und mit dem
sync.sh Skript übertragen werden.
RA-Operator
1. Sichern und anschließendes Entfernen des alten CA-Zertifikates
Bevor der Import des neuen CA-Zertifikates stattfinden kann, muss das
alte erst entfernt werden. Dazu kann genauso wie auf der CA vorgegangen
werden (Sichern des alten CA-Zertifikates im Filesystem und anschließendes Entfernen aus der RA-Datenbank und dem Filesystem)64 .
2. Import des neuen CA-Zertifikates
Sind diese Vorbereitungen abgeschlossen, kann nun der Import des neuen
CA-Zertifikates über das NODE-Interface erfolgen.
Nachdem die oben beschriebenen Schritte ausgeführt wurden, ist nun ein neues
Schlüsselpaar mit dazugehörigem CA-Zertifikat verfügbar. Weiter sollte darauf
geachtet werden, das alte Root-Zertifikat solange online zu halten, bis die durch
64
Da der private Schlüssel der CA nicht an die RA exportiert wird, braucht der Ordner
keys nicht gesichert werden (er ist leer).
160
das Root-Zertifikat ausgestellten Nutzerzertifikate abgelaufen sind. Um dies zu
erreichen, wurde das Menü des PUBLIC-Interface sowie ein internes Kommando von OpenCA angepasst, um das Laden des alten CA-Zertifikates aus dem
Verzeichnis unter /OPENCADIR/crypto/cacerts-old/ zu ermöglichen. Diese
beiden Anpassungen werden nun an dieser Stelle kurz erläutert.
Anpassung des PUBLIC-Menüs
Um einen neuen Eintrag für das Herunterladen des alten CA-Zertifikates einzufügen, wurde die menu.xml auf der Online-RA unter /OPENCADIR/etc/ im
PUBLIC Teil (<name>pub</name>) unterhalb von <id>5</id> um folgenden Eintrag erweitert:
< item >
< name > Laden des
alten CA Zertifikates </ name >
< link > cmd = getStaticPage ; name = download_old_cacert </ link >
< target > main </ target >
</ item >
Nach dem Neustart von OpenCA wird durch diese Änderung der Eintrag ”Laden des alten CA-Zertifikates” im PUBLIC-Interface unter dem Punkt CAInformationen verfügbar.
Anpassung des Kommandos getStaticPage
Wie schon im obigen Abschnitt zu sehen ist greift der neu erstellte Eintrag
”Laden des alten CA-Zertifikates” auf ein internes Kommando namens getStaticPage zu. Dieses Kommando hat unter OpenCA die Aufgabe, verschiedene
HTML-Seiten zu generieren, die unter den Interfaces Verwendung finden. Wird
nun dem Kommando getStaticPage der Parameter download_old_cacert übergeben, bedeutet das, dass innerhalb des Kommandos eine Behandlung dieses
Parameters stattfinden muss, um eine entsprechende HTML-Seite zu generieren. Dieser Parameter ist aber so nicht verfügbar und wurde im Laufe der
Entwicklung des Prototypen am Beispiel des Parameters download_cacert implementiert. Dazu wurde im Quellcode von getStaticPage der Codeausschnitt
161
für download_cacert dupliziert und den eigenen Bedürfnissen angepasst (Siehe
Listing 4.15)65 .
# Aenderung durch Hans - Georg Winkler am 16.5.06
# Erweiterung um die Moeglichkeit des Downloads des alten CA - Zertifikates nach
einem Schluesselwechsel oder einer Z e r t i f i k a t e r n e u e r u n g
} elsif ( $query - > param ( ’ name ’) =~ / d ow n l o ad _ o ld _ c ac e r t /) {
$name = gettext ( " Download und Installation des alten
CA - Zertifikates " ) ;
$exp
= gettext ( " Diese Seite stellt das alte CA - Zertifikat in
verschiedenene Formaten zur Verf & uuml ; gung . Bitte importieren sie
sich das alte CA - Zertifikat , wenn sie mit Nutzern ko mm uni tz ie ren
wollen die durch das alte CA - Zertifikat zertifiziert wurden
( g & uuml : ltig bis zu der Seriennummer ...) . Zum importieren klicken
sie einfach auf den passenden Link " ) ;
$item_list - >[0] - >[1] = gettext ( " [ Mozilla , Netscape and Microsoft
Internet Explorer importable format ] " ) ;
$item_list - >[0] - >[0] = ’ <a
href =" ’. getRequired ( ’ Ht d o c s U r lP r e f i x ’) . ’/ cacert - old / cacert . crt " > ’.
gettext ( " CA certificate in format CRT " ) .
’ </a > ’;
$item_list - >[1] - >[1] = gettext ( " [ Server importable format ] " ) ;
$item_list - >[1] - >[0] = ’ <a
href =" ’. getRequired ( ’ Ht d o c s U r lP r e f i x ’) . ’/ cacert - old / cacert . pem " > ’.
gettext ( " CA certificate in format PEM " ) .
’ </a > ’;
$item_list - >[2] - >[1] = gettext ( " [ Another Microsoft Internet Explorer
importable format ] " ) ;
$item_list - >[2] - >[0] = ’ <a
href =" ’. getRequired ( ’ Ht d o c s U r lP r e f i x ’) . ’/ cacert - old / cacert . der " > ’.
gettext ( " CA certificate in format DER " ) .
’ </a > ’;
$item_list - >[3] - >[1] = gettext ( " [ Another Microsoft Internet Explorer
importable format ] " ) ;
$item_list - >[3] - >[0] = ’ <a
href =" ’. getRequired ( ’ Ht d o c s U r lP r e f i x ’) . ’/ cacert - old / cacert . cer " > ’.
gettext ( " CA certificate in format CER " ) .
’ </a > ’;
65
Erst nach dem Neustart von OpenCA werden die Änderungen im Code gültig.
162
$item_list - >[4] - >[1] = gettext ( " [ Just for information ] " ) ;
$item_list - >[4] - >[0] = ’ <a
href =" ’. getRequired ( ’ H t d o c s U rl P r e f i x ’) . ’/ cacert - old / cacert . txt " > ’.
gettext ( " CA certificate in text format " ) .
’ </a > ’;
Listing 4.15: Exemplarischer Ausschnitt der Änderungen an dem Kommando
getStaticPage
Zusätzlich zu den Änderungen im Code von OpenCA mussten, um das alte CAZertifikat über das PUBLIC-Interface im Punkt ”Laden des alten CA-Zertifikates” beziehen zu können, unter /APPACHEDIR/htdocs/pub/ das enthaltene
cacerts/ in cacerts-old/ umkopiert und die darin enthaltenen Verknüpfungen von /OPENCADIR/crypto/cacerts/ zu /OPENCADIR/crypto/cacerts-old/
umgelenkt werden, d.h. im /APPACHEDIR/htdocs/pub/ existieren nach dieser Aktion die zwei Verzeichnisse cacerts/ und cacerts-old/, die jeweils
Datei-Verknüpfungen auf /OPENCADIR/crypto/cacerts/ (für den Download
des neuen CA-Zertifikat) und /OPENCADIR/crypto/cacerts-old/ (für den
Download des alten CA-Zertifikat) enthalten.
In diesem Kapitel wurden die Arbeiten an dem Prototypen einer Zertifizierungsstelle am Beispiel der User CA dokumentiert. Dabei ging es in erster
Linie um den Aufbau, aber auch die Installation und Konfiguration, die in den
wichtigsten Schritten erläutert wurden. Weiter wurde die Anbindung der Zertifizierungsstelle an einen LDAP-Server beschrieben und auch die dabei auftretenden Probleme und Besonderheiten näher betrachtet. Die Handhabung und
Einbindung des Batch-Prozessors zum automatischen Erstellen von Zertifikaten wurde in einem weiteren Abschnitt abgehandelt. Zum Abschluss wurden
verschiedene Anwendungsszenarien für den Umgang mit den Interfaces von
OpenCA besprochen, um so dem Nutzer einen Überblick über die Zusammenhänge innerhalb von OpenCA zu geben.
163
Abschließend soll an dieser Stelle angemerkt werden, dass die in diesem Kapitel
behandelten Bereiche aufgrund ihres Umfangs nicht in jedem Detail besprochen werden konnten. Aus diesem Grund wurden im ”organisatorischen Anhang” weitere Themen zum Umgang mit den Interfaces und im ”technischen
Anhang” weitere Themen zur Installation und Konfiguration von OpenCA abgehandelt.
164
5. Erfahrungen mit Client
Software
Aufbauend auf das vorhergehende Kapitel, in dem die Einrichtung der Zertifizierungsstelle beschrieben wurde soll der daraus entstandene Prototyp entsprechenden Tests zur Einbindung in verschiedene Applikationen unterworfen
werden. In diesem Kapitel werden zusammenfassend die Erfahrungen der Unterstützung von Zertifikaten und LDAP-Funktionalitäten in verschiedenen EMail-Programmen, Adressbüchern und Schlüsselspeichern betrachtet.
Als Ausgangsbasis wird ein LDAP-Server verwendet, der vom Aufbau her dem
der Nutzerverwaltung des Fachbereiches entspricht. Ferner sind die darin enthaltenen Objekte von ihren Eigenschaften her wie denen auf dem Original
beschaffen. Als Basis für die Nachbildung der Nutzereinträge auf dem LDAP
diente der Account des Verfassers, der als LDIF ausgeliefert wurde. Durch
diese Informationen und das nachträgliche Einbinden der fachbereichinternen
Schemata fhw.schema und fhwstudent.schema war es möglich, den Zweig der
Nutzerverwaltung auf den LDAP-Server des Prototypen originalgetreu nachzubilden1 . Zu den Tests wurden unter OU=Users, DC=cs, DC=fh-wiesbaden,
DC=de fünf fiktive Nutzer mit ihren Daten und Zertifikaten abgelegt. Diese
werden zur Übersicht im Einzelnen aufgelistet:
• Winkler Hans-Georg = hwink001
• Boitz Martin = mboit001
1
Siehe dazu auch im Kapitel 4 ”Praktische Umsetzung” Abschnitt 4.6 ”LDAP”.
165
5.1. Mozilla (Thunderbird)
Kapitel 5. Erfahrungen mit Client Software
• Kibron Aron = akibr001
• Winkelmann Horst = hwink002
• Ruehle Ludwig = lrueh001
Bei allen zu testenden Clienten wurde die weitere Unterstützung von LDAP
durch das interne Adressbuch des jeweiligen Programms untersucht. Weiter
wurden die Import- und Export-Funktionen einer näheren Betrachtung unterzogen, sowie die Möglichkeiten der Einbindung eines Zertifikates in verschiedenen Schlüsselspeicher ausgewertet.
Thunderbird, basierend auf dem Quelltext der Mozilla Suite, ist unter anderem für Windows, Linux, Mac OS X, Solaris, OS/2 verfügbar und stellt die
Weiterentwicklung des Netscape E-Mail-Clients dar. Dabei hat sich dessen
Funktionalität erweitert. Die Menü-Führung entspricht in etwa der des Mozilla E-Mail-Clients, sodass diese Ausführungen auch für die Mozilla-Varianten
gelten.
5.1.1. Adressbuch
Das Adressbuch unter Thunderbird unterstützt LDAP-Adressbücher. Jedoch
ist ein Zugriff nur lesend möglich. Soll also ein Eintrag geändert werden, muss
der Nutzer auf andere Programme zurückgreifen.
Um den LDAP für das Adressbuch nutzbar zu machen, muss zuallererst unter
Adressbuch -> neu -> LDAP-Verzeichnis ein neues Adressbuch angelegt werden. Das nun erscheinende Fenster wurde für die Nutzung am LDAP-Server,
der auf dem EXTERN Host eingerichtet wurde, folgendermaßen ausgefüllt:
• Name: UserCA
• Hostname: 192.168.1.52
166
• Bind DN: ou=Users, dc=cs, dc=fh-wiesbaden, dc=de
• Port: 389
Ist das Adressbuch nach dem Klicken auf den OK-Button eingerichtet, kann
es getestet werden, indem man nach einem bestimmten Namen suchen lässt,
z.B., wie im Abbildung 5.1 zu sehen, nach ”hw”. Wie man sehen kann, wurden
Abbildung 5.1.: Mozilla LDAP-Adressbuch
die zwei User (hwink001 und hwink002) mit ihren Einträgen gefunden. Hier
wird ein Problem offensichtlich. Erstens ist Aufgrund fehlender Einträge2 im
User hwink001, wie CN=? oder SN=? keine Angabe von Vor- oder Nachname
möglich. Des weiteren kann das Thunderbird Adressbuch mit den abgelegten
Zertifikaten nichts anfangen, da es diese nicht aus dem Objekt auslesen kann.
Dies liegt an der grundsätzlich fehlenden Unterstützung des inetOrgPerson3
Zertifikat-Attributs ”userCertificate”.
5.1.2. Import/Export von Zertifikaten und CRLs
Im Gegensatz zu der LDAP Unterstützung im Adressbuch bereitet die Verwaltung der Zertifikate unter Thunderbird keine Probleme. Unter Einstellungen
2
3
Siehe auch das LDIF-Listing 4.8 im Kapitel 4 ”Praktische Umsetzung” Abschnitt 4.6
”LDAP”.
inetOrgPerson ist eine LDAP-Objekt-Klasse die Informationen über Personen speichern
kann. Sie wird mit ihren Attributen in der RFC 2798 [Smi00] beschrieben.
167
-> Datenschutz -> Sicherheit -> Zertifikate kann man den Keystore des Thunderbird einsehen. Wie in Abbildung 5.2 zu sehen, gibt es vier Kategorien.
Abbildung 5.2.: Mozilla Keystore
• Ihre Zertifikate:
Im Reiter ”Ihre Zertifikate” können die eigenen Zertifikate eingesehen
und verwaltet werden.
• Zertifikate anderer Personen:
Im Reiter ”Zertifikate anderer Personen” können die Zertifikate anderer
Teilnehmer, mit denen schon E-Mail-Kontakt besteht, eingesehen werden.
• Websites:
Im Reiter ”Websites” werden die Zertifikate für verwendete Webseiten
abgelegt.
• Zertifizierungsstellen:
Im Reiter ”Zertifizierungsstellen” kann man alle zugelassenen Zertifizierungsstellen einsehen. An dieser Stelle muss auch das Root-Zertifikat der
168
User CA importiert werden, um das eigene Zertifikat wie auch die der
anderen Teilnehmer verifizieren zu können.
Jede der vier Kategorien bietet dabei die Möglichkeit, neue Zertifikate zu importieren. Will man ein eigenes Zertifikat unter ”Ihre Zertifikate” importieren,
so muss die zu importierende Datei im PKCS#12 Format vorliegen, da der
private und öffentliche Schlüssel importiert wird. Bei allen anderen Importfunktionen wird nur der öffentliche Schlüssel importiert. Aus diesem Grund
wird hier nur eine Datei im PEM- oder CRT-Format benötigt. Für den Export gilt das Gleiche wie für den Import. Bei dem eigenen Zertifikat wird
im PKCS#12-Format exportiert und bei allen anderen im PEM-Format. Will
man sich den Inhalt eines Zertifikates ansehen, reicht dazu ein Doppelklick auf
das entsprechende Zertifikat im Keystore. Dabei ergibt sich folgendes Bild in
Abbildung 5.3.
Abbildung 5.3.: Mozilla Zertifikat Ansicht
169
5.2. KMail
Wie man sehen kann gibt Thunderbird dem Nutzer einen Überblick über die
Attribute des Zertifikates. Reichen diese Informationen nicht, kann über den
Reiter ”Details” direkt auf die einzelnen Attribute des Zertifikates zugegriffen
werden. Um die Zertifikate im Keystore von Thunderbird auch zur Signierung und Verschlüsselung nutzen zu können, müssen diese unter Konten ->
entsprechendes Nutzerkonto -> S/MINE -Sicherheit -> Digitale Unterschrift
eingebunden werden. Nun kann beim Schreiben einer E-Mail die Signier- und
Verschlüsselungsfunktion auf Basis der angegeben Zertifikate genutzt werden.
Sollen CRLs Verwendung finden, können diese unter Einstellungen -> Datenschutz -> Sicherheit -> CRLs importiert werden.
5.2. KMail
Der E-Mail-Client KMail ist das Standard-E-Mail-Programm unter der KDE
und als solches weit verbreitet. KMail hat eine graphische Benutzeroberfläche
und fügt sich vollständig in KDE ein. Es unterstützt die gängigen E-MailProtokolle, läuft unter Linux, BSD und anderen UNIX-artigen Betriebssystemen und basiert auf den Qt-Bibliotheken4 der Firma Trolltech5 . Unterstützt
werden Signier- und Verschlüsselungsoperationen auf Basis von Zertifikaten
sowie die Anbindung eines LDAP-Dienstes als Adressbuch.
5.2.1. Adressbuch
Das verwendete Adressbuch unter KMail ist ein eigenständiges Programm, welches unter KDE integriert ist. Man kann es separat starten, indem man in der
Konsole den Befehl kadressbook ausführt oder über KMail Extras -> Adressbuch dieses aufruft. Um das Adressbuch für den Einsatz auf dem LDAP-Server
einzurichten, muss als Erstes ein neues Adressbuch hinzugefügt werden. Dies
4
5
Das ”Quasar Toolkit” ist eine Programmbibliothek, die das Programmieren von
Plattformübergreifender Software möglich macht.
http://www.trolltech.com/
170
5.2. KMail
erreicht man, indem der Button hinzufügen unterhalb der Adressbuch-Liste angeklickt wird. Als Nächstes wird die Art des neuen Adressbuches ausgewählt.
Dabei sollte der Eintrag ”LDAP” genutzt werden. Ist dies geschehen, müssen
die Zugangsdaten für den LDAP eingegeben werden:
• Rechner: 192.168.1.52
• Port: 389
• LDAP-Version: 3
• DN: ou=Users, dc=cs, dc=fh-wiesbaden, dc=de
• Sicherheit: nein
• Authentifizierung: nein
Sind diese Einträge erfolgt, kann mit einem Klick auf den OK-Button die
Einrichtung des LDAP-Adressbuch abgeschlossen werden. Wird nun das neu
eingerichtete Adressbuch aktiviert, ergibt sich das Bild in Abbildung 5.4.
Abbildung 5.4.: KAdressbuch mit LDAP
171
5.2. KMail
Offensichtlich tritt auch hier wieder das gleiche Problem auf, welches auch
unter dem Thunderbird Adressbuch auftritt. Das Einzige was gefunden wird,
sind die E-Mail-Adressen da alle anderen Attribute, die von KAdressbuch ausgelesen werden, entweder leer (CN, SN) oder gar nicht vorhanden sind. Weiter
wird hier das vorhandene Attribut ”userCertificate” nicht ausgelesen, so dass
der Bezug von Zertifikaten über das LDAP-Adressbuch von KAdressbuch ausgeschlossen werden kann.
Doch gibt es unter KMail eine Erweiterung für die Verwaltung von Zertifikaten, die unter dem Namen ”Kleopatra” fester Bestandteil von KMail ist. Diese
Erweiterung ist aus dem Open-Source-Projekt Ägypten [URL11] und Ägypten2 [URL12] hervorgegangen und seit KDE 3.3 fest in KMail integriert. Diese
hat die Aufgabe, dem Nutzer die lokale Verwaltung von X.509 Zertifikaten
in einem GpGSM-Schlüsselspeicher6 sowie das Abfragen und Importieren von
Zertifikaten von einem LDAP-Server zu ermöglichen.
Gestartet wird Kleopatra unter KMail Extras -> Zertifikatverwaltung oder
über die Konsole mit dem Kommando kleopatra. Um es zu ermöglichen, über
Kleopatra auf die Zertifikate der Nutzerverwaltung zuzugreifen, muss als Erstes
der Zugriff auf den LDAP-Server in Kleoaptra unter Einstellungen -> Kleopatra einrichten -> Verzeichnissdienste -> Dienst hinzufügen eingerichtet werden.
Folgende Einträge müssen dabei in den LDAP-Einrichtungsdialog übertragen
werden:
• Servername: 192.168.1.52
• Port: 389
• Basis DN: ou=Users, dc=cs, dc=fh-wiesbaden, dc=de
Ist die LDAP-Anbindung eingerichtet, kann anschließend im Hauptfenster unter suchen nach -> in externen Zertifikaten in der Nutzerverwaltung nach Zertifikaten gesucht werden. Wird ein Zertifikat gefunden (Abbildung 5.5), kann
6
Ist eine vollständige S/MIME Implementation.
172
5.2. KMail
man dieses durch einen Doppelklick auf den Eintrag einsehen. Hier findet sich
auch, wie in Abbildung 5.6 zu sehen, die Möglichkeit, das Zertifikat in den
lokalen Schlüsselspeicher zu importieren.
Abbildung 5.5.: Suchen von Zertifikaten unter Kleopatra
Abbildung 5.6.: Zertifikate Ansicht unter Kleopatra
Um die Zertifikate im Schlüsselspeicher auch in KMail zur Signierung und
Verschlüsselung zu verwenden, müssen diese unter KMail Einstellungen ->
KMail einrichten -> Identitäten -> entsprechende Identität -> Kryptographie
173
5.3. Microsoft Outlook Express Kapitel 5. Erfahrungen mit Client Software
-> S/MINE Unterschriftzertifikat und S/MINE Verschlüsselungszertifikat eingebunden werden. Nun kann bei dem Schreiben einer E-Mail die Signier- und
Verschlüsselungs-funktion genutzt werden.
Der Import von Zertifikaten ist unter Kleopatra über zwei Wege möglich. Zum
einen über den normalen Weg des Imports von PKCS#12 (für eigenen Zertifikate), PEM oder DER Dateien und zum anderen über den gerade besprochenen LDAP-Dienst. Weiter können eigene und fremde Zertifikate über Datei
-> Geheime Schlüssel Exportieren als PKCS#12 und Datei -> Zertifkate exportieren als PEM Datei exportiert werden. Sollen CRLs verwendet werden,
können diese unter Kleopatra Datei -> Sperrlisten importieren eingespielt werden.
5.3. Microsoft Outlook Express
Outlook Express ist ein E-Mail-Client und Newsreader von Microsoft, der
dem Betriebssystem Windows in den aktuellen Versionen beiliegt und daher
auch von vielen Anwendern eingesetzt wird. Der Funktionsumfang von Outlook Express ist für den normalen Einsatz gedacht und unterstützt LDAPAdressbücher wie auch Zertifkat-Management über den internen Keystore von
Windows.
Eine direkte Möglichkeit, mit dem Adressbuch über den LDAP zu suchen, wie
unter Thunderbird oder KMail, existiert in Outlook Express nicht. Es gibt jedoch andere Möglichkeiten um die Zertifikate auf dem LDAP zu nutzen. Diese
sollen in den folgenden Schritten erläutert werden:
1. Einrichten des Verzeichnisdienstes
Der Verzeichnisdienste kann unter Extra -> Konten -> Verzeichnisdienst
-> Hinzufügen -> Verzeichnisdienst eingerichtet werden. Im Falle des
174
Kapitel 5. Erfahrungen mit Client Software 5.3. Microsoft Outlook Express
LDAP-Server auf dem EXTERN Host 192.168.1.52 gelten folgende Werte:
• Allgemein -> Servername: 192.168.1.52
• Erweitert -> Serverport: 389
• Erweitert -> Suchbasis: ou=Users, dc=cs, dc=fh-wiesdaden, dc=de
2. Suchen nach Personen
Ist der Verzeichnisdienst eingerichtet, ist es möglich, direkt über den
LDAP-Server nach bestimmten Namen oder Personen zu suchen. Dazu
muss Bearbeiten -> Suchen -> Personen angewählt werden. Das nun
erscheinende Fenster gibt unter ”suchen in” die Möglichkeit den Verzeichnisdienst anzuwählen, worin gesucht werden soll. In dem darunter
liegenden Feld können dann Namen oder E-Mail-Adressen angegeben
werden, nach denen gesucht werden soll.
3. Importieren
Wurden entsprechende Einträge gefunden, können diese über den Button
”Eigenschaften” eingesehen werden. In dem nun erscheinenden Fenster
können die Details des Eintrages wie die Adressdaten, das digitale Zertifikat etc. eingesehen sowie ein Import des gesamten Eintrags zum lokalen
Adressbuch des Outlook Express durchgeführt werden. Wie auch in den
anderen Adressbüchern zeigt sich auch hier, dass nur die E-Mail-Adresse
und das Zertifikat abgerufen werden können. Alle anderen Einträge wie
Adressen- oder Namensangaben bleiben, auf Grund fehlender Attribute
in den Objekten der Nutzerverwaltung, leer.
4. Zertifikatspeicher
Der Zertifikatspeicher unter Windows ist unter Start -> Systemsteuerung -> Internetoptionen -> Inhalte -> Zertifkate oder direkt im Outlook Express unter Extras -> Optionen -> Sicherheit -> Digitale IDs
175
5.3. Microsoft Outlook Express Kapitel 5. Erfahrungen mit Client Software
erreichbar. Wird dieser geöffnet, kann der Nutzer auf sechs verschiedene
Reiter zugreifen:
• Eigene Zertifikate:
Im Reiter ”Eigene Zertifikate” werden die eigenen Zertifikate angezeigt sowie exportiert und importiert.
• Andere Personen:
Im Bereich ”Andere Personen” werden alle Zertifikate angezeigt die
durch den direkten Import oder durch Hinzufügen von Kontakten
über einen Verzeichnisdienst eingespielt wurden.
• Zwischenzertifizierungsstellen:
Im Reiter ”Zwischenzertifizierungsstellen” werden die für SubCAs
ausgestellten Zertifikate eingespielt und angezeigt.
• Vertrauenswürdige Stammzertifizierungsstellen:
Im Reiter ”Vertrauenswürdige Stammzertifizierungsstellen” werden
die Root-Zertifikate der PCAs, für das Verifizieren der SubCAs oder
der direkt erstellten Zertifikate, abgelegt.
• Vertraute Herausgeber:
Im Reiter ”Vertraute Herausgeber” werden Zertifikate von Zertifizierungsstellen abgelegt, die als vertrauenswürdig eingestuft wurden.
• Nicht vertrauenswürdige Herausgeber:
Im Reiter ”Nicht vertrauenswürdige Herausgeber” werden Zertifikate von Zertifizierungsstellen abgelegt, die als nicht vertrauenswürdig
eingestuft wurden.
5. Einrichten der Zertifikate
Sollen nun die Zertifikate im Schlüsselspeicher unter Outlook Express
zum Signieren und Verschlüsseln genutzt werden, müssen unter Extras
-> Konten -> entsprechendes E-Mail-Konto -> Eigenschaften -> Sicherheit in den Punkten ”Zertifikat” und ”Verschlüsselungseinstellungen” die
176
jeweiligen Zertifikate aus dem Schlüsselspeicher angewählt werden. Ist
dies geschehen, wird beim Erstellen einer neuen E-Mail der Zugriff auf
die Signier- und Verschlüsselungsoption möglich.
Unter dem Schlüsselspeicher von Windows stehen für alle Rubriken (siehe
oben) Import- und Export-Funktionen zur Verfügung. Dabei wird in erster
Linie das CER- und PEM-Format für den Import von Zertifikaten verwendet.
Weiter wird der PKCS#12 Import unterstützt. Exportiert wird im CER- oder
PKCS#7-Format. Weiter ist es möglich, über einen gefundenen Eintrag (lokal
oder in einem Verzeichnisdienst) direkt unter ”Digitale IDs” das Zertifkat im
CER-Format zu exportieren.
Da der Schlüsselspeicher unter Windows global funktioniert, muss auch eine
CRL direkt über die von Windows zur Verfügung gestellten Möglichkeiten in
den Zertifikatspeicher importiert werden. Dies geschieht folgendermaßen:
1. Herunterladen der CRL,
2. Rechts-Klick auf die CRL und Anwählen von Zertifikatsperrliste installieren,
Nach der erfolgreichen Installation ist die CRL im Zertifikatspeicher aktiv, so
dass der Nutzer zwischen gültigen und gesperrten Zertifikaten unterscheiden
kann.
Grundsätzlich ist die Unterstützung von Zertifikaten innerhalb der gängigen
E-Mail-Programme vorhanden. Alle Programme unterstützen das Signieren
und Verschlüsseln von Nachrichten auf Basis der X.509 Zertifikate sowie das
Einbinden von CRLs und Zertifikaten in die internen Schlüsselspeicher. Da-
177
bei kann klar von einer Trennung der Bezugsquellen der Zertifikate ausgegangen werden. Sind die Zertifikate von einer Quelle im Internet, z.B. von
einem Online-Portal, auf den Rechner heruntergeladen und dann per Hand
in die jeweiligen Schlüsselspeicher der Programme oder Betriebssysteme integriert, gestaltet sich die Vorgehensweise in allen Programmen ähnlich. Der
Einsatz von LDAP für den Bezug von Zertifikaten wird jedoch unterschiedlich gehandhabt. Dabei hat Thunderbird die schlechtesten Voraussetzungen.
Zwar ist eine LDAP-Unterstützung im Adressbuch vorhanden, jedoch können
darüber keine Zertifikate von einem LDAP-Server bezogen werden, sodass sich
das Einbinden von Zertifikaten auf das lokale Importieren in den Schlüsselspeicher beschränkt. KMail dagegen bietet gute Ansätze des Einbindens von
Zertifikaten über einen LDAP-Server. Jedoch ist die fehlende Unterstützung
von Zertifikaten im LDAP-Adressbuch ein Nachteil, der durch die Verwendung von Kleopatra teilweise kompensiert werden kann. Dabei bietet KMail
im Linux-Sektor die besten Ansätze und Unterstützung bei der Verwendung
von X.509 Zertifikaten. Unter Windows ist Outlook Express in Kombination
mit dem internen Schlüsselspeicher von Windows eine gute Wahl und bietet
bei den getesteten Clienten die beste Unterstützung, einen LDAP-Server als
Adressbuch und Zertifikatspeicher zu verwenden. Dabei ist die globale Verfügbarkeit des Verzeichnisdienstes wie auch des Schlüsselspeichers ein nicht zu
unterschätzender Vorteil, da auch andere Programme außer Outlook Express
auf die Daten zugreifen können.
Abschließend wird festgestellt, dass die Untersützung für LDAP als Zertifikatspeicher noch nicht konsequent umgesetzt wurde. Dennoch ist die Verwendung eines LDAP-Server als Adressbuch in alle Clienten gegeben. Findet jedoch die Nutzerverwaltung als Basis eines solchen Adressbuches Verwendung,
muss diese generell um entsprechende Attribute für LDAP-Adressbücher erweitert werden.
178
6. Zusammenfassung und Ausblick
Dieses Kapitel gibt eine Abschlussbetrachtung über die in dieser Arbeit behandelten Themengebiete, wertet das Erreichte aus und zeigt einen Ausblick
und Empfehlungen für die weitere Entwicklung auf.
Angefangen mit den Grundlagen in Kapitel 2 wurde der Leser zur Problematik
der Notwendigkeit einer Public Key Infrastruktur hingeführt. In der Analyse
in Kapitel 3 wurde dieser Gedankengang konkretisiert, indem am Beispiel der
Policy wichtige Fragestellungen einer PKI angesprochen und ausgewertet wurden. Hierbei wurden Aussagen über den Aufbau, und die Anwendungsbereiche
der PKI sowie über die Identifizierung, Authentifizierung und Veröffentlichung
von Zertifikaten gemacht. Weiter wurde näher auf eine mögliche Ablauforganisation und das Thema der Sicherheitsmaßnahmen eingegangen. Nachdem der
theoretische Teil mit den Grundlagen und einer ersten Analyse abgeschlossen
wurde, konzentriert sich der Rest der Arbeit auf die praktische Umsetzung
der in der Analyse gemachten Aussagen und Vorgaben. Dabei ging es vornehmlich um den Aufbau, aber auch die Installation und Konfiguration des
auf Basis von OpenCA entwickelten Prototypen. Weiter wurde die Anbindung
an einen LDAP-Server beschrieben und auch die dabei auftretenden Probleme und Besonderheiten näher betrachtet. Die Handhabung und Einbindung
des Batch-Prozessors zum automatischen Erstellen von Zertifikaten wurde in
einem weiteren Teil abgehandelt. Zum Abschluss wurden verschiedene Anwendungszenarien für den Umgang mit den Interfaces des Prototypen besprochen,
um so dem Nutzer einen Überblick über die Zusammenhänge innerhalb von
OpenCA zu geben. Jedoch konnte aufgrund des Umfangs und der Komple-
179
Kapitel 6. Zusammenfassung und Ausblick
xität von OpenCA, der Prototyp nicht in jedem Detail besprochen werden.
Aus diesem Grund wurde zusätzlich für nähere Informationen zum Umgang
mit den Interfaces von OpenCA und der Installation und Konfiguration der
organisatorische und technische Anhang eingerichtet. Schließlich wurde in dem
letzten Kapitel ”Erfahrungen mit Client Software” die Integration der PKI in
bestehende Applikation geprüft und ausgewertet.
Werden die eben besprochenen Kapitel als Ganzes betrachtet, ergibt sich ein
Gesamtbild für die Umsetzung einer PKI am Fachbereich. Dabei muss jedoch
angemerkt werden, dass spezielle Problemstellungen die während der Arbeiten
aufgetreten sind, einer weiteren Prüfung und Vertiefung bedürfen. Zu diesen
Problemstellungen zählt unter anderem in der Analyse die Frage nach den
möglichen X.509 Erweiterungen bei Zertifikaten und CRLs. Weiter benötigen
die sicherheitstechnischen Maßnahmen und die Festlegung von Regelungen in
Bezug auf das Personal und die Verantwortlichkeiten innerhalb der PKI einer
weiteren Regelung und Konkretisierung durch den Fachbereich. Zur rechtlichen Absicherung einer laufenden PKI müssen die Rechte und Pflichten sowie Verbindlichkeiten in den Rahmenvorschriften konkretisiert werden. In der
praktischen Umsetzung muss wiederum geprüft werden inwieweit die Nutzung
der Userverwaltung durch den zentralen LDAP-Server des Fachbereiches als
Adressbuch und Zertifikatspeicher möglich ist. Sollte diese Nutzung vorgesehen
sein, müssen der LDAP-Server und die darin abgelegten Objekte einer entsprechenden Erweiterung unterzogen sowie klare Regelungen in Bezug auf den DN
vergeben werden. Weiter stellt sich bei der Einrichtung entsprechender Zertifizierungsstellen, auf Basis des Prototypen, die Frage nach Implementierung und
Einbindung dieser in die Netz-Infrastruktur sowie in die Prozesse innerhalb des
Fachbereiches. Des Weiteren sollte bei der Einrichtung einer PKI in die Vorbetrachtung die Betreuung der Nutzer durch entsprechende Dokumentation und
Lehrveranstaltungen sowie die Möglichkeiten zu einer Online-Betreuung1 einbezogen werden. Dabei spielt ein gut durchdachtes Konzept für die Betreuung
1
Zum Beispiel ein Online-Forum, in dem man Fragen bezüglich der PKI stellen kann.
180
6.1. Entwicklung von OpenCA
der Nutzer und die weitgehende transparente Einbindung der PKI in schon
existierende Prozesse eine entscheidende Rolle für eine breite Akzeptanz der
PKI. Aus diesem Grund sollten besonders in Bezug auf Schulung und Einbindung der PKI umfangreiche Planung und Testläufe durchgeführt werden.
Sollte es zu der Umsetzung einer zentralen PKI für die gesamte Fachhochschule Wiesbaden kommen, gelten im Ganzen die eben gemachten Aussagen zum
Fachbereich. Zusätzlich dazu sollte eine zentrale Stelle existieren, die sich nur
für den laufenden Betrieb und Support einer PKI kümmert sowie die Rolle
einer zentralen Nutzerbetreuung übernimmt. Nur so kann gewährleistet werden, dass die PKI an allen Fachbereichen in gleicher Qualität Anwendung und
Akzeptanz findet.
Abschließend bleibt festzustellen, dass zu dem Betrieb einer aktiven PKI das
Konzept, welches hinter OpenCA steht, für den fachbereichs- und fachhochschulweiten Einsatz durchaus geeignet ist.
Da es 2005 einige Änderungen in der Entwicklung und den zukünftigen Konzepten von OpenCA gegeben hat, soll dieser letzte Abschnitt dazu dienen,
einen Ausblick auf die weitere Entwicklung von OpenCA zu geben.
Die in dieser Arbeit verwendete Version von OpenCA 0.9.2.x wird aufgrund
eines Konflikts unter den Entwicklern über die Lizensierung und das Management nicht mehr direkt weiterentwickelt2 . Aufgrund dieser Probleme kam es
zur Abspaltung einer Gruppe von Entwicklern, die maßgeblich für die Entwicklung von OpenCA verantwortlich waren. Diese Entwickler haben im Oktober
2005 ein neues Projekt ins Leben gerufen. Dieses Projekt namens ”OpenXPKI”
basiert auf der Entwicklung von OpenCA 0.9.3. Ziel dieses Projektes ist es eine
robuste Open Source ”out-of-the-box Certification Authority” zu implementie2
Das System wird zwar weiterhin gepflegt und Bugfixes eingespielt, jedoch nicht mehr in
seiner Entwicklung vorangetrieben.
181
ren, welche die gängigsten Protokolle mit voller kryptographischer Sicherheit
für den weltweiten Einsatz unterstützt. Da dieses Projekt noch sehr jung ist,
konnte in dieser Arbeit kein Bezug auf die Entwicklung von OpenXPKI genommen werden. Jedoch sollte für eine weitere Entwicklung der fachbereichs- bzw.
fachhochschulweiten Public Key Infrastruktur der Einsatz von OpenXPKI berücksichtigt werden, da dieses System eine Weiterentwicklung von OpenCA
darstellt3 .
3
Weitere Informationen zu der Entwicklung und ersten Veröffentlichungen von OpenXPKI
unter http://www.openca.info.
182
A. Technischer Anhang
Der technische Anhang wurde eingerichtet, um als eine Ergänzung der in der
Arbeit gemachten Aussagen dem Leser den Einstieg und Umgang mit OpenCA
zu erleichtern. Dabei handelt es sich bei diesen Informationen zum größten Teil
um Aufzeichnungen, die während der Entwicklung des Prototypen entstanden
sind, um die gemachten Arbeiten und Änderungen auch später noch nachvollziehen zu können.
A.1. config.xml
Nachfolgend soll der Inhalt der config.xml näher betrachtet werden. Die Datei
ist in sieben große Konfigurationsabschnitte unterteilt. Diese sollen hier mit
ihren Inhalten und ihrer Bedeutung erläutert werden.
A.1.1. Generelle Einstellungen
Hier werden einige Optionen definiert, die für OpenCA-Interfaces von zentraler
Bedeutung sind.
Standort
Der CA-Standort, die Organisation und das Land, haben später einen starken
Einfluss auf die gesamte Konfiguration von OpenCA, z.B die LDAP- oder
CSR-Konfiguration.
183
A.1. config.xml
Anhang A. Technischer Anhang
< name > default_language </ name >
< value > DE </ value >
Angabe der Sprache (ist gleichbedeutend mit der Angabe des Landes).
< name > default_charset </ name >
< value > UTF -8 </ value >
Angabe der Zeichenkodierung
< name > cert_chars </ name >
< value > UTF8 </ value >
Diese Option gibt an, in welcher Zeichenkodierung die Inhalte (Strings) der
Felder O, OU, CN, EMAIL etc. in den Zertifikatanträgen und Zertifkaten
abgelegt werden sollen. Erlaubt sind die Werte UTF8 oder LATIN1. Wird das
Feld leer gelassen, ist die Standard Einstellung LATIN11 .
< name > ca_organization </ name >
< value > FH - Wiesbaden </ value >
Angabe der Organisation, in der OpenCA betrieben wird.
< name > ca_locality </ name >
< value > Wiesbaden </ value >
Angabe der Stadt, in der OpenCA betrieben wird.
< name > ca_country </ name >
< value > </ value >
Angabe des Landes, in dem OpenCA betrieben wird. Dabei gelten die ISOCodes für die Angabe des Landes. Bsp. DE, IT, PL, UK, US usw.
1
Für UTF8 Unterstützung ist mindestens OpenSSL 0.9.8+ notwendig.
184
A.1. config.xml
E-Mail-Teil
< name > sendmail </ name >
< value >/ usr / lib / sendmail -n -t </ value >
Angabe, welches Kommando zum Senden von E-Mails verwendet werden soll.
< name > send_mail_automatic </ name >
< value > no </ value >
Diese Option konfiguriert das Node-Interface. Ist der Wert auf YES gesetzt,
sendet OpenCA alle eintreffenden E-Mails während eines Imports automatisch.
Diese Option sollte vorsichtig eingesetzt werden, da es durch das automatische
Versenden von E-Mails zu Missverständnissen kommen kann.
< name > service_mail_account </ name >
Angabe der E-Mail-Adresse als Kontakt für PKI-User.
< name > policy_link </ name >
< value > https : // / pub / policy . html </ value >
Hier kann ein Link zur Policy angegeben werden.
A.1.2. Webserver Konfiguration
Dieser Teil ist, wie der Name schon sagt, für die speziellere Konfiguration und
Anpassung von OpenCA an die Gegebenheiten des Webservers zuständig.
< name > httpd_protocol </ name >
< value > https </ value >
Angabe, auf welchem Protokoll der Datentransfer stattfinden soll.
185
A.1. config.xml
< name > httpd_host </ name >
Angabe des Hostnamens, auf dem der Webserver hört2 .
< name > httpd_port </ name >
< value >:443 </ value >
Manchmal ist es notwendig, OpenCA an unüblichen Ports zu betreiben. Hier
hat man die Möglichkeit, diesen Port anzugeben. Ist dieses Feld leer, wird der
Standard-Port des angegeben Protokolls verwendet3 .
< name > menu_logo_left </ name >
Hier können Referenzen zu einem Logo angegeben werden. Dabei sind HTMLReferenzen erlaubt. Bsp: <img src=” ” alt=”XYZ Logo”/>
A.1.3. LDAP-Server Konfiguration
Folgende Optionen stehen zur Konfiguration des LDAP in der config.xml zur
Verfügung:
< name > ldap_host </ name >
Angabe, auf welchem Host der LDAP-Server zu finden ist.
< name > ldap_port </ name >
< value >389 </ value >
Angabe, auf welchen Port der LDAP-Server zu finden ist.
2
3
Bei VHosts sollte hier der Name des VHosts angegeben werden, auf dem OpenCA installiert wurde.
Zum Beispiel benutzt man das HTTP-Protokoll. Zusätzlich wird der Webserver, auf dem
OpenCA läuft, auf Port 8080 betrieben.
186
A.1. config.xml
< name > ldaproot </ name >
Angabe der Bind-DN des LDAP-Users, der berechtigt ist, Daten auf den
LDAP-Server zu übertragen.
< name > ldaprootpwd </ name >
Angabe des Passwortes des LDAP-Useraccounts
< name > useLDAP </ name >
Ist die Option auf YES gesetzt, wird der LDAP-Teil von OpenCA aktiviert.
< name > update_ldap_automatic </ name >
Soll der LDAP automatisch updaten, wenn von einer höheren Instanz ein Import durchgeführt wird, sollte diese Option auf YES gesetzt werden.
A.1.4. Datenbank Konfiguration
Folgende Optionen stehen für die Konfiguration der Datenbank zur Verfügung:
< name > dbmodule </ name >
< value > DB </ value >
Als erstes sollte man sich entscheiden, welches Datenbankmodul genutzt werden soll. OpenCA unterstützt zwei Module. Eines für DBM-Dateien und eines
für SQL. Für die Unterstützung von DBM den Wert DB angeben, für SQL
DBI.
187
A.1. config.xml
< name > db_type </ name >
< value > Pg </ value >
Hier kann der Datenbanktyp angegeben werden. Es werden folgenden Datenbanken unterstützt: Pg, MySQL, Oracle und DB2.
< name > db_name </ name >
< value > openca </ value >
Name der Datenbank, die genutzt werden soll.
< name > db_host </ name >
< value > localhost </ value >
Hostname des Datenbankservers, auf dem die Datenbank erreichbar ist.
< name > db_port </ name >
Port, auf dem die Datenbank erreichbar ist.
< name > db_user </ name >
< value > openca </ value >
Datenbankbenutzer, der Schreib- und Leserechte auf die oben genannte Datenbank hat.
< name > db_passwd </ name >
Passwort des Datenbankbenutzers, der Schreib- und Leserechte auf die oben
genannte Datenbank hat.
188
A.1. config.xml
A.1.5. Module Konfiguration
< name > module_shift </ name >
Um Konflikte wie z.B. doppelte Seriennummern zu vermeiden, besitzt OpenCA
einen Mechanismus um die verschiedenen Interfaces voneinander zu isolieren.
Die module_shift Option ermöglicht es, Zahlenräume für IDs festzulegen. Dabei
ist 0 die ID der CA. Alle anderen Module-IDs bewegen sich in dem Raum, der
durch die module_shift Option angegeben wurde4 . Hier die Standard-IDs, die
den Modulen durch die config.xml vorgegeben werden:
• ra_module_id = 1
• ldap_module_id = 2
• node_module_id = 3
• pub_module_id = 32
• scep_module_id = 33
• batch_module_id = 128
A.1.6. Konfiguration der relativen und absoluten Pfade
Die *_url_prefix und *_fs_prefix Optionen definieren die exakte Position der
einzelnen Module auf dem Webserver. Diese verweisen auf Positionen im Dateisystem, können aber auch durch die Angabe von Aliases in der httpd.conf (je
nachdem ob der Host bzw. VHost darin konfiguriert wurde) konfiguriert werden.
4
Man sollte vorsichtig mit dieser Option umgehen. Sie kann nach der ersten Definition
nicht mehr geändert werden.
189
A.1. config.xml
A.1.7. Datenaustausch Konfiguration
Dieser Abschnitt ist entscheidend für den späteren Export und Import von Daten über das NODE-Interface zwischen verschiedenen Ebenen der Hierarchie
innerhalb der Zertifizierungsstelle. Dabei ist es nicht notwendig, diese Sektion
im ersten Schritt auszufüllen, da es auch später über die node.conf Konfigurationsdateien möglich ist, die Ex- und Importfähigkeiten zu bearbeitet. Doch
ist die zentrale Konfiguration über die config.xml zu empfehlen.5
Dieser große und letzte Teil der config.xml spaltet sich in 6 Teile auf, die alle bis auf 0 auskommentiert wurden. Je nach Einsatz sollten hier die nötigen
Ex-/Importoptionen freigeschaltet werden:
• 0 -> keine Datenaustauschkonfiguration, alles befindet sich auf einem
Rechner, und jedes Interface arbeitet mit demselben /var und derselben
Datenbank.
• 1 -> Diese Sektion sollte verwendet werden, will man eine Offline-CA
betreiben (NODE-, CA- und BATCH-Interface). Dabei kann über das
NODE mit einer oder mehreren RA’s Daten ausgetauscht werden.
• 2 -> Für das Betreiben einer reinen RA (NODE- und RA-Interface) dabei
können über das NODE Daten mit der PUBLIC-/ SCEP-Instanz einer
CA ausgetauscht werden.
• 3 -> Hier kann eine reine PUBLIC-/ SCEP-Instanz betrieben werden.
Dabei kann das NODE Daten mit einer zugehörigen RA austauschen.
• 4 -> Mit dieser Sektion kann eine reine LDAP-Instanz betrieben werden.
Dabei bezieht das NODE Daten von einer zugehörigen RA oder CA.
5
Merke: Bei einem Durchlauf von configure_etc.sh werden alle *.conf -Dateien überschrieben.
190
A.2. Anpassung Apache
• 5 -> Dieser Modus wird benutzt, wenn auf einer Instanz PUBLIC/ SCEP
und RA gleichzeitig betrieben werden. Das NODE tauscht dabei nur mit
der zuständigen CA Daten aus.6
• 6 -> Hier können CA und RA gemeinsam auf einem Rechner betrieben werden. Das NODE tauscht dabei Daten mit der dazugehörigen
PUBLIC-/ SCEP-Instanz auf einem anderen Rechner aus.
Für den fehlerlosen Betrieb von OpenCA müssen an der Standardinstallation
des Apache unter SuSE einige Modifizierungen durchgeführt werden.
A.2.1. Symbolische Links
OpenCA nutzt in seiner Installation symbolische Links, um z.B. *.css Dateien an zentraler Stelle halten zu können. In der normalen Konfiguration des
Apache ist das Folgen symbolischer Links deaktiviert. Um diese Option zu
aktivieren, muss unter der Serverkonfiguration für den Host (in dem Falle
des Prototypen /etc/apache2/default-server.conf) die Option ”Options
+FollowSymLinks +SymLinksIfOwnerMatch” hinzugefügt werden: .
A.2.2. HTTPS
OpenCA verlangt in der Standardeinstellung (kann wenn nötig geändert werden) für alle Interfaces eine HTTPS-Verbindung. Im Folgenden wird darauf eingegangen, wie Apache konfiguriert werden muss, um zu ermöglichen, HTTPSVerbindungen annehmen zu können. Voraussetzung dafür ist ein schon generiertes und gültiges Serverzertifikat mit dazugehörigem privaten Schlüssel.
Sind Zertifikat und Schlüssel verfügbar, müssen diese unter /etc/apache2/ in
6
Dieser Teil wurde für den Prototypen verwendet; siehe auch Abschnitt 4.3 ”Planung einer
Zertifizierungsstelle” im Kapitel 4 ”Praktische Umsetzung”.
191
das Verzeichnis ssl.crt/ (für das Zertifikat) und in das Verzeichnis ssl.key/
(für den privaten Schlüssel) eingespielt werden. Ist dies geschehen, muss in
der Datei /etc/apache2/listen.conf der Port 443 aktiviert werden. Jetzt
kann Apache auch auf dem HTTPS-Port lauschen. Doch ist noch kein entsprechender Host eingerichtet, der die SSL-Verbindungen annimmt. Dazu muss
Folgendes in die httpd.conf eingetragen werden7 .
< VirtualHost _default_ :443 >
DocumentRoot / srv / www / htdocs /
SSLEngine On
SSLOptions + StdEnvVars + ExportCertData
SSLCertificateFile / etc / apache2 / ssl . crt / server . crt
SS LCert ific ateK eyFi le / etc / apache2 / ssl . key / server . key
</ VirtualHost >
Listing A.1: Exemplarischer Ausschnitt der https.conf
Nach einem Neustart des Apache sollte dieser auf dem HTTPS-Port Verbindungen annehmen und SSL-Sessions auf Basis der Zertifikate und des privaten
Schlüssels etablieren können.
Hinweis: Nicht vergessen, das Wurzelzertifikat der Zertifizierungsstelle, die das
Zertifikat des Apache abgestempelt hat, in den Browser zu importieren. Es
können sonst Fehlermeldungen aufgrund der Prüfung des Zertifikates auftreten.
Anmerkung zu SSL: Apache muss in der ssl-global.conf durch hinzufügen
der Option ”SSLOptions +StdEnvVars” angepasst werden. Wenn dies nicht
geschieht werden die Umgebungsvariablen für SSL nicht exportiert. Dies hat
zur Folge das beim Aufrufen der Webinterfaces die Fehlermeldung ”General
Error. 6251043 Error Aborting connection - you are using a too short symmetric keylength ()” zurückgegeben wird, da Perl die SSL Umgebungsvariablen
nicht finden kann.
7
Hinweis: man kann auch eine eigene Datei für die VHosts verwenden und in die httpd.conf
aufnehmen. Das ist reine Geschmackssache.
192
A.3. Wichtige Konfigurationsdateien
A.3. Wichtige Konfigurationsdateien
Zur Konfiguration soll an dieser Stelle ein Überblick über die wichtigsten Konfigurationsdateien unter OpenCA gegeben werden:
/OPENCADIR/etc/
1. config.xml -> Basis-Konfigurationsdatei für die Erstinitialisierung mit
dem Script configure_etc.sh
2. ldap.xml -> Basis-Konfigurationsdatei für LDAP-spezifische Einstellungen von OpenCA
3. menu.xml -> Basis-Konfigurationsdatei für die Menüs der Interfaces.
Hier können neue Menüs oder Einträge erzeugt und manipuliert werden.
4. loa.xml -> definiert die möglichen Level of Assurance
5. access_control/
a) *.xml -> Beeinhaltet die Konfigurationsdateien für die Zugangskontrolle der installierten Interfaces
6. bp/
a) states.txt -> alle bekannten Zustände des Batch-Prozessors
b) funktions.txt -> alle bekannten Funktionen des Batch-Prozessors
c) bp.xml -> interne Konfiguration des Batch-Prozessors
d) funktions/
i. funktions_name.txt -> Start-Konfiguration der Zustände,
die einen Funktionsstart verursachen
7. database/
a) DBI.conf -> zentrale Konfiguration für die Datenbank der Interfaces
193
A.4. OpenCA Konfiguration
8. openssl/
a) openssl.cnf -> Hier werden die Konfigurationen für die CA eingestellt.
b) openssl/
i. *.conf -> Hier werden die Eigenschaften der Rollen definiert,
die im Antrag angegeben werden können.
c) extfiles/
i. *.ext -> Hier werden die Zertifikat-Erweiterungen der Rollen
definiert.
9. rbac/
a) acl.xml -> Konfiguration der Access Control List.
b) modules.xml -> Hier werden die IDs der Module festgelegt.
c) roles.xml -> Hier werden die Rollen definiert.
10. servers/
a) *.conf -> Basis-Konfigurationsdateien für die Interfaces von OpenCA
In diesem Abschnitt werden zusätzliche Details zur Konfiguration von OpenCA
behandelt.
A.4.1. Zusätzliche Attribute bei CSRs
Zusätzliche Attribute sind zusätzliche Informationen, die im Antrag mit aufgenommen, aber nicht veröffentlicht werden. Diese Informationen werden also
nur im Antrag abgespeichert und sind auch nur dort verfügbar.
194
Ist man z.B. ein Webmaster innerhalb einer Universität, ist es eine gute Idee,
die E-Mail-Adresse in das Zertifikat zu übernehmen. Weniger günstig ist es
aber, die Telefonnummer in einem Zertifikat zu veröffentlichen. Trotzdem sollte die Telefonnummer, auch wenn sie nicht im Zertifikat veröffentlicht werden
soll, erhoben und gespeichert werden, um den Nutzer z.B. im Notfall erreichen
zu können. Genau aus diesem Grund wurden in OpenCA die zusätzlichen Attribute eingeführt. Listing A.2 soll zur Erklärung dienen.
ADDITIONAL_REQUEST_ATTRIBUTES
" requestercn " " email " " department "
" telephone "
" Name ( first and Last name ) "
ADDITIONAL_ATTRIBUTES_DISPLAY_VALUE
" Email " " Department "
" Telephone "
A D D I T I O N A L _ R E Q U E S T _ A T T R I B U T E S _ S T R I N G _ T Y P E " LAT IN 1_ LET TE RS " " EMAIL "
" LATIN1_LETTERS " " LATIN1 _L ET TER S "
Listing A.2: Exemplarischer Ausschnitt für zusätzliche Attribute
• Der ADDITIONAL_REQUEST_ATTRIBUTES ist der interne Name
des Attributes
• Mit ADDITIONAL_ATTRIBUTES_DISPLAY_VALUE hat man die
Möglichkeit, den Namen des angezeigten Attributs zu definieren. Dies
ist sehr praktisch, um Beispiele für die Eingabe vorzugeben.
• Mit ADDITIONAL_REQUEST_ATTRIBUTES_STRING_TYPE kann
man der Software bei der Fehlererkennung für die Eingabe helfen. Folgende Werte sind erlaubt: LETTERS, TEXT, NUMERIC, MIXED, DATE,
TEL, EMAIL, LATIN1_LETTERS, LATIN1.
A.4.2. Channel verification
Die channel verification überprüft die Parameter für eingehende Übertragungen. Die Werte in der Konfiguration sind reguläre Ausdrücke, die den Wert
der Umgebungsvariablen definieren der getestet werden sollen. Zur Zeit wird
nur mod_ssl unterstützt. Wenn man eine verschlüsselte Verbindung nutzen
195
möchte, muss deshalb das SSL-Protokoll genutzt werden. Benötigt man eine
unverschlüsselte Verbindung zur CA oder RA muss das HTTP-Protokoll verwendet und für mod_ssl der Wert ”.*” angegeben werden. Dies bewirkt, dass
alle eingehenden Verbindungs-Protokolle angenommen werden.
Wichtig: Es sollte bei einer unverschlüsselten Verbindung darauf geachtet
werden, dass die Schlüssellänge auf Null gestellt wird. Wird das nicht getan,
werden alle unverschlüsselten Verbindungen abgewiesen.
Abschließend, in Listing A.3, ein Beispiel für eine Channel-Konfiguration:
< channel >
< type > mod_ssl </ type >
< protocol > ssl </ protocol >
< source >192.168.0.1 </ source >
< asymmetric_cipher >.* </ asymmetric_cipher >
< asymmetric_keylength >0 </ asymmetric_keylength >
< symmetric_cipher >.* </ symmetric_cipher >
< symmetric_keylength >128 </ symmetric_keylength >
</ channel >
Listing A.3: Exemplarischer Ausschnitt aus der Channel-Konfiguration
A.4.3. Login
Es sind drei verschiedene Methoden für den Login Verfügbar:
1. none
2. passwd
3. x509
Dabei soll an dieser Stelle nur der Login auf Basis von passwd erläutert werden,
da dieser für die Anwendung am Prototypen verwendet wurde und auch so eine
besonders effektive Möglichkeit der Zugangskontrolle bietet. Für alle weiteren
Methoden soll hier auf die OpenCA Dokumentation [URL6] verwiesen werden.
196
Die passwd Methode kann genutzt werden, wenn ein Login via Passwortabfrage benutzt werden soll. Dabei unterstützt OpenCA zur Zeit nur die Abfrage
der internen Datenbank für die Zugriffskontrollkonfiguration.
Es ist möglich, verschiedene User zu definieren. Jeder User hat einen Namen,
einen definierten Algorithmus und sein verschlüsseltes Passwort. Dabei spezifiziert der Algorithmus, welche Art verwendet wurde um das Passwort zu
verschlüsseln8 .
Listing A.4 soll zur Erklärung dienen.
< login >
< type > passwd </ type >
< form > OPENCADIR / lib / servers / ca / sheets / login_passwd . html </ form >
< database > internal </ database >
< passwd >
< user >
< name > root </ name >
< algorithm > sha1 </ algorithm >
< digest >3 Hbp8MAAbo + RngxRXGbbujmC94U </ digest >
</ user >
< user >... </ user >
...
</ passwd >
</ login >
Listing A.4: Exemplarischer Ausschnitt aus der Login-Konfiguration
Die Standard Einstellung in OpenCA ist >passwd<, das im Listing A.4 gezeigte <digest> ist das Standardpasswort, das im Klartext ”root” lautet. Um
eigene Digests zu erzeugen stellt OpenCA ein Skript zu Verfügung. Der Name
des Skriptes ist openca-digest. Die Anwendung lautet:
openca - digest ( help | sha1 | crypt | md5 ) string
8
OpenCA unterstützt drei Algorithmen SHA1, MD5 und crypt.
197
A.4.4. ACLs
Über ACLs (Access Control List) lassen sich die Zugriffsberechtigungen von
Personen oder Gruppen auf einzelnen Elemente und Funktionen von OpenCA
genau festlegen. Dies kann z.B. notwendig werden, wenn in der Policy die Aufgaben des CA- oder auch RA-Operators noch einmal in einzelne Bestandteile
aufgeteilt und diese wiederum verschiedenen Rollen oder Personen zugeteilt
werden. Durch diese Gewaltenteilung kann noch einmal das Sicherheitniveau
erhöht werden. Jedoch sollte darauf geachtet werden, dass eine zu starke Aufteilung den administrativen Aufwand enorm schnell in die Höhe steigen lassen
kann.
Will man nun, aus Gründen der gerade besprochenen Aufgabenteilung, mehr
als einem Operator den Zugriff auf ein Interface gestatten, müssen die entsprechenden Zugriffskontrollen unter /OPENCADIR/etc/access_control/ und die
dazugehörigen ACLs im Verzeichnis /OPENCADIR/etc/rbac/ angepasst werden, um so klar die einzelnen Operatoren mit ihren zugeteilten Aufgaben unterscheiden zu können. Da dieses Thema in seinem Umfang an dieser Stelle
jedoch den Rahmen sprengen würde und auch in der Entwicklung des Prototypen keine weitere Rolle gespielt hat, soll es hier nicht weiter behandelt und
für weitere Informationen auf die OpenCA Dokumentation [URL6] verwiesen
werden.
A.4.5. Datenaustausch Konfiguration
In diesem Teil (etwas unterhalb der ”dataexchange section”) befinden sich
Möglichkeiten zur Einstellung der Art und Weise des Exportes/ Importes in/aus Archiven9 . Jeder Eintrag repräsentiert ein Verzeichnis innerhalb des Archives, in das Daten eingespielt (bei einem Export) oder aus dem Daten entnommen (bei einem Import) werden.
Anmerkung: Diese Sektion kann auch über das config.xml konfiguriert wer9
Was wird wie wohin exportiert/importiert CA <-> RA.
198
den. Mehr dazu siehe im Abschnitt A.1.7 ”Datenaustausch Konfiguration”.
Ein Archiv zum Datenaustausch besitzt folgenden grundlegende Verzeichnisstruktur:
openca . tar
/
/ CA_ CERT IFIC ATE_ STATE S
/ CERTIFICATE_STATES
/ CRL_STATES
/ CRR_STATES
/ CSR_STATES
/ MAIL_STATES
/ CRR_STATE
Listing A.5: Inhalt des Export/Import Archiv openca.tar
Was in welches Verzeichnis abgelegt (beim Export) und was aus welchen Verzeichnis entnommen (beim Import) wird, wird in der node.conf unterhalb der
”dataexchange section” festgelegt. Hier in Listing A.6 ein Beispiel für die Konfiguration einer Offline-CA die mit einer Online-RA ihre Daten abgleicht.
# Export Teil zu RA
ENROLL_CA_CERTIFICATE_STATES
VALID
E N R O L L _ C E R T I F I C A T E_ S T A T E S
VALID
ENROLL_CRL_STATES
VALID
ENROLL_CRR_STATES
ARCHIVED DELETED APPROVED
ENROLL_CSR_STATES
ARCHIVED DELETED
ENROLL_MAIL_STATES
DEFAULT
# Import Teil zu CA
RECEIVE_CSR_STATES
APPROVED
RECEIVE_CRR_STATES
APPROVED
Listing A.6: Exemplarischer Ausschnitt für Export/Import
• ENROLL_*
Export der aktuelle CA Zertifikate (CA_CERTIFICATE_STATES), User
Zertifikate (CERTIFICATE_STATES), CRLs (CRL_STATES), CRRs
(CRR_STATES), CSRs (CSR_STATES) und User E-Mails (MAIL_STATES)
zur Auslieferung an eine niedrigere Ebene der Hierarchie.
199
A.5. LDAP Konfiguration
• RECEIVE_*
Herunterladen der aktuellen CSRs (CSR_STATES) und CRRs (CRR_STATES)
beim Import von einer niedrigeren Ebene der Hierarchie.
Dieser Abschnitt soll weitere Details der LDAP Konfiguration unter OpenCA
behandeln.
A.5.1. OpenCA-Teil
Dieser verteilt sich in den verschiedenen /OPENCADIR/etc/server/*.conf Dateien. Dabei können folgende Optionen verwendet werden:
• LDAP
Ist diese Option auf YES gesetzt, ist der LDAP-Teil von OpenCA aktiviert.
• updateLDAPautomatic
Diese Option wird im NODE-Interface benutzt. Ist der Wert auf YES
gesetzt, updatet der Server automatisch bei Importen von Zertifkaten,
CRLs und CRRs.
• LDAP_CRL_Issuer
Viele Nutzer speichern die CRL in einem speziellen Knoten des LDAPServers, der nicht identisch ist mit dem Aussteller der CRL. Hier kann
dafür ein spezieller DN vergeben werden.
• LDAP_CA_DN
Viele User speichern die CA-Zertifikate in einem nicht standardkonformen Knoten. Das heißt, es gibt z.B. ein schon existierendes Verzeichnis,
das im Konflikt mit der PKI Struktur ist. Hier bietet sich die Möglichkeit,
200
Zertifikate an einem speziellen Knoten abzulegen, der nicht in Konflikt
mit der Struktur des LDAP-Server gerät.
• SET_CERTIFICATE_SERIAL_IN_DN
Hier kann die Vergabe eines eigenen Blattobjektes unterhalb eines Eintrages aktiviert werden. Ist diese Option mit ”Y” aktiviert, wird unterhalb des CN ein Blattobjekt namens serialNumber erzeugt, in dem das
Zertifikat abgelegt wird. Diese Methode hat den Vorteil, dass für einen
Eintrag mehrere Zertifikate vergeben werden können. Nachteilig ist allerdings, dass bei der Suche über den LDAP-Server mit einem Adressbuch,
wenn nur auf einer Ebene gesucht werden kann, nur die Einträge, aber
nicht die darunter liegenden serialNumber Objekte geprüft werden. Setzt
man die Option auf ”N”, wird das Zertifikat direkt in dem Eintrag abgelegt.
• CERTIFICATE_SERIAL_NAME
Hier kann der Name des Blattobjektes angegeben werden, in dem das
Zertifikat abgelegt werden soll10 .
A.5.2. LDAP Teil
Der LDAP-Teil befindet sich in der /OPENCADIR/etc/ldap.xml. Die folgenden
Optionen findet man unter anderem auch in der /OPENCADIR/etc/config.xml.
wieder. Diese hat, wie schon gesagt, nur für das Konfigurationsscript configure_etc.sh eine Bedeutung, nicht aber für den laufenden Betrieb des OPENCA
Serves.
• host
Der Hostname des LDAP-Servers.
• port
Der Port, an dem der LDAP-Server anfragen entgegen nimmt.
10
Es sollten die Vorgaben verwendet werden, da sonst Probleme mit dem OpenCA-Schema
auftreten könnten.
201
• suffix/dn
Dies ist die Angabe der Wurzel-DN des LDAP-Serves. Weiter können hier
mehrere Wurzeln (soweit unterstützt) angegeben werden. Dabei muss
jede DN in einem eigenen DN-Tag abgelegt werden. Listing A.7 soll als
Beispiel dienen.
< suffix >
<dn > o = OpenCA , c = IT < dn >
<dn > o = OpenCA , c = DE < dn >
< suffix >
Listing A.7: Exemplarischer Ausschnitt die Konfiguration des Wurzel-DN
• login
Die Bind-DN des Nutzers, der auf den LDAP-Server zugreifen soll.
• passwd
Angabe der Passwortes für den oben angegebenen LDAP-Account.
• protocol_version
Gibt an welche Version des LDAP-Protokolls verwendet werden soll.
Standard ist V2, für den Prototypen wurde V3 verwendet.11
• tls
Aktivieren oder Deaktivieren der Verschlüsselung mit TLS12 .
• sasl
Aktivieren oder Deaktivieren der sasl-Authentifizierung13 . Weiter wird
CRAM-MD5 für das Passworthashing eingesetzt.
11
Wenn V3 vom LDAP-Server unterstützt wird, sollte es verwendet werden, um unnötigen
12
Ärger zu vermeiden.
Für diese Option wird LDAP-Protokoll V3 vorausgesetzt.
Für diese Option wird LDAP-Protokoll V3 vorausgesetzt.
13
202
A.6. Batchimport
• excluded_roles/role
OpenCA verfügt über die Möglichkeit, Rollen für die Veröffentlichung
von Zertifikaten auszuschließen. Listing A.8 soll als Beispiel dienen.
< excluded \ _roles >
< role > Internal Security Stuff < role >
< role > IDS VPN < role >
< excluded \ _roles >
Listing A.8: Welche Zertifikate dürfen nicht veröffentlicht werden
A.6. Batchimport
Im Folgenden sollen die Formate der Importdateien beim Standard Import mit
Hilfe entsprechender Beispiele erläutert werden14 :
A.6.1. Batch-System Import New User Format
file
::= ( serial . " \ n " ) *
serial ::= this is a user name or ID
Listing A.9: Exemplarischer Ausschnitt für das ”Import New User Format”
Beispiel für batch_new_user.txt in Listing A.10.
hwink001
hwink002
Listing A.10: Beispiel für ”Import New User”
14
Quelle der Formate [CB05] Kapitel 16.
203
A.6. Batchimport
A.6.2. Batch-System Import New Process Format
file
::= ( serial . " \ n " . process . " \ n " . " \ n " + ) *
serial
::= this is a user name or ID
process ::= this is a process name
Listing A.11: Exemplarischer Ausschnitt für ”Import New Process Format”
Beispiel für batch_new_process.txt in Listing A.12.
hwink001
neues_zertifikat
hwink002
neues_zertifikat2
Listing A.12: Beispiel für ”Import New Process”
A.6.3. Batch-System Import New Process Format
file
::= ( ( id . param * . " \ n " ) *
id
::= " USER " . serial . " \ n " . " PROCESS " . process . " \ n "
serial
::= this is a user name or ID
process ::= this is a process name
param
::= ( common | loa_mode | key_algorithm |
key_length | state | subject_alt_name ) . " \ n "
common
::= name . " " . value . " \ n "
name
::= " SUBJECT " | " ROLE " | " LOA " | __user_defined__
value
::= oneline | multiline
oneline ::= [^\ n ]+
multiline ::= " \n - - - - - BEGIN " . limiter . " - - - - -\ n "
. content . " \n - - - - - END " . limiter . " ----- " ;
limiter ::= [A - Za - z0 -9 _ -\.]+
key_length
::= " KEY_LENGTH " . " " . _ _ u n s i g n e d _ i n t e g e r _ _
loa_mode
::= " LOA_MODE " . " " . ( " IGNORE " | " NORMAL " )
key_algorithm
::= " KEY_ALGORITHM " . " " . ( " rsa " | " dsa " )
state
::= ( " SET_STATE " | " UNSET_STATE " ) . " " .
_ _ ex i s t in g _ b a t c h _ s t a t e _ _
204
A.6. Batchimport
subject_alt_name ::= " S UB J EC T _ A L T _ N A M E _ " . san_number . " " .
san_name . ( " = " | " : " ) . san_value
san_number
::= integer / position in the subject alternative name
san_name
::= " DNS " | " IP " | " EMAIL " | " OTHERNAME "
san_value
::= value of the alternative name component
Listing A.13: Exemplarischer Ausschnitt für ”Import New Process Format”
Achtung: Bei ’__user_defined__ ist kein Leerzeichen in den Namen erlaubt!
Beispiel für batch_process_data.txt
USER hwink001
PROCESS neues_zertifikat
set_state new_process
ROLE User
SUBJECT_ALT_NAME_1 email : HG . Winkler@Web . de
SUBJECT CN = hwink001 , DC = cs , DC = fh - wiesbaden , DC = de
LOA_MODE IGNORE
Listing A.14: Ausschnitt für den Basis-Antrag
• USER
Ist die UserID des Benutzers.
• PROCESS
Hier kann irgendein Name angegeben werden. Über diesen kann man
dann später die verschiedenen Prozesse eines Users unterscheiden.
• set_state new_process
Hier wird angegeben, bei welchem Status begonnen werden soll.
• SUBJECT_ALT_NAME_*
Angabe der E-Mail-Adresse und anderer alternativer Namensgebungen.
Es werden email, DNS, IP, DirName, URL, RID, otherName, Microsoft_GUID und Microsoft_UPN erlaubt. Mehr dazu siehe batch.conf
unter CSR_SUPPORTED_SUBJECT_ALT_NAMES .
205
A.7. Batch Workflow
• SUBJECT
Angabe des DN ist gleichbedeutend mit dem Pfad innerhalb des LDAP.
A.7. Batch Workflow
Die Statusmaschine des Batch-Prozessors durchläuft bei der Abarbeitung eines
Userprozesses vom Start bis zum PKCS#12-Rollout 14 Stufen, welche an dieser Stelle in Abblidung A.1 aufgezeigt werden sollen. Wird der Batch-Prozess
gestartet, beginnt dieser immer im Zustand new_process. Als Erstes wird für
die Abarbeitung von OpenCA ein PIN erzeugt. Dieser ist später das Passwort,
mit dem der private Schlüssel und die PKCS#12-Datei vor fremdem Zugriff
geschützt werden15 . Ist dieser Prozess abgeschlossen, kommt es zur Erzeugung
des Schlüsselpaares. Dieser Vorgang wird abgelöst durch die Erzeugung des dazugehörigen CSR, welcher wiederum nach entsprechender automatischer Überprüfung mit dem privaten Schlüssel der CA abgezeichnet wird. Ist bis dahin
alles gut gegangen, kann der Batch-Prozess mit der Erzeugung der PKCS#12Container und der Ablage der neuen Zertifikate in der Datenbank der CA
abgeschlossen werden.
A.7.1. Anpassen des Batch-Prozessors
Im alltäglichen Betrieb ist der normale Workflow des Batch-Prozessors völlig
ausreichend. Doch kann es sein, dass spezielle Anforderungen es nötig machen,
diesen anzupassen, um ihn z.B. um zusätzliche Stufen zu erweitern. Im Folgenden sollen zur näheren Erklärung der Änderung des Workflow als Erstes
die relevanten Konfigurationsdateien angegeben werden.
Alle bekannten Zustände sind unter /OPENCADIR/etc/bp/states.txt und alle bekannten Funktionen unter /OPENCADIR/etc/bp/functions.txt abgelegt.
Die Start-Konfiguration der Zustände, die einen Funktionsstart verursachen,
15
Siehe auch Abschnitt 4.8.1 ”Probleme mit der PIN”.
206
A.7. Batch Workflow
new_process
checked_csr_p.
create_pin
create_csr
new_pin
new_csr
check_pin
complete_csr
checked_pin
complete_csr
check_csr
check_key_params
checked_pin_p.
checked_csr
create_key
create_cert
new_key
new_cert
check_key
enroll_pin
checked_key
enrolled_pin
backup_key
enroll_pkcs12
enrolled_pkcs12
backuped_key
check_csr_params
/OPENCADIR//var/bp/dataexchange/pkcs12/
Abbildung A.1.: Standard Workflow des Batch-Prozessors von OpenCA
befinden sich unter /OPENCADIR/etc/bp/functions/. Die darin enthaltenen
Dateinamen orientieren sich an der Namensgebung der Funktion z.B. function_name.txt. Dabei beinhaltet jede Zeile einen Status, der benötigt wird, um
die Funktion zu starten.
207
A.7. Batch Workflow
Anmerkung: Jeder Prozess eines Users besitzt eine Konfigurationsdatei namens state.txt16 , die den aktuellen Status des User Workflows beinhaltet. Sie
hat dasselbe Format wie die Konfigurationsdatei für die Funktionen.
Um nun einen Workflow zu ändern oder komplett neu zu erstellen, sollten
folgende Schritte unternommen werden17 .
1. Aufzeichnen des Zustandsgraphen.
2. Markieren der Änderungen im Graphen.
3. Erzeugen einer eigenen /OPENCADIR/etc/bp/states.txt, welche alle möglichen Zustände enthält.
4. Erzeugen einer eigenen /OPENCADIR/etc/bp/functions.txt, welche alle
möglichen Batch-Funktionen enthält.
5. Erzeugen der Start-Konfigurationen der Zustände aller Batch-Funktionen
in /OPENCADIR/etc/bp/functions/.
6. Überprüfen der in der Start-Konfiguration spezifizierten /OPENCADIR/etc
/bp/functions/ auf Konfliktfreiheit.
7. Implementieren der neuen Funktionen und Auswechseln der alten.
8. Test des neuen Systems.
Das größte Problem bei dem Implementieren einer neuen Funktion ist, die Auswirkung der neuen Funktion bei ihrer Ausführung in entsprechender Situation
zu überblicken. Macht man irgend etwas falsch, wird die Funktion normalerweise für alle User unbrauchbar. Die Schritte zur Erzeugung einer neuen Funktion
sind folgende:
1. Füge die neue Funktion in die Liste unter /OPENCADIR/etc/bp/functions.
txt ein.
16
17
Diese befindet sich unter /OPENCADIR/var/bp/users/userpfad/.
Entnommen aus [CB05].
208
A.7. Batch Workflow
2. Erzeuge eine neue Datei namens /OPENCADIR/etc/bp/functions/funct
ion_name.txt und spezifiziere die Start-Konfigurationen des Zustandes.
3. Erzeuge eine neue Datei namens /OPENCADIR/lib/bp/function_name
.sub und kopiere den Inhalt einer schon existenten anderen Funktion
hinein.
4. Ändere den Funktionsnamen in der Datei function_name.sub zu dem
eigenen workflow_function_name.
5. Ändere die Funktion entsprechend den eigenen Vorstellungen ab. Jede
Funktion besitzt zwei Parameter USER und WORKFLOW, diese können
dazu genutzt werden, um Daten in das Batch-System zu integrieren.
6. Als letztes sollte die aktuelle Status-Konfiguration in den User-Prozessen
und die eigene /OPENCADIR/etc/bp/states.txt um den neuen Zustand
erweitert und angepasst werden.
209
210
B. Organisatorischer Anhang
Dieser Anhang soll Hilfestellung zur Inbetriebnahme des Prototypen und dem
Umgang mit diesem geben.
B.1. Inhalt der DVD
Auf der DVD befinden sich drei Verzeichnisse. Das erste Verzeichnis /doc
beinhaltet zwei Unterverzeichnisse, den Latex-Source der Diplomarbeit unter /diplomarbeit und das Material der bei den Recherchen für diese Arbeit
zusammengetragenen und verwendeten Quellen unter recherche/. Das zweite
Verzeichnis auf der DVD namens /source, beinhaltet den Source der verwendeten OpenCA-Version. Abschließend im dritten Verzeichnis /vm sind die
gepackten Images der virtuellen Maschinen des Prototypen sowie der Installationssatz von VMWare abgelegt.
B.2. Inbetriebnahme des Prototypen
Voraussetzung für die Inbetriebnahme der virtuellen Maschinen ist ein schon
installiertes VMWare 4.5 (oder höher). Weiter müssen die Archive auf der
DVD unter /vm entpackt und an geeigneter Stelle im Dateisystem abgelegt
worden sein. Nach dem Start von VMWare müssen nun als erstes die VMs in
das Programm importiert werden. Dies geschieht über File -> Open Virtual
Machine. Daraufhin öffnet sich ein Fenster, in dem man die fragliche VM im
Dateisystem suchen und anwählen kann. Nachdem die Prozedur für alle drei
211
B.2. Inbetriebnahme des Prototypen Anhang B. Organisatorischer Anhang
VMs durchgeführt wurde, soll nun am Beispiel der Online-RA das weitere
Vorgehen erläutert werden.
1. Starten der VM. Dabei kommt es zur Meldung, dass der VM eine neue
ID zugeordnet wird. Diese ID ist gleichbedeutend mit der Vergabe einer neuen Mac-Adresse, sodass in jedem Fall die virtuelle Netzkarte neu
konfiguriert werden muss.
2. Einloggen als Root (Passwort = ”turrican”)
3. Starten von yast
4. Unter Netzwerkgeräte -> Netzwerkarte muss die konfigurierte Netzwerkkarte gelöscht werden. Nach diesem Vorgang die Änderungen speichern.
5. Wieder unter Netzwerkgeräte -> Netzwerkarte die nun nicht konfigurierte Netzkarte neu einrichten und die gemachten Änderungen abspeichern.
6. Anschließend OpenCA mit openca-start hochfahren (in der .bashrc stehen weitere Alias die eingerichtet wurden).
Jetzt ist es möglich, auf die Dienste der Online-RA unter der konfigurierten
Netzwerkadresse zuzugreifen. Dieser Vorgang muss für die anderen beiden VMs
”Offline-CA” und ”Extern” auch durchgeführt werden um die volle Funktionalität des Prototypen zu erreichen.1
Anmerkung: Der Prototyp wird im Leer-Zustand ausgeliefert d.h. die Initialisierung der Online-RA und Offline-CA muss noch vor der aktiven Nutzung
durchgeführt werden2 .
1
Die VM des EXTERN-Host benötigt bei einer Erst-Inbetriebnahme die Konfiguration der
Netzwerkschnittstelle und bei geänderter IP die Prüfung der DNS Konfiguration unter
/etc/named.conf und /var/lib/named/treehouse.zone sowie den Neustart des DNS
2
Servers.
Siehe dazu 4 Abschnitt 4.10.1 ”Erstinitialisierung der CA” und 4.10.2 ”Erstinitialisierung
der RA”.
212
Anhang B. Organisatorischer Anhang B.2. Inbetriebnahme des Prototypen
B.2.1. Verzeichnisstruktur
In diesem Abschnitt sollen die Verzeichnisse auf der Online-RA wie der OfflineCA nach ihren Funktionen kurz genannt und erläutert werden.
• backup/
Beinhaltet die beim Export erzeugten Archive sowie die beim BatchImport erstellten Konfigurationsdateien mit ihren Archiven (dies gilt nur
für die Offline-CA).
• batch/
In diesem Verzeichnis, das nur auf der Offline-CA existiert, werden die für
dem Batch-Import generierten Archive erstellt. Weiter werden die durch
das pkcs2user.sh Skript erzeugten PKCS#12-Container hier in entsprechenden Verzeichnissen hinterlegt, um sie anschließend an die Nutzer
auszuliefern.
• datenaustausch
Hier wird das Import- bzw. Export-Archiv hinterlegt.
• etc/
In diesem Verzeichnis werden alle zentralen Konfigurationsdateien gehalten. Mehr dazu siehe im technischen Anhang Abschnitt A.3 ”Wichtige
Konfigurationsdateien”.
• lib/
Hier werden alle zentralen Funktionen und Kommandos gehalten, die die
Funktionalität von OpenCA ausmachen.
• modules/
Hier werden alle verwendeten Perl-Bibliotheken und Erweiterungen hinterlegt.
• sh-tools/
Hier befinden sich die für den Betrieb des Prototypen entwickelten Shell-
213
B.3. Benutzeranleitung OpenCA
Anhang B. Organisatorischer Anhang
Skripte. Mehr dazu siehe im Kapitel 4 ”Praktische Umsetzung” Abschnitt
4.9 ”Shell Skripte”.
• var/
Hier werden alle Daten von OpenCA gehalten. Besonders interessant ist
bp/ für die Daten der Batch und crypto/, welches die zentralen Daten
wie Privat Key (Offline-CA) und Zertifikate oder CRLs (Online-RA),
enthält.
B.2.2. Vergebene Passwörter
In diesem Kapitel sollen noch einmal zusammenfassend alle Passwörter aufgelistet werden, die auf dem Prototypen vergeben wurden3 :
• Windows Login für den Nutzer ”HGW” am Labor-Rechner: ”turrican”
• Root Login für die Virtuellen Maschinen: ”turrican”
• Root Login für die Interfaces: ”root”
• Root Login LDAP: ”katakis”
• MySQL Nutzer openca: ”katakis”
Nachdem die Installation und Konfiguration von OpenCA besprochen sowie
auf die Infrastruktur des Prototypen eingegangen wurde, soll dieser Abschnitt
sich direkt mit den Benutzer-Interfaces und der Anwendung beschäftigen. Dabei soll es um die Funktionalität gehen, die auf jedem Interface dem Nutzer
zur Verfügung gestellt wird4 .
3
4
Die Hier vergebenen Passwörter wurden für die Entwicklung verwendet und gelten nicht
gerade als ”sicher”.
Ausgegangen wird von einer unveränderten Menüführung.
214
B.3.1. PUB Interface
Dieser Abschnitt beschreibt das öffentliche Interface einer Zertifizierungsstelle,
die durch OpenCA implementiert wurde. Von dieser Stelle wird es dem Nutzer
möglich, aktuelle Zertifikatlisten aller durch die Zertifizierungsstelle ausgestellten Zertifikate einzusehen. Weiterhin können CRLs heruntergeladen, die Policy
eingesehen, die Wurzelzertifikate bezogen sowie Anträge auf Zertifizierung und
Sperrung erstellt und abgeschickt werden. Die Menüführung ist unter allen Interfaces von OpenCA gleich organisiert. Es gibt jeweils eine obere Kategorie
worunter verschiedene Punkte zusammengefasst sind.
CA Informationen
Diese Sektion, Abbildung B.1, beinhaltet alle nötigen Informationen, die der
Nutzer von der Zertifizierungsstelle beziehen kann.
Abbildung B.1.: PUBLIC-Interface CA Informationen
• Policy
Hier kann die Policy der Zertifizierungsstelle eingesehen werden.
• Laden des CA-Zertifikates
Hier kann das Wurzel-Zertifikat der Zertifizierungsstelle in verschiedenen
Formaten (CRT, PEM, DER, CER, TXT) bezogen werden.
• Zertifikats-Rückruf-Listen
Diese Seite stellt die aktuelle CRL (Zertifikats-Rückruf-Liste) zur Verfügung. Es wird der Download der CRLs im DER-, PEM- und TXT-Format
unterstützt.
215
Nutzer
Diese Sektion, dargestellt in Abbildung B.2, erlaubt es dem Nutzer seine Zertifikate zu verwalten.
Abbildung B.2.: PUBLIC-Interface Nutzer
• Beantragen eines Zertifikates
Dieser Punkt ist mit einer Seite verknüpft, die eine Menge verschiedener
Möglichkeiten der Antragserstellung bereitstellt5 . Je nach Verwendungszweck der Zertifizierungsstelle können hier folgende Punkte erscheinen:
– Beantragen eines Zertifikates mit automatischer Browsererkennung
Im Normalfall versucht OpenCA die Generierung des CSR sowie
die Erzeugung der Schlüssel dem Client zu überlassen, um so ein
Maximum an Sicherheit zu erreichen. In diesem Punkt prüft OpenCA selbst, welcher Browser verwendet wird und wählt den Ort der
Erzeugung selbst aus.
– Allgemeiner Zertifizierungsantrag
Hier wird eine Server-seitige Schlüsselgenerierung benutzt (wenn der
verwendete Browser nicht unterstützt wird)
– Antrag für einen Hardwaretoken
Hier wird das Schlüsselpaar auch auf dem Server generiert. Dieser
Menüpunkt kommt zum Einsatz, wenn die Zertifizierungsstelle die
Verwendung von Hardware-Tokens unterstützt.
– Netscape-Zertifizierungsantrag
Dieser Punkt nutzt die im Netscape-(Mozilla-/Firefox-) Browser
5
Für nähere Informationen siehe auch Abschnitt 4.9.4 ”CSR Handhabung” und 4.10.4
”Reguläre Zertifikatbeantragung”.
216
verfügbaren Krypto-Funktionen für die Client-seitige Generierung
der Schlüssel und des Antrages.
– Zertifizierungsantrag für Internet Explorer
Dieser Punkt nutzt die im Internet Explorer verfügbaren KryptoFunktionen für die Client-seitige Generierung der Schlüssel und des
Antrages.
– Zertifizierungsantrag für Server
Hier kann ein Server zertifiziert werden. Dazu muss vom Administrator des fraglichen Servers ein eigener Zertifikatsantrag und
die dazugehörigen Schlüssel selbst generiert werden. Der CSR kann
dann an dieser Stelle hochgeladen und an die Zertifizierungsstelle
geschickt werden.
• Laden des beantragten Zertifikates
Hier werden die beantragten Zertifikate vom User empfangen. Wenn eine Client-seitige Schlüsselgenerierung verwendet wurde, ist es nötig, dass
der Nutzer denselben Computer und Browser verwendet, den er zur Erstellung des Antrages verwendet hat. Dies ist sehr wichtig, da IE und
Netscape die Verlinkung zwischen dem Zertifikat, dem Antrag und dem
privaten Schlüssel benötigen. Dies kann aber nur von dem Browser auf
dem Rechner gewährleistet werden, auf dem auch das Schlüsselpaar und
der Antrag erstellt wurden. Der Nutzer kann dann durch die Eingabe der
Seriennummer, die er bei der Erzeugung des Antrages bekommen hat,
das Zertifikat herunterladen und dieses zusammen mit dem im Browser
schon vorhandenen zugehörigen privaten Schlüssel installieren.
• Test Certificate
Nach Anwählen dieses Punktes werden dem Nutzer die Daten der aktuelle HTTPS-Session mit dem PUBLIC-Interface angezeigt. Meist werden
hier die Daten des Server-Zertifikates angezeigt die der Server im Laufe der Etablierung der HTTPS-Verbindung an den Client geschickt hat.
217
Durch den Schalter ”signieren” ist es nun möglich, das Zertifikat zu testen.
• Zertifikat zurückrufen
Dieser Punkt gibt dem Nutzer die Möglichkeit, das eigene Zertifikat mit
Angabe von Gründen sperren zu lassen.
Zertifikate
Diese Sektion, dargestellt in Abbildung B.3, erlaubt es dem Nutzer, alle auf
der Zertifizierungsstelle zugelassenen, gesperrten, abgelaufenen und suspendierten Zertifikate einzusehen und ist in erster Linie ein Interface zur Suche
von bestimmten Zertifikaten.
Abbildung B.3.: PUBLIC-Interface Zertifikate
• Gültig
Dieser Punkt gibt Überblick über alle gültigen Zertifikate innerhalb der
Zertifizierungsstelle. Folgende Daten werden für jedes Zertifikat in einer
generierten Liste angezeigt:
– Serial
Die Seriennummer des Zertifikates. Der Nutzer kann den Inhalt des
Zertifikates durch Anwählen des Links der Seriennummer einsehen.
Hier kann auch das Zertifikat heruntergeladen und gesperrt werden.
– Name
Der Name, auf dem das Zertifikat ausgestellt wurde.
– Ausstellungsdatum
Der Tag, an dem das Zertifikat signiert wurde.
218
– EMail
E-Mail-Adresse im Zertifikat.
– Rolle
Der Typ des Zertifikates.
• Abgelaufen
Dieser Punkt gibt Überblick über alle abgelaufenen Zertifikate innerhalb
der Zertifizierungsstelle.
• Suspendiert
Dieser Punkt gibt Überblick über alle suspendierten Zertifikate innerhalb
der Zertifizierungsstelle.
• Zurückgerufen
Dieser Punkt gibt Überblick über alle zurückgerufenen Zertifikate innerhalb der Zertifizierungsstelle.
• Suche
Hier kann speziell nach einem Zertifikat anhand des Namens, der E-MailAdresse oder des DN gesucht werden6 .
Anträge
Die Sektion, dargestellt in Abbildung B.4, zeigt alle noch nicht bearbeiteten
Anträge an.
Abbildung B.4.: PUBLIC-Interface Anträge
• Zertifizierungsanträge
Hier kann man sich eine Übersicht über alle Anträge verschaffen, die in
der Warteschlange der RA stehen.
6
Eine Angabe von Wildcards *name* ist erlaubt.
219
• Zertifikatsrückrufe
Hier kann man sich eine Übersicht über alle Zertifikatsrückrufe verschaffen, die in der Warteschlange der RA stehen.
B.3.2. RA-Interface
Dieser Abschnitt beschreibt das RA-Interface einer OpenCA-PKI. Von diesem
kann der RA-Operator Zertifikatsanträge verwalten, Zertifikatinformationen
einsehen und den RA-Server verwalten.
Allgemein
Abbildung B.5.: RA-Interface Allgemein
• Server-Verwaltung
Über diesen Punkt kommt man auf das NODE-Interface der RA
• LDAP Administration
Über diesen Punkt kann man direkt in das LDAP-Interface der RA wechseln.
Aktive CSR
Hier (siehe Abbildung B.6) können die an die RA gestellten und in Bearbeitung befindlichen Zertifikatsanträge eingesehen und verwaltet werden. Ist der
RA-Operator sicher, dass alle Informationen im Antrag korrekt sind, kann er
den Antrag akzeptieren. Dies kann mit oder ohne eine digitale Unterschrift geschehen. Ist der CSR fehlerhaft, kann er an dieser Stelle auch gelöscht werden.
220
Abbildung B.6.: RA-Interface aktive CSRs
Aktive CRRs
Hier (siehe Abbildung B.7) können die an die RA gestellten und in Bearbeitung
befindlichen Widerrufungsanträge eingesehen und verwaltet werden.
Abbildung B.7.: RA-Interface aktive CRRs
Information
In dieser Sektion, dargestellt in Abbildung B.8, ist es dem RA-Operator möglich alle Zertifikate und Anträge in all ihren Stadien einzusehen und zu überwachen.
Abbildung B.8.: RA-Interface Informationen
Hilfsmittel
In dieser Sektion, dargestellt in Abbildung B.9, stehen dem RA-Operator ein
paar kleinere Werkzeuge zum Suchen in den Anträgen und Zertifikaten zur
Verfügung.
221
Abbildung B.9.: RA-Interface Hilfsmittel
Veränderbare Felder im CSR
Nach dem Einreichen des Antrages an eine RA muss dieser durch eine zuständige Person (der RA-Operator) geprüft werden. Diese Person hat die Möglichkeit, den Antrag nachträglich teilweise anzupassen. Folgende Felder können
geändert werden.
• Subject alternative name
Diese Feld kann zusätzliche Informationen für Programme enthalten, die
das Zertifikat, nicht aber den privaten Schlüssel nutzen. Dies können z.B.
E-Mail-Adressen, DNS-Namen, IP-Addressen und mehr sein. E-MailAdressen sind wichtig wenn man das Zertifikat für E-Mail-Verschlüsselung
nutzen will. Der Grund dafür ist, dass viele E-Mail-Clients S/MIME v2
unterstützen, dass wiederum E-Mail-Adressen im Zertifikat voraussetzt.
DNS-Namen and IP-Addressen sind sehr nützlich, benutzt man das Zertifikat für SSL-Server oder VPNs.
• Subject or distinguished name
Dies ist der Distinguished Name des Zertifikates. Dabei ist zu beachten,
dass der DN von rechts nach links gelesen wird (siehe auch LDAP und
DNs).
• Role
Dies ist die angefragte Rolle. Der RA-Operator muss diese prüfen und
gegebenenfalls auf die richtige anpassen.
• Additional data
Diese Informationen werden nur für interne Zwecke verwendet und sind
222
nicht Teil des Zertifikates. Diese Felder werden normalerweise für das
Abspeichern von Telefonnummern, Adressen oder IDs verwendet.
B.3.3. CA-Interface
Das CA-Interface ist die zentrale Schaltstelle einer Zertifizierungsstelle zum
Zertifizieren und Verwalten von Anträgen sowie das Erstellen und Verwalten
von CRLs. Befindet sich der CA-Operator auf dem CA-Interface, kann dieser unter der CSR Sektion neue Anträge einsehen und diese entweder unterzeichnen oder löschen. Soll ein Antrag unterzeichnet werden, wird als Erstes
nach dem Passwort des privaten Schlüssels der CA gefragt. Nach erfolgreicher
Eingabe wird der Antrag unterzeichnet und das neue Zertifikat in der CADatenbank abgelegt. Besitzen CA und RA nicht dieselbe Datenbank, muss
anschließend ein Export an die RA stattfinden, um das neu signierte Zertifikat
im PUBLIC-Interface und auf dem LDAP-Server zu veröffentlichen.
Allgemein
Abbildung B.10.: CA-Interface Allgemein
• Initialisierung
Grundinitialisierung der CA siehe Abschnitt 4.10.1 ”Erstinitialisierung
der CA”
• Konfiguration
In diesem Punkt können zentrale Einstellungen für die CA getätigt werden. Folgendes steht zur Verfügung:
223
– Roles
Alle verfügbaren Rollen innerhalb der CA können hier verwaltet
und auch weitere hinzugefügt werden.
– Rights
Alle verfügbaren Rechte innerhalb der CA können hier verwaltet
und auch weitere hinzugefügt werden.
– Modules
Alle verfügbaren Module mir ihren IDs können hier eingesehen werden.
– Sign the configuration
Hier kann die Konfiguration signiert werden.
• Knotenverwaltung
Hier kann man in das NODE-Interface der CA wechseln.
Normale Operationen
Hier (siehe Abbildung B.11) können die an die CA übertragenen und in Bearbeitung befindlichen Zertifizierungsanträge und Widerrufungsanträge eingesehen und verwaltet werden. Folgende Punkte stehen dem CA-Operator zur
Verfügung:
Abbildung B.11.: CA-Interface Normale Operationen
• Genehmigte Zertifizierungsanträge
Hier können die durch die RA genehmigten CSRs eingesehen und signiert
werden.
224
• Genehmigte Rückrufe
Hier können die durch die RA genehmigten CRRs eingesehen und signiert
werden.
• Erstellen einer neuen CRL
Hier kann eine neue CRL generiert werden.
• Issue certificates (automaticly)
Dieser Punkt ist eine zusätzliche Nutzung des Batch-Prozessors. Darüber
können alle in der Warteschlange der CA befindlichen CSRs automatisch
abgearbeitet werden.
• Revoke certificates (automaticly)
Dieser Punkt ist ähnlich dem obigen, mit dem Unterschied, dass hier alle
in der Warteschlange der CA befindlichen CRRs automatisch abgearbeitet werden können.
B.3.4. NODE-Interface
In einer Umgebung, in der eine Offline-CA realisiert wurde, besitzt die CA
wie auch die RA eine eigenständige Datenbank, die völlig getrennt von einander existieren. Um den Abgleich der Datenbanken zu ermöglichen (d.h. die
Anträge von der RA auf die CA und die Zertifikate von der CA auf die RA
zu übertragen), die ja keine Verbindung über das Netzwerk zueinander haben, wurde das NODE-Interface eingeführt. Mit dem NODE-Interface wird
es möglich den Datenaustausches zwischen der RA und CA über ein beliebiges Medium (Diskette, USB-Stick, Tokens) zu betreiben. Standardmäßig ist
unter OpenCA das Diskettenlaufwerk /dev/fd0 als Export-/Import-Medium
konfiguriert. Für eine weitere Konfiguration des Datenaustausch sei an dieser Stelle auf den Abschnitt 4.5.4 ”Datenaustausch” im Kapitel 4 ”Praktische
Umsetzung” verwiesen.
225
Allgemein
In dieser Sektion, dargestellt in Abbildung B.12, kann auf die verschiedenen
Interfaces von OpenCA gewechselt werden.
Abbildung B.12.: NODE-Interface Allgemein
• Zertifizierungsinstanz
Hier wird der User auf die zentrale CA-Seite des Servers geleitet. Dieser
Link ist aber nur ansprechbar, wenn die CA als eine Online-CA ausgeführt ist. Ist eine Offline-CA vorgesehen, führt dieser Link ins Leere.
• Registrierungsinstanz
Hier wird der User auf die zentrale RA-Seite des Servers geleitet.
• LDAP Administration
Hier wird der User auf die Zentrale LDAP-Seite des Servers geleitet. Vorausgesetzt der LDAP-Teil ist ordnungsgemäß konfiguriert, können hier
die Zertifikate und CRLs auf einem LDAP-Server veröffentlicht werden.
• Öffentlich
Hier wird der User auf die zentralen Public-Seiten des Servers geleitet.
Administration
Hier (siehe Abbildung B.13) ist es möglich, die Export-, Import- und BackupFunktionen die OpenCA zur Verfügung stellt, zu nutzen.
Abbildung B.13.: NODE-Interface Administration
226
• Anhalten der Services der Crypto Token
Anhalten des OpenCA-Servers.
• Server Initialisierung
An dieser Stelle kann die Datenbank für die RA initialisiert werden (vorausgesetzt es existieren für RA und CA jeweils getrennte Datenbanken)
Der Punk ”Importieren der Konfiguration” startet einen Import-Prozess
von der CA. Voraussetzung ist dafür ein vorher initiierter Export bei
der CA und die richtige Konfiguration des Mediums z.B. Diskette oder
USB-Stick.
• Datenaustausch
Hier ist es möglich, den Datenaustausch mit anderen Ebenen der PKI
z.B. einer Offline-CA zu gewährleisten. Folgende Möglichkeiten stehen
zur Verfügung:
– Exportieren von Daten zu einer niedrigeren Ebene der Hierarchie
Export von CA zu RA. Voraussetzung für einen erfolgreichen Export sind Schreibrechte auf dem Exportmedium.
– Importieren von Daten von einer niedrigeren Ebene der Hierarchie
Import von RA zu CA. Voraussetzung für einen erfolgreichen Import sind ein vorheriger erfolgreicher Export und die Leserechte auf
dem Medium, über den der Import geschehen soll.
– Download data from a higher level of the hierarchy
Import von CA zu RA. Voraussetzung für einen erfolgreichen Import sind ein vorheriger erfolgreicher Export und die Leserechte auf
dem Medium, über das der Import geschehen soll.
– Exportieren von Daten zu einer höheren Ebene der Hierarchie
Export von RA zu CA. Voraussetzung für einen erfolgreichen Export sind Schreibrechte auf dem Exportmedium.
227
• Backup und Wiederherstellung der Datenbank
Dieser Punkt erlaubt es dem Administrator, die Inhalte der Datenbank
zu sichern oder wiederherzustellen. Voraussetzung ist die Konfiguration
des Export-/Import-Mediums. Folgende Wiederherstellungsmöglichkeiten stehen zur Verfügung:
– Initialisierung der Datenbank
Vorbereiten der Tabellen der Datenbank vor dem Import.
– Wiederherstellen der Datenbank
Kompletter Import der Datenbank mir allen CRLs, CRTs usw.
– Wiederherstellen von OpenSSLs Datenbank und der nächsten Seriennummer
um die schon verwendeten Seriennummer für die Zertifikate und
Anträge auf den aktuellen Stand zu bringen.
• Datenbank
Hier kann direkt in der Datenbank nach Attributen gesucht werden.
Hilfsmittel
Abbildung B.14.: NODE-Interface Hilfsmittel
• E-Mail an neue Nutzer
Hier kann man den neu zertifizierten Nutzern eine Nachricht über die
Bereitstellung ihres Zertifikats zusenden.
• Senden von CRIN E-Mails
Mit diesem Punkt wird den neu zertifizierten Nutzern eine verschlüssel-
228
te E-Mail mit dem CRIN-Code zugesandt. Dieser Code wird gefordert,
wenn man das eigene Zertifikat widerrufen will7 .
• Aufräumen der Sessions
Hier können alle temporären Dateien und Sessions gelöscht werden.
• Löschen temporärer Dateien (nach einem Import)
Hier werden alle bei einem Import erzeugten temporären Dateien gelöscht.
B.3.5. LDAP-Interface
Das LDAP-Interface ist Teil einer jeden RA und ermöglicht es dem RA-Operator,
die Zertifikate und CRLs aus der Datenbank auf einem LDAP-Server abzulegen und zu verwalten.
Aktualisierung
In dieser Sektion, dargestellt in Abbildung B.15, können die Zertifikate und
CRLs auf den LDAP-Server gespielt werden.
Abbildung B.15.: LDAP-Interface Aktualisierung
• CA-Zertifikate
Alle CA-Zertifikate in der Datenbank werden auf dem LDAP-Server abgelegt.
• Zertifikate
Alle Zertifikate in der Datenbank werden auf dem LDAP-Server abgelegt.
• CRL
Alle CRLs in der Datenbank werden auf dem LDAP-Server abgelegt.
7
Siehe auch 4.8.2 ”Probleme mit der CRIN” und 4.10.5 ”Sperren von Zertifikaten”.
229
CA-Zertifikate
In dieser Sektion, dargestellt in Abbildung B.16, ist es möglich, die CA-Zertifikate
wie unter dem PUBLIC-Interface einzusehen. Weiter ist es möglich, explizit bestimmte CA-Zertifikate unter Angabe einer eigenen DN auf dem LDAP-Server
abzulegen oder zu löschen.
Abbildung B.16.: LDAP-Interface CA-Zertifikate
User Zertifikate
In dieser Sektion, dargestellt in Abbildung B.17, ist es möglich, die Zertifikate
wie unter dem PUBLIC-Interface einzusehen. Weiter ist es möglich, explizit
bestimmte Zertifikate unter Angabe einer eigenen DN auf dem LDAP-Server
abzulegen oder zu löschen.
Abbildung B.17.: LDAP-Interface User Zertifikate
CRLs
In dieser Sektion, Abbildung B.18, können die CRLs eingesehen und auf dem
LDAP-Server abgelegt werden. Weiter ist es möglich, explizit die CRLs unter
Angabe einer eigenen DN auf dem LDAP-Server abzulegen oder zu löschen.
Abbildung B.18.: LDAP-Interface CRLs
230
B.3.6. Handhabung der Zertifikate
In diesem Abschnitt soll darauf eingegangen werden, was der Nutzer mit den
angezeigten Zertifikaten machen kann.
Finden eines Zertifikates
Es können Zertifikate mit zwei verschiedenen Methoden gesucht werden. Der
erste Weg ist das Suchen im PUBLIC-Interface unter Utilities -> Search certificate. Hier kann das Zertifikat durch die Eingabe bestimmter Suchparameter
gefunden werden8 . Der zweite Weg ist der etwas ”einfachere”: man geht zu
Zertifkate -> Gültig und sucht in den angezeigten Zertifikaten nach dem gesuchten. Für kleinere PKIs ist dieser Weg sicher recht effizient, doch sollte bei
größeren PKIs der erste Weg bevorzugt werden.
Download eines Zertifikates
Direkter Download
Es ist möglich, das Zertifikat direkt in den Browser zu laden. Voraussetzung
dafür ist die Kenntnis der Seriennummer des Zertifikates.
Anmerkung: Man sollte nicht vergessen, dass diese Methode nur funktioniert,
wenn das Schlüsselpaar und der Antrag auf dem gleichen Browser generiert
wurden und der private Schlüssel im Keystore des Computers oder Browsers
abgelegt wurde.
Download von der Zertifikatseite
Es gibt drei verschiedene Möglichkeiten des Downloads: Der passive Download von Daten, der Download von privaten Schlüsseln und dem Zertifikat
und der Download eines fremden Zertifikates, um es im Browser oder E-MailProgramm zu installieren9 .
8
9
Die Eingabeform akzeptiert nur Wildcards wenn über eine SQL Datenbank gesucht wird.
Besitzt man schon den privaten Schlüssel und will man das eigene Zertifikat laden, sollte
man die Option des direkten Downloads nutzen.
231
• Normaler Download
Hier ist es möglich, ein Zertifikat in verschiedenen Formaten zu beziehen.
• Privater Schlüssel Download
Will man ein Zertifikat und den privaten Schlüssel laden, gibt es dazu
zwei Möglichkeiten:
Ist die Operation des Download erlaubt und ist in der Konfiguration des
PUBLIC-Interface die Option REQUIRE_PASSWD_PUBLIC auf NO gesetzt, dann ist es möglich, direkt über den download-Link das Zertifikat
und den privaten Schlüssel nach Angabe der PIN zu laden.
Bei der zweiten Möglichkeit ist in der Konfiguration die Option REQUIRE_PASSWD_PUBLIC auf YES gesetzt. Daher muss der RA-Operator
kontaktiert werden, um das zusätzliche Passwort für den Download anzufordern. In anderen Worten wird dadurch der private Schlüssel mit
dem eigenen PIN und einem zusätzlichen, vom RA-Operator definierten, Passwort geschützt. Dieser Schutz sollte dann verwendet werden,
wenn man ”Denial Of Service”-Attacken auf den privaten Schlüssel eines
Nutzers verhindern möchte.
• Zertifikatinstallation
Manchmal werden Zertifikate von anderen Nutzern benötigt, um z.B.
signierte E-Mails zu überprüfen, die von einem Nutzer gesandt wurden,
mit dem man vorher noch nie Kontakt hatte. Normalerweise wird von
den meisten E-Mail-Clients das Zertifikat mit in der signierten E-Mail
deponiert, so dass ein gesonderter Download über das PUBLIC-Interface
nicht nötig ist. Ist das Zertifikat in der E-Mail nicht verfügbar, ist es für
den Nutzer möglich, auf dem PUBLIC-Interface von OpenCA nach dem
Zertifikat zu suchen und über den Schalter ”Install” das Zertifkat automatisch in der entsprechenden Applikation zu installieren bzw. herunterzuladen. Voraussetzung dafür ist, dass in der Konfiguration pub.conf
die Option INSTALL_CERT aktiviert wurde.
232
B.4. Erstinitialisierung der CA
Die hier beschriebenen Phasen sind kein Muss. Sie sollten aber genutzt werden,
wenn der CA- und RA-Operator ein eigenes Zertifikat an der Zertifizierungsstelle betreiben will. Diese Zertifikate können CA- und RA-Operator z.B. zum
Datenaustausch mit anderen Teilnehmern der Zertifizierungsstelle oder zum
Signieren von CRRs (RA-Operator) oder CRLs (CA-Operator) verwenden.
B.4.1. Erstellen des ersten Administrators
1. Erzeugen eines neuen Antrages
Hier werden die Daten für den CA-Operator angegeben und der private Schlüssel nebst CSR erzeugt. Für die Erstellung des CA-Operators
wurden im Prototypen exemplarisch folgende Werte vergeben:
• Nutzer Name = CA-Operator-Informatik
• Name (Vor- und Nachname) = Winkler Hans-Georg
• Rolle = RA-Operator
• Registrierungsinstanz (RA) = Trustcenter selbst
• PIN = Hier sollte ein sicheres Passwort verwendet werden.
Erzeugt wird dabei das Zertifikat mit dem Distinguished Name CN=CAOperator-Informatik, OU=User-CA, O=Fachbereich DCSM, DC=cs, DC=fhwiesbaden, dc=de.
2. Bearbeiten des Antrages
Hier kann der Antrag nachträglich bearbeitet und anschließend abgeschickt werden.
233
3. Zertifikat ausstellen
Hier wird der abgeschickte Antrag durch die CA nach Abfragen des Passwortes für den privaten Schlüssel der CA signiert.
4. Zertifikat verwalten
Hier kann man das Zertifikat einsehen.
Der CA-Operator kann nun dieses Zertifikat als PKCS#12-Datei herunterladen und in seine E-Mail- und Browser-Applikationen Importieren.
B.4.2. Erstellen des ersten RA-Zertifikates
1. Erzeugen eines neuen Antrages
Hier werden die Daten für den RA-Operator angegeben und der private
Schlüssel nebst CSR erzeugt. Innerhalb des Prototypen wurden dieselben Werte wie beim CA-Operator verwendet. Die einzigen Unterschiede
bestehen darin, dass als Rolle der RA-Operator angegeben und als Nutzername ”RA-Operator-Informatik” vergeben wurde. Erzeugt wird dabei
das Zertifikat mit dem Distinguished Name CN=RA-Operator-Informatik,
OU=User-CA, O=Fachbereich DCSM, DC=cs, DC=fh-wiesbaden, dc=de.
2. Bearbeiten des Antrages
Hier kann der Antrag nachträglich bearbeitet und anschließend abgeschickt werden.
3. Zertifikat ausstellen
Hier wird der abgeschickte Antrag durch die CA nach Abfragen des Passwortes für den privaten Schlüssel der CA signiert.
4. Zertifikat verwalten
Hier kann man das Zertifikat einsehen.
Der RA-Operator kann nun dieses Zertifikat als PKCS#12-Datei herunterladen und in seine E-Mail- und Browser-Applikationen importieren. Dadurch
234
wird es dem Operator möglich, CSRs und CRRs nach der Genehmigung noch
mit dem eigenen Zertifikat zu signieren. So wird einer nachträglichen Manipulation auf dem Weg von der RA zur CA vorgebeugt.
235
236
Abbildungsverzeichnis
2.1. Vorgang der symmetrischen Verschlüsselung . . . . . . . . . . . 10
2.2. Vorgang der asymmetrische Verschlüsselung . . . . . . . . . . . 13
2.3. Vorgang der Hybriden Verschlüsselung . . . . . . . . . . . . . . 16
2.4. Vorgang der digitalen Signierung . . . . . . . . . . . . . . . . . 19
2.5. Grundlegender Aufbau einer PKI . . . . . . . . . . . . . . . . . 23
2.6. Erstellung eines Zertifikates . . . . . . . . . . . . . . . . . . . . 28
2.7. Prüfung eines Zertifikates . . . . . . . . . . . . . . . . . . . . . 29
2.8. Signierung einer E-Mail . . . . . . . . . . . . . . . . . . . . . . . 31
3.1. Aufbau der Fachbereich-PKI . . . . . . . . . . . . . . . . . . . . 37
3.2. Aufbau der Fachhochschul-PKI . . . . . . . . . . . . . . . . . . 38
3.3. Automatischen Zertifikaterstellung bei Studenten . . . . . . . . 55
3.4. Reguläre Zertifikaterstellung für Professoren, Mitarbeiter und
Studenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5. Zertifikaterstellung für Datenverarbeitungssysteme . . . . . . . . 58
3.6. Zertifikaterneuerung . . . . . . . . . . . . . . . . . . . . . . . . 65
3.7. Rollenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1. Interner Aufbau von OpenCA . . . . . . . . . . . . . . . . . . . 87
4.2. Aufbau der Zertifizierungsstelle . . . . . . . . . . . . . . . . . . 90
4.3. Interner Aufbau der Zertifizierungsstelle . . . . . . . . . . . . . 92
4.4. Mögliche Aufteilung bei der Einführung von LOA . . . . . . . . 114
4.5. Übersicht über ein Zertifikat unter Mozilla Thunderbird . . . . . 123
237
4.6. Übersicht über ein Zertifikat unter Mozilla Thunderbird bei Verwendung des DN für die Nutzer-Verwaltung . . . . . . . . . . . 124
4.7. CA-Interface Erstinstallation . . . . . . . . . . . . . . . . . . . . 143
4.8. Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.9. Antrag auf Zertifizierung . . . . . . . . . . . . . . . . . . . . . . 149
4.10. Abgeschlossener Antrag
. . . . . . . . . . . . . . . . . . . . . . 150
4.11. Prozess Zertifikat Antrag . . . . . . . . . . . . . . . . . . . . . . 153
4.12. Prozess der automatischen Zertifikaterstellung . . . . . . . . . . 156
4.13. Prozess der Sperrung von Zertifkaten . . . . . . . . . . . . . . . 157
5.1. Mozilla LDAP-Adressbuch . . . . . . . . . . . . . . . . . . . . . 167
5.2. Mozilla Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.3. Mozilla Zertifikat Ansicht . . . . . . . . . . . . . . . . . . . . . 169
5.4. KAdressbuch mit LDAP . . . . . . . . . . . . . . . . . . . . . . 171
5.5. Suchen von Zertifikaten unter Kleopatra . . . . . . . . . . . . . 173
5.6. Zertifikate Ansicht unter Kleopatra . . . . . . . . . . . . . . . . 173
A.1. Standard Workflow des Batch-Prozessors von OpenCA . . . . . 207
B.1. PUBLIC-Interface CA Informationen . . . . . . . . . . . . . . . 215
B.2. PUBLIC-Interface Nutzer . . . . . . . . . . . . . . . . . . . . . 216
B.3. PUBLIC-Interface Zertifikate . . . . . . . . . . . . . . . . . . . 218
B.4. PUBLIC-Interface Anträge . . . . . . . . . . . . . . . . . . . . . 219
B.5. RA-Interface Allgemein . . . . . . . . . . . . . . . . . . . . . . . 220
B.6. RA-Interface aktive CSRs . . . . . . . . . . . . . . . . . . . . . 221
B.7. RA-Interface aktive CRRs . . . . . . . . . . . . . . . . . . . . . 221
B.8. RA-Interface Informationen . . . . . . . . . . . . . . . . . . . . 221
B.9. RA-Interface Hilfsmittel . . . . . . . . . . . . . . . . . . . . . . 222
B.10.CA-Interface Allgemein . . . . . . . . . . . . . . . . . . . . . . . 223
B.11.CA-Interface Normale Operationen . . . . . . . . . . . . . . . . 224
B.12.NODE-Interface Allgemein . . . . . . . . . . . . . . . . . . . . . 226
B.13.NODE-Interface Administration . . . . . . . . . . . . . . . . . . 226
238
B.14.NODE-Interface Hilfsmittel . . . . . . . . . . . . . . . . . . . . 228
B.15.LDAP-Interface Aktualisierung . . . . . . . . . . . . . . . . . . 229
B.16.LDAP-Interface CA-Zertifikate . . . . . . . . . . . . . . . . . . 230
B.17.LDAP-Interface User Zertifikate . . . . . . . . . . . . . . . . . . 230
B.18.LDAP-Interface CRLs . . . . . . . . . . . . . . . . . . . . . . . 230
239
240
Tabellenverzeichnis
2.1. Schlüssellängen im Vergleich zur Sicherheit . . . . . . . . . . . .
9
3.1. Sicherheitsrelevante Rollen und ihre Aufgaben . . . . . . . . . . 73
3.2. Sicherheitsrelevante Rollen und ihre Verträglichkeiten . . . . . . 73
4.1. Definition der Rollen innerhalb des Prototypen . . . . . . . . . . 113
241
242
Listings
3.1. DN für Mitarbeiter, Professoren, Studenten und externe Mitarbeiter
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2. DN für Datenverarbeitungssysteme . . . . . . . . . . . . . . . . 48
3.3. DN für Mitarbeiter, Professoren und Studenten . . . . . . . . . 49
3.4. DN für Datenverarbeitungssysteme . . . . . . . . . . . . . . . . 49
4.1. Aufruf von ./configure für den Prototypen . . . . . . . . . . . . 99
4.2. Exemplarischer Ausschnitt der pub.conf
. . . . . . . . . . . . . 104
4.3. Exemplarischer Ausschnitt der Konfiguration für PKCS#10 . . 107
4.4. Exemplarischer Ausschnitt für Export/Import zu/von einem niedrigeren Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.5. Exemplarischer Ausschnitt für den Export-Befehl . . . . . . . . 111
4.6. Exemplarischer Ausschnitt für den Import-Befehl . . . . . . . . 111
4.7. Exemplarischer Ausschnitt für den Aufbau einer ACL . . . . . . 112
4.8. Inhalt des User Account von hwink001 . . . . . . . . . . . . . . 118
4.9. Exemplarischer Ausschnitt für den Basisantrag . . . . . . . . . . 121
4.10. Anpassung des Kommandos viewCert . . . . . . . . . . . . . . . 121
4.11. Anpassung des Kommandos listCerts . . . . . . . . . . . . . . . 122
4.12. Exemplarischer Ausschnitt aus der batch_process_data.txt . . . 127
4.13. Ausschnitt der Batch Import-/Export-Sektion . . . . . . . . . . 128
4.14. Aufbau der crin.db . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.15. Exemplarischer Ausschnitt der Änderungen an dem Kommando
getStaticPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
A.1. Exemplarischer Ausschnitt der https.conf . . . . . . . . . . . . . 192
243
A.2. Exemplarischer Ausschnitt für zusätzliche Attribute . . . . . . . 195
A.3. Exemplarischer Ausschnitt aus der Channel-Konfiguration . . . 196
A.4. Exemplarischer Ausschnitt aus der Login-Konfiguration . . . . . 197
A.5. Inhalt des Export/Import Archiv openca.tar . . . . . . . . . . . 199
A.6. Exemplarischer Ausschnitt für Export/Import . . . . . . . . . . 199
A.7. Exemplarischer Ausschnitt die Konfiguration des Wurzel-DN . . 202
A.8. Welche Zertifikate dürfen nicht veröffentlicht werden . . . . . . . 203
A.9. Exemplarischer Ausschnitt für das ”Import New User Format” . 203
A.10.Beispiel für ”Import New User” . . . . . . . . . . . . . . . . . . 203
A.11.Exemplarischer Ausschnitt für ”Import New Process Format”
. 204
A.12.Beispiel für ”Import New Process” . . . . . . . . . . . . . . . . 204
A.13.Exemplarischer Ausschnitt für ”Import New Process Format”
. 204
A.14.Ausschnitt für den Basis-Antrag . . . . . . . . . . . . . . . . . . 205
244
Abkürzungsverzeichnis
AGOF . . . . . . . . . Die Arbeitsgemeinschaft Online Forschung ist eine verbandsübergreifende Initiative, die sich mit der Erarbeitung von
qualitativen Messkriterien für Online-Angebote beschäftigt.
CA . . . . . . . . . . . . . Die Zertifizierungsstelle (auch als Certification Authority
bezeichnet) ist ein zentraler Knoten innerhalb einer PKI,
vergibt eindeutige Identitäten und verwaltet diese für jeden
Teilnehmer.
CN . . . . . . . . . . . . . Die Bezeichnung Common Name steht für ein Blattobjekt
innerhalb eines Verzeichnisbaums und ist Bestandteil des
DN.
CP . . . . . . . . . . . . . Die Certificate Policy ist ein Dokument das die Arbeitsweise
einer PKI beschreibt. Weiter soll sie Dritten dazu dienen
die Vertrauenswürdigkeit der durch die CP implementierten
PKI zu prüfen.
CPS . . . . . . . . . . . . Die Certificate Practice Statement (Erklärung zum Zertifizierungsbetrieb) beschreibt die praktische Umsetzung der
Anforderungen die in der CP gestellt werden.
CRL . . . . . . . . . . . Die Certificate Revocation List ist eine Liste mit zurückgezogenen, abgelaufenen und für ungültig erklärten Zertifikaten der herausgebenden Zertifizierungsstelle.
CRR . . . . . . . . . . . Der Certificate Revocation Request ist ein Antrag auf die
Sperrung eines Zertifikates, der vom Inhaber an die ausstellende Zertifizierungsstelle versandt wird.
245
CRT . . . . . . . . . . . Ein Format, in dem ein Zertifikat ausgeliefert werden kann.
CSR . . . . . . . . . . . . Der Certificate Signing Request ist ein Antrag auf die Erstellung eines Zertifikates, der von einem Nutzer zur Signierung an eine Zertifizierungsstelle gesendet wird.
DCSM . . . . . . . . . Abkürzung für den Fachbereich ”Design, Computer Science,
Media”.
DER . . . . . . . . . . . Ähnlich dem CRT kann auch in diesem Format ein Zertifikat ausgeliefert werden.
DES . . . . . . . . . . . . Ein symmetrischer Verschlüsselungsalgorithmus namens Digital Encryption Standard.
DN . . . . . . . . . . . . . Ein Distinguished Name kennzeichnet einen eindeutigen Namen innerhalb eines Verzeichnisdienstes
FB-PKI . . . . . . . . Bezeichnung für die Fachbereichs Public Key Infrastruktur.
FH-PKI . . . . . . . . Bezeichnung für die Fachhochschulweite Public Key Infrastruktur.
GnuPG . . . . . . . . . Gnu Privacy Guard oder GPG ist ein freies KryptographieSystem. Es dient zum Ver- und Entschlüsseln von Daten
sowie zum Erzeugen und Prüfen elektronischer Signaturen.
GPGSM . . . . . . . . GPGSM ist eine vollständige S/MIME Implementation; sehr
ähnlich der OpenPGP Implementation von GnuPG.
ITU-T . . . . . . . . . . Ist ein Sektor der Internationalen Fernmeldeunion, der für
internationale Empfehlungen und Standardisierungen im Fernmeldewesen zuständig ist.
KDE . . . . . . . . . . . Das Kool Desktop Environment ist eine frei verfügbare Arbeitsumgebung für Linux/Unix.
LDAP . . . . . . . . . . Ein Netzwerkprotokoll namens Lightweight Directory Access Protocol, das bei Verzeichnisdiensten zum Einsatz kommt.
LDIF . . . . . . . . . . . Das Lightweight Directory Interchange Format ist ein auf
ASCII basierendes Dateiformat das zur Darstellung von Informationen aus einem LDAP-Verzeichnis, zum Datenaus-
246
tausch und zur Synchronisation der Daten mit Hilfe eines
LDAP-Servers verwendet wird.
MD5 . . . . . . . . . . . Eine weitverbreitete kryptographische Hash-Funktion namens Message Digest Algorithm 5.
OCSP . . . . . . . . . . Das Online Certificate Status Protocol ist ein Internet-Protokoll,
das es Clients ermöglicht, den Status von X.509-Zertifikaten
abzufragen.
OpenPGP . . . . . . OpenPGP ist ein Internet-Standard und im RFC 2440 standardisiert. Das Dokument beschreibt das Datenformat, um
Informationen verschlüsselt zu speichern und digitale Signaturen zu erzeugen.
PCA . . . . . . . . . . . Die Policy Certification Authority (auch als RootCA bezeichnet) ist die oberste Instanz einer PKI und besitzt ein
selbstsignierendes Zertifikat (Root-Zertifikat).
PEM . . . . . . . . . . . Abkürzung für Privacy Enhanced Mail und ist eine Serie
von Dokumenten unter der RFC, die die sichere Übertragung von E-Mail über das Internet beschreiben.
PGP . . . . . . . . . . . Pretty Good Privacy ist ein von Phil Zimmermann entwickeltes Programm zur asymmetrischen Verschlüsselung von
Daten.
PKA . . . . . . . . . . . PKI-enabled Application ist eine Anwendung, die auf der
Grundlage der von der PKI zu Verfügung gestellten Dienste
eine vertrauenswürdige Nutzung ermöglicht.
PKCS . . . . . . . . . . Steht für Public Key Cryptography Standard und beinhaltet eine Reihe von kryptografischen Spezifikationen die von
den RSA-Laboratorien entwickelt wurden.
PKCS#10 . . . . . . Steht für Certification Request Standard und bezeichnet das
Format des CSR, der an eine Zertifizierungsstelle gesendet
wird.
247
PKCS#12 . . . . . . Steht für Personal Information Exchange Syntax Standard
und definiert ein Dateiformat, das benutzt wird, um den privaten Schlüssel zusammen mit dem zugehörigen Zertifikat
passwortgeschützt in einem Container zu speichern.
PKI . . . . . . . . . . . . Eine Public Key Infrastruktur ist ein System, welches es ermöglicht, digitale Zertifikate auszustellen, zu verteilen und
zu prüfen.
PSE . . . . . . . . . . . . Personal Security Environment ist in der realen Welt mit
einem großen Schlüsselbund vergleichbar. In der digitalen
Welt ist dies die Ansammlung aller sicherheitsrelevanten
Daten eines Teilnehmers der PKI.
QT . . . . . . . . . . . . . Das Quasar Toolkit ist eine Programmbibliothek, die das
Programmieren von plattformübergreifender Software möglich macht. Wesentliche Teile von KDE basieren auf Qt.
RA . . . . . . . . . . . . . Ist die Registrierungsstelle einer Zertifizierungsstelle (auch
als Registration Authority bezeichnet) zur Annahme von
Anträgen und Sperrung von Zertifikaten.
RD . . . . . . . . . . . . . Der Registrierungsdienst wird durch die RA implementiert.
RFC . . . . . . . . . . . Request for Comments sind eine Reihe von technischen und
organisatorischen Dokumenten.
RootCP . . . . . . . . Die Root Certificate Policy ist die CP der PCA und beinhaltet die Basis-Anforderungen, die jede durch die PCA zertifizierte SubCA erfüllen muss.
RootCPS . . . . . . . Das Root Certificate Practice Statement ist das CPS der
PCA und enthält die praktische Umsetzung der Basis-Anforderungen,
die von den SubCA’s umgesetzt werden müssen.
RSA . . . . . . . . . . . Ein asymmetrischer Verschlüsselungsalgorithmus benannt
nach seinen Entwicklern Ronald L. Rivest, Adi Shamir und
Leonard Adleman.
248
S/MIME . . . . . . . S/MIME ist ein Standard für digitale Unterschriften und
baut auf den Konzepten einer Public-Key-Infrastruktur auf.
SA . . . . . . . . . . . . . Steht für den Systemadministrator, der die Aufgabe hat,
die Installation, Konfiguration, Administration und Wartung der Systeme vorzunehmen.
SB . . . . . . . . . . . . . Der Sicherheitsbeauftragte ist für die Definition und Einhaltung der Sicherheitsbestimmungen zuständig.
SCEP . . . . . . . . . . Das Simple Certificate Enrollment Protocol ist ein von Cisco und VeriSign entwickeltes Protokoll zur Verteilung von
Zertifikaten.
SCP . . . . . . . . . . . . Das Secure Copy ist ein Protokoll sowie ein Programm zur
verschlüsselten Übertragung von Daten zwischen zwei Computern über ein Netzwerk.
SHA . . . . . . . . . . . Steht für sicherer Hash-Algorithmus und bezeichnet eine
Gruppe standardisierter kryptographischer Hash-Funktionen.
SO . . . . . . . . . . . . . Der Systemoperator hat Zugriff auf die kryptographischen
Systeme und ist verantwortlich für die Betreuung der Anwendungen.
SSH . . . . . . . . . . . . Die Secure shell ist sowohl ein Programm als auch ein Netzwerkprotokoll, mit dessen Hilfe man sich über eine verschlüsselte Verbindung auf einem entfernten Computer einloggen kann.
SSL . . . . . . . . . . . . Das Secure Sockets Layer ist ein Verschlüsselungsprotokoll
für Datenübertragungen im Internet.
VPN . . . . . . . . . . . Das Virtual Private Network ist ein Computernetz, das über
ein öffentliches Netz gelegt werden kann, um so den sicheren
Transport privater Daten zu gewährleisten.
ZD . . . . . . . . . . . . . Der Zertifizierungsdienst wird durch die CA implementiert.
249
250
Literaturverzeichnis
[AGO06]
AGOF. Berichtsband Teil 1 zu Internet Fakten. Arbeitsgemeinschaft Online Forschung, 2006.
[Ban01]
Jens Banning. Ldap unter Linux. Addison Wesley, 2001.
[BP01]
Steve Burnett und Stephen Paine. Kryptographie RSA Security’s Official Guide. RSA Press, 2001.
[Bra02]
Gilbert Brands. Verschlüsselungsalgorithmen. vieweg, 2002.
[CB05]
Chris Covell und Michael Bell. OpenCA Guides for 0.9.2+.
OpenCA
Group,
http://www.openca.org/openca/docs/,
2005.
[Cla03]
Prof.Dr. Echert Claudia. IT-Sicherheit Konzepte - Verfahren
- Protokolle. OldenBourg, 2003.
[DFN05a]
DFN-Verein. Erklärung zum Zertifizierungsbetrieb der obersten Zertifizierungsstelle der Public Key Infrastruktur im
Deutschen Forschungsnetz, cps-classic v1.1 Auflage, Februar
2005.
[DFN05b]
DFN-Verein. Zertifizierungsrichtlinie der Public Key Infrastruktur im Deutschen Forschungsnetz, cp-classic v1.1 Auflage, Februar 2005.
[ICSbCfNRI+ 93] S. Hardcastle-Kille (ISODE-Consortium), V. Cerf (SURFnet bv), V. Cerf (Corporation for National Research Initiati-
251
ves), R. Hobby (University of California, Davis), und S. Kent
(Bolt Beranek und Newman). RFC 1430 - A Strategic Plan
for Deploying an Internet X.500 Directory Service. Network
Working Group, Februar 1993.
[NDJB02]
Andrew Nash, William Duane, Celia Joseph, und Derek
Brink. PKI e-security implementieren. RSA Press, 2002.
[OSSIVCGL+ 03] S.Chokhani (Orion Security Solutions Inc), W.Ford (VeriSign), R.Sabett (Cooley Godward LLP), C.Merril (McCarter und English LLP), und S.Wu (Infoliance Inc). RFC 3647
- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. Network Working
Group, November 2003.
[PB04]
Norbert Pohlmann und Hartmut Blumberg.
Der IT-
Sicherheitsleitfaden. mitp, 2004.
[RLNVC02]
R.Housley (RSA Laboratories), W.Polk (NIST), W.Ford
(VeriSign), und D.Solo (Citigroup). RFC 3280 - Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile. Network Working Group,
April 2002.
[Smi00]
M. Smith. RFC 2798 - Definition of the inetOrgPerson LDAP Object Class. Network Working Group Netscape Communications, http://www.faqs.org/rfcs/rfc2798.html, 2000.
252
Internetquellen
[URL1] Peter Meyer. Eine Einführung in die Anwendung der Verschlüsselung.
http://www.hermetic.ch/crypto/introg.htm.
[URL2] Robert Silverman.
A Cost-Based Security Analysis of Sym-
metric and Asymmetric Key Lengths.
RSA - Laboratori-
en, http://www.rsasecurity.com/rsalabs/node.asp?id=2088, bulletin
nr.13 edition, April 2000.
[URL3] Wikipedia, http://de.wikipedia.org/wiki/Caesar-Chiffre.
Caesar-
Chiffre, 2006.
[URL4] Wikipedia, http://de.wikipedia.org/wiki/X.509.
X.509 Definition,
März 2006.
[URL5] Wikipedia, http://de.wikipedia.org/wiki/X.500.
X.500 Definition,
März 2006.
[URL6] Massimiliano Pala.
OpenCA Documentation.
OpenCA Group,
http://www.openca.org/openca/docs/.
[URL7] Ann
levels
West.
of
More
on
assurance.
the
e-authentication
initiative
and
http://www.nmi-edit.org/roadmap/auth-
roadmap_200510/start-click-eauth-loa.html.
[URL8] U.S. General Services Administration. What is meant by level of assurance? http://asc.gsa.gov.
253
[URL9] The
OpenLDAP
Administrator’s
Project.
OpenLDAP
Guide.
University
Software
of
2.3
Michigan,
http://www.openldap.org/doc/admin23/.
[URL10] Netscape
Devedge
Mozilla.org,
http://devedge-
temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503.
HTML Tag Reference.
[URL11] Project
ägypten
(free
software
sphinx-clients).
http://www.gnupg.org/aegypten/index.html, 2004.
[URL12] Project
ägypten2:
Improving
free
software
http://www.gnupg.org/aegypten2/index.html, 2005.
254
sphinx-clients.
Index
CA-Operator 113
Symbols
Certification Policy 24
Ägypten 172
Certification Practice Statement 25
A
channel verification 112
Chiffretext 6, 11
ACLs 112
Client-seitig 140
Aktivierungscode 131
Common Name 121
Angreifer 18
Computersicherheit 5
Ausrollen 109
config.xml 101
Authentifizierung 6
configure 94, 103
Authentizität 14
configure_etc.sh 101
B
CP 26, 35
CPS 26, 35
basic 115
CRIN 133, 156
Batch 88, 125, 132
CSR 27, 103, 139
BATCH-Interface 154
Batch-Prozessor 137, 154
D
Batch-System 154
Bearbeitungsdauer 61
Datenaustausch 109, 136, 145
Blockalgorithmen 10
Datenbank 147
Datenblock 10, 18
C
Datenimport 126, 128
CA-Interface 88, 121
Datenintegrität 6
255
Hybridverfahren 16
Datenstromalgorithmen 10
Dekanat 132
I
DES 10
Digest 18
Identität 22, 25
Digitale Signatur 18, 19, 31
Identitätsprüfung 53
Disjuncted Name 48
Initialisierungsphasen 145
E
K
E-Security 1
KAdressbuch 171
Einbrecher 11
Keystore 27, 133
Empfangen 109
Kleopatra 172
Erstinitialisierung 142, 145
KMail 170
Erweiterungen 109
Kryptographie 5, 6
EXTERN-Host 93
L
F
LDAP 89
Fingerabdruck 19
LDAP-Interface 115
Funktionen 126
LDAP-Server 104, 147
LDIF 117
G
Level of Assurance 113
Gültigkeitsdauer 28
LOA 113
Gültigkeitszeiträume 80
login 112
Geheimnis 6, 16
M
H
Mailinglist 103
Hashfunktion 28
make 100, 103
Hashing 18
Masterpasswort 57, 78, 132, 133, 138
Herunterladen 109
MD5 19
high 115
medium 115
Hochladen 109
Microsoft Internet Explorer 140
Home-Verzeichnis 133
Microsoft Outlook Express 174
256
Mitarbeiter 113
Prozessdaten 126
Module IDs 96
Prozesse 126
Mozilla 141
Prozessimport 128
MySQL 86, 89, 102
PSE 26
Pseudonyme 51
N
PUBLIC-Interface 26, 87, 104, 121,
Namen 48
141, 147, 155, 157
Neusignierung 158
Q
Nichtabstreitbarkeit 18
NODE-Interface 88, 145, 151, 155,
Quickimport 126, 128, 154
157
R
Nutzer-Verwaltung 120
RA-Interface 88, 108
O
RA-Operator 113
Offline-CA 90, 93
Registrierung 60
Online-RA 91
Registrierungsdienst 71
OpenLDAP 85, 116
Registrierungsstelle 25, 41
OpenSSL 85, 108
Rollen 71, 109, 112
Rollenmodell 74
P
Root-Policy 114
Passwort 117
Root-Zertifikat 38
PCA 38
RootCA 38
PIN 132, 138, 152, 155
RootDN 120
pin_list 155
RSA 12
PKA 26
rudimentary 115
pkcs2user.sh 132, 138
S
PKCS#10 107, 139, 141
PKCS#12 131, 138, 152, 155
SCEP 87
Policy 35
Schlüssel 7
Prüfsumme 20, 28
Schlüsselaustausch 15
Prototyp 83, 94, 142, 144
Schlüsselbund 26
257
Schlüsselerzeugung 78
U
Schlüsselgenerierung 12, 153
User 126
Schlüssellänge 8, 79, 140, 141
user2batch.sh 131, 137, 154
Schlüsselmanagement 11, 15, 18
Userimport 128
Schlüsselpaar 63, 149, 155
Usernamen 130
Schlüsselraum 8
V
Seriennummer 149, 156
Server-seitig 140, 141
Verbindlichkeit 6
session management 112
Verlängern 158
SHA 19
Verschlüsseln 27, 33
Sicherheitsbeauftragter 72
Vertrauen 21
Sicherheitsmaßnahmen 70
Vertrauenskette 143
Signieren 27
Vertraulichkeit 5
Sperren 156
Verzeichnisdienst 45
SPKAC 139
Vetrauenskette 28
Statusmaschine 125
W
Studentenliste 129, 154
Studentensekretariat 57, 129
Webserver 97
Sub-Policy 114
Widerruf 67, 156
SubCA 144
X
Suspendierung 67
sync.sh 136, 147, 151
X.500 22
Systemadministrator 71
X.509 22, 139
Systemoperator 72
XCA 83
Z
T
Zertifikat 21
technische Systeme 113
Zertifikatakzeptanz 62
Thunderbird 166
Zertifikatbeantragung 148
TinyCA 83
Zertifikaterneuerung 54, 64, 66
258
Zertifikatmodifizierung 67
Zertifikatnehmer 42
Zertifikatnutzung 44
Zertifikatsspeicher 25
Zertifizierungsdienst 71
Zertifizierungsserver 25
Zertifizierungsstelle 23, 39, 43
Zufallszahlengenerator 7, 12
Zustände 126
259
Notizen:
Letzte Änderung 21. Juni 2006
protect your environment !

Entwurf und Strategie der Einführung einer fachbereichsweiten

Transcription

Similar documents

Swisscom Digital Certificate Services Time

InstallationeinerWebsite

Internet-Algorithmen

Jahresbericht 2010 - Institut für Informatik - Hu

Erklärung zum Zertifizierungsbetrieb der ALP

Erzeugen eines externen Schlüssels außerhalb des Browsers

UNIVERSITY OF MACEDONIA

suse linux - ITwelzel.biz

- Axis Communications

Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

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

Anleitung - Erweiterte Funksteuerung "Elinchrom"

Konzept und Nutzen von Certificate Policy und Certification Practice

Leseprobe