Kapitel 1: Inhalt 1

INHALTSVERZEICHNIS
1 INHALT

*
2 ZERTIFIKATE*

2.1 Funktionsweise Zertifikaten*
2.2 Probleme mit Zertifikaten*
2.2.1 Fälschungsproblem*
2.2.2 Mißbrauch von Zertifikaten*

3 X.509 V3*

3.1 Aufbau des Zertifikates nach X.509 v3*
3.2 Zertifikation und Vertrauenshierarchie*
3.2.1 Vertrauenshierarchie nach PEM*
3.2.2 Dezentrale Struktur für IPKI*
3.3 WiderrufeneZertifikate (Certificate Revocation)*
3.3.1 Die CRL v2*
3.3.2 Grenzen dieser Widerrufungsmethode*
3.4 Nachteile von X.509*

4 SPKI (SIMPLE PUBLIC KEY INFRASTRUCTURE)*

4.1 Grundlagen*
4.1.1 Ausgangsposition*
4.1.2 Begriffserklärung*
4.1.3 Bindungen*
4.1.4 Ceritificate Revocation Lists*
4.1.5 Doppelte Unterschriften*
4.2 Aufbau eines SPKI-Zerifikates*
4.2.1 Komplexe Zertifizierungsprogramme*
4.3 Das Autoritätsfeld*
4.3.1 Gültigkeit*
4.3.2 Unterschriftenformate*

5 SDSI (SIMPLE DISTRIBUTED SECURITY INFRASTRUCTURE)*

5.1 SDSI Einführung*
5.2 Zertifikatsstruktur*
5.3 Standard SDSI Objekte*
5.3.1 Schlüssel und Verschlüsselungsparameter:*
5.3.2 Benutzer repräsentiert durch öffentliche Schlüssel*
5.3.3 Codierte Objekte*
5.3.4 Unterschriebene Objekte*
5.3.5 Lokale Namen, Zertifikate und Namen/Werte Bindungen*
5.3.6 Protokolle*
5.3.7 Gruppen und ACL's*
5.3.8 Anwendung*

6 UNTERSCHIEDE X.509, SDSI, SPKI*

6.1 Fazit*

7 ZERTIFIKATE IN DER PRAXIS*

7.1 SET*
7.1.1 X.509 Zertifikat Definition:*
7.1.2 Standard Extensions in SET*
7.1.3 SET Private Extensions*
7.1.4 Certificate Revocation List and BrandCRLIdentifier*
7.2 SSL*
7.2.1 Das SSL Protokoll*
7.2.2 SSL Handshake Protokoll im Detail*
7.2.3 Besonderheiten für SSL*
7.3 PRIVATE COMMUNICATION TECHNOLOGY PROTOCOL (Version 1)*
7.3.1 PCT HANDSHAKE PROTOCOL*
7.3.2 NACHRICHTEN IM DETAIL*
7.3.3 Zusammenfassung*
7.3.4 ZERTIFIKATTYPEN IN PCT*
7.3.5 Unterschiede zwischen PCT und SSL*

8 LITERATUR*

1 Inhalt

Wie allgemein bekannt bietet das Internet enorme wirtschaftliche Möglichkeiten, die zur Zeit ungenutzt sind. Der Grund ist nicht sosehr die mangelnden Akzeptanz dieses relativ jungen Mediums, sondern vielmehr die Angst vor Mißbrauch und Betrug.

In dieser Seminararbeit wird ein Mittel dargestellt, das durchaus in der Lage ist, die Möglichkeiten zum Mißbrauch und Betrug auf ein akzeptables Maß zu reduzieren. Dieses Mittel nennt sich Vertrauens-Management mit Zertifikaten.

Da es in diesem Bereich zur Zeit viele Entwicklungen mit unterschiedlichen Ansatzpunkten gibt, wird nach einer kurzen Einführung der weitverbreitete Standard X.509 in der Version 3 vorgestellt. Besonders wird hier auf eine gerade in der Entwicklung stehende, dezentrale  Vertrauensstrukturen eingegangen.

Danach werden zwei Neuentwicklungen behandelt, die durchaus den bestehenden X.509-Standard verdrängen könnten. Hierbei handelt es sich um Simple Public Key Infrastructure (SPKI) und Simple Distributed Security Infrastructure (SDSI). Außerdem werden die Unterschiede zu X.509 aufgezeigt.

Zum Abschluß werden drei praktische Anwendungen für X.509-Zertifikate beschrieben. Es handelt sich um:

1. Secure Electronic Transaction (SET): Eine offene Spezifikation für Kreditkartenzahlungen.

2. Secure Socket Layer (SSL): Eine applikationsunabhängige Sicherheitslösung.

3. Private Communication Technology Protocol (PCT): Ein neues SSL-kompatibles Protokoll.

Natürlich kann diese Arbeit in keinem Fall alle Einzelheiten oder alle neuen Entwicklungen behandeln, da dies sicherlich den Umfang um ein Vielfaches sprängen würde. Darum wird hier versucht eine Auswahl der wichtigsten Element zu treffen, die es ermöglicht, die Vor- und Nachteile des jeweiligen Konzepts zu erkennen.

2 Zertifikate

Das Internet stammt aus dem akademischen Bereich. 1969 wurden die Grundsteine dafür von den Universitäten UCLA, Stantford Research Institute, UC Santa Barbara und der University of Utah gelegt. Es wurde dazu konzipiert möglichst vielen Interessierten in einfacher Weise Zugang zu Datenbanken, Bibliotheken und anderen Informationsquellen zu bieten. Aus diesem Anwendungsprofil kann man sehr leicht erkennen, daß Datenschutz und Datensicherheit nicht zum Kernbereich des Internet zählte. Doch als das Internet nicht mehr nur den Universitäten vorbehalten war und immer schneller wuchs, wollte man auch sensible Daten über das Netz versenden. Beispiele dafür sind Telebanking und Teleshopping.

Zur Sicherung der Daten gegen Unbefugte wird symmetrische- und asymmetrische Kryptokraphie eingesetzt. Doch Verschlüsselung alleine kann nicht alle Probleme lösen.

Wie kann man beweisen, daß man einen Auftrag über zum Beispiel E-Mail erhalten hat?

Wie kann man sicherstellen, daß man wirklich den richtigen öffentlichen Schlüssel einer Person hat?

Diese Fragen der Übertragungssicherheit und der Rechtssicherheit werden normalerweise durch amtliche Ausweise und Unterschriften gelöst. Das Problem ist nun wie man diese Objekte auf das Internet übertragen kann. Die Lösung dafür sind Zertifikate.

    2.1 Funktionsweise Zertifikaten

Ein Zertifikat funktioniert wie ein amtlicher Ausweis. Ein Beispiel ist der Reisepaß. Mit dem Dokument Reisepaß ist das Recht verbunden in bestimmte Länder einreisen zu dürfen. Das Dokument enthält den Namen des Inhabers, ein Foto des Inhabers, die Unterschrift des Inhabers, einen Gültigkeitsvermerk der ausstellenden Behörde und viele weitere Daten. So kann jeder erkennen, wem dieser Ausweis gehört, und wem das damit verbundene Recht zusteht. Wichtig dabei ist, daß dieses Recht unverwechselbar mit einer bestimmten Person verbunden ist. Außerdem geht man davon aus, daß es relativ schwierig ist einen Ausweis zu fälschen. Daher wird ein gültiger Ausweis in unserem Rechtssystem als ausreichend zur Identifikation von Personen angesehen.

Abstrahiert man diesen Gedanken, kommt man zum Ergebnis, daß ein Ausweis ein Recht bzw. eine Identität  mit einer Person verbindet.

Soll nun ein Zertifikat die Funktion eines Ausweises übernehmen, muß es dieselben Punkte erfüllen. Eine autorisierte Stelle muß bestätigen, daß die Angaben im Zertifikat korrekt sind. Ist es nun möglich so ein Zertifikat in digitaler Form fälschungssicher zu erstellen, kann man einen öffentlichen Schlüssel - und damit auch eine digitale Unterschrift - mit einer Person verbinden.

    2.2 Probleme mit Zertifikaten

Natürlich gibt es bei der Verwendung digitaler Zertifikate auch einige Probleme. Diese lassen sich sehr leicht darstellen, wenn man wieder von einem normalen Ausweis wie dem Reisepaß ausgeht.

        2.2.1 Fälschungsproblem

Das Fälschungsproblem wird es immer geben, wenn der Nutzen größer als der Aufwand ist. Da es unmöglich ist den Idealfall der absoluten Fälschungssicherheit zu erreichen, muß versucht werden den Aufwand, der zur Fälschung nötig ist so hoch zu machen, daß es sich nicht mehr auszahlt.

Bei Reisepässen wird das durch Spezialpapier, Spezialdruck ,Wasserzeichen und vieles mehr erreicht. Diese Funktion erfüllt bei Zertifikaten die digitale Unterschrift der autorisierten Stelle.

        2.2.2 Mißbrauch von Zertifikaten

Was passiert, wenn sich ein Inhaber eines gültigen Zertifikats entschließt dieses für kriminelle Handlungen (Betrug, Diebstahl ) zu verwenden? Dieses Problem tritt auch bei Reisepässen auf. Zum Beispiel möchte ein Täter mit seinem gültigen Reisepaß das Land verlassen und sich der Bestrafung entziehen.

Bei Reisepässen wird versucht dieses Problem mit zwei Mechanismen zu bekämpfen.

1. Die Gültigkeitsdauer jedes Reisepasses ist begrenzt.

2. An den Staatsgrenzen werden die Reisepässe der Ausreisenden mit den Einträgen einer Datenbank verglichen, in der die Daten der Kriminellen gespeichert sind.

Natürlich besteht bei Zertifikaten auch die Möglichkeit diese Mechanismen anzuwenden. Außerdem könnte man die Gültigkeitsdauer der Zertifikate relativ kurz ansetzen, da die Ausstellung neuer Zertifikate, jederzeit und für den Benutzer unsichtbar  geschehen könnte (Key Pair Update). Eine Datenbank mit Einträgen der von Kriminellen benutzten Zertifikate (CRL-Certificate Revocation List) bereitet bedeutend größere Schwierigkeiten. Diese Datenbank müßte zentral verwaltet werden und bei der stark steigenden Verwendung von Zertifikaten, Unmengen an Daten beinhalten.

3 X.509 v3

1988 gab die CCITT eine Empfehlung [CCITT88] für die Verwendung von X.509 heraus. Sie beschreibt den Aufbau von Zertifikaten. Diese Zertifikate wurden dafür entwickelt, in X.500 Verzeichnissen zu arbeiten, sind aber so allgemein gehalten, daß sie auch darüber hinaus verwendet werden können.

X.509 ist zur Zeit in der Version 3 vorhanden und wurde von ANSI und ISO übernommen. Es ist zur Zeit der verbreitetste Standard.

    3.1 Aufbau des Zertifikates nach X.509 v3

Wie schon im Kapitel über Zertifikate beschrieben, muß ein Zertifikat mindestens folgende Daten enthalten:

Inhaber

öffentlichen Schlüssel des Inhabers

Gültigkeitsvermerk einer autorisierten Stelle

Somit wird von einer autorisierten Stelle, der Zertifizierungsstelle (CA-Certification Agency) bestätigt, daß ein öffentliche Schlüssel einem bestimmten Inhaber zugeordnet ist.

Natürlich sind, wie auch bei einem Reisepaß noch viele zusätzliche Informationen nötig. Das Format des X.509-Zertifikats ist in Abbildung 1 dargestellt.

Erklärung der Felder:
Version: Identifiziert die Version von X.509 die diesem Zertifikat zugrunde liegt. Zur Zeit gibt es drei Versionen (v1 - v3) von X.509-Zertifikaten. Diese Information ist wichtig, da sie den Inhalt des Feldes Extensions festlegt.
Serial Number: Die Zertifizierungsstelle (CA-Certification Authority) weist dem Zertifikat diese Nummer zu. Sie muß für jedes Zertifikat einer CA einmalig sein, da sie für die Widerrufung von Zertifikaten (Certificate Revocation) verwendet wird.
Signature: Verweist auf den verwendeten Algorithmus, den der Aussteller zum Unterschreiben verwendet. Dies ist wichtig, da X.509 nicht von einem bestimmten Algorithmus abhängig ist. Einige dieser Algorithmen sind zum Beispiel RSA, Diffie-Hellman und DSA.
Issuer: Identifiziert den Aussteller des Zertifikats. Dies ist die CA, die das Zertifikat unterschrieben hat.
Validity: Beinhaltet die Gültigkeitsdauer. Hier sollte UTC (Greenwich-Zeit) und keine lokale Zeit verwendet werden, da die Zertifikate  weltweit, und damit in verschiedenen Zeitzonen verwendet werden.
Subject Name: Enthält den Namen der Person,  mit der der öffentlichen Schlüssel im Zertifikat verbunden ist. Hier ist  besonders wichtig, daß das Prinzip des Distinguished Name eingehalten wird. Dies bedeutet, daß nicht mehrere Personen exakt den selben Namen verwenden dürfen. Dies ist eine sehr große Einschränkung, die erheblichen Koordinationsaufwand erfordert.
Subject PublikKeyInfo: Beinhaltet den wichtigsten Teil des Zertifikats, nämlich den Öffentlicher Schlüssel des Benutzers. Außerdem wird hier wie im Feld Signature der für diesen Schlüssel verwendete Algorithmus angegeben.
Unique Identifiers: Diese Felder wurden erst mit der Zertifikatsversion 3 eingeführt. Sie wurden vorgesehen, damit die Issuer- und Subject Names später  wiederverwendet werden können. Es wird aber vorgeschlagen diese Möglichkeit  nicht zu nutzen.
Extensions: Sie wurden auch erst in der Version 3 eingeführt. Damit können zusätzliche Attribute mit der Person (Subject) verbunden werden. Es gibt Standard Extensions aber auch Private Extensions, die letzteren können beliebige Informationen enthalten. Extensions sind außerdem kritisch oder nicht-kritisch. Wobei ein Zertifikat das eine kritische Extension hat, deren Bedeutung man nicht kennt, nicht akzeptiert werden darf.
Wichtige Standard Extensions Felder:
Certificate Policies: Beinhaltet die Konditionen unter denen die CA arbeitet (z.B. Sicherheitsvorkehrungen bei der Zertifizierung ). Dies soll Applikationen ermöglichen, anhand einer Vergleichsliste zu entscheiden, ob ein Zertifikat den geforderten Sicherheitsanforderungen entspricht, oder zurückgewiesen werden soll.
CRL Distribution Points: Bezeichnet den Punkt (IP-Adresse) wo Information über widerrufene Zertifikate (die CRL) der für dieses Zertifikat zuständigen Zertifizierungsstelle gefunden werden können.
Grund für die Einführung von Extensions:
Die Einführung von Extensions in der Zertifikatsversion 3 erweitert entscheidend die Anwendungsmöglichkeiten von X509. Hauptsächlich wurden sie eingeführt um die Unzulänglichkeiten des schon relativ alten Zertifikats, das eigentlich für den Einsatz in eine Verzeichnisstruktur nach X.500 entwickelt wurde, zu umgehen. Es ist möglich die meisten Felder des Zertifikats durch Extension-Felder zu ersetzen. Dadurch besteht aber die Gefahr, daß der Sinn von X.509 - nämlich ein einheitliches Zertifikatformat - total untergraben wird. Hier stellt sich die Frage ob nicht gleich ein neuer Zertifikat-Standard geschaffen werden sollte, der den heutigen Anforderungen entspricht.

    3.2 Zertifikation und Vertrauenshierarchie

Beim Aufbau des Zertifikats wurde immer von den Zertifizierungsstellen bzw. den CAs gesprochen. Doch bisher wurde nicht festgelegt, wer diese eigentlich sind. Der Grund dafür ist das die X.509 Spezifikationen nur auf den Aufbau des Zertifikats selbst eingehen, nicht aber auf die Anwendung im Internet. Diese wird in sogenannten RFC's (Request for Comment) beschrieben.

Allgemein müssen Zertifizierungsstellen natürlich Organisationen sein, denen man vertraut. Hier bieten sich in erster Linie öffentlich Stellen und große Unternehmen an. Außerdem muß es mehrere Zertifizierungsstellen geben, um den weltweiten Bedarf an Zertifikaten abzudecken.

Es werden hier zwei Organisationsformen für solchen Zertifizierungsstellen beschrieben.

        3.2.1 Vertrauenshierarchie nach PEM

Abbildung 2: Hierarchie vorgeschlagen von PEM

PEM (Privacy Enhancement for Internet Electronic Mail) ist ein Standard der mit dem [RFC1422] eingeführt wurde. Darin wird der Aufbau einer Vertrauenshierarchie für die Verwendung von X.509-Zertifikaten beschrieben.



PEM geht davon aus, daß es viele verschiedene CAs gibt. Natürlich kennt jeder die Digitale Unterschrift der CA, die sein eigenes Zertifikat ausgestellt hat, aber wahrscheinlich nicht alle anderen. Soll nun ein Zertifikat überprüft werden, das nicht von der eigenen CA ausgestellt wurde, muß man über zusätzliche Zertifikate eine geschlossene Kette zu der anderen CA schaffen. Diese Kette heißt: Zertifikationsweg (Certification Path). Für PEM wird eine Vertrauenshierarchie mit einem Aufbau, wie er in Abbildung 2 dargestellt wird, vorausgesetzt.

Benötigte Organisationen:
Für diese Art der Hierarchie sind folgende Organisationen vorgesehen, die verschiedenen Aufgaben zu erfüllen habe.

Internet Policy Registration Authority (IPRA): Stellt die Wurzel der Vertrauenshierarchie dar. Sie stellt nur Zertifikate für die nächste Ebene aus.
Policy Certification Authorities (PCAs): Werden von der IPRA zertifiziert. Die PCAs unterscheiden sich durch die Politik die sie vertreten. Diese Politik stellt die Konditionen dar, unter denen die PCA arbeitet. Ein wichtiger Punkt sind zum Beispiel die Sicherheitsvorkehrungen bei der Zertifizierung. Die Politik wird niedergeschrieben, publiziert und außerdem im Feld Certificate Policies jedes Zertifikates angegeben. Die Verwendung von verschiedenen Politiken soll sicherstellen, daß sich einzelne PCAs auf bestimmte Anwendergruppen spezialisieren können. Zum Beispiel benötigen private Anwender weniger Sicherheit als Kommerzielle.
Certification Authorities (CAs): Zertifizierungsstellen, die hierarchisch in weitere CAs untergliedert werden können.

            3.2.1.1 Der Zertifikationsweg

Die Funktion des Zertifikationswegs soll hier anhand eines Beispiels erläutert werden. Diese Beispiel bezieht sich auf Abbildung 2.  

Ein End-Benutzer (A) läßt einem anderen (B) sein Zertifikat zukommen. B möchte nun die Gültigkeit dieses Zertifikats überprüfen. Das Problem ist, daß B nur der Unterschrift seiner CA (CA1) vertraut. Um nun eine Verbindung nach oben zu ermöglichen, muß die CA1 ein selbst ausgestelltes Zertifikat für die nächst höhere CA2 besitzen und B weitergeben. Dieses Zertifikat heißt Rückwärts-Zertifikat. B vertraut nun auch auf Unterschriften von CA2. Durch ein zweites Rückwärts-Zertifikat vertraut B auch der übergeordneten PCA. Die PCA besitzt ein selbst ausgestelltes Zertifikat für die CA3. Dieses nennt man Vorwärts-Zertifikat. Nun hat B einen lückenlosen Zertifikationsweg von seiner Zertifizierungsstelle (CA1) zur CA3 hergestellt, und vertraut nun auf die Gültigkeit des Zertifikats von A.

Voraussetzungen:
Jede Zertifizierungsstelle muß für alle frei verfügbar die benötigten Vorwärts- und Rückwärts-Zertifikate zur Verfügung stellen.

Vorwärts-Zertifikate: Ein Zertifikat, das von der nächst höheren Stelle für eine untergeordnete ausgestellt wurde. Diese Zertifikate ermöglichen den Zertifikationsweg nach unten.

Rückwärts-Zertifikat: Ein selbst ausgestelltes Zertifikat, das die nächst höhere Stelle ausweist. Es ermöglicht den Zertifikationsweg nach oben.

Weitere Informationen über den Zertifikationsweg finden sich im Buch "Sicherheit im Datennetz" [SID95] im Kapitel über X.509.

            3.2.1.2 Nachteile dieser hierarchischen Struktur

Die starre Struktur mit nur einer Wurzel ist für manche Zwecke zu aufwendig und eine zu große Einschränkung. Dadurch konnte sich PGP gegen PEM durchsetzen. PGP (Pretty Good Privay) beschrieben in [PGP95], ist ein frei erhältliches Programm, daß die Funktionalität von Public-Key Kryptographie für jederman anwendbar macht.

Das Konzept, daß verschiedene PCAs auch verschiedene Politiken verfolgen können, schränkt die allgemeine Aussagekraft eines Zertifikats ein. Man muß sich zuerst über den Aussteller erkundigen. Dieses Problem soll durch ein StandardExtensions-Feld von X.509 v3 behoben werden, das Informationen über die Zertifizierungspolitik enthält.  

        3.2.2 Dezentrale Struktur für IPKI

Eine alternative Organisationsform für CAs wird in IPKI (Intenet Public Key Infrastructure), einem Internet-Draft der PKIX Working Group [IPKI96], vorgestellt. Hier wird versucht die Nachteile von PEM durch eine dezentrale Struktur zu vermeiden. Wobei jede Zertifizierungsstelle ein eigenes Vertrauensnetzwerk aufbaut.

            3.2.2.1 Aufbau des Vertrauensnetzwerkes

Jede Zertifizierungsstelle verfügt über folgende Einrichtungen.

RA (Registration Authority): Diese Stelle soll der CA gewisse Managementfunktionen abnehmen. Sie ist nur bei größeren CAs notwendig.
Hinterlegungsstelle (Repository): Ein Datenbanksystem in dem Zertifikate und Widerrufungslisten (CRLs) gesammelt und den Benutzern zur Verfügung gestellt werden.

Der Aufbau einer Zertifizierungsstelle samt der benötigten Einrichtungen wird in Abbildung 3 dargestellt. In dieser Abbildung sind Verbindungen zu anderen CAs eingezeichnet. Diese Bedeuten einen Austausch von Zertifikaten. Um diesen Zertifikataustausch mit anderen CAs zu gewährleisten, wird die Methode der gegenseitigen Zertifizierung (Cross-Certification) verwendet. Hierbei stellen sich CAs gegenseitig Zertifikate aus.

Das Ergebnis dieser Struktur ist eine Annäherung an die Funktionsweise von PGP. Bei PGP ist jeder Benutzer seine eigene Zertifizierungsstelle und betreibt Zertifikataustausch mit anderen. Hier wird dieses Verfahren eine Ebene nach oben verlagert, das heißt es gibt eine Stelle die einem diese Funktionalität zur Verfügung stellt. Dadurch wird der Bereich mit dem sicher kommuniziert werden kann viel größer, aber man kann nie das Ziel erreichen, daß man jedes Zertifikat auf seine Gültigkeit überprüfen kann, wie es beim hierarchischen Ansatz der Fall ist. Trotzdem könnte sich dieses Konzept durchaus wie PGP durchsetzen.

            3.2.2.2 Kommunikation zwischen CA und Benutzer

Um ein neues Zertifikat zu erstellen, ist ein Datenaustausch zwischen dem Benutzer und der von ihm gewählten Zertifizierungsstelle notwendig. Der erste Schritt ist die Registrierung. Hierbei bewirbt sich der Benutzer bei einer CA um ein Zertifikat. Danach folgt die Initialisierung. Dabei ist wichtig, daß der Benutzer auf einem sicheren Weg den öffentlichen Schlüssel der CA bekommen. Dies stellt den gefährlichsten Punkt bei der Verwendung von Public-Key Kryptographie dar, da es relativ einfach ist den Öffentlichen Schlüssel der CA abzufangen und den eigenen an den Benutzer weiterzuleiten. Um dieser Gefahr entgegenzuwirken, wird meist der Öffentliche Schlüssel der Zertifizierungsstelle in die Zugangssoftware integriert. Der letzte Schritt ist die Zertifizierung selbst. Die CA unterschreibt das Zertifikat, das die  Zugehörigkeit eines Öffentlichen Schlüssels zu einer Person bestätigt.

Außerdem sind folgende Funktionen nötig:

Schlüsselpaarwiederherstellung (Key Pair Recovery): Das gesamte Schlüsselpaar wird bei der CA hinterlegt um im Bedarfsfall (Verlorener privater Schlüssel, Tod oder Unfall des Benutzers, ) die Informationen entschlüsseln zu können. Dies ist eine sehr heikle Sache, da auch andere (Staat, Sicherheitsbehörden) auf diese Schlüssel Zugriff haben könnten. Dies wird zur Zeit in den U.S.A. unter dem Namen Key Escrow  diskutiert. Bei Key Escrow sollen alle Benutzer ihren Privaten Schlüssel hinterlegen, um den Behörden die Möglichkeit zu Nachforschungen zu geben.

Schlüsselerneuerung (Key Pair Update): Da die Gültigkeitsdauer jedes Zertifikats beschränkt ist, muß es regelmäßig durch ein neues ersetzt werden. Es wird ein neues Schlüsselpaar generiert und daraus ein neues Zertifikat erstellt.

Widerrufung anfordern (Revocation Request): Autorisierte Personen berichten der CA von abnormalen Aktivitäten, die eine Widerrufung eines Zertifikats zur Folge haben können.

Gegenseitige Zertifizierung (Cross-Certification): Zwei CAs tauschen Informationen aus, um die Zertifikate, die der andere ausgestellt hat anzuerkennen. Dies führt dazu, daß nicht mehr unbedingt nur eine Wurzel in der Hierarchie vorhanden ist.

    3.3 Widerrufene  Zertifikate (Certificate Revocation)

Um das Problem des Mißbrauches von Zertifikaten zu bekämpfen, müssen mißbrauchte Zertifikate erkannt und für alle erkennbar widerrufen werden. Die Erkennung liegt außerhalb des Bereichs von X.509. Hier wird nur der Wiederrufungsmechanismus von mißbrauchten Zertifikaten beschrieben. Die mißbrauchten Zertifikate werden in speziellen Listen (CRLs) gesammelt. Hier bleibt jeder Eintrag solange bestehen, bis die restliche Gültigkeitsdauer des Zertifikats abgelaufen ist.

        3.3.1 Die CRL v2

Der Aufbau der Certificate Revocation List Version 2 ist in Abbildung 4 dargestellt.

Erklärung der Felder:
Version: Version der CRL.
Signature: Zum Unterschreiben verwendeter Algorithmus.
Issuer Name: Identität der Zertifizierungsstelle, die diese CRL ausgegeben hat. Jede CA ist verpflichtet eine CRL zur Verfügung zu stellen.
This Update: Zeitpunkt zu dem diese CRL ausgegeben wurde.
Next Update: Zeitpunkt zu dem eine neue CRL ausgegeben wird. Die nächste CRL kann auch früher ausgegeben werden, muß aber spätestens zu diesem Zeitpunkt erneuert werden.
Revoked Certificates: Auflistung der widerrufenen Zertifikate (Serial Numbers der Zertifikate) mit Angabe des Widerrufungszeitpunkts. Für widerrufene Zertifikate an andere CAs gibt es eine eigene Liste (ARL-Authority Revocation List).
Extensions: Hier können wie bei Zertifikaten zusätzliche Attribute mit der CRL verbunden werden.
Wichtige Extensions:
Issuing Distribution Point: Gibt an wo die CRL ausgegeben wurde und gegebenenfalls eine neuere erhältlich ist.

        3.3.2 Grenzen dieser Widerrufungsmethode

Die CRLs sind nur zum Zeitpunkt der Erstellung vollständig. Soll ein Zertifikat widerrufen werden, kann das erst bei der nächsten Ausgabe der CRL bekannt gemacht werden. Die Zeit bis eine neue CRL erstellt wird, kann einige Stunden bis zu Wochen betragen.

Es besteht das Risiko, daß die CRLs enorme Größen erreichen. Die Größe hängt von der Anzahl der Benutzer einer Zertifizierungsstelle und der Gültigkeitsdauer der ausgestellten Zertifikate ab. Je mehr Benutzer eine CA hat, und je länger die Gültigkeitsdauer der Zertifikate ist, desto mehr Einträge wird die CRL fassen müssen. Eine Abhilfe ist hier die Verwendung von ultrakurz gültigen Einmal-Zertifikaten, die man sich kurz vor der Benutzung von der CA abholt.

    3.4 Nachteile von X.509

Der wichtigste Nachteil, der auch die meisten der folgenden begründet, ist das Alter von X.509. Dieses Konzept wurde 1988 entwickelt. Seitdem haben sich die Sicherheitsanforderungen dramatisch verschärft. Es wir jetzt Funktionalität verlangt, an die damals noch nicht gedacht wurde.

Es können nur öffentliche Schlüssel an Personen gebunden werden. In manchen Fällen ist es aber nötig einfach nur eine Information an eine andere zu binden. Dafür braucht man ein allgemeines Zertifikat. Dieses Problem soll durch Private Extensions in X.509 v3 gelöst werden. Das bedingt aber, daß das X.509-Zertifikat nur noch eine Hülle ist und die gesamte Information in den Extensions steckt.

Durch all diese Probleme, soll doch daran gedacht werden, einen neuen Zertifikat-Standard einzuführen, der auf die jetzigen Anforderungen zugeschnitten ist. Vor allem muß er so konzipiert werden, daß eine Weiterentwicklung möglich ist.

4 SPKI (Simple Public Key Infrastructure)

SPKI wird zum Zeitpunkt der Erstellung dieser Arbeit noch entwickelt. Wesentlich an der Entwicklung ist Carl Ellison beteiligt. SPKI soll die den alten X.509 Standard ablösen und Zertifikate vielseitiger gestalten. Dabei wird besonderer Wert auf die Art der Autorität, die durch ein Zertifikat übertragen wird, gelegt.

    4.1 Grundlagen

Im folgenden Abschnitt sollen die Grundgedanken der Ersteller, die zur Kritik an X.509 führten und letzluch in der Schaffung eines neuen Standards resultierten aufgezeigt werden.

        4.1.1 Ausgangsposition

Der ursprüngliche Zweck eines Zertifikats ist das Binden eines öffentlichen Schlüssels an einen Benutzer. Dieser Benutzer muß seinen privaten Schlüssel geheim halten.

Weiters wird davon ausgegangen, daß nur ein öffentlicher Schlüssel einem Hashwert zugeordnet werden kann. Ohne ein zusätzliches Zertifikat ist vom Benutzer, außer seinem öffentlichen Schlüssel, nichts bekannt (wie Name, Adresse, Bild, ... ).

        4.1.2 Begriffserklärung

Autorität ist ein Benutzer bzw. sein privater Schlüssel, der gewisse Berechtigungen besitzt.

Benutzer ist eine Person, die ein Schlüsselpaar besitzt.

Subjekt ist der Benutzer eines Zertifikates, auf den Autorität übertragen wird.

        4.1.3 Bindungen

Bindungen sind nicht bidirektional. Sie können Autorität von der Realität in die virtuelle Welt transferieren oder umgekehrt.

Wenn ein Zertifikat besagt, daß zu einer E-Mail Adresse ein bestimmter Schlüssel gehört, transferiert dieses Zertifikat Autorität von der Realität in das Netzwerk. Dieses Zertifikat sollte vom Systemadministrator unterschrieben werden, der für die E-Mail Adressen verantwortlich ist und nicht wie bisher üblich vom Subjekt selbst.

Wenn ein Zertifikat besagt, daß der Benutzer, bekannt unter dem öffentlichen Schlüssel XY, unter der E-Mail Adresse Z erreichbar ist, transferiert dieses Zertifikat Autorität vom Netzwerk in die Realität und sollte von diesem Benutzer selbst unterschrieben werden. Zertifikate dieser Art sind wesentlich einfacher und sicherer.

In PGP sind die Zertifizierer nicht die Verantwortlichen für die E-mail Adressen. Zertifikate über eine Bindung einer E-Mail Adresse an einen Schlüssel dürften sie nicht ausstellen, sondern der Verantwortliche für die Adreßvergabe der E-Mail Adressen.



PCAs (Policy Certification Authoritys) erteilen Benutzern Autorität durch die Zertifizierung ihrer privaten Schlüssel. In X.509 können PCAs nicht die Richtung des Autoritätstransfers angeben. Ein Zertifikat transferiert bestimmte Autorität vom ausstellenden Schlüssel zum Subjektschlüssel. In SPKI existiert ein <auth> Feld das angibt, welche Autorität durch dieses Zertifikat übertragen wird.

        4.1.4 Ceritificate Revocation Lists

Es gibt drei verschiedene Methoden, um das Problem von Zertifikaten, die vor ihrem Ablaufen ungültig werden, zu lösen: CRLs, on-line Überprüfung oder periodische Rezertifizierung. SPKI setzt wie X.509 hauptsächlich auf CRLs. Das bedeutet daß eine Stelle die Zertifikate ausgibt eine Liste mit den Zertifikaten zur Verfügung stellen muß, die alle Zertifikate enthält, die vor ihrem Ablaufdatum ungültig geworden sind.

Damit sind jedoch große Probleme verbunden, da der Benutzer schnellen Zugriff zu diesen Daten benötigt um immer über eine möglichst aktuelle Version zu verfügen, andererseits diese Listen relativ umfangreich sind.

        4.1.5 Doppelte Unterschriften

Um das Problem von Zertifikaten zu vermeiden, die der Schlüsselhalter des Subjektschlüssels nicht will, sollten bestimmte Zertifikate vom Aussteller und vom Subjekt unterschrieben werden. Dazu verfügt SPKI über die Dual-Sig Option.

    4.2 Aufbau eines SPKI-Zerifikates

SPKI Zertifikate werden durch folgende Felder aufgebaut. Die Bezeichnungen werden bei der Datenübertragnung durch Zahlen (Tokens) ersetzt um die Übertragung effizienter zu gestalten.



SUBJECT: <alg>, <Hash>

Dieses Objekt enthält den Hash des öffentlichen Schlüssels des Anwenders auf den das Zertifikat ausgestellt ist (Subjektschlüssel) und den Hashalgorithmus.



SUBJECT-CERT: <location>

Gibt die Adresse des öffentlichen Schlüssels des Subjektes (Benutzer) an, an der auch ein selbst unterschriebenes Zertifikat des Subjekts liegen kann (ähnlich AUTO-CERT in SDSI siehe 5.3.6)



ISSUER: <alg>, <Hash>

Dieses Objekt enthält den Hash des öffentlichen Schlüssels des Ausstellers und den Hashalgorithmus.



ISSUER-CERT: <location>

Gibt die Adresse an, an der der öffentliche Schlüssel des Ausstellers ist und an der allenfalls Zertifikate vorhanden sind, um zu überprüfen, ob er berechtigt ist diese Autorität zu übertragen.



<auth>

Jedes SPKI Zertifikat enthält kein, ein oder mehrere <auth> Felder. Sie bestimmen die Art und den Zweck des Zertifikates und beschreiben den Autoritätsfluß. Die verschiedenen Einträge werden im nächsten Kapitel beschrieben.



<validity>

Gibt die Gültigkeitsdauer eines Zertifikates an. Ist keine Gültigkeitsdauer vorhanden, hängt die Gültigkeit nur von den zu Grunde liegenden Zertifikaten ab. Die einzelnen Objekte werden nachfolgend beschrieben.



<signature>

Jedes SPKI Zertifikat muß vom Aussteller unterschrieben werden. Der Aufbau wird nachfolgend beschrieben.



In der Grundstruktur des Zertifikates ist nicht der vollständige öffentliche Schlüssel des Subjekts und des Ausstellers vorhanden, sondern nur der jeweilige Hash und eine Adresse an der der vollständige Schlüssel zu finden ist.



Datenformate
Jedes mehrzeilige Objekt muß durch BEGIN - END eingeschlossen werden.

Jedes Attribut entspricht einem binären Code. Die Code Tabelle findet sich im Internet-Draft.

Zeitpunkte im Binärcode werden als 32bit Integer Wert ohne Vorzeichen angegeben. Der Wert entspricht Sekunden seit 1970-01-01.00:00:00 UTC.

Im UTF-8 Format (ASCII) können Zeitpunkte in YYYY-MM-DD.HH:MM:SS angegeben werden.

        4.2.1 Komplexe Zertifizierungsprogramme

Ein einfaches Zertifikat ist Teil einer einfachen Zertifizierungskette. Zertifikate von komplexen Zertifizierungsprogrammen wie BFL [BFL96] sind nicht mehr in einer einfachen Kette und haben daher mehrere Aussteller und Subjekte. Auch der Autoritätstransfer läßt sich nicht im <auth> Feld darstellen und kann besser durch ein <program> Feld dargestellt werden.

Für diese Zwecke sind zwei Objekte vorgesehen:

PP-PARAM: <n>, <cert Hash>, <cert location>

PP-PROG: <program Hash>, <program location>

wobei n die Zertifizierungsparameternummer angibt und <program location> die Adresse angibt, an die die Gruppe von Zertifikaten zu senden ist, um die speziellen Rechte zu erhalten.

    4.3 Das Autoritätsfeld

Die verschiedenen Einträge im Autoritätsfeld erlauben die Nutzung von SPKI Zertifikaten für unterschiedliche Zwecke. Folgende Einträge sind im Internet-Draft vorgesehen und sind durch die Benutzer beliebig erweiterbar:

May-Delegate: <deleg>
Wert, wie oft die Autorisierung übertragen werden darf. Defaultwert ist 0, das heißt sie kann nicht übertragen werden. Der Wert 255 besagt, daß sie beliebig oft übertragen werden darf.

Internet Access Control
FTP: <hostname>, <username>

TELNET: <hostname>, <username>

USER: <hostname>, <username>

Erlaubnis auf einen der Dienste (FTP, TELNET, USER) eines benannten Hosts <hostname> als User <username> zuzugreifen.

Public Key Protected File System
PKPFS://<hostname>/<path> (<access>)

Zugriff auf ein noch nicht definiertes Public Key Protected File System das im Internet-Draft vorgeschlagen wird. Das Feld <access> kann R (read), W (write), A (add) und D (delete) Zugriff enthalten.

HTTP Access
HTTP://<hostname>/<path>

Erlaubt den Zugriff auf Web Pages.

Neues <auth> Feld
AUTH: <auth-tag>, <N>, <parameters>

Das <auth-tag> Feld ist für selbst definierte Einträge, wobei <N> die nachfolgenden Parameter angibt.

SET (Secure Electronic Transaction)
Für die Erstellung von [SET] Zertifikaten in SPKI sind die in Abbildung beschriebenen Felder vorgesehen

Identity Certificates
Herkömmliche Identity Certificates passen nicht in das System von SPKI, da sie keinen definitiven Autoritätstransfer bezeichnen. Sie transferieren undefinierte Autorität vom Aussteller zum Subjekt.

Da allerdings viele CAs (Certification Authoritys) diese Zertifikate benötigen, sind sie in SPKI integriert worden.

Sie erlauben:

0. Autoritätsübergabe von einem Namen zu einem Schlüssel
1. Namenszertifikate wie in SDSI (siehe Kapitel 5)
2. PGP ähnliche Einträge wie "known to me as"
3. Zertifikate über den Aufenthaltsort (z.B. durch ein Sicherheitsbüro, etc.)
4. Transfers von Autorität vom Netzwerk in die Realität wie z.B. eine E-Mail Adresse.
Authority to spend money
SPENDING-AUTHORITY: <amount>, <kind of purchase>

Dieses Feld gibt an, daß der Benutzer von einer Stelle berechtigt worden ist, einen gewissen Betrag auszugeben. Optional kann der Zweck <kind of purchase> angegeben werden, es muß jedoch noch von Menschen interpretiert werden. Diese Option ist in SPKI nicht näher definiert und ist erst durch Anbieter aufzugreifen.

Kommentare
COMMENT: <text>

Für den Benutzer bestimmte Anmerkungen die nicht maschinell ausgewertet werden.

Gruppenzugehörigkeit
Autorisieren einer Gruppe

DELEGATE-ALL:

Erteilt einer Gruppe bestimmte Autorität

MEMBER: <group name>

NON-MEMBER <group name>

Gibt an, ob ein Subjektschlüssel (Benutzer) Mitglied einer SDSI Gruppen ist oder nicht.

        4.3.1 Gültigkeit

Das <validity> Feld kann die Gültigkeitsdauer eines Zertifikates einschränken. Ohne dieses Feld würde es nur von der Gültigkeitsdauer der Zertifikate eingeschränkt (Zertifizierungskette), von denen das Zertifikat abhängt. Hängt es von keinen Zertifikaten ab, wäre es theoretisch unendlich lange gültig.

Ablaufen von Zertifikaten
EXPIRES: <date> gibt an, wann ein Zertifikat abläuft, RENEW-LOCATION: <location> gibt die Stelle an, wo ein neues Zertifikat erhältlich ist.

VALID-TO: <date> entspricht EXPIRES und dient als Unterscheidung, wenn z.B. ein Ablauf durch EXPIRES eine kostenpflichtige Rezertifizierung nachziehen soll, VALID-TO jedoch nicht.

CRL: <duration> gibt die Gültigkeitsdauer einer Certificate Revocation List an. CRLs werden zwar in einem eigenen Format angegeben, kleine Updates könnten aber als SPKI Zertifikate verschickt werden.

[ECR] erlaubt, anhand eines verketteten Hash, die Überprüfung, ob ein Zertifikat immer nocht gültig ist oder nicht. Es ist dafür das ECR-PARAMS: Objekt vorgesehen.

Zertifikate können auch nur für eine bestimmte Session Gültigkeit behalten (z.B. Telnet Session). Das GOOD-ONLY-FOR-SESSION: <session ID> Objekt bezeichnet dabei die Session als Text String.

        4.3.2 Unterschriftenformate

Das Unterschriftenformat in SPKI beinhaltet folgende Felder:

SIGNATURE: <Hash alg>, <PK alg>, <sig value>, <body Hash>

<Hash alg> bezeichnet den Algorithmus der zur Hash Erzeugung verwendet wurde (z.B. RSA).

<PK alg> ist die Bezeichnung des Algorithmus der zur Erzeugung des öffentlichen Schlüssels verwendet wurde (z.B. SHA-1).

<sig value> ist die Unterschrift

<body Hash> ist optional und spezifiziert das unterschriebene Objekt durch seinen Hash. Ist dieses Feld nicht vorhanden, wird der vorhergehende BEGIN-END Block angenommen.



DUAL-SIG: gibt an, daß das Zertifikat erst dann gültig ist, wenn es vom Subjekt auch unterschrieben wurde.

KEY: <alg>, <fields are required by alg> gibt einen öffentlichen Schlüssel an (z.B. RSA, <e>, <N>).

5 SDSI (Simple Distributed Security Infrastructure)

SDSI ist wie SPKI ein Ansatz zur Verbesserung des alten X.509 Standards. Es wird von Ronald L. Rivest und Butler Lampson entwickelt. Es ist das Konzept das am stärksten mit dem alten Standard bricht, da es keien Certificate Revocation Lists verwendet.

Es wird bei diesem Konzept besonderer Wert auf Benutzergruppen und Vergabe von Zugriffsrechten für World Wide Web Objekte gelegt.

    5.1 SDSI Einführung

Jeder Benutzer wird durch ein einzigartiges Schlüsselpaar repräsentiert (wie bei X.509 oder SPKI). In SDSI sind alle Schlüssel gleichwertig (mit Ausnahme einzelner reservierter Schlüssel wie z.B. VeriSign!!) - das heißt, jeder kann ein Objekt unterschreiben. Ein Objekt kann durch ein oder mehrere Schlüssel unterschrieben sein.

Der Benutzer arbeitet in SDSI mit Namen und nicht mit Schlüsseln. Namen sind lokal, und jeder Benutzer kann diesen beliebig wählen. E-mail Adressen von Benutzern haben besondere Bedeutung.

Zertifikate binden wie in X.509 Namen an Schlüssel (z.B. Gruppendefinitionen, etc.). Jedes Zertifikat muß einen Aussteller und ein Ablaufdatum beinhalten. Zertifikate in SDSI haben ein Ablaufdatum (ab diesem kann es nicht mehr rezertifiziert werden) und optional ein Wiederbestätigungsdatum. Wiederbestätigt wird ein Zertifikat durch ein neues Datum und eine erneute Unterschrift.

SDSI verlangt Auto Zertifikate (Auto-Cert), die vom Benutzer unterschrieben werden und online zur Verfügung stehen. Diese sind vom Benutzer selbst unterschriebene Zertifikate, die seinen Namen, Adresse und andere persönliche Daten enthalten.

Jeder Benutzer muß weiters von ihm ausgestellte Zertifikate, Objekte die ihm gehören und Rezertifizierungen für abgelaufene Zertifikate online (auf einem Server) zur Verfügung stellen. Dadurch werden CRLs (Certificate Revocation Lists) überflüssig. Der Server muß die Berechtigung haben, jederzeit die Zertifikate des Benutzers auszustellen.

SDSI soll Zugriffsrechte für WWW-Seiten ermöglichen. Sogenannte ACLs (Access Controll Lists) werden für jedes Objekt (Seite, Bild, Applet, etc.) verwaltet. Bei jeder Anfrage wird vom Server geprüft ob der Anfragende die Berechtigung hat auf das Objekt zuzugreifen. Um diesen Vorgang zu vereinfachen, erlaubt SDSI die Bildung von Gruppen.

Eine Autorität kann einen lokalen Namen für eine Gruppe definieren, die aus einer Menge von Autoritäten besteht. Wird nun ein geschütztes Objekt von einem WWW Server abgefragt, überprüft dieser die Zugehörigkeit zur ACL.

Wenn der Benutzer eine Seite abfragen will, ist er für die Bereitstellung der benötigten Gruppenzugehörigkeitszertifikate selbst verantwortlich. Der Server kann ihm jedoch einen Hinweis geben, welche Zertifikate benötigt werden.

    5.2 Zertifikatsstruktur

Zertifikate werden in SDSI durch sogenannte S-Expressions aufgebaut. Eine S-Expression kann ein Octet String oder eine Liste mehrerer S-Expressions sein. Einem Octet String kann ein Darstellungshinweis vorangestellt werden. Dieser soll eine für den Benutzer verständliche Darstellung ermöglichen und ist in eckige Klammern zu setzen. Ein Beispiel für einen Darstellungshinweis und einen Octet String wären:

[charset=unicode-1-1] #34518976aabcde.

Octet Strings können auch aus mehreren Teilstrings zusammengesetzt werden, wobei alle bis auf den letzten String ein Minuszeichen am Ende haben.

#01- "b"- #a- #00 entspricht #0162a00.



Zahlen werden als Octet String dargestellt.

Hash Werte beinhalten den Algorithmus und den Wert z.B.
( SHA-1 = 67adhNPs8Y+/Uy34NhWp77CvULm= ).

Datum und Zeitangaben erfolgen im ISO 8601:1988 Format bis zu Millisekunden: yyyy-mm-ddThh.ss.mmm-xxzz. xx (Stunden) und zz (Minuten) geben die Differenz zur UTC Zeit an.

Zur effektiveren Übertragung können Tokens als Abkürzungen übertragen werden. Die Abkürzung besteht aus einem * und einer Buchstabenfolge. Eine Tabelle der Abkürzungen wird erstellt und publiziert (z.B. Principal: = *P:)



(type:

( Attribute1: value1 )

( Attribute2: value2a value2b )

... )

Nachrichtenobjekte bestehen aus einem Protokollnamen und einem Nachrichtennamen wie z.B. Get.Reply

    5.3 Standard SDSI Objekte

        5.3.1 Schlüssel und Verschlüsselungsparameter:

Diese Objekte enthalten den Algorithmus-Namen und den entsprechenden Schlüssel. Objekte der Typen Public-Key, Private-Key und Shared-Secret-Key sind vorgesehen.



( Public-Key:

( Algorithm: RSA-with-SHA-1 )

( N: =Hi7KugV013Tv978d00vCpQ== )

( E: #11 ) )

Abbildung 8: Das Schlüsselfeld

        5.3.2 Benutzer repräsentiert durch öffentliche Schlüssel

Ein Benutzer wird in SDSI durch einen öffentlichen Schlüssel, einen oder mehrere globale Namen und eine oder mehrere Internet Adressen repräsentiert.



( Principal:

( Public-Key: ... )

( Global-Name: ( ref: VeriSign!! WebMaster Bob-Jones ) )

( Principal-At: "http://abc.webmaster.com/cgi-bin/sdsi-
     Server/" )

( Server-At: "http://xyz.webmaster.com/cgi-bin/sdsi-
     Server/" ) )

Abbildung 9: Das Benutzerfeld

Das Server-At Feld enthält die Internet Adresse von einem oder mehreren Servern, die Zertifikate und Unterschriften für den Benutzer ausgeben dürfen. Sie sollten eine hohe Erreichbarkeit aufweisen; im Gegensatz dazu kann der Benutzer selbst permanent offline sein. Die Server müssen auch das Auto-Zertifikat des Benutzers auf Anfrage zur Verfügung stellen.

Im Benutzerobjekt sollte möglichst wenig Information enthalten sein, da einerseits das Veralten der Informationen die Zertifikate unbrauchbar machen würde, andererseits das Benutzerobjekt in jedem unterschriebenen Objekt vorkommt und daher beträchtlichen Speicherplatz verbrauchen würde.

Die lokalen Namen/Werte Bindungen können durch Zertifikate exportiert werden. SDSI unterstützt dabei Verbindungen. Wenn lokal Verisign!! definiert ist kann durch

Verisign!!'s Smith's father

derjenige angesprochen werden, der bei Smith unter father bekannt ist. Smith ist wiederum derjenige der bei Verisign!! als Smith bekannt ist. Lokal ist somit Verisign!! definiert, Verisign!! definiert Smith und Smith definiert father - die Zertifizierungskette nimmt ihren lauf.

        5.3.3 Codierte Objekte

Codierte Objekte enthalten den Codierungsschlüssel oder einen Hash davon und den codierten Text. Dadurch können Hinweise oder andere Felder codiert an den Zertifikatsempfänger übertragen werden.



( Encrypted:

( Key: ( Shared-Secret-Key: ... ) )

( Ciphertext: =Yj86gs54k92== ... ) )

Abbildung 10: Codierte Objekte

        5.3.4 Unterschriebene Objekte

Objekte können in drei verschiedenen Formen unterschrieben werden. In der "wrapped-object" Form (Objekt und sein Hash sind enthalten und der Hash wird unterschrieben), der "wrapped Hash" Form (Hash wird unterschrieben) und der "signature appendix" Form. Die "wrapped" Form besagt, daß das Objekt eingeschlossen ist, bei der "appendix" Form (Standard SDSI Form) wird die Unterschrift an das Objekt angehängt.

Object	Das unterschriebene Objekt, dessen Hash im Object Hash Feld enthalten ist
Expiration-Date	Ablaufdatum der Unterschrift (auch durch Rekonfirmation nicht aufhebbar)
Signer	Unterschreibender Benutzer
Signer-Key-Hash	Hash des unterschreibenden Schlüssels (notwendig bei shared secret key)
Credentials	zB. Zertifikate, die zur Autentifizierung des Unterschreibers beitragen
Signing-For	Unterschreiber unterschreibt für einen Benutzer (in diesem Fall muß das Credential Feld vorhanden sein!)
Re-confirm	Gibt an, daß Rezertifizierung notwendig ist und enthält die Details (periodisch, Stichtag, etc.)

Wrapped-object Unterschriften können durch das Entfernen des Objekts in Wrapped-Hash Unterschriften umgewandelt werden, da das Hash nicht das Objekt beinhaltet. Nur im Appendix Format können Zweitunterschriften erstellt werden. Eine Unterschrift im Wrapped Format kann durch einfaches Umstellen (ohne neue Unterschrift) in eine Appendix Unterschrift umgewandelt werden.



( Get.Query:

( Template: (Auto-Cert: ) )

( Signed:

          ( Objekt-Hash: ( SHA-1 #3... ) )

          ( Date: 1996-06-12T09:48:32.021-2300 )

          ( Signature: #76gtt4216 ) ) )

( Signed:

( Objekt-Hash: ( SHA-1 #3... ) )

( Object: ( Get.Query: ( Template: (Auto-Cert: ) ) ) )

( Date: 1996-06-12T09:48:32.021-2300 )

( Signature: #76gtt4216 ) )

Zweitunterschriften können entweder parallel oder verschachtelt erfolgen. Im verschachtelten Format bietet die Zweitunterschrift Sicherheit, daß die erste vorher erstellt wurde, da der Hash der zweiten Unterschrift die erste einschließt.

        5.3.5 Lokale Namen, Zertifikate und Namen/Werte Bindungen

Jeder Benutzer hat seinen eigenen lokalen Namenbereich. Er kann Zertifikate ausstellen um seine Namen/Werte Bindungen zu exportieren.

Namen
Namen können durch einen Octet-string oder durch eine S-expression dargestellt werden.

Namen/Werte Bindungen
Ein Wert kann an einen Namen durch ein Zertifikat gebunden werden. DNS Adressen haben besondere Bedeutung. Sind die Werte Octet Strings der Form name@ak..a2.a1 für k>= 1, dann wird der String gleich dem ersten definierten (im lokalen Namensverzeichnis enthaltenen) Element der Liste gesetzt.

Zertifikate
Zertifikate sind unterschriebene Nachrichten oder Objekte. Sie enthalten ein Value Feld, daß den Inhalt enthält der an einen lokalen Namen gebunden werden soll. Es beschreibt zum Beispiel den Benutzer eines öffentlichen Schlüssels

Erlaubte Werte für das Value Feld sind Principal, Group, Quote, ref und Encrypted Objekte. Das Encrypted Objekt muß eines der vorangegangenen Objekte ergeben, wenn es decodiert wird. Ein Assert-Hash ist dann gültig, wenn das erste Objekt Feld eines der vorangegangenen Felder ist.



( Cert:

( Local-Name: "Bob Smith" )

( Value: ( Principal: ... ) )

( Signed:

     ( Objekt-Hash: ( SHA-1: #... ) )

     ( Date: 1997-01-10T17:49 )

     ( Expiration-Date: 2000-01-01T00:00 )

     ( Signer: ( Principal: ... ) )

     ( Signature: #67A321 ) )

Abbildung 15: Beispiel für ein Zertifikat

Das Zertifikat kann ein Description Feld enthalten, welches für den Benutzer bestimmt ist. Es soll zusätzliche Erklärung für einen Benutzer bieten.

Die Verfasser des SDSI Standards gehen davon aus, daß jeder Benutzer persönlich entscheiden sollte, welche Benutzer in seinen persönlichen Namensbereich aufgenommen werden sollte. Daher sollte er über Zusatzinformationen verfügen, die ihm bei dieser Entscheidung helfen (z.B. Auto-Cert). Das bedingt aber, daß jeder Benutzer sich mit Zertifikaten und Zertifizierungsstrukturen bis zu einem gewissen Maß auskennt.

Es kann Zertifikate ohne Ablaufdatum geben, die periodisch rekonfirmiert werden müssen.

Es kann gleichzeitig mehrere Zertifikate gleichen Typs geben. Jedes dieser Zertifikate ist dann gültig. Im Zweifelsfall sollte das neueste Zertifikat verwendet werden. SDSI verzichtet jedoch vollständig auf CRL's - Zertifikate können nicht wiederrufen werden.

        5.3.6 Protokolle

Kommunikation in SDSI findet als Sequenz von Protokollen statt. Zwei Parteien sind daran beteiligt: der Client, der die Kommunikation beginnt und der Server. Die SDSI Spezifikation sieht allerdings kein eigenes Übertragungsprotokoll vor.

Anfragen mit dem "Get" Protokoll
Das Get Protokoll ist das Protokoll für die Anfrage an einen Server, ein Zertifikat aus seiner Datenbank zu senden. Eine Anfrage enthält ein Template Objekt, das den Typ des Zertifikats enthält, und eine Liste von Attributen und Werten, die das gesuchte Zertifikat enthält.



( Get.Query:

( To: (Principal: ... ) )

( Template: ( Cert: ( Local-Name: paul ) ) )

( Signed: ... ) )

Abbildung 16: Anfrage für alle Zertifikate
die das Wertepaar Loacal-Name: paul enthalten

Anfragen können auch zwei Flags enthalten, die im Fall von ( Encrypt-Reply: true ) eine codierte Antwort und im Fall von (Sign-Reply: true) eine unterschriebene Antwort verlangen.

Antworten oder Fehlermeldungen vom Server beinhalten ein Your-Last-Message-Hash Feld, um jede Antwort mit einer Anfrage des Client zu identifizieren.

Rezertifizierungsanfragen
SDSI benutzt Zertifikate mit periodischer Rezertifizierung im Gegensatz zu den Certificate-Revocation-Lists (CRL) von X.509 oder SPKI.

Ein Zertifikat kann entweder durch den ausstellenden Benutzer oder durch einen von ihm Ermächtigten rezertifiziert werden. Dafür gibt es eine Rezertifizierungsanfrage:



( Reconfirm.Query:

( To: ( Principal: ... ) )

( Signed-Object:

     (Signed:

          ( Object-Hash: (SHA-1 ... ) )

          ( Date: ... )

          ( Signature: #444111 ) ) )

Abbildung 17: Die Rezertifizierungsanfrage

Das Signed-Object Feld gibt das Objekt in der wrapped-Hash Form an, das rezertifiziert werden soll. Eine erfolgreiche Rezertifizierung ist entweder:

Eine neue wrapped-Hash Unterschrift des Ausstellers vom Originalobjekt

Eine neue wrapped Hash Unterschrift vom Rezertifizierungs-Aussteller, die verschachtelt die ursprüngliche Unterschrift unterschreibt.

Wenn eine Fehlermeldung zurückkommt, enthält diese wieder das Your-Last-Message-Hash Feld.

Auto Zertifikate
Ein Auto Zertifikat wird von dem Benutzer unterschrieben, um den es sich handelt. Jeder Benutzer muß über ein Auto Zertifikat verfügen. Es wird im online Bereich des Benutzers abgelegt und kann ohne Änderung des principal Objekts geändert werden. Das principal Objekt enthält die Adressen von einem oder mehreren Auto-Cert Servern, die auf eine Auto-Cert Anfrage antworten können.



( Auto-Cert:

( Public-Key: ... )

( Principal-At: ... )

( Server ... )

( Local-Name: ... )

( Global-Name: ... )

( Email-address: h9452132@asterix.wu-wien.ac.at )

( Signed: ... ) )

Abbildung 18: Das Auto-Certificate

Die Felder: Public-Key:, Principal-At: und Global-Name: sind ident mit denen des Principal: Objekts. Vorgeschrieben sind die Public-Key: und die Signed: Felder.

Für den Computer verwertbar sollten lediglich die Principal-At:, Server:, Email:, Global-Name: und Server: Felder sein.

Das Server: Feld gibt ein oder mehrere Server an, die als ein Agent für den Benutzer arbeiten und eine Datenbank mit seinen Zertifikaten enthalten.

Zumindest Fehlermeldungen muß der Server auch unterschreiben können. Diese Benutzer - Server Trennung wirft Probleme auf. Die unterschriebenen Objekte müssen leicht zugänglich sein, aber der private Schlüssel des Benutzers sollte möglichst sicher beim Server verwahrt werden.

Delegations Zertifikate
Delegations Zertifikate werden benutzt, um eine Gruppe zu autorisieren, für den Benutzer zu unterschreiben.



( Delegation-Cert:

( Template:( Membership.Cert:( Group: WI-SE-C-Teilnehmer )

( Group: ( Principal: ... (Stefan) ... )

( Signed: ... ) )

Abbildung 19: Das Delegationszertifikat

Dieses Zertifikat erlaubt es Beispielsweise dem Benutzer (Stefan) Mitgliedszertifikate für die Gruppe WI-SE-C-Teilnehmer zu unterschreiben.

Transportmechanismen
SDSI könnte über verschiedene Transportmechanismen wie HTTP, Gopher oder E-Mail übertragen werden. Die Autoren schlagen jedoch einen eigenen Transportmechanismus vor, der erst zu erstellen ist.

        5.3.7 Gruppen und ACL's

Ein oder mehrere Benutzer bilden eine Gruppe. Die einfachste Gruppe ist das Principal Objekt, das nur ein Mitglied hat. Das reservierte Wort ALL! beschreibt eine Gruppe der alle Benutzer angehören.

Gruppen können durch Auflistung ihrer Mitglieder (direkt durch ein Principal: Objekt oder indirekt durch ihren lokalen Namen) definiert werden. In der Definition sind auch andere Gruppen erlaubt.

( Group: paul ( Principal: ... ) friends )



Ob jemand einer Gruppe angehört, kann über eine Membership.Query Anfrage abgefragt werden.



( Membership.Query:

( To: ( Principal: ... A ... ) )

( Member: ( Principal: ... B ... ) ... )

( Group: WI-SE-C-Teilnehmer )

( Credentials: ... )

( Signed: ... )

Abbildung 20: Die Membership Anfrage

Der Server schickt als Antwort ein Membership.Cert: Objekt.



( Membership.Cert:

( Member: ( Principal: ... B ... ) ... )

( Group: WI-SE-C-Teilnehmer )

( Reply: answer hint )

( Signed: ... )

Abbildung 21: Das Membership Zertifikat

Das Reply: Feld gibt eine der drei folgenden Antworten: true, false oder fail. Im letzen Fall (fail) gibt der Server einen Hinweis (hint), wie der Anfrager zusätzliche Zertifikate bekommen kann, um den Fehler zu vermeiden (Credentials).



SDSI soll es ermöglichen, ACLs (Access Controll Lists) in einer einfachen und leicht verständlichen Weise zu erstellen und zu warten.

Der Syntax von ACL besteht aus ( ACL: ( type1 def1 ) ( type2 def2 ) .. ). Type gibt die Operationen an ( z.B. read) und def entweder einen lokalen Namen oder eine Gruppendefinition.

        5.3.8 Anwendung

Mail Reader
Wenn ein Mail Reader ein SDSI unterschriebenes Objekt erhält, kann er dem Benutzer entweder den lokalen Namen oder, wenn er nicht im lokalen Namensbereich vorhanden ist, einen globalen Namen anzeigen.

WWW
Ein HTML Dokument kann ACLs benutzen um ein Dokument nur für bestimmte Benutzer zugänglich zu machen.

<META NAME="SDSI-ACL" CONTENT="( ACL: ( read: Gruppe-C4 ) )">

Kerberos ähnliche Tickets
Sehr kurzlebige Zertifikate können benutzt werden, um Zugriff auf Objekte die ACLs enthalten zu ermöglichen. A kann ein Zertifikat erhalten das ihn als Mitglied einer Gruppe G ausweist und dadurch auf ein Objekt zugreifen, auf das Mitglieder von G Zugriff haben.

Verbreitung von unterschriebenem Code
Code kann in der wrapped Hash Form unterschrieben werden, um seine Unverfälschtheit zu garantieren.

Unternehmensinternen Datenbankzugriff
Daten können nur bestimmten Gruppen zugänglich gemacht werden.

6 Unterschiede X.509, SDSI, SPKI

Der alte Standard X.509 wird durch die Modifikationen v2 und v3 laufend an neue Anforderungen angepaßt. Die Strukturen und Probleme der ersten Version haben sich jedoch nicht vollständig beseitigen lassen. Darum sind verschiedene neue Vorschläge für Zertifikatstandards entstanden.

SPKI wurde von Carl M. Ellison und anderen erarbeitet. Er ist Mitarbeiter der Firma CyberCash, die naturgemäß stark an einem leistungsfähigeren Zertifikatstandard interessiert ist.

Ronald Rivest erarbeitete in Zusammenarbeit mit Butler Lampson SDSI. Butler Lampson ist Mitarbeiter der Firma Microsoft.

SPKI versucht den Rahmen von X.509 zu erweitern, indem es nicht von der Bindung eines Schlüssels mit einer Person ausgeht, diese Möglichkeit aber beinhaltet. Dadurch wird es möglich, in weiteren Anwendungsgebieten die Vorteile von Zertifikaten zu nutzen.

Die genaue Spezifizierung des Autoritätsflusses birgt auch die Möglichkeit in sich, Zertifikate mit bestimmten Autoritäten zu erstellen.

Alte Probleme, wie die Handhabung von CRLs (Certificate Revocation Lists) oder Zertifizierungsstrukturen, bleiben jedoch bestehen.

SDSI will mit seinen Gruppen die Handhabung von Access Control Lists vereinfachen und die Verifizierungsstrukturen aufbrechen. Dies bietet zwar den Vorteil, daß sich der Benutzer nicht mehr fortlaufend die neuen CRL besorgen muß und er dadurch entlastet wird, die Zertifikate müssen aber eine sehr kurzfristige Gültigkeitsdauer aufweisen, um im Falle des Mißbrauchs diesen nicht lange zu ermöglichen. Kurzfristige Zertifikate verlangen jedoch hohe Rezertifizierungs-frequenzen, und diese verursachen wieder große Datenmengen, die übertragen werden müssen.

Man bedenke etwa die durchschnittliche Dauer des Verbindungsaufbaus zu einem Server in den Vereinigten Staaten, wenn ein Host der WU-Wien mehrere Zertifikate benötigt, um eine Zertifizierungskette zu überprüfen.

Der Online Bereich, den jeder Benutzer für seine Zertifikate benötigt, stellt auch einen großen Aufwand für die meisten User dar.

SDSI dürfte sich daher vorerst eher im Intranet als im Internetbereich durchsetzen.

    6.1 Fazit

Es zeichnet sich ein Wettlauf zwischen den verschiedenen Standards ab. Ideen die von einer der Gruppen erarbeitet werden, sind bald auch in den anderen Vorschlägen vorhanden. Wie effektiv die einzelnen Konzepte sind, wird sich erst im praktischen Einsatz zeigen.

X.509 hat den Vorteil, daß es in vielen Anwendungen schon heute eingesetzt wird. Aber auch SPKI und SDSI planen Realisierungen ihrer Konzepte in Kürze. Welcher der Standards allerdings tatsächlich den Durchbruch schaffen wird, hängt aber auch davon ab, wie er von den Benutzern und der Softwareindustrie unterstützt wird.

Da SSL und PCT die in den nächsten Kapiteln behandelt werden X.509 unterstüzen wird die Ablöse von X.509 wahrscheinlich noch einige Zeit in Anspruch nehmen.

7 ZERTIFIKATE IN DER PRAXIS

Schutzwürdige Daten werden immer dann übertragen, wenn die Daten allein jemanden ermächtigen, einer beteiligten Partei finanziellen Schaden zuzufügen. Derartige Daten sollen nicht unverschlüsselt über das Netz gehen. Es besteht immer die technische Möglichkeit, daß an beliebigen Knoten diese Daten abgefangen, kopiert und eingesehen werden.

Schützenswürdige Daten sind insbesondere Kreditkartennummern. Jeder, der schon einmal telefonisch mit der Kreditkarte bezahlt hat, weiß, wie leicht man auch eine fremde Nummer angeben hätte können. Der Betroffene eines Betruges kann, gegen eine Abbuchung die er nicht selbst vorgenommen hat, Einspruch erheben. Er bekommt, soweit der Händler ihm nicht das Gegenteil beweisen kann, sein Geld zurück.

Auch wenn man als Kreditkarteninhaber gegen solche Vorfälle ziemlich gut abgesichert ist, sollte man trotzdem vorsichtig mit diesen Daten umgehen. Es kann immer passieren, daß man einmal eine unberechtigte Abbuchung übersieht oder Kreditinstitute vielleicht (in Zukunft) auf die Idee kommen, unverschlüsselte Daten die über das Netz gehen als nicht sorgsame Verwahrung der Daten anzusehen. Die Gefahr, daß Daten während des Transports über ein Computernetz abgehört werden, läßt sich durch folgende Möglichkeiten vermeiden: verschlüsselte Übertragung mit SET, SSL und PCT.

Diese Verfahren werden in den folgenden Kapiteln unter die Lupe genommen. Im nächsten Kapitel wird besonders genau auf die Anpassung des Zertifikats X.509 v3 auf die speziellen Bedürfnisse für SET eingegangen. In den letzten zwei Kapiteln wird untersucht, in welcher Weise Zertifikate in die Handshake-Protokolle SSL und PCT eingebaut sind. Diese Handshake-Protokolle werden in der Fachliteratur auch als TLS-Protokolle (Transport Layer Security-Protokolle) bezeichnet.

    7.1 SET

Secure Electronic Transaction ist eine offene Spezifikation um  unabhängig von Netzwerken Kreditkartenzahlungen zu schützen . SET inkludiert die Verwendung der Public Key Kryptographie von RSA Data Security um den Schutz von Informationen in offenen Netzen zu gewährleisten.

Immer häufiger bilden elektronische Zertifikate das Herzstück sicherer elektronischer Geschäfte. Sie tragen sehr dazu bei, daß die an den Geschäften Beteiligten einander trauen können. Dieses Vertrauen geht von einer dritten Stelle wie z.B. VISA aus [SET]. VISA erteilt Zertifikate an jene Institutionen die Kreditkarten ausstellen, welche ihrerseits wieder Zertifikate an die Kartenbesitzer erteilen. Ein ähnlicher Prozeß findet auch für den Händler statt.

Bei jeder Transaktion bestätigt die SET-Software die Identität des Händlers und des Kunden bevor weitere Informationen ausgetauscht werden. Die Bestätigung erfolgt durch die Kontrolle der Zertifikate, welche durch autorisierte Dritte ausgestellt wurden.

Shopping im Cyberspace sieht also folgendermaßen aus:
Bevor man endlich sicher im Cyberspace einkaufen kann, muß man sich vorher registrieren lassen. Der Kartenbesitzer muß dazu seine VISA-Karte on-line bei seiner Bank registrieren. Dazu muß ein Formular mit Basisinformationen (Name, Kontonummer, Ablaufdatum, etc.) ausgefüllt werden. Anschließend wird das Formular verschlüsselt an das Kreditinstitut geschickt. Nach der Prüfung der Informationen wird das digitale Zertifikat ausgestellt und von der Bank mit ihrer elektronischen Unterschrift versehen. Dieses unterschriebene Zertifikat bezeugt nun die Gültigkeit der Kreditkarte. Der Karteninhaber speichert das Zertifikat für den zukünftigen Gebrauch auf seinem PC und das Einkaufen im Netz kann beginnen.

Auch der Händler benötigt ein digitales unterschriebenes Zertifikat seiner Bank um beim sicheren Einkaufen im Netz mitmachen zu können.

Im folgenden Abschnitt wird zu Beginn zur Wiederholung eine Definition des Zertifikats X.509 v3 vorgenommen, wobei ein paar Besonderheiten für SET dargestellt werden. Anschließend wird ein Überblick über die Standard Extensions und die SET Private Extensions gegeben. Zum Abschluß wird noch auf die Certificate Revocation List und den Brand Identifier näher eingegangen.

        7.1.1 X.509 Zertifikat Definition:

Das Zertifikat X.509 v3 sieht zur Erinnerung folgendermaßen aus:

Die genaue Bedeutung der Extensions wird in den folgenden Kapiteln dargestellt.

        7.1.2 Standard Extensions in SET

Wie in Abbildung 22: Definition des Zertifikats X.509 v3

ersichtlich, können Extension Daten applikationsabhängig definiert werden. SET verwendet folgende:

Authority Key Identifier Extension: Eine CA kann mehr als ein Zertifikat haben (z.B. aus unterschiedlichen funktionalen Gründen oder beim Key-Updating). Diese Extension gibt an, welches CA-Zertifikat verwendet werden muß um die digitale Unterschrift zu verfizieren. Diese Extension ist nicht kritisch und enthält folgende Felder:

Key Usage Extension: Kritische Extension die angibt wie der öffentliche Schlüssel in dem Zertifikat verwendet werden kann.

KeyUsage

digitale Unterschrift Zertifikat Unterschrift CRL Unterschrift Daten- und Schlüsselverschlüsselung Zertifikat Unterschrift und CRL Unterschrift

Private Key Usage Period Extension: Ist kritisch und setzt die Zeit für die Gültigkeit des Privaten Schlüssels, und damit des Zertifikats, fest.

.notBefore	definiert die Startzeit
.notAfter	definiert das Ende der Gültigkeit

Certificate Policies Extension: Ist nicht kritisch und enthält eine Liste einer oder mehrerer Certificate Policies. Jede Certificate Policy ist durch einen weltweit einzigartigen Object Identifier (OID) gekennzeichnet und kann wahlweise einen entsprechenden Qualifier enthalten. Enthält ein SET Zertifikat einen Object Identifier so muß das Zertifikat gemäß den in der Certificate Policy enthaltenen Regeln verwendet werden. Diese Extension beinhaltet die Konditionen unter denen die CA arbeitet (z.B. Sicherheitsvorkehrungen bei der Zertifizierung,). Dies soll Applikationen ermöglichen, anhand einer Vergleichsliste zu entscheiden, ob ein Zertifikat den geforderten Sicherheitsanforderungen entspricht, oder zurückgewiesen werden soll.

Policy	enthält den OID welcher auf das Brand's Policy Statement hinweist. Die Policy kann durch die e-mail Adresse oder URL erhalten werden, die in der SETQualifier Private Extension enthalten ist
Qualifier	Nicht in SET verwendet. Siehe SET-Qualifier Private Extension

Subject Alt Name Extension: Diese Extension enthält einen oder mehrere alternierende Subject Names. Dieses Feld ist optional, nicht kritisch und wird nur inkludiert, wenn in der Anfrage ein Alternate Name spezifiziert wurde.

SubjectAltName .GeneralNames

enthält einen oder mehrere Alternate Names (auch e-mail Adresse oder URL verwendbar)

Basic Constraints Extension: Diese Extension ist kritisch und zeigt an ob ein zertifiziertes Subjekt als CA, als Benutzer oder beides handeln kann. Wenn es als CA handeln kann, zeigt die Extension die Anzahl der Sub-CAs an welche die CA authentifizieren kann.

.subjectType	für alle CAs und Sub-CAs (weggelassen bei End Entities)
.pathLenConstraint	zeigt die Anzahl der Sub-CAs (z.B. eine Null bedeutet, daß das CA Zertifikat nur dazu verwendet werden kann um Zertifikate von End Entities zu unterschreiben)

Issuer Alt Name Extension: Wird nur inkludiert wenn die ausstellende CA sich für mehrere Namen entscheidet. Sonst ident mit Subject Alt Name Extension.

        7.1.3 SET Private Extensions

Folgend werden die in SET verwendeten Private Extensions im Detail erläutert.

Hashed Root Key Private Extension: Diese Extension wird nur in Root Zertifikaten verwendet und enthält den Hash des nächsten Root Key. Der Hash wird durch den Hash-Algorithmus SHA1 erzeugt. Der SubjectPublicKey enthält den öffentlichen Schlüssel für die nächste Root und wird zur Authentifizierung des nächsten Root Zertifikats verwendet. Die Extension ist kritisch.

Certificate Type Private Extension: Dient dazu um zwischen den neun Bestandteilen der Certificate Management Architecture zu unterscheiden. Diese Architektur ist folgend aufgebaut:

Abbildung 30: Aufbau der Zertifikathierarchie in SET

Durch die Extension können nun folgende Typen festgesetzt werden:

Es ist nur ein einziger Typ möglich:

Cardholder (CARD): beantragt und erhält Zertifikate von der CCA Merchant (MER): beantragt und erhält Zertifikate von der MCA Acquirer Payment Gateway (PGWY): beantragt und erhält Zertifikate von der PCA Geo-political Certification Authority (GCA): diesen CA's wird für bestimmte geografische oder politische Regionen Verantwortung von Brand Certification Authorities übertragen Brand Certification Authority (BCA): diese CA besitzt ein bestimmtes Maß an Autonomie im jeweiligen Brand´s Certificate Management und stellen Zertifikate an die Einheiten unterhalb in der Hierarchie aus Root Certification Authority (RCA): diese CA unterliegt sehr strengen Kontrollen und dient zur Ausstellung neuer Brand Level CA- und Root-Zertifikaten

Es sind mehrere Typen gleichzeitig möglich (z.B. eine CA kann sowohl Zertifikate an Kartenbesitzer und Händler ausstellen):

Cardholder Certification Authority (CCA): diese CA's sind für die Erstellung und Verteilung von Zertifikaten an Cardholder zuständig Merchant Certification Authority (MCA): diese CA's sind für die Verteilung von Zertifikaten an Merchants zuständig Payment Certification Authority (PCA): diese CA's sind für die Ausstellung von Zertifikaten für SET Acquirer Payment Gateways zuständig

MerchantData Private Extension: Enthält Daten über den Händler die dessen Bank von ihm benötigt (ID, AcquirerBIN, Name, City, StateProvince,...). Die notwendigen Daten muß der Händler bei der Zertifikat-Registrierung per Formular übermitteln. Diese Extension ist nicht kritisch.

Cardholder Certificate Required Private Extension: Zeigt an ob das Payment Gateway Zahlung mit Karteninhabern akzeptiert, welche keine Zertifikate haben. Nicht kritische Extension.

Tunneling Private Extension: Zeigt an ob die CA oder das Payment Gateway "tunneling" von verschlüsselten Nachrichten an den Karteninhaber unterstützt. Wenn dies der Fall ist, enthält die Extension eine Liste mit den unterstützten symmetrischen Verschlüsselungsalgorithmen.

.tunneling	zeigt an ob tunneling unterstützt wird oder nicht
.tunnelAlgIDs	enthält eine Liste von symmetrischen Verschlüsselungsalgorithmen die von der CA oder Payment Gateway unterstützt werden

SETQualifier Private Extension: Enthält Informationen in Verbindung zur SET Policy. Diese Extension ist kritisch.

.policyURL	enthält den URL wo eine Kopie des Policy Statement gefunden werden kann
.policyEmail	enthält eine E-Mail Adresse unter welcher eine Kopie des Policy Statements angefordert werden kann
.digestAlgorithm .algorithm	enthält den OID des Hash Algorithmus der für die Policy verwendet wurde (SHA1 für SET)
.digestAlgorithm .parameters	nicht verwendet
.policyDigest	enthält den Hash des Policy Statements
.terseStatement	enthält Informationen über den Widerruf in Verbindung mit der Ausstellung des Zertifikats

        7.1.4 Certificate Revocation List and BrandCRLIdentifier

Jede CA in SET (außer MCA und CCA) ist für die Führung und für die Verteilung einer CRL verantwortlich. Eine CA ist also dafür verantwortlich, "gefährliche" Zertifikate die von ihr ausgestellt und unterschrieben wurden und noch nicht abgelaufen sind, zu widerrufen. Dabei wird die Seriennummer dieser Zertifikate in die CRL aufgenommen. Die CA wird in der CRL durch ihren Distinguished Name identifiziert, und die CRL durch die CA unterschrieben.

CRL Update:
Immer wenn ein Zertifikat widerrufen wird und die Liste auf den neuesten Stand gebracht werden muß, wird eine neue CRL erzeugt. Wenn ein neues Update durchgeführt wird, werden gleichzeitig abgelaufene Zertifikate aus der Liste gestrichen. Ein neue Liste enthält somit alle noch nicht abgelaufenen, widerrufenen Zertifikate die von der CA ausgestellt wurden.

Gültigkeitserklärung eines Zertifikats:
Damit ein Zertifikat für gültig erklärt werden kann, müssen folgende zwei Felder verglichen werden:

1. Der IssuerDN darf nicht dem IssuerDN-Feld der CRL übereinstimmen und

2. Die CertSerialNumber muß der RevokedCertificates.CertSerialNumber in der CRL entsprechen.

BrandCRLIdentifier:
Der BrandCRLIdentifier ist eine durch SET definierte Struktur, die dazu verwendet wird, alle aktuellen CRLs einer bestimmten Klasse zu identifizieren. Der BCI wird von der Brand level CA geführt, enthält eine Liste mit CRL-Nummern und wird in allen downstream Antwortnachrichten verteilt. Der BCI wird automatisch berichtigt wenn eine Sub-CA (der Brand level CA) eine CRL auf den neuesten Stand bringt. Der BCI wird von der Brand level CA unterschrieben.



Jede X.509 CRL enthält folgende Informationen:

.version	CRL Version (immer v2)
.signature .algorithmIdentifier	Definiert den Algorithmus, welcher zum Unterschreiben der CRL verwendet wird
.Issuer	enthält den Subject DN der CA
.thisUpdate	wann die CRL erstellt wurde
.nextUpdate	wann die CRL aufläuft
.revokedCertificates .certSerialNumber	enthält die Seriennummern der widerrufenen Zertifikate
.revokedCertificates .revocationDate	Datum der Widerrufung
.revokedCertificates .Extensions	Nicht in SET verwendet
.Extensions	2 Extensions möglich: CRLNumber (Wenn eine neue CRL von der CA ausgestellt wird, muß eine CRL Number eingefügt werden. Diese Extension ist nicht kritisch.) AuthorityKeyIdentifier (wie bei Zertifikat verwendet)

    7.2 SSL

Die Secure Socket Layer (SSL) bildet die Grundlage des Netscape Commerce Server, welcher sowohl über das unsichere HTTP als auch mittels einer sicheren Variante kommunizieren kann. Das bedeutet, daß der selbe Server harmlose Dokumente über das unverschlüsselte HTTP, sensitive Informationen aber über das sichere Protokoll übertragen kann. Ob man in einer abgesicherten Verbindung arbeitet kann man an folgenden Kennzeichen erkennen: der URL beginnt mit https anstelle des sonst üblichen http. Beim Netscape Navigator erscheint außerdem ein blauer Balken am oberen Fensterrand und ein Schlüssel in der linken unteren Ecke. Das bedeutet, daß Vorgänge der Ver- und Entschlüsselung für den Benutzer völlig transparent ablaufen [NEW95].

SSL basiert auf der Public Key Kryptographie der Firma RSA Data Security. Dabei enthält jeder Netscape-Browser den öffentlichen Schlüssel eines zentralen Netscape-Servers in den Vereinigten Staaten von Amerika. Dieser Rechner dient dazu, die Identität der Netscape Commerce Server zu bestätigen. Auch hier wird Public-Key-Kryptographie eingesetzt, um eine sichere Kommunikation zwischen den Beteiligten zu ermöglichen. Eine sichere Verbindung in SSL bedeutet, daß der Verbindungspartner ein gültiges Zertifikat besitzt, der Server eindeutig identifiziert wurde (Client optional), und die weitere Datenübertragung verschlüsselt erfolgt.

Auch in SSL bildet das X.509 v3 Zertifikat das Herzstück des Protokolls. Das Zertifikat wird dazu verwendet, einen öffentlichen Schlüssel einer bestimmten Person zuzuweisen. Die wichtigsten Bestandteile des Zertifikats bilden auch hier die Seriennummer, persönliche Daten, Gültigkeitsdauer, Öffentlicher Schlüssel der Person/Organisation und die digitale Unterschrift der CA. Als Zertifizierungsstelle ist derzeit nur Verisign Inc. tätig. (Vielleicht nicht uninteressant zu erwähnen, daß das erste Zertifikat für die Gültigkeitsdauer von einem Jahr 290 USD, jede Verlängerung für ein weiteres Jahr 75 USD kostet.)



Eine lesbare Version eines Musterzertifikats ist in Abbildung 35: X.509 v3 Musterzertifikat

dargestellt:

   Certificate:
        Data:
           Version: 0 (0x0)
           Serial Number:
               02:41:00:00:01
           Signature Algorithm: MD2 digest with RSA Encryption
           Issuer: C=US, O=RSA Data Security, Inc.,
                   OU=Secure Server Certification Authority
           Validity:
               Not Before: Wed Nov  9 15:54:17 1994
               Not After: Fri Dec 31 15:54:17 1999
           Subject: C=US, O=RSA Data Security, Inc.,
                    OU=Secure Server Certification Authority
           Subject Public Key Info:
               Public Key Algorithm: RSA Encryption
               Public Key:
                   Modulus:
                       00:92:ce:7a:c1:ae:83:3e:5a:aa:89:83:57:ac:25:
                       01:76:0c:ad:ae:8e:2c:37:ce:eb:35:78:64:54:03:
                       e5:84:40:51:c9:bf:8f:08:e2:8a:82:08:d2:16:86:
                       37:55:e9:b1:21:02:ad:76:68:81:9a:05:a2:4b:c9:
                       4b:25:66:22:56:6c:88:07:8f:f7:81:59:6d:84:07:
                       65:70:13:71:76:3e:9b:77:4c:e3:50:89:56:98:48:
                       b9:1d:a7:29:1a:13:2e:4a:11:59:9c:1e:15:d5:49:
                       54:2c:73:3a:69:82:b1:97:39:9c:6d:70:67:48:e5:
                       dd:2d:d6:c8:1e:7b
                   Exponent: 65537 (0x10001)
       Signature Algorithm: MD2 digest with RSA Encryption
       Signature:
           88:d1:d1:79:21:ce:e2:8b:e8:f8:c1:7d:34:53:3f:61:83:d9:
           b6:0b:38:17:b6:e8:be:21:8d:8f:00:b8:8b:53:7e:44:67:1e:
           22:bd:97:27:e0:9c:85:cc:4a:f6:85:3b:b2:e2:be:92:d3:e5:
           0d:e9:af:5c:0e:0c:46:95:ff:a1:1c:5e:3e:e8:36:58:7a:73:
           a6:0a:f8:22:11:6b:c3:09:38:7e:26:bb:73:ef:00:bd:02:a4:
           f3:14:0d:30:3f:61:70:7b:20:fe:32:a3:9f:b3:f4:67:52:dc:
           b4:ee:84:8c:96:36:20:de:81:08:83:71:21:8a:0f:9e:a9

Abbildung 35: X.509 v3 Musterzertifikat

        7.2.1 Das SSL Protokoll

Das SSL Protokoll [SSLP95]wurde ,wie einleitend bereits erwähnt, entworfen, um die Geheimhaltung zwischen zwei Kommunikationspartnern (Client und Server) zu gewährleisten. Der große Vorteil dieses Protokolls liegt in der Unabhängigkeit von anderen Applikationsprotokollen. Das bedeutet, daß ein "higher level" Applikationsprotokoll (z.B. HTTP, FTP, TELNET, etc.) auf dem SSL Protokoll aufliegen kann. Weiters kann das SSL Protokoll einen Verschlüsselungsalgorithmus und Session Key aushandeln bevor das Applikationsprotokoll die ersten Daten abschickt bzw. empfängt. Um die Sicherheit zu gewährleisten werden daher alle Daten des Applikationsprotokolls verschlüsselt über den Datenhighway geschickt.



Das SSL Protokoll bietet also Channel-Security mit folgenden Eigenschaften:

Der Kanal ist "privat": nach einer kurzen Handshake-Phase, die zur Erzeugung eines geheimen Schlüssels dient, werden alle Nachrichten verschlüsselt

Der Kanal ist eindeutig: der Server wird immer eindeutig identifiziert (der Client optional)

Der Kanal ist verläßlich: die Integrität der Nachrichten wird durch einen Message Integrity Check (Message Authentication Code - MAC) sichergestellt

        7.2.2 SSL Handshake Protokoll im Detail

Das SSL Handshake-Protokoll besteht grundsätzlich aus zwei Phasen. Während die erste dazu verwendet wird eine sichere Kommunikation aufzubauen, dient die zweite Phase dazu die Authentifizierung des Clients vorzunehmen.





Abbildung 36: Ablauf des SSL Handshake Protokolls

Phase 1
In der ersten Einführungsphase übermitteln die Beteiligten ihre "Hello" Nachrichten. Der Client startet mit der CLIENT-HELLO Message, welche vom Server mit der SERVER-HELLO Message beantwortet wird. Zu diesem Zeitpunkt haben die Beteiligten genug Informationen um zu wissen, ob ein neuer Master Key benötigt wird oder nicht. Der Master Key wird von Client und Server zur Erzeugung der Session Keys verwendet. Wenn kein neuer Master Key notwendig ist springt man direkt in Phase 2. Falls ein neuer Master Key benötigt wird enthält die SERVER-HELLO Message genug Information damit der Client ihn erzeugen kann. Die SERVER-HELLO Message enthält das unterschriebene Zertifikat des Servers, eine Liste unterstützter Public Key Verfahren und eine CONNECTION-ID (eine CONNECTION-ID ist ein zufällig generierter Wert der von Client und Server während einer bestimmten Verbindung verwendet wird). Nachdem der Client den Master Key erzeugt hat, antwortet er mit einer CLIENT-MASTER-KEY Message (oder einer ERROR Message wenn sich Client und Server nicht auf ein gemeinsames Public Key Verfahren einigen können). An dieser Stelle muß erwähnt werden, daß Client und Server je ein Schlüsselpaar verwenden. Wenn der Client oder der Server einen Session Key erzeugt, werden eigentlich zwei Schlüssel erzeugt: der SERVER-READ-KEY (auch bekannt als CLIENT-WRITE-KEY) und der SERVER-WRITE-KEY (auch bekannt als CLIENT-READ-KEY). Der Master Key wird dazu verwendet die verschiedenen Session Keys zu erzeugen. Nachdem die Session Keys erzeugt wurden, werden die folgenden Nachrichten mit diesem verschlüsselt. Abschließend sendet der Server eine SERVER-VERIFY Message an den Client nachdem der Master Key bestimmt wurde. Dieser letzte Schritt authentifiziert den Server.

Phase 2
Die zweite Phase wird Authentifizierungsphase genannt. Da der Server bereits in der ersten Phase durch den Client authentifiziert wurde, bezieht sich diese Phase primär auf die Authentifizierung des Clients. Das typische Szenario sieht folgendermaßen aus: der Server verlangt etwas vom Client und sendet eine Anfrage. Der Client wird antworten wenn er die benötigte Informationen hat bzw. sendet im negativen Fall eine ERROR Message.

Wenn die Authentifizierung einer Partei abgeschlossen ist, wird eine FINISHED Message gesandt.

Wenn ein Beteiligter diese FINISHED Message abgeschickt hat, muß er weiter auf Nachrichten seines Partners warten bis auch dieser seine FINISHED Message abgeschickt hat. Das SSL Handshake Protokoll ist beendet wenn beide FINISHED Messages abgesandt wurden. Dann beginnt das Applikationsprotokoll zu arbeiten.

            7.2.2.1 CLIENT ONLY PROTOCOL MESSAGES

Es gibt einige Nachrichten die ausschließlich von Clients erzeugt werden. Diese Messages werden niemals von richtig funktionierenden Servern generiert. Ein Client der eine solche Nachricht erhält schließt die Verbindung zum Server und schickt eine Fehlermeldung.

CLIENT-HELLO (Phase 1)
Der Client schickt an den Server seine SSL Version, eine Liste der unterstützen Public Key Verfahren, Challenge Data und die Session-Identifier Daten. Die Session-Identifier Daten werden nur gesandt wenn der Client einen Session-Identifier in seinem Cache für den Server gefunden hat (die SESSION-ID-LENGTH ist dann ungleich Null). Die Challenge Daten werden verwendet, um die Echtheit des Servers zu bescheinigen. Nachdem der Client und Server sich auf ein Paar Session Keys geeinigt hat, schickt der Server eine SERVER-VERIFY Message mit der verschlüsselten Form der Challenge Daten.

Der Server untersucht die CLIENT-HELLO Message und überprüft ob er die Client Version und Verschlüsselungsverfahren  des Clients unterstützt. Es können Veränderungen vorgenommen werden und diese im SERVER-HELLO mitgeteilt werden.

Nachdem die CLIENT-HELLO Message abgeschickt wurde, wartet der Client auf die SERVER-HELLO Message. Jede andere Nachricht des Servers ist unzulässig.

CLIENT-MASTER-KEY (Phase 1)
Der Client schickt diese Nachricht wenn er einen Master Key für den Server bestimmt hat. Diese Nachricht wird nicht gesandt wenn man sich auf einen Session-Identifier geeinigt hat.

Der MASTER-KEY wird an den Server in der CLIENT-MASTER-KEY Message übermittelt. Außerdem werden die Session Keys aus dem MASTER-KEY, der CHALLENGE und der CONNECTION-ID erzeugt. Die CHALLENGE wird schon im CLIENT-HELLO an den Server gesandt. Auf der anderen Seite erhält der Client die CONNECTION-ID in der SERVER-HELLO Message. Das bedeutet, daß die erzeugten Schlüssel eine Funktion aus der ursprünglichen und aktuellen "Sitzung" sind.

Die CLIENT-MASTER-KEY Nachricht muß immer nach der CLIENT-HELLO und vor der CLIENT-FINISHED Message abgesandt werden. Die CLIENT-MASTER-KEY Message muß nur dann geschickt werden wenn die SERVER-HELLO Message einen SESSION-ID-HIT Wert von Null hat.

CLIENT-CERTIFICATE (Phase 2)
Diese Nachricht wird als Antwort auf eine Server REQUEST-CERTIFICATE Message gesandt wenn der Client ein gültiges Zertifikat hat (sonst eine ERROR Message). Die CERTIFICATE-DATA enthält Informationen die durch den CERTIFICATE-TYPE (X.509 v3) definiert sind.

Es wird eine digitale Unterschrift mit MD5 erzeugt und mit dem Private Key des Clients verschlüsselt. Der Server authentifiziert den Client indem er die Echtheit der digitalen Unterschrift feststellt. Diese Nachricht wird bereits mit dem neuen Verfahren verschlüsselt.

CLIENT-FINISHED (Phase 2)
Der Client beendet die Handshake-Phase indem er die CLIENT-FINISHED Nachricht sendet. Der Client muß aber weiterhin auf Server Messages warten bis dieser seinerseits die FINISHED Message abschickt. Die CLIENT-FINISHED Nachricht enthält die verschlüsselte CONNECTION-ID.

Der Client muß diese Nachricht nach der SERVER-HELLO Nachricht senden. Wenn diese SERVER-HELLO Nachricht einen SESSION-ID-HIT flag ungleich Null enthält wird die CLIENT-FINISHED Nachricht unmittelbar danach, sonst nach der CLIENT-MASTER-KEY Nachricht gesandt.

            7.2.2.2 SERVER ONLY PROTOCOL MESSAGES

Diese Nachrichten werden ausschließlich von Servern und niemals von korrekt funktionierenden Clients erzeugt.

SERVER-HELLO (Phase 1)
Diese Nachricht wird unmittelbar nach Empfang der CLIENT-HELLO Nachricht geschickt.

Einen wichtigen Bestandteil der Nachricht bildet der SESSION-ID-HIT Flag. Dieser zeigt an ob dem Server der in der CLIENT-HELLO Nachricht übermittelten Session-Identifier bereits bekannt ist. Der SESSION-ID-HIT flag wird ungleich Null sein wenn der Client einen Session-Identifier gesandt und der Server diesen in seinem Cache gefunden hat. Wenn der SESSION-ID-HIT flag Null ist werden das Zertifikat des Servers, eine Liste der unterstützen Public-Key-Verfahren und eine CONNECTION-ID an den Client gesandt. Diese Informationen werden vom Client dazu verwendet um den Session Key zu erzeugen und diesen in der CLIENT-MASTER-KEY Message an den Server zu retournieren.

Wenn der SESSION-ID-HIT flag nicht Null ist, erzeugen Server und Client ein neues Paar Session Keys aus dem MASTER-KEY, welcher ausgetauscht wurde als die SESSION-ID erzeugt wurde.

Einen wichtigen Bestandteil bilden die bereits erwähnten CIPHER-SPECS-DATA. Diese definieren das kryptografische Verfahren und Schlüssellänge. Hier muß erwähnt werden, daß die Schlüssellänge bei der Exportversion des SSL Handshake-Protokolls auf 40 bits beschränkt ist.



Die SERVER-HELLO Nachricht wird nach Empfang der CLIENT-HELLO und vor der SERVER-VERIFY Nachricht gesandt.

SERVER-VERIFY (Phase 1)
Der Server sendet diese Nachricht nachdem man sich auf ein Paar Session Keys geeinigt hat (entweder durch einen Session-Identifier oder einer expliziten Spezifikation mit der CLIENT-MASTER-KEY Nachricht). Die Nachricht enthält eine verschlüsselte Kopie der CHALLENGE-DATA aus der CLIENT-HELLO Nachricht.

Die SERVER-VERIFY Message dient zur Authentifizierung des Servers wie folgt. Nur der richtige Server hat den zugehörigen Private Key der zu dem Public Key in dem Zertifikat paßt (dieses wurde bereits in der SERVER-HELLO Message gesandt). Folglich ist der wahre Server in der Lage das Paar Session Keys zu extrahieren und wieder herzustellen. Schließlich kann nur ein Server nach erfolgreicher Gewinnung und Entschlüsselung die CHANNEL-DATA korrekt verschlüsseln. Der Client muß diese Nachricht entschlüsseln und mit der CHANNEL-DATA aus der CLIENT-HELLO Message vergleichen. Nur wenn beide Werte gleich sind, kann der Client sicher sein, daß er dem Server "vertrauen" kann. Bei Ungleichheit wird die Verbindung vom Client geschlossen.

Diese Nachricht muß vom Server abgesandt werden nachdem ein Session-Identifier Hit festgestellt wurde oder der Server eine CLIENT-MASTER-KEY Message erhalten hat. Die Message muß vor Phase 2 oder der SERVER-FINISHED Nachricht abgesandt werden.

SERVER-FINISHED (Phase 2)
Wenn der Server mit dem Sicherheitshandshake des Clients zufrieden ist wird die SERVER-FINISHED Nachricht abgesandt. Diese Nachricht enthält die verschlüsselte Session-Id.

Der Server ist nun für den Empfang bzw. Übertragung von higher level Protokoll-Daten bereit.

REQUEST-CERTIFICATE (Phase 2)
Der Server kann diese Anfrage zu jedem Zeitpunkt in Phase 2 durchführen. Der Client antwortet sofort mit der CLIENT-CERTIFICATE oder einer NO-CERTIFICATE-ERROR Nachricht.

Die Nachricht beinhaltet CERTIFICATE-CHALLENGE-DATA, dies ist ein kurzer Byte-string, der vom Client verwendet wird um die Nachricht zu beantworten. Der Server authentifiziert den Client wenn er die CLIENT-CERTIFICATE Nachricht erhält.

Diese Message wird nach der SERVER-VERIFY und vor der SERVER-FINISHED Nachricht abgesandt.

            7.2.2.3 CLIENT/SERVER PROTOCOL MESSAGES

ERROR-Nachrichten können von Servern als auch von Clients erzeugt werden.

Nachdem die ERROR-Nachricht abgeschickt wurde, wird die Verbindung vom Sender der Nachricht geschlossen. Der Empfänger registriert den Fehler und schließt dann ebenfalls die Verbindung.



Beispiele für ERROR Nachrichten sind:

NO CIPHER

NO CERTIFICATE

BAD CERTIFICATE

UNSUPPORTED CERTIFICATE TYPE



Diese Nachricht wird im Klartext versandt wenn ein Fehler während der Session Key Verhandlung auftritt. Nachdem man sich auf einen Session Key geeinigt hat werden Errors wie alle anderen Nachrichten verschlüsselt versandt.

            7.2.2.4 Zusammenfassung

Der Ablauf des SSL Protokolls sieht zusammengefaßt so aus:

        7.2.3 Besonderheiten für SSL

In Verbindung zu SSL sind folgende Einschränkungen zu beachten:

Die Felder Signature_Algorithm (beinhaltet den Algorithmus der zum Unterschreiben des Zertifikats verwendet wurde) und SubjectPublicKeyInfo_Algorithm (definiert welcher Algorithmus mit diesem Key verwendet werden kann) müssen ident sein (siehe Kapitel 3.1 Aufbau des Zertifikats nach X.509 v3).

Das Feld für den Zertifikataussteller (Certification Authority) muß einen Namen beinhalten der von der Applikation (die SSL verwendet) akzeptiert wird



Das Zertifikat wird durch folgende Schritte überprüft:

1. Es wird die elektronische Unterschrift des Zertifikats überprüft (es erfolgt ein Error wenn die Unterschrift ungültig ist)

2. Es wird gecheckt ob der Name der CA von der Applikation anerkannt wird

3. Es wird das Gültigkeitsdatum des Zertifikats überprüft

4. Es wird der Zertifikatinhabergeprüft - dies ist optional und abhängig vom benötigten Vertrauensniveau der Applikation

    7.3 PRIVATE COMMUNICATION TECHNOLOGY PROTOCOL (Version 1)

Das PCT Protokoll [PCTP95] dient der sicheren Übertragung von Daten zwischen einem Client und einem Server, wobei der Server immer, der Client optional authentifiziert wird.

Das Protokoll ist applikationsunabhängig. Das bedeutet, daß ein higher level Applikationsprotokoll (z.B. HTTP, FTP, TELNET, etc.) auf dem PCT Protokoll aufliegen kann. Das Protokoll startet mit der Aushandlung eines Verschlüsselungsalgorithmus und einem symmetrischen Session Key. Außerdem wird die Authentifizierung des Servers und wahlweise des Clients vorgenommen (= Handshaking Phase). Sobald die Handshaking Phase abgeschlossen ist werden die Daten des Applikationsprotokolls mit dem ausgehandelten Session Key verschlüsselt übertragen.

Ein Kennzeichen des PCT Protokolls ist, daß es keine Einzelheiten über die Verifizierung von Zertifikaten in bezug auf Zertifizierungsstellen, Revocation Lists und ähnliches enthält. Es wird angenommen, daß Protokollimplementierungen Zugang zu einer "Black Box" haben. Diese ist in der Lage über die Gültigkeit von Zertifikaten zu entscheiden.

Das Protokoll ist außerdem in der Lage die Integrität der Nachrichten mit Hilfe eines Message Authentication Code (MAC) zu bestätigen.

Abschließend muß erwähnt werden, daß das Record-Format des PCT Protokolls mit SSL kompatibel ist.

        7.3.1 PCT HANDSHAKE PROTOCOL

Die Sicherheitsbestandteile des Protokolls umfassen die Authentifizierung, symmetrische Verschlüsselung und Überprüfung der Integrität von Nachrichten. Die symmetrische Verschlüsselung wird durch einen "Key Exchange Algorithm" vereinfacht.



Das PCT Handshake Protokoll besteht aus vier Nachrichten:

1. CLIENT-HELLO

2. SERVER-HELLO

3. CLIENT-MASTER-KEY

4. SERVER-VERIFY



Die Inhalte der Nachrichten hängen von folgenden zwei Faktoren ab:

1. Handelt es sich um eine neue oder um die Fortsetzung einer alten Session und

2. Kommt es zu einer Client-Authentifizierung oder nicht



Die CLIENT-HELLO Nachricht enthält eine Random Authentication Challenge und eine Anfrage bezüglich der Art der Verschlüsselung und Zertifizierung. Wenn der Client versucht eine alte Session wieder zu starten wird auch die Session-Id mitgesandt.

Wenn eine neue Session gestartet wird enthält die SERVER-HELLO Nachricht ein Zertifikat und einen Random Connection Identifier. Dieser Identifier wird als Authentication Challenge dupliziert wenn der Server eine Client Authentifizierung anstrebt. Der Client antwortet mit der CLIENT-MASTER-KEY Nachricht. Diese Message enthält den Master Key ,aus dem die Session Keys abgeleitet werden, welcher mit dem Public Key des Servers (aus dem Zertifikat) verschlüsselt wird. Außerdem enthält diese Nachricht das Zertifikat des Clients wenn der Server die Authentifizierung des Clients verlangt hat. Um sicherzustellen, daß die vorangegangenen unverschlüsselten Nachrichten nicht verfälscht wurden, wird ihr verschlüsselter Hash in der CLIENT-MASTER-KEY Nachricht ebenfalls mitgeschickt. Abschließend sendet der Server die SERVER-VERIFY Message, welche eine Antwort auf die Challenge des Clients sowie einen Random Session-Id enthält.

Wenn der Server den alten Session-Id akzeptiert enthält die SERVER_HELLO Nachricht eine Antwort auf die Challenge des Clients und einen Random Connection Identifier. Wenn der Server keine Authentifizierung des Clients verlangt ist die Handshake Phase beendet. Andernfalls folgt eine CLIENT-MASTER-KEY und SERVER-VERIFY Nachricht.

Handshake Protokoll Nachrichten werden ausschließlich im Klartext gesandt. Eine Ausnahme bilden jene Felder der CLIENT-MASTER-KEY Nachricht die in Verbindung zum Schlüsseltausch stehen.

        7.3.2 NACHRICHTEN IM DETAIL

Im folgenden Abschnitt werden die vier Nachrichten des PCT Handshake Protokolls im Detail erklärt.

            7.3.2.1 CLIENT-HELLO

Die CLIENT-HELLO Nachricht muß die erste Nachricht des Clients sein. Sie enthält die PCT Version Number, Challenge Data, Session-Id (bei Restart-Session) sowie eine Cipher-, Hash-, Server-Certificate- und Key-Exchange-Liste.

Das CHALLENGE-DATA Feld besteht aus einer 32 byte langen Kette zufällig ausgewählter Bits und dient zur Authentifizierung des Servers. Wenn der Client einen Session-Identifier in seinem Cache findet wird dieser im CLIENT-HELLO übermittelt. Im negativen Fall wird das Feld PCT-SESSION-ID-NONE verwendet. Abschließend werden vier Listen mit jenen symmetrischen Verschlüsserlungsverfahren, Hash-Funktionen (zur Erstellung von MACs und Schlüsssel), Zertifikatformaten und asymmetrischen Schlüsseltauschalgorithmen gesandt, welche vom Client unterstützt werden.

Die CLIENT-HELLO Nachricht muß die erste sein die der Client an den Server schickt. Nachdem die Nachricht abgeschickt ist, wartet der Client auf die SERVER-HELLO Nachricht. Jede andere empfangene Message erzeugt eine PCT-ERR-ILLEGAL-MESSAGE Error.

            7.3.2.2 SERVER-HELLO

Der Server sendet diese Nachricht nachdem er die CLIENT-HELLO Nachricht erhalten hat. Sie enthält den Connection-Id, Server Certificate (nur bei neuer Session), Server´s Cipher-, Hash-, Server-Certificate- und Key-Exchange Specification Choices, Challenge Response (bei Restart Session) - wenn die Authentifizierung des Clients verlangt wird zusätzlich den Signature Type und die Client-Certificate und Specification Lists.

Zu Beginn wird die Version Number geprüft und ein zufälliger Wert von 32 Bytes im CONNECTION-ID Feld an den Client retourniert.

Dann wird die SESSION-ID geprüft. Es gibt zwei mögliche Fälle der Reaktion des Servers.

Im ersten Fall schickt der Server ein RESTART-SESSION-OK mit Wert Null wenn die CLIENT-HELLO Nachricht keinen SESSION-ID beinhaltet oder ein übermittelter SESSION-ID vom Server nicht erkannt wird. Der Server untersucht dann die oben erwähnten vier Listen und retourniert in den Datenfeldern (SH-CIPHER-SPECS-DATA, etc.) jene Typen, die von ihm unterstützt werden. Außerdem wird im CERTIFICATE-DATA Feld das Zertifikat des Servers übersandt.

Im zweiten Fall schickt der Server ein RESTART-SESSION-OK ungleich Null, wenn er den SESSION-ID in seinem Cache gefunden hat. Dann setzt er in die Datenfelder der Verschlüsselungsverfahren, Hash-Funktionen, etc. die bereits bekannten Werte aus dem SESSION-ID ein. Außerdem werden die RESPONSE-DATA von einer Funktion aus SERVER-MAC-KEY, CH-CHALLENGE-DATA, CH-SESSION-ID-DATA (aus der CLIENT-HELLO Nachricht) und SH-CONNECTION-ID-DATA gebildet.

Wenn der Server die Authentifizierung des Clients verlangt, wird das CLIENT-AUTH-REQ Feld auf einen Wert ungleich Null gesetzt. Außerdem werden die möglichen Zertifikattypen und Unterschrift-Algorithmen in den zugehörigen Datenfeldern (CLIENT-CERT-SPECS-DATA und CLIENT-SIG-SPECS-DATA) übermittelt.

Wenn der Client die SERVER-HELLO Nachricht erhält wird zuerst geprüft ob der Server die Wiederaufnahme einer alten Verbindung akzeptiert oder eine neue Session initialisiert hat.

Kann der Client im Falle einer neuen Session ein kompatibles Zertifikat zur Verfügung stellen wird dies in der folgenden CLIENT-MASTER-KEY Nachricht getan. Andernfalls schickt er einen SPECS-MISMATCH Error.

Wenn es sich um eine alte Session handelt erzeugt der Client den neuen CLIENT-WRITE-KEY, SERVER-WRITE-KEY, CLIENT-MAC-KEY UND SERVER-MAC-KEY gemäß den Cipher-Specific Rules. Anschließend wird geprüft ob der Inhalt des RESPONSE-DATA Feldes mit dem vom Client kalkulierten Wert übereinstimmt. Ist dies der Fall so beginnt der Client mit der Übermittlung der Applikationsdaten (bzw. sendet im negativen Fall einen SERVER-AUTH-FAILED Error).

            7.3.2.3 CLIENT-MASTER-KEY

Diese Nachricht wird vom Client verschickt nachdem er die SERVER-HELLO Nachricht erhalten hat und es sich um eine neue Session handelt, oder der Server die Authentifizierung des Clients anfordert. Die CLIENT-MASTER-KEY Message wird nicht gesendet wenn eine alte Verbindung wieder aufgenommen wird und eine Authentifizierung des Clients nicht verlangt wird.

Die CLIENT-MASTER-KEY Nachricht enthält, wenn es sich um eine neue Session handelt, den mit dem öffentlichen Schlüssel des Servers verschlüsselten Master Key (dieser wird zur Erzeugung des CLIENT-WRITE-KEY, SERVER-WRITE-KEY, CLIENT-MAC-KEY und SERVER-MAC-KEY verwendet), die Authentifizierung der vorangegangenen zwei Nachrichten (CMK-VERIFY-PRELUDE-DATA - eine Hash-Funktion aus CLIENT-MAC-KEY, CLIENT-HELLO und SERVER-HELLO), und (falls verlangt) Daten zur Authentifizierung des Clients. Falls es sich um die Wiederaufnahme einer alten Session handelt werden das Zertifikat des Clients und die Challenge Response des Clients geschickt.

Nach Empfang der CLIENT-MASTER-KEY Nachricht erzeugt der Server aus dem Master Key ebenfalls einen neuen CLIENT-WRITE-KEY, SERVER-WRITE-KEY, CLIENT-MAC-KEY und SERVER-MAC-KEY. Anschließend werden der Wert der VERIFY-PRELUDE-DATA und (optional) das Zertifikat des Clients sowie die Client Response auf ihre Korrektheit und Gültigkeit überprüft. Wenn alle Checks erfolgreich verlaufen schickt der Server die SERVER-VERIFY Nachricht; im negativen Fall eine Fehlermeldung (INTEGRITY-CHECK-FAILED, BAD-CERTIFICATE oder CLIENT-AUTH-FAILED).

            7.3.2.4 SERVER VERIFY

Diese Nachricht wird vom Server abgeschickt nachdem er eine gültige CLIENT-MASTER-KEY Nachricht vom Client erhalten hat. Die Nachricht enthält die Session Id (32 bytes Länge) und die Server Response Daten. Diese werden durch eine Hash Funktion aus SERVER-MAC-KEY, CH-CHALLENGE-DATA, SH-CONNECTION-DATA und SV-SESSION-ID-DATA erzeugt.

Wenn der Client diese Nachricht erhält, wird die Korrektheit der Response Daten geprüft und im positiven Fall mit der Übertragung der Applikationsdaten begonnen. Im negativen Fall (der vom Client erzeugte Hash-Wert stimmt nicht mit dem übermittelten überein) entsteht ein SERVER-AUTH-FAILED Error.

        7.3.3 Zusammenfassung

Abschließend wird der Ablauf des PCT Protokolls bei neuer bzw. Wiederaufnahme einer alten Session zusammengefaßt.

            7.3.3.1 Ablauf des PCT Protokolls bei neuer Session

Nachricht	zwingend/optional	Inhalt	Schlüssel
Client-Hello	zwingend	Client Challenge, Client's Cipher, Hash, Server-Certificate und Key-Exchange Specification Lists
Server-Hello	zwingend	Connection-Id/Challenge Server Certificate Server's Cipher, Hash, Server-Certificate und Key-Exchange Specification Choices optional: Server's Signature-Type und Client-Certificate Specification Lists
Client-Master-Key	zwingend	Master Key Authentication der vorangegangenen zwei Nachrichten optional: Client's Signature-Type und Client-Certificate Specification Choices, Client's Certificate, Client's Challenge Response	Master Key verschlüsselt mit dem Public Key des Servers
Server-Verify	zwingend	Session-Id Server's Challenge Response

            7.3.3.2 Ablauf des PCT Protokolls bei Wiederaufnahme einer alten Verbindung

Nachricht	zwingend/optional	Inhalt	Schlüssel
Client-Hello	zwingend	Client Challenge Session -Id Client's Cipher, Hash, Server-Certificate, und Key-Exchange Specification Lists
Server-Hello	zwingend	Connection-Id/Challenge old Session's Cipher, Hash, Server-Certificate, und Key-Exchange Specification Choices Server's Challenge Response optional: Server's Signature-Type und Client-Certificate Specification Lists
Client-Master-Key	optional	Client's Certificate Client's Challenge Response
Server-Verify	optional

        7.3.4 ZERTIFIKATTYPEN IN PCT

Version 1 erlaubt folgende Zertifikattypen:

        7.3.5 Unterschiede zwischen PCT und SSL

PCT besteht aus  maximal vier Nachrichten (im Minimum kommt PCT mit zwei Nachrichten aus - SSL benötigt mindestens fünf Messages)

größere Auswahl an kryptografischen Algorithmen und Formaten. In PCT wird zusätzlich zum Cipher Type und Server Certificate Type ein Hash Function Type und Key Exchange Type ausgehandelt. Wenn eine Authentifizierung des Clients verlangt wird, werden auch ein Client Certificate Type und Signature Type ausgehandelt.

PCT verwendet für die Nachrichten-Authentifizierung nicht die Encryption Keys. Deshalb können die Message Authentication Keys auch viel länger sein als die Encryption Keys.

die PCT Authentication Challenge Response des Clients hängt von der Verschlüsselungsart ab die für diese Session ausgehandelt wurde (SSL Client Authentication ist davon unabhängig)

8 Literatur

Document converted from word 8 by MSWordView (mswordview 0.5.2)
MSWordView written by Caolan McNamara