Raconte-moi le web!

Défenses relatives à l’attaque de la table du routage

• Défenses contre le routage incorrect

Il est heureusement plutôt facile de détecter certaines formes de tentatives d’envoi de données erronées de table de routage. A chaque HOP, l’application effectuant la recherche sait qu’elle doit normalement s’approcher du noeud cible. L’application doit donc vérifier ceci pour que l’attaque soit détectée. Si une telle attaque est détectée, l’application peut effectuer un backtrack vers le dernier hop réussi et demander une meilleure route alternative.

Une autre solution est d’utiliser les clés publiques. Ceci peut provoquer des charges supplémentaires du à l’utilisation des signatures. Mais ceci permet d’avoir confiance en l’origine des messages et leur validité. Les clés publiques facileront la vérification du système. En particulier, un noeud certifié peut être utilisé par les autres noeuds pour joindre en tout sécurité le système P2P.

• Défenses contre la mise à jour incorrecte de la table de routage

Pour pallier cette attaque, le système doit mettre en place certains critères pour la mise à jour des tables de routage. Ces critères pouvant alors être vérifiés.

Par exemple, le système Pastry demande à ce que chaque entrée d’une table de routage dispose d’un préfix correct. Certaines informations incorrectes peuvent être détecté de cette manière. Un autre critère est de vérifier qu’un noeud ne sera incorporé à la table de routage que lorsque le noeud original aura vérifié par lui-même que le noeud distant est existant.

• Défenses contre le partitionnement

Pour empêcher ceci, un nouveau noeud doit se connecter au réseau à travers un noeud certifié. Quand il rejoint un réseau, un noeud peut soit utiliser des noeuds certifiés, soit utiliser un des noeuds qu’elle a déjà utilisé par le passé. Le problème avec cette deuxième technique c’est qu’elle ne peut être appliquée dans un réseau avec des noeuds temporaires et transitoires, qui ne possède pas de véritable identité. L’utilisation des clés publiques peut fournir une solution à ce problème.

Si un noeud croit qu’il s’est correctement connecté par le passé. Il peut détecter les noeuds malicieux en comparant les résultats des différents noeuds. Un noeud peut donc maintenir une liste de noeuds qu’il a déjà utilisé par le passé, puis il effectue une comparaison des tables en utilisant des requêtes aléatoires. En demandant à sa liste de noeud d’effectuer des requêtes aléatoires puis en comparant les différents résultats avec son propre résultat, un noeud peut vérifier si sa vue du réseau est consistante avec les autres noeuds.

Défense contre les attaques relatives au stockage et à la récupération de données

Pour faire face à cette attaque, la couche de stockage doit implémenter la technique de réplication. La réplication doit être implémenté de sorte qu’il n’y ait pas qu’un seul noeud responsable de la réplication ou de l’accès aux réplicats. Les clients doivent être capable de déterminer de façon indépendante les noeuds qu’il faudrait contacter pour un replica. En résumé, il faudrait éviter de mettre tous les oeufs dans le même sac.

Popularité et classement des fichiers

Nous traiterons le système utilisé par le réseau eDonkey qui consiste à offrir la possibibité aux utilisateurs de donner des commentaires et des évaluations aux différents fichiers qu’ils ont téléchargés.

Ainsi, un utilisateur peut donner une évaluation et un commentaire à chaque fichier qu’il télécharge. Il peut par exemple indiquer qu’il s’agit d’un fichier erronné, ou d’un fichier de faible qualité.

Lorsqu’un autre utilisateur effectue une recherche par mot clé, il se verra donc afficher la liste des fichiers avec commentaires et évaluations, ce qui pourra l’aider à choisir le meilleur fichier dans la liste. C’est particulièrement utile lorsque plusieurs centaines de fichiers qui correspondent au même sujet apparaissent.

De nombreux réseaux de P2P utilisent la technique du hachage (Hashing). Le hachage d’un fichier peut être comparé à une empreinte digitale. Cette technique permet une identification, unique et certaine, du contenu de ce fichier, en n’utilisant qu’une faible quantité de données.

• Exemple du protocole eDonkey

Le protocole eDonkey/eMule utilise l’algorithme MD4 (message digests 4), dont la longueur est fixe de 16 octets (128 bits). Quelle que soit la taille du fichier, 10 octets, 20 kilo octets ou 1,5 giga octets, la valeur de hachage fait toujours 16 octets. Deux fichiers de même taille mais dont les contenus diffèrent ont des valeurs de hachage différentes (en théorie, car il y a toujours un très petit risque que deux contenus distincts produisent le même hachage. Toutefois, cet algorithme autorise 2^128 valeurs)

Le hachage du fichier représente donc l’identifieur ultime de son contenu.

Hachage des fichiers (Hash, File ID)

Le protocole prévoit que pour être mis en partage, chaque fichier doit être “découpé” en morceaux élémentaires. Ces entités élémentaires ont une taille de 9,28 Mo*. Seuls les morceaux complets et non corrompus sont partagés.

Ainsi, chaque fois qu’eMule termine le téléchargement d’un morceau, elle s’assure de l’absence de corruption des données. S’il est valide, il est proposé en partage.

Reconnaissance du morceau sur le réseau

Le morceau, tout comme n’importe quel fichier est reconnu, non par son nom (un morceau n’a pas de nom), mais par la valeur de son hachage. eMule applique l’algorithme MD 4 sur les données constitutives de chaque morceau élémentaire complet. Le résultat de cette opération est une valeur de hachage, unique.

Valeur de hachage d’un fichier

C’est la valeur obtenue en appliquant un algorithme MD4 aux valeurs de hachage de l’ensemble des morceaux qui le constituent.

Table de hachage

Lorsque l’on ajoute un téléchargement à eMule, la première source qui envoie des données envoie pour commencer la table de hachage (ou hash set) du fichier. C’est l’ensemble des valeurs de hachage de tous les morceaux qui constituent le téléchargement, la position précise du début et de la fin de chacun de ces morceaux et la valeur de hachage du fichier lui-même. Le fichier part.met est alors créé, en fonction des instructions de cette table. Le part.met est donc le plan permettant à eMule la construction du téléchargement.

Grâce à lui, elle sait si le morceau reçu est valide ou non (en comparant la valeur de son hachage à celui de la table de hachage) et où il doit se placer. Lorsque le téléchargement est achevé, toutes les valeurs de hachage des morceaux ont été vérifiées. Il ne reste plus à eMule qu’à calculer la valeur de hachage du fichier lui-même, en appliquant l’algorithme MD4 aux valeurs de tous les morceaux élémentaires. Puis à la comparer à la valeur reçue dans la table de hachage. Si elle est identique, le fichier est transféré dans le répertoire de réception et partagé.

L’algorithme MD4 est aussi utilisé pour générer d’autres identifiants nécessaires à eMule. Ainsi, chaque utilisateur du réseau est reconnu par la valeur de hachage qui lui est attribuée une fois pour toute, lors du premier lancement d’eMule et qui est sauvegardée dans le fichier preferences.dat.