Statusprüfung von Zertifikaten mit CRL und OCSP, bewertet auf Basis des aktuellen Umfelds von UBS Diplomarbeit DA Sna 04/01

Transkript

1 Statusprüfung von Zertifikaten mit CRL und OCSP, bewertet auf Basis des aktuellen Umfelds von UBS Diplomarbeit DA Sna 04/01 Betreuender Dozent: Firmenpartner: Studierende: Herr Prof. Dr. sc. techn. ETH, Andreas Steffen UBS, Identity Management, Zürich Nadja Holenstein, Colette Pfister Abgabetermin: 25. Oktober 2004 Studiengang Kommunikation und Informatik Zürcher Fachhochschule Winterthur (ZHW)

2 Inhaltsverzeichnis Management Summary... 4 Abstract... 5 Aufbau der Arbeit... 6 Abgrenzung... 6 Verwendete Informationsquellen... 7 Gliederung Grundlagen Zusammenfassung Anforderung an eine sichere Infrastruktur Kryptographie, Kryptologie, Kryptoanalyse Verschlüsselungsstärke Digitale Signaturen Public Key Infrastructure (PKI) Digitales Zertifikat ASN Die Microsoft CryptoAPI Ist-Situation der UBS Zusammenfassung Ist Situation Soll-Situation im Bereich Wealth Management & Business Banking (WMBB) Probleme Certificate Revocation List (CRL) Zusammenfassung Einleitung Gültigkeit und Revokation von Zertifikaten Gründe für die Revokation eines Zertifikats Sperrlisten Inhalt einer Certificate Revocation List Funktionsweise der Zertifikatsstatus-Überprüfung mittels CRL CRL Distribution Point Nachteile von CRLs Delta CRL Funktionsweise der Delta CRL Client Prozessing Auswahl des richtigen CRL Typs Verzeichnisdienst-Anbindung Erstellen eines CRL Publikationsplans Grundfragen, auf denen die Publikationsplanung basieren sollte Zwischengespeicherte CRLs CRL Overlap CRL Partitionierung Zuverlässigkeit und Verfügbarkeit der CRL CRL Struktur Online Certificate Status Protocol (OCSP) Einleitung Zugriffsart: Online Abfrage mit externem OCSP-Server Zugriffsart: Online Abfrage mit integriertem Responder Die OCSP Modelle Kodierung des OCSP Protokoll Zertifikatsstatus Exception Case Zeiten in einer OCSP-Response Transportart über HTTP

3 4.10 Abspeichern von Antworten Transportart über Schlüssel des OCSP-Responders, Signierungsart des OCSP Microsoft Lösungen Historisches OCSP-Anfrage/Archive Cutoff Optimierung durch Pre-Production Response und Response-Caching Einsatzgebiete von OCSP Sicherheitsüberlegungen Risiken eines kompromittierten OCSP-Signaturschlüssels Revokation von OCSP-Schlüsselzertifikaten OCSP-Struktur Extensions OCSPv OCSPv2 Drafts Simple Certificate Validation Protocol (SCVP) Zusammenfassung Entstehung von SCVP Simple Certificate Validation Protocol Delegated Path Validation (DPV) Delegated Path Discovery Validation Policies Protokollabläufe Abfragungsmöglichkeiten mit SCVP SCVP Use Cases Sicherheitsüberlegungen SCVP Server Relay SCVP Struktur Überprüfung der Policy Antworten Produkte OCSP und SCVP Technische Facts Certificate Revocation List (CRL) Online Certificate Status Protocol (OCSPv1) Direkter Vergleich zwischen CRL und OCSP SCVP Mögliche Lösung für die UBS Erkenntnisse Einleitung CRL OCSP SCVP Schlusswort Dank Glossary Quellenverzeichnis Anhang

4 Abbildungsverzeichnis Abbildung 1: symmetrische Kryptographie Abbildung 2: Asymmetrische Kryptographie Abbildung 3: Signatur Abbildung 4: Signatur mit Verschlüsselung Abbildung 5: Public Key Infrastructure Abbildung 6: Certification Practice Statement (CPS) Abbildung 7: X.509-Zertifikat [11] Abbildung 8: Aufbau CryptoAPI Abbildung 9: Ist-Situation UBS AG Abbildung 10: aktuelle Persauth-Karte Abbildung 11: Soll-Situation UBS AG Abbildung 12: neue Smartcard Abbildung 13: Sichtweise von Microsoft Outlook [19] Abbildung 14: Message Security Properties [19] Abbildung 15: Informationen zur Zertifikatskette [19] Abbildung 16: Zertifikats-Kettenbildung Abbildung 17: CRL-Inhalt [50] Abbildung 18: Funktionsweise der Statusabfrage am Beispiel von Routern Abbildung 19: Delta-CRL Abbildung 20: Delta CRL Mechanismus Abbildung 21: Entscheid für den richtigen CRL-Typ Abbildung 22: Funktion von OCSP Abbildung 23: Informationsbeschaffung Abbildung 24: Online Abfrage mit externem OCSP-Server Abbildung 25: Online Abfrage mit integriertem Responder Abbildung 26: Zugriff via CRL Abbildung 27: klassisches Modell Abbildung 28: Rivest-Idee Modell Abbildung 29: Self-signed OCSP-Server Abbildung 30: CA-Responder Abbildung 31: Authorized Responder Abbildung 32: Angestrebte Lösung der UBS Abbildung 33: Retension-Intervall Abbildung 34: Achive Cutoff Abbildung 35: OCSP-Request [50] Abbildung 36: OCSP-Response [50] Abbildung 37: Validierung durch Server (Delegated Path Validation, DPV) Abbildung 38: Validierung durch Client (Delegated Path Discovery, DPD) Abbildung 39: Use Case I Abbildung 40: Use Case II Abbildung 41: Use Case III Abbildung 42: Use Case IV Abbildung 43: Problematik der Gültigkeitsperiode Abbildung 44: Mögliche Lösung für UBS

5 Management Summary Die vorliegende Diplomarbeit zeigt das komplexe Thema der Zertifikatsstatusprüfung auf. Sie liefert dem Information Security Management der UBS AG wichtige Aspekte über die gängigen Mechanismen, mit denen die Zertifikatsstatusprüfung vorgenommen werden kann. Zur Gewährleistung der Sicherheit, nimmt das Sperren von einzelnen Zertifikaten beim Betreiben einer PKI eine wichtige Funktion ein. Einem Zertifikat muss vorzeitig das Vertrauen entzogen werden, wenn das Schlüsselmaterial eines Zertifikatsinhabers kompromittiert wurde oder wenn zum Beispiel der Name des Zertifikatsinhabers sich geändert hat. In solchen Fällen wird das Zertifikat gesperrt und für ungültig erklärt. Die für ungültig erklärten Zertifikate werden in so genannten Revokationslisten veröffentlicht. Benutzer können diese Revokationslisten konsultieren und den aktuellen Status eines Zertifikates abfragen. Wurde das Zertifikat revoziert, dann ist es ungültig. Eine Möglichkeit zur Statusabfrage bieten die Certificate Revocation List (CRL) und das Online Certificate Status Protocol (OCSP). CRL ist das klassische Sperrlisten-Verfahren und einfachste Art der Zertifikatssperrung. Eine CRL ist eine periodisch erstellte Liste, auf der alle gesperrten Zertifikate veröffentlicht werden. Jede Liste ist mit einem Zeitstempel versehen und von einer Vertrauensstelle signiert. OCSP ist ein Protokoll, das analog zu CRL den aktuellen Zustand eines Zertifikats abfragt. Es wurde vor allem für die zeitnahe Statusprüfung bei kritischen Transaktionen konzipiert, um eine Alternative zum bisherigen klassischen Sperrlisten-Verfahren zu bieten. Im Vergleich zu statischen, periodisch veröffentlichten CRLs ermöglicht OCSP eine dynamische Abfrage des aktuellen Sperrstatus eines einzelnen Zertifikats. Als Antwort wird ein eindeutiger Zertifikatsstatus zurückgeliefert - "good", "revoked" oder "unknown". Auch diese Antworten werden signiert und zwar von einem zwischengeschalteten OCSP-Server. Im Mittelpunkt dieser Diplomarbeit steht die Analyse zwischen den zwei Standardverfahren CRL und OCSP. Die Diplomarbeit beschreibt, vergleicht und bewertet Leistungsmerkmale und Einsatzszenarien von CRL und OCSP. Die Möglichkeiten wie die Antworten des OCSP-Servers signiert werden können, bilden einen weiteren Schwerpunkt. Denn die strengen Vorgaben für die Verwendung der Signing Keys im OCSP Standard führen zu einem manuellen Key- Management, welches in der UBS eigentlich nicht praktikabel ist. Während unseren Recherchen über die Signaturproblematik von OCSP sind wir auf ein weiteres Protokoll gestossen. Das Protokoll heisst Simple Certificate Validation Protocol (SCVP). Dieses weist neben der reinen Statusüberprüfung noch weitere Funktionen auf. Da es in der Frage der Server-Signatur offener und flexibler ist, könnte es das Problem der Signatur lösen. Es ist aber noch kein Standard, sondern erst in einem Internet-Draft spezifiziert. Mit dem Resultat unserer Diplomarbeit existiert nun ein Lösungsvorschlag für die UBS. Die Lösung könnte in Erwägung gezogen werden, sobald das Protokoll SCVP von der Internet- Engineering-Task-Force (IETF) zum Standard erklärt wird und in Form von Client- und Serverimplementierungen Verbreitung findet. 4

6 Abstract This work is based on the direct environment of the UBS AG. It faces the problem of the controlling and closing of the validity of certificates. The analysis of discussions of how to check if a Certificate is valid or revoked reveals two major concepts behind validation and the need for revocation of certificates. These consists of periodic revocation mechanisms such as Certificate Revocation Lists (CRLs) and online query mechanisms such as the Online Certificate Status Protocol (OCSP). The CRL is generally the preferred model. It is a periodically published data structure that contains a list of revoked certificate serial numbers. The CRL is time-stamped and digitally signed by typically the issuer of the certificate. Currently the preferred online revocation mechanism amongst standards and implementations is the Online Certificate Status Protocol (OCSP). The basic process consists of a request/response protocol that obtains online revocation information from a trusted entity referred to as an OCSP Responder, with all responses being digitally signed. Within this work we will concentrate on this two fundamental revocation concepts of periodic and online revocation. The advantage and disadvantage of the till now known mechanism are described and evaluated. Furthermore this work contains a discussion about the possibilities of how a OSCP-answer can be signed. It is important to prove to the inquirer that the OCSPanswers originate from the expected OCSP-server. During our research we came up against another protocol which has got additional functions to the ones mentioned above. This protocol is called Simple Certificate Validation Protocol (SCVP). It isn t standard yet, but specified in a Internet-Draft. Where there aren t any time critical inquiries to be made, the CRL s are a good solution for the UBS environment. The strict guidelines for the usage of the signing Keys in the OCSP standard lead to a manual key management which is not practicable in UBS. However the SCVP fulfils the signed answers issue and offers more flexibility. With the result of our diploma thesis we created a proposition for a solution, which could be considered in a middle-term, as soon as the SCVP protocol is declared as standard from the IETF. Furthermore it has to be implemented on clients and servers. 5

7 Aufbau der Arbeit In einem ersten Teil wird das am weit verbreitetsten Standardverfahren Certificate Revocation List (CRL), dass im RFC 3280, definiert ist, analysiert. Da Windows XP, einen zertifikatsbasierten Login verlangt, und derzeit nur Zertifikatsstatusprüfung mittels CRL unterstützt, wird die UBS diesen Mechanismus weiterhin einsetzen. Bei einer umfangreichen PKI Umgebung, wie dies bei UBS der Fall ist, kann die CRL sehr gross werden und bei der Verteilung im Netzwerk zu Performanceproblemen führen. Eine Möglichkeit die übertragene Datenmenge zu beschränken sind Delta CRLs. Eine Delta-CRL erhält lediglich Änderungen im Bezug auf die zuletzt von der CA herausgegebene vollständige CRL. Somit können Sie häufiger publiziert werden und benötigen weniger Bandbreite. In dieser Teilaufgabe wird vor allem auf die Publikation und Verfügbarkeit der CRL ein besonderes Augenmerk gelegt. Ein zweiter Teil der Arbeit besteht aus der Analyse eines im Juni 1999 von der Internet- Engineering-Task-Force (IETF) als Standard angenommenes Verfahren Online-Certificate-Revocation-Protocol - OCSP (RFC 2560). Eigentlich entspricht OCSP dem UBS Konzept, da es aktuellere Sperrinformationen ermöglicht, als dies mit periodisch herausgegebenen CRLs möglich ist. Das momentan in der UBS eingesetzte OCSP Protokoll arbeitet auf der Basis von CRLs. Dass heisst, die Antworten werden auf der Basis von CRLs gegeben. Damit geht zwar der Vorteil der Aktualität der Auskünfte verloren, aber es bietet für die Anwendungs-Infrastruktur eine zusätzliche Möglichkeit zur Verwaltung und Bereitstellung von Sperrlisten. Das Problem bei OCSP liegt bei der Signierung der OCSP-Antworten. Die jetzigen OCSP-Antworten werden mit einem self-signed Zertifikat signiert. Dabei muss jeder Client, der eine OCSP-Antwort empfangen möchte, das self-signed Zertifikat bei sich lokal konfiguriert haben. Wenn sich der Schlüssel des OCSP-Servers aber jemals ändert, stellt dies ein problematisches Unterfangen dar, da jeder Client neu konfiguriert werden müsste. Die für die UBS geeignete Lösung entspricht nicht dem OCSPv1 Standard. Im Mittelpunkt steht daher die Analyse über die OCSP Version 2, die noch mehr Funktionalitäten als OCSP Version 1 aufweist und die Signierung der OCSP-Anworten weniger stark einschränkt. Wir mussten jedoch feststellen, dass sich OCSPv2 nicht als Standard etablieren wird, sondern ein neues Protokoll SCVP, das erst in Form eines Internet-Drafts besteht. SCVP ist als Obermenge von OCSP zu verstehen, bei der zusätzlich zu den Statusinformationen weitere Zertifikatsprüfungen abgefragt werden können. Im Gegensatz zu OCSP ermöglicht das Protokoll SCVP dem Client ein partielles bis vollständiges Auslagern der Zertifikatsvalidierung. In dieser Teilaufgabe wird die bis jetzt in der UBS eingesetzte OCSP-Lösung, die Wunschlösung und die damit verbundenen Probleme beschrieben. Weiter wird auf das neue Protokoll SCVP und deren neuen Funktionalitäten eingegangen. Zum Schluss wird eine mögliche Lösung, die für die UBS in Frage käme, aufgezeigt. Abgrenzung Die vorliegende Arbeit beschränkt sich auf die Revokationsmechanismen, die in den aktuellen und zukünftigen Standards unterstützt werden. 6

8 Verwendete Informationsquellen Die Public Key Infrastruktur ist ein relativ umfangreiches und dynamisches Gebiet. Es ist zwar bereits vieles in Buchform erhältlich, doch die enthaltenen Informationen sind oftmals bereits wieder veraltet. Die wichtigsten Informationen entnahmen wir direkt aus den Request-for-Comments (RFC). Sie bilden die Grundlage für viele Internet relevante Protokolle. Diese RFCs werden von der IETF kostenlos im Internet publiziert. Im Verlaufe der Verabschiedung eines solchen Standards entstehen mehrere vorläufige Internet- Drafts. Nach der Veröffentlichung als RFC stehen diese Drafts im Allgemeinen nicht mehr zur Verfügung. Dennoch können sie wertvolle Hinweise liefern, warum im endgültigen Standard eine Entscheidung zugunsten der einen anstatt der anderen Lösung getroffen wurde. Weiter sind die Internet-Drafts in der Regel nur für 6 Monaten gültig. Bei der Analyse von OCSPv2 stiessen wir auf keinen einzigen Internet-Draf, der für uns relevant und noch nicht abgelaufen war. Hilfreich beim Nachvollziehen der Entwicklungsgeschichte ist auch das Archiv der IETF-PKIX- Mailingliste. 1 Zusätzlich konnten wir aus einigen Diplomarbeiten verschiedene grundlegende Informationen entnehmen. Neben internen Ansprechspersonen konnten wir via mit vielen verschiedenen kompetenten Personen in Kontakt treten und haben ihre Aussagen in diese Arbeit einfliessen lassen. 1 http: // 7

9 Gliederung Kapitel 1 - Grundlagen In diesem Kapitel werden verschiedene technische und kryptographische Grundlagen beschrieben. Wir beschränkten uns auf die Themen der symmetrischen und asymmetrischen Verschlüsselung, digitale Signaturen und Public Key Infrastructure mit all ihren Bestandteilen. Des Weiteren wird noch auf die ASN.1-Codierung und die Microsoft Schnittstelle CryptoAPI eingegangen. Kapitel 2 - Ist-/Soll-Situation UBS Das Kapitel 2 beschreibt die aktuelle PKI-Situation der UBS. Des Weiteren wird das angestrebte Ziel und die damit verbundenen Probleme des Bereichs Wealth Management & Business Banking (WMBB) dargestellt. Kapitel 3 - Certificate Revocation List (CRL) Das Kapitel 3 gibt einen Überblick über den Revokationsmechanismus CRL. Microsoft unterstützt momentan standardmässig CRL und deshalb wird CRL vor allem im Kontext mit Microsoft diskutiert. In der Windows 2003 CA werden zusätzlich noch Delta CRLs unterstützt. Die Vorteile von Delta CRLs werden hier aufgezeigt. Weiter ist beschrieben, was beim Einsatz von CRLs und Delta CRLs besonders beachtet werden muss. Da die Publikation von einer CRL einen entscheidenden Faktor ist, wird dieses Thema detailliert ausgeleuchtet. Die ASN.1 Struktur einer CRL wird am Schluss aufgeführt. Das Kapitel 4 - Online Certificate Status Protocol (OCSP) In diesem Kapitel sind neben den verschiedenen OCSP-Modellen, Signierungsvariationen und Statusabfragungsarten die Einzelheiten einer OCSP-Request und Response zu finden. Weiter wird erläutert, welche Problematik eine OCSP-Lösung im Umfeld der UBS-PKI darstellt. Die Marktsituation wie auch einige Sicherheitsüberlegungen fehlen in diesem Kapitel nicht. Und wie im Kapitel 3 (CRL) wird die Darstellung der ASN.1 Definition für Request und Response aufgeführt. Der Abschluss bildet die Diskussion über die Version 2 von OCSP (OCSPv2). Im Kapitel 5 - Simple Certificate Validation Protocol (SCVP) Hier wird ein weiterer Mechanismus für die Statusabfragung vorgestellt. SCVP ist zwar noch zu keinem Standard erhoben worden, es stellt aber ein Protokoll mit Potential dar. SCVP wird als Nachfolger von OCSPv2 gehandelt und weist natürlich im Gegensatz zu OCSP einige Erweiterungen auf. Diese werden hier aufgezeigt. Im Wesentlichen sind die Erweiterungen mit den zusätzlichen Protokollen Delegated Path Discovery (DPD) und Delecated Path Validation (DPV) abgesteckt. Die Sicherheitsüberlegungen und die ASN.1 Struktur von SCVP runden dieses Kapitel ab. Kapitel 6 - Produkte OCSP und SCVP Das Kapitel 6 zeigt anhand einer Tabelle verschiedene Produkte für OCSP und SCVP und zeigt einzelne Äusserungen einiger Hersteller auf. Kapitel 7 - Technische Facts Die signifikanten Punkte der vorangehenden Themen werden hier nochmals zusammen getragen und erläutert. Es flossen hier auch einige Meinungen und Äusserungen von UBS- Mitarbeitenden ein, die in keinen Unterlagen nachgelesen werden können. Aus diesen Facts erarbeiteten wir den Lösungsvorschlag für die UBS. Kapitel 8 - Mögliche Lösung für die UBS Auf die konkreten Fragen von UBS wird hier eine Antwort formuliert. Diese Antwort steht jedoch in der Abhängigkeit von SCVP, welches ja noch nicht als Standard etabliert werden konnte. Trotzdem stellt dieses Kapitel, neben der Analyse über die Mechanismen der Statusabfrage, einen wichtigen Schwerpunkt unserer Arbeit dar. 8

10 Kapitel 9 - Erkenntnisse In diesem Kapitel werden alle unsere technischen Erkenntnisse, die wir während unserer Arbeit sammelten, aufgezeigt und umschrieben. Anhang Im Anhang ist der CRL-Test zu finden. 9

11 1 Grundlagen Es ist uns bewusst, dass das Kapitel Grundlagen sehr umfangreich ist. Während der Arbeit ist uns aber aufgefallen, dass es wichtig ist die grundlegenden kryptographischen Konzepte und Abläufe einer PKI zu kennen. Personen, die schon über ein sehr gutes Wissen an Information Security verfügen, können das ganze Kapitel überspringen oder mittels Zusammenfassung sich kurz in die Thematik einlesen. Die einzelnen Verschlüsselungs-Algorithmen haben wir nur kurz erklärt. Für eine genauere Informationsbeschaffung verweisen wir auf einschlägige Literatur. Weiter findet man im Internet auch viele Unterlagen, die jedoch mit Vorsicht zu geniessen sind. Diese Verschlüsselungs-Algorithmen genau zu erläutern würde den Rahmen dieser Arbeit sprengen. Da wir während unserer Arbeit in der UBS mit einem Kryptologen sprechen konnten, wollten wir einige Informationen unbedingt einfliessen lassen. Das Gespräch war sehr interessant und das zuvor abstrakte Wissen über die Algorithmen bekam einen lebendigen Input. Für das allgemeine Verständnis der Funktionsweise von ASN.1 ist fast am Ende der Grundlagen ein Kapitel gewidmet. Das X.509v3 Zertifikat hat einen ASN.1-Strukturaufbau, wie auch die Certificate Revocation List (CRL) und das Online Certificate Status Protocol (OCSP). Zu guter Letzt wird noch auf die Schnittstelle CryptoAPI von Microsoft eingegangen, da diese im Zusammenhang mit der Zertifikatsstatusprüfung auf der Client-Seite eine wichtige Funktion einnimmt. 1.1 Zusammenfassung Die wichtigen Anforderungen an ein sicheres System sind Integrität, Authentizität, Vertraulichkeit und Nichtabstreitbarkeit. Um diese Anforderungen umzusetzen, werden verschiedene kryptografische Elemente eingesetzt. Ein Grundstein der PKI ist die asymmetrische Verschlüsselung, die im Gegensatz zur symmetrischen Verschlüsselung mit zwei verschiedenen Schlüsseln funktioniert. Der Nachteil des sicheren asymmetrischen Verfahrens ist die höhere benötigte Rechenleistung. Das Hybridverfahren kombiniert die asymmetrische und symmetrische Verschlüsselungstechnik. Dies bedeutet, dass für die Verschlüsselung des zu übermittelnde Textes das schnellere symmetrische Verfahren gewählt wird. Den Schlüssel, der für die Verschlüsselung benötigt wird, verschlüsselt man mit einem asymmetrischen Algorithmus und übermittelt so den chiffrierten Text und den verschlüsselten "Session Key" an den Empfänger. Für die Integrität bürgt eine Hashfunktion. Es ist zwar keine Ver- oder Entschlüsselungsfunktion, aber sie ist in einer PKI (Public Key Infratructure) und vor allem für die digitale Unterschrift unerlässlich. Wie eine digitale Signatur aufgebaut ist kann in Kapitel 1.4 nachgelesen werden. Unter einer PKI versteht man eine umfassende Aufbau- und Ablauforganisation, die vor allem den nicht miteinander bekannten Mitgliedern die gegenseitige Authentisierung und vertrauliche Kommunikation über ein unsicheres Netzwerk ermöglicht. Die PKI besteht aus einer Benutzerkomponente, einer Certificate Authority, einer Registrierungstelle, einem Directory Service und den Sicherungsmodulen HSM (Hardware Security Module) und PSE (Personal Security Environment). Relevant sind natürlich auch die Sicherheitsapplikationen, welche auf die PKI zugreifen. Die Certificate Policy (CP) und Certification Practice Statement (CSP) beschreiben einerseits die Ausgabe und Verwendung der Zertifikate und andererseits die betrieblichen Vorgänge einer PKI. Ein digitales Zertifikat soll garantieren, ob der Absender wirklich zu einem spezifischen öffentlichen Schlüssel gehört. In dieser Diplomarbeit wird immer von einem X.509 Zertifikat gesprochen. Ein solches Zertifikat enthält Informationen, mit welchen sich der Empfänger von der Glaubwürdigkeit des erhaltenen Dokumentes und der Identität des Absenders überzeugen kann. Ein wichtiger Teil dieser Arbeit, ist die Zertifikatssperrung. Ein Mechanismus muss die Zertifikate revozieren können. Nur so kann gewährleistet werden, dass eine vertrauenswürdige PKI betrieben werden kann. Es gibt verschiedene Gründe, weshalb ein Zertifikat vor dem eigentlichen Ablaufdatum ungültig wird. 10

12 Für die Beschreibung der Datenstrukturen zum Beispiel eines Zertifikates wird die Abstract Syntax Notation One (ASN.1) verwendet. Diese Notation liegt auch einer CRL (Certificate Revocation List) oder OCSP-Response/Request (Online Certificate Status Protocol) zu Grunde. ASN.1 ist ein ITU-T Standard, um Datentypen und -werte unabhängig zu beschreiben. Für die Codierung wird dann im Zusammenhang mit Zertifikaten Distinguished Encoding Rules (DER) verwendet. Häufig verweisen wir auf die CryptoAPI von Microsoft, deshalb wird sie hier am Schluss dieses Kapitels erwähnt. Diese Schnittstelle wird von den Clients eingesetzt um die Zertifikats-Status- Prüfung und die Zertifikatskettenbildung durchzuführen. Applikationen, die auf diese Schnittstelle zugreifen, können weiter mit leistungsfähigen verschlüsselungsbasierte Sicherheits- Features erweitert werden. 1.2 Anforderung an eine sichere Infrastruktur Systeme, Anwendungen und insbesondere die darin verarbeiteten und verwalteten Informationen, die über öffentliche Netze zugänglich sein müssen, sind interessante Angriffspunkte für Hacker und kriminelle Organisationen. Die verfolgten Ziele sind dabei ganz unterschiedlich. Sie reichen vom einfachen Spieltrieb, über Vandalismus, Sabotage, Betrug bis hin zur gezielten Spionage. Es ist die Aufgabe die Daten zu schützen und bei der Übertragung zu sichern, so dass die Daten zu dem richtigen Empfänger gelangen. Bei einem Gespräch ist die Identität der Kommunikationspartner in der Regel zweifelsfrei gegeben und bei Vereinbarungen können Zeugen herbeigezogen werden. Die persönliche Unterschrift gilt bei der Kommunikation in Schriftform als wichtigste Absicherung. Bei der im Internet typischen Kommunikation besteht jedoch keine entsprechende Lösung. Die Kommunikationspartner können sich also weder auf die Vertraulichkeit der Kommunikation verlassen, noch darauf, dass ihr "Gegenüber" wirklich die Person ist, für die sie sich ausgibt. Die so genannte Public-Key-Infrastructure PKI stellt für die sichere Kommunikation im Internet geeignete kryptographische Massnahmen zur Verfügung. Für den Ablauf einer sicheren Kommunikation gibt es folgende zentrale Sicherheitsziele: Integrität Die Nachricht soll unverändert den Empfänger erreichen und muss vor Manipulationen geschützt werden. Authentizität Die Herkunft der Nachricht muss eindeutig sichergestellt sein und der Absender einer Nachricht eindeutig identifiziert. Vertraulichkeit Nur berechtigte Personen dürfen die Nachricht lesen, die für sie bestimmt ist. Nichtabstreitbarkeit Bei gewissen Geschäftsprozessen ist es wichtig, dass eine Aussage nachweislich gemacht wurde und später nicht bestritten werden kann. Verfügbarkeit Die Geschäftsprozesse müssen fristgerecht abgewickelt werden. Verbindlichkeit Integrität, Verfügbarkeit und Nachvollziehbarkeit ist in der Verbindlichkeit mit eingeschlossen. Daten müssen jederzeit authentisch und korrekt sein. Nachvollziehbarkeit Die verschiedensten Daten müssen zu jedem Zeitpunkt des Life Cycles rekonstruiert werden können. Hiernach müssen die Daten authentisch, vor Manipulation geschützt und über einen längeren Zeitraum aufbewahrt werden. 11

13 1.3 Kryptographie, Kryptologie, Kryptoanalyse Die Kunst geheimer Schriften basiert auf besonderen Verfahren und Methoden. Die Kryptologie ist die Wissenschaft der Verschlüsselung und der Entschlüsselung von Informationen und stellt somit den Oberbegriff dar. Die Kryptologie lässt sich in die Kryptographie, Steganographie und Kryptoanalyse einteilen. Die Kryptographie ist die Lehre der Verschlüsselung von Informationen (Geheimschriften), die Steganographie des Versteckens von Informationen und die Kryptoanalyse des Entschlüsselns von Informationen ohne Kenntnisse des Schlüssels. Eine Grundlage für digitale Signaturen und die Verschlüsselung von Daten bilden heute so genannte Public-Key-Verfahren. Nur mit den mathematischen Algorithmen ist zwar ein sicheres jedoch kein leistungsfähiges Signatur- oder Verschlüsselungssystem aufgebaut. Es benötigt einen breiten Einsatz kryptographischer Verfahren um überhaupt die Existenz solcher Verfahren zu sichern. Grundsätzlich gibt es zwei Arten von Verschlüsselungsalgorithmen, die sich in ein symmetrisches und asymmetrisches Verfahren unterscheiden lassen. [1], [2], [3], [4] Symmetrische Kryptographie Abbildung 1: symmetrische Kryptographie Der Empfänger und der Sender tauschen einen geheimen Schlüssel aus, mit dem sie die Nachricht zuerst verschlüsseln und dann mit dem gleichen Schlüssel wieder entschlüsseln. Die Nachricht kann von jedem, der den geheimen Schlüssel besitzt einfach entschlüsselt werden und darf deshalb nur berechtigten Empfängern bekannt sein. Die grosse Problematik liegt im Umfang des Schlüsselmanagement und des Schlüsselaustausches, insbesondere die Bereitstellung eines sicheren Kanals. Die Anzahl der maximal nötigen verschiedenen Schlüssel beträgt bei n Kommunikationspartnern n*(n-1)/2. Wollen zum Beispiel 5 Personen sicher kommunizieren, so müssen insgesamt 10 Schlüssel generiert werden. Im Allgemeinen werden die symmetrischen Algorithmen noch in Block- und Streamcipher eingeteilt. Beim Blockcipher-Verfahren, wird der zu verschlüsselnde Text in Blöcke geteilt, die dann einzel verschlüsselt werden. Bei Streamcipher wird jedes einzelne Zeichen verschlüsselt. Streamcipher gelten als unsicher, wenn ein Schlüssel mehrfach zur Verschlüsselung eingesetzt wird. [6] Schwachstelle Die Schwachstelle ist der sichere Austausch des vereinbarten Schlüssels. Gerät dieser in falsche Hände, dann kann nicht mehr von einer sicheren Kommunikation ausgegangen werden. Sehr 12

14 viel folgenreicher kann sich das "Abfangen" des Schlüssels auswirken, wenn dieser Vorfall unbemerkt bleibt und Dritte den als sicher geglaubten Informationsaustausch "belauschen" können Vorteil Der Vorteil ist in der relativ hohen Ausführungsgeschwindigkeit und folglich in der Ausführungseffizienz dieser Verschlüsselungsverfahren zu sehen Sicherheitsanforderungen Die für die symmetrischen Verschlüsselungsverfahren geltenden Sicherheitsanforderungen sind: eine hinreichend große Schlüssellänge, die uneingeschränkte Offenlegung des Verfahrens, die hinreichende Bekanntheit und Erprobung des Verfahrens Verschlüsselungsalgorithmen Die wichtigsten Beispiele für symmetrische Verschlüsselungsalgorithmen sind folgend beschreiben DES (Federal Data Encryption Standard): Bei DES handelt es sich um ein blockcipher symmetrisches Verschlüsselungsverfahren. DES entstand in den 70er Jahren. Das National Bureau of Standards (NBS), heute National Institut for Standards and Technology (NIST), hatte damals eine Ausschreibung für einen Standard- Algorithmus publiziert, der für nicht sensible Daten eingesetzt und veröffentlicht werden sollte. Der Algorithmus sollte für die nächsten Jahren als sicher gelten. IBM hatte mit "Luzifer", den einzigen ernstzunehmenden Vorschlag eingereicht, der dann von der NSA - als damals einzige kompetente Instanz - geprüft wurde. Durch die von NSA empfohlenen Änderungen (weniger Schlüsselbits, Änderung in der Struktur) entstand dann DES. Das Verfahren ist auf Hardware-Implementationen optimiert. Die Entwurfskriterien blieben im Gegensatz zum Algorithmus geheim. DES arbeitet mit einer Schlüssellänge von 64 Bit, wovon jedoch nur 56 Bit signifikant sind. Aufgrund dieser kurzen Schlüssellänge ist DES nicht mehr zeitgemäss und durchaus anfällig für brute force Attacken. Eine brute force Attacke bedeutet, dass der Computer alle Schlüssel durchprobiert, bis der passende gefunden wird. Je länger der Schlüssel, desto länger braucht der Computer bis er den passenden gefunden hat. Heute wird meistens umgestiegen auf 3DES (Triple-DES), eine DES-Variante, die mit erhöhter Schlüssellänge und Mehrfachverschlüsselung (z.b. 3DES-EDE) arbeitet. Der DES ist nur wegen seines zu kleinen Schlüsselraums heute nicht mehr als sicher zu betrachten! Theoretische Ergebnisse haben gezeigt, das DES wahrscheinlich sicher gemacht wurde. Es ist auch kein realistischer Angriff bekannt, der schneller als die brute force Attacke ist IDEA (International Data Encryption Algorithm) Dieses symmetrische Verschlüsselungsverfahren wurde von J. L. Massey und X. Lai an der ETH Zürich entwickelt und 1990 veröffentlicht. IDEA arbeitet mit 64 Bit Blöcken und verwendet 128 Bit Schlüssel und gilt als sicher. Der Algorithmus hielt bereits umfangreichen kryptoanalytischen Angriffen stand. Das Patent für IDEA wird von der Ascom Systec AG (Schweiz) gehalten, die nicht-kommerzielle Nutzung ist frei AES/Rijndael (Advanced Encryption Standard) Anfang 2001 veröffentlichte das Computer Security Resource Center des NIST (National Institute of Standards and Technology) einen Vorschlag, den künftigen Verschlüsselungsstandard AES auf dem Algorithmus Rijndael zu implementieren. Seit dem hat das NIST AES offiziell als Standard anerkannt und damit die Ablösung von DES eingeleitet. Rijndael ist eine symmetrische Blockchiffre für 128-bit-Blöcke mit Schlüssellängen von 128, 192 und 256 Bits RC4 RC4 ist ein Streamchiffre und wurde 1987 von Ron Rivest für RSA Data Security entwickelt und als trade secret geheim gehalten wurde der RC4 Algorithmus anonym im Internet 13

15 veröffentlicht. RC4 hat, im Gegensatz zu DES, eine variable Schlüssellänge. RCE wird in vielen kommerziellen Software-Packeten eingesetzt (z.b. Lotus Notes, Oracle Secure SQL), aber z.b. auch in SSL/TLS-Implementierungen (z.b. OpenSSL) Weitere Verfahren Noch andere symmetrische Verschlüsselungsalgorithmen sind Blowfisch, FEAL, RC2, RC5 und SAFER-128. Diese werden aber in dieser Arbeit nicht weiter umschrieben Asymmetrische Kryptographie Abbildung 2: Asymmetrische Kryptographie Ein weiteres Verschlüsselungsverfahren ist die so genannte asymmetrische Verschlüsselung, die auf der Verwendung eines zusammengehörenden Schlüsselpaares basiert. Die asymmetrischen Verfahren werden auch Public-Key-Verfahren genannt. Jeder Anwender generiert ein Schlüsselpaar. Und zwar einen geheimen, den so genannten privaten Schlüssel, und einen öffentlichen Schlüssel, der frei verfügbar sein muss und der sogar in einem Verzeichnis (Directory) bereitgestellt wird. Mit dem öffentlichen Schlüssel des Empfängers lässt sich eine Nachricht verschlüsseln. Die Kenntnis des öffentlichen Schlüssels allein reicht aber nicht aus, um die Nachricht wieder zu entschlüsseln. Der Empfänger entschlüsselt die Nachricht mit dem nur ihm bekannten geheimen Schlüssel (Private Key). Dieser ist ausschließlich dem Besitzer des Schlüsselpaares bekannt und wird von diesem eingesetzt. Der private Schlüssel sollte niemals aus der Hand gegeben werden. Es muss dafür Sorge getragen werden, dass er niemals einem Dritten in die Hände fällt. Aus der Kenntnis eines privaten oder öffentlichen Schlüssels lassen sich keine Informationen über den anderen Schlüssel des Schlüsselpaars ziehen. Die asymmetrische Verschlüsselung kann auch zur Authentifizierung eingesetzt werden. Zu diesem Zweck werden die öffentlichen Schlüssel vom Sender und vom Empfänger gegenseitig bekannt gemacht. Wird eine Nachricht mit dem geheimen Schlüssel (Private Key) verschlüsselt, so kann sie nur mit dem dazugehörigen öffentlichen Schlüssel wieder lesbar gemacht werden. Dies heisst, dass sie von einer Person stammen muss, die der Empfänger kennt oder vertraut. Man nennt ein solches Verfahren dann auch digitale Unterschrift. Kurz gesagt lässt sich sowohl der eine, wie auch der andere Schlüssel zum Verschlüsseln oder Entschlüsseln verwenden - je nachdem welches Ziel verfolgt wird. Zurzeit basieren die gängigen asymmetrischen Verfahren darauf, dass es numerisch sehr aufwendig ist, Primfaktorzerlegungen sehr grosser Zahlen durchzuführen oder diskrete 14

16 Logarithmen grosser Zahlen zu bestimmen. Mit solchen Berechnungen werden Einwegfunktionen definiert. Einwegfunktionen sind in einer Richtung relativ einfach zu berechnen, aber rückwärts praktisch nicht. Ein praktisches Beispiel für eine Einwegfunktion ist ein Telefonbuch. Für einen bestimmten Namen die entsprechende Nummer zu finden ist einfach, aber von der Nummer auf den Namen zu kommen, ist mit einem Telefonbuch beinahe unmöglich. Für die PKI sind besondere Einwegfunktionen interessant, die mit Hilfe des privaten Schlüssels einfach umzukehren sind. Solche Funktionen nennt man Einwegfunktionen mit "Drapdoor" und der private Schlüssel ist die "Drapdoor". Asymmetrische Verfahren können ausser zur Verschlüsselung auch zur Generierung digitaler Unterschriften verwendet werden. [5] Nachteil Der Nachteil liegt in der höheren Rechenleistung als für symmetrische Verfahren benötigt wird. Dies liegt vor allem darin, dass die verwendeten Schlüssel viel länger sein müssen als beim symmetrischen Verfahren. Damit eng verbunden, fallen gleichfalls verschiedene Aufwände wie beispielsweise der Zeitaufwand oder der Aufwand für einzusetzende Hardware größer aus. Bei heutigen symmetrischen Verfahren sind Schlüssellängen von 128-Bit eine gute Wahl. Bei asymmetrischen Verfahren sollte die Schlüssellänge dagegen schon grösser als 1024-Bit sein. In der Praxis werden aufgrund der oben genannten Nachteile meistens hybride Verschlüsselungstechnologien eingesetzt. Die hybride Verschlüsselungstechnologie wird in Kapitel genauer beschrieben Vorteil Ist eine Nachricht einmal verschlüsselt, so kann sie nur noch der Empfänger entschlüsseln und lesen. Der Sender und der Empfänger müssen sich nicht zuvor persönlich getroffen haben, um später eine vertrauliche Nachricht zu versenden und empfangen zu können. Es muss nur einmal ein Schlüsselpaar generiert werden, welches dann für jede Kommunikationsverbindung benutzt werden kann. Im Gegensatz zum symmetrischen Verfahren ist dies ein Vorteil. Denn beim symmetrischen Verfahren muss man für jeden Kommunikationspartner einen separaten Schlüssel generieren Sicherheitsanforderungen Die Sicherheit des Private Key wird beeinflusst durch: die Geheimhaltung des Private Key durch seinen Besitzer, die Qualität des Passwortes, mit dem der Private Key verschlüsselt ist, die verfügbare Rechenleistung für eine "brute force Attacke" auf den Private Key, die Schlüssellänge des Private Key, die Lebensdauer des Private Key. Hieraus kann unter anderem abgeleitet werden, dass einer zunehmend stärker werdenden Rechenleistung mit größeren Schlüssellängen und gegebenenfalls kürzeren Lebenszyklen für Private Keys zu begegnen ist Verschlüsselungsalgorithmen Die wichtigsten Beispiele für asymmetrische Verschlüsselungsalgorithmen sind folgend beschrieben Diffie Hellman Algorithmus (DH) Das Diffie-Hellman-Verfahren ist das älteste asymmetrische Verschlüsselungsverfahren. Es ist nach seinen Erfindern benannt und beruht auf dem bis heute ungelösten mathematischen Problem des diskreten Logarithmus. Diffie-Hellman ist in PKCS#3 standardisiert. Der DH Algorithmus wird für die Schlüsselvereinbarung (Key Agreement) über einen unsicheren Kanal verwendet. Bis zu seiner Entwicklung im Jahre 1976 wurden nur symmetrische Verfahren verwendet. 15

17 Elliptische Kurven Elliptische Kurven setzen einerseits ein sehr grosses mathematisches Verständnis voraus und andererseits wurde dieses Verfahren patentiert. Eine Implementierung eines solchen Verfahrens setzt voraus, dass man die Prinzipien Elliptischer Kurven kennt, diese in kryptographische Systeme implementieren kann und gewillt ist, Lizenzgebühren zu zahlen. Die Elliptischen Kurven als Verschlüsselungsalgorithmus werden in Umgebungen eingesetzt, wo nur geringer Speicherplatz vorhanden ist. Dies zum Beispiel bei geschützten Telefonverbindungen und mobilen Endgeräten RSA Der RSA-Algorithmus ist der bekannteste und am flexibelsten einsetzbare asymmetrische Verschlüsselungs-Algorithmus, der zurzeit verwendet wird. Das Schlüsselpaar wird auf der Grundlage des mathematischen Problems der grossen Primzahlen generiert. RSA kann zur Verschlüsselung und für die Erzeugung von digitalen Signaturen verwendet werden. [7] Hybride Verschlüsselung Bei der Hybride Verschlüsselung werden die Vorteile der symmetrischen und asymmetrischen Verschlüsselungsmethoden kombiniert. Die Geschwindigkeit der symmetrischen Verschlüsselung und die Sicherheit der asymmetrischen Verschlüsselung werden optimal miteinander ergänzt. Die Verschlüsselung der eigentlichen Daten erfolgt mit symmetrischer Verschlüsselung. Für das symmetrische Verfahren typische, wird nur ein Schlüssel verwendet. Im Hybridverfahren, wird für jede Übermittlung ein eigener Schlüssel den so genanten "session key" generiert. Dieser "session key" wird dann per asymmetrische Verschlüsselung dem Kommunikationspartner übermittelt bzw. der eigentlichen Nachricht angehängt. Da es sich bei einem Schlüssel nur um sehr wenige Daten handelt, fällt hier der Nachteil der langsamen asymmetrischen Verschlüsselung praktisch nicht ins Gewicht. Ablauf: 1. Zu Beginn wird ein session key mittels einer Zufallssequenz erzeugt. Mit diesem session key wird die vertraulich zu übermittelnde Information z.b. per DES chiffriert. 2. Anschließend wird nun der session key eines asymmetrischen Verschlüsselungsverfahrens und unter Verwendung des Public Keys des entsprechenden Empfängers der Information verschlüsselt. Dies erfolgt trotz asymmetrischer Verschlüsselung schnell, da der session key relativ kurz ist. 3. Nun werden beide verschlüsselten Informationen, der Chiffriertext der ursprünglichen Nachricht und der Chiffriertext des verwendeten session key, an den Empfänger übermittelt. 4. Abschließend ist der Empfänger nach dem Erhalten der verschlüsselten Information in der Lage, diese zu entschlüsseln. Zuerst entschlüsselt er den auf asymmetrische Weise verschlüsselten session key. Hierfür setzt der Empfänger seinen geheimen Schlüssel ein. Hat der Empfänger jetzt den session key entschlüsselt, kann der Empfänger sehr einfach mit diesem Schlüssel den verschlüsselten Text entschlüsseln aufgrund des symmetrischen Verfahrens Hashfunktion Eine Hashfunktion ist kein Ver- oder Entschlüsselungsverfahren. Hashverfahren werden lediglich eng mit Verschlüsselungsverfahren eingesetzt. Die Grundlage für Hashverfahren bilden mathematisch festgelegte Algorithmen. Aus einem Text wird eine Bitfolge (Hashwert) aufgrund vordefinierter mathematischer Algorithmen erzeugt. Dieses Verfahren, welche die Bitfolge berechnet, nennt man Hashfunktion. Aus einem Text ist einfach ein Hashwert zu generieren aber es ist nicht möglich, aus dem Hashwert die Eingabe zu berechnen. Als Anschauungsbeispiel kann die Quersumme herangezogen werden. Das Ergebnis (Hashwert) weist eine fixe Länge von zum Beispiel 160 Bit auf. Der Hashwert ist eine Einwegfunktion und ändert sich, sobald nur ein einziges Bit im Text geändert wurde. Die Wahrscheinlichkeit, dass zwei unterschiedliche Texte denselben Hashwert ergeben ist sehr gering bis unmöglich. 16

18 Häufig anzutreffende Bezeichnungen für das Ergebnis einer angewendeten Hashfunktion sind: message authentication code (MAC) digital fingerprint data authentication code (DAC) message digest (MD). Die Hash-Berechnung ist eines der Bestandteile zur Generierung von "digitalen Signaturen" und dient zum Schutz von Integritätsverletzungen. Dieser Wert wird durch seine Eindeutigkeit auch als digital fingerprint der Datenmenge bezeichnet Sicherheitsanforderungen Die Anforderungen an kryptographische Hashverfahren sind: Den Basis-Informationen unterschiedlichster Größe sind immer Hash-Werte einer bestimmten Größe zuzuordnen. Es handelt sich hier um eine Form der Kompression. Die Wahrscheinlichkeit, dass aus zwei unterschiedlichen Informationen die gleiche Prüfsumme errechnet wird, ist so gering wie möglich zu halten bzw. auszuschließen. Eine Kollision ist zu vermeiden. Einen Ursprungstext aus einer vorliegenden Prüfsumme zu erzeugen, muss außerordentlich schwierig bzw. unmöglich sein. Man spricht von der Unumkehrbarkeit des Verfahrens Hash-Verfahren: SHA-1, (Secure Hash Algorithm 1) Secure Hash Algorithm wurde vom NIST 1994 entwickelt und gilt momentan als sicher MD5, (Message Digest 5) Message Digest ist eine von Ron Rivest entwickelte Einweg-Hashfunktion. Sehr aktuell ist die Frage, ob MD5 überhaupt noch sicher ist. Es finden häufige Kollisionen statt, die können aber nicht so wie bei MD4 von Hand ausgelöst werden. Eine Kollision findet dann statt, wenn für zwei unterschiedliche Texte der gleiche Hashwert erzeugt worden ist. Sobald Kollisionen stattfinden, gilt das Verfahren eigentlich als gebrochen und somit muss der Standard MD5 als unsicher deklariert werden RIPEMD (RACE Integrity Primitives Evaluation Message Digest) RIPEMD wurde von Hans Dobbertin, Anton Bosselaers und Bart Preneel entwickelt. Es können Hashwerte von 128 (RIPEMD-128) oder 160 (RIPEMD-160) Bit Länge erzeugt werden. 1.4 Verschlüsselungsstärke Bei der Implementierung muss man sich immer vor Augen halten, dass kein kryptographisches Verfahren 100% Sicherheit gewährleistet. Je sicherer das Verfahren, desto teuerer und komplexer das System. Momentan ist die Schlüsselstärke, die bei UBS verwendet wird, bei 1024 Bit. Ab spätestens 2006 wird die Schlüsselstärke auf 2048 Bit erhöht. Es wird behauptet, dass die Schlüssel früher geknackt werden als bisher angenommen. Der rasante technische Fortschritt in den letzten Jahren hat es Hackern erleichtert, sich starke Maschinen zu beschaffen, die in einer vernünftigen Zeit mittels brute force Attacke kryptographische Verfahren brechen können. 1.5 Digitale Signaturen Digitale Signaturen sind eigentlich das Online Gegenstück zur Unterschrift per Hand, die wir heute zur persönlichen Identifizierung nutzen. Die Ziele Integrität und Authentizität, werden mittels digitaler Signatur erreicht. Der Sender erstellt zum Text eine Prüfsumme mittels einer Hashfunktion. Diese Prüfsumme verschlüsselt er dann mit seinem privaten Schlüssel. Zur Feststellung der Integrität der Nachricht entschlüsselt der Empfänger die Prüfsumme mit dem öffentlichen Schlüssel des Senders (Authentizität wird erreicht, da nur der Inhaber des privaten Schlüssels verschlüsseln kann) und vergleicht sie mit der Prüfsumme, die er selbst aus der 17

19 Nachricht erstellt hat. Bei Übereinstimmung kann der Empfänger sicher sein, die Nachricht unverändert empfangen zu haben. Will der Empfänger ganz sicher sein, dass die erhaltene Signatur wirklich vom Sender ist, für den er sich ausgibt, dann muss eine neutrale Drittperson dies bestätigen. Dies wird mit einem Zertifikat bestätigt. [45] Die Begriffe "elektronische Signatur" und "elektronische Unterschrift" sind als Synonyme zu verstehen. Beispiel Secure (ohne Verschlüsselung) Für die Signatur werden eigentlich zwei Schritte benötigt. Ein Verfahren um das Dokument fälschungssicher zu signieren und ein Verfahren, das überprüft, ob die Signatur von der angegebenen Person generiert wurde. Abbildung 3: Signatur 1. Alice generiert aus der Kopie der Bestellung zuerst mittels eines Verfahrens H (z.b. SHA-1) einen "Hashwert" H(B) der Bestellung B. 2. Alice verschlüsselt NUR den Hashwert (Bitfolge) H(B), mit ihrem geheimen Schlüssel Ae. Daraus entsteht Sig(B). Sie hängt Sig(B) an die Bestellung B und sendet dann alles zusammen an Bob. Überprüfung der Signatur: Bei der Überprüfung der Signatur generiert der Empfänger selbstständig nochmals einen gleichen Hashwert über den enthalten Text und vergleicht den erhaltenen mit dem selbst erstellten Hashwert. Die Bitfolge muss übereinstimmen, damit die Integrität gewährleistet ist. 3. Bob bildet einen Hashwert (auch hier z.b. SHA-1) aus der Kopie der empfangenen Bestellung H(B)'. 4. Bob entschlüsselt nun den verschlüsselten Hashwert Sig(B) mit dem öffentlichen Schlüssel Ad von Alice und erhält so den Bitstring H(B). 5. Sind nun H(B) und H(B)' identisch, dann weiss Bob, dass Alice die Bestellung aufgegeben hat. Hätte nun Carl etwas an der Bestellung geändert, so wären die beiden Hashwerte H(B) und H(B)' unterschiedlich. Die digitale Unterschrift schützt das Dokument neben der Authentizität auch noch vor Integritätsmissbrauch. Die Hashfunktion ist Bit sensitiv, das heisst jede Veränderung nach der Signatur führt zu einer Verifikation des Hashwertes und führt zu einem ungültigen Resultat. Beispiel Secure mit Verschlüsselung 1. Alice bildet einen Hashwert H(O) ihrer und verschlüsselt diesen mit ihrem geheimen Schlüssel Ae. Daraus entsteht Sig(O). 18

20 2. Sie hängt nun Sig(O) an die Bestellung. 3. Sie generiert zufällig einen Schlüssel, welchen wir "Session Key" nennen. Sie verschlüsselt den ganzen Text mittels eines symmetrischen Verfahrens, wobei sie diesen Session Key verwendet. 4. Sie verschlüsselt nun den Session Key mittels des öffentlichen Schlüssels Bd von Bob, einem Angestellten der Bank. Das Resultat Bd(K) wird an den verschlüsselten Text gehängt. Alles zusammen wird dann Bob zugestellt. 5. Bob wiederum entschlüsselt den verschlüsselten Session Key mittels Be und erhält somit den ursprünglichen Session Key K. 6. Mittels K wird nun der verschlüsselte Text entschlüsselt. Kein Problem, da es sich um ein symmetrisches Verfahren handelt. 7. Bob bildet einen Hashwert des Textes H(O)'. 8. Er entschlüsselt nun den verschlüsselten Hashwert der Bestellung mit dem öffentlichen Schlüssel Ad von Alice und erhält so einen Bitstring H(O). 9. Sind nun H(O) und H(O)' identisch, dann weiss Bob, dass Alice das verschickt hat. Abbildung 4: Signatur mit Verschlüsselung Dazu sind folgende 5 Schlüssel benötigt worden: Schlüsselpaar von Alice Schlüsselpaar von Bob gemeinsamer Session Key. Zu beachten ist auch die Ablage von verschlüsselten s. Eine Kopie der soll man an sich selbst schicken, damit der Session Key gespeichert wird. Diese Aufgabe übernimmt gegenwärtig jeder standardmässige Mail-Client automatisch. Vorsicht ist bei verschlüsselten E- Mails geboten, denn diese können von der Firewall nicht auf Viren überprüft werden. Die Virenprüfung muss dann der Endbenutzer vornehmen. Eine Beschleunigung bei der Verschlüsselung kann man erzielen, in dem man den Text vorgängig komprimiert und somit alle Redundanzen verschwinden. Gemäss dem Beispiel lassen sich vertrauliche Nachrichten sehr leicht austauschen, wenn sich die Teilnehmer einmal gegenseitig auf der Basis von Zertifikaten authentisiert haben. Dies gilt nicht nur für s, sondern auch für Client-Server Technologien im Bereich Sicherheit, wie IPSEC und TLS/SSL. Hauptziel der Verschlüsselung ist vertrauliche Informationen zu schützen, also ein Geheimnis zu wahren. Auch eine Käufer- Verkäufer-Beziehung, die über das Internet stattfindet, funktioniert mit zertifikatsbasiertem Vertrauen. 19

21 1.5.1 Risiken der digitalen Unterschrift Falsche Identität bei der CA Die Überprüfung der Person, welche sich ein Zertifikat ausstellen will, ist unzureichend. Die Identität, die von der CA beglaubigt ist, stimmt nicht mit der Realität überein. Im Zertifikat soll erwähnt sein, wie die Identität des Ausstellers überprüft wurde. Falsche Ungültigkeitserklärung eines Zertifikats Umgehung der Hashfunktion Kollision Brechen des asymmetrischen Verfahrens eines Benutzers Brechen des asymmetrischen Verfahrens der CA Aufbewahrung des geheimen Schlüssels Aufbewahrung des digital signierten Dokumentes Überprüfung der Zertifikate Jemand sperrt einem anderen sein Zertifikat. Mittels Kollision können zwei Dokumente vertauscht werden, die den gleichen Hashwert aufweisen. Ein Benutzer gibt sich als anderer Benutzer aus und kann in dessen Namen Transaktionen vornehmen. Gelingt es einer Person das Verfahren der CA zu brechen, so ist sie in der Lage für nichtvertrauenswürdige Personen Zertifikate auszustellen. Sie kann auch das Vertrauen missbrauchen. Wurde der private Schlüssel kompromittiert, so können Transaktionen unter einem falschen Namen ausgeübt werden. Es muss verunmöglicht werden, dass das Original verändert werden kann. Denn somit kann nicht nochmals ein gleicher Hashwert erzeugt werden und später nicht bewiesen werden, dass das Dokument von der jeweiligen Person signiert wurde. Es ist von zentraler Bedeutung, dass die Applikationen oder Clients die Zertifikate auf ihre Gültigkeit überprüfen. Tun sie dies nicht, so wird einem Benutzer Zugang gewährt, auch wenn die Zertifizierungsstelle ihm nicht mehr vertraut Anforderungen an digitale Signaturen Damit eine digitale Signatur wirklich als adäquate Signatur für die Wahrung der Verbindlichkeit, Vertraulichkeit und Authentizität eingesetzt werden kann, obliegen ihr natürlich einige sicherheitsrelevante Anforderungen. Aus Bankensicht ergeben sich folgende Anforderungen: Die Signatur darf nur vom Unterzeichner erzeugbar sein. Die dazu eingesetzte Soft- und Hardware müssen den Anforderungen entsprechen. Dies gilt auch für die Herstellung der erforderlichen geheimen Schlüsselparameter. Sie muss durch jede autorisierte Person überprüfbar sein. 20

22 1.6 Public Key Infrastructure (PKI) Abbildung 5: Public Key Infrastructure Unter einer Public Key Infrastructure (PKI) wird eine umfassende Aufbau- und Ablauforganisation verstanden. Ihr Zweck ist es vor allem nicht miteinander bekannten Mitgliedern die gegenseitige Authentisierung und eine vertrauliche Kommunikation über ein unsicheres elektronisches Kommunikationsnetz zu gewährleisten. Weiter soll auch ermöglicht werden, dass elektronische Dokumente rechtsverbindlich digital unterzeichnet werden können. Hierzu stützt sich die PKI auf spezifische Hard- und Softwaresysteme sowie auf eine geeignete Infrastruktur. Ein Grundstein der PKI ist die Benutzung der Public Key Kryptographie und die Verwendung von Zertifikaten, welche die Echtheitsbescheinigungen für die öffentlichen Schlüssel darstellen. Das Zertifikat bescheinigt dem Empfänger einer digital unterschriebenen Nachricht, die Zugehörigkeit der persönlichen Daten des Absenders, zu den von diesem verwendeten Schlüsseln. Kurz, es sagt aus, dass die Person, die sich als Herr Müller ausgibt wirklich Herr Müller ist. Aufgrund des hierarchischen Aufbaus einer PKI basiert das Vertrauen der Mitglieder auf Zertifikaten einer CA (Certification Authority, siehe ) und letztendlich auf dem alleinigen Vertrauen in die jeweilige PKI-Spitzenorganisation, der sog. "Root-CA". PKI ist die Methode mit deren Hilfe nach dem derzeitigen Stand der Technik die Authentisierung, Identifizierung, Vertraulichkeit und Nichtabstreitbarkeit von elektronischen Daten sichergestellt werden kann. [8], [9], [45], [46] Komponente einer PKI Jede der Komponenten hat eine bestimmte Funktionalität und Aufgabe, die zu erfüllen ist. Zwischen den einzelnen Komponenten bestehen verschiedene interne und externe Schnittstellen Benutzerkomponente Damit zählt man den Endanwender, der in der UBS "Subscriber" genannt wird, als Schlüsselund Zertifikatsinhaber. Dazu gehören auch die Server, in der UBS "Relying Parties" genannt, die zwar mit Zertifikaten konfrontiert werden und diese auch auswerten müssen. Die "Relying Parties" müssen aber nicht zwingend selbst ein Zertifikat besitzen Certificate Authority (CA) Die Zertifizierungsstelle übernimmt die Ausstellung, die Verteilung und das Sperrung von Zertifikaten. In den meisten Fällen arbeitet die CA sehr eng mit einer Registration Authority (RA) zusammen. Die CA wird verpflichtet, das Zertifikat unter Berücksichtigung des vorgegebenen Policy und allenfalls Gesetzgebung, mit der nötigen Sorgfalt zu erstellen. Zertifikate können für natürliche und juristische Personen ausgestellt werden. 21

23 Aufgaben einer CA Die Aufgabe der CA umfasst zusätzliche Dienste, damit Zertifikate und private Schlüssel sinnvoll eingesetzt werden können. Dies sind: Schlüsselgenerierungsdienst Schlüsselhinterlegungsdienst Verzeichnisdienst für Zertifikate und Sperrlisten Erstellung und Publikation von Zertifikaten Ungültigkeitserklärung eines Zertifikates Key Management, teilweise optional Kreuzzertifizierung (Zertifikat für eine andere CA ausstellen), optional Gültigkeitsdauer eines bestehenden Zertifikates oder Verlängerung Benutzerschlüssels Datenarchivierung Notariatsfunktionen, optional Zeitstempel und Beglaubigung der inhaltlichen Korrektheit analog zu bestehenden Notariatsdiensten Handhabung Policy Herstellung von anonymen Zertifikaten, optional Anmerkung Schlüsselgenerierung: Man muss zwischen Authentisierungs- bzw. Signaturschlüssel und Verschlüsselungs-Schlüssel unterscheiden. Der Authentisierungsschlüssel wird von dem Anwender oder Smartcard produziert, der Verschlüsselungs-Schlüssel generiert die CA. Schlüssel, die für beide Zwecke einsatzfähig sind, gibt es kaum noch. Anmerkung Policy: In der Literatur wird die Handhabung der Policy als optional angegeben. Jedoch variiert zwar ihre Form und Verbindlichkeit und letztlich gibt sich jede CA eine Policy und versucht sie auch einzuhalten. Einige dieser Dienste werden in eine Datenbank abgelegt. Entrust benutzt eine Oracle oder Ingres Datenbank, auf die man via ODBC zugreifen kann. OpenSSL greift nicht auf eine Datenbank zu, sondern schreibt ihre abzurufenden Daten in ein Flatfile. Unter der CA von Microsoft verbirgt sich eine MS JET Datenbank, für die weder eine standardisierte Schnittstelle noch ein publiziertes DB-Schema existiert. Diese Datenbank setzt Microsoft unter anderem auch in den Diensten Exchange und Active Directory ein Verschiedene Arten von CAs Root CA Die Root-CA ist innerhalb der PKI die Wurzel des Vertrauens. Als einzige Zertifizierungsinstanz wird sie nicht zertifiziert, sondern zertifiziert sich selbst. Alle anderen CAs werden von der jeweils übergeordneten CA zertifiziert. Auf diesem Wege werden sowohl das Vertrauen als auch die Policies weitergegeben bzw. vererbt. Policy CA Die Policy CA stellt nur (CA-) Zertifikate für die Issuer CA aus. Darin hält sie die Policies fest, nach denen die untergeordneten Issuer CAs Zertifikate ausstellen dürfen. Issuer CA Diese CA stellt die Benutzer- und Server-Zertifikate aus. Sie steht an unterster Stelle einer CA- Hierarchie. Class CA Abhängig von Art und Umfang, wie die Identitätsprüfung vorgenommen wird, können Klassen von CAs entstehen. Je nach CA-Klasse werden natürlich auch Zertifikate mit der jeweiligen Klasse generiert. Weitere Informationen zu dieser Klassifizierung folgen im Kapitel

24 Registrierungstelle (RA) Die Registrierungsstelle nimmt Zertifikatsanträge entgegen, prüft diese und genehmigt sie im positiven Fall. Die Registrierungsstellen (RA) sind auch befugt die Sperrung eines Zertifikats zu beantragen. RAs agieren im Namen und innerhalb einer bestimmten CA. Da es im Grundsatz nicht erheblich ist, ob eine CA selbst registriert oder eine RA mit der Registrierung beauftragt wird, wird im folgenden Dokument nur noch von der CA gesprochen und es findet keine Unterscheidung zwischen RA und CA statt. Je nachdem, wie sich ein Zertifikatsantragssteller vor der RA respektive CA ausgewiesen hat, erhält er ein besser oder schlechter klassifiziertes Zertifikat Directory Service, Verzeichnisdienst Der Directory Service lagert die gültigen Zertifikate und führt eine Liste von gesperrten Zertifikaten. Gleichzeitig bildet der Directory Service eine Schnittstelle zur Sicherheitsapplikation, zu anderen Directory Services und zu anderen Software-Applikationen. In diesem Directory können Zertifikate einer oder mehrerer CAs und die dazugehörenden Sperrlisten enthalten sein. Ebenso werden aktuelle und frühere Versionen des CPS (Certification Practice Statement) gespeichert Hardware Security Module (HSM) In einer PKI spielt der Private Key der Root-CA eine zentrale Rolle. Damit dieser nicht kompromittiert wird oder zumindest das Risiko eines Angriffes vermindert werden kann, ist der Private Key von der CA zu trennen. Er wird in einem separierten Hardware Security Modul (HSM) gespeichert. Der anerkannte Standard FIPS (Federal Information Processing Standard) beschreibt das Vorgehen, wie der Private Key vor unautorisiertem Zugriff zu schützen ist. Dabei verlässt der Privat Key das HSM nie PSE Personal Security Environment PSE steht für das Aufbewahrungs- oder Ablagemedium der Geheimelemente (Schlüssel) und der Zertifikate eines Benutzers. Die unsicherste Lagerung des geheimen Schlüssels ist in einem File auf einem PC (Gefahr wegen Attacken). Sowohl auf der Floppy Disk, einem USB-Stick wie auch auf der Chipcard kann der geheime Schlüssel mittels einer Zeichenkette (Passphrase) respektive PIN verschlüsselt abgelegt werden. Mittels PIN oder Passphrase wird das PSE freigegeben und die Sicherheitsapplikation kann auf den geheimen Schlüssel zugreifen. Je nach Anforderungen gibt es unterschiedliche Chipcards. Chipcards sind unterteilt in Memorycards und Smartcards. Im Gegensatz zu Memorycards, die einfache Speicher sind, können die Smartcards zusätzlich einfache Funktionen berechnen. Cryptocard gehören zu der Gruppe Smartcard. Im Gegensatz zur Speicherkarten besitzen sie zusätzlich zum Speichermedium noch einen Mikroprozessor mit integrierten kryptographische Funktionen. Der geheime Schlüssel verlässt die Cryptocard nie und kann von aussen auch nicht gelesen werden. Es kann von aussen nur veranlasst werden, dass die jeweiligen Private Key Operationen, wie das Signieren und das Entschlüsseln des Session Keys auf der Karte durchgeführt werden und das entsprechende Resultat der jeweiligen Operation an die Sicherheitsapplikation zurückgesandt wird. Die Sicherheitsapplikation übermittelt die für die kryptographischen Berechnungen notwendigen Daten über den Kartenleser an die Cryptocard. Im Mikroprozessor der Cryptocard werden die kryptographischen Rechnungen durchgeführt. Für diese Berechnungen werden der geheime Schlüssel des Benutzers und die von der Sicherheitsapplikation erhaltenen Daten benötigt. Das Resultat wird dann an diese Applikation zurückgesendet. Oft werden die Cryptocards und die Memorycards miteinander verwechselt. Die Memorycard hat jedoch keine Intelligenz, sie ist nur eine Cryptocard. 23

25 Sicherheitsapplikation Damit die Sicherheitsapplikation oder Sicherheitstechnologie auf dem Public Key Verfahren funktioniert, benötigt sie primär: Zugriff auf den Private Key des lokalen Benutzers (Oder Schnittstelle zu einem Kartenleser - respektive Cryptocard). Zertifikat des lokalen Benutzers. Zertifikat des sich auf der anderen Seite befindenden zu authentisierenden Partners. Verbindung zum Directory Dienst der CA, welcher das Zertifikat des zu authentisierenden Partners ausgestellt hat, damit die Gültigkeit des Zertifikats überprüft werden kann. Unterscheidung der Sicherheitsapplikationen: Client zu Server (IPSec, SSL/TLS, SSH, GSS API) Benutzer zu Benutzer (z.b. S/MIME, PGP) Code Signing, Unterschrift unter dem Programm, welches vom Netz geladen werden kann Certification Policy (CP) und Certification Practice Statement (CPS) Certificate Policy (CP) und Certification Practice Statement (CSP) Eine Certificate Policy beschreibt die Ausgabe und die Verwendung der Zertifikate. Ein Certification Practice Statement beschreibt die Vorgänge wie eine PKI betrieben werden muss. In diesen Policies werden Haftungsregeln unter Berücksichtigung der gesetzlichen Normen soweit wie möglich berücksichtigt. Da die europäischen Banken mit dem amerikanischen Bank-Institute zusammenarbeiten sind die gesetzlichen Richtlinien der USA zu befolgen. Abbildung 6: Certification Practice Statement (CPS)[45] Vertrauensmodelle (Trustmodelle) Unterschiedliche Sicherheitsanforderungen bei der Identifikation vom Zertifikatsantragsteller erlauben auch unterschiedlich aufwändige Möglichkeiten der Zertifikatsüberprüfung. Die in der Praxis am häufigsten angewendeten Modelle werden nachfolgend kurz erklärt: Direktes Vertrauen Direct Trust ist das einfachste Vertrauensmodell, bei dem jeder Nutzer selbst seinen eigenen öffentlichen Schlüssel unterzeichnet. Es eignet sich vor allem für den Privatgebrauch, in dem der öffentliche Schlüssel auf der Homepage publiziert oder per verschickt wird und dann der Fingerprint per Telefon verglichen werden muss. Das Sperren von Schlüsseln im Falle eines 24

26 Verlustes ist jedoch schwierig und aus rechtlicher Sicht bietet das Direct Trust Modell keine Sicherheit Web of Trust PGP PGP ist ein Programm, das für den Privatgebrauch kostenlos ist und hauptsächlich für und Harddiskverschlüsselung eingesetzt wird. Das Problem der Zugehörigkeit von Schlüssel und Person löst PGP mit der Möglichkeit, dass PGP Benutzer untereinander ihre Schlüssel signieren können. Es ist eine etwas sicherere Alternative zum direct Trust. Für seriöse Identitätskontrollen wird jedoch meist auf CA-zertifizierte Schlüssel zurückgegriffen Hierarchical Trust Dieses Modell ist am weitesten verbreitet und bietet die grösste Sicherheit. An der Spitze steht die Root CA, welche die öffentlichen Signierschlüssel der direkt unter ihr gelegenen CA signiert. Die nächstuntere Ebene von CA signiert wieder die öffentlichen Signierschlüssel der ihr hierarchisch untergeordneten Zertifizierungsstellen. Dies setzt sich immer weiter fort, bis letztlich ein Benutzerzertifikat ausgestellt wird. Das Benutzerzertifikat bildet das Ende der Hierarchiekette. Damit dieses Modell funktioniert, müssen alle Benutzer der Root CA vertrauen. Vertrauen alleine genügt jedoch nicht für den Mechanismus der Authentisierung. Alle Benutzer benötigen zusätzlich zu ihrem Zertifikat noch eine beglaubigte Kopie des öffentlichen Schlüssels der Root CA oder deren selbst signiertes Zertifikat. Zertifikate werden von einer CA (Sub CA) unterzeichnet, deren Zertifikat wiederum von einer CA einer höheren Stufe unterzeichnet wurde. Am Ende dieser Kette steht eine Root CA, die ihr Zertifikat selbst unterzeichnet hat. 1.7 Digitales Zertifikat Ein digitales Zertifikat ist ein Dokument, welches garantiert, dass ein spezifischer öffentlicher Schlüssel (Public Key) mit einem Benutzer verknüpft ist. Das Zertifikat beinhaltet neben der Kopie des öffentlichen Schlüssels und Daten des Zertifikatsinhabers auch Daten und die Signatur von einer vertrauenswürdigen Zertifizierungsstelle. Sie bestätigt die Richtigkeit mit ihrer Signatur. Den Hashwert wird über das gesamte Zertifikat berechnet und dann mit dem privaten Schlüssel der CA verschlüsselt. Um die Gültigkeit eines digitalen Zertifikats zu überprüfen, muss man den Public Key der CA verwenden. Im Allgemeinen könnte man ein Zertifikat mit einer Identitätskarte oder Pass vergleichen. Ein Zertifikat ist nichts anderes als eine digital signierte Datei, welche über einen strukturierten und definierten Aufbau verfügt. [10], [11] Abbildung 7: X.509-Zertifikat [11] 25

27 1.7.1 Inhalt eines X509v3 Zertifikat Version Die Sicherheitsapplikation muss die Version 3 richtig interpretieren und auswerten können. Serial Number Signatur Issuer Validity Subject Subject Public Key Info Issuer Unique Identifier Subject Unique Identifier Extension Signatur Ist innerhalb einer CA eine eindeutige Nummer. Enthält Angaben über das Verfahren, mit welchem die Signatur des Zertifikats hergestellt worden ist. Diese Angaben müssen mit dem Feld Signatur Algorithm übereinstimmen. Beinhaltet den Distinguished Name des Zertifikatsausstellers. Gültigkeitszeitfenster. Distinguished Name des Zertifikatsbesitzers/Nutzniessers. Enthält Angaben über den Algorithmus und die Parameter des Public Key des Zertifikatsinhabers. Der öffentliche Key ist hier explizit und zwingend enthalten. optional, nähere Angaben über den Zertifikatsaussteller, wird nicht empfohlen optional, nähere Angaben zum Zertifikastinhaber, wird nicht empfohlen Ermöglicht die Einbettung von zusätzlichen Informationen. Die Standard-Erweiterungen sind in X.509 definiert, aber jede Organisation kann private Erweiterungen definieren. Das Signatur-Feld beinhaltet das Feld Signatur Algorithmus (Dieses Feld enthält nähere Angaben zum Signierverfahren. Es wird genauer umschrieben mittels Algorithmus- und Parameterangaben.) Signature Value (Dieses Feld enthält den digital unterschriebenen Hashwert. Dieser Wert wird über den ganzen Inhalt - ausser Signaturfeld selbst -des Zertifikats hergestellt) Extensions AKI, Authority Key Identifier SKI, Subject Key Identifier Key Usage Extended Key Usage CRL Distribution Point Wird eingesetzt, wenn die CA mehrere Schlüssel besitzt. Wird eingesetzt, wenn der Zertifikatsbenutzer mehrere gültige Schlüssel besitzt. Hier wird der Verwendungszweck für den privaten Schlüssel des Zertifikatsbenutzers festgelegt. Ist eine Erweiterung von Key Usage. Es sind weitere Einschränkungen/Optionen möglich. Definiert den Ort oder das Medium der Publikation der Sperrliste (CRL). In diesem Feld kann sowohl ein genereller Name enthalten sein, als auch der Ort, wo unterhalb des 26

28 Distinguished Name der CA die CRL im Directory Baum anzutreffen ist. DNS Name, -Adresse, X.400 Adresse, EDI Name, Directory Name, IP Adresse vordefinierter Eintrag, URI. Private Key Usage Period Subject Alternative Name Eingesetzt, wenn der zu zertifizierende, öffentliche Schlüssel zur Verifikation von Signaturen verwendet wird. Enthält alternativer Namen zum Zertifikatsinhaber, ermöglicht primär nur die Authentisierung für verschiedenste Applikationen. Issuer Alternative Name Enthält alternativer Namen zum Zertifikatsherausgeber (z.b. E- Mail) Certificate Policies Subject Directory Attributes Enthält optionale und zwingende Vorschriften, welche die Ausstellung und den Gebrauch der Zertifikate regelt. Es gibt jedoch keine einheitliche Regelung und deshalb rät RFC3280 vom Gebrauch ab. Enthält eine Reihe von Attributen über den Zertifikatsinhaber Einteilung von Zertifikaten Zertifikate werden für unterschiedliche Situationen, Prozesse oder Personengruppen verwendet, deshalb werden sie eingestuft in: [45] Zertifikatstypen Zertifikatsklassen Fälschungssicherheitsstufen Zertifikatstypen Die Unterscheidung in dieser Zertifikatsgruppe findet einerseits auf dem Verwendungszweck und andererseits auf der Zertifikatsarchitektur statt CA Zertifikate Als CA Zertifikate werden Zertifikate bezeichnet, welche den öffentlichen Schlüssel einer CA beglaubigen. Der Aufbau dieser Zertifikate unterscheidet sich von den Benutzerzertifikaten dadurch, dass in den Erweiterungen zusätzliche Informationen vorhanden sein können Benutzerzertifikate Ein Benutzerzertifikat wird für den Endanwender, den Nutzniesser, erstellt. Mit diesem Zertifikat kann sich zum Beispiel ein Benutzer bei einer Applikation anmelden Maschinenzertifikat, Serverzertifikat Dieses Zertifikat wird für einen Server ausgestellt und benützt, wenn eine sichere Verbindung zwischen zwei Servern stattfinden soll. In der UBS werden die Zertifikate für die Domain Controller "Maschinenzertifikate" genannt, da ja ein Domain Controller auch eine Maschine ist. Das eigentliche Maschinenzertifikat (für irgendeinen Server oder auch Client) existiert in der UBS nicht. 27

29 Anonyme Zertifikate Anstelle des eigenen Namens werden Pseudonyme verwendet und die Personen können sich anonym und frei im Internet bewegen. Erst bei zu beanstandender Verwendung der Zertifikate, dürfte dann mittels richterlichen Beschlusses die Identität der betreffenden Personen bei der CA ermittelt und festgestellt werden Kreuzzertifikate Ein Zertifikat, welches für den öffentlichen Schlüssel einer anderen CA hergestellt worden ist, wird Kreuzzertifikat (Cross Certificate) genannt. Dies kommt zur Anwendung, wenn Benutzer von verschiedenen CA stammende Zertifikate benutzen und untereinander vertraulich und authentisch kommunizieren wollen. Dann müssen die CAs untereinander ihre eigenen öffentlichen Schlüssel gegenseitig zertifizieren lassen Zertifikatsklassen Die Einstufung von verschiedenen Zertifikatsklassen hängt von der Qualität des Registrierungsablaufes ab. Es ist wichtig zu unterscheiden, wie sich ein Client bei der CA authentisiert hat und welche Kriterien herbei gezogen wurden, um die Identität des Client zu prüfen. Im Normalfall werden drei Klassen von Zertifikaten unterschieden Fälschungssicherheitsstufen Das zentrale Thema dieser Zertifikatseinteilung, ist die Schlüssellänge des privaten Schlüssels Zur Kommunikation mit anderen PKIs bieten sich folgende Möglichkeiten Eine gemeinsame Wurzelinstanz (Root) stellt sicher, dass die Teilnehmer der nachgeordneten CAs direkt miteinander sicher kommunizieren können (hierarchisches Modell). Über die Cross-Zertifizierung können unabhängig aufgebaute PKIs nachträglich durch gegenseitige Anerkennung miteinander verbunden werden. Die gegenseitige Anerkennung unterschiedlicher PKIs kann über eine Bridge-CA vereinfacht werden. Dabei entfällt die individuelle Vereinbarung der Cross-Zertifizierung der Partner untereinander. Sie wird durch Vereinbarungen der einzelnen PKI mit der Bridge-CA ersetzt. Bei allen Alternativen ist grundsätzlich auf die Verträglichkeit der Policies, der verbundenen PKIs zu achten Herstellen und publizieren von Zertifikaten Es wird unterschieden zwischen "Erzeugen der Geheimelemente durch die CA" und "Erzeugen der Geheimelemente durch den Benutzer". Grundsätzlich stellt der Benutzer einen Antrag für ein Zertifikat. Die CA überprüft dann den Antrag und nimmt die Personaldaten auf Publikation der Zertifikate Die CA legt nun das gültige Zertifikat auf einem öffentlich lesbaren Datenbankserver ab. Dieser Server wird als Verzeichnisdienst oder Directory Dienst bezeichnet. Die Daten müssen konsistent und korrekt wiedergegeben werden und der Server muss vor Manipulationen unberechtigter Dritter geschützt werden Sperrung eines Zertifikates Die Zertifikate haben eine reguläre Laufzeit und laufen nach diesem Datum automatisch ab. Manchmal müssen jedoch die Zertifikate vor diesem Datum als ungültig erklärt werden. Über die Gründe für eine Zertifikatssperrung wird im Kapitel 3.4 näher darauf eingegangen werden. 28

30 Ablauf einer Sperrung: 1. Sperrung des Zertifikats erfassen 2. Zertifikatssperrung annehmen 3. Identität und Berechtigung der sperrenden Person prüfen 4. Zertifikatssperrung erfassen 5. Erzeugung und Verteilung der Sperrlisten (CRL), ist aber nicht für jede Sperrung zwingend 6. Sperrung von Service-Rechten auslösen 7. Benutzer informieren Je nach Situation können unterschiedliche Sperrlisten erzeugt werden. Eine Sperrliste wird auch Revocation List genannt Arten von Standard-Revokationslisten: Vollständige Revokationslisten Hier sind alle revozierten Zertifikate enthalten, welche bis zum Ausgabezeitpunkt der Liste als ungültig erklärt wurden Delta Revokationslisten Hier werden nur die ab einem bestimmten Zeitpunkt für ungültig erklärten Zertifikate publiziert. Man erspart sich die Mühe wegen ein paar wenigen revozierten Zertifikaten eine komplette Liste zu erstellen Indirekte Revokationslisten Alle revozierten Zertifikate von unterschiedlichen CAs können in einer Liste aufgeführt werden. Diese Form von Revokationslisten wird jedoch selten verwendet Verlängerung des Zertifikats, Key Update Manchmal soll die Gültigkeitsdauer eines bestehenden Zertifikats verlängert werden, weil der Benutzer den bestehenden privaten Schlüssel nicht wechseln will. Die originalen Antragsdaten werden kopiert und die Gültigkeitsdauer wird gemäss den Polies ergänzt Datenarchivierung Das Herstellen und Aushändigen von Zertifikaten und die Ungültigkeitserklärung von Zertifikaten sollten so aufgezeichnet werden, dass diese Prozesse später einmal nachvollziehbar sind Notariatsfunktionen Eine CA kann in einem Unternehmen noch zusätzliche Funktionen übernehmen. Versehen eines Zeitstempels an ein Dokument Bescheinigung des Vorliegen eines Dokuments Nichtabstreitbarkeit Verifikation einer Signatur unter einem bestehenden Dokument Diese Notariatsfunktionen werden selten in Anspruch genommen, da sie schlecht von den Sicherheitsapplikationen unterstützt werden. Wenn die CA die Geheimelemente erzeugt, so kann sie diese auch speichern. Dies ist jedoch nur bei einer privaten CA möglich. Eine öffentlich anerkannte CA darf gemäss EU Richtlinie zur elektronischen Signatur, gemäss dem deutschen Signaturgesetz und gemäss Entwurf BGES, die für die Benutzer generierten Schlüssel nicht aufbewahren. 29

31 1.7.8 Policy Management Es werden Richtlinien erstellt und deren Durchsetzung überprüft. Auch das Zuteilen und Überprüfen von Berechtigungen werden innerhalb der Policy geregelt. Es soll vermieden werden, Autorisierungsinformationen in ein Zertifikat einzupacken, da der Wechsel der Berechtigung ein Wechsel des Zertifikates zur Folge hätte Key Management Wie bereits im Kapitel als Anmerkung erwähnt, hat sich mittlerweile allgemein durchgesetzt, dass Schlüssel für Authentisierungs- und Signierzwecke, auch im Firmenumfeld, nie durch die CA sondern durch den Benutzer erzeugt werden. Somit wird die Verantwortung klar dem Zertifikatsinhaber zugewiesen. (bspw. werden die Mitarbeiter auch auf ihre zertifikatsbasierte Authentisierung behaftet). Eine zentrale Schlüsselerzeugung und allenfalls Speicherung wird nur für Verschlüsselungs-Schlüssel gemacht. Die Konsequenz ist natürlich, dass immer mit "dual" Zertifikaten gearbeitet werden muss - eins für Authentisieren/Signieren, eins zum Ver- bzw. Entschlüsseln. 1.8 ASN.1 Die ASN.1 (Abstract Syntax Notation One) ist ein von der ->ITU-T (International Telecommunication Union - Telecommunication Standardization Sector) herausgegebener Standard, um Datentypen und -werte zu beschreiben. Es ist eine Sprache zur Spezifikation abstrakter Syntaxen, die unabhängig von benutzer- und maschinenspezifischen Codierungsverfahren ist. Sie dient als standardisierte Schnittstelle zwischen sehr vielen verschiedenen Anwendungen, welche Daten über ein Netzwerk versenden, beziehungsweise empfangen. Mit Hilfe von ASN.1 können Systeme mit unterschiedlichen internen Datendarstellungen Nachrichten austauschen. ASN.1 findet Anwendung im Telekommunikationsbereich, im SNMP (Simple Network Management Protocol) und im Bereich von X.509 Zertifikaten. Es gibt noch mehr Bereiche in denen die ASN.1 Codierung verwendet wird. Auf diese weiteren Bereiche wird aber nicht weiter eingegangen. [12] ASN.1 beschreibt lediglich die syntaktischen Regeln von Datenfeldern und muss dementsprechend noch codiert werden. In den Standards X.680ff werden die Daten in "Encoding Rules" wie BER (Specification of Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules) oder PER (Packing Encoding Rules) definiert. Bei den "Encoding Rules" handelt es sich um eine Reihe von Regeln zur Codierung von ASN.1-Daten in einen Oktettstrom. Jede Codierungsmethode verfügt über ihre eigene Anwendung. Mehr Informationen könnte unter DE; bezogen werden. Die Bekanntesten Codierungsregeln sind die Basic-Encoding-Rules (BER) und die Distingueshed- Endcoding-Rules (DER). BER lässt Mehrdeutigkeit derselben Daten zu, wo hingegen DER eindeutig ist ASN.1 spezifisch im Umfeld von X.509 Zertifikate Im Zusammenhang mit X.509 Zertifikaten wird die DER-Codierung verwendet. Als Default-Wert wird auch das ASN.1 EXPLICIT tagging angenommen, ansonsten müsste man es spezifizieren. ASN.1 ist jedoch nicht unumstritten, da dieser Standard sehr komplex ist und dadurch viel Rechenleistung benötigt. Da sich aber die Verwendung von ASN.1 in PKIX-Protokollen durchgesetzt hat und in allen relevanten Applikationen ASN-1-Funktionalitäten eingebaut sind, lohnt es sich kaum ein zusätzliches Datenformat zu kreieren. [14], [15] 30

32 1.8.2 BER Mittels BER wird definiert wie die Daten codiert werden müssen, um sie über einen physikalischen Übertragungskanal zu transportieren. Die Daten werden auf der Bitebene eindeutig beschrieben. [13] DER Im Zusammenhang mit Zertifikaten wird aber die Codierungsmethode DER verwendet und deshalb wird für das Verständnis ein DER-Codierungsbeispiel herbeigezogen: Beispiel ASN.1 (uncodiert) Buch ::= SEQUENCE{ autor OCTET STRING, titel OCTET STRING, verfuegb OCTET STRING, } DER Codierung Eine SEQUENCE wird mit der DER-Codierung als 0x30 und OCTET STRING als 0x04 dargestellt. Es wird jeweils noch die Länge und die entsprechende Daten sequentiell aufgeführt. ASN.1: SEQUENCE autor titel verfuegb DER: 0x30 length 0x04 length date 0x04 length date 0x04 length date ASN.1 Syntax eines X.509 Zertifikat Die ASN.1 Syntax eines X.509 Zertifikats sieht folgendermassen aus: Certificate ::= SEQUENCE { tbscertificate TBSCertificate, signaturealgorithm AlgorithmIdentifier, signature BIT STRING } TBSCertificate ::= SEQUENCE { version [ 0 ] Version DEFAULT v1(0), serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, Issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, ssueruniqueid [ 1 ] IMPLICIT UniqueIdentifier OPTIONAL, subjectuniqueid [ 2 ] IMPLICIT UniqueIdentifier OPTIONAL, extensions [ 3 ] Extensions OPTIONAL } Den zu signierenden Teil stellt die TBSCertificat-Sequence dar (TBS To be Signed) und über diese Sequenz wird der Hashwert gebildet und mit dem Private Key der Issuer CA (Aussteller) verschlüsselt. Die restlichen Felder müssen nicht vor Veränderung durch Dritte (Integrität) geschützt werden, da es keinen grossen Sinn macht, diese zu verfälschen. 31

33 1.9 Die Microsoft CryptoAPI Im konkreten UBS Umfeld wird als PKI die Windows 2003 Server CA eingesetzt. Die Clients werden mittels Windows XP betrieben. Aus diesem Grund nimmt die Microsoft Schnittstelle CryptoAPI eine wichtige Position ein. [16], [17] Auf der Client-Seite setzen das Windows Betriebssystem und die Applikationen die Schnittstelle CryptoAPI ein, um die Zertifikats-Status-Prüfung und die Zertifikatskettenbildung durchzuführen. Alle Applikationen, die CryptoAPI aufrufen können, garantieren, dass eine angemessene und korrekte Zertifikatskettenbildung (chain building) und Zertifikats-Status-Prüfung erfolgt. Für Applikationsentwickler ist es deshalb nicht nötig, dass sie ihre eigenen Methoden schreiben müssen, um diese Funktionen einzusetzen. CryptoAPI ermöglicht es Software-Entwicklern, ihren Windows-basierten Anwendungen leistungsfähige verschlüsselungsbasierte Sicherheits-Features hinzuzufügen. Die einzelnen Applikationen können die Funktionen von CryptoAPI für folgende Tätigkeiten gebrauchen: Generierung und Austausch von Schlüsseln Ver- und Entschlüsselung von Daten Codierung und Decodierung von Zertifikaten Managen und Sichern von Zertifikaten Kreieren und Prüfen von Digitalen Signaturen und Berechnung von Hashwerten Somit stellt die Microsoft Crypto-Architektur mit dem CryptoAPI zusätzlich zur Schnittstelle eine umfassende Bibliothek im Bereich der Kryptographie zur Verfügung. Das CryptoAPI wurde so entworfen, dass Applikationsentwickler auf die Kryptographie-Funktionalität verschiedenster so genannter Cryptographic Service Provider (CSP) zugreifen können. CSPs sind unabhängige Module. Sie enthalten gewöhnlich eine Bibliothek, welche die Algorithmen enthält und alle kryptographischen Funktionen ausführt. Dies schliesst auch Anbieter von Hardware-Modulen, beispielsweise Smartcards ein. Idealerweise sind diese CSPs unabhängig von einer bestimmten Applikation, so dass verschiedenste Applikationen mit einer Vielfalt von CSPs laufen. Diese API Funktionalität kann erweitert werden, indem weitere Revocation checking Provider (Provider für die Statusüberprüfung) registriert werden. Jeder Provider kann dann einen oder mehrere Mechanismen für die Zertifikatsstatusprüfung implementieren. Certificate Revocation Lists (CRL), Online Certificate Status Protocol (OCSP) und Simple Certificate Validation Protocol (SCVP) sind zum Beispiel drei Mechanismen um den Status eines Zertifikates zu ermitteln Aufbau CryptoAPI Die drei Elemente des Microsoft Kryptosystems sind das Betriebssystem (Operating System), die Applikationen und die Cryptographic Service Provider (CSP). Die Applikationen kommunizieren über den CryptoAPI Layer und das Betriebssystem kommuniziert mit dem CSP durch das Cryptographic Service Provider Interface (CSPI). Die Applikationen können die CryptoAPI- Funktionen einsetzen, ohne Wissen über die darunterliegenden Sicherheitsimplementationen zu haben. 32

34 Application Layer Microsoft Outlook Microsoft Internet Explorer Microsoft Internet Information Server Microsoft Internet Information Server Microsoft CryptoAPI (CAPI) System Layer Operating System CryptoSPI Cryptographic Service Provider (CSP) Service Provider Layer CertVerifyRevocation A CertVerifyRevocation B CertVerifyRevocation C Abbildung 8: Aufbau CryptoAPI Folgende Tabelle zeigt die vordefinierten CSPs, die in Windows enthalten sind: CSP Microsoft RSA Base Provider Microsoft Enhanced Cryptographic Provider Microsoft Digital Signature Standard (DSS) and Diffie-Hellman Cryptographic Provider Smart Card CSP Beschreibung Unterstützt die Digitale Signatur und die Datenverschlüsselung. Unterstützt eine 128 bit Verschlüsselung. Durch längere Keys und zusätzliche Algorithmen kann noch eine höhere Sicherheit erreicht werden. Unterstützt Diffie-Hellman (D-H) Key exchange, SHA Hashing, DSS Datensignierung und DSS Signaturprüfung. Unterstützt Smartcards für Windows. Dieser CSP illustriert wie man eine Smartcard mit ihren vielen Funktionen sauber in die CryptoAPI integriert Certificate Chaining engine Die Microsoft CryptoAPI enthält also viele kryptographische Funktionen. Die Microsoft Certificate chaining engine bildet einen Teil von diesen Funktionen und wird für die Zertifikats- Statusprüfung verwendet. 33

35 2 Ist-Situation der UBS 2.1 Zusammenfassung Dieses Kapitel gibt einen Überblick über die aktuelle PKI-Situation der UBS. Momentan baut die PKI auf einer einstufigen Hierarchie auf. In Zukunft möchte die UBS ihre PKI auf einer dreistufigen Hierarchie aufsetzen. Diese erlaubt die zentrale Vorgabe aller akzeptierten Policies und Abstützung auf eine gemeinsame Root CA, ohne damit die Ausstellung der Zertifikate für die Enduser zentral steuern zu müssen.[51], [52], [53], [54] 2.2 Ist Situation Issuing CA layer User CA Swiss-DD Forest Server CA #1 Users Trust Group Server CA #1 Machines Server CA #1 Users Machines Users Machines Server CA #1 Abbildung 9: Ist-Situation UBS AG In der Schweiz setzt UBS momentan eine Issuer CA für Mitarbeiterzertifikate ein. Das heisst, zurzeit ist nur ein Issuing CA Layer vorhanden und es besteht keine Unterordnung von verschiedenen CAs. Die User Issuer CA gibt, wie der Name schon sagt, die Zertifikate für die Benutzer aus. Der Benutzer erhält beim Eintritt in die UBS drei Identifikationsnummern, die ihn gegenüber den Applikationen eindeutig identifizieren. Eine 7-stellige t-nr., eine 8-stellige Global Personal Number (GPN 8) für den ganzen UBS Konzern und eine 6-stellige ABACUS-ID. Diese drei Identifikations-Nummern werden dann auf die "Persauth-Smartcard" gespeichert. Im Umfeld der Informationstechnologie (IT) müssen sich die Benutzer gegenüber einer Applikation authentisieren, um sich einloggen zu können. Die Sicherstellung der Identität einer Person geschieht mit dem User Zertifikat oder durch die User-ID und ein Passwort. Mit der Persauth-Karte beweisen die Benutzer Ihre Identität durch den Besitz der Karte und die Kenntnis der persönlichen PIN, die ebenfalls beim Eintritt dem Benutzer abgegeben wird. 34

36 Abbildung 10: aktuelle Persauth-Karte Die Authentisierung der Maschinen und Domänencontroller folgt über Zertifikate, ausgestellt von den Server CAs, die ausserhalb des Swiss-DD Forest stehen. Die Server CAs sind somit unabhängig von der User CA und bilden eine eigene Domäne. Sie dienen zugleich einer Zugriffskontrolle einzelner "Trusted Groups" von Maschinen. Zum Beispiel darf eine Maschine von der Trusted Group "Produktion" nicht mit einer Maschine von der Trusted Group "Development" kommunizieren. Das heisst, dass sich die Maschinen innerhalb einer Gruppe nur gegenseitig vertrauen und eine Kommunikation mit einer Maschine einer anderen Gruppe nicht möglich ist. Momentan bestehen in der UBS folgende 8 "Trusted Groups": Server CA Production 1-3 Server CA Production Others Server CA Test 1 und 2 Server CA Development 1 und 2 Mit einem Certificate Management System (CMS) erfolgt die Verteilung einer Trust List. Die Trust List besteht aus einer Datei, in der definiert wird, welchen Server CAs einer bestimmten Trusted Group vertraut wird. Den Applikationen wird diese Datei dann mit einem Package zugesendet. Ob auch wirklich die richtige Liste mitgeschickt wurde und keine falschen Server CAs eingetragen sind, kann mit diesem Mechanismus nicht überprüft werden. Das momentan noch aktuelle Betriebssystem Windows NT verlangt keinen zertifikatsbasierten Login. Das heisst, die Mitarbeiter können sich mit dem Passwort, dass auf der Persauth-Karte gespeichert ist in die Swiss-DD Domäne einloggen. Hingegen verlangen die zertifikatsbasierten Applikationen REMAX, das den Fernzugriff für externe Mitarbeiter ermöglicht und Secure eine Überprüfung des Zertifikatsstatus mittels Certificate Revocation Lists (CRLs). Allgemein verfolgt die UBS die Strategie, dass die Verfügbarkeit einer Applikation höher gewichtet wird als die Verfügbarkeit der CRL. Dass heisst, wenn keine CRL zur Verfügung steht, wird der Zugriff trotzdem gewährt. Bei Secure- steht die Statusüberprüfung eines Zertifikates jedoch im Vordergrund. Denn ein Empfänger einer kann zum Beispiel eine verschlüsseltet nicht lesen, wenn das Zertifikat des Absenders gesperrt wurde. Mit einem gesperrten Zertifikat können ebenfalls auch keine s mehr versendet werden. Signierte s, welche von ausserhalb der UBS kommen, werden momentan nicht geprüft. Ein Wunsch wäre hingegen, dass externe Zertifikate von Business Applikationen (Web-Applikationen, FAT Clients, etc.) über das Online Certificate Status Protocool (OCSP) geprüft werden. Die momentane Herausforderung für das Engineering besteht darin, über einen Revocation- Provider zu verfügen, welcher je nach ausstellender CA unterschiedliche Überprüfungen ausführt, die entweder auf CRL oder OCSP basieren. In der UBS sind ca. 800 verschiedene Applikationen im Einsatz. Das Ziel ist es, dass in Zukunft alle sensitiven Applikationen die Zertifikatsstatusprüfung mittels CRL oder OCSP verlangen. Das Problem ist, dass zum Teil noch sehr alte Applikationen im Einsatz sind, die den CRL oder OCSP Mechanismus nicht unterstützen. Das heisst, dass die Zertifikatsstatusprüfung nicht bei allen 35

37 Applikationen möglich ist oder evt. nur mit grossem Programmieraufwand zu realisieren wäre. Es ist vorgesehen, dass die Zertifikatsstatusprüfung mit jedem neuen Produkt-Release eingeführt werden soll. 2.3 Soll-Situation im Bereich Wealth Management & Business Banking (WMBB) Das von der UBS angestrebte Ziel ist die Implementation einer 3-stufigen CA Architektur bestehend aus einer Root CA, einer Policy CA und einer Issuer CA. Root CA Intermediate CA layer Offline Root CA Policy CA Issuing CA layer User Machine Users Users Users Machines Machines Machines WM&BB (Trust Domain) Abbildung 11: Soll-Situation UBS AG Die Root CA wäre für die ganze UBS die oberste CA. Sie ist von der Issuer CA durch die Policy CA getrennt. Dies minimiert den Gebrauch des Private Keys der Root CA. Das heisst, die Root CA hängt nicht am Netz und wird offline betrieben. Die CA wird nur dann hochgefahren, wenn eine neue Certificate Revocation List (CRL) oder ein CA Zertifikat einer untergeordneten CA ausgegeben werden muss. Somit kann eine höhere Sicherheit gewährleistet werden. Der Zweck der Policy CA ist die Entkopplung der Root CA von der Issuer CA und die Einschränkung des Anwendungsbereiches durch Policies der Issuer CA. Mit dem Einsatz einer Policy CA können neue Issuer CAs flexibler in die CA Hierarchie integriert werden. In diesem Fall ist die Policy CA die Root CA einer Sub-Hierarchie. Sie schützt die Root CA, indem sie CAs in dem Issuing Layer zertifiziert ohne Intervention mit der Root CA. Mit dem Hierarchischen Modell ist es auch möglich, CA Produkte anderer Hersteller oder Dienstleister beliebig mit Windows CAs zu mischen. So kann beispielsweise eine Windows CA als untergeordnete CA unter einer externen CA arbeiten. Windows kann aber auch Zertifikate für untergeordnete CAs ausstellen, die sich ausserhalb der Windows Umgebung befinden. Diese 3-stufige Hierarchie hätte für die UBS folgende Vorteile: Die Root CA steht über der ganzen UBS Group. Jede Business Group betreibt mindestens eine Policy CA, die jeweils durch die UBS Group Root CA zertifiziert wird. Die Policy CA der einzelnen Business Groups können dann - im Rahmen der auf Group-Ebene vorgegebenen Policies - autonom eigene Einschränkungen des Anwendungsbereiches durch spezifische Policies 36

38 definieren. Somit kann schon von der Root CA aus ein zentrales Management und eine zentrale Kontrolle aller untergeordneten CAs erfolgen. Am 1. Januar 2005 wird die Migration auf Windows 2003 Server und XP-Clients gestartet. Mit dem Windows 2003 Server hat Microsoft eine ganze Reihe von wichtigen PKI-Funktionen ergänzt, die bei der Windows 2000 PKI noch fehlten. Dazu gehören hauptsächlich Funktionalitäten wie Key-Archival, das erweiterte Autoenrollment, das Rollenkonzept sowie die Anpassungsmöglichkeiten bei den Zertifikats-Templates. Bevorzugte Typen der Certificate Authorities (Microsoft) Tier CA Role CA Type Tier 1 Offline Root CA Stand-alone CA Tier 2 Offline intermediate CA Stand-alone CA Tier 3 Issuing CA Enterprise CA Stand-alone CA Ist weitgehend unabhängig von anderen Komponenten (z.b. Active Directory) und kann unabhängig von einer Windows Domäne betrieben werden. Die Zertifizierung erfolgt unabhängig von den Domänen-Accounts. Enterprise CA Ist sehr tief in die Windows Umgebung inkl. Active Directory integriert und setzt eine Windows Domäne und Active Directory voraus. Die Enterprise CA ist daher für die Zertifizierung von Benutzern und Rechnern innerhalb einer Windows-Domäne vorgesehen. Die Kopplung mit anderen Systemen ist aber nicht ausgeschlossen. Mit der Einführung von Windows XP wird auch eine neue Smart Card eingeführt, die einen zertifikatsbasierten Domain- und Applikationslogin (CbL) unterstützt. Abbildung 12: neue Smartcard Für den Windows Domänen-Login wird die Überprüfung des Benutzer-Zertifikates verlangt. Die Hochverfügbarkeit der CRL spielt in diesem Sinne eine wichtige Rolle. Falls keine aktuelle CRL zur Verfügung steht, besteht bis auf weiteres jedoch die Möglichkeit, dass sich ein Benutzer via Passwort trotzdem noch in die Domäne einloggen kann. Für die Fälle in welchen Mitarbeiter ihre Karte vergessen haben oder die Karte defekt ist, ist der Einsatz von Tageskarten geplant. Die Maschine CA in Abbildung 11 wird jedoch nur für den Zertifikatsbasierten Windows-XP Login gebraucht. Dass heisst, die Maschine CA stellt nur Zertifikate für die Domänencontroller aus. Die Statusüberprüfung von Server-Zertifikaten auf dem Client ist nicht erforderlich, denn solange die Server im Betrieb sind dürfen deren Zertifikate als gültig akzeptiert werden. 2.4 Probleme Bei der Server-Server Kommunikation (bspw. File-Transfer) wird heute die Zugriffskontrolle durch die Zuordnung zu "Trust Groups" gelöst. So können nur die Server ohne weiteres miteinander kommunizieren, die derselben Trust Group angehören. Dies steht aber im Widerspruch zur geplanten 3-stufigen Hierarchie: Wenn sich die Server CA der gemeinsamen Root CA 37

39 unterordnen, werden all von ihnen ausgestellten Zertifikate automatisch in allen untergeordneten Umgebungen akzeptiert. Somit wird die Bildung von Trust Groups durch die gezielte Verteilung der CA-Zertifikate verunmöglicht. Bis auf weiteres bleiben deshalb die Server CAs autonom. 38

40 3 Certificate Revocation List (CRL) 3.1 Zusammenfassung In diesem Kapitel wird aufgezeigt, warum ein Zertifikat überhaupt gesperrt werden muss und wie die Statusüberprüfung von Zertifikaten funktioniert. Ab Windows 2000 werden bei Microsoft standardmässig Certificate Revocation Lists (CRLs) als Mechanismus, um Zertifikate zu sperren, unterstützt. Hierbei werden Sperrlisten nach dem X.509 Standard eingesetzt, was dem heute üblichen Standard entspricht. Es handelt sich dabei immer um komplette Sperrlisten. Das heisst, die Zertifizierungsstelle (CA) gibt eine Sperrliste aus, in der alle gesperrten (und noch nicht abgelaufenen) Zertifikate einer CA enthalten sind. In einer grossen PKI-Umgebung kann der Einsatz von CRLs jedoch problematisch werden. Bei sehr grossen CRLs kann zum Beispiel die Verteilung auf die einzelnen Clients zu Performance Problemen im Netzwerk führen. Das heisst, dass unter Umständen die CRL nicht mehr verfügbar ist. Um diesem Problemen entgegen zu wirken, unterstützt die Windows 2003 CA Delta CRLs, die einen etwas spezielleren Mechanismus darstellen. Im Mittelpunkt dieses Kapitels steht vor allem die Hochverfügbarkeit von Certificate Revocation Lists. Damit eine Hochverfügbarkeit erreicht werden kann, muss zum Beispiel auf die Wahl und Reihenfolge der Distribution Points besonders geachtet werden. Den Abschluss dieses Kapitels bildet die Struktur der CRL. Wir haben die Struktur bewusst am Ende dieses Kapitels eingefügt, da sie vor allem denjenigen Lesern dienen soll, die noch mehr über die Funktionen der CRL erfahren wollen. [19], [20], [21], [22], [23] 3.2 Einleitung Um die Zertifikatssperrung und die Statusüberprüfung etwas besser zu verstehen, möchten wir mit dieser kurzen Einleitung zeigen, wie ein Endbenutzer die Effekte einer Zertifikatssperrung und der Statusüberprüfung in Windows XP sehen kann. Ein anschauliches und häufig benutztes Szenario, in dem Zertifikate zum Einsatz kommen, ist bei Verwendung von Microsoft Outlook. Wenn ein Benutzer zum Beispiel eine digital signierte E- Mail bekommt, ist die mit einem speziellen Icon versehen. Abbildung 13: Sichtweise von Microsoft Outlook [19] Um zu überprüfen, ob der Inhalt nicht modifiziert wurde, kann dann die Zertifikatskette angesehen werden. Eine Zertifikatskette wird vom Anwenderzertifikat und dem dazugehörigen Ausstellerzertifikat gebildet. Eine vollständige Zertifikatskette beginnt mit einem selbst signierten Ausstellerzertifikat (self-signed), kann ein oder mehrere Zertifikate von Zwischenzertifizierungsstellen (Sub CAs) enthalten und schliesst mit dem Anwenderzertifikat ab. 39

41 Untenstehende Dialogbox zeigt aber nicht nur an, ob der Inhalt evt. modifiziert wurde, sondern es enthält auch noch weitere Informationen, die von der Microsoft Certificate chaining engine ermittelt werden: Das Zertifikat wurde nicht widerrufen, was an den grünen Häkchen erkennbar ist. Dies gilt für alle Zertifikate in der Zertifikatskette. Die Zertifikatskette besteht aus dem Public Key Zertifikat, das die signierte und einem CA Zertifikat von einer vertrauten Root CA. Dem Zertifikat wird vertraut. Die Microsoft Certificate chaining engine war also fähig eine Zertifikatskette für dieses Zertifikat aufzubauen. Abbildung 14: Message Security Properties [19] Für mehr Informationen über die Zertifikatskette kann auf den Button "View Details" gedrückt werden (Abbildung 15). Dieser Button erlaubt es, die ganze Zertifikatskette vom End-Zertifikat bis zum Root CA-Zertifikat anzusehen und jedes Zertifikat falls notwendig manuell zu überprüfen. Abbildung 15: Informationen zur Zertifikatskette [19] Prüfung des Zertifikatstatus In einer Microsoft Umgebung bestehend aus Windows 2003 Server und XP Clients (analog UBS), wird der Status eines Zertifikates durch drei eindeutige zusammenhängenden Prozesse, die in der Microsoft CryptoAPI implementiert sind, ermittelt. 40

42 1. Certificate Discovery Dieser Prozess sammelt CA Zertifikate von Group Policies, Enterprise Policies und Authority Information Access (AIA) Pointern in den herausgegebenen Zertifikaten und dem ganzen Zertifikats Enrollment Prozess. 2. Path Validation Bei diesem Prozess werden die Public Key Zertifikate und ihre Herausgeber in einer hierarchischen Art und Weise aufgestellt bis die Zertifikatskette bei einem vertrauten, selbst signierten Zertifikat endet. Typischerweise ist das oberste Zertifikat in der Zertifikatskette ein Root CA-Zertifikat. Beim hierarchischen Trustmodell hat jeder Inhaber eines Zertifikats eine Kopie des öffentlichen Schlüssels der Root CA. Grundsätzlich wird hier nur geprüft, ob die Kette von der Root CA über die einzelnen CAs bis zum Benützerzertifikat zusammenhängend, bzw. lückenlos ist. 3. Revocation Checking Jedes Zertifikat in der Zertifikatskette wird geprüft um zu versichern, dass kein Zertifikat gesperrt wurde. Diese Statusprüfung kann entweder gleich mit der Zertifikatskettenbildung oder erst nachher vorgenommen werden. Windows XP und Windows Server 2003 benützen "inline Revocation". Das heisst, die Zertifikate werden schon während dem Aufbau der Zertifikatskette geprüft. Das ist eine Änderung gegenüber Windows 2000, bei welchem die Zertifikatsstatusprüfung erst vorgenommen wird, nachdem die beste Zertifikatskette aufgebaut wurde (auch bekannt als "post-process" Statusprüfung). Somit können Zertifikatsketten in denen ein Zertifikat zurückgezogen wurde, vermieden werden Kettenbildung Die Kettenbildung ist der Prozess, mit dem eine vertraute Zertifikatskette oder ein Zertifikatspfad gebildet werden kann. Die Kettenbildung erfolgt vom End-Zertifikat bis zur Root CA, der von dem Sicherheitsprinzip vertraut wird. Abbildung 16: Zertifikats-Kettenbildung In diesem Beispiel wurde das Benutzer1 Zertifikat von der Issuer CA herausgegeben und das Zertifikat der Issuer CA wurde wiederum von der Root CA herausgegeben. Dies wird als eine vertraute Zertifikatskette betrachtet, weil das Root CA Zertifikat in der vertrauten Root CA enthalten ist. Der Prozess der Zertifikatskettenbildung überprüft jedes Zertifikat in der Zertifikatskette. Falls die Microsoft Certificate chaining engine ein Problem mit einem Zertifikat in der Zertifikatskette 41

43 entdeckt, oder sie kein Zertifikat finden kann, so wird die Zertifikatskette als non-trusted abgelegt. Die ganze Kette von Zertifikaten wird nach ihrer Qualität geordnet. Die beste Zertifikatskette, die für ein gegebenes End-Zertifikat gebildet werden kann, wird dann der aufrufenden Applikation (Client) als Default Kette zurückgegeben. Jedes Zertifikat in der Kette ist mit einem Status Code verbunden. Dieser Code zeigt an, ob das individuelle Zertifikat eine gültige Signatur hat, nicht abgelaufen (time-valid), oder gesperrt ist. Jeder Status Code steht in Verbindung mit einer Priorität. Zum Beispiel hat ein abgelaufenes Zertifikat eine höhere Priorität als ein gesperrtes Zertifikat. Dies, weil ein abgelaufenes Zertifikat nicht auf den Status geprüft werden soll, da es ja sowieso nicht mehr gültig ist. Wenn unterschiedliche Status Codes den Zertifikaten in der Zertifikatskette zugeteilt werden, wird der Status Code mit der höchsten Priorität in den Einsatz kommen und in dem Status der Zertifikatskette angegeben. 3.3 Gültigkeit und Revokation von Zertifikaten Wenn Zertifikate zwecks Authentisierung ausgetauscht werden, dann müssen die Zertifikate überprüft und bewertet werden. Dieses Vorgehen wird in Englisch auch als "Certificate Handling" bezeichnet. Wenn einer Microsoft-Applikation ein Zertifikat vorliegt, dann werden von der Microsoft Certificate chaining engine folgende Komponenten geprüft: Innhalt des Zertifikats: Der Inhalt eines Zertifikats muss dem X.509 Standard entsprechen. Falls die erforderlichen Informationen nicht im Zertifikat enthalten sind oder nicht korrekte Daten vorliegen, wird das Zertifikat als ungültig angesehen. Zertifikatsformat: Ein Zertifikat muss den gültigen X.509 Standard Konformen für digitale Zertifikate entsprechen. Die Certificate chaining engine weist jedes Zertifikat ab, dass nicht den X.509 Versionen 1-3 entspricht. Critical Extensions: Falls das Zertifikat (X.509 Version 3) critical Extensions besitzt, dann wird die Certificate chaining engine diese critcal Extensions der Applikation identifizieren, welche das Zertifikat prüfen möchte. Falls die aufrufende Applikation die critical Extensions nicht versteht, wird sie das Zertifikat als ungültig erklären. Policy validation: Falls die aufrufende Applikation eine spezifische Application- oder Issuance- Policy oder Zertifikats Object Identifier (OID) im Zertifikat erwartet und diese nicht im Zertifikat enthalten sind, so erklärt die Certificate chaining engine das Zertifikat für ungültig. Revocation check: Die Certificate chaining engine ruft die installierten Revocation Provider auf, um sicherzustellen, dass die Seriennummer des zu prüfenden Zertifikats nicht in einer Sperrliste enthalten ist. Falls das Zertifikat in einer solchen Sperrliste enthalten ist, wird es für ungültig erklärt. Root check: Die Zertifikatskette, die von der Certificate chaining engine aufgebaut wurde, muss bis zur vertrauten Root CA reichen oder in einer Certificate Trust List (CTL), die manuell von der Organisation konfiguriert wurde, enthalten sein. Falls die Kette bei einer nicht vertrauten Root CA endet oder nicht mit einer self-signed Root CA verbunden ist, wird das vorliegende Zertifikat als ungültig betrachtet. Signature Check: Wenn eine CA ein Zertifikat ausgibt, wird der Inhalt des Zertifikats vom Private Key der CA signiert. Falls der Inhalt modifiziert wurde, schlägt die Signaturprüfung fehl und das Zertifikat wird ungültig. 42

44 Time Validity: Das aktuelle Datum und die Zeit müssen innerhalb der aktuellen Gültigkeitsperiode des Zertifikats liegen. Ist dies nicht der Fall, wird das Zertifikat von der Certificate chaining engine als ungültig erklärt. 3.4 Gründe für die Revokation eines Zertifikats Die Sperrung eines Zertifikats kann aus verschiedenen Gründen notwendig werden: ein unberechtigter Benutzer erhält Zugang zum Private Key des Zertifikats. ein unberechtigter Benutzer erhält Zugang zu der CA. In diesem Fall müssen alle Zertifikate, welche die CA publiziert hat, zurückgezogen und neu ausgegeben werden. Die Zertifikatsrichtlinien haben sich geändert. Zum Beispiel hat ein Angestellter einen neuen Job in einer anderen Abteilung angenommen. Das Zertifikat wurde ersetzt. Dies ist nötig, wenn ein anderer Verschlüsselungsalgorithmus oder ein längerer Schlüssel eingesetzt wird (Schlüsselerneuerung). Die CA, welche die Zertifikate ausstellt, ist nicht mehr in Betrieb. Der Status des Zertifikates ist "hold" (ReasonCode in CRL-Struktur Kapitel ). Wenn ein Zertifikat gesperrt wurde, kann dies nicht wieder rückgängig gemacht werden. Wenn der Status des Zertifikates fraglich ist, z.b. hat der Benutzer seine Smartcard verlegt und findet sie evt. später wieder, so kann das Zertifikat, das den Status "hold" besitzt, gesperrt und später wieder gültig gemacht werden. Diese Art der Zertifikatssperrung findet in der Praxis jedoch kaum Anwendung. Denn wenn ein Mitarbeiter seine Smartcard als vermisst meldet, dann erhält er meist eine zweite Smartcard, damit er trotzdem arbeiten kann. Wird die vermisste Karte wieder gefunden, so wird der Mitarbeiter dies kaum nochmals melden, weil er ja mittlerweile schon eine neue Karte hat. Somit wird diese Art von Zertifikatssperrung überflüssig. Jemand missbraucht den Private Key oder der Private Key eines Benutzers ist in Gefahr missbraucht zu werden. (Zum Beispiel, wenn eine Smartcard gestohlen wurde). Ein Computer wird ersetzt oder für eine bestimmte Dauer nicht mehr gebraucht, oder der Private Key des Computers ist kompromittiert worden. 3.5 Sperrlisten Um ein Zertifikate auf seine Gültigkeit zu prüfen, muss eine Public Key Infrastructure (PKI), die im Kaptitel 4 beschriebenen Zertifikatsinformationen den einzelnen Personen, Computern und Applikationen, die Zertifikate benutzen, zur Verfügung stellen. Für ein System, dass ein Zertifikat braucht, ist es wichtig, dass eben alle Komponenten überprüft werden. Das heisst, dass nicht nur die Signatur und die Gültigkeitsdauer des Zertifikates geprüft werden sollten, sondern auch den Status, um sicher zu gehen, dass das Zertifikat nicht gesperrt wurde. Damit Zertifikate nicht missbräuchlich gesperrt werden, muss die Sperrung von der allgemein anerkannten Vertrauensstelle (CA) vorgenommen werden. Der Prozess, mit dessen Hilfe die CA den geänderten Status eines Zertifikates bekannt gibt, wird als Certificate Revocation List (CRL) bezeichnet. Es ist das klassische Verfahren und der am weitverbreiteste Standard der im RFC 3280, (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile), beschrieben wird. Wenn ein Zertifikat auf seinen Status geprüft werden soll, so muss in der CRL nach diesem bestimmten Zertifikat gesucht werden. Steht das Zertifikat auf der Liste, so ist es gesperrt. Nicht alle PKIs unterstützen aber den Mechanismus der Statusprüfung mittels Certificate Revocation Lists (CRL). Und in einigen Fällen, wenn zum Beispiel die Zertifikate nur einen tiefenoder mittleren Sicherheitsgrad bieten und der Missbrauch gar unwahrscheinlich ist, oder die Zertifikate nur eine kurze Lebenszeit haben, ist es oft nicht nötig eine Liste der gesperrten Zertifikate zu publizieren. Wenn im Gegensatz die Zertifikate aber einen hohen Wert haben und 43

45 ihre Lebenszeit lange genug ist und ein Missbrauch möglich ist, benötigt man in der Regel eine CRL. Achtung: Ein Root Zertifikat kann nicht mit einer CRL zurückgezogen werden, weil eine Root CA sich selbst signiert. Eine CRL enthält nur Zertifikate, die von einer zugehörigen CA ausgegeben wurden. Die Alternative wäre jedoch, wenn alle Zertifikate, die von der Root CA ausgegeben wurden, gesperrt werden. Denn wenn eine CA keine gültigen Zertifikate mehr hat, verfällt sie und wird ungültig. 3.6 Inhalt einer Certificate Revocation List Mit einer CRL ist es also möglich festzustellen, ob ein Zertifikat zum aktuellen Zeitpunkt gültig ist, oder ob das Zertifikat aus einem bestimmten Grund gesperrt wurde. Erklärt eine CA ein Zertifikat für ungültig, so publiziert sie das gesperrte Zertifikat auf einer CRL. Die Seriennummer eines gesperrten Zertifikates (Certificate Serial Number) wird zusammen mit dem Zeitpunkt (revocationdate) der Sperrung in eine Liste eingetragen. Zusätzlich kann der Grund für die Rücknahme des Zertifikats angegeben werden. RFC 3280 erfordert, dass jede CA regelmässig eine signierte CRL mit allen gesperrten Zertifikaten herausgibt. Die digitale Signatur dient zum Schutz vor Manipulationen und es kann überprüft werden, ob die Integrität der Sperrliste gewährleistet ist. Abbildung 17: CRL-Inhalt [50] Neben dem Aktualisierungszeitpunkt (thisupdate) enthält eine PKIX-konforme CRL den spät möglichsten Zeitpunkt (nextupdate), zu dem von der CA eine neue CRL herausgegeben wird. Es 44

46 kann auch bereits zu einem früheren Zeitpunkt eine neue CRL ausgestellt werden. Den genauen Aufbau der Struktur kann am im Kapitel 3.21nachgelesen werden. 3.7 Funktionsweise der Zertifikatsstatus-Überprüfung mittels CRL Zertifikat/CRL Datenbank CA LDAP 2. CRL kehrt zum Router zurück Datenbank 1. Router fragt CDP für CRL ab Internet Router 1 Router 2 3. Router prüft ob das Zertifikat von Router 1 gesperrt ist Zertifikat von Router 1 Abbildung 18: Funktionsweise der Statusabfrage am Beispiel von Routern Möglicher Ablauf, wenn die Gültigkeit eines Zertifikates geprüft werden muss: 1. Router 1 sendet sein Zertifikat an Router Router 2 liest die CRL Distribution Points (CDPs) vom Zertifikat des Routers 1. CDPs geben den Ort an, an welchem die CRL abgerufen werden kann. Router 2 holt sich die CRL von der entsprechenden Quelle. 3. Die CRL muss signiert sein, damit eine Applikation entscheiden kann, ob sie der CA, welche die CRL herausgegeben hat, auch vertraut. Windows 2000 und Windows XP können nur eine CRL überprüfen, die mit dem gleichen Private Key signiert wurde, wie das ausgegebene Zertifikat. Das heisst, sie unterstützen keine CRL, die von einer anderen Instanz als der CA, welche die Zertifikate herausgegeben hat, signiert wurde. 4. Router 2 muss auch überprüfen, ob die CRL noch nicht abgelaufen ist. Eine CRL verfällt, wenn das aktuelle Datum älter ist, als das Datum, das im NextUpdate-Erweiterungsfeld (siehe Kapitel xy, CRL-Struktur) steht. 5. Router 2 prüft, ob das Zertifikat von Router 1 in der CRL enthalten ist. 6. Falls die Zertifikatsseriennummer nicht in der CRL enthalten ist und alle anderen Komponenten in Ordnung sind, kann das Zertifikat akzeptiert werden. Weiterführende Anforderung für Historisierung Theoretisch sollte eine Zertifizierungsstelle jedes gesperrte Zertifikat bis in alle Ewigkeit in ihrer CRL führen. Der Eintrag für ein einzelnes gesperrtes Zertifikat ist zwar klein er besteht aus Zertifikatsseriennummer sowie der Zeitpunkt und Grund der Sperrung- wenn jedoch sehr viele Zertifikate gesperrt werden müssen, kann die Sperrliste sehr gross werden. Um hier Abhilfe zu schaffen, gehen CAs wie folgt vor: Ein gesperrtes Zertifikat wird nach Ablauf seiner Gültigkeit noch einmal in einer regulären CRL geführt und danach von der Liste genommen. Nach Ablauf 45

47 der Gültigkeit wird dieses Zertifikat ohnehin nicht mehr akzeptiert werden. Diese Vorgehensweise muss von einer CA aber nicht gewählt werden. In einigen Fällen kann es sinnvoll sein eine öffentliche Liste der abgelaufen Zertifikate zu behalten und zu überprüfen. Man kann daher in der Registry der CA konfigurieren, dass gesperrte Zertifikate, die abgelaufen sind, nicht von der CRL entfernt werden dürfen. 3.8 CRL Distribution Point Die von Microsoft verwendete Methode zum Abrufen einer CRL, ist der Einsatz von so genannten CRL Distribution Points (CDP). CDPs definieren den Ort oder das Medium der Sperrliste. In diesem Fall kann sowohl ein genereller Name in den CDPs enthalten sein, als auch der Ort, wo unterhalb des Distinguished Name der CA die CRL im Directory Baum anzutreffen ist. Der Name oder der Pfad wird in Form des Relativ Distinguished Name angegeben. In jeder CA müssen solche Publication Points für herausgegebene Zertifikate definiert werden. Die CDPs erlauben dann den Zugriff auf die Zertifikate und die CRLs der entsprechenden CA. Der Microsoft Client erwartet also zum Abrufen einer Sperrliste einen solchen CDP. Eine andere Art, die Sperrliste zu holen besteht für den Client nicht. Wenn also ein Zertifikat geprüft werden soll, welches keinen passenden CDP enthält oder wenn der Ort im CDP nicht erreichbar ist (z.b. da das Active Directory durch Firewalls nicht erreichbar ist), kann der Client keine Statusprüfung durchführen. Genauso können andere Produkte, die CDPs nicht unterstützen, die Sperrlisten im Active Directory nicht ohne weiteres finden, da der Name der CA und die Ablage der Sperrliste im Directory nicht übereinstimmen. Die Microsoft Certificate chaining engine, ermittelt den Status eines Zertifikates, in dem sie die URLs, die in den CRL Distribution Points und den Authority Information Access (AIA) Erweiterungen gespeichert sind, durchsucht und verarbeitet. (AIA Extensions definieren den Standort der CA-Zertifikate). Bevor die Certificate chaining engine eine neue CRL von der CA abruft, durchsucht sie zuerst den lokalen Zertifikatsspeicher und den lokalen Zwischenspeicher auf eine CRL. Erst wenn die CRL im Zwischenspeicher nicht mehr gültig ist, muss eine neue CRL abgerufen werden. [43] Für die Definition dieser Publication Points können folgende Protokolle für die URLs verwendet werden, mit denen die CRLs im Binärformat (DER) bezogen werden können: Hypertext Transfer Protocol (HTTP) URLs Lightweight Directory Access Protocol (LDAP) URLs File Transfer Protocol (FTP) URLs File URLs Die CRL wird bei der UBS von der Issuer CA ausgegeben. Die Issuer CA ist eine Microsoft Enterprise CA. Eine Enterprise CA legt die CRL per Default an folgende zwei Speicherstellen ab: HTTP URL: LDAP URL:LDAP:///CN=CAName,CN=CAComputerName,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRootDomain,DC=TLD Die CA besitzt ebenfalls einen lokalen CDP. Dieser sollte nicht entfernt werde, denn die CA erfordert den lokalen CDP, um die CRL sich selbst zu publizieren. Weiter braucht die CA die lokale CRL um die Zertifikate vor der Herausgabe an die Benutzer zu prüfen. Der lokale Pfad ist aber nur im CA-Zertifikat enthalten und wird nicht in den ausgegebenen Zertifikaten publiziert Hypertext Transfer Protocol (HTTP) URLs Das HTTP-Protokoll bietet die höchste Flexibilität. Denn fast alle Client-Computer haben einen Web-Browser installiert, der den Zugriff auf eine HTTP URL erlaubt. 46

48 HTTP URLs werden gewöhnlich für interne und externe Publication Points gebraucht. Der Vorteil einer HTTP URL ist, das nur eine geringe Verzögerung zwischen der Publikation und der Verfügbarkeit der CRL besteht. Wenn man eine neue CRL oder ein neues CA-Zertifikat mittels einer HTTP URL publiziert, so stehen sie praktisch sofort für den Download bereit. Weiter können HTTP URLs typischerweise von Clients hinter der Firewall herunter geladen werden und auch von Clients die nicht im Active Directory sind oder auch von solchen, die ein älteres Betriebssystem als Windows 2000 haben oder gar kein Microsoft Betriebssystem einsetzen. Um eine höchst mögliche Verfügbarkeit zu garantieren, können das CA Zertifikat und die CRL mittels Web Cluster publiziert werden. Weiter sollten Round Robin DNS oder virtuelle Namen von Web Servern genutzt werden um die Redundanz des HTTP URLs zu garantieren. HTTPS-URLs können in den CDPs nicht eingetragen werden. Die Implementierung von Secure Sockets Layer (SLL) sollt aber auch nicht nötig sein, da das CA Zertifikat und die CRLs ja von der CA digital signiert wurden. Eine Transport-Sicherheit ist nicht nötig, um die Datenintegrität zu garantieren. Weiter kann der Gebrauch von SSL sehr komplex werden und eine Rekursion verursachen Lightweight Directory Access Protocol (LDAP) URL Das LDAP-Protokoll ermöglicht eine hohe Verfügbarkeit, wenn die CA-Zertifikate und die CRLs im Microsoft Active Directory naming context publiziert werden. Das bedeutet, dass die CRL oder das CA Zertifikat auf allen Domänen Controllern in einem Forest verfügbar ist und von jedem Client in diesem Forest abgefragt werden kann. Diese Clients können Windows 2003, Windows 2000, Windows 98, Windows Me und Windows NT 4.0 Computer sein, die den Directory Service installiert haben. Falls ein expliziter X.500 Distinguished Name für den LDAP URL gebraucht wird, muss Active Directory eine explizite Referenz auf dieses Objekt beinhalten. Auf LDAP URLs können auch nicht-windows Systemen zugreifen, wenn der DNS Name des LDAP Servers in der LDAP URL enthalten ist. Zum Beispiel kann an Stelle von der CDP URL "LDAP://CN=CAName, CN=CAComputer, CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain" die CDP URL "LDAP://LDAPServerr/CN=CAComputer, CN=CDP, CN=Public Key Services, CN=Configuration, ForestRootDomain", verwendet werden. Beim Gebrauch von LDAP bestehen jedoch zwei Nachteile, die hier diskutiert werden sollten: 1. Es kann einige Zeit dauern, bis die CRLs oder CA-Zertifikate im Active Directory an alle Domänen Controller in einem Forest voll repliziert werden. Die benötigte Zeit hängt von der Netzwerk Replikations-Latenzzeit ab. Besonders wenn die Replikation zwischen ganzen Sites als nur zwischen Domänen Controllern in der gleichen Site repliziert werden muss, wird viel Zeit benötigt. 2. Eine Active Directory Unterstützung in Beziehung mit LDAP URLs kann zu Verzögerungen bei der Abfrage von CRLs und/oder CA-Zertifikaten führen. Wenn die LDAP URL die erste URL in der Liste ist, braucht ein nicht Active Directory Client 10 Sekunden um zur nächsten verfügbaren URL zu springen. (nähere Informationen dazu können im Kapitel nachgelesen werden) File Transfer Protocol (FTP) URLs Ein CA-Zertifikat oder eine CRL kann auch auf einem FTP Server publiziert werden. FTP-URLs werden von Microsoft Clients mit einen TCP/IP Protokoll Stack unterstützt. Wie mit HTTP URLs, können FTP URLs von Clients hinter der Firewall heruntergeladen werden. 47

49 3.8.4 File URLs Das File Protokoll erteilt Zugang zu File Shares beim Gebrauch vom Internet File System (CIFS) oder Server Message Blocks (SMBs). Obwohl dieses Protokoll für CA-Zertifikate und CRLs gewöhnlich nicht eingesetzt wird, kann das File Protokoll gebraucht werden um CA-Zertifikate und CRLs auf einem Remote File Server zu publizieren. Eine File URL verweist auf Server Message Blocks, die für die Verbindung der CDPs gebraucht werden. Falls das File mit einer Access Control List (ACL) geschützt wird, hat dies oft Folgen. Die Client-Maschine, die unter dem System Account läuft, muss auf diesen Ort Zugang haben. Dies bedeutet, dass ein anonymer Zugriff in der ACL erlaubt werden muss. Wenn eine CRL publiziert wird, kann die CRL unterschiedliche Namen haben. Dies ist davon abhängig ob das CA Zertifikat erneuert wurde und ob der existierende Private Key beim neuen Zertifikat wieder gebraucht wurde. Untenstehende Tabelle zeigt ein paar Beispiele wie der CRL Name automatisch von einer Microsoft CA generiert wird: Szenario Eine CA namens "IssuingCA" hat ihr CA-Zertifikat noch nie erneuert Eine CA namens "IssuingCA" hat ihr CA-Zertifikat mit dem gleichen Key erneuert Eine CA namens "IssuingCA" hat ihr CA-Zertifikat mit einem neuen Schlüssel erneuert Eine CA namens "IssuingCA" hat ihr CA-Zertifikat 3 mal erneuert mit bereits 2 neuen Keys Name des CRL Name des Delta CRL CA Version Files Files issuingca.crl issuingca+.crl 0.0 issuingca.crl issuingca+.crl 0.0 issuingca.crl issuingca(1).crl issuingca+.crl issuingca(1).crl 2.2 issuingca(3).crl issuingca(3)+.crl Die richtigen Publication Points wählen Bei der Wahl des Publikations-Protokolls muss auch bestimmt werden, wo am besten das CA- Zertifikat und die CRL publiziert werden sollen. Der Entscheid über den Ort beinhaltet die physikalischen Server, auf welchen die Files publiziert werden und die Server im Corporate Network: Intranet oder Extranet. Publication Points sollten nach folgenden Regeln ausgewählt werden: Wenn mehrere Computer auf Windows 2000 oder späteren Versionen laufen und Teil des Forest sind, sollte man eine LDAP URL verwenden, die den Active Directory Configuration naming context referenziert. Dieser Ort wird auf allen Domänen Controllern in einem Forest publiziert und garantiert Verfügbarkeit und Fehlertoleranz. Wenn einige non-forest Computer oder andere Betriebssysteme, wie zum Beispiel UNIX, vorliegen, eignen sich Web Server Publication Points für HTTP URLs am besten. Falls Zertifikate von dem externen Netzwerk ausgewertet werden sollen, müssen das CA- Zertifikat und die CDPs an einen von aussen zugreifbaren Ort publiziert werden. Zum Beispiel auf einem Web Server oder LDAP Server in der demilitarisierter Zone (DMZ) des Netzwerkes. File Publication Points werden typischerweise nicht für CA-Zertifikate und für die Abfrage von CRLs eingesetzt. File Publication Points kommen eher zum Einsatz, wenn die CA- Zertifikate und die CRL Informationen auf einem Remote Server publiziert werden. 48

50 3.8.6 Die richtige Reihenfolge der Publication Points wählen Die Reihenfolge sollte so gewählt werden, dass eine Mehrheit der Clients ein CA-Zertifikat oder eine CRL von der ersten URL in der Liste abrufen können. Wenn mehrere URLs in einer CDP-Extension implementiert sind, so spielt die Reihenfolge dieser Publication Points eine wichtige Rolle. Falls keine richtige Reihenfolge gewählt wird, steht dem Client für jede URL nur eine bestimmte Zeit zur Verfügung, um eine Verbindung zu der CRL aufzubauen. Erst nach Ablauf dieser Zeit versucht der Client sich mit der nächsten URL zu verbinden. Das Default Verhalten eines Windows Clients sieht wie folgt aus: Die maximale Zeit für die Abfrage einer CRL beträgt bei Windows XP 20 Sekunden. Sobald ein Download gestartet wird, beginnt die Zeit zu laufen. Für einen erfolgreichen Verbindungsaufbau stehen dem ersten CDP URL 10 Sekunden zur Verfügung. Falls die CRL innerhalb dieser 10 Sekunden nicht herunter geladen werden kann, wird die Microsoft Certificate chaining engine die nächste URL in der Liste verarbeiten. Den später folgenden CDP Speicherstellen in der Liste stehen maximal die Hälfte der noch verbleibenden Zeit für einen Verbindungsaufbau zur Verfügung. Nach Ablauf dieser Zeit wird wiederum die nächste CDP Speicherstelle in der Liste abgearbeitet. Falls die Microsoft Certificate chaining engine aus irgendwelchen Gründen wie zum Beispiel ungültiger Pfad, Zugriffsverweigerung usw., nicht fähig ist eine CRL während der erlaubten Zeit abzurufen, so wird eine Fehlermeldung "revocation offline" zu der Applikation zurückkehren. Eine sorgfältige Planung der CRL Speicherstellen ist somit sehr wichtig damit timeout Errors bei der Zertifikats-Statusabfrage möglichst vermieden werden können. Die Windows Server 2003 PKI Applikationen suchen in der CRL Distribution Point (CDP) Extension nach einer URL, die auf einen Netzwerk-Speicherplatz zeigt, von welchem die CRL abgerufen werden kann. Weil die CRLs einer Enterprise CA in dem Active Directory abgelegt werden, können auf diese mit dem LDAP-Protokoll zugegriffen werden. Bei Stand-alone CAs werden die CRLs in einem Verzeichnis auf dem Server abgelegt und können mit dem HTTP- und FTP-Protokoll abgerufen werden, solange die CA online ist. Weil der CRL Pfad in jedem Zertifikat enthalten ist, muss der Speicherort der CRL vor der Ausgabe von Zertifikaten festgelegt werden. Denn es kann sein, dass eine bestimmte Applikation ein zu überprüfendes Zertifikat abweist, wenn keine CRL zur Verfügung steht. Die Reihenfolge der URLs spielt jedoch nicht bei allen Betriebssystemen eine wichtige Rolle. Manche Unix Systeme benützen ihre eigenen Methoden um zu ermitteln welche Reihenfolge abgerufen wird, falls mehrere URLs in den CDP Extensions existieren. UBS Innerhalb der UBS Infrastruktur werden zwei CDPs eingesetzt. Der erste CDP ist eine allgemeine HTTP URL. Der zweite CDP zeigt auf das Active Directory der Issuer CA. HTTP Distribution Point: Die CRL wird auf einem anonymen zugänglichen Web Server publiziert. Der Web Server ist auch von ausserhalb der UBS (Extranet, Intranet) zugänglich. Active Directory Distribution Point: Die CRL wird im Active Directory der Issuer CA publiziert. Das heisst, die CRL wird auf allen Domänen Controller einer Windows Site verteilt. In der aktuellen Konfiguration wird für die weltweite Replikation innerhalb UBS eine Stunde benötigt. 49

51 Allgemeine User bzw. non-windows-applikationen haben keinen Zugriff auf das Active Directory. Ein anonymer Zugriff wird in UBS explizit ausgeschlossen. Für diese braucht es den Zugriff via http. 3.9 Nachteile von CRLs Während Certificate Revocation Lists einen idealen Mechanismus für eine umfangreiche Verteilung der Informationen bezüglich gesperrten Zertifikaten für die Clients darstellen, müssen hier einige Nachteile diskutiert werden. 1. Viele Applikationen erfordern eine aktuelle CRL. Die CA hat somit die Aufgabe immer wieder aktuelle CRLs zu publizieren. Je länger jedoch die Publikations-Perioden sind, desto grösser ist die Gefahr, dass ein Client noch eine veraltete CRL benutzt, die sich im Zwischenspeicher befindet. 2. Wenn eine CA von einer grossen Anzahl von Benutzer gebraucht wird, so wird die Liste schnell relativ gross (30'000 Einträge entsprechen zirka 1 MB). Dies bedeutet, dass je nachdem in welchen Intervallen die aktuelle CRL publiziert wird, jedes mal die vollständige CRL vom Server auf die Clients herunter geladen werden muss. 3. Auch wenn sich die CRL nicht verändert hat, d.h. keine neuen Einträge stattgefunden haben, muss die CRL aktualisiert bzw. auf den Client herunter geladen werden. 4. Häufige Publikationen von CRLs erzeugen eine hohe Netzbelastung. Wenn also eine CA häufig eine komplette CRL publiziert, müssen die Clients relativ schnell über diese neue Liste verfügen können. Das häufige Updaten dieser Liste kann eine hohe Netzbelastung zur Folge haben. Das heisst, dass zum Beispiel Probleme mit dem Verbindungsaufbau entstehen können oder einfach eine langsame Netzverbindung zur Verfügung steht. Falls die CRL nicht so häufig aktualisiert wird, entsteht weniger Netzwerk- Verkehr. Es besteht jedoch die Gefahr, dass der Client evt. noch veraltete Sperrinformationen besitzt und ein Zertifikat als gültig betracht obwohl es bereits gesperrt wurde Delta CRL Eine Möglichkeit die übertragene Datenmenge und die damit verbundene Netzbelastung zu reduzieren, bietet der Mechanismus Delta CRL. Eine Delta CRL publiziert nur die Veränderungen der vollständigen CRL (Base CRL, bcrl) in einer kleineren Datei (scrl). Dass heisst, wenn Delta CRL Mechanismus implementiert wird, kann ein Client eine Base CRL in längeren Abständen und die kleineren Delta CRLs in kürzeren Intervallen herunterladen. Die Intervalle können sehr kurz sein, zum Beispiel jede Stunde, um so die CRL aktuell zu halten. Dies bedeutet jedoch nicht, dass die Base CRL nun nicht mehr herunter geladen werden muss. Die Base CRL muss jedes Mal herunter geladen werden, wenn die vorhergehende Base CRL abläuft (ungültig wird). 50

52 Abbildung 19: Delta-CRL Im obigen Bild wird die Base CRL (CRL#1) mit drei zurückgezogenen Zertifikaten zur Zeit t0 publiziert. Zum Zeitpunkt t1 wird das Zertifikat mit der Seriennummer 444 zurückgezogen. Wenn die Delta CRL (CRL#2) zum Zeitpunkt t2 publiziert wird, zeigt die Delta CRL an, dass sie Änderungen der Base CRL#1 enthält. Zur Zeit t3, wird ein zweites Zertifikat mit der Seriennummer 555 gesperrt. Wenn eine neue Delta CRL (CRL #3) zur Zeit t4 publiziert wird, enthält sie beide Seriennummern der gesperrten Zertifikate 444 und 555. Zum Schluss, wenn die Base CRL zum Zeitpunkt t5 wieder aktualisiert wird, enthält die aktuelle Base CRL (CRL#4) die Seriennummern der gesperrten Zertifikate 444 und 555 ebenfalls. Die neuen Delta CRLs, die nach t5 publiziert werden, enthalten nur noch die Zertifikate, die seit der Ausgabe von CRL#2 und nach t3 gesperrt wurden. Der erste Algorithmus für Delta CRL bezieht sich auf die letzte volle propagierte Base CRL. Falls eine Base CRL nicht erreichbar ist, bezieht sich die Delta-CRL auf die letzt verfügbare Base CRL. Der Delta CRL Prozess ist vergleichbar mit einer inkrementellen Backup-Strategie. Das Inkrementelle Backup beinhaltet alle Dateien, die seit dem letzten Full-Backup geändert wurden. Die Delta CRL beinhaltet alle Zertifikate, die seit der letzten Base CRL zurückgezogen wurden Optionale Erweiterungen Damit Delta CRLs eingesetzt werden können, wurden einige neue optionale Erweiterungen die in RFC 3280 definiert sind, zur CRL hinzugefügt. Diese Erweiterungen beinhalten: CRL Number Ist eine non-critical Extension und ist eine eindeutige Sequenznummer, die sich mit jeder Herausgabe der CRL erhöht. Wie Abbildung 19 ersichtlich, erhöht sich die CRL Nummer (z.b. CRL#1) für jede ausgegebene CRL. Dabei wird nicht unterschieden ob es sich um eine Baseoder Delta CRL handelt. Das Erweiterungsfeld mit der CRL Number ist in den Base- und Delta CRLs enthalten Delta CRL Indicator Diese Erweiterung muss in allen Delta-CRLs als critical markiert sein. 51

53 ASN.1-Definitionen Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnvalue OCTET STRING } deltacrlindicator EXTENSION ::= { SYNTAX BaseCRLNumber IDENTIFIED BY id-ce-deltacrlindicator } id-ce-deltacrlindicator OBJECT IDENTIFIER ::= { } BaseCRLNumber ::= CRLNumber CRLNumber ::= INTEGER (0..MAX) Diese Erweiterung verweist auf die vollständige (Base) CRL, auf der eine Delta CRL basiert. Das Feld deltacrlindicator enthält die CRLNumber der regulären CRL. Mit einer Base CRL und den darauf basierenden Delta CRLs hat der Benutzer die Möglichkeit, effizient den aktuellen Status von Zertifikaten zu verwalten. Der deltacrlindicator unterscheidet die Delta CRLs von der Base CRL. Zusätzlich wird durch den deltacrlindicator die Base-CRL referenziert. Wichtig ist nun, dass die CRL-Number beginnend von der vollständigen CRL bis zur aktuellsten Delta CRL eine stetig um eins steigende Zahlenfolge bildet. Wenn dies der Fall ist, weiss die Anwendung, dass die Sperrinformation lückenlos vorliegt. Falls die verfügbare Base CRL älter ist, als die Base CRL, die im DeltaCRLIndicator angegeben ist, dann kann die Delta CRL in Verbindung mit der Base CRL nicht gebraucht werden. Trifft dieses Szenario ein, versucht die Microsoft Certificate chaining engine eine aktuellere Base CRL aufzurufen Freshest CRL Ist eine non-critical Extension, die den Ort für den Aufruf der Delta CRLs beinhaltet. Falls die Freshest CRL weder in der Base CRL noch im Zertifikat enthalten ist, so wird die Base CRL als normale CRL behandelt. Dass heisst, es wird nicht zwischen Base CRL und Delta CRL unterschieden. Diese Extension darf in einer Delta-CRL nicht existieren. id-ce-freshestcrl OBJECT IDENTIFIER ::= { id-ce 46 } FreshestCRL ::= CRLDistributionPoints Jeder Distribution Point ermittelt den Ort, an welchem die Delta CRL abgerufen werden kann. Applikationen, die unter Windows XP oder Windows Server 2003 laufen, sind fähig die Freshness Period bei einer CRL-Anforderung zu prüfen. Die Freshness Period spezifiziert, in Sekunden, das maximal zulässige Alter einer Base- oder Delta CRL (Alter = Differenz zwischen der aktuellen Zeit und dem ThisUpdate Feld in der CRL). Wenn die CRL älter ist, als die Freshness Period, dann muss eine neue CRL geladen werden CRL Publication Period Ist eine non-critical Extension, die dem Client sagt, zur welcher Zeit er nach einer neuen CRL schauen soll. Hat die Base CRL oder die Delta CRL eine CRL Publikations-Periode definiert, so bestimmt diese Erweiterung, wann eine neue Base CRL oder Delta CRL abgerufen werden kann. Für diese Extension wird eine Microsoft Object ID (OID) benötigt. Diese OID ist bekannt als nextpublish Extension. 52

54 3.11 Funktionsweise der Delta CRL Sobald eine CRL aufgerufen wird, prüft die Microsoft Certificate chaining engine die CDPs im Zertifikat, die angeben wo die aktuelle Base CRL zu finden ist. Falls der Delta CRL Mechanismus implementiert ist, beinhaltet die Base CRL die Freshest CRL Extension, die den Ort für den Aufruf der Delta CRL beinhaltet. Somit versucht die Microsoft Certificate chaining engine die Delta CRL abzurufen, die in der Freshest CRL Extension angegeben ist. Zeit thisupdate nextupdate nextupdate thisupdate thisupdate crlnumber 0 Delta CRL crlnumber1 Delta CRL 2 crlnumber 2 basecrlnumber 0 basecrlnumber 1 Abbildung 20: Delta CRL Mechanismus Die abzurufende Delta CRL hat ihre eigene Identifizierungs-Nummer. Das deltacrlindicator Feld enthält die Nummer der Base CRL, die von der Delta CRL gebraucht wird. Sobald die Publikationsperiode einer CRL abgelaufen ist, wird die Microsoft Certificate chaining engine eine neue und aktuelle Delta CRL suchen. Ob die Publikationsperiode noch gültig ist, wird festgestellt, indem die aktuelle Zeit mit der Zeit im ThisUpdate-Feld verglichen wird. Wenn die aktuelle Zeit grösser oder gleich ist wie die Zeit in nextpublish, dann sollte eine Delta CRL erneuert werden Client Prozessing Windows XP unterstützt einige Änderungen damit die Clients den Delta CRL Mechanismus implementieren können. Speziell, wurden folgende Änderungen gemacht: Active Revocation Freshness Policy: Die Applikation, die eine CRL abrufen möchte, kann eine Policy oder das Ziel für die Revocation Freshness Information spezifizieren. Die Policy definiert Richtlinien, die zum Beispiel spezifizieren, dass die Sperrinformation maximal 8 Stunden alt sein darf. Wenn also eine Base CRL oder Delta CRL gefunden wird, die erst vor 6 Stunden publiziert worden ist, dann wird die Certificate chaining engine nicht versuchen eine neue Delta CRL oder Base CRL abzurufen. Revocation Freshness Property: Angenommen man hat keine Policy für die Revocation- Freshness, wird der Code versuchen so gut wie möglich Revocation Freshness einzusetzen. Bei jedem Aufruf sollte die Revocation Freshness Information für die aufrufende Applikation verfügbar sein. Einrichtungen, falls die CA Delta CRLs publiziert: Die Clients sollten immer prüfen, ob eine FreshestCRL Extension in dem Zertifikat oder der CRL enthalten ist. Wenn in der CRL keine solche Extension gefunden wird, dann wird die CA den Standard Full CRL-Prozess einsetzen. 53

55 Delta CRL processing: Falls die FreshestCRL Extension gefunden wird, dann sollte diese für die Abfrage der CRL eingesetzt werden. Der Client sollte dann beide CRLs (Base und Delta) für die Überprüfung der Zertifikats-Status prüfen. Caching Delta CRL's: Wie bei Base CRLs, sind alle abgefragten Delta CRLs im Zwischenspeicher (Kapitel 3.17) abgelegt. Looking for new Delta CRL's: Der Client kann bereits nach einer neuen Delta CRL Ausschau halten, sobald die Publikations-Periode mit der thisupdate Zeit in der CRL überlappt. Das heisst, aktuelle Zeit = CRL thisupdate + CRL nextpublish. Die Windows XP Clients können das nextpublish-feld in der CRL gebrauchen um die nächste Base oder Delta CRL entsprechend abzurufen Auswahl des richtigen CRL Typs Bei der Auswahl des richtigen CRL Typs müssen vorerst einige Überlegungen gemacht werden. Base und Delta CRLs werden folgend nochmals kurz zusammengefasst. Base CRLs Base CRLs beinhalten eine komplette Liste aller zurückgezogenen Zertifikate. Diese Listen können in Organisationen, die eine hohe Anzahl von Zertifikaten ausgeben aber sehr schnell wachsen. Der Update von Base CRLs benötigt zudem eine hohe Bandbreite. Daher muss das Gleichgewicht von den Benefits der Publikation von gesperrten Zertifikaten und den Kosten bezüglich den Netzwerkressourcen gefunden werden. Base CRL müssen öfter publiziert werden um die Aktualität der CRL zu garantieren. Delta CRLs Delta CRLs erlauben das CRL Management zu vereinfachen. Eine Delta CRL beinhaltet nur Informationen über die Zertifikate, die seit der letzten Publikation der Base CRL zurückgezogen wurden; darum ist die Delta CRL während ihrer Lebenszeit aktueller und präziser. Weil die Delta CRLs kleiner sind als die Base CRLs erfordern sie weniger Bandbreite für die Replikation quer durch das Netzwerk. Sie können häufiger publiziert werden und erhöhen die Sicherheit der PKI. Bei der Kombination von Base- und Delta CRLs, kann man die Effektivität von CRLs maximieren und das erforderliche Management reduzieren. Delta CRLs können dem Problem der Listengrösse und daraus entstandenen Performanceproblemen etwas entgegen wirken. Vor dem Einsatz von Delta CRLs sollte man sich überlegen, ob dieser Mechanismus im konkrete Umfeld einer Organisation realisierbar ist und Sinn macht. Der Gebrauch von Delta CRLs in Verbindung mit Base CRLs hängt von den folgenden Faktoren ab: - Kompatibilität: Im Windows-Umfeld erkennen nur Windows XP Clients Delta CRLs. - Volumen: Je nach dem, wie gross die Base CRL werden kann, lohnt es sich die kleineren Delta CRLs einzusetzen. In der UBS ist momentan ein Zertifikat 4 Jahre gültig. Bei ca. 30'000 Angestellten kann daher die CRL innerhalb dieser 4 Jahre schon ziemlich gross werden. - Online Status: Delta CRLs sollten nicht im Zusammenhang mit offline CAs gebraucht werden. 54

56 Abbildung 21: Entscheid für den richtigen CRL-Typ 3.14 Verzeichnisdienst-Anbindung Ein Problem bei PKI-Projekten ist immer wieder die Anbindung an Verzeichnisdienste. Diese Probleme tauchen verstärkt dann auf, wenn über Firmengrenzen hinaus sicher kommuniziert werden soll. Während die Verteilung des Zertifikates im Verzeichnisdienst kein Problem darstellt, ist die Verteilung der CRL schon eher problematisch. Dies weil Verzeichnisdienste im Allgemeinen nicht ausserhalb der Firmennetzwerke zur Verfügung stehen. Dadurch kann es Probleme mit verschiedenen Namensgebungen und Verzeichnisstrukturen in verschiedenen Organisationen geben. Eine Tatsache ist, dass Produkte verschiedener Hersteller verschiedene Voraussetzungen für das Auffinden von CRL-Informationen haben Active Directory Überlegungen Microsoft bietet eine direkte Active-Directory-Unterstützung nur bei Verwendung einer Enterprise CA. In diesem Fall werden Zertifikate und CRLs automatisch im Active Directory veröffentlicht. Eine automatische Veröffentlichung in anderen Verzeichnissen via LDAP wird nicht unterstützt. Im Stand-Alone-Modus ist keine direkte Integration mit einem Directory vorhanden. Active Directory unterstützt LDAPv3 in der Form, dass Anwendungen per LDAPv3 auf das Active Directory und die Zertifikate und Sperrlisten zugreifen können. Es können aber auch Anwendungen anderer Hersteller auf Zertifikate und Sperrlisten zugreifen. Hierzu müssen die Clients allerdings die CDP und AIA Extensions zum Auffinden der Sperrlisten bzw. CA-Zertifikate im Active Directory unterstützen. Da die Directory Struktur des Active Directory in der Praxis nicht der Namensstruktur in den Zertifikaten und Sperrlisten entspricht, kann es für Anwendungen, welche diese Erweiterung nicht unterstützen schwierig sein, die richtigen Informationen zu finden. Die Publikation der CRLs im Active Directory erlaubt eine saubere Replikation der CRLs und garantiert, dass ein Client Verbindung zu einer lokalen Kopie von einer CRL hat. Gewisse Komplikationen und Schwierigkeiten (siehe Kapitel 3.15) können jedoch während der Kombination der CRL Publikation und der Active Directory Replikation entstehen. 55

57 UBS In der UBS wird die CRL im Active Directory der Issuer CA publiziert. Die CRL wird dann auf allen Domänen Controller verteilt, durch den Windows Site Replikationsmechanismus. Die weltweite Replikation innerhalb der UBS beträgt maximal eine Stunde Erstellen eines CRL Publikationsplans CAs publizieren CRLs gemäss einem erstellten Publikationsplan. Wie häufig eine CRL publiziert wird, hängt in erster Linie vom Bedarf der gegebenen Applikation ab und wie stark die Aktualität der CRL von einer Organisation gewichtet wird. Hier eine typische Publikationsplanung, beim Einsatz von Delta CRLs: Wöchentliche Publikation von Base CRLs Tägliche Publikation von Delta CRLs Die kleinste Gültigkeitsperiode einer CRL, die beim Microsoft Certificate Service gewählt werden kann, beträgt eine Stunde. UBS In der UBS werden bis auf weiteres nur Base CRLs eingesetzt. Diese werden alle 2 Tage erneuert und haben eine Gültigkeit von 4 Tagen. Somit muss die CA erst 4 Tage nach dem Ausstellen der letzten CRL zwingend wieder in Betrieb sein, das heisst, ein Ausfall am Wochenende kann überbrückt werden. Die Planung ist für eine erfolgreiche PKI ein wichtiger Aspekt. Eine Organisation muss zuerst die Kapazität und Charakteristiken ihrer Netzwerk-Infrastruktur kennen. Erst dann können Entwicklungs-Richtlinien und Sicherheits-Regeln der PKI für die Infrastruktur erstellt werden, die für die Einschränkungen und Kapazitäten gelten. Dabei sollten folgende Punkte besonders berücksichtigt werden: Die Replikations-Latenzzeit des Active Directories Die Verfügbare Bandbreite für den CRL Download im Netzwerk Benutzer Anforderungen für die Latenzzeit auf Grund der Status-Prüfung Es darf dabei nicht vergessen werden, dass oftmals die vom Management gestellten Anforderungen technisch nicht umsetzbar sind. Weiter könnten auch Sicherheitsrichtlinien oder Business-Anforderungen oder das deklarierte Budget einen starken Einfluss auf die effektive Umsetzung haben. Eine Organisation muss daher eine Balance zwischen der Sicherheit, der Kapazität der IT- Infrastruktur und dem technisch und finanziell Machbaren finden. Bei den Kapazitätsanforderungen ist es zum Beispiel unrealistisch die Latenzzeit der Zertifikats- Statusprüfung auf 8 Stunden zu setzen wenn die Replikationszeit im Active Directory 24 Stunden beträgt Base CRL Publikationsplanung Die Basisvoraussetzung bei Delta CRL ist, dass die aktuelle Base CRL Nummer immer grösser oder gleich sein muss, wie die Base CRL Nummer, die im DeltaCRLIndicator angegeben ist. Das bedeutet, dass bevor man eine Delta CRL auf eine Base CRL referenzieren kann, muss die Base CRL von allen Clients abrufbar und erreichbar sein. Falls die referenzierte Base CRL nicht erreichbar ist, dann müssen die Clients den Standard CRL Prozess einsetzen. Um das Eintreten dieses Falls zu vermeiden, muss die CA auf die beste abschätzbare Directory Service Replikations-Zeit konfiguriert werden. Die CA sollte keine neue CRL abrufen bevor: t Base ThisUpdate + t DS Replication vergangen ist. 56

58 Wenn man jedoch die Publikationszeit der Base CRL zu lange wählt, dann haben evt. Clients noch eine Referenz auf eine veraltete Base CRL Delta CRL Publikationsplanung Typischerweise werden die Delta CRLs häufiger als die Base CRLs publiziert. Der Grenzfaktor ist der Replikations-Intervall für Active Directory oder den Grad den man will, dass die Clients fähig sind die Sperrinformation zwischen zu speichern (Falls Active Directory nicht gebraucht wird). Falls die Delta CRL Publikationsperiode kleiner als die Replikationszeit im Active Directory ist, können die Clients keine aktuelle CRL akquirieren. Dies kann jedoch umgangen werden, indem man die folgenden Änderungen bei der Konfiguration der Delta CRL Publikation beachtet: Man sollte den Delta CRL Publikations-Intervall grösser oder gleich wählen als den Active Directory Replikations-Intervall. Die LDAP CDP sollten nicht in der FreshestCRL einbezogen werden. Wenn der LDAP-Pfad nicht in der FreshestCRL integriert ist, dann wird Active Directory bei der Abfrage der Delta CRL auch nicht gebraucht. Man sollte versichern, dass die HTTP oder die FTP Server-Referenz in der FreshestCRL hoch verfügbar ist. Die Publikation in einer Webumgebung mit Network Balancing Services oder mehreren Web Servern die Round Robin DNS Adressierung unterstützen, ermöglichen eine Hochverfügbarkeit der CRL Manuelle Publikation der Delta CRL CRLs können bei Bedarf auch manuell und direkt veröffentlicht werden. Wird eine Sperrliste vor der nächsten geplanten Publikation veröffentlicht, so wird sie am Ende der aktuellen Publikationsperiode automatisch ein zweites Mal veröffentlicht. Man sollte jedoch bedenken, dass die Clients über eine zwischengespeicherte CRL verfügen und diese bis zum Ablauf der Gültigkeitsdauer von den Clients weiterhin verwendet wird. Dies, obwohl eine neue CRL publiziert wurde. Nach eigenen Erfahrungen muss man nach der manuellen Publikation die CRL dann auch noch manuell auf dem Client speichern, damit die zwischengespeicherten CRLs überschrieben werden. Bei einer grossen PKI ist dies jedoch praktisch nicht umsetzbar Grundfragen, auf denen die Publikationsplanung basieren sollte Im Folgenden möchten wir ein paar Grundfragen in den Mittelpunkt stellen, auf denen die Publikationsplanung von CRLs basieren sollte. 1. Welches ist die maximale Periode, in der meine Organisation revozierte Zertifikate akzeptiert? Falls die Default Intervalle eingesetzt werden, wird die Base CRL wöchentlich und die Delta CRL täglich publiziert. Diese Publikationsintervalle müssen allenfalls neu definiert werden, damit sie dem Risiko-Level des Unternehmens entsprechen. 2. Welches Betriebssystem wird eingesetzt? Wenn die Clients auf Windows 2000 oder älteren Versionen laufen, sollte man kürzere CRL Publikationsintervalle definieren, so dass die Clients eine aktuelle Information haben. Nur Windows XP und Windows Server 2003 Betriebssysteme unterstützen Delta CRLs. Falls andere Betriebssysteme wie zum Beispiel UNIX im Einsatz sind, muss geprüft werden ob allenfalls Delta CRL unterstützt wird. 57

59 3. Welche Netzbelastung wird mit dem Download der CRL verursacht? Je häufiger Base CRLs publiziert werden, desto öfter laden die Clients die CRL auf ihren Computer herunter, was die Netzbelastung erhöht. 4. Wie gross ist die Delta CRL? Das Publizieren von Delta CRLs zwischen den Base CRLs kann auch zur Folge haben, das die Delta CRLs ziemlich gross werden. Das Ziel einer Delta CRL jedoch ist es, die Grösse der herunter geladenen CRLs zu reduzieren und die Statusinformationen trotzdem häufiger aktualisieren zu können. Im Falle einer grossen Delta CRL, sollten die Publikationsintervalle der Base CRL reduziert oder Delta CRLs sollten weniger häufig publiziert werden. 5. Wie oft werden Zertifikate gesperrt? Die Häufigkeit, mit der Zertifikate innerhalb einer Periode gesperrt werden, hat auf den Publikationsintervall für die Base- und Delta CRL einen grossen Einfluss. Der Publikationsintervall sollte so gewählt werden, dass die Zertifikate so schnell wie möglich als gesperrt erkannt werden. Je nach Anforderungen der Applikation kann die verlangte Aktualität der CRL unterschiedlich sein. Der Intervall sollte jedoch auch in Balance mit der Netzperformance stehen. 6. Wie gross ist die Netzwerk Latenzzeit für die Replikation im Active Directory Die Delta CRL und Base CRL Publikationsintervalle hängen von der Replikations-Latenzzeit des Active Directory ab. Wenn zum Beispiel die Replikations-Latenzzeit 8 Stunden beträgt, sollte die CRL Publikation in einem Intervall von mehr als acht Stunden stattfinden, da sonst die CRL während der Active Directory Replikation nicht verfügbar ist. 7. Wie lange ist die akzeptierte Zeit für ein Disaster-Recovery Falls ein Zertifikats-Service ausfällt, muss man die CA wieder aufbauen und die CA Datenbank und die Registry Settings wieder herstellen, bevor die bisherige CRL abläuft. Falls der CRL Publikationsintervall kürzer ist als die Zeit, die für das Recovery einer CA benötigt wird, kann unter Umständen keine Statusprüfung aller von dieser CA ausgegebener Zertifikate mehr durchgeführt werden, weil keine aktuelle CRL herunter geladen werden kann Zwischengespeicherte CRLs Sobald die Microsoft Certificate chaining engine eine Base oder Delta CRL abgerufen hat, wird sie eine Kopie der CRL lokal auf dem Client System speichern. Der Zwischenspeicher bleibt gültig, solange die CRL gültig ist (nextupdate). Die Vorteile von zwischengespeicherten CRLs sind, dass die Microsoft Certificate chaining engine immer zuerst nach einer zwischengespeicherten Kopie sucht, um das durchqueren des ganzen Netzwerkes und grosse Latenzzeiten zu vermeiden. Der Nachteil vom lokalen Zwischenspeichern ist jedoch, dass der Client nicht nach einer neuen CRL oder Delta CRL sucht, bis die CRL abgelaufen ist. Wenn also eine Sperrung eines Zertifikates erfolgte und die CA eine neue CRL publizierte, wird der Client nicht die neue CRL gebrauchen, weil die lokale Kopie noch Gültigkeit hat. Ein Weg ein Client dazu zu zwingen eine neue CRL herunter zu laden ist, indem man den Cache wieder leert. Diese Aufgabe ist jedoch in den meisten Netzwerken nicht so einfach zu lösen und hängt von den Anforderungen der Organisation ab. Für jede URL, die in den CDPs angegeben ist, wird die Microsoft Certificate chaining engine folgende Aufgaben ausführen: Entscheiden ob der Inhalt der URL lokal im Zwischenspeicher abgelegt wurde. Falls eine zwischengespeicherte Version gefunden wird, muss garantiert werden, dass die Version time-valid, name-valid und signature-valid ist. Falls eine gültige CRL gefunden wird, enthält sie die definitive Quelle der Sperrinformation. 58

60 Falls keine CDPs gefunden werden, die lokal zwischengespeichert wurden oder keine gültige zwischengespeicherte CRL gefunden wird, wird die Certificate chaining engine eine gültige CRL im lokalen CA-Zertifikats-Speicher suchen. Für alle gefundenen name-valid CRLs, wird die erste time- und signaure-valid CRL als Quelle akzeptiert. Falls schlussendlich keine gültige CRL mittels CDPs abgerufen werden kann, endet der Prozess mit einer entsprechenden Fehlermeldung CRL Overlap Um CRL-Publikationsfehler, Netzwerkausfälle oder lange Replikations-Latenzzeiten möglichst zu vermeiden, kann eine Organisation einen Overlap der Gültigkeitsperioden einer Publizierten CRL kreieren. Der Overlap ist wichtig, weil so garantiert werden kann, dass immer eine CRL verfügbar ist. Vor allem bei der Verteilung der CRLs auf die entsprechenden Clients ist es wichtig, dass vor Ablauf der Gültigkeit der CRL, dem Client bereits eine neue CRL zur Verfügung steht. CRL Overlaps können in der Registry mit folgenden Werten festgelegt werden: CRLOverlapPeriod: Definiert die Überlappungsperiode, die für die CRL Publikation gedacht ist. CRLOverlapUnits: Definiert die aktuellen Units (z.b. Minuten oder Stunden) einer CRLOverlap-Periode, die für die CRL Publikation implementiert ist. Clockskewminutes: Definiert die Periodenlänge für den Overlap des clock skews (Zeit- Toleranz) der zwischen Clients erlaubt ist. Diese 3 Registry-Einträge arbeiten in Verbindung mit der CRL Publikation und der Active Directory Replikations-Latenzzeit. Zum Beispiel, wenn die Replikationszeit im Active Directory 3 Stunden beträgt, ist es sinnvoll die Overlap-Periode auf 4 Stunden zu setzen. CRLPeriod REG_SZ = Weeks CRLPeriodUnits REG_DWORD = 1 CRLOverlapPeriod REG_SZ = Hours CRLOverlapUnits REG_DWORD = 4 ClockSkewMinutes REG_DWORD = a Die CRLPeriod und die CRLPeriodUnits sind in der CA Konsole definiert, während die CRLOverlapPeriod, CRLOverlapUnits und ClockSkewMinutes in der Registry definiert werden können. In der obigen Konfiguration, ist die Gültigkeitsperiode auf 1 Woche, 4 Stunden und 10 Minuten gesetzt. Dieses Resultat ist die Summe der CRLPeriod, CRLOverlapUnits und ClockSkewMinutes. Die Gültigkeitsperiode der CRL ist nicht dasselbe wie die Publikationsperiode einer CRL. Die Gültigkeitsdauer einer CRL entspricht dem Zeitraum, in dem die Liste von der Zertifikatsüberprüfung als massgebend angesehen wird. Die Publikationsperiode ist ein festgelegter Zeitintervall, nach dem von der CA automatisch eine neue CRL publiziert wird. Die maximale Base- oder Delta-CRL Overlap ist die Publikationsperiode. Die Gültigkeitsperiode überlappt die Publikationsperiode per Default um 10%. Das heisst, der Overlap beträgt 10% der Lebenszeit einer CRL. Wenn zum Beispiel eine CA ihre CRL alle 24 Stunden publiziert, dann wird die Gültigkeitsperiode auf 26.4 Stunden gesetzt. Zusätzlich wird die Gültigkeitsdauer verlängert, indem zu Beginn und am Ende der Publikationsperiode eine Toleranz (Clock skew) von 10 Minuten eingeräumt wird. Damit werden 59

61 Abweichungen der Systemuhr unterschiedlicher Computer kompensiert. Aus diesem Grund ist die CRL bereits 10 Minuten vor Beginn ihrer Publikationsperiode gültig. Wenn eine Base CRL und eine Delta CRL gerade erst publiziert wurden, kann ein gesperrtes Zertifikat in beiden CRLs erscheinen. Dies, weil die Delta CRL immer noch auf eine alte Base CRL verweist, während die neue Base CRL bereits repliziert wurde. Mit diesem Mechanismus, die Zertifikate in beiden CRLs zu publizieren, wird versichert, dass die Widerrufung des Zertifikates hoch verfügbar ist. Falls die Systemumgebung keine Delta CRLs ausgibt, haben die CRLDeltaOverlapUnit und DeltaOverlapPeriod Definitionen keinen weiteren Einfluss und werden vom System ignoriert CRL Partitionierung Die CRL wächst mit jedem gesperrten Zertifikat um 29 Bytes. Die Grösse kann aber je nach Rückzugsgrund weiter anwachsen. Um die Zeit für das Herunterladen der CRLs zu minimieren und Performance Probleme zu vermeiden, besteht die Möglichkeit das CA Schlüsselpaar jedes Mal zu erneuern, wenn die CRL die kritische Grösse erreicht hat. Eine Erneuerung des Schlüsselpaares bedeutet, dass eine CRL für das alte Schlüsselpaar und eine CRL für das neue Schlüsselpaar erstellt wird. Obwohl beide, die alten und die neuen Zertifikate von der gleichen CA ausgegeben wurden, wird die Gültigkeit mit unterschiedlichen CRLs geprüft. CRLs müssen für alle vorhandenen CA Schlüssel publiziert werden. Man kann nicht nur eine CRL für mehrere Schlüsselpaare erstellen. Die CRL-Erweiterung IssuingDistributionPoint die im Kapitel genauer beschrieben wird, stellt eine weitere Möglichkeit dar, wie die CRLs partitioniert werden können. Dabei kann jeder DistributionPoint die CRL für ein bestimmtes Intervall von Zertifikatsseriennummern vorhalten. Weiter ist es auch möglich, die Aufteilung auf mehrere DistributionPoints aufgrund des Zertifikatstyps (Endanwender oder CA-Zertifikat) vorzunehmen. Applikationen müssen dann nur eine Teilmenge der CRL verwalten Zuverlässigkeit und Verfügbarkeit der CRL Viele Applikationen verlassen sich auf die Verfügbarkeit der CRL und versagen, wenn der Zugriff auf die CRL nicht möglich oder veraltet ist. Um die Zuverlässigkeit und Verfügbarkeit der CRLs zu versichern, sollten deshalb folgende Punkte beachtet werden: Die CRL soll für eine genügend lange Zeit konfiguriert werden. Denn falls ein Hard- oder Softwarefehler entsteht, soll für das Recovery der CA, noch genügend Zeit vorhanden sein. Es soll eine vernünftige Overlap Periode gesetzt werden um die CRL Publikation zu optimieren und sich gegen Replikaktionsfehler zu schützen. Der Private Key der CA und eine Kopie der CRL sollten an einem sicheren nicht mit dem Netz verbundenen Ort abgelegt werden. Somit kann in einem Katastrophenfall eine gültige CRL manuell signiert und publiziert werden. Zur Publikation von CRLs innerhalb einer Windows-Domäne sollte, wenn immer möglich, Active Directory gebraucht werden. Dies erhöht die Verfügbarkeit und Netzwerkperformance. Die Replikation zwischen den Domänen Controllern kann aber sehr viel Zeit beanspruchen. CRLs sollten nicht im Active Directory publiziert werden, wenn die Publikationsperiode kürzer als die Replikations-Latenzzeit in einem Active Directory Forest ist. 60

62 3.21 CRL Struktur Bei der Realisierung von öffentlichen Sicherheitsinfrastrukturen spielen Sperrlistenformate und Erweiterungen für Sperrlisten eine wichtige Rolle. Zur Definition der Datenstrukturen von CRL wird die Abstract Syntax-Notation 1 eingesetzt. ASN.1 definiert lediglich die abstrakte Darstellung von Daten und dient der plattformunabhängigen Definition von Datenstrukturen. Mehr Informationen zu ASN.1 können im Kapitel 1.8 nachgelesen werden. Die nach X.509v.3 definierte Certificate Revocation List ist grundlegend wie folgt strukturiert: [18] ASN.1-Definition CertificateList ::= SEQUENCE { tbscertlist TBSCertList; signaturealgorithm AlgorithmIdentifier, signature BIT STRING } Der ASN.1 Sperrlistentyp CertificateList besteht syntaktisch aus einer Folge von jeweils drei Feldern, die zur Trennung der zu signierenden Daten tbscertlist, des zu benutzenden Signaturalgorithmus signaturealgorithm und der eigentlichen Signatur dienen. Es ist jedoch zu sagen, dass X.509-PKIX-konforme Zertifizierungsstellen CRLs nicht ausstellen müssen, wenn andere Möglichkeiten zur Abfrage des Status von Zertifikaten angeboten werden Signaturalgorithmus Dieses Signaturfeld signaturealgorithm vom Typ AlgorithmIdentifier enthält den Bezeichner des kryptographischen Algorithmus, der von der Zertifizierungsstelle zum Signieren der Sperrliste benutzt wird. Dabei gilt zu beachten, dass Signaturalgorithmen immer in Kombination mit Einweg-Hash-Funktionen und digitalen Signaturformaten benutzt werden. Das Signaturfeld besteht aus den Teilfeldern algorithm und parameters. Das Teilfeld algorithm ist ein Objektbezeichner, der zur Identifikation des Algorithmus dient. Der Inhalt des optionalen Teilfeldes parameters ist abhängig vom angegebenen Algorithmus und dem Algorithmusbezeichner. ASN.1-Definitionen TBSCertList ::= SEQUENCE {..., signaturealgorithm AlgorithmIdentifier,... } Algorithmidentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Signatur einer Sperrliste Das Signaturfeld signature enthält eine digitale Signatur, die für das in ASN.1-DER kodierte Sperrlistenfeld tbscertlist berechnet wird. Bei der Berechnung der Signatur wird das Sperrlistenfeld tbscertlist als Eingabe in eine Einweg-Hash-Funktion benutzt. Auf den Ergebniswert der Hashfunktion wird der private Schlüssel der Zertifizierungsstelle angewandt und als ASN.1-Bitstring kodiert. Er liefert die konkrete digitale Signatur der Sperrliste im Signaturfeld signature. Durch den Signaturvorgang beglaubigt eine Zertifizierungsstelle die Gültigkeit der im Sperrlistenfeld tbscertlist enthaltenen Informationen sowie die Gültigkeit der im Sperrlistenfeld tbscertlist enthaltenen Informationen. Insbesondere wird auch die Ungültigkeit der betreffenden Zertifikate gewährleistet. 61

63 ASN.1-Definition Certificate ::= SEQUENCE {..., signature BIT STRING } Zu signierende Sperrlisteninformationen Das Sperrlistenfeld tbscertlist besteht aus einer Folge von optionalen und vorgeschriebenen Feldern, die Informationen enthalten, welche in unmittelbarem Zusammenhang mit dem Sperren von Zertifikaten stehen. Die Bestandteile signature, issuer und thisupdate dienen zur Kennung des benutzten Signaturalgorithmus, zur Identifikation des Erstellers der Sperrliste sowie zur Angabe des Erstellungsdatums. Die optionalen Teilfelder version, nextupdate, revokedcertificates und crlextensions enthalten die Version der aktuellen CRL, das Erstellungsdatum der nächsten Sperrliste, Listen von gesperrten Zertifikaten und mögliche CRL- Erweiterungen. Zertifikate werden innerhalb der Folge revokedcertificates durch ihre Seriennummer usercertificate, das Datum der Sperrung revocationdate und durch mögliche zertifikatsspezifische CRL-Erweiterungen crlentryextensions als gesperrte Zertifikate gekennzeichnet. ASN.1-Definitionen CertificateList ::= SEQUENCE { tbscertlist TBSCertList,... } TBSCertList ::= SEQUENCE { version Version OPTIONAL, signature AlgorithmIdentifier, issuer Name, thisupdate Time, nextupdate Time OPTIONAL, revokedcertificates SEQUENCE OF SEQUENCE { usercertificate CertificateSerialNumber, revocationdate Time, crlentryextensions Extensions OPTIONAL} OPTIONAL, crlextensions [0] EXPLICIT Extensions OPTIONAL } Version Die Inhaltsstruktur und die Konfigurationsmöglichkeiten dieses Feldes stimmen mit dem gleichnamigen Feld des Benutzerzertifikates überein. Signature Die Inhaltsstruktur und die Konfigurationsmöglichkeiten dieses Feldes entsprechen dem gleichnamigen Feld des Benutzerzertifikates. Das Feld enthält den Bezeichner des Algorithmus, der von der Zertifizierungsstelle zum Signieren der Sperrliste benutzt wird. Issuer Dieses Feld enthält die Bezeichnung (Distinguished Name) des Herausgebers der Liste und stimmt im Inhalt mit dem gleichnamigen Feld des Benutzerzertifikats überein. Es dient zur technischen Identifikation der Instanz bzw. Zertifizierungsstelle, welche die betreffende Sperrliste erstellt und signiert hat. ThisUpdate Das thisupdate-datums- und Zeitfeld gibt das Datum und den Zeitpunkt der Erstellung einer Sperrliste an und kann dabei entweder in UTCTime- oder im GeneralizedTime-Datums- und Zeitformat kodiert werden. 62

64 Zur Kodierung des Zeitpunktes der Erstellung einer Sperrliste ist bis zum Jahr 2049 als Zeittyp stets der Typ UTCTime und ab dem Jahr 2050 der Typ GeneralizedTime zu benutzen. Bei der Kodierung der Datums- und Zeitangaben sind für GeneralizedTime das Format YYYYMMDDHHMMSSZ und für UTCTTime das Format YYMMDDHHMMSSZ zu beachten. Die Bedeutung der einzelnen Felder der Datums- und Zeitformate ist in der folgenden Tabelle zusammengefasst. Datumsangaben Zeitangaben Feld Bedeutung Feld Bedeutung YYYY vollständige Jahreszahl, nur bei HH Sunde 00, 01,, 23 GeneralizedTime YY letzte zwei Ziffern der Jahreszahl, nur bei MM Minute 00, 01,, 59 UTCTime MM Monat 01, 02,, 12 SS Sekunde 00, 01, 000, 59 DD Tag 01, 02, 000, 31 Z GMT NextUpdate Dies ist ein optionales Feld, welches den Zeitpunkt der nächsten Herausgabe der Sperrliste enthält. NexUpdate sollte in jeder Liste eingefügt werden. Damit weiss die Sicherheitsapplikation oder der Benutzer, ab wann spätestens wieder eine neue Liste zu erwarten ist. Das Datum und die Zeit kann entweder im UTCTime- oder im GeneralizedTime-Datums- und Zeitformat kodiert werden. RevokedCertificates Darin ist die Liste der revozierten Zertifikate enthalten. Es werden nicht die gesamten Inhalte der für ungültig erklärten Zertifikate eingefügt, sondern nur deren Seriennummer usercertificate vom Typ CertificateSerialNumber. (Ein Grund, weshalb die Seriennummer eindeutig sein muss.) Pro revoziertes Zertifikat kann man eine dafür spezifische Erweiterung optional anfügen. Diese Erweiterung ist von der Erweiterung der gesamten Liste zu unterscheiden. Die pro revoziertes Zertifikat vorgesehene Erweiterung wird in der englischen Sprache auch als "CRL Entry Extensions" bezeichnet CRL Entry Extensions Das X.509v2 CRL Format erlaubt die Definition von privaten CRL Extensions. CRL Entry Extensions werden genau so kodiert wie Zertifikats- und CRL Erweiterungen. Ein Object Identifier (OID) identifiziert den Typ und die Kodierung der Erweiterung. Erweiterungen in Sperrlisteneinträgen können als critical oder als non-critical gekennzeichnet werden. Der CRL- Verifikationsprozess soll zu einem fail-ergebnis führen, falls eine als critical markierte CRL- Erweiterung nicht verarbeitet werden kann. Unbekannte und als non-critical spezifizierte Erweiterungen dürfen bei der Validierung ignoriert werden. Des Weiteren besteht die Möglichkeit private Sperrlisten-Erweiterungen zu kodieren. Alle im Folgenden beschriebenen Per Entry Extensions sollen als non-critical markiert werden Überblick aller Per Entry Extensions: Reason Code Certificate Issuer Hold Instruction Code Invalidity Date Reason Code Das reasoncode-feld ist eine non-critical CRL Entry Extension, die den Grund für die Sperrung eines Zertifikates anzeigt. Sperrgründe werden syntaktisch durch einen ASN.1-Aufzähltyp beschrieben, der aus einer Menge von benamten Integerwerten besteht. Sperrgründe können 63

65 von Anwendungen dazu benutzt werden, um zu entscheiden, wie sie auf die Anzeige eines gesperrten Zertifikates in Abhängigkeit von ihren lokalen Sicherheitsrichtlinien reagieren sollen. ASN.1-Definitionen Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnvalue OCTET STRING } id-ce OBJECT IDENTIFIER ::= { } id-ce-crlreason OBJECT IDENTIFIER ::= { } crlreason EXTENSION ::= { SYNTAX CRLReason IDENTIFIED BY id-ce-crlreason } CRLReason ::= ENUMERATED { unspecified (0), keycompromise (1), cacompromise (2), affiliationchanged (3), superseded (4), cessationofoperation (5), certificatehold (6), removefromcrl (7) } Die Verwendung der Reasoncode-Erweiterungen im crlentryextensions-feld durch Zertifizierungsstellen wird sehr empfohlen. Folgend die Bedeutung der einzelnen Sperrgründe: unspecified Nicht-spezifizierter Sperrgrund. key Compromise Der im Zertifikat enthaltene Schlüssel ist kompromittiert worden. CA Compromise Der Schlüssel der CA, welche das betreffende Zertifikat ausgestellt hat, ist kompromittiert worden. affiliation changed Der Inhalt des Zertifikats musste verändert werden, weil er im Laufe der Zeit nicht mehr ganz zutraf. Sei es, dass der Besitzer des Zertifikats den Namen geändert oder die Organisation gewechselt hat. Es liegt aber kein Grund oder kein Anhaltspunkt vor, anzunehmen, der Schlüssel sei kompromittiert worden. superseded Das Zertifikat ist abgelaufen, weil zum Beispiel der Besitzer des Zertifikats das Unternehmen verlassen hat. Doch es liegt keine Kompromittierung des privaten Schlüssels vor. cessationofoperation Das Zertifikat wird vor Ablauf seiner Gültigkeit nicht mehr benötigt, ohne dass eine Kompromittierung des privaten Schlüssels vorliegt. certificatehold Dieses Feld wird für die temporäre Aufhebung (Suspendierung) eines Zertifikats benutzt. Man sollte den Status "hold" bei Zertifikaten nur sehr sparsam einsetzen, weil es zum Teil zu unerwarteten Resultaten führen kann. Zum Beispiel, wenn ein Zertifikat für drei Stunden den 64

66 Status "hold" hat und der "Hold-Status" dann wieder entfernt wird, so kann der Gebrauch des Zertifikates während dieser Periode unerwartete Folgen haben. removefromcrl Wenn ein gesperrtes Zertifikat den Status "CertificateHold" hat, dann kann das Zertifikat wieder zurückgerufen werden bzw. wieder gültig gemacht werden. Bei Delta CRLs erfordert dies einen neuen Eintrag beim Base CRL Parameter RemovedFromCRL um zu sagen, dass der Eintrag in der Base CRL existiert aber anschliessend wieder gültig gemacht wurde. HoldInstructionCode Das holdinstructioncode-feld ist eine non-critical CRL Entry Extension, die einen registrierten Instruktionsbezeichner enthält, der die auszuführende Aktionen festlegt, die für temporär gesperrte Zertifikate (CertificateHold) gelten. Die Anweisungen sagen dem Anwender, was er im entsprechenden Fall zu unternehmen hat. Diese CRL Pre Entry Extension enthält nur einen Object Identifier, der die notwendige Aktion festlegt. In RFC 3280 sind drei OIDs standardisiert: ASN.1-Definition HoldInstructionCode ::= CHOICE { id-holdinstruction-none OBJECT IDENTIFIER, id-holdinstruction-callissuer OBJECT IDENTIFIER, id-holdinstruction-reject OBJECT IDENTIFIER } id-holdinstruction OBJECT IDENTIFIER ::= { } id-holdinstruction-none OBJECT IDENTIFIER ::= { } id-holdinstruction-callissuer OBJECT IDENTIFIER ::= { } id-holdinstruction-reject OBJECT IDENTIFIER ::= { } Bevor jedoch diese Per Entry Extension mit id-holdinstruction-none kodiert wird, sollte sie ganz weggelassen werden. Trifft man auf ein temporär gesperrtes Zertifikat, das die Anweisung idholdinstruction-callissuer enthält, so ist der Zertifikatsaussteller für weitere Anweisungen zu kontaktieren. Ein mit id-holdinstruction-reject markiertes Zertifikat darf nicht akzeptiert werden. Certificate Issuer Dieses Feld enthält die Bezeichnung, wer das revozierte Zertifikat herausgegeben hat. Die Bezeichnung erfolgt über den generellen Namen und sollte identisch mit dem Inhalt des gleichnamigen Felds IssuerAlternativName im Benutzerzertifikat sein. Dieses Feld wird dann verwendet, wenn die CRL gesperrte Zertifikate verschiedener Hersteller enthält. CRLs, die Zertifikate enthalten, die nicht vom CRL-Aussteller signiert wurden, werden als indirekte CRLs bezeichnet. ASN.1-Definitionen Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnvalue OCTET STRING } certificateissuer EXTENSION ::= { SYNTAX CertificateIssuer IDENTIFIED BY id-ce-certificateissuer } 65

67 id-ce-certificateissuer OBJECT IDENTIFIER ::= { } CertificateIssuer ::= GeneralNames Invalidity Date Oft wird ein Zertifikat früher kompromittiert oder ungültig, bevor die Sperrung erfolgt. Auch wird eine Kompromittierung erst nach dem Eintreten eines Missbrauchs erkannt. Mit dem noncritical InvalidityDate kann dem Zertifikatsinhaber der angenommene Zeitpunkt der Kompromittierung mitgeteilt werden. Ob diese Erweiterung in der Praxis eine grosse Anwendung findet, lässt sich hingegen in Frage gestellt. ASN.1-Definitionen Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnvalue OCTET STRING } id-ce OBJECT IDENTIFIER ::= { } id-ce-invaliditydate OBJECT IDENTIFIER ::= { } invaliditydate EXTENSION ::= { SYNTAX GeneralizedTime IDENTIFIED BY id-ce-invaliditydate } CRL Erweiterungen Die Erweiterungen pro gesamte Sperrliste werden in der englischen Fachliteratur als "Per CRL Extensions" bezeichnet. Sie beinhalten: Authority Key Identifier Issuer Alternative Name CRL Number Issuing Distribution Point Delta CRL Indicator Authority Key Identifier Das authoritykeyidentifier-erweiterungsfeld dient zur Identifikation eines bestimmten öffentlichen Schlüssels einer Zertifizierungsstelle, der zum Signieren einer Sperrliste verwendet wurde. Die Erweiterung wird dann verwendet, wenn eine Zertifizierungsstelle mehrere Signaturschlüssel - sei es als gleichzeitig aktive Schlüssel oder zum Schlüsselwechsel - besitzt. Die Identifizierung kann entweder durch den Schlüsselnamen im keyidentifier-teilfeld oder durch den Namen der Zertifizierungsstelle im authoritycertissuer-teilfeld und die Seriennummer im authoritycertserialnumber-teilfeld erfolgen. Diese Erweiterung muss als non-critical bezeichnet werden. ASN.1-Definitionen AuthorityKeyIdentifier ::= SEQUENCE { keyidentifier [0] KeyIdentifier OPTIONAL, authoritycertissuer [1] GeneralNames OPTIONAL, authoritycertserialnumber [2] CertificateSerialNumber OPTIONAL } KeyIdentifier ::= OCTET STRING Issuer Alternative Name Das issueraltname-erweiterungsfeld enthält einen oder mehrere alternative Namen für den Hersteller einer Sperrliste, durch die zusätzliche Identitäten an den Sperrlistenhersteller gebunden werden. Es können folgende Adressen angegeben werden: Eine Adresse für die 66

68 elektronische Post (rfc822), ein DNS Name, eine IP-Adresse oder eine URI. Es können mehrere Namen in unterschiedlichen Formaten angegeben werden. Das issueraltname-erweiterungsfeld sollte als non-critical bezeichnet sein. CRL Number Dies ist eine eindeutige Nummer, die bei jeder neu ausgestellten CRL erhöht wird. Es darf keine unterschiedliche, von derselben CA ausgestellte CRL mit identischer Nummer geben. ASN.1-Definitionen Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnvalue OCTET STRING } crlnumber EXTENSION ::= { SYNTAX CRLNumber IDENTIFIED BY id-ce-crlnumber } id-ce-crlnumber OBJECT IDENTIFIER ::= { } CRLNumber ::= INTEGER (0..MAX) Diese Erweiterung darf nicht als critical markiert werden und muss in allen CRLs enthalten sein. Issuing Distribution Point Das issuingdistributionpoint-feld ist eine critical CRL-Erweiterung, die den Verteilungspunkt (CRL Distribution point) einer bestimmten Sperrliste identifiziert und anzeigt, ob die Sperrliste nur Endanwender-Zertifikate, nur CA-Zertifikate oder nur Zertifikate für eine begrenzte Menge von Sperrgründen enthält. In den CRL sind die gesperrten Zertifikate nicht explizit enthalten, sondern nur deren Seriennummer. Zertifizierungsstellen können das issuingdistributionpoint-feld zur Partitionierung von Sperrlisten einsetzen. ASN.1-Definitionen issuingdistributionpoint ::= SEQUENCE { distributionpoint [0] DistributionPointName OPTIONAL, onlycontainsbenutzercerts [1] BOOLEAN DEFAULT FALSE, onlycontainscacerts [2] BOOLEAN DEFAULT FALSE, onlysomereasons [3] ReasonFlags OPTIONAL indirectcrl [4] BOOLEAN DEFAULT FALSE } distributionpoint Im Feld distributionpoint wird der Verteilungspunkt angegeben. Dies ist entweder ein Verzeichnisbaum oder ein URI. onlycontainusercerts Diese Option in den IDPs erlaubt nur Zertifikate, die den Wert "ca" in den Basic Constraints Extension nicht haben. Wenn das Zertifikat eine Basic Constraints Extension nicht enthält, dann wird angenommen, dass es keine CA ist. onlycontainscacerts Diese Option in den IDPs erlaubt nur Zertifikate, die eine Basic Constraints Extension mit "ca" haben, die in CRL einbezogen werden. 67

69 onlysomereason Ist dieses Feld kodiert, so enthält die CRL nur die gesperrten Zertifikate, die aus den angegebenen Gründen revoziert wurden. indirectcrl Wenn ein Aussteller der CRL ein anderer ist, als der, der die Zertifikate signiert, dann ist das Feld indirectcrl auf TRUE zu setzen. Die IssuingDistributionPoint-Erweiterung muss nicht implementiert werden. Wird sie jedoch kodiert, so muss sie den Status critical haben. Achtung: In Windows XP werden die onlysomereasons und die indirectcrl Felder nicht unterstützt. Das heisst, CRL Partitionierung mit Annullierungsgründen kann nicht gemacht werden. Windows Server 2003 unterstützt CRL Partitioning mit Annullierungsgründen oder Zertifikatstypen ebenfalls nicht. Falls aber doch solch eine IDP Extension existiert, dann vergleicht die Microsoft Certificate chaining engine die Namen in den CDP und IDP Extensions. Stimmen die beiden Namen überein, wird die CRL das zu prüfende Zertifikat als gültig erklären. Delta CRL Indicator Falls diese Erweiterung vorhanden ist, gibt sie an, dass es sich um eine Delta CRL handelt. 68

70 4 Online Certificate Status Protocol (OCSP) In diesem Kapitel wird das Protokoll Online Certificate Status Protocol (OCSP) beschrieben. Es ist ein Protokoll, welches die Statusabfrage eines Zertifikates ermöglicht. Das OCSP-Protokoll wurde durch die PKIX Arbeitsgruppe IETF als Standard (RFC 2560) definiert. Es stellt ein einfaches Request-Response-Protokoll dar, welches auf einem beliebiges Transportprotokoll aufsetzt. Es wird ein OCSP-Server (Responder) zwischen den Client und den Statusinformationen, welche auf der CA gelagert werden, geschaltet. Dieser OCSP-Responder nimmt die Anfrage des Client entgegen und beschafft sich dann die Sperrinformation des spezifischen Zertifikats. Dem Client werden die Antworten "good", "revoked" oder "unknown" übermittelt. "Good" bedeutet, dass das Zertifikat nicht als revoziert gekennzeichnet ist und nicht vorgängig zurückgerufen wurde. OCSP ist nur für die Sperrinformationsabfrage verantwortlich. Alle anderen Zertifikats- Überprüfungen musst der Client direkt bei der CA abfragen. Im Unterschied zum CRL Mechanismus, kann die Statusüberprüfung in Echtzeit vorgenommen werden. Das OCSP- Protokoll wird in der UBS bereits für die ersten Applikationen eingesetzt. [25], [26], [27], [28] 4.1 Einleitung Das Online Certificate Status Protocol ist ein Verfahren, um die Statusabfrage, im Gegensatz zu CRLs, zeitnah vorzunehmen. Das OCSP-Protokoll wurde im April 1999 von der PKIX Arbeitsgruppe der IETF als RFC 2560 spezifiziert und standardisiert. Es soll ein einfaches Request- Response-Protokoll sein, das den Revokationssatus eines Zertifikats abfragen und übermitteln kann. Das Protokoll ist transportunabhängig definiert, das heisst, OCSP kann auf ein beliebiges Internetprotokoll aufgesetzt werden. Der Client (Verifier, Zertifikatsprüfer) schickt bei der Validierung eines Zertifikats eine Anfrage an den OCSP-Server. Dieser Server muss zur Auskunft über den aktuellen Zertifikatsstatus autorisiert sein und bei der CA den Status abfragen. Die Authentizität der Antwort wird durch eine digitale Signatur des OCSP-Responder sichergestellt. Abbildung 22: Funktion von OCSP Das zeitnahe Sperren mit CRLs würde bedeuten, dass in sehr kurzen Abständen eine neue CRL erstellt und verteilt werden müsste. Dies ist nicht praktikabel und belastet die Infrastruktur enorm. Der OCSP-Client richtet eine spezifische Anfrage an den OCSP-Responder, um zu prüfen, ob das zu entsprechende Zertifikat nicht revoziert wurde. Der Client muss dazu keine Sperrliste herunter laden. Der OCSP Server beantwortet die Anfrage mit dem Status "good", "revoked" oder "unknown". Eine Statusauskunft (z.b. Zertifikat vorhanden und nicht gesperrt oder vorhanden und seit :42:00 Uhr gesperrt ) ist eine elektronisch signierte Nachricht. Ein OCSP-Responder oder auch OCSP-Server genannt, kann seine Informationen über verschiedene Kanäle, wie OCSP, LDAP oder CRL beziehen. 69

71 Abbildung 23: Informationsbeschaffung Das Konzept des OCSP-Verfahrens widerspiegelt eher den Ansprüchen der UBS an eine Statusüberprüfung. Für Applikationen, die eine zeitnahe Überprüfung der Zertifikate insbesondere der Sperrinformationen benötigen, um dem Benutzer zu vertrauen, ist OCSP sehr gut geeignet. In der UBS wurde bereits ein OCSP-Server implementiert und für die ersten Applikationen eingesetzt. Für den Zertifikatsbasierten Login in die Windows-Domäne wird hingegen OCSP nicht eingesetzt, da der OCSP-Dienst nicht im Windows-Betriebssystem implementiert ist. Das heisst, dass für den Swiss-DD Domänen-Login weiterhin eine Statusüberprüfung mittels CRL durchgeführt wird. Die Wahl der Zugriffmethode kann einen entscheidenden Einfluss auf die Dienstgüte des OCSP- Responders haben. Ausserdem muss darauf geachtet werden, dass die Authentizität des Datenaustausches sichergestellt ist. Von einer reinen Online-Statusabfragungsart wird dann gesprochen, wenn der OCSP-Responder zu jedem beliebigen Zeitpunkt die aktuellen Sperrinformationen zur Verfügung stellen kann. Dies ist der Fall, wenn der OCSP-Server (Responder) direkt auf die CA-Datenbank Zugriff hat. Die andere Möglichkeit ist, dass der OCSP-Responder direkt in die CA integriert ist. Die Integration des OCSP-Responders in die CA macht aber nur dann Sinn, wenn die CA und OCSP-Responder vom gleichen Hersteller hergestellt und verkauft werden. Diese beiden Varianten haben den Vorteil, dass die Daten jederzeit aktuell sind. Nachteilig ist, dass ein OCSP-Server, im Gegensatz zur CA, hochverfügbar sein muss. Greift der OCSP-Responder aber direkt auf die CA, so muss auch diese hochverfügbar sein. Neben anderen sicherheitsrelevanten Massnahmen wäre die Hochverfügbarkeit ein grosser Kostenpunkt. Deshalb basieren die meisten OCSP-Lösungen auf CRL's. Somit sind die Daten zwar nicht zu jedem beliebigen Zeitpunkt hochaktuell, die Lösung ist aber um einiges günstiger. Ein weiterer Punkt ist, dass mit dieser Lösung die CA und der OCSP-Responder nicht gleich hoch verfügbar sein müssen. Die CRLs werden dann in kurzen Intervallen ausgestellt und nur an den OCSP- Server verteilt. Dies belastet die Netzinfrastruktur nicht gross. 4.2 Zugriffsart: Online Abfrage mit externem OCSP-Server Diese Art der OCSP-Infrastruktur entspricht dem eigentlichen Sinn von OCSP. Die Sperrinformationen sind zu einem beliebigen Zeitpunkt aktuell. Die Daten eines Zertifikats, die auf der Datenbank in der CA gelagert sind, werden durch den OCSP-Responder abgefragt und die Statusantwort an den Client übermittelt. Der OCSP-Responder kann ein Produkt eines Drittherstellers sein und muss lediglich eine Schnittstelle zum CA-Produkt aufweisen. Falls die CA bereits ein öffentliches Directory benutzt, bietet sich der Einsatz eines speziellen Directory- Protokolls (z.b. LDAP) an. Es gibt jedoch Protokolle, die keine besondere Sicherheitsvorkehrungen treffen, wie zum Beispiel LDAP. Die Authentizität muss daher mit besonderen Massnahmen gesichert werden. Zum Beispiel den Betrieb von OCSP-Responder und CA in einer 70

72 gemeinsamen und sicheren Umgebung. Zusätzlich könnte die Übertragung durch Sicherheitsprotokolle, wie SSL/TLS oder IPSec geschützt werden. Abbildung 24: Online Abfrage mit externem OCSP-Server 4.3 Zugriffsart: Online Abfrage mit integriertem Responder Diese OCSP-Infrastruktur kommt da vor, wo ein Hersteller eine CA und ein OCSP-Server anbietet. Der Nachteil an dieser Architektur ist, dass die CA und der OCSP-Server unterschiedlichen Verfügbarkeitsanforderungen unterliegen. Während die CA eigentlich nur für die Zertifikatsgenerierung und allenfalls für die Erstellung einer CRL verfügbar sein muss, soll ein OCSP Server hochverfügbar sein. Damit die Daten aber jederzeit abrufbar sind, muss natürlich die CA-Datenbank trotzdem hochverfügbar sein und damit auch die CA im Allgemeinen. Ist eine CA aber ständig online, so ist sie weniger sicher und anfälliger auf Attacken. Somit entsteht ein Anforderungskonflikt zwischen der Verfügbarkeit der CA und dem OCSP-Responder. Abbildung 25: Online Abfrage mit integriertem Responder Zugriffsart: Zugriff via CRL Die Sperrinformationen werden von der CA mittel CRLs an den OCSP-Responder verteilt. Dabei basiert die Aktualität der Daten auf der zuletzt ausgestellten CRL. Zusätzlich soll der OCSP- Responder ständig überprüfen, ob die CA vorzeitig eine neue CRL herausgegeben hat. Die hohe Aktualität der Statusinformation geht dabei aber verloren. Der Einsatz eines CRL-basierten OCSP-Responders kann dennoch Sinn machen, da die einzelnen Clients von der Administration der CRL entlastet werden. Die CRL wird nur an den oder die OCSP-Server geschickt und nicht mehr an alle Clients verteilt. Dadurch kann häufiger eine CRL ausgestellt werden. Dieser Ansatz entspricht zwar nicht ganz dem OCSP-Konzept, berücksichtigt jedoch die unterschiedlichen 71

73 Verfügbarkeitsstufen der CA und dem OCSP-Responder. Die Sicherheitsanforderungen einzuhalten ist auch eher einfacher und somit billiger realisierbar. Der Einsatz von CRL-basierten Abfragungen, wird im Standard durch eine spezielle singleextension (id-pkix-ocsp-crl) berücksichtigt. Abbildung 26: Zugriff via CRL 4.4 Die OCSP Modelle Klassisches Modell Die Verantwortung für die Statusüberprüfung eines Zertifikats liegt alleine auf der Seite des Zertifikatsvalidierers. Das heisst, im klassischen Modell erkundigt sich der Nachrichten- Empfänger (Bob) beim OCSP-Responder, ob das erhaltene Zertifikat nicht vorzeitig gesperrt wurde. Bob stellt einen Request an den OCSP-Responder, welcher dann wiederum die CA anfragt, die das Zertifikat von Alice ausstellte, ob das Zertifikat gesperrt wurde. Der Responder teilt in einer signierten Nachricht Bob mit, über welchen Zertifikatsstatus das nachgefragte Zertifikat verfügt. Abbildung 27: klassisches Modell Rivest-Idee-Modell Im Rivest Modell verpflichtet sich der Sender sämtliche Informationen inklusiver Statusinformationen zu beschaffen und dem Empfänger vorzulegen. Hat der Empfänger, in diesem Fall Bob, keinen Zugriff auf einen Responder, der die besagte CA kennt, dann kann der Status nicht abgefragt werden. Mit der Rivest Idee könnte man ausserhalb firmeninternen 72

74 Strukturen die Statusabfragung durchführen. Alice schickt nicht nur die signierte Nachricht und ihr Zertifikat mit, sondern schickt auch die signierte Statusabfragung des Responders mit. Somit kann Bob nun offline den Status des Zertifikats von Alice vollumfänglich überprüfen. Eine Weiterentwicklung dieses Modells ist das Notariatsmodell von Rivest. Darin ist ein vermittelnder Notariatsdienst zwischen Absender und CA definiert. Der Notariatsdienst stellt ein neues Zertifikat mit aktuellem Zeitstempel aus und der Sender schickt dieses anstelle seines Zertifikats an den Empfänger. Die OCSP-Anfrage muss nur einmal bei der Signaturerzeugung ausgeführt werden. Die Signatur kann beliebig oft verifiziert werden, ohne dass zusätzlich Abfragen anfallen. Abbildung 28: Rivest-Idee Modell 4.5 Kodierung des OCSP Protokoll Zur Definition der Datenstrukturen des Protokolls OCSP wird die Abstract Syntax-Notation 1 (ASN.1) eingesetzt. ASN.1 definiert lediglich die abstrakte Darstellung von Daten und dient der plattformunabhängigen Definition von Datenstrukturen. Um diese abstrakte Darstellung von Daten tatsächlich verschicken zu können, müssen sie kodiert werden. Im Zusammenhang mit Zertifikaten wird die Kodierungsregel Distingueshed-Endcoding-Rules (DER) verwendet. Mehr Informationen zu ASN.1 und DER finden Sie im Kapitel 1.8. [49], [50] Request Folgende Informationen basieren auf der ASN.1 Spezifikation. Die eigentliche Formatierung hängt vom Transportmechanismus ab. (z.b. HTTP, SMTP, LDAP ) Ein Beispiel mit HTTP finden Sie im Kapitel Die Anfrage des OCSP-Clients soll das zu prüfende Zertifikat eindeutig identifizieren. Ein Zertifikat kann eindeutig durch die Angabe des Zertifikatsausstellers und der Seriennummer des Zertifikats gekennzeichnet werden. Die Anfrage besteht aus den Angaben der Anfrage selbst und einem Anfrageblock mit einer Folge von Zertifikaten bzw. dessen Zertifikatsbezeichnern. Jedem einzelnen Zertifikat respektive Zertifikatsanfrage können Erweiterungen angefügt werden. Zur Authentisierung des Clients kann die Anfrage signiert werden. Eine Anfrage an den OCSP-Server enthält folgende Daten: Protokollversion Art des Services für den Request ein oder mehrere Zertifikatsbezeichner 73

75 zusätzliche Erweiterungen je Zertifikat und Erweiterungen je Anfrage optional den technischen Namen des Anfragenden eine optionale Signatur der Anfrage Eine Anfrage bezieht sich auf ein oder mehrere Zertifikate, denn das Protokoll OCSP unterstützt die Anfrage mehrerer Zertifikate. Üblicherweise wird der Client in einer Anfrage nur nach einem einzigen Zertifikat fragen, da für jedes Zertifikat eine Zertifikatskette gebildet wird. Ein Responder antwortet wenn die Anfrage "well formed" ist und der Responder für diesen Service konfiguriert ist Die detaillierte Struktur des OCSP-Requests wird im Kapitel ausführlich beschrieben Reponse Allgemeiner Inhalt Alle definitiven Antworten (responses) müssen vom OCSP-Server digital unterzeichnet werden. Im Wesentlichen besteht eine Response aus: Version der Response Syntax Name des Responders Antworten auf jedes Zertifikat in einem Request optionale Extensions Algorithmusverfahren der Signatur (OID) Signatur über den Hash der Respons Die Response für jedes einzelne Zertifikat besteht aus: eindeutige Kennzeichnung des Zertifikats Status des Zertifikats (good, revoked, unknown) Gültigkeitsintervall der Response optionale Extensions Auch die Response basiert auf ASN.1. Die eigentliche Formatierung hängt auch von dem Transportmechanismus ab. (z.b. HTTP, SMTP, LDAP). Es wird der gleiche Transportmechanismus gewählt wie im Request. Die detaillierte Struktur des OCSP-Response wird im Kapitel ausführlich beschrieben. 74

76 4.6 Zertifikatsstatus Die OCSP-Response gibt den Status eine Zertifikats mit lediglich drei Werten "good", "revoked", "unknown" zurück. Insbesondere wird die durch notbefore und notafter angegebene Gültigkeitsdauer eines Zertifikats von OCSP nicht überprüft. OCSP geht davon aus, dass dem Zertifikatsprüfer (Client) alle Informationen ausser dem Zertifikatsstatus bereits vorliegen. Aus dem Ergebnis der Pfadvalidierung ergibt sich, ob ein Zertifikat jemals von einer akkreditierten CA ausgestellt wurde good: Der Zustand good sagt aus, dass zum Zeitpunkt thisupdate das Zertifikat nicht gesperrt war. Good sagt aber nichts über die Gültigkeitsdauer und Existenz des Zertifikates aus. Es könnte bedeuten, dass das Zertifikat regulär abgelaufen ist und deshalb nicht auf einer CRL oder CA Datenbank aufgeführt ist. In diesen Fall kommt auf die Anfrage ein good zurück, auch wenn das Zertifikat nicht mehr gültig ist. Der Client überprüft jedoch dieses Ablaufdatum im Zusammenhang mit der Zertifikatsvalidierung. Über OCSP oder CRL wird lediglich den Status des Zertifikates abgefragt revoked Der Zustand revoked sagt aus, dass das Zertifikat von der zugehörigen Zertifizierungsstelle ausgestellt wurde, dem OCSP-Server bekannt ist und temporär oder endgültig gesperrt ist. Falls ein revoked-zustand vorliegt, wird der Sperrzeitpunkt im Teilfeld revocationtime und optional der Sperrgrund im Teilfeld revocationreason der Struktur RevokedInfo abgelegt unknown Diese Antwort bedeutet, dass der OCSP-Responder das nachgefragte Zertifikat nicht kennt. Entweder ist er von der entsprechenden CA nicht für die Beantwortung von Statusabfragen autorisiert, oder es können keine Revokationsinformationen zu dem Zertifikat gefunden werden. Es könnte auch sein, dass der CRL-basierte OCSP-Responder keine gültige CRL vorfand. Falls ein unknown Zustand vorliegt, so muss im Feld certid der Struktur SingleResponse der Inhalt des certid-feld in der Struktur Request der Anfrage wiederholt werden. 4.7 Exception Case Tritt kein Fehler auf so beinhaltet das Feld Status den Wert successful. Im Falle eines Fehlers, erscheinen Werte, wie malformedrequest, internalerror, trylater, sigrequired oder un-authorized. In der folgenden Tabelle sind alle Ergebnisse aufgelistet. Ergebnis Anfrage successful malformed Request internalerror trylater sigrequired unauthorized Bedeutung Erfolgreiche Bearbeitung einer Anfrage. Wegen fehlerhaftem Anfrageformat, konnte keine erfolgreiche Bearbeitung der Anfrage erfolgen. Auftretung eines internen Fehlers beim OCSP-Server. Nicht-Verfügbarkeit des OCSP-Servers (temporär) Der OCSP-Server fordert explizit, dass die Anfrage vom Client signiert werden muss. Der Client ist nicht berechtigt. 75

77 4.8 Zeiten in einer OCSP-Response Die Antwort eines OCSP-Servers kann folgende Zeiten beinhalten: thisupdate nextupdate producedat revocationtime thisupdate Die Komponente thisupdate enthält den Zeitpunkt, für den die gemachte Aussage gültig ist. Es zeigt so zu sagen den aktuellen Zeitpunkt zu der die Sperrinformationen erstellt wurden an. Beim Online Verzeichnisdienst stimmt dieser Zeitpunkt mit dem Zeitpunkt producedat überein. OCSP-Antworten, deren thisupdate Zeitpunkt nach der lokalen Systemzeit liegt, sollten als ungültig erachtet werden. Es liegt im Ermessen des Client, wie weit dieser Zeitpunkt zurückliegen darf nextupdate Die Komponente nextupdate enthält einen Hinweis, wann die Information, auf der die Antwort basiert, erneuert wird. Dies schliesst nicht aus, dass schon früher aktuellere Auskünfte erteilt werden können. Spätestens nachdem der Zeitpunkt nextupdate verstrichen ist, sollte eine neue Anfrage gestellt werden. Dieser Zeitpunkt ist nur für OCSP Antworten sinnvoll, die auf CRLs basieren. Beim reinen Online-Dienst stimmt dieser Zeitpunkt immer mit dem Zeitpunkt thisupdate überein. Der Zeitpunkt nextupdate kann in der Zukunft liegen, sofern die Antwort auf einer Sperrliste mit einem festgelegtem Gültigkeitszeitraum basiert. OCSP-Antworten, die keinen nextupdate Zeitpunkt enthalten, zeigen an, dass jederzeit neuere Statusinformation zu Zertifikaten vorhanden sein können producedat Der Zeitpunkt der Erzeugung und Signierung einer OCSP-Response wird in producedat gesondert vermerkt. Als Kontrolle kann überprüft werden, ob producedat vor der lokalen Systemzeit liegt. Der Zeitpunkt darf nicht in der Zukunft liegen. Die Zeitpunkte thisupdate und revocationtime stimmen mit producedat überein, wenn der OCSP-Dienst auf einem reinen Online-Dienst basiert. Auch ein OCSP-Responder hat nicht zwingend immer Zugriff auf die neuesten Zertifikatsstatusdaten einer CA. Das kann daran liegen, dass die CA diese Daten nur zu fixen Zeiten in eine gemeinsame Datenbasis schreibt. Es ist auch möglich einen OCSP-Responder als Frontend in einem ansonsten CRL-basierten Revokationsmodell zu verwenden. Falls der OCSP-Server in der Lage ist, ständig die aktuellsten Revokationsinformationen zu liefern, gilt thisupdate = producedat und nextupdate entfällt. Diese Zeiten sind besonders wichtig, wenn der OCSP-Server seine Sperrinformation von einer CRL bezieht. Das heisst, die Interpretationen der Werte von thisupdate und nextupdate stimmen mit der CRL-Semantik überein. Ist der Wert von nextupdate kleiner oder der Wert des thisupdates oder producedat grösser als die Zeit des lokalen Systems, dann sind sie unzuverlässig. Greift der OCSP-Server direkt auf die CA-Datenbank oder wurde die CA- Datenbank auf den OCSP-Server ausgelagert, so fallen die Zeiten thisupdate und producedat zusammen. Auch nextupdate wird in diesem Falle überflüssig, da in jedem Moment die aktuellen Informationen zur Verfügung stehen revocationtime Die Komponente revocationtime gibt bei einem gesperrten Zertifikat den Zeitpunkt an, zu dem die Sperrung aktiv wurde, das heisst, das der Sperreintrag gemacht wurde und über den OCSP- Server für die Nutzer des Gesamtsystems verfügbar war. 76

78 4.8.5 certindirsince Der Zeitpunkt certindirsince wurde eingeführt, um folgenden Sonderfall abzufangen: Ein Zertifikat wird in den Verzeichnisdienst eingestellt, wobei der Zeitpunkt der Einstellung in den Verzeichnisdienst nach dem Beginn des Gültigkeitszeitraumes des Zertifikates liegt. Anfragen zu einem Zertifikat vor der Einstellung in den Verzeichnisdienst würden mit ungültig beantwortet werden (Antwort Zertifikat nicht vorhanden ). Anfragen zu diesem Zertifikat nach der Einstellung würden mit Zertifikat vorhanden seit und nicht gesperrt beantwortet werden. Um diese widersprüchlichen Antworten klären zu können, wurde die SigI-spezifische Erweiterung certindirsince eingeführt, die den Zeitpunkt enthält, seit dem das Zertifikat im Verzeichnis vorhanden ist. 4.9 Transportart über HTTP Das OCSP-Protokoll ist unabhängig vom Transportmechanismus. Die ASN.1-DER-kodierten OCSP-Nachrichten können als Bytestrom in ein beliebiges Netzprotokoll eingebettet und verschickt werden. Ein Beispiel dafür wäre das bekannte HTTP-Protokoll. Die Kommunikation zwischen Client und OCSP-Server erfolgt dann mittels Hypertext Transport Protokoll (HTTP). Auch wenn diese Möglichkeit der Übermittlung nicht ganz optimal ist, überwiegen die Vorteile. Man könnte OCSP beispielsweise auch auf das effizientere, aber auf einer niedrigeren Protokollschicht liegende User Datagram Protocol (UDP) aufzusetzen. UDP bietet als unzuverlässiges Transport-Protokoll jedoch lediglich Grundfunktionen zum Austausch von binären Daten über ein Netzwerk. Sämtliche darüber hinaus benötigten Fähigkeiten hätten für OCSP entwickelt werden müssen. Für die Verwendung von HTTP (RFC 2068) stehen erprobte Protokollbibliotheken und eine ausgereifte Infrastruktur zur Verfügung. In vielen Umgebungen ist HTTP das einzige Protokoll, das zur Verfügung steht, da andere Protokolle von der Firewall oder dem Proxy des Internet-Providers unter Umständen nicht weitergeleitet werden. Der Zugriff auf externe Ressourcen im Internet über HTTP ist meistens gestattet. Dafür müssen sichere Übergangsmöglichkeiten für HTTP eingebaut werden. Diese werden mit den so genannten Firewalls in der Form von HTTP Proxies realisiert und sind bereits mehrfach erprobt. Um die OCSP-Nachrichten zu schützen, kann auf einer niedrigeren Protokollebene ein Sicherheitsprotokoll wie SSL/TLS oder IPSec verwendet werden. Die Signatur der OCSP-Response wird dadurch allerdings nicht ersetzt. Bei Einsatz eines sicheren Transportprotokolls ist die Authentizität nur gewährleistet, solange die Netzwerkverbindung besteht. Nachdem die Verbindung abgebaut wurde, ist es nicht mehr möglich, den Ursprung der Daten nachzuweisen. Da die Signatur und die Identität des OCSP-Responders ein fester Bestandteil der OCSP- Response ist, kann die Auskunft mit ihrer Hilfe jederzeit verifiziert werden. Für die Sicherheit (Vertraulichkeit) kann die Meldung mittels Transport Layer Security (TLS) oder Secure Socket Layer (SSL) verschlüsselt übertragen werden Request mit Transportart HTTP HTTP basierende OCSP-Requests können per GET- oder POST-Methode übermittelt werden. Um HTTP-Caching und für kleinere Request zu ermöglichen, soll die Methode GET verwendet werden. Es soll jedoch die POST-Methode favorisiert werden, da die Möglichkeit den HTTP- Cache zwischen zu speichern ein Sicherheitsrisiko darstellt. Für Anfragen, die grösser als 255 Bytes sind, sollte die POST-Methode benutzt werden. Der base-64 DER kodierte Anfrage liegt die ASN.1 Struktur des OCSP-Requests zugrunde. Der OCSP-Server muss Anfragen beider Methoden verstehen und verarbeiten können GET Methode: GET HTTP/1.1 Erklärung: GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest} 77

79 POST Methode POST HTTP/1.1 Content-Type: application/ocsp-request Content-Length: 90 OXLJ..UZLNDUB lsiuoie9zsldhsldh. Erklärung: POST {url} Content-Type: beinhaltet Wert "application/ocsp-request" Content-Length: {Länge der Anfrage} Body OCSP Response over HTTP Analog zu dem Request, kann die Transportart HTTP gewählt werden. Der base-64 DER kodierte Antwort liegt die ASN.1 Struktur des OCSP-Response zugrunde. Der Transport kann entweder binär oder base-64 kodiert erfolgen, wobei binär die erste Wahl sein sollte. Mittels Transportart HTTP sieht die Antwort folgendermassen aus. HTTP/ OK Content-Type header: application/ocsp-response Content-Length header: 235 ouso.suodhnl.sluvsd Erklärung: Content-Type header: beinhaltet Wert "application/ocsp-response" Content-Length header: sollte die Länge der Response anzeigen Body Die Antwort verwendet immer das gleiche Protokoll, wie die Anfrage benutzt hatte Abspeichern von Antworten Antworten vom OCSP-Server können vom Client für spätere Nachweise abgespeichert werden. In diesem Fall sollte die Datei in ihrem Format der Antwort des HTTP Protokolls entsprechen. Die Dateinamenserweiterung für Antworten ist ".ors" 4.11 Transportart über Die Benutzung von für die Kommunikation wird nicht empfohlen. Die zugehörigen Prozess laufen asynchron ab und insbesondere der Verifikationsprozess des Anfragenden wird unterbrochen. Die Antworten des OCSP-Servers werden dann als in die Mailbox geschickt und der anfragende Client müsste manuell die Antwort dem Verifikationsprozess zugänglich machen. 78

80 4.12 Schlüssel des OCSP-Responders, Signierungsart des OCSP Alle definitiven Antworten des Server müssen signiert werden. Dazu muss der OCSP-Responder auf einen privaten Signaturschlüssel zurückgreifen können, dem der Client vertrauen kann und auf dessen bestimmungsgemässe Verwendung Verlass ist. Der OCSPv1-Standard sieht drei Möglichkeiten vor, einen privaten Schlüssel für den OCSP-Responder bereitzustellen: 1. Der OCSP-Responder verwendet einen unabhängigen Schlüssel, dem der Client direkt vertraut (TrustedResponder, self-signed Certificate) 2. Der private Schlüssel der CA wird auch für den OCSP-Responder verwendet. Es wird der Schlüssel derjenigen CA verwendet, die das nachgefragte Zertifikat ausgestellt hatte. (CA- Responder) 3. Dem OCSP-Responder wird ein speziell gekennzeichnetes Schlüsselzertifikat von der CA ausgestellt. Mit diesem Schlüsselzertifikat muss der OCSP-Responder jede Antwort signieren. Das nachgefragte Zertifikat muss jeweils von der gleichen CA sein, die auch das Schlüsselzertifikat für den OCSP-Responder ausgestellt hat. (Authorized Responder) Generell kann man sagen, dass der Schlüssel, welcher ein Zertifikatsstatus signiert, nicht der gleiche Schlüssel sein muss, der das Zertifikat unterschrieb. Die CA muss entweder den OCSP- Responder selbst signieren oder die Berechtigung einer anderen Autorität übertragen. Wurde das Unterzeichnen des OCSP-Responders delegiert, so muss in der Extension extendedkeyusage des OCSP-Responder-Zertifikat dies ersichtlich sein. Systeme oder Applikationen, welche sich auf einen OCSP-Responder verlassen, müssen einen id-ad-ocspsigning Wert entdecken und interpretieren können. Sie müssen die Antwort ablehnen, wenn das OCSP Signer-Zertifikat keine gültige Signatur aufweist Self-signed OCSP-Server, Trusted Responder Ist der OCSP-Dienst vollständig vom Betrieb der CA zu trennen, dann bietet sich die Verwendung eines von der CA unabhängigen Signaturschlüssels für den OCSP-Responder an. Der OCSP-Responder (Server) signiert sich selbst (selbst signiertes Zertifikat erstellen) und übermittelt die Statusabfragungsantwort, die mit dem self-signed Zertifikat signiert ist, an den Client. Der OCSP-Server greift meist via CRL auf die CA zu. Es ist aber auch denkbar, dass er direkt auf die CA- Datenbank zugreifen kann. Jede Applikation, die den OCSP-Responder benutzt, um die Benutzer-Zertifikate zu überprüfen, muss das self-signed Zertifikat des OCSP-Servers bei sich lokal konfiguriert haben. Das heisst, dass dieses Zertifikat über einen vertrauenswürdigen Kommunikationskanal an die Clients verteilt werden muss. Der Client muss zwischen vertrauenswürdigen Zertifikaten für verschiedene Anwendungszwecke unterscheiden können. Diese Art von OCSP-Responder wird in der UBS verwendet und zwar auf der Basis von CRL. 79

81 self-signed Abbildung 29: Self-signed OCSP-Server CA-Responder Der OCSP Responder signiert seine Antwort mit dem gleichen Schlüssel, mit dem auch die ausgegebenen Zertifikate signiert worden sind. Somit besteht die Möglichkeit einen OCSP-Server direkt in einer CA einzubauen. Diese Möglichkeit wird meistens dann gewählt, wenn der OCSP- Dienst direkt von einer CA angeboten wird. Da die Clients dem öffentlichen Schlüssel der CA bereits vertrauen, entsteht beim Angebot von OCSP kein zusätzlicher Aufwand beim Schlüsselmanagement. Dies hat jedoch den Nachteil, dass beide Server die gleiche Verfügbarkeit aufweisen müssen. Ein OCSP-Server muss eine hohe Verfügbarkeit aufweisen, während eine CA nur dann verfügbar sein muss, wenn sie ein Zertifikat oder eine CRL ausstellt. Muss jedoch ein OCSP-Server direkt auf die Datenhaltung einer CA zugreifen, so hat diese natürlich auch eine hohe Verfügbarkeit aufzuweisen. Zusätzlich sollte generell auch darauf geachtet werden, den privaten Schlüssel der CA ausserhalb der eigentlichen Zertifikatsausstellung sparsam zu verwenden, um das Risiko einer Schlüsselkompromittierung gering zu halten. Abbildung 30: CA-Responder Authorized-Responder Die CAs können ein spezielles id-kp-ocspsigning-zertifikat für OCSP-Responder ausstellen, deren Auskünfte sie autorisieren. Diese Betriebsart eines OCSP-Responders wird daher auch als Authorized-Responder bezeichnet. Das autorisierende Zertifikat kann als Zusatzinformation für den Client als Bestandteil der OCSP-Response mitgeliefert werden. Das Zertifikat, dessen Status abzufragen ist, muss von derselben CA stammen, welche auch das spezielle Zertifikat ausgestellt 80

82 hat. Der OCSP-Server wurde zwar von der CA signiert, hat jedoch einen eigenen Schlüssel. Dies wird durch eine spezielle Extension extendedkeyusage im Responder-Zertifikat gekennzeichnet. Mit dieser Variante kann ein OCSP-Responder mehrere CAs abdecken. Dazu benötigt der Authorized-OCSP-Responder von jeder CA ein eigenes Zertifikat. Da eine OCSP-Anfrage mehrere Zertifikate umfassen kann, die Antwort aber nur eine Signatur vorsieht, muss jede CA denselben Schlüssel autorisieren. Abbildung 31: Authorized Responder Momentane Lösung der UBS Wie unter bereits erwähnt, setzt die UBS zurzeit OCSP-Responder ein, die auf CRLs basieren und deren Antworten mit einem self-signed Zertifikat signiert werden. Diese Lösung ist somit keine reine Online-Statusabfrage. Die CRLs werden zentral gesammelt und dann an die verschiedenen OCSP-Responder bzw. Clients geschickt. Der CRL Service wird als hochverfügbarer Dienst mittels redundanter Hardware zur Verfügung gestellt. Mittelfristig will man die externen Zertifikate über den OCSP-Server überprüfen. Das Problem dieser Lösung ist, dass bei allen Applikationen der Public Key des OCSP-Responders lokal konfiguriert werden muss. Wenn der Schlüssel jemals ändert, so würde dies bedeuten, dass wiederum bei allen Applikationen der Schlüssel angepasst werden muss. Bei mehreren hundert Applikationen, stellt dies ein problematisches Unterfangen dar. 81

83 Die angestrebte UBS-Lösung Die UBS würde gerne die OCSP-Responder mit einem Server-Zertifikat an die Vertrauensstruktur anbinden. Da alle Applikationen der Server-CA vertrauen, wäre das Vertrauensmodell gegeben und der Schlüssel müsste nicht lokal konfiguriert werden. Diese Wunschlösung entspricht jedoch nicht dem RFC 2560 Standard. Eine Abweichung des Standards entspricht nicht der UBS- Strategie. Abbildung 32: Angestrebte Lösung der UBS 4.13 Microsoft Lösungen Momentan ist der OCSP-Dienst noch nicht im Betriebssystem von Microsoft integriert. Es besteht die Möglichkeit, dass mit der Einführung von Longhorn, dieser Dienst dann integriert ist. Heute kann mittels Plug-In von Drittherstellern OCSP über die Schnittstelle CryptoAPI an Microsoft angebunden werden. Serverseitig existiert eine Server-Software, die unter anderem auf einem Windows Betriebssystem installiert werden kann. Je nach Hersteller, vertreibt dieser die eine oder andere Lösung. Es ist jedoch auch möglich ein ganzes System (Client und Server Software) zu kaufen. Prinzipiell sind die OCSP-Client-Produkte von einem Hersteller interoperabel zu anderen OCSP-Server-Produkten eines anderen Herstellers Historisches OCSP-Anfrage/Archive Cutoff Beim nachträglichen Verifizieren von Signaturen, z.b. Verträgen vor Gericht, ist es natürlich wichtig zu wissen, ob ein Zertifikat zu einem bestimmten Zeitpunkt bereits ungültig war. Wurde das Zertifikat erst zwei Wochen nachdem ein Vertrag unterzeichnet wurde, widerrufen, so muss die Signatur auf dem Vertrag natürlich noch als gültig angesehen werden. Das damals verwendete Zertifikat kann mittlerweile regulär abgelaufen oder durch ein neues ersetzt worden sein. Grundsätzlich übermittelt der OCSP-Server im Falle eines Widerrufes im RevocationInfo-Feld den Zeitpunkt des Widerrufes. Allerdings muss er diese Informationen lange genug aufheben, sonst gibt es nach Ablauf der reguläre Gültigkeitsdauer nur noch ein good als Status zurück. Die Zeitspanne, in welcher die Revokationsdaten abgelaufener Zertifikate aufgehoben werden, wird als "Retension-Intervall" bezeichnet. Die Zeitdifferenz zwischen der Länge des Retension- Intervalls und dem Zeitstempel produceat der Statusauskunft, wird "Archive-Cutoff"-Datum des Zertifikats genannt. Abbildung 33: Retension-Intervall 82

84 Ist die Zeitperiode, die dem Retension-Intervall entspricht ab dem Moment notafter verstrichen, so kann keine Information über dieses Zertifikat eingeholt werden. Der Status diese Zertifikats ist expired. Eine Statusabfragung würde das Ergebnis good liefern. Damit der Client in Erfahrung bringen kann, ob ein OCSP-Responder noch eine Statusinformation liefern kann, muss der Client die beiden Zeiten Archive-Cutoff und notafter vergleichen. Liegt das Archive-Cutoff-Datum vor notafter, kann die Statusauskunft noch verwendet werden. Liegt das Archive-Cutoff-Datum nach notafter, dann ist das Zertifikat bereits zu lange abgelaufen und wurde endgültig aus der Datenbasis entfernt. Das Datum Archive- Cutoff wir als singleextension mitgeliefert. Folgendes Bild soll bei der Visualisierung der Situation "Archive-Cutoff vor notafter" helfen. Abbildung 34: Achive Cutoff Falls ein Zertifikat nach einmaliger Sperrung nie wieder gültig werden kann (nicht onhold), zerfällt seine Laufzeit in valid - revoked - expired. Aus den Datumsangaben notbefore, revocationtime und notafter kann der Zertifikatsstatus zu einem beliebigen Zeitpunkt bestimmt werden. Ein einmal gesperrtes Zertifikat wird, bis es nach Ablauf des Retension-Intervalls endgültig gelöscht wird, als gesperrt gemeldet. Nach Ablauf des Retension-Intervalls kann der Zertifikatsstatus nicht mehr rekonstruiert werden. Die Zeit des Retension-Intervalls kann in der Policy eingestellt werden. Falls Zertifikate mit dem Grund onhold, also temporär, gelöscht werden und später wieder aus der Revokation-Historie gestrichen wird, muss die CA über die Zeiträume den Überblick bewahren. Eine komplette Übermittlung dieser Daten als OCSP Auskunft ist ineffizient. Der OCSP-Responder soll den Status direkt bei der CA holen und zwar dann, wenn er vom Client angefragt wird. Generell weist die PKIX-Empfehlung darauf hin, dass die zeitweise Sperrungen von Zertifikaten nicht zugelassen wird. 83

85 4.15 Optimierung durch Pre-Production Response und Response-Caching Bei den rechenintensiven Signaturoperation für jede OCSP-Response oder beim Datenaustausch über ein Kommunikationsmittel mit geringer Bandbreite, kann schon mal ein Engpass oder eine Verzögerung auftreten. Es gibt zwei Möglichkeiten um dem entgegen zu wirken. In diesem Fall darf die Extension nonce nicht verwendet werden Response-Pre-Production Dieser Mechanismus ist geeignet um den OCSP-Responder von der Signaturoperation bei jeder Anfrage zu entlasten. In regelmässigen Abständen werden Statusantworten für alle Zertifikate erstellt und in einer Datenbank abgelegt. Diese Antworten sollen eine bestimmte Gültigkeitsdauer aufweisen. Der OCSP-Responder schickt dann bei einer Anfrage des Clients solch eine vorgefertigte Antwort zurück. Ein effektiver Einsatz dieses Mechanismus erweist sich bei CRLbasierenden OCSP-Statusanfragen, da ohnehin in nur regelmässigen Abständen die neue Statusinformation vorhanden ist. Es ist nicht sinnvoll eine Beschränkung auf die häufig nachgefragte Zertifikate zu legen. Die Pre-Production birgt jedoch das Risiko einer Replay-Attacke und sollte daher in kritischen Umgebungen nicht verwendet werden Caching Das Caching entlastet nicht nur den OCSP-Responder sondern auch die Kommunikationsinfrastruktur. Wird das OCSP-Protokoll über HTTP transportiert, dann können via HTTP-GET- Requests die Caching-Mechanismen von HTTP-Proxies greifen. OCSP-Client und OCSP- Responder haben dabei nur geringe Kontrolle über die vom Cache-Management verwendeten Regeln. Effektiv ist HTTP-Caching vor allem bei häufigen Zugriffen auf dieselben statischen Daten. Eine andere Einsatzmöglichkeit ist ein Trusted-Responder innerhalb einer abgegrenzten Umgebung, wie zum Beispiel das Intranet. OCSP-Clients erhalten ihre Antwort von einem lokal konfigurierten Trusted-Responder. Dieser kann auf eigene Verantwortung Revokationsinformationen zwischenspeichern und wieder verwenden Einsatzgebiete von OCSP Innerhalb Firmennetzen ermöglicht OCSP die Durchsetzung einheitlicher Policies und verringert den Administrationsaufwand erheblich. Zum Beispiel werden CRLs nur an einen zentralen Server, nämlich dem OCSP-Responder verschickt. Durch die Trennung in Client und Server kann das mobile Endgerät als Client mit weniger Ressourcen auskommen, da die Hauptarbeit in den Server verlagert wurde. Ein Schwachpunkt wäre der single point of failure Ansatz zu sehen. Diese Sicherheitslücke kann aber geschlossen werden, indem man die OCSP-Server redundant hält Marktsituation 2004 (Daten von CoreSTreet) [28] Native OCSP OCSP libraries/plug-ins Plug-ins support Microsoft Windows (Longhorn) MS bestreitet dies jedoch Identrus Netscape/Mozilla Communicator Sun ONE Identity Server RIM Blackberry PDA Compaq ipaq Netegrity SiteMinder Oblix Netpoint CoreStreet Alacris ValiCert, Tumbleweed Ascertia AssuredBytes Kyberpass SyTrust RSA KEON und BSAFE Authentica Microsoft Outlook MS Outlook Express MS Internet Explorer MS IIS Apache web server Netscape/AOL/Sun servers Microsoft VPN MS OFFICE XP Eudora (via Authentica) 84

86 Silanis Aprovelt Arcot Adobe Acrobat signing Elock Assured Office IBM DSMS Ascertina PDF Signer Conculsive TrustLogic Lexign ProSigner Gemplus esigner CMG WAP Gateway Cisco Local Director, VPN Netscreen VPN Cyberguard VPN VeriSign Peoplesoft (via Authentica) SAP (via Authentica) Lotus Notes (via Authentica) 4.17 Sicherheitsüberlegungen Bei jedem Internetprotokoll stellt sich die Frage nach seiner Verletzbarkeit und Unsicherheit gegenüber Angriffen. Eine Anwendung müsste für jede OCSP-Zertfikatsstatus-Abfrage eine Netzwerkverbindung zum OCSP-Responder aufbauen. Diese Verbindung kann entweder bei Überlastung oder falscher Konfiguration nicht zustande kommen oder durch einen Angreifer absichtlich gestört werden. Zum Senden und Empfangen von OCSP-Nachrichten benötigt die Applikation eine Kommunikationsschnittstelle. Diese zusätzliche Schnittstelle birgt ein zusätzliches Angriffsrisiko. OCSP setzt eine verfügbare authentische Zeitquelle voraus. Client- Server-Zeitsynchronisation fällt hier besonders ins Gewicht, da notwendigerweise sehr kurze Toleranzzeiten gewählt werden. Es besteht sowohl die Gefahr von einer manipulierten Zeitquelle des OCSP-Responders als auch von Eingriffen in die Systemzeit des Clients Denial-of-Service-Attacken Durch eine Flut von Anfragen, kann ein Angreifer den OCSP-Responder so stark auslasten, dass die Anfragen berechtigter Clients nicht mehr bedient werden. Diese Auslastung wird vor allem dadurch generiert, da der OCSP-Responder bei jeder Statusauskunft eine Signaturoperation auszuführen hat. Ein Schutz wäre, nur berechtigte Clients zu zulassen, welche sich mit einer Signatur bei der Anfrage authentisieren. Die Verifikation einer RSA-Signatur kann bei geeigneter Wahl des Schlüsselpaars sehr schnell durchgeführt werden. Der OCSP-Responder hat jedoch im Allgemeinen keinen Einfluss auf die Auswahl des Verifikationsschlüssels. Dieser Schutz kann jedoch auch wieder für eine DoS-Attacke eingesetzt werden, da zur Verifikation der Client Signatur auch enormer Rechenaufwand erfordert wird. Unberechtigte Anfragen werden mit einer unsignierten Fehlermeldung beantwortet. Der Angreifer kann auch korrekt signierte Anfragen berechtigter Clients, die er zuvor abgefangen hat, beliebig oft an den OCSP- Responder weiterschicken. Es können auch einfache unkorrekte Anfrage den OCSP-Responder belasten, ohne dass Kryptographische-Operationen dazu gebraucht werden Man-in-the-Middle Der Angreifer könnte sich zwischen OCSP-Client und OCSP-Server platzieren und jede Anfrage und Antwort abfangen und lesen. Der Angreifer kann die abgefangene Antwort durch eine unsignierte Fehlermeldung ersetzen. Der Client kann nicht erkennen, dass diese Antwort gefälscht ist und schliesst je nach Fehlermeldung (siehe Kap. 4.7) daraus die falschen Schlüsse. Es könnte auch möglich sein, dass der Angreifer eine als Rückfalloption vorgehaltene CRL als Revokationsmöglichkeit vorschlägt. Durch signierte Fehlermeldungen hätte dieses Problem vermieden werden können. Jedoch wäre hier dann auch wieder eine DoS-Attacke möglich. Auch eine gezielte Verzögerung der Antwort kann bei einer sensiblen Anwendung dazu führen, dass diese Antwort nicht mehr akzeptiert wird. 85

87 Response-Replay Die Möglichkeit im vornherein Antworten (vorberechnete Antworten) zu erzeugen und damit die Performance und Skalierbarkeit zu verbessern, kann auch ein Angreifer für sich benutzen. Diese replay Attacke benutzt alte gute Antworten, die vor dem Verfallsdatum revoziert wurden, nochmals. Ein Angreifer verwendet diese Funktion um dem OCSP-Client falsche Auskünfte zu liefern. Dieser Angriff unterdrückt die Verteilung der aktuelle Revokationsinformationen. Diese Attacke kann durch eine Koppelung von Anfragen und zugehöriger Response durch eine nonce ausgeschlossen werden. Dieses Problem kann auch auftreten, falls die OCSP-Abfrage über unzuverlässige, fehlerhafte oder falsch konfigurierte HTTP-Caches abgewickelt werden. Das HTTP Caching kann unter Umständen zu unerwarteten Resultaten führen, wenn der OCSP- Server falsch konfiguriert wurde oder sein Cache-Management Fehler aufweist. Deshalb ist bei der Implementierung des HTTP-Dienstes genügend Aufmerksamkeit zu schenken Risiken eines kompromittierten OCSP-Signaturschlüssels Ist ein Angreifer im Besitz des privaten Schlüssels des OCSP-Responders, kann er natürlich irreführende Auskünfte über den Revokationsstatus eines Zertifikats erteilen. Zum Beispiel kann der falsche Responder dem Client einen noch gültigen Status eines Anwenders übermitteln. Solange der Betrug unentdeckt bleibt, kann der Angreifer Botschaften im Namen des OCSP- Responders signieren. Ein gefälschter OCSP-Responder kann beliebige Zertifikate als gesperrt kennzeichnen und dadurch die Legitimation einer Signatur aberkennen Revokation von OCSP-Schlüsselzertifikaten Für die Sperrung der Schlüsselzertifikate von Autoritäten wie CA, RA und den Verzeichnisdiensten innerhalb einer PKI können Authority-Revocation-List (ARL) verwendet werden. Im Prinzip sind sie fast gleich wie CRL, nur werden die Autoritäten viel weniger gesperrt. Die Vertrauenswürdigkeit in die CA und OCSP-Responder wird sofort verloren. Für den Betrieb eines OCSP-Responders, der nicht an eine CA gebunden ist (self-signed) und dem direkt vertraut wird, wird bereits zur Herstellung des Vertrauens in den OCSP-Signaturschlüssel ein spezielles Verfahren benötigt. Die Verbreitung der Revokationsnachricht kann im Umfeld von UBS sehr kompliziert und aufwendig sein. In anderen Umgebungen mit einer übersichtlichen Anzahl von Clients, die dem OCSP-Responder vertrauen, kann die Verteilung sehr einfach sein. 86

88 4.20 OCSP-Struktur OCSP-Request Abbildung 35: OCSP-Request [50] Request ASN.1 Syntax OCSPRequest ::= SEQUENCE { tbsrequest TBSRequest, optionalsignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorname [1] EXPLICIT GeneralName OPTIONAL, requestlist SEQUENCE OF Request, requestextensions [2] EXPLICIT Extensions OPTIONAL } Signature ::= SEQUENCE { signaturealgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} Version ::= INTEGER { v1(0) } Request ::= SEQUENCE { reqcert CertID, singlerequestextensions [0] EXPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE { hashalgorithm AlgorithmIdentifier, 87

89 issuernamehash OCTET STRING, -- Hash of Issuer s DN issuerkeyhash OCTET STRING, -- Hash of Issuers public key serialnumber CertificateSerialNumber } CertificateSerialNumber ::= [24] INTEGER OCSPRequest Anfragen an den OCSP-Server werden durch die Struktur OCSPRequest spezifiziert, die ihrerseits aus den eigentlichen Anfragedaten tbsrequest (tbs = to be signed) und der optionalen Signatur optionalsignature besteht. TBSRequest Das tbsrequest-teilfeld enthält eine Versionsnummer version. Falls der OCSP-Request signiert wurde, muss der Name des Client in requestorname angegeben werden. Eine Folge von Einzelanfragen sind im Feld requestlist einzutragen. Der Request kann durch optionale Anfrageerweiterungen requestextensions ergänzt werden. Version Das version-teilfeld enthält die Versionsnummer der OCSP-Anfrage. Die Voreinstellung für dieses Feld hat den Wert 0, der die Version 1 anzeigt. Aktuell gibt es nur die Version 1. Die OCSPv2 liegt nur in einer Draft-Version vor und es ist unsicher, ob dieser Draft jemals zu einem Standard hinüber geht. requestorname Das optionale requestorname-teilfeld enthält den Namen des Clients, der seine Anfrage an den OCSP-Server bei Bedarf signieren kann. Falls eine OCSP-Anfrage signiert wird, so muss der Anfragende seinen Namen in dem requestorname- Teilfeld angeben. Der Name kann in verschiedenen Formaten (Relative Distinguished Name, URL, IP-Adresse, etc.) angegeben werden. Der Typ GeneralName wird aus PKIX1 importiert. requestlist Das requestlist-teilfeld enthält die Anfragen selbst. Die Liste der Einzelanfragen kann mehrere unterschiedliche Zertifikatsreferenzen enthalten. Diese Zertifikate müssen nicht alle von der gleichen CA ausgestellt sein. requestextensions Die optionale Komponente requestextensions dient zur Aufnahme von Erweiterungen, die für die gesamte OCSP-Anfrage gelten. Sie ist vom Typ Extensions. Signature Das optionalsignature-feld besteht aus signaturealgorithm, signature und certs. Die Signatur wird im Feld signaturealgorithm angegeben. Der Bitstring signature enthält den Binärwert der digitalen Signatur. Im Feld certs kann eine Menge von Zertifikaten, die der OCSP-Responder bei der Signaturverifikation verwenden kann, übergeben werden. Die Signatur wird über die gesamte tbsrequest-struktur berechnet. Falls eine OCSP-Anfrage signiert wird, so muss der Anfragende seinen Namen im requestorname-teilfeld der tbsrequest-struktur angeben. Request In der Datenstruktur Request werden die einzelnen Zertifikate bezeichnet (ein Zertifikat aus der requestlist), deren Status abzufragen ist. Der Request besteht aus dem Zertifikatsbezeichner certid. Zusätzlich können eine oder mehrere Anfrageerweiterungen singlerequest-extensions, die sich auf dieses Zertifikat beziehen, angefügt werden. 88

90 reqcert Ein Zertifikat wird mit der Datenstruktur CertID des reqcert-teilfeldes eindeutig beschrieben. Die Namensangabe wurde wegen Platzersparnis auf einen Hashwert reduziert. Die Berechnung des Hashwertes wirft jedoch weitere Probleme auf. Zum Beispiel ist die unterschiedliche Gross- /Kleinschreibung relevant. Denn stimmen die Buchstaben nicht überrein, so erhält man zwei unterschiedliche Hashwerte. Als Hash-Algorithmus soll der SHA-1 verwendet werden. Zur eindeutigen Identifizierung der CA wird der Hash über den public Key (issuerkeyhash) und distinguished Issuername (issuernamehash) berechnet. Der Name des Ausstellers ist nicht zwingend global eindeutig. Die PKIX-Standards empfehlen lediglich die Verwendung eindeutiger Namen innerhalb einer PKI-Domäne. Zwei Aussteller (Issuer) können zwar die gleichen Namen tragen, aber sie werden jedoch niemals den gleichen öffentlichen Schlüssel verwenden. Und wenn, dann ist es fraglich, ob sie immer noch zwei unterschiedliche CA's sind? Der Hashalgorithmus ist im Feld hashalgorithm festgelegt und er soll mit DER codiert werden. Die Seriennummer ist die Zertifikats-Nummer, dessen Status abgefragt werden soll. Die Kombination aus dem Namen des Ausstellers issuernamehash und der Seriennummer serialnumber des betreffenden Zertifikates wird als Identifikator des Zertifikats verwendet. Das Feld hashalgorithm enthält den Objektbezeichner eines geeigneten Hashalgorithmus. Das Feld issuernamehash enthält das Ergebnis der Anwendung der Hashfunktion auf den nach DER-codierten Namen des Ausstellers. Das Feld issuerkeyhash enthält das Ergebnis der Anwendung der Hashfunktion auf den Wert des Feldes subjectpublickey (ohne den ASN.1-Tag und die Längenbeschreibung) aus dem Zertifikat des Ausstellers. singlerequestextensions Die Komponente singlerequestextensions dient zur Aufnahme von Erweiterungen, die für einzelne Anfragen gelten. Sie ist vom Typ Extensions. Die Unterstützung von Erweiterungen ist optional. Das critical Flag sollte für keine Erweiterung gesetzt werden. Unbekannte Erweiterungen dürfen ignoriert werden, sofern das critical Flag nicht gesetzt ist. Die Erweiterung muss als critical markiert werden. Außerdem wird eine obligatorische Erweiterung certhash für das singlerequestextensions-teilfeld der Request-Struktur vorgesehen, die den Hashwert des betreffenden Zertifikates enthält. Die Erweiterung muss als non-critical markiert werden. Diese Komponente etabliert eine kryptographische Bindung zwischen der Bytefolge des Zertifikates und der Antwort des Verzeichnisdienstes. 89

91 OCSP-Response Abbildung 36: OCSP-Response [50] ASN.1 OCSPResponse OCSPResponse ::= SEQUENCE { responsestatus OCSPResponseStatus, responsebytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus ::= ENUMERATED { successful (0), --Response has valid confirmations malformedrequest (1), --Illegal confirmation request internalerror (2), --Internal error in issuer trylater (3), --Try again later --(4) is not used sigrequired (5), --Must sign the request unauthorized (6) --Request unauthorized } ResponseBytes ::= SEQUENCE { responsetype OBJECT IDENTIFIER, response OCTET STRING } OCSPResponse Die Antwort besteht aus dem allgemeinen Ergebnis der Anfrage responsestatus und dem optionalen Feld responsebytes. Der Status beinhaltet die Werte wie successful, malformedrequest, internalerror, trylater, sigrequired und unauthorized. Im Falle der 90

92 erfolgreichen Beantwortung des Requests, enthalten die responsebytes die Auskunftsdaten. Im Fehlerfall ist das Feld nicht belegt. OCSPResponseStatus Im responsestatus-feld der OCSPResponse-Struktur wird das Ergebnis einer erfolgreichen Anfrage an den OCSP-Server angezeigt. Falls eine Anfrage vom OCSP-Server erfolgreich bearbeitet werden konnte, ist die explizite Antwort im responsebytes-teilfeld von OCSPResponse enthalten. Es erfolgt keine Antwort im responsebytes-teilfeld von OCSPResponse, wenn ein Fehlerfall aufgetreten ist. Insbesondere die Anfrage ein unbekanntes Format enthält, ein interner Fehler auftaucht, OCSP-Server temporär nicht verfügbar ist, trotz Verlangen eine unsigniert Anfrage einging und wenn der OCSP-Server das explizite Vorhandensein eines Zertifikates im cert-teilfeld einer Anfrage verlangt. Alle Fehlerfälle sind in 4.7 aufgeführt. ResponseBytes Das responsebytes-feld beinhaltet das Feld responsetyp, welches den Objektbezeichner id-pkixocsp enthält sowie das Feld response, das die Response beinhaltet. Im Feld responsetyp wird sozusagen der Antwort-Typ definiert. Momentan ist aber nur der Basic standardisiert. Jede OCSP-Applikation, jeder Server und OCSP-Client müssen den Basic-Typ unterstützen. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-ad-ocsp 1 } Es ist möglich daraus einen eigenen Antwort-Typ zu generieren und diese Struktur steht auch keiner zukünftigen Erweiterung in die Quere. id-pkix-ocsp-ubs OBJECT IDENTIFIER ::= { id-ad-ocsp X } BasicOCSPResponse BasicOCSPResponse ::= SEQUENCE { tbsresponsedata ResponseData, signaturealgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, responderid ResponderID, producedat GeneralizedTime, responses SEQUENCE OF SingleResponse, responseextensions [1] EXPLICIT Extensions OPTIONAL } ResponderID ::= CHOICE { byname [1] Name, bykey [2] KeyHash } KeyHash ::= OCTET STRING -- SHA-1 hash of responder s public key (excluding the tag and length fields) SingleResponse ::= SEQUENCE { certid CertID, certstatus CertStatus, thisupdate GeneralizedTime, nextupdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleextensions [1] EXPLICIT Extensions OPTIONAL } 91

93 CertStatus ::= CHOICE { good [0] IMPLICIT NULL, revoked [1] IMPLICIT RevokedInfo, unknown [2] IMPLICIT UnknownInfo } RevokedInfo ::= SEQUENCE { revocationtime GeneralizedTime, revocationreason [0] EXPLICIT CRLReason OPTIONAL } UnknownInfo ::= NULL -- this can be replaced with an enumeration BasicOCSPResponse Das response-antwortfeld der ResponseBytes-Struktur vom Typ BasicOCSPResponse besteht aus der eigentlichen Antwort tbsresponsedata, einer Beschreibung des Signaturalgorithmus signaturealgorithm, dem Wert der Signatur signature selbst sowie einer optionalen Folge von Zertifikaten certs. Diese Menge von speziellen Zertifikaten weisen nach, dass der Schlüssel des OCSP-Responders von den entsprechenden CAs zur Auskunftserteilung autorisiert wurde. Falls die BasicOCSPResponse-Komponente eine Reihe von Zertifikaten enthält, so darf die Reihenfolge beliebig sein. Den Wert für die Signatur soll aus DER encoding ResponseData mittels dem Hash berechnet werden. ResponseData Die Nutzdaten der BasicOCSPResponse-Antwort sind in der Struktur ResponseData abgelegt und wiederum in die Teilfelder version, responderid, dem Zeitstempel producedat, den Einzelantworten responses und optionalen responseextensions, die sich auf die gesamte OCSP- Response beziehen, unterteilt. version Enthält die Version des OCSP-Protokolls. Zurzeit ist dies nur die Version v1. responderid Die Identifizierung des OCSP-Server erfolgt über das responderid-feld. Dies kann entweder durch den Namen (byname) oder öffentlichen Schlüssel (bykey) des OCSP-Responders erfolgen. Der Wert von bykey wird als SHA-1-Hash über den Wert des öffentlichen Schlüssels berechnet. producedat Der Zeitpunkt, zu dem diese Antwort signiert wurde, wird in dem Feld producedat angezeigt, das vom Typ GeneralizedTime ist. Sofern ein OCSP-Server Antworten für gesperrte Zertifikate erstellt und für späteren Gebrauch signiert, kann dieser Zeitpunkt auch vom Zeitpunkt der Anfrage abweichen. In diesem Fall muss der Zeitpunkt von producedat zwischen dem Sperrzeitpunkt und dem Zeitpunkt der Anfrage liegen. responseextensions Die Komponente responseextensions dient zur Aufnahme von Erweiterungen, die für die gesamte OCSP-Antwort gelten. SingleResponse Das Feld responses enthält eine Folge von Einzelantworten SingleResponses, die den entsprechenden Anfragen zugeordnet werden. Die Reihenfolge der SingleResponses ist beliebig, und der Client muss die einzelnen Felder der Antworten den jeweiligen Anfragen zuordnen. Der OCSP-Server muss zu jeder einzelnen Anfrage aus dem requestlist-feld (innerhalb OCSPRequest und TBSRequest) eine Antwort im dem Feld responses bereitstellen. Sofern der OCSP-Server dies in einem konkreten Fall nicht kann, muss er mit der Fehlermeldung internal-error antworten. Jede Einzelantwort SingleResponse besteht aus den Informationen certid, certstatus und thisupdate sowie aus den optionalen Teilfeldern nextupdate und singleextensions. 92

94 certid Ein Zertifikat wird mit der Datenstruktur CertID des responses-teilfeldes eindeutig beschrieben. Die Angaben der certid in der Response erlaubt eine eindeutige Zuordnung des Zertifikatsstatus zu einem Zertifikat. Die Kombination aus dem Namen des Ausstellers issuernamehash und der Seriennummer serialnumber des betreffenden Zertifikates wird als Identifikator des Zertifikates verwendet. Das Feld hashalgorithm enthält den Objektbezeichner eines geeigneten Hashalgorithmus. Das Feld issuernamehash enthält das Ergebnis der Anwendung der Hashfunktion auf den nach DER-codierten Namen des Ausstellers. Das Feld issuerkeyhash enthält das Ergebnis der Anwendung der Hasfunktion auf den Wert des Feldes subjectpublickey (aus dem Zertifikat des Ausstellers. certstatus Das certstatus-teilfeld enthält sie Statusinformationen des in certid bezeichneten oder enthaltenen Zertifikates. OCSP unterschiedet zwischen den drei Zuständen good, revoked und unknown. thisupdate Der Zeitpunkt thisupdate gibt den Zeitpunkt an, zu dem der gemeldete Zertifikatsstatus vorlag. nextupdate Dieser Zeitpunkt gibt den spät möglichsten Zeitpunkt an, ab dem mit neuen Informationen gerechnet werden muss. Diese Zeitangabe ist nur nötig bei OCSP-Responses, die auf CRL basieren. singleextensions Die Komponente singleextensions dient zur Aufnahme von Erweiterungen, die für einzelne Antworten gelten. Sie ist vom Typ Extensions. Der Client muss Antworten mit vorhandenem singleextensions-teilfeld verarbeiten können. Er muss aber nicht auf deren Inhalt reagieren. Insbesondere können Erweiterung die Aussagen im certstatus-teilfeld weder modifizieren oder einschränken. 93

95 4.21 Extensions Der Erweiterungsmechanismus erlaubt einen flexiblen Ausbau des Grundprotokolls. Die im OCSP-Protokoll verwendeten Erweiterungen entsprechen im Format den X.509-Extensions der X.509v3-Zertifikate. OCSP erlaubt sowohl Erweiterungen, die den kompletten Request beziehungsweise die Response betreffen, als auch zertifikatsspezifische Erweiterungen. Die Unterstützung von speziellen Extensions ist optional und diese Extensions sollten als noncritical markiert werden. Die kritische Markierung erreicht man, wenn das Flag critical gesetzt wird und damit können nicht anerkannte Extensions nicht ignoriert werden. Dies wiederum bedeutet, dass - analog zu Zertifikats-Extensions - eine solche Anfrage nicht beantwortet werden kann. Die folgende Tabelle fasst die wichtigsten definierten Erweiterungstypen für das OCSP-Protokoll zusammen. ASN.1 OID OCSP- Request request Extension single requ. Extension i OCSP- Respons e response single respo. Extension. Erläuterungen id-pkix-ocsp-nonce x x id-pkix-ocsp-nonce ::= { id-pkix-ocsp 2} Diese Extensions ermöglicht die kryptographische Bindung von Request und Response (siehe Kap ) id-pkix-ocsp-crl x id-pkix-ocsp-crl ::= { id-pkix-ocsp 3} Referenziert eine CRL. aus der die Revokationsinformation entnommen wurde (siehe Kap ) id-pkix-ocsp-response x id-pkix-ocsp-response ::= { id-pkix-ocsp 4} Ein OCSP-Client kann angeben, welche Antworttypen er akzeptiert. In der Extensions sind die OID's aufgeführt, welche auf die Responstypen hinweisen. (z.b. id-pkix-ocsp-basic). Jeder OCSP- Teilnehmer muss mindestens den Typ Basic verstehen. id-pkix-ocsp-achivecutoff id-pkix-ocsp-servicelocator x x id-pkix-ocsp-achive-cutoff ::= { id-pkixocsp 5} Wird zur Bestimmung des Zertifikatsstatus zu einem früheren Zeitpunkt verwendet (siehe Kap. xxx) id-pkix-ocsp-service-locator ::= { id-pkixocsp 6} Dient dem Routing von OCSP-Anfragen (siehe Kap. xxx) Folgende Erweiterungen sind für CRL vereinbart, werden aber auch von OCSP unterstützt: id-ce-crlreason x id-ce-crlreason ::= { id-ce 21} Gibt den Revokationsgrund an. Ein entsprechendes optionales Feld ist bereits in RevokedInfo enthalten. id-ceholdinstructioncode x id-ce-holdinstructioncode::= { id-ce 23} Bestimmt im Falle eines zeitweise gesperrten Zertifikats (on hold) wie 94

96 verfahren werden soll. id-ce-invaliditydate x id-ce-invaliditydate::= { id-ce 24} Gibt den Zeitpunkt an, zu dem das Zertifikat vermutlich revoziert wurde. Dieser Zeitpunkt kann vor dem Zeitpunkt liegen, an dem das Zertifikat tatsächlich gesperrt wurde. id-ce-certificateissuer x id-ce- certificateissuer::= { id-ce 29} Enthält als Wert den Namen der CA, die das Zertifikat ausgestellt hat. In Verbindung mit CRLs wird diese Erweiterung verwendet, falls die CRL nicht auch von dieser CA ausgegeben wurde (indirekte CRL). Da der Name der CA bereits fester Bestandteil der CertID ist, ist diese Erweiterung in OCSP überflüssig Nonce Das OCSP-Protokoll unterschiedet nicht zwischen verschiedenen Sessions und daher steht eine Response nicht in direktem Bezug zu einer bestimmten Anfrage. Der Vorteil bei diesem Vorgehen ist, dass einmal erzeugte und signierte OCSP-Responses mehrmals verwendet werden können. Andererseits werden dadurch Replay-Attacken ermöglicht. Die Extension nonce bindet die Antwort an eine Anfrage, damit keine Verwechslung stattfinden kann. In der Response steht nonce innerhalb der responseextensions und im Request innerhalb der requestextensions. Beide sind aber mit dem Object Identifier identifiziert. id-pkiy-ocsp-nonce OBJECT IDENTIFIER::={ id-pkix-ocsp 2 } Die nonce-erweiterung kann in ihrem Datenteil eine beliebige eindeutige Kennzeichnung als Session-Identifier enthalten. Sinnvoll ist jeweils eine nonce pro Anfrage als requestextension. Im einfachsten Fall schickt der OCSP-Client eine Zufallszahl. Die nonce wird vom OCSP-Responder in die Antwort übertragen CRL Referenz Diese Extension wird benötigt, wenn der OCSP-Dienst auf CRL basiert. In dieser singleextension wird auf die CRL referenziert, welche den Status des einzelnen Zertifikats angab (siehe auch Kapitel 3.21, Zugriff via CRL) Die CRL ist mit einer URL, CRL Nummer und/oder einer spezifischen Zeit (thisupdate) definiert. Diese Extension ist als singleextensions spezifiziert. Der Object Identifier ist: id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } Der Wert wird folgend nach ASN.1 spezifiziert: crlreference EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY id-pkix-ocsp-crl} CrlID :: _ SEQUENCE { crlurl [0] EXPLICIT IA5String OPTIONAL, crlnum [1] EXPLICIT INTEGER OPTIONAL, crltime [2] EXPLICIT GeneralizedTime OPTIONAL} 95

97 Archive Cutoff Es ist möglich die Statusinformation eines Zertifikats über das Ablaufdatum des Zertifikats für eine definierte Dauer aufzubewahren. Dann ist diese Statusinformation durch den OCSP- Responder noch abrufbar. Ist jedoch diese Zeit verstrichen, so wird das Zertifikat nach Ablauf dieser Frist als expired aus der Datenbasis gelöscht. Diese Möglichkeit ist im Kapitel xxxx genauer beschrieben. id-pkix-ocsp-archive-cutoff. OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } Service Locator Es besteht auch die Möglichkeit einen OCSP-Responder als eine Art Proxy in Verbindung mit OCSP-Responder zu betreiben. Mittels der singelrequestextentsion kann der Proxy-OCSP- Responder den richtigen, autorisierten OCSP-Responder wählen. Diese Extension ist innerhalb der singlerequestextentisons im Request. Der Wert dieses Feldes muss mit dem entsprechendem Feld im Benutzer-Zertifikat (subject certificate) übereinstimmen. Anmerkung: Aufgrund dieser Extension können auch die OCSP-Anfragen weitergeleitet werden, bis ein OCSP-Responder verfügbar ist. Ein vorangestellter OCSP-Responder übernimmt die zentrale Verarbeitung der Weiterleitung. Ein Produkt mit einer solchen Architektur kann bei corestreet [28] bezogen werden. Weitere Details sind im Kapitel Extension nachzulesen. id-pkix-ocsp-service-locator. OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } crllocator EXTENSION ::= { SYNTAX ServiceLocator IDENTIFIED BY id-pkix-ocsp-service-locator } ServiceLocator ::= SEQUENCE { issuer Name, locator AuthorityInfoAccessSyntax OPTIONAL } 96

98 4.22 OCSPv2 Obwohl OCSP bereits recht ausgereift ist und sich gut durchsetzen konnte, weist OCSPv1 einige Lücken auf. Das größte Problem von OCSPv1 ist, dass es wirklich nur überprüft, ob ein Zertifikat widerrufen wurde. Um ein Zertifikat als gültig anzuerkennen, sind vom Client aber noch andere Überprüfungen durchzuführen. So sind z.b. die Signaturen der CAs und eventuell deren Zertifikate zu überprüfen. Da dies den Implementierungs- und Administrationsaufwand von Clients weiter erhöht, versucht OCSPv2 weitere Arbeit vom Client auf den Server zu übertragen. Dabei ist OCSPv2 in drei Abfragemodi aufgegliedert: [29], [30], [31], [35] Online Revocation Status (ORS). Delegated Path Validation (DPV) Delegated Path Discovery (DPD) Der gewünschte Abfragemodi wird vom Client als object identifier (OID) in die requestextension geschrieben. Steht dort kein Wert, wird ORS (Online Revocation Status) als Standardwert angenommen. Dadurch wird die Abwärtskompatibilität zu OCSPv1 erreicht, so dass ein OCSP v1 Client problemlos mit einem OCSPv2 Server kommunizieren könnte. Zusätzlich sollte der Client, bevor er eine Verbindung aufbaut, den CA Public Key erhalten. Der zweite Punkt wäre, dass die Server die CA's indexieren. Eine andere grosse Änderung ist, dass der Client das Zertifikat mitschickt, für welches er den Status abfragen möchte. Es gibt nun auch 5 Wege das Zertifikat zu identifizieren, nämlich mittels certid, Hash (Cert), cert, IssuerSerial und URL to Cert. Dies soll zu der Sicherheit auch Interoperabilität unterstützen. Zusätzlich gibt es auch 4 neue Status-Zustände. Zu den Zuständen good, revoked und unknown wären neu die Zustände "valid", "invalid", "suspended" und "expired" möglich. Die grössten Erneuerungen in OCSPv2 sind aber die Protokolle Delegated Path Discovery und Delegated Path Validation. Der ASN.1 in OCSPv2 wurde so definiert: [32], [33] DPVOptions :: = SEQUENCE{ pathparams PathParameters OPTIONAL, validat [2] GeneralizedTime OPTIONAL, revinfo [3] SEQUENCE OF RevocationInfo OPTIONAL, dpvflags [4] DPVFlags OPTIONAL } PathParameters ::= SEQUENCE { initialpolicyset [0] PolicyList OPTIONAL, trustpoints [1] SEQUENCE OF ReqCert OPTIONAL } DPVFlags ::= BIT STRING { returnpath (0), returnrevinfo (1), returntsp (2), returnpolicy (3) } RevocationInfo ::= CHOICE { crl CertificateList, ocsp OCSPResponse } DPDOptions :: = SEQUENCE{ retryreference OCTET STRING, initialpolicyset [0] EXPLICIT PolicyList OPTIONAL, trustpoints [1] SEQUENCE OF ReqCert OPTIONAL, validat [2] GeneralizedTime OPTIONAL, ddpflags [3] DPDFlags OPTIONAL} 97

99 DPDFlags ::= BIT STRING { returntsp (0), returnpolicy (1), crlonly (2), ocsponly (3), either (4) } Delegated Path Validation (DPV) und Delegated Path Discovery (DPD) Die grosse Errungenschaft in OCSPv2 sind die Protokolle DPV und DPD. Diese beiden Protokolle wurden auch im SCVP aufgenommen. Sie werde deshalb auch im Kapitel xxx unter SCVP weiter erläutert Auswirkung auf die UBS Die UBS hätte es gerne, wenn sich der Draft OCSPv2 als Standard deklarieren würde. In diesem Standard sind die definierten Vorgaben, wie der OCSP-Responder signiert werden muss aufgelockert und weniger eingeschränkt. In diesem Fall könnte die UBS ihre Lösung eine Server- CA, die den OCSP-Responder signiert, einführen, ohne vom Standard abzuweichen. Leider wird der Draft OCSPv2 nicht weiter verfolgt OCSPv2 Drafts Wir haben nur wenige OCSPv2-Drafts gefunden und diese waren teilweise schon lange abgelaufen oder sogar gelöscht worden (z.b. draft-ietf-pkix-ocspv2-02.txt draft-ietf-pkix-ocspv2-03.txt). Auf der Suche nach dem Status der OCSPv2-Draft sind wir auf SCVP gestossen. Uns erschien es so, als ob das Protokoll OCSP von SCVP abgelöst werden wird. Wir lasen die Begründung, dass das OCSP-Protokoll bereits in der Version 1 einen hohen Komplexitätsgrad aufweist und mit der nächsten Version nur noch komplexer würde. [34] 98

100 5 Simple Certificate Validation Protocol (SCVP) 5.1 Zusammenfassung Die Validierung eines Zertifikates ist sehr komplex. Wenn einer Applikation ein Zertifikat vorliegt, so muss sie dieses jedes Mal auf seine Gültigkeit überprüfen, bevor der Zugriff erlaubt werden kann. Heutzutage gibt es bereits viele Applikationen, die Zertifikate einsetzen können. Oft sind sie jedoch mit der Überprüfung der Zertifikatsgültigkeit überlastet. Beim Protokoll OCSP muss die Validierung der Zertifikate und die Konstruktion der Zertifikatskette auf der Client-Seite ausgeführt werden. Um dem Client die Zertifikatskettenbildung und dessen Validierung zu ersparen, arbeitet die IETF derzeit an einem weiteren Produkt, Simple Certificate Validation Protocol (SCVP), das einen ähnlichen Zweck erfüllen soll wie OCSP, aber mehr Funktionen aufweist. Dieses Kapitel gibt einen Überblick über das Protokoll SCVP. Es wird aufgezeigt, welche neuen Zusatzfunktionen das Protokoll im Gegensatz zu OCSP bietet. In möglichen Anwendungsfällen soll ersichtlich sein, welche Variationen von Abfragen gemacht werden können. Das Kapitel 5.12 beschreibt die SCVP-Struktur. Dieses Kapitel soll vor allem Lesern, die sich näher mit dem Protokoll befassen möchten, dienen. [36], [37], [38] 5.2 Entstehung von SCVP Mit der Entwicklung von SCVP wollte man vermeiden, dass OCSP zu komplex wird. Daher entstand für die Zertifikatsvalidierung ein eigenes Protokoll. Zu Beginn der Entwicklung von SCVP war es das Ziel, folgende drei Arten von Gemeinschaften zu unterstützen: 1. very lightweigth Clients (Thin Clients) 2. Organisationen, die Kontrolle zentralisieren möchten 3. Clients die ASN.1 nicht parsen können, aber XML verstehen Während die Punkte 1 und 2 berücksichtigt werden konnte, wurde die Idee der XML- Untersützung wieder verworfen und nicht umgesetzt.2 Der Grundgedanke von Punkt 3, Clients zu unterstützen, die ASN.1 nicht parsen können aber XML verstehen, entstand aus der Erkenntnis, dass XML sehr zukunftsbasiert ist und viele Organisationen bereits nach XML streben und auch einsetzen. Weiter wollte man versichern, dass auch mit XML die PKI auf sicherem Wege eingesetzt werden kann. Man war der Meinung, dass ohne XML Unterstützung die PKI wegen dem doch schon ziemlich alten ASN.1 Code ignoriert werde und Eigenentwicklungen zum Einsatz kommen könnten. 5.3 Simple Certificate Validation Protocol SCVP ist ein Protokoll, das dem Client ein partielles bis vollständiges Auslagern der Zertifikats- Validierung ermöglicht. Der Server kann dem Client, neben den Informationen über den Sperrstatus des Zertifikats, mit zusätzlichen Zertifikatsinformationen beliefern. Zum Beispiel, ob das Zertifikat oder der Zertifikatspfad bis zur einer bestimmten Root CA gültig ist. Das primäre Ziel von SCVP ist die Anwendungen von PKI-fähigen Applikationen zu vereinfachen und eine zentrale Administration der PKI Policies innerhalb einer Organisation zu ermöglichen. SCVP wurde mit Fokus auf zwei Klassen von Applikationen entwickelt: 1. Klasse Die erste Klasse von Applikationen ist an zwei Vorgängen interessiert. Erstens wollen sie eine Bestätigung, dass der Public Key auch wirklich zu dem identifizierten Namen gehört, der im 2 Mail von Ambarish Malpani; Malpani Colulting Services 99

101 Zertifikat steht. Zweitens, möchten sie wissen ob der Public Key zu dem von ihnen beabsichtigten Zweck auch eingesetzt werden kann. Der Client delegiert dem Server die vollständige Zertifikats- und Pfadüberprüfung inklusive Statusüberprüfung der Zertifikate. SCVP Request- Processing Path Construction Path-Validation SCVP Responsehandling Status- Checking SCVP Request: Certificate OK? SCVP Response: Certificate Valid/ Not Valid SCVP-Client Abbildung 37: Validierung durch Server (Delegated Path Validation, DPV) Die Applikation ist also am Ergebnis der Validierung eines Zertifikates für eine bestimmte Anwendung interessiert. Diese Situation ist beispielsweise wenn: - die Applikationen nicht die Ressourcen haben, dies selbst zu tun (z.b. Thin Clients) - der Client den Overhead für die Zertifikats-Validierungs-Software nicht übernehmen möchte. Denn jedes Mal, wenn einer Applikation ein Zertifikat vorliegt, muss diese Validationssoftware gestartet werden. - der Client in einer Unternehmung steht, die ihre PKI-Policies zentralisieren möchte. Diese Policies können bestimmen, welchen CAs vertraut wird und welche CAs eingesetzt werden dürfen. Weiter kann der Typ des Policy-checking bestimmt werden, der während der Validierung der Zertifikatskette ausgeführt werden soll. (Kapitel 5.4) - die Einhaltung der Sicherheitsrichtlinien auch durch den SCVP-Server gewährleistet werden kann. Für die Validierung einer Zertifikatskette wird das Protokoll Delegated Path Validation (DPV) eingesetzt. 2. Klasse Die zweite Klasse von Applikationen können zwar die Validierung der Zertifikatskette selbst durchführen, haben aber keine zuverlässige Methode um die Zertifikatskette selbst zu konstruieren. Dies zum Beispiel weil: - die Applikationen, die dafür nötige Protokolle nicht implementiert haben. - die Komplexität der Konstruktion (Pfad-Findung) die Möglichkeiten des Gerätes überschreitet. SCVP Request- Processing Path Construction SCVP Responsehandling SCVP Request: Find certificate path SCVP Response: Certificate path or error "no certificate path found" SCVP-Client Abbildung 38: Validierung durch Client (Delegated Path Discovery, DPD) 100

102 Der Client delegiert also die Konstruktion der Zertifikatskette an den SCVP Server. Ebenfalls können Sperrinformationen wie zum Beispiel CRLs und OCSP-Antworten vom SCVP-Server ermittelt werden. Die Validierung erfolgt dann lokal (Client-seitig) anhand von so genannten Path Discovery Policies. Für die Konstruktion einer Zertifikatskette wird das Protokoll Delegated Path Discovery eingesetzt. ASN.1 Das SCVP-Protokoll benutzt an vielen Stellen die ASN.1 definierten eindeutigen Bezeichner (object identifier, OIDs). Sie werden zum Beispiel benutzt, um Policies zu referenzieren und um bei der Konstruktion und Validierung einer Zertifikatskette zu bestimmen, welche Prüfungen durchgeführt und welche Daten an den Client zurückgeliefert werden sollen. 5.4 Delegated Path Validation (DPV) Das Delegated Path Validation Protokoll [RFC 3379] erlaubt die Validierung von einem oder mehreren Zertifikaten zur Echtzeit, oder zu einer Zeit in der Vergangenheit. In Applikationen, in welchen eine minimale Latenzzeit kritisch ist, kann das Delegieren der ganzen Validierung an einen Server erhebliche Vorteile bringen. Die benötigte Zeit, um das zu überprüfende Zertifikat an einen Server zu senden, eine Antwort zu erhalten und diese zu authentisieren, kann wesentlich kürzer sein, als die Zeit, die für die Zertifikatskettenbildung und die Validierung benötigt wird. Sogar wenn eine Zertifikatskette von einem Client griffbereit ist, ist die benötigte Zeit für die Signaturüberprüfung jedes Zertifikates in der Kette in den meisten Fällen wesentlich grösser. Einen weiteren Beweggrund, die Validierung der Zertifikatskette an einen Server zu delegieren ist, dass mit dem Protokoll DPV das Management der Validation Policies zentralisiert werden kann. Auch Clients, welche die Validierung selbst ausführen, können sich auf einen DPV-Server verlassen, wenn zentralisiertes Management der Validierung Policies notwendig ist. Wenn ein Client diesen Validierungs-Service einsetzt, dann vertraut er dem Server gleich viel, wie seiner eigenen Validierungs-Software. Clients können die Validierung der Zertifikatsketten bestimmen, indem sie Validation Policies (Kapitel 5.6) einsetzen. Die Zertifikate, die validiert werden, müssen entweder direkt in der Anfrage enthalten sein oder entsprechend referenziert werden. Die DPV-Antwort muss einer von den folgenden Stati beinhalten: 1) Das Zertifikat ist gemäss den Validation Policies gültig 2) Das Zertifikat ist gemäss den Validation Policies ungültig 3) Die Gültigkeit des Zertifikates ist gemäss den Validation Policies unbekannt Falls das Zertifikat als ungültig erkannt wird, muss ein entsprechender Grund angegeben werden. Zum Beispiel: a) Der DPV Server kann keine Gültigkeit des Zertifikats ermitteln, weil keine Zertifikatskette aufgebaut werden konnte. b) Es konnte erfolgreich eine Zertifikatskette aufgebaut werden, aber diese ist gemäss dem Validation Algorithmus in RFC 3280 nicht gültig. c) Das Zertifikat ist zu dieser Zeit nicht gültig. Falls später nochmals eine Anfrage gemacht werden kann, ist möglicherweise das Zertifikat gültig. Dieser Zustand kann auftreten, wenn die Gültigkeitsperiode des Zertifikates noch nicht begonnen hat oder wenn ein Zertifikat suspendiert wurde. Damit ein Client sicher sein kann, dass die Zertifikatsvalidierung auch von dem erwarteten DPV- Server vorgenommen wird, müssen alle DPV-Antworten authentisiert sein, ausser es kommt eine Fehlermeldung zurück. 101

103 5.5 Delegated Path Discovery Das Delegated Path Discovery Protokoll [RCF 3379] ermittelt einen gültigen Zertifikatspfad und liefert dem Client auch noch alle relevanten Daten zu diesem Pfad. Diese Daten bestehen aus den Zertifikaten aller Knoten und den dazugehörigen Sperrinformationen. Mit Hilfe dieser Daten, kann der Client dann die Gültigkeit des Zertifikates selbst überprüfen, ohne erst aufwendig einen gültigen Pfad bestimmt zu haben. Ein Client hat also die Möglichkeit sich vom Server Zertifikate, CRLs und OCSP Responses zu beschaffen. Somit ist der Server, dem der Client vertraut, eine Art Sammelstelle. Wenn der Server nicht all diese Informationen sammeln könnte, so müsste sich der Client mittels LDAP, HTTP, FTP oder einem anderen Protokoll diese Informationen beschaffen. Weil die Zertifikate, CRLs und OCSP-Responses der Vertrauensstelle digital signiert sind, muss der Client dem Server nicht mehr vertrauen als den anderen Datenquellen (CRL und OCSP-Response), die diese Informationen bereitstellen. Clients können die Bildung des Zertifikatspfades steuern, indem sie Path Discovery Policies einsetzen. DPD hat somit einige Vorteile. Zum Beispiel kann eine einzige Anfrage gleich mehrere Anfragen ersetzen und das serverseitige Caching (Zwischenspeichern) kann die Latenzzeit reduzieren. Ein weiterer Vorteil für den Client ist, dass er keine weitere Software braucht, um diese Zertifikatskettenbildung zu implementieren. Bei einer Anfrage an den DPD-Server müssen die Clients spezifizieren, ob sie den Zertifikatspfad für ein End-Benutzerzertifikat, für ein CA Zertifikat oder für beide Zertifikatstypen haben wollen. Das heisst, es können zwei unterschiedliche Zertifikatspfade gebildet werden. Die DPD-Antworten müssen den Path Discovery Policies entsprechen und können folgenden Status haben: 1) Ein oder mehrere Zertifikatspfade wurden gefunden, die der Path Discovery Policy entsprechen. Zudem sind alle Revokationsinformationen vorhanden. 2) Ein oder mehrere Zertifikatspfade wurden gefunden, die der Path Discovery Policy entsprechen. Allerdings ist nur eine Teilmenge der Revokationsinformationen gefunden worden. 3) Ein oder mehrere Zertifikatspfade wurden gefunden, die der Path Discovery Policy entsprechen. Allerdings sind keine Revokationsinformationen gefunden worden. 4) Es wurde kein Zertifikatspfad gefunden, welcher der Path Discovery Policy entspricht. 5) Es konnte kein Zertifikatspfad konstruiert werden. Wenn keine Fehler detektiert wurden, beinhaltet die zurückkehrende Information eine oder mehrere Zertifikatspfade und falls gefordert wird auch die Revokationsinformation für jedes Zertifikat in der Zertifikatskette mitgeliefert. Die Antworten können authentisiert sein, falls man sicher sein möchte, dass die Informationen auch vom erwarteten DPD Server stammen. [38] 102

104 5.6 Validation Policies Eine Validation Policy [definiert in RFC 3379] spezifiziert die Regeln, die von einem SCVP Server eingesetzt werden müssen, wenn er ein Zertifikat validiert. In SCVP kann eine Validation Policy explizit ausgedrückt werden, in dem in der Anfrage bestimmte Parameter spezifiziert werden, die den Validierungsalgorithmus für die Zertifikatskettenbildung beeinflussen. Diese Parameter werden mit OIDs oder URLs ausgedrückt. Beide OIDs und URLs beinhalten Parameter, die für die komplette Validierung notwendig sind. Die per Default gesetzten Parameter umfassen folgendes: Das Zertifikat, das validiert werden soll Die Validierungszeit Ein Satz von "TrustAnchors" Ein Satz von Policies Policy Mapping Einstellungen any-policy Einstellungen und explizite Policy Einstellungen Der Validierungs-Algorithmus wird durch ein Abkommen zwischen dem Server und dem Client festgelegt und als ein OBJECT IDENTIFIER (OID) repräsentiert. Solche OIDs können von dem Client (applikationsspezifisch) und dem Server festgelegt werden. Damit eine Zertifikatskette als gültig erkannt werden kann, müssen die Validation Policy Bedingungen überprüft werden und übereinstimmen. Komponenten einer Validation Policy: Eine Validation Policy besteht aus drei Komponenten: 1. Vorgaben für die Zertifikatsketten 2. Vorgaben der Sperrinformationen 3. Vorgaben zu den End-Zertifikaten Zertifikatsketten Die Vorgaben für die Zertifikatskette bezeichnet eine Sequenz von trustanchors (z.b. Root CA) um dann die Validierung der Zertifikatskette nach RFC 3280 vorzunehmen. Statusüberprüfung Die Zertifikatsstatusprüfung ist ebenfalls ein Aspekt der Validierung von Zertifikatsketten. Zertifikats-Revokations-Abfragen können für ein End-Benutzer-Zertifikat und für ein CA- Zertifikat definiert werden. Die Revokations-Anforderungen für ein End-Benutzer Zertifikat und CA Zertifikate können unterschiedlich sein. Zum Beispiel ist eine OCSP-Response für ein End- Benutzer Zertifikat besser geeignet während CRLs für ein CA Zertifikat ausreichen. Die Validation Policy muss daher die Quelle der Sperrinformationen ebenfalls definieren. Es stehen fünf Alternativen zur Verfügung: 1. Full CRLs 2. OCSP Responses 3. Delta CRLs und die dazugehörige Base CRL 4. irgendeine verfügbare Sperrinformation 5. oder es wird keine Sperrinformation gebraucht End-Benutzer Zertifikatsanforderungen Die Validation Policy kann erfordern, dass das End-Benutzer-Zertifikat spezifische Extensions mit spezifischen Typen oder Werten enthalten muss. Dabei spielt es keine Rolle ob die Extensions als critical oder non-critical markiert sind. Eine Validation Policy kann zum Beispiel ein End-Benutzer- 103

105 Zertifikat erfordern, dass eine Elektronische -Adresse enthält (entweder in dem rfc822 subject alt name oder im adress naming Attribut in dem subject name). Path Discovery Policy Eine Path Discovery Policy ist ein Satz von Richtlinien, welche die Bildung von einem Zertifikatspfad bestimmen. Eine Path Discovery Policy ist eine Teilmenge von einer Validation Policy. Sie kann entweder eine Referenz auf eine Validation Policy haben oder selbst einige Elemente (z.b. trustanchors) der Validation Policy beinhalten. [37] 5.7 Protokollabläufe SCVP folgt wie OCSP dem einfachen Frage-Antwort-Modell. Der SCVP Client kreiert eine Anfrage (Request) und sendet diese an den SCVP Server. Der SCVP Server generiert dann eine Antwort (Response) und sendet diese zurück an den Client. Typischerweise verwendet SCVP das Protokoll HTTP aber es kann auch mit gebraucht werden. SCVP spezifiziert zwei Frage- Antwort Abläufe: 1. Der Client befragt den SCVP-Server nach unterstützten Validierungsrichtlinien (Validation Policy) - die Validierungsrichtlinie ist anwendungsspezifisch (S/MIME, IPsec, TLS) und gibt an, wie die Validierung erfolgen soll (Konfiguration des SCVP-Servers) - Der Server spezifiziert in der Antwort die unterstützten Richtlinien durch stellvertretende Objekt-IDs 2. Der Client beauftragt den SCVP-Server mit der (teilweisen) Validierung von Zertifikaten - Der Client sendet Zertifikats-IDs, durchzuführende Aktionen und Kontext-Informationen (soweit nicht durch die Sicherheitsrichtlinie vorgegeben) und spezifiziert, welche Informationen der Server liefern soll. - Der Client spezifiziert auch den Zeitpunkt, somit ist eine Prüfung eines Zertifikates in einem in der Vergangenheit liegenden Zeitpunkt möglich. - Der Server antwortet mit den geforderten, signierten Daten oder einer Fehlermeldung. [38a] 5.8 Abfragungsmöglichkeiten mit SCVP Was ich vom Server erhalten möchte (wantback). Dass heisst, der Typ der Zertifikatsüberprüfung (Aufbau einer Zertifikatskette mit oder ohne Validierung, mit oder ohne Statusprüfung) Sperrinformationen (CRL, OCSP-Response), die zur Statusüberprüfung verwendet werden sollen (referenzieren oder mitsenden) Intermediate Zertifikate, die für die Zertifikatskettenbildung eingesetzt werden sollen TrustAnchors, zu welchen die Zertifikatskette aufgebaut werden soll Validation Policies, die vom Server während der Validierung beachtet werden müssen Die Zeit, in welcher die Anfrage ausgeführt werden soll Überprüfung des Verwendungszwecks des Zertifikates Bildung von mehreren Zertifikatsketten für das gleiche Zertifikat 104

106 5.9 SCVP Use Cases Folgend werden die für uns wichtigsten Anwendungsfälle, die mit SCVP möglich sind veranschaulicht: [39] Use Case I Der einfachste Anwendungsfall demonstriert, wie ein Client eine Anfrage an den SCVP-Server stellt. Der Client sendet dem Server ein bestimmtes Zertifikat und verlangt, die Bildung einer Zertifikatskette. Die Validierung wird vom Client selbst durchgeführt. Die SCVP request/response Nachrichten sehen wie folgt aus: SCVP-Server SCVP Request { here is a target certificate: <certificate> Following checks should be performed: build certificate path I want back: certificate path } SCVP Response { here is a target certificate: <certificate> Reply checks: built a path or couldn t build a path Reply want backs: certificate path } SCVP-Client Abbildung 39: Use Case I Use Case II In diesem Anwendungsfall stellt der Client dem SCVP-Server eine Anfrage, in der er eine Zertifikatskette zu einem trustanchor (Root CA) bilden soll. In diesem Fall muss der SCVP-Server ein Zertifikatspfad bilden und ihn anschliessend validieren, um sicher zu sein, dass der Pfad in Ordnung ist. Diese Zertifikatskettenbidlung enthält keine Statusprüfung der Zertifikate. Das wantback Element ist wie im Anwendungsfall 1 "certificate path". Dies bedeutet, dass der Server eine Zertifikatskette (valid/not valid) zurücksendet. SCVP-Server SCVP Request { here is a target certificate: <certificate> Following checks should be performed: build a validated certificate path I want back: certificate path } SCVP Response { here is a target certificate: <certificate> Reply checks: Valid / Not Valid Reply want backs: certificate path } SCVP-Client Abbildung 40: Use Case II Use Case III Der Client verlangt in diesem Anwendungsfall die Bildung einer Zertifikatskette. Zusätzlich soll die Validierung und eine vollständige Statusüberprüfung vom SCVP-Server durchgeführt werden. Der Client will die Sperrinformation, die vom Server verwendet wurden (CRLs oder OCSP Response) und den einzelnen Status der Zertifikate abfragen (good, revoked). Das heisst, der Server sendet den einzelnen Zertifikatstatus sowie auch die benutzten Sperrinformationsquellen (CRL oder OCSP-Response) zum Client zurück. Die Anforderung, dass 105

107 der SCVP-Server die Sperrinformationsquellen mitschicken soll, kann für spätere Beweislast nützlich sein. Ansonsten ist diese Anforderung überflüssig, da sie eine unnötige Netzbelastung erzeugt. SCVP-Server SCVP Request { here is a target certificate: <certificate> Following checks should be performed: Perform full validation including revocation checking I want back: Status Indicator and Proof of revocation status for each certificate in path } SCVP Response { here is a target certificate: <certificate> Reply checks: Good, Revoked, Unknown, unavailable Reply want backs: Status Indicator: valid /not valid - Set of revocation info (CRL/OCSPs) } SCVP-Client Abbildung 41: Use Case III Use Case IV 4. In diesem Anwendungsfall kann ein Client das Zertifikat nicht selbst parsen. Der Client sendet daher das abzufragende Zertifikat an den SCVP Server und erfordert eine vollständige Validierung inkl. Statusüberprüfung. Dass heisst, der Client will eine Bestätigung, dass der Public Key auch wirklich zu dem identifizierten Namen gehört, der im Zertifikat steht. Weiter möchte der Client wissen, ob der Public Key zu dem beabsichtigten Zweck auch eingesetzt werden kann. Der SCVP Server sendet den Public Key Wert des angefragten Zertifikats zurück, dass erfolgreich validiert werden konnte. SCVP-Server SCVP Request { here is a target certificate: <certificate> Following checks should be performed: Perform full validation including revocation checking I want back: Status Indicator and Public Key Value } SCVP-Client SCVP Response { here is a target certificate: <certificate> Reply checks: Good, Revoked, Unknown, unavailable Reply want backs: Status Indicator: valid / not valid - Public key value field obtained from a valid target certificate } Abbildung 42: Use Case IV 106

108 5.10 Sicherheitsüberlegungen Ein Client, der einer Antwort von einem SCVP-Server vertraut, vertraut dem Server gleich viel, wie seiner eigenen Gültigkeitsprüfungs-Software. Das bedeutet, dass wenn ein Hacker einen vertrauten Server kompromittiert, kann er den Validationsprozess für jeden Client, der diesem Server vertraut, verfälschen. Daher muss ein SCVP Server genau so geschützt werden wie die Root CA, dem der SCVP Server vertraut. Die Clients müssen das requestref-element in der Antwort überprüfen und versichern, dass es mit der Original-Nachricht übereinstimmt. Mit dem requestref-element kann kontrolliert werden, wie der Server die entsprechende Anfrage identifiziert (Kapitel ). Anfragen beinhalten eine Vielzahl an Informationen, welche die Antworten des Servers beeinflussen. Aus diesem Grund ist die Überprüfung der Antwort des Servers so wichtig. Wenn eine SCVP Antwort (um die Gültigkeit eines Zertifikates zu ermitteln) signiert wurde, muss der Client die Signatur der erhaltenen Antwort überprüfen, um sicher zu sein, dass die Antwort auch von dem erwarteten SCVP-Server kommt. Wenn der Client die Signatur nicht prüft, kann eine man-in-the-midddle Attacke den Client austricksen und ihn zum Glauben bringen, dass die Antwort von dem richtigen SCVP Server stammt. Falls der Server keine Autorisierung, wie zum Beispiel eine signierte Anfrage erfordert, kann ein Angreifer den Server missbrauchen und willkürliche Anfragen stellen. Die Antworten können dem Hacker wertvolle Daten geben, wie zum Beispiel über Schwächen des Servers oder über die Pünktlichkeit der Überprüfung des Servers. Diese Informationen können dann für zukünftige Server Attacken genutzt werden. Wenn der Client kein requestnonce Element (Kapitel xy) in die Anfrage packt, oder wenn er nicht prüft ob die requestnonce der Antwort mit der requestnonce in der Anfrage übereinstimmt, kann ein Angreifer auch die vorhergehenden Antworten des Servers zurückgeben. Wenn der Server die servercontextinformation braucht um Server-Statusinformationen aufzuzeigen, müssen angemessene Methoden implementiert werden um allfällige Denial of Service Attacken (DOS) zu vermeiden. Die Anfrage- und Antworten-Policies, die vom Server unterstützt werden, sind nicht signiert. Dies kann eine man-in-the-middle-attacke zulassen, welche eine andere Validations-Policy vortäuscht. Das kann die Folge haben, dass die Anfrage des Clients auf einer Policy basiert, die vom Server nicht unterstützt wird und der Client allenfalls eine weniger sichere Policy in seiner Anfrage definieren muss SCVP Server Relay In manchen Netzwerkumgebungen, zum Beispiel mit Firewalls, ist es möglich, dass ein Server nicht alle geforderten Informationen zur Verfügung stellen kann. Der Server kann daher so konfiguriert werden, dass er auch andere SCVP Services von anderen SCVP Servern verwenden kann, um die Anfrage zu erfüllen. Der SCVP Server, der die Anfrage erhalten hat agiert in einem solchen Fall ebenfalls als Client. Im Gegensatz zum Original-Client braucht der SCVP Server angemessene Rechenleistung und Speicher. 107

109 5.12 SCVP Struktur SCVP Request Ein SCVP-Client Request muss als single CVRequest definiert sein. Wenn ein SCVPRequest in einem Teil des MIME Body verkapselt ist, so müssen Applikationen cv-requests einsetzen. Es gibt zwei Arten von SVC Requests: unsigned und signed. Eine signierte Anfrage wird für die Authentisierung des Clients gegenüber dem Server gebraucht. Ein Server kann erfordern, dass nur signierte Anfragen zugelassen werden. Ein Server kann aber auch unsignierte Anfragen zulassen. Somit sollte ein SCVP Client signierte Anfragen und Antworten unterstützen können. Die Client-Anfrage an den SVCP-Server muss eindeutig sein. Der Client sollte deshalb das signierte Zertifikat in die Anfrage einbeziehen. Er kann das Zertifikat auch nur referenzieren, um die Grösse der Anfrage zu reduzieren. [36] Folgend die Syntax eines CVRequests: ASN.1-Definition CVRequest ::= SEQUENCE { scvpversion INTEGER, query Query, requestor [0] OCTET STRING OPTIONAL, requestnonce [1] OCTET STRING OPTIONAL, reqextensions [2] Extensions OPTIONAL } scvpversion Die scvpversion zeigt die eingesetzte SCVP Version an. Der Integer Wert muss 1 sein. Weitere zukünftige Updates können dann einen anderen Integer Wert spezifizieren Query Die Query spezifiziert ein oder mehrere Zertifikate, die Objekte des Requests sind. (Es können Public Key Zertifikate oder Attribut Zertifikate sein). Eine Query muss ein oder mehrere Zertifikatsreferenzen, checks und wantback Einheiten enthalten; und eine Query kann auch valpolicy, validitytime, trustanchors, immediatecerts, revinfos und queryextensions beinhalten. Eine Query muss folgende Syntax haben: ASN.1-Definition Query ::= SEQUENCE { queridcerts checks wantback validationalg requestrefhash SEQUENCE SIZE (1 MAX) OF CertReference, CertChecks, WantBack, ValidationAlg, BOOLEAN DEFAULT TRUE, fullpolresponse [0] BOOLEAN DEFAULT FALSE, inhibitpolmap [1] BOOLEAN DEFAULT FALSE, requireexplicitpol [2] BOOLEAN DEFAULT FALSE, ignoreanypol [3] BOOLEAN DEFAULT FALSE, IsCA [4] BOOLEAN DEFAULT FALSE, SignResponse [5] BOOLEAN DEFAULT TRUE, servercontextinfo [6] OCTET STRING OPTIONAL, 108

110 validitytime [7] GeneralizedTime OPTIONAL, trustanchors [8] TrustAnchors OPTIONAL, intermidiatecerts [9] CertBundle OPTIONAL, revinfos [10] RevocationInfos OPTIONAL, keyusage [11] KeyUsage OPTIONAL, extendedkeyusage [12] ExtKeyUsageSyntax OPTIONAL, queryextensions [13] Extensions OPTIONAL, produceat [14] GeneralizedTime OPTIONAL, validationolref [15] ValidationPolRef OPTIONAL} Diese Liste der Zertifikatsreferenzen zeigt dem Server für welches Zertifikat ein Client Informationen will. Die OPTIONALEN servercontextinfo sagen dem Server, dass evt. noch weitere Informationen gewünscht sind. OPTIONAL ValidityTime sagt dem Server an welchem Datum und zur welcher Zeit er die Zertifikatsprüfung durchführen soll. Die OPTIONALEN valpolicy, trustanchors, intermediatecerts und revinfos bieten zusätzliche Informationen für eine Client Anfrage. OPTIONAL queryextensions ist für zukünftige Erweiterungen der Query Syntax vorgesehen. queridcerts Das queriedcerts, das den CertReference Typ braucht, identifiziert den Zertifikatstyp einer Anfrage. Das Zertifikat kann ein Public Key-Zertifikat oder ein Attribut-Zertifikat sein. checks Mit checks kann ein Client die gewünschte Überprüfungsart definieren. Die checks-einheiten müssen Object Identifiers (OIDs) enthalten. Jede OID sagt dem SVCP Server, was für eine Überprüfung der Client erfordert. Der Server muss alle OIDs erfüllen oder sonst eine Fehlermeldung zurückgeben. ASN.1-Definition CertChecks ::= SEQUENCE SIZE (1 MAX) OF OBJECT IDENTIFIER Mögliche OIDs für Public Key Zertifikate: - Aufbau einer Zertifikatskette zu einer vertrauten Root - Aufbau einer validierten Zertifikatskette zu einer vertrauten Root - Prüfe den Status der Zertifikate in der Zertifikatskette Mögliche OIDs für Attribut Zertifikate - Aufbau einer Zertifikatskette zu einer vertrauten Root für ein Attribut Zertifikats- Herausgeber - Aufbau einer valdierten Zertifikatskette zu einer vertrauten Root für ein Attribut Zertifikats- Herausgeber - Prüfe den Status des Zertifikates in der Zertifikatskette für den Attribut Zertifikats- Herausgeber - Prüfe den Status des Zertifikates in der Zertifikatskette für den Attribut Zertifikats- Herausgeber und für das Attribut Zertifikat selbst. ASN.1-Definition d-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } id-stc-build-status-checked-pkc-path OBJECT IDENTIFIER ::= { id-stc 3 } 109

111 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } id-stc-build-status-checked-aa-path OBJECT IDENTIFIER ::= { id-stc 6 } id-stc-status-check-ac-and-build-status-checked-aa-path OBJECT IDENTIFIER ::= { id-stc 7 } wantback Beschreibt die Art der Information, die der Client vom SCVP Server anfordert. Das wantback Element muss ebenfalls eine Sequenz von OIDs enthalten. Eine Anfrage kann zum Beispiel ein checks Element enthalten, das nur eine Konstruktion einer Zertifikatskette spezifiziert. Das wantback Element erfordert dann die Zertifikatskette. In diesem Fall wird die Antwort keine Validierung der Zertifikatskette enthalten sondern nur eine Zertifikatskette, die der SCVP als gültig betrachtet. Ein Client, der die Validierung selber machen möchte, sollte diese Form der Anfrage benützen. Als Alternative kann mit dem wantback Element der Server aufgefordert werden, dass er eine Zertifikatskette konstruiert und validiert und zudem auch eine Zertifikatsstatusprüfung durchführen soll. Eine wantback-antwort enthält somit den Status einer Zertifikatskette oder eines einzelnen Zertifikates. RequestRefHash Kontrolliert, wie der Server die entsprechende Anfrage identifiziert. Per Default fügt der Server einen Hashwert der Antwort bei. Falls der Client will, dass der Server seine Anfrage zur Antwort hinzufügt, so muss das RequestRefHash auf FALSE gesetzt werden. Ein Grund für diesen Prozess ist, wenn man die Anfrage und die Antwort archivieren möchte. fullpolresponse Kontrolliert, ob der Server die Antwort-Werte der vollen Validierungs-Policy enthält. Die Antwort beinhaltet per Default nur Referenzen zu allen relevanten Datenelementen, welche für die volle Validierung gebraucht werden. Falls der Client will, dass die Validation Policy in der Server CVResponse beinhaltet ist, so muss das fullpolresponse Element auf TRUE gesetzt werden. Dieser Prozess wird ebenfalls für die Archivierung der Anfrage und der Antwort gebraucht. inhibitpolmap Spezifiziert einen Input zum Zertifikatsketten-Validierungs-Algorithmus und kontrolliert, ob das Policy mapping erlaubt ist. Wenn ein Client das Policy mapping nicht erlauben möchte, muss das inhibitpolmap Element auf TRUE gesetzt werden. requireexplicitpol Spezifiziert einen Input zum Zertifikatsketten-Validierungs-Algorithmus und kontrolliert, ob mindestens eine gültige Policy in den Zertifikats Policies Extensions enthalten ist. Per Default akzeptiert der Server, dass keine Policies in den Extensions vorhanden sind. Falls der Client will, dass der Server mindestens eine gültige Policy anfordert, muss das requireeyplicitpol Element in der Anfrage auf TRUE gesetzt werden. ignoreanypol Spezifiziert einen Input zum Zertifikatsketten-Validierungs-Algorithmus und kontrolliert, ob die any-policy OID ausgeführt oder ignoriert wurde. Falls ein Client die any-policy OID ignorieren möchte, so muss das ignoreanypol-element auf TRUE gesetzt werden. Per Default ist das ignoreanypol auf FALSE gesetzt, was bedeutet, dass der Server die Any-Policy-OID verarbeitet. 110

112 isca Spezifiziert, ob ein Client ein CA Zertifikat erwartet. Falls der Client ein CA Zertifikat erwartet, muss der Wert des isca Elementes auf TRUE gesetzt werden. signresponse Spezifiziert, ob der Client den Server auffordert seine Antwort zu signieren. Falls der Client eine volle Zertifikatsketten-Validierung anfordert und nicht um die Authentizität der Datenquelle besorgt ist, nützt die signierte Antwort jedoch nichts und die Signatur via signresponse wird unwichtig. SCVP-Clients, die Delegated Path Discovery (DPD) unterstützen, müssen den Wert auf TRUE setzen. Da Delegated Path Validation (DPV) Antworten auf jeden Fall signiert sind, müssen DPV Clients signresponse nicht unterstützen. SVCP Server sollten deshalb auch unsignierte Antworten zulassen. servercontextinfo Dieses Element enthält den Kontext von vorherigen Anfragen bzw. Antworten zum selben SCVP Server und erlaubt einem Server mehrere Zertifizierungsketten für das gleiche Zertifikat zurückzugeben. Zum Beispiel, wenn ein Server eine bestimmte Zertifikatskette erstellt, aber der Client dies nicht akzeptiert, so kann der Client dieselbe Anfrage dem Server zurücksenden mit dem servercontextinfo-element der ersten Antwort. Der Server wird dann eine andere Zertifikatskette, falls er eine andere findet, zurückgeben. validationalg Dieses Element definiert den Validations-Algorithmus, der vom SCVP Server eingesetzt wird. Der Wert dieses Elements kann durch eine Vereinbarung zwischen dem Client und dem Server bestimmt werden und wird als OID präsentiert. ASN.1-Definition ValidationAlg ::= SEQUENCE { valalgid OBJECT IDENTIFIER, parameters ANY DEFINED BY valalgid OPTIONAL } Default Validation Algorithmus Der Client kann den Default Algorithmus des Servers einsetzen oder einen anderen Algorithmus definieren. Der OID des Default Algorithmus lautet wie folgt: ASN.1-Definition id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } d-svp-defaultvalalg OBJECT IDENTIFIER ::= { id-svp 1 } SCVP Server und Clients müssen diesen Default Algorithmus unterstützen. Sie können aber auch andere Validierungsalgorithmen einsetzen. Die Bedeutung des Default Algorithmus ist: - "Trust Anchors" (CA Zertifikate) werden von dem trustanchor-element kommen. Falls kein Zertifikat im trustanchor-element spezifiziert ist, dann wird der SCVP Server seine eigenen "trustanchors" wählen. - Die zulässige Policy wird vom certpolicies-element in Verbindung mit dem selektierten "trustanchor" kommen. Falls keine Zertifikats-Policy in dem certpolicies-element spezifiziert wurde, wird der SCVP Server eine "any-policy" einsetzen. 111

113 - Der SCVP Server wird die Zertifikats-Statusüberprüfung machen in dem er CRLs, Delta CRLs oder OCSP Responses oder eine andere Quelle mit Sperrinformationen, die zur Verfügung stehen, einsetzt. Unter anderem gibt es noch dem Name Validation Algorithmus, der im Internet Draft "draft-ietfpkix-scvp-15.txt" vom Juli 2004 nachgelesen werden kann. validitytime Bestimmt das Datum und die Zeit, in welcher ein SCVP Client den SCVP Server auffordert eine Anfrage auszuführen. Das heisst, ein Zertifikat kann zum Beispiel zu einem vorhergehenden Datum auf den Status geprüft werden. Falls kein validitytime-element spezifiziert ist, muss der Server die Prüfung mit dem Datum und der Zeit durchführen, an welchem die Anfrage gestellt wurde. Die validitytime muss eine rückblickende Zeit sein, weil der Server nur eine Validierung durchführen kann, wenn er die aktuelle oder vorhergehende Zeit gebraucht. Die validitytime kann von einem Server ignoriert werden, wenn die Zeit innerhalb der clock skew (Zeit-Toleranz) der aktuellen Serverzeit liegt. trustanchors Spezifiziert den Vertrauensanker (Root oder CA Zertifikat), der von dem SCVP Server gebraucht wird. Es können mehrere Zertifikatspolicies mit dem Vertrauensanker assoziiert werden. Falls ein trustanchor-element vorliegt, darf der Server nicht beliebige Zertifikatsketten-trustAnchor gebrauchen sondern nur diesen, die in den Policies stehen. Jedes CA-Zertifikat kann als trustanchor eingesetzt werden. Der Client kann dadurch sagen, dass er nur dieser speziellen Root CA vertraut. Falls die Zertifikatskette zu einem anderen trustanchor führt, als vom Client angefordert, kommt eine Fehlermeldung zurück. Der TrustAnchor Typ enthält ein oder mehrere trustanchor-spezifikationen. Es kann eine Referenz für die Identifizierung des trustanchors angegeben werden. Als Alternative können trustanchors auch direkt mit gesendet werden. Die Reihenfolge der mit gesendeten trustanchors spielt keine Rolle. ASN.1-Definition TrustAnchors : := SEQUENCE SIZE (1..MAX) OF TrustAnchor TrustAnchor ::= SEQUENCE { anchor PKCReference, certpolicies [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL } -- if absent, use any-policy Das optionale certpolicies-element spezifiziert eine Liste von Policy Identifiers, die ein SCVP Server bei einer Validierung einzusetzen hat. Falls dieses Element nicht definiert ist, muss anypolicy vom SCVP verwendet werden. intermediatecerts Erlaubt einem Client, alle Root und intermediate Zertifikate (d.h. CAs, die von einer Root ausgestellt wurden und dann selbst weiter intermediate CAs oder End Entity Zertifikate ausstellen) mitzuschicken. Der Server muss diese dann beim Pathbuilding berücksichtigen. Dass heisst, ein SCVP Client kann praktisch ohne eigene Intelligenz erstellt werden, indem er einfach alles an den Server delegiert und ihm dazu nebst dem zu prüfenden Zertifikat und dessen Verwendungszweck auch seine akzeptierten Root und Intermediate Certs mitschickt. Das Element intermediatecerts muss mindestens ein Zertifikat enthalten und als CertBundle strukturiert sein. Das Zertifikat im intermediatecerts-element darf vom Server nicht als gültig betrachtet werden, nur weil es in diesem Element enthalten ist, sondern muss zusätzlich noch geprüft werden. 112

114 Der CertBundle Typ beinhaltet ein oder mehrere Zertifikatsreferenzen. Die Reihenfolge spielt dabei keine Rolle. ASN.1-Definition CertBundle ::= SEQUENCE SIZE (1 MAX) of PKCReference revinfos Spezifiziert die Sperrinformation wie zum Beispiel CRLs, Delta CRLs und OCSP Antworten, die der Client definiert und mit der Anfrage mitsenden kann. Der SCVP Server darf dann zum Beispiel nur diesen bestimmten OCSP-Responder einsetzen, weil der SCVP Client nur diesem OCSP Responder vertraut. Es kann aber vorkommen, dass der Server die angegebene Revokationsinformation nicht einsetzt. Zum Beispiel, wenn die angegebenen Revokationsinformation nicht in Verbindung mit den Zertifikaten in der Zertifikatskette gebracht werden können. Es ist von Vorteil, wenn der SCVP Server CRLs und Delta CRLs trennt. CRLs, Delta CRLs und OCSP Antworten können als Sperrinformationen angegeben werden. Falls nötig, können weitere OIDs für evt. weitere in Zukunft gebrauchte Sperrinformationstypen assoziiert werden. ASN.1-Definition RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo RevocationInfo ::= CHOICE { crl [0] CertificateList, delta-crl [1] CertificateList, ocsp [2] OCSPResponse, other [3] OtherRevInfo } OtherRevInfo ::= SEQUENCE { ritype OBJECT IDENTIFIER, rivalue ANY DEFINED BY ritype } keyusage Definiert den technischen Zweck (z. B. Entschlüsselung, Signatur, Zertifikatssignierung) des Schlüssel, der im Zertifikat enthalten ist. Der Client kann sich mit diesem Element den technischen Zweck eines Schlüssels vom Server bestätigen lassen. Zum Beispiel wenn ein Client ein Zertifikat mit einer digitalen Signatur erhält, kann der Gebrauch bestätigt werden, indem beim keyusage Element das Bit für die digitale Signatur gesetzt wird. extendedkeyusage Definiert zusätzliche Zwecke zum KeyUsage Extension. Der Client kann zum Beispiel den SCVP Server auffordern, dass er überprüft, ob das Zertifikat im Kontext mit einem TLS Server verwendet werden kann. queryextensions Jede Extension in diesem Element erweitert die Abfrage und wird evt. für spätere Spezifikationen des SCVP-Protokolls gebraucht. producedat Falls der Client dem SCVP Server erlaubt eine zwischengespeicherte Antwort einzusetzen, sagt das producedat Element das Datum und die Zeit, zu welcher die Antwort erzeugt werden muss. validationpolref Der Client und der Server können Parameter vereinbaren, welche eine vollständige oder partitionierte Validation-Policy definieren. Falls die Policy alle nötigen Parameter für einen SCVP- 113

115 Request definiert, braucht sich der Client nur die Zertifikate, die geprüft werden und die referenzierte Policy in der Anfrage zu beschaffen. Stimmen nur einige Parameter überein, muss sich der Client eine Referenz auf die Policy und alle nötigen Parameter selbst beschaffen, die für einen vollständiger Request erforderlich sind. Die Referenz auf die Validation-Policy kann entweder eine OID, die vom Server und dem Client vereinbart wurden, oder eine URI sein. Der Server muss einen binären Vergleich zwischen der referenzierten Policy in der Anfrage und den konfigurierten Policies durchführen. Falls Konflikte zwischen der referenzierten Policy in der Anfrage und den gelieferten Werten in dem Request bestehen, muss der Server eine Fehlermeldung zurückliefern. ASN.1-Definition ValidationPolRef ::= CHOICE { valpolrefbyoid [0] OBJECT IDENTIFIER, valpolrefbyuri [1] IA5String} Requestor Ist eine lokale Referenz um eine Anfrage anzufordern. Der Wert hat nur eine lokale Bedeutung zum Client. Das heisst, dass nur der Anfordernde (Client) diese Information versteht. Wenn der SCVP Client einen requestor-wert in seiner Anfrage beinhaltet, muss der SCVP Server den gleichen Wert in einer einzigen und eindeutigen Server-Antwort zurücksenden. Der SCVP Server kann den requestor-wert in einer zwischengespeicherten Antwort weglassen Das requestor-element muss ein 8Bit String sein. Es bestehen aber keine Vorschriften, dass dieser String einmalig sein muss. Der String darf aber nicht Null sein. requestnonce Dieses Element enthält einen Request-Identifikator, der vom SCVP-Client generiert wird. Falls die Anfrage des Clients einen requestnonce-wert enthält, drückt dies eine Präferenz aus, dass der SCVP Server eine spezifizierte Antwort zurückgeben soll. Wenn der Server eine spezifizierte Antwort zurückgibt, muss diese das requestnonce-element der Anfrage wieder enthalten. Der Server kann aber eine erfolgreiche zwischengespeicherte Antwort zurückgeben. Diese darf dann aber keine requestnonce enthalten. Der Client darf keine wantback (id-swb-unique-resprequired) ohne requestnonce erfordern. Falls der Server aber trotzdem eine solche Antwort erhält, so sollte er eine Fehlermeldung "invalidrequest" zurückgeben. Das requestnonce-element muss ein 8Bit String sein, der exklusiv für diesen Zweck generiert wurde. reqextensions Das reqextensions-element enthält, wie der Name schon sagt, Extensions. Diese Spezifikation definiert bis heute noch keine Extensions. Es kann aber für evt. spätere Entwicklungen des SCVP Protokolls gebraucht werden. Wie in CRL und OCSP können die Extensions als kritisch (TRUE) oder unkritisch (FALSE) definiert werden. Ein SCVP Server muss eine Anfrage abweisen, wenn diese kritische Extensions enthält aber nicht verstanden werden können. Unkritische Extensions können einfach ignoriert werden Validation Response Eine SCVP Server Antwort muss als single CVResponse Element definiert sein. Ein solches CVResponse Element wird im MIME Body übertragen. 114

116 Es gibt drei Formen von SCVP Antworten: 1. Eine erfolgreiche Antwort, in welcher das SignResponse-Element auf FALSE gesetzt ist. Die Antwort kann vom Server signiert sein. 2. Alle anderen erfolgreichen Antworten müssen vom Server signiert werden. Wenn der Server unfähig ist, eine erfolgreiche signierte Antwort zurückzusenden, muss er eine Fehlermeldung zurückgeben. 3. Fehlermeldungen. Diese müssen vom Server nicht signiert werden. Alle SCVP Server müssen signeddata unterstützen und sollten auch authenticateddate für signierte Anfragen und Antworten unterstützen. Falls der Server eine erfolgreiche signierte Antwort zu einer signierten Anfrage zurückgibt, so muss der Server denselben Signatur-Typ verwenden wie in der Anfrage. Die CVResponse ist entweder in SignedData oder in AuthenticatedData eingekapselt. Folgend ein Beispiel für eine signierte Antwort: ASN.1-Definition ContentInfo { contenttype id-signeddata, -- ( ) content SignedData } SignedData { version digestalgorithms encapcontentinfo certificates crls signerinfos CMSVersion, DigestAlgorithmIdentifiers, EncapsulatedContentInfo, CertificateSet, -- MUST include server cert CertificateRevocationLists, -- Optional SET OF SignerInfos } -- Only one in SCVP SignerInfo { version CMSVersion, sid SignerIdentifier, digestalgorithm DigestAlgorithmIdentifier, signedattrs SignedAttributes, -- (Required) signaturealgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedattrs UnsignedAttributes } -- Not used in SCVP EncapsulatedContentInfo { econtenttype id-ct-scvp-psresponse, -- ( ) econtent OCTET STRING } -- Contains CVResponse AuthenticatedData Example: ContentInfo { contenttype id-ct-authdata, -- ( ) content AuthenticatedData } AuthenticatedData ::= SEQUENCE { version CMSVersion, originatorinfo OriginatorInfo, -- Optional recipientinfos RecipientInfos, -- Only for SCVP client 115

117 macalgorithm digestalgorithm encapcontentinfo authattrs mac unauthattrs MessageAuthenticationCodeAlgorithm, DigestAlgorithmIdentifier, -- Optional EncapsulatedContentInfo, AuthAttributes, -- Required MessageAuthenticationCode, UnauthAttributes } -- Not used in SCVP EncapsulatedContentInfo { econtenttype id-ct-scvp-psresponse, -- ( ) econtent OCTET STRING } -- Contains CVResponse Der SCVP Server muss sein eigenes Zertifikat im Zertifikatsfeld innerhalb von SignedData beinhalten. Innerhalb von AuthenicatedData muss das Server-Zertifikat sein, wenn der HMAC (Keyed-Hashing for Message Authentication) von dem benützten Public Key eines Zertifikates abgeleitet wurde. Es können auch andere Zertifikate enthalten sein und der SCVP Server kann mehr als eine CRL im Feld crls bereitstellen. Das signedattr innerhalb von SignerInfo muss den content-type und das message-digest Attribut beinhalten. Innerhalb des SigningCertificate-Attributes, muss das erste identifizierte Zertifikat ein SCVP Server Zertifikat sein. Die Einfügung von anderen Zertifikaten innerhalb von SigningCertificate ist optional. Die Einfügung von Policies in dem SigningCertificate-Attribut ist ebenfalls optional. Das CVResponse Element enthält die Server-Antwort. Die Antwort muss das scvpversion, producedat, responsestatus und das requestref Element enthalten. Die Antwort kann auch den requestor, replyobjects, requestnonce, ServerContextInfo und respextensions-elemente enthalten. Das replyobjects Element muss für jedes Zertifikat, das angefragt wird, exakt ein CertReply Element enthalten. Das requestor- und responser-element müssen in der Antwort enthalten sein, wenn die Anfrage ein requestor-element enthält. Ebenfalls muss das requestnonce-element in der Antwort enthalten sein, wenn in der Anfrage dieses Element enthalten ist. Die Antwort muss daher folgende Syntax haben: ASN.1-Definition Die CVResponse muss folgende Syntax aufweisen: CVResponse ::= SEQUENCE { scvpversion INTEGER, policyid INTEGER, producedat GeneralizedTime, responsestatus ResponseStatus, requestref RequestReference, requestor [1] OCTET STRING OPTIONAL, responder [2] OCTET STRING OPTIONAL, replyobjects [3] ReplyObjects OPTIONAL, requestnonce [4] OCTET STRING OPTIONAL, servercontextinfo [5] OCTET STRING OPTIONAL, valpolresponse [6] ValPolicy OPTIONAL, validationpolref policyid Siehe Kapitel 5.13 [7] ValidationPolicyRef OPTIONAL respextensions [8] Extensions OPTIONAL } 116

118 producedca Das producedca-element sagt zur welcher Zeit und an welchem Datum die Antwort vom Server generiert wurde. responsestatus Gibt dem Client Statusinformationen über seine Anfrage. Folgend ein Beispiel: ASN.1-Definition ResponseStatus ::= SEQUENCE { statuscode SCVPStatusCode, errormessage [0] UTF8String OPTIONAL } SCVPStatusCode ::= ENUMERATED { okay (0), skipunrecognizeditems (1), toobusy (10), invalidrequest (11), internalerror (12), badstructure (20), unsupportedversion (21), abortunrecognizeditems (22), unrecognizedsigkey (23), badsignature (24), unabletodecode (25), notauthorized (26), unsupportedchecks (27), unsupportedwantbacks (28), unsupportedsignature (29), invalidsignature (30), relayingloop (40), fullrequestrefunsuported (51}, fullpolrequestunsuported (52), inhibitpolmapunsuported (53), requireexppolunsuported (54), ignoreanypolunsuported (55), validitytimeunsuported (56) } Bedeutung der Zahlen: 0. The request was fully processed 1. The request included some unrecognized items; however, pocessing was able to continue ignoring them 10. Too busy; try again later 11. The server was able to decode the request but there was some oher problem with the request 12. Internal server error occurred 13. The structure of the request was wrong 14. The version of request is not supported by this server 15. The request included unrecognized items, and the server was not able to continue processing 16. The key given in the RequestSignature is not recognized 17. The signature or MAC did not match the body of the request 18. The encoding was not understood 19. The request was not authorized 20. The request included unsupported checks items, and the server was not able to continue processing 117

119 21. he request included unsupported want back items, and the erver was not able to continue processing 22. The server does not support the signature or MAC algorithm used by the client to sign the request 23. The server could not validate the client's signature or MAC on the request 24. he request was previously relayed by the same server 25. he request contained an unrecognized validation algorithm 26. he server does not returning the full request in the esponse 27. he server does not returning the full policy response 28. he server does not support inhibiting policy mapping 29. he server does not support requiring explicit policy 30. he server does not support ignoring the any policy OID 31. he server only validates requests using current time Die Statuscodes 0-9 sind für die Prozesse, die vom Server ausgeführt werden reserviert. Diese Antworten, müssen signiert zum Client gesendet werden. Die Statuscodes müssen nicht mit einer signierten Antwort zurückgesendet werden. requestreference Dieses Element erlaubt dem SCVP-Server die Anfrage des Clients zu identifizieren. Der Server bringt seine Antwort mit der Anfrage in Verbindung, indem er entweder den Hashwert der Anfrage oder eine Kopie des CVRequest der Anfrage nutzt. Das requestref-element ermittelt keine Authentifizierung, aber zeigt dem Client, dass die Antwort nicht modifiziert wurde. Das requestref-element erlaubt den Clients einen Antwort mit ihrer Anfrage in Verbindung zu bringen. Das requestnonce-element ist eine alternative Methode um Anfragen und Antworten auf Übereinstimmung zu prüfen, falls der Client fullresponse selektiert hat. Wenn die fullrequest-alternative eingesetzt wird, liefert die Antwort eine Datenstruktur, die für die Archivierung der Transaktionen geeignet ist. SCVP-Server müssen einen requesthash einsetzen und sollten auch fullrequest unterstützen. SCVP Clients müssen ebenfalls requesthash unterstützen. Die fullrequest-unterstützung ist zu empfehlen. requesthash Dieses Element ist der Hash des CVRequests. Per Default wird SHA-1 eingesetzt aber es können auch andere eingesetzt werden. RequestHash dient zwei Zwecken: Erstens erlaubt es dem Client zu überprüfen, ob die Antwort nicht modifiziert wurde. Zweitens erlaubt es dem Client die Antworten mit seinen Anfragen in Verbindung zu bringen. ASN.1-Definition HashValue ::= SEQUENCE { algorithm AlgorithmIdentifier DEFAULT { sha-1 }, value OCTET STRING } sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } fullrequest Wie mit requesthash, kann ein Client auch mit dem fullrequest prüfen, ob eine Antwort modifiziert wurde. Es bietet ebenfalls eine single Datenstruktur, die für die Archivierung der Transaktionen geeignet ist. 118

120 Requestor Dieses optionale Element wird gebraucht, um den Anfordernden (Client) zu identifizieren. Der Wert hat nur lokale Aussagekraft zum Anfordernden. Falls der SCVP Client einen requestor-wert in der Anfrage setzt, dann muss der SCVP Server bei einer Antwort den gleichen Wert zurücksenden. Das request-element muss ein 8Bit String sein. responder Dieses optionale Element wird gebraucht um den Server zu identifizieren. Der Wert hat nur lokale Aussagekraft zum SCVP-Server. Das responder-element muss mit der Antwort zurückkommen, wenn die Anfrage ein solches Element enthält. Das responder-element muss ein 8Bit String sein. replyobject Dieses Element gibt vom SCVP-Client angeforderte Objekte zurück. Das replyobjects-element muss immer in der Antwort enthalten sein, ausser wenn ein Fehler raportiert wird. Das CertReply-Element muss die Element cert, replystatus, replyvaltime, replychecks, replywantback und valpolicy enthalten. Weiter können im CertReply-Element auch die optionalen Elemente nextupdate und certreplyextensions enthalten sein. Das Element checks in der Anfrage bestimmt den Inhalt des replychecks-element in der Antwort. Das wantback-element in der Anfrage bestimmt den Inhalt des replywantbacks- Element in der Antwort. Das queryextensions-element in der Anfrage kontrolliert die An- oder Abwesenheit und Inhalt des certreplyextensions-element in der Antwort. Das ReplyObjectes Element verwendet folgende Syntax: ASN.1-Definition replyobjects ::= SEQUENCE SIZE (1..MAX) OF CertReply CertReply ::= SEQUENCE { cert CertReference, replystatus ReplyStatus, replyvaltime GeneralizedTime, replychecks ReplyChecks, replywantbacks ReplyWantBacks, valalg ValidationAlg, nextupdate [1] GeneralizedTime OPTIONAL, certreplyextensions 2] Extensions OPTIONAL } cert Dieses Element enthält entweder das Public Key-Zertifikat, ein Attribut-Zertifikat oder eine Referenz auf ein Zertifikat, mit welchem der Client eine Anfrage anfordert. replystatus Das Element replystatus gibt Statusinformationen über ein spezifisches Zertifikat, das vom Client angefragt wurde zurück. Der ReplyStatus ist aber nicht dasselbe wie der ResponseStatus. Der ResponseStatuts ist der Status der ganzen Anfrage, während der replystatus der Status einer bestimmten Zertifikatsanfrage ist. Das replystatus Element benutzt folgende Syntax: ASN.1-Definition ReplyStatus ::= ENUMERATED { success (0), unrecognizedcheck (1), unrecognizedwantback (2), 119

121 malformedpkc (3), malformedac (4), unrecognizedcertpolicy (5), unrecognizedvalpolicy (6), unrecognizedextension (7), unavailablevaliditytime (8), referencecerthashfail (9), certpathconstructfail (10), certpathnotvalid (11), certpathnotvalidnow (12) } Bedeutung der Zahlen 0. Success: a definitive answer follows 1. Failure: an OID in the check item is not recognized 2. Failure: an OID in the wantback item is not recognized 3. Failure: the public key certificate was malformed 4. Failure: the attribute certificate was malformed 5. Failure: the certificate policy OID is not recognized 6. Failure: the validation policy OID is not recognized 7. Failure: the extension OID is not recognized 8. Failure: historical data for the requested validity time is not available 9. Failure: the referenced certificate did not match the hash value provided 10. Failure: no certification path could be constructed 11. Failure: the constructed certification path is invalid 12. Failure: the constructed certification path is invalid, but a query at a later time may be successful Code 3 und 4 werden gebraucht um dem Client zu sagen, dass die Anfrage richtig formatiert wurde, das Zertifikat jedoch nicht. Das ist vor allem für Clients nützlich, die Zertifikate nicht analysieren oder parsen. replyvaltime Innerhalb der Anfrage sagt dieses optionale Element aus, zu welcher Zeit und zu welchem Datum der Client möchte, dass der Server die Anfrage ausführt. Falls kein solches Element existiert muss der Server die Antwort umgehend nach der Anfrage zurücksenden. replychecks ReplyChecks enthält die Antwort auf das Element checks in der Anfrage. Es wiederholt den OID von der Query und den Integer. Der Wert des Integers zeigt an, ob die Überprüfung der Anfrage erfolgreich war. Die OIDs in dem Element checks werden gebraucht, um die entsprechenden replychecks-werte zu identifizieren. Die OIDs in dem replychecks-element müssen mit den OIDs in dem checks-element in der Anfrage übereinstimmen. ASN.1-Definition ReplyCheck ::= SEQUENCE { check OBJECT IDENTIFIER, status INTEGER } Das status-element für eine Zertifikatskettenbildung zu einer vertrauten Root kann folgende Werte annehmen: 0: Built a path 1: Could not build a path Zertifikatskettenbildung mit einfachem Validierungsprozess: 120

122 0: Valid 1: Not valid Zertifikatskettenbildung mit einem kompletten Validierungsprozess: 0: Good 1: Revoked 2: Unknown 3: Unavailable replywantback Enthält die Antworten auf das wantback-element in der Anfrage. Das replywantback-element enthält den OID von dem wantback-element und ein 8Bit String. Innerhalb dieses Strings steht der erforderte Wert. Die OIDs in dem wantback-element werden gebraucht, um die entsprechenden Werte der Antwort zu identifizieren. Die OIDs in dem replywantback-element müssen mit den OIDs in dem wantback-element übereinstimmen. ASN.1-Definition ReplyWantBack::= SEQUENCE { wb OBJECT IDENTIFIER, value OCTET STRING } validationalg Dieses Element zeigt den Überprüfungsalgorithmus der vom SCVP Server verwendet wird. nextupdate Dieses Element sagt dem Server zu welcher Zeit er eine neue Information erwarten kann. NextUpdate ist vor allem interessant, falls die Sperrinformationen der Zertifikate nicht verfügbar sind. certreplyextensions Die certreplyextensions enthalten die Antworten auf das queryextension-element in der Anfrage. Die OIDs im queryextension-element werden für die Identifikation der entsprechenden Antworten gebraucht. Das certreplyextensions-element enthält eine Sequenz von Elementen und jedes Element enthält wiederum ein extnid-element (critical) und ein extnvalue-element. Das extnid-element identifiziert die Extensions. Es beinhaltet die OIDs, die die Extensions benennen und sie müssen mit den OIDs in dem queryextension-element in der Anfrage übereinstimmen. Das extnvalue-element enthält einen 8Bit String. Innerhalb dieses Strings steht dann der Wert, der Extension. Ein ASN.1 Typ ist für jede Extension definiert und wird von extnid identifiziert. requestnonce Dieses optionale Element enthält ein Identifizierungszeichen, das vom Client für die Anfrage generiert wurde. Falls der Client einen requestnonce-wert in der Anfrage einfügt, dann muss der Server denselben Wert zurücksenden, wie in der Antwort steht. Falls der Server eine zwischengespeicherte Antwort zurücksendet, dann darf dieser Wert in der Antwort nicht enthalten sein. servercontextinfo Dieses Element ist ein Mechanismus für den Server, um Kontextinformationen zum Client zu senden. Die Kontextinformation ist für den Client undurchsichtig, aber liefert dem Server Informationen, die versichern, dass unterschiedliche Zertifikatsketten zurückkehren werden (falls eine andere Zertifikatskette gefunden werden konnte). Die Kontextinformationen können dem Server Statusinformationen anzeigen oder können eine Sequenz von Hashwerten einer Zertifikatskette enthalten, die schon zum Client zurückgesandt wurden. 121

123 Server, die nicht fähig sind zusätzliche Zertifikatsketten zurückzusenden, dürfen das servercontexinfo-element in der Antwort nicht enthalten. valpolresponse Ist die Vereinigung der: 1. Werte von der Validation-Policy, die von den Referenzen in der Anfrage spezifiziert ist. 2. Werte von der Anfrage. 3. Default-Werte, die vom Server für beliebige Parameter gebraucht werden, die in Punkt 1 oder 2 nicht spezifiziert sind. respextensions Diese Spezifikation definiert zurzeit noch Extension, kann aber für zukünftige Erweiterungen von SCVP eingesetzt werden. Falls dieses Element vorhanden ist, enthält es eine Sequenz von Extensions. Jedes Element enthält ein extnid-element (critical) und ein extnvalue-element Server Policies Request Ein SCVP Client benutzt das PolRequest Element, um die Liste der gültigen Policies, welche vom SCVP Server unterstützt werden, anzufordern. Wenn ein PolRequest-Element in einem Teil des MIME Body verkapselt ist, muss es in einem application/cv-policies-request MIME Teil mitgeführt werden. Die Anfrage besteht aus einem PolRequest Element, das in dem ContentInfo-Teil enthalten ist. Die Anfrage wird nicht vom Client signiert. ASN.1-Definition ContentInfo { contenttype content PolRequest } id-ct-scvp-valpolrequest, -- ( ) 5.13 Überprüfung der Policy Antworten In einer Antwort auf ein PolRequest sendet der SCVP Server eine PolResponse. Eine PolResponse ist nicht eindeutig und kann auf mehrere PolRequests eingesetzt werden. Die PolResponse hat auch eine Anzeige wie häufig eine PolResponse wieder verwendet wurde. Wenn eine PolResponse in einem Teil des MIME Body verkapselt ist, muss es in einem application/cvpolicies-request MIME Teil mitgeführt werden. Die Antwort besteht aus einem PolResponse-Element, das in dem ContentInfo-Teil enthalten ist. Die Antwort muss vom Server signiert sein. ASN.1-Definition ContentInfo { contenttype content PolResponse } id-ct-scvp-polresponse, -- ( ) Der PolResponse Typ hat folgende Syntax: ASN.1-Definition PoliciesResponse ::= SEQUENCE { scvpversion INTEGER, DefaultPolicyID NTEGER, thisupdate GeneralizedTime, nextupdate GeneralizedTime, 122

124 trustanchors TrustAnchors, validationpolices SEQUENCE OF ValidationPolRef, validationalgs SEQUENCE OF OBJECT IDENTIFIER, authpolicies SEQUENCE OF AuthPolicy, responsetypes ResponseTypes, defaultvalpol ValPolicy, clockskew INTEGER OPTIONAL, authdatacert Certificate OPTIONAL } ResponseTypes ::= ENUMERATED { cached only (0), unique signed only (1), both cached and unique signed (2)} scvpversion Siehe Kapitel PolicyID Ist ein Integer-Wert, welcher die Version der Default-Validation-Policy definiert, wie es von den Elementen trustanchors, validationalg, authpolicies, clock skew und authdatacerts angezeigt wird. Falls einer dieser Werte ändert, muss der Server eine neue PolResponse mit einer neuen PolicyID kreieren. Falls die Policy und auch die policyid nicht geändert hat, kann der Server die PolicyID mehrmals einsetzen. Falls der Server eine Policy ändert, die auf eine frühere Policy zurückgreift, so darf der Server die PolicyID nicht wieder verwenden, aber einen anderen eindeutigen Wert wählen. thisupdate Dieses Feld zeigt das Datum und die Zeit, an welcher die Policy signiert wurde. Seit diesem Zeitpunkt ist die polresponse nicht an eine spezifische Anfrage gebunden. Ein SCVP Server kann periodisch die Antworten generieren und auch mehrmals die gleiche polresponse für mehrere Anfragen gebrauchen. nextupdate Dieses Feld zeigt die erwartete Publikation (Zeit und Datum) der nächsten Policy Antwort. trustanchors Spezifiziert den Default-trustAnchor, der vom SCVP Server gebraucht wird, falls der Client keinen trustanchor in der Anfrage anfordert. valdidationalgs Dieses Element enthält eine Sequenz von OIDs. Jede OID identifiziert einen einzelnen Überprüfungsalgorithmus, der vom Server unterstützt wird. authpolicies Dieses Element enthält eine Sequenz von Policy-Referenzen für die Authentifikation des SCVP Servers. Die Referenz kann entweder eine OID, welche vom Server und dem Client vereinbart wurde, oder eine URI sein. responsetypes Erlaubt dem Server einen Bereich von Response Typen zu publizieren, die er unterstützt. Cache bedeutet zum Beispiel, dass er nur zwischengespeicherte Antworten auf eine Anfrage zurücksenden wird. Eindeutig signierte Antworten bedeuten, dass der Server eine spezifische Antwort auf eine Anfrage sendet (z.b. wenn das Element requestnonce enthalten ist). 123

125 clockskew Bestimmt die Anzahl Minuten, die der Server für die clockskew (Zeit-Toleranz) erlaubt. Falls nichts angegeben wird, beträgt die clockskew per Default 10 Minuten. Damit werden Abweichungen der Systemuhr unterschiedlicher Computer kompensiert. defaultvalpolicy Dies ist die Default Validations-Policy, die vom Server eingesetzt wird. Ein Client kann diese Default Werte ausser Kraft setzen, indem er das validaionpolref Element in der Anfrage definiert und einsetzt. Anmerkungen SCVP ist noch in Entwicklung und noch nicht als Standard (RFC) erklärt worden. Der aktuelle Internet-Draft, der hier benutzt wurde ist "draft-ietf-pkix-scvp-15.txt vom Juli Gemäss E- Mail von Gavin Spencer (ascertia) wird auf Anfang November 2004 eine neue Draft Version Nr. 16 herauskommen, der aber nur noch kleine Änderungen beinhalten wird. 124

126 6 Produkte OCSP und SCVP Der Markt für SCVP ist noch nicht reif. Die Hersteller sind sehr zurückhaltend mit der Implementierung von SCVP. Die meisten warten ab, bis SCVP als Standard spezifiziert wird. Die Frage, die wir den Herstellern stellten, war "Haben sie gegenwärtig ein Produkt, welches SCVP einsetzt?". Nur von Ascertia bekamen wir eine konkrete Antwort. Wobei wir nicht untersuchten, wie kompetent SCVP im Produkt "TrustFinder" umgesetzt wird. Zu beachten ist auch, dass wir nicht unterschieden, ob die Antwort vom Marketing oder von den Technikern beantwortet wurde. Die unten stehende Tabelle, soll eine Übersicht über die erhaltenen Antworten darstellen. Wir versuchten auch weniger bekannte Hersteller aufzuführen. Firma Kontakt OCSP-Produkt SCVP-Produkt Bemerkungen Info.- quelle Ascertia U.K. Gavin Spencer ertia.com] TrustFinder OCSP (Windows) v4.0 TrustFinder SCVP v1.0 TFSCVP Server TFSCVP Workstation TFSCVP Admin Console TFSCVP Client Super Unterlagen Auch ein XKMS- Produkt auf dem Markt Unterstützt Draft 15 Produkt bestand PKITS-Test zu 80% Mailaussage SyTrust Deutschland Florian Oelmaier om] CoreStreet USA Paul Ohrenberger om] CertControl BASIC CertControl ENTERPRISE CertControl ROOT Desktop Validation Client 1.5 RTC Validation Authority 3.0 die grundlegenden Ziele von SCVP fertig implementiert warten auf endgültigen RFC in der Lage kurzfristig verschiedene Protokolle zu implementieren Im Entwicklungs- Prozess Mailaussage Mailaussage m VeriSign Schweiz support (Verisign.de) [support@verisign.d e] Alacris Responder Appliance 1400 (Hardware) VeriSign Managed Public Key Infrastructure (PKI) Alacris OCSP Client VeriSign Managed PKI ist eine voll integrierte Unternehmenslösu ng SCVP noch nicht in den Produkten integriert planen SCVP in ihre Produkte zu Mailaussage Webseite Mailaussage 125

127 Conrad Bayer m] ValiCert, Tumbleweed U. K. com Keyon Schweiz Martin Christinat h] Alacris OCSP Server Validation Authority: Enterprise Validation Authority Server (EVA) Server Validator Desktop Validator Validator Tool Kit Validation Responder implementieren noch kein spezifisches Datum, wann ein Produkt auf den Markt kommt Interoperabilität mit den meisten CA-Produkten (Microsoft CA, Entrust PKI, Baltimore Unicert usw.) Validation Authority unterstützt OCSP, SCVP, CMP und CSC zur Zeit nur OCSP Unterstützung MUST Features Implementierung mittelfristig vorgesehen da erst Plug-Ins auf der Clientseite vorhanden, dagegen OCSP in immer mehr Standardprodukten mittelfristige Implementierung des Protokolls SCVP Webseite Mailaussage 126

128 7 Technische Facts 7.1 Certificate Revocation List (CRL) Die CRL wird im Allgemeinen in festen Zeitabständen von einer Zertifizierungsstelle ausgegeben. Zum Schutz vor Manipulationen wird sie durch die Zertifizierungsstelle signiert. Eine Transportsicherheit wie zum Beispiel Secure Socket Layer (SSL) oder ein sicherer Server wird deshalb nicht benötigt. Ein weiterer Vorteil von CRL ist, dass die Prüfung der Zertifikate offline erfolgen kann. Für die meisten PKI Applikationen sind CRLs auch sehr praktisch. Jedoch für die Überprüfung von nur einem Zertifikat muss die gesamte CRL beim Prüfer vorliegen. Und auch wenn sich die CRL nicht verändert hat, d.h. keine Einträge stattfanden, muss die CRL aktualisiert bzw. auf den Client herunter geladen werden. Verteilungsproblematik Vor allem bei grossen PKIs stellt die Verteilung der Sperrinformationen mittels CRL ein Problem dar. Die Herausforderung liegt einerseits bei den langen Verteilungswegen und andererseits bei der hohen Netzbelastung. Je häufiger eine CRL publiziert wird, desto aktueller sind die Sperrinformationen. Das häufige Publizieren erzeugt aber eine hohe Netzbelastung. Im schlimmsten Fall kann sogar das ganze Netz zusammenbrechen und es stehen keine CRLs mehr zur Verfügung. Zusätzlich bedeutet eine hohe Anzahl von gesperrten Zertifikaten, dass die CRL auch dementsprechend gross wird. Das Downloaden von grossen CRLs kann wiederum eine Überlastung des Netzwerkes zur Folge haben Eine Möglichkeit, die durch die Verteilung entstehende Last einzuschränken, ist die Partitionierung. Nach RFC 3280 können die Sperrlisten so partitioniert werden, dass sie nur Endanwenderzertifikate, nur CA-Zertifikate oder nur Zertifikate für eine begrenzte Menge von Sperrgründen enthalten. Windows 2003 Server und Windows XP unterstützen die Partitionierung mit Sperrgründen oder Zertifikatstypen jedoch so nicht. Durch die Erneuerung des CA Schlüsselpaares kann aber ein ähnlicher Effekt erzeugt werden. Ob eine Schlüsselerneuerung der CA in der Praxis sinnvoll ist, sei dahingestellt. Eine weitere Möglichkeit zur Beschränkung der zur übertragenden Datenmenge sind Delta-CRLs. Eine Delta-CRL erhält lediglich Änderungen im Bezug auf die zuletzt von der CA herausgegebene vollständige CRL. Die Verteilung grosser vollständiger CRLs ist dann nur in grösseren Zeitabständen nötig. Sowohl die Partitionierung als auch die Verwendung von Delta-CRLs sind mit erheblichem Administrationsaufwand beim Zertifikatsprüfer verbunden. Die Handhabung mehrerer (Delta-) CRLs für verschiedene CAs kann leicht Fehler bei der Zertifikatsstatusprüfung nach sich ziehen. Diese Optimierungsverfahren sind daher nicht in allen PKI-Client-Produkten implementiert. Zwischenspeicherproblematik Damit der Client oder die Applikation nicht bei jeder Statusprüfung eine CRL herunterladen muss, können die CRLs auf dem Client-System zwischengespeichert werden. Der Client sucht dann aber nicht nach einer neuen CRL, solange die zwischengespeicherte CRL noch gültig ist. Das heisst, wenn zum Beispiel bereits eine neuere Version der CRL auf dem Server zur Verfügung steht, aber die CRL auf dem Zwischenspeicher des Clients noch nicht abgelaufen ist, wird der Client trotzdem noch die CRL im Zwischenspeicher verwenden. Somit hat die manuelle Publikation ebenfalls keinen Einfluss auf die zwischengespeicherte CRL-Version, obwohl dieser Mechanismus genau in einer Notsituation eine grosse Relevanz darstellt. Problematik der Gültigkeitsperiode In untenstehender Abbildung ist der zeitliche Ablauf der Ereignisse bei der Revokation eines Zertifikates dargestellt. Es wird davon ausgegangen, dass die CA in periodischen Zeitabständen CRLs publiziert. 127

129 Abbildung 43: Problematik der Gültigkeitsperiode Zum Zeitpunkt T1 wird von der CA eine CRL veröffentlicht. Bei T2 verliert ein bisher nicht gesperrtes Zertifikat zum Beispiel durch Schlüsselkompromittierung seine Gültigkeit. Der Inhaber des Schlüssels bemerkt dies und veranlasst bei T3 eine Sperrung des Zertifikates bei der CA. Obwohl die Sperrung bereits kurz danach zurzeit T4 vermerkt wird, erscheint die nächste CRL2 erst nach Ablauf der Gültigkeitsperiode von CRL1. Eine Anwendung, die Zertifikate unter Zuhilfenahme von CRLs auf Sperrung prüft, erkennt seit T4 gesperrte Zertifikate in der Regel erst nach T5. NextUpdate bedeutet, dass unter Umständen die CRL1 noch bis zum Zeitpunkt T6 verwendet wird. Der Overlap bedeutet, dass zwischen dem Zeitpunkt T5 und T6 CRL1 und CRL2 gültig sind. Der Overlap ist wichtig, weil so garantiert werden kann, dass immer eine CRL verfügbar ist. Bei der Verteilung der CRLs auf die entsprechenden Clients ist es deshalb wichtig, dass vor Ablauf der Gültigkeit der CRL, dem Client bereits eine neue CRL zur Verfügung steht. Zugriff auf CRLs (Microsoft spezifisch) Jedes ausgegebene Zertifikat enthält CRL Distribution Points (CDPs), die auf den Ort der abgelegten CRL verweisen. Die CDPs sind fix und können nach der Ausgabe des Zertifikats nicht mehr geändert werden. Weiter können CRLs ohne CDPs nur mit Hilfe von zusätzlichen Mechanismen (d.h. unabhängig von der verifizierenden Applikation) abgerufen und lokal zur Verfügung gestellt werden (bspw. durch die 'Installation' im betreffenden Windows-Store). Wenn also ein Zertifikat geprüft werden soll, welches keinen passenden CDP enthält, kann der Client keine Statusprüfung durchführen wenn solche Mechanismen nicht implementiert sind. Weiter muss das Herunterladen der CRL innerhalb eine bestimmten Zeit erfolgen. Die benutzten Protokolle (HTTP, LDAP etc.) und die Reihenfolge der CDPs spielen daher eine sehr wichtige Rolle. Solange die CA nur Zertifikate innerhalb einer MS Active Directory Domäne ausgibt, wird nur ein LDAP-CDP benötigt. Bei einer heterogenen Umgebung empfiehlt sich jedoch die Verwendung eines HTTP-CDPs. 7.2 Online Certificate Status Protocol (OCSPv1) Die über CRL verfügbaren Sperrinformationen reichen für sensible, zeitkritische Transaktionen nicht aus. Das Online Certificate Status Protocol (OCSP) erlaubt aktuellere Sperrinformationen. Um die Sicherheit zu gewährleisten, dass die OCSP-Responses vom erwarteten OCSP-Server kommen, wird jede Antwort signiert. Wie die Antworten signiert werden können und welche Vor- respektive Nachteile sie aufweisen, ist ein Teil unserer Arbeit und deshalb im Kapitel 4 und 8 näher beschrieben. Aktualität der Sperrinformationen Mit OCSP kann die Statusabfragung in Echtzeit erfolgen. Die Aktualität der Antwort hängt aber von der Quelle ab, von welcher der Responder seine Daten bekommt. Mit direktem Zugriff auf die Datenbank der CA enthalten die Antworten die aktuellsten Sperrinformationen. Bei einer Backend-Lösung mit CRL ist die Antwort nicht aktueller als die CRL. Diese Backend-Lösung erlaubt jedoch, dass die CRL häufiger herunter geladen werden kann und somit aktuellere Statusinformationen zur Verfügung stehen. 128

130 Verfügbarkeitskonflikt Das Konzept des direkten Zugriffs auf die Datenbank hat den Nachteil, dass die CA selbst hochverfügbar sein muss und so erhebliche Mehrkosten verursacht werden. Auch muss die Datenbank redundant geführt werden, damit bei einem allfälligen Ausfall die Daten noch zur Verfügung stehen. Dies ist wiederum mit hohen Kosten verbunden. Netzwerkbelastung Ein Endbenutzer kann dem OCSP Responder eine einzige Anfrage für das zu prüfende Zertifikat stellen. Die Antworten sind somit kleiner und erfordern weniger Bandbreite, weil nicht jedes Mal eine volle CRL von jedem einzelnen Client heruntergeladen werden muss. Selbst bei einer CRL- Backend-Lösung ist die Belastung der Netzwerkinfrastruktur klein, weil die CRLs nur auf den OCSP Responder übermittelt werden muss. Zusätzlich erspart sich der Client die CRL-Verwaltung. Im Gegensatz zu CRLs, die zu einem festgelegten Zeitpunkt von den CAs veröffentlicht werden und dabei das Kommunikationsmedium zu diesen Zeiten stark belastet, verteilt sich bei OCSP die Datenmenge im Mittel gleichmässig über den Tag. Authority Delegation Der OCSP Dienst muss nicht von der Zertifizierungsstelle betrieben, sondern kann von einem unabhängigen Server übernommen werden, der dafür verantwortlich ist, sich stets die aktuelle Sperrinformation von der Zertifizierungsstelle zu beschaffen. Häufig wird der OCSP-Dienst in einer CA integriert, wenn die Zertifizierungsstelle und der OCSP-Responder vom gleichen Hersteller angeboten werden. Ansonsten betreibt man diese beiden Dienste auf separaten Servern, da sie unterschiedliche Anforderungen an die Verfügbarkeit verlangen. Sicherheitsanforderungen Für die Sicherheit und den Komfort muss allerdings ein höherer Aufwand betrieben werden. Denn für jede Zertifikatsprüfung muss eine neue Abfrage ausgeführt werden. Dies bedeutet, dass bei jeder Abfrage eine Verbindung zum OCSP-Responder bestehen muss. Fällt der Server oder die Verbindung aus, können keine Statusabfragen durchgeführt werden. Die redundante Haltung der Infrastruktur wirkt dem entgegen. Ausserdem ist ein Verfahren, das Online- Transaktionen voraussetzt, allfälliger gegenüber Denial-of-Service Attacken. Skalierbarkeit Bei CRL wächst die Liste mit der Anzahl von Zertifikaten linear. Es gibt kein Mittel um dieses Wachstum zu vermeiden. Mit der Partitionierung und den Delta CRLs kann die Grösse der List nur besser verteilt werden. Das OCSP-Protokoll ist jedoch unabhängig von der Anzahl gesperrten Zertifikaten, dass eine spezifische Anfrage an den Server gestellt werden kann, die sich auf ein einzelnes Zertifikat bezieht. 129

131 7.3 Direkter Vergleich zwischen CRL und OCSP CRL OCSP Wird im Allgemeinen in festen Zeitabständen Kann aktuellsten Zertifikatsstatus liefern veröffentlicht Kann sehr gross werden, enthält unter Einzelanfrage nach einem bestimmten Zertifikat Umständen unbenötigte Informationen möglich Einmalige CPU Belastung (bei grossen CRL sehr CPU-Bedarf fällt synchron bei jeder Anfrage an stark) Hoher Administrationsaufwand Niedriger Administrationsaufwand Prüfung kann offline erfolgen Prüfung benötigt Online-Abfrage Einmalige Signatur der CRL Signatur für jede Response Ungeeignet für Applikationen, die zeitnahen Geeignet für Applikationen, die zeitnahen Zertifikatsstatus benötigen Zertifikatsstatus benötigen weniger skalierbar Skalierung möglich 7.4 SCVP SCVP ist als eine Obermenge von OCSP zu verstehen, bei der zusätzlich zu den Statusinformationen weitere Zertifikatsprüfungen abgefragt werden können. Konstruktion und Validierung der Zertifikatskette SCVP erlaubt zusätzlich die protokollseitige Abwicklung von Anfragen zur Konstruktion einer Zertifikatskette mit oder ohne Validierung einer Zertifikatskette. Policy Management Die Validierung und die Konstruktion der Zertifikatsketten können mittels Policies kontrolliert werden. Der grosse Vorteil liegt darin, dass die Policies zentralisiert werden können. Das heisst, dass die Policies nur noch auf dem Server konfiguriert werden müssen und allfällige Änderungen nur noch an einer zentralen Stelle (Server) vorgenommen werden müssen. Sperrinformation Mit SCVP kann der Client dem Server mitteilen, auf welche Sperrinformationen er zugreifen soll. Dabei können Full CRLs, OCSP-Responses, Delta CRLs und die dazugehörige Base CRL, irgendeine verfügbare Sperrinformation oder keine Sperrinformation angegeben werden. Der SCVP-Server ist dann verantwortlich für die Validierung und für das Weiterleiten an den OCSP Responder, falls OCSP für die Statusprüfung verlangt wird. Zeitpunkt der Abfrage Der Client kann auch einen bestimmten Zeitpunkt definieren, in der eine Abfrage ausgeführt werden soll (validitytime). Somit ist eine Prüfung des Zertifikates in der Vergangenheit möglich. Mit OCSP ist dies auch möglich, jedoch nur innerhalb einer bestimmten Zeit (retension-intervall). Infrastruktur Die Interoperabilität von unterschiedlichen PKIs wird durch den Einsatz von SCVP einfacher und transparenter. Back-end PKI Standards können geändert werden ohne die zertifikatsbasierte Applikation zu beeinflussen. Dies macht SCVP zukunftssicher. In SCVP wird nicht erfordert, dass die SCVP Server in einer Hierarchie angeordnet werden müssen. Clientsicht Mit SCVP wird der Gebrauch von Zertifikaten einfacher, sicherer, konsistenter und leichter verfügbar für eine Applikation. Wird die komplette Intelligenz des Client delegiert, so vereinfacht dies die Implementation des Clients. 130

132 8 Mögliche Lösung für die UBS Ab Windows XP verlangt der zertifikatsbasierte Login in die Swiss-DD Domäne eine Statusprüfung. Microsoft bietet im Lieferumfang standardmässig CRL als Mechanismus für die Statusprüfung an. Mittels definierter Schnittstelle (CryptoAPI) können weitere Statusabfragungs- Mechanismen an das Windows-Umfeld eingebunden werden. Dies setzt voraus, dass weitere Produkte eines Drittherstellers eingesetzt werden müssen. Für den Windows Login, der keine hohen Anforderungen an die Aktualität der Sperrinformationen stellt, reichen CRLs aus. Es macht deshalb keinen Sinn ein weiteres Produkt einzusetzen. Die Grösse der CRL stellt bis heute noch kein erhebliches Problem dar. Die Benutzer-Zertifikate haben eine Gültigkeit von vier Jahren. Gegen Ende dieser Gültigkeit könnte die Gösse der Sperrliste und deren Verteilung jedoch zum Problem werden. Weil nur die Client-Zertifikate auf ihren Status geprüft werden, müssen nur die Domain Controller jederzeit über aktuelle CRL verfügen Der Einsatz von Delta CRL ermöglicht eine weitere Reduzierung der Grösse einer CRL. Uns wurde eine Testumgebung zur Verfügung gestellt und wir konnten den Umgang mit Delta CRL erproben. Die Tests erfolgten mit der Applikation Secure , welche Delta CRL unterstützt. Wir wählten Secure , weil mit dieser Applikation im Umfeld UBS der CRL Check einwandfrei funktioniert und von einer Mehrzahl von UBS-Mitarbeitenden eingesetzt wird. Nach eigenen Erfahrungen, sind wir der Meinung, dass Delta CRL im Umfeld von Secure einfach betrieben werden kann. Die Herausforderung liegt in der Definition einer geeigneten Publikationsperiode. Einerseits müssen die Anforderungen (Aktualität Sperrinformation) einzelner Applikationen genau analysiert werden und zweitens muss die Infrastruktur dem vermehrten CRL-Traffic standhalten können. Die CRLs an sich sind zwar kleiner, aber die Zeit für die Verteilung darf nicht länger als die Publikationsperiode sein. Zum Beispiel würde es inkonsistente Antworten liefern, wenn der Verteilungsweg bis zum letzten Endbenutzer zwei Stunden beträgt und die Delta CRL jede Stunde erstellt und verteilt wird. Um der Anforderung einer aktuelleren Sperrinformation gerecht zu werden, entstand das Protokoll OCSP. Dieser Dienst wird von der UBS bereits zur Verfügung gestellt. Der eigentliche Anstoss für die Implementierung von OCSP gab das Online-Banking, da Geldtransfers und der Aktienhandel zeitkritische Transaktionen darstellen. Bis heute wird OCSP von ein paar wenigen Applikationen eingesetzt. In einer grösseren Anzahl Applikationen ist OCSP implementiert, jedoch noch nicht frei geschaltet. OCSP bewährte sich in der Praxis als Statusabfragungsmechanismus gut und müsste nicht durch einen neuen Mechanismus ersetzt werden. Das einzige Problem liegt in der Signierungsstruktur. Der RFC 2560 Standard lässt nur die Möglichkeiten zu, dass die OCSP-Responder-Antworten entweder durch die CA, die das zu überprüfende Zertifikat ausgegeben hat, oder durch den OCSP-Server selbst (self-signed) signiert werden. Diese Varianten mit denen ein OCSP-Responder seine Antworten signieren kann, stellen für die UBS keine befriedigende Lösung dar. Einerseits fordert die self-signed-variante einen grossen Aufwand beim Management des Signaturschlüssels, andererseits entspricht die Lösung, mit welcher der OCSP-Responder von der User-CA signiert wird, nicht dem Vertrauensmodell der UBS. Am Beispiel UBS kann die Problematik der self-signed-variante genauer aufgezeigt werden. Denn würde der Public Key des OCSP-Responders ändern, so müsste in der UBS mindestens 3 Jahre für die neue Konfiguration in allen Applikationen aufgewendet werden. Eine mögliche Lösung wäre mit OCSPv2 realisierbar gewesen, da die Vorgaben über die Signatur der Antworten viel offener formuliert wurden. Das heisst, dass die OCSP-Antworten von einer unabhängigen CA signiert werden können. Der Hersteller "Keyon" hätte so eine Lösung im Angebot, da die Signaturproblematik nicht nur die UBS sondern auch noch weitere Organisationen betrifft. Bis heute entspricht diese Lösung jedoch keinem Standard. Weiter möchte sich die UBS nicht an ein Produkt binden, um Abhängigkeiten möglichst zu vermeiden. 131

133 Nach eigenen Erkenntnissen hat sich OCSPv2 nicht durchsetzen können und ist auf den IETF- Seiten nicht mehr aufgeführt, nicht mal mehr als Draft. Aus diesem Grund kommt die Lösung von Keyon für die UBS nicht in Frage. SCVP scheint sich gegenüber OCSPv2 durchgesetzt zu haben. Das Problem der Signatur könnte mit SCVP gelöst werden, da das Konzept, dass eine CA eine SCVP Response signiert, keinen Sinn macht. Das einzige sinnvolle Modell ist, dass man dem Schlüssel, der für die Signatur gebraucht wird, direkt vertraut. Oder man vertraut einer Stelle die wiederum den SCVP Server signiert. Dies würde für die UBS bedeuten, dass die bisher eingesetzte Variante, mit der die OCSP-Antworten auf einem self-signed Zertifikat basieren, weiterhin eingesetzt werden kann. Das heisst, dass der Schlüssel nur noch auf dem SCVP-Server lokal konfiguriert werden muss. Der SCVP-Server könnte dann von einer unabhängigen Server-CA signiert werden, dem wiederum die Applikationen vertrauen. Abbildung 44: Mögliche Lösung für UBS 132

134 9 Erkenntnisse 9.1 Einleitung Während die Validierung von Zertifikaten eine weit verbreitete Akzeptanz findet und als wichtiger Vorgang im Umgang mit Zertifikaten anerkannt ist, wird die Sperrlistenabfragung häufig vernachlässigt. Die Vernachlässigung ist einerseits mit dem Unwissen der Verantwortlichen oder mit dem Mehraufwand, der bei jeder Sicherheitsvorkehrung aufgewendet werden muss, zu begründen. Die beiden bekanntesten Varianten, die Sperrlisteninformationen bereitstellen, sind CRL und OCSP. CRLs und Onlineabfragen mit OCSP weisen je nach Einsatzgebiet spezifische Vor- und Nachteile im Hinblick auf Sicherheit, Skalierbarkeit und nicht zuletzt Administrationsaufwand auf. 9.2 CRL CRLs bieten einen zuverlässigen Mechanismus zur Statusüberprüfung an und sind weit verbreitet. Die Statusprüfung mittels CRL war der erste Mechanismus, der sich als Standard durchsetzte. So wird beispielsweise auch ab Windows 2000 standardmässig CRL als Mechanismus, um Zertifikate zu sperren, unterstützt. In den gesammelten Dokumentationen über CRL konnten wir heraus lesen, dass die Statusüberprüfungen mit CRLs in kleinen Umgebungen ausreicht, solange keine Echtzeit- Abfrage verlangt wird. Mit einer kleinen Umgebung, respektive PKI ist gemeint, dass die Statusprüfung nur an wenigen zentralen Stellen stattfindet und die Liste nicht allzu gross wird. Sobald die Komplexität der PKI ansteigt (Zertifikatsprüfung an vielen verteilten Stellen), weist CRL einige Nachteile auf, die im Kapitel 7.1 nachgelesen werden können. Bei den Studien über die CRL-Lösung von Microsoft, erkannten wir, dass vor allem die zwei Schlagwörter "Certificate chaining engine" verbunden mit "CryptoAPI" sehr bedeutend sind. Die CyptoAPI wird auf der Clientseite eingesetzt, um die Zertifikatsstatusprüfung und Zertifikatskettenbildung inklusive Validierung durch zu führen. Bei einer Zertifikats-Validierung werden die Komponenten Inhalte des Zertifikats, Zertifikatsformat, Critical Extensions, Policy Validation, Revocation Check, Route Check, Signature Check und Time validity überprüft. Die CryptoAPI ist eine Schnittstelle zwischen der angewendeten Applikation und dem eigentlichen Betriebssystem. Zusätzlich stellt die CryptoAPI eine umfassende Bibliothek im Bereich der Kryptographie zur Verfügung. Die Certificate chaining engine ist ein Bestandteil dieser kryptographischen Funktionen und wird für die Zertifikats-Statusprüfung eingesetzt. Das Microsoft-Betriebssystem (ab Win2K) stellt eine zufrieden stellende Lösung für die Zertifikats- Validierung und Sperrlisten-Abfragung zur Verfügung. Bei alleiniger Verwendung von CRL ist es deshalb nicht nötig eine zusätzliche Client-Software zu installieren. Um uns die Praxis von einer PKI näher zu bringen, konnten wir auf einer kleinen Testumgebung die ersten Eindrücke und praxisbezogene Erfahrungen sammeln. Die eingesetzte Infrastruktur umfasste zwei XP-Clients und eine Windows Server 2003 CA. Die Tests erfolgten auf der Applikation Secure (MS Outlook 2003). Da vor allem die Grösse einer CRL ein Problem darstellt, versuchten wir eine grösstmögliche CRL nach zu bilden. Wir generierten insgesamt über 10'000 Zertifikate mit einem eigenem Skript. Dabei wurden mehrere Zertifikate für einen Benutzer ausgestellt. Dies entspricht zwar nicht der Realität, das Ziel einer grossen CRL konnte so jedoch einfach erreicht werden. Die Microsoft CA ist aber nicht darauf konzipiert, dass mehrere Zertifikate für den gleichen Benutzer erstellt werden. Das hatte zur Folge, dass wir beispielsweise einige Stunden für die Generierung der ersten 1000 Zertifikate benötigten, da jeweils für jedes weitere Zertifikat die Zeit exponentiell anstieg. Falls sehr viele Zertifikate für einen Benutzer ausgestellt werden, ist zudem nicht klar ersichtlich welches Zertifikat von der Applikation verwendet wird. 133

135 Den Schwerpunkt unserer Tests setzten wir auf Delta CRL. Wir wollten prüfen, ob der Delta CRL Mechanismus auch so funktioniert, wie es in den Microsoft Papers [19] dokumentiert ist. Wir revozierten unsere Zertifikate mit dem Reason Code "Certificate Hold". Dieser Sperrgrund wird für die temporäre Sperrung benutzt. Das heisst das Zertifikat kann von der Sperrliste entfernt werden und ist somit wieder gültig. In der Praxis wird diese Art von Sperrung selten bis gar nie eingesetzt. Wir profitierten jedoch von dieser Möglichkeit, denn so mussten wir nicht immer neue Zertifikate erzeugen. Dabei wurden wir davon überzeugt, dass die Extension RemoveFromCRL richtig erkannt wird und die Sperrung rückgängig gemacht werden kann. Des Weiteren ist uns aufgefallen, dass bei jeder Ausgabe einer Base CRL auch eine Delta CRL ausgestellt wird, welche die gleiche CRLNumber aufweist, aber der CRLDeltaIndicator zeigt auf die letzte Base CRL. Bei Aktivierung der Benutzereinstellung "Explicitly Trust this Certificate" wird das Zertifikat akzeptiert und als gültig anerkannt, obwohl es gesperrt wurde. Weil auch wir diese Einstellung unbewusst aktiviert haben, bekamen wir zu Glauben, dass Delta CRL in der Microsoft- Umgebung nicht funktioniert. Dies war auch ein wichtiger Hinweis für die UBS. Mitarbeitende sollten diese Einstellung nicht selbständig und ohne Wissen über die Auswirkung vornehmen können. Ansonsten wäre der ganze CRL Check hinfällig. 9.3 OCSP Obwohl OCSP zunächst vor allem zur zeitnahen Statusprüfung bei kritischen Transaktionen konzipiert wurde, ist auch ein breiter Einsatz sinnvoll. OCSP ist zur Verteilung von Statusinformationen in einer grossen Umgebungen, in denen viele verschiedene Applikationen auf Statusinformationen zugreifen, besser geeignet als der CRL Mechanismus. Das Protokoll OCSP ist bis auf weiteres kein Bestandteil des Windows Betriebssystems. Nach heutigen Informationen ist die Einführung von OCSP in Microsoft Longhorn nicht definitiv bestätigt. OCSP kann aber mittels Plug-In gut in die bestehende PKI-Umgebung integriert werden. Bei Microsoft kann zum Beispiel ein OCSP-Dienst über die Schnittstelle CryptoAPI an die bestehende PKI- Umgebung angebunden werden. OCSP existiert seit 1999 als RFC und mittlerweile bieten auch immer mehr Hersteller Produkte mit OCSP-Unterstützung an. Unsere Auswahl von Herstellern lag nicht bei Anbietern von einer kompletten OCSP-Lösung, sonder fokussierte auf Dritthersteller, die das Fehlen einer OCSP- Implementierung im Windows Betriebssystem ausnutzen. Eine Übersicht ist im Kapitel 6 zu finden. OCSP ist also Reif und hat sich in der Praxis für die Online Statusabfrage bewährt. OCSP Antworten müssen nicht zwingend durch die CA selbst signiert werden. Der OCSP- Responder kann sich auch selbst ein Zertifikat ausstellen und mit diesem die Antwort signieren (self-signed). OCSPv2 hätte zusätzliche zur Statusabfrage noch weitere Funktionalitäten ermöglicht. Die grosse Errungenschaften von OCSPv2 wären die Protokolle DPV (Delegated Path Validation) und DPD (Delegated Path Discovery). Diese Protokolle erlauben die Validierung und die Konstruktion einer Zertifikatskette. Auf der PKIX-Mailingliste konnten wir herauslesen, dass die Integration dieser beiden Funktionen die Komplexität von OCSPv2 unnötig erhöht hätte. Davon abgeleitet wäre OCSP nicht nur für die Statusprüfung verantwortlich sondern auch für die Zertifikatsprüfung. Und dies wollte man vermeiden. 134

136 9.4 SCVP SCVP existiert nach drei Jahren immer noch als Draft Version 15. Gemäss Aussagen von verschiedenen Herstellern, wird höchst wahrscheinlich anfangs November 2004 Draft 16 erscheinen. Der Draft ist bereits jetzt schon sehr detailliert und es müssen nur noch einige Sicherheitsüberlegungen geklärt werden. Unsere kleine Marktanalyse ergab, dass bereits viele Hersteller ein Produkt für SCVP am Entwickeln sind. Wir stiessen auf eine sehr positives Echo. Ob diese Angaben rein Marktstrategisch sind, kann erst festgestellt werden, wenn SCVP zum Standard wird. Über die Interoperabilität zwischen verschiedenen Produkten können wir keine abschliessende Aussage machen. SCVP ist als Obermenge von OCSP zu verstehen, bei der nicht nur Statusinformationen abgefragt werden können, sondern das ganze Path Building kann ebenfalls auf den Server delegiert werden. Es braucht selbstverständlich auch einen Server und eine entsprechende Client-Komponente, sofern die Clientseite nicht im Produkt oder Betriebssystem selbst implementiert ist. Auch SCVP kann in der Schnittstelle CryptoAPI an die Microsoft-Umgebung eingebunden werden. Für die Statusabfrage alleine ist SCVP sicher des Guten zu viel, denn da macht OCSP seinen Job gut. Für eine komplette Delegation der Intelligenz der Zertifikatskettenbildung inkl. Prüfung und Policy Vollstreckung an einen zentralen Server ist es sicher geeignet, setzt aber entsprechende Clients voraus und der Server muss entsprechend der grösseren Last (Rechenleistung wie auch Netzwerktraffic) ausgelegt werden. Dazu ein extremes Beispiel, was vom Protokoll her zulässig wäre: Ein Client sendet mit einem SCVP Request eine CRL von 900KB Grösse als "Hilfe" für die Validierung mit. Das dürfte dann schon fast als Denial of Service Attacke ausgelegt werden. Diese Situation widerspricht jedoch der Idee eines Validation Servers, dessen Aufgabe es ja unter anderem ist, solche Revokationsinformationen zu sammeln. Eine elementar wichtige Frage ist bei einer kompletten Delegation aber, ob eine Applikation dies überhaupt unterstützt, resp. die Möglichkeit zur Integration anbietet. Ein anderer zentraler Aspekt ist die harte Abhängigkeit vom SCVP-Server, der die ganze Intelligenz enthalten kann. Jedoch genau dieser Punkt ist ja der Vorteil von SCVP. Die Fallback-Situation muss berücksichtigt werden und mit geeigneten Massnahmen sichergestellt werden. 135

137 Schlusswort Wir sind froh, haben wir die Möglichkeit erhalten, unsere Diplomarbeit in Zusammenarbeit mit UBS zu schreiben. Viele praktische Inputs bereicherten unser Arbeiten und Recherchieren. Neben unserem täglichen Engagement für die Diplomarbeit konnten wir zusätzlich vom Wissen, das in der UBS vorhanden ist, profitieren. So bekamen wir einen Einblick in das Benutzerberechtigungssystem (BBS), Risk Management, Security Awareness. Weiter erhielten wir Informationen über kryptographische Algorithmen in der UBS-Kryptologie. Nebenher konnten wir uns an das zukünftige Berufsleben gewöhnen und sehen das als grosse Bereicherung. Das Thema PKI war uns nicht fremd, jedoch realisierten wir erst während den ersten Tagen, wie umfassend und komplex PKI eigentlich ist. PKI kann nicht in Einzelteile aufgesplittet und separiert betrachtet werden. Erst mit dem Kontext kann auf entsprechende Anforderungen reagiert werden. Neben der allgemeinen PKI-Komplexität gesellte sich der Aspekt der Praxis dazu, was manche theoretisch gute Lösung über den Haufen werfen kann. Eins haben wir ganz sicher gelernt: Es gibt in einer Umgebung, wie die UBS aufweist, nie DIE Lösung, sonder die entsprechende Lösung erweist sich nur in spezifischen Situationen als richtig. Je nach dem von welchem Blickwinkel das ganze betrachtet wird, tauchen unterschiedliche Vor- bzw. Nachteile auf. Zu Beginn dieser Arbeit hatten wir hohe persönliche Ansprüche und wir wollten alles ganz genau verstehen. Wir suchten daher oft tief bis ins Detail um eine Antwort auf unsere Fragen zu finden. Dabei verloren wir manchmal auch den Überblick. Dank vielen Diskussionen und Anregungen von unseren Begleitern, fanden wir jedoch den Weg zum vorgegebenen Thema jeweils wieder zurück. Wir hoffen, dass wir einige Aspekte aufzeigen und den Horizont der Statusprüfung erweitern konnten, so dass auch die UBS von uns profitieren kann. Gerne hätten wir unsere Arbeit fortgeführt und einige Details noch weiter ausgeleuchtet. Die Auseinandersetzung mit einem detaillierten technischen Problem war für uns eine grosse Herausforderung und faszinierte uns bis zum Schluss. Wir sind der Meinung, dass wir uns mit dieser Diplomarbeit ein grosses Wissen aneignen konnten, das in dieser Form weder in Schulbüchern noch auf Internetseiten existiert. Dank Für die Unterstützung zur Definition des Themas und für die wertvollen und kompetenten Auskünfte möchten wir uns an dieser Stelle bei unseren Betreuern recht herzlich bedanken. Einen speziellen Dank möchte wir der Bank UBS AG aussprechen, die uns diese Diplomarbeit ermöglicht hat und uns beim Arbeiten unterstützt hat. Andreas Steffen Dozent an der Fachhochschule Winterthur und DA-Betreuer Betreuer von der UBS Jürg Spörndli Vice-director Identity Management UBS AG Peter Bodenmann OCSP und CRL Spezialist Martin Sieber Microsoft-Spezialist 136

138 Glossary A Access Control List Wenn ein Benutzer auf eine Ressource (z.b. eine Datei, ein Ordner, ein Laufwerk, ein Drucker) zugreift, so muss das Betriebssystem prüfen, ob der Benutzer dazu berechtigt ist. Dazu kann man für jede dieser Ressourcen eine Berechtigung festlegen. ADS, Active Directory Service Microsoft bietet seit der Verbreitung des Betriebssystems den Verzeichnisdienst Active Directory Service an. Der Hauptzweck von ADS ist die effiziente Verwaltung komplexer verteilter Systeme und die Skalierbarkeit von Windows-basierten Netzwerkarchitekturen. Attributzertifikate Dies sind Zertifikate ohne öffentlichen Schlüssel, die ansonsten einem normalen Zertifikat entsprechen. Sie sind meistens eine Ergänzung zu einem normalen Zertifikat, um bestimmte Zusatzinformationen über eine Person auszulagern. Dadurch werden die normalen Zertifikate kleiner und Datenschutzauflagen können leichter erfüllt werden, da diese nur bei Bedarf veröffentlicht werden müssen. Außerdem kann man so Zusatzinformationen über eine Person vermitteln, ohne dass das dazugehörige normale Zertifikat geändert werden muss. Obwohl sie u.a. in [ITU97], [RFC3281] und in ISIS-MTT spezifiziert sind, werden sie kaum verwendet und werden in diesem Kapitel nicht weiter berücksichtigt. Authentifizierung Das ist der Vorgang eine Identität zu beweisen. Um den Beweis einer Identität zu erbringen, gibt es 3 Ansätze, den "etwas haben" - Ansatz, wo der Besitz einer Sache die Identität beweist, der "etwas wissen" Ansatz (z.b. Passwort) und der "etwas sein" Ansatz, wo genau genommen körperliche Merkmale die Identität beweisen. Autorisierung Überprüft und weist Zugriffsrechte auf Daten und Dienste zu. Die Autorisierung erfolgt meist nach einer erfolgreichen Authentifizierung. B Brute Force Attacke Übersetzt heisst dies soviel wie "mit brutaler Kraft angelegte Attacke" und meint damit, dass ein Angreifer der Schlüssel erratet, indem er sämtliche Möglichkeiten durchprobiert. C CA, Certificate Authority Vertrauenswürdige Stelle, die Sicherheitszertifikate erteilen und deren Authentizität sicherstellen. Die wahrscheinlich bekannteste kommerzielle Zertifizierungsstelle ist VeriSign, die u. a. Zertifikate für Microsoft kompatible ActiveX- Komponenten oder Echtheitszertifikate von SSL- Schlüsseln für Webserver ausstellt. Certificate Chaining engine Die Microsoft CryptoAPI enthält Cert- und Crypto-Funktionen. Die Microsoft Certificate chaining engine ist ein Teil von den Cert-Funktionen und wird deshalb für die Zertifikats-Statusprüfung verwendet. Chiffrat Verschlüsselter Text Chiffrieren verschlüsseln 137

139 CryptoAPI Kurzform für von Microsofts Verschlüsselungs-Applikations-Schnittstelle. CryptoAPI ermöglicht es Software-Entwicklern, ihren Windows-basierten Anwendungen leistungsfähige Verschlüsselungsbasierte Sicherheits-Features hinzuzufügen. CryptoAPI enthält Funktionalitäten für die Ver- und Entschlüsselung von Daten und für die Verwendung und Verwaltung von digitalen Zertifikaten. API steht für Application Programming Interface. D Directory Service siehe Verzeichnisdienst DN, Distinguished Name DN bezeichnet einen eindeutigen Knoten innerhalb des X.500 Verzeichnisbaumes. Der Name ermöglicht den Zugriff auf einen bestimmten Eintrag. Er bildet sich aus den Werten aller Objekte von der Wurzel bis zum entsprechenden Eintrag. Domäne Eine Domäne ist der Grundbaustein eines Active Directory. Eine Domäne wird häufig einem physischen Standort entsprechen. Sie muss es jedoch nicht. Sie kann durchaus auch standortübergreifend betrieben werden. Voraussetzung dafür ist allerdings eine hinreichend gute Verbindung der Standorte untereinander. DoS, Denial of Service Diese Attacke versucht einen Server so zu überlasten, dass keine Verbindung mehr aufgebaut oder keine Funktion mehr gestartet werden kann. Das Ziel ist, den Server für andere unbenutzbar zu machen. Draft Dies ist ein Entwurf für einen zukünftigen Standard. Der Draft ist bereits öffentlich zugänglich. DSA, Digital Signature Algorithm DSA ist eine asymmetrische Verschlüsselung zur Erzeugung digitaler Signaturen. Es wurde von der National Security Agency (NSA) entwickelt und verwendet als Hashfunktion den SHA1- Algorithmus. E Enterprise CA Ist sehr tief in die Windows 200x Umgebung inkl. Active Directory integriert und setzt eine Windows 200x Domäne und Active Directory voraus. Die Enterprise CA ist ausschliesslich für die Zertifizierung von Benutzern und Rechnern innerhalb einer Domäne vorgesehen. F Firewall Die Firewall beschützt ein sicheres Netz vor unberechtigten Dritten (Hacker). Dazu werden Zugriffskontrollen durchgeführt, welche die Kommunikationsmöglichkeiten für Dritte einschränken. Forest Ein Forst ist die höchste Ebene einer Active Directory Struktur. In der deutschsprachigen Dokumentation wird ein Forest auch als "Gesamtstruktur" bezeichnet. Ein Forest beinhaltet einen oder mehrere Active Directory Trees. Zwischen den Trees werden automatisch Vertrauensstellung aufgebaut. Somit können alle Active Directory Objekte innerhalb des gesamten Forests genutzt werden. Die Global Catalog Server werden Forest-Weit gepflegt, d. h. auch sie enthalten alle Objekte des Forests. Die in einem Forest enthaltenen Active Directory Trees verfügen über unterschiedliche Namensräume (z. B. adiscon.de und adiscon.com). Alle Trees innerhalb eines Forest besitzen das gleiche Active Directory Schema. 138

140 Ein Active Directory enthält immer mindestens einen Forest - auch dann, wenn nur ein Tree vorhanden ist. Es ist allerdings möglich, in einer Organisation mehrere Forests zu haben. Dies ist nicht empfohlen, da zwischen den Forests keinerlei automatische Synchronisation erfolgt. Mehrere Forests können aus Versehen entstehen: wird bei Installation einer neuen Domäne diese nicht in einen bestehenden Tree / Forest hinein installiert (das muss angegeben werden), so entsteht ein neuer Forest. H HSM, Hardware Sicherheitsmodul Das HSM dient zur Beschleunigung von kryptographischen Operationen sowie zur sicheren Ablage von Schlüsseln und wird über die PKCS#11 V2.01 angesteuert. Der Schlüssel zum Signieren der OCSP Antworten wird im HSM generiert und das signieren mit dem Schlüssel erfolgt auf dem HSM. Falls kein HSM verwendet wird, wird der Schlüssel in einer mit einem zufällig generierten, starken Passwort geschützten PKCS#12 Datei abgelegt. I IETF Internet Engineering Task Force ( bearbeitet technische Internetprobleme. Sie wird in spezifische Arbeitsgruppen geteilt. ITU International Telecommunication Union, früher CCITT genannt. Dies ist eine internationale Organisation, welche für die Normierung und Entwicklung von Telekommunikationsdiensten verantwortlich ist. K Kompromittiert Zum Beispiel ist ein Schlüssel kompromittiert worden, wenn der geheime Schlüssel offen gelegt wurde oder in Gefahr ist. Kreuzzertifikat Ein Zertifikat, welches für den öffentlichen Schlüssel einer anderen CA hergestellt worden ist. M Man in the Middle Attacke Übersetzt heisst dies "die Attacke des Mannes in der Mitte", was soviel bedeutet wie, ein unberechtigter Dritte (Hacker) steht zwischen zwei Kommunikationspartner und fängt die Anfragen und Antworten ab. Dieser Dritte kann störend in die Kommunikation eingreifen, Rechte eines der Partner aneignen und falsche Informationen liefern. MIME, Multipurpose Internet Mail Extensions Dies ist ein Mechanismus, der in der Kommunikation unterschiedliche Datentypen erlaubt. Ohne MIME wäre eine nur in ASCII-Codierung möglich. MIME-Typs sind zum Beispiel Image, Audio oder Video. O Online In Echtzeit P PGP, Pretty Good Privacy Dies ist ein Programm für die Verschlüsselung und die elektronische Unterschrift. Es ist eine Freeware-Software und plattformunabhängig. Es ist ein Public Key Verfahren. PKCS Public Key Cryptography Standard 139

141 PKIX Dies ist eine X.509 basierte PKI. R Replay Attacke Bei dieser Attacke werden bereits gesandte Meldungen wiederholt an den gleichen Empfänger geschickt. Es wird erwartet, dass entweder der Empfänger den gleichen Befehl mehrmals ausführt oder so überlastet wird, dass er seine Funktion nicht mehr ausführen kann. Revocation Provider Hiermit können standardmässig in Windows enthaltene Routinen und Techniken zur Überprüfung des Sperrstatus von Zertifikaten durch zusätzliche Provider ergänzt werden. Auf diese Weise kann Windows z.b. um Funktionalitäten wie OCSP zur Sperrprüfung erweitert werden. Revozieren Etwas für ungültig erklären, was davor öffentlich beglaubigt wurde. RFC, Request for Comment In den RFCs werden die Standards des Internets spezifiziert. Es sind technische Berichte, die online und kostenlos von verschiedenen Servern heruntergeladen werden können. Router Es ist ein Element in einem Netzwerk, das Datenpakete anhand der Zieladresse auf den richtigen Netzabschnitt weiterleitet. S Session Key Dies ist ein temporäres, vereinbartes Geheimnis rsp. symmetrischer Schlüssel, welcher genau für eine Kommunikationsverbindung eingesetzt wird. Site Sites repräsentieren im Active Directory wirklich nur Standorte im Sinne der physischen Struktur des Netzwerks und sind von der logischen Struktur völlig unabhängig. Domänen können sich über mehrere Sites erstrecken, ebenso wie es in einer Site mehrere Domänen geben kann. SMB, Server Message Blocks Mittels des Protokolls Server Message Blocks SMB erfolgt die Vernetzung von Windows-Clients per Peer-to-Peer-Vernetzung oder mit einem Windows-Server. Mit dem Programm Samba kann die Linux- und Windows-Welt zusammen geschlossen werden. Nicht unüblich ist es, in kleinen lokalen Netzen verschiedene Freigaben einzurichten. Diese sind aber bei aktiver Internetverbindung unter Umständen auch aus dem Internet erreichbar. Auf diese Weise können private Daten ungewollt der Öffentlichkeit zugänglich gemacht werden. Daher sollten die Ports 137 bis 139 aus dem Internet nicht erreichbar sein. Mit einem Portscanner können leicht riesige Adressbereiche daraufhin untersucht werden, ob die genannten Ports offen sind. In einem nächsten Schritt wird dann versucht, auf diese Freigaben zuzugreifen. Es gibt auch spezialisierte Tools genau für diesen Zweck. S/MIME, Secure MIME Sicherheitsstandard für die Absicherung einer Kommunikation mit MIME. Stand-alone CA Ist weitgehend unabhängig von anderen Komponenten (z.b. dem Active Directory) und kann unabhängig von einer Windows 200x Domäne betrieben werden. Die Zertifizierung erfolgt unabhängig von Domänen Accounts. 140

142 T Trap Door In einem Sicherheitssystem vorsätzlich eingebauter Mechanismus, welcher es ermöglicht zu den sensitiven Daten vorzudringen. Die Sicherheitsvorkehrungen werden dabei umgangen. Im Zusammenhang mit Verschlüsselungsalgorithmen wird aber damit der Schlüssel gemeint. Nur mit diesem privaten Schlüssel kann die verschlüsselte Nachricht entschlüsselt werden. Tree Ein Active Directory Tree (Baum) sind die in einem Namensraum (z. B. adiscon.com) zusammengefügten Domänen. Domänen sind innerhalb des Trees hierarchisch aufgebaut, d. h. es gibt eine Domäne auf höchster Ebene, von der sich dann wieder andere Domänen ableiten. Alle Domänen innerhalb des Trees sind über sogenannte transitive Vertrauensstellungen untereinander verbunden. Die Objekte des Trees können also überall genutzt werden. Trust Anchor Das selbstsignierte Zertifikat der Root-CA wird auch als Trust Anchor bezeichnet. V Verzeichnisdienst (Directory Service) Der Verzeichnisdienst leistet in einer Public Key Infrastruktur Dienste von zentraler Bedeutung. So zum Beispiel die Publikation von Personendaten, deren zugehörige Zertifikate sowie CRLs. Die wohl am bekanntesten Directory Services sind X.500, bzw. das daraus entstandene Lightweight Directory Access Protocol (LDAP), Novell Directory Services (NDS) und Active Directory (AD) von Microsoft (LDAP kompatibel, jedoch Proprietär). X X.509v3 Dies ist ein vom ITU empfohlener Standard für Zertifikate, CRLs und CAs. V3 bedeutet die 3. Version. XKMS, XML Key Management Specification XKMS wurde von VeriSign, Microsoft und WebMethods gemeinsam als offener Standard entwickelt. XKMS soll die Absicherung XML-basierter Internet-Transaktionen über die PKI erleichtern. Entwickler können Dienste für die Authentifizierung, für digitale Signaturen und für die Verschlüsselung einfach in ihre Anwendungen integrieren. XKMS Services sind unabhängig von der Plattform, vom Hersteller und vom Transportprotokoll. 141

143 Kapitel 1:Grundlagen Quellenverzeichnis [1] Kryptographie FAQ [2] Uni Potsdam (Deutschland): Sicherheitskonzepte [3] Internet-Lexikon Security [4] Wikipedia: Kryptologie [5] Uni Mainz (Deutschland): Asymmetrische Veschlüsselung [6] Uni Mainz (Deutschland): Symmetrische Verschlüsselung [7] RSA, DSA Signature Algorithm [8] PKI-Grundlagen wledgebase/technology/standards/pkix.htm [9] Public Key Infrastructure Grundlagen [10] Digitale Zertifikate [11] Hisecure White Paper per_deutsch.htm Abstract Syntax Notatino One (ASN.1) [12] Abstract Syntax Notation One (ASN.1) [13] ASN.1 und BER bezogen werden. [14] Vorlesungsunterlagen von Herrn Andreas Steffen, Kommunikationssysteme (KSy), Block 7, Abstract Syntax Notation One ASN.1 [15] OCSP für Linux FreeS/WAN, Christoph Gysin, Simon Zwahlen, ZHW Winterthur, Oktober CryptoAPI [16] Adding Revocation Providers to CryptoAPI for Identrus Applications (Valicert and Microsoft Corporation) en-us/dnsecure/html/rpcrypto.asp 142

144 [17] Data Encryption with CryptoAPI wceosdev5/html/wce50conencryptdatausingcryptoapi.asp Kapitel 3: Certificate Revocation List (CRL) [18] IETF RFC 3280 PKIX - Certificate and CRL Profile Microsoft Unterlagen [19] Troubleshooting Certificate Status and Revocation List [20] Microsoft Whitepapers *** Certificate revocation ocs/en-us/sag_cs_certrevoke.asp [21] To configure CRL and delta CRL overlap period ocs/en-us/sag_cs_procs_crloverlap.asp [22] Establishing Certificate Revocation Policies en-us/dssch_pki_ulzk.asp [23] Buch: Microsoft Windows Server 2003 PKI and Certificate Security, Brian Komar with the Microsoft PKI Team, ISBN , 2004 Kapitel 4: Online Certificate Status Protcol (OCSP) [24] IETF RFC 2560 Online Certificate Status Protcol (OCSP) [25] OCSP-Responder von Flexsecure [26] OCSP-Responder von Keyon [27] OCSP: openvalidation [28] Hersteller Liste: CoreStreet's, Distributed Certificate Validation, Randy Bowman, Principal Systems Engineer OCSPv2 [29] Technische Universität Darmstadt m_pki/ausarbeitungen/fertigewebseiten/sebastiankanthak/ocsp/doc/ocsp-21.htm [30] OCSPv2 Internet Draft draft-ietf-pkix-ocspv2-ext-01.txt [31] OCSPv2 Internet Draft draft-meyers-pkix-ocsp-core-00.txt, December, txt 143

145 [32] Overview OCSPv2 [33] Future Directions for OCSP [34] gelöschte OCSPv2 Draftversion 3 ftp://sunsite.cnlab-switch.ch/mirror/internet-drafts/draft-ietf-pkix-ocspv2-03.txt [35] Integration of OCPv2, DPV & DPD Kapitel 4: Simple Certificate Validation Protocol (SCVP) [36] SCVP Internet Draft <draft-ietf-pkix-scvp-15.txt vom Juli 2004 [37] vorlesungen/v_ns_unterlagen/ns03-2-4h.pdf Microsoft Power Point PKI-PMI-21 [38] IETF RFC 3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements Internet Draft <draft-ietf-pkix-scvp-15.txt> vom Juli 2004 [38a] TELEMATICS: SCVP: Protokollabläufe [39] Von Hersteller Ascertia, TrustFinder SCVP Server Dokument, Requirements Overwiew Kapitel 7: Technische Facts [40] PKI Standards, Christ Mitchel, Information Security Group, Royal Holloway, University of London projects/pkiclub/pkistandards.ppt [41] Public Key Infrastructure Certificate Revocation List versus Online Certificate Status Protocol bdd5.shtml [42] PKIX-Mailing-List [43] Secorvo, Security Consulting, PKI-Unterstützung in Windows 2000 und Windows 2003 Server [44] ValiCert (PDF-Doku) Digital Certificate Validation: Technologies, Protocols and Infrastructure Introduction to CRTs Bücher und Diplomarbeiten [45] Diplomarbeit "Einsatz von digitalen Unterschriften und Zertifikaten im internationalen Bankenumfeld", Roland Sprecher [46] ]Digitale Unterschrift und PKI, Einführung in die modernen Sicherheitsverfahren und deren Problemfelder, Daniel Muster, 2. Auflage, ISBN

146 [47] Taschenbuch Rechnernetze und Internet; Erich Stein, Diplomarbeit PKI, PA D. Riedweg, H. Zürcher) [48] Aus Buch: Sicherheit und Kryptographie in Java [49] OCSP für Linux FreeS/WAN, Christoph Gysin, Simon Zwahlen, ZHW Winterthur, Oktober [50] Revokation von Public-Key-Zertifikaten: Java-basierter OCSP-Responder, Markus Heintel, Fachhochschule München, 14. März 2000 Unterlagen UBS [51] Powerpoint-Präsentation: UBS WM&&BB Wintel Environment, 24. Juni 2004, Joerg Rossow [52] Certificate Status Checking, White Paper: 11. Juni 2004, Peter Bodenmann [53] CA Implementation Considerations, Sandro Polenta [54] Certification Authority for W-XP, Architecture, Decisions and Measures, Sandro Polenta Referenzen CoreStreet Paul Ohrenberger SVP Sales and Marketing Keyon Martin Christinat CTO Ascertia Gavin Spencer Sytrust Florian Oelmaier Tumbleweed Emma Cunningham Alacris Conrad Bayer Malpani Consulting Services Ambarish Malpani, 145

147 Anhang Registry Eintrag Test 1: Zertifikat bei der CA anfordern damit die signiert und verschlüsselt werden kann. 1. User cpfister erfordert ein Zertifikat mit Template (TestUser2). Das Zertifikat kann für die Signierung und die Verschlüsselung der verwendet werden. 2. User nholenstein schreibt eine an User cpister (signiert und verschlüsselt) 3. User cpfister kann das öffnen und den Status des Zertifikates selbst überprüfen. 4. User cpfister schreibt eine an nholenstein zurück (signiert und verschlüsselt) 5. User nholenstein kann jetzt auch das Zertifikat von cpfister überprüfen. 146

148 Test 2 Zertifikate werden mit dem ReasonCode "Certificate Hold" gesperrt. Es erfolgt manuelle Publikation einer Full CRL. 1. Beide Zertifikate (nholenstein und cpfister) werden mit dem Status Certificate Hold gesperrt. 2. Es wird eine Full CRL manuell publiziert. 3. User nholenstein schreibt eine an User cpfister (signiert und verschlüsselt). Das Absenden der ist nicht mehr möglich. 147

149 Test 3 Zertifikate werden wieder von der Sperrliste entnommen. Es wird eine Full CRL manuell publiziert. 1. Die Zertifikate werden wieder gültig gemacht und von der Sperrliste entnommen. Es wird wiederum eine volle CRL manuell publiziert 2. User nholenstein schreibt an cfpister (signiert und verschlüsselt) 3. User cpfister möchte von User nholenstein öffnen. Die kann geöffnet und gelesen werden. 148

150 Test 4 Zertifikate werden mit dem ReasonCode "Certificate Hold" gesperrt. Es erfolgt manuelle Publikation einer Delta CRL. 1. Zertifikate (nholenstein und cpfister) werden mit dem Status CertificateHold gesperrt. 2. Es wird nur eine Delta CRL manuell publiziert. Base CRL Number = 446 DeltaCRLIndicator = User nholenstein möchte an User cpfister eine (verschlüsselt und signiert) 4. kann nicht versendet werden.(gleiche Meldung wie in Test 2) 149

151 Test 5 Zertifikate werden wieder von der Sperrliste entnommen. Es wird nur eine Delta CRL manuell publiziert. 1. Gesperrte Zertifikate werden wieder gültig gemacht 2. Es wird nur eine Delta CRL publiziert 3. cpfister schreibe an nholenstein verschlüsselt und signiert 4. Absenden ist wieder möglich RemoveFromCRL Wenn ein gesperrtes Zertifikat den Status CertificateHold hat, und dann wieder gültig gemacht wird, muss bei Delta CRL einen neuen Eintrag beim CRL Parameter RemoveFromCRL gemacht werden. Dieser Eintrag sagt, dass in der Base CRL der Eintrag existiert aber wieder rückgängig gemacht wurde. 150

152 Test 6 Die s, die mit einem gültigen Zertifikat signiert wurden, können nach einer Sperrung immer noch gelesen werden. Eine entsprechende Meldung weist jedoch darauf hin, dass das Zertifikat mittlerweile revoziert worden ist. 151