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. <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 au niveau du développement</a></li>
<li><a href="#impl">Attaques d'implémentation</a></li>
<li><a href="#blocklist">Autres défenses et protections</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 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é.</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 de nœuds flics à 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. Des menaces potentielles spécifiques et les 
protections correspondantes sont un sujet de futures recherches.
</p>


<h3 id="netdb">Autres attaques de la base de données</h3>
<p>
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 <a href="how_networkdatabase.html#threat">détail</a>sur sur la page de la base de données du réseau.
</p>



<h3 id="central">Attaques de ressources centrales</h3>
<p>
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.
<ul>
<li>Le <a href="/">site web</a> dispose de miroirs et utilise le round-robin DNS pour l'accès public externe.
<li>Les routeurs supportent maintenant des <a href="faq_fr.html#reseed">sources de réamorçage multiples</a>, mais plus 
d'hôtes de réamorçage pourraient devenir nécessaires, et la gestion de ceux d'entre eux qui seraient peu fiables ou 
carrément vénéneux devrait faire l'objet d'améliorations.
<li>Les routeurs supportent aussi plusieurs lieux de mise à jour. Un hôte de mise à jour vérolé pourrait délivrer un 
fichier énorme, il nous faut limiter la taille.
<li>Les routeurs supportent maintenant par défaut de multiples signataires de mise à jour.
<li>Ils ont aussi une meilleure gestion des <a href="#ffdos">multiples pairs diffuseurs non fiables</a>. Le problème 
des diffuseurs hostiles doit faire l'<a href="#ffdos">objet</a> d'une étude <a href="#floodfill">supplémentaire</a>.
<li>Le code est maintenant stocké dans un <a href="monotone.html">système de contrôle de versions décentralisé</a>.
<li>Les routeurs se reposent sur un seul hôte pour les news, mais il y a une URL de secours codée en dur qui pointe sur 
autre hôte. Un hôte corrompu pourrait fourguer un fichier monstrueux, il nous faut verrouiller ça.
<li>Les <a href="naming_fr.html">services systèmes de nommage</a>, dont les fournisseurs d'abonnements du carnet 
d'adresses, les services d'ajout d'hôtes et les services de saut pourraient être corrompus. Des protections 
conséquentes pour les abonnements on été mises en place dans la version 0.6.1.31, avec d'autres améliorations dans les 
versions suivantes. Cependant, tous les services de nommage ont besoin de quelque mesure de confiance. Voir les détails 
dans la page sur le <a href="naming_fr.html">nommage</a>.
<li>Nous restons dépendants de DNS pour le domaine i2p2.de, et sa défaillance pourrait causer une perte substantielle à 
notre capacité d'attirer de nouveaux utilisateurs, et pourrait restreindre le réseau à court et moyen terme comme le 
fit la perte d'i2p.net.</ul>


<h3 id="dev">Attaques au niveau du développement</h3>

<p>
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.</p>
<p>
Nous avons deux moyens pour nous prémunir de ces attaques :
<ul>
<li> Tous les éléments du réseau doivent être open-source pour permettre leur inspection, vérification, modification, 
et amélioration. Si un développeur est compromis, la communauté, une fois avertie, devrait demander des explications et 
refuser d'accepter ses contributions. Toutes les adjonctions à notre <a href="monotone.html">SCV</a> sont numériquement 
signées, et les publieurs de nouvelles version utilisent un système de liste de confiance pour restreindre les 
possibilités de modifications à ceux précédemment approuvés.</li>
<li>Le développement se fait sur le réseau lui-même, ce qui permet aux développeurs de rester anonymes mais renforce 
encore la sécurité du processus de développement. Tout le développement d'I2P peut se faire via I2P - par l'utilisation 
du <a href="monotone.html">SCV</a> que nous avons choisi, l'IRC, des serveurs web publics, des forums de discussion 
(forum.i2p), et les sites de distribution du logiciel, tous disponibles dans I2P.</li>
</ul>
Nous entretenons des relations avec diverses organisations qui offrent du conseil juridique, s'il advenait jamais 
qu'une protection devienne nécessaire.</p>

<h3 id="impl">Attaques sur l'implémentation (bogues)</h3>
<p>
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 
<a href="http://www.haystacknetwork.com/">sécurité par l'obscurité</a>.</p>
<p>
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.</p>
<p>
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.</p>
<p>
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'<a href="https://torproject.org/">autres systèmes d'anonymat</a>. Nous 
continuons à faire appel aux gens pour <a href="getinvolved_fr.html">s'impliquer</a> et nous aider.
</p>




<h2>Autres protections</h2>
<h3 id="blocklist">Listes de blocage</h3>
<p>
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.
<p>
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.
<p>
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é.
<p>
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 <a href="#central">attaques de ressources centrales</a>.
Des abonnements à une liste donne au fournisseur de la liste le pouvoir d'éteindre le réseau I2P. Complètement.
<p>
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&hellip;), demander aux utilisateurs de mettre à jour manuellement leur liste de blocage.
</p>


{% endblock %}