Partage de fichiers en pair à pair - Définition

Technique

Débuts du Pair-à-pair : Les systèmes centralisés

Les systèmes centralisés sont donc les premiers systèmes pair-à-pair à voir le jour, dès juin 1999 avec Napster. Il fut suivi d'autres protocoles du même type, comme DirectConnect (qui a évolué en DC++). Le système Napster propose le téléchargement de fichiers musicaux, mais il n'est pas encore formellement pair-à-pair, puisqu'il repose sur l'utilisation d'un serveur stable pour la mise en relation des utilisateurs. Le créateur de Napster fut pour cela rapidement attaqué en justice par de grands distributeurs de musique comme EMI-Time-Warner.

Napster est un système de partage de fichiers où les objets partagés (des fichiers), sont gérés par 50 à 150 serveurs index virtuellement regroupés en un seul méta-serveur routant les nouveaux nœuds vers un des serveurs de ce méta-serveur.

Les serveurs contiennent les titres de fichiers hébergés par le réseau et l'adresse des nœuds qui les mettent à disposition. Ils peuvent aussi jouer le rôle de censeurs : par exemple, dans Napster, seul était autorisé le partage de fichiers audio de format mp3. Pour affirmer cela, les analyses du protocole de Napster sont basées sur la rétro-ingénierie, le protocole Napster n'ayant pas été officiellement diffusé.

Ces analyses ont permis la création de logiciels client-serveur libres, comme Lopster, Xnap ou Teknap, mais aussi de non libres tels que WinMX. Divers serveurs libres ont également vu le jour comme OpenNap et OpenNap-ng. Ces derniers permettaient de choisir les fichiers partagés, ôtant ainsi la limitation aux fichiers mp3.

Dans Napster, lorsqu'un nœud recherche un objet (un fichier), il envoie au serveur une requête sous forme d'une chaîne de caractères afin de trouver tous les fichiers dont le titre contient cette chaîne. Le serveur répond alors par une liste de nœuds hébergeant l'un de ces fichiers. La recherche peut être limitée au serveur auquel est connecté le nœud demandeur, ou être lancée sur tous les serveurs à la fois. L'échange du fichier s'effectue ensuite directement entre le pair qui héberge le fichier et le pair qui le demande. Seule l'étape du transfert de fichier diffère du modèle client-serveur. L'architecture de ce type de système permet ainsi de partager les mêmes fichiers sur des nœuds différents.

Ce type de systèmes ne permet pas un bon équilibre de charge, car l'évolution du nombre de serveurs supporte difficilement celle du nombre d'utilisateurs, augmentant bien plus rapidement. Ce qui rend difficile l'acceptation de nouveaux utilisateurs au-delà d'une certaine limite. Par ailleurs, cette centralisation créé un maillon faible qui rend ces types de systèmes particulièrement sensibles à des attaques de type déni de service, qui peuvent aller jusqu'à rendre le système inutilisable.

Cette centralisation fut le talon d'achille de Napster : il aura suffit d'attaquer juridiquement le propriétaire des quelques serveurs pour entraîner la destruction de tout le système. La protection contre la censure et la défense de l'anonymat des utilisateurs ne pouvaient être assurées correctement par des systèmes centralisés puisqu'il suffit de contrôler le serveur pour censurer les nœuds, ou de les identifier pour obtenir toutes les informations relatives à leurs activités sur le réseau.

Toutefois, la centralisation permet d'assurer une exhaustivité des réponses, c'est-à-dire que si une réponse existe, elle sera trouvée car chaque serveur connaît tout le réseau. Elle permet également d'assurer une authentification des fichiers partagés de manière simple. L'existence d'un serveur permet aussi de contourner la difficulté posée par les pare-feux, mais le coût pour chaque serveur est tel que cette solution fut abandonnée dans la plupart des systèmes centralisés.

Vers une dissémination des serveurs : Les systèmes semi-décentralisés

À la suite des systèmes centralisés sont apparus des systèmes créés pour rendre les recherches d'objets plus efficaces. En effet, si les systèmes hybrides permettent de décentraliser la recherche et la récupération d'objets, ils peinent à rendre des résultats lorsque le nombre d'utilisateurs augmente. En effet, dans ces systèmes, la méthode de recherche est basée sur une inondation bornée, c'est-à-dire un envoi systématique de la recherche à tous les utilisateurs connectés à distance inférieure à une borne fixée. Au fur et mesure que le nombre de noeuds du réseau augmente, ainsi que le nombre d'objets dans le réseau, l'inondation bornée touche proportionnellement de moins en moins de noeuds du réseau et donc de moins en moins d'objets du réseau. Cela diminue la probabilité de trouver une réponse. La solution consistant à augmenter la borne de l'inondation n'est pas satisfaisante car elle augmente la charge du réseau de manière exponentielle. Or la philosophie d'un système pair-à-pair repose a priori sur une augmentation des performances et de l'efficacité au fur et à mesure qu'augmente le nombre de noeuds participants, donc le nombre d'objets.

C'est pourquoi des systèmes basés sur des interconnexions de serveurs stables, comme eDonkey en juin 2000, KaZaA en 2001, ou eMule en mai 2002 (utilisant initialement le protocole eDonkey), ont été conçus pour améliorer les résultats de recherche.

Chaque nœud non serveur, appelé feuille, est connecté à un serveur. Ces serveurs sont stables, et gèrent un très grand nombre de nœuds (jusqu'à un million de nœuds pour eMule par exemple). Ils n'ont pas besoin de communiquer entre eux, et ne partagent aucun fichier. Les objets partagés par une feuille sont enregistrés sur le serveur responsable de cette feuille. Lorsqu'une feuille recherche un objet, elle envoie sa requête à son serveur. Celui-ci effectue alors la recherche parmi les objets des nœuds qui lui sont connectés. Le rôle de l'interconnexion peut varier selon les protocoles. Il n'a pas vocation à servir pour diffuser des requêtes, mais a plutôt un rôle de calcul de statistiques, ou de maintien de la liste des serveurs en fonctionnement par exemple. Ce système perd en décentralisation ce qu'il gagne en finesse et en nombre de résultats. En effet, la centralisation permet de bénéficier de recherches plus fines sur des serveurs regroupant un grand nombre de noeuds donc de fichiers. Plusieurs dizaines de serveurs permettent d'assurer une continuité dans le service.

KazaA

Fut un logiciel de P2P basé sur le réseau FastTrack, de même que les clients iMesh et Grokster. Ce logiciel fut le premier à offrir une décentralisation de serveur : Les fichiers partagés sont stockés dans un dossier spécialisé, ce dossier étant sur l’ordinateur de chaque utilisateur. Le principe de fonctionnement est grossièrement semblable à eMule et à son protocole Kademlia. Sans serveur central, l’indexation des contenus partagés de tous les utilisateurs devient difficile. FastTrack aura pour cela recours à l’utilisation des superpeers, une fonction du réseau permettant cette indexation au prix d’une grande quantité de ressources et de bande passante afin de maintenir à jour la base de données des fichiers potentiellement téléchargeables.

KazaA ne sera quasiment plus utilisé en 2007 du fait de son caractère non libre : Divers procès de la part des maisons de disques et de la RIAA pour violation de Copyright affaibliront Sharman Networks, procès contre lesquels Sharmans Networks obtiendra gain de cause, Niklas Zennström (fondateur de KaZaA, et également développeur de Skype et The Venice Project) ayant été dédouané des utilisations illicites effectuées sur un logiciel licite. Néanmoins, afin d’imposer une surveillance de ces activités, Niklas Zennström fut contraint d’ajouter divers spywares à KazaA, ce qui signera la fin de la réputation de ce logiciel, même si une version sans spywares existe : KazaA Lite.

eDonkey / eMule

eDonkey est un logiciel client-serveur permettant le partage de fichiers. Il a donné son nom au protocole qui utilise des serveurs reliés entre eux, afin que chacun sache quel serveur est en fonctionnement. Ce protocole est aussi à la base des logiciels client-serveur eMule (qui a proposé des extensions au protocole), eMule+, et MLDonkey. Les nœuds se connectent à un seul serveur (bien que rien n'interdise de se connecter à plusieurs comme l'a proposé MLDonkey). Les nœuds peuvent effectuer des recherches sur leur serveur mais aussi à l'ensemble des serveurs connus, afin de maximiser leurs chances de trouver un fichier satisfaisant. La distribution du logiciel client-serveur à l'origine du protocole eDonkey a cessé en septembre 2005 suite à des attaques judiciaires.

Chaque nœud se voit attribuer un identifiant unique. S'il n'est pas connecté à travers un pare-feu, un nœud se voit attribuer un identifiant dépendant directement de son adresse physique (adresse IP). Lorsqu'un nœud lance une requête de recherche, il obtient des réponses contenant chacune des informations sur le fichier trouvé et l'identifiant du nœud qui héberge la donnée. S'il souhaite télécharger cette donnée, il peut soit calculer l'adresse physique de la source à partir de son identifiant, et cela signifie que la source est accessible directement, soit le calcul de l'adresse physique est impossible. Dans le second cas, c'est que la source n'est pas accessible directement (cela arrive quand le port de l'application TCP 4662) n'est pas utilisable. Cela peut être dû au fait que la source est connectée au système pair-à-pair via un pare-feu, un proxy, une traduction d'adresse (NAT), ou qu'elle est occupée. Le protocole permet alors l'envoi d'une requête au serveur auquel est connectée la source afin qu'elle se connecte elle-même au demandeur. Le problème d'un nœud derrière un pare-feu cherchant à communiquer avec un autre nœud lui aussi derrière un pare-feu persiste et n'est pas résolu par cette méthode. De toute façon, cette fonctionnalité augmente beaucoup trop la charge du serveur et a été désactivée de la plupart des serveurs.

Le téléchargement multisource est aussi permis par eDonkey. L'extension eMule permet que, lorsqu'une source est trouvée, et dans le cas où le fichier est en cours de récupération, la source qui héberge la donnée fournit les autres sources qu'elle connaît afin d'accélérer la récupération de la donnée à partir de plusieurs sources. Afin de décourager les nœuds égoïstes, eMule a mis en place une extension permettant un système de crédits, utilisant l'algorithme de cryptographie à clé publique RSA. Ce système permet aux nœuds qui attendent de télécharger un fichier d'avancer plus vite dans la file d'attente des nœuds fournisseurs auxquels il a lui-même fourni des fichiers, et donc de récupérer le fichier demandé plus rapidement. Il s'agit donc d'un système de récompense local. Ce système de crédit est basé sur un identifiant d'utilisateur de 16 bits (différent de l'identifiant du nœud) qui est engendré aléatoirement, et dépendant de la machine associée au nœud. Cet identifiant reste donc le même au cours des différentes connexions du nœud au réseau.

eDonkey utilise des hachages de contenu de fichiers pour les différencier de manière sûre. Il décompose les fichiers en blocs récupérables indépendamment, ce qui permet d'accélérer la récupération des fichiers en parallélisant les téléchargements. Ces blocs sont identifiés au moyen de la fonction de hachage SHA1, ce qui limite la probabilité d'avoir une collision entre deux hachages. Cette fonction se révèle bien plus efficace que la fonction UUHash utilisée par FastTrack (système décrit ci-dessous).

De plus, eDonkey identifie aussi chaque fichier dans son intégralité par la concaténation de hachages (utilisant la fonction MD4). Dans les protocoles eDonkey et eMule, il n'est pas possible d'attribuer plus de responsabilités à un nœud ayant des capacités supérieures aux autres.

De plus, deux limites au nombre d'utilisateurs existent :

• une limite matérielle interdit toute nouvelle connexion lorsque le nombre d'utilisateurs maximum permis est atteint ;
• une limite logicielle interdit toute nouvelle arrivée de nœud connecté derrière un pare-feu (nœud protégé) au delà de cette borne.

Depuis 2004, certains serveurs eDonkey censurent les requêtes lorsqu'elles concernent certains mots-clés (sex, xxx, etc.), et interdisent le partage de données lorsqu'elles sont de certains types (mp3, vidéos, etc.). Cela rappelle encore une fois l'une des faiblesse des systèmes centralisés : la sensibilité à la censure.

Toutefois, afin de diminuer l'un des autres problèmes posés par la centralisation et limiter la charge des serveurs, eDonkey a intégré à son logiciel client-serveur l'utilisation d'une table de hachage répartie baptisée Overnet, et basée sur Kademlia. Le logiciel client-serveur est devenu à cette occasion eDonkey2000. eMule a aussi intégré cette table de hachage répartie sous le nom de Kad!.

L'administration du réseau eDonkey2000 et la propriété du logiciel client-serveur associé par la société MetaMachine ont mis fin à l'utilisation de ce protocole en septembre 2005, suite à des attaques judiciaires. Le protocole eMule, ne dépendant d'aucune entreprise, continue toutefois de fonctionner.

Ce type de systèmes repose sur une certaine centralisation puisqu'il nécessite un certain nombre de serveurs supportant toute la charge du réseau. Si un serveur se déconnecte, tous ses utilisateurs doivent se reconnecter à un autre serveur. Les serveurs, et donc les nœuds qui y sont connectés, présentent donc l'inconvénient d'être à la merci d'une attaque ou d'une surcharge. Du fait de la centralisation, certains serveurs espions ont été lancés afin d'espionner les utilisateurs.

En effet, plusieurs sociétés et associations se sont spécialisées dans la lutte contre l'utilisation des systèmes pair-à-pair (telles que MediaDefender, une société mise à mal en 2007, par une attaque de hackers suédois baptisés MediaDefender-Defenders, puis attaquée en justice par TPB). Celles-ci peuvent très facilement identifier l'adresse physique d'un utilisateur en se connectant à un système pair-à-pair semi-décentralisé. Ces organismes peuvent même faire fonctionner des serveurs afin de savoir ce qui est partagé par les utilisateurs connectés à ces serveurs.

L'identification des nœuds eMule étant basée sur l'adresse physique, il est possible de connaître l'adresse physique d'un nœud à partir de son identifiant. eMule ne garantit donc aucunement l'anonymat de ses utilisateurs. Puisque chaque résultat de recherche pour un objet est accompagné des identifiants des sources, il suffit d'effectuer une recherche sur un objet pour obtenir des adresses physiques d'utilisateurs de systèmes pair-à-pair hébergeant cet objet. Les systèmes semi-décentralisés sont donc peu apte à la protection des utilisateurs.

De plus, la recherche est par défaut non exhaustive puisqu'elle n'est pas effectuée sur tous les serveur. Dans les cas où la recherche est effectuée sur tous les serveurs, la réponse contiendra les adresses de nœuds qui ont été envoyés comme réponse il y plus d'une minute. Néanmoins, si la centralisation permet l'exhaustivité, les nœuds hébergeant des objets populaires reçoivent beaucoup de demandes.

Le P2P privé : La génération anonyme et chiffrée

Exemples de protocoles et logiciels clients de pair-à-pair open-source et anonymes dans l'ordre de popularité en novembre 2007 (Extraits de la section spécialisée du forum de Numerama) :

• Rshare alias Stealthnet (Site officiel français), Multilingue, Multiplate-forme, origine allemande. L'un des plus prometteurs, il ressemble beaucoup à eMule et connaît une évolution très dynamique.
• Ants, Multilingue, Multiplate-forme, basé sur Java. Interface conviviale, évolution dynamique, son anonymat ayant la réputation d'être inviolable mais il est difficile d'utilisation.
• iMule, basée sur la surcouche réseau I2P et sur le réseau Kad, Multilingue, Multiplate-forme.
• MUTE, Multilingue, Multiplate-forme, interface peu ergonomique ;
• WASTE, anglais avec patch français, Multiplate-forme, utilisable d'ami à ami (aucune connexion n'est alors possible sans un accord réciproque) ;
• OFFsystem, uniquement anglais.
• Perfect Dark, la suite de Share, complexe à l'utilisation, pas en français ;
• GNUnet et surtout Freenet, Multilingues, Multiplate-formes, ils ne sont pas seulement un réseau d'échange de fichiers, mais plutôt un second internet décentralisé anonyme et crypté (d'ami à ami). Ils nécessitent l'utilisation du navigateur web , ils sont en quelque sorte la face cachée d'internet, son underground ;
• Alliance, d'ami-à-ami .

Un célèbre logiciel japonais nommé Share faisait partie de cette catégorie de clients P2P, mais le cryptage de l'anonymat ayant été cassé pour les téléchargeurs (downloaders) mais pas pour les partageurs (uploaders), et celui-ci n'évoluant plus (non open-source), il est maintenant déconseillé de l'utiliser, d'autant plus qu'il crée diverses failles de sécurité sur l'ordinateur.

Ici, seuls sont présentés les logiciels permettant un anonymat extérieur et entre les utilisateurs, car certains logiciels tels que AllPeers, Hamachi, Hybrid Share, OnShare, TribalWeb alias GigaTribe, Retroshare, ne permettent pas d'anonymat entre les utilisateurs.