I2P

Transcription

I2P

Seminar:
Erstellen und Analysieren einer Beispielimplementierung der
nichttrivialen Verzögerung in dem I nvisible I nternet P roject
(I2P)
Krieg, Lukas
53506
Kubitza, Henrik
53580
Tauchnitz, Johannes
53579
14. Juni 2016
Betreuhender Professor
Prof. Dr. Rainer Werthebach
Wir diskutieren und erstellen eine Beispielimplementierung der nichttriviale Verzögerung
im Anonymisierungsnetzwerk I2P, und besprechen die Auswirkungen auf unterschiedliche Angriffsszenarien und den Ressourcenbedarf der Router. Einführend geben wir eine
Übersicht über die Funktionsweise von I2P und anderen relevanten Anonymisierungsnetzwerken.
Arguing that you don’t care about the right to privacy because you have nothing
to hide is no different than saying you don’t care about free speech because you
have nothing to say. — EDWARD SNOWDEN
1
Eidestattliche Erklärung
Hiermit versichern wir, die vorliegende Seminararbeit selbstständig und nur unter Verwendung der von uns angegebenen Quellen und Hilfsmittel verfasst zu haben. Sowohl inhaltlich
als auch wörtlich entnommene Inhalte wurden als solche kenntlich gemacht. Die Arbeit hat
in dieser oder vergleichbarer Form noch keinem anderem Prüfungsgremium vorgelegen.
Datum
Krieg Lukas
Kubitza Henrik
Tauchnitz Johannes
2
Inhaltsverzeichnis
1 Bedeutung und Nutzen des I2P
4
2 Grundlagen der Funktionsweise von I2P
2.1 Tunnel . . . . . . . . . . . . . . . . . . . .
2.2 Garlic Verfahren . . . . . . . . . . . . . .
2.3 Eepseiten . . . . . . . . . . . . . . . . . .
2.4 Krytographische Verfahren . . . . . . . .
2.5 Vergleich zwischen I2P und Tor . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
7
7
8
3 Bedrohungen und Angriffsarten auf I2P
3.1 Brute-Force Angriff . . . . . . . . . . . .
3.2 Timing Angriff . . . . . . . . . . . . . .
3.3 Verkehrsanalyseangriff . . . . . . . . . .
3.4 Intersection Angriff . . . . . . . . . . . .
3.5 Denial of Service Angriffe . . . . . . . .
3.5.1 Starvation Angriff . . . . . . . .
3.5.2 CPU Load Angriff . . . . . . . .
3.5.3 Floodfill-DOS Angriff . . . . . .
3.6 Tagging Angriffe . . . . . . . . . . . . .
3.7 Partitioning Angriffe . . . . . . . . . . .
3.8 Harvesting Angriffe . . . . . . . . . . . .
3.9 Zeitvergeichsangriffe . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
10
11
11
11
11
11
11
12
13
4 Nichttriviale Verzögerung
4.1 Idee . . . . . . . . . . . . . . . . . . . . . .
4.2 Herausforderungen bei der Implementation
4.3 Implementierung . . . . . . . . . . . . . . .
4.4 Testen der Implementierung . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
15
16
.
.
.
.
.
.
.
.
.
.
.
.
5 Review
16
6 Hinweise
18
7 Code
18
3
1
Bedeutung und Nutzen des I2P
Mit der Verbreitung des Internets gegen Ende des 20. Jahrhunderts und dessen neuer Art
der Kommunikation bildeten sich auch neue Bedürfnisse auf Seiten der Nutzer aber auch
auf Seiten des Staates. Während der Staat für die Sicherheit seiner Bürger sorgen möchte,
genießt der Internetnutzer die neugewonnene Möglichkeit Texte, Bild- oder Sprachaufnahmen
weitestgehend anonym über das Internet teilen und veröffentlichen zu können.
Dies führt zu einem Spannungsfeld, in welchem das Grundrecht auf informelle Selbstbestimmung (Interessen von Journalisten, Anwälten und politischen Aktivisten) auf das staatliche Interesse der Sicherheit trifft. Dies führt zu einer undurchsichtigen Lage, in der Behörden
das existierende Recht in unterschiedlichen Bereichen zu ihren Gunsten auslegen und niemand
wirklich sicher sein kann, was über seine Kommunikation wem bekannt sein darf oder bereits
bekannt ist. Außerdem ist es wahrscheinlich, dass die Kommunikation auch durch Drittstaaten
mit anderen Rechtsgrundlagen fließt. Deshalb sind viele Bürger daran interessiert ihre Kommunikationswege, Nachrichtenquellen, sowie Freundschaften vor möglicher Identifizierung zu
schützen. Eine gute Methode um dies zu erreichen ist ein persönliches Treffen an einem sicheren Ort. Wenn dies jedoch nicht möglich ist, sind Anonymisierungsnetzwerke wie Tor und
I2P eine gute Alternative für eine ausreichend anonyme und sichere Kommunikation.
Wir gewinnen Anonymität. Und dadurch Frieden. “ [Hydra ]
”
I2P ist eines der größten Anonymisierungsnetzwerke, welches nicht von einer Regierung gesponsert wird und dadurch vollkommen autark ist. Außerdem sind einige der Kernentwickler,
sowie der (nicht mehr aktive) Gründer nicht mit bürgerlichem Namen bekannt. Dies ist gleichzeitig ein Vorteil, da Angreifer nicht wissen, welche Personen sie unter Druck setzen müssen,
um an Informationen zu gelangen. Obwohl viele Entwickler anonym sind, ist das Invisible Internet Project sehr offen. Die Besprechungsrunden sowie Email-Listen sind dokumentiert und
im Internet und innerhalb von I2P abrufbar. [I2PMeeting ] Außerdem werden alle Commits
kryptographisch signiert, und sind den Pseudonymen der Entwickler zuordenbar. [devguid ]
Zuletzt ist I2P deutlich kleiner als Tor, nicht nur in der Anzahl der Benutzer, sondern
auch in der Anzahl der Entwickler, was ein Einarbeiten in das Projekt erleichtert. Außerdem
sind viele interessante Probleme und Möglichkeiten schon in der Spezifikation angedacht und
teilweise sogar schon dokumentiert, jedoch noch nicht implementiert, was einen interessanten
Einstieg ermöglicht.
Trotz seiner (im Vergleich zu Tor) geringen Benutzerzahl sind über 60.000 Router
”
online [...].“ [I2PStat ]
4
2
Grundlagen der Funktionsweise von I2P
I2P ist ein Paket basiertes Anonymisierungsnetzwerk, dass international von Freiwilligen betrieben wir. Dazu installieren Benutzer eine Software auf ihren (ganz normalen) Computern,
mit der sich Browser und andere Dienste wie mit einem Proxy verbinden. Dadurch können
sie auch von anderen als Router verwendet werden. Um I2P Seiten (Eepsites) einsetzen zu
können, verbindet der Client sich mit den einprogrammierten oder durch die vorherigen Starts
bekannten Routern und erfrägt von ihnen Informationen über das Netzwerk. Diese verwendet
der Client, um seine eigene Netzwerkdatenbank zu erstellen. In der Netzwerkdatenbank werden alle bekannten Router, deren kryptographischer öffentlicher Schlüssel, IP-Adresse, sowie
seine Eigenschaften in signierter Form gespeichert. Zusätzlich wird seine Qualität repräsentiert
durch Datendurchsatz und Betriebszeit regelmäßig aktualisiert.
Zu den Eigenschaften eines Routers zählt auch, ob er ein Floodfill -Router ist oder nicht.
Floodfill -Router senden nicht, wie der Name vermuten ließe, eine Flut an Paketen, sondern
speichern einen Teil der im Netzwerk vorhanden LeaseSets sowie Router Infos, die für das
Kontaktieren von Knoten notwendig sind. In der Router Info sind hierbei die Physikalische
IP-Adresse und öffentlichen Schlüssel eines Routers hinterlegt. Das LeaseSet besteht mehreren
Leases, jedes Lease repräsentiert einen Tunnel dessen Informationen benötigt werden um ein
Ziel zu kontaktieren. Ein LeaseSet ist somit ein Bündel aus Tunnelinformationen und enthält
Daten darüber, wie alt es ist und einen Signaturschlüssel bzw. eine Signatur der Daten.
[leasset ] Jedes Lease enthält IP-Adresse des Gateways, Tunnel-ID und öffentliche Schlüssel
aller Teilnehmer des Tunnels. Um sich mit einer I2P Adresse verbinden zu können, muss das
LeaseSet dem Client bekannt sein. Deshalb kann dieses bei Floodfill Routern erfragt werden.
Um ein Leaseset zu bekommen, frägt der Client die Router, deren Hash in der Nähe der
.b32.I2P Adresse des Zieles liegen. Die Router senden das Leaseset anschließend dem Client
zu, welcher dann mit dem im Leaseset eingetragenen Router eine Verbindung aufbauen kann.
2.1
Tunnel
Innerhalb von I2P werden Nachrichten in eine Richtung mittels unidirektionalen Tunneln weitergereicht. Es wird deshalb zwischen Eingangstunnel (Inbound) und Ausgangstunnel (Outbound) unterschieden. Ein Tunnel besteht aus einem oder mehreren Routern, welche dabei
auch als Hops bezeichnet werden. Die Tunnellänge kann dabei in der I2P Router Konsole
eingestellt werden, wobei generell gilt: Umso länger der Tunnel, desto höher ist der Grad der
Sicherheit, aber auch die Zeit, die ein Paket durch ihn benötigt. Tunnellängen größer als drei
sind nicht signifikant sicherer als ein Tunnel der Länge drei. [torLng ]. Die variable Tunnellänge macht es Angreifern noch schwerer den Absender zu identifizieren. Es ist möglich
eine Tunnellänge von 0 zu haben. In diesem Fall ist der Absender des Paketes gleichzeitig
Anfang und Ende seiner Tunnel. Dies wird in Situationen genutzt, wenn der Serviceanbieter
bekannt ist, um eine möglichst schnelle Verbindung zu ermöglichen.
Alle Tunnel besitzen jeweils einen Gateway und einen Endpunkt. Ein Sender ist somit
Gateway seines Ausgangstunnels, dieser wird die Nachricht verschlüsselt und in 1kb große
Pakete aufgeteilt an den nächsten Router seines Ausgangstunnels senden. Wenn der Router
die Nachricht entschlüsselt hat, wird er sie an den nächsten Router des Tunnels weitersenden.
Dieser Vorgang wiederholt sich solange bis der Endpunkt des Ausgangstunnels erreicht ist.
Von diesem aus wird die Nachricht an den Gateway des Eingangstunnels des Empfängers
geschickt.
5
Abbildung 1: Aufbau der Ein- und Ausgangstunnel
Eingangstunnel besitzen einen Gateway, der die Nachrichten über die Hops an den Ersteller des Tunnels weiterschickt, welcher gleichzeitig der Endpunkt ist. Für Ausgangstunnel ist
der Ersteller der Gateway, der die Nachrichten über die Hops an den entfernten Endpunkt
schickt. Der Benutzer wählt, welche Peers an seiner Tunnelverbindung teilnehmen und stellt
jedem die benötigten Konfigurationsdaten zur Verfügung.
Nachrichten kommen am Gateway des jeweiligen Eingangstunnels an und werden dort
gebündelt, um dann in Tunnelnachrichten von 1kb zerteilt zu werden. Daraufhin werden sie
an den nächsten Hop des Tunnels gesendet, welcher die Gültigkeit der Nachricht prüft und
weiterschickt, bis der Austrittspunkt des Tunnels erreicht wurde.
Neben den obig genannten Ein- und Ausgangstunneln, die zur Datenübertragung verwendet werden, baut ein Router anfangs Erforschungstunnel (engl. Exporatory Tunnel) auf, um
mehr Informationen über das Netzwerk zu sammeln. Sie werden ebenfalls genutzt um die
Stabilität von Routern zu analysieren.[iTunnSpec ] [tunRout ]
Die benutzten Router werden von dem Ersteller des Tunnels ausgesucht. Dazu schaut
er in seiner Netzwerkdatenbank nach Routern mit hohem Datendurchsatz und Betriebszeit
[petcon ] [met86 ] und wählt so viele Router aus, wie er für seinen Tunnel verwenden möchte.
Um bestimmte Angriffe zu erschweren, werden Router in allen Tunneln zu einem Ziel immer
in der gleichen Reihenfolge verwendet. Um eine Analyse der Tunnel zu erschweren und einen
Nutzer so zu Deanonymisieren, werden Tunnel nach 10 Minuten geschlossen und über andere
Router wieder neu aufgebaut.
2.2
Garlic Verfahren
Garlic (dt. Knoblauch) ist das von I2P vorgesehen Routingverfahren. Es ist eine Weiterentwicklung des Onion Routingverfahrens, welches bei Tor Verwendung findet. Beide Verfahren
verfolgen das Ziel jede Nachricht mehrfach zu verschlüsseln und mit Lieferinformationen zu
versehen. Die Lieferinformationen enthalten unteranderem die Adresse des Empfängers. Sei es
der nächste Hop oder der Gateway des Eingangstunnels. Anhand dieser Informationen kann
die Nachricht von einem Hop an den nächsten weitergegeben werden. Jeder Hop kann dabei
nur eine Schale an Verschlüsselung wie eine Zwiebelhaut abziehen und die darunterliegende
Lieferanweisung lesen und durchführen. Auf diese Art und Weise muss und kann der erste Hop
nicht die Zieladresse der Nachricht wissen. Dies stellt sicher, dass niemand außer dem Sender
die Ziel- und Quelladresse kennt und somit keine Benutzer deanonymisiert werden kann. Dies
bedeutet auch, dass der Sender die Nachricht mit samt den Lieferinformationen für jeden
Hop entlang des Tunnels mit deren öffentlichen Schlüsseln verschlüsseln muss. Die Nachrichten sind also beim Entpacken des ersten Hops immer noch mit den öffentlichen Schlüsseln der
folgenden Hops verschlüsselt.
Beim Garlic Routing können mehrere Nachrichten (Cloves -¨¿ Zehen) in einer Knolle (Pa6
ket) gepackt sein. So könnte unter jeder Verschlüsselungsschicht anstatt einer Nachricht mit
einem Empfänger mehrere Nachrichten mit unterschiedlichen Empfängern ausgepackt werden. Die Lieferanweisungen können also bei I2P für jede Zehe unterschiedlich sein. Außerdem
können mehrere einzelne Zehen zusammengefasst und dann als Nachrichtenknolle an den
nächsten Router zugestellt werden. Dieses Verfahren setzt jedoch voraus, dass die Nachrichten
zwischengespeichert werden, bis mehrere Nachrichten des gleichen Empfängers angekommen
sind.
Das I2P Netzwerk besitzt zwei Stellen, die eine hohe Wahrscheinlichkeit haben, dass mehrere Nachrichten für den gleichen Empfänger auftreten. Diese sind somit für den Einsatz
des Garlic Routings besonders gut geeignet. Die Rede ist von den Gateways der Ein- oder
Ausgangstunnel. Garlic Routing ist jedoch (größtenteils) noch nicht in I2P implementiert.
2.3
Eepseiten
Eepsites sind werden bei Tor als Hidden Services“ bezeichnet . Eine Web“-Seite, die nur
”
”
durch das Netzwerk aufgerufen werden kann. Da I2P externe Seiten nicht (oder nicht effizient)
anzeigen kann ist das erreichbar machen von Eepsites eins der zentralen Ziele von I2P. Jeder
der I2P installiert hat kann eine Eepsite hosten. Dazu muss er lediglich die Konfiguration in der
Weboberfläche der Software anpassen und entsprechenden Inhalt auf einer TCP-Verbindung
bereitstellen. Um die Webseite erreichen zu können müssen potentielle Benutzer im Besitz
der Base32-Adresse dieser sein und sie in ihrem Router eingeben. Ein Beispiel hierfür wäre
(dsfasdfasdf). Die Benutzer können diese Adressen in ihrer lokalen Datenbank verwalten.
Um seine I2P Adresse zu verbreiten (z.B. example.I2P), muss der hoster seine Base32Adresse auf einer Jumpsite eintragen. Jumpsites sind von anderen Benutzern (meist langjährige
I2P Benutzer) gehostete Seiten, die die Verbindung zwischen den merkbaren Adressen und
ihren Bas32 gegenüber bilden. Um auf Jumsites aufgenommen zu werden muss ein potentieller
Hoster ein Formular ausfüllen. Es ist relativ einfach auch mehrere unterschiedliche Services
von einem Computer zu hosten. Es müssen dazu lediglich mehr Tunnel aufgebaut werden. Da
die Base32-Adresse abhängig von dem öffentlichen Schlüssel ist müsste für eine teilweise sprechende I2P-Adresse eine Vielzahl von privaten Schlüsseln erstellt, gehashed und verglichen
werden. Dies wird momentan nicht versucht.
2.4
Krytographische Verfahren
[i2pcrypt ] I2P benutzt Verschlüsselung, um sicherzustellen, dass kein Angreifer Inhalte, oder
soweit möglich, Metadaten abgreiffen kann. Dafür wird das ElGamal Verschlüsselungsverfahren
für asymetrische Verschlüsselung und AES als symetische Verschlüsselungsverfahren verwendet. Der ElGamal Verschlüsselungsalgorithmus wird bei Router-zu-Router Paketen, wie sie
zum Aufbau von Tunneln benötigt werden verwendet. Außerdem wird ElGamal zur Ende-zuEnde Verschlüsselung verwendet. ElGamal ist ein asymetrisches Verschlüsselungsverfahren.
Das heißt, dass ein öffentlicher Schlüssel veröffentlicht werden muss. Diese Schlüssel befinden
dann in den Leases in der Netzwerkdatenbank. Für die symetrische Verschlüsselung wird AES
mit 256 Bit Schlüsseln und einer Blockgröße von 128 Bit im Cipher Block Chaining verwendet. Dieses Verfahren wird bei der Transportverschlüsselung entlang von Tunneln und bei
Tunneltest Nachrichten verwendet. Als Schlüsselaustauschverfahren wird der Diffie Hellman
Schlüsselaustausch mit 2048 Bit verwendet, sodass Forward Secrecy gewährt wird. [dhfs ]
Für die Signierung wird der DSA-Algorithmus mit 1024 Bit Länge verwendet. Die Länge
7
ist möglicherweise nicht mehr außreichend [nistDSA ], neue Verschüsselungsverfahren sind
schon implementiert, aber ab wann sie benutzt werden können ist noch nicht beschlossen.
Als Haschverfahren wird überall SHA256 verwendet.
Aufgrund der (zur damiligen Zeit) relativ großen Schlüsselängen musste bis jetzt kein
Update der kryptoraphischen Verfahren vorgenommen werden. Dies ist jedoch in Planung.
Da die Java Kryptographie Bibliotheken nie effizient waren oder nie als besonders sicher
galten, oder erst später implementiert wurden [javaMessDig ][JavaCrypt ]wurden viele für
das I2P Projekt nachimplementiert.
2.5
Vergleich zwischen I2P und Tor
Tor ist aktuell das beliebteste und bekannteste Anonymisierungsnetzwerk. Es wurde 2002
in der Alphaversion als studentisches Projekt erstellt und ist auf Freiwillige angewiesen, die
Tor-Exit-Nodes betreiben, über die letztendlich ein anonymisierter Zugriff auf das Internet
möglich wird. Dies ermöglicht es wiederum alle Webseiten zu besuchen, die im normalen“
”
Internet (Clearnet) erreichbar sind und schützt gleichzeitig gegen eine einfache Zuordnung
der Kommunikation zu einer IP-Adresse. Die Betreiber der Internetseiten können den Torbenutzern jedoch einfach die Registrierung verweigern oder von ihnen erstellte Beiträge löschen.
Des Weiteren ist die HTTP-Kommunikation mit der Webseite nicht Verschlüsselt und daher einfach zu überwachen. Aus diesem Grund wurden im Jahre 2004 Hidden Services“ im
”
Tornetzwerk eingeführt. Diese sind nur durch das Tornetzwerk erreichbare Webseiten, deren
Betreiber anonym sind. Die Kommunikation mit diesen Services ist außerdem immer verschlüsselt, wodurch eine Reihe von SSL-Angriffen unterbunden wird.
Der Fakt, dass diese Hidden Services im Nachhinein in Tor implementiert wurden, führt
jedoch zu Problemen [goltorDean ]
I2P begann im Jahre 2003 in der Entwicklung als verteiltes Internet Relay Chat (IRC)
Netzwerk. Das Projekt wurde jedoch schnell erweitert, sodass beliebige Inhalte und Webseiten darüber verteilt werden konnten. Zwar ist es auch möglich über sogenannte Outproxies
auf das Clearnet zuzugreifen, dies ist jedoch nicht der eigentliche Verwendungszweck. Um die
Kommunikation zu ermöglichen, agieren alle Beteiligten als Router. Dies ist zwar im Tornetzwerk ebenso vorgesehen, jedoch nicht der Regelfall. Dies bedeutet auch, um in dem I2P
Netzwerk beitreten zu können lediglich die IP-Adresse eines beliebigen Routers vonnöten ist.
Im Gegensatz dazu benutzt Tor Eintrittsknoten (engl. entry node). Dies sind Torknoten, die
eingehenden Datenverkehr akzeptieren. Im I2P Netzwerk wird dieser mit nur wenigen Ausnahmen von allen Knoten akzeptiert. Alle aktiven Router und ihre IP-Adressen sind jedoch
in der Netzwerkdatenbank hinterlegt. Durch ausschalten des eigenen Routings ist dies jedoch
ein wenig zu erschweren. Außerdem benutzt Tor zentrale Server zwecks Verbindungsaufbau
[TorSpec ] , wohingegen bei I2P die Informationen über die schon vorhandenen Router von
jedem andern Router erfragt werden können.
8
3
Bedrohungen und Angriffsarten auf I2P
[i2pthM ]
Anonymität ist kein true oder false“ Attribut, es wird daher von einem Grad bzw. Level
”
an Anonymität gesprochen. Der Grad der Anonymität beschreibt, wie schwer es ist Informationen über eine Person herauszufinden, die eben das nicht will. Diese Informationen schließen
z.B. ein wer mit wem, wann über was kommuniziert . Allerdings ist auch mit I2P keine perfekte Anonymität möglich, da die Software z.B. nicht von Personen, die keinen Computer oder
kein Internet benutzen ununterscheidbar macht. Das Ziel ist, ausreichende Anonymität herzustellen. Aus diesem Grund werden in diesem Kapitel einige Angriffsmöglichkeiten vorgestellt,
die es Dritten möglich macht an einige der oben genannten Informationen zu gelangen. Viele
der Angriffe sind momentan, bedingt durch die geringe Größe des I2P Netzwerks weniger
schwer durchzuführen als sie es im Idealfall seien sollten.
3.1
Brute-Force Angriff
Ein Brute-Force Angriff kann von einem passiven oder aktiven Angreifer durchgeführt werden,
der den kompletten Datenverkehr zwischen I2P Knoten verfolgt und versucht herrauszufinden,
welche Nachrichten welchen Pfad genommen haben. Neben dem gewaltigen Aufwand den der
Angreifer betreiben müsste, um den Datenverkehr zu überwachen kommt erschwerend hinzu,
dass eine Nachricht auf ihrem Weg zum Empfänger ihre Größe und Inhalt stetig ändert. Auf
den Inhalt der Nachricht hat der Angreifer ebenfalls keinen Zugriff, da diese nur verschlüsselt
übertragen wird.
Nichtsdestotrotz kann ein mächtiger Angreifer, beispielsweise ein Internet Service Provider
oder Internet Exchange Point, mit Brute-Force Tendenzen entdecken. Indem er zum Beispiel
eine 5GB große Nachricht an eine I2P Adresse sendet, kann er jeden I2P Knoten, welcher
weniger als 5GB Daten in der gleichen Zeit empfangen hat, als mögliche Tunnelteilnehmer
ausschließen. Dieser Angriff ist zwar in der Praxis unbeschreiblich aufwändig, in der Theorie
jedoch möglich.
Verteidigungsmaßnamen gegen einen Brute-Force-Angriff sind zum Beispiel das Setzen
eines niedrigen Bandbreiten-Limits oder der Einsatz von nichttrivialer Verzögerung oder resctricted Routern. Die letzten beiden genannten Optionen sind in der aktuellen Version von
I2P noch nicht implementiert. Auf nichttriviale Verzögerung wird in Kapitel 4 weiter eingegangen.
3.2
Timing Angriff
Nachrichten in I2P sind unidirektional und der Empfänger wird nicht zwangsläufig eine Antwort senden. Allerdings besteht eine hohe Wahrscheinlichkeit, dass Anwendungen die über
I2P ausgeführt werden erkennbare Muster durch die Häufigkeit und Menge der Nachrichten
erzeugen. Beispielsweise wird bei einem HTTP-Request eine kleine Nachricht gesendet, auf
die eine große Menge an Antwortnachrichten zurückgesendet werden wird. Mit diesen Informationen gepaart mit der Überwachung des Netzwerkes, kann ein Angreifer Router aus
dem möglichen Pfad ausschließen, die zu langsam wären um die Nachrichten rechtzeitig zu
übertragen. Diese Art des Angriffs ist zwar mächtig
9
3.3
Verkehrsanalyseangriff
Netzwerkanalyseangriffe sind eine Art von Angriffen die gegenüber dem Tornetzwerk erfolgreich getestet wurde [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1425067&url=httpBei
Verkehrsanalyseangriffen wird der Verkehr an einer Vielzahl von Knoten analysiert und gespeichert. Ein Beispiel eines Datenpunkts wäre: um 12:50.50 wurden von Router 1.1.1.0 20
Pakete der Größe 1 Kb an 1.1.1.1 geschickt. Um 12.50.55 wurden 20 Pakete mit einer Größe
von jeweils 1 Kb von 1.1.1.1 an 1.1.1.2 geschickt. Wenn diese Daten von einer Vielzahl von
Routern vorhanden ist, kann man sie analysieren und auswerten. Mit nur diesen Datensetzen kann man nicht viel anfangen (nur einen Knoten aus der Kette rausrechnen), aber wenn
Zeitlich gesicherte Datenpakete von einer Vielzahl von Routern erfasst werden können, dann
ist es möglich dadurch Eingangspakete (die unverschlüsseltes TCP sein können) Benutzern
zuzuordnen.
Abbildung 2: Einfacher Darstellung eines Verkehrsanalyseangriffes
3.4
Intersection Angriff
Bei Systemen, die eine niedrige Latenz benötigen sind Intersection Angriffe sehr wirkungsvoll.
Hierbei wird dauerhaft Kontakt mit dem Ziel aufgenommen und beobachtet, welche Nodes im
Netzwerk online sind. Über längere Zeit werden Node Churns auftreten, die durch intersecting wichtige Informationen über das Ziel liefern. Diese Art des Angriffs wird schnell enorm
10
Kostspielig, je größer das Netzwerk wird.
3.5
3.5.1
Denial of Service Angriffe
Starvation Angriff
Ein feindseliger Benutzer, der dem Netzwerk schaden will, könnte eine Signifikanten Anzahl von Peers erzeugen. Wenn es bei diesen nicht identifiziert werden kann, dass sie unter
der Kontrolle derselben Entität stehen, kann der Angreifer sie dazu veranlassen, dem Netzwerk keine Ressourcen zur Verfügung zu stellen. Als Resultat müssen bereits existierende
Peers größere Netzwerkdatenbanken durchsuchen oder könnten mehr Tunnel anfordern als
gebraucht werden. Alternative könnten diese Peers zum Routen verwendet werden und zu
unzuverlässigen Services führen. Durch regelmäßiges verwerfen von geroutetem Traffic oder
der strikten Verweigerung von bestimmten Verbindungen kann zu Störungen führen, da Peers
die dieses Verhalten aufweisen, nicht von überlasteten Peers zu unterscheiden wären.
3.5.2
CPU Load Angriff
Über bestimmte Methoden können Peers dazu gebracht werden kryptografisch teure Berechnungen durchzuführen. Ein Angreifer könnte einen Peer mit einer großen Zahl dieser Anfragen
fluten, um zu versuchen seinen CPU zu überlasten.
3.5.3
Floodfill-DOS Angriff
Ein Angreifer kann ohne Probleme selbst ein Floodfill-Router werden und dies ausnutzen,
um falsche oder gar keine Informationen bei einem Floodfill-Lookup auszugeben. Außerdem
könnte er auch andere Floodfill-Router stören.
3.6
Tagging Angriffe
Ist ein Angreifer Teil eines Tunnels, könnte dieser versuchen ein übertragenes Paket zu verfolgen. In I2P ist es zwar unmöglich eine Nachricht so zu verändern, dass sie später wieder
identifiziert werden kann, aber der Angreifer kann, falls er einen zweiten Router im Tunnel
kontrolliert, ohne Probleme herausfinden, dass sich beide Router im selben Tunnel befinden.
Dies erkennt er durch die Tunnel-ID die für beide Router sichtbar wird, wenn sie die erhaltene
Nachricht entschlüsseln.
3.7
Partitioning Angriffe
Die Anonymität im I2P-Netzwerk wird verstärkt mit der wachsenden Größe des Netzes. Leider ist es für einen mächtigen Angreifer (z.B. Internet Service Provider) möglich dieses zu
zerteilen. Bei einem Partitioning Angriff werden Verbindungen zwischen Peers getrennt, um
separierte Netzwerke zu erzeugen. Dieses Problem wird zwar von der Netzwerkdatenbank versucht zu beheben, indem jede noch existierende Verbindung genutzt wird, um das Netzwerk
wieder zusammenzusetzen. Sollte der Angreifer aber alle Verbindungen getrennt haben, wird
auch die Netzwerkdatenbank hier chancenlos sein. Der getrennte Router müsste jetzt erkennen, dass eine große Zahl an zu vor noch verlässlichen Routern plötzlich nicht mehr verfügbar
sind, um dann seinen Client darauf hinzuweisen, dass er getrennt wurde. Leider gibt es dafür
im Moment noch keine Implementierung.
11
Bei einer analytischen Zerteilung des Netzwerks kann beobachtet werden wie sich Router und Ziel verhalten, um sie entsprechend zu gruppieren. Beispielsweise weiß ein Angreifer,
nachdem er die Netzwerkdatenbank ausgelesen hat, welche Anzahl von Eingangstunnel bestimmte Peers besitzen. Danach kann er die Peers nach diesem Kriterium einordnen.
Eine andere Art des analytischen Partition Angriffs ist in Verbindung mit nichttrivialer
Verzögerung und Batching Strategien möglich, da Tunnel und Router die eine Verzögerung
verwenden sehr wahrscheinlich statistisch auffällig werden. Allerdings müsste der Angreifer
einen großen Teil des Netzwerks kontrollieren und weiß weiterhin nicht, für welche anderen
Nachrichten dieselben Verzögerung verwendet werden.
3.8
Harvesting Angriffe
Mit einem Harvesting Angriff können Peers identifiziert werden, die I2P benutzen. Der Angreifer betreibt selbst einen Peer und verfolgt, wer sich mit ihm verbindet. Durch das Ernten“
”
aller Informationen von anderen Peers die er finden kann, ist es ihm möglich eine Liste von
I2P Nutzern zu generieren, die für weitere Angriffe oder rechtliche Schritte verwendet werden
kann. Alternativ können die Daten auch aus der Net-DB gelesen werden.
In I2P you don’t know who is talking to who, but you can know some of the
”
people who are in the I2P Network. To be part of the I2P Network you have to
let people know who you are, at least for an IP Adress [. . . ] I can basically scrape
Net-DB and find a collection of these IP Adresses“ - Adrian Crenshaw Blackhat
DC 2011
Abbildung 3: Datensammlung über im I2P Netz vorhandene Router
12
3.9
Zeitvergeichsangriffe
Jeder Server hat eine interne Uhr, die zwecks timing verwendet wird. Diese Uhr geht etwas
falsch. Wenn nun zwei Webserver (eventuell einer im Internet und der andere ausschließlich
über I2P erreichbar, oder einer mit bekannten Betreiber und einer mit unbekanntem Betreiber) dieselbe Zeit haben, so kann dadurch eine Verbindung zwischen diesen zwei vermutet
werden. Um diese Angriffsmöglichkeit zu reduzieren, verwendet und erfordert I2P die Verwendung von SMTP zwecks Zeiteinstellung. [I2PFaqPort ] I2P verwendet dazu den standard
tpool.ntp.orgserver Pool. Dadurch werden weder I2P-Cients analysiert noch ein neuer Angriffspfad eröffnet, da die (S)NTP Server als harmlos und relativ zuverlässig gelten. Selbst
wenn die Server Betreiber einzelne Benutzer deanonymisieren wollen ist dies aufgrund der
hohen Zahl [ntpUsage ] von externen anfragen schwer.
4
Nichttriviale Verzögerung
Verkehrsanalyseangriffe sind schon seit Jahren bekannt und werden als gefährlich angesehen.
In der Definition von I2P sind zwei Gegenmaßnahmen angedacht. Eine davon, die konstante
Paketgröße ist schon implementiert [iDatagSpec ]. Da alle Pakete dieselbe Größe haben
(Bei I2P 1kb), ist es bei Routern mit einem hohen Verkehrsaufkommen schwerer, die einzelne
Pakete nachzuverfolgen.
Dies bedeutet nicht, dass es unmöglich ist. So kann vermutet werden, dass wenn in kurzer
Zeit 1.1.1.0 Pakete an 1.1.1.1 sendet und 1.1.1.1 fünfundzwanzig Pakete an 1.1.1.2 übermittelt
1.1.1.0 an 1.1.1.2 sendet. Um dies zu reduzieren gibt es unteranderem das Prinzip der nicht”
trivialen Verzögerung“, welcher in diesem Kapitel beleuchtet werden soll.
Ebenso könnten Pakete verschiedener Sender, die ein Gemeinsames (nächstes)ziel haben
zusammen genommen und gemeinsam gesendet werden. Dies ist im I2P Protokoll vorgesehen
jedoch noch nicht Implementiert.
4.1
Idee
Nichttriviale Verzögerung“ (engl. nontrivial delay) bezeichnet die Idee große, nicht tech”
nisch bedingte Verzögerungen in den Transport von Paketen einzubauen, um die Zusammengehörigkeit von Paketen zu verschleiern und das Analysieren von Netzwerken zu erschweren.
Wenn ein Teilnehmer im Netzwerk ein Paket empfängt, und nicht sofort weiterleitet, so ist es,
für einen außenstehenden Beobachter nicht klar, ob das Paket an seinem Ziel angekommen
ist, oder ob es nur zwischengespeichert wird bevor es zum nächsten Ziel weitergeleitet wird.
Ebenso schwer ist es, mit Sicherheit zu sagen, ob die 25 Pakete die ein Mitglied an ein anderes
Mitglied sendet eigene Inhalte sind, oder unter Umständen vor vielen Minuten oder Stunden
zwecks weitersenden abgespeichert wurden.
Diese Idee ist von Anfang an in I2P geplant gewesen, wurde jedoch bis zum heutigen Tag
aufgrund von Schwierigkeiten nicht Implementiert. Im Folgenden wird auf einige Schwierigkeiten eingegangen und die potentiellen Gründe für die noch nicht stattgefundene Implementation beleuchtet.
4.2
Herausforderungen bei der Implementation
Bei der Implementation gibt es einige Herausforderungen, die in der Natur der Verzögerung
stecken. Diese werden im folgenden Abschnitt diskutiert und es wird nach Lösungen im Rah13
men unserer Beispielimplementation gesucht.
Ausfälle I2P benutzt Festplattenzugriffe ausschließlich, um Konfigurationen und Logs zu
speichern. Eine Vielzahl der Session Schlüssel, alle Transportschlüssel und die Nachrichten
werden zu keinem Zeitpunkt auf persistenten Medien gespeichert, wenn die Softwarekonfiguration nicht verändert wurde. Dies dient nicht nur der besseren Geschwindigkeit, weil weniger
Festplattenzugriffe notwendig sind, sondern schützt die Schlüssel von forensischer Untersuchung von heruntergefahren Computern (wie ein Angreifer mit Zugang zu einem Computer
es tuen würde). Wenn also ein als Router fungierender Computer neustartet sind die oben
erwähnten Daten nicht mehr vorhanden. Dies Stellt normalerweise kein Problem dar, da die
Weiterleitung von Paketen in der Regel innerhalb von Sekundenbruchteilen geschieht und
ein Neustart des Computers in dieser Zeit sehr selten ist. Ein Paket, das jedoch Tage auf
einem Computer liegt, bevor es Weitergeleitet wird, hat eine deutlich höhere Wahrscheinlichkeit, dass dieser in der Zwischenzeit heruntergefahren wird, ein Netzwerkproblem hat, oder
aufgrund eines Stromausfalls oder anderen Hardwaredefekten ausfällt.
Dies ist im Grunde kein Problem, da I2P Pakete nach dem Best-Effort-Prinzip nicht zuverlässig sind. Jedoch sind die Ausfälle bei allem was über 3,5% der Fälle hinausgeht in vielen
Situationen nicht vertretbar [borella98 ], und aufgrund der langen Laufzeit sind zuverlässige
Zwischenprotokolle wie TCP nicht gut nutzbar. Die Wahrscheinlichkeit, dass Pakete bei weniger als einer Stunde Verzögerung einem solchen Ausfall zu Opfer fallen ist jedoch recht
gering, da als Router eingesetzte Computer selten neugestartet werden und nur langfristig
erreichbare Router für das Versenden von Nutzdaten verwendet werden.
Für dieses Problem gibt es zwei Lösungsansätze. Die erste Möglichkeit ist, die oben genannten Daten auf der Festplatte temporär zwischenzuspeichern. Möglichkeit zwei ist die
Daten über zwei unterschiedliche Tunnel zum Ziel zu senden.
Kurze Schlüsselgültigkeiten In I2P werden Transportschlüssel, die auch zum Senden von
Nachrichten benutzt werden regelmäßig ausgetauscht und dabei die alten Schlüssel gelöscht.
Dies führt dazu, dass wenn das Paket ankommt, es potenziell nicht mehr entschlüsselt und
weitergesendet werden kann.
Dies kann zum einen dadurch gelöst werden, dass Langzeitschlüssel generiert und gehalten
werden. Diese Schlüssel wären dann Erfolg versprechende Ziele und müssten eventuell besser (sicherer) als die sonst verwendeten Schlüssel sein. Außerdem müssen Langzeitschlüssel
eventuell auch über Neustarts hinweg gesichert werden, was zu einer Vielzahl von Problemen
führt.
Speicherplatzverbrauch Ein Router muss mehrere Gigabyte von Datenverkehr pro Stunde verarbeiten können. Insbesondere, wenn er bestimmte Dienste im Netzwerk übernimmt.
Sollten alle diese Verbindungen eine Verzögerung beantragen ist dies aktuell kaum umsetzbar.
Dies kann jedoch bei einer experimentellen Implementation vernachlässigt werden, wenn die
Anzahl der zu sendenden Pakete niedrig gehalten wird. Eine mögliche Lösung ist, besonders
große Pakete früher zu senden, wenn der Speicherplatz nicht mehr ausreicht.
Ausfälle/Änderung von Komponenten entlang des Pfades Bei I2P muss jeder Client
vor dem Absenden eines Pakets den Weg bestimmen, den ein Paket nehmen soll. Dazu wählt
die Software aus den vorhandenen Routern jene aus, die eine hohe Stabilität aufweisen und
14
baut auf diesen Ersatztunnel auf. Diese Tunnel werden dann benötigt, wenn der Haupttunnel
nicht mehr funktionsfähig ist. Wenn nun während des Sendens einer der Router entlang des
Pfades nicht mehr verfügbar ist, kann das Paket nicht mehr übermittelt werden. Deshalb
sollten Kopien des Pakets über andere Wege gesendet werden. Dies wird bei dieser Beispiel
Implementation jedoch nicht beachtet.
Tunnel I2P verwendet wie in Kapitel 2.1 Tunnel beschrieben Ein- und Ausgangstunnel. Insbesondere Services die Nachrichten erhalten benötigen Tunnel. Die Existenz von Tunneln ist
mit 10 Minuten jedoch relativ kurz [goltorDean ], was das Benutzen von Verzögerungen im
Minutenbereich aktuell enorm erschwert. Es wäre jedoch möglich, dass die Verfügbarkeitsdauer
von Tunneln in einer zukünftigen Version verändert oder vom Ersteller relativ frei gewählt
werden kann.
Ein Erstellen von Tunneln mit nichttrivialer Verzögerung ist aktuell nicht möglich, da
Tunnel-Build-Nachrichten nicht als Garlic-Nachricht gesendet werden.
Benutzung Um die nichttriviale Verzögerung zu verwenden muss dem Router, der es in die
Pakete reinschreibt, bekannt geben, dass sie verwendet werden soll. Dies könnte möglicherweise
für jeden Tunnel separat in der Router Console eingestellt werden. Dies hat den Vorteil,
dass die verwendeten Dienste in dieser Hinsicht nicht angepasst werden müssen, solange der
Roundtrip der Pakete klein genug bleibt oder Daten nur in eine Richtung gesendet werden
sollen. Andererseits könnte über die I2P API (BOB:Basic Usage Bridge) die Einstellung benutzbar gemacht werden. Insbesondere Applikationen, die für I2P entwickelt werden, wie der
I2P-Bote (I2P interner Messaging Service) können diese Methode wählen. Zuletzt könnten
die benutzten Dienste Header mitschicken. Der letzte Punkt ist jedoch arbeitsintensiver für
den sendenden Computer, da er alle Pakete analysieren muss.
Außerdem muss die verwendete Software mit ausreichend langen Verzögerungen umgehen können und nicht als Bandbreitenlimit oder Timeout erkennen. Zum Testen wurde das
Empfangen von Paketen nur simuliert und Pakete an Dummy-Adressen gesendet.
4.3
Implementierung
Vorüberlegung In I2P ist die Implementation von nichttrivialer Verzögerung eingeplant
und größtenteils schon vorbereitet. Im Nachrichten Datagramm sind alle notwendigen Felder
spezifiziert [I2PspecGarl ] und im Interface als Deprecated vorhanden. Die Verzögerung
kann bei Garlic-Nachrichten bereits in Sekunden angegeben werden. Der Einfachheit halber
wurde in dieser Implementation bei den zu verzögernden Paketen die Java eigene sleep()
Methode verwendet. Dies ist alles andere als effizient. Eine für große Mengen an Paketen
sinnvollere Lösung wäre, die wartenden Pakete in einem binomialen Heap zu speichern. Pakete
mit großer Verzögerung könnten in, nach Sendezeit geordneten, Dateien gespeichert werden,
die in regelmäßigen Abständen nach zu sendenden Paketen durchsucht werden.
Dies ist auch für eine vollständige Implementierung des Garlic Routings vorteilhaft. Dafür
müssten die Pakete zusätzlich in einer Hashtabelle mit Zieladresse als Schlüssel gespeichert
werden. Aus dieser können dann effizient andere Pakete mit demselben Ziel ausgelesen und
die Garlic Zehen zu einer neuen Knolle zusammengefügt werden.
15
4.4
Testen der Implementierung
Da I2P ein großes Netzwerk ist und unter anderem von Leuten benutzt wird, für die Anonymität lebenswichtig sein kann, sollten alle Tests außerhalb dieses Netzwerkes durchgeführt
werden [TorResSec ]. Dies ist jedoch sehr kompliziert, da ein solches Vorgehen nicht dokumentiert ist, und Sicherheitsfeatures in die Software eingebaut und nicht auffindbar sind.
So werden große IP-Adressen Abstände, zu kleine Rundlaufzeiten, lokale Adressen als Ausschlusskriterium bei der Tunnelerstellung verwendet, die leider in unterschiedlichen Klassen
aufgelistet sind. Ein Ausführen der Software in einem eigenen Netzwerk und ein Senden von
Paketen über einen von uns bestimmten Knoten schlugen immer fehl. Um dieses Problem
zu umgehen, wurde das Empfangen und anschließende Senden von Paketen mit Hilfe von
Javadocs simuliert, und die eingestellte Zeit zwischen Empfangen und Senden festgestellt.
5
Review
I2P ist ein robustes Netzwerk, das von einer Vielzahl von Benutzern täglich verwendet und
darauf vertraut wird. Um diesen Anforderungen auch in Zukunft Herr zu werden sind in I2P an
vielen Stellen schon zukünftige Erweiterungen angedacht und vorbereitet. So steht der nichttrivialen Verzögerung nur noch ein Bedarf im weg. Genauso könnte eine voll funktionsfähige
Implementation von Garlic Routing eine weitere Reduktion der Erfolgswahrscheinlichkeit von
Timing Attacken erreicht werden, da die größe der Packeten damit variable währen
Dadurch, dass einer I2P Adresse mehrere Tunnel zugeordnet sein können und dadurch
auch mehrere LeaseSets, können mehrere Server gleichzeitig an unterschiedlichen Stellen der
Welt ohne zusätzlichen Aufwand dieselbe Seite ausliefern. Dies kann zum Schutz gegen die
Intersection Attacke verwendet werden. Wie erfolgreich dies ist muss jedoch noch gezeigt
werden. [I2PORQ ]
Es wird ebenfalls überlegt Tunnel mit optional fest einstellbaren Bandbreiten (400 Pakete
pro Minute o. Ä.) zu implementieren. Diese würden, wenn keine Nutzdaten versendet werden
Füllpakete transportieren und in einigen DDoS-Angriffen den Server und seine Anonymität
schützen. Dies beeinträchtigt jedoch im Regelfall die Netzwerkkapazität und im Extremfall die
Erreichbarkeit der Dienste. Wenn die Grenzen zwischen minimaler und maximaler Paketzahl
pro Minute frei eingestellt werden kann, würde dies den Einfluss auf die Netzwerkauslastung
reduzieren. Zu diskutieren wäre in diesem Fall, wie mit verzögerten Paketen umzugehen ist.
Innerhalb von I2P sind alle Transaktionen so schnell, wie sie sicher sein können. Einige Angriffsmethoden basieren jedoch darauf, dass viele Anfragen kurz hintereinander durchgeführt
werden (Sybil-Attack). Um gegen diese Art von Angriffen vorzugehen, könnte die Hashcash
Methode implementiert werden. D.h. es wird jeder Transaktion eine mathematische Aufgabe
mitgegeben, die vor der Ausführung der eigentlichen Transaktion gelöst werden muss. Dadurch, dass dann für jede Anfrage eine zusätzliche CPU-Last anfällt, wären Angreifer, die
viele Anfragen stellen dauerhaft mit Lösen dieser Aufgaben beschäftigt. Was den Preis (und
die benötigten CPUs) in die Höhe treibt. Diese Art von Kosten könnten auch für Netzwerk
Dienste eingefügt werden, um auch dort ein Schutz vor DDoS Angriffen zu bilden.
Dies könnte auch bei nichttrialer Verzögerung verwendet werden. Man könnte die Berechnung eines Wertes erzwingen, sodass wenn der Hash von ihm berechent wird, der berechnete
Hash in einer Speicherdauer und große abhängigen Anzahl von Bits mit dem Hash der Nachricht und dem Sendezeitpunkt konkateniert. Ansonsten wuerde das packet sofort gedroppedDies würde DDoS-Angriffe mit zu langen Speicherzeiten und zu großen Paketen reduzieren.
16
Die Schwirigkeiten dieser Aufgaben (Anzahl der abzugleichen Bits), sowie die Auswirkung auf
Benutzer mit rechenschwachen Computern muss noch erforscht werden.
Für Interessierte, die Java nicht verwenden wollen oder können gibt es eine C++ Implementierung, die auf GitHub gepflegt wird.[gitI2PD ] Es ist nicht der erste Versuch eine C++
Implementierung zu erstellen, die jetzige wird jedoch inzwischen von den I2P Entwicklern
unterstützt. [I2pTeam ]
17
6
Hinweise
Viele in diesem Dokument behandelte Themen können, wenn sie falsch eingesetzt werden,
dazu führen, dass Benutzer des jeweiligen Netzwerkes deanonymisiert werden können. Der
beiliegende Code ist nicht für den Einsatz im Netzwerk gedacht. Bitte vor dem Einsatz alle in
Kapitel refsubsec:impl aufgelisteten Themen bedenken und mit anderen auf den I2P Kanälen
darüber diskutieren.
Dies behandelt eine Beispiel Implementation von 3 Studenten. In allen Fragen bitte die
original Implementation auf getI2P.net lesen und verstehen.
Der besprochen Code wurde von uns nie im echten“ I2P Netz benutzt, um keine Benutzer
”
zu gefährden.
Anonymität im Internet ist schwer. Bitte lesen sie weiterreichende Informationen unter
[TorUG ] oder [secBox ], um mehr darüber zu erfahren.
7
Code
Hier sind kleine auschnitte aus dem erstellten quellcode. lstsetlanguage=Java
i n SendMessageDirectJob
p r i v a t e Date d e l a y T i l l ;
/∗∗
∗
∗ @param d e l a y T i l l t e d a t e t i m e a t w i t c h i t s c h o u l d be s e n t
∗/
p u b l i c SendMessageDirectJob ( RouterContext ctx , I2NPMessage message , Hash
t h i s ( ctx , message , toPeer , n u l l , n u l l , n u l l , n u l l , timeoutMs , p r i o r i t y ) ;
t h i s . d e l a y T i l l=d e l a y T i l l ;
}
send ( ) {
...
i f ( d e l a y T i l l != n u l l ) {
try {
l o n g delayBy=d e l a y T i l l . getTime ()−new Date ( ) . getTime ( ) ;
i f ( delayBy >1){
// delay , r e a l Delay
m e s s a g e . w a i t ( delayBy ) ;
}
// o t h e r w i s e , d e l a y a l r e a d d y handeld
}
catch ( InterruptedException ){
// N o t i f y o f b e e i n g dropped
18
o n F a i l . dropped ( ) ;
return ;
}
// message i s now a p r o p r e a t l y d e l a y e d
}
...
}
SendMessageDirectJob j o b ;
i f ( ! i n s t r u c t i o n s . getDelayRequested ( ) ) {
j o b= new SendMessageDirectJob ( g e t C o n t e x t ( ) , gw ,
i n s t r u c t i o n s . getRouter ( ) ,
1 0 ∗ 1 0 0 0 , TUNNEL PRIORITY ) ;
}
else {
Date d e l i v e r A f t e r=new Date ( ) ;
d e l i v e r A f t e r . setTime ( d e l i v e r A f t e r . getTime ( )
∗
+i n s t r u c t i o n s . g e t D e l a y S e c o n d s ( ) ∗ 1 0 0 0 ) ;
j o b= new SendMessageDirectJob ( g e t C o n t e x t ( ) , gw ,
∗
i n s t r u c t i o n s . getRouter ( ) ,
1 0 ∗ 1 0 0 0 , TUNNEL PRIORITY,
deliverAfter );
}
// run i t i n l i n e ( adds t o t h e outNetPool i f i t has t h e r o u t e r i n f o
j o b . runJob ( ) ;
}
in garlicMessage {
readBytes ( . . . ) {
//um empfangen zu konnen
}
toByteArray ( . . . ) {
um senden zu koennen
}
%found code s n i p p e t s
i f ( sent ) {
i f ( l o g . shouldLog ( Log .WARN) )
l o g . warn ( ” Not r e s e n d i n g ! ” , new E x c e p t i o n ( ” b l a h ” ) ) ;
19
Literatur
[1] [i2pMeeting] Meetings von I2p https://getI2P.net/en/meetings/
[2] [devguid] I2P
developers
devellopment
guide
https://getI2P.net/en/get-involved/guides/new-
[3] [i2pstat] I2P router informationen stats.I2P
[4] Leaseset definitionhttps://geti2p.net/spec/common-structures#struct LeaseSet
[5] Mitarbeiter an I2P https://getI2P.net/de/about/team
[6] tor blog https://blog.torproject.org/blog/one-cell-enough
[7] I2p Packet datagram https://getI2P.net/en/docs/api/datagrams
[8] I2P tunnel specificationhttps://getI2P.net/en/docs/tunnels/implementation
[9] i2p crypto specification https://geti2p.net/spec/cryptography]
[10] i2p tunnel routing https://geti2p.net/de/docs/how/tunnel-routing
[11] i2p thread moddel https://getI2P.net/en/docs/how/threat-model
[12] asd
[13] 68 irc entwickler teffen https://getI2P.net/en/meetings/68
[14] National Institute of Standarts http://csrc.nist.gov/publications/nistpubs/80057/sp800-57-Part1-revised2 Mar08-2007.pdf
[15] https://geti2p.net/ static/pdf/I2P-PET-CON-2009.1.pdf
[16] Crypto specification of java http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoS
[17] paper about deanonymisation of Tor hidden services http://www.golem.de/news/torhidden-services-leichter-zu-deanonymisieren-1505-114347.html
[18] java
documentation
if
messagedigist
in
java
ps://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html
6
htt-
[19] Advances in Cryptology — EUROCRYPT 2002: International Conference on the Theory
and Applications of Cryptographic Techniques Amsterdam, The Netherlands, April 28 –
May 2, 2002 Proceedings http://dx.doi.org/10.1007/3-540-46035-7 21
[20] Tor Spezifikation https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt
[21] Tor User guide https://www.torproject.org/download/download-easy.html.en 06/2016
[22] Securety in a Box https://securityinabox.org 06/2016
[23] Tor Researchsecurety council https://research.torproject.org/safetyboard.html 06/2016
20
[24] Specification
of
garlicclovedeliveryinstructions 06/2016
Garlichttps://getI2P.net/spec/i2np#struct-
[25] Anonymität=Frieden http://hydra.geht.net/tino/p2p/I2P/gedanken/
[26] I2P open reaserch Questions getI2P.net/en/research/questions
[27] faq about open ports for I2Phttps://getI2P.net/de/faq#ports
[28] faq of ntp server about usagehttp://www.pool.ntp.org/en/vendors.html#pool-capacity
[29] c++ implementation von I2Phttps://github.com/PurpleI2P/I2Pd
[30] to do of I2P https://getI2P.net/en/get-involved/todo#hashcash
[31] author = Michael S. Borella and Debbie Swider and Suleyman Uludag and Gregory B.
Brewster, title = Internet Packet Loss: Measurement and Implications for End-to-End
QoS, booktitle = In International Conference on Parallel Processing, year = 1998, pages
= 3–12
21

I2P

Transcription

Similar documents

Februar 2010 (hier als pdf-Datei)

1. Aufgabenstellung

Einige Tipps zum wissenschaftlichen Arbeiten

PROMAX Kopfstationen

Belgien - ziegel.com

Hilfe-PDF anzeigen