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 n’essaie pas d’assurer l’anonymat en cachant l’expéditeur d’une communication, mais pas le destinataire, ou le contraire. I2P est conçu afin de permettre aux pairs qui l’utilisent de communiquer anonymement ; ni l’expéditeur ni le destinataire ne peut être identifié par l’autre, ni par un tiers. Par exemple, il y a aujourd’hui des sites Web intra-I2P (qui permettent la publication et l’hébergement anonymes), mais aussi des mandataires HTTP vers le Web normal (qui permettent une navigation anonyme sur la Toile). Il est essentiel d’avoir la capacité d’exécuter des serveurs dans I2P, car il est fort probable que tout mandataire sortant vers l’Internet normal sera surveillé, désactivé ou qu’il sera même piraté pour tenter des attaques encore plus malveillantes.

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 mandataire 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 mandataires pour piloter la fonction 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.

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 ail, 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 même utilise un nombre important de techniques et algorithmes cryptographiques. La liste complète comprend le chiffrement ElGamal à 2048  bits, AES à 256 bits en mode CBC avec bourrage PKCS#5, des signatures DSA à 1024 bits, des hachages SHA256, des connexions négociées en Diffie-Hellman 2048 bit avec une authentification poste à poste, et ElGamal/AES+étiquette de session.

Les contenus envoyés sur I2P sont chiffrés à travers trois couches de chiffrement en ail (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).

End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a" to Bob's router "h" remains. Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end encrypted! A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.

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

Les deux mécanismes principaux pour permettre à ceux qui ont besoin d’un anonymat renforcer d’utiliser le réseau sont les messages à routage en ail explicitement retardés et des tunnels plus complets pour prendre en charge le regroupement et le mélange des messages. Ils sont actuellement prévus pour la version 3.0, mais les messages à routage en ail sans retard et les tunnels premiers entrés, premiers sortis (FIFO) sont déjà en place. De plus, la version 2.0 permettra aux utilisateurs de mettre en place un système et de le faire fonctionner dans des routes restreintes (peut-être avec des pairs de confiance), et permettra aussi le déploiement de transports anonymes plus souples.

Des questions ont été soulevées au sujet de l’extensibilité d’I2P, et à juste titre. D’autres d’analyses seront probablement effectuées avec le temps, mais la recherche de pairs et l’intégration devraient être liées par O(log(N)), à cause de l’algorithme de la base de données, tandis que les messages de bout en bout devraient être O(1) (sans extension), dans la mesure où les messages sortent en K sauts par le tunnel sortant, et encore K sauts par le tunnel entrant, avec K inférieur ou égal à 3. La taille du réseau (N) n’a pas d’impact.