Kademlia bietet zwei grundlegende Lookup-Methoden: Die Methode FIND_NODE dient nur dem Auffinden der k n¨achsten Knoten zu einem Bezeichner. Ein Knoten, welcher eine Lookup-Nachricht mitFIND_NODE erh¨alt, liefert stets diekihm bekannten n¨achsten Knoten zum gesuchten Bezeichner zur¨uck.
Anders verh¨alt es sich mit der Methode FIND_VALUE, die dem Auffinden eines Daten-satzes dient. Empf¨angt ein Knoten eine Lookup-Nachricht mit FIND_VALUE, so pr¨uft er zun¨achst, ob er einen Datensatz mit dem gesuchten Bezeichner selbst gespeichert hat. Ist dies der Fall, liefert er direkt den Datensatz zur¨uck. Besitzt er den gesuchten Datensatz nicht, so antwortet er wie beiFIND_NODEmit einer Liste vonkbesser passenden Knoten.
Es wird angenommen, dass ein Teil der Knoten b¨oswillig handelt. Neben den in 4.3 untersuchten Effekten von Angriffen auf die Verf¨ugbarkeit von Datens¨atzen ist auch da-mit zu rechnen, dass Daten von Speicherknoten modifiziert und/oder falsche Antworten geliefert werden (Integrit¨atsangriff, siehe auch Kapitel 7).
Unter Ber¨ucksichtigung dieser Annahmen ergeben sich nun zwei praktikable Alternativen zum Bezug eines Datensatzes mit Bezeichner b:
1. Uber die Anwendung von¨ FIND_NODE werden die k Knoten aus Nb bestimmt. Der Lookup-Initiator sendet dann an jeden davon einFIND_VALUE. Alle Knoten, welche
einen oder mehrere Datens¨atze mit Bezeichnerb besitzen, liefern diese(n) zur¨uck.
2. Bei Verwendung der Methode FIND_VALUE wird der Lookup beendet, sobald die erste Antwort (in Form eines oder mehrerer Datens¨atze) von einem kontaktierten Knoten gesendet wird. Erf¨ullt diese Antwort nicht die Integrit¨atsanforderungen, so muss eine weitere Anfrage gestartet werden.
Diese wird dann wie in 1. durchgef¨uhrt, indem allekKnoten ausNbbefragt werden.
Letzteres ist notwendig, da die Wahrscheinlichkeit sehr hoch ist, dass bei einer erneutenFIND_VALUE-Anfrage wieder derselbe Knoten wie zuvor kontaktiert wird, der inkorrekte Antworten liefert.
Es ist unmittelbar einsichtig, dass sich die beiden Varianten hinsichtlich ihres Kommu-nikationsaufwandes unterscheiden. Dabei seien folgende Annahmen getroffen:
• Eine Lookup-Nachricht hat die L¨angelLOOKU P Byte.
• Der Transfer eines Datensatzes entspricht lDS Byte.
• In einem vollst¨andig belegten Adressraum der Gr¨oßeN = 2160(Adressl¨ange 160 Bit in Kademlia) ist die maximale Anzahl der in einem Lookup kontaktierten Knoten log2 N = 160. In einem Netzwerk, in dem nicht alle Adressen belegt sind (N <2m), ist die Anzahlx aller kontaktierten Knoten:
x=O(log2 N) =a·log2 N+b < m
Untersuchungen von Ratnasamy et al. [GGG03] an einem Netzwerk der Gr¨oße 216 ergaben die Pfadl¨ange lpath ≈ 12 log2 N pro Anfrage in einem Netzwerk ohne Knotenausf¨alle, wobei der Ausfall von ¨uber 50% der Knoten die durchschnittliche Pfadl¨ange um ca. 50% (also lpath ≈ 34 log2 N) erh¨oht. Diese Analyse bezieht aber den Parallelisierungsfaktor α f¨ur Anfragen nicht ein. Unter Ber¨ucksichtigung von α erg¨abe sich dann als Maximalwert f¨ur die Anzahl der pro Lookup kontaktierten Knotenx=α·lpath ≈α·34 log2 N. Es ist also wahrscheinlich, dassxf¨urα= 3 und eine maximal angenommene Netzgr¨oße N = 221 (¨uber 2 Mio. Knoten)≤48 ist.
• kˆist die Gesamtzahl der Datens¨atze, die unter dem gesuchten Bezeichnerbauf den Knoten aus Nb verf¨ugbar sind. Dies beinhaltet alle Replika aller Datens¨atze mit identischem Bezeichnerb (zur Existenz von gleichen Bezeichnern vgl. 5.3.2.1).
• k¯ist die Anzahl der verschiedenen unter identischem Bezeichnerbpublizierten Da-tens¨atze. Dabei gilt dann f¨ur den Anfragezeitpunkt: ˆk= ¯k·k, d.h. die Gesamtzahl˜ der verf¨ugbaren Datens¨atze unter Bezeichnerbauf allen Knoten ∈ Nb entspricht in etwa der Anzahl der unter diesem Bezeichner publizierten Datens¨atze multipliziert mit der erwarteten Anzahl der aktuell vorhandenen Replika pro Datensatz.
Unterschiedliche Publikationszeitpunkte der Datens¨atze werden vernachl¨assigt, d.h.
es wird vereinfachend angenommen, dass alle Datens¨atze in Form einer festen An-zahl ˜kan Replika vorliegen.
• Caching wird nicht ber¨ucksichtigt, d.h. der erste Knoten, der auf ein FIND_VALUE einen Datensatz zur¨uckliefern kann, muss bereits ∈ Nb sein.
Der Kommunikationsaufwand in Byte (bezeichnet mitc) f¨ur die beiden verf¨ugbaren Va-rianten kann damit wie folgt berechnet werden:
Variante I. Aufwand f¨ur FIND_NODEmitFIND_VALUE an jeden Knoten der MengeNb: cVar.I = (1 +k)·x·lLOOKU P + ˆk·lDS |ˆk= ¯k·˜k
⇔cVar.I = (1 +k)·x·lLOOKU P
| {z }
I
+ ¯k| ·k˜{z·lDS}
II
SummandI repr¨asentiert dabei den Aufwand f¨ur das Auffinden der Knoten ausNb. Der Multiplikator (1 +k) ergibt sich daraus, dass pro kontaktiertem Knoten der Aufwand f¨ur eine Lookup-Nachricht vom Anfrageknoten hin zum kontaktierten Knoten plus der Aufwand f¨urkLookup-Nachrichten (Liste der besser passenden Knoten) in die entgegen-gesetzte Richtung anf¨allt. SummandII quantifiziert den Aufwand f¨ur den Transfer von kˆ Datens¨atzen an den Initiator der Anfrage.
Variante II.Aufwand f¨ur standardm¨aßigesFIND_VALUEmit Umschwenken auf Variante I bei Misserfolg:
cVar.II = (1−pa)·((1 +k)·x·lLOOKU P + ¯k·lDS) +pa·(((1 +k)·x·lLOOKU P + ¯k·lDS)
+ (1 +k)·x·lLOOKU P + ˆk·lDS) |kˆ= ¯k·˜k
⇔cVar.II =
z }|I {
(1−pa)·((1 +k)·x·lLOOKU P + ¯k·lDS)
II
(
+pa·(((1 +k)·x·lLOOKU P + ¯k·lDS) +(1 +k)·x·lLOOKU P + ¯k·k˜·lDS)
Der Summand I stellt den Idealfall dar: der erste Knoten, der den Datensatz besitzt, ist kein Angreifer (Wahrscheinlichkeit 1−pa) und liefert die bei ihm gespeicherten ¯k korrekten Datens¨atze zur¨uck. SummandII repr¨asentiert den Fall, dass auf die erste An-frage falsche Daten zur¨uckgeliefert werden, da der Knoten ein Angreifer ist und die bei ihm gespeicherten Daten modifiziert hat. Sobald dies bei der Verarbeitung der Antwort bemerkt wird, muss eine zweite Anfrage gestellt werden. In diesem zweiten Durchgang wird dann wie in Variante I. vorgegangen, der Kommunikationsaufwand summiert sich.
Durch GleichsetzencVar.I =cVar.IIund L¨osen nachpawird die Angriffswahrscheinlichkeit berechnet, bei welcher der Kommunikationsaufwand f¨ur beide Varianten identisch ist.
(1 +k)·x·lLOOKU P + ¯k·˜k·lDS = (1−pa)·((1 +k)·x·lLOOKU P + ¯k·lDS) + pa·(((1 +k)·x·lLOOKU P + ¯k·lDS) + (1 +k)·x·lLOOKU P + ¯k·˜k·lDS)
⇔
pa= (˜k−1)·¯k·lDS
(1 +k)·x·lLOOKU P + ˜k·k¯·lDS
Die Platzhalter lLOOKU P und lDS werden nun mit plausiblen Werten ersetzt. Da ein Lookup neben dem gesuchten 20-Byte-Bezeichner noch einige weitere Informationen (z.B.
die verwendete Methode:FIND_NODEoderFIND_VALUE) enth¨alt, wird hierf¨ur von 40 Byte Gesamtgr¨oße ausgegangen10.
Die Gr¨oße eines Datensatzes h¨angt vom konkreten Anwendungsfall ab. Dementsprechend wird hier die Gr¨oße eines AAI-Zertifikats11verwendet (ca. 2 kB, also 2048 Byte [NyB99]).
Unter weiterer Einsetzung des in 4.3 ermittelten optimalen Replikationsfaktors k = 39 f¨ur moderat fluktuierende Netzwerke ergibt sich dann:
pa= 2048·(˜k−1)·k¯
1600·x+ 2048·˜k·¯k (4.19) Der Wert f¨ur pa, bei dem der Aufwand f¨ur Variante I und II identisch ist, h¨angt also von drei Parametern ab: der tats¨achlichen Anzahl der kontaktierten Knoten x in einem Lookup (d.h. des exakten Lookup-Aufwandes), den zum gegebenen Zeitpunkt im Durch-schnitt vorhandenen Replika pro Zertifikat ˜k und der Anzahl verschiedener Zertifikate, die unter gleichem Bezeichner gespeichert (¯k) sind. Der Wert f¨ur x bewegt sich wegen x=O(log2N) mita≤1 im Intervall [0,160], wobeix≤48 als wahrscheinlich gilt (siehe S. 102). F¨ur ˜kgilt: ˜k∈[1, k].
0 0.2 0.4 0.6 0.8 1
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 pa
Anzahl kontaktierter Knoten x
k = 5 -k = 2 pa = 0.5
(a) ˜k= 20; ¯k= 2,5
0 0.2 0.4 0.6 0.8 1
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 pa
Anzahl kontaktierter Knoten x
k = 5 k = 2 -pa = 0.5
(b) ˜k= 39; ¯k= 2,5
Abbildung 4.15: Break-Even des Kommunikationsaufwandes zwischen Anfragevariante I und II (stetig interpoliert)
Abbildung 4.15(a) zeigt den Verlauf der Schnittkurve gem¨aß Formel 4.19 zwischen cVar.I und cVar.II aufgel¨ost nach pa f¨ur eine beispielhafte Belegung der Parameter ˜k= 20≈ 12k (Average Case) bzw. ˜k= 39 = k (Worst Case hinsichtlich des Kommunikationsaufwan-des) und ¯k = 2 bzw. ¯k = 5. F¨ur Punkte (xi, pai) unterhalb einer Kurve ist Variante II vorteilhafter, f¨ur Punkte oberhalb Variante I.
Die angenommene Angriffswahrscheinlichkeit pa = 0.5 ergibt f¨ur k = 20 und ¯k = 2 x≈47, d.h. die Kommunikationsaufwendungen f¨ur Variante I und II sind bei 47
kontak-10Bei allen Angaben wird der auf den unteren Schichten des Netzwerks entstehende Overhead f¨ur UDP-Header usw. ausgeklammert.
11Zertifikate werden im verteilten AAI-Verzeichnis die gr¨oßten Datens¨atze darstellen, s. Abschnitt 5.2.
tierten Knoten identisch. Wie bereits erw¨ahnt, sind gr¨oßere Werte f¨ur xin einem realen Kademlia-System unwahrscheinlich, so dass Variante II Szenarien vorzuziehen ist12.
0 50000 100000 150000 200000 250000 300000 350000 400000 450000
5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 125 130 135 140 145 150 155 160
Kommunikationsaufwand in Byte
x Variante II besser Variante I besser
cVar.II cVar.I
Abbildung 4.16: Kommunikationsaufwand f¨ur Variante I und II, stetig interpoliert; ˜k= 20,¯k= 2
Diese Entscheidung wird f¨ur gr¨oßere ¯kund ˜kuntermauert (siehe Abb. 4.15(b) und obere Kurve in 4.15(a)): hier ist Variante I f¨ur pa = 0.5 erst f¨ur sehr große x bzw. in keinem Fall (obere Kurve in Abb. 4.15(b)) vorteilhafter. Dies illustrieren auch Abb. 4.16 sowie Abb. 4.17(a) und 4.17(b) Zur Minimierung des Kommunikationsaufwandes ist also die
200000 300000 400000 500000 600000 700000
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160
Kommunikationsaufwand in Byte
x
cVar.II cVar.I
(a) ˜k= 39
100000 150000 200000 250000 300000 350000 400000 450000 500000
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160
Kommunikationsaufwand in Byte
x
cVar.II cVar.I
(b) ˜k= 20
Abbildung 4.17: Kommunikationsaufwand f¨ur Variante I und II, stetig interpoliert; ¯k= 5 optimale Anfragepolitik unter den gegebenen Rahmenbedingungen stets Variante II.
12F¨ur h¨ohere Replikationsfaktorenkwird wegen der zugleich erwarteten h¨oheren Werte f¨ur ˜kdie Ent-scheidung best¨atigt. So ergibt sich beispielsweise f¨urk= 100,k˜= 50,k¯= 2, pa= 0.5 Aufwandsgleichheit beix≈49.
System zur Speicherung von Zertifikaten und
Statusinformationen : P2P-ZuSI
Ein zentraler Punkt dieser Arbeit ist die Spezifikation eines verteilten Informations-systems, welches die Daten einer AAI dezentral im Rahmen eines strukturierten P2P-Verzeichnisses speichert, verwaltet und f¨ur Anfragen bereith¨alt. Hierf¨ur muss ein Regel-werk entwickelt werden, welches von allen Teilnehmern des Systems verwendet wird und die Details der Formatierung, Speicherung und Anfrage von Datens¨atzen festlegt.
Die Kombination aus diesem Regelwerk (im Folgenden P2P-ZuSI-Regelwerk genannt) und einem konkreten Kademlia-basierten Peer-to-Peer-System wird als P2P-ZuSI (P2P Zertifikat- und Status-Informationssystem) bezeichnet und realisiert das verteilte Ver-zeichnis einer AAI.
Zun¨achst wird ein Grobentwurf von P2P-ZuSI vorgestellt. Dann wird die geeignete Status- bzw. R¨uckruftechnik f¨ur die durch den Entwurf vorgegebenen Rahmenbedin-gungen bestimmt und darauf das Regelwerk f¨ur Adressierung und Speicherung der Sta-tusnachrichten aufgebaut.
Im Anschluss werden die Regeln f¨ur die Verwaltung von Zertifikaten und dabei insbeson-dere die Behandlung der Zertifikatinhalte hinsichtlich des Sicherheitsziels Vertraulichkeit diskutiert und formuliert.
Weiterhin wird ein Schichtenmodell vorgestellt, welches die Ergebnisse illustriert und als Basis f¨ur die formale Modellierung des spezifizierten Systems (siehe Kapitel 6) dient.
5.1 Grobkonzept
P2P-ZuSI ist ein Informationssystem, welches unter Verwendung eines festen Regelwerks ein Kademlia-basiertes P2P-Netzwerk nutzt, um als Verzeichnis zur Speicherung, Verwal-tung und Bereitstellung von Daten einer AAI zu agieren.
Daten aus dem Verzeichnis k¨onnen von jedem Teilnehmer des P2P-Systems angefragt werden. Weiterhin ist es jedem Knoten erlaubt, beliebige Daten zu ver¨offentlichen. Es ist somit Voraussetzung, dass jede Entit¨at der AAI zugleich auch Teilnehmer des Netz-werks ist oder zumindest unbeschr¨ankten Zugriff auf einen Netzwerkknoten hat. Damit
106
ist die Differenzierung zwischen Entit¨at im Sinne der AAI und Knoten im Sinne der P2P-Infrastruktur im wesentlichen aufgehoben.
Es ist zu beachten, dass keine bestimmte AAI-Architektur besonders unterst¨utzt wer-den soll, sondern eine m¨oglichst allgemeine Eignung f¨ur verschiewer-dene Architekturen zu erreichen ist. Somit bestehen insbesondere keine Beschr¨ankungen dahingehend, welche AAI-Rollen von einem P2P-Systemteilnehmer eingenommen werden d¨urfen.