Si n’importe quel membre peut certifier pour calculer, alors un membre qui rejoint la Wot peut très bien se faire certifier pour calculer par ceux qui l’on fait entrer. Il n’y pas vraiment de sécurité supplémentaire.
La sécurité est comme dans l’application de la licence : ne certifiez un membre qui souhaite calculer que si il a les moyens techniques d’héberger correctement un noeud. Ne prenez pas la responsabilité d’héberger un noeud si vous n’en avez pas les compétences.
Ceci dit, pour l’attaque que j’évoquais plus haut, comment la traiter avec le système de clés déléguées ?
Les clients devraient avertir de la déclaration/utilisation d’une clé déléguée (qui devrait être inscrite en blockchain de toute façon). Ainsi, un utilisateur qui n’a pas de noeud mais qui voit une clé déléguée être déclarée pourrait la révoquer, ainsi que sa clé membre.
Le problème ici est :
- Est-ce qu’un utilisateur aura vraiment envie de révoquer sa clé déléguée ? Pour se protéger, il doit révoquer son identité et sa clé déléguée. Si cet évènement arrive, la clé déléguée permet de révoquer son identité. L’utilisateur pourrait se dire “tant que l’attaquant de me révoque pas, je m’en fiche…”
Pas besoin de révoquer son identité si seule sa clé délégué est exposé. La clé délégué permet de révoquer l’identité, sauf si elle a été remplacé par une nouvelle clé.
L’utilisateur a un intérêt de changer sa clé délégué si elle est compromise pour ne pas risquer de perdre son identité justement.
3 Likes
Tu as raison, ce point m’avait échappé 
Mais l’idée de certifier pour calculer me semble intéressante. Je pencherais plus à des certifications de la part des membres calculant, car plus à même de vérifier que le noeud est assez sécurisé. Un membre qui n’y connait pas grand chose en sécurité informatique ne pourra pas juger de la robustesse du nœud 
Après je partirai sur un nombre de certifs plus faible, 2 ou 3. La certif serait faite envers la clé délégué, de sort qu’en cas de changement il faut repasser par des certifications, potentiellement en expliquant quels étaient les failles et ce que la personne compte faire pour que ça n’arrive plus. Si un membre prend ça trop à la légère et change de clé de calcul trop régulièrement, on peut décider qu’il est trop risqué de le laisser calculer.
La question est de savoir dans ce cas comment initialiser le système. On inscrit en dur au bloc xxx ceux qui ont le droit de calculer (et donc de certifier les autres), un peu comme au bloc 0. Vous vous rendez quand même compte que vous êtes en train de bâtir une deuxième toile de confiance au sein de la première, là? 
Mais c’est vrai ça c’est un peu flippant:
parce que cette situation (moins d’un membre sur 10 qui calcule) ne risque pas de s’estomper avec le temps, au contraire…
Exactement.
Oui, mais le calcul des blocs est plus critique que le statut de membre. Après je pencherais pour un nombre de certifications plus petit vu qu’il y a moins de personnes qui calculent. 2 ou 3 me semble suffisant. Un membre lambda n’ayant pas forcement les connaissances pour déterminer si un nœud calculant est sécurisé ou pas, il ne me semble pas bon de leur laisser cette possibilité. Après cette 2ème couche de confiance pourrait être plus facile d’accès que le statut de membre. Pas forcement besoin de connaître la personne en vrai, simplement discuter avec lui pour savoir sur quoi il l’héberge, s’il a fait les configurations de base pour se protéger, etc. Les calculateurs pourront sûrement aider de nouvelles personnes et partager leur connaissance pour avoir un réseau plus sûr. Enfin si une personne n’a pas encore moyen d’avoir une plateforme assez sécurisée, il peut toujours faire un nœud miroir qui ne compromet pas son identité, la sécurité du réseau mais qui augmente la redondance des données ainsi que la bande passante du réseau.
Le plus gros problème aujourd’hui, c’est que les membres ne sont même pas au courant que leur clé est en train de calculer si jamais elle est compromise.
La clé déléguée permettrait de régler ce problème (les clés calculantes sont inscrites en blockchain)…
J’y repense, le problème n’est pas là. Si l’utilisateur n’a pas émi de clé déléguée pour calculer, mais qu’il se trouve que son client l’avertit qu’une clé déléguée est présente sur le réseau et calcule à sa place, il va bien se retrouver dans la situation que j’ai décris :
Est-ce qu’un utilisateur aura vraiment envie de révoquer sa clé déléguée ? Pour se protéger, il doit révoquer son identité et sa clé déléguée. Si cet évènement arrive, la clé déléguée permet de révoquer son identité. L’utilisateur pourrait se dire “tant que l’attaquant de me révoque pas, je m’en fiche…”
Comme proposé plus haut, on ne pourrait calculer qu’avec une clé déléguée, et plus avec sa clé privée.
A ce moment là au moins 2 possibilités :
- Le membre déclare sa clé déléguée et peut directement miner avec
- Le membre déclare sa clé déléguée, puis d’autres membre doivent la certifier pour qu’elle puisse être utilisée pour calculer des blocs.
Le calcul de bloc devrait être en option et désactivé par défaut (ce qui sera le cas si la clé déléguée de calcul devient obligatoire).
Après on pourrait réfléchir pour trouver un moyen de détecter l’utilisation de la clé sur une machine qui n’est pas la notre, et ceux sans dégrader la vie privée de la personne.
1 Like
Si l’on considère le cas d’un attaquant avec un minimum de moyens capable de déclarer une clé déléguée à l’insu de son propriétaire (on suppose là que la clé a pu être dérobée), alors obtenir 3-4 certfications de calcul ne me semble pas être une protection suffisante, même sans complices (vu qu’il peut voler des clés).
Par contre on peut rendre la procédure moins immédiate en instaurant des règles diverses comme :
- une clé déléguée doit attendre 5 jours/blocs avant d’être utilisable
- une clé déléguée sortie de la fenêtre courante devient inactive subit un handicap
- …
Autre piste
On joue sur la difficulté personnalisée pour mitiger le contrôle par l’attaquant.
J’ai déjà parlé des clés déléguées VRF dans un autre sujet, permettant de faire du tirage au sort. Ce que j’ai en tête, de façon non définitive et non formalisée : on peut imager 3 tranches égales de calculateurs, avec comme aujourd’hui 1 tranche de calculateurs exclus. Les 2 tranches restantes n’auraient pas de difficulté excluante, mais on pourrait avoir une pente pour la deuxième tranche et enfin le niveau minimum commun en dernière tranche :
À ces niveaux « de tranche » on ajoute donc un handicap personnalisé (fonction de notre niveau effectif de blocs constaté, par rapport à la médiane/tercile des autres calculateurs), et aussi un bonus aléatoire. Ce bonus ne devrait pas être trop fort en rapport à la difficulté commune, mais permettrait de favoriser aléatoirement des nœuds, ce qui évite un contrôle déterministe par un attaquant.
Bon, je ne dis pas que c’est la panacée, mais forts d’une fonction de tirage aléatoire vous pourriez avoir d’autres idées
1 Like
Peux-tu rappeler ce qu’est la “fenêtre courante” ?
L’idée d’un bonus aléatoire est une très très bonne idée. Il faudrait que je m’intéresse au fonctionnement des VRF. Tu as un document qui décris leur utilisation pour une blockchain ?
La fenêtre courante est un concept utilisé dans le protocole Duniter : c’est l’ensemble des N blocs précédents HEAD permettant de définir le nombre estimé de calculateurs en cours. N = taille de la fenêtre courante, et cette taille est donnée par le champ issuersFrame de chaque bloc. Cette taille évolue au fil des différents émetteurs que l’on peut constater dans cette fenêtre.
Grosso modo : la fenêtre courante = nombre de calculateurs s’exprimant sur le réseau * 5.
J’ai découvert ça récemment dans la publication d’Algorand, c’est au cœur de cet algorithme. Les fonctions VRFs sont un mécanisme découvert en 1999, mais devenu praticable qu’assez récemment.
Côté implémentations, ça ne court pas les rues : voir les implémentations connues par l’IETF. Mais j’ai déjà pu en réaliser une de mon côté en C++ (reposant largement sur la libraire libsignal), et en faire un addon NodeJS. Pour Rust je ne sais pas, mais j’ai vu passer aussi une implémentation en Go, alors il y a peut-être un espoir.
Alors, dans les hypothèse, c’est un membre non-informaticien, qui se ferait dérober sa clé. Les membres déjà “calculateurs”, on considère qu’ils ont intégré les minimums requis en terme de sécurité etc.
Du coup, ça me semble être une hypothèse raisonnable de considérer que l’attaquant ne pourrait pas voler massivement les clés des membres calculant.
De toute façon, si cette hypothèse n’est pas considérée comme raisonnable, on est mal barré
L’inconvénient que je vois ici avec ce système de certifications au sein des certifications, c’est que ça complexifie encore plus le protocole de Duniter. Ca rendrait la maintenance et la montée en compétence très laborieuse ! C’est déja assez complexe comme ça…
Donc si on trouve une solution technique et non humaine, telle que ton idée de tirage au sort, ça me paraitrait très bien.
2 Likes
En effet l’idée du tirage au sort me semble mieux qu’une certification supplémentaire, avec un temps d’attente initial.
Si tu as un code en C++, il y a moyen de le traduire en Rust 
Il doit aussi y avoir un équivalent à libsignal. Je vais regarder ton code et faire quelque recherches, je te tiens au courant
EDIT : Ow, les VRF c’est du 0-knownledge proof ? C’est bon ça 
1 Like
Je faisais l’hypothèse d’un membre non-informaticien et non calculateur à qui on dérobe la clé de membre.
Tu as l’air de mieux connaître que moi, j’ai seulement compris l’intérêt fonctionnel je vais me renseigner.
1 Like
J’ai trouvé ce document qui explique en détail comment ça fonctionne. Tu as déjà une implémentation, mais ça pourrait être utile pour comprendre ce que l’on peut faire avec ou pour d’autres personnes (comme moi) qui voudrait le réimplémenter.
2 Likes
Pour résumer l’état actuel de nos réflexions :
A court terme : Implémenter le système de publication de clé déléguée dédiée au calcul. Ce mécanisme limitera l’impact d’avoir 5% des clés de la toile calculantes, et réduira l’exposition des clés membres sur internet.
A moyen terme : Trouver une solution avancée pour se défendre contre une attaque du type “un attaquant vole N clés et profite d’un poids potentiel plus fort dans le calcul”.
2 Likes
Rien à redire pour le moment
Oui mais bon, c’est une implémentation non standard j’ai l’impression. En effet les clés utilisées ne sont pas compatibles avec libsodium, j’avais fait un ticket sur le dépôt de libsignal et je me suis aperçu tout seul qu’ils utilisaient un « clamping » qui modifiait la clé privée pour la rendre compatible.
Bref c’est utilisable, mais quelles garanties aies-je que ça fonctionne comme espéré, et sans faille dans leur code ?
Vu que dans ma crate de crypto j’ai accès aux fonctions sur courbe elliptique, je vais voir si c’est possible de l’implémenter directement.