Revocation mechanics

Protocols Ğ1v2 protocol
#1

Je viens de tester la révocation explicite, vu qu’aucun wallet ne permet encore de générer le document de révocation, je l’ai généré « à la main » avec un peu de code Rust.

Le document de révocation est extrêmement simple, c’est la concaténation de la clé publique et du genesis hash, cela permet déjà d’identifier de manière unique une identité dans tout l’univers, pas besoin de plus.

Une fois la signature générée, il suffit de conserver précieusement cette signature et c’est suffisant, la clé publique et le genesis hash pouvant être retrouvés aisément.

Ensuite, n’importe-qui en possession de la signature peut révoquer l’identité via le call suivant:

image
image1740×617 111 KB

Et ça fonctionne, mon 2ème compte membre Elois2 à bien été révoqué :smiley: :

image
image1712×379 67 KB

6 « J'aime »
Lancement de la blockchain ĞDev le 27 mai 2022
#2

Du moins, c’est suffisant pour fournir l’équivalent de ce que fournissait duniter v1, mais je pense qu’il nous faut plus:

La possibilité de rendre invalide une signature de révocation. En effet, c’est une donnée qu’on est censé conserver toute sa vie, donc qui peut se retrouver exposée/divulguée par erreur à certains moments de la vie, ça peut être bien de pouvoir « modifier » cette signature de révocation de temps à autre.

Il suffirait de rajouter un « revocation nonce » dans la payload à signer, ainsi que dans le storage onchain (par identité), et créer un call pour l’incrémenter.

#3

Oui bonne idée, il faut quand même que le « temps à autre » soit suffisamment grand pour être assuré qu’en cas de vol de la clé privée l’on puisse quand même révoquer le compte (changer le nonce et balancer la révocation dans la foulée), il ne faudrait pas que le voleur puisse empêcher la révocation en « contrant » rapidement le changement de nonce.

2 « J'aime »
#4

Dans cesium V1, on peut révoquer son compte en utilisant son identifiant et mot de passe.
Je suppose qu’il en sera de même avec les wallets de Duniter V2.

#5

Tu sous-entends une règle côté protocole qui imposerait un délai minimal entre deux incréments du « revocation nonce », je pense qu’il n’y en a pas besoin, on devrait d’ailleurs supprimer toutes les autres règles du même type (délai minimum entre deux renouvellements d’adhésion ou de certifs), car ces règles servent uniquement d’anti-spam, mais ne servent à rien, car un spammeur va juste spammer un call qui n’est pas limité par ces règles la (comme balances.transfer).

Je me rends compte que j’ai reproduit bêtement ces deux règles (RenewablePeriod et CertRenewablePeriod) alors qu’elles ne servent à rien, j’ouvre urne issue pour les supprimer: Remove useless rules RenewablePeriod and CertRenewablePeriod (#56) · Issues · nodes / rust / Duniter v2S · GitLab

Le spam de call on doit s’en protéger par des frais adaptés (ce que est possible grâce au système de weights), et des quotas gratuit pour les membres certifiées (en nombre de poids par période de temps), ça permet en plus d’avoir une seule logique à un seul endroit pour tous les call, et pas plein de règles complexes en plus pour certains calls.

2 « J'aime »
#6

Évidemment

#7

Oui c’est ça. Je pense qu’il y en a besoin dans le cas précis de la révocation pour assurer à tout membre (passé, présent ou en devenir) qu’un vol de sa clé privée ne l’empêchera pas de révoquer son identité.

Car si l’attaquant vole la clé privée et peut spammer lui aussi l’évolution du revocation nonce, alors l’utilisateur honnête pourrait ne pas être en mesure de publier sa révocation dans le cas où l’attaquant répondrait automatiquement à l’incrémentation du revocation nonce par une autre incrémentation. C’est facile avec un bot.

Si la seule contrainte sont les frais, alors il suffit de monnaie pour nuire à quelqu’un une fois la clé privée dérobée. Ce peut être un investissement rentable si le voleur réalise un chantage économique pour arrêter d’incrémenter le revocation nonce. C’est assez proche du squatting DNS.

C’est peut-être un cas à la marge, mais quand même, on parle d’usurpation d’identité, ça me semble important.

3 « J'aime »
#8

Oui pour ces paramètres, en effet.

2 « J'aime »
#9

J’avoue que j’ai un peu de mal à comprendre ce problème.
En cas de vol d’identité, l’utilisateur à toujours accès à son compte avec son mot de passe, cela suffit pour révoquer son compte sans avoir besoin de générer un nouveau fichier de révocation.

#10

Pas avec le système de « revocation nonce » proposé par Eloïs ci-dessus.

#11

Alors cela ne correspond pas avec ce que j’avais compris ici :

#12

C’est parce que sa réponse suppose que l’attaque je décris, utilisant le revocation nonce, n’est pas possible ou négligeable. Dans ce cas en effet, identifiant + mdp suffisent.

2 « J'aime »
#13

Il suffit de permettre la révocation du compte de manière « directe », sans revocation nonce, comme actuellement en fait.
Le « revocation nonce » servira uniquement pour générer une signature de révocation « périssable » si besoin, mais il restera possible de générer une signature de révocation éternelle comme actuellement (à ne faire que pour révoquer le compte directement).

Oui en effet, elle n’est pas possible car il n’est pas obligatoire de passer par le revocation nonce.

1 « J'aime »
#14

Ah bah oui avec ce détail, ça change tout :slight_smile: OK pour moi, ça tient bien la route, c’est même une bonne idée.

2 « J'aime »
#15

Je ne saisis pas bien toute la discussion sur le document de révocation. Si on suppose que l’utilisateur peut perdre son mnemonic, pourquoi ne pourrait-il pas perdre également son fichier de révocation? En quoi serait-il plus simple pour un utilisateur lambda de conserver une signature générée une fois à la création de son compte et jamais utilisée que son mnemonic ?

Je serais plus pour rester sur cette solution extrêmement simple quitte à implémenter du sharding pour permettre à un utilisateur de récupérer sa clé grâce à des proches. @poka avait de bons arguments pour cette option.

#16

Il peut le perdre aussi, mais le fichier de révocation peut être possédé par un proche (famille ou meilleur ami) .

Et moi non, ne pas pouvoir « invalider » mon document de révocation me pose vraiment problème.

C’est une autre feature qui apporte d’autres intérêts, on à besoin des deux, pour moi c’est un autre sujet :slight_smile:

#17

J’ai bougé cette partie de la discussion pour ne pas la perdre parce qu’elle me semble intéressante.

2 « J'aime »
#18

Il y a 2 events dans ce bloc 91662:

  • membership.MembershipRevoked
  • identity.IdtyRemoved

Quel conséquence ont ces 2 events à part ne plus obtenir de DU ?
Est-ce que toutes les certifications sont supprimées ?
Un compte révoqué est-il définitivement fermé et irrécupérable ?
J’imagine que le compte est toujours là. Est-ce que l’on peut refaire un membership.RequestMembership ou carrément membership.forceRequestMembership pour récupérer le compte ? (Et quel différence avec membership.claimMembership ?)

#19
  • La suppression de l’identité, donc la perte de tout les droits associés, donc également droit de certifier, droit de créer une identité, et tout éventuel droit de vote dans une future gouvernance on-chain.
  • La suppression du compte s’il n’a plus de monnaie, donc la suppression du nonce, donc attaque par rejeu possible si le compte est réalimenté plus tard.

Non, comme dans la Ğ1 actuellement, les certifications restent actives jusqu’à leur expiration, pour évitier un effondrement de la toile de confiance en cascade.

Attention toutefois, si l’identité n’était pas encore validée, mais juste créée ou confirmée, les certifications reçues sont supprimées.

Il ne pourra plus jamais y avoir d’identité attachée à ce compte. Il reste utilisable en simple portefeuille, à condition qu’il ne soit pas vide (qu’il y ai des Ğ1 dessus).

Non on ne peut pas.

C’est un call interne, il ne peut pas être appelé par l’utilisateur.

1 « J'aime »
#20

Ça émet des calls quand les certifs sont supprimées ? Dans la palet cert je vois seulement addCert.

Aussi, quel est l’implication de system.KilledAccount ?