Note de l’auteur : les attaques mentionnées dans cet article ne sont pas possibles contre les versions actuelles d’I2P.

En tant que réseau pair-à-pair auto-organisé, I2P dépend du fait que les routers participant au réseau disposent d’un moyen de partager des informations sur ce qui se trouve sur le réseau et sur la manière de l’atteindre. Les routers I2P réalisent ce partage d’informations en utilisant la NetDB, une DHT (table de hachage distribuée) basée sur Kademlia mais modifiée pour fonctionner avec I2P. La NetDB doit partager deux principaux types d’entrées, les “RouterInfos” que les pairs utiliseront pour communiquer directement avec d’autres routers, et les “LeaseSets” que d’autres pairs utiliseront pour communiquer avec des clients I2P via des tunnels anonymes. Les routers échangent fréquemment des entrées de la NetDB entre eux, soit en envoyant l’information à un router ou à un client, soit en demandant des informations à un router ou à un client. Cela signifie que les entrées peuvent arriver directement ou indirectement, de manière anonyme ou non anonyme, selon les besoins du réseau et les capacités du client. Cependant, en tant que réseau d’anonymisation, il est également important qu’il demeure impossible de redemander de façon non anonyme une information envoyée anonymement. Il est également important qu’une information envoyée de façon non anonyme ne puisse pas être redemandée de façon anonyme. Si l’une de ces situations devient possible, une attaque de corrélation pourrait être menée, permettant à un attaquant de déterminer si des clients et des routers partagent une vue commune de la NetDB. S’il peut être établi de manière fiable que les 2 cibles partagent une vue commune de la NetDB, il y a de très fortes chances qu’elles se trouvent sur le même router, ce qui affaiblit drastiquement l’anonymat de la cible. Comme il existe très peu de réseaux d’anonymisation, et qu’I2P est le seul où la table de routage est partagée via le fonctionnement d’une DHT, cette classe d’attaque est quasiment unique à I2P et sa résolution est importante pour le succès d’I2P.

Considérez le scénario suivant : Il existe un I2P router hébergeant un I2P client. Le router publie un RouterInfo, et le I2P client publie son LeaseSet. Étant donné qu’ils sont tous deux publiés dans le NetDB, d’autres I2P routers peuvent interroger le NetDB pour découvrir comment communiquer avec eux. C’est normal et essentiel au fonctionnement d’un réseau superposé du type implémenté par I2P. Un attaquant exécute un I2P router et interroge le NetDB pour obtenir le RouterInfo cible et le LeaseSet cible. Il fabrique ensuite un nouveau LeaseSet qui est unique et et potentiellement même faux, et l’envoie via un tunnel vers le LeaseSet du client qu’il cible pour l’attaque. Le client traite le LeaseSet fabriqué et l’ajoute à son propre NetDB. L’attaquant redemande ensuite directement le LeaseSet fabriqué, depuis le router, en utilisant le RouterInfo qu’il a obtenu du NetDB. Si le LeaseSet fabriqué est renvoyé en réponse, alors l’attaquant peut conclure que le client ciblé et le router ciblé partagent une vue commune du NetDB.

Ceci est un exemple simple d’une classe d’attaque de désanonymisation de la NetDB qui repose sur l’ajout d’une entrée dans la NetDB de quelqu’un d’autre avec une identité, puis sur sa récupération avec une autre identité. Dans ce cas, les identités en question sont l’identité “router” et l’identité “client”. Cependant, la corrélation client-à-client, moins dommageable, est également possible dans certaines conceptions. Concevoir une défense contre cette classe d’attaque nécessite de donner au router un moyen de déterminer s’il est sûr de communiquer une information à une identité potentielle.

Alors, comment faut-il aborder ce problème ? Ce dont nous traitons ici, en réalité, concerne la corrélabilité de différentes “identités” sur le réseau. La possibilité d’établir un lien naît du fait que toutes ces identités partagent une structure de données commune qui “se souvient” avec qui elle a communiqué, et qui a communiqué avec elle. Elle “se souvient” aussi de la manière dont cette communication a eu lieu.

L’espace d’un instant, imaginons-nous à la place d’un attaquant. Imaginez que vous cherchiez à découvrir l’identité d’un maître du déguisement. Vous savez avec certitude que vous avez vu son vrai visage, et vous savez tout aussi sûrement que vous communiquez régulièrement avec l’une de ses identités déguisées. Comment établiriez-vous que l’identité déguisée et l’identité réelle appartiennent à la même personne ? Je pourrais confier un secret à la personne déguisée. Si la personne non déguisée répond en utilisant l’information secrète, alors je peux déterminer que la personne non déguisée connaît ce secret. En partant du principe que la personne déguisée n’a communiqué ce secret à personne d’autre, je peux en déduire que la personne non déguisée et la personne déguisée sont en réalité une seule et même personne. Peu importe le nombre de masques que porte le maître du déguisement, il n’a qu’un seul esprit.

Afin de protéger efficacement les identités des clients I2P, I2P doit pouvoir se montrer un meilleur maître de la dissimulation que celui décrit ci-dessus. Il doit être capable de “se souvenir” de plusieurs informations importantes sur la façon dont il a participé au NetDB et de réagir de manière appropriée en fonction de ces détails. Il doit être capable de se rappeler :

  • 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

Sur le plan structurel, la manière la plus claire et la plus fiable de gérer ce modèle consiste à utiliser des “Sub-DB” (sous-bases de données). Les Sub-DB sont des NetDB miniatures qui servent à aider la NetDB à organiser les entrées sans en perdre la trace. Chaque client reçoit une Sub-DB pour son propre usage, et le router lui-même dispose d’une NetDB à part entière. En utilisant des Sub-DB, nous donnons à notre maître du déguisement un répertoire de secrets, organisé par la personne qui les lui a communiqués. Lorsqu’une requête est envoyée à un client, on ne recherche que les entrées qui ont été communiquées à ce client, et lorsqu’une requête est envoyée à un router, seule la NetDB globale du router est utilisée. En procédant de cette manière, nous neutralisons non seulement la forme la plus simple de l’attaque, mais nous réduisons également la puissance de l’ensemble de cette classe d’attaques.