Multiple clef par identités

Hello,

Je suis en plein apprentissage du protocole Duniter et je trouve que quelque chose manque. Il n’y a qu’une seule paire de clef publique/privée pour une identité.
Ca signifie que si je me fait voler ma clef privée, c’est totalement mort pour mon identité. Bon dit comme ça, c’est logique, mais ça rend l’authentification rapide impossible (du moins sans prendre des “gros” risques).

Si on me vole mon via scan QR code, je ne peut pas juste bloquer ce QR code.
Encore pire si un client contient une faille qui permet de récupérer la clef privée.
Même je réagit au vol très tôt, je ne peut que révoquer mon compte et vite transférer mon solde ailleurs. Il n’y a pas de changement de mot de passe possible comme sur la plupart des applications.

L’idéal pour éviter tout problème est de toujours ce connecter avec le login / pass mais ce n’est pas pratique (même avec un gestionnaire de mot de passe).
Un contournement actuel est d’utiliser un portefeuille pour limiter les dégâts. Mais encore une fois ce n’est pas pratique (puisqu’il faut faire des transferts préalable, et donc une connexion “lente” par login / pass).

Toute les applications modernes ont un système pour se connecter plus rapidement sans avoir à rentrer login / pass à chaque fois. Empreinte digitale / code pin / …
Ses systèmes réduisent la sécurité mais c’est “ok” puisque la sécurité est réduite uniquement sur le périphérique de l’utilisateur. Dans l’idéal, il est même possible de couper cet accès moins sécurisé à distance si on perd le périphérique qui l’utilisait.

Coté Duniter, si on pouvait avoir plusieurs clef publique par identité, cela permettrais d’utiliser une paire de clef public/privée par application (et périphérique du coup) et pouvoir couper un accès rapide d’un périphérique à distance en cas de problème (faille, vol, …). A partir de la, on peut implémenter des raccourcis pour payer plus vite, sans risquer de compromettre la clef privée principale. (Comme l’oauth en somme…). Les applications n’ont alors pas besoin de connaître la clef privée “primaire”.

En résumé : une clef publique “primaire” pour tout les opérations (révocation, retirer/ajouter d’autres clefs “secondaire”, certifications…), et N clef “secondaires” pour effectuer des seulement des transactions. Ne pas permettre une autre méthode que login / pass lors de la connexion via un client avec la clef “primaire”.

Peut-être que ce que je propose n’est tout simplement pas possible, je ne suis pas encore capable de le déterminer tout seul :sweat_smile:
Désolé par avance si j’ai raté un post du forum qui parle de ça (j’ai cherché! :stuck_out_tongue:); j’imagine bien que je suis pas le premier à être gêné par ce système.

1 Like

Hello,

tous les systèmes login/mot de passe sont gérés par un serveur centralisé : c’est lui qui détient les clefs, t’identifie, et te renvoie (le cas échéant) un lien de réinitialisation.

Avec la blockchain pas de serveur de ce genre. Tout est écrit, partagé et distribué. Techniquement ce que tu propose serait peut-être faisable, mais chaque action devrait être écrite dans un bloc, ce qui aurait plusieurs effets problématiques :

  • alourdissement de la chaîne,
  • plus (+) d’information rendues publiques (qui oublie quel identifiant où, quand, sur quel périphérique),
  • perte d’importance des identifiants. Actuellement un mot de passe inchangeable a l’avantage de montrer son importance. En cas de compromission, il faut effectivement révoquer et recommencer le processus de certification.

Pour l’identification rapide, il te suffit de créer un compte portefeuille : en cas de compromission, tu limites la perte, et tu n’affaiblis pas la toile de confiance.
Tu peux en créer autant que tu veux, et pour changer d’identifiants il suffit de tout transférer sur un nouveau portefeuille.

Pour moi, le compte membre devrait n’être accédé que de temps en temps (certifier quelqu’un, renouveler son adhésion, et transférer ses Ğ1 sur un compte + pratique).

1 Like

C’est vrai que la possibilité d’avoir plusieurs trousseaux pour le même compte peut être utile dans certains cas. Par exemple un enfant pour qui les parents créent un compte et dont ils gardent les identifiants. Plus tard ils veulent lui donner le plein contrôle de son compte, pour ne pas avoir à refaire les certifications (avec donc une période où le DU ne sera pas produit, si on respecte la licence) on pourrait créer un deuxième trousseau pour le compte et supprimer l’ancien.

Le problème est que la clé publique est calculée en fonction du trousseau, il apparaît donc impossible d’avoir plusieurs clés privées pour la même clé publique (et de toute façon on ne peut pas révoquer la clé privée sans révoquer la clé publique avec). C’est probablement un champ de recherche en cryptographie qui reste à explorer…

Yes je fait bien la diff entre la blockchain et un système centralisé.

Oui bien sûr. La question est : à quel point c’est un problème ? (par rapport au problème initial).

Donc je dois détailler le “pas pratique” :
→ Pas intuitif du tout : va donc demander à un nouvel utilisateur de crée deux compte et de n’utiliser que le deuxième et des fois le premier pour les certifs.
→ Transfère d’argent à faire en amont. Donc encore du jonglage entre les comptes.
→ Faire comprendre à l’utilisateur que le compte principal ne doit être accédé que de manière très sécurisée.

Exactly. “Pour toi”. Il faut quand même garder quand tête que beaucoup d’utilisateur ne voudront pas se prendre la tête sur ça au détriment de la sécurité. La plupart des utilisateurs que je croise utilisent directement leurs compte membre.
Ce que je propose est un compromis déjà utilisé partout (cf oauth), et a priori faisable en blockchain si je me plante pas.

Ce que je propose est une amélioration, on est d’accord, ça fonctionne aujourd’hui.

Non je parlais de plusieurs paire de clef, pas seulement privée.
Dans le format identity : duniter/doc/Protocol.md at master · duniter/duniter · GitHub
L’idée serait de rajouter des champs en plus de Issuer: PUBLIC_KEY qui référence des clef publique “secondaires”.

Bonjour @Wykks :slight_smile:

2 Likes

Intéressant :slight_smile:
Je comprend pas grand chose (pour le moment!) et ça vise pas exactement le même besoin mais apparemment ça peut permettre la même chose. Bon manque de bol, pas de news depuis fin 2017 :open_mouth:
Merci pour le lien :smiley:

A mon humble avis, faut s’inspirer de ce qui marche bien dans les autres crypto-monnaies, donc en l’'occurrence des HD wallet.

Mais dans tout les cas ce n’est pas a la blockchain de gérer les authen légères, il faudrait des services tiers centralisés qui proposerait cette prestation, et qui ne publierai que les preuves en blockchain (révocation d’une sous-clé, etc)

2 Likes

Mais le service tiers va devoir stocker la clef privée non ? Et il ne peut que la chiffrer de manière symétrique puisqu’il doit pouvoir la lire pour signer (Ou j’ai raté un truc ?).

Je comprend pas trop les raisons qui empêche d’autoriser plusieurs clef par identité. J’imagine que ça ajoute trop de complexité (comme dit par @Nartagnan), mais c’est pas clair dans ma tête :sweat_smile:

Bref, il me manque encore beaucoup trop de connaissance pour continuer de réfléchir sur ça de toute façon… N’empêche qu’il y a un problème assez important à corriger. On ne peut tout simplement pas éduquer tout les utilisateurs à bien faire à ce niveau. La réalité actuelle le prouve déjà.

ben non avec les HD wallet justement tu pourra donner une sous-paire de clés au service tier que tu pourra révoquer en cas de fraude du service tier. La blockcahin ne gèrerai pas l’authen légère, elle gèrerai uniquement la révocation des sous-clès (la déclaration n’étant pas nécessaire grâce au principe des HD wallet)

1 Like

Ah d’accord, j’avais pas compris que quand tu parlais de service tier c’était en plus des HD wallet :smiley:

1 Like