ID 6333
Pawelczak, Dieter: Entwurf und Realisierung eines Trust Centers
Hamburg: Diplomica GmbH, 2003
Zugl.: München, Technische Universität, Diplomarbeit, 1998
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
III
Zusammenfassung
In dieser Diplomarbeit werden Teilbereiche eines universitären Trust Centers realisiert. Als
Grundlage entsteht eine Klassenbibliothek zur Erzeugung und Analyse von Zertifikaten, Zer-
tifikatsanträgen und Widerrufslisten gemäß dem Standard X.509.
Im ersten Teil der Arbeit wird allgemein auf die Aufgaben und Anforderungen eines Trust
Centers eingegangen. In diesem Zusammenhang werden typische Anwendungsgebiete sowie
der Standard X.509 vorgestellt.
Im folgenden Kapitel wird der Entwurf eines universitären Trust Centers diskutiert. Die An-
forderungen an ein universitäres Trust Center, die sichere Kommunikation zwischen den
Trust-Center-Instanzen und die Vorgehensweise bei der Zertifizierung und Sperrung von Zer-
tifikaten stehen im Mittelpunkt dieses Kapitels. Für das universitäre Trust Center werden spe-
ziell das Anwendungsgebiet Electronic Mail und das Projekt CAMPUS-CARD betrachtet.
Das Projekt CAMPUS-CARD der Technischen Universität untersucht die Verwendung einer
Chipkarte als elektronischen Studentenausweis. Damit können verwaltungstechnische Vorgän-
ge automatisiert durchgeführt werden. Für das Projekt CAMPUS-CARD entsteht eine Klas-
senbibliothek. Die Realisierung erfolgt nach objektorientierten Methoden. Als Programmier-
sprache wird C++ gewählt. Die Klassen werden mit der Notation der Unified Modeling Lan-
guage (UML) beschrieben.
Es entstehen Klassen für die Generierung von Zertifikaten, Zertifikatsanträgen und Widerrufs-
listen. Für die ASN.1-Kodierung gemäß X.509 wird die Kryptobibliothek SSLeay des Austra-
liers Eric Young verwendet. Weiterhin wird eine Anbindung an die Chipkarte realisiert. Dabei
werden Methoden für den Nachweis über die Authentizität des öffentlichen Schlüssels sowie
für das Lesen und Speichern von Zertifikaten implementiert.
Als eine Anwendung der Klassenbibliothek entsteht die Software für eine Registrierungs- und
eine Zertifizierungsinstanz.
V
Inhaltsverzeichnis
1. Einleitung... 1
1.1
Allgemeines Umfeld ... 1
1.2
Motivation der Arbeit... 3
2. Grundlagen... 5
2.1
Asymmetrische Verschlüsselungsverfahren ... 5
2.1.1 Mathematische Grundlagen des RSA-Verfahrens... 6
2.1.2 Anwendung des RSA-Verfahrens ... 7
2.1.3 Sicherheit des RSA-Verfahrens... 7
2.2
Digitale Signatur ... 9
2.2.1 Forderungen an eine digitale Signatur ... 9
2.2.2 Digitale Signatur mit dem RSA-Verfahren ... 10
2.3
Zertifizierung ... 11
2.3.1 Zertifikate ... 11
2.3.2 Public-Key-Infrastruktur ... 12
2.3.3 Standardisierung nach X.509 ... 14
2.3.4 Weitere Standardisierungsvorschläge... 18
2.4
Sicherheitskonzepte ... 19
2.4.1 Pretty Good Privacy (PGP) ... 19
2.4.2 Privacy Enhanced Mail (PEM)... 21
2.4.3 Secure Socket Layer (SSL) ... 22
2.4.4 Secure Multipurpose Internet Mail Extensions (S/MIME) ... 22
3. Aufgaben und Anforderungen... 25
3.1
Schlüsselmanagement... 25
3.1.1 Schlüsselgenerierung... 25
3.1.2 Schlüsselspeicherung ... 27
3.1.3 Schlüsselverteilung ... 28
3.1.4 Widerruf ... 29
3.2
Beglaubigungsleistung ... 29
3.2.1 Registrierung ... 30
3.2.2 Zertifizierung... 30
3.3
Serverfunktion ... 31
3.4
Anforderung an die Sicherheit ... 32
3.5
Anforderung an die Vertrauenswürdigkeit... 33
4. Entwurf eines universitären Trust Centers... 35
4.1
Anforderungen an ein universitäres Trust Center... 35
4.1.1 Angriffsszenarien und Gegenmaßnahmen ... 35
4.1.2 Anforderungen gemäß den Richtlinien der DFN-PCA ... 37
VI
4.2
Sicherheitskonzepte ...38
4.2.1 Kommunikation der Trust-Center-Instanzen ...39
4.2.2 Sicherheitsumgebung...42
4.3
Anwendung Electronic Mail...43
4.3.1 Pretty Good Privacy...43
4.3.2 Weitere Sicherheitskonzepte für Electronic Mail ...44
4.4
CAMPUS-Card Projekt ...44
4.4.1 Aufbau des Zertifikats ...44
4.4.2 Gültigkeitsdauer des Zertifikats...46
4.4.3 Zertifikatsprüfung ...47
4.4.4 Widerruf...47
4.4.5 Integration von Electronic Mail...48
5. Objektorientierter Entwurf ... 49
5.1
Die Beschreibungssprache UML...49
5.1.1 Anwendungsfalldiagramm...49
5.1.2 Sequenzdiagramm ...50
5.1.3 Klassenstrukturdiagramm ...50
5.2
Kryptobibliothek SSLeay ...52
5.2.1 Übersicht...52
5.2.2 Vorteile der Bibliothek...52
5.2.3 Nachteile der Bibliothek ...53
5.2.4 Integration der Bibliothek...53
5.3
Klassenentwurf ...55
5.3.1 Überblick und Anforderungen...55
5.3.2 Spezifikation der Klassen ...56
5.3.3 Feinspezifikation der Klassen ...58
5.4
Hilfsklassen...61
5.4.1 Anbindung der Chipkarte ...62
5.4.2 Mengenklassen ...62
5.5
Registrierung und Zertifizierung ...63
5.5.1 Registrierung ...63
5.5.2 Zertifizierung ...65
6. Implementierung und Test... 69
6.1
Implementierung der Klassen...69
6.1.1 Transportklassen ...69
6.1.2 ASN.1-Klassen ...69
6.1.3 Schlüsselverwaltung ...70
6.1.4 Chipkarten-Klasse ...70
6.1.5 Test der Klassen...71
6.2
Beispielszenario ...72
6.2.1 Implementierung einer Anwendung für eine Registrierungsinstanz ...72
6.2.2 Implementierung einer Anwendung für eine Zertifizierungsinstanz ...75
6.2.3 Test und Bewertung der Anwendungen...76
VII
7. Zusammenfassung und Ausblick... 81
7.1
Zusammenfassung ... 81
7.2
Ausblick... 81
Literaturverzeichnis ... 83
Glossar ... 89
Anhang... 91
A
Dokumentation der Klassen ... 91
A.1
Klasse DName... 91
A.2
Klasse Key... 92
A.3
Klasse BCert... 93
A.4
Klasse Request ... 94
A.5
Klasse Certificate ... 94
A.6
Klasse CA_Certificate ... 95
A.7
Klasse Crl ... 96
A.8
Klasse CA_Crl ... 98
A.9
Klasse Communication ... 98
A.10 Klasse Offline_Communication ... 99
A.11 Klasse File_Communication ... 100
A.12 Klasse Smart_Card... 101
A.13 Klasse BCertColl... 101
A.14 Klasse BComColl... 102
B
Dokumentation der Anwendungsprogramme ... 103
B.1
Registrierungsinstanz ... 103
B.2
Zertifizierungsinstanz ... 103
C
Beispiel ... 104
IX
Abbildungsverzeichnis
Abb. 1.1: Man-in-the-Middle-Angriff... 2
Abb. 2.1: Digitale Signatur mit Einweg-Hashfunktion und RSA-Verfahren... 11
Abb. 2.2: Verifikation einer digitalen Signatur in einem System mit Trust Center ... 12
Abb. 2.3: Kommunikation bei einer Cross-Zertifizierung zweier Trust Center ... 13
Abb. 2.4: Hierarchische Trust-Center-Infrastruktur ... 14
Abb. 2.5: Felder eines X.509-Zertifikats ... 15
Abb. 2.6: Distinguished Name gemäß X.500... 16
Abb. 2.7: Registrierungsbaum ... 16
Abb. 2.8: Aufbau einer Widerrufsliste... 17
Abb. 2.9: Vertrauensmodell bei PGP... 20
Abb. 2.10:Public-Key-Infrastruktur gemäß Privacy Enhanced Mail... 21
Abb. 3.1: Komponenten eines Trust Centers mit zentraler Schlüsselgenerierung... 26
Abb. 3.2: Trust-Center-Komponenten mit Schlüsselgenerierung durch den Anwender ... 27
Abb. 4.1: RA und CA im geschützten Subnetz... 39
Abb. 4.2: CA- und RA-Rechner mit Netzübergang ... 40
Abb. 4.3: CA- und RA-Rechner völlig vom Netz getrennt ... 41
Abb. 4.4: Beispiele eines Distinguished Name ... 45
Abb. 5.1: Komponenten eines Anwendungsfalldiagramms ... 49
Abb. 5.2: Komponenten des Sequenzdiagramms ... 50
Abb. 5.3: Darstellung einer Klasse mit UML. ... 51
Abb. 5.4: Beziehungen in einem Klassenstrukturdiagramm ... 51
Abb. 5.5a:Speicherung im ASN.1-Format ... 53
Abb. 5.5b:Speicherung in SSLeay-Strukturen ... 54
Abb. 5.5c:Speicherung in Standard C++ -Typen... 54
Abb. 5.6: Anwendungsfalldiagramm Zertifizierung... 55
Abb. 5.7: Verwendung der Klasse DName... 59
Abb. 5.8: Verwendung der Basisklasse BCert... 60
Abb. 5.9: Die Klassen Crl und CA_Crl... 60
Abb. 5.10:Transportklassen ... 61
Abb. 5.11:Interaktionsdiagramm Registrierung ... 64
Abb. 5.12:Interaktionsdiagramm Zertifizierung... 66
Abb. 6.1: Menüstruktur der Registrierungsinstanz... 73
Abb. 6.2: Entwurf einer graphischen Benutzeroberfläche ... 74
Abb. 6.3: Menüstruktur der Zertifizierungsinstanz ... 75
Abb. 6.4: Vorgang der Registrierung ... 77
Abb. 6.5: Vorgang der Zertifizierung... 78
Abb. B.1: Darstellung der Funktionen des RA-Menüs... 103
Abb. B.2: Darstellung der Funktionen des CA-Menüs... 104
XI
Tabellenverzeichnis
Tab. 2.1: Empfohlene Schlüsselgrößen nach [Schn96] ... 8
Tab. 3.1: Instanzen eines Trust Centers ... 25
Tab. 4.1: CAMPUS-CARD-Zertifikat... 45
Tab. 5.1: Klassendarstellung der ASN.1-Objekte... 56
Tab. 5.2: Aufteilung und Verwendung der Klassen ... 57
Tab. 5.3: Verschiedene Transportklassen ... 58
Tab. 5.4: Verwendung des Distinguished Names ... 58
Tab. 6.1: Testprogramme... 71
Tab. 6.2: Aufteilung der Klassen auf Dateien ... 72
Allgemeines Umfeld
1
1. Einleitung
Der Anwenderkreis des Internets hat in den letzten Jahren einen Wandel durchlaufen. Zu-
nächst wurde das Internet in erster Linie von Universitäten und Instituten für Forschungs-
zwecke verwendet. Inzwischen haben auch immer mehr private Haushalte Zugriff auf das
Internet. Daraus ergeben sich völlig neue Anwendungsmöglichkeiten.
So bietet es sich an, eine Reihe von Dienstleistungen über das Internet abzuwickeln. Dazu ge-
hören zum Beispiel Dienstleistungen wie Banküberweisungen, Auskunftssysteme, Buchungen
für Veranstaltungen und Bestellungen.
Weiterhin können verwaltungstechnische Vorgänge, wie zum Beispiel das Einreichen der
Steuererklärung, über das Internet durchgeführt werden.
Allerdings bietet das Internetprotokoll TCP/IP bei der Übertragung elektronischer Nachrich-
ten keinen Schutz vor Abhören oder Manipulation der Daten. Außerdem kann sehr leicht eine
falsche Identität vorgetäuscht werden. Ohne geeignete Sicherheitskonzepte können Dienstlei-
stungen nicht über das Internet abgewickelt werden, wenn dabei vertrauliche Daten übertra-
gen werden müssen.
1.1 Allgemeines Umfeld
Mit Hilfe kryptographischer Verfahren können Nachrichten verschlüsselt und somit vertrau-
lich übertragen werden. Mit asymmetrischen Kryptosystemen kann eine digitale Signatur rea-
lisiert werden. Diese ist vergleichbar mit der eigenhändigen Unterschrift und garantiert für die
Authentizität, Integrität und die Urheberschaft eines Dokuments.
Das Hauptproblem bei asymmetrischen Kryptosystemen liegt in der Schlüssel-Benutzer-Zu-
ordnung. Wenn zwei Parteien miteinander vertraulich kommunizieren wollen, so müssen sie
zunächst ihre öffentlichen Schlüssel austauschen. Bei dem Schlüsselaustausch kann ein An-
greifer den Kommunikationspartnern seinen eigenen Schlüssel unterschieben. Dies stellt den
sogenannten Man-in-the-Middle-Angriff dar [Schn96]. In Abbildung 1.1 ist dieser Angriff dar-
gestellt. Da beide Parteien für die Verschlüssellung den öffentlichen Schlüssel des Angreifers
verwenden, kann der Angreifer die Nachrichten beider Parteien entschlüsseln und nach einer
Manipulation an den eigentlichen Empfänger weiterleiten.
2
Einleitung
Abb. 1.1 Man-in-the-Middle-Angriff
Auch die Einführung einer digitalen Signatur erscheint nur dann sinnvoll, wenn die Signatur
eindeutig und nachweislich einer Person zugeordnet werden kann.
Zur Lösung dieses Problems werden sogenannte Trust Center eingeführt. Ein Trust Center
überprüft die Identität des Schlüsselinhabers und bestätigt mit einem Zertifikat, daß der
Schlüssel tatsächlich zu dieser Person gehört. Ein Zertifikat enthält neben dem öffentlichen
Schlüssel auch die Angaben zur Person des Schlüsselinhabers. Um die Authentizität des Zer-
tifikats zu gewährleisten, wird das Zertifikat mit der digitalen Signatur des Trust Centers ver-
sehen. Das Trust Center stellt allen Teilnehmern eines Systems die Zertifikate zur Verfügung.
Sofern die Teilnehmer über den authentischen öffentlichen Schlüssel des Trust Centers verfü-
gen, können sie die Zertifikate ihrer Kommunikationspartner überprüfen. Das Vortäuschen
einer falschen Identität wird erschwert, da jede Zertifizierung mit einer Überprüfung der Teil-
nehmeridentität verbunden ist.
Die englische Bezeichnung Trust Center kann mit Zentrum des Vertrauens übersetzt werden.
Das Trust Center muß gegenüber seinen Teilnehmern eine Vertrauensbasis schaffen. Schließ-
lich könnte das Trust Center bei der Identitätsüberprüfung unsachgemäß arbeiten und somit
einem Angreifer Zugang zum System verschaffen. Außerdem könnte das Trust Center auch
direkt am Mißbrauch beteiligt sein. So könnte das Trust Center zum Beispiel beliebige falsche
Identitäten erzeugen und zertifizieren. Es könnte auch bereits erstellte Zertifikate widerrufen
und somit eine digitale Signatur für ungültig erklären. In manchen Fällen hat das Trust Center
sogar Zugriff auf die privaten Anwenderschlüssel: In diesem Fall könnte das Trust Center so-
gar mißbräuchlich digitale Signaturen erstellen.
Teilnehmer A
Teilnehmer B
Internet
Angreifer X
E
X
E
X
D
B
D
A
D
X
E
A
E
B
E
x
öffentlicher Schlüssel von X
D
x
privater Schlüssel von X
glaubt im Besitz von E
B
zu sein
glaubt im Besitz von E
A
zu sein
Motivation der Arbeit
3
1.2 Motivation der Arbeit
Im universitären Umfeld gibt es eine Reihe von Anwendungen, bei denen die Wahl elektroni-
scher Datenübertragung gegenüber dem herkömmlichen Schriftverkehr vorzuziehen ist. Auf
diese Weise können deutlich Kosten gespart und Verwaltungsvorgänge beschleunigt werden.
Allerdings müssen elektronische Dokumente über Eigenschaften wie Authentizität, Nach-
weisbarkeit des Ursprungs und Vertraulichkeit verfügen. Diese Eigenschaften werden im her-
kömmlichen Schriftverkehr durch handschriftliche Unterschrift und Stempel bzw. Siegel
sowie durch die Verwendung eines Briefumschlags erreicht. Mit Hilfe von kryptographischen
Verfahren und dem Einsatz eines Trust Centers können diese Anforderungen an elektronische
Dokumente erfüllt werden.
Für das Versenden von vertraulichen Dokumenten können zum Beispiel kryptograpisch ge-
schützte E-Mails verwendet werden. Hierfür existieren bereits eine Reihe von Sicherheitskon-
zepten, die auf asymmetrischen Verschlüsselungsverfahren basieren. So erfordert zum Bei-
spiel der Internet Standard PEM (Privacy Enhanced Mail) eine Zertifizierungsinfrastruktur.
Obwohl Pretty Good Privacy ohne eine strenge Zertifizierungshierarchie auskommt, bietet
sich auch hier der Einsatz eines Trust Centers an.
Das Projekt CAMPUS-CARD der Technischen Universität München verfolgt das Ziel, ver-
waltungstechnische Verfahren wie An-/Abmeldung von Prüfungen, Praktika und Seminaren
zu automatisieren. Die Studenten erhalten dabei einen elektronischen Studentenausweis in
Form einer Chipkarte. Die Chipkarte ist mit einem asymmetrischen Schlüsselpaar versehen
und kann damit eine digitale Signatur durchführen. Auch bei diesem System spielt die Schlüs-
sel-Benutzer-Zuordnung eine wichtige Rolle; schließlich muß die von der Chipkarte durchge-
führte Signatur einem Studenten zugewiesen werden können. Für diesen Zweck soll in dem
Projekt ein Trust Center verwendet werden.
Im Rahmen dieser Arbeit werden die Aufgaben und Anforderungen sowie das Konzept eines
universitären Trust Centers behandelt. Außerdem entsteht für das Projekt CAMPUS-CARD
eine Klassenbibliothek zum Ausstellen und Verwalten von Zertifikaten. Anhand dieser Klas-
senbibliothek werden Teilbereiche des Trust Centers realisiert.
Asymmetrische Verschlüsselungsverfahren
5
2. Grundlagen
In der Kryptographie werden Verschlüsselungsverfahren unter dem Gesichtspunkt der Schlüs-
selverwendung bei der Ver- und Entschlüsselung von Nachrichten unterschieden. Wird für
beide Vorgänge der gleiche Schlüssel verwendet, so wird das Verfahren als symmetrisch be-
zeichnet. Bei asymmetrischen Kryptosystemen kommen unterschiedliche Schlüssel zum Ein-
satz.
Wie in diesem Kapitel gezeigt wird, kann mit asymmetrischen Verfahren eine elektronische
Unterschrift, die sogenannte digitale Signatur, realisiert werden. Um asymmetrische Verfahren
in einem verteilten System sinnvoll einsetzen zu können, ist eine Zertifizierung notwendig
[Ham95].
Eine Reihe von Sicherheitskonzepten, die im Internet verwendet werden, basieren auf asym-
metrischen Kryptosystemen. Typische Konzepte, die im Internet verwendet werden, sind
PGP (Pretty Good Privacy), PEM (Privacy Enhanced Mail), SSL (Secure Socket Layer) und
S/MIME (Secure Multipurpose Internet Mail Extensions)
2.1 Asymmetrische Verschlüsselungsverfahren
Bei asymmetrischen Kryptosystemen, auch Public-Key-Kryptosysteme genannt, verfügt jeder
Teilnehmer über ein Schlüsselpaar. Das Schlüsselpaar besteht dabei aus einem öffentlichen
und einem privaten Schlüssel. Der öffentliche Schlüssel wird zum Verschlüsseln einer Nach-
richt verwendet. Die Nachricht kann anschließend nur mit dem privaten Schlüssel wieder ent-
schlüsselt werden.
Asymmetrische Verschlüsselungsverfahren sind durch die folgende Beziehung gekennzeich-
net: Für jede Nachricht m gilt [Beu96]:
Hier bezeichnet D(x) die Entschlüsselung (Decryption) mit dem privaten Schlüssel und E(x)
den Vorgang der Verschlüsselung (Encryption) mit dem öffentlichen Schlüssel.
Die bekannteste Methode asymmetrischer Verschlüsselungsverfahren ist das RSA-Verfahren,
das nach seinen Entwicklern Ronald Rivest, Adi Shamir und Leonard Adleman benannt
[Beu96] ist. Da der RSA-Algorithmus eine Grundlage dieser Arbeit darstellt, soll im folgen-
den näher auf diesen Algorithmus eingegangen werden. Weitere asymmetrische Verfahren
sind [Sti95]:
· Merkle-Hellmann-Rucksack: Die Sicherheit basiert auf dem Rucksackproblem, einem
NP-vollständigen Problem. Es hat sich jedoch gezeigt, daß Algorithmen, die auf dem
Rucksackproblem basieren, unsicher sind.
· McEliece-Algorithmus: Dieser Algorithmus basiert auf der algebraischen Kodierungs-
theorie und verwendet einen linearen, fehlerkorrigierenden Code.
D E m
( )
(
)
m
=
6
Grundlagen
· ElGamal-Verfahren: Die Sicherheit beruht auf dem Problem des diskreten Logarith-
mus.
· Chor-Rivest: Dieser Rucksackalgorithmus gilt als sicher, benötigt jedoch einen hohen
Berechnungsaufwand [Schn96].
· Verfahren mit elliptischen Kurven.
2.1.1
Mathematische Grundlagen des RSA-Verfahrens
Der RSA-Algorithmus beruht auf dem Satz von Euler. Zur Schlüsselberechnung wird der eu-
klidische Algorithmus zum Berechnen des größten gemeinsamen Teilers verwendet. Die
Schlüssel bestehen aus dem Modul n, dem öffentlichen Exponenten e und dem privaten Expo-
nenten d. Dabei bildet sich der öffentliche Schlüssel aus den Komponenten n und e, der pri-
vate Schlüssel aus n und d. Üblicherweise werden bei der Speicherung des privaten Schlüssels
zusätzliche Hilfsvariablen gespeichert, um den Durchsatz des RSA-Algorithmus zu beschleu-
nigen [RFC2313].
Die Schlüsselgenerierung erfolgt nach dem folgenden Prinzip [Swo97a]:
Es werden zwei unterschiedliche Primzahlen p und q gewählt. Das Modul n berechnet sich zu:
Die Euler'sche Funktion
(n) einer Zahl n stellt die Anzahl aller Zahlen dar, die relativ prim
zu n sind. Für eine Primzahl gilt:
Für das Produkt zweier Primzahlen, und damit für das Modul n ergibt sich:
Die beiden Schlüssel werden so gewählt, so daß die folgende Gleichung gilt:
Dabei ist einer der beiden Exponenten, unter der Bedingung daß er teilerfremd zu
(n) ist, frei
wählbar; es gilt:
Verschlüsselung und Entschlüsselung erfolgt gemäß den folgenden Gleichungen [Swo97a]:
Eine Nachricht m wird mit dem öffentlichen Schlüssel in den Geheimtext c transformiert:
n
p q
=
p
( )
p
1
=
pq
( )
p
1
(
)
q
1
(
)
n
( )
=
=
ed
1 mod
n
( )
ggT
n
( )
d
,
(
)
(
)
1
=
bzw.
ggT
n
( )
e
,
(
)
(
)
1
=
c
m
e
)
mod n
(
=
Asymmetrische Verschlüsselungsverfahren
7
Aus dem Geheimtext c wird mit Hilfe des privaten Schlüssels der Klartext m zurückgewon-
nen:
Der Klartext m sowie der Geheimtext c stellt dabei eine Zahl im Bereich 0..(n-1) dar. Aus die-
sem Grund entsteht eine Blockbildung beim RSA-Verfahren. Bei einer Modullänge von 1024
Bit ergibt sich zum Beispiel eine Blockgröße von 128 Oktetten.
Bei der Schlüsselgenerierung wird üblicherweise der öffentliche Exponent e fest gewählt. Es
bietet sich die vierte Fermat-Zahl F
4
an, da sie aufgrund ihrer binären Darstellung die Potenz-
berechnung stark vereinfacht [Beu96]:
2.1.2
Anwendung des RSA-Verfahrens
Asymmetrische Verschlüsselungsverfahren sind sehr rechenaufwendig und im Vergleich zu
symmetrischen Verschlüsselungsverfahren langsam. Aus diesem Grund wird das RSA-Verfah-
ren nicht direkt zum Verschlüsseln längerer Nachrichten verwendet. Es entstehen sogenannte
hybride Verschlüsselungssysteme [Schn96]: Bei der Übertragung von Nachrichten wird mit
Hilfe des RSA-Algorithmus zunächst ein einmaliger (zufällig generierter) Sitzungsschlüssel
verschlüsselt. Die Nachricht wird anschließend mit einem symmetrischen Kryptoalgorithmus
und diesem Schlüssel verschlüsselt. Der Empfänger entschlüsselt mit seinem privaten RSA-
Schlüssel den Sitzungsschlüssel und kann daraufhin die restliche Nachricht entschlüsseln.
2.1.3
Sicherheit des RSA-Verfahrens
Die Sicherheit des RSA-Verfahrens liegt in dem Problem der Faktorisierung großer Zahlen.
Sobald der öffentliche Modul n in seine beiden Faktoren p und q zerlegt werden kann, ist es
sehr einfach
(n) zu berechnen und mit Hilfe des öffentlichen Exponenten e auf d zu schlies-
sen. Aus diesem Grund muß der Modul n sehr groß gewählt werden. Eine Schlüssellänge von
512 Bit, das entspricht 155 Dezimalstellen und 768 Bit (232 Dezimalstellen) wird heute kaum
noch verwendet. Viele Zertifizierungsinstanzen fordern bereits Schlüssel mit einer Modullän-
ge von 1024 Bit (309 Dezimalstellen) bis zu 2048 Bit (617 Dezimalstellen). Der Faktorisie-
rungsaufwand steigt dabei stark an. So gibt [Schn96] für die Faktorisierung von 512 Bits
30000 Mips-Jahre an. Dabei stellt ein Mips-Jahr die Rechenleistung eines Computers dar, der
ein Jahr lang mit einer Million Instruktionen pro Sekunde rechnet. Als grundlegender Algo-
rithmus ist dabei die Faktorisierung mit dem allgemeinen Zahlkörpersieb betrachtet worden.
Die Rechenleistung, die für die Faktorisierung eines 2048 Bit Schlüssels benötigt wird, ist mit
3*10
20
Mips-Jahre angegeben.
m
c
d
( )
mod n
m
e
(
)
d
modn
=
=
F
4
2
2
4
1
+
2
16
1
+
10000000000000001b
65537
=
=
=
=
8
Grundlagen
Allerdings wird die Rechenleistung heutiger Rechner bereits in einigen 100 Mips angegeben
[Fär97]. Mit einer starken Vernetzung mehrerer Rechner und geeigneter Algorithmen können
inzwischen Zahlen bis 129 Dezimalstellen faktorisiert werden [Schn96]. Die Suche nach
schnelleren Algorithmen zur Faktorisierung großer Zahlen ist aktueller Gegenstand der For-
schung. Tabelle 2.1 enthält Empfehlungen für die Wahl von Schlüssellängen.
Tab. 2.1 Empfohlene Schlüsselgrößen nach [Schn96]
Ein Brute-Force-Angriff, also das Durchprobieren aller möglichen privaten Schlüssel, ist bei
der großen Schlüssellänge noch ineffizienter als der Versuch, das Modul n zu faktorisieren
[Schn96]. Es gibt aber andere Methoden, Angriffe gegen RSA durchzuführen. Diese beziehen
sich nicht auf den Algorithmus, sondern auf das verwendete Protokoll. Aus diesen Angriffen
können direkt Forderungen an das Protokoll abgeleitet werden [Schn96]. Diese Forderungen
fließen direkt in den Standard X.509 ein:
· Chosen-Ciphertext-Angriff: Durch eine geschickt gewählte Zahl, die dem Inhaber des
privaten Schlüssels zur Signatur gegeben wird, kann eine Nachricht, die mit dem ent-
sprechenden öffentlichen Schlüssel verschlüsselt wurde, ermittelt werden. Dieser An-
griff kann dadurch abgewehrt werden, daß Nachrichten bevor sie signiert werden mit
einer Einweg-Hashfunktion bearbeitet werden. Eine Einweg-Hashfunktion erzeugt aus
einer beliebig großen Nachricht einen Fingerabdruck der Nachricht mit einer Länge
von nur wenigen (16-20) Oktetten (siehe Abschnitt 2.2.2 Digitale Signatur mit dem
RSA-Verfahren). Für einen Angreifer ist es praktisch unmöglich, diese Funktion umzu-
drehen, d.h. eine Nachricht zu einem gegebenem Hashwert zu finden [Beu96].
· Angriffe gegen RSA mit gemeinsamem Modul: Bei der Verwendung eines gleichen Mo-
duls n und unterschiedlicher Schlüssel e und d gibt es eine Reihe von Angriffen. Aus
zwei gleichen - aber unterschiedlich verschlüsselten Nachrichten - kann die Nachricht
wiedergewonnen werden, sofern die Verschlüsselungsexponenten relativ prim zueinan-
der sind. Weiterhin können probabilistische Methoden zur Faktorisierung von n ange-
wandt werden. Auch deterministische Algorithmen zur Berechnung eines geheimen
Schlüssels können verwendet werden, ohne das Modul n faktorisieren zu müssen. Die
Benutzung eines gemeinsamen Moduls ist daher zu vermeiden.
· Angriff gegen RSA mit kleinem Verschlüsselungsexponenten: Mit kleinen Werten für e
wird eine deutlich größere Verschlüsselungsrate erreicht. Um einen Angriff durchfüh-
ren zu können, genügt es jedoch e identische Nachrichten mit verschiedenen öffentli-
Jahr
Einzelperson
Unternehmen
Regierung
1995
768
1280
1536
2000
1024
1280
1536
2005
1280
1536
2048
2010
1280
1536
2048
2015
1536
2048
2048
Digitale Signatur
9
chen Schlüsseln zu verschlüsseln. Aus diesem Grund sollten Nachrichten mit
zufälligen Werten aufgefüllt werden. Somit wird vermieden, daß zwei Nachrichten
identisch sind.
· Angriff gegen RSA mit kleinem Entschlüsselungsexponenten: Auch die Verwendung ei-
nes kleinen Entschlüsselungsexponentem d kann die Sicherheit eines System gefähr-
den. Die Wahl von F
4
für den Verschlüsselungsexponenten e erfordert jedoch
automatisch einen großen Wert für d.
2.2 Digitale Signatur
Um elektronische Verträge verbindlich abschließen zu können, ist eine elektronische Variante
der handschriftlichen Unterschrift erforderlich. Aus der Betrachtung der Eigenschaften einer
handschriftlichen Unterschrift können Forderungen für eine digitale Signatur abgeleitet wer-
den. Anschließend wird anhand des RSA-Verfahrens die Realisierung einer digitalen Signatur
beschrieben.
2.2.1
Forderungen an eine digitale Signatur
Eine handschriftliche Unterschrift hat folgende Eigenschaften [Beu96]:
· Die Unterschrift ist individuell, sie kann nur von einer bestimmten Person geleistet
werden.
· Die Unterschrift kann eindeutig einer bestimmten Person zugeordnet werden.
In [Schn96] werden weitere Eigenschaften aufgeführt:
· Die Unterschrift ist nicht wiederverwendbar, sie ist Bestandteil eines Dokuments.
· Die Unterschrift kann nicht zurückgenommen werden, da Unterschrift und Dokument
physisch vorliegen.
Eine handschriftliche Unterschrift kann nicht auf ein elektronisches Dokument angewendet
werden. Zwar kann das Abbild einer Unterschrift elektronisch dargestellt werden, es muß aber
zusätzlich eine Bindung zwischen Unterschrift und Dokument bestehen. Andernfalls könnten
sehr leicht Kopien des elektronischen Abbildes angefertigt und diese anderen Dokumenten
zugeordnet werden.
Eine digitale Signatur muß daher über die folgenden Eigenschaften verfügen [Kelm98]:
· Abhängigkeit sowohl von Dokument und Unterzeichner.
· Ausschließlich der autorisierte Benutzer kann Signatur leisten.
· Die Korrektheit der Signatur kann von jedem Benutzer überprüft werden.
Mit asymmetrischen Verschlüsselungsverfahren kann eine digitale Signatur realisiert werden.
Ein Dokument wird mit dem privaten Schlüssel des Unterzeichners verschlüsselt. Da nur der
Unterzeichner über diesen Schlüssel verfügt, kann ausschließlich dieser die Verschlüsselung
durchführen. Das verschlüsselte Dokument kann anhand des öffentlichen Schlüssels ent-
schlüsselt werden. Da jeder Benutzer Zugriff auf die öffentlichen Schlüssel erhält, kann die
10
Grundlagen
Unterschrift von allen Teilnehmern nachgeprüft werden. Die Signatur ist das Ergebnis einer
Verschlüsselung des ursprünglichen Dokuments, und daher unmittelbar von diesem abhängig.
Im Folgenden sind eine Reihe von Algorithmen aufgeführt, die sich für die Durchführung ei-
ner digitalen Signatur eignen [Schn96]:
· RSA-Verfahren: Beim RSA-Verfahren sind die Algorithmen für die Verschlüsselung
und Entschlüsselung bis auf die verwendeten Exponenten gleich. Bei einer digitalen
Signatur wird daher für die Verschlüsselung der private und für die Entschlüsselung
der öffentliche Exponent verwendet.
· ElGamal Verfahren: Das Signaturverfahren nach ElGamal beruht wie das gleichnami-
ge Verschlüsselungsverfahren auf dem diskreten Logarithmus; Verschlüsselung und di-
gitale Signatur werden jedoch mit unterschiedlichen Algorithmen durchgeführt.
· Digital Signature Algorithm (DSA): DSA ist ein reines Signaturverfahren und kann
nicht zur Verschlüsselung oder Schlüsselverteilung benutzt werden. Es ist aus einer
Modifikation des ElGamal-Verfahrens entstanden.
2.2.2
Digitale Signatur mit dem RSA-Verfahren
Eine Signatur nach dem RSA-Verfahren berechnet sich wie folgt [Swo97a]:
Die Prüfung der Signatur erfolgt gemäß der Gleichung:
Wie in Abschnitt 2.1.2 Anwendung des RSA-Verfahrens gezeigt wurde, ist die Verwendung
des RSA-Algorithmus bei langen Nachrichten ineffektiv. Aus diesem Grund wird nicht die
Nachricht selbst, sondern ein aus der Nachricht abgeleiteter Hashwert signiert. Mit Hilfe von
Einweg-Hashfunktionen wird eine Nachricht beliebiger Länge in einen Hashwert mit definier-
ter Länge (z.B. 128 Bit) transformiert. Eine Einweg-Hashfunktion zeichnet sich durch die fol-
genden Merkmale aus [Schn96]:
· Es ist leicht, aus einer gegebenen Nachricht einen Hashwert zu berechnen.
· Es ist schwer, aus einem gegebenen Hashwert eine passende Nachricht zu berechnen.
· Zu einer Nachricht ist es schwer, eine weitere Nachricht zu finden, die den gleichen
Hashwert besitzt.
Die bekanntesten Einweg-Hashfunktionen sind [Schn96]:
· MD5 (Message Digest) entwickelt von Ronald Rivest, erzeugt 128 Bit Hashwerte.
· SHA (Secure Hash Algorithm) im Zusammenhang mit dem DSA-Verfahren entwickelt
worden. SHA erzeugt einen 160 Bit langen Hashwert.
Abbildung 2.1 zeigt die Übertragung einer signierten Nachricht mit anschließender Verifikati-
on der Signatur. Dabei steht H(x) für eine gewählte Einweg-Hashfunktion.
s
m
d
)
mod n
(
=
s
e
( )
mod n
m
d
(
)
e
mod n
m
=
=
?
Zertifizierung
11
Abb. 2.1 Digitale Signatur mit Einweg-Hashfunktion und RSA-Verfahren
Aus der Abbildung wird ersichtlich, daß die Originalnachricht und der signierte Hashwert
übertragen werden müssen. Aufgrund der Forderungen an eine Einweg-Hashfunktion stellt
dies keine Einschränkung der Sicherheit dar: Es ist für den Empfänger praktisch unmöglich,
eine andere sinnvolle Nachricht zu erzeugen, für die die Signatur übereinstimmt [Beu96].
Asymmetrische Kryptosysteme stellen zwar die grundsätzlichen Methoden für eine digitale
Signatur bereit, zusätzlich müssen jedoch Protokolle angewandt werden, die einen sinnvollen
Einsatz der Signatur gewähren.
2.3 Zertifizierung
Mit Hilfe von Zertifikaten wird eine Bindung zwischen Benutzer und öffentlichem Schlüssel
erreicht. Da in einem verteilten System der Betrieb einer einzigen Zertifizierungsinstanz im
allgemeinen nicht ausreicht, muß eine Infrastruktur von Zertifizierungsinstanzen aufgebaut
werden.
2.3.1
Zertifikate
In einem asymmetrischen Kryptosystem besteht generell keine eindeutige Bindung zwischen
einem öffentlichen Schlüssel und dem jeweiligen Benutzer [KeLi96]. Gerade diese Tatsache
stellt die Verwendung einer digitalen Signatur in Frage. Eine Signatur, deren Herkunft nicht
eindeutig bestimmt werden kann, entspricht nicht den Forderungen, die an eine elektronische
Unterschrift gestellt worden sind (siehe Kapitel 2.2 Digitale Signatur). Aus diesem Grund
werden Zertifikate eingeführt:
Unter einem Zertifikat versteht man ein überprüfbares, öffentliches Dokument, das Informa-
tionen über seinen Besitzer, seinen öffentlichen Schlüssel und weitere Verwaltungsinformatio-
nen enthält und das von einer vertrauenswürdigen Institution (Zertifizierungsinstanz)
unterschrieben ist [Schä95].
Nachricht m
h
H m
( )
=
Sender
h'
s
e
( )
mod n
=
h'
h
=
?
Empfänger
berechnet den
Hashwert h
Nachricht m
h
H m
( )
=
s
h
d
)
mod n
(
=
errechnet di
e
Signatur mit
m
s
berechnet den
Hashwert h
verifiziert die
Signatur mit
dem privaten
Exponenten d
dem öffentlichen
Exponenten e
12
Grundlagen
Anhand eines Zertifikats kann die Schlüssel-Benutzerzugehörigkeit nachgewiesen werden.
Die Zertifizierungsinstanz, die für die Ausstellung des Zertifikats verantwortlich ist, garantiert
mit ihrer digitalen Signatur für die Authentizität des Zertifikats. Jeder Teilnehmer, der über
den authentischen öffentlichen Schlüssel der Zertifizierungsinstanz verfügt, kann die öffentli-
chen Schlüssel, die in den Zertifikaten enthalten sind, für authentisch anerkennen und so eine
vertrauliche und authentische Kommunikation mit den anderen Teilnehmern aufbauen
[Rul93]. Die Zertifizierungsinstanz generiert im Allgemeinen keine Schlüssel, sondern bestä-
tigt nur die Echtheit und Zugehörigkeit eines öffentlichen Schlüssels zu seinem Besitzer. Für
eine authentische Kommunikation sind daher weitere Instanzen für die Schlüsselgenerierung
und die Schlüssel- bzw. Zertifikatsverteilung notwendig. Die Gesamtheit eines solchen Sy-
stems wird als Trust Center bezeichnet. In Abbildung 2.2 ist die Kommunikation zweier Teil-
nehmer in einem System mit Trust Center dargestellt.
Abb. 2.2 Verifikation einer digitalen Signatur in einem System mit Trust Center
2.3.2
Public-Key-Infrastruktur
Wie Abbildung 2.2 zeigt, ist die Verifikation einer Signatur bei einer einzigen Zertifizierungs-
instanz einfach zu lösen. Problematisch wird es, wenn zwei Teilnehmer miteinander kommu-
nizieren wollen, die Zertifikate von unterschiedlichen Trust Centern besitzen. So kann ein
Teilnehmer zum Beispiel ein fiktives Trust Center erzeugen, sich selbst ein Zertifikat ausstel-
len und seinem Kommunikationsteilnehmer eine beliebige Identität vortäuschen. Auch wenn
beide Teilnehmer über rechtmäßige Zertifikate verfügen, ist es unter Umständen nicht leicht,
die Rechtmäßigkeit der Zertifikate nachzuprüfen, beispielsweise, wenn beide Trust Center in
unterschiedlichen Ländern angesiedelt sind [Sta95].
Sender A
Trust Center
Empfänger B
Zert(A,E
A,
s(D
T
))
Zert(B,E
B,
s(D
T
))
m, s(m, D
A
)
Zert A?
D
A
D
T
E
T
E
T
D
B
Zert(A,E
A,
s(D
T
))
Empfänger
- prüft Zert(A,E
A,
s(D
T
)) mi E
T
-
prüft m, s(m,D
A
) mit E
A
D
x
E
x
T
privater Schlüssel von X
öffentlicher Schlüssel von X
m
s(m, D
X
)
Nachricht
Signatur der Nachricht
Zert(X,E
X
,s(D
Y
)) Zertifikat von X mit öffentlichen
Schlüssel E
x
ausgestellt von Y
Zertifizierung
13
Das Problem kann durch eine Cross-Zertifizierung oder durch eine hierarchische Zertifizie-
rung gelöst werden. Bei der Cross-Zertifizierung zertifizieren zwei Trust Center gegenseitig
ihre öffentlichen Schlüssel. Abbildung 2.3 zeigt die Kommunikation zweier Teilnehmer bei
diesem Konzept.
Abb. 2.3 Kommunikation bei einer Cross-Zertifizierung zweier Trust Center
Einer Cross-Zertifizierung geht eine eingehende Prüfung von beiden Seiten voraus. Schließ-
lich garantiert das Trust Center mit einer Cross-Zertifizierung seinen Teilnehmern die Vertrau-
enswürdigkeit des anderen Trust Centers. Zwei Teilnehmer unterschiedlicher Trust Center
können jetzt ihre Zertifikate prüfen, indem sie sich zunächst bei ihrem Trust Center das Cross-
Zertifikat des anderen Trust Centers besorgen. Dieses Zertifikat enthält den öffentlichen
Schlüssel des anderen Trust Centers. Anhand dieses Schlüssels kann nun das Zertifikat des
Kommunikationspartners überprüft werden.
Eine stärkere Bindung zwischen den Trust Centern wird durch eine hierarchische Infrastruktur
erreicht. Entgegen einer Prüfung, wie sie bei einer Cross-Zertifizierung erfolgen muß, müssen
sich alle untergeordneten Trust Center in einem hierarchischen System an die gleichen Richt-
linien halten. Auf diese Weise entsteht eine einheitliche Sicherheitspolitik in der gesamten In-
frastruktur. Abbildung 2.4 zeigt eine hierarchische Trust-Center-Infrastruktur. Das Wurzel-
Trust Center zertifiziert die direkt untergeordneten Trust Center. Jedes Trust Center kann
ebenfalls wieder weitere Trust Center zertifizieren. Wollen zwei Teilnehmer kommunizieren,
so müssen sie sich zunächst das Wurzelzertifikat besorgen. Anhand dieses Zertifikats können
sie die untergeordneten Trust Center verifizieren, bis sie zu dem Trust Center des beteiligten
Kommunikationspartners kommen [Schn96].
Sender A
Trust Center TB
Empfänger B
Zert(B,E
B
,s(D
TB
))
Zert(TA,E
TA
,s(D
TB
))
m, s(m,D
A
)
D
A
D
TB
E
TA
E
TB
D
B
Trust Center TA
Zert(A,E
A,
s(D
TA
))
Zert(TB,E
TB
,s(D
TA
))
D
TA
Crosszertifikate
Zert A?
Zert(A,E
A
,s(D
TA
))
Zert TA?
Zert(TA,E
TA
,s(D
TB
))
Empfänger
- prüft Zert(TA,ET
A
,s(D
TB
)) mit E
TB
- prüft Zert(A,E
A
,s(D
TA
)) mit E
TA
-
prüft m, s(m,D
A
) mit E
A
14
Grundlagen
Abb. 2.4 Hierarchische Trust-Center-Infrastruktur
Nachteil der hierarchischen Infrastruktur ist, daß bei jeder Kommunikation eine Reihe von
Zertifikaten überprüft werden muß. Der Vorteil gegenüber Cross-Zertifizierung besteht jedoch
in der geringeren Anzahl an Zertifikaten, die für die gegenseitige Kontrolle ausgestellt werden
müssen. Ein System, das nur Cross-Zertifikate verwendet, benötigt für N vollständig gegen-
seitig zertifizierte Trust Center n Zertifikate, gemäß der folgenden Gleichung:
Die Anzahl der Cross-Zertifikate steigt daher quadratisch mit der Anzahl der Trust Center.
Das hierarchische System benötigt für jedes Trust Center nur ein einziges Zertifikat des über-
geordneten Trust Centers; hier steigt die Anzahl der Zertifizierungen linear.
Der Einsatz einer Mischform beider Konzepte ist sinnvoll. So ist zum Beispiel generell der
hierarchische Ansatz zum Aufbau einer geeigneten Infrastruktur zu wählen. Instanzen, die
häufig miteinander kommunizieren, können zusätzlich eine Cross-Zertifizierung betreiben
[Ham95].
2.3.3
Standardisierung nach X.509
Ende der achtziger Jahre ist von dem Comité Consultatif International Télégraphique et Télé-
phonique (das CCITT läuft heute unter der Bezeichnung ITU - International Telecommunica-
tion Union) ein Standard für Authentifizierung in verteilten Systemen unter der Bezeichnung
X.509 verabschiedet worden. Dieser Standard beschreibt neben verschiedenen Authentifizie-
rungsprotokollen den Einsatz und das Format von Zertifikaten. Der Standard ist von der Inter-
national Organisation for Standardization (ISO) übernommen worden. 1993 und 1997 ist der
Standard überarbeitet und erweitert worden. Die aktuelle, dritte Version des Standards läuft
unter der Bezeichnung ISO/IEC 9594-8:1997.
Im folgenden wird der Aufbau eines Zertifikats gemäß dem Standard X.509 betrachtet.
Wurzel Trust Center TW
Zert(TA,E
TA
,s(D
TW
))
Zert(TB,E
TB
,s(D
TW
))
Trust Center TA
Zert(A,E
A
,s(D
TA
))
Trust Center TB
Zert(B,E
B
,s(D
TB
))
Teilnehmer A
Teilnehmer B
n
N N
1
(
)
=
Zertifizierung
15
Abb. 2.5 Felder eines X.509-Zertifikats
In Abbildung 2.5 sind die einzelnen Felder eines Zertifikats schematisch dargestellt. Das erste
Feld bezeichnet die Versionsnummer des Standards. Die Seriennummer dient zur eindeutigen
Identifikation eines Zertifikats innerhalb einer Zertifizierungsinstanz. Der Algorithmenbe-
zeichner weist auf die bei der Signatur verwendeten Algorithmen hin (Einweg-Hashfunktion,
Signaturalgorithmus, evtl. zusätzliche Parameter). Im Feld Aussteller ist der Name der Zerti-
fizierungsinstanz eingetragen, die das Zertifikat erzeugt und signiert hat. Die Gültigkeit be-
steht aus zwei Terminen. Der erste Termin beschreibt den ersten Tag der Gültigkeit und der
zweite Termin den letzten Tag der Gültigkeit. Das Benutzerfeld enthält Namen und weitere
Beschreibungsmerkmale des Benutzers. Anschließend ist der öffentliche Schlüssel des Teil-
nehmers eingetragen: Auf eine Beschreibung des Algorithmus, für den der Schlüssel gültig ist
und eventuell zusätzlich benötigte Parameter folgen die Komponenten des Schlüssels.
Für den Namen der Zertifizierungsinstanz sowie den Benutzernamen wird gemäß dem Stan-
dard CCITT X.500 ein sogenannter Distinguished Name vergeben [X500]. Mit diesem Na-
men kann ein Teilnehmer eindeutig identifiziert werden, da der Name aus dem Abbild einer
Verzeichnisstruktur (Baumstruktur) gebildet wird (siehe Abbildung 2.6). Ausgehend von einer
Wurzel erhalten Namen zunächst eine Länderkennung. Darauf folgt eine Staatenkennung,
Ortskennung, Postanschrift oder Firmenanschrift. Zusätzlich können Attribute wie Titel, Be-
schreibungen, Telefonnummern, etc. eingetragen werden. Die einzelnen Namensattribute wer-
den ausführlich im CCITT-Standard X.520 beschrieben [X520].
Version
Seriennummer
Algorithmenbezeichner
Aussteller
Geltungsdauer
Benutzer
öffentlicher Schlüssel des
Benutzers
Signatur
16
Grundlagen
Abb. 2.6 Distinguished Name gemäß X.500
Die Signatur des Zertifikats erfolgt über alle Einträge des Zertifikats und wird dem Zertifikat
hinzugefügt.
Das Zertifikat ist in der Abstract Syntax Notation One (ASN.1) beschrieben, die ebenfalls
durch das CCITT unter der Bezeichnung X.208 standardisiert worden ist [X208]. ASN.1 ist
als eine universelle Beschreibungssprache für Kommunikationsprotokolle entwickelt worden.
Aufgrund ihrer Kodierungsregeln können Objekte, die in ASN.1 beschrieben werden, auch in
kodierter Form übertragen und gespeichert werden [GoSp88]. Der CCITT-Standard X.209 de-
finiert die Basic Encoding Rules (BER), die eine bitweise Darstellung der ASN.1 Syntax be-
schreiben [X209]. Neben Standardtypen wie Integer, Boolean, Bit-String und Octet-String
können auch benutzerdefinierte Objekte erzeugt werden. Eine Reihe von Objekten sind inzwi-
schen standardisiert worden. Diese werden durch Objektbezeichner definiert, welche eindeu-
tig aus dem Registrierungsbaum abgeleitet werden. Abbildung 2.7 zeigt einen Ausschnitt aus
dem Registrierungsbaum [GoSp88].
Abb. 2.7 Registrierungsbaum
Gemäß diesem Registrierungsbaum sind auch die Namensattribute Country, Locality, Com-
monName, etc., sowie die übrigen Felder des Zertifikats definiert, sofern sie nicht durch einen
ASN.1 Standardtyp dargestellt werden können.
US
DE
FR
Country C
Massachusetts
Bayern
Boston
MIT
München
LMU
TUM
LDV
Sabine Musterfrau
StateOrProvince SP
Locality L
Organisation O
Organizational Unit OU
CommonName CN
C=DE
SP=Bayern
L=München
O=TUM
OU=LDV
CN=Sabine Musterfrau
root
ccitt
iso
joint-iso-ccitt
0
1
2
Zertifizierung
17
Der Standard definiert weiterhin den Einsatz von Widerrufslisten. Sofern ein Zertifikat vor
Ablauf der Gültigkeit gesperrt werden muß, wird die Seriennummer zusammen mit dem Ter-
min des Widerrufs in eine Widerrufsliste eingetragen.
Abb. 2.8 Aufbau einer Widerrufsliste
Der Aufbau einer Widerrufsliste ist in Abbildung 2.8 dargestellt. Eine Widerrufsliste enthält
die Versionsnummer des Standards, einen Bezeichner für den Signaturalgorithmus, Name des
Ausstellers sowie eine Liste mit den Seriennummern und Widerrufsterminen der gesperrten
Zertifikate. Die Gültigkeit einer Widerrufsliste wird durch die Eintragung von zwei Terminen
bestimmt. Der erste Termin entspricht dem Datum der Ausstellung, der zweite Termin kündigt
die nächste Veröffentlichung der Widerrufsliste an. Das Datum der nächsten Veröffentlichung
ist gemäß dem Standard optional. In [PKIX98c] wird die Verwendung dieses Feldes dringend
empfohlen, da so die Gültigkeit der Widerrufsliste bestimmt und ein Ausbleiben der Wider-
rufsliste erkannt werden kann. Für die Authentizität und eine nachweisbare Integrität der Wi-
derrufsliste sorgt die digitale Signatur der Zertifizierungsinstanz.
Mit der ersten Erweiterung des X.509-Standards sind die Basic Encoding Rules spezialisiert
worden und unter der Bezeichnung Distinguished Encoding Rules for ASN.1 (DER) dem
Standard hinzugefügt worden. Die Kodierung gemäß DER erfolgt nach strengeren, eindeuti-
gen Regeln. Auf diese Weise wird garantiert, daß für jedes Zertifikat eine eindeutige Kodie-
rung existiert und die Verifikation der Signatur durch verschiedene Instanzen von den gleichen
Voraussetzungen ausgeht.
Außerdem ist das Zertifikat um zwei optionale Felder erweitert worden [Bra97]. Diese beiden
Felder IssuerUniqueIdentifier und SubjectUniqueIdentifier dienen zur näheren Beschreibung
des Ausstellers, bzw. Teilnehmers und erlauben als Unterscheidungsmerkmal eine Wieder-,
bzw. Mehrfachverwendung eines Distinguished Names. Nach [PKIX98c] sollten diese Erwei-
terungen nicht verwendet werden und ein Distinguished Name nicht mehrfach verwendet wer-
den.
Version
Algorithmenbezeichner
Ausstellername
Ausstelldatum
nächste Veröffentlichung
Seriennummer, Datum
Seriennummer, Datum
Seriennummer, Datum
...
Signatur
Ende der Leseprobe aus 109 Seiten
- nach oben
Details
- Arbeit zitieren
- , 1998, Entwurf und Realisierung eines Trust Centers, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/221774
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare