Kommunikation in einem Trustcenter

Transkript

1 Technische Universität Darmstadt Fachbereich Informatik Fachgebiet Kryptographie und Computeralgebra Prof. Dr. rer. nat. Johannes Buchmann Kommunikation in einem Trustcenter Intra Trustcenter Protocol Version 1.2 Entwurf und Design Diplomarbeit von Jochen Becker Betreuer: Dr.-Ing. Vangelis Karatsiolis Darmstadt, 20. Juli 2007

2 ii

3 Ehrenwörtliche Erklärung Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Darmstadt, am 20. Juli 2007 iii

4 Kurzdarstellung Ein Trustcenter besteht aus einzelnen Komponenten die miteinander interagieren. Zwingend notwendig für diese Interaktion ist die Kommunikation der einzelnen Komponenten untereinander. Dazu wird eine Protokoll benötigt, welches jegliche Art der Kommunikation in einer Trustcenterumgebung erfassen und verarbeiten beziehungsweise weitergeben kann. Dieses Protokoll muss auch hohe Sicherheitsanforderungen aus dem PKI-Umfeld erfüllen. In dieser Arbeit werden aktuell eingesetzte Protokolle für die Codierung von Informationen und Kommunikation innerhalb eines Trustcenters vorgestellt. Im Gegensatz zu den meisten verwendeten Protokollen basiert das Intra Trustcenter Protocol nicht auf dem nur maschinenlesbaren Datenformat ASN.1, sondern auf dem sowohl maschinen- wie auch menschenlesbaren Datenformat XML. Kern der hier vorliegenden Arbeit ist der Entwurf von Intra Trustcenter Protocol Version 1.2. Hierbei werden Anforderungsaspekte an ein Intra Trustcenter Management Protokoll anhand von Szenarien vorgestellt. Die für die Abdeckung dieser Szenarien notwendigen Nachrichten sollen modelliert und in Form eines XML-Schema implementiert werden. Im Anschluss soll der Fortschritt gegenüber der Vorgängerversion aufgezeigt und die Neuheiten nochmal zusammengefasst werden. Abschließend wird noch ein Ausblick auf mögliche Verbesserungen und Erweiterungen von Intra Trustcenter Protocol gegeben. iv

5 Inhaltsverzeichnis Kurzdarstellung Abbildungsverzeichnis Tabellenverzeichnis Quelltextverzeichnis iv vii ix xi 1. Einleitung 1 2. Public-Key Infrastrukturen Überblick Bestandteile einer Public Key Infrastruktur Registration Authority Certification Authority Flexiprovider Codierungsformate Extensible Markup Language Abstract Syntax Notation One Bewertung Trustcenter Management Protokolle Public Key Cryptography Standard # Public Key Cryptography Standard # XML Key Management Specification Certificate Management Protocol Szenarien Kernvorgänge Beantragung Ausstellung Auslieferung Aktivierung Veröffentlichung Erneuerung Revokation Weitere Vorgänge Gültigkeitsprüfung Externe Schlüsselerzeugung Vertrauensanker erneuern Informations- und Fehlerübermittlung v

6 Inhaltsverzeichnis 6. Intra Trustcenter Protocol Designziele Intra Trustcenter Protocol Version Intra Trustcenter Protocol Version Intra Trustcenter Protocol Version XML-Schema Definition Informationssicherheit Nachrichten Analyse Fazit und Ausblick Fazit zu Version Ausblick auf Intra Trustcenter Protocol Version A. ITP-Nachrichten Quelltexte 43 B. Intra Trustcenter Protocol Version 1.2 Schema 55 C. ITP-Tag Referenz 65 D. Vergleich ITP mit CMP 67 E. Gesetzestexte 69 E.1. Signaturgesetz E.2. Signaturgesetz 10 Absatz E.3. Signaturverordnung 5 Absatz 2 Satz E.4. Signaturverordnung 7 Absatz E.5. Signaturverordnung 15 Absatz 2 Satz 2b) Begriffe 71 Literaturverzeichnis 73 vi

7 Abbildungsverzeichnis 2.1. Struktur von Flexitrust Komponenten von Flexitrust Lebenszyklus eines Schlüssels Zertifizierungsvorgänge in einer PKI Revokation eines Zertifikats Ablauf einer OCSP Anfrage nach SigG Externe Schlüsselerzeugung Schlüsselerzeugung auf einer Chipkarte Übersicht über verschiedene Module in der PKI vii

8 Abbildungsverzeichnis viii

9 Tabellenverzeichnis 3.1. Gegenüberstellung ASN.1 und XML Felder des Kopfteils Felder des Fussteiles ITP Version 1.2 Nachrichtentypen Felder der CertificateRequest-Nachricht Felder der Activation-Nachricht Felder der Revocation-Nachricht Felder der Recovery-Nachricht Felder der CertificateTransport-Nachricht Felder der KeyTransport-Nachricht Felder der Information-Nachricht Felder der Notify-Nachricht C.1. ITP Version 1.0 XML-Tags im Überblick C.2. ITP Version 1.1 XML-Tags im Überblick ix

10 Tabellenverzeichnis x

11 Quelltexte A.1. Standardnachricht von ITP Version A.2. Syntax einer ITP-Nachricht Version A.3. Syntax einer ITP-Nachricht Version A.4. Standard CertificateRequest-Nachricht A.5. Standard Activation-Nachricht A.6. Kürzeste Activation-Nachricht A.7. Standard CertificateTransport-Nachricht A.8. Standard KeyTransport-Nachricht A.9. Standard Recovery-Nachricht A.10.Standard Revocation-Nachricht B.1. ITP 1.2 Schema D.1. Aktivierungsnachricht von ITP D.2. Aktivierungsnachricht in CMP xi

12 Quelltexte xii

13 1. Einleitung In heutigen Zeiten werden immer mehr Prozesse elektronisch abgebildet und durchgeführt. Da hierzu eine eindeutige Identifizierung von der beteiligten Komponenten notwendig ist, werden digitale Identitäten ausgestellt. Jede Komponente, somit auch jede Person, die an diesen Prozessen beteiligt ist, besitzt eine eigene eindeutige digitale Identität. Zum Speichern dieser Identitäten wird auf Public-Key-Verfahren zurückgegriffen. Hier erhält jede Komponente einen privaten Schlüssel, der niemandem weiter bekannt ist, und den dazugehörige öffentliche Schlüssel. Dieser wird von einer vertrauenswürdigen Instanz zusammen mit weiteren Informationen in einem Zertifikat gespeichert. Diese Zertifikate werden veröffentlicht, so dass sie für andere Komponenten und Dritte zugänglich sind. Eine Public-Key Infrastruktur (PKI) ist für diese Aufgaben konzipiert. In dieser werden Vertrauensmodelle abgebildet und ein strukturiertes Vertrauen etabliert. Innerhalb einer PKI gibt es den Trustcenter (TC), der die wichtigsten Komponenten bereitstellt. Alle Komponenten müssen untereinander Kommunizieren, um sich Informationen zu beschaffen und auszutauschen. Aktuell werden hierfür Protokolle verwendet die direkt an einer streng hierarchischen PKI Struktur festhalten und Zertifikate nach X.509 verarbeiten. Auch ein Verknüpfung von mehreren Protokollen wird zur Erfüllung der Aufgabe der Kommunikation in einem TC benutzt. Ein Problem dieser Protokolle ist die Verwendung von Codierungsformaten, die die Daten als Binärcode übertragen. Ein direkte Überprüfung dieser Daten ist durch ein reines Betrachten des Paketes nicht möglich. Die Anforderungen die an eine PKI und vor allem den TC gestellt werden, ergeben sich aus aus allgemeinen Anforderungen an IT-Systeme und den Sicherheitsanforderungen aus dem PKI-Umfeld. Weiterhin können sich Sicherheitsanforderungen aus dem speziellen Anwendungsgebiet oder auch aus gesetzlichen Vorgaben ergeben. Für diese Aufgaben wurde das Intra Trustcenter Protocol (ITP) entworfen und bereits einer ersten Revision unterzogen. Die Konzepte und Ideen auf denen diese Arbeit aufbaut, sind bereits 2004 veröffentlicht worden [28]. Ziel dieser Arbeit ist das Design und der Entwurf von ITP Version 1.2 und die erstmaligen Einführung einer formellen Beschreibung der Nachrichten. Hierfür soll auf XML-Schema zurückgegriffen werden. Die Struktur und die einzelnen Elemente des Schema sollen aufgezeigt und erklärt werden. Dieses Schema soll die bisherigen freien Nachrichten ersetzen und zukünftige Nachrichten ohne Verletzung der Allgemeinheit der Nachrichten vereinheitlichen. Es soll ein Meilenstein auf dem Weg zur ITP Version 2.0 bilden. Das Schema soll generisch genug angelegt werden, so dass andere Konzepte und Strukturen von Vertrauensmodellen durch ITP auch erfasst werden können. Dabei soll auf vorhandene und etablierte Mechanismen zurückgegriffen werden. Die vorliegende Arbeit ist wie folgt aufgebaut: Nach der Einführung in Kapitel 1 wird in Kapitel 2 eine Überblick über eine PKI gegeben. Die einzelnen Hauptbestandteile eines TC werden näher erläutert. In Kapitel 3 werden die zwei Codierungsformate XML und ASN.1 vorgestellt und bewertet. Kapitel 4 gibt einen Einblick in die vier am weitest verbreiteten 1

14 1. Einleitung Management-Protokolle (PKCS #7, PKCS #10, XMKS und CMP). Die Szenarien die im PKI Umfeld auftreten und für die Entwicklung von ITP 1.2 zu Grunde liegen werden in Kapitel 5 aufgeführt. Hierbei gibt es eine Trennung in die Kernvörgänge und weitere Operationen in einem TC. In Kapitel 6 wird ITP vorgestellt. Zu Beginn werden die Designziele von ITP aufgeführt und die Versionen 1.0 und 1.1 vorgestellt. Der Abschnitt 6.2 befasst sich mit dem Entwurf von Version 1.2. In diesem werden die einzelnen Nachrichten spezifiziert und deren Elemente und Attribute vorgestellt. Im Anschluss wird der Fortschritt gegenüber der direkten Vorgängerversion analysiert. Kapitel 7 bildet das Fazit zu ITP Version 1.2 und gibt einen Ausblick auf die Version 2.0. Alle in dieser Arbeit verwendeten Quelltexte sind in Anhang A abgedruckt. Dort finden sich Beispiele für die ITP-Nachrichten in Version 1.2. Das gesamte Schema von ITP Version 1.2 ist in Anhang B abgedruckt. Dies bietet die Möglichkeit eines Einblicks in die genaue Spezifikation der Nachrichten. Im Vergleich dazu ist eine TAG-Referenz der beiden Vorgängerversionen in Anhang C gegeben. Ein direkte Vergleich zwischen ITP und CMP wird anhand der Aktivierungsnachricht in Anhang D geben. Die in dieser Arbeit verwendeten Gesetzesgrundlagen finden sich in der aktuell gültigen Fassung in Anhang E. 2

15 2. Public-Key Infrastrukturen 2.1. Überblick Eine Public-Key Infrastruktur (PKI) bietet die Möglichkeit Vertrauen zu etablieren. Jeder Benutzer und jedes System in diesem Umfeld wird mit mindestens einer digitalen Identität ausgestattet. Durch eine hierarchische Struktur ergibt sich ein Vertrauensverhältnis, welches die PKI selbst schützen muss. Der klassische technische Aufbau besteht aus einer Registration Authority (RA) und einer Certification Authority (CA) [19]. Es soll möglich sein die einzelnen Komponenten dezentral zu platzieren und gegebenenfalls auch mehrere Instanzen einer Komponente zu haben. Auch in der Wahl der verwendeten Algorithmen wird Flexibilität gefordert. Ohne großen Aufwand sollte ein zu schwacher Algorithmus gegen einen stärkeren Algorithmus ausgetauscht werden können Bestandteile einer Public Key Infrastruktur Am Beispiel der PKI von Flexitrust [45] werden in diesem Unterabschnitt die wichtigsten in einem Trustcenter beteiligten Komponenten aufgeführt und erklärt. Die Abbildung 2.1 zeigt die Struktur der PKI-Software. Flexitrust gliedert sich in die drei Hauptkomponenten Registration Authority, Key Authority und Certificate Management Authority (Abbildung 2.2). Flexitrust unterscheidet sich von der klassischen Aufteilung insofern, dass die Aufgaben der CA in eine Offline-Komponente (Key Authority) und eine Online-Komponente (Certificate Management Authority) aufgeteilt sind. Die kryptographischen Algorithmen sind in den Flexiprovider ausgelagert Registration Authority Die Aufgabe einer Registration Authority (RA) ist die gesamte verwaltungstechnische Erfassung der Benutzer beziehungsweise der untergeordneten Instanzen einer PKI, welche ein Zertifikat benötigen. Sie kann dezentral organisiert werden. Somit können mehrere RA innerhalb einer PKI vorhanden sein. Ist dies der Fall, so muss bei der Namensvergabe darauf geachtet werden, dass die Namen eindeutig vergeben werden und eindeutig bleiben. Die Hauptaufgabe der RA ist die eindeutige und richtige Zuordnung der Instanz (Sub-CA, Host, Benutzer), die ein Zertifikat erhalten möchten. Diese Kontrolle kann zur Zeit nur durch einen Menschen erfolgen, da es für ein TC anfangs nicht möglich ist, einen Mitarbeiter direkt erkennen und zuordnen zu können. Hat dieser jedoch innerhalb der PKI einmal eine Identität erhalten, so kann man den Benutzer anhand dieser Identität identifizieren und weitere Vorgänge automatisieren. Diese Bindung zwischen dem Antragsteller, dessen 3

16 2. Public-Key Infrastrukturen Abbildung 2.1.: Struktur von Flexitrust Antrag und der Bestätigung durch die RA muss durch den ganzen Prozess der Ausstellung der digitalen Identität nachvollziehbar und geschützt sein Certification Authority Die Certification Authority (CA) ist für die gesamte Verwaltung der Zertifikate innerhalb einer PKI-Umgebung verantwortlich. Es werden Registrierungsanfragen entgegengenommen, Schlüssel erzeugt, Zertifikate erstellt und diese signiert. Bei Flexitrust ist die CA in Offline- und Online-Komponente unterteilt. Die Offline-Komponente nimmt hierbei die sicherheitskritischen Aufgaben wahr. Die Online-Komponente ist die direkte Schnittstelle zu den Benutzern. Offline-Komponente - Key Authority Die Offline-Komponente, im folgenden Key Authority (KA) genannt, ist für alle Operationen mit dem Schlüssel innerhalb der PKI verantwortlich [47]. Sie ist das am stärksten zu schützende Element einer PKI. Hierbei gilt es den gesamten Lebenszyklus eines Schlüssels zu schützen (Abbildung 2.3). Angefangen mit der sicheren Erzeugung, über die Speicherung auf einer Chipkarte oder als Soft-Token [40], den geschützten Transport des privaten Schlüsselteiles zum Benutzer, Verknüpfung des öffentlichen Schlüssels mit den Benutzerdaten in Form eines Zertifikats, Signatur des Benutzerzertifikats und die Bereitstellung des öffentlichen Zertifikats für den öffentlichen Verzeichnis. Hinzu kommt, wenn es erforderlich ist, eine Sicherung und Archivierung des privaten Schlüssel innerhalb der PKI für die Möglichkeit der Wiederherstellung bei Verlust. Diese letzt genannten Operationen sind kritische Vorgänge bei denen die Sicherheitsanforderungen meist über das Vier-Augen- 4

17 2.2. Bestandteile einer Public Key Infrastruktur Abbildung 2.2.: Komponenten von Flexitrust Prinzip hinausgehen. Um den Lebenszyklus eines Schlüssels zu komplementieren sei an dieser Stelle die Benutzung und die Zerstörung nach Ablauf der Gültigkeit oder im Falle der Revokation erwähnt. Die Revokationsinformationen werden ebenfalls von der KA erstellt. Eine KA erstellt und bearbeitet jeden Schlüssel beziehungsweise jedes Zertifikat einer PKI und daher gilt hier sehr starker Schutz. Deshalb ist die KA eine Offline Komponente, dass bedeutet sie ist in keinerlei Netzwerk integriert. Diese zusätzliche Sicherheitsmaßnahme zieht auch eine Komplexitätssteigerung der Anforderung an ein Managementprotokoll nach sich. Online-Komponente - Certificate Management Authority Die direkte Benutzerinteraktion übernimmt die Online-Komponente Certificate Management Authority (CMA). Sie übernimmt das Management der Zertifikate und verwaltet die Sperrinformationen von Zertifikaten. Sie sorgt für die Verfügbarkeit von Sperrinformationen. Diese kann entweder durch die Veröffentlichung der Certificate Revocation List (CRL) geschehen oder direkt mittels des Online Certificate Status Protocols (OCSP) [36] 5

18 2. Public-Key Infrastrukturen Schlüsselerzeugung Hinterlegung Wiederherstellung Speicherung Transport Benutzung Zerstörung Abbildung 2.3.: Lebenszyklus eines Schlüssels verfügbar sein. Die gesamte Benutzerinteraktion läuft über die CMA ab. Die Aufgaben hierbei sind der Versand der Zertifikate, die Auslieferung der Tokens, die Erstellung von Pin-Briefen und die Annahme sowie Weiterleitung der Sperrung eines Zertifikats. Ist die Auslieferung eines Zertifikats erfolgt und dieses aktiviert worden, so wird das dazugehörige öffentliche Zertifikate durch die CMA in einem zentralen Verzeichnisdienst [27] bereitgestellt. Hierzu wird eine gemeinsame Datenbank mit der RA gepflegt. Externe Schlüsselerzeugungseinheit Aus Sicherheitsgründen kann es notwendig sein ein Schlüsselpaar nicht in der KA sondern in einer externen Einheit zu erzeugen. Gründe hierfür können sehr hohe Sicherheitsanforderung an den Schlüssel sein oder dass die Anzahl der zu erzeugenden Schlüsselpaare einer KA überfordert. Hierbei muss sichergestellt sein, dass die generierten Schlüssel, falls der private Schlüssel transportiert werden müsste, stark geschützt sind. Eine Methode kann der Einsatz von Chipkarten sein. Auf diesen ist meist eine direkte Schlüsselerzeugung möglich. Damit ist der private Schlüssel durch das Betriebssystem und den Aufbau der Chipkarte vor dem Auslesen und damit dem Zugriff geschützt. Ist eine direkte Erzeugung auf der Chipkarte nicht möglich, so wird der private Schlüssel auf die Karte geschrieben und kann nicht mehr ausgelesen werden Flexiprovider Der Flexiprovider stellt für Flexitrust alle kryptographischen Algorithmen zur Verfügung. Innerhalb des Flexiproviders können kryptographische Algorithmen zur Verschlüsselung, Signaturerzeugung und zur Ermittelung von Prüfsummen schnell und sicher implementiert werden. Flexitrust nutzt diese Schnittstelle um verschiedene Algorithmen einfacher verwenden zu können. Somit ist jeder im Flexiprovider implementierte und geprüfte Algorithmus unmittelbar für die gesamte PKI von Flexitrust verfügbar. Der Flexiprovider kann auch als eigenständige Bibliothek für kryptographische Funktionen in Anwendungen 6

19 2.2. Bestandteile einer Public Key Infrastruktur integriert werden. Er basiert auf der Java Cryptography Architecture (JCA/JCE) [44] und ist zu dieser kompatibel. Die Ausgliederung der Algorithmen sorgt für eine einfachere Evaluation des Quelltexts und damit einer Erhöhung der Sicherheit in der gesamten PKI. Sind neue Algorithmen zu implementieren so erfolgt dies nur an einer Stelle. Die Implementierung muss einmalig evaluiert werden. Dadurch ist es möglich die Sicherheit in der PKI trotz neuer Algorithmen aufrecht zu erhalten. 7

20 2. Public-Key Infrastrukturen 8

21 3. Codierungsformate Die vorhandene Heterogenität der heutigen IT-Systemen im Bereich der Hardware, Betriebssysteme, Anwendungen und Programmiersprachen sorgt für eine Vielzahl unterschiedliche verwendeter Datenformate. Die Darstellung von Zeichenketten, Zahlen, Zeitangaben und anderen Informationen finden sich oft in jeweils eigenen Datentypen wieder. Ein direkter Austausch zwischen diesen Systemen ist nicht möglich. Die Vernetzung der IT-Systeme und damit die Möglichkeit der direkten Datenübertragung von einem System zu einem Anderen bringt die Notwendigkeit für mindestens ein gemeinsames Format mit. Die zwei Codierungsformate Extensible Markup Language und Abstract Syntax Notation One sorgen für eine vereinheitliche Darstellung von Daten. Sie sind beide standardisiert und somit kann für eine Datenübermittlung auf diese zurückgegriffen werden Extensible Markup Language Durch die klare Struktur von Extensible Markup Language (XML) [12] ist es möglich Daten unabhängig von der Darstellung zu strukturieren und zu erfassen. Mit Hilfe der XML-TAGs [20, 34] kann eine Datendarstellung in XML jederzeit eindeutig interpretiert werden, da die zusammengehörigen Elemente klar erkennbar sind. Die Übertragung selbst erfolgt in Form von Text-Zeichen. Somit kann jedes System und jede Plattform ohne großen Aufwand die Daten einlesen und verarbeiten. Anschließend können die Daten auf verschiedensten Wegen übermittelt werden. Angefangen mit einfachen Dateien auf Speichersticks, über oder auch eine direkte Netzwerkverbindung sind möglich. XML ermöglicht die direkte Darstellung der Informationen, die signiert oder verschlüsselt werden sollen. Dazu kann auf die zwei vorhandenen Standards XML Digital Signature [5] und XML Encryption [4] zurückgegriffen werden. XML bietet durch seine Klartextdarstellung die Möglichkeit die Daten direkt vor und nach der Verarbeitung zu betrachten und zu analysieren. Sollte hierbei ein Fehler festgestellt werden, sei es durch eine maschinelle syntaktische Prüfung oder eine semantische Prüfung durch eine Person, so kann der Fehler unverzüglich korrigiert werden. Diese Korrektur kann automatisch und auch manuell erfolgen. Am Ende sollte das gesamte veränderte Dokument erneut überprüft werden. Mit XML-Schema [21] bietet XML selbst eine Schemasprache an, welche diesen Vorgang durch die Vorgabe einer klaren Struktur ermöglicht. XML leistet in der Kryptographie durch seine einfache und klare Struktur einen bedeutenden Vorteil im Bereich der Langzeitarchivierung und Darstellung von Informationen. Es ist ein offenes Format und kann somit beliebig erweitert werden. Auch ist bei zukünftigen Rechnersystemen eine Verarbeitung der Daten ohne großen Aufwand möglich. 9

22 3. Codierungsformate 3.2. Abstract Syntax Notation One Die Abstract Syntax Notation One (ASN.1) wurde als gemeinsamer Standard der International Telecommunication Union Telecommunication Standardization Sector [2] und der International Organization for Standardization [8] verabschiedet. Es ist als Protokoll in der Anwendungsschicht angesiedelt und nutzt in der darunter liegenden Darstellungsschicht verschiedene Encoding Rules um Daten für den Transport vorzubereiten. Die meist verwendeten Encoding Rules sind: Basic Encoding Rule (BER), Canonical Encoding Rule (CER) und Distinguished Encoding Rule (DER) [3]. Daten werden nach einer diesen Encoding Rules binär codiert und anschließend übermittelt. BER, CER und DER bieten in der Verarbeitung eine kompaktere Darstellung der Daten und ermöglichen somit eine schnellere Datenübertragung. Mit der XML Encoding Rule (XER) [1] besteht die Möglichkeit der Codierung von Daten in XML-Syntax. Es ist nach [7] sogar vorgesehene XML Schema Definitionen in ASN.1 zu konvertieren. Aktuell wird ASN.1 als Standardverfahren für die Codierung und Übertragung von Zertifikaten oder Revokationslisten verwendet. Jedoch liefert ASN.1 eine recht breite Angriffsfläche, da die Parser und Interpreter in der Verarbeitungssoftware durch die komplexe Struktur oft fehlerhaft implementiert sind und somit nicht korrekt arbeiten. Eine Fehlersuche ist nur schwer möglich, da durch eine Betrachtung des Datenstroms kein direkter Zugang zu den Daten vorhanden ist und somit nicht aufgedeckt werden kann, welche Daten in die weiterverarbeitende Software gelangen. Einen tieferen Einblick in ASN.1 liefern die Werke ASN.1 Complete [32] und ASN.1 Communication [17] Bewertung Da IT-Systeme Daten in einer Binärcodierung verarbeiten ermöglicht ASN.1 durch seine Darstellung in Binärcode ein direkte Verarbeitung der Daten. Im Gegensatz zu XML, welches einen Umwandlungsschritt der Text-Zeichen in binären weiterverarbeitbaren Code benötigt. Verschiedene Systeme benutzen auch unterschiedliche Binärcodierungen und somit kann es bei ASN.1 vorkommen, dass Daten falsch interpretiert werden. Durch den überall notwendigen Zwischenschritt bei XML ist es möglich die Daten für jedes System zur Verfügung zustellen und vor der Verarbeitung selbst in ein möglichst effizientes und auf die Plattform angepasstes Format zu codieren. Beide Formate können in Software implementiert werden. Die Programmierung eines ASN.1 Parsers ist auf Grund der Komplexität von ASN.1 sehr schwer und eine fehlerhafte Implementierung kann dazu führen, dass Softwaresysteme abstürzen. Die Ursache hierfür liegt in fehlerhaft interpretierten oder bewusst falsch codierten ASN.1 Nachrichtenpaketen, die verarbeitet werden sollten. XML hat durch seine klare Darstellung und der Möglichkeiten sowohl einer syntaktischen als auch einer semantischen Überprüfung vor der Verarbeitung, Vorteile gegenüber ASN.1. Durch die Anordnung der TAGs und die klare Vorgabe mittels einer Schema-Definition kann der Parser die Daten eindeutig Interpretieren und zur Verarbeitung weitergeben. XML unterstützt durch seine Menschenlesbarkeit eine einfache Fehlersuche, welche in ASN.1 durch die Binärcodierung nicht möglich ist. 10

23 3.3. Bewertung Der entscheidender Vorteil von XML in einem Sicherheitsbereich ist die Menschenlesbarkeit und eine daraus resultierende Möglichkeit der semantischen Überprüfung. Ein Anwender oder Administrator kann jedes Datenpaket betrachten und einer semantischen Prüfung unterziehen. Hierbei kann Punkt für Punkt überprüft werden, ob alle notwendigen Daten korrekt angegeben wurden oder keine zusätzliche störende gar schädlichen Information enthalten sind. Wird ein Problem erkannt, so kann unmittelbar darauf reagiert werden. Bei ASN.1 ist diese semantische Überprüfung nicht einfach möglich. Wählt man die Codierung nach ASN.1 - DER, so werden die Daten in einer langen Reihe von Datentyp - Wertlänge - Wert (Type Length Value) übermittelt. Dies unübersichtliche Darstellung ist kaum menschenlesbar. Durch die Menschenlesbarkeit wird eine Evaluation vereinfacht und XML unterstützt aktiv Audit-Prozesse. Diese Prozesse finden sich im Bereich der Qualitätssicherung in Form von Vorgangsbeschreibungen oder Protokollierung wieder. Die Signatur oder Verschlüsselung von Binärcode ist im Sicherheitsumfeld stark umstritten, da der Signierer hier nicht sehen kann, was er genau unterschreibt. So besteht die Möglichkeit bei der Codierung der Daten in Binärcode zusätzliche Informationen einzuschleusen, welche dann unbemerkt mit signiert oder verschlüsselt werden. Dies ist bei XML nicht möglich, da hier mit Klartext gearbeitet wird. Die Daten sind vor einer Signatur oder Verschlüsselung lesbar und der Signierer weiß was er signiert beziehungsweise verschlüsselt hat. Es soll stets gelten What you see is, what you sign [43]. Ein Ausnahme bilden verschlüsselte Daten, sowie die Signaturen selbst. Diese können nur als binäre Daten gespeichert und dem entsprechend übermittelt werden. XML ist ohne Probleme von jedem IT-System lesbar und auf lange Sicht eine Option zur Speicherung und Strukturierung von Daten. Im Bereich der Langzeitsicherheit und Langzeitarchivierung von digitalen oder digitalisierten Daten wird fast ausschließlich mit XML als Codierungsformat gearbeitet [31]. Ein abschließenden Überblick über die zwei Codierungsformate inklusive eine groben Bewertung findet sich in Tabelle 3.1. XML ASN.1 maschinenlesbar + + menschenlesbar + - Softwareimplementierung + 0 Langzeitlesbarkeit + 0 Syntaktische überprüfbar + + Semantisch überprüfbar + - Legende: + = Vorteil / 0 = neutral / - = Nachteil Tabelle 3.1.: Gegenüberstellung ASN.1 und XML 11

24 3. Codierungsformate 12

25 4. Trustcenter Management Protokolle In diesem Kapitel werden aktuell verwendete Trustcenter Management Protokollen vorgestellt. Es werden die vier Protokolle Public Key Cryptography Standard #7 und #10, XML Key Management Specification und Certificate Management Protocol betrachtet. XML Key Management Specification verwendet, wie der Name schon erahnen lässt, als Codierungsformat XML die restlichen Protokolle nutzen ASN.1. Weiterhin gibt es die folgende Protokolle, auf die hier im einzelnen nicht eingegangen wird: Certificate Request Message Format [42], Certificate Message Syntax [24] und Certificate Management Messages over CMS [37] Public Key Cryptography Standard #7 Public Key Cryptography Standard (PKCS) #7 [39] ist ein Standard für eine Datenübertragung. Er stellt vier verschiedene Datentypen bereit in die Informationen eingebettet und übermittelt werden können: Klartextinformationen, signierte Informationen, verschlüsselte Informationen und signierte eingepackte Informationen. Es besteht auch die Möglichkeit diese Datentypen ineinander zu Schachteln. PKCS #7 ist als Container zu verstehen, in den man beliebige viele Informationen einlagern und diese anschließend dem Empfänger bei Bedarf signiert und oder verschlüsselt zukommen lassen kann. Es gibt keine spezifischen Festlegungen oder Strukturierung der Daten. Ein Anwendungsgebiet ist der Datenverkehr via . Hier wird eine Absicherung mit S/MIME [18] vorgenommen. S/MIME selbst benutzt PKCS #7 als Container für die Information. Diese werden einfach eingebettet, übermittelt und auf der Gegenseite wieder ausgepackt Public Key Cryptography Standard #10 PKCS #10 [41] erfasst nur die Anforderung auf die Signatur eines Zertifikats. Diese Anfrage muss den eindeutigen Namen des Anfragenden, das heißt den öffentlichen Schlüssel, enthalten. Die gesamten Daten der Anfrage müssen mit dem privaten Schlüssel des Anfragenden unterzeichnet sein. Die Anfrage enthält einen Identifikator des Signaturalgorithmus und die Signatur des Anfragenden. Optional sind weitere Attribute möglich, welche dann ebenfalls in die Signatur einfließen. Diese Nachricht wird zur Signatur an die Zertifizierungsstelle geschickt. Die Rücksendung eines Zertifikats in Form eines X.509 Zertifikats [26] ist nicht mehr Bestandteil von PKCS #10. Hierfür wird auf andere Verfahren, beispielsweise das zuvor erwähnte Protokoll PKCS #7, zurückgegriffen. 13

26 4. Trustcenter Management Protokolle Aktuell wird dieser Standard in vielen PKI-Umgebungen unter anderem auch Flexitrust verwendet, um die Zertifikatsanfragen entgegen zunehmen XML Key Management Specification Extended Key Management System Version 2.0 (XKMS) [23] ist ein auf XML-basierendes Protokoll. XKMS soll als Webservice-Schnittstelle für die Benutzer die komplizierten und komplexen Vorgänge einer PKI verbergen. Für das Protokoll selbst muss keine PKI gemäß X.509 oder PGP [13] vorhanden sein. Jedoch ist dieses Protokoll mittels einer API darauf ausgelegt, solche Infrastrukturen zu unterstützen. XKMS greift für die Verarbeitung auf die Standards XML Digital Signature und XML Encryption zurück. Es teilt sich in zwei Bereiche XML Key Information Service Specification (X-KISS) und XML Key Registration Service Specification (X-KRSS). X-KISS als direkte Benutzerschnittstelle bearbeitet die Informationsauskünfte über Zertifikate. Es kann die Lokalisierung der Informationen über ein Zertifikat oder den verwendeten Schlüssel vornehmen, sowie in einem zweiten Schritt die Informationen überprüfen. Hierbei kann die Gültigkeit der Zertifikatsinformationen sowie der eigentlichen Signatur abgefragt werden. Zusammengefasst kann man sagen, dass X-KISS die Operationen rund um das XML Digital Signature Element <KeyInfo> für den Benutzer transparent anbietet. X-KRSS deckt die Aufgaben der Verwaltung von Zertifikaten ab. Unter anderem sind die Registrierung von Zertifikaten und die Verknüpfung von Zertifikat mit dem dazugehörigen Schlüssel angebotene Operationen. Ebenso ist die Neuausstellung, die Revokation und auch eine Wiederherstellung des privaten Schlüsselteiles in der API vorgesehen. Wird nur eine öffentlicher Schlüssels verarbeitet, so ist auch eine Überprüfung auf den Besitz des passenden privaten Schlüssels möglich. Das Protokoll kann direkt mit RSA und DSA Schlüsseln umgehen, darüber hinaus bietet es selbst eine Umgebung, die die Anbindung von weiteren und eventuell neueren Algorithmen ermöglicht. Aktuell wird XKMS zum Beispiel in einem Grid Computing Projekt verwendet [38] Certificate Management Protocol Das Certificate Management Protocol (CMP) [11] ist im September 2005 eingereicht worden. Es arbeitet zusammen mit dem Protokoll Certificate Request Message Format (CRMF) [42], welches zum gleichen Zeitpunkt eingereicht wurde. Mit dieser Veröffentlichung haben beide Protokolle ihre Vorgänger abgelöst. Die erste Version von CMP und CRMF [10, 35] kannte keine optionalen Felder. Sind Informationen nicht angegeben worden und wurden sie für den weiteren Verlauf nicht nötig, so sind diese an sich Pflichtelemente nicht ausgefüllt. Die Nachfolge Version führte als eine Änderung optionalen Elemente ein und somit gab es die Möglichkeit legal Elemente auslassen zu können. CMP ist entwickelt worden, um die PKI-Struktur sowie den Zertifikateaufbau nach X.509 zu verwalten. Es ermöglicht die Kommunikation zwischen den einzelnen Komponenten einer PKI, sowie einem Clientsystem und der CA. Durch die Vorgabe der Struktur und der Inhalte der PKI wurde das gesamte Protokoll genau daraufhin ausgerichtet. Es werden sämtliche Elemente in den Zertifikaten unterstützt und eine Kommunikation ist zwi- 14

27 4.4. Certificate Management Protocol schen der RA, CA, einem Verzeichnisdienst sowie Clientsystem möglich. Der Transport der Nachrichten ist nicht vorgegeben und kann somit auf verschiedene Arten erfolgen. In vielen Nachrichten ist ein Handshake-Verfahren eingebaut, welches nur bei einer direkten Netzwerkverbindung funktioniert. Im RFC zu CMP sind verschiedene Szenarien aufgeführt die CMP komplett unterstützt. CMP behandelt viele verschiedene Situationen mit eigenen Nachrichten und Mechanismen. Diese vielen vorgegebenen Nachrichten sind eine gute Grundlage für eine Implementierung, sie ist jedoch sehr speziell und nur mit hohem Aufwand komplett zu bewerkstelligen. Viele der vorgesehenen Mechanismen sind so spezifisch, dass sie außerhalb des vorgesehenen Rahmens nur durch spezielle Anpassungsschritte verwendet werden können. Es ist zur starr, als das es auf anderen PKI-Modellen sinnvoll eingesetzt werden könnte. 15

28 4. Trustcenter Management Protokolle 16

29 5. Szenarien In diesem Kapitel werden Szenarien aus dem Bereich einer Public-Key Infrastruktur aufgezeigt. Zur Vereinfachung ist die PKI in der Struktur Benutzer, RA, CA und Verzeichnisdienst gegeben. Die in Kapitel 2 vorgestellten Komponenten RA und CMA sind in der CA zusammengefasst. Im Ersten Abschnitt werden die Vorgänge aufgeführt, die unmittelbar mit dem Zertifikat zusammenhängen oder an dieses geknüpft sind. Hierbei handelt es sich um die Beantragung, Ausstellung, Auslieferung, Aktivierung, Veröffentlichung des öffentlichen Teiles, Erneuerung und Revokation des Zertifikats. Der Zweite Abschnitt befasst sich mit den Verwaltungsoperationen, die von Dritten gegenüber der PKI oder dem Zertifikat erfolgen. Betrachtet wird die Überprüfung des Zertifikats mittels Certificate Revocation List, Delta Certificate Revocation List oder Online Certificate Status Protokoll und die externe Schlüsselerzeugung. Ein weiterer verwaltungstechnischer Vorgang ist die Erneuerung des Vertrauensankers, welcher zu Ende des Abschnitts erläutert wird Kernvorgänge In diesem Abschnitt werden die unmittelbaren Vorgänge erläutert, welche vom Erlangen bis zum Zurückziehen eines Zertifikats notwendig sind. Zur besseren Übersicht sind in Abbildung 5.1 alle Vorgänge und beteiligten Komponenten dargestellt. RA 1. Beantragen 2. Ausstellen 4. Aktivieren Benutzer 3. Ausliefern Verzeichnisdienst CA = KA & CMA 5. Veröffentlichen Abbildung 5.1.: Zertifizierungsvorgänge in einer PKI 17

30 5. Szenarien Beantragung Bei einer Beantragung eines neuen Zertifikats werden die persönlichen Daten des Benutzers durch die RA geprüft und ihre Echtheit bestätigt. Anhand dieser Daten wird ein Zertifikat für den Benutzer ausgestellt. Es besteht die Möglichkeit, dass der Benutzer nur die Zertifizierung seines öffentlichen Schlüssels haben möchte. Dieser Schlüssel muss dann bei Beantragung vorliegen und wird an die CA weitergeleitet. Für eine spätere Überprüfung auf die Echtheit des Benutzers kann ein Transportpasswort verwendet werden. Es besteht auch die Möglichkeit, dass ein Benutzer ein Revokationspasswort festlegt, mit dem er später sein Zertifikat revozieren kann und es selbst vor einer nicht autorisierten Revokation schützt. Sind keine Passwörter angeben, so werden diese meist von der CA erstellt und nur dem Benutzer zugänglich gemacht Ausstellung Von den validierten Daten des Benutzers werden alle notwendigen Daten für die Erstellung des Zertifikats an die CA weitergeleitet. Bringt der Benutzer bereits einen öffentlichen Schlüssel mit, so ist dieser auf dem Weg zur CA gegen einen Austausch und eine Manipulation zu schützen. Der bereits vorhandene oder ein neu zu erzeugender Schlüssel wird in einem Zertifikat mit der Benutzeridentität verbunden. Dieses Zertifikat wird anschließend von der CA signiert und ist damit in die Hierarchie der PKI eingeordnet Auslieferung Bei der Auslieferung wird das fertige Zertifikat dem Benutzer übermittelt. Ein Schutz bei der Auslieferung bietet das Transportpasswort. Es besteht die Möglichkeit, dass dieses von der PKI vorgegeben wird oder der Benutzer es bei der Beantragung bereits hinterlegt hat. Das Zertifikat und der private Schlüssel wird anschließend mit dem Transportpasswort verschlüsselt und dem Benutzer übermittelt. Dieser kann als einziger Geheimnisträger das Zertifikat gültig entschlüsseln. Falls es sich um die Auslieferung eines reinen öffentlichen Zertifikats handelt, der private Schlüssel nicht von der PKI selbst erzeugt wurde, so ist ein Proof-of-Possession-Mechanismus (PoP) nötig. Mittels diesem Verfahren muss der Benutzer nachweisen, dass er im Besitz des korrespondierendem privaten Schlüssels ist und somit auch gültiger Empfänger für das Zertifikat. Diese Überprüfung kann auch bei der Beantragung erfolgen und wäre dann zum Zeitpunkt der Auslieferung nicht mehr notwendig Aktivierung Im gewöhnlichen PKI Umfeld ist eine Aktivierung eines Zertifikats nicht notwendig. Es wird davon ausgegangen, dass ein Zertifikat mit der Auslieferung als gültig anzusehen ist. Jedoch ist für die Einhaltung des deutschen Signaturgesetzes (E.3) eine Aktivierung zwingend notwendig. Der Benutzer muss das Zertifikat aktivieren und damit nachweisen, dass er es erhalten hat und verwenden kann. Gegebenenfalls erfolgt in diesem Schritt eine 18

31 5.1. Kernvorgänge Überprüfung gemäß der Forderung nach PoP. Hierfür könnte das Aktivierungspasswort mit dem öffentlichen Schlüssel verschlüsselt sein. Für die Aktivierung eines Zertifikats muss dieses eindeutig zugeordnet werden können. Ebenso muss diese Nachricht vom Benutzer bis zur CA unverändert übertragen werden oder eine Veränderung erkennbar sein. Es sollte jedoch dem Benutzer ermöglicht werden, eine Aktivierung auch zu verweigern. Gründe hierfür wären eine Änderung der Policy, welche an das Zertifikat geknüpft ist, nicht ausreichende Sicherheitsstandards (Schlüssellänge zu kurz oder Verwendung eines falschen kryptographischen Verfahrens) oder im schlimmsten Fall eine nicht aufgeforderte beziehungsweise nicht reguläre Erneuerung des Zertifikats Veröffentlichung Um Dritten die Möglichkeit der Überprüfung einer Signatur oder die Übermittlung von verschlüsselten Daten zu geben, sind die öffentlichen Zertifikate in einem Verzeichnisdienst gespeichert. Dritte können das Zertifikat abrufen und die darin enthaltenen Informationen überprüfen und nutzen. Eine Veröffentlichung des Zertifikats kann auch unterbunden beziehungsweise unterdrückt werden. Diese Verzeichnisdienst ist meist als Lightweight Directory Access Protocol organisiert [27] Erneuerung Wird ein Zertifikat verlängert, so muss ein Neues mit dem bereits gegebenem öffentlichen Schlüssel erstellt werden. Die Erneuerung erfolgt in den Schritten: Beantragung, Ausstellung, Auslieferung und Veröffentlichung. Eine erneute Überprüfung auf den Besitz des privaten Schlüssel ist nicht notwendig, da der Benutzer diesen bereits verwendet hatte und demnach besitzt. Für den Fall, dass ein neuer Schlüssel notwendig und verwendet ist, kann erneut eine Prüfung mittels PoP erfolgen. Ebenso kann bei der Beantragung auf bereits im abgelaufenen oder ablaufenden Zertifikate enthaltenen Daten zurückgegriffen werden. Damit ist der gesamte Vorgang voll automatisierbar. Etwaige automatisch erstellte Passwörter können dem Benutzer unter der zu Zuhilfenahme seines aktuellen Zertifikates sicher übermittelt werden Revokation Falls ein Zertifikat ungültig wird, muss der Benutzer diese Information der CA mitteilen (Abbildung 5.2). Der Zeitpunkt der Sperrung ist der Zeitpunkt der Bekanntgabe gegenüber dem TC. Der Benutzer hat ein Revokationspasswort erhalten, mit dem er der RA nachweisen kann, dass er Eigentümer des zu revozierenden Zertifikats ist. Alle Informationen werden dann von der RA an die CA weitergeleitet. Die CA fügt die Sperrinformation, sofern die Komponenten vorhanden sind, in die CRL ein und leitet sie an den OCSP- Provider weiter. Hier sind diese Komponenten in Form des Verzeichnisdienstes modelliert. Wird dann eine Statusanfrage bezüglich des revozierten Zertifikats gestellt, so fällt sie negativ aus. Eine weitergehende Betrachtung der Revokationsanfrage erfolgt in Abschnitt

32 5. Szenarien RA 1. Meldung 2. Revokation Benutzer CA = KA & CMA Verzeichnisdienst 3. Veröffentlichen 5.2. Weitere Vorgänge Abbildung 5.2.: Revokation eines Zertifikats In einer PKI gibt es neben den Kernvorgängen noch weitere Operationen. Hierbei sei die Überprüfung auf die Gültigkeit eines Zertifikats, die externe Schlüsselerzeugung und die Erneuerung des Zertifikats der Wurzelinstanz genannt Gültigkeitsprüfung In einer PKI ist es wichtig überprüfen zu können, ob ein Zertifikat nicht aus anderen Gründen als dem Ablauf des Gültigkeitszeitraums ungültig geworden ist. Hierfür werden verschiedene Konzepte verwendet, um diese Informationen auf der einen Seite zu erfassen und zu verwalten, auf der anderen Seite sie auch für Dritte verfügbar und erreichbar zu haben. Diese Forderungen finden sich auch in der Signaturverordnung 7 Absatz 2 (E.4) wieder. Die zwei großen Vertreter dieser Konzepte sind Certificate Revocation Lists (CRL) (ein als seit langem schon etabliertes und auch offline verfügbares Verfahren) und Online Certificate Status Protocol (OCSP). OCSP ist, wie der Name schon sagt, ein Online Protokoll. Es benötigt einen funktionierenden Internetzugang und eine Verbindung zum OCSP-Server. Auf diese zwei Verfahren wird im folgenden noch genauer eingegangen. Weiterhin gibt es noch Konzepte und Verfahren wie Novomodo [6]. Bei diesem Verfahren wird die Revokationsinformation schon bei der Erstellung in das Zertifikat eingebracht und mit signiert. Hierbei handelt es sich um den Hashwert eines Geheimnisses. Wird das Geheimnis bekannt, so ist das Zertifikat revoziert. Die Verfahren haben gemeinsam, dass sie zur Revozierung eines Zertifikats eine eindeutige Zuordnung der Zertifikats benötigen. Für Systeme nachdem X.509 Standard wird diese aus dem Aussteller und der Seriennummer gebildet. (Delta) Certificate Revocation List Eine Certificate Revokation List (CRL) oder auch eine Delta Certificate Revocation List (dcrl) [25] wird von einer CA erstellt, um alle revozierten Zertifikate zu verwalten. Eine CRL wird zu bestimmten Zeitpunkten erstellt und enthält alle Zertifikate die bis zu diesem 20

33 5.2. Weitere Vorgänge Zeitpunkt revoziert worden sind. Da eine CRL ein Liste ist die stets wächst, wurde zur Reduzierung des Datentransfers das Konzept der dcrl eingeführt. Hierbei werden immer in Bezug auf eine komplette Liste (BaseCRL) die neu revozierten und noch nicht in einer BaseCRL erfassten Zertifikate gesammelt und bereitgestellt. Die Delta CRL zusammen mit der referenzierten BaseCRL ergeben die Liste aller zurückgezogenen Zertifikat zum Zeitpunkt der Erstellung der dcrl. Ein Client ruft diese Liste ab und kann danach ohne eine Internetverbindung Zertifikate auf ihre Gültigkeit hin überprüfen. Für ein Auffrischung der Informationen muss ein Client entweder eine zu seiner bereits vorhandenen CRL passende dcrl laden oder eine komplette neue CRL. Die Aktualität der Information ist immer in der Geschwindigkeit, in der eine CA eine CRL beziehungsweise dcrl bereitgestellt und der Client diese vorliegen hat. Online Certificate Status Protocol Das Online Certificate Status Protocol (OCSP) [36] ermöglicht eine direkte Überprüfung einzelner Zertifikate. Somit kann unmittelbar festgestellt werden, ob ein Zertifikat zum Zeitpunkt der Überprüfung noch gültig ist. In Abbildung 5.3 ist ein Prüfungsschema innerhalb des OCSP-Anbieters dargestellt. Es sind folgende drei Antworten möglich: unknown (der Aussteller ist unbekannt), revoked (das Zertifikate wurde zurückgezogen), good (das Zertifikat ist nicht revoziert). Die dritte Antwortmöglichkeit muss im Rahmen des deutschen Signaturgesetzes (E.5) gegeben werden. Hierbei wird geprüft, ob das Zertifikat bekannt ist und dieses dann anschließend explizit als gültig erklärt. OCSP bietet gegenüber CRL zwei entscheidende Vorteile. Das erste ist die Echtzeit- Information über den Status eines Zertifikats. Den zweiten Vorteil bildet die Größe der Anfrage beziehungsweise der Datenpakete die übermittelt werden. Das Nutzen eines OCSP- Server kann das übermittelte Datenvolumen auf das notwendigste reduzieren. Weiterhin können sich mehrere CA durchaus einen OCSP-Server teilen. Dieser liefert dann die Status- Informationen über die Zertifikate der angeschlossenen CA in Echtzeit aus Externe Schlüsselerzeugung Auf Grund von Sicherheitsanforderungen kann es durchaus möglich sein, dass Schlüssel auf einer sicheren externen Einheit erzeugt werden müssen (Abbildung 5.4). Die CA stellt hierzu eine Anfrage an die externe Einheit. Die externe Einheit erzeugt den Schlüssel und dieser muss dann auf sicherem Wege wieder zur CA übermittelt werden. Hierbei ist der Schutz des privaten Schlüssel als sehr hoch einzustufen. Es besteht auch die Möglichkeit der Erzeugung des Schlüsselpaares auf eine Chipkarte (Abbildung 5.5) und somit ist der private Schlüssel vor externem Zugriff geschützt. Die CA muss im Anschluss die Benutzerdaten mit dem öffentlichen Schlüssel kombinieren, das Zertifikate erstellen und signieren. Dieses Zertifikat kann auf gewöhnlichem Wege ohne zusätzlichen Schutz an den Benutzer und den Verzeichnisdienste übermittelt werden. Der private Schlüssel wird auf der Chipkarte geschützt. 21

34 5. Szenarien verify issuer Aussteller unbekannt unknown check CRL Aussteller bekannt enthalten in CRL revoked check Certificate nicht revoziert Zertifikat unbekannt unknown good Zertifikat bekannt Abbildung 5.3.: Ablauf einer OCSP Anfrage nach SigG Vertrauensanker erneuern Eine Erneuerung des Zertifikats beziehungsweise des Schlüssels der Wurzelinstanz einer PKI ist die kritischste Operation in einer PKI. An dieser Stelle muss ein Zertifikat verwendet werden, das selbst signiert ist. Es gibt keine übergeordnete Instanz die die Authentizität dieser Wurzel bestätigen kann. Auch ist es der am besten zu schützende Vorgang in einer PKI, da dieses Zertifikat allen anderen Zertifikaten übergeordnet ist und man mit dem Besitz des dazugehörigen privaten Schlüssels die gesamte PKI kontrollieren kann [14]. Die Vorgänge die hierbei ablaufen sind meist individuell und müssen für jede eingesetzte PKI-Software einzeln angepasst werden. Sie sind ähnliche den Vorgängen bei dem erstmaligen Aufsetzen der PKI (Bootstrap). Daher gibt es im Bereich der Kommunikationsprotokolle keine großen Anforderungen. Dieser Prozess kann auch völlig automatisiert ablaufen. In dem die CA mitteilt, dass ihr Zertifikat abläuft und die entsprechenden Prozesse eigenständig auslöst. Zum Schluss kann es sein, dass den restlichen Komponenten innerhalb der PKI die Erneuerung des Zertifikats im Vertrauensanker mitgeteilt werden muss Eine semiautomatische Reaktion kann auch erfolgen. Hierbei müssen dann die Systembetreuer auf die Nachricht der CA reagieren und die Prozesse manuell ausführen. Bei einer CA, die nicht am Netzwerk angeschlossen ist, müssen alle Zertifikate per Datenträger zu dieser gebracht werden und anschließend wieder in signierter Form zurück übermittelt werden. Dieses Vorgehen bietet eine maximal Sicherheit für die CA. 22

35 5.2. Weitere Vorgänge RA Schlüsselerzeuger 1. Schlüsselanforderung 2. Schlüsselübertragung Benutzer CA = KA & CMA Verzeichnisdienst Abbildung 5.4.: Externe Schlüsselerzeugung RA Benutzer CA = KA & CMA 2. öffentlichen Schlüssel übermitteln Verzeichnisdienst 1. Anforderung zur Schlüsselgenerierung Chipkarte Abbildung 5.5.: Schlüsselerzeugung auf einer Chipkarte Informations- und Fehlerübermittlung Bei der Verarbeitung von Informationen können Fehler auftreten. Diese müssen gemeldet werden und Maßnahmen getroffen werden um sie zu beheben. Eine falsche Fehlermeldung kann zu nicht erwünschten Reaktionen führen. Daher müssen Fehlermeldungen korrekt erstellt und übermittelt werden. Sie sind genauso zu schützen wie normale Nachrichten innerhalb des TC. Ein Fehlermeldung sollte von jeder Komponente an jede Komponente gesendet werden können. Konkrete Mechanismen zur eigentlichen Fehlerbehebung obliegen der Anwendung. Gleiches gilt für den allgemeinen Informationsaustausch, auch dieser muss geschützt werden. Nehme man als Beispiel ein autonomes voll automatisiertes Trustcenters an, hier darf kein Fehlverhalten auf Grund von falschen Informationen ausgelöst werden. 23