Anmerkung des Autors: Die in diesem Artikel genannten Angriffe sind gegen aktuelle Versionen von I2P nicht möglich.

Als selbstorganisierendes Peer-to-Peer-Netzwerk ist I2P darauf angewiesen, dass die am Netzwerk teilnehmenden Router eine Möglichkeit haben, Informationen darüber auszutauschen, was sich im Netzwerk befindet und wie es erreichbar ist. I2P-Router realisieren diesen Informationsaustausch über die NetDB, eine auf Kademlia basierende DHT (verteilte Hashtabelle), die für den Einsatz in I2P angepasst wurde. Die NetDB muss zwei Hauptarten von Einträgen verteilen: „RouterInfos“, die Peers verwenden, um direkt mit anderen Routern zu kommunizieren, und „LeaseSets“, die andere Peers verwenden, um über anonyme Tunnel mit I2P-Clients zu kommunizieren. Router tauschen häufig NetDB-Einträge untereinander aus, entweder indem sie Informationen an einen Router oder einen Client senden oder indem sie Informationen von einem Router oder einem Client anfordern. Das bedeutet, dass die Einträge direkt oder indirekt, anonym oder nicht anonym eingehen können – je nach den Bedürfnissen des Netzwerks und den Fähigkeiten des Clients. Als anonymisierendes Netzwerk ist es jedoch ebenso wichtig, dass es unmöglich bleibt, anonym gesendete Informationen nicht-anonym wieder abzurufen. Ebenso muss es unmöglich sein, nicht-anonym gesendete Informationen anonym abzurufen. Wenn eine dieser Situationen möglich wird, kann ein Verknüpfungsangriff durchgeführt werden, der es einem Angreifer erlaubt festzustellen, ob ein Client und ein Router eine gemeinsame Sicht auf die NetDB teilen. Lässt sich zuverlässig feststellen, dass die beiden Ziele eine gemeinsame Sicht auf die NetDB teilen, ist die Wahrscheinlichkeit groß, dass sie sich auf demselben Router befinden, was die Anonymität des Ziels drastisch schwächt. Da es nur wenige anonymisierende Netzwerke gibt und I2P das einzige ist, bei dem die Routing-Tabelle über den Betrieb einer DHT verteilt wird, ist diese Klasse von Angriffen nahezu einzigartig für I2P, und ihre Lösung ist entscheidend für den Erfolg von I2P.

Betrachten Sie das folgende Szenario: Es gibt einen I2P-Router, auf dem ein I2P-Client läuft. Der Router veröffentlicht eine RouterInfo, und der I2P-Client veröffentlicht sein LeaseSet. Da beide in der NetDB veröffentlicht sind, können andere I2P-Router die NetDB abfragen, um herauszufinden, wie sie mit ihnen kommunizieren können. Das ist normal und wesentlich für den Betrieb eines Overlay-Netzwerks der von I2P implementierten Art. Ein Angreifer betreibt einen I2P-Router und fragt die NetDB nach der Ziel-RouterInfo und dem Ziel-LeaseSet ab. Anschließend erstellt er ein neues LeaseSet, das eindeutig und möglicherweise sogar gefälscht ist, und sendet es durch einen tunnel an das LeaseSet des Clients, den er angreifen will. Der Client verarbeitet das präparierte LeaseSet und fügt es seiner eigenen NetDB hinzu. Der Angreifer fordert anschließend das präparierte LeaseSet direkt beim Router an, unter Verwendung der RouterInfo, die er aus der NetDB erhalten hat. Wenn das präparierte LeaseSet als Antwort zurückkommt, kann der Angreifer daraus schließen, dass der Ziel-Client und der Ziel-Router eine gemeinsame Sicht auf die NetDB haben.

Das ist ein einfaches Beispiel für eine Klasse von NetDB-Deanonymisierungsangriffen, die darauf beruht, mit einer Identität einen Eintrag in die NetDB einer anderen Person hinzuzufügen und ihn anschließend mit einer anderen Identität wieder abzurufen. In diesem Fall sind die betreffenden Identitäten die “router”- und die “client”-Identität. Allerdings ist in einigen Designs auch eine Client-zu-Client-Verknüpfung möglich, die weniger schädlich ist. Eine Verteidigung gegen diese Klasse von Angriffen zu entwerfen, erfordert, dem router eine Möglichkeit zu geben, festzustellen, ob es sicher ist, eine Information an eine potenzielle Identität zu übermitteln.

Wie sollten wir also über dieses Problem nachdenken? Worum es hier im Kern geht, hat mit der Verknüpfbarkeit verschiedener “Identitäten” im Netzwerk zu tun. Die Möglichkeit der Verknüpfung entsteht, weil all diese Identitäten eine gemeinsame Datenstruktur teilen, die sich “merkt”, mit wem sie kommuniziert hat und wer mit ihr kommuniziert hat. Sie “merkt” sich außerdem, wie diese Kommunikation stattgefunden hat.

Stellen wir uns für einen Moment als Angreifer vor. Stellen Sie sich vor, Sie wollten die Identität eines Meisters der Verkleidung herausfinden. Sie wissen mit Sicherheit, dass Sie sein echtes Gesicht gesehen haben, und Sie wissen mit Sicherheit, dass Sie regelmäßig mit einer seiner Tarnidentitäten kommunizieren. Wie würden Sie nachweisen, dass die Tarnidentität und die echte Identität zu derselben Person gehören? Ich könnte der verkleideten Person ein Geheimnis verraten. Wenn die nicht verkleidete Person reagiert, indem sie die geheimen Informationen verwendet, kann ich feststellen, dass die nicht verkleidete Person das Geheimnis kennt. Unter der Annahme, dass die verkleidete Person das Geheimnis niemand anderem mitgeteilt hat, kann ich davon ausgehen, dass die nicht verkleidete Person und die verkleidete Person tatsächlich ein und dieselbe Person sind. Ganz gleich, wie viele Masken der Meister der Verkleidung trägt, er hat doch nur einen einzigen Geist.

Um die Identitäten von I2P-Clients erfolgreich zu schützen, muss I2P als ein besserer Meister der Tarnung agieren können als der oben beschriebene. Es muss sich “erinnern” können an mehrere wichtige Informationen darüber, wie es an der NetDB beteiligt war, und basierend auf diesen Details angemessen reagieren. Es muss sich erinnern können:

  • Whether a NetDB Entry was received directly, or received down a client tunnel
  • Whether a NetDB Entry was sent by a peer in response to our lookup, or sent unsolicited
  • Which NetDB Entry was received down Which client Tunnel
  • Multiple versions of the same entry for different client tunnels

Strukturell ist der verständlichste und zuverlässigste Weg, mit diesem Muster umzugehen, die Verwendung von “Sub-DBs” (untergeordnete Datenbanken). Sub-DBs sind Miniatur-NetDBs, die die NetDB dabei unterstützen, Einträge zu organisieren, ohne den Überblick zu verlieren. Jeder Client erhält eine Sub-DB zur eigenen Nutzung, und der router selbst erhält eine vollwertige NetDB. Mithilfe von Sub-DBs geben wir unserem Meister der Tarnung ein Rolodex von Geheimnissen, geordnet nach denjenigen, die diese Geheimnisse mit ihm geteilt haben. Wenn eine Anfrage an einen Client gesendet wird, werden nur Einträge gesucht, die dem Client übermittelt wurden, und wenn eine Anfrage an einen router gesendet wird, wird nur die router-weite NetDB verwendet. Auf diese Weise beheben wir nicht nur die einfachste Form des Angriffs, sondern untergraben auch die Wirksamkeit der gesamten Angriffsklasse.