sybile
Dans cette section, nous présentons le couplage entre SybilGuard et l’autorité de certification distribuée. La protection contre l’attaque sybile est réalisée par un contrôle d’accès au réseau. Lors de sa première connexion, un pair doit obtenir un certificat délivré par l’autorité de certification distribuée.
L’insertion d’un nouveau pair S dans le réseau est réalisée en quatre étapes :
1. S génère un couple de clés publique/secrète noté (PS, SS) ;
2. S contacte un pair appartenant au réseau pour obtenir son certificat, qu’il n’obtient que s’il est considéré honnête par un membre de chaque groupe de fragmentation (chaque pair impliqué utilisant SybilGuard pour décider de coopérer ou non) ;
3. S rejoint l’overlay pair-à-pair en présentant son certificat, son identifiant étant le condensat de la signature de son certificat ;
4. S prend part au partage de la clé, obtient son arbre de fragmentation et peut à son tour participer au contrôle d’admission de nouveaux pairs. Dans cette section, nous décrivons les points 2 (obtention du certificat) et 3 (identification du pair) qui sont spécifiques à cette application.
6.2.1 Obtention du certificat
Le contrôle du nombre de pairs sybils est réalisé lors de la deuxième étape du processus d’admission, à savoir durant l’obtention du certificat. La requête
de certification émise par le nouveau pair est Req = (Content, Clues), qui contient :
– Content, qui représente les informations présentes dans le certificat final
signé, contient PS, la clé publique de S ;
– Clues, qui représente les informations fournies aux participants pour leur permettre de prendre leur décision, contient les tables des témoins de
S représentées de manière compacte sous la forme d’un filtre de Bloom
[Blo70]. Un filtre de Bloom est un résumé d’un ensemble dans lequel le test d’appartenance d’un élément peut renvoyer des faux positifs. Dans le cas de SybilGuard, les faux positifs correspondent à des intersections X et sont discriminés en contactant X.
Une signature distribuée est réalisée sur cette requête de certification. Un pair A, bootstrap de S, distribue la requête dans le réseau selon l’algorithme arborescent de signature distribuée.
Chaque pair participant à l’admission de S trouve dans la requête l’ensemble des tables de témoins de S : chaque participant peut donc évaluer l’honnêteté de S localement et décider de coopérer ou non à la signature. Les intersections trouvées sont ensuite vérifiées avec le pair X présent à l’intersection pour rejeter un attaquant fournissant de fausses tables et discriminer les faux positifs des
filtres de Bloom. Les tables des enregistrés de X, dont la clé publique est PX,
sont stockées dans la DHT à l’emplacement h(PX) et sont signées par X, ce qui
permet de réaliser cette vérification en l’absence de X.
S obtient son certificat si et seulement si un membre de chaque groupe de
fragmentation, et donc un ratio t des pairs actuels, l’évalue honnête, en utilisant SybilGuard. Dans le cas où un pair refuse l’admission, la requête peut être retransmise à un autre pair du même groupe. L’obtention d’un certificat est illustrée figure 6.5.
Propriété 9 (Limitation du nombre de pairs sybils)
Un nouveau pair n’est accepté que si un ratio t des membres actuels le juge honnête, en utilisant SybilGuard. Un pair détecté comme sybil par tous les membres de l’un des groupes de fragmentation ne peut donc pas entrer dans le réseau.
6.2.2 Identification du pair
Une fois son certificat obtenu, S rejoint l’overlay en utilisant comme identi-fiant le condensat de la signature de son certificat. Si nous notons h la fonction
de padding utilisée lors de la signature et h′ la fonction de hachage utilisée pour
obtenir l’identifiant de pair, alors l’identifiant du pair S vaut :
P eerIdS = h′(h(PS)e[m])
S peut initialement choisir sa clé publique PS; en revanche, S ne peut pas
prévoir la signature de PS (qui vaut h(PS)e[m]) et ne peut donc pas influencer
le choix de son identifiant.
Propriété 10 (Aléa des identifiants)
Un nouveau pair ne connaît son identifiant qu’une fois son certificat obtenu et donc, si l’utilisateur ne peut plus ensuite changer de clé publique, son identifiant est fixé et aléatoire.
A (e0) B (e10) C (e11) S D (e11) (PS, TTS) SybilGuard : S ? Honnête
(a) Le suspect S transmet sa requête à son pair de bootstrap A. PS est la clé publique de S et T TS ses tables de témoins. A utilise SybilGuard et juge S honnête : A poursuit l’algorithme de signature. A (e0) B (e10) C (e11) S D (e11) 1 0 (PS, TTS) SybilGuard : S ? Sybil
(b) A retransmet la requête à un pair C dont l’identifiant commence par 1. C utilise Sybil-Guard et juge S sybil : C refuse de pour-suivre. A (e0) B (e10) C (e11) S D (e11) 1 0 (PS, TTS) SybilGuard : S ? Honnête
(c) A retransmet la requête à un autre pair
D du même groupe que C. D accepte S et poursuit la signature. A (e0) B (e10) C (e11) S D (e11) 10 11 (PS, TTS) SybilGuard : S ? Honnête
(d) D transmet la requête à un pair B du groupe ˚e10qui accepte S comme honnête.
A (e0) B (e10) C (e11) S D (e11) CertS
(e) Les trois pairs A, B et D réalisent conjointement le certificat de S. A (e0) B (e10) C (e11) S D (e11)
(f) S rejoint le réseau à l’emplacement spéci-fié par le certificat.
Figure 6.5 – Contrôle d’admission d’un nouveau membre S. Le réseau est
composé de trois groupes de fragmentation ˚e0, ˚e10 et ˚e11. S est accepté si un
membre de chaque groupe le reconnaît honnête. À l’inverse, si tous les membres d’un groupe le jugent sybil, S n’obtient pas de certificat.
B C D E F Table des témoins
1 2 3 ID PE PF ... Table des enregistrés 1 2 3 ID PC PB PA A
(a) L’attaquant B insère un premier pair sy-bil A, obtient son certificat et son identifiant aléatoire. B souhaite ensuite changer l’iden-tifiant de A. B C D E F G Table des enregistrés 1 2 3 ID PC PB PG A
(b) B crée un autre pair G à la place de A, qui s’enregistre dans le réseau SybilGuard en remplaçant A. G peut ensuite obtenir un autre certificat avec un nouvel identifiant.
Figure6.6 – Attaque sur la révocation des clés.
Le réseau SybilGuard ne doit pas permettre à un pair de changer sa clé publique. Dans la version originale de SybilGuard, la révocation de clé est au-torisée et est utilisée pour maintenir les tables de routage SybilGuard. Quand deux pairs ajoutent un arc entre eux dans le graphe SybilGuard, ces deux pairs doivent mettre à jour leur table de routage SybilGuard pour diriger des routes vers et depuis ces nouveaux arcs : leur table de routage est réinitialisée aléatoire-ment. Les routes arrivant par ces nouveaux arcs ressortent par un ancien arc et écrasent l’ancienne route qui empruntait cet arc ; les routes déjà existantes sont déviées et les tables sont mises à jour, comme illustré figure 6.3. La possibilité de cet écrasement autorise un attaquant à changer sa clé publique, comme nous le montrons figure 6.6.
Avec la révocation des clés, un attaquant peut obtenir séquentiellement plu-sieurs certificats correspondant à des clés différentes, afin de finalement garder celui qui se trouve dans la partie de l’espace souhaitée. Nous envisageons deux contre-mesures :
– limiter la fréquence des changements, auquel cas chaque certificat a une durée de vie limitée et les tables de routage SybilGuard sont réinitialisées avec la même fréquence. Un pair ne peut donc mettre à jour sa clé publique qu’à la fin de la validité de son certificat. Cela permet de limiter le nombre d’identifiants qu’un attaquant peut obtenir mais induit une surcharge sur le réseau, puisque tous les pairs doivent renouveler leur certificat ; – interdire les changements, auquel cas un certificat est obtenu à vie (ou
à défaut pour une durée de plusieurs années) mais les tables de routage SybilGuard ne peuvent plus être modifiées. Au lieu de redistribuer toute la table à chaque ajout d’arc, deux nouveaux arcs successifs sont
appai-– n = 1 000 000 est le nombre de pairs du réseau – d = 24 est le degré de chaque pair
– w est la longueur des routes aléatoires
Figure 6.7 – Résumé des notations et conditions
rés entre eux ; les anciens arcs conservent les mêmes routes et les tables d’enregistrement ne sont donc pas mises à jour. Les tables de routage SybilGuard ne sont, en revanche, plus des permutations aléatoires : les résultats expérimentaux présentés section 6.4 montrent que cela n’affecte que légèrement les performances de SybilGuard.
Nous choisissons la seconde contre-mesure, à savoir l’interdiction des chan-gements de clé publique. Au lieu d’associer les arcs deux par deux, une stratégie plus évoluée et se rapprochant plus de la permutation aléatoire serait de permu-ter entre plus de deux nouveaux arcs. En contrepartie, tant que le pair n’a pas suffisamment d’arcs pour mettre à jour sa table de routage, les routes aléatoires passant par ces arcs sont interrompues.