depuis que j’ai découvert les monnaies libres il y a de cela 3 semaines et demi une question me trotte dans la tête, à laquelle je n’ai pas trouver de réponse.
Lorsque nous mettrons en place une “vrai” Monnaie Libre, comment feront les utilisateurs qui perdrons leur mots de passe ou leur clé privé (voir les deux), pour récupérer leur solde. Car soyons réaliste, cela arrivera et fréquemment !
Peut-être certains d’entre-vous ont déjà discuter de ce problème, mais j’ai beau chercher je n’ai rien trouver a ce sujet sur ce forum.
J’ai donc réfléchi a une idée d’évolution du protocole qui permettrait à un membre ayant perdu son mots de passe ou/et sa clé privé de récupérer son solde, voici ma proposition (nettement perfectible bien sur ) :
Un humain toto perd son mots de passe ou/sa clé privée de son ancien compte toto.
1 / l’humain toto en question créer un nouveau compte non-membre du nom de toto2
2/ Une évolution du protocole permettrait au compte non-membre toto2 d’émettre une révocation de la clé publique toto (il retrouvera facilement sa clé publique dans l’annuaire).
3/ Cette révocation de toto par toto2 ne sera considérée comme légitime que si elle est confirmée par X membres de la monnaie qui sont à un pas de 1 de toto. (X devenant un paramètre supplémentaire de la monnaie).
Cela induit la création de 2 nouveaux types de documents : la révocation de compte pour perte de pass + la confirmation d’une révocation de compte pour perte de pass
4/ La révocation de compte pour perte de pass emise par toto2 sera considérée comme légitime si et seulement si :
toto à encore le statut de membre au moment de la déclaration de révocation ou à perdu le statut de membre depuis un temps inférieur au temps de validité d’une certification (évite de réveiller un très vieux compte).
toto2 acquiert le statut de membre par le procédé déjà existant de toile de confiance
la révocation déclarée par toto2 est confirmé par X membres à un pas de 1 de toto dans la toile de confiance (donc des membres qui avait certifiés toto ou avaient été certifiés par toto)
les 3 conditions précédentes sont respectés dans un délai inférieur à une durée Y depuis la déclaration de l’identité toto2 dans la blockchain. Y étant un nouveau paramètre de la monnaie.
X et Y devant être correctement réglé pour éviter toute utilisation illégitime de ce procédé.
Valeurs d’Exemple : X=3 membres et Y=7 jours.
Dans une situation réelle, Mme. Michu qui perd son pass devra se créer un nouveau compte et contacter au moins 3 personnes qui était a un pas de 1 d’elle et ses 3 personnes doivent validé sa demande en moins d’une semaine, et en plus elle doit devenir membre en moins d 'une semaine ça me parait suffisamment exigeant pour éviter les abus. Tout en étant largement faisable dans le sens ou une demande légitime est censé émanée d’un humain qui était déjà inclus dans la communauté monétaire.
5/ Une fois la révocation de compte pour perte de pass validée comme légitime, toto2 peut demander le transfert de son ancien solde toto vers son nouveaux compte toto2.
Soyons clair, le but de ce topic n’est pas de demander aux développeurs, déjà bien assez surmené de développer cette proposition.
Dans un premier temps je souhaite simplement discuter du protocole.
Et si nous parvenons à un consensus sur une évolution du protocole qui vous semble pertinente alors qui sait peut-être que je me motiverai à la coder moi même seul ou avec ceux qui souhaiterait m’y aider
mais ça me demanderai beaucoup de temps car je n’ai jamais contribuer a aucun projets d’autres personnes. J’ai toujours coder seul et seulement pour le plaisir de coder (en C++ et php uniquement). je suis un petit programmeur du dimanche pas un développeur.
Mais je compte bien venir aux journées informatiques des RML8 pour apprendre
Bref, je ne veut pas jouer les yakafaukon. Je souhaite simplement dans un premier temps, discute du meilleur protocole possible pour traiter les cas légitimes de perte de mots de passe ou/et de clé privée, qu’en pensez vous ?
Personnellement, je pense qu’il faut d’abord traiter fonctionnellement les différents cas d’utilisation que l’on peut avoir. J’en vois trois :
Le changement/renouvellement de mot de passe : Dans un système informatisé qui a pour cible de fonctionner plus dizaines voir centaines d’années, il faut absolument que les individus puissent changer le mot de passe correspondant à leur identité. Ce, pour des besoins de sécurité principalement.
Ce changement est différent du “Transfert de monnaie + Révocation + Publication” car il ne doit pas provoquer de rupture dans les certifications et statut d’adhésion. Pour ce mécanisme, l’utilisateur connaît son couple (clé secrète, mot de passe) actuel et son futur couple (clé secrète, mot de passe).
La possibilité de retrouver un compte perdu/volé. C’est le cas que tu décris dans ta proposition. Dans ce cas, l’utilisateur ne possède plus le couple (clé secrète, mot de passe) précédent. Il peut cependant avoir pris ses précautions et enregistré ou imprimé son document de révocation sur un support protégé. Un document de redécouverte de mot de passe pourrait être basé sur la publication d’un document de révocation concaténé à un document de publication d’identité, le tout signé par la nouvelle clé et potentiellement par d’autres membres du réseau.
Le cas de la perte de mot de passe de clé publique associée à de la monnaie mais non associée à une identité. Faut-il le traiter ? Aucune cryptomonnaie ne l’a réalisé jusqu’à présent, et dans ces situations tout fonctionne via un tiers de confiance.
Dans Sakia/Cesium/Duniter, aujourd’hui on utilise la génération à la volée par couple identifiant + mot de passe. Mais ce n’est qu’un cas parmi tant d’autres possibles ! Par exemple, on peut tout à fait générer un trousseau sur la base de « l’aléatoire » fourni par l’ordinateur sur lequel on se trouve, qu’il faut alors stocker pour le retrouver plus tard.
Et donc vous comprenez bien ici qu’à aucun moment le protocole ne pourrait traiter du changement de mot de passe, puisque de son point de vue, ça n’existe tout simplement pas. C’est un 1er point.
2ème point, concernant la perte d’accès à son identité personnelle : le protocole prévoit un document de révocation d’identité, comme le souligne @inso. Ce document permet d’empêcher que quelqu’un usurpe notre identité. Il n’empêche pas une personne qui connaîtrait notre clé privée de voler la monnaie se trouvant sur le compte.
Et donc 3ème point : que faire si une personne perd sa clé privée associée à de la monnaie ? Je suis du même avis qu’inso, et peut-être toi aussi eloïs, laissons l’utilisateur méditer sur la causalité et le sens de la vie :
Et donc au final, je pense que le protocole ne doit pas gérer la « récupération de mot de passe ».
On peut voir ça autrement. Les algos de crypto expirent régulièrement (RSA 2014 aurait été cassé la semaine dernière par exemple). Je pense qu’il faut pouvoir changer régulièrement la clé publique associée à une identité, puisque les algos qui génèrent cette clé publique peuvent expirer. Il faudrait que ce changement de clé publique puisse être réalisé en toute transparence sans que ça interrompt le cycle de vie de l’identité de l’utilisateur.
Oui, il vaut pouvoir changer de crypto si besoin. Mais comment le protocole peut-il spécifier un algorithme si celui-ci est encore inconnu ? A mon avis c’est le genre de changements qui s’appliquera à travers une évolution du protocole de façon ultérieure.
C’est peut-être souhaitable, mais ce n’est pas nécessaire : un utilisateur qui souhaiterait changer de clé peut révoquer son identité et en créer une autre, comme nous l’avons déjà fait dans TestNet (@Moul de mémoire), et de redemander légitimement les certifications à leurs émetteurs, avec comme preuve de bonne foi la précédente identité formellement révoquée.
De sorte que si rupture il y a, elle peut être très courte (quelques heures à quelques jours, voire semaines) et cela n’a pratiquement aucune incidence sur la production personnelle de monnaie, si le DU est quotidien par exemple.
Donc si je peux éviter cette complexité, je le ferai. Rien n’empêche d’autres développeurs dans le futur d’ajouter cette fonctionnalité par contre !
Je ne parle que de la crypto utilisée pour la génération des clés publiques/privées des utilisateurs (le salt/password actuel en sommes)
Tout à fait. Cependant, en cas de faille de sécurité découverte et qui impose un changement massif des clés des utilisateurs, la toile et la blockchain risque d’être très fragilisée si les identités doivent toutes passer par une case de révocation/certification.
Cette complexité me semble nécessaire mais pas à court-terme, c’est sûr Avis aux motivés pour travailler là dessus !
Je ne comprends pas bien : si le problème vient de l’algorithme utilisé (ed25519 par exemple) alors changer de salt/password ne changera rien. Donc je suppose que tu parles d’autre chose, mais quoi ?
De la clé publique/privée de manière générale !
Du côté de Duniter, c’est libsodium/libnacl qui s’occupe de la vérification… On peut leur filer un seed qui n’est pas généré par ed25519. Et donc si ed25519 est attaqué, et qu’il faut changer d’algo, il faut pouvoir changer les clés publiques vérifiées par le protocol.
Oui c’est sûr, Ed25519 (NaCl/libsodium) c’est l’algorithme de cryptographie asymétrique. Si je ne me goure pas, c’est ce qui fait le lien entre :
un très grand nombre secret
une clé publique
une clé privée
une signature et un contenu
Le seed étant donc juste le très grand nombre ci-dessus, qui peut-être quelconque et par exemple aléatoire, ou bien dérivé de nos fameux identifiant/mot de passe par un algorithme spécifique comme scrypt. D’ailleurs nous on utilise scrypt depuis le début, mais d’une part on n’est pas obligé et on peut choisir autre chose, et d’autre part le protocole est totalement insensible à cela quoi qu’il arrive : lui ne voit que les éléments listés ci-dessus (clé publique, privée, signature, contenu) et utilise NaCl pour tester la cohérence du tout.
Et donc, si Ed25519 est attaqué, c’est bien l’algorithme utilisé par le protocole qu’il faut changer dans son entièreté au profit d’un autre … mais qui forcément doit avoir été choisi préalablement, sinon le protocole ne saura pas le gérer.
Par conséquent, si Ed25519 est attaqué et que Duniter ne possède pas d’alternative à ce moment-là, c’est foutu. En réalité, il aura dû intégrer depuis longtemps déjà d’autres algorithmes que Ed25519, afin que justement tous les utilisateurs n’utilisent pas le même algo, le même type de clés, etc, et doivent tous changer en même temps.
Bref Duniter devra généraliser son protocole pour accueillir plusieurs algorithmes de cryptographie asymétrique, sans attendre d’être au pied du mur pour le faire. Et s’il n’est pas nécessaire d’avoir un mécanisme de “changement” de clé à la volée, il est certain que ce serait quand même plus pratique s’il y en avait un, je le concède !
Vous aurez compris ce que je veux dire : la priorité n’est pas tant de pouvoir changer de clé à la volée que d’avoir plusieurs algorithmes possibles de cryptographie asymétrie.
Sans compter le fait déjà vu, qu’en cas d’attaque considérée comme trop importante, il existe la possibilité pour l’ensemble de la communauté de revenir à un état antérieur de la blockchain, avant l’attaque, qui permet alors de reprendre depuis un état sain, avec de nouveaux algorithmes.
Cette procédure de retour en arrière permis par la blockchain, et qui doit être approuvé par l’ensemble pour se faire (techniquement), est un procédé de confiance forte pour les cas de problèmes forts, qui existe et reste parfaitement imparable.
Merci Inso pour la distinction de ces 3 cas effectivement très différent.
Mon intervention ne portait que sur le second cas “La possibilité de retrouver un compte perdu/volé”.
Je croyais que le 1er cas “Le changement/renouvellement de mot de passe” était déjà implémenter dans Duniter, finalement le projets est moins abouti que ce que je pensais, il reste encore beaucoup à faire !!
Quand au 3ème cas “Le cas de la perte de mot de passe de clé publique associée à de la monnaie mais non associée à une identité”, je pense comme toi qu’il n’est pas nécessaire de traiter ce cas. Dans la pratique ce type de compte sera surtout destiné aux personnes morales, donc avec plusieurs personnes physiques responsables derrières qui auront toutes l’intelligence de conserver une copie d’un certif de révocation.
Pour revenir sur le cas qui m’intéresse “La possibilité de retrouver un compte perdu/volé” pour une personne physique, je pense que cette fonctionnalité est essentielle, et que si l’on déploi une monnaie libre sans cette fonctionnalité nous n’obtiendrons pas la confiance de Mme. Michu qui n’y connais rien en informatique et qui ne pensera pas a garder en sûreté une copie d’un certificat de révocation qu’elle doit en plus pensée a générer avant de perdre sa clé privé ou son pass !!
Je comprend que tout cela fait beaucoup de boulot, et je comprend que @cgeek n’ai pas envie de le faire, il en a déjà tellement fais.
Ceci dit, il faudra bien que des contributeurs mettent en place ces fonctionnalités indispensables AVANT la création d’une VRAI Monnaie Libre.
Je n’ai pas les compétences pour cela mais je veut bien apprendre, c’est pourquoi je compte venir aux journées informatiques des rml8.
Je n’ai pas énormément de temps mais si je peut participer a l’effort collectif nécessaire a l’aboutissement de Duniter ce sera avec grand plaisir
Galuel cela est possible pour le moment car nous sommes encore très peu nombreux.
Comment fera t’on si un tel problème se présente à 1000 voir 10000 utilisateurs ?
Non je pense comme @inso que l’on doit consolider Duniter en amont en intégrant plusieurs algorithmes différents (au moins 3 ou 4) et en permettant le changement de clé !
De plus en plus de gens entendent parler des monnaie libres, et nous faisons un travail long et laborieux de sensibilisation pour les convaincre d’avoir confiance et les monnaies libres. Si nous lançons une première “vrai” Monnaie Libre trop tôt et que cette 1ère vrai monnaie libre subit une attaque a laquelle Duniter n’est pas assez bien préparer, nous risquons de rater l’avènement des monnais libres, même si l’on trouve les solutions techniques pour continuer. Parce que les humain n’aurons plus confiance, et sans les humains nous n’arriverons a rien !
Ouais je me suis totalement mélangé les pinceaux ! C’était bien de scrypt que je voulais parler, et plus généralement le fait de découper les clés publiques des identités.
Ok avec ton argumentation + le rappel de Galuel. C’est effectivement la meilleure des choses à faire : supporter un maximum de type de clés sur le réseau.
Reste toujours le usecase pour Madame michu. Je pense toutefois que la gestion du document de révocation peut faire l’affaire si on arrive à rendre ça “user friendly” du côté des clients.
Ce qui pourrait être bien pour que ce soit “user-friendly” coté client,
c’est de générer par défaut un certificat de révocation lors de la création de l’identité et de proposer immédiatement à l’utilisateur de le sauvegarder sur son disque dur.
Mais prenons le cas de quelqu’un dont l’ordinateur rend l’âme et qui n’a pas pensé a sauvegarder son certificat de révocation sur un support externe ?
Ce serait bête que cette personne ne puisse pas récupérer son solde, surtout que la Toile de Confiance nous permettrais d’avoir une bonne assurance que la demande de transfert de solde est légitime si elle doit être confirmée par des personnes qui sont à un pas de 1 du compte perdu.
Je me projette a long terme et j’imagine la frustration d’un utilisateur qui perdrais tout son solde au bout de 10 ans par exemple… je suis d’accord qu’une telle fonctionnalité n’est pas la priorité, mais je pense qu’il faudra la mettre en place tôt ou tard.
Si je résume les priorité donc :
Faire en sorte que Duniter gère les jeux de clés de plusieurs algorithmes différents
Permettre le changement de clé par un utilisateur qui à toujours son ancienne clé via le certificat de révocation.
Plus tard, lorsque tout cela sera fait. Permettre a l’utilisateur lambda de transférer son solde de son ancien compte ou il n’a plus accès vers son nouveau compte et prévoyant les mécanismes de protection nécessaire pour limiter les abus possibles.
En fait je me rend compte avec vos réponses que la fonctionnalité que je propose arrive bien trop tôt. Il y a plus important a faire d’abord.
J’avoue que vos échanges sur les différents algorithmes de cryptographie sont un peu du chinois pour moi mais si vous avez quelques liens sous le coude qui explique tout cela, je suis preneur. je vais de ce pas faire quelques recherches pour m’instruire
Je confirme ce point, suite à plusieurs discussions avec un ancien de la cyber-défense (Eric Filiol - un lavalois !) : il m’indique en effet qu’il faut penser à utiliser des algos non-gérés/implémentés par la prédominance anglo-saxons, car nous savons qu’ils investissent massivement pour en contrôler le code, afin d’en connaitre (ou créer) les failles. Voir cette vidéo de la chaine Thinkerview.
Il m’indique également qu’il ne croit pas du tout à la périnnité, en l’état, de monnaies alternatives comme Duniter, à moins de :
s’assurer de ne pas avoir une seule monnaie, pour plus de résililence;
d’utiliser différents algorithmes de crypto,
algo qui doivent être établi et maintenu par une recherche (notamment universitaire) indépendante des financements anglo-saxons.
A mon avis, il faut avoir en tête que nos “enemies” ne seront pas les états, mais plutôt des pirates payés par les grandes banques privées, notamment anglo-saxonne, dont on connait la puissance de feu… et le lien avec les laboratoires de crypto.
Sans attendre, et sans changer le protocole, vous pouvez sauvegarder vos clefs privées avec l’api python :
Les clients peuvent rapidement implémenter le chargement de ces clefs en plus des codes d’accès actuels.
Ce qui donnera une seconde chance en cas de perte des codes.
Je vais aussi faire un tutorial pour sauvegarder le document de révocation.
I really hope this kind of hard-fork (similarly to how Ethereum dealt with the DAO hack) will not be possible with Duniter. In my opinion, immutability is the single most important feature of a blockchain.
You cannot oblige other people to follow you. You can follow one blockchain fork or another one. Other people can follow you or not, but this cannot be an obligation.
For sure these kind of things should be used with caution. But in case of massive hack of the blockchain, this can be used to protect the currency against its attackers.
For Ethereum, the problem is that this blockchain is making the promise to execute Turing-complete contracts, and that miners would not watch what is executed. Obviously, this was a big lie.
In the end, it’s up to the users to decide what to do with their common blockchain. Doing a hard-fork is always something risky, you can totally destroy the trust in your currency. So this should be avoided as much as possible.
Oui, donc il y croit. Tout ce qu’il dit, en résumé, c’est qu’il faut retirer les centres de contrôle :
décentraliser les participants (P2P, c’est fait)
décentraliser les algorithmes (à faire)
décentraliser la recherche sur les algorithmes (à faire)
décentraliser X, Y, Z
Décentraliser ou, comme je préfère ce terme, rendre libre X, Y ou Z. Mais croire qu’on pourra libérer tout cela sans monnaie libre au départ, même si celle-ci en encore constituée de nombreux points de centralisation, c’est peut-être remettre à trop tard la réalisation de tout ce qu’on souhaitait.
Bref, bien évidemment, chez Duniter et les Monnaies Libres, on plutôt d’accord sur ces points.
Avis aux motivés pour travailler là dessus !
