Anonyme Internetnutzung mit dem Invisible Internet Project (I2P)
Technischer Datenschutz Teil 4
Durch die Vorrats- und Verbindungsdatenspeicherung wird der Datenschutz im Internet weiter ausgehöhlt. Um dennoch das Internet anonym nutzen zu können, muss man zu technischen Hilfsmitteln greifen. In Teil 4 der Reihe über technischen Datenschutz wird die VPN-ähnliche Lösung I2P getestet.
Das Invisible Internet Project (I2P) hat einen von TOR verschiedenen Ansatz: Neben der Nutzung verschiedener Dienste im Internet liegt das Hauptaugenmerk der Entwickler auch im Anbieten interner Dienste. Somit ist es möglich, anonyme Webserver ("Eepsites") zu betreiben, die sich durch die Pseudo-Top-Level-Domain .i2p auszeichnen. Einige dieser Eepsites sind auf der Startseite der I2P-Console aufgelistet, die zur bequemen Administration des Clients über einen Browser aufgerufen werden kann.
Ein weiterer Unterschied ist der Verzicht auf einen zentralen Server, der Informationen über verbundene Knoten vorrätig hält. Die Clients verbinden sich selbständig und routen ihre Anfragen zu anderen Clients. Interessant ist auch die Trennung von aus- und eingehendem Verkehr, die durch unterschiedliche "Tunnel" gesendet werden. Die Daten innerhalb eines Tunnels werden mit einen 1024 Bit DSA-Schlüssel signiert und 256 Bit AES verschlüsselt weitergeleitet, wobei sich zwischen Start- und Endpunkt eines Tunnels zwei weitere Router befinden. Die Routen können auch von Datenpaket zu Datenpaket variiert werden. Der Schlüsselaustausch erfolgt über einen 2048 Bit Diffie-Hellman-Algorithmus. Zur Optimierung liefern die am Netzwerk angeschlossenen Rechner Informationen über die Übertragungsrate und Auslastung an die mit ihnen verbundenen Clients.
Für den Test wurde die I2P-Version 0.6.1.28, sowie Azureus 2.5.0.4 mit dem I2P-Plugin in der Version 0.2.1 verwendet. Der Client ist in Java programmiert, die kompilierte .exe-Datei kann auch auf nicht-Microsoft-Systemen mit einem Aufruf über einen installierten Java-Interpreter geöffnet und I2P damit installiert werden. Dies funktionierte auch unter Debian Etch problemlos, wenn eine aktuelle Java-Version installiert ist. Unter Windows war dies 1.5.0_11-b03, in Debian 1.4.2-03, obwohl eine Version 5.0 empfohlen wird.
Im Gegensatz zu TOR ist jeder verbunden Client auch gleichzeitig ein Ausgangsknoten, durch den andere Nutzer das Netzwerk nach außen nutzen können. Dieses anonyme Surfen funktioniert allerdings nicht immer - teilweise werden HTML-Seiten mit dem MIME-Typ application/octet-stream übertragen. Eine Möglichkeit, diese Texte dennoch betrachten zu können, wäre, sie auf dem Rechner lokal zu speichern - dann erhält man beim Betrachten aber nur Zeichensalat.
Es existiert auch ein Plugin für den BitTorrent-Client Azureus, bei dessen Verwendung allerdings Vorsicht angebracht ist: Das alleinige Aktivieren der Erweiterung ist nicht ausreichend - es müssen weitere Einstellungen vorgenommen werden, um den Datenverkehr nur über I2P laufen zu lassen, die auch für erfahrene Nutzer nicht trivial sind. Danach läuft die Übertragung der Daten nur noch über das I2P-Netzwerk. BitTorrent-Clients außerhalb werden nicht mehr kontaktiert, was die Übertragungsrate deutlich reduziert.
Sicherheit und Angriffsmöglichkeiten auf das Netzwerk
Durch die kurzlebigen Routen ist die Identifikation eines Nutzers schwer möglich, so dass eine vollständige Umzingelung eines Clients sehr schwer zu erreichen ist. Dazu trägt auch bei, dass Anfrage und Antwort auf verschiedenen Wegen an ihr Ziel gelangen. Durch den Wegfall eines zentralen Servers ist es für einen Angreifer auch schwieriger, eine Verbindung mit dem Netzwerk überhaupt zu entdecken. Aus diesem Grunde ist es jedoch notwendig, dass nicht nur der Transport der Nutzdaten, sondern auch die Tunnelverwaltung über den Tunnel selbst abgewickelt wird - was wiederum charakteristischen Datenverkehr bewirkt, so dass dieser Vorteil teilweise aufgehoben wird. Andererseits wird dadurch aber auch der Nachweis über die übermittelten Daten erschwert.
Weitere Angriffe sind zumindest theoretisch denkbar: So kann ein Angreifer über den Vergleich der Laufzeiten von Datenpaketen im I2P-Netzwerk zumindest Teilnehmer ausschließen, die nicht schnell genug wären, um diese weiterzuleiten. Dagegen steht bei I2P bereits mit Hilfe der Trennung von Anfrage- und Rückgaberouten ein sehr gutes Mittel bereit. Allerdings möchten die Entwickler weitere Strategien einbauen, um dieses Verfahren endgültig auszuschließen. Auch wären diverse Denial-of-Service-Attacken auf das Netzwerk denkbar, mit deren Hilfe zwar keine Nutzer identifiziert werden können, mit denen aber die Benutzung unmöglich gemacht werden kann. Schließlich könnte ein Angreifer auch durch gefälschte Performance-Parameter einen Großteil des Verkehrs auf Knoten ziehen, die unter seiner Kontrolle stehen - ähnlich wie dies bei TOR bereits nachgewiesen wurde. Damit wird eine vollständige Umzingelung einzelner Clients wahrscheinlicher.
Dies sind u. a. auch die Gründe, weshalb die Entwickler I2P noch nicht als sicher ansehen. Allerdings gibt es bereits Überlegungen zu Verbesserungen. Ein anderer wichtiger Grund für die Unfertigkeit ist das Fehlen eines Review-Prozesses, durch den eben solche Probleme aufgedeckt werden. Sehen die Entwickler das Netzwerk als sicher an, soll dies durch einen Sprung auf die Versionsnummer 1.0 angezeigt werden.