En Duniter v1, 1 identité = 1 paire de clés, et révoquer une identité interdit de créer une identité avec les mêmes clés. Mais en Duniter v2, une identité peut faire évoluer ses clés avec “change_owner_key”, et les mêmes clés peuvent être utilisées pour recréer une autre identité après révocation.
Cela introduit un scénario d’attaque :
Attaquant s’empare des clés de Alice
Attaquant révoque l’identité de Alice
Attaquant crée une identité “Aalice” avec les mêmes clés (mais un autre pseudo et un autre idty_index)
Attaquant demande à Bob, Charlie et Dave, des certifications vers l’identité “Aalice” en se faisant passer pour elle et en signant ses messages avec les clés de l’ancienne identité Alice
Bob, Charlie, et Dave sont surpris, et certifient donc le nouveau compte Aalice sans rentrer en contact avec Alice
On pourrait éliminer ce scénario d’attaque en interdisant la création d’identité pour des clés ayant déjà appartenu à une identité auparavant.
Personnellement, je trouve que c’est une solution technique à un problème plutôt humain : le respect de la licence implique de rentrer en contact avec les personnes au moment où on les certifie, surtout s’il y a révocation d’identité et changement de pseudo. Donc une réponse plus appropriée serait de travailler ça côté UI des applis grand public.
Ce n’est pas qu’un problème d’attaque que j’essaye de soulever, c’est un problème de contrat : quand on révoque en Duniter V1, on est tranquille. On sait que la clé est “bannie”.
Ce n’est pas le cas dans Duniter V2S, même révoquée, la clé peut encore devenir nuisible.
Je pense que c’est la meilleur chose à faire, même si ça alourdi encore un peu plus le protocole.
hm je vois où tu veux en venir, mais je ne pense pas que ce soit une solution.
Le protocole serveur doit en lui même garantir qu’une clé membre dérobé et révoqué ne peut pas recréer d’identité. Les apps doivent être contraints dans un cadre protocolaire prédéfinis, le reste étant du bonus pour rendre l’expérience le plus agréable possible.
Je suis encore septique sur la pertinence des parcours UX type QCM du bon petit certificateur lors de la certification sur Cesium par exemple, je ne dis pas que je suis contre mais je me pose des questions si c’est vraiment utile ou si juste ça casse les couilles.
Je songe à d’autres proposition d’UX, comme par exemple demander à l’utilisateur de retaper précisément le username de la personne qu’on certifie. Mais je pense que ce sont des questions d’UX très compliqués et qui demandent encore réflexion en groupe.
Comme il y a déjà un délai pour les clés ayant subi un changement d’identité, il pourrait y avoir un délai pour la clé après révocation, possiblement très long (années).
Une durée de 40 ans n’a même pas de sens pour une technologie comme la blockchain dont on ne sait même pas si elle sera encore utilisée dans 15 ans. J’aurais dit quelque chose comme 5 ans, c’est déjà long, ça laisse le temps d’avertir des gens qu’on ne verrait qu’une fois par an, par exemple.
C’est-à-dire ? Je parlais de la durée après révocation d’une identité, pendant laquelle la clé correspondante ne peut pas être associée à une identité membre.