Wir setzen unsere Reihe von Interviews im I2P Universum fort (frühere Interviews hier und hier). Heute präsentieren wir auf diva.exchange einen einzigartigen Gast, einen talentierten Programmierer und einen der aktivsten Teilnehmer der I2P-Community – idk. Mit idk werden wir über die jüngsten Angriffe auf die I2P-Infrastruktur, die neuesten Innovationen im Netzwerk, MoneroKon und natürlich philosophische Fragen sprechen.

DIVA: Idk, um dich unseren Lesern vorstellen, was sind deine Aufgaben?

idk: Ich glaube, dass ich derzeit ein halbes Dutzend oder so Jobs auf der I2P-Website aufgelistet habe, die ich für I2P mache. Momentan ist meine grösste Arbeit wahrscheinlich als Release-Maintainer. Ich arbeite auch am Java-Kerncode und einigen der Client-Bibliotheken. Im Grunde genommen alles in der „Go-Sprache“ und ich pflege den Android-Zweig, schreibe einige der Nachrichten, aktualisiere die Website, alle möglichen Dinge.

DIVA: Ich möchte mit einer schwierigen, aber wichtigen Frage beginnen. Vor nicht allzu langer Zeit wurde das I2P-Netzwerk angegriffen. Bitte erzähle uns mehr darüber. Waren es Konkurrenten, Hobbyhacker oder jemand anders?

idk: Nun, es gibt wahrscheinlich mehr als eine Gruppe. Es gab zumindest ein sehr talentiertes „Skriptkiddy“. Es gab mindestens einen Angriff, der von einer relativ kleinen Anzahl von Routern aus durchgeführt werden konnte. Das deutet darauf hin, dass es zumindest einige Angriffe mit relativ geringem Aufwand an Fähigkeiten und Ressourcen gab, gegen die wir auf verschiedene Weise vorgegangen sind und die wir auch weiterhin besser bekämpfen wollen.

Ein sehr interessanter Angriff war der „Klon-Angriff“, der I2Pd ein wenig schlimmer traf als Java I2P, da es Unterschiede in der Art und Weise gibt, wie wir bestehende Router profilieren. Grundsätzlich funktioniert der Klon-Angriff so, dass ein Angreifer eine legitim aussehende RouterInfo für einen nicht existierenden Router generiert, der auf dem gleichen Host und der gleichen IP-Adresse wie ein tatsächlich existierender Router ist, und diese dann an den DHT sendet, so dass die Leute verwirrt sind, welcher Router auf welcher IP-Adresse zu verwenden ist. Um dies zu erreichen, musst du lediglich eine RouterInfo generieren, so wie du es tun würdest, wenn du dem Netzwerk neu beitreten würdest. In diesem speziellen Fall muss ein Angreifer also nicht unbedingt über grosse Ressourcen verfügen, um einfach etwas an den DHT zu senden, er braucht nur einen gehackten Router, um diese gefälschten RouterInfos zu erzeugen.

Das war also ein ziemlich kritischer Punkt, gegen den wir uns wehren mussten, weil er dazu benutzt wurde, das Netzwerk wirklich zu verwirren und den Erfolg beim Tunnelbau ausserordentlich zu verringern. Dann haben wir eine Reihe von Dingen implementiert, die es im Grunde einfacher machen, diese Klone zu erkennen, und die es einfacher machen, diese Klone früher zu erkennen, weil es keine gute Möglichkeit gibt, jemanden daran zu hindern, RouterInfos zu generieren, die so aussehen, als wären sie an denselben IP-Adressen wie jemand anderes, weil es ein anonymes Netzwerk ist. Wir wollen, dass jeder ohne Zugangsbarriere mitmachen kann.  Wenn jeder seine eigene IP-Adresse haben muss, dann wird das zu einer Zugangsbarriere, und wir müssen einen Weg finden, zwischen diesen beiden Zielpfosten zu navigieren.

Es gibt aber auch noch andere Arten von Angriffen, wie z. B. Botnets, die eine grosse Anzahl von Routern betreiben, die sich manchmal auf seltsame Weise am Netzwerk beteiligen. Insbesondere fordern sie über einige wenige Tunnel eine extrem hohe Anzahl von Ressourcen an, was dazu führt, dass die verfügbaren Ressourcen knapp werden, was dann wiederum dazu führt, dass dem Netzwerk im Gesamten weniger Ressourcen zum Aufbau von Tunneln zur Verfügung stehen.

Beides sind die grossen Angriffe, die in letzter Zeit stattgefunden haben, und beide haben zur Folge, dass die Metrik, die wir für den Erfolg des Aufbaus von Erkundungstunneln verwenden, sinkt. Erkundungstunnel werden verwendet, um Informationen über die Sicht auf den DHT zu sammeln, damit man Router hat, mit denen man Tunnel bauen kann. Und wenn man keine Erkundungstunnel bauen kann, kann man die DHT nicht erkunden und nicht am Netzwerk teilnehmen. Das wird zu einem ziemlich grossen Problem.

Glücklicherweise ist die Tunnelaufbau-Erfolgsrate nie auf Null gesunken. Es ging ein paar Mal Richtung 10%. Aber sie ist nie auf Null gesunken, so dass das Netzwerk nie wirklich zusammengebrochen ist. Momentan, mal sehen, schwankt die Rate zwischen 40% und 70%, das ist ziemlich gut.

DIVA: Hat das I2P-Netzwerk diesen Stresstest bestanden? Haben die Entwickler aus dieser Situation eine Lehre gezogen? Was denken Sie?

idk: Aus einigen der früheren Angriffe habe ich gelernt, proaktiver zu werden, was die Architektur angeht.

Insbesondere die Frage, was auf welchem Weg in die DHT eingeht und was sie verlässt, wurde für mich im letzten Jahr zu einem ziemlich grossen Thema. Etwa sechs Monate lang war es meine „raison d’etre“, zu überprüfen, was zu einem bestimmten Zeitpunkt in die DHT ein- und aus ihr herausging. Eine wichtige Erkenntnis für mich war, dass wir proaktiver sein müssen, wenn es darum geht, den Status zwischen verschiedenen Bereichen des Routers und verschiedenen Teilen der Clients zu trennen und einzuschränken, was Clients im Verhältnis zu dem, was der gesamte Router sehen kann, sehen können. Eine wichtige Erkenntnis war also, dass wir Wege finden müssen, um proaktiv mit diesen Abwehrmassnahmen und Angriffsklassen umzugehen, wenn sie erkannt werden.

DIVA: Haben die Angriffe dir geholfen, Schwachstellen im Netzwerk zu finden?

idk: Oh, ja. Das hat er in der Tat. Ein gutes Beispiel für die unerwarteten Auswirkungen des Angriffs auf das Sybil-Subsystem war, dass der Angriff eine Schwachstelle aufdeckte. Und wir haben dieses probabilistische Werkzeug zur Erkennung von Sybil-Angriffen. Es nimmt im Wesentlichen Merkmale aus den von den Routern gesendeten Informationen und wandelt sie in eine Punktzahl um, mit der man im Grunde einschätzen kann, ob es wahrscheinlich ist, dass es sich um eine Gruppe handelt, die gemeinsam versucht, einen Tunnel zu übernehmen. Dies ist wahrscheinlich ziemlich effektiv, um diese Art von Angriff (Tunnelübernahme) zu erkennen. Bei dem Klon-Angriff gab es jedoch das Problem, dass das Sybil-Attack-Tool all diese geklonten, gefälschten Router identifizierte, die die gleiche IP-Adresse wie andere echte Router hatten.

Zur Information: Sybil-Angriffe sind eine Art von Angriffen auf Peer-to-Peer-Netzwerke, bei denen ein Angreifer eine grosse Anzahl von Peers erstellt, um einen grösseren Anteil an den Ressourcen des Netzwerks zu kontrollieren. In anonymen Netzwerken wie I2P wird dies genutzt, um eine „Übernahme“ von Peers in der Netzwerkroute eines anonymen Benutzers durchzuführen.

Wir hatten also eine Situation, in der das Sybil-Attack-Identifikationstool 30, 40 oder hundert verschiedene geklonte RouterInfo sah, die alle unter derselben IP-Adresse existierten, und alle bekamen im Sybil-Attack-Tool denselben IP-Score zugewiesen, was dazu führte, dass sie das bekamen, was ich als „Bedrohungsinflation“ bezeichne, weil es so aussah, als ob alle diese IP-Router einen Bedrohungsscore im Sybil-Attack-Tool von Tausenden hätten, obwohl der Schwellenwert für eine Sperrung in den Fünfzigern lag. Wenn man diesen Klon-Angriff durchführt, könnte man Router relativ leicht aus dem gesamten Java-Teil des Netzwerks verbannen, und der einzige Ausweg, den wir hatten, war, diesen Teil des Sybil-Angriffs-Tools zu deaktivieren, was wir auch taten. Wir sind dabei, es umzugestalten, um dieses Problem der Bedrohungsinflation zu entschärfen, so dass niemand einfach eine Million Mal dem Netzwerk beitreten kann, um den Router eines anderen auszugrenzen.

Zur Information: „Bedrohungsinflation“ bezieht sich auf die „aufgeblähte“ Einschätzung der Bedrohung, die von einer grossen Anzahl von Routern mit derselben IP-Adresse ausgeht. Da alle geklonten Router bis auf einen gefälscht waren, stellten sie keine wirkliche Bedrohung dar.

Kurz: Die Angriffe haben uns viel über die Schwachstellen der Java-Router gezeigt. Wie ich schon sagte, hat der Klon-Angriff I2Pd irgendwie schlimmer getroffen.

Lese mehr über die restlichen Themen im zweiten Teil des Interviews mit idk. Verpasse es nicht, auch das wird interessant.

DAS IST DIVA.EXCHANGE

Der gemeinnützige Verein diva.exchange, unterstützt mit einem barrierefreien und kollaborativen Ansatz die Entwicklung freier Banking-Technologie für alle interessierten Menschen. Die quelloffene Technologie sichert die Privatsphäre aller Teilnehmer im Finanzwesen der Zukunft. Das Blockchain-basierte Gesamtsystem ist vollkommen verteilt. Jeder kann bei diva.exchange mitmachen.

Die Zusammenarbeit mit der Forschungsinstitutionen spielt bei diva.exchange eine wichtige Rolle. Forschung findet in Kooperation mit akademischen Einrichtungen statt und die Resultate werden jeweils auf Fachkonferenzen öffentlich vorgestellt.

ERFAHRE MEHR ÜBER UNSERE ARBEIT

Alle technischen Informationen unter: https://github.com/diva-exchange/

I2P-Leitfaden für Einsteiger und Installationsanleitung: https://www.diva.exchange/en/privacy/introduction-to-i2p-your-own-internet-secure-private-and-free/

Alle Videos: https://odysee.com/@diva.exchange:d/

Einführung in I2P: https://en.wikipedia.org/wiki/I2P

Testnetz von diva.exchange: https://testnet.diva.exchange

KONTAKT

Twitter: https://twitter.com/@DigitalValueX

Mastodon: https://social.diva.exchange/@social

Falls noch Fragen auftauchen so ist Telegram besonders geeignet: https://t.me/diva_exchange_chat_de (auf Englisch, Deutsch oder Russisch