i2p.www/www.i2p2/pages/how_threatmodel_fr.html

{% extends "_layout_fr.html" %}
{% block title %}Modèle des menaces pour I2P{% endblock %}
{% block content %}
Traduction d'avril 2011 (en cours). <a href="how_threatmodel.html">Version anglaise actuelle</a><br /><br />
Mise à jour de novembre 2010, valide pour la version 0.8.1 du routeur
<h2>Ce que nous entendons par "anonyme"</h2>

<p>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.</p>  

<p>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.</p>

<p>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.</p>

<h2>Résumé de la topologie du réseau</h2>
<p>I2P germe des idées de nombreux <a href="how_networkcomparisons">autres</a> <a href="links_fr">systèmes</a>, mais 
il faut garder à l'esprit un petit nombre de points essentiels quand on examine la littérature concernée :</p><ul>
<li><b>I2P est un réseau croisé sur routes libres</b> - le créateur du message définit explicitement le chemin par 
lequel celui-ci sera envoyé (le tunnel sortant), et le destinataire du message définit explicitement le chemin par 
lequel le message sera reçu (le tunnel entrant).
</li>
<li><b>I2P n'a aucuns points d'entrée ou de sortie officiels</b> - tous les pairs participent intégralement au 
maillage, et il n'y a pas de mandataires entrants ou sortants au niveau de la couche réseau (il en existe cependant 
quelques-uns au niveau de la couche application)</li>
<li><b>I2P est entièrement décentralisé</b> - il n'y a pas de contrôles ou d'autorités centrales : quelqu'un pourrait, 
sans briser la compatibilité avec le reste du réseau, modifier quelques routeurs en vue de contrôler une partie de la 
chaîne de maillage (en construisant les tunnels et en maîtrisant les clés nécessaires au pilotage du transfert au 
niveau du point terminal du tunnel) ou élaborer une sélection basée sur un profilage des informations d'annuaire, mais 
ceci n'est bien sûr pas nécessaire (et pourrait même réduire son anonymat à néant).</li>
</ul>
<p>
   Nous avons des plans documentés de mise en œuvre de <a href="todo_fr#stop">retards conséquents</a> et 
de <a href="todo_fr#batching">stratégies traitements par lots</a> 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.</p>
<p>
  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.
</p>


<h2>Le modèle de menaces (Attaques)</h2>
<p>
La conception d'I2P a commencé en 2003, juste après l'apparition de l'
<a href="http://www.onion-router.net">[Onion Routing]</a>, de <a href="http://freenetproject.org/">[Freenet]</a>, et de 
<a href="http://www.torproject.org/">[Tor]</a>. 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.</p>
<p>
Inspirée des attaques et analyses mises en avant dans <a href="http://freehaven.net/anonbib/topic.html">littérature</a> 
(particulièrement <a href="http://citeseer.ist.psu.edu/454354.html">Traffic Analysis: Protocols, Attacks, Design Issues 
and Open Problems</a>), 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.
</p><p>
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.</p>
<p>
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.</p>
<p>
Les pages sur la <a href="how_networkcomparisons.html">comparaison des réseaux</a> et la 
<a href="how_garlicrouting.html">terminologie des "gousses d'ail"</a> apportent aussi un éclairage complémentaire.
</p>

<h3 id="index">Index</h3>
<ul>
<li><a href="#bruteforce">Force brute</a></li>
<li><a href="#timing">Attaques de timing</a></li>
<li><a href="#intersection">Attaques d'intersection</a></li>
<li><a href="#dos">Deni de service</a></li>
<li><a href="#tagging">Attaques par marquage</a></li>
<li><a href="#partitioning">Attaques par cloisonnement</a></li>
<li><a href="#predecessor">Attaques de prédécesseur</a></li>
<li><a href="#harvesting">Attaques de collecte</a></li>
<li><a href="#traffic">Identification via l'analyse du trafic</a></li>
<li><a href="#sybil">Attaques de Sibylle</a></li>
<li><a href="#buddy">Attaques de listage de complices</a></li>
<li><a href="#crypto">Attaques cryptographiques</a></li>
<li><a href="#floodfill">Attaques de la part des diffuseurs</a></li>
<li><a href="#netdb">Autres attaques de base de données</a></li>
<li><a href="#central">Attaques des ressources centralisées</a></li>
<li><a href="#dev">Attaques de développement</a></li>
<li><a href="#impl">Attaques d'implémentation</a></li>
</ul>

<h3 id="bruteforce">Force brute</h3>

<p>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).</p>

<p>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 : 
<a href="http://citeseer.ist.psu.edu/freedman02tarzan.html">Tarzan</a> 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.
</p><p>
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 
<a href="how_peerselection.html">sélection des pairs</a>.
</p>



<h3 id="timing">Attaques de timing</h3>

<p>Les messages I2P sont unidirectionnels et d'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é.</p>

<p>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).</p>

<p>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 
<a href="todo_fr#stop">retards non négligeables</a> ou les 
<a href="todo_fr#batching">stratégies de traitement par lots</a>), le camouflage de protocole, ou d'autres 
<a href="todo_fr#batching">techniques</a> de routage en tunnel avancées, mais celles-ci ne sont pas implémentées dans 
I2P.
</p>

<p>Références:
<a href="http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf">Low-Resource Routing 
Attacks Against Anonymous Systems</a>
</p>

<h3 id="intersection">Attaques d'intersection</h3>

<p>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.</p>
  
<p>
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 
<a href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatattacksremainagainstonionrouting">
même mise en garde</a>.
</p><p>
Défenses partielles implémentées dans I2P :
<ul><li>
<a href="tunnel-alt.html#ordering">Tri strict</a> des pairs
</li><li>
<a href="how_peerselection.html">Profilage et sélection des pairs</a> à partir d'un petit groupe qui change peu souvent
</li><li>
Limitation du nombre de tunnels routés par un seul pair
</li><li>
Empêchement des pairs d'une même plage d'adresses IP /16 d'être membres d'un même tunnel
</li><li>
Pour les eepsites et autres services hébergés, nous fournissons la possibilité d'hébergement simultané sur de multiples 
routeurs ou <a href="#intersection">multi-résidence</a>
</li></ul>

Même prises ensemble, ces protections ne constituent pas une réponse complète. Aussi avons-nous pris quelques décisions 
de conception qui peuvent sensiblement augmenter notre vulnérabilité:
<ul><li>
Nous n'utilisons pas les "guard nœuds" à faible bande passante.
</li><li>
Nous utilisons des groupes de tunnels constitués de plusieurs tunnels, et le trafic peut basculer d'un tunnel à l'autre.
</li><li>
Les tunnels ont une durée de vie courte ; de nouveaux tunnels sont construits toutes les 10 minutes.
</li><li>
Les longueurs des tunnels sont configurables. Les tunnels à 3 sauts sont recommandés pour une protection complète, 
mais plusieurs applications et services utilisent par défaut des tunnels à 2 sauts.
</li></ul>


</p><p>
Dans le futur, on peut envisager d'utiliser pour les pairs qui peuvent se le permettre, utiliser des délais importants 
(via les <a href="todo_fr#stop">retards volontaires</a> et les <a href="todo_fr#batching">stratégies de traitement par 
lots</a>). 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.</p>

<p>Référence:
<a href="http://blog.torproject.org/blog/one-cell-enough">One Cell Enough</a>
</p>



<h3 id="dos">Déni de service</h3>

<p>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 :</p><ul>
<li><b>L'attaque du goinfre :</b> c'est simplement celui qui essaye de consommer beaucoup plus de ressources qu'il n'en 
fournit. Les parades : <ul>
    <li>Définir les réglages par défaut de telle sorte que les utilisateurs fournissent des ressources au réseau. Dans 
I2P, les utilisateurs font par défaut du routage de trafic. À la différence radicale avec 
d'<a href="https://torproject.org/">autres réseaux</a>, jusqu'à 95% des utilisateurs d'I2P relaient du trafic pour les 
autres.
   </li>
    <li>Fournir des options de configuration simples à utiliser pour que les utilisateurs puissent augmenter leur 
contribution au réseau (pourcentage de partage). Afficher des mesures simples à comprendre comme le ratio de partage 
pour permettre aux utilisateur de voir en quoi ils contribuent.
   </li><lil>
     Maintenir une forte communauté grâce à des blogs, des forums, l'IRC, et autres moyens de communication.
   </li></ul>
<li><b>L'attaque de la famine :</b> l'utilisateur hostile peut tenter de vicier le réseau en créant un grand nombre de 
pairs n'étant bien sûr pas identifiés comme contrôlés par la même entité (comme avec l'attaque de Sibylle). Ces nœuds 
décident alors comme un seul homme de ne fournir aucunes ressources au réseau, conduisant alors les autres pairs à 
faire leurs recherches dans une base de données plus grande ou demander plus de tunnels qu'il ne serait nécessaire. 
L'apprenti nazillon pourrait aussi fournir un service erratique en abandonnant régulièrement une sélection de trafic ou 
en refusant les connexions à certains pairs. Ce comportement peut être indiscernable de celui d'un nœud surchargé ou 
défaillant. I2P gère ces problèmes en maintenant des <a href="how_peerselection.html">profils</a> sur les pairs, en 
tentant d'identifier les nœuds anémiés pour les ignorer purement et simplement, ou les utiliser rarement. Nous avons 
sensiblement amélioré la capacité à reconnaître et éviter les pairs à performances réduites, mais il reste pas mal 
d'efforts à fournir de ce côté là.
</li>
<li><b>Attaque par inondation :</b> l'utilisateur hostile peut tenter de noyer le réseau, un pair, une destination ou 
un tunnel. l'inondation d'un pair ou du réseau est possible, et I2P ne fait rien pour empêcher le bombardement de la 
couche IP. La tentative de faire boire un bouillon de messages à une destination par plusieurs de ses passerelles de 
tunnels entrants est également possible, mais elle en sera avertie aussi bien par le contenu des messages que par 
l'échec des tests de tunnels. La même analyse concerne aussi les tentatives d'engorgement d'un tunnel donné. I2P n'a 
pas de défense contre les attaques par inondation. Quand la cible est une destination ou un tunnel, elle identifie le 
tunnel constipé et en crée d'autres. Du nouveau code pourrait permettre d'ajouter encore plus de tunnels si le client 
souhaite gérer la charge plus forte. D'un autre côté, si la charge est supérieure à ce que le client peut gérer, il 
pourrait indiquer aux tunnels de brider le nombre de messages ou d'octets qu'ils devraient passer (une fois les 
<a href="todo_fr#batching">fonctions de tunnels avancées</a> implémentées).</li>
<li><b>Attaques de charge CPU :</b> il existe actuellement quelques méthodes pour demander à un pair distant 
d'exécuter de coûteux calculs cryptographiques, et un attaquant pourrait essayer d'en surcharger un pair pour mettre 
son UC à genoux. L'utilisation de bonnes pratiques d'ingénierie, éventuellement conjointes à des certificats peu 
courants (p.e. les pénalités HashCash) rattachées à ces requêtes de travaux coûteux, devraient limiter le problème, 
bien qu'il puisse rester des possibilités pour un attaquant d'exploiter divers bogues dans l'implémentation.</li>
<li id="ffdos"><b>Attaque DOS par des diffuseurs :</b> un autre attaquant (ou le même, décidément sa mère a confondu la 
salle d'accouchement et les chiottes) pourrait essayer de perturber le réseau en devenant un routeur diffuseur. Les 
protections actuelles contre les diffuseurs non fiables, intermittents ou pervers sont faibles. Un diffuseur peut 
fournir de mauvaises réponses aux requêtes ou pas de réponse du tout, et il peut aussi interférer avec la communication 
inter-diffuseurs. Quelques défenses et le <a href="how_peerselection">profilage de pairs</a> sont implémentés, mais il 
ne reste pas grand chose à faire. Pour plus d'informations, voir la page 
<a href="how_networkdatabase.html#threat">base de données du réseau</a>.
</li>
</ul>

<h3 id="tagging">Attaques par marquage</h3>
<p>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 <a href="todo_fr#tunnelId">identifiants uniques de 
tunnels</a> 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.</p>

<h3 id="partitioning">Attaques par cloisonnement</h3>

<p>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).</p>

<p>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 
<a href="#harvesting">collecte</a> 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 
<a href="todo_fr#stop">retards non négligeables</a> et des <a href="todo_fr#batching">stratégies de traitement par 
lots</a>, 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).
</p><p>
Également discuté sur la page <a href="how_networkdatabase.html#threat">base de données du réseau</a> 
(attaque d'amorçage).
</p>

<h3 id="predecessor">Attaques de prédécesseur</h3>

<p>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.</p>

<p>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 <a href="how_peerselection">sélection des pairs</a> 
qui les répartit en groupes. Puis avec le <a href="tunnel-alt.html#ordering">tri strict</a> 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 
<a href="tunnel-alt.html#length">longueur de tunnel permutée</a> (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 <a href="todo_fr#fullRestrictedRoutes">routes réservées</a> (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.</p>
<p>
La <a href="tunnel-alt-creation.html">méthode de construction des tunnels</a> actuelle a été spécifiquement conçue pour 
parer aux attaques de prédécesseur. Voir aussi l'<a href="#intersection">attaque d'intersection</a>.
</p>

<p>Références:
<a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">
http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf</a> qui est une mise à jour de 2008 de la publication sur 
l'attaque de prédécesseur 
<a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">
http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf</a>.
</p>


<h3 id="harvesting">Attaques de collectes</h3>
<p>
"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.</p>
<p>
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 :
<ul><li>
La croissance du réseau rend encore plus difficile l'obtention d'une portion donnée du réseau.
</li><li>
Les routeurs diffuseurs ont des limites pour les requêtes comme protection contre les attaques de déni de service.
</li><li>
Le "mode caché", qui empêche un routeur de se publier dans la base de données (mais l'empêche aussi de relayer), n'est 
pas actuellement très utilisé, mais il pourrait l'être.
</li></ul>
Dans de futures implémentations, grâce aux routes réservées <a href="todo_fr#nat">basiques</a> et 
<a href="todo_fr#fullRestrictedRoutes">complètes</a>, ce type d'attaques perdra beaucoup de son efficacité, car les 
pairs "cachés" ne publient pas leurs adresses de contact dans la base de données - mais uniquement les tunnels par 
lesquels on peut les atteindre, leurs clés publiques, etc&hellip;)</p>
<p>
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.</p>



<h3 id="traffic">Identification par analyse de trafic</h3>
<p>
En surveillant le trafic d'un routeur, un FAI sans scrupule ou un pare-feu  
<a href="http://fr.wikipedia.org/wiki/Pare-feu_%28informatique%29#Pare-feu_.C3.A0_.C3.A9tats_.28
stateful_firewall.29">à état</a> pourrait déterminer qu'un ordinateur utilise I2P. Comme expliqué ci-dessus 
<a href="#harvesting">(collecte)</a>, I2P n'est pas conçu pour se cacher lui-même. Cependant, certaines décisions de 
conception du transport <a href="transport.html">(couche et protocole)</a> rendent l'identification du trafic I2P 
difficile :<ul><li>
Sélection de port aléatoire.
</li><li>
Cryptage de bout en bout de tout le trafic.
</li><li>
Échange de clé Diffie-Hellman sans octets de protocole ou autres champs de constantes non cryptés.
</li><li>
Utilisation simultanée des transports <a href="ntcp.html">TCP</a> et <a href="udp.html">UDP</a>. UDP est plus difficile 
à suivre pour les équipements d'analyse détaillée de paquets (DPI).
</li></ul>

Nous prévoyons dans un avenir proche de régler le problème d'analyse du trafic par d'autres moyens de brouillage des 
protocoles de transport I2P, éventuellement :
<ul><li>
Bourrage/remplissage au niveau de la couche transport à des longueurs aléatoires, particulièrement pendant les poignées 
de main (handshake).
</li><li>
Étude de la signature de distribution des tailles de paquets, et bourrage supplémentaire si nécessaire.
</li><li>
Développement de méthodes de transport supplémentaires qui miment SSL ou d'autre protocoles communs.
</li><li>
Examen des stratégies de bourrage aux niveaux supérieurs pour voir si elles impactent la taille des paquets au niveau 
de la couche transport.
</li><li>
Examen des méthodes implémentées par les pare-feux à état pour bloquer Tor.
</li><li>
Collaboration directe avec les experts de l'analyse approfondie des paquets et du brouillage.
</li></ul>
</p><p>
Références:
<a href="http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf">Breaking and Improving Protocol 
Obfuscation</a>
</p>



<h3 id="sybil">Attaques de Sibylle</h3>

<p>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, 
<a href="http://www.pdos.lcs.mit.edu/tarzan/">Tarzan</a> se sert de la limite des adresses IP, alors qu'IIP utilisait 
les pénalités <a href="http://www.hashcash.org/">HashCash</a> 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é).
</p><p>
La nécessité de certificats pénalisants à divers endroits a deux défauts majeurs :
<ul><li>
L'incompatibilité ascendante.
</li><li>
Le défaut principal des systèmes de pénalités - le choix de valeurs significatives pour les machine de dernier cri, 
tout en restant à la portée des machines d'entrée de gamme comme les appareils portables.
</li></ul>
</p><p>
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.
</p><p>
Voir la page sur la <a href="how_networkdatabase.html#threat">base de données du réseau</a> sur le sujet des attaques 
de type Sibylle.
</p>


<h3 id="buddy">Attaques par listage de complices</h3>
<p>
  (Référence:
  <a href="https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf">In Search of an Anonymouns 
and Secure Lookup</a> Section 5.2)
</p>
<p>
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 <a href="#sybil">méthode Sibylle</a>. Ceci est diminué par 
nos méthodes de <a href="how_peerselection">profilage des pairs</a> utilisées pour surveiller leurs performances. Mais 
ça reste une attaque efficace quand le nombre de routeurs approche de <i>f</i> = 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.
</p>


<h3 id="crypto">Attaques cryptographiques</h3>

<p>
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 
<a href="how_cryptography">cryptographie sous-jacente</a>. 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'<a href="https://torproject.org/">autres systèmes anonymes</a>. 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 
<a href="http://fr.wikipedia.org/wiki/Table_arc-en-ciel">tables arc-en-ciel</a> et des grappes de consoles de jeux 
vidéo, etc&hellip; 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.
</p><p>
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 <a href="how_cryptography">entreprise majeure</a>, 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.
</p><p>
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.</p>

<h3 id="floodfill">Attaques de l'anonymat de la part des diffuseurs</h3>
<p>
En plus des attaques de DdS par les diffuseurs décrites <a href="#ffdos">plus haut</a>, 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 
<a href="how_networkdatabase.html#threat">base de données du réseau</a>. Les mécanismes particuliers par lesquels les 
routeurs communiquent avec les diffuseurs ont été <a href="how_networkdatabase.html#delivery">soigneusement conçus</a>. 
Ces menaces devraient cependant faire l'objet d'examens plus poussés. Les menaces potentielles spécifiques d'I2P et les 
protections correspondantes sont un sujet de futures recherches.
</p>


<h3 id="netdb">Other Network Database attacks</h3>
<p>
  A hostile user may attempt to harm the network by
  creating one or more floodfill routers and crafting them to offer
  bad, slow, or no responses.
  Several scenarios are discussed on the
  <a href="how_networkdatabase.html#threat">network database page</a>.
</p>



<h3 id="central">Central Resource Attacks</h3>
<p>
There are a few centralized or limited resources (some inside I2P, some not)
that could be attacked or used as a vector for attacks.
The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008,
highlighted numerous centralized resources in the development and operation of the I2P network,
most of which are now distributed.
Attacks on externally-reachable resources mainly affect the ability of new users to find us,
not the operation of the network itself.
<ul>
<li>The <a href="/">website</a> is mirrored and uses DNS round-robin for external public access.
<li>Routers now support <a href="faq.html#reseed">multiple external reseed locations</a>,
    however more reseed hosts may be needed, and the handling of unreliable or malicious
    reseed hosts may need improvement.
<li>Routers now support multiple update file locations.
    A malicious update host could feed a huge file, need to limit the size.
<li>Routers now support multiple default trusted update signers.
<li>Routers now better handle <a href="#ffdos">multiple unreliable floodfill peers</a>.
    Malicious floodfills <a href="#ffdos">needs</a> <a href="#floodfill">more</a> study.
<li>The code is now stored in a <a href="monotone.html">distributed source control system</a>.
<li>Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
    A malicious news host could feed a huge file, need to limit the size.
<li><a href="naming.html">Naming system services</a>, including addressbook subscription providers, add-host services,
    and jump services, could be malicious. Substantial protections for subscriptions were implemented
    in release 0.6.1.31, with additional enhancements in subsequent releases.
    However, all naming services require some measure of trust, see
    <a href="naming.html">the naming page</a> for details.
<li>We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
    disruption in our ability to attract new users,
    and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
</ul>


<h3 id="dev">Development attacks</h3>

<p>
These attacks aren't directly on the network, but instead go after its development team 
by either introducing legal hurdles on anyone contributing to the development
of the software, or by using whatever means are available to get the developers to 
subvert the software.  Traditional technical measures cannot defeat these attacks, and
if someone threatened the life or livelihood of a developer (or even just issuing a 
court order along with a gag order, under threat of prison), we would have a big problem.
</p>

<p>
However, two techniques help defend against these attacks:
<ul>
<li> All components of the network must be open source to enable inspection, verification, 
     modification, and improvement.  If a developer is compromised, once it is noticed 
     the community should demand explanation and cease to accept that developer's work.
     All checkins to our <a href="monotone.html">distributed source control system</a>
     are cryptographically signed, and the release packagers use a trust-list system
     to restrict modifications to those previously approved.
</li>
<li> Development over the network itself, allowing developers to stay anonymous but still 
     secure the development process.  All I2P development can occur through I2P - using
     a <a href="monotone.html">distributed source control system</a>,
     a distributed source control system, IRC chat,
     public web servers,
     discussion forums (forum.i2p), and the software distribution sites,
     all available within I2P.</li>
</ul>
We also maintain relationships with various organizations that offer legal advice,
should any defense be necessary.
</p>

<h3 id="impl">Implementation attacks (bugs)</h3>
<p>
Try as we might, most nontrivial applications include errors in the design or 
implementation, and I2P is no exception.  There may be bugs that could be exploited to 
attack the anonymity or security of the communication running over I2P in unexpected 
ways.  To help withstand attacks against the design or protocols in use, we publish 
all designs and documentation and solicit review and criticism with 
the hope that many eyes will improve the system.
We do not believe in
<a href="http://www.haystacknetwork.com/">security through obscurity</a>.
</p><p>
In addition, the code is being 
treated the same way, with little aversion towards reworking or throwing out 
something that isn't meeting the needs of the software system (including ease of 
modification).  Documentation for the design and implementation of the network and 
the software components are an essential part of security, as without them it is 
unlikely that developers would be willing to spend the time to learn the software 
enough to identify shortcomings and bugs.
</p><p>
Our software is likely, in particular, to contain bugs related to denial of service
through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues  in the router console,
and other vulnerabilities to non-standard inputs via the various protocols.
</p><p>
I2P is still a small network with a small development community and almost no
interest from academic or research groups.
Therefore we lack the analysis that
<a href="https://torproject.org/">other anonymity networks</a>
may have received. We continue to recruit people to
<a href="getinvolved.html">get involved</a> and help.
</p>




<h2>Other Defenses</h2>
<h3 id="blocklist">Blocklists</h3>
<p>
To some extent, I2P could be enhanced to avoid peers operating at IP addresses
listed in a blocklist. Several blocklists are commonly available in standard formats,
listing anti-P2P organizations, potential state-level adversaries, and others.
<p>
To the extent that active peers actually do show up in the actual blocklist,
blocking by only a subset of peers would tend to segment the network,
exacerbate reachability problems, and decrease overall reliability.
Therefore we would want to agree on a particular blocklist and
enable it by default.

<p>
Blocklists are only a part (perhaps a small part) of an array of defenses
against maliciousness.
In large part the profiling system does a good job of measuring
router behavior so that we don't need to trust anything in netDb.
However there is more that can be done. For each of the areas in the
list above there are improvements we can make in detecting badness.
<p>
If a blocklist is hosted at a central location with automatic updates
the network is vulnerable to a
<a href="#central">central resource attack</a>.
Automatic subscription to a list gives the list provider the power to shut
the i2p network down. Completely.
<p>
Currently, a default blocklist is distributed with our software,
listing only the IPs of past DOS sources.
There
is no automatic update mechanism.
Should a particular IP range implement serious attacks on the I2P network,
we would have to ask people to update their blocklist manually through
out-of-band mechanisms such as forums, blogs, etc&hellip;
</p>


{% endblock %}