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