I2P - Définition

L'I2PTunnel

Indirection des communications

Les correspondants ne s'exposent pas directement. Ils utilisent chacun une série de routeurs I2P comme intermédiaires pour créer un I2PTunnel. Ces tunnels sont unidirectionnels et utilisés pour masquer le destinataire comme l'expéditeur. On peut donc distinguer deux catégories d'I2PTunnel :

• les tunnels sortants pour masquer les expéditeurs
• les tunnels entrants pour masquer les destinataires

Pour contacter un membre du réseau, il faut trouver les routeurs I2P qui correspondent aux entrées des tunnels mis à disposition par le destinataire. Cette recherche se fait à l'aide du Network Database.

Anonymat au sein de l'indirection

Un chiffrement, appelé en gousse d'ail pour marquer sa différence avec le chiffrement en oignon de TOR, est utilisé sur les messages qui transitent par les I2PTunnel. Ce chiffrement assure :

1. la confidentialité du message
2. et que les intermédiaires ne puissent connaître que les routeurs précèdant et suivant du tunnel.

Le point 1 empêche de pouvoir utiliser les informations contenues dans le message pour identifier les correspondants. Le point 2 empêche les intermédiaires de connaître leur position dans le tunnel et donc que ces intermédiaires puissent différencier correspondants et intermédiaires.

Taille d'un tunnel et qualité d'anonymat

La taille des I2PTunnels est choisie par celui qui le crée. Elle influe de façon conséquente sur l'ensemble des mécanismes qui protège l'anonymat.

Un tunnel sans intermédiaires offre une protection puisqu'on ne peut pas distinguer correspondants et intermédiaires depuis l'intérieur du réseau ; un déni plausible les protège. Cependant un attaquant extérieur au réseau et possédant les ressources pour superviser le trafic d'un tel tunnel peut monter une attaque par analyse statistique.

Lorsque des intermédiaires interviennent il faut compromettre l'ensemble des intermédiaires avant de monter une attaque par analyse statistique. Le mécanisme de mélange de trafic s'attaque à ce problème.

Limitations et contraintes de l'I2PTunnel

Si l'I2PTunnel est relativement efficace pour préserver l'anonymat à l'intérieur du réseau, seul il n'est plus suffisant pour qui peut avoir une vue globale du réseau I2P. Il suffirait d'observer le trafic pour constater où il commence et s'arrête.

Un tunnel, I2P ou autre, entraine une limitation du débit et une augmentation de la latence. La multiplication des tunnels permet d'augmenter l'utilisation du débit inutilisé.

La création de tunnel

Pour communiquer, un correspondant doit créer un tunnel sans avoir à lever son anonymat (afin de faire transiter son message par des pairs). Le créateur du tunnel doit tout d'abord sélectionner les pairs qui participeront potentiellement à son tunnel. Ensuite il crée une requête de demande (TunnelBuildMessage) qui transitera par les pairs sélectionnés avant de revenir au créateur avec les réponses de chacun.

Sélection des pairs

La sélection des pairs s'effectue sur la base de certain critères. Parmi ces critères figure entre autres, leurs temps de réponse et leurs bandes passante. Cette sélection se fait en fonction du rendement, de la fiabilité ou du degré d'anonymat recherché par l'utilisateur.

Création du TunnelBuildMessage

Le TunnelBuildMessage est un message construit par le créateur du tunnel. Il va servir à recenser les réponses des pairs acceptant de participer ou non au tunnel. Si toutes les réponses sont positives alors le tunnel est créé. Ce message est composé de huit fiches d'enregistrement. Une fiche d'enregistrement contient la requête de participation d'un pair. Un tunnel peut donc avoir huit pairs maximum.

        bytes     0-3: tunnel ID to receive messages as        bytes    4-35: local router identity hash        bytes   36-39: next tunnel ID        bytes   40-71: next router identity hash        bytes  72-103: AES-256 tunnel layer key        bytes 104-135: AES-256 tunnel IV key          bytes 136-167: AES-256 reply key         bytes 168-183: reply IV         byte      184: flags        bytes 185-188: request time (in hours since the epoch)        bytes 189-192: next message ID        bytes 193-222: uninterpreted / random padding      

Description d'une fiche d'enregistrement

AES-256 tunnel layer key et AES-256 tunnel IV key : clés de chiffrement qui seront utilisés lors des transactions dans le tunnel si celui ci est construit.

AES-256 reply IV et AES-256 reply key : clé de chiffrement de la réponse et son vecteur d'initialisation, il permet au pair de chiffrer sa réponse avant de faire suivre le message.

next message ID : le pair suivant dans le tunnel. Celui à qui doit être envoyé le message après avoir répondu.

Les autres options permettent de vérifier l'intégrité du message mais aussi d'ajouter des informations supplémentaires à la réponse.

Préparation à l'envoi

Avant d'envoyer le TunnelBuildMessage, le créateur du tunnel chiffre ce message de deux façons successives. Par le chiffrement asymétrique qui permet de garder la confidentialité de l'information sur le réseau, puis par le chiffrement symétrique qui permet de s'assurer que le message a transité dans l'ordre établi par le créateur :

Chiffrement asymétrique : Chaque fiche d'enregistrement est chiffrée avec la clé publique du pair correspondant, de façon à ce que chaque pair n'accède qu'à sa fiche d'enregistrement.

Chiffrement symétrique : Le message est ensuite chiffré par plusieurs couches de façon à n'exposer la fiche qu'au moment opportun. Le chiffrement a lieu de tel manière que lorsque un pair chiffre le message avec sa réponse, alors la fiche d'enregistrement du pair suivant peut être déchiffrée par celui-ci. On peut voir cela comme un oignon auquel on enlève une couche à chaque transmission de l'un à l'autre. Par exemple, un tunnel avec trois pairs A, B et C :

La fiche du dernier pair du tunnel (C) est chiffrée avec la clé de réponse de l'avant dernier (B) de telle manière que lorsque B chiffre sa réponse alors la fiche d'enregistrement de C peut être déchiffrée par C. De même les fiches d'enregistrements de B et C sont chiffrées avec la clé de A afin que B ne puisse être lu qu'après A.

Traitement du TunnelBuildMessage par un pair

Récupération de la fiche

Lorsqu'un pair reçoit un TunnelBuildMessage, il n'y a qu'une seule fiche d'enregistrement n'étant pas chiffré symétriquement. Il déchiffre cette fiche avec sa clé privé afin de récupérer la demande de participation au tunnel.

Choix de participation

Lorsque la fiche est déchiffrée, il remplace le contenu de la fiche par sa réponse, soit il participe au tunnel, soit non. S'il refuse, il donne son motif de rejet.

Chiffrement du message

Une fois la réponse créée et écrite dans la fiche d'enregistrement, il chiffre symétriquement la fiche d'enregistrement avec la clé fournie dans la demande. Il chiffre ensuite les autres fiches d'enregistrements. Le chiffrement des autres fiches a pour conséquence de retirer une couche de chiffrement symétrique, ainsi la fiche du destinataire suivant n'a plus de chiffrement symétrique. Elle est prête à être déchiffré par le destinataire.

Passer au suivant

La dernière opération exécuté par le pair lors de la création du tunnel et de faire passer le TunnelBuildMessage au destinataire suivant. Le destinataire suivant est mentionné dans la fiche d'enregistrement lors de la requête.

Le dernier pair participant à la création du tunnel est le créateur du tunnel. Il déchiffre les fiches dans l'ordre inverse du chiffrement symétrique, effectué lors de la création du TunnelBuildMessage, pour récupérer les réponses.