Cholez
Transcription
Cholez
Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Un mécanisme de révocation distribué et adaptatif pour les réseaux pair-à-pair Thibault Cholez, Isabelle Chrisment et Olivier Festor {thibault.cholez, isabelle.chrisment, olivier.festor}@loria.fr LORIA - Campus Scientifique - BP 239 - 54506 Vandœuvre-lès-Nancy Cedex 17 janvier 2008 1 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion 2 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Contexte : les réseaux pair-à-pair Définition Architectures permettant le partage de ressources informatiques et de services par des échanges directs entre des systèmes autonomes. • Intérêts du schéma P2P : coût de l’infrastructure, passage à l’échelle, tolérance aux pannes, ressources mobilisées. • Aujourd’hui : support de nombreux services, ∼ 2/3 du trafic global. • Limites : absence de contrôle et autonomie des utilisateurs. 3 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Les difficultés des réseaux P2P Les mauvais comportements des pairs nuisent à : • La sécurité du réseau : • Pairs réalisant des attaques (non respect du protocole). • Pairs partageant des contenus dangereux (virus, malwares) ou illégaux. • La qualité de service : • Individualisme (70% des utilisateurs ne partagent rien, 50% des ressources partagées par 1%) [1] [8]. • Pollution du contenu (50% du contenu) [11]. 4 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Problématique Notre objectif : assurer le bon fonctionnement du réseau. • Détecter les mauvais comportements. • Exclure les membres du réseau. Difficultés de réaliser un mécanisme de révocation : • Comment définir la réputation d’un pair ? (stockage, évolution) • Comment mettre en œuvre la révocation ? (information, messages) • Comment assurer la sécurité du mécanisme ? 5 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Travaux sur la réputation Mécanisme P2P classique : chaque pair stocke localement la réputation des autres [6] [10]. • Pas de connaissance à priori. • Inefficace pour de grands réseaux P2P (peu de pairs connus, peu de relation avec chacun). Mécanisme centralisé : eBay. • Crée une note synthétique à partir des évaluations de la communauté (∼ historique). • Limite : notes mises à disposition par un serveur. Évolution vers les comptes distribués : PeerMint [7]. • Chaque pair a un compte stocké sur le réseau (DHT). • Présente les deux avantages : réputation globale et adaptée au P2P. 6 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Travaux sur la révocation Révocation par contrôle d’accès [13] : • Réalisée par des moyens de chiffrement. • Vote au sein du groupe (différents types de seuils, de signatures). • Mécanismes trop lourds, ne passent pas l’échelle. Révocation par suicide [5] : • Détection et révocation individuelles (pas de consensus). • Un membre voulant révoquer se suicide en même temps. • Avantage : simple, rapide, adapté au P2P, sûr. • Limite : application spécifique (pas d’intérêt individuel). 7 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Idée principale Limites observées : • Révocation : chiffrement, consensus, action individuelle : mal adaptés. • Réputation : mécanismes inefficaces (pas de gestion globale). Principe : • Stocker la réputation de chaque pair sur la DHT (réseau P2P structuré). • Mécanisme de révocation utilise la réputation (déclenché par un seuil). Réseau P2P support : KAD. • Implantation du protocole Kademlia [12] dans eMule et aMule. • Réseau P2P structuré déployé à large échelle. 8 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Comptes distribués Chaque pair a deux identifiants (128 bits) : • L’adresse du pair dans le réseau (KADID). • L’adresse du compte dans le réseau (userID). Chaque compte contient les informations publiques du pair : • publicKey (128 bits) : clé publique pour le chiffrement. • trustRating (16 bits) : réputation du pair. • blackboard (quelques kiloBytes) : affiche les transactions courantes du pair. 9 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Évolution de la réputation Critère de réputation choisi : propension d’un pair à participer au réseau. Évolution de la réputation : • Évolution automatique traduisant la participation. • Suite à une transaction entre A et B, modification de leur réputation. • Modification effective si transaction affichée par 2 pairs, proportionnelle au montant. Propriétés du mécanisme : • Un utilisateur ne peut pas modifier directement sa réputation. • Contrôle mutuel des 2 intervenants. 10 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Utilisation du blackboard 11 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Utilisation du blackboard 11 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Utilisation du blackboard 11 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Utilisation du blackboard 11 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Utilisation du blackboard 11 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Utilisation du blackboard 11 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Utilisation du blackboard 11 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Mécanisme de révocation Une révocation par le contrôle des services : • Révocation distribuée : chaque pair doit vérifier avant de rendre un service. • Utilise la note de réputation stockée sur le réseau. • Révocation décrite au cœur du protocole. • Révocation adaptative : les services sont révoqués différemment selon la réputation et les critères retenus. 12 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Contrôle de la phase d’amorce Premier niveau de révocation ∼ contrôle d’accès : • Vérification de la réputation avant de partager sa liste de contacts. • Contrôle insuffisant car détournable avec un pair passerelle. 13 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Contrôle des services Services rendus selon le même procédé : • 1) Kademlia REQ générique pour trouver les pairs potentiels. • 2) Envoi d’une requête spécifique au service souhaité. 14 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Implantation Modification du client aMule pour KAD : • Gestion d’un nouveau type d’information ”Account” (structure de données, requêtes associées). • Modification du comportement de la partie UDPListener : cherche et vérifie la réputation avant de traiter la requête. Passage à l’échelle sur EmanicsLab (en cours). 15 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Évaluation des performances D’après une étude des performances de KAD [2] : • 200sec de délais pour publier les informations. • 100sec pour les trouver. • Délais peu perceptibles pour l’utilisateur (services non temps-réel). En cours d’étude : • Mesure des délais réels. • Compromis délais / réplication. 16 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Sécurité de la réputation A la fin d’un transfert : changer les valeurs du blackboard : • Décroı̂tre le montant de données téléchargées : impossible. • Accroı̂tre le montant de données envoyées : contradiction entre les deux pairs. • Solution : prendre la valeur du pair téléchargeant (désavantagé si le montant augmente). Pair malveillant mentant sur la valeur de la réputation : • Peu d’impact car comptes répliqués. • Décision à la majorité. Création de nouvelles identités : • Permet de gagner une nouvelle réputation initiale. • Problème de l’identité : plusieurs solutions possibles. 17 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Sécurité de la révocation Révocation injustifiée (déni de service d’un pair) : peu d’impact. Coalition de pairs malveillants : possibilité d’obtenir la charge de (n/2 +1) pairs stockant la réputation d’un seul. • Sybil attack : insertion de nombreux pairs factices pour contrôler une partie du réseau. • Permet de faire révoquer la victime par l’ensemble du réseau. • Quelle est la probabilité de succès ? P(X = i) = P(X > 6) = 10−i Cxi ∗ C4000 10 C4000+x i≤10 X P(X = i) (1) (2) i=6 18 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Sécurité de la révocation Implantation de KAD insuffisante : réalisation d’importantes Sybil attack (216 ) [14]. Comment sécuriser l’identité des pairs : • Autorité centrale délivrant les KadID. • Keypeer : autorité de certification distribuée [15]. 19 / 20 Plan Introduction État de l’art Architecture Application à KAD Évaluation du mécanisme Conclusion Conclusion et perspectives En Résumé : • Mécanisme de réputation global, basé sur les comptes distribués, 1er critère : participation au réseau. • Mécanisme de révocation orienté services, distribué, adaptatif . • Sûr si identités des pairs fortes. Travaux actuels : évaluation des performances sur EmanicsLab. Travaux futurs : • Nouveau critère : qualité du contenu partagé. • Détection des attaques. 20 / 20