↓ Aller au contenu
Ixonae on Security
  1. Articles/

I2P - Une introduction simple

·8 mins
Ixonae
Vie privée Réseaux
Ixonae
Auteur
Ixonae
Sommaire

Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.

L’Invisible Internet Project (I2P) est une couche réseau privée et chiffrée qui permet aux gens de se connecter anonymement. Contrairement à Tor (si vous n’êtes pas familier avec lui, je vous recommande de consulter cet article), I2P n’est pas conçu pour accéder à Internet (bien qu’il soit possible de le faire avec des outproxies) mais pour accéder à divers types de services au sein du réseau, tels que des sites web anonymes (site I2P, ou eepSite), des torrents, des IRC, … I2P a été publié en 2003 et en est maintenant à la version 1.5.

Certaines parties de l’implémentation d’I2P sont un peu similaires à Tor (le concept de chiffrement en oignon), mais il possède aussi des caractéristiques supplémentaires (principalement le routage et le chiffrement en ail). La documentation officielle est un peu difficile à appréhender, donc cet article vise à vous donner une bonne vue d’ensemble du fonctionnement de toutes les parties du système.

Comment fonctionne I2P
#

Vue d’ensemble de haut niveau et tunnels
#

Le premier terme que nous devons connaître est « routeur ». Fondamentalement, il désigne tout client qui exécute I2P. Chaque routeur possède des tunnels entrants et sortants qui sont des conduits de données permettant de recevoir et d’envoyer des données. Les données entrantes et sortantes sont séparées pour permettre une meilleure anonymité et de meilleures performances.

La Figure 1 suivante montre comment les échanges sont effectués entre différents utilisateurs. Notez qu’il s’agit d’une version simplifiée avec certains tunnels omis.

Figure 1: I2P routing between routers
Figure 1 : Routage I2P entre routeurs (source geti2p.net)

Nous pouvons voir qu’Alice et Bob communiquent ensemble. Les données envoyées à Bob passent par les tunnels sortants d’Alice puis vers les tunnels entrants de Charlie, tandis que les données reçues de Bob passent par les tunnels sortants de Bob puis les tunnels entrants d’Alice.

Une plongée plus profonde dans les tunnels et le chiffrement
#

Après avoir lu la partie précédente, nous avons une vue d’ensemble de haut niveau du fonctionnement du système, mais cela ne répond pas à la question de comment les données des clients restent secrètes. Cette partie est là pour y répondre.

La partie principale de la réponse réside dans les tunnels. De manière similaire à Tor, deux clients communiquant ensemble sont séparés par plusieurs routeurs (sauts). Habituellement 2 ou 3 (comme dans la Figure 2), mais cela pourrait être configuré jusqu’à 7, ou aussi peu que 0.

Figure 2: Exchanges between I2P tunnels
Figure 2 : Échanges entre tunnels I2P (source geti2p.net)

La Figure 2 montre ce qui se passerait si Alice envoyait un message à Bob. Avant d’expliquer les interactions, nous avons besoin de quelques définitions :

  • a est la passerelle sortante. Techniquement, c’est le routeur d’Alice
  • b et c sont les participants du tunnel sortant. Il peut y en avoir un ou plusieurs, et ils sont juste là pour transférer le message au nœud suivant
  • d est le point de sortie du tunnel sortant. C’est la fin du tunnel sortant (appartenant à Alice), et il est chargé de transmettre le message au tunnel entrant (appartenant à Bob)
  • e est la passerelle entrante. Si un client veut que des personnes puissent le contacter, l’adresse de la passerelle entrante sera publiée dans la base de données du réseau (plus de détails à ce sujet plus tard)
  • f et g sont les participants du tunnel entrant. Ils sont identiques à b et c. Les participants des tunnels ne savent jamais s’ils font partie d’un tunnel entrant ou sortant, et sont simplement chargés de recevoir des messages et de les envoyer au saut suivant
  • h est le point de terminaison entrant. Techniquement, le routeur de Bob

Lors de l’envoi d’un message, voici ce qui se passera au niveau du chiffrement :

  1. a va fragmenter le message en messages plus petits de 1 024 octets. Tous les messages passant dans le pipeline ont une taille fixe pour prévenir diverses attaques
  2. a va chiffrer chaque message de 1 024 octets pour h, de sorte que seuls Alice et Bob puissent en connaître le contenu
  3. a va chiffrer le résultat obtenu en (1) pour d, puis il va chiffrer le résultat pour c, puis il va chiffrer le résultat pour b (et faire cela autant de fois qu’il y a de participants). C’est similaire à ce qui est fait dans Tor avec le chiffrement en oignon
  4. b va recevoir les messages du tunnel, les déchiffrer, et les transférer à c
  5. c va recevoir les messages du tunnel, les déchiffrer, et les transférer à d
  6. d va recevoir les messages de 1 024 octets, les réassembler pour récupérer les données initiales qui ont été fragmentées à l’étape (1), et transmettre cela à la passerelle entrante e
  7. e va recevoir le message, le fragmenter en messages tunnel de 1 024 octets, et envoyer chacun d’eux à f
  8. f va recevoir les messages du tunnel, les chiffrer, et les transférer à g
  9. g va recevoir les messages du tunnel, les chiffrer, et les transférer à h
  10. h va déchiffrer les messages chiffrés par g, déchiffrer le résultat chiffré par f, déchiffrer le résultat chiffré par e, et déchiffrer le résultat chiffré par a. Puis il assemble le tout pour récupérer le grand message en clair que nous avions à l’étape (1)

Notez que a utilisera la fonction decrypt pour chiffrer les messages, et b et c la fonction encrypt pour les déchiffrer. Puisque f et g utilisent aussi la fonction encrypt (pour chiffrer les messages cette fois), les participants ne peuvent pas savoir s’ils font partie d’un tunnel entrant ou sortant. De plus, pour s’assurer que les messages du tunnel font toujours 1 024 octets, les différents processus peuvent utiliser du rembourrage.

Établissement des tunnels et base de données
#

Si vous êtes arrivé jusqu’ici, vous avez maintenant une idée générale du fonctionnement d’I2P, de comment les données restent confidentielles, et de ce que font les tunnels. Deux choses que vous ne savez pas encore sont comment les tunnels sont créés, et comment les clients sont anonymes (si vous êtes familier avec Tor, vous avez peut-être déjà compris la deuxième partie de la question).

La base de données
#

Un élément critique dans le système est la capacité de contacter d’autres routeurs pour créer les routes, mais aussi de savoir comment accéder aux services. Tor a un point central où les clients peuvent se renseigner sur les informations des nœuds. I2P a aussi un point central pour obtenir les informations des routeurs, mais ce n’est pas une base de données exhaustive. Elle sera simplement utilisée pour fournir quelques adresses de routeurs, afin que le client puisse amorcer la carte du réseau. La base de données des routeurs elle-même est une base de données distribuée nommée netDb. La netDb est distribuée avec une technique appelée « floodfill », et chaque routeur y participant est appelé un « routeur floodfill ». La base de données contient deux entités : les RouterInfos et les LeaseSets.

Chaque routeur participant au réseau a une entrée dans la base de données nommée RouterInfo. Elle contient les éléments suivants :

  • L’identité du routeur (une clé de chiffrement, une clé de signature et un certificat)
  • L’adresse de contact pour joindre le routeur
  • La date de publication
  • Diverses options textuelles pour partager les capacités du routeur et autres
  • Une signature de tous les champs précédents, créée par le routeur avec la clé de signature

Pour pouvoir envoyer un message à un client, chacun de ses tunnels entrants possède un LeaseSet dans la base de données. Il fournira les informations suivantes :

  • Le routeur passerelle du tunnel (qui est défini dans les entités RouterInfo)
  • L’identifiant du tunnel (nombre de 4 octets)
  • La date d’expiration du tunnel (par défaut toutes les 10 minutes)
  • Une clé de chiffrement, une clé de signature et un certificat pour la destination
  • Une signature des données du LeaseSet

Notez qu’il est possible pour un LeaseSet de ne pas être public (par exemple quand un client utilise IRC), et de simplement faire en sorte qu’I2P partage les informations du LeaseSet avec les parties concernées.

Un type de LeaseSets est particulièrement intéressant pour nous : les LeaseSets chiffrés. Comme leur nom l’indique, ils ne permettent qu’aux clients possédant la bonne clé d’obtenir les informations du LeaseSet, et donc de pouvoir contacter le tunnel entrant. Notez que lorsqu’un routeur enregistre un LeaseSet dans la base de données, il le fera en utilisant son tunnel sortant pour pouvoir rester anonyme.

Établissement des tunnels
#

Lorsqu’un routeur veut créer un tunnel, il trouvera des routeurs à partir des entrées RouteInfo de la base de données, et les sélectionnera pour avoir une route optimisée à l’aide de diverses heuristiques. Il devra ensuite contacter les routeurs pour leur demander la permission de configurer un tunnel.

Chacun des membres potentiels du tunnel recevra un identifiant de tunnel et des clés de chiffrement qu’il devra utiliser pour chiffrer les données transitant, et aussi pour répondre à la demande de construction. De plus :

  • les participants intermédiaires du tunnel et la passerelle entrante recevront les informations du prochain saut (adresse du routeur et identifiant du tunnel)
  • le point de sortie du tunnel sortant recevra les informations de la passerelle entrante à laquelle nous voulons envoyer des informations

Lorsque tous les participants ont accepté de faire partie d’un tunnel, le routeur initiateur peut commencer à l’utiliser pour envoyer ou recevoir des données. Les participants peuvent avoir plusieurs tunnels ouverts, donc l’identifiant de tunnel qui leur est fourni au début leur permet de savoir à quel tunnel appartient un paquet qu’ils reçoivent, et donc quel est le prochain saut pour ce message. Puisque les routeurs ne peuvent voir que la destination précédente et suivante d’un message, ils ne peuvent pas savoir qui envoie le message ni où il va, permettant ainsi l’anonymat.

Sources et lectures complémentaires
#