Proposition d’identités forgerons − solution user-friendly au problème de sécurité des instances cesium web

En fait la question n’est pas là, c’est une question de simplicité des changements de protocole : le protocole est la partie la plus critique de Duniter, chaque augmentation de complexité est un coût énorme car outre le temps de dev pur il y a tout les temps de tests et stabilisation → et vue que l’on est très peu de dev sur le coeur avec très peu de temps dispo pour développer je propose l’implémentation la plus simple.

Dans l’absolu, gérer différemment les anciennes identités selon qu’elles avaient déjà écrit des blocs ou pas est possible, mais ça complique beaucoup le code de synchronisation notamment, qui doit vérifier la validité de tout l’historique.
Et en terme de performance, il faut vérifier tout l’historique de la blockchain pour déterminer une ancienne identité a le droit au calcul, c’est lourd. Et même pour le dev de cesium ça compliquerai les choses.

La on vas au plus simple et performant : après t2 toutes les anciennes identités ne peuvent plus calculer, point. Par contre ces anciennes identités pourront toujours ce connecter sur cesium web.

Tu ne sera pas obligé de révoquer ton compte membre. Tu peut le garder, il ne pourra juste plus calculer (dans l’hypothèse ou cette proposition était appliquée).

1 Like

Cette proposition me paraît très intéressante.

Remarques :

  • Appellation “Membre calculant” (“Computing member”) - ou “Membre participant”, ou “Membre contributeur” : ok pour moi.
  • Appellation "Membre utilisateur" (“User member”) ou "Membre standard" préférable à “Membre restreint”, car personne n’a envie d’être “restreint” en quoi que ce soit, même s’il ne sait pas ce que cela veut dire.
  • Les responsabilités des “membres calculant” sont clairement définies et leurs contraintes de sécurité ne polluent pas le confort d’utilisation des “membres utilisateurs”. Ok pour moi.

[EDIT]
Le paragraphe suivant a été écrit au saut du lit et son auteur n’a pas bien compris la proposition.
Voir plus loin
Ne pas lire à partir d’ici…:flushed:

Problème potentiel de sigPowQty < sigQty

Réfléchir au fait que cela crée deux toiles de confiance dont le nombre réduit des calculants implique d’avoir sigPowQty avec un montant plus faible pour éviter un effondrement. Mais si sigPowQty < sigQty alors on peut crier à l’injustice car un “membre calculant” peut acquérir le droit de créer de la monnaie plus facilement qu’un “membre utilisateur”.

Du coup cela peut inciter à cliquer sur “membre calculant” juste pour créer son DU avec moins de certifications.

Si on part du principe que pour des raisons d’égalité en nombre de certifications pour créer son DU sigPowQty = sigQty. Alors on peut se passer de sigPowQty.

Le protocole doit alors gérer les certifications ainsi :

  • Membre calculant -> Membre calculant : AUTORISE.
  • Membre utilisateur -> Membre utilisateur : AUTORISE.
  • Membre utilisateur -> Membre calculant : REFUSE.
  • Membre calculant -> Membre utilisateur : AUTORISE ?.

Lire à partir de là… :wink:

Réflexion sur sigPowQty < sigQty

Réfléchir au fait que cela crée deux toiles de confiance dont le nombre réduit des calculants implique d’avoir sigPowQty avec un montant plus faible pour éviter un effondrement.

Le protocole doit alors gérer les certifications ainsi :

  • Membre calculant -> Membre calculant : AUTORISE.
  • Membre utilisateur -> Membre utilisateur : AUTORISE.
  • Membre utilisateur -> Membre calculant : AUTORISE.
  • Membre calculant -> Membre utilisateur : AUTORISE.

Si je me créé un nouveau compte “Membre calculant”
Je deviens membre créateur de DU (“utilisateur”) avec des certifications de Membres utilisateurs.
Je deviens membre calculant avec des certifications d’autres membres calculant.
Cela signifie que je dois d’abord devenir “membre utilisateur”, avant de pouvoir certifier en tant que calculant. Je peux le devenir avec des certifications d’autres membres utilisateurs.
Bon je cherche une faille potentielle, mais là tout de suite à chaud je ne vois pas, je m’embrouille… Faudrait simuler…

En fait non, on a toujours une seule toile de confiance et un seul type de certification, une seule règle de distance appliquée a tout les noeuds, etc.

On rajoute juste une 2ème propriété aux nœuds du graphe, il avaient déjà la propriété “référent” ou non, ils ont désormais la propriété “calculant” ou “non-calculant”( on peut changer le nom par “membre standard”, “membre classqiue”, “membre utilisateur”, etc).

Arf, tu n’a pas compris ma proposition :sweat_smile:

Non ce ne sera pas possible car toutes les règles existantes de la toile s’appliqueront toujours aux membres calculants, ainsi une identité calculante devra quand même recevoir sigQty certifications.
Le paramètre sigPowQty ne remplace pas sigQty, il se rajoute, c’est une règle de plus, que seules les identités calculantes doivent satisfaire.

Non non, il n’y a pas de DU “utilisateur”, il y a un seul et même DU pour tout les membres, qu’ils soient calculants ou non.
De plus il n’y a pas de transition : Si tu créer une identité calculante elle passera directement en membre calculant ou ne deviendra jamais membre, point. Il n’y a pas de statut intermédiaire.
Tu infère un paquet de règles qui n’existent pas, cantonne toi aux règles que j’ai explicitement énoncé, il n’y en a pas d’autres :slight_smile:

1 Like

Si ces informaticiens veulent quand même se connecter depuis LEUR instance cesium web, rien ne les empêche de modifier césium web pour y ajouter une liste blanche de comptes calculant autorisés, qui ne devrait en général pas dépasser un compte : le leur.

Une chose me dérange avec la révocation comme méthode de transition : les uid ne sont pas transférable à une nouvelle identité (ni libéré par la révocation).

Pour la conversion auto, je présume que le problème est l’imutabilité des documents d’identité une fois inscrit en blockchain ?
Quid d’autoriser :
Du bloc X au bloc Y (entre T1 et T2) les identités existante à publier un nouveau document d’identité sous le même uid et même clef publique/privée mais au nouveau format, pour pouvoir préciser “membre calculant” sans y perdre son uid ni avoir à se faire re-certifier. Passé T2, ce n’est plus possible.

ça me semble faciliter la transition.

PS : Un Membre calculant, qui finalement de fait pas tourner de noeud, ça me fait bizarre terminologiquement, il est considéré comme entrain de calculer (calculant) qu’il le face ou non, alors que cela signifie en réalité en capacité de calculer. Membre calculateur me semble anxiogène, propice à nourrir la paranoïa des complotistes, Membre forgeron me semble pas mal : Un forgeron à la capacité de forger, mais n’est pas forcément entrain de s’affairer à sa forge en permanence.

ça me perturbe beaucoup moins, mais Membre utilisateur j’ai l’impression de lire Membre qui est membre Je préfère Membre standard ou Membre classique ou simplement Membre.

2 Likes

Ce serait possible de créer une exception pour l’uid, mais ça complique le code de vérification pour qqch qui n’est franchement pas indispensable, les uid étant sensible a la casse tu peut reprendre le même en changeant juste la casse :wink:

En revanche pour les clef publique/privée il ne sera pas possible de reprendre les mêmes pour 2 raisons :

  1. La sécurité : certains membres calculants actuels se sont déà connecté sur un cesium web hébergé et leur compte, peut être compromis un jour dans l’avenir.

  2. Le code : tout est basé sur les clés publiques, devoir supporter la réutilisation d’une même clé publique pourrait causer de nombreuses régressions et obliger a refondre une bonne part du code du cœur, avec tout ce que ça implique derrière en temps de temps supplémentaire de stabilisation.

  3. Ce rituel de reboot me semble souhaitable et bénéfique, c’est une opportunité de passer a de meilleurs pratiques pour tout les membres calculants actuels dont les pratiques ne serait pas assez secure (et je suis sur qu’il y en a).
    Alors certes c’est des procédures pour rien pour les membres calculants dont les pratiques sont déjà très safe, mais l’effort que ça demande est bien inférieur a l’effort que demanderai en terme de code le fait d’éviter ça. De plus on y perdrais le bénéfice du reboot qui permet de repartir sur des bases saines et terme de sécurité.

Si l’on appliquais cette proposition, il y aurait 2 licences. La licence actuelle pour les comptes membres classiques, et une licence supplémentaire pour les comptes membres forgeron. Cette dernière expliciterai toutes les précautions de sécurités qui incombent a un membre forgeron. Ainsi les membres calculant actuels dont les pratiques ne sont pas assez safe et qui n’en avait peut être même pas conscience auront occasion de repartir sur des base saines, avec de nouveaux identifiants plus solides (ce qu’on perd si l’on oblige pas a changer de trousseau de clés).


Tes remarques sur les nom sont tout a fait pertinentes, mais des noms ça ce change facilement, l’important dans un premier temps c’est de se prononcer sur les choix techniques :slight_smile:

1 Like

du coup, j’aurais tendance à ne pas faire d’exception mais à, au choix :

  • libérer les uid des comptes révoqué plutôt que les garder réservé pour l’éternité
  • supprimer la notion d’uid si tout est rattaché à la clef publique (et rajouter plus tard une surcouche de nameService qui n’a pas besoin d’être dans le protocol monétaire)
  • coder le changement de mot de passe pour un compte membre (donc rattacher à l’uid les certif et émettre un document signé avec les anciens code indiquant la nouvelle clef publique à associer à l’uid/compte membre, ce document pourrait inclure le nouveau champ).

PS : si on veut une sécurité au top, voici les mesure que l’on pourrait demander aux membres forgerons :

  • générer ses nouveaux secret sur un hardware-wallet dont il est possible de faire des duplicata à la création mais plus ulterieurement. (et laisser le hardware wallet effectuer toutes les opérations de signature pour pouvoir l’implémenter de manière à ce que la clef privé ne puisse jamais en sortir) (mais cela introduit un frein UNL à l’entrée tant qu’il n’est pas possible d’achetter des hardware-wallet en Ǧ1
  • faire contre-signer une certification de membre forgeron destiné à un membre forgeron par un des membre forgeron ayant certifié le certifieur (ou au moins par un des certifieurs du forgeron signeur), l’idée étant de renforcer le contrôle/la vigilance sur le fait qu’il n’y ai pas de certification à la légère de membre forgeron.

Je serai pour en profiter pour faire du ménage dans la licence actuelle pour en faire une licence qui explicite les engagements de qui l’accepte et non un cours (même court) sur ce qu’est une monnaie libre.

Et je serai aussi pour qu’au lieu d’un accepter, il y ai pour chaque engagement une case à cocher pour s’assurer que tout ai été lu et accepté.

Et idem pour la licence forgeron mais avec plus d’engagements et donc de case à cocher.

C’est entre autre l’objet de cette conf :
https://rml12.duniter.io/session_licence_TdC_grandir.html

3 Likes

Sauf pour le changement d’uid, je suis pour les changements technique que tu propose. ça me semble aussi être le plus urgent pour augmenter la sécurité du système autour de la Ǧ1. (et ça me semble être un pas dans une direction similaire à la proposition de cgeek vu que concrètement, cela distingue 2 type de compte (forgeron ou non) et 2 types de certifications (entre forgerons ou non), mais avec une approche plus sécuritaire (puisqu’un compte ne peux pas devenir forgeron en cours de route, soit il est créé pour l’être soit non). ça n’adresse en revanche pas la problématique d’extension de la communauté plus aisée, mais les changement coté code à faire sont moindre.

J’ai tout bien compris ?

Cela empêcherait de pouvoir faire tourner un Duniter membre sur une machine à laquelle on n’a pas accès physiquement… Alors que j’espère pouvoir le faire un jour avec un conteneur qui garde secret les credentials.

Je plussoie ! Il y a les membres forgerons, les membres villageois (et les membres loup-garous qui sont de fausses identités…) :wink:

Sinon la proposition @elois me semble bonne.

8 Likes

Franchement j’adorerais qu’on utilise ces termes ! Ludiques et clairs !

La proposition d’@elois me semble très intéressante en tout cas. Le seul truc embêtant c’est la perte de quelques DU lorsqu’on veut passer de villageois à forgeron… Mais ça impact peu de personnes, donc ça me semble acceptable (et si c’est bien fait, on peut même éviter ça)

Autre point d’attention : en général, les membres forgerons sont des noeuds importants de la toile actuelle. Il faut faire gaffe, car lorsqu’ils révoqueront leurs comptes, on a beaucoup de liens qui vont disparaitre avec eux (et qui mettront plusieurs mois pour revenir).

4 Likes

Je sais que ce n’est peut-être pas très propre, mais ce serait pour la bonne cause :
Ne pourrait-on pas écrire à la main la liste des membres “forgerons de départ” ?
C’est encore possible vu la taille de la toile, en prenant bien la peine de communiquer en amont auprès de tous ceux qui ont déjà calculé au moins 1 bloc.
Processus transparent, on accepte tous ceux qui demandent (et on voit, encore une fois “à la main”, s’il y a 200 nouveaux forgerons dont personne n’a entendu parler sur le forum qui s’inscrivent). Si la démarche est clairement expliquée ici ça ne devrait pas être trop critiquable si ?

Pour le problème des comptes potentiellement compromis, il faut se demander quel % de comptes ça représente, car le nombre de comptes :

  1. Qui demandent à pouvoir calculer,
  2. Qui se sont déjà connectés à CesiumWeb,
  3. Sur une instance qui soit au choix :
    a) déjà compromise
    b) tenue par quelqu’un qui refusera une MaJ qui “nettoiera” les connexions de la liste.

me semble faible (mais je me trompe peut-être).

Tout ceci me paraît bien compliqué pour un problème de piratage de DNS qui peut être résolu en ne passant pas par un DNS !
Si chaque hébergeur de CesiumWeb communique une adresse IP fixe et non plus un nom de domaine usurpable, le problème est résolu !
Ceci s’accompagne d’une petite explication pour l’utilisateur final des risques liés au DNS et qu’il est 100% en sécurité seulement en passant par un liens commençant par une IP.
Il pourrait être maintenu par la dev team une whiteliste d’IP indiquant qui est l’hébergeur, clé de membre éventuellement (l’ajout/vérification de ces informations est faite en dehors du système par d’autres moyens de confiance), et invite les utilisateurs à “cliquez droit sur le lien et ajouter aux favoris”.

Changements dans la user story de création d’un compte membre

Aucun

Changements dans le protocole DUBP

Aucun

[edit] Changements pour les hébergeurs de CesiumWeb

  • Corriger le certificat HTTPS pour qu’il soit valide avec l’IP ( ?heu je maitrise pas, est-ce faisable? ou bien le certificat ne vautque pour des noms de domaines? )

Transition en deux étapes pour la Ğ1

  1. Créer une page de liste blanche avec message éducatif avec des liens et/ou QRCode
    exemple: g1.duniter.fr << glissez ce lien dans vos favoris
  2. Effacer toute traces de lien avec DNS dans les docs te sites parlant d’instances de CesiumWeb

Changements pour l’utilisateur

  • Mettre à jour son-ses favori-s

(post écrit par un utilisateur averti, pas dev ni sysadmin)

Ca n’est pas qu’un problème de DNS. En règle générale, sur les Blockchain, avoir accès à une clef privée permet d’avoir accès à la monnaie sur le compte. En plus, sur la June, une clef privée membre permet de calculer des blocs. Le problème est la centralisation d’un certain nombre de clefs privées potentiellement calculantes sur des serveurs Césium (qui pour le moment n’enregistrent pas ces clefs, à ma connaissance).

Ces serveurs sont des points d’attaque faibles de la monnaie pour mener des attaques 67%.

On peut avoir comme attaques :

  • par DNS menteur
  • par prise de contrôle d’un serveur (faille ou erreur humaine)
  • par corruption d’un admin
  • et sans doute d’autres.

Donc la question n’est pas simplement du DNS, c’est “comment éviter que des identités calculantes ne soient exposées sur des serveurs”. Par précaution.

Si tu lis TOUS les tutos concernant la gestion de portefeuilles d’autres cryptomonnaies, ils insistent bien : ne communiquez pas vos clefs privées sur internet ni à personne alors même que ces clefs sont bien moins critiques car sans rapport avec la sécurité du réseau de calcul. Et sur la June, on a une situation inverse : des clefs privées critiques pour le calcul, potentiellement exposées sur des serveurs.

5 Likes

La solution d’Eloïs renforce la sécurité bien au dela d’un piratage DNS d’instance cesium-web.

Plus le nombre de membre forgeron est proche du nombre de membre dans la fenêtre de calcul courante, plus il sera difficile pour un attaquant d’avoir suffisement de clef membre forgeron pour effectuer une attaque significative.
Le fait que les clef membre forgeron ne puisse pas se connecter sur un cesium-web est selon moi un bonus accessoire d’un point de vu sécurité par rapport à l’ampleur du problème actuel : De nombreux membres prosélyte son prêt à certifier qui que ce soit qu’ils ont vu 1 ou 2 fois et semble intéressé, donc il est facile pour quelqu’un de nomade de se faire certifier plusieurs compte, comptes pouvant écrire en blockchain, donc il est relativement simple d’effectuer une attaque pouvant prendre la main sur la blockchain aujourd’hui.

Restreindre l’écriture blockchain aux seuls membres forgerons, créé pour cela, et avoir une licence spécifique, renforcée sur les principes de sécurité pour ces membres me semble certes ajouter une contrainte non négligeable pour ces derniers, mais améliorer considérablement la sécurité de l’ensemble, cesium-web ou non.

5 Likes

Heu… pardon ? Qui a dit que c’était pour “résoudre un problème de DNS” ??

Je ne l’ai effectivement pas rappelé dans mon premier post, mais le fait que tout les membres est le droit au calcul est un problème de sécurité a de nombreux égards et tout les dev sont déjà d’accord sur le fait qu’il est nécessaire de restreindre ce droit d’accès au calcul. On n’avais simplement pas de proposition claire et arrêtée sur comment procéder exactement, ou alors des solutions bien trop complexes, la proposition que je fais ici est au contraire la plus simple à implémenter parmi toutes les propositions qui ont été faites jusque la :wink:

L’app Cesium n’a pas de logique serveur, tout se passe dans le navigateur de l’hote, en tout cas sur une version non modifiée/piratée…

Ha ça! Effectivement, c’est une réflexion que je me suis déjà faite, et j’ai même penser à le réaliser, et puis manque de temps pour jouer à ce petit jeu…
C’est un réel problème je suis d’accord… Et je dirais même que c’est du ressort de la conception de la TdC, le fait de ne pas avoir de “finesse” dans l’acte de certifier, ni d’outils supplémentaires d’aide à la confiance qu’une licence qu’on suppose respectée…
Alors effectivement il y’a peut être des choses à faire niveau protocol !

Bah c’est que le méchant CesiumWeb reviens souvent sur le tapis comme un risque MAJEUR, alors que je vois des solutions pour ce problème-ci…
Maiiiiis j’entends je lis vos réponses et je comprends le problème plus profond pas de soucis !!

3 Likes

La solution de @cgeek n’est pas réalisable pour éviter que tous le monde puissent calculer des blocs ? :thinking:

Si @cgeek a envie de le faire dans Duniter je suivrais, mais perso je ne serais pas moteur pour ces 3 propositions, car nous avons bien d’autres priorités concernant l’évolution du protocole. Je préfère donc qu’on se limitent aux changements absolument nécessaires dans un premier temps, et j’estime que tes propositions permettent concernant l’uid ne sont pas une nécessité :slight_smile:

Je pense au contraire que la Licence Ğ1 doit expliciter l’ensemble des droits et devoir nécessaires et suffisants qui incombent a tout membre de la Ğ1, en ce sens la présence de la formule de calcul du DU me semble indispensable, c’est la formule officielle a laquelle se référer sans avoir besoin d’aller chercher dans la documentation du site web ou sur le forum :wink:

Oui c’est une bonne idée :slight_smile:

En fait il y aurait toujours qu’un seul et unique type de certification dans le protocole. Donc c’est énormément plus simple a implémenter et énormément plus simples pour les utilisateurs finaux, qui n’auront rien de plus a savoir s’il ne calculaient pas de blocs.

Les membres forgerons n’auront qu’un seul type de certif, c’est juste qu’il devront faire preuve de plus de vigilance lorsqu’il certifieront d’autres membres forgerons. Les clients pourrait par exemple, ré-afficher la licence forgeron avec une checklist de points a vérifier chaque fois qu’un membre forgeron est sur le point de certifier une identité forgeron.

@vincentux relis bien ce que j’ai écrit :

Je me suis déjà exprimé sur le fait que la proposition de 3 types de liens qu’avait soumis cgeek était beaucoup trop complexe et allait rendre illisible pour l’utilisateur final un concept déjà fort complexe a comprendre.
Cela complexifierai également beaucoup trop le protocole a mon goût, il me semble qu’un bon protocole se doit d’être le plus simple possible pour répondre a un besoin donné, car plus il est simple plus il est maintenable, réimplémentable et optimisable.
Donc si l’on peut répondre a un même besoin avec une solution technique plus simple, j’estime qu’il nous faut opter pour la solution la plus simple, conformément au principe du Rasoir d’Ockham.

ok :blush: