I2P (Invisible Internet Project; ) ist ein verschlüsseltes, anonymes, pseudonymes und dezentrales ohne Server auskommendes weltweit verteiltes Rechnernetz.
I2P basiert auf freier Software und hat das Ziel, eine einfache Übertragungsschicht mit dem Nutzen der Anonymität und Privatsphäre, der Sicherheit vor Angriffen und der Resistenz gegenüber Zensur für verschiedene Anwendungssoftware zu ermöglichen. I2P ermöglicht eine anonyme, verschlüsselte und dezentrale über Peer-to-Peer verteilte Kommunikationsschicht, die dafür konzipiert wurde, jedes herkömmliche Protokoll wie BitTorrent, HTTPS, SSH, XMPP, E-Mail, IRC, IPv4 und IPv6, genauso wie die traditionellen verteilten Anwendungen (z. B. Squid oder auch DNS) zu unterstützen.
Funktionsweise mini|I2P als Android-App Das I2P-Netzwerk selbst ist nachrichtenbasiert (wie IP), bietet aber auch eine Bibliothek an, die Datenübertragung sowie Streaming von Information ermöglicht und TCP ähnlich ist. Jede Datenübertragung ist in I2P mehrfach verschlüsselt, dafür werden insgesamt vier Schichten zur Verschlüsselung je Datenpaket verwendet. Auch die Empfangspunkte (Downloader/Empfänger) der Datenpakete sind wiederum durch das Verschlüsselungsverfahren geschützt, größtenteils bestehen diese aus einem Paar öffentlicher Schlüssel.
Auch wird der Datenverkehr parallel über mehrere unterschiedliche und sich ständig wechselnde Tunnels (Netzwerkketten) geleitet. Der eigene I2P-Router (I2P Benutzer) ist somit auch stetig an der gleichzeitigen und wechselnden Weiterleitung von mehreren verschiedenen und verschlüsselten Datenpaketen für andere I2P-Anwender beteiligt. Angesichts der hohen Anzahl an möglichen dynamischen Transportwegen (der verschiedenen und sich ständig ändernden Netzwerkketten), die der Datenverkehr durchqueren kann, ist es sehr unwahrscheinlich, dass ein Dritter eine vollständige Verbindung beobachten und den Dateninhalt überwachen kann.
Zur Weiterleitung sendet das jeweilige unter I2P laufende Programm seine Daten an den dafür vorgesehenen I2P-Router. Der I2P-Router sorgt zuerst dafür, dass die Daten verschlüsselt und für die Weitergabe anonymisiert werden. Anschließend wird eine Route über mehrere fremde I2P-Router bis zu einem aktuell gültigen Übergabepunkt des Ziel-Routers festgelegt. Von dort werden die Daten wiederum über mehrere I2P-Router bis zum eigentlichen Ziel weitergereicht. Die dabei verwendeten weiterleitenden Router werden als Hops bezeichnet. Aus Sicherheitsgründen werden aber nur die eigenen Hops bis zur Übergabestelle gezählt; auf die Anzahl der vom Ziel-Router bestimmten Hops hat der Absender keinen Einfluss.
Damit unterwegs keine Daten verloren gehen, was bereits beim Ausfall eines I2P-Routers in einer Kette von Routern geschehen kann, werden diese zugleich ein weiteres Mal über eine andere Route gesendet. Jede dieser Routen entspricht einem Tunnel. Konnten die Daten über diesen Weg ihr Ziel erreichen, so wurde dieser Tunnel erfolgreich aufgebaut.
Die Empfangsbestätigung wiederum wird vom Ziel-Router über eine neue Reihe von Hops durch neue Tunnel auf die zuvor genannte Art und Weise versendet.
Zur Ermittlung der jeweiligen Übergabepunkte und Bekanntgabe der Tunnelbelegung wird eine Anfrage an die verteilte I2P-Netzwerkdatenbank gestellt, die eine strukturierte verteilte Hashtabelle (DHT) basierend auf dem Kademlia-Algorithmus vorhält. Nach je elf Minuten werden die Tunnel verworfen und durch neue ersetzt.
I2P verwendet 2048bit ElGamal / AES256 / SHA256 + Session-Tags-Verschlüsselung und Ed25519-EdDSA- / ECDSA-Signaturen.
Realisierung Der Kern der ursprünglichen I2P-Anwendung wurde plattformunabhängig in Java geschrieben; eine bereits installierte Java-Laufzeitumgebung wird vorausgesetzt. In Java-I2P wurden grundlegende Programme in Form von Webanwendungen integriert. Über einen Webbrowser wird die so genannte „Routerkonsole“ aufgerufen. Sie dient zur Konfiguration und als Einstiegsseite in das I2P-Netz.
Seit 2015 existiert mit I2Pd eine vollständige Implementierung in C++. I2Pd kommt mit weniger Ressourcen aus, bringt dafür aber keine zusätzliche Software mit.
Über die in I2P integrierten Proxys können „gewöhnliche“ Anwendungen eingebunden werden. Beispiele hierfür sind alle Webbrowser, das IRC, diverse E-Mail-Programme und auch Software zur Versionsverwaltung. Mittels der Proxys sollen die für gewöhnlich zur Identifizierung mitgesendeten Kopfdaten wie zum Beispiel die IP-Adresse entfernt werden.
Zudem wird eigens auf I2P zugeschnittene Software entwickelt, einige Anwendungen werden im Abschnitt Applikationen angesprochen.
Schnittstellen I2PTunnel ist eine in I2P eingebettete Anwendung, die es erlaubt, beliebige TCP/IP-Dienste über I2P zur Verfügung zu stellen. SAM ist ein Protokoll, welches es erlaubt, I2P-basierte Programme in einer größeren Auswahl von Programmiersprachen zu entwickeln. BOB ist eine weitere Schnittstelle, die es erlaubt, I2P-basierte Programme in einer größeren Auswahl von Programmiersprachen zu entwickeln.
Outproxy I2P wurde aus Sicherheitsgründen als ein in sich geschlossenes Netzwerk entwickelt. Davon abweichend kann ein eigens dafür eingerichteter Proxy innerhalb des I2P-Netzwerks eine Verbindung zwischen dem I2P-Netz und dem Internet herstellen. Für diese so genannten Outproxys besteht zudem die Möglichkeit, die anfallende Kommunikation über das Tor-Netzwerk zu leiten. Damit soll die IP-Adresse der Proxy-Betreiber als erkennbarer Absender verschleiert werden. Auf diese Weise können auch Tor Hidden Services aus dem I2P-Netz erreicht werden. Von den I2P-Entwicklern selbst werden keine öffentlich zugänglichen Outproxys betrieben, sondern sie werden ausschließlich von meist anonymen Freiwilligen bereitgestellt.
Releases I2P hat alle sechs bis acht Wochen eine stabile Version erhalten. Updates werden über I2P-Torrents verteilt und vom Release-Manager (in der Regel zzz oder str4d) signiert.
Unterschied zu Tor Während Tor hauptsächlich anonyme Proxyserver für diverse Internet-Dienste wie IRC (Internet Relay Chat), E-Mail oder HTTP bietet, geschieht bei I2P primär alles innerhalb des Netzwerks. Das hat den Vorteil, dass die Nutzdaten Ende-zu-Ende-verschlüsselt sind. Dies ist zwar auch bei den Tor Onion Services der Fall, nicht aber, wenn normale, öffentlich erreichbare Webservices über Tor verwendet werden. Gleiches gilt für E-Mails, die über einen I2P-internen Server geleitet werden (Susimail): Diese sind nur vom Sender bis zum Server und vom Server zum Empfänger verschlüsselt – I2P-Bote ist davon nicht betroffen, da es serverlos ist.
I2P kommt im Gegensatz zu Tor ohne zentrale Knotendatenbank (directory server) aus und ist somit vollkommen dezentral. Die Knotenliste wird bei I2P stattdessen durch die leistungsfähigsten Knoten (sogenannte floodfill peers) mit Hilfe des Kademlia-Algorithmus als verteilte Datenbank vorgehalten. Da es keine Zentralinstanz mit der Knotenliste gibt, muss deshalb beim Start von I2P die Adresse mindestens eines anderen I2P-Teilnehmers bekannt sein, um am I2P-Netzwerk teilnehmen zu können. Von diesem Teilnehmer kann man dann die Informationen zu weiteren I2P-Knoten erhalten. Um dieses Startproblem zu umgehen, publizieren einige I2P-Teilnehmer regelmäßig die Knotenliste auf verschiedenen Websites. Der I2P-Client versucht diese Websites beim Start automatisch abzurufen, um darüber an Adressen von I2P-Knoten zu kommen.
I2P verwendet im Gegensatz zu Tor auch keine Entry-Knoten, sondern wählt zufällig andere I2P-Benutzer aus, um mit ihnen zu kommunizieren. Dadurch ist es schwieriger, die Quelle oder das Ziel der Daten zu identifizieren, da sie sich in der Menge der anderen I2P-Benutzer verlieren, die ständig und dynamisch unterschiedlichen Traffic im I2P-Netzwerk weiterleiten. Es ist nicht einsehbar, was der I2P-Benutzer selber sendet, da man im Rauschen des weitergeleiteten Traffics von anderen I2P-Anwendern untergeht. Bei Tor hingegen werden Entry-Knoten benötigt, die immer als erste Station vom Anwender verwendet werden, um ins Tor-Netzwerk zu gelangen. Diese Entry-Knoten sind öffentlich bekannt und können von Dritten beobachtet werden, die versuchen könnten, die Aktivitäten der Tor-Benutzer zu verfolgen.
Auch benutzt I2P ausschließlich unidirektionale Tunnel, was bei der Abwehr von Timing-Angriffen hilfreich ist, denn eine Anfrage und die Antwort darauf nehmen nicht denselben Weg. Allerdings verdoppelt dies auch die Anzahl aufgebauter Tunnel, was wiederum die Wahrscheinlichkeit erhöht, einen Tunnel mit Knoten aufzubauen, die unter der Kontrolle eines Angreifers liegen. Damit könnte für diesen Angreifer u. U. eine Deanonymisierung der Verkehrsbeziehung zwischen Sender und Empfänger möglich werden.
Zusätzlich verwendet I2P onion routing auch garlic messages. Diese realisieren die Ende-zu-Ende-Verschlüsselung innerhalb des I2P-Netzes und bündeln eine oder mehrere Nachrichten, die beim Empfänger gemeinsam entschlüsselt werden. Die einzelnen Nachrichten müssen dabei nicht alle unbedingt für den Empfänger selbst bestimmt sein, sondern können teilweise auch Weiterleitungs- und Verzögerungsanweisungen enthalten. Dies ist insbesondere für zeitunkritische Dienste interessant, da die durch die Verzögerung realisierte zeitliche Entkopplung der Nachrichtenweiterleitung die Anonymität zusätzlich stärkt.
Prinzipiell wäre I2P auch ganz ohne Tunnelaufbau, d. h. allein durch Nutzung der Weiterleitungsfunktion innerhalb der garlic messages anonym verwendbar, indem die weiterzuleitende Nachricht selbst wieder eine garlic message für den nächsten Knoten in der Route ist usw. Standardmäßig wird diese Form der Nachrichtenweiterleitung aber nicht verwendet.
Angriffsverfahren Im Jahr 2011 wurde ein Angriffsverfahren auf das I2P-Netzwerk dokumentiert und gezeigt, dass ein Angreifer mit moderaten Ressourcen die Identität eines HTTP-Dienstes (einer „eepsite“) herausfinden kann.
Die entscheidenden Schwachstellen dieses Angriffs wurden in den folgenden Jahren durch mehrere gezielte Verbesserungen behoben:
- Das NetDB- und Verifizierungsprotokoll wurde mehrfach überarbeitet und gehärtet, sodass die damalige Kombination aus Sybil-ähnlicher netDB-Manipulation und Tunnel-Endpoint-Korrelation nicht mehr praktikabel ist.
- Die Standard- bzw. empfohlene Länge clientseitiger Tunnels wurde von früher häufig 2 hops auf 3 hops (in beide Richtungen) angehoben. Dadurch steigt der Aufwand für Korrelations- und Timing-Angriffe deutlich an.
- Das alte UDP-Transportprotokoll SSU wurde (seit ca. 2005) durch das deutlich sicherere SSU2 ersetzt, das bessere Authentifizierung, Schutz vor Fingerprinting und DoS-Resistenz bietet. Seit der I2P-Version 2.0.0 (November 2022) ist SSU2 für alle Nutzer standardmäßig aktiviert; das alte SSU-Protokoll wurde später schrittweise deaktiviert.
Der spezifische 2011/2013-Angriff gilt daher seit etwa 2014–2016 als mit moderaten Mitteln nicht mehr durchführbar. Neuere Forschungsarbeiten zu I2P konzentrieren sich stattdessen auf andere, meist sehr ressourcenintensive Angriffsvektoren (z. B. großflächige Traffic-Correlation oder langfristige Verhaltensmuster-Analyse), vor denen das Netzwerk in der Praxis den meisten Anwendern weiterhin eine hohe Schutzwirkung bietet.
Applikationen E-Mail susimail In Java-I2P integriert ist der Webmail-Client susimail (Eigenschreibweise) im Zusammenspiel mit dem Provider „Postman HQ“. Abruf und Versand erfolgen via SMTP und POP3. Mit susimail sollen die in diesem Bereich als Sicherheitslücken geltenden Kopf-Daten, die zur Identifikation der Absender führen, gefiltert werden. Eine Verschlüsselung der eigentlichen E-Mails liegt im Ermessen der Anwender. Der Dienst steht allen Teilnehmern nach Anmeldung kostenfrei zur Verfügung.
I2P-Bote I2P-Bote ist ein Ende-zu-Ende-verschlüsseltes, netzwerkinternes und völlig dezentrales, serverloses E-Mail-System.