Votre niveau d'anonymat peut se définir par "la difficulté que quelqu'un rencontrera pour trouver des informations vous concernant que vous ne voulez pas qu'il connaisse" - qui vous êtes, où vous vous trouvez, avec qui vous communiquez, ou même quand. L'anonymat "parfait" n'est ici un concept ni pertinent ni utile : un logiciel ne vous rendra pas indiscernable par des gens qui n'utilisent ni ordinateur ni Internet. Nous travaillons plutôt à produire l'anonymat suffisant aux besoins réels, dans la mesure du possible, de qui que ce soit - de ceux qui se promènent simplement sur Internet, à ceux qui échangent des données, jusqu'à ceux inquiets de l'intrusion des organisations et des états.
La réponse à la question de savoir si I2P apportera un anonymat suffisant à vos besoins particuliers est difficile, mais nous espérons que cette page vous éclairera en passant en revue les diverses menaces.
Nous accueillons avec bienveillance toutes recherches et analyses supplémentaires sur la résistance d'I2P aux menaces décrites ci-dessous. Nous avons besoin de plus de recherche sur la littérature existante (dont la plus grande partie est focalisée sur Tor), ainsi que de travaux originaux.
I2P germe des idées de nombreux autres systèmes, mais il faut garder à l'esprit un petit nombre de points essentiels quand on examine la littérature concernée :
Nous avons des plans documentés de mise en œuvre de retards conséquents et de stratégies traitements par lots dont l'existence et le détail des modalités ne sont connus que par le saut ou la passerelle de tunnel particuliers qui reçoivent le message, pour permettre au réseau (croisé à basse latence dans sa caractéristique principale) de fournir un trafic de camouflage aux communications de latence plus élevée (p.ex. les e-mails). Nous savons que l'introduction de retards élevés est requise pour assurer une protection significative, et que son implémentation sera une épreuve sérieuse. Il n'est cependant pas actuellement certain que nous solliciterons ces méthodes de retardement.
En théorie, des routeurs situés sur le chemin du message pourraient injecter un nombre arbitraire de sauts supplémentaires avant de transférer le message au pairs suivant. L'implémentation actuelle ne le fait pas.
La conception d'I2P a commencé en 2003, juste après l'apparition de l' [Onion Routing], de [Freenet], et de [Tor]. Notre conception tire de substantiels bénéfices des recherches publiées à cette époque. I2P utilise plusieurs des techniques du routage en oignon, et continue de bénéficier de l'intérêt que Tor suscite dans la recherche théorique.
Inspirée des attaques et analyses mises en avant dans littérature (particulièrement Traffic Analysis: Protocols, Attacks, Design Issues and Open Problems), la suite décrit brièvement un large éventail d'attaques et plusieurs des contre-mesures prises par I2P. Nous tenons à jour cette liste pour y ajouter les nouvelles attaques au fur et à mesure de leurs découvertes.
Nous y adjoignons quelques attaques spécifiques à I2P. Nous n'avons pas de réponse adaptée à chacune d'elles, mais nous poursuivons nos recherches et fourbissons nos défenses.
De plus, plusieurs de ces attaques sont d'autant plus potentiellement réalisables que la taille du réseau est actuellement modeste. Bien que nous soyons au courant de quelques limitations qui restent à résoudre, I2P est conçu pour accueillir des centaines de millier et même des millions de participants. Au fur et à mesure de la croissance du réseau, ces attaques deviendront de plus en plus difficiles à monter.
Les pages sur la comparaison des réseaux et la terminologie des "gousses d'ail" apportent aussi un éclairage complémentaire.
Une attaque en force brute peut être montée par un adversaire global passif ou actif qui surveillerait tous les transferts de messages entre tous le nœuds et tenterait d'établir une corrélation entre les messages et les chemins qu'ils empruntent. Le montage d'une attaque de ce type contre I2P ne serait pas une mince affaire car tous les pairs du réseau envoient souvent des messages (tant de bout en bout que d'entretien du réseau), sans compter les changements de taille et de données des messages tout au long de leur transit d'un bout à l'autre. de plus, l'attaquant externe n'a pas accès au messages, car la communication inter-router est à la fois cryptée et envoyée comme un flux (ce qui rend deux messages de 1024 bits indiscernables d'un message de 2048 bits).
Cependant, un attaquant puissant peut utiliser la force brute pour détecter des tendances - s'il peut envoyer 5 Go à une destination I2P et surveiller toutes les connexions du réseau, il peut éliminer les pairs qui n'ont pas reçu 5 Go. Il existe des techniques pour déjouer cette attaque, mais elle serait prohibitive (voir : Tarzan et sa simulation de trafic à taux constant). La plupart des utilisateurs ne craignent pas cette attaque à cause de son extrême coût de montage (et du fait qu'elle nécessiterait à coup sûr un comportement légalement répréhensible). Elle est malgré tout envisageable au niveau d'un gros FAI ou d'un point d'échange Internet. Ceux qui veulent y parer devraient prendre des mesure conservatoires, telles que régler de faibles limites de bande passante et l'utilisation de jeux de baux cryptés ou non publiés pour les sites eep. D'autre contre-mesures comme les retards volontaires et les routes privées ne sont pas implémentées actuellement.
En tant que protection partielle envers un seul routeur ou un groupe de routeurs qui tenteraient de router tout le trafic du réseau, le routeur contient des limites quand au nombre de tunnels pouvant être routés par un seul pair. À mesure de la croissance du réseau, ces limites sont sujettes à ajustements ultérieurs. D'autres mécanismes d'évaluation, de sélection et d'évitement des pairs sont approfondis la page sélection des pairs.
Les messages I2P sont unidirectionnels et n'induisent pas nécessairement de réponse. Cependant, les applications tournant sur I2P ont certainement des motifs reconnaissables dans la fréquence de leurs messages - par exemple une requête HTTP est un court message suivi d'une longue séquence de messages constituant la réponse. Connaissant ça, un attaquant doté d'une large vue sur la topologie du réseau serait en mesure d'écarter les liens trop lents pour avoir pu transférer les réponses dans le temps observé.
Ce genre d'attaque est efficace, mais sa faisabilité n'est pas évidente car les retards variables sur les transferts de messages dus à mise en file d'attente, au traitement et au bridage dépassent souvent le temps nécessaire au passage à travers un seul lien - même si l'attaquant sait qu'une réponse repartira dès le message reçu. Il y a quelques scenarii qui exposent cependant des réponses automatiques rapides - c'est le cas dans l'utilisation de la bibliothèque de flux (avec le SYN+ACK), et le mode transmission garantie (avec la paire DataMessage+DeliveryStatusMessage).
Sans camouflage du protocole ou latences plus élevées, des adversaires globaux actifs peuvent obtenir des informations significatives. Les gens soucieux de ces attaques pourraient augmenter la latence (en utilisant des retards non négligeables ou les stratégies de traitement par lots), le camouflage de protocole, ou d'autres techniques de routage en tunnel avancées, mais celles-ci ne sont pas implémentées dans I2P.
Références: Low-Resource Routing Attacks Against Anonymous Systems
Les attaques d'intersection contre les systèmes à basse latence sont très efficaces - il s'agit de contacter périodiquement la cible et de conserver la trace des pairs présents sur le réseau. Au fil du temps, quand la présence des nœuds est bien homogénéisée, l'attaquant obtient des informations en croisant simplement les jeux de pairs en ligne quand un message les traverse avec succès. Le coût de cette attaque croît avec la taille du réseau, mais pourrait être faisable dans certaines circonstances.
En résumé, si un attaquant se trouve à chaque extrémité de votre tunnel au même moment, il pourrait y parvenir. I2P ne dispose pas de parade ultime contre ça pour les communications à basse latence. Il s'agit d'une faiblesse inhérente au routage en oignon à basse latence. Tor fait clairement état de la même mise en garde.
Défenses partielles implémentées dans I2P :
Dans le futur, on peut envisager d'utiliser pour les pairs qui peuvent se le permettre, utiliser des délais importants (via les retards volontaires et les stratégies de traitement par lots). De plus, ceci ne vaut que pour les destinations que d'autres gens connaissent - un groupe privé dont la destination n'est connue que par des pairs de confiance n'a pas à s'inquiéter, car un adversaire ne peut pas les "pinguer" pour monter une attaque.
Référence: One Cell Enough
Il y a tout un groupe d'attaques de déni de service disponibles contre I2P, chacune ayant ses propres coûts et conséquences :
Les attaques par marquage - modifier un message pour pouvoir l'identifier plus loin sur son chemin - sont par elles-mêmes impossibles dans I2P, car les messages passant par les tunnels sont signés. Cependant, si l'attaquant est la passerelle de tunnel entrant et par collusion en même temps un participant au même tunnel, il peut identifier le fait qu'ils sont dans le même tunnel (avant l'implémentation des identifiants uniques de tunnels et autres mises à jour, des pairs complices dans un même tunnel pouvaient détecter cette circonstance sans aucun effort). Un attaquant dans un tunnel sortant et une partie quelconque d'un tunnel entrant ne peuvent cependant pas coopérer car le cryptage de tunnels remplit les paquets et modifie les données séparément pour les tunnels entrants et sortants. Les attaquants externes ne peuvent rien manigancer, car les liens sont cryptés et les messages signés.
Les attaques par cloisonnement - trouver des moyens de différentier (techniquement ou analytiquement) les pairs d'un réseau - sont importantes à ne pas perdre de vue quand il s'agit de considérer leur utilisation par un adversaire doté de gros moyens, car la taille du réseau joue un rôle prépondérant dans la détermination de votre anonymat. Le cloisonnement technique réalisé en coupant des liens entre pairs pour des réseaux fragmentés est pris en compte par la base de données intégrée d'I2P, qui entretient des statistiques sur les divers pairs tant pour permettre l'exploitation de connexions existantes vers des zones isolées que pour cicatriser le réseau. De toute façon, si l'attaquant déconnecte tous les liens vers des pairs non contrôlés, isolant ainsi la cible, la base de donnée ne lui sera d'aucun secours. À ce moment, la seule chose que le client puisse espérer c'est que le routeur cible détecte qu'un nombre important de pairs précédemment fiables sont devenus inaccessibles et qu'il le prévienne qu'il est temporairement déconnecté (ce code de détection n'est pas implémenté à ce jour).
Le cloisonnement du réseau par l'analyse des différences dans la façon dont routeurs et destinations se comportent et les regrouper en conséquence est un autre méthode d'attaque très fructueuse. Par exemple, l'attaquant qui collecte la base de données du réseau saura quand une destination donnée aura 5 tunnels entrants dans ses jeux de baux, quand les autres n'en ont que 2 ou 3, ce qui permettrait à l'attaquant d'isoler la cible par le nombre de tunnels sélectionnés. Une autre partition est possible par le moyen des retards non négligeables et des stratégies de traitement par lots, car les passerelles de tunnel et les sauts particuliers à retards non-nuls seront probablement mis en avant. Quoi qu'il en soit, cette donnée n'est exposée qu'à ces sauts particuliers, et donc, pour cloisonner effectivement sur ce critère, l'attaquant devrait contrôler une partie importante du réseau (et ça ne serait encore qu'une partition probabiliste, car il ne saurait pas quels tunnels ou quels messages sont affublés de cet attribut de retard).
Également discuté sur la page base de données du réseau (attaque d'amorçage).
L'attaque de prédécesseur collecte passivement des données statistiques pour trouver quels pairs sont "proches" de la destination en participant à leurs tunnels et en gardant la trace des sauts précédents et suivants (respectivement pour les tunnels sortants et entrants). Sur la durée, en utilisant un échantillon parfaitement aléatoire de pairs et un tri aléatoire, l'attaquant pourrait parvenir à voir quel pair se montre statistiquement plus "proche" que les autres, et donc ainsi révéler où est la cible.
I2P empêche ceci par quatre moyens : d'abord, les pairs retenus pour participer aux tunnels ne sont pas choisis aléatoirement dans le réseau - ils sont déduits de l'algorithme de sélection des pairs qui les répartit en groupes. Puis avec le tri strict des pairs d'un tunnel, le fait qu'un pair apparaît plus souvent ne signifie pas qu'il est la source. Ensuite, grâce à la longueur de tunnel permutée (non activée par défaut), même des tunnels à 0 saut peuvent fournir un alibi recevable car les changements occasionnels de la passerelle les font apparaitre comme des tunnels normaux. Et pour finir, avec les routes réservées (pas encore implémentées), seul le pair en connexion réservée à la cible pourra la contacter, et l'attaquant se heurtera alors à la passerelle.
La méthode de construction des tunnels actuelle a été spécifiquement conçue pour parer aux attaques de prédécesseur. Voir aussi l'attaque d'intersection.
Références: http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf qui est une mise à jour de 2008 de la publication sur l'attaque de prédécesseur http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf.
"Collecter" signifie dresser une liste d'utilisateurs d'I2P. Elle peut servir à des "attaques" légitime et pour aider à réaliser d'autres attaques par la simple exécution d'un pair, pour savoir à qui il se connecte et recueillir toutes les références aux autres pairs qu'il peut trouver.
I2P n'est pas en lui-même conçu avec des protections effectives contre cette attaque, puisque l'existence même de la base de données du réseau pourrait relever de cette définition. Les détails suivants rendent cette attaque plutôt difficile dans la pratique :
Plus tard les routeurs pourront utiliser GeoIP pour savoir s'ils sont dans un pays où l'identification en tant qu'utilisateur d'I2P pourrait être dangereuse. Dans ce cas, le routeur pourrait automatiquement activer le mode caché ou mettre en œuvre les autres méthodes de routes réservées.
En surveillant le trafic d'un routeur, un FAI sans scrupule ou un pare-feu à état pourrait déterminer qu'un ordinateur utilise I2P. Comme expliqué ci-dessus (collecte), I2P n'est pas conçu pour se cacher lui-même. Cependant, certaines décisions de conception du transport (couche et protocole) rendent l'identification du trafic I2P difficile :
Références: Breaking and Improving Protocol Obfuscation
On range sous cette appellation les attaques mettant en œuvre la création d'un grand nombre arbitraire de nœuds coalisés et de leur utilisation pour aider à monter d'autres types d'attaques. Par exemple, si un attaquant se trouve sur un réseau dans lequel les pairs sont sélectionnés aléatoirement et qu'il désire avoir 80% de chances d'être un de ceux là, il n'a qu'à créer cinq fois plus de nœuds qu'il n'y en a déjà dans le réseau, et lancer les dés. Quand l'identité est libre, la méthode Sibylle peut être très productive pour un attaquant aux moyens importants. La principale technique d'empêcher ça est de rendre l'identité non libre - parmi d'autres, Tarzan se sert de la limite des adresses IP, alors qu'IIP utilisait les pénalités HashCash comme ticket d'entrée à la création d'une nouvelle identité. Nous n'avons ce jour implémenté aucune technique particulière pour répondre à ces attaques, mais nous avons des champs réservés de certificats dans les structures de données des routeurs et des destinations qui peuvent contenir un certificat de HashCash de valeur appropriée si nécessaire (ou autre certificat d'épreuve de rareté).
La nécessité de certificats pénalisants à divers endroits a deux défauts majeurs :
Diverses limitations du nombre de routeurs dans un intervalle IP réduisent la vulnérabilité à l'attaquant qui n'a pas la possibilité de placer ses machines dans plusieurs blocs d'IP. Cependant, ça n'est pas suffisant contre un adversaire à gros moyens.
Voir la page sur la base de données du réseau sur le sujet des attaques de type Sibylle.
(Référence: In Search of an Anonymouns and Secure Lookup Section 5.2)
En refusant d'accepter les requêtes de création ou de transfert de tunnels, à part pour les pairs complices, un routeur peut d'assurer qu'un tunnel n'est composé que de complices. Les chances de succès sont accrues par un grand nombre de complices, par exemple grâce à l'aide d'une attaque par la méthode Sibylle. Ceci est diminué par nos méthodes de profilage des pairs utilisées pour surveiller leurs performances. Mais ça reste une attaque efficace quand le nombre de routeurs approche de f = 0.2, ou 20% de nœuds toxiques, comme c'est indiqué dans cet article. Les routeurs attaquants peuvent aussi maintenir des connexions à la cible et lui fournir une excellente bande passante de transfert pour influencer le profilage effectué par la cible en apparaissant attractifs. D'autres recherches et protections sont nécessaires.
Nous utilisons la cryptographie forte à clés longues, et nous adoptons la sécurité des fonctions primitives des standards industriels pour I2P, comme détaillé sur la page concernant la cryptographie sous-jacente. Les fonctionnalités de sécurité incluent la détection immédiate de messages altérés, l'impossibilité de déchiffrer les messages qui ne vous sont pas destinés et la protection contre les attaques de type "usurpation d'identité" (man-in-the-middle). Les tailles de clés choisie en 2003 sont encore assez raisonnables aujourd'hui, et sont même plus longues que celles utilisées dans d'autres systèmes anonymes. Nous pensons que la longueur des clés n'est pas notre plus grosse faiblesse particulièrement pour les adversaires traditionnels ; les bogues et la petite taille du réseau sont plus inquiétants. Bien sûr, tous les algorithmes cryptographiques sont sujets à obsolescence à cause de l'apparition de processeurs plus rapides, de la recherche en cryptographie, et de méthodes comme celles des tables arc-en-ciel et des grappes de consoles de jeux vidéo, etc… Malheureusement, I2P n'a pas été conçu avec des mécanismes simples d'allongement des clés ou de changements de valeur de secrets partagés tout en conservant la compatibilité ascendante.
La mise à jour de diverses structures de données et protocoles en vue de supporter des clés plus longues devra sûrement être prise à bras le corps, et ce sera une entreprise majeure, tout comme ça le sera pour les autres systèmes. Heureusement, avec un planning soigneux, nous pouvons minimiser les interruptions de fonctionnement et implémenter des mécanismes de transition en douceur.
Prochainement, plusieurs protocoles et structures de données supporteront le bourrage sécurisé des messages à une taille arbitraire, en sorte que les messages aient une taille constante ou que les messages en tête d'ail puissent être modifiés aléatoirement pour que quelques gousses semblent contenir plus de sous-gousses qu'elles n'en contiennent réellement. Pour l'instant cependant, les têtes d'ail, les tunnels et les messages de bout en bout utilisent un simple bourrage aléatoire.
En plus des attaques de DdS par les diffuseurs décrites plus haut, les routeurs diffuseurs, sont dans une position privilégiée pour avoir connaissance des participants au réseau (du fait de leur rôle dans la base de données et du niveau élevé de communication qu'ils entretiennent avec les participants). Ceci est quand même pondéré à la baisse car les diffuseurs ne gèrent qu'une partie réduite de l'espace de clés total, et que celui-ci change tous les jours comme expliqué sur la page de la base de données du réseau. Les mécanismes particuliers par lesquels les routeurs communiquent avec les diffuseurs ont été soigneusement conçus. Ces menaces devraient cependant faire l'objet d'examens plus poussés. Des menaces potentielles spécifiques et les protections correspondantes sont un sujet de futures recherches.
Un utilisateur hostile pourrait tenter de perturber le réseau en créant un ou plusieurs diffuseurs trafiqués pour fournir de mauvaises réponses, voire des réponses lentes ou même aucune. Plusieurs scenarii sont examinés en détailsur sur la page de la base de données du réseau.
Il y a peu de ressources centrales susceptibles d'attaques ou d'y contribuer en tant que vectrices. L'absence de jrandom depuis novembre 2007, suivie de la perte du service d'hébergement de i2p.net en janvier 2008 ont mis en lumière les nombreuses ressources centralisées utilisées dans le développement et le fonctionnement d'I2P. La plupart d'entre elles sont maintenant décentralisées. Des attaques contre des ressources accessibles de l'extérieur affecteraient la facilité avec laquelle les nouveaux utilisateurs peuvent nous rejoindre, mais pas le fonctionnement du réseau lui-même.
Ces attaques n'ont pas directement lieu sur le réseau, mais concernent plutôt son équipe de développement, soit par l'introduction d'obstacles juridiques destinés à entraver quiconque participerait au développement du logiciel, soit par tout moyen disponible pour amener les développeurs à corrompre le logiciel. Les mesures techniques traditionnelles ne peuvent pas déjouer ces attaques et si quelqu'un menaçait la vie ou les moyens d'existence d'un développeur (ou même une injonction légale de cessation d'activité sous peine de prison), ça représenterait un très sérieux problème.
Nous avons deux moyens pour nous prémunir de ces attaques :
Malgré tous les efforts, la plupart des applications évoluées comportent des erreurs de conception ou de mise en œuvre, et I2P n'y fait pas exception. Il pourrait y avoir des bogues qui pourraient être exploités pour attaquer l'anonymat ou la sécurité des communications passant par I2P de façons inattendues. Pour aider à la résistance contre les conceptions et protocoles en usage, nous publions toutes les conceptions et la documentation, et nous sollicitons la critique et l'examen dans l'espoir que de nombreux avis amélioreront le système. Nous n'adhérons pas à l'idée de sécurité par l'obscurité.
De plus, le code est traité de la même façon, avec une légère aversion pour la révision ou l'expulsion pure et simple de quoi que ce soit qui ne concerne pas les besoins du système logiciel (y compris les facilités de modifications). La documentation de conception et d'implémentation du réseau et des composants logiciels est une partie essentielle de la sécurité, car sans elle il est peu probable que des développeurs aient envie d'investir beaucoup de temps pour assimiler suffisamment les arcanes du logiciel pour pouvoir y détecter des défauts et des bogues.
Notre logiciel est potentiellement porteur, en particulier, de bogues relatifs au déni de service jusqu'au dépassement de capacité mémoire (OoMs), aux problèmes de scripts inter-sites (XSS) dans la console et autre vulnérabilités aux entrées non standard via les divers protocoles.
I2P est encore un petit réseau avec une petite communauté de développement et ne bénéficiant de presque aucun intérêt de la part des recherches universitaires ou des groupes de chercheurs. En conséquence, nous manquons cruellement des mêmes travaux d'analyse dont ont bénéficié d'autres systèmes d'anonymat. Nous continuons à faire appel aux gens pour s'impliquer et nous aider.
Dans une certaine mesure, I2P pourrait être amélioré pour écarter les pairs opérant depuis des adresses IP recensées dans des listes de blocage. Plusieurs d'entre elles, aisément disponibles dans différent formats, listent les entités anti-P2P, les entités potentiellement pressenties pour pouvoir être des adversaires "state-level", et d'autres.
Dans la mesure où des pairs actifs apparaissent réellement dans les listes de blocage actuelles, leur blocage par une fraction seule des pairs conduirait à une segmentation du réseau, augmenterait les problèmes de joignabilité, et diminuerait la fiabilité globale. Nous devrions en conséquence nous accorder sur une liste particulière et l'activer par défaut.
Les listes de blocage ne sont qu'une partie (et même une petite partie) d'un arsenal de défenses contre la malignité. Le système de profilage, par son travail d'évaluation du comportement des routeurs, en prend une grosse partie à sa charge, de sorte que nous n'ayons pas besoin d'établir des relations de confiance particulières avec tel ou tel élément de la base de données. Cependant, on peut en faire plus : pour chacun des points listés ci-dessus, il y des améliorations à apporter pour en détecter la nocivité.
Si une liste de blocage est hébergée de façon centralisée, avec des mises à jour automatisées des routeurs, le réseau devient plus vulnérable aux attaques de ressources centrales. Des abonnements à une liste donne au fournisseur de la liste le pouvoir d'éteindre le réseau I2P. Complètement.
Actuellement, une liste de blocage par défaut est distribuée avec le logiciel, ne listant que les IP d'origine d'attaques de déni de service passées. Il n'y a pas de mécanisme de mise à jour automatique. Si une plage IP lançait une attaque sérieuse sur le réseau I2P, il nous faudrait, via des moyens extérieurs au champ de bataille (forums, blogs, etc…), demander aux utilisateurs de mettre à jour manuellement leur liste de blocage.
{% endblock %}