La gestion des scores de réputation est un composant essentiel des mécanismes de réputation, qui garantit l’intégrité des témoignages. Nous présentons dans cette section une méthode de gestion des scores de réputation reposant sur unedht, à l’instar de EigenTrust [KSG03] (voir section3.2.4).
En général, lesdhtassignent les identifiants des utilisateurs grâce à une fonction aléatoire à sens unique, qui renvoie une chaîne de m bits, par exemple à partir de l’adresse ip et du port utilisés par un utilisateur. En pratique, des fonctions de hachage cryptographiques sont utilisées pour garantir à la fois qu’un adversaire ne peut choisir son identifiant et que les collisions sont peu probables. Par exemple, pour la fonction sha-256 [Nat12], l’identifiant est une chaîne de 256 bits, ce qui donne 2256identifiants possibles. Unedhtdéfinit une distance à partir des
identifiants des utilisateurs ; par exemple, deux nœuds sont voisins si la longueur de leur préfixe commun est supérieure à un seuil donné. La figure4.1présente un exemple dedhten anneau où m = 4, et où les voisins d’un nœud sont les trois nœuds le précédant sur l’anneau : les voisins du nœud 1 sont les nœuds 10, 12 et 15.
1 3 6 8 10 12 15 1 3 6 8 10 12 FS1, FS3, FS6 FS1, FS3, FS6 FS12, FS1, FS3 Légende : 1 FS 33 GS
Figure 4.1 – Gestion des scores de réputation à travers une dht
Dans notre mécanisme de réputation, les fournisseurs de service sont organisés dans une telledht. De cette façon, les gestionnaires de score d’un fournisseur donné sont ses voisins sur ladht– d’autres fournisseurs ; cela permet de les retrouver simplement afin d’obtenir la répu- tation d’un fournisseur de service. En reprenant la figure4.1, la réputation du fournisseur FS1
est gérée par GS10, GS12et GS15. Plus précisément, les gestionnaires de score d’un fournisseur
4.2 Gestion des scores de réputation
peuvent ainsi obtenir les témoignages émis sur un fournisseur aisément et, à partir de ces té- moignages, calculer la réputation du fournisseur. Ladhtgère également les arrivées et départs de nœuds. Lorsqu’un nœud intègre le système, il est assigné en tant que gestionnaire de score de plusieurs fournisseurs ; il se synchronise avec les autres gestionnaires de score de chacun de ces fournisseurs et commence à stocker les témoignages sur ces fournisseurs. Le départ d’un gestionnaire de score déclenche également une telle synchronisation. Afin d’éviter les attaques
par bourrage d’urne, les gestionnaires de score ne conservent que les derniers témoignages
émis par chaque pseudonyme.
Utiliser plusieurs gestionnaires de score pour un même fournisseur permet en outre de tolé- rer les comportements malveillants. En effet, nous montrons en section4.3que l’intégrité des témoignages est garantie tant que deux tiers des gestionnaires se comportent honnêtement. Le choix des gestionnaires de score doit donc garantir que la probabilité qu’il existe une col- lusion supérieure à un tiers soit faible. Cette probabilité dépend de plusieurs paramètres : N , le nombre de gestionnaires de score potentiels parmi lesquels ils sont choisis ; m, le nombre de malveillants parmi ces N utilisateurs ; n, le nombre de gestionnaires de score associés à chaque fournisseur ; et f (n), la taille maximale d’une collusion parmi les gestionnaires de score choisis, qui dépend de leur nombre. Dans ce chapitre, f (n) vaut dn/3e −1, mais nous utiliserons le même
raisonnement ultérieurement pour f (n) = dn/2e −1.1En supposant que le choix des gestion-
naires de score est aléatoire – ce qui est garanti par ladht–, la probabilité d’obtention d’une collusion réussie est modélisée par la distribution hypergéométrique de paramètres N ,m et n : il s’agit d’un choix sans remplacement de n éléments parmi N , dont m nous intéressent. Plus pré- cisément, en notant cdfN ,m,n la fonction de répartition2de la distribution hypergéométrique
de paramètres N , m et n, la probabilité de réussite d’une collusion est p = 1 − cdfN ,m,n f(n) .
Ainsi, si la probabilité maximale de réussite d’une collusion souhaitée est notée pmax, le nombre
de gestionnaires de score nécessaire nGSest
nGS= min
n
n ∈ N | 1 − cdfN ,m,n f(n) < pmaxo. La figure4.2étudie nGSpour f : n 7→ dn/3e −1.
La figure4.2aprésente nGSpour N compris entre 100 et 108, pour des proportions d’utili-
sateurs malveillantsm/N fixées et pour pmax = 2−64, c’est-à-dire une probabilité extrêmement
faible, qui va de pair avec la sécurité des outils cryptographiques utilisés. Cette figure montre que le nombre de gestionnaires de score nécessaire passe parfaitement à l’échelle : quelle que soit la proportion d’utilisateurs malveillants, le nombre de gestionnaires de score ne croît plus au delà de N = 106.
La figure4.2bprésente nGSpour N = 108, pour pmaxcompris entre 2−10 et 2−70et pour des
proportionsm/Nfixées. Cette figure montre que le nombre de gestionnaires de score nécessaires
est logarithmique en la probabilité de collusion désirée. Par exemple, nGS= 100 permet d’em-
pêcher les collusions soit pourm/N = 15 % avec une probabilité pmax = 2−20, pourm/N = 10 %
avec une probabilité pmax= 2−35, ou pourm/N = 5 % avec une probabilité pmax= 2−20.
Finalement, la figure4.2cprésente nGS en fonction dem/N, pour N = 108et pmax = 2−64.
Cette figure montre que, pour conserver un nombre de gestionnaires de score raisonnable,
1. La section4.3.3explique que la synchronisation des gestionnaires de score pour l’acceptation d’un témoi- gnage fonctionne seulement si le nombre de gestionnaires malveillants est inférieur à dn/3e −1.
102 103 104 105 106 107 108 109 1010 Nombre d'utilisateurs (p =2−64)
101
102
103
Nombre de gestionnaires de score nécessaires
Proportion de malveillants
20.0% 15.0% 10.0% 5.0%
(a) En fonction du nombre d’utilisateurs
2-70 2-65 2-60 2-55 2-50 2-45 2-40 2-35 2-30 2-25 2-20 2-15 2-10
Probabilité maximale de collusion (N =108)
0 200 400 600 800 1000
Nombre de gestionnaires de score nécessaires
Proportion de malveillants
20.0% 15.0% 10.0% 5.0%
(b) En fonction de la probabilité maximale de collusion, pour N = 108
0.00 0.05 0.10 0.15 0.20 0.25
Proportion de malveillants (N=108, pmax=2−64)
101
102
103
104
Nombre de gestionnaires de score nécessaires
(c) En fonction de la proportion d’utilisateurs malveillants, pour N = 108et pmax= 2−20
Figure 4.2 – Nombre de gestionnaires de score nécessaires pour rendre les collusions supé- rieurs à un tiers improbables
notre mécanisme peut utiliser 103 gestionnaires de score pour empêcher les collusions pour
m/N = 5 % avec une probabilité pmax = 2−64, ce qui rend extrêmement faible la probabilité que
les gestionnaires de score d’un fournisseur du système soient en collusion. Remarque
Deux fournisseurs de service proches sur ladhtpeuvent se mettre en collusion pour essayer d’attaquer le mécanisme. Par exemple, reprenons l’exemple de la figure4.1et supposons que les fournisseurs FS1et FS8 soient en collusion. FS8 peut faire pression sur FS10 pour que ce
dernier améliore la réputation de FS1. Cependant, pour que la menace de FS8 soit crédible, il
faut que celui-ci contrôle suffisamment de gestionnaires de score de FS10; la probabilité d’un