I2P est un projet dont le but est de construire, déployer, et maintenir un réseau fournissant des communications sécurisées et anonymes. Les gens utilisant I2P ont le contrôle de l'arbitrage entre l'anonymat, la fiabilité, l'utilisation de la bande passante, et la latence. Il n'y a dans ce réseau, pas de centre sur lequel pourrait être exercée une pression en vue de compromettre l'intégrité, la sécurité, ou l'anonymat du système. Le réseau intègre sa propre reconfiguration dynamique en réponse aux diverses attaques, et a été conçu pour utiliser de nouvelles ressources au fur et à mesure de leur disponibilité. Bien entendu, tous les aspects du réseau sont publics et disponibles gratuitement.

Contrairement à de nombreux autres réseaux anonymisants, I2P ne tente pas de procurer l'anonymat en masquant l'initiateur d'une communication et pas le destinataire, ou le contraire. I2P est conçu pour permettre aux pairs l'utilisant de communiquer anonymement — à la fois l'émetteur et le récepteur sont non-identifiables à l'un par l'autre comme par un tiers. Par exemple, il y a aujourd'hui des sites web intra-I2P (permettant la publication / hébergement anonyme) tout comme des serveurs proxy HTTP vers le web normal (permettant la navigation anonyme). La possibilité d'avoir des serveurs dans I2P est essentielle, car il est plus que certain que n'importe quel proxy sortant vers l'Internet sera surveillé, désactivé, ou même piraté pour tenter des attaques encore plus pernicieuses.

Le réseau lui-même est "orienté messages" : il est principalement constitué d'une couche IP sécurisée et anonyme, dans laquelle les messages sont adressés à des clés cryptographiques (Destinations) et peuvent être sensiblement plus gros que des paquets IP. Comme exemples d'utilisation du réseau citons les "eepsites" (serveurs web hébergeant des applications Internet normales au sein d'I2P), un client BitTorrent ("I2PSnark"), ou un système de stockage distribué. Grâce à l'application I2PTunnel, nous pouvons utiliser des applications TCP/IP traditionnelles sur I2P, telles que SSH, IRC, un proxy squid, et même du flux audio. La plupart des gens n'utilisent pas I2P directement, ou ne ressentent même pas le besoin de savoir qu'ils l'utilisent. Au lieu de ça ils verront une des application compatibles avec I2P, ou peut-être une petite application de contrôle qui va activer ou désactiver divers proxies pour piloter la fonctionnalité d'anonymisation.

Un des points clés de la conception, du développement, et du test d'un réseau anonyme est la définition de son modèle de sécurité, car il n'existe nulle part un "vrai" anonymat, mais uniquement des moyens d'augmenter les coûts d'identification de quelqu'un. Succinctement, le but d'I2P est de permettre de communiquer dans des environnements hostiles en procurant un bon anonymat, mélangé à un trafic de camouflage suffisant fourni par l'activité de ceux qui ont besoin de moins d'anonymat, de sorte que certains utilisateurs puissent se soustraire à la détection par un adversaire très puissant, quand d'autres pourront esquiver une entité plus faible, tout ceci sur le même réseau dans lequel les messages des uns sont fondamentalement indistinguables de ceux des autres.

Pourquoi?

Il y a une multitude de raisons pour lesquelles nous avons besoin d'un système pour soutenir la communication anonyme, et chacun a son propre raisonnement personnel. Il y a beaucoup d'autres efforts travaillant à découvrir des façons de fournir des degrés variables d'anonymat aux gens à travers l'Internet, mais nous n'avons pu en trouver aucun qui réponde à nos besoins ou à notre modèle de menace.

Comment?

Au premier coup d'oeil le réseau est constitué d'un tas de noeuds ("routeurs") dotés d'un certain nombre de chemins virtuels entrants et sortants unidirectionnels (appelés "tunnels", expliqués sur la page routage en tunnel). Chaque routeur est identifié par l'identifiant cryptographique "RouterIdentity", typiquement à longue durée de vie. Ces routeurs communiquent par des mécanismes existants (TCP, UDP, etc). Les applications clientes ont leur propre identifiant cryptographique ("Destination") qui leur permet d'envoyer et de recevoir des messages. Ces clients peuvent se connecter à n'importe quel routeur et autoriser l'allocation temporaire ("lease") de quelques tunnels qui seront utilisés pour l'envoi et la réception à travers le réseau. I2P dispose de sa propre base de donnée réseau interne (utilisant une modification de l'algorithme Kademlia) pour une distribution sécurisée des informations de routage et de contacts.

Exemple de topologie du réseau

Ci-dessus, Alice, Bob, Charlie, et Dave ont tous leur routeur, avec une seule Destination locale. Ils ont chacun une paire de tunnels entrants ayant deux sauts par destination (repérés 1, 2, 3, 4, 5 et 6), et une petite partie des tunnels sortants de chacun de ces routeurs est montré avec des tunnels sortants ayant deux sauts. Pour simplifier, ne sont représentés ni les tunnels entrants de Charlie et les tunnels sortants de Dave, ni le reste du groupe de tunnels sortants de chaque routeur (fourni par défaut avec quelques tunnels). Quand Alice et Bob discutent ensemble, Alice envoie un message vers un de ses tunnels sortants (en rose) avec pour cible un des tunnels entrants de Bob (3 ou 4, en vert). Elle sait qu'elle doit envoyer vers ces tunnels sur le bon routeur en interrogeant la base de donnée du réseau qui est actualisée en permanence au fur et à mesure que les nouveaux baux sont autorisés et que les anciens expirent.

Si Bob veut répondre à Alice, il utilise simplement la même procédure : envoyer un message via un de ses tunnels sortants en ciblant un des tunnels entrants d'Alice (tunnel 1 ou 2). Pour rendre les choses plus faciles, la plupart des messages circulant entre Alice et Bob sont empaquetés en oignon, embarquant les informations sur le bail actuel de l'expéditeur, de sorte que le destinataire puisse répondre immédiatement sans avoir à interroger la base de données.

Pour gérer une grande gamme d'attaques, I2P est entièrement décentralisé et en conséquence il n'y a pas de serveur d'annuaire conservant des statistiques de performances et de fiabilité Donc chaque routeur doit garder et entretenir les profils de divers routeurs et est responsable de la sélection de pairs appropriés aux besoins d'anonymat, de performance et de fiabilité des utilisateurs, comme expliqué sur la page sélection de pairs.

Le réseau fait usage d'un nombre significatif de techniques et algorithmes cryptographiques : la liste complète est constituée des cryptages ElGamal 2048bits, AES 256bits en mode CBC avec bourrage PKCS#5, des signatures DSA à 1024bits, des hachages SHA256, de l'authentification de connexions station à station négociée en Diffie-Hellman 2048bit, et ElGamal / AES+SessionTag.

Les contenus envoyés sur I2P sont chiffrés à travers trois couches de chiffrement en oignon (utilisées pour vérifier la réception du message par le destinataire), par le chiffrement de tunnel (tous les messages traversant un tunnel sont chiffrés par la passerelle du tunnel jusqu'au point de sortie du tunnel), et par un chiffrement de la couche de transport inter routeurs (p.e. le transport TCP utilise des clés AES256 éphémères).

Le chiffrement de bout en bout (I2CP) (application cliente vers l'application serveur) a été désactivé dans la version 0.6; Le chiffrement (oignon) de bout en bout (routeur I2P client vers routeur I2P serveur) depuis le routeur "a" d'Alice vers le "h" de Bob est resté. Remarquez l'utilisation différente des termes ! Toutes les données transitant de "a" vers "h" sont cryptées de bout en bout, mais la connexion I2CP entre le routeur et les applications ne l'est pas ! "a" et "h" sont les routeurs d'Alice et Bob, alors qu'Alice et Bob dans le schéma suivant sont les applications qui tournent sur I2P.

Cryptage en couches de bout en bout

Les utilisations spécifiques de ces algorithmes sont précisées ailleurs.

Les deux mécanismes principaux permettant l'usage du réseau par ceux qui ont besoin d'un anonymat fort sont très explicitement le routage "oignon" retardé et des tunnels plus évolués incluant la possibilité d'appeler et de croiser les messages. Ils sont actuellement planifiés pour la version 3.0, mais le routage "oignon" instantané et les tunnels FIFO sont d'ores et déjà opérationnels. La version 2.0 permettra de mettre en place des routes réservées (peut-être avec des pairs de confiance), ainsi que des transports plus souples et plus anonymes.

Des questions ont surgit à juste titre concernant l'évolutivité d'I2P en terme d'échelle. Il y aura certainement davantage d'analyse avec le temps, mais l'intégration et la recherche des pairs devraient répondre via O(log(N)) grâce à l'algorithme de la base de données, tandis que les messages seraient plutôt liés à O(1) (non dépendant de l'échelle), car les messages passent par K sauts du tunnel sortant puis encore K sauts via le tunnel entrant, avec K inférieur ou égal à 3. La taille du réseau (N) n'a pas d'impact.

Quand?

I2P a initialement commencé en février 2003 comme modification proposée à Freenet pour permettre d'utiliser des transports alternés, tels que JMS, puis s'est développé en lui-même en tant que 'anonCommFramework' en avril 2003, se métamorphosant en I2P en juillet, avec du code étant écrit sérieusement à partir de août 2003. I2P est actuellement en développement, selon la feuille de route.

Qui?

Nous sommes une petite équipe répartie sur plusieurs continents, qui travaille à l'avancement de différents aspects du projet. Nous sommes complètement ouverts à l'arrivée d'autre développeurs qui voudraient s'impliquer et à celle de quiconque préfèrerait participer d'autres façons, telles que la critique, l'analyse de pair, le test, l'écriture d'applications compatibles, ou de documentation. Le système est totalement "open source" : le routeur et presque tout l'outil de développement sont de plein droit dans le domaine public avec quelques lignes de code sous licences BSD et Cryptix, et quelques applications comme I2PTunnel et I2PSnark sous GPL. Presque tout est écrit en Java (1.5+), bien que quelques applications de tierce partie soient écrites en Python et autres langages. Le code fonctionne sur Oracle/Sun Java SE et d'autres Machines Virtuelles Java.

Où?

Anyone interested should join us on the IRC channel #i2p-dev (hosted concurrently on irc.freenode.net, irc.postman.i2p, irc.echelon.i2p, irc.dg.i2p and irc.oftc.net). There are currently no scheduled development meetings, however archives are available.

Le code source est disponible dans monotone.

Plus d'infos

Voir l'index de la documentation technique.