I2P: Ein skalierbares Framework für anonyme Kommunikation

HINWEIS: Dieses Dokument wurde ursprünglich 2003 von jrandom verfasst. Obwohl wir uns bemühen, es aktuell zu halten, können einige Informationen veraltet oder unvollständig sein. Die Abschnitte zu Transport und Kryptographie sind Stand 2025-01 aktuell.

Einführung

I2P ist eine skalierbare, sich selbst organisierende, belastbare paketvermittelte anonyme Netzwerkschicht, auf der beliebig viele verschiedene anonymitäts- oder sicherheitsbewusste Anwendungen laufen können. Jede dieser Anwendungen kann ihre eigenen Kompromisse zwischen Anonymität, Latenz und Durchsatz treffen, ohne sich um die ordnungsgemäße Implementierung eines freien Route-Mixnets sorgen zu müssen, wodurch sie ihre Aktivitäten mit der größeren Anonymitätsgruppe von Benutzern vermischen können, die bereits auf I2P laufen.

Die bereits verfügbaren Anwendungen bieten das vollständige Spektrum typischer Internetaktivitäten — anonymes Web-Browsing, Web-Hosting, Chat, Dateiaustausch, E-Mail, Blogging und Content-Syndication sowie mehrere weitere Anwendungen, die sich in der Entwicklung befinden.

Web-Browsing: mit jedem vorhandenen Browser, der die Verwendung eines Proxys unterstützt.
Chat: IRC und andere Protokolle
Dateiaustausch: I2PSnark und andere Anwendungen
E-Mail: susimail und andere Anwendungen
Blog: mit jedem lokalen Webserver oder verfügbaren Plugins

Anders als Websites, die in Content Distribution Networks wie Freenet oder GNUnet gehostet werden, sind die auf I2P gehosteten Dienste vollständig interaktiv — es gibt traditionelle Web-Suchmaschinen, Diskussionsforen, Blogs, in denen man kommentieren kann, datenbankgesteuerte Websites und Brücken zur Abfrage statischer Systeme wie Freenet, ohne es lokal installieren zu müssen.

Mit all diesen anonymitätsfähigen Anwendungen übernimmt I2P die Rolle der nachrichtenorientierten Middleware — Anwendungen geben an, dass sie Daten an eine kryptografische Kennung (eine “destination”) senden möchten, und I2P kümmert sich darum, dass diese sicher und anonym ankommen. I2P bündelt auch eine einfache Streaming -Bibliothek, um I2Ps anonyme Best-Effort-Nachrichten als zuverlässige, geordnete Streams zu übertragen und bietet transparent einen TCP-basierten Staukontrollalgorithmus, der auf das hohe Bandbreiten-Verzögerungs-Produkt des Netzwerks abgestimmt ist. Obwohl mehrere einfache SOCKS-Proxies verfügbar waren, um bestehende Anwendungen an das Netzwerk anzubinden, war ihr Nutzen begrenzt, da nahezu jede Anwendung routinemäßig Informationen preisgibt, die in einem anonymen Kontext sensibel sind. Der einzige sichere Weg ist eine vollständige Prüfung einer Anwendung, um den ordnungsgemäßen Betrieb sicherzustellen, und um dabei zu helfen, stellen wir eine Reihe von APIs in verschiedenen Sprachen bereit, die verwendet werden können, um das Beste aus dem Netzwerk herauszuholen.

I2P ist kein Forschungsprojekt — weder akademisch, kommerziell noch staatlich — sondern eine technische Entwicklungsarbeit, die darauf abzielt, alles Notwendige zu tun, um ein ausreichendes Maß an Anonymität für diejenigen zu bieten, die sie benötigen. Es befindet sich seit Anfang 2003 in aktiver Entwicklung mit einem Vollzeit-Entwickler und einer engagierten Gruppe von Teilzeit-Mitwirkenden aus der ganzen Welt. Die gesamte Arbeit an I2P ist quelloffen und frei verfügbar auf der Website , wobei der Großteil des Codes direkt in die öffentliche Domäne freigegeben wurde, obwohl einige kryptographische Routinen unter BSD-ähnlichen Lizenzen verwendet werden. Die an I2P arbeitenden Personen kontrollieren nicht, unter welchen Lizenzen andere Client-Anwendungen veröffentlichen, und es sind mehrere GPL-lizenzierte Anwendungen verfügbar (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex und andere). Die Finanzierung für I2P stammt vollständig aus Spenden und erhält derzeit in keiner Rechtsordnung Steuererleichterungen, da viele der Entwickler selbst anonym sind.

Betrieb

Überblick

Um die Funktionsweise von I2P zu verstehen, ist es wichtig, einige Schlüsselkonzepte zu begreifen. Zunächst trennt I2P strikt zwischen der Software, die am Netzwerk teilnimmt (ein “router”), und den anonymen Endpunkten (“destinations”), die mit einzelnen Anwendungen verknüpft sind. Die Tatsache, dass jemand I2P betreibt, ist normalerweise kein Geheimnis. Was verborgen bleibt, sind Informationen darüber, was der Benutzer tut, falls überhaupt etwas, sowie mit welchem router eine bestimmte destination verbunden ist. Endbenutzer haben typischerweise mehrere lokale destinations auf ihrem router — zum Beispiel eine, die zu IRC-Servern weiterleitet, eine andere, die den anonymen Webserver des Benutzers (“I2P Site”) unterstützt, eine weitere für eine I2Phex-Instanz, eine andere für Torrents, usw.

Ein weiteres wichtiges Konzept ist der “tunnel”. Ein tunnel ist ein gerichteter Pfad durch eine explizit ausgewählte Liste von Routern. Es wird geschichtete Verschlüsselung verwendet, sodass jeder der Router nur eine einzige Schicht entschlüsseln kann. Die entschlüsselten Informationen enthalten die IP des nächsten Routers sowie die verschlüsselten Informationen, die weitergeleitet werden sollen. Jeder tunnel hat einen Startpunkt (der erste Router, auch als “Gateway” bekannt) und einen Endpunkt. Nachrichten können nur in eine Richtung gesendet werden. Um Nachrichten zurückzusenden, ist ein weiterer tunnel erforderlich.

Abbildung 1: Es gibt zwei Arten von tunnels: inbound und outbound.

Es gibt zwei Arten von tunneln: “Outbound” tunnels senden Nachrichten vom tunnel-Ersteller weg, während “inbound” tunnels Nachrichten zum tunnel-Ersteller bringen. Durch die Kombination dieser beiden tunnels können Benutzer Nachrichten aneinander senden. Der Sender (“Alice” im obigen Bild) richtet einen outbound tunnel ein, während der Empfänger (“Bob” im obigen Bild) einen inbound tunnel erstellt. Das Gateway eines inbound tunnels kann Nachrichten von jedem anderen Benutzer empfangen und wird sie weiterleiten bis zum Endpunkt (“Bob”). Der Endpunkt des outbound tunnels muss die Nachricht an das Gateway des inbound tunnels weiterleiten. Um dies zu tun, fügt der Sender (“Alice”) Anweisungen zu ihrer verschlüsselten Nachricht hinzu. Sobald der Endpunkt des outbound tunnels die Nachricht entschlüsselt, wird er Anweisungen haben, die Nachricht an das korrekte inbound Gateway weiterzuleiten (das Gateway zu “Bob”).

Ein drittes kritisches Konzept, das es zu verstehen gilt, ist I2Ps “network database” (oder “netDb”) — ein Paar von Algorithmen, die zur Weitergabe von Netzwerk-Metadaten verwendet werden. Die beiden Arten von Metadaten, die übertragen werden, sind “routerInfo” und “leaseSets” — die routerInfo gibt Routern die notwendigen Daten, um einen bestimmten Router zu kontaktieren (deren öffentliche Schlüssel, Transport-Adressen, etc.), während das leaseSet den Routern die notwendigen Informationen gibt, um ein bestimmtes Ziel zu kontaktieren. Ein leaseSet enthält eine Anzahl von “leases” (Mietverträgen). Jeder dieser leases spezifiziert ein Tunnel-Gateway, das das Erreichen eines bestimmten Ziels ermöglicht. Die vollständigen Informationen, die in einem lease enthalten sind:

Eingangs-Gateway für einen tunnel, der das Erreichen eines bestimmten Ziels ermöglicht.
Zeitpunkt, zu dem ein tunnel abläuft.
Paar von öffentlichen Schlüsseln, um Nachrichten verschlüsseln zu können (um sie durch den tunnel zu senden und das Ziel zu erreichen).

Router senden ihre routerInfo direkt an die netDb, während leaseSets durch ausgehende tunnel gesendet werden (leaseSets müssen anonym gesendet werden, um eine Korrelation zwischen einem router und seinen leaseSets zu vermeiden).

Wir können die oben genannten Konzepte kombinieren, um erfolgreiche Verbindungen im Netzwerk aufzubauen.

Um ihre eigenen eingehenden und ausgehenden tunnel aufzubauen, führt Alice eine Suche in der netDb durch, um routerInfo zu sammeln. Auf diese Weise sammelt sie Listen von Peers, die sie als Hops in ihren tunnels verwenden kann. Sie kann dann eine Build-Nachricht an den ersten Hop senden, den Aufbau eines tunnels anfordern und diesen router bitten, die Konstruktionsnachricht weiterzuleiten, bis der tunnel aufgebaut wurde.

Routerinformationen von anderen Routern anfordern

Abbildung 2: Router-Informationen werden verwendet, um Tunnel zu erstellen.

Wenn Alice eine Nachricht an Bob senden möchte, sucht sie zunächst in der netDb nach Bobs leaseSet, um seine aktuellen eingehenden tunnel-Gateways zu finden. Sie wählt dann einen ihrer ausgehenden tunnel aus und sendet die Nachricht mit Anweisungen hinunter, dass der Endpunkt des ausgehenden tunnels die Nachricht an eines von Bobs eingehenden tunnel-Gateways weiterleiten soll. Wenn der Endpunkt des ausgehenden tunnels diese Anweisungen erhält, leitet er die Nachricht wie gewünscht weiter, und wenn Bobs eingehendes tunnel-Gateway sie erhält, wird sie durch den tunnel zu Bobs router weitergeleitet. Wenn Alice möchte, dass Bob auf die Nachricht antworten kann, muss sie ihr eigenes Ziel explizit als Teil der Nachricht selbst übertragen. Dies kann durch die Einführung einer höheren Ebene geschehen, was in der streaming -Bibliothek gemacht wird. Alice kann auch die Antwortzeit verkürzen, indem sie ihr neuestes leaseSet mit der Nachricht bündelt, sodass Bob keine netDb-Suche dafür durchführen muss, wenn er antworten möchte, aber dies ist optional.

Abbildung 3: LeaseSets werden verwendet, um ausgehende und eingehende Tunnel zu verbinden.

Während die tunnels selbst mehrschichtige Verschlüsselung verwenden, um unbefugte Offenlegung gegenüber Peers innerhalb des Netzwerks zu verhindern (ebenso wie die Transportschicht selbst dies tut, um unbefugte Offenlegung gegenüber Peers außerhalb des Netzwerks zu verhindern), ist es notwendig, eine zusätzliche Ende-zu-Ende-Verschlüsselungsschicht hinzuzufügen, um die Nachricht vor dem Endpunkt des ausgehenden tunnels und dem Gateway des eingehenden tunnels zu verbergen. Diese “garlic encryption ” ermöglicht es Alices router, mehrere Nachrichten in eine einzige “garlic message” zu verpacken, die mit einem bestimmten öffentlichen Schlüssel verschlüsselt wird, so dass zwischengeschaltete Peers weder bestimmen können, wie viele Nachrichten sich in der Garlic-Nachricht befinden, was diese Nachrichten besagen, noch wohin diese einzelnen Segmente bestimmt sind. Für die typische Ende-zu-Ende-Kommunikation zwischen Alice und Bob wird die garlic message mit dem öffentlichen Schlüssel verschlüsselt, der in Bobs leaseSet veröffentlicht ist, wodurch die Nachricht verschlüsselt werden kann, ohne den öffentlichen Schlüssel an Bobs eigenen router preiszugeben.

Ein weiterer wichtiger Punkt ist, dass I2P vollständig nachrichtenbasiert ist und dass einige Nachrichten unterwegs verloren gehen können. Anwendungen, die I2P verwenden, können die nachrichtenorientierten Schnittstellen nutzen und sich selbst um Staukontrolle und Zuverlässigkeitsanforderungen kümmern, aber die meisten wären am besten bedient, wenn sie die bereitgestellte streaming Bibliothek wiederverwenden, um I2P als streambasiertes Netzwerk zu betrachten.

Tunnels

Sowohl eingehende als auch ausgehende tunnels funktionieren nach ähnlichen Prinzipien. Das tunnel-Gateway sammelt eine Anzahl von tunnel-Nachrichten an und verarbeitet sie schließlich zu etwas für die tunnel-Übertragung vor. Als nächstes verschlüsselt das Gateway diese vorverarbeiteten Daten und leitet sie an den ersten Hop weiter. Dieser Peer und nachfolgende tunnel-Teilnehmer fügen eine Verschlüsselungsschicht hinzu, nachdem sie verifiziert haben, dass es sich nicht um ein Duplikat handelt, bevor sie es an den nächsten Peer weiterleiten. Schließlich kommt die Nachricht am Endpunkt an, wo die Nachrichten wieder aufgeteilt und wie angefordert weitergeleitet werden. Der Unterschied liegt darin, was der Ersteller des tunnels tut — bei eingehenden tunnels ist der Ersteller der Endpunkt und entschlüsselt einfach alle hinzugefügten Schichten, während bei ausgehenden tunnels der Ersteller das Gateway ist und alle Schichten vorab entschlüsselt, sodass nach dem Hinzufügen aller Schichten der Per-Hop-Verschlüsselung die Nachricht im Klartext am tunnel-Endpunkt ankommt.

Die Auswahl bestimmter Peers zur Weiterleitung von Nachrichten sowie deren spezifische Reihenfolge ist wichtig für das Verständnis sowohl der Anonymitäts- als auch der Leistungsmerkmale von I2P. Während die netDb (unten) ihre eigenen Kriterien für die Auswahl von Peers hat, die abgefragt werden sollen und auf denen Einträge gespeichert werden, können tunnel-Ersteller beliebige Peers im Netzwerk in beliebiger Reihenfolge (und sogar beliebig oft) in einem einzigen tunnel verwenden. Wenn perfekte Latenz- und Kapazitätsdaten global bekannt wären, würden Auswahl und Reihenfolge durch die besonderen Bedürfnisse des Clients in Verbindung mit seinem Bedrohungsmodell bestimmt. Leider sind Latenz- und Kapazitätsdaten nicht trivial anonym zu sammeln, und sich auf nicht vertrauenswürdige Peers zu verlassen, um diese Informationen bereitzustellen, hat seine eigenen schwerwiegenden Anonymitätsimplikationen.

Aus Sicht der Anonymität wäre die einfachste Technik, peers zufällig aus dem gesamten Netzwerk auszuwählen, sie zufällig zu ordnen und diese peers in dieser Reihenfolge für alle Ewigkeit zu verwenden. Aus Leistungssicht wäre die einfachste Technik, die schnellsten peers mit der notwendigen freien Kapazität auszuwählen, die Last auf verschiedene peers zu verteilen, um transparente Ausfallsicherheit zu gewährleisten, und den tunnel neu aufzubauen, wann immer sich Kapazitätsinformationen ändern. Während ersteres sowohl anfällig als auch ineffizient ist, benötigt letzteres unzugängliche Informationen und bietet unzureichende Anonymität. I2P arbeitet stattdessen daran, eine Reihe von Peer-Auswahlstrategien anzubieten, gepaart mit anonymitätsbewusstem Messcode, um die peers nach ihren Profilen zu organisieren.

Als Grundlage erstellt I2P kontinuierlich Profile der Peers, mit denen es interagiert, indem es deren indirektes Verhalten misst — beispielsweise wird, wenn ein Peer auf eine netDb-Abfrage in 1,3 Sekunden antwortet, diese Roundtrip-Latenz in den Profilen aller router aufgezeichnet, die an den beiden tunnels (eingehend und ausgehend) beteiligt sind, durch die Anfrage und Antwort gelaufen sind, sowie im Profil des abgefragten Peers. Direkte Messungen, wie Latenz oder Überlastung auf der Transportschicht, werden nicht als Teil des Profils verwendet, da sie manipuliert und mit dem messenden router in Verbindung gebracht werden können, wodurch dieser trivialen Angriffen ausgesetzt wird. Während der Erfassung dieser Profile wird eine Reihe von Berechnungen für jedes durchgeführt, um dessen Leistung zusammenzufassen — seine Latenz, Kapazität zur Bewältigung hoher Aktivität, ob es derzeit überlastet ist und wie gut es in das Netzwerk integriert zu sein scheint. Diese Berechnungen werden dann für aktive Peers verglichen, um die router in vier Kategorien zu organisieren — schnell und hohe Kapazität, hohe Kapazität, nicht ausfallend und ausfallend. Die Schwellwerte für diese Kategorien werden dynamisch bestimmt, und obwohl sie derzeit recht einfache Algorithmen verwenden, existieren Alternativen.

Mit diesen Profildaten ist die einfachste vernünftige Peer-Auswahlstrategie, Peers zufällig aus der obersten Stufe (schnell und hohe Kapazität) auszuwählen, und dies ist derzeit für Client-tunnel implementiert. Explorative tunnel (verwendet für netDb und tunnel-Verwaltung) wählen Peers zufällig aus der Stufe “nicht fehlerhaft” (welche auch router aus ‘besseren’ Stufen einschließt), wodurch der Peer router breiter abtasten kann und die Peer-Auswahl durch randomisiertes Hill Climbing optimiert. Diese Strategien allein geben jedoch Informationen über die Peers in der obersten Stufe des routers durch Vorgänger- und netDb-Harvesting-Angriffe preis. Wiederum existieren mehrere Alternativen, die, obwohl sie die Last nicht so gleichmäßig verteilen, Angriffe bestimmter Klassen von Angreifern abwehren.

Durch die Auswahl eines zufälligen Schlüssels und die Anordnung der Peers nach ihrer XOR-Distanz zu diesem wird die preisgegeben Information bei Predecessor- und Harvesting-Angriffen entsprechend der Ausfallrate der Peers und der Fluktuation der Ebene reduziert. Eine weitere einfache Strategie zum Umgang mit netDb Harvesting-Angriffen besteht darin, einfach die eingehenden tunnel-Gateways zu fixieren, aber die Peers weiter hinten in den tunnels zu randomisieren. Um Predecessor-Angriffe von Gegnern zu bewältigen, die der Client kontaktiert, würden auch die Endpunkte der ausgehenden tunnel fest bleiben. Die Auswahl, welcher Peer am exponiertesten Punkt fixiert werden soll, müsste natürlich eine zeitliche Begrenzung haben, da alle Peers schließlich ausfallen, sodass dies entweder reaktiv angepasst oder proaktiv vermieden werden könnte, um eine gemessene mittlere Zeit zwischen Ausfällen anderer router nachzuahmen. Diese beiden Strategien können wiederum kombiniert werden, indem ein fester exponierter Peer und eine XOR-basierte Anordnung innerhalb der tunnel selbst verwendet werden. Eine rigidere Strategie würde die exakten Peers und die Anordnung eines potentiellen tunnel fixieren und nur dann einzelne Peers verwenden, wenn alle zustimmen, jedes Mal auf die gleiche Weise teilzunehmen. Dies unterscheidet sich von der XOR-basierten Anordnung darin, dass der Vorgänger und Nachfolger jedes Peers immer derselbe ist, während das XOR nur sicherstellt, dass sich ihre Reihenfolge nicht ändert.

Wie bereits erwähnt, enthält I2P derzeit (Release 0.8) die oben beschriebene mehrstufige Zufallsstrategie mit XOR-basierter Sortierung. Eine detailliertere Diskussion der Mechanismen, die beim tunnel-Betrieb, -Management und der Peer-Auswahl beteiligt sind, finden Sie in der tunnel-Spezifikation .

Network Database (netDb)

Wie bereits erwähnt, funktioniert I2Ps netDb zum Teilen der Netzwerk-Metadaten. Dies ist auf der network database Seite detailliert beschrieben, aber eine grundlegende Erklärung ist unten verfügbar.

Alle I2P router enthalten eine lokale netDb, aber nicht alle router nehmen am DHT teil oder antworten auf leaseSet-Anfragen. Die router, die am DHT teilnehmen und auf leaseSet-Anfragen antworten, werden ‘floodfills’ genannt. Router können manuell als floodfills konfiguriert werden oder automatisch zu floodfills werden, wenn sie genügend Kapazität haben und andere Kriterien für zuverlässigen Betrieb erfüllen.

Andere I2P router speichern ihre Daten und suchen Daten, indem sie einfache ‘store’- und ’lookup’-Anfragen an die floodfills senden. Wenn ein floodfill router eine ‘store’-Anfrage erhält, verbreitet er die Informationen an andere floodfill router unter Verwendung des Kademlia-Algorithmus . Die ’lookup’-Anfragen funktionieren derzeit anders, um ein wichtiges Sicherheitsproblem zu vermeiden. Wenn eine Suche durchgeführt wird, leitet der floodfill router die Suchanfrage nicht an andere Peers weiter, sondern antwortet immer selbst (falls er die angeforderten Daten hat).

Zwei Arten von Informationen werden in der Netzwerkdatenbank gespeichert.

Eine RouterInfo speichert Informationen über einen bestimmten I2P router und wie man ihn kontaktieren kann
Ein LeaseSet speichert Informationen über ein bestimmtes Ziel (z.B. I2P-Website, E-Mail-Server…)

All diese Informationen werden von der veröffentlichenden Partei signiert und von jedem I2P router, der die Informationen verwendet oder speichert, verifiziert. Zusätzlich enthalten die Daten Zeitinformationen, um die Speicherung alter Einträge und mögliche Angriffe zu vermeiden. Das ist auch der Grund, warum I2P den notwendigen Code zur Aufrechterhaltung der korrekten Zeit mitliefert, gelegentlich einige SNTP-Server abfragt (standardmäßig das pool.ntp.org Round-Robin-System) und Zeitabweichungen zwischen routern auf der Transportschicht erkennt.

Einige zusätzliche Anmerkungen sind ebenfalls wichtig.

Unveröffentlichte und verschlüsselte leasesets: Man möchte möglicherweise, dass nur bestimmte Personen ein Ziel erreichen können. Dies ist möglich, indem das Ziel nicht in der netDb veröffentlicht wird. Sie müssen jedoch das Ziel auf anderen Wegen übertragen. Dies wird durch ‘verschlüsselte leaseSets’ unterstützt. Diese leaseSets können nur von Personen mit Zugang zum Entschlüsselungsschlüssel dekodiert werden.
Bootstrapping: Das Bootstrapping der netDb ist recht einfach. Sobald es einem router gelingt, eine einzige routerInfo eines erreichbaren Peers zu erhalten, kann er diesen router nach Verweisen auf andere router im Netzwerk abfragen. Derzeit veröffentlichen eine Reihe von Benutzern ihre routerInfo-Dateien auf einer Website, um diese Informationen verfügbar zu machen. I2P verbindet sich automatisch mit einer dieser Websites, um routerInfo-Dateien zu sammeln und das Bootstrapping durchzuführen. I2P nennt diesen Bootstrap-Prozess “Reseeding”.
Lookup-Skalierbarkeit: Lookups im I2P-Netzwerk sind iterativ, nicht rekursiv. Wenn ein Lookup von einem floodfill fehlschlägt, wird der Lookup zum nächstgelegenen floodfill wiederholt. Der floodfill fragt nicht rekursiv einen anderen floodfill nach den Daten. Iterative Lookups sind skalierbar für große DHT-Netzwerke.

Transport-Protokolle

Die Kommunikation zwischen Routern muss Vertraulichkeit und Integrität gegenüber externen Angreifern gewährleisten und dabei authentifizieren, dass der kontaktierte Router derjenige ist, der eine bestimmte Nachricht erhalten sollte. Die Details, wie Router mit anderen Routern kommunizieren, sind nicht kritisch — drei verschiedene Protokolle wurden zu unterschiedlichen Zeitpunkten verwendet, um diese grundlegenden Anforderungen zu erfüllen.

I2P unterstützt derzeit zwei Transportprotokolle: NTCP2 über TCP und SSU2 über UDP. Diese haben die vorherigen Versionen der Protokolle, NTCP und SSU , ersetzt, welche nun veraltet sind. Beide Protokolle unterstützen sowohl IPv4 als auch IPv6. Durch die Unterstützung sowohl von TCP- als auch UDP-Transporten kann I2P effektiv die meisten Firewalls durchdringen, einschließlich solcher, die darauf ausgelegt sind, Datenverkehr in restriktiven Zensurregimen zu blockieren. NTCP2 und SSU2 wurden entwickelt, um moderne Verschlüsselungsstandards zu verwenden, die Widerstandsfähigkeit gegen Traffic-Identifizierung zu verbessern, Effizienz und Sicherheit zu erhöhen und NAT-Traversierung robuster zu machen. Router veröffentlichen jeden unterstützten Transport und jede IP-Adresse in der Netzwerkdatenbank. Router mit Zugang zu öffentlichen IPv4- und IPv6-Netzwerken werden normalerweise vier Adressen veröffentlichen, eine für jede Kombination von NTCP2/SSU2 mit IPv4/IPv6.

SSU2 unterstützt und erweitert die Ziele von SSU. SSU2 weist viele Ähnlichkeiten mit anderen modernen UDP-basierten Protokollen wie Wireguard und QUIC auf. Zusätzlich zum zuverlässigen Transport von Netzwerknachrichten über UDP bietet SSU2 spezialisierte Funktionen für Peer-to-Peer, kooperative IP-Adresserkennung, Firewall-Erkennung und NAT-Traversierung. Wie in der SSU-Spezifikation beschrieben:

Das Ziel dieses Protokolls ist es, sichere, authentifizierte, semi-zuverlässige und ungeordnete Nachrichtenübertragung bereitzustellen, wobei nur ein minimaler Datenumfang preisgegeben wird, der für Dritte leicht erkennbar ist. Es sollte hochgradige Kommunikation sowie TCP-freundliche Staukontrolle unterstützen und kann PMTU-Erkennung einschließen. Es sollte in der Lage sein, Massendaten effizient mit Raten zu übertragen, die für Heimanwender ausreichend sind. Darüber hinaus sollte es Techniken zur Bewältigung von Netzwerkhindernissen wie den meisten NATs oder Firewalls unterstützen.

NTCP2 unterstützt und erweitert die Ziele von NTCP. Es bietet einen effizienten und vollständig verschlüsselten Transport von Netzwerknachrichten über TCP sowie Widerstand gegen Traffic-Identifikation unter Verwendung moderner Verschlüsselungsstandards.

I2P unterstützt mehrere Transporte gleichzeitig. Ein bestimmter Transport für eine ausgehende Verbindung wird mit “Geboten” ausgewählt. Jeder Transport bietet für die Verbindung und der relative Wert dieser Gebote bestimmt die Priorität. Transporte können mit unterschiedlichen Geboten antworten, je nachdem, ob bereits eine etablierte Verbindung zu dem Peer besteht.

Die Bid-(Prioritäts-)Werte sind implementierungsabhängig und können je nach Verkehrsbedingungen, Verbindungsanzahl und anderen Faktoren variieren. Router veröffentlichen auch ihre Transportpräferenzen für eingehende Verbindungen in der Netzwerkdatenbank als Transport-“Kosten” für jeden Transport und jede Adresse.

Kryptographie

I2P verwendet Kryptographie auf mehreren Protokollebenen für Verschlüsselung, Authentifizierung und Verifikation. Die wichtigsten Protokollebenen sind: Transporte, tunnel build messages, tunnel layer encryption, network database messages und End-zu-End (garlic) messages. I2Ps ursprüngliches Design verwendete eine kleine Anzahl kryptographischer Primitive, die damals als sicher galten. Dazu gehörten ElGamal asymmetrische Verschlüsselung, DSA-SHA1-Signaturen, AES256/CBC symmetrische Verschlüsselung und SHA-256-Hashes. Da die verfügbare Rechenleistung zunahm und die kryptographische Forschung sich über die Jahre erheblich weiterentwickelte, musste I2P seine Primitive und Protokolle aktualisieren. Daher fügten wir ein Konzept von “Verschlüsselungstypen” und “Signaturtypen” hinzu und erweiterten unsere Protokolle um diese Bezeichner und Unterstützungsanzeigen. Dies ermöglicht es uns, die Netzwerkunterstützung für moderne Kryptographie regelmäßig zu aktualisieren und zu erweitern und das Netzwerk für neue Primitive zukunftssicher zu machen, ohne die Rückwärtskompatibilität zu beeinträchtigen oder einen “Flag Day” für Netzwerkupdates zu erfordern. Einige Signatur- und Verschlüsselungstypen sind auch für experimentelle Nutzung reserviert.

Die aktuell verwendeten Grundbausteine in den meisten Protokollschichten sind X25519-Schlüsselaustausch, EdDSA-Signaturen, ChaCha20/Poly1305-authentifizierte symmetrische Verschlüsselung und SHA-256-Hashes. AES256 wird weiterhin für die tunnel-Schicht-Verschlüsselung verwendet. Diese modernen Protokolle werden für den Großteil der Netzwerkkommunikation eingesetzt. Ältere Grundbausteine wie ElGamal, ECDSA und DSA-SHA1 werden von den meisten Implementierungen weiterhin für Rückwärtskompatibilität bei der Kommunikation mit älteren routern unterstützt. Einige alte Protokolle wurden als veraltet markiert und/oder vollständig entfernt. In naher Zukunft werden wir mit der Forschung zu einer Migration auf Post-Quantum (PQ) oder Hybrid-PQ-Verschlüsselung und -Signaturen beginnen, um unsere robusten Sicherheitsstandards aufrechtzuerhalten.

Diese kryptographischen Grundelemente werden kombiniert, um I2Ps mehrschichtige Verteidigung gegen verschiedene Angreifer zu gewährleisten. Auf der untersten Ebene wird die Kommunikation zwischen Routern durch die Transportschichtsicherheit geschützt. Tunnel -Nachrichten, die über die Transporte übertragen werden, haben ihre eigene mehrschichtige Verschlüsselung. Verschiedene andere Nachrichten werden innerhalb von “garlic messages” übertragen, die ebenfalls verschlüsselt sind.

Garlic Messages

Garlic-Nachrichten sind eine Erweiterung der geschichteten “Zwiebel”-Verschlüsselung, die es ermöglicht, dass der Inhalt einer einzelnen Nachricht mehrere “Gewürznelken” (cloves) enthalten kann — vollständig geformte Nachrichten zusammen mit ihren eigenen Anweisungen zur Zustellung. Nachrichten werden in eine garlic-Nachricht eingepackt, wenn die Nachricht andernfalls im Klartext durch einen Peer geleitet würde, der keinen Zugang zu den Informationen haben sollte — zum Beispiel, wenn ein router einen anderen router bitten möchte, an einem tunnel teilzunehmen, packen sie die Anfrage in eine garlic-Nachricht ein, verschlüsseln diese garlic mit dem öffentlichen Schlüssel des empfangenden routers und leiten sie durch einen tunnel weiter. Ein weiteres Beispiel ist, wenn ein Client eine Nachricht an ein Ziel senden möchte — der router des Senders wird diese Datennachricht (zusammen mit einigen anderen Nachrichten) in eine garlic-Nachricht einpacken, diese garlic mit dem öffentlichen Schlüssel verschlüsseln, der im leaseSet des Empfängers veröffentlicht ist, und sie durch die entsprechenden tunnel weiterleiten.

Die “Anweisungen”, die an jede Knoblauchzehe innerhalb der Verschlüsselungsschicht angehängt sind, beinhalten die Möglichkeit anzufordern, dass die Zehe lokal, an einen entfernten router oder an einen entfernten tunnel auf einem entfernten router weitergeleitet wird. Es gibt Felder in diesen Anweisungen, die es einem Peer ermöglichen anzufordern, dass die Zustellung verzögert wird, bis eine bestimmte Zeit oder Bedingung erfüllt ist, obwohl diese nicht berücksichtigt werden, bis die nichttrivialen Verzögerungen eingesetzt werden. Es ist möglich, garlic-Nachrichten explizit über eine beliebige Anzahl von Hops zu routen, ohne tunnels zu bauen, oder sogar tunnel-Nachrichten umzuleiten, indem man sie in garlic-Nachrichten einpackt und sie eine Anzahl von Hops weiterleitet, bevor man sie an den nächsten Hop im tunnel zustellt, aber diese Techniken werden derzeit in der bestehenden Implementierung nicht verwendet.

Session Tags

Als unzuverlässiges, ungeordnetes, nachrichtenbasiertes System verwendet I2P eine einfache Kombination aus asymmetrischen und symmetrischen Verschlüsselungsalgorithmen, um Datenvertraulichkeit und -integrität für garlic messages zu gewährleisten. Die ursprüngliche Kombination wurde als ElGamal/AES+SessionTags bezeichnet, aber das ist eine übermäßig ausführliche Art, die einfache Verwendung von 2048bit ElGamal, AES256, SHA256 und 32-Byte-Nonces zu beschreiben. Obwohl dieses Protokoll noch unterstützt wird, ist der größte Teil des Netzwerks zu einem neuen Protokoll migriert: ECIES-X25519-AEAD-Ratchet. Dieses Protokoll kombiniert X25519, ChaCha20/Poly1305 und einen synchronisierten PRNG zur Generierung der 32-Byte-Nonces. Beide Protokolle werden nachfolgend kurz beschrieben.

ElGamal/AES+SessionTags

Wenn ein router zum ersten Mal eine garlic-Nachricht an einen anderen router verschlüsseln möchte, verschlüsselt er das Schlüsselmaterial für einen AES256-Session-Key mit ElGamal und hängt die AES256/CBC-verschlüsselte Nutzlast nach diesem verschlüsselten ElGamal-Block an. Zusätzlich zur verschlüsselten Nutzlast enthält der AES-verschlüsselte Abschnitt die Länge der Nutzlast, den SHA256-Hash der unverschlüsselten Nutzlast sowie eine Anzahl von “session tags” — zufällige 32-Byte-Nonces. Wenn der Sender das nächste Mal eine garlic-Nachricht an einen anderen router verschlüsseln möchte, verschlüsselt er nicht mit ElGamal einen neuen Session-Key, sondern wählt einfach einen der zuvor übermittelten session tags aus und verschlüsselt die Nutzlast wie zuvor mit AES, wobei er den Session-Key verwendet, der mit diesem session tag genutzt wurde, vorangestellt mit dem session tag selbst. Wenn ein router eine garlic-verschlüsselte Nachricht erhält, überprüft er die ersten 32 Bytes, um zu sehen, ob sie mit einem verfügbaren session tag übereinstimmen — wenn ja, entschlüsselt er die Nachricht einfach mit AES, aber wenn nicht, entschlüsselt er den ersten Block mit ElGamal.

Jeder Session-Tag kann nur einmal verwendet werden, um zu verhindern, dass interne Angreifer unnötig verschiedene Nachrichten als zwischen denselben Routern stammend korrelieren können. Der Sender einer ElGamal/AES+SessionTag-verschlüsselten Nachricht wählt, wann und wie viele Tags geliefert werden sollen, und stattet den Empfänger im Voraus mit genügend Tags aus, um eine Reihe von Nachrichten abzudecken. Garlic-Nachrichten können die erfolgreiche Tag-Zustellung erkennen, indem sie eine kleine zusätzliche Nachricht als Clove (eine “Zustellstatus-Nachricht”) bündeln – wenn die Garlic-Nachricht beim vorgesehenen Empfänger ankommt und erfolgreich entschlüsselt wird, ist diese kleine Zustellstatus-Nachricht eine der freigegebenen Cloves und enthält Anweisungen für den Empfänger, die Clove an den ursprünglichen Sender zurückzusenden (natürlich durch einen eingehenden Tunnel). Wenn der ursprüngliche Sender diese Zustellstatus-Nachricht erhält, weiß er, dass die in der Garlic-Nachricht gebündelten Session-Tags erfolgreich zugestellt wurden.

Session tags selbst haben eine sehr kurze Lebensdauer, nach der sie verworfen werden, wenn sie nicht verwendet werden. Zusätzlich ist die für jeden Schlüssel gespeicherte Menge begrenzt, ebenso wie die Anzahl der Schlüssel selbst — wenn zu viele ankommen, können entweder neue oder alte Nachrichten verworfen werden. Der Sender verfolgt, ob Nachrichten mit session tags durchkommen, und wenn nicht ausreichend Kommunikation stattfindet, kann er diejenigen verwerfen, die zuvor als ordnungsgemäß zugestellt angenommen wurden, und zur vollständigen teuren ElGamal-Verschlüsselung zurückkehren.

ECIES-X25519-AEAD-Ratchet

ElGamal/AES+SessionTags erforderte erheblichen Overhead in verschiedener Hinsicht. Die CPU-Nutzung war hoch, da ElGamal ziemlich langsam ist. Die Bandbreite war übermäßig hoch, weil große Mengen von Session-Tags im Voraus übertragen werden mussten und weil ElGamal-Public-Keys sehr groß sind. Der Speicherverbrauch war hoch aufgrund der Anforderung, große Mengen von Session-Tags zu speichern. Die Zuverlässigkeit wurde durch verlorene Session-Tag-Übertragungen beeinträchtigt.

ECIES-X25519-AEAD-Ratchet wurde entwickelt, um diese Probleme zu lösen. X25519 wird für den Schlüsselaustausch verwendet. ChaCha20/Poly1305 wird für die authentifizierte symmetrische Verschlüsselung eingesetzt. Verschlüsselungsschlüssel werden “doppelt geratchet” oder regelmäßig rotiert. Session-Tags werden von 32 Bytes auf 8 Bytes reduziert und mit einem PRNG generiert. Das Protokoll weist viele Ähnlichkeiten mit dem Signal-Protokoll auf, das in Signal und WhatsApp verwendet wird. Dieses Protokoll bietet einen erheblich geringeren Overhead bei CPU, RAM und Bandbreite.

Die Session-Tags werden von einem deterministischen synchronisierten PRNG generiert, der an beiden Enden der Session läuft, um Session-Tags und Session-Schlüssel zu erzeugen. Der PRNG ist ein HKDF mit SHA-256 HMAC und wird mit dem Ergebnis des X25519 DH-Verfahrens initialisiert. Session-Tags werden niemals im Voraus übertragen; sie sind nur in der Nachricht enthalten. Der Empfänger speichert eine begrenzte Anzahl von Session-Schlüsseln, indexiert nach Session-Tag. Der Sender muss keine Session-Tags oder Schlüssel speichern, da sie nicht im Voraus gesendet werden; sie können bei Bedarf generiert werden. Durch die ungefähre Synchronisation dieses PRNG zwischen Sender und Empfänger (der Empfänger berechnet ein Fenster der nächsten z.B. 50 Tags im Voraus) wird der Overhead des periodischen Bündelns einer großen Anzahl von Tags eliminiert.

Zukunft

I2Ps Protokolle sind auf den meisten Plattformen, einschließlich Mobiltelefonen, effizient und für die meisten Bedrohungsmodelle sicher. Es gibt jedoch mehrere Bereiche, die weitere Verbesserungen erfordern, um den Bedürfnissen derjenigen gerecht zu werden, die mächtigen staatlich geförderten Gegnern gegenüberstehen, und um den Bedrohungen durch kontinuierliche kryptographische Fortschritte und ständig steigende Rechenleistung zu begegnen. Zwei mögliche Funktionen, restricted routes und variable latency, wurden von jrandom im Jahr 2003 vorgeschlagen. Obwohl wir nicht mehr planen, diese Funktionen zu implementieren, werden sie unten beschrieben.

Eingeschränkter Routenbetrieb

I2P ist ein Overlay-Netzwerk, das darauf ausgelegt ist, auf einem funktionsfähigen paketvermittelten Netzwerk zu laufen und das End-to-End-Prinzip zu nutzen, um Anonymität und Sicherheit zu bieten. Während das Internet das End-to-End-Prinzip nicht mehr vollständig umsetzt (aufgrund der Verwendung von NAT), benötigt I2P einen erheblichen Teil des Netzwerks, der erreichbar ist — es kann eine Anzahl von Peers an den Rändern geben, die mit eingeschränkten Routen laufen, aber I2P enthält keinen geeigneten Routing-Algorithmus für den degenerierten Fall, in dem die meisten Peers nicht erreichbar sind. Es würde jedoch auf einem Netzwerk funktionieren, das einen solchen Algorithmus verwendet.

Der Betrieb mit eingeschränkten Routen, bei dem es Beschränkungen gibt, welche Peers direkt erreichbar sind, hat verschiedene funktionale und anonymitätsbezogene Auswirkungen, abhängig davon, wie die eingeschränkten Routen behandelt werden. Auf grundlegendster Ebene existieren eingeschränkte Routen, wenn sich ein Peer hinter einem NAT oder einer Firewall befindet, die keine eingehenden Verbindungen zulässt. Dies wurde größtenteils durch die Integration von verteiltem Hole Punching in die Transportschicht gelöst, wodurch Personen hinter den meisten NATs und Firewalls unaufgeforderte Verbindungen empfangen können, ohne dass eine Konfiguration erforderlich ist. Dies schränkt jedoch nicht die Preisgabe der IP-Adresse des Peers an router innerhalb des Netzwerks ein, da sie einfach über den veröffentlichten introducer mit dem Peer bekannt gemacht werden können.

Über die funktionale Behandlung von eingeschränkten Routen hinaus gibt es zwei Ebenen des eingeschränkten Betriebs, die verwendet werden können, um die Preisgabe der eigenen IP-Adresse zu begrenzen — die Verwendung router-spezifischer tunnel für die Kommunikation und das Anbieten von ‘Client-Routern’. Für ersteres können router entweder einen neuen Pool von tunnels erstellen oder ihren explorativen Pool wiederverwenden, wobei sie die eingehenden Gateways zu einigen von ihnen als Teil ihrer routerInfo anstelle ihrer Transport-Adressen veröffentlichen. Wenn ein Peer mit ihnen in Kontakt treten möchte, sieht er diese tunnel-Gateways in der netDb und sendet die relevante Nachricht einfach über einen der veröffentlichten tunnel an sie. Wenn der Peer hinter der eingeschränkten Route antworten möchte, kann er dies entweder direkt tun (wenn er bereit ist, seine IP dem Peer preiszugeben) oder indirekt über seine ausgehenden tunnel. Wenn die router, zu denen der Peer direkte Verbindungen hat, ihn erreichen wollen (um tunnel-Nachrichten weiterzuleiten, zum Beispiel), priorisieren sie einfach ihre direkte Verbindung über das veröffentlichte tunnel-Gateway. Das Konzept der ‘Client-router’ erweitert die eingeschränkte Route einfach, indem keine router-Adressen veröffentlicht werden. Ein solcher router müsste nicht einmal seine routerInfo in der netDb veröffentlichen, sondern lediglich seine selbstsignierte routerInfo den Peers zur Verfügung stellen, die er kontaktiert (notwendig, um die öffentlichen Schlüssel des routers zu übertragen).

Es gibt Kompromisse für diejenigen hinter eingeschränkten Routen, da sie wahrscheinlich seltener an den tunnels anderer Personen teilnehmen würden, und die router, mit denen sie verbunden sind, könnten Verkehrsmuster ableiten, die andernfalls nicht preisgegeben würden. Andererseits, wenn die Kosten dieser Preisgabe geringer sind als die Kosten einer verfügbar gemachten IP, könnte es sich lohnen. Dies setzt natürlich voraus, dass die Peers, die der router hinter einer eingeschränkten Route kontaktiert, nicht feindselig sind — entweder das Netzwerk ist groß genug, dass die Wahrscheinlichkeit, einen feindseligen Peer für die Verbindung zu verwenden, klein genug ist, oder vertrauenswürdige (und vielleicht temporäre) Peers werden stattdessen verwendet.

Restricted routes sind komplex, und das übergeordnete Ziel wurde weitgehend aufgegeben. Mehrere verwandte Verbesserungen haben den Bedarf dafür stark reduziert. Wir unterstützen jetzt UPnP, um Firewall-Ports automatisch zu öffnen. Wir unterstützen sowohl IPv4 als auch IPv6. SSU2 verbesserte die Adresserkennung, die Bestimmung des Firewall-Status und das kooperative NAT-Hole-Punching. SSU2, NTCP2 und Adresskompatibilitätsprüfungen stellen sicher, dass tunnel-Hops eine Verbindung herstellen können, bevor der tunnel aufgebaut wird. GeoIP und Länderidentifikation ermöglichen es uns, Peers in Ländern mit restriktiven Firewalls zu vermeiden. Die Unterstützung für “versteckte” router hinter diesen Firewalls wurde verbessert. Einige Implementierungen unterstützen auch Verbindungen zu Peers in Overlay-Netzwerken wie Yggdrasil.

Variable Latenz

Obwohl sich I2Ps anfängliche Bemühungen hauptsächlich auf die Kommunikation mit niedriger Latenz konzentrierten, wurde es von Anfang an mit Diensten variabler Latenz im Hinterkopf entwickelt. Auf der grundlegendsten Ebene können Anwendungen, die auf I2P laufen, die Anonymität der Kommunikation mit mittlerer und hoher Latenz bieten, während sie ihre Verkehrsmuster dennoch mit dem Verkehr niedriger Latenz vermischen. Intern kann I2P jedoch seine eigene Kommunikation mit mittlerer und hoher Latenz durch die garlic encryption anbieten — indem spezifiziert wird, dass die Nachricht nach einer bestimmten Verzögerung, zu einem bestimmten Zeitpunkt, nach einer bestimmten Anzahl von Nachrichten oder einer anderen Mix-Strategie gesendet werden soll. Mit der mehrschichtigen Verschlüsselung würde nur der router, dem die Clove die Verzögerungsanfrage preisgab, wissen, dass die Nachricht eine hohe Latenz erfordert, wodurch sich der Verkehr weiter mit dem Verkehr niedriger Latenz vermischen kann. Sobald die Übertragungsvoraussetzung erfüllt ist, leitet der router, der die Clove festhält (die selbst wahrscheinlich eine garlic-Nachricht wäre), sie einfach wie angefordert weiter — an einen router, an einen tunnel oder, sehr wahrscheinlich, an ein entferntes Client-Ziel.

Das Ziel von Services mit variabler Latenz erfordert erhebliche Ressourcen für Store-and-Forward-Mechanismen, um diese zu unterstützen. Diese Mechanismen können und werden in verschiedenen Messaging-Anwendungen unterstützt, wie beispielsweise i2p-bote. Auf Netzwerkebene bieten alternative Netzwerke wie Freenet diese Services. Wir haben entschieden, dieses Ziel auf I2P router-Ebene nicht zu verfolgen.

Anhang A: Anwendungsschicht

I2P selbst macht nicht wirklich viel — es sendet einfach Nachrichten an entfernte Ziele und empfängt Nachrichten, die an lokale Ziele gerichtet sind — die meiste interessante Arbeit findet in den darüber liegenden Schichten statt. Für sich genommen könnte I2P als anonyme und sichere IP-Schicht betrachtet werden, und die mitgelieferte streaming library als Implementierung einer anonymen und sicheren TCP-Schicht darüber. Darüber hinaus stellt I2PTunnel ein generisches TCP-Proxy-System zur Verfügung, um entweder in das I2P-Netzwerk hinein oder aus ihm heraus zu gelangen, plus eine Vielzahl von Netzwerkanwendungen, die weitere Funktionalitäten für Endbenutzer bereitstellen.

Streaming-Bibliothek

Die I2P-Streaming-Bibliothek kann als generische Streaming-Schnittstelle betrachtet werden (ähnlich TCP-Sockets), und die Implementierung unterstützt ein Sliding Window Protocol mit mehreren Optimierungen, um die hohe Latenz über I2P zu berücksichtigen. Einzelne Streams können die maximale Paketgröße und andere Optionen anpassen, obwohl die Standardeinstellung von 4KB komprimiert ein vernünftiger Kompromiss zwischen den Bandbreitenkosten für die Neuübertragung verlorener Nachrichten und der Latenz mehrerer Nachrichten zu sein scheint.

Darüber hinaus wurde das Protokoll der Streaming-Bibliothek für die Planung und Übertragung von Nachrichten unter Berücksichtigung der relativ hohen Kosten nachfolgender Nachrichten optimiert, um zu ermöglichen, dass einzelne übertragene Nachrichten so viele Informationen wie verfügbar enthalten können. Beispielsweise kann eine kleine HTTP-Transaktion, die über die Streaming-Bibliothek weitergeleitet wird, in einem einzigen Roundtrip abgeschlossen werden — die erste Nachricht bündelt SYN, FIN und die kleine Nutzlast (eine HTTP-Anfrage passt typischerweise hinein) und die Antwort bündelt SYN, FIN, ACK und die kleine Nutzlast (viele HTTP-Antworten passen hinein). Während eine zusätzliche ACK übertragen werden muss, um dem HTTP-Server mitzuteilen, dass das SYN/FIN/ACK empfangen wurde, kann der lokale HTTP-Proxy die vollständige Antwort sofort an den Browser weiterleiten.

Im Großen und Ganzen ähnelt die Streaming-Bibliothek jedoch stark einer TCP-Abstraktion mit ihren Sliding Windows, Congestion-Control-Algorithmen (sowohl Slow Start als auch Congestion Avoidance) und dem allgemeinen Paketverhalten (ACK, SYN, FIN, RST, usw.).

Namens-Bibliothek und Adressbuch

Für weitere Informationen siehe die Seite Naming and Address Book .

Entwickelt von: mihi, Ragnarok

Die Namensgebung innerhalb von I2P ist seit den Anfängen ein viel diskutiertes Thema mit Befürwortern aus dem gesamten Spektrum der Möglichkeiten. Angesichts von I2Ps inhärentem Bedarf nach sicherer Kommunikation und dezentralisiertem Betrieb scheiden jedoch das traditionelle DNS-artige Namensystem sowie Abstimmungssysteme nach dem Prinzip “Die Mehrheit entscheidet” klar aus. Stattdessen wird I2P mit einer generischen Namensgebungsbibliothek und einer Grundimplementierung ausgeliefert, die darauf ausgelegt ist, mit einer lokalen Zuordnung von Namen zu Zielen zu arbeiten, sowie einer optionalen Zusatzanwendung namens “Address Book” (Adressbuch). Das Adressbuch ist ein web-of-trust-basiertes sicheres, verteiltes und menschenlesbares Namensystem, das nur die Forderung nach globaler Eindeutigkeit aller menschenlesbaren Namen opfert, indem es nur lokale Eindeutigkeit vorschreibt. Während alle Nachrichten in I2P kryptographisch über ihr Ziel adressiert werden, können verschiedene Personen lokale Adressbucheinträge für “Alice” haben, die sich auf unterschiedliche Ziele beziehen. Menschen können dennoch neue Namen entdecken, indem sie veröffentlichte Adressbücher von Peers importieren, die in ihrem web of trust spezifiziert sind, indem sie Einträge hinzufügen, die über Dritte bereitgestellt werden, oder (falls einige Leute eine Reihe von veröffentlichten Adressbüchern mit einem “Wer zuerst kommt, mahlt zuerst”-Registrierungssystem organisieren) können Menschen wählen, diese Adressbücher als Nameserver zu behandeln und damit traditionelles DNS zu emulieren.

I2P befürwortet jedoch nicht die Verwendung von DNS-ähnlichen Diensten, da der durch die Übernahme einer Website verursachte Schaden enorm sein kann — und unsichere Ziele haben keinen Wert. DNSsec selbst greift immer noch auf Registrare und Zertifizierungsstellen zurück, während bei I2P Anfragen, die an ein Ziel gesendet werden, weder abgefangen noch die Antwort gefälscht werden können, da sie mit den öffentlichen Schlüsseln des Ziels verschlüsselt sind, und ein Ziel selbst nur ein Paar aus öffentlichen Schlüsseln und einem Zertifikat ist. DNS-ähnliche Systeme hingegen ermöglichen es jedem der Nameserver im Suchpfad, einfache Denial-of-Service- und Spoofing-Angriffe durchzuführen. Das Hinzufügen eines Zertifikats, das die Antworten als von einer zentralisierten Zertifizierungsstelle signiert authentifiziert, würde viele der Probleme mit feindlichen Nameservern beheben, aber Replay-Angriffe sowie Angriffe von feindlichen Zertifizierungsstellen weiterhin ermöglichen.

Abstimmungsbasierte Namensgebung ist ebenfalls gefährlich, insbesondere angesichts der Wirksamkeit von Sybil-Angriffen in anonymen Systemen — der Angreifer kann einfach eine beliebig hohe Anzahl von Peers erstellen und mit jedem “abstimmen”, um einen bestimmten Namen zu übernehmen. Proof-of-Work-Methoden können verwendet werden, um Identitäten nicht-kostenlos zu machen, aber wenn das Netzwerk wächst, ist die Last, die erforderlich ist, um alle zu kontaktieren und Online-Abstimmungen durchzuführen, nicht praktikabel, oder wenn das gesamte Netzwerk nicht abgefragt wird, können verschiedene Sets von Antworten erreichbar sein.

Wie beim Internet hält I2P jedoch das Design und den Betrieb eines Namensystems aus der (IP-ähnlichen) Kommunikationsschicht heraus. Die mitgelieferte Naming-Bibliothek enthält eine einfache Service Provider Interface, in die alternative Namensysteme eingesteckt werden können, wodurch Endbenutzer bestimmen können, welche Art von Naming-Kompromissen sie bevorzugen.

I2PTunnel

Entwickelt von: mihi

I2PTunnel ist wahrscheinlich I2Ps beliebteste und vielseitigste Client-Anwendung, die generisches Proxying sowohl in das als auch aus dem I2P-Netzwerk ermöglicht. I2PTunnel kann als vier separate Proxy-Anwendungen betrachtet werden — ein “client”, der eingehende TCP-Verbindungen empfängt und sie an ein bestimmtes I2P-Ziel weiterleitet, ein “httpclient” (auch “eepproxy” genannt), der wie ein HTTP-Proxy fungiert und die Anfragen an das entsprechende I2P-Ziel weiterleitet (nach Abfrage des Namensdienstes falls nötig), ein “server”, der eingehende I2P-Streaming-Verbindungen an einem Ziel empfängt und sie an einen bestimmten TCP-Host+Port weiterleitet, und einen “httpserver”, der den “server” erweitert, indem er HTTP-Anfragen und -Antworten analysiert, um einen sichereren Betrieb zu ermöglichen. Es gibt eine zusätzliche “socksclient”-Anwendung, aber deren Verwendung wird aus den zuvor erwähnten Gründen nicht empfohlen.

I2P selbst ist kein Outproxy-Netzwerk — die Anonymitäts- und Sicherheitsbedenken, die einem Mix-Netzwerk innewohnen, das Daten in das Mix-Netz hinein und aus ihm heraus weiterleitet, haben dazu geführt, dass sich I2Ps Design darauf konzentriert, ein anonymes Netzwerk bereitzustellen, das die Bedürfnisse der Benutzer erfüllen kann, ohne externe Ressourcen zu benötigen. Die I2PTunnel “httpclient”-Anwendung bietet jedoch eine Schnittstelle für Outproxying — wenn der angeforderte Hostname nicht auf “.i2p” endet, wählt sie ein zufälliges Ziel aus einer vom Benutzer bereitgestellten Sammlung von Outproxies aus und leitet die Anfrage an diese weiter. Diese Ziele sind einfach I2PTunnel “server”-Instanzen, die von Freiwilligen betrieben werden, die sich explizit dafür entschieden haben, Outproxies zu betreiben — niemand ist standardmäßig ein Outproxy, und das Betreiben eines Outproxies teilt anderen Leuten nicht automatisch mit, dass sie durch Sie proxyen sollen. Obwohl Outproxies inhärente Schwächen haben, bieten sie einen einfachen Machbarkeitsnachweis für die Verwendung von I2P und stellen einige Funktionalitäten unter einem Bedrohungsmodell bereit, das für manche Benutzer ausreichend sein kann.

I2PTunnel ermöglicht die meisten verwendeten Anwendungen. Ein “httpserver”, der auf einen Webserver zeigt, ermöglicht es jedem, seine eigene anonyme Website (oder “I2P Site”) zu betreiben — ein Webserver ist zu diesem Zweck in I2P enthalten, aber jeder Webserver kann verwendet werden. Jeder kann einen “client” betreiben, der auf einen der anonym gehosteten IRC-Server zeigt, von denen jeder einen “server” betreibt, der auf seinen lokalen IRCd zeigt und zwischen IRCds über ihre eigenen “client” tunnel kommuniziert. Endbenutzer haben auch “client” tunnel, die auf I2Pmail’s POP3- und SMTP-Ziele zeigen (die wiederum einfach “server”-Instanzen sind, die auf POP3- und SMTP-Server zeigen), sowie “client” tunnel, die auf I2Ps CVS-Server zeigen und anonyme Entwicklung ermöglichen. Manchmal haben Leute sogar “client”-Proxies betrieben, um auf die “server”-Instanzen zuzugreifen, die auf einen NNTP-Server zeigen.

I2PSnark

I2PSnark entwickelt von: jrandom, et al, portiert von mjw ’s Snark Client

Im Lieferumfang der I2P-Installation enthalten, bietet I2PSnark einen einfachen anonymen BitTorrent-Client mit Multitorrent-Funktionen, der alle Funktionalitäten über eine einfache HTML-Weboberfläche bereitstellt.

I2Pmail / Susimail

Entwickelt von: postman, susi23, mastiejaner

I2Pmail ist eher ein Dienst als eine Anwendung — postman bietet sowohl interne als auch externe E-Mails mit POP3- und SMTP-Service durch I2PTunnel-Instanzen, die auf eine Reihe von Komponenten zugreifen, die mit mastiejaner entwickelt wurden, und ermöglicht es Menschen, ihre bevorzugten E-Mail-Clients zu verwenden, um pseudonym E-Mails zu senden und zu empfangen. Da jedoch die meisten E-Mail-Clients erhebliche identifizierende Informationen preisgeben, bündelt I2P den webbasierten susimail-Client von susi23, der speziell mit Blick auf I2Ps Anonymitätsbedürfnisse entwickelt wurde. Der I2Pmail/mail.i2p-Service bietet transparente Virusfilterung sowie Denial-of-Service-Prävention mit hashcash-erweiterten Quoten. Zusätzlich hat jeder Benutzer die Kontrolle über seine Batch-Strategie vor der Zustellung durch die mail.i2p-Outproxies, die von den mail.i2p-SMTP- und POP3-Servern getrennt sind — sowohl die Outproxies als auch die Inproxies kommunizieren mit den mail.i2p-SMTP- und POP3-Servern über I2P selbst, sodass eine Kompromittierung dieser nicht-anonymen Standorte keinen Zugang zu den E-Mail-Konten oder Aktivitätsmustern des Benutzers gewährt.

Einführung