Teil 1

I2P (Invisible Internet Project) ist ein Projekt, welches die Entwicklung eines anonymisierten Kommunikationsnetzwerks zum Ziel hat. Auf Basis von I2P soll es möglich sein, verschiedenste, aus dem Internet bekannte Dienste in sicherer und anonymer Form zu nutzen bzw anzubieten. Zusätzlich soll I2P in Zukunft noch eine Reihe selbst entwickelter Services zur Verfügung stellen

Bitte werft einen Blick auf geti2p.net, um näheres zu erfahren.

Das Projekt hat sich mehrere Ziele gestellt:

Schutz gegen möglichst viele Bedrohungsszenarien
Dezentralität
höchstmögliche Skalierbarkeit
Anwendbarkeit
State of the art anonymität / Kryptoimplementierung

Bitte beachte, dass I2P per se kein klassisches P2P Netzwerk ist!!!

Man kann es AUCH benutzen, um P2P Applikationen damit zu betreiben, jedoch bedürfen diese einer entsprechenden Portierung. Zum aktuellen Zeitpunkt existiert bereits ein Bittorrent Port für I2P, sowie ein Port des Phex Gnutella Client, genannt i2phex.

Das eigentliche Design sieht I2P als in sich geschlossenes Netzwerk. In- und Outproxies existieren jedoch, um Dienste wie Internet HTTP Proxys oder das Senden/Empfangen von E-Mails mit dem Internet zu ermöglichen.

Gegen welche Bedrohungsszenarien schützt mich I2P?

Beim Design wurden verschiedene sogenannte Thread Models beachtet. Welche Thread Models es gibt, und mit welchen Mitteln I2P Euch vor dem erfolgreichen Durchführen ebendieser schützen soll, könnt Ihr unter https://geti2p.net/how_threatmodel nachlesen. Ich werde später eine Einführung in die grundlegenden Anonymisierungstechniken geben.

Wie ist der aktuelle Stand des Netzwerks?

Momentan befindet sich I2P in der Version 0.6.1.7 kurz vor dem Versionssprung zu 0.6.2. Die I2P Knoten kommunizieren auf Basis eines UDP gestützten Protokolls namens SSU (Semireliable Secure UDP) miteinander. Seit der Version 0.6 wird dieses Verfahren standardmässig genutzt, und ist damit die Grundlage für eine Skalierbarkeit des Netzes. Aktuell nehmen am Netz ca. 500-700 Knoten teil. Die Tendenz ist stabil wachsend. Eine offizielle Veröffentlichung und Bekanntmachung ist mit der Version 1.0 geplant. Folgende Dienste wurden/werden erfolgreich im I2P Netzwerk betrieben:

Anonym gehostete Webseiten (sogenannte eepsites) (inkl. Supportforum)
Anonymes IRC
Anoynme E-Mail (inklusive Mail vom/zum Internet)
Anonymes Bittorrent
Anonymer NNTP Dienst
Jabber/IM Dienste
gnutella Dienst (i2phex)

Wie stellt denn I2P eigentlich Anonymität her?

(Die Definition des Begriffes Anonymität wird hier grosszügigerweise übergangen Smiley ) Diese Frage ist für jeden interessant, der sich die (berechtigte) Frage stellt, wie ein System jemanden schützen kann, obwohl am Ende trotzdem Rechner mit Hilfe von IP Paketen Daten austauschen. Ich werde versuchen, es vertändlich zu machen...

Als erstes möchte ich sagen:
IP ADRESSEN SIND KEIN GEHEIMNIS IN I2P

Ich habe so manch einen erlebt, der diese Erkenntnis schockierend fand Aber es geht nicht anders,denn die I2P-Router müssen sich ja trotzdem miteinander auf Basis von Internettechnologien unterhalten. Und das verlangt IP.

Es ist aber ein Geheimnis, welches DEINE IP ist

I2P erlaubt dir Dienste im I2P Netzwerk zu nutzen, ohne dass eine der beteiligten Parteien (auch die eingebundenen Router selbst) wissen, dass du Dienste nutzt oder welche du nutzt. Gleichzeitig erlaubt es dir, Services im I2P Netzwerk anzubieten, ohne dass deine Nutzer wissen WO ( also auf welchem Router ) der Dienst läuft und ohne dass du weisst, von WO aus deine Nutzer zugreifen. Server und Client geniessen den gleichen Schutz.

Ein wichtiger Aspekt in Bezug auf die Anonymität im I2P Netzwerk ist daher die Gesamtanzahl aktiver Router. Je grösser sie ist, desto besser. ( Anonymity likes Company). Im aktuellen Moment (500-700 Knoten) ist diese noch nicht sonderlich hoch

Ausholung

Normale Internetrechner kommunizieren über TCP / IP. IP sorgt dafür, dass ein Paket im Netzwerk seinen Weg findet und TCP ( manchmal auch UDP ) adressiert einen Dienst auf dem Rechner ( Port ) und sorgt für Flusskontrolle / Vollständigkeit / Datenintegrität. Das System klappt, ist recht schnell, aber leider direkt und ganz und gar nicht verschleiernd. Manche Leute benutzen deshalb Proxies für bestimmte Dienste und verschleiern damit gegenüber dem Leistungsanbieter die tatsächliche Absenderidentität. Diese ist DANN aber beim Proxybetreiber immer noch zu finden. Der Proxy schützt in dem Moment auch nur den Client, da dieser sich vor dem Dienstanbieter verschleiert, nicht aber den Anbieter, da dessen IP / Name natürlich öffentlich bekannt ist. Dazu kommt das der Proxybetreiber meine Clientidentität kennt und unter Umständen nicht als vertrauenswürdig zu bewerten ist. Normale Internetkommunikation ist dazu nicht verschlüsselt, also mit bestimmtem Aufwand mit zu schnüffeln.

Zuerst sollte man sagen: Alles, was I2P Router kommunizieren, ist verschlüsselt. (Ich gehe daruf jetzt nicht näher ein)

Dazu kommt.. Wenn dein I2P Knoten hochfährt, baut er mehrere sogenannte Tunnel auf. Zum Tunnelaufbau werden dabei neben deinem eigenen Knoten IMMER auch andere I2P Knoten benötigt, die dir dabei helfen. Ein Tunnel ist dabei ein "Kommunikationskanal" über den dein Router Daten in das Netzwerk schickt, oder über den dein Router Daten aus dem Netzwerk erhält. Für beide Richtungen werden unterschiedliche Tunnel aufgebaut. Dein Router sendet also Daten über andere Tunnel, als er Daten empfängt. Meist baut dein Router nach dem Hochfahren zwischen 3-10 ausgehende Tunnel und einige eingehende Tunnel auf.

              +---------+ ausgehende Tunnel
              |dein     | -------------->
              |Router   | -------------->
              |         | -------------->
              |         |
              |         | Eingehende Tunnel
              |         | <--------------
              |         | <--------------
              |         | <--------------
              +---------+


Ausgehender Tunnel in Nahaufnahme


+--------+        +---------+       +---------+     +--------+
|Dein    |        |HOP 1    |       |HOP  2   |     |Endpoint|
|Router  |------->|Router   |------>|Router   |---->|Router  |--------->
|        |        |der macht|       |der macht|     |der mit |Daten VON mir treten hier
|        |        |mit      |       |mit      |     |macht   |in das Netzwerk und
+--------+        +---------+       +---------+     +--------+in das Gateway eines
                                                              eingehenden Tunnels

Kurz gesagt: Ein Tunnel ist ein virtuelles Konstrukt. Er kommt zustande, wenn dein Router andere Router bittet, ihm zur Datendurchleitung zur Verfügung zu stehen. Im obigen Beispiel ist es ein ausgehender Tunnel, der dargestellt wird Alle, die im I2P Netzwerk Daten von mir empfangen, sehen nicht, von welchem Router die Daten ursprünglich stammten. Statt dessen erscheint der Endpoint Router als derjenige der die Daten versandt hat.

Das gleiche Schema kann man aber auch umkehren:

+--------+        +---------+       +---------+     +--------+
|Dein    |        |HOP 1    |       |HOP  2   |     |Gateway |
|Router  |<-------|Router   |<------|Router   |<----|Router  |<---------
|        |        |der mit  |       |der macht|     |der mit |Daten FüR mich treten hier
|        |        |macht    |       |mit      |     |macht   |aus dem Netzwerk
+--------+        +---------+       +---------+     +--------+in das Gateway meines
                                                              eingehenden Tunnels

Daten, die meinen Router als Ziel haben, werden ebenfalls über einen Tunnel an mich gesandt, die Daten treten am inbound Gateway ein hüpfen über die anderen mitmachenden Router und werden dann von mir weiterverarbeitet.

Dein eigener Router macht übrigens auch mit. Abhängig von der Geschwindigkeit deiner Anbindung und weiterer Konfigurationen ist dein Router nicht nur Anfangspunkt und Endpunkt deiner eigenen Tunnel, sondern partizipiert an den ein/ausgehenden Tunnel anderer Router. Somit ergibt sich eine Vermaschung, die eine Rückverfolgung bzw Datenanalyse erschwert. Damit transportierst du auch den Verkehr anderer über deinen Router, welches es leichter macht, bestreiten zu können, dass dieser Verkehr für dich selbst bestimmt war. ( Plausible Deniability )

Dein Router ist dabei ständig am Tunnel aufbauen, abbauen und umbauen und wird von anderen Routern auch immer wieder gebeten an neuen Tunneln zu partizipieren. Es handelt sich um ein hochdynamisches System.

Das alles ist der Grundstein für ein leistungsfähiges gemixtes / verschlüsseltes Netzwerk. Es ermöglicht aber noch keine Dienste und kein Routing im Netzwerk. Wie das funktioniert, erkläre ich im zweiten Teil.

Teil 2

Hallo nochmal,

Wer auf diesen Artikel stösst und noch nicht den ersten Teil gelesen hat, sollte dies noch nachholen. Damit wird das Verständnis spürbar erleichtert Smiley

Ich hatte im letzten Teil das grundsätzliche Verfahren erläutert, mit dem I2P Knoten untereinander kommunizieren. Das virtuelle Konstrukt, "Tunnel" genannt sichert das Netzwerk gegen eine Reihe von Attacken und Bedrohungszenarien ab, die eingesetzt werden könnten, um das Arbeiten des Netzwerks zu stören oder Daten zu erheben, die eventuell genutzt werden könnten, um Verkehr im Netzwerk mit bestimmten Diensten oder gar Nutzern zu korrelieren. Bitte nehmt zur Kenntnis, dass ich nicht auf ALLE Mechanismen, sondern nur auf die Basisideen eingegangen bin. Bestimmte Konzepte wie das Garlic-Routing und welche Kryptographie an welcher Stelle eingesetzt wird, ist ausserhalb des Fokus' dieses Dokuments.

Wenn wir uns die Routerbasiskommunikation betrachten, stellen wir jedoch fest, dass sich dort keinerlei Bezug finden lässt, wie denn nun Nutzer/Programme in diesem Netzwerk zueinander finden. Die im ersten Teil zitierten Tunnel und die I2P interne Kommunikation geschieht fern von Serverdiensten, Ports und Clients, die sie nutzen wollen. Um dies zu ermöglichen, müssen wir uns einige weitere Komponenten der I2P Welt näher anschauen.

In der normalen Internetwelt haben wir TCP/IP, wobei TCP das sogenannte Transportprotokoll ist. Es adressiert den gewünschten Dienst über den Port, verfügt über eine statusorientierte Kommunikation und Datenflusskontrolle, sowie Integritätschecks.

I2P könnte man als ein "IP" üBER TCP/IP betrachten. Die Router reden über TCP/IP miteinander, bauen Tunnel auf und tauschen verschlüsselt über diese Tunnel Nachrichten aus. Diese darin enthaltenen Nachrichten könnte man als NEUE IP-Pakete betrachten, auch wenn ihnen, im Vergleich mit Ihren echten Internetkameraden Merkmale, wie IP Absende und Zieladresse fehlen. Aber genau das ist ja das Ziel bei I2P!

Partizipiert dein Router nur an Tunneln, bekommt er die eigentliche Nachricht oder Payload nicht zu sehen. Er leitet sie einfach an den nächsten Partner weiter, bis die Nachricht den Router erreicht, der am Ende des Tunnels ( oder Anfang des Tunnels ) steht. Nur dieser kann die Nachricht entschlüsseln.

Damit nun aus dieser Quasi-IP Nachricht etwas programmtechnisch nutzbares wird, gibt es in I2P die sogenannte Streaming-Lib. Sie kann als TCP/UDP Implementierung von I2P betrachtet werden, da sie Nachrichten aus den Tunneln zu einem Datenstrom zusammensetzt und diese an lokale Ports auf deinem Node weiterleitet, an denen z.B. ein Webserver horcht oder anderere Services laufen.

               dein Node
eingehender  +---------------+
Tunnel1      |  +---------+  |
-----------> |->|         |  |
[DATEN1]     |  |[DATEN1] |  |
             |  | +   +   |=====>Datenstrom  ---> <lokaler Port> <-> <Applikation>
eingehender  |  |[DATEN2] |  |                       z.b.9999        z.B Webserver
Tunnel2      |  | +   +   |  |
-----------> |->| CHECKS  |  |
[DATEN2]     |  +---------+  |
             | Streaming Lib |
             +---------------+

Im obigen Bild können wir schematisch erkennen, wie die Daten aus zwei unterschiedlichen eingehenden Tunneln, von der StreamingLib zu einem Datenstrom zusammengesetzt werden und danach an einen lokalen Port geleitet werden. Wenn man bedenkt, wie die Tunnelbildung zustandekommt, so fällt es einem Angreifer äussert schwer, nachzuvollziehen, welche Daten die durch deinen Router laufen, schlussendlich für dich bestimmt waren, da Daten, auch wenn sie die selbe Quelle und das selbe Ziel haben, unterschiedlichste Wege durch das Netz nehmen werden.

Das gleiche gilt umgekehrt natürlich auch für ausgehende Daten.

Das klingt soweit ganz schön, ist aber alles nur akademischer Natur, wenn es einem Anwender nicht gelingt den Dienst, den er kontaktieren möchte, in irgendeiner Art zu benennen oder anzusteuern. Im normalen Internet haben wir dazu DNS Namen(Hostnamen) und Ports. In I2P gibt es dies nicht. Trotzdem muss ein beliebiger Teilnehmer im Netzwerk einen beliebigen I2P-öffentichen Dienst erreichen können.

Um dies zu ermöglichen, greift man zu einem nicht ganz leichten Verfahren, welches ich hier versuche, zu erläutern. Wir bleiben bei dem Beispiel Webserver. Markus hat in seinem Howto http://board.planetpeer.de/index.php/topic,731.0.html [einsehbar auf archive.org] erklärt, wie man mit Zuhilfenahme des I2PTunnel Tools ( Webbasiert ) die Einrichtung eines neuen Dienstes vornimmt. (Bitte unbedingt lesen, wer es noch nicht getan hat)

Das interessante dabei ist, dass für diesen "Dienst" neben dem Port und einigen weiteren Angaben ein kryptographisches Schlüsselpaar mit öffentlichem und privatem Schlüssel gebildet wird. Der private Schlüssel wird auf der Festplatte in deinem I2P Arbeitsverzeichnis gespeichert. Der öffentliche Schlüssel wird "veröffentlicht", d.h. anderen I2P Nutzern zugänglich gemacht. Er wird im I2P Jargon meist "Destination Key" oder einfach nur "Destination" genannt. Der öffentliche Schlüssel ist also eine Art "Namen" unter dem dein Dienst in Zukunft für andere zugänglich gemacht wird.

Da niemand 516 Zeichen gerne in seinem Browser eintippt, verfügt dein I2P über eine hosts.txt Datei, in der alle bekannten und veröffentlichten Destinations unter einem einfachen Namen abgespeichtert werden

Beispieleintrag aus der hosts.txt
sciencebooks.i2p=Rrqf6EmeuqckygNrim-ZcZ97uEIL9Ykkr8cj1RSGbeih33~UUpjAp0x2fxrpbibXwuGufWMNoaMkZH8FxO xZr1hvBeV4Mvjrn05kKWyPpBB1x7rAcVCCoD~bl6CUU2k4NtFrO9~BCCZdoIvMxXYWRy4nj18RVaIlOS3qE6~F04pU7Fy0sj7xtd0 2wgeyKkJ6pXYGfETMr6phVusHSSQfCumDBpnqEt7EcXTIsPz58y9Zim4u1wp6xj~OvGWFIP8fKIxpH~zf6o0qYytXrf6SJbIEvwIT KGIXZTM5KxQ0LbEydSgPn4q5PttQlKg~7hxuGG5RYqP2IMg-f9z4-1SfYTbz~EixEq8gv0R30c60tqsyAaw9o37R3k9inkT5WylYw BKM0pzfcAVjejcoPYnFF1iithGl0AYkP~~isxCErCNwLs39NyE688C5amDIpXl7AgB~IvbwZfONbd2cwMOB2RFzTShYZlwcILB7Ez gMvEt2l8GBkstP3CzNrjQ2gAL0AAAA

Aber woher weiss mein I2P Router WO er sich hinwenden soll wenn er sciencebooks.i2p connecten will? Nun, die Veröffentlichung des Schlüssels in den I2P Foren oder im IRC oder mit Hilfe der mitgelieferten Adressbuch Software, dient nur zur Bekanntmachung unter den Anwendern des Netzwerkes. Damit I2P Router den Service finden, wurde ein automatisches Verfahren etabliert:

Nehmen wir mal an, du aktvierst einen Servertunnel für deinen Webserver auf Port 9999 dazu wird das Schlüsselpaar erzeugt, du announct den Destinationkey im I2P Forum. Gleichzeitig muss dein I2P Router sicherstellen, dass Anwender deinen Server finden, ohne dabei deine tatsächliche IP/Identität herauszufinden. Also kommen auch hier die Tunnel ins Spiel

Dein Router baut einen oder mehrere eingehende Tunnel auf, über die dich Nutzer in Zukunft erreichen können sollen

        +--------+        +---------+       +---------+     +--------+
        |Dein    |        |HOP 2    |       |HOP  1   |     |Gateway |
Port    |Router  |<-------|Router   |<------|Router   |<----|Router  |<---------
9999<---|        |        |der mit  |       |der macht|     |der mit |Daten FüR mich treten hier
        |        |        |macht    |       |mit      |     |macht   |aus dem Netzwerk
        +--------+        +---------+       +---------+     +--------+in das Gateway meines
                                                                |     eingehenden Tunnels
                                                                |
                                                                |
                                                              NETDB

Das alleine hilft dir noch nicht. Als nächstes veröffentlicht der Gateway Router eine Information der Form
"Hallo Leute, wenn ihr sciencebooks.i2p sucht ( Schlüssel: SchRrqf6EmeuqckygNrim-ZcZ97uEIL9Ykkr....)
dann bin ich dafür der entgegennehmende Router für die nächsten paar Minuten"
in der sogenannten netdb. Die NetDB ist eine verteilte Informationsdatenbank, in der I2P speichert, welche Router zum Netzwerk gehören und welche Destinations wie erreicht werden können. Sie ist in Form einer Distributierten HashTable organisiert und arbeitet komplett dezentral, ist also auf alle I2P Knoten verteilt.

Fällt euch etwas auf?
Der Router der in die Netdb speichert, dass eine bestimmte Destination über Ihn erreichbar ist, seid nicht ihr, sondern der Gateway Router für euren eingehenden Tunnel. Damit ist euer Router als eigentlicher Dienstanbieter versteckt und die HOP Router dazwischen kriegen von all dem auch nichts mit.

Etwas zweites ist interessant: Der Netdb Eintrag ist nur zeitlich begrenzt gültig. Meist gilt er nicht länger als 10 Minuten. Aus diesem Grund wird dieses Announcement auch als "LeaseSet" bezeichnet. Der Gateway Router ist nur für einige Minuten das System, welches für Euren Webserver eingehenden Tunnel spielt. Nach ein paar Minuten werden die Karten neu gemischt ein neuer eingehender Tunnel wird gebaut, der andere partizipierende Knoten hat und mit hoher Wahrscheinlichkeit auch einen anderen Gateway Router. Ist dies geschehen wird das alte Leaseset durch ein neues ersetzt und alle, die deinen Service nutzen wollen, müssen die neue Tunnelstrecke verwenden. Das ganze geschieht für den Anwender unterbrechungsfrei. Dafür sorgt die Streaminglib.

Damit kann Euer Dienst gefunden werden, ohne das der Nutzer/Anwender weiss, welcher I2P Router ihm den Service anbietet.

Der Client, der sich mit euch verbinden will, fragt also in der netdb an, auf welchem I2P Router er einen eingehenden Tunnel für diesen Dienst findet, und benutzt einen oder mehrere seiner ausgehenden Tunnel, um sich mit deinem Dienst zu verbinden. Dabei hat auch ein Client eine Destination, da der Server ihm ja antworten können muss. Allerdings ist es so, dass Client Destinations nicht in der Netdb gelistet werden. Stattdessen teilt der Client beim Verbindungsaufbau mit, über welchen incoming Tunnel Gateway er für eine Antwort zur Verfügung steht.

Trotz dieses gewaltigen Aufwands kann die Geschwindigkeit, mit der im I2P Daten übertragen werden, recht beeindruckend sein. Allerdings hängt dies immer auch von der übertragungskapazität und der Auslastung der beteiligten Router ab.

Ich hoffe mal, dass einige von Euch jetzt verstanden haben, nach welchem Verfahren I2P grundsätzlich funktioniert. Im Teil III werde ich auf Bedrohungsszenarion und Sicherheitsrisiken eingehen