Tor Onion Routing und Private Information Retrieval in Peer-to

Tor Onion Routing und Private Information
Retrieval in Peer-to-Peer Informationssystemen
@
@
@
@
@
@
@
Studienarbeit
von
Daniel Dahlmeier
Betreuer:
Betreuende Mitarbeiter:
Prof. Dr. Jacques Calmet
Dr. Regine Endsuleit und Thilo Mie
Institut für Algorithmen und Kognitive Systeme
Universität Karlsruhe (TH)
SS 2006
Hiermit bestätige ich, die vorliegende Arbeit selbständig durchgeführt und keine anderen als die angegebenen Literaturhilfsmittel
verwendet zu haben.
Daniel Dahlmeier
4
Kapitel 1
Einleitung
Das Ziel meiner Arbeit ist der Entwurf eines anonymen Peer-to-Peer Informationssystems. Das System soll anonymes Verbreiten von Informationen
ermöglichen, robust gegen Zensur sein und eine gezielte Suche über Stichworte ermöglichen.
Peer-to-Peer Systeme sind eine Entwicklung weg vom hierarchischen
Client-Server Model hin zu dezentralen Strukturen. Der Begriff Peer-toPeer bezeichnet ein System, dessen Komponenten in einer gleichberechtigten
Weise miteinander agieren. Osram [3] definiert Peer-to-Peer Netzwerke als
ein
sich selbst organisierendes System gleichberechtigter, autonomer
Einheiten(Peers), das vorzugsweise ohne Nutzung zentraler Dienste auf der Basis eines Rechnernetzes mit dem Ziel der gegenseitigen Nutzung von Ressourcen operiert
Peer-to-Peer Netzwerke sind eine Konsequenz aus immer leistungsfähigeren
Personalcomputern und Rechnernetzen. Jeder Rechner in einem Peer-toPeer Netzwerk ist sowohl Client als auch Server.
Peer-to-Peer Netzwerke sind eine relative junge Anwendung für das Internet, haben aber innerhalb kürzester Zeit enorm an Popularität gewonnen.
Während viele Peer-to-Peer Anwendungen zum Austauschen von Musik und
Filmen genutzt werden und hauptsächlich wegen der damit verbundenen Copyright Verletzungen in das Licht der Öffentlichkeit rücken, birgt die Peerto-Peer Technologie durchaus weitreichendere Möglichkeiten zum Austausch
von Informationen.
Ich bin der Auffassung, dass Peer-to-Peer Netzwerke ein geeignetes Mittel sind um freien Informationsaustausch und damit Meinungs- und Informationsfreiheit zu propagieren. Da sie nicht auf zentrale Server angewiesen
5
6
KAPITEL 1. EINLEITUNG
sind, sind sie weniger leicht zu kontrollieren. In Ländern, in denen Meinungsund Pressefreiheit keine Grundrechte sind, können sie helfen sich gegen Zensur und Unterdrückung zu wehren. Ein Beispiel für die Nutzung von Peerto-Peer Technologie wäre der Informationsaustausch zwischen nicht Regierungsorganisationen (NGO) in totalitären Staaten.
Ein System zum freien Austausch von Informationen muss einen ausreichenden Schutz vor Zensur mit sich bringen. Das Netzwerk muss robust gegen Angriffe sein, die die Verfügbarkeit von Informationen einschränken wollen. Informationen sollen langfristig verfügbar gemacht werden, so dass sie
für jedermann zugänglich sind, aber nur von dem jeweiligen Autor gelöscht
oder geändert werden können.
Ein robustes System allein reicht aber nicht aus. Um Meinungsfreiheit zu
propagieren, muss das Peer-to-Peer Netzwerk meiner Meinung nach zwangsläufig
Anonymität gewährleisten. Wenn eine Person, die Informationen aus dem
Netzwerk liest oder Informationen verbreitet, unmittelbare, persönliche Konsequenzen befürchten muss, dann kann daraus eine indirekte Zensur entstehen.
Doch was ist unter einem anonymen Peer-to-Peer Netzwerk zu verstehen? In einem Peer-to-Peer Netzwerk gibt es zunächst eine Menge von Servern, die über ein Netzwerk miteinander kommunizieren. Es gibt Dokumente, die auf den Servern gespeichert sind, und Personen, die Dokumente erstellen, suchen und lesen. Personen, die neue Dokumente erstellen oder verbreiten, werden als Autoren bezeichnet. Die Beziehungen zwischen Servern,
Autoren, Lesern, und Dokumenten ist in Abbildung 1.1 dargestellt.
Abbildung 1.1: Beziehungen in einem Peer-to-Peer Informationssystem
In einem anonymen Peer-to-Peer Netzwerk sollten im Idealfall keine Rückschlüsse
auf diese Beziehungen möglich sein. Zu einem herausgegriffenen Dokument
soll man nicht den Autor, die Leser oder die Server, die das Dokument speichern, erfahren. Zu einem herausgegriffenen Server soll man nicht erfahren,
welche Dokumente auf ihm gespeichert sind. Eine Person, deren Rechner
beschlagnahmt und durchsucht wird, soll in der Lage sein, jede Kenntnis
7
über die auf seinem Rechner gespeicherten Dokumente abzustreiten. Nur
so werden Personen bereit sein, ihre Rechner einem anonymen Peer-to-Peer
Netzwerk anzuschließen.
Wir sehen, dass es unterschiedliche Arten” von Anonymität gibt, je
”
nachdem aus welcher Sicht wir den Begriff betrachten. Dingledine u.a.[9]
identifizieren folgende Anonymitätsbegriffe für Peer-to-Peer Netzwerke:
Autor Anonymität: Ein Dokument lässt keine Rückschlüsse auf seinen
Autor zu.
Leser Anonymität: Die Privatsphäre des Lesers bleibt geschützt. Ein Angreifer kann ein Dokument nicht mit seinen Lesern in Verbindung bringen.
Dokumenten Anonymität: Ein Server weiß nicht, welche Dokumente auf
ihm gespeichert sind.
Server Anonymität: Ein Server kann nicht mit einem bestimmten Dokument in Verbindung gebracht werden.
Anfrage Anonymität: Ein Server erfährt nicht, um welches Dokument es
sich bei einer Anfrage handelt. Eine schwächere Variante ist Anfrage
Abstreitbarkeit: der Server erfährt zwar welches Dokument angefragt
wurde, aber keine dritte Partei. Der Server kann also gegenüber dritten
abstreiten eine bestimmte Anfrage bearbeitet zu haben.
Ebenso wichtig für den Erfolg eines Peer-to-Peer Informationssystems ist
die Frage, wie einfach man Informationen in dem Netzwerk finden kann.
Ich denke, dass eine Stichwortsuche eine viel versprechende Möglichkeit ist.
Der Erfolg von Internet Suchmaschinen und ihr Einfluss auf unser Informationsverhalten legen diese Entscheidung nahe. Zusammengefasst sind die
wichtigsten Ziele in meinem Entwurf:
1. Anonymität für Autoren, Leser und Server
2. Schutz des Server Betreibers gegen strafrechtliche Verfolgung
3. Schutz vor Zensur der Inhalte
4. Erreichbarkeit der Dokumente über eine Stichwortsuche
5. Erschweren von DoS Attacken
Leider stehen die Ziele der Arbeit,Anonymität einerseits und Stichwortsuche
andererseits, zunächst einmal in einem Konflikt zueinander. Wie wollen wir
andere Benutzer in unseren Daten suchen lassen, wenn wir jederzeit in der
Lage sein wollen, jede Kenntnis über den Inhalt abzustreiten? Dieser Konflikt erscheint auf den ersten Blick nur schwer überbrückbar. Um den Spagat
8
KAPITEL 1. EINLEITUNG
zwischen Anonymität und Suchfunktion zu schaffen, benötige ich eine Reihe
fortgeschrittener Methoden und Techniken aus den Bereichen Computernetzwerke und Kryptographie. Die Kernkomponenten in meinem Entwurf
sind:
• Pastry Overlay Netzwerk für ein robustes und effizientes Peer-to-Peer
• TOR Onion Routing für anonyme Kommunikation
• Private Information Retrieval (PIR) für vertrauliche Suchanfragen
• Aufteilung der Daten mittels One-Time-Pad (OTP) Verschlüsselung
• Vertrauliche Vergabe von zertifizierten Pseudoidentitäten
Mein Beitrag besteht darin, diese Techniken in einem Peer-to-Peer Informationssystem zu integrieren. Ich zeige, wie ein zensurresistentes, anonymes
Peer-to-Peer Informationssystem mit Hilfe dieser kryptographischer Techniken realisiert werden kann. Meines Wissens nach ist ein Peer-to-Peer Entwurf
dieser Art neuartig.
Ein weiteres Ergebnis meiner Arbeit ist, das ausreichend starke Peerto-Peer Netzwerke nicht durch Speicherung des Datenverkehrs ausspioniert
werden können. In jüngster Vergangenheit gibt es einen Trend juristische
Mittel zur Überwachung des Datenverkehrs auszuweiten. Insbesondere neue
Gesetze zur Datenbevorratung”, der Speicherung von Daten durch die
”
Internet Service Provider (ISP), zeigen ein wachsendes Interesse an der
Überwachung des Internets. In meiner Arbeit zeige ich, dass selbst, wenn
ein ISP sämtliche Daten eines anonymen Peer-to-Peer Systems aufzeichnet, das System nicht ausspioniert werden kann. Das macht den Nutzen der
Speicherung von Internet Daten fraglich. Da diese Speicherung hohe Kosten
verursachen würde, könnte es im Interesse der ISPs sein, zu zeigen, dass ein
Aufzeichnung der Daten keinen Nutzen bringt, und damit eingespart werden
kann.
Die weiteren Kapitel meiner Arbeit sind wie folgt strukturiert: In Kapitel 2 gebe ich einen Überblick über bestehende Peer-to-Peer Systeme und
vorangegangene Publikationen. In Kapitel 3 führe ich die einzelnen Komponenten meines Peer-to-Peer Entwurfs ein. Insbesondere werden TOR Onion
Routing und PIR erklärt. In Kapitel 4 beschreibe ich konkrete Protokolle und argumentiere für jedes Protokoll, welche Sicherheitseigenschaften es
erfüllt. Kapitel 5 fasst die Ergebnisse meiner Arbeit zusammen und gibt
einen Ausblick auf zukünftige Arbeiten.
Kapitel 2
Vorangegangene Arbeiten
In diesem Kapitel gebe ich einen Überblick über Projekt und Publikationen,
die sich mit anonymen Peer-to-Peer Netzwerken befassen. Ich diskutiere kurz
welche Sicherheitsanforderungen und Arten von Anonymität sie erfüllen.
MUTE [1]verwendet ein Routing Schema, dass auf dem Verhalten von
Ameisen aufbaut, um Suchanfragen anonym weiterzuleiten. Jeder Server sieht nur seine direkten Nachbarn und kann nicht unterscheiden ob
diese nur Anfragen weiterleiten oder selbst anfragen. Die Anforderungen bezüglich Leser- und Server Anonymität sind in MUTE erfüllt. Die
Inhalte verbleiben aber im Klartext auf dem lokalen Rechner, so dass
keine Dokumenten Anonymität besteht. Der Besitzer des Rechners
kann nicht die Kenntnis über den Inhalt der Dokumente abstreiten,
und ist außerdem auch gleich als Autor der Dokumente zu identifizieren. MUTE bietet also keine Autor- und Dokumenten Anonymität.
Freenet Das wahrscheinlich bekannteste Beispiel für ein anonymes Peer-toPeer Netz ist Freenet[7]. Im Gegensatz zu MUTE werden die Inhalte
in Freenet verschlüsselt und nicht mehr auf dem Rechner des Autors
gespeichert, so dass der Autor anonym bleibt.
Wenn ein Client ein Dokument herunterladen möchte, generiert er
aus einer Reihe von Stichworten deterministisch einen Dokumentenschlüssel. Wie der Benutzer die Stichworte lernt ist nicht Teil von Freenet. Der Client startet eine Anfrage mit dem Dokumentenschlüssel an
seinen (lokalen) Server. Wenn der Server das angefragte Dokument
nicht gerade selbst speichert, leitet er die Anfrage an den nächsten
Server weiter. Wird ein passendes Dokument gefunden, so wandert es
auf dem Pfad der Suchanfrage zurück. Der Leser und der Server bleiben
anonym. Die von Freenet verwendete heuristische Routingstrategie ist
allerdings wenig effizient.
Das Hauptproblem, bei dem Ansatz von Freenet ist, dass er keine
starke Dokumenten Anonymität erreicht. Das Dokument ist zwar ver9
10
KAPITEL 2. VORANGEGANGENE ARBEITEN
schlüsselt, aber noch vollständig auf einem Rechner vorhanden. Die
Schlüssel zur Entschlüsselung der Inhalte wird aus den Stichworten,
die das Dokument beschreiben, gewonnen. Um anderen Benutzern eine Chance zu geben die Inhalte zu finden, müssen die Stichworte einfach zu raten sein. Ein Angreifer, der einen Server beschlagnahmt,
kann über einen Wörterbuch Angriff versuchen Dokumente zu entschlüsseln. Unter entsprechenden juristischen Gegebenheiten ist der
Server Betreiber auch hier für die gespeicherten Daten haftbar zu machen.
Anonymous Storage In [14] schlägt Serjantov ein System vor, in dem Inhalte mit einem Secret-Sharing Verfahren auf mehrere Server aufgeteilt
werden. Das würde rechtliche Vorteile für den Serverbetreiber bringen,
der jetzt ernsthaft behaupten kann, dass er kein (vollständiges) Dokument auf seinem Rechner speichert. Allerdings sind die Schlüssel im
Peer-to-Peer gespeichert. Angreifer, leicht auffinden kann. Der Entwurf bietet auch keinen Schutz in dem Fall eines maliziösen ISP oder
wenn der Angreifer die Netzwerkverbindung abhören kann, denn die
Fragmente werden im Klartext übertragen.
Free Haven Das Ziel des Free Haven Projekts[9] ist es, eine robuste, anonyme Publikationsplattform aufzubauen. Das System basiert auf einer dezentralen Gemeinschaft von Servern, dem servnet. Server im
servnet tauschen Inhalte untereinander aus. Ein Dokument wird mittels Secret-Sharing in Fragmente f1 , . . . , fn aufgeteilt, so dass k der
Fragmente genügen, um das Dokument zu rekonstruieren.
Wenn ein Client ein Dokument herunterladen möchte, so muss er
zunächst dessen Dokumentenschlüssel erfahren. Dann sendet er eine
Suchanfrage mit dem Schlüssel und einem anonymen Remailer Block
an einen Free Haven Server(z.B. seinen lokalen Server). Die Suchanfrage wird per Broadcast weitergesendet. Kommt die Anfrage an einem
Server an, der ein Fragment des Dokuments speichert, so sendet er
es über den anonymen Remailer Block an den Client zurück. Free
Haven kommt den Zielen, die ich in meinem Entwurf verfolge, von allen implementierten Systemen am nächsten. Es bietet Autor-, Leser-,
Server- und Dokumenten Anonymität und soll Dokumente auch dann
verfügbar halten, wenn ein mächtiger Angreifer versucht, diese Dokumente verschwinden zu lassen. Ein Nachteil in dem Entwurf von Free
Haven ist, dass der Client den Dokumentenschlüssel bereits kennen
muss. Außerdem wird die Suchanfrage über einen ineffizienten Broadcast versendet. Das System skaliert dadurch nicht für große Netzwerke.
Kleinere Netzwerke bedeuten aber automatisch ein geringeres Maß an
Anonymität.
Censorship-Resistand and Anonymous P2P Filesharing Endsuleit und
11
Mie schlagen in [10] vor, zwei Fragmente aus dem Dokument und einem
One-Time-Pad zu bilden und sie zusätzlich mit einer symmetrischen
Chiffre zu verschlüsseln. Dieses Verfahren bietet informationstheoretische Sicherheit für die gespeicherten Fragmente und damit perfekte Dokumenten Anonymität. Der Schlüssel zu der Chiffre wird aus
den Stichworten, die das Dokument beschreiben, gewonnen. Selbst für
einen maliziösen ISP, der alle Fragmente abfängt, sollte es durch die
doppelte Verschlüsselung nur schwer möglich sein, den Inhalt zu rekonstruieren.
Jeder Teilnehmer im Netzwerk hat eine langlebige Pseudoidentität,
die autorisierte Updates, Ende-zu-Ende Verschlüsselung und signierte
Fragmente erlaubt. Gleichzeitig werden die Pseudonyme in einer Weise vergeben, die keine Verbindung zu der realen Person erlaubt. Die
Anforderungen an Autor- und Leser Anonymität sind damit erfüllt.
Um an ein Dokument zu gelangen, muss der Benutzer aber zunächst
die richtigen Stichworte wissen. Das macht das System für den realen
Einsatz zumindest unpraktisch.
Meine Arbeit baut auf dem Entwurf von Endsuleit und Mie auf und erweitert ihn um eine Suchmaschine. Dabei soll das Maß an Sicherheit für
den Serverbetreiber und den Client so hoch bleiben wie im ursprünglichen
Entwurf. Es wäre deshalb nicht ausreichend den Dokumentenschlüssel für
jedes Stichwort in dem Peer-to-Peer abzulegen. Ein Angreifer könnte über
eine einfache Wörterbuch Attacke erfahren, welche Server Dokumente zu
bestimmten Stichworten speichern. Eine Suche nach den Stichworten De”
mokratie”, und Tibet” würde dem Angreifer eine Liste von Servern liefern,
”
die Dokumente zu den Stichworten Demokratie” und Tibet” enthalten.
”
”
Der Serverbetreiber könnte nicht abstreiten ein Dokument mit dem Inhalt
Demokratie” und Tibet” zu speichern.
”
”
Ein weiteres Problem ist, dass ein einzelner Server für ein Stichwort verantwortlich wäre (Genaugenommen ein Server und seine Nachbarschaft). Ein
Angreifer, könnte den für das Stichwort zuständigen Suchmaschinenserver
einfach ausmachen. Wenn der Angreifer es schafft den Server auszuschalten,
kann er Suchanfragen zu diesem Stichwort verhindern.
Mein Ansatz verwendet ein Private Information Retrieval Schema, um
eine Anfrage gleichmäßig auf viele Server zu verteilen. Es ist nicht mehr
ein einzelner Server (oder eine Nachbarschaft von Servern) für ein spezielles
Stichwort zuständig. Um die Suchmaschine zu integrieren, muss ich den Entwurf von Endsuleit und Mie an mehreren Stellen modifizieren, vor allem ist
es notwendig anonyme Kommunikation zwischen den Knoten im Netzwerk
hinzuzufügen. Im folgenden Kapitel erkläre ich die anonyme Kommunikation
und die weiteren Komponenten in meinem Entwurf.
12
KAPITEL 2. VORANGEGANGENE ARBEITEN
Kapitel 3
Techniken und Komponenten
Dieses Kapitel ist eine Einführung in die verschiedenen Techniken und Komponenten, die in meinem Entwurf verwendet werden.
3.1
Structured Peer-to-Peer Overlay Netzwerke
Grundlage jedes Peer-to-Peer Systems ist eine dezentrale Netzwerkstruktur,
die es den Knoten(oder Peers) in dem Netzwerk ermöglicht unter gegenseitiger Nutzung ihrer Ressourcen miteinander zu operieren. Es ist daher
sinnvoll die verwendete Netzwerkarchitektur genauer zu untersuchen. Im
wesentlichen fordern wir von unserem Netzwerk die folgenden Eigenschaften:
• Robustheit gegen Ausfälle und DoS Angriffe
• effizientes und sicheres Routing
• adaptives Verhalten beim Hinzukommen und Ausscheiden von Knoten
Diese Eigenschaften sollen auch dann erfüllt bleiben, wenn ein Teil der Peers
im Netzwerk maliziös ist. Das Netzwerk soll auch dann Nachrichten korrekt
ausliefern können, wenn ein Teil der Knoten Nachrichten falsch oder gar
nicht weiterleitet. Darüber hinaus ist es wünschenswert, dass das Netzwerk
adaptiv auf das Hinzukommen und Ausscheiden von neuen Knoten reagiert,
ohne dass Dokumente in dem Netzwerk verloren gehen. In einer offenen
Umgebung, wie dem Internet, ist damit zu rechnen, dass das Netzwerk nicht
aus einer festen Anzahl Knoten, sondern einer Vielzahl ständig wechselnder
Parteien besteht.
3.1.1
Pastry
Für meinen Entwurf sind besonders strukturierte Peer-to-Peer Netzwerke
von Interesse, da sie sehr effiziente Routing Mechanismen besitzen. Das
13
14
KAPITEL 3. TECHNIKEN UND KOMPONENTEN
Netzwerk, das meinem Entwurf zugrunde liegt, ist Pastry [13] ein strukturiertes Peer-to-Peer Overlay Network. Wie der Name Overlay” verrät,
”
setzt Pastry auf einem bestehenden Netzwerk, wie etwa dem Internet, auf.
Einem Knoten ist eine zufällig gewählte 128-bit knotenID zugeordnet. Jeder
Knoten verwaltet eine lokale Routingtabelle. Pastry arbeitet nach dem Prinzip einer verteilten Hashtabelle. Jedes Objekt, das in das Pastry Netzwerk
eingespeist wird, erhält einen 128-bit Schlüssel. Pastry speichert ein Objekt
auf dem Knoten, dessen knotenID dem Schlüssel numerisch am nächsten ist.
Erhält ein Knoten eine Nachricht, so leitet er sie an den Knoten in seiner Routingtabelle weiter, der numerisch näher am Empfänger der Nachricht
liegt. Genauer leitet er sie an einen Knoten weiter, dessen knotenID mit dem
Schlüssel der Nachricht ein gemeinsames Präfix hat, das länger als das gemeinsame Präfix des aktuellen Knoten mit dem Schlüssel ist. Die Anzahl der
Routing Schritte ist logarithmisch in der Anzahl der Knoten im Netzwerk.
In einem Netzwerk aus N Knoten, leitet Pastry eine Nachricht in erwarteten O(dlog N e) Schritten zu ihrem Empfänger, was unsere Anforderung des
effizienten Routing erfüllt.
Was aber passiert, wenn ein Knoten das Netzwerk verlässt oder aus anderen Gründen nicht erreichbar ist? Um Robustheit zu erreichen, repliziert
die Nachbarschaftsmenge jedes Knoten dessen Daten. Die Nachbarschaftsmenge eines Knoten Bob besteht aus Knoten deren knotenIDs numerisch
nahe an der knotenID von Bob sind. Die Knoten aus der Nachbarschaft
können Anfragen an Bob’s Stelle beantworten. Dadurch wird das Netzwerk
robuster gegen Knotenausfälle. Wenn Knoten das Netzwerk verlassen oder
neue Knoten hinzukommen, wird die Nachbarschaftsmenge automatisch angepasst.
Wie schon bemerkt, müssen wir davon ausgehen, dass f < N der Knoten in dem Pastry Netzwerk maliziös sind. Diese Knoten können beliebig
vom Protokoll abweichen, insbesondere Nachrichten verwerfen, falsch weiterleiten oder verändern. Damit das Peer-to-Peer System trotzdem korrekt
funktioniert, muss es über sichere Routing Primitiven verfügen. Castro u.a.
identifizieren in [4] drei notwendige Bedingungen für sicheres Routing in
Peer-to-Peer Netzen:
1. sichere Vergabe von Knotennamen
2. sichere Verwaltung der Routingtabellen
3. sicheres Weiterleiten von Nachrichten
Die sichere Vergabe der Knotennamen kann über eine zentrale Certification
Authority (CA) erfolgen. Siehe dazu den nächsten Abschnitt 3.2.
3.2. AUTHENTIFIZIERUNG
15
Der zweite Punkt betrifft die Routingtabelle eines Pastry Knoten. Castro u.a. schlagen in [4] einen hybriden Ansatz mit zwei Routingtabellen
vor. Die erste Tabelle nutzt Informationen über die Netzwerkumgebung des
Knoten, um ein effizientes Routing zu erreichen. Die zweite Routingtabelle
ist in ihren Werten beschränkt: Ein Eintrag an der Stelle (i, j) ist die IP
Adresse eines Knoten, dessen knotenID an allen Stellen bis zu der i + 1-ten
Stelle mit der des Routers übereinstimmt und an der i + 1-ten Stelle den
Wert j hat. Die Wahl der Routingtabellen ist daher stark eingeschränkt, so
dass es für einen Angreifer schwer ist, sie für einen Angriff zu missbrauchen.
Der dritte Punkt wird in Pastry dadurch sichergestellt, dass ein Router
über einen Routingfehler-Test ein falsches Weiterleiten seiner Nachricht mit
hoher Wahrscheinlich bemerkt. Dann sendet er die gleiche Nachricht noch
einmal über mehrere Routen. Die Wahrscheinlichkeit, dass ein Angreifer alle
diese Routen kontrolliert, ist gering.
Die Details der Routing Technik sind in [4] zu finden. In [13] untersuchen
Rowstron und Druschel die Performanz von Pastry und kommen zu dem
Schluss, dass Pastry effizient ist, gut skaliert und Knotenausfälle ausgleichen
kann.
3.2
Authentifizierung
Ein zentrales Problem in allen Peer-to-Peer Netzwerken ist die Authentifizierung neuer Knoten.
Wir wollen jeder Person im Peer-to-Peer eine eindeutige und langlebige
Pseudoidentität (pseudoID) und jedem Rechner eine zufällige knotenID zuordnen. Die pseudoID ermöglicht es, Dokumente zu signieren, autorisierte
Updates vorzunehmen und schwarze Listen anzulegen. Bei der Vergabe der
knotenIDs ist sicherzustellen, dass sie gleichförmig über den Namensraum
verteilt sind. Wenn ein Angreifer, nennen wir ihn Eve, in der Lage ist, seine
knotenID beliebig zu wählen, kann er die Integrität des Netzwerks angreifen.
Auch wenn Eve eine große Anzahl von knotenIDs erlangen kann, ist er in
der Lage das Netzwerk zu sabotieren, zum Beispiel in dem er Nachrichten
nicht weiterleitet.
Um zu verhindern, dass Eve übermäßig viele Knoten erhält, verwenden
ich eine zentrale Certification Authority (CA), die Pseudoidentitäten und
knotenIDs vergibt. Wir wollen verhindern, dass die Pseudoidentitäten und
knotenIDs mit realen Personen in Verbindung gebracht werden können, um
Anonymität zu gewährleisten. Wir verwenden ein Blinde-Signatur Schema,
in dem die CA gültige Zertifikate für Pseudoidentitäten und knotenIDs aus-
16
KAPITEL 3. TECHNIKEN UND KOMPONENTEN
stellt, ohne die signierten Werte zu erfahren.
In einer offenen Umgebungen, wie dem Internet, ist es allerdings sehr
schwierig eine zentrale CA aufzubauen, der alle Teilnehmer vertrauen. Für
solche Umgebungen sind dezentrales Verfahren interessant. Eine Möglichkeit
ist, jeden Teilnehmer in regelmäßigen Abständen ein kryptographisches Rätsel
lösen zu lassen[12]. Ein Angreifer, der versucht eine Vielzahl von Knoten ins
Netz einzuschleusen, müsste über enorme Rechenkapazität verfügen um alle
Rätsel zu lösen. Die Vergabe über eine CA ist aber der wesentlich sicherere,
wenn auch weniger gut realisierbare Ansatz.
3.3
One-Time-Pad Verschlüsselung
Um Dokumente zu verschlüsseln, benutze ich ein One-Time-Pad(OTP) Verfahren. Dabei wird bitweise das XOR-Produkt aus dem Klartext und einem
Zufallsstring gleicher Länge gebildet. Der OTP liefert informationstheoretische Sicherheit, in dem Sinne, dass das Chiffrat tatsächlich keine Information über den Klartext mehr enthält. Damit sollte ein Serverbetreiber in der
Lage sein, jegliche Kenntnis über gespeicherte Inhalte abzustreiten. Durch
den Einsatz von Spezialhardware oder Projekte wie [2], sollte es in Zukunft
möglich sein echten Zufall in ausreichend großer Menge zur Verfügung zu
haben.
3.4
Onion Routing
Onion Routing basiert auf der Idee von Mixer”-Netzwerken. Nachrichten
”
werden auf einem, vom Sender gewählten Pfad, über mehrere Onion Routern
gesendet. Der Absender verschlüsselt die Nachricht in mehreren Schichten”,
”
ähnlich den Schichten einer Zwiebel. Auf dem Weg durch das Netzwerk entfernt jeder Onion Router auf dem Pfad eine Schicht” der Verschlüsselung
”
und leitet die Nachricht dann an den nächsten Router weiter. Die Router mixen” die Nachrichten, indem sie Nachrichten zwischenspeichern und
”
in permutierter Reihenfolge weitersenden. Für einen Angreifer ist es daher
schwer, den Pfad einer Nachricht nachzuvollziehen.
3.4.1
TOR Onion Routing
In meinem Entwurf benutze ich das Onion Routing Schema von TOR [8].
TOR bietet perfekte Vorwärts-Sicherheit, Ende-zu-Ende Integritäts Checks
und variable Routing Taktiken für TCP-Anwendungen. TOR umfasst ungefähr 160 Onion Router auf fünf Kontinenten und über zehntausend Benutzer (Stand Mai 2005).
3.4. ONION ROUTING
3.4.2
17
Aufbau anonymer Kanäle
Seien P1 , . . . , PN die Onion Router im Netzwerk. Router kommunizieren
über sichere Kanäle miteinander und es gebe eine Public Key Infrastruktur.
Nehmen wir an, Alice möchte Bob eine anonyme Nachricht schicken. Sie
baut dazu schrittweise einen anonymen Kanal zu Bob auf. Sie wählt eine
zufällige Menge von Onion Routern P1 , . . . , Pn und eine KanalID CAliceBob .
Dann erzeugt sie ein create-Nachricht für den Router P1 , zusammen mit der
ersten Hälfte eines Diffie-Hellman Schlüssels. Die Schlüsselhälfte ist mit dem
öffentlichen Schlüssel von P1 chiffriert:
(create, CAliceBob , EncP1 (g x ))
Diese Nachricht sendet Alice über eine TLS-Verbindung an den Router P1 .
P1 antwortet mit einer created -Nachricht, der zweiten Hälfte des DiffieHellman Schlüssels und einem Hashwert des gemeinsamen Schlüssels K =
g xy ::
(created, g y , H(K| handshake”))
”
Mit dem Hashwert beweist P1 , dass die Nachricht wirklich von ihm kommt.
Alice und P1 verfügen jetzt über ein gemeinsames Geheimnis K. Die Nachrichten zwischen Alice und P1 werden von nun an mit dem Schlüssel K
verschlüsselt. Alice erweitert den anonymen Kanal teleskopartig”. Sie sen”
det eine extend -Nachricht mit der Adresse von P2 und einem, mit dem
öffentlichen Schlüssel von P2 chiffrierten, g x2 an P1 :
(extend, P2 , EncP2 (g x2 ))
P1 wählt eine KanalID CP 1P 2 und erzeugt eine create-Nachricht mit dem
Inhalt (create, CP 1P 2 , g x2 ) für P2 . Diese Nachricht wird über eine TLSVerbindung an P2 gesendet.
P2 antwortet mit einer created -Nachricht, einem g y und einem Hashwert
H(K). P2 leitet g y und H(K) Inhalt einer extended -Nachricht an Alice weiter. Alice hat jetzt ein gemeinsames Geheimnis mit P2 . Der anonyme Kanal
umfasst jetzt Alice, P1 , und P2 . Es ist zu beachten, dass Alice zwar weiß,
dass sie mit P2 kommuniziert, aber P2 kommuniziert nur mit P1 und weiß
nicht wer den anonymen Kanal initiiert hat. Jeder Knoten auf dem Kanal
hat einen gemeinsamen Schlüssel mit Alice, aber nur Alice hat Kenntnis aller geheimen Schlüssel und weiß welche Knoten den Kanal bilden. Der Kanal
wird schrittweise erweitert, bis Alice einen anonymen Kanal zwischen sich
und Bob aufgebaut hat.
3.4.3
Konstruktion einer Nachricht
Sobald Alice einen anonymen Kanal zu Bob aufgebaut hat, kann sie Nachrichten versenden. Nehmen wir an, dass P1 , P2 , . . . , Pn+1 = Bob die Onion
18
KAPITEL 3. TECHNIKEN UND KOMPONENTEN
Router sind, die den anonymen Kanal bilden, und K1 , . . . , Kn+1 die zugehörigen, symmetrischen Schlüssel. Alice erzeugt den Datenteil der anonymen Nachricht, indem sie die Nachricht m in mehreren Schichten” zu einem
”
Chiffrat c1 verschlüsselt.
cn+1 = {m}Kn+1
(3.1)
cn = {cn+1 }Kn = {{m}Kn+1 }Kn
..
.
c1 = {c2 }K1 = {. . . {{m}Kn+1 }Kn . . .}K1
Zu dem Datenteil wird ein Header mit einer Prüfsumme hinzugefügt. Die
Prüfsumme ist der Hashwert der Nachricht mit einer Hashfunktion H. Der
Header wird genau wie die Nachricht in mehreren Schichten verschlüsselt.
Headn+1 = {H(m)}Kn+1
(3.2)
Headn = {Headn+1 }Kn = {{H(m)}Kn+1 }Kn
..
.
Head1 = {Head2 }K1 = {. . . {{H(m)}Kn+1 }Kn . . .}K1
Aus dem Chiffrat c1 und dem Headern H1 bildet Alice die Onion-Nachricht:
O1 = (CAliceBob , Head1 , c1 )
3.4.4
Weiterleiten von Onions
Wenn der Router P1 die Nachricht O1 empfängt, entfernt er eine Schicht der
Verschlüsselung, jeweils vom Datenteil und vom Header. Er schaut nach,
welcher Router als nächster auf dem Kanal folgt. Er ersetzt die KanalID
durch CP1 P2 .
O2 = P rocOnion(O1 , K1 , CP1 P2 ) = (CP1 P2 , Head2 , c2 )
und sendet die Onion-Nachricht O2 auf dem anonymen Kanal an den Router
P2 weiter. Der Router P2 verfährt mit der Nachricht in gleicher Weise, indem er mit dem Schlüssel K2 eine Schicht der Verschlüsselung entfernt, die
KanalID anpasst und die Nachricht an den nächsten Router weiter sendet.
Schließlich erhält Bob die Nachricht. Er entschlüsselt sie mit seinem
Schlüssel Kn+1 und erhält:
On+1 = P rocOnion(On+1 , Kn+1 , CPn Bob )
= (⊥, H(m), m)
(3.3)
3.4. ONION ROUTING
19
Bob erkennt, dass er keine passende KanalID zum weiterversenden hat. Er
überprüft durch Berechnen des Hashwertes die Integrität der Daten.
Bob kann Alice über den selben anonymen Kanal antworten. Er verschlüsselt seine Nachricht und die zugehörige Prüfsumme mit dem Schlüssel
Kn+1 , und sendet sie über den Kanal CPn+1 Pn an den Router Pn . Pn und
alle folgenden Router fügen je eine weitere Schicht der Verschlüsselung hinzu und senden die Nachricht auf dem anonymen Kanal weiter. Schließlich
erhält Alice die mit Kn+1 , Kn , . . . , K1 verschlüsselte Nachricht. Sie entfernt
alle Schichten der Verschlüsselung und erhält die Antwort.
3.4.5
Rendezvous Punkte
Zusätzlich zu der Möglichkeit anonyme Nachrichten zu versenden, ist es in
meinem Entwurf notwendig, dass Router Nachrichten erhalten können und
dabei selber anonym bleiben. Ich verwende Rendezvous Punkte um verborgene Dienste (location-hidden services) zu konstruieren.
Solche verborgenen Dienste ermöglichen es Bob einen Service, wie zum
Beispiel einen Web Server, anzubieten, ohne seine Adresse im Peer bekanntzugeben. Er wählt dazu einen oder mehrere Knoten als Zugangspunkte
(Frontends). Wenn Alice auf Bob’s Web Server zugreifen möchte, wählt sie
zunächst einen Knoten als ihren Rendezvous Punkt. Sie verbindet sich mit
einem von Bob’s Zugangspunkten und teilt ihm ihren Rendezvous Punkt
mit. Dann wartet sie darauf, dass Bob sich mit ihrem Rendezvous Punkt
verbindet.
1. Bob erzeugt ein Public Key Schlüssel Paar um seinen Service zu identifizieren.
2. Bob wählt ein Menge von Knoten PZP1 , . . . , PZPn als Zugangspunkte
aus. Er baut einen anonymen Kanal zu jedem der Zugangspunkte auf
und sendet ihm eine Benachrichtigung, dass er auf Anfragen warten
soll.
3. Bob veröffentlicht die Zugangspunkte zusammen mit einer Beschreibung seines Services. Er signiert die Veröffentlichungen mit seinem
privaten Schlüssel.
4. Alice möchte Bob’s Service nützen. Sie wählt einen Knoten PRP als
ihren Rendezvous Punkt. Sie baut einen anonymen Kanal zu PRP auf
und sendet ihm einen zufäl̈lig gewählten Wert c.
5. Alice baut einen anonymen Kanal zu einem Zugangspunkt PZP i auf.
Sie bildet eine Nachricht aus ihrem Namen, ihrem Rendezvous Punkt,
20
KAPITEL 3. TECHNIKEN UND KOMPONENTEN
der ersten Hälfte eines Diffie-Hellmann Schlüssels und dem Wert c:
(Alice, PRP , g x , c)
Sie verschlüsselt die Nachricht mit Bob’s öffentlichem Schlüssel und
sendet sie an PZPi
6. Der Zugangspunkt PZP i sendet die Nachricht an Bob weiter.
7. Wenn Bob auf Alice Anfrage eingehen möchte, baut er einen anonymen Kanal zu dem Rendezvous Punkt PRP auf und sendet die zweite
Hälfte des Diffie-Hellmann Schlüssels, den Wert c und den Hashwert
des Diffie-Hellmann Schlüssels:
(g y , c, H(g xy ))
8. Der Rendezvous Punkt verbindet den anonymen Kanal von Bob mit
dem von Alice. Nachrichten die auf dem anonymen Kanal von Alice
kommen, sendet er auf dem Kanal an Bob weiter und umgekehrt. Er
kennt dabei weder Alice noch Bob oder erfährt etwas über die Daten,
die beide austauschen. Alice und Bob besitzen jetzt einen gemeinsamen
anonymen Kanal und kommunizieren wie üblich.
Zugangspunkte bieten neben der Möglichkeit versteckte Dienste anzubieten
auch verstärkte Sicherheit gegen Denial-of-Service Attacken. Bob’s Adresse
ist Alice nicht bekannt. Bob kann sich jederzeit dazu entscheiden nicht auf
Alice Anfrage einzugehen, wenn er den Verdacht hat, dass Alice eine Denialof-Service Attacke unternimmt. Wenn einer der Zugangspunkte angegriffen
wird, kann Bob einfach einen neuen Zugangspunkt für seinen Service wählen.
3.5
Private Information Retrieval
Bei dem Problem des Private Information Retrieval (PIR)[6] geht es darum,
dass ein Client Informationen von einem Datenbankserver abfragen möchte,
ohne dass der Server dabei etwas über den Inhalt der Anfrage lernen soll.
Eine triviale Lösung für das Problem ist die Datenbank vollständig an
den Client zu senden. Bei realistischen Größen für die Datenbank ist diese
Lösung nicht mehr praktikabel. Leider gibt es für den Fall eines einzelnen
Servers keine Lösung, die geringeren Kommunikationsaufwand hat als die
triviale[6]. Eine Möglichkeit den Aufwand zu verringern, ist die Datenbank
auf mehreren Servern zu replizieren. Eine andere Möglichkeit ist, den Sicherheitsbegriff abzuschwächen. Das führt zu dem Begriff des Computational Private Information Retrieval (CPIR) [5]. Dabei wird verlangt, dass ein
polynomiell beschränkter Datenbankserver den Inhalt der Suchanfrage nicht
3.5. PRIVATE INFORMATION RETRIEVAL
21
erfährt. Da dieser Sicherheitsbegriff für meine Anforderungen ausreicht, verwende im weiteren der Übersichtlichkeit halber die Begriffe PIR und CPIR
synonym.
3.5.1
Private Information Retrieval und Anonymität
Wenn man anonyme Kommunikation voraussetzt, lassen sich PIR Protokolle mit deutlich besserer Effizienz konstruieren. Ishai u.a. beschreiben diese
Technik in [11]. Sie verwenden einen Ansatz, bei dem die Clients ihre Anfragen aufteilen und als Eingabe für ein multi-Server PIR Protokoll verwenden.
Alle Anfragen werden an den Server gesendet, der nicht wissen kann, welche
Anfrage von welchem Client stammt. Ein Client kann aus den Antworten
des Protokolls das Ergebnis seiner Anfrage konstruieren.
3.5.2
Konstruktion des PIR Schemas
Ich beschreibe in diesem Abschnitt das P IR Schema von Ishai u.a für Peerto-Peer Systeme. Das Schema baut auf einem t-Server informatonsheoretisch
sicherem PIR Protokoll auf, in dem die Sicherheit des Clients für bis zu k
kooperierende, maliziöse Server gewährleistet ist. Die Anfragen eines Clients werden als Punkte auf einem Polynom vom Grad k aufgefasst. Jeweils
k Punkte verraten nichts über die Anfrage i, während k + 1 Punkte i eindeutig festlegen.
Die Sicherheit des Protokolls beruht auf der Annahme, dass die Interpolation verrauschter Kurven von geringem Grad schwierig ist. Die Annahme
besagt, dass eine Kurve vom Grad k über einem endlichen Körper nicht rekonstruiert werden kann, wenn zusammen mit den Werten der Kurve eine
ausreichende Menge von Rauschwerten ausgegeben wird. Durch das Ver”
rauschen” der Anfragen mit Zufallswerten soll i verschleiert werden. Wie sich
aber zeigt, muss der Anteil des Rauschen mindestens in der Größenordnung
der Datenbank liegen. Damit ist dieser Ansatz für einen einzelnen Client
sinnlos.
Die Erkenntnis bei Ishai u.a. ist, dass die gleiche Menge an Rauschen
benutzt werden kann um eine beliebige Menge von Kurven zu verschleiern.
Wenn viele Clients Anfragen an die Datenbank senden, ist die Anzahl der
Rauschwerte, den jeder Client beitragen muss, klein.
3.5.3
Das PIR Model
Jeder Knoten in dem Peer kann drei verschiedene Rollen annehmen: als Datenbankbesitzer, der Daten über ein P IR Schema für die anderen Peer Teilnehmer zugänglich machen möchte, als Server, der einen Teil seiner Ressourcen für andere Datenbanken zur Verfügung stellt, und als Client, der Daten
22
KAPITEL 3. TECHNIKEN UND KOMPONENTEN
aus einer Datenbanken abfragen möchte.
Um eine Datenbank x der Größe m in das Peer einzuspeisen, betrachtet man die Einträge xi als Werte eines c-dimensionalen Polynoms qx vom
Grad höchstens d über einem endlichen Körper F . Ein Index i entspricht
einem Punkt zi ∈ F c , mit qx (zi ) = xi . Der Datenbankbesitzer berechnet alle
möglichen Werte des Polynoms und sendet sie an an eine Menge von Datenbankservern. Wenn die Anzahl der Server ausreichend groß ist, speichert
jeder Server nur einen einzelnen Eintrag aus der Datenbank.
Um einen Eintrag xi aus der Datenbank abzufragen, wählt ein Client eine zufällige Kurve p = (p1 , . . . , pc ) vom Grad k mit p(0) = zi und t = kd + 1
zufällige Stützstellen aj ∈ F \{0}. Er sendet an die Server t anonyme Anfragen vj = p(aj ) ∈ F c und zufällige Rauschwerte bj ∈R F c , so dass die Anzahl
aller Rauschwerte mindestens n beträgt. Jeder Server antwortet auf die Anfrage vj mit dem Wert sj = qx (vj ) aus seiner Tabelle mit Datenbankwerten.
Die Punkte (aj , sj ) legen ein Polynom qx ◦ p vom Grad kd fest. Der Client
interpoliert diese Punkte, wertet das Polynom an der Stelle 0 aus und erhält
xi . Damit die Interpolation erfolgreich ist muss die Anzahl der Elemente in
F größer sein als t + 1.
Wir wählen c als Konstante und setzten t = O(km1/c ). Die Menge des
Rauschens liegt in der Größenordnung der Datenbank. Der endliche Körper
F ist polynomiell in m.
Unter der Annahme, dass anonyme Kanäle existieren, gibt es ein einRunden PIR Protokoll mit verteilten Servern und amortisierter Kommunikationsund Rechenkomplexität von Õ(t) = Õ(km1/c ) pro Anfrage. Das Protokoll
ist berechenbar sicher, solange die nicht maliziösen Clients mindestens n(k)
Rauschanfragen produzieren.
Zusätzlich hat dieses PIR Schema den Vorteil der Lastenverteilung: die
Last der Suchanfragen wird durch die verteilte Struktur der Datenbank
gleichmäßig auf alle Knoten im Peer verteilt. Auch dann, wenn ein Index
von vielen Clients angefragt wird, bleibt die Anfragelast durch die zufällige
Wahl der Kurve p auf fast allen Datenbankservern gleichmäßig hoch. Das
macht das System weniger anfällig gegen Denial-of-Service Attacken.
Das PIR Schema erlaubt es, eine verteilte Suchmaschine aufzubauen,
in der die Anfragen der Clients anonym bleiben. Im nächsten Kapitel gebe
ich Protokolle, in dem das PIR Schema zur Suche in einem Peer-to-Peer
Informationssystem benutzt wird.
Kapitel 4
Peer-to-Peer Entwurf
Dieses Kapitel enthält den detaillierten Entwurf meines Peer-to-Peer Informationssystems. Ich gebe Protokolle für die grundlegenden Funktionen: neue
Teilnehmer treten dem Netzwerk bei, suchen nach Dokumenten, speichern
und laden Dokumente, etc. Ich diskutiere zu jedem Protokoll die erreichten
Eigenschaften, insbesondere Korrektheit, Vertraulichkeit und Robustheit.
4.1
Überblick
Grundlage meines Entwurfs ist ein Pastry Overlay Netzwerk. Jede Person
hat ein Pseudonym und jeder Rechner hat eine eindeutige knotenID. Eine
CA vergibt Pseudonyme und knotenIDs in in vertraulicher Weise. Die Architektur von Pastry garantiert sichere und effiziente Kommunikation, robustes
Speicherung von Fragmenten durch Replizieren und adaptives Verhalten des
Netzwerks beim Hinzukommen und Ausscheiden von Rechnern. TOR Onion
Routing ermöglicht anonyme Kommunikation und versteckte Dienst. Jeder
Rechner im Netzwerk kann (gleichzeitig) drei verschiedenen Rollen annehmen:
1. Datenserver
2. Client
3. Suchmaschinenserver
Als Datenserver speichert er Fragmente von Dokumenten. Als Client kann er
Anfragen an die verteilte Suchmaschine stellen, Dokumente ablegen, herunterladen, aktualisieren oder löschen, genauso wie Einträge in seiner Suchmaschine anlegen oder löschen. Als Suchmaschinenserver beantwortet er Anfragen an die verteilte PIR Suchmaschine. Für jede diese Funktionen gebe
ich im nächsten Abschnitt geeignete Protokolle an.
23
24
KAPITEL 4. PEER-TO-PEER ENTWURF
4.2
4.2.1
Protokolle
Join
Eine neue Teilnehmerin, nennen wir sie Alice, möchte dem Peer-to-Peer
beitreten. Um eine Pseudoidentität zu erhalten führen Alice und die CA die
folgenden Schritte durch:
1. Alice muss der CA zunächst beweisen, dass sie auch wirklich Alice ist,
z.B. durch Vorlage eines gültigen Personalausweises.
2. Alice erzeugt eine zuällige 160-bit pseudoID und ein Schlüsselpaar
(eP , dP ).
3. Alice wählt eine Zufallszahl r und multipliziert ihre pseudoID und das
Schlüsselpaar mit reCA , wobei eCA der öffentliche Schlüssel der CA ist:
a := reCA ∗ (pseudoID, (eP , dP )).
4. Die CA signiert a mit ihren privaten Schlüssel dCA und sendet den
Wert adCA an Alice zurück.
5. Alice multipliziert mit r−1 und hat nun ein Zertifikat (pseudoID, (eP , dP ))dCA .
Die Schritte um eine knotenID zu erhalten sind ähnlich, allerdings wollen wir
sicherstellen, dass die knotenID gleichförmig aus dem Namensraum gewählt
ist.
1. Alice erzeugt eine zufällige 128-bit knotenID und ein Schlüsselpaar
(eS , dS ).
2. Alice wählt Zufallszahlen r1 , r2 , r3 und sendet (c1 , c2 ) := (r2eCA ∗ r1 ∗
eS , eS ∗ r3eCA ) an die CA.
3. Die CA erzeugt eine Zufallszahl r4 . Sie berechnet a1 := (c1 ∗ r4 )dCA
und a2 := cd2CA und sendet beide Werte an Alice.
4. Alice berechnet a2dCA ∗ r3−1 = edSCA und erhält ein Zertifikat für den
Schlüssel eS . Zusätzlich berechnet sie a3 := r2−1 a1 = r1dCA edSCA r4dCA . a3
ist die knotenID. Sie enthält je eine Zufallszahl von Alice und eine Zufallszahl der CA und ist damit zufällig aus dem Namensraum gewählt.
Durch die blinde Signatur erfährt die CA den Wert von a3 nicht.
Korrektheit Wenn Alice und die CA ehrlich sind, erhält Alice eine gültige
Signatur zu ihrem Pseudonym und Schlüsselpaar, sowie eine zufällige
knotenID und ein Signatur für das knotenID Schlüsselpaar.
Vertraulichkeit Durch die blinde Signatur ist der Wert den die CA signiert
vollkommen zufällig. Die CA ist nicht in der Lage Alice Pseudonym
oder die knotenID zu erfahren.
4.2. PROTOKOLLE
4.2.2
25
Create Search Database
Alice kann eine eigene, verteilte Suchmaschine im Netzwerk aufbauen.
1. Sie erzeugt ein Public Key Schlüsselpaar (edb , ddb ) für ihre Datenbank.
2. Sei x die Datenbank mit n Einträgen. Man betrachte die Einträge xi
als Werte eines c-dimensionalen Polynoms qx vom Grad höchstens d =
O(m1/c ) über einem endlichen Körper F . Ein Index i in x entspricht
einem Punkt zi ∈ F c , mit qx (zi ) = xi . Alice berechnet alle Werte
xj = qx (zj ), 1 ≤ j ≤ n des Polynoms.
3. Sie signiert die Werte mit ihrem privaten Schlüssel und bildet eine
Nachricht aus dem Wertepaar, dem Namen der Datenbank und dem
öffentlichen Datenbankschlüssel:
(createDB, x, sigdAlice (zj , xj ), edb )
Die Nachricht sendet Alice über einen anonymen Kanal an den Server
mit der knotenID dbID := H(x, xj ).
4. Der Server speichert das Tupel (zj , xj ) zusammen mit x und dem
öffentlichen Schlüssel edb in einer Datenbank Tabelle.
Korrektheit Wenn Alice und alle Server ehrlich sind, dann speichert jeder
Server einen gültigen Eintrag der Datenbank.
Vertraulichkeit Durch die anonymen Kanäle ist die Kommunikation zwischen Alice und den Servern geschützt. Nur die Server lernen die Werte in Alice Suchmaschine. Alice Pseudonym ist nicht mit ihrer wahren
Identität in Verbindung zu bringen.
Robustheit Unter der Annahme des sicheren Routing erreichen die meisten Datenbankwerte ihren Server oder einen Server in seiner Nachbarschaftsmenge.
4.2.3
Publish
Nehmen wir an, Alice will ein neues Dokument in das System einspeisen.
Dokumente werden so in zwei Fragmente aufgeteilt, dass jedes Fragment für
sich keine Information im informationstheoretischen Sinne enthält. Wenn
Alice ein Dokument m einspeisen möchte, geht sie wie folgt vor:
1. Sie wählt eine Liste von Stichworten k1 , . . . , kl , die das Dokument
möglichst treffend beschreiben. Die Stichworte werden später in der
Suchmaschine verwendet. Sie berechnet den Hashwert H0 := H(k1 | . . . |kl )
der konkatonierten Stichworte mit Hilfe einer öffentlich bekannten 160bit Hashfunktion H.
26
KAPITEL 4. PEER-TO-PEER ENTWURF
2. Alice wählt die 128 höherwertigen Bits von H0 und berechnet daraus
einen Schlüssel k.
3. Alice erzeugt zwei Hashwerte H1 := H(H0 |1) und H2 := H(H0 |2) aus
dem Hashwert H0 . Diese Hashwerte dienen als Fragment Schlüssel.
4. Alice verschlüsselt das Dokument m mit einer symmetrischen Chiffre
(z.B. AES) und dem Schlüssel k: Enck (m).
5. Zuletzt verschlüsselt Alice das Chiffrat Enck (m) mit einem OTP r der
Länge |m| und bildet die Fragmente
p1 := sig((r ⊕ Enck (m), H1 ), dAlice )
p2 := sig((r, H2 ), dAlice )
Der Hashwert H0 muss zum Auffinden des Dokuments bekannt sein.
Die Wahl von H0 als Hashwert der Stichworte k1 , . . . , kl ist nicht zwingend. Wichtig ist nur, dass H0 (pseudo)zufällig gewählt wird und dass
die Fragmente p1 und p2 nicht auf dem selben Knoten abgelegt werden.
6. Alice sendet ein Nachricht (store, σAlice ) ihrem Public Key Zertifikat an die Knoten, die für den Schlüssel zuständig sind, der den 128
höherwertigen Bits von Hi , i = 1, 2 entspricht.
7. Zumindest alle ehrlichen Knoten antworten, indem sie ihre Public Key
Zertifikate und ihren öffentlichen Schlüssel eserver an Alice senden. Jeder Server verfügt über einen oder mehrere Zugangspunkte für seinen Dienst. Jeder der Zugangspunkt hat von seinem Server eine Zufallszahl c bekommen. Alice muss diesen Wert in ihre Suchmaschine
eintragen.Die Server senden Alice die Adresse ihrer Zugangspunkte
knotenIDzp und den Zufallswert c. Alice überprüft die Gültigkeit der
Zertifikate.
8. Alice erzeugt ein Public Key Schlüsselpaar (ef ile , df ile ) und sendet an
alle Server, die gültige Zertifikate gesendet haben, die Nachricht:
(pi , Enc((Hi , ef ile ), eserver ))
9. Die Server speichern das Fragment, den Fragment Schlüssel und den
öffentlichen Schlüssel.
Um das Dokument über die P IR Suche im Netzwerk auffindbar zu machen,
führt Alice für jedes Stichwort k die folgenden Schritte aus:
1. Sie bildet k mit einer Hashfunktion auf einen numerischen Index i ab,
dem ein Punkt zi ∈ F c zugeordnet ist.
4.2. PROTOKOLLE
27
2. Sie bildet das Tupel
xi := (knotenIDzp , H0 , c)
wobei knotenIDzp die Liste von Zugangspunkten ist, H0 der Dokumentenschlüssel und c die Liste von Zufallszahlen für die Zugangspunkte.
3. Alice setzt den Wert ihrer Funktion qx an der Stelle zi auf den Wert
des Tupels: qx (zi ) := xi
4. Alice baut einen anonymen Kanal zu dem Server auf, der den Wert
des Polynoms an der Stelle zi speichert.
5. Sie sendet eine Nachricht (updateDB, sig((x, xi ), ddb )) an den Server.
Der überprüft die Signatur mit dem Datenbankschlüssel. Wenn die
Signatur korrekt ist, aktualisiert er die Datenbank mit dem neuen
Wert xi .
Korrektheit Es ist einfach nachzuvollziehen, dass wenn alle Teilnehmer
ehrlich handeln, zwei korrekte Fragmente eingespeist werden, und beide zusammen mit dem korrekten Schlüssel das Dokument liefern.
Vertraulichkeit Der OTP bietet perfekte Sicherheit im informationstheoretischen Sinne. Daher kann weder einer der Server, noch ein dazwischenliegender Router den Inhalt der Fragmente entschlüsselen. Selbst
wenn beide Fragmente bekannt sind, ist der Inhalt noch mit einer symmetrischen Chiffre geschützt.
Der Fragment Schlüssel Hi ist nur Alice und den Servern bekannt.
Genauer ist nur Alice und den Servern bewusst, dass ein Dokument
eingespeist wird, da der anonyme Kanal Ende-zu-Ende verschlüsselt
ist. Wenn einer der Server maliziös ist, weiß er, dass Alice ein Dokument publiziert. Er kann von dem Pseudonym aber nicht auf Alice
wirkliche Identität schließen. Alice bleibt als Autor gegenüber den Servern (pseudo-)anonym.
Robustheit Robustheit verlangt, dass die Fragmente auch dann an die
korrekten Server ausgeteilt werden, wenn f Teilnehmer maliziös sind
und beliebig vom Protokoll abweichen. Ich benutze die Annahme des
sicheren Routing und der robusten Replizierung durch Pastry.
Alice kann den anonymen Kanal auch dann aufbauen, wenn f der
Knoten Nachrichten löschen oder falsch weiterleiten. Um das zu sehen,
nehmen wir an, dass Alice bereits einen Kanal der Länge n (n = 0 ist
zulässig) aufgebaut hat und betrachten die Erweiterung des Kanals um
einen weiteren n+1-ten Knoten. Durch das sichere Routing erreicht die
extend -Nachricht den letzten Knoten auf dem Kanal. Wenn Alice, eine
28
KAPITEL 4. PEER-TO-PEER ENTWURF
extended -Antwort bekommt, kann sie über den Hashwert feststellen, ob
der Kanal um den richtigen Knoten erweitert wurde. Ist der Hashwert
falsch, baut sie einen neuen Kanal mit anderen Routern P10 , . . . , Pn0
auf. Im schlimmsten Fall, indem Alice bei jedem Versuch genau einen
der f maliziösen Router auswählt, benötigt sie f + 1 Versuche bis sie
den Kanal erfolgreich aufgebaut hat. Um den Aufwand zu reduzieren
könnte Alice sich auf einen kürzeren Kanal beschränken, sobald sie
merkt, dass ihrer Versuche einen Kanal aufzubauen gestört werden.
Wenn der Kanal aufgebaut ist, kann Alice ihre store-Nachricht an
den Server senden. Durch die Replizierung im Pastry Netz, wird das
Fragment auf allen Servern aus der Nachbarschaftsmenge des Servers
gespeichert. Um das Speichern der Fragments zu verhindern, müsste
ein Angreifer alle Knoten der Nachbarschaftsmenge kontrollieren. Die
Wahrscheinlichkeit, dass ein Angreifer so viele numerisch nah zusammen liegende knotenIDs erhalten kann, ist sehr gering, wenn wir eine
CA zur Vergabe der Pseudonyme verwenden.
4.2.4
Search
Der Client Bob möchte nach Dokumenten suchen, die einer Reihe von Stichworten k1 , . . . , kl entsprechen. Er berechnet im ersten Schritt die Hashwerte
H(k1 ), . . . , H(kl ) aller Stichworte. Auf diese Weise erhält Bob für jedes Stichwort einen numerischen Wert, der als Eingabe für ein Private Information
Retrieval (PIR) Schema genutzt wird. Bob führt für jedes Stichwort, wie
in Abschnitt 3.5.3 beschrieben, ein k-robustes PIR Protokoll mit den Suchmaschinenservern aus, bei dem er den i := H(ki ) -ten Eintrag der Suchdatenbank lernt, ohne, dass die Server erfahren, nach was für einem Wort er
gesucht hat.
1. Bob bildet den Index i auf einen Punkt zi ∈ F c ab
2. Bob wählt eine zufällige Kurve p = (p1 , . . . , pc ) vom Grad k mit p(0) =
zi und t = kd + 1 zufällige Stützstellen aj ∈ F \{0}.
3. Er sendet an die Server t anonyme Anfragen vj = p(aj ) ∈ F c und
zufällige Rauschwerte bj ∈R F c , so dass die Anzahl der Rauschwerte
aller Clients mindestens n beträgt.
4. Jeder Server antwortet auf die Anfrage vj mit dem Wert sj = qx (vj )
aus seiner Tabelle mit Datenbankwerten.
5. Die Punkte (aj , sj ) legen ein Polynom qx ◦ p vom Grad kd fest. Bob
interpoliert diese Punkte, wertet das Polynom an der Stelle 0 aus und
erhält den Eintrag xi . xi hat die Form eines Tupels
(knotenIDzp , H0 , czp )
4.2. PROTOKOLLE
29
knotenIDzp ist die Liste von knotenIDs der Zugangspunkte für den
versteckten Dienst, H0 ist der Schlüssel des Dokuments, czp ist eine
Zufallszahl, mit der der Zugangspunkt die Anfrage Bob zuordnen kann.
Bob kann durch Schnittmengenbildung der einzelnen Anfragen eine boolsche
Verknüpfung der Stichworte bilden.
Korrektheit Wenn Bob und alle Datenbankserver ehrlich sind, dann lernt
Bob den Eintrag zu seiner Suchanfrage.
Vertraulichkeit Die Vertraulichkeit für Bob’s Anfrage folgt direkt aus den
Eigenschaften des PIR Protokolls. Bob’s Identität bleibt durch die
anonyme Kommunikation geheim.
Robustheit Um die Robustheit des Protokolls zu erhöhen kann man die
Anzahl der Anfragen auf t = kd + l erhöhen und einen fehlerkorrigierenden Code auf die Ergebnisse anzuwenden. Dann kann Bob auch
dann das Tupel zu seiner Anfrage rekonstruieren, wenn bis zu l − 1 der
Server falsche oder keine Antworten senden.
4.2.5
Retrieve
Bob ist nun im Besitz des Schlüssels für ein Dokument, auf das seine Suchanfrage passt. Um das Dokument H0 herunterzuladen, bildet er die Hashwerte
H1 = H(H0 |1) und H2 = H(H0 |2) und erhält die Schlüssel zu den beiden
Fragmenten des Dokuments. Nehmen wir an, der Knoten Carol speichert
das Fragment p1 . Wenn Bob p1 herunterladen will, kontaktiert er Carol’s
versteckten Dienst. Sämtliche Kommunikation läuft dabei über anonyme
Kanäle.
1. Bob wählt einen Knoten knotenIDrp als Rendezvous Punkt und sendet ihm eine Zufallszahl ccarol .
2. Er schickt eine retrieve-Nachricht
(EncCarol (H1 , knotenIDrp , ccarol ), g x , czp )
an den Zugangspunkt knotenIDzp . Die Nachricht enthält den mit
mit Carol’s öffentlichem Schlüssel chiffrierten Fragment Schlüssel, den
Rendezvous Punkt, die Zufallszahl cCarol , die erste Hälfte eines DiffieHellmann Schlüssels und die Routing Information czp .
3. Der Zugangspunkt knotenIDzp weiß auf Grund der Zufallszahl czp ,
dass die Nachricht für Carol bestimmt ist. Er sendet die Nachricht
(EncCarol (H1 , knotenIDrp , ccarol ), g x )
an Carol weiter.
30
KAPITEL 4. PEER-TO-PEER ENTWURF
4. Carol erzeugt die zweite Hälfte des Diffie-Hellmann Schlüssels und berechnet den Schlüssel K := g xy . Sie verschlüsselt p1 mit einer symmetrischen Chiffre und dem Schlüssel K.
5. Carol sendet
(EncK (p1 ), g y , H(K), ccarol )
an den Rendezvous Punkt von Bob.
6. Wenn ccarol gleich der Zufallszahl ist, die der Rendezvous Punkt zuvor
von Bob bekommen hat, schickt er die Nachricht an Bob weiter.
7. Bob prüft, ob Carol den korrekten Hashwert des gemeinsamen Schlüssels
geschickt hat. Wenn ja, entschlüsselt er p1 und erhält das erste Fragment.
Für das Fragment p2 geht Bob genauso vor. Dann berechnet er Enck0 (m) als
das bitweise XOR Produkt der Fragmente und dechiffriert mit dem Schlüssel
k 0 . Es ist zu beachten, dass außer Bob und Carol niemand die vollen 160 Bit
der Schlüssel H1 und H2 erfährt. Der Schlüssel wird mit bei der Übertragung
durch Verschlüsselung mit Carol’s öffentlichem Schlüssel geschützt. Carol’s
Zugangspunkt knotenIDzp leitet die Nachricht nur aufgrund der Kenntnis
von czp an Carol weiter, ohne den Inhalt zu kennen. Die Kommunikation
zwischen Carol zu Bob wird durch Verschlüsselung mit K geschützt.
Korrektheit Wenn Bob, Carol und alle Router auf dem anonymen Kanal
ehrlich handeln, erhält Bob beide Fragmente und damit das Dokument.
Die Korrektheit ist einfach nachzuvollziehen.
Vertraulichkeit Die Anonymität von Bob folgt aus den Eigenschaften der
anonymen Kanäle. Vor allem bleibt Bob gegenüber Carol anonym.
Carol sieht lediglich den von Bob gewählten Rendezvous Punkt. Bob
erfährt aus der Suchmaschinen Datenbank den öffentlichen Datenbankschlüssel von Carol. Bob kennt aber nicht Carol’s Pseudoidentität (und natürlich auch nicht ihre wahre Identität). Er sieht lediglich den von Carol veröffentlichten Zugangspunkt. Durch die Verschlüsselung des Index Hi mit Carol’s öffentlichem Schlüssel und die
Verschlüsselung auf dem anonymen Kanal, bleibt allen anderen Knoten verborgen, welcher Schlüssel von Bob angefragt wurde.
Robustheit Die Robustheit des anonymen Kanals zeigt sich analog zu dem
Publish-Protokoll. Wenn Bob den Kanal aufgebaut hat, kann er seine
retrieve-Nachricht senden. Unter der Annahme des sicheren Routing
gelangt die Nachricht zu den Servern, die in der Nachbarschaftsmenge
von Carol liegen. Wenn nicht alle Server korrupt sind, sendet mindestens einer das passende Fragment über den anonymen Kanal an Bob
zurück.
4.2. PROTOKOLLE
4.2.6
31
Update File
Alice möchte ein Dokument m, das sie zuvor in das Netzwerk eingespeist
hat, aktualisieren. Sie bildet zwei Fragmente zu dem neuen Dokument m0 :
p1 := sig((r ⊕ Enck (m0 ), H1 ), dAlice )
p2 := sig((r, H2 ), dAlice )
Die Fragment Schlüssel H1 und H2 ändern sich nicht, da sie nur von den
Stichworten, und nicht von dem Dokument selbst. Für jeden Fragment Schlüssel
aktualisiert Alice das Fragment:
1. Alice sendet eine update-Nachricht
(updateF ileRequest, Hi )
mit dem Fragment Schlüssel an alle Server deren knotenIDs numerisch
nah an den 128 höherwertigen Bits von Hi liegen.
2. Zumindest alle ehrlichen Knoten antworten auf die Nachricht, indem
sie jeweils eine Zufallszahl r mit dem Schüssel ef ile aus dem PublishProtokoll chiffrieren und zusammen mit ihrem Public Key Zertifikat
zurücksenden.
3. Alice prüft die Zertifikate und entschlüsselt r mit dem privaten Schlüssel
df ile . Sie erhöht den Wert von r um eins.
4. Sie sendet eine Nachricht
(updateF ile, r + 1, pi )
mit dem inkrementierten Wert r + 1 und dem neuen Fragment pi an
alle Server, die gültige Zertifikate gesendet haben.
5. Die Server überprüfen, ob Alice den Wert r + 1 korrekt inkrementiert
hat. Wenn ja, ersetzen sie das alte Fragment durch das neue.
Korrektheit Es ist leicht zu sehen, dass wenn alle Teilnehmer ehrlich sind,
am Ende des Protokolls alle Fragmente des Dokuments durch neue
ersetzt werden.
Vertraulichkeit Die Vertraulichkeit des Protokolls folgt aus der gleichen
Argumentation wie im Publish-Protokoll.
Robustheit Die Robustheit der anonymen Kanäle zur Kommunikation
zwischen Alice und den Servern folgt wie im Publish-Protokolls aus
der Annahme des sicheren Routing und der Voraussetzung, dass ein
Angreifer nur einen kleinen Teil der Knoten im Netzwerk kontrollieren
kann.
32
KAPITEL 4. PEER-TO-PEER ENTWURF
4.2.7
Update Search Entry
Alice möchte einen Eintrag in ihrer Suchmaschine aktualisieren. Sie führt
für jedes Stichwort k die folgenden Schritte aus:
1. Sie bildet k mit einer Hashfunktion auf einen numerischen Index i ab,
dem ein Punkt zi ∈ F c zugeordnet ist.
2. Alice bildet das Tupel
xi := (knotenIDzp , H0 , czp )
wobei knotenIDzp eine Liste von Zugangspunkten ist, H0 der Dokumentenschlüssel und czp eine Zufallszahl.
3. Sie setzt den Wert der Funktion qx an der Stelle zi auf den Wert des
Tupels: qx (zi ) := xi
4. Alice sendet eine updateDB -Nachricht (updateDB, x) über einen anonymen Kanal an den Server Si , der den Wert des Polynoms an der
Stelle zi speichert.
5. Zumindest alle ehrlichen Server aus der Nachbarschaft von Si antworten auf die Anfrage, indem sie eine Zufallszahl r mit dem Schüssel edb
chiffrieren und zusammen mit ihrem Public Key Zertifikat zurücksenden.
6. Alice prüft die Zertifikate und entschlüsselt r mit dem privaten Schlüssel
ddb . Sie erhöht den Wert von r um eins.
7. Sie sendet eine Nachricht
(updateDB, r + 1, sig((x, xi ), ddb ))
mit dem inkrementierten Wert r + 1 und dem Datenbanktupel pi an
alle Server, die gültige Zertifikate gesendet haben.
8. Die Server können überprüfen, ob Alice den Wert r + 1 korrekt inkrementiert hat.
9. Wenn ja, ersetzen sie den Wert des Polynoms an der Stelle zi durch
den neuen Wert xi .
Korrektheit Es ist auch hier leicht zu sehen, dass wenn alle Teilnehmer
ehrlich sind, am Ende des Protokolls der alte Datenbankeintrag durch
einen neuen ersetzt wird.
Vertraulichkeit Die Vertraulichkeit des Protokolls folgt aus der gleichen
Argumentation wie im Publish-Protokoll.
4.2. PROTOKOLLE
33
Robustheit Die Robustheit der anonymen Kanäle zur Kommunikation
zwischen Alice und den Servern folgt wie im Publish-Protokolls aus
der Annahme des sicheren Routing und der Voraussetzung, dass ein
Angreifer nur einen kleinen Teil der Knoten im Netzwerk kontrollieren
kann.
4.2.8
Delete File
Alice kann ein Dokument, das sie zuvor im Netzwerk gespeichert hat, auch
wieder löschen. Dazu führt sie das folgende Protokoll aus:
1. Alice sendet eine Nachricht
(deleteRequest, Hi )
an alle Server, deren knotenIDs numerisch nah an den 128 höherwertigen
Bits von Hi liegen.
2. Die Server antworten mit einer Zufallszahl r, die mit dem öffentlichen
Dokumentenschlüssel verschlüsselt ist und ihre Public Key Zertifikate
zurücksenden.
3. Alice prüft die Zertifikate und entschlüsselt r mit dem privaten Schlüssel
df ile . Sie erhöht den Wert von r um eins.
4. Sie sendet eine Nachricht
(delete, Hi , r + 1)
mit dem inkrementierten Wert r + 1 alle Server, die gültige Zertifikate
gesendet haben.
5. Die Server überprüfen, ob Alice den Wert r + 1 korrekt inkrementiert hat. Wenn ja, löschen die Server ihr Fragment pi , den Fragment
Schlüssel Hi und den öffentlichen Schlüssel ef ile .
Korrektheit, Vertraulichkeit, Robustheit Die Korrektheit, Vertraulichkeit und Robustheit des Protokolls folgen direkt aus den Eigenschaften
des Update File-Protokolls.
4.2.9
Delete Search Entry
Wenn Alice ein Dokument löscht, muss sie auch die dazugehörigen Einträge
aus ihrer Datenbank entfernen. Für jedes Stichwort k zu dem Dokument
führt Alice das folgende Protokoll aus:
1. Sie bildet k mit einer Hashfunktion auf einen numerischen Index i ab,
dem ein Punkt zi ∈ F c zugeordnet ist.
34
KAPITEL 4. PEER-TO-PEER ENTWURF
2. Mit dem Punkt berechnet sie den Wert xi = qx (zi) und den Schlüssel
dbID := H(x, xi ).
3. Alice sendet eine Nachricht
(deleteDBRequest, xi )
an die Knoten, dessen knotenID den 128-höherwertigen Bits von dbID
numerisch nah sind.
4. Zumindest alle ehrlichen Server antworten auf die Nachricht, indem
sie ähnlich zum Delete File-Protokoll eine mit dem öffentlichen Datenbankschlüssel chiffrierte Zufallszahl r schicken.
5. Alice sendet eine Nachricht
(deleteDB, xi , r + 1)
mit dem um eins inkrementierten Wert an die Server zurück.
6. Die Server überprüfen, ob Alice den korrekten Wert r + 1 gesendet
hat. Wenn ja, löschen sie den Eintrag xi aus der Datenbank qx .
Korrektheit, Vertraulichkeit, Robustheit Die Korrektheit, Vertraulichkeit und Robustheit des Protokolls folgt aus der Korrektheit und Sicherheit des Delete File-Protokolls. Nur dass die Server einen Datenbank Eintrag löschen statt eines Fragments.
Kapitel 5
Zusammenfassung
In diesem Kapitel fasse ich die Ergebnisse meiner Arbeit zusammen. Ich beschreibe welche Ziele erreicht wurden und gebe einen Ausblick auf zukünftige
Arbeiten.
In meiner Arbeit habe ich ein anonymes Peer-to-Peer Informationssystem entworfen, dass Anonymität und Suchfunktion verbindet. In Kapitel
1 habe ich anonyme Peer-to-Peer Netzwerke als anonyme, zensurresistente
Informationssysteme motiviert. In Kapitel 2 habe ich einen Überblick über
bestehende Peer-to-Peer Netzwerke und vorangegangene Publikationen gegeben. In Kapitel 3 habe ich die nötigen Bausteine für meinen Peer-to-Peer
Entwurf eingeführt und erklärt. In Kapitel 4 habe ich Protokolle für die
grundlegenden Funktionen des Peer-to-Peer Systems angegeben und ihre Sicherheit diskutiert.
Ich habe das Peer-to-Peer Filesharing System von Endsuleit und Mie[10]
um TOR Onion Routing und PIR ergänzt und damit ein System konstruiert,
in dem Inhalte über eine Stichwortsuche zugänglich sind, der Schutz der
Serverbetreiber gegen strafrechtliche Verfolgung aber weiter gegeben ist. Das
System erfüllt Sicherheit nicht nur im kryptographischen Sinne, sondern
auch aus einer juristischen Sicht.
5.1
Ergebnisse
In diesem Abschnitt fasse ich zusammen, welche Ziele in meinem Entwurf
erreicht werden konnten.
5.1.1
Anonymität für Autoren, Leser und Server
Ein Dokument ist in dem Peer nur an das Pseudonym eines Benutzers gebunden. Die wahre Identität eines Autors oder Lesers kann nicht aus seinem
Pseudonym ermittelt werden. Selbst wenn die CA angegriffen wird, oder zur
35
36
KAPITEL 5. ZUSAMMENFASSUNG
Herausgabe ihrer Daten gezwungen wird, ist es nicht möglich, einem Pseudonym eine reale Identität zuzuordnen. Das System gewährleistet also Autor
Anonymität im Sinne von Pseudonymität.
Die Privatsphäre der Leser bleibt gewahrt. Die Kommunikation verläuft
über Rendezvous Punkte und anonyme Kanäle. Der Server selbst erfährt
nicht, welcher Client das Dokument haben möchte. Die Privatsphäre des
Lesers bleibt auch gegenüber einem Angreifer gewahrt, der seinen Datenverkehr abhört. Der Fragment Schlüssel wird nicht im Klartext übertragen, so
dass nur der Server ihn lesen kann. Wenn der Server das zugehörige Fragment an den Client sendet, bleibt der Inhalt auch vor einem mächtigen
Angreifer verborgen. Nehmen wir zum Beispiel einen ISP, der das gesamte
Datenaufkommen des Clients aufzeichnet (oder aufzeichnen muss): Es ist
ihm nicht möglich den Inhalt eines Dokuments zu rekonstruieren, solange
es mit dem OTP verschlüsselt ist. Um den OTP zu überwinden, müsste er
zunächst den Diffie-Hellmann Schlüssel brechen und die beiden Fragmente
finden, die zu dem selben Dokument gehören. Aber die Datei ist noch einmal
verschlüsselt, so dass die korrekt zusammengesetzten Fragmente nur schwer
von anderen Kombinationen unterscheidbar sind. In einem Netz mit hohem
Datenaufkommen, ist dieser Angriff ohne große Aussicht auf Erfolg.
Der Ablageort des Dokuments hängt nicht vom Dokument selbst, sondern von den Stichworten, die das Dokument beschreiben, ab. Die Server
sind im Netzwerk unter ihrer knotenID bekannt. Zu einem herausgegriffenen Dokumentenschlüssel weiß man durch die verteilte Hashtabelle, welche
knotenID das Dokument speichert. Die IP-Adresse zu der knotenID ist aber
nur benachbarten Knoten bekannt. Server Anonymität ist in meinem Entwurf nur im Sinne von Pseudonymität gegeben.
5.1.2
Schutz des Serverbetreibers gegen strafrechtliche Verfolgung
Auf den Servern werden nur Zeichenketten gespeichert, ohne das sie Information im informationstheoretischen Sinne enthalten. Ein Betreiber kann
glaubhaft abstreiten, bestimmte Informationen auf seinem Rechner zu speichern. Wenn echter Zufall verwendet wird, bietet das System perfekte Dokumenten Anonymität.
5.1.3
Schutz vor Zensur der Inhalte
Durch das Erschweren von DoS Angriffen, die zufälligen knotenIDs und die
Dokumenten Anonymität sollte es selbst für einen mächtigen Angreifer nur
schwer möglich sein, gezielt Inhalte in dem System zu zensieren. Der Angreifer kann über die Stichwortsuche nach Inhalten suchen, erfährt aber nur
5.2. AUSBLICK
37
den Zugangspunkt zu dem Server.
Zusätzlich werden Inhalte von benachbarten Servern repliziert. Um ein
Fragment ohne Kenntnis des passenden Schlüssels zu entfernen müsste er
gleichzeitig alle Server aus der Nachbarschaftsmenge ausschalten.
5.1.4
Erreichbarkeit der Dokumente über eine Stichwortsuche
Ein Client muss nicht mehr die exakten Stichworte zu einem Dokument
kennen. Er kann nach einzelnen Stichworten suchen und anschließend das
Dokument herunterladen, ohne das der Inhalt seiner Anfrage anderen bekannt wird. Das erleichtert das Suchen nach Informationen und macht die
Benutzung für den Client komfortabler.
5.1.5
Erschweren von DoS Attacken
Die IP-Adresse des Servers ist nur den benachbarten Knoten bekannt. Die
Server sind über versteckte Dienste erreichbar, so dass selbst ihre knotenID
verborgen bleibt. Andere Rechner kommunizieren mit dem Server lediglich
über dessen Zugangspunkte und Rendezvous Punkte. Wird ein Zugangspunkt Ziel einer DoS Attacke, kann der Server die von dem Zugangspunkt
empfangenen Nachrichten einfach ignorieren oder einen neuen Zugangspunkt
für seinen Dienst wählen. Wenn der Server dennoch Opfer eines DoS Angriffs
wird, gibt es immer noch seine Nachbarschaftsmenge. Nach dem Ausfall eines Servers wird ein neuer Server in die Nachbarschaftsmenge aufgenommen
und die Daten auf ihm repliziert.
5.2
Ausblick
Von Seiten der Theorie wäre es interessant zu versuchen, den Begriff anonymes Peer-to-Peer formal zu definieren und die Anonymität und Sicherheit
von anonymen Peer-to-Peer Systemen formal zu beweisen.
In der Praxis gibt es in Peer-to-Peer Netzwerken noch viele Probleme,
die gelöst werden müssen, wenn man ein Informationssysteme auf der Peerto-Peer Architektur aufbauen möchte. Hier ist weitere Arbeit notwendig, um
Peer-to-Peer Netzwerke sicherer zu machen.
Es wäre interessant meinen Entwurfs zu implementieren und zu testen.
Vor allem die Frage, wie weit das System skaliert und welchen Belastungen
es standhält, könnten im Experiment untersucht werden.
38
KAPITEL 5. ZUSAMMENFASSUNG
Es bleibt abzuwarten, wie sich bestehende Projekte, vor allem Free Haven, entwickeln. Bis jetzt scheint es bei vielen Anwendern noch kein Bedürfnis
nach Anonymität zu geben, jedenfalls nicht, wenn dies mit Leistungseinbußen verbunden ist. Eine kleine Zahl an Benutzern verspricht aber gleichzeitig
ein geringeres Maß an Anonymität. Es wird zu untersuchen sein, wie ein optimaler Kompromiss zwischen Anonymität und Performanz aussehen kann.
Literaturverzeichnis
[1] Mute. http://www.mute.net.sourceforge.net.
[2] Random.org. http://www.random.org.
[3] A.Osram. Peer-to-Peer - Harnessing the Power of Disruptive Technology. O’Reilly, 2001.
[4] M. Castro, P. Drushel, A. Ganesh, A. Rowstron, and D. Wallach. Secure
routing for structured peer-to-peer overlay networks, 2002.
[5] B. Chor, N. Gilboa, and M. Naor. Private information retrieval by
keywords, 1997.
[6] Benny Chor, Oded Goldreich, Eyal Kushilevitz, and Madhu Sudan.
Private information retrieval. In IEEE Symposium on Foundations of
Computer Science, pages 41–50, 1995.
[7] Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore W. Hong.
Freenet: A distributed anonymous information storage and retrieval
system. Lecture Notes in Computer Science, 2009:46–??, 2001.
[8] R. Dingledine, N. Mathewson, and P. Syverson.
generation onion router, 2004.
Tor: The second-
[9] Roger Dingledine, Michael J. Freedman, and David Molnar. The free
haven project: Distributed anonymous storage service, July 19 2000.
[10] T. Endsuleit, R.; Mie. Censorship-resistant and anonymous p2p filesharing, availability, reliability and security, 2006. ares 2006. the first
international conference on , vol., no.pp. 58- 65, 20-22 april 2006, 2006.
[11] Yuval Ishai Eyal. Cryptography from anonymity.
[12] Ralph C. Merkle. Secure communications over insecure channels. Commun. ACM, 21(4):294–299, 1978.
[13] A. Rowstron and P. Druschel. Pastry: Scalable, distributed object location and routing for large-scale peer-topeer systems, 2001.
39
40
LITERATURVERZEICHNIS
[14] A. Serjantov. Anonymizing censorship resistant systems, 2002.