10 likes | 106 Views
RESCOM 2008. Un mécanisme de révocation orienté services pour les réseaux P2P. Thibault CHOLEZ Directeur de thèse : Isabelle CHRISMENT Méls : {thibault.cholez,isabelle.chrisment}@loria.fr. Contexte : Faiblesse des réseaux P2P: comportement autonome des pairs et absence de contrôle.
E N D
RESCOM 2008 Un mécanisme de révocation orienté services pour les réseaux P2P Thibault CHOLEZ Directeur de thèse : Isabelle CHRISMENT Méls : {thibault.cholez,isabelle.chrisment}@loria.fr • Contexte: • Faiblesse des réseaux P2P: comportement autonome des • pairs et absence de contrôle. • Les comportements malveillants affectent: • La sécurité du réseau: • pairs réalisant des attaques (non respect du protocole) • pairs partageant du contenu malveillant (virus, malware) • La qualité de service: • - comportement égoïste (70% ne partagent rien, 50% des • ressources partagées par 1% des pairs) • - phénomène de pollution (50% du contenu pollué) • Objectif: détecter les comportements malveillants et les • révoquer Travaux relatifs: Réputation: - Mécanisme classique: chaque pair stocke la réputation de ceux qu’il connaît. Pas de connaissance à priori, peu adapté aux grands réseaux. - Comptes distribués: PeerMint permet une gestion globale de la réputation. Révocation: - Contrôle d’accès: réalisé par des moyens de chiffrement (vote de groupe). Coût élevé, passage à l’échelle limité. - Révocation par suicide: un pair se suicide en révoquant. Intérêt individuel impossible. • Architecture: • Chaque pair a 2 identités: • - KadID la place du pair dans la DHT • userID la place de son compte dans la DHT, contenant la • réputation • Réputation: • Reflète la participation d’un pair au réseau, màj automatique • après chaque transaction. • Propriétés: • un pair ne peut pas changer directement sa réputation • contrôle réciproque des pairs Mécanisme de révocation: - Chaque pair consulte la réputation avant de rendre un service: révocation déclenchée en dessous d’un seuil. - Révocation définie au coeur du protocole: contrôle les services du réseau P2P. - Révocation adaptative: services révoqués différents selon les critères. • Evaluation: • Implantation dans le client KAD aMule: • création et gestion des comptes distribués • contrôles introduits dans la classe UDPListener • Mesure des délais sur EmanicsLab: • - délais proportionnels à la réplication, limités par le timeout • tous les comptes ne sont pas trouvés (~2/3) • Sécurité: • Problème du changement d’identité « white wash ». • Problème de la Sybil Attaque: • - insertion de faux pairs pour • prendre le contrôle d’un compte • permet de révoquer un pair