5.2.1 Auswahl der optimalen Technik zur Statusverwaltung
Die in Abschnitt 3.9.2 vorgestellten Techniken sind in unterschiedlichem Maße f¨ur P2P-ZuSI geeignet.
5.2.1.1 Online-Techniken
In einem P2P-Verzeichnis findet die Verteilung von Informationen stets unter zeitli-cher Verz¨ogerung und unter Beteiligung zahlreizeitli-cher Knoten statt. Eine direkte Ver-bindung und damit ein Online-Datenaustausch zwischen zwei AAI-Entit¨aten ist nicht m¨oglich und auch nicht gewollt. Im Gegenteil, die dezentrale Datenspeicherung soll ja den Organisations- und Kommunikationsaufwand f¨ur die Issuing und Status Authorities verringern. Eine Online-Technik zur Kommunikation des Zertifikatstatus ist also nicht einsetzbar.
5.2.1.2 Offline-Techniken
Das strukturierte Peer-to-Peer-Verzeichnis kann prinzipiell zur Verwaltung von Offline-R¨uckrufinformationen genutzt werden. Die Status Authorities f¨ugen dann regelm¨aßig aktualisierte, signierte R¨uckruflisten in das Netzwerk ein. Diese Certificate Revocation Lists bzw. Trees sind entweder vollst¨andig oder in mehrere Teile gespalten speicherbar.
Um ein Zertifikat verifizieren zu k¨onnen, muss ein Pr¨ufer nach den zuletzt ver¨offentlichten R¨uckrufdaten suchen, ein Exemplar dieser Daten von einem gerade f¨ur diesen Datensatz zust¨andigen Peer herunterladen und ermitteln, ob das betreffende Zertifikat in dieser Da-tenstruktur als zur¨uckgerufen deklariert wurde.
Die Integrit¨at der Datei kann leicht mittels Signaturverifikation ¨uberpr¨uft werden, indem hierf¨ur der authentische ¨offentliche Schl¨ussel des Ausstellers verwendet wird. Damit wird Gewissheit dar¨uber erlangt, ob Manipulationen durch P2P-Knoten durchgef¨uhrt wurden oder die Datei anderweitig besch¨adigt ist. Der Pr¨ufer wird in einem solchen Fall die ent-haltenen Informationen nicht mehr akzeptieren.
Allerdings erg¨aben sich beim Einsatz von Offline-Techniken im Rahmen von P2P-ZuSI wesentliche Nachteile:
Bei nicht fragmentierten Dateien wie vollst¨andigen CRLs oder CRTs sind die einzelnen Dateien potentiell sehr groß, so dass hoher Kommunikations- und Speicheraufwand bei der Publikation entsteht. Somit w¨aren aber Knoten mit geringen Ressourcen prinzipiell benachteiligt und m¨oglicherweise sogar von der Teilnahme am System ausgeschlossen.
Die Replikation gestaltet sich ebenfalls schwierig, da mit den notwendigen Replikationsfaktoren sehr viel Speicherplatz ben¨otigt wird und insbesondere beim Republishing -hoher Kommunikationsaufwand entsteht. Lebenszyklusmanagement solcher Daten, ins-besondere die L¨oschung z.B. bei Auftauchen einer neuen CRL ist u.a. aufgrund der m¨oglicherweise differierenden G¨ultigkeitszeitr¨aume und des notwendigen Aufwandes zur regelm¨aßigen Pr¨ufung, ob Updates publiziert wurden, schwierig.
Das wesentlichste Problem liegt aber in der bereits in Abschnitt 3.9.2.2 beschriebenen Gefahr, dass ein Pr¨ufer ein Zertifikat unzutreffenderweise als g¨ultig ansieht, weil er die R¨uckrufliste oder Teile davon nicht auffinden oder aufgrund einer Besch¨adigung nicht verwenden kann. Da ein falsches Positivergebnis im Rahmen einer AAI als wesentlich schlimmer als ein falsches Negativergebnis einzustufen ist, ist die Verwendung von Offline-Techniken f¨urP2P-ZuSI nicht zu empfehlen.
5.2.1.3 R¨uckruffreie Systeme Trusted Directory
Ein Trusted Directory verlangt per Definition die Existenz einer vertrauensw¨urdigen, kon-trollierten Umgebung, in der Zertifikate sicher und stetig verf¨ugbar vorgehalten werden.
In einem Peer-to-Peer-System wird der Dienst aber von einer Gruppe nicht notwendi-gerweise vertrauensw¨urdiger Teilnehmer angeboten. Eine weitere Voraussetzung ist die Existenz einer Instanz, welche f¨ur die Integrit¨at der Daten organisatorisch und technisch verantwortlich ist. Beides kann nicht garantiert werden (siehe auch Kap. 8), so dass eine Kombination des Trusted-Directory-Ansatzes mit einem P2P-Verzeichnis unm¨oglich ist.
CRS/Novomodo und HCRS
Alle Statusnachrichten k¨onnen einzeln im Netzwerk gespeichert werden. Diese kleinen, voneinander unabh¨angigen Datens¨atze halten den Kommunikationsaufwand allgemein gering und erm¨oglichen so auch die problemlose Einbindung von Knoten mit geringer Bandbreite und Speicherkapazit¨at in das System. Auch entsteht kein Overhead, da ein Anfrageknoten immer nur genau die Information erh¨alt, die ihn interessiert, und bei-spielsweise keine R¨uckrufinformationen ¨uber viele andere Zertifikate wie beim Einsatz von CRLs.
HCRS setzt allerdings eine gewisse”Intelligenz“ des Verzeichnisdienstes oder nicht zerti-fikatgebundene Adressierung der Datens¨atze voraus (siehe 3.9.2.3 und 5.2.2.2). Die Um-setzung dieser Anforderungen w¨are schwierig, da Suchanfragen der Form ”Liefere eine aktuelle SI f¨ur einen beliebigen Knoten aus Di“ nur mit wesentlichem Zusatzaufwand1 realisierbar sind (zumal die Zusammensetzung von Di den Pr¨ufern nicht bekannt ist).
Die Statusnachrichten aus CRS sind allerdings sehr gut f¨ur die Speicherung in einem P2P-Netzwerk und damit f¨ur den Einsatz in P2P-ZuSI geeignet.
NewPKI
Da innerhalb des Peer-to-Peer-Netzwerks alle Knoten gleichberechtigt sind, ist es un-erheblich, von welcher AAI-Entit¨at eine Statusnachricht publiziert ist. Damit bietet NewPKI die gleichen Vorteile wie CRS und ist im skizzierten System sehr gut einsetzbar.
1z.B. mittels separat gespeicherter und ¨uber Metadaten adressierter Zuordnungsdatens¨atze, welche die konkreten FileIDs der Statusinformationen enthalten
Fazit:Aus der Menge der vorgestellten Techniken f¨ur die Bereitstellung von R¨uckrufen und Statusinformationen sind die r¨uckruffreien Techniken CRS und NewPKI optimal f¨ur das skizzierte Peer-to-Peer-basierte Informationssystem.
5.2.2 Regelwerk f¨ur Statusinformationen
5.2.2.1 Paralleler Einsatz von IA- und EE-zentrierten Statusinformationen Wie im vorigen Abschnitt gezeigt, sind CRS und NewPKI gleichermaßen f¨ur die Rea-lisierung von Statusnachrichten im skizzierten P2P-ZuSI geeignet. CRS implementiert eine IA-zentrierte Sicht auf die Statusverwaltung, d.h. die IA kontrolliert den Status ihrer ausgestellten Zertifikate. NewPKI realisiert ein EE-zentriertes System mit der Ver-antwortung f¨ur die Statuskontrolle auf Seite der End-Entit¨at. Es k¨onnen also sowohl End-Entit¨aten als auch Issuing Authorities in der Rolle SA auftreten.
Da in einer AAI - wie in Abschnitt 3.9.1 und insbesondere Tabelle 3.1 angesprochen - sowohl IA-zentrierte als auch EE-zentrierte Gr¨unde f¨ur den R¨uckruf von Zertifikaten vorliegen k¨onnen, ist die alleinige Integration eines der beiden Konzepte in P2P-ZuSI nicht ratsam und auch nicht notwendig: Da alle Teilnehmer des P2P-Netzwerks belie-bige Daten publizieren d¨urfen (vollst¨andige Gleichberechtigung), werden in P2P-ZuSI Statusnachrichten aus allen m¨oglichen Quellen gespeichert und verf¨ugbar gemacht. Der Urheber einer Statusnachricht ist sogar V¨ollig unerheblich, sie muss nur g¨ultig sein.
Negativnachrichten, d.h. explizite R¨uckrufe wie bei CRS/Novomodo in 3.9.2.3 vorgestellt, werden f¨urP2P-ZuSI nicht verwendet. Es reicht aus, dass die Entit¨at SA bei einem R¨uck-rufereignis keine weiteren Positivnachrichten ausstellt. Zus¨atzliche Nachrichten zu publi-zieren erzeugt nur zus¨atzlichen Aufwand, bietet aber keinen Informationsvorteil und ist daher unn¨otig. Es kommen also nur Statusinformationen, d.h. positive Statusnachrichten zum Einsatz.
5.2.2.2 Publikation von Statusinformationen
Die Status Authority erzeugt in jeder Periode2, in der das Zertifikat gilt, einen Datensatz der folgenden Form:
sii(cert) =Hd−i(r)
Dabei ist idie G¨ultigkeitsperiode des Zertifikats, wobei mit G¨ultigkeitsdauerd(in Peri-oden) gilt: 1≤i≤d.
Anschließend bestimmt SA die FileID f¨ur den Datensatz aus dem Hashwert ¨uber das gesamte Zertifikat konkateniert mit der aktuellen Periodei:
f idsii =H(H(cert)ui)
Da jeder Pr¨ufer eine Statusinformation erst dann anfragt, wenn er das zugeh¨orige Zer-tifikat bereits besitzt, kann er leicht dessen Hashwert bestimmen. Die Periode errechnet er aus G¨ultigkeitsbeginn des Zertifikats und dem aktuellen Datum (ggf. inkl. Uhrzeit).
Mit dieser Berechnungsmethodik f¨ur die FileID ist gew¨ahrleistet, dass jeder Pr¨ufer diese leicht berechnen und damit auch jede Statusinformation zu einem bekannten Zertifikat
2Es ist generell keine Synchronisierung der Perioden, weder in ihrer L¨ange noch in ihrer Anzahl, notwendig. Es muss lediglich im Zertifikat angegeben werden, wie sich die Perioden errechnen.
anfragen kann.
Die Status Authority publiziert dann den Datensatz (f idsii, sii(cert)) durch STORE-Requests an diek zust¨andigen Knoten.
5.2.2.3 Speichern von Statusinformationen
Erh¨alt ein Knoten eine Statusinformation mit einem STORE-Request, speichert er diese und stellt sie auf Anfragen hin zur Verf¨ugung. Nach Ablauf einer allgemein bekannten Mindestspeicherdauer l¨oscht er sie, da die Statusinformation dann ung¨ultig geworden ist.
5.2.2.4 Abfragen von Statusinformationen
Um eine aktuelle Statusinformation zu beziehen, muss ein Pr¨ufer aus dem ihm vorliegen-den Zertifikat cert die Werte H(cert) und i berechnen und daraus die passende FileID erzeugen.
Er startet dann einen Lookup (gem¨aß den Ergebnissen aus Abschnitt 4.4 zun¨achst mit FIND_VALUE) nach einem Datensatz mit f idsii. Wird die Statusinformation von keinem Knoten zur¨uckgeliefert, muss er annehmen, dass das Zertifikat nicht mehr g¨ultig ist.
Erh¨alt er eine Statusinformation, pr¨uft er sie auf Korrektheit, indem er deni-fachen Has-hwert ¨ubersii berechnet und mit dem Validierungsziel aus dem Zertifikat vergleicht. Ist die Validierung erfolglos, fordert er den Datensatz nochmals von allen Peers ausNf idsii an. Erst nach Abarbeitung der dabei empfangenen Ergebnisse entscheidet sich dann, ob das Zertifikat als g¨ultig oder ung¨ultig aufgefasst wird.