Je souhaite vous soumettre une proposition visant à renforcer la sécurité de la Toile de Confiance.
L’idée est d’organiser le réseau ucoin en « partitions », chaque partition contenant une liste des membres.
Pour être considéré membre, un utilisateur doit être signé par au moins un utilisateur de chaque partition.
Ainsi la sécurité se trouve renforcée.
Un utilisateur souhaitant créer des Sybil est contraint de trouver et convaincre un membre de chaque partition pour y arriver.
Un utilisateur légitime doit lui, trouver au travers de ses contacts les signatures nécessaires à la validation de son identité.
Le nombre de partitions doit augmenter ou se réduire en fonction de l’évolution du nombre de membres.
Cela me semble tout à fait faisable par division ou fusion des listes.
Je pense que les concepts/algorithmes décrits dans ce papier https://tel.archives-ouvertes.fr/tel-00443852/document sont applicables.
Reste à trouver le bon paramètre pour que le nombre de partitions soit :
suffisamment élevé pour garantir une bonne sécurité (difficulté à mettre en œuvre une attaque Sybil)
suffisamment faible pour que l’utilisateur légitime puisse aisément trouver les signatures dont il a besoin
Les membres pourraient être aléatoirement placés dans telle ou telle partition pour ne pas faire un classement alphabétique des uid ou pubkey. Ce qui perdrait tout son intérêt.
Je dirais même certifié par un membre de n partitions différentes.
Oui effectivement, ça parait nécessaire. En effet, si on exige que les membres soient signés par au moins un utilisateur de chaque partition, ils seront éjectes du système dès que le nombre de partitions augmentera.
On pourrait avoir deux paramètres qui seraient :
le nombre de partitions total en fonction du nombre de membres Np = f(nombre de membres)
le nombre de partitions nécessaires à la validation d’un membre en fonction du nombre de membres Nv = f(nombre de membres)
La première fonction pourrait être un simple pourcentage.
Le seconde pourrait être une asymptote variant entre Nv min et Nv max. (Exemple : Si Nv min = 3 et Nv max = 10, l’utilisateur légitime devra trouver entre 3 et 10 partitions en fonction de la taille de la communauté pour qu’il soit considéré valide.)
Ne pensez vous pas qu’avec cette méthode, il serait possible de se passer de la règle du nombre de pas maximum, et ainsi permettre l’existence de communautés de grande ampleur ?
Il me semble qu’une telle règle est déjà impliquée par la règle de distance.
Puisque si l’on doit être à une distance maximum de tous les membres, alors on doit obtenir des certifications provenant d’une variété minimum d’individus. Et rien n’empêche d’avoir une distance de 6 ou 7 si l’on veut des communautés de grande taille.
Salut cgeek,
Je suis d’accord que la règle de nombre de pas maximum implique une certaine variété de signatures pour pouvoir être membre.
Cependant, je me demande si la règle des partitions n’est pas plus efficace contre une attaque Sybil impliquant un groupe de membres organisés entre eux pour créer de fausses identités.
En effet, c’est une contrainte supplémentaire pour les tricheurs car il doivent rallier au moins un membre dans Nv partitions.
De plus, la règle du nombre de pas implique une capacité de calcul importante (même si ce point peut être résolu en utilisant les statistiques comme tu as pu le démontrer dans un précédent post), et instinctivement, je pense que la règle des partitions est moins consommatrice en ressources CPU.
Je pense que c’est une approche qui mériterait d’être creusée.
(Bien que je ne sache pas vraiment par où commencer.)
Je dois dire que ce papier est très intéressant, d’autant plus qu’il traite de l’attaque sybile et de la crypto homomorphe. Je note aussi que notre règle de distance est très similaire à l’algo SybilGuard.
Quant à l’intégrer dans uCoin, je ne le ferai pas pour plusieurs raisons :
le fait que la règle de distance induit déjà un fonctionnement similaire à celui des partitions (mais pas identique)
le fait d’avoir trop de règles, ou des règles trop contraignantes est aussi un frein à l’adoption (on me l’a déjà fait remarqué plusieurs fois pour uCoin, je retiens)
le besoin de sortir le logiciel : cela fait déjà 2 ans et demi que j’ai débuté les devs, il est temps que l’on démarre quelque chose
Bref, je garde ce papier dans un coin.
Désolé de systématiquement répondre négativement aux propositions, mais je n’ai de toute manière plus le temps ni la volonté de changer à nouveau profondément les mécanismes du logiciel.
Ne soit pas désolé. Je comprends parfaitement ta position et même je la partage.
Je suis admiratif du boulot que tu as produit jusque là et je pense ne pas être le seul.
J’essaie simplement d’apporter des idées pour une éventuelle version ultérieure (et/ou un fork du logiciel). Et je pense que c’est le meilleur endroit pour le faire.
J’ai une autre piste de réflexion à vous soumettre, qui à mon avis est plus simple à mettre en œuvre que cette histoire de partition.
L’idée c’est d’empêcher qu’un groupe d’individu puisse être co-signataires d’un grand nombre d’individus.
Par exemple, dans le graphe ci dessous, si l’on détermine que deux membres distincts ne peuvent être cosignataire que de deux identités uniquement, C ne peut pas signer C’ parce qu’il est déjà co-signataire de A’ et de B’ avec A.
Au niveau calcul de chemins, ça peut se faire facilement :
Je sais que c’est une intuition et comme me l’a fait justement remarquer Galuel dans ce post, il faut peut être mieux garder quelque chose de simple tant que l’on a pas de retours d’expériences et/ou de simulations crédibles.
Néanmoins, je me demandais si cette piste de réflexion avait déjà été explorée.
Intuitivement, je dirais que A et B peuvent être considérés cosignataires de C, à partir du moment où A a un certificat en cours de validité vers C et qu’arrive une nouvelle certification de B vers C.
Ce statut de cosignataire disparaît au moment où un des deux certificats expire.
C’est pas très formel, ça ne répond pas à ta question, mais ça me paraît fonctionnel.
