[Idée] Clé déléguée au calcul de blocs

Je trouve que tu prends le problème à l’envers.

Si tu autorises les certifications, c’est la communauté que tu met en danger lorsque les utilisateurs sont irresponsables (à travers les attaques Sybille)

Si tu autorises les révocation, seul le compte de l’utilisateur est en danger. La communauté souffre moins du risque qu’il prend (mise à part la main mise sur le réseau, qui apparaît dans les 2 cas de toute façon, et qu’on souhaite empêcher en responsabilisant les utilisateurs vis à vis de leur clé)

2 Likes

Non ce n’est pas incommodant pour le membre en question, s’il est peu scrupuleux il s’en fou que d’autres puissent certifier en son nom. Par contre il tiendra a ses DU, auxquels il n’aura plus droit en cas de révocation :wink:

1 Like

C’est justement ce que l’on veut éviter avec la clé déléguée : mettre le compte utilisateur en danger.

Non, ce que l’on veut éviter avec la clé déléguée, c’est de mettre la communauté en danger a cause d’un vol de clé sur un noeud membre.

La révocation ne met personne en danger. Recréer un compte va vite quand on a déjà été certifié. Ça peut même se faire en 24h. La monnaie est toujours à l’abri, elle, sur la clé principale.

Les certifications, ça met tout le monde en danger. C’est beaucoup, beaucoup plus dangereux.

3 Likes

D’ailleurs si l’on met en place ce système de clé déléguée je serais pour que l’on interdise a la clé membre principale de calculer des blocs. je pense notamment aux utilisateurs non informaticiens qui installer Duniter sur un windows mal sécurisé, je vois venir la rafle massive de clés un de ces jours !

3 Likes

Je vois.

Complètement d’accord.

1 Like

En même temps, si il installe un logiciel pour gérer son identité et qu’il se fait pirater sa clé, les attaquants peuvent alors aussi générer la clé déléguée…

Peur être qu’on est pas encore allé au bout de la réflexion au sujet des mécanismes de sécurisation des noeuds. L’idée de la clé déléguée ne me convainc qu’à moitié pour le moment…

2 Likes

L’idée serait que le membre peut a tout moment déclarer une nouvelle clé déléguée qui annulera le pouvoir de calcul des blocs de la clé déléguée précédente. Mais oui en tout les cas si un membre se fait dérober sa clé membre principale, la révocation reste le seul recours.

2 Likes

Du coup en effet, au niveau de la sécurité globale du réseau ça me semble être le mieux. A voir s’il y a moyen d’aller plus loin sans rendre ça trop complexe pour l’utilisateur.

1 Like

@Inso en fait je n’ai pas compris ta crainte, en quoi le fait qu’un attaquant qui aurait dérober une clé membre puisse générer des clés délégués est “plus grave” que le vol de la clé membre en lui-même ? Ça ne change rien.

Il a quand même une subtilité que j’ai en tête : Pour réduire le stockage seule la dernière clé déléguée déclarée serait en base de donnée, ce qui en soi n’empêche pas les clés précédentes de révoquer le compte mais cela demanderai a Duniter d’aller ré-extraire de la blockchain une info qu’il a supprimer, c’est un peu gênant.
Ou alors on accepte l’idée que les anciennes clés délégués ne peuvent pas révoquer le compte. Cela reste-il acceptable selon vous ?

Selon moi seule la dernière clé délégué est valide. De ce fait si elle est compromise mais que tu la remplace, alors l’attaquant ne pourra pas révoquer le compte car sa clé n’est plus valide.

Et comme la clé délégué ne permet que de calculer et révoquer le compte, l’argent present sur l’adresse n’est pas en danger. Seul la certification et le DU peuvent sauter, mais en effet il suffirait de se faire certifier un nouveau compte (même si je doute que ça ne prenne que 24h à se faire). Mais c’est une bonne chose, ça reste une incitation à bien sécuriser son environnement pour ne pas perdre son temps à refaire un compte.

C’est un comportement possible, et c’est plus optimisé coté logiciel, mais on peut aussi décider que les anciennes clés délégués gardent un pouvoir de révocation, la question se pose en tout cas !

Je ne vois vraiment pas pourquoi elles garderaient leur pouvoir de révocation. La révocation incite à protéger sa clé et de la changer si elle est compromise. Si l’utilisateur change la clé, celle ci n’a plus aucune valeur pour le réseau. C’est beaucoup plus simple à gérer au niveau logiciel et c’est beaucoup plus logique. Ce n’est plus possible de céder le pouvoir de calcul, donc aucune raison de pouvoir révoquer un membre avec une ancienne clé.

Hop voilà le ticket : https://github.com/duniter/duniter/issues/1208

Justement, je me demande si ça apporte réellement quelque chose en terme de sécurité :slight_smile: si on se serait pas mis dans un effet tunnel en se concentrant sur cette solution qui n’apporte finalement peut être pas grand chose.

Si on repart du besoin, tel qu’on l’a exprimé aujourd’hui :

  • Réduire l’exposition sur le web des clés membres qui sont des clés qui donnent “tout les droits” membres :
    • Calculer des blocs
    • Certifier des utilisateurs
    • Co-créer le DU
  • Faire en sorte que ce soient bien les utilisateurs qui calculent et qu’ils ne délèguent pas leur droit à un prestataire

Est-ce que finalement, le besoin ne serait pas de réduire les droits des clés membres, ou en tout cas de distinguer ces droits en clés différentes ? Je pense comme ça à un mécanisme du type :

  • Clé membre = Certifier des utilisateurs, Co-créer des DU, accorder l’autorisation de calculer des blocs
  • Clé calculateur = Calculer des blocs.

Pour qu’une clé obtiennent le statut de “membre”, il faut rentrer dans la toile de confiance. Pour qu’une clé obtienne le statut de “calculateur”, il faut que N membres lui accordent ce droit, et qu’elle soit associée à une clé membre qui n’est pas déja associée à un calculateur.

Un membre ne devrait certifier un nouveau membre que si il a bien compris ce que ça implique et qu’il le connait (de pas certifier online, etc).
De la même manière, un membre ne devrait autoriser un calculateur que si il a bien compris ce que ça implique (hébergement, sécurité, pas chez un prestataire, etc).

2 Likes

Que veux-tu dire par “prestataire”.
Si tu veux parler d’un serveur dédié, c’est dommage si tu veux construire quelque chose au dessus de Dunite et que tu as besoin d’avoir un noeud membre à disposition pour éliminer tout tiers de confiance, sans pour autant rediriger le trafic sur sa ligne internet perso. Si ton service a du trafic, je ne pense pas que ça soit une bonne idée de l’héberger chez soi.

Il faut que la clé délégué :

  • n’ai pas d’impact négatif sur la communauté
  • essaye d’aporter une couche de sécurité aux membres qui veulent calculer.

La solution précédemment énoncée (clé délégué qui permet de calculer et de révoquer le compte) incite le membre à en prendre soin et à ne pas la donner à d’autre personne, tout en protégeant son argent en cas de faille. Comme cette clé est remplaçable, on peut très bien imaginer qu’en cas d’attaque le membre change directement de clé pour éviter d’avoir son compte révoqué (si ce n’est pas encore fait).

Je parle d’un équivalent à une société dont le service serait d’héberger des noeuds duniter à partir des clés des utilisateurs.

La limite que je vois avec la clé déléguée, c’est le scénario suivant :

  • Un membre ne fait pas attention à sa clé membre
  • L’attaquant utilise sa clé membre pour générer le clé déléguée de calcul. Il ne touche à rien sur sa clé membre (pas de vol de DU, pas de certification frauduleuse - l’utilisateur n’est pas au courant de l’attaque)
  • L’attaquant reproduit l’attaque sur N membres (via un malware par exemple) : il a maintenant à sa disposition N clés déléguées lui permettant de s’attaquer au réseau

Quand on voit l’évolution du nombre de clés membres disponibles par rapport au nombre de clés membres qui sont utilisées pour calculer, cette attaque pourrait être très efficace (dans le réseau actuel il “suffit” de récupérer 30 clés sur 430 utilisateurs pour y arriver) : https://g1-monit.elois.org/membersCount?lg=fr

Plus le nombre de membres calculant sera un petit pourcentage du nombre de membres, plus cette attaque est dangereuse.

Je vois 2 défenses contre cette attaque :

  • Augmenter le nombre d’utilisateurs ayant les compétences (sysadmin, sécurité, disponibilité) pour monter un noeud qui calcul et sécuriser le réseau
  • Authentifier les clés de calculateur dans un subset des clés membres, pour ne pas permettre à n’importe quelle clé membre de participer à la sécurisation du réseau, mais seulement les clés qui ont été vérifiées par des humains membres du réseau
2 Likes

Donc tu proposes une 2eme couche de certifications pour calculer les blocks ?

A ce moment là, qui peut donner ces certifications ? Tous les membres certifiés, ou seulement les calculateurs ?

L’idée me semble intéressante, à voir comment ça pourrait être mis en œuvre.

On pourrait imaginer que c’est la clé délégué qui est certifiée. Si le calculateur change sa clé parcequ’elle est compromise (et qu’il veut protéger son DU), il doit repasser par des certifications pour s’assurer qu’il fera attention à la sécurité de son noeud.

D’après moi, tous les membres certifiés. La seule règle serait par exemple “au moins 3 droits au calculs doivent être reçus pour pouvoir calculer avec une clé de calculateur”.

Évidemment, cet accord de “droits au calcul” devrait être affichés dans les clients, de façon à ce que si la clé est compromise et que le droit au calcul est donné à une clé déléguée contre la volonté de l’utilisateur, celui-ci puisse s’en rendre compte.

1 Like