Je déterre ce sujet après des discussions avec @poka il y a quelques mois ou avec @tuxmain il y a quelques jours.
Peut-être que je le ferais au sein de Ǧardien comme je le proposais initialement, histoire de proposer une interface pour ça, ou peut-être que d’autre irons plus vite que moi et l’intègreront dans leurs clients.
L’idée principale, c’est d’utiliser des shards / fragments ou du sharding (fragmentation) pour sauvegarder ses secrets chez des tiers sans que ceux-ci ne puissent utiliser ces secrets à votre insu.
Au gré des discussions, mon idéal d’UX a évolué. Aujourd’hui je n’imagine pas grand monde créer son compte en générant directement ses fragments,
- d’une part, parce que ça rajout une complexité à un moment où l’utilisateur est encore peu engagé et donc susceptible d’être facilement effrayé par tout ce qui rajoute des étapes entre l’envie d’avoir un compte et le moment de pouvoir s’en servir.
- d’autre part, parceque, en tant que nouvel⋅le arrivant⋅e, sans connaitre personne, difficile de savoir à qui confier ses fragments.
Les moments qui me semblent pertinents pour générer et partager des fragments de sauvegarde de ses secrets d’accès au compte, c’est, selon ce qui arrive en premier :
- quand le compte dépasse 100DU en tant que portefeuille
- quand le compte reçoit ça 5ᵉ certification (et devient membre)
La manière de faire, serait de proposer une interface avec réglages par défaut, mais modifiable simplement (j’en parle là : N/2+1 as default, but customizable like in SLIP-0039 spec · Issue #98 · paritytech/banana_split · GitHub )
Et d’avoir une répartition suggérée des fragments/shards également par défaut, pour pouvoir faire un simple suivant/valider pour valider et mettre en place le sharding comme procédé de sauvegarde de ses secrets.
La répartition par défaut qui me parle est la suivante (avec minimum 4 fragments sur 7 pour reconstituer le secret) :
- un fragment envoyé chiffré à son premier certificateur (donc déchiffrable uniquement par lui)
- un fragment envoyé chiffré à l’un des 4 autres premiers certificateurs aléatoirement
- un fragment envoyé chiffré à un membre aléatoire de la toile forgeron (V2s)
- un fragment envoyé chiffré à un membre aléatoire du commité technique (V2s)
- un fragment envoyé chiffré à un membre aléatoire de l’assemblée citoyenne (V2s)
- un fragment en clair à s’envoyer par email, copier sur PC et smartphone ou à imprimer et garder chez soi
- un fragment en clair à confier à un proche (amis, famille, collègue, voisin…) par le moyen de son choix
Pour un compte portefeuille, on remplace les 2 premiers par :
- un fragment envoyé chiffré à l’un des 3 premiers comptes vous ayant versé des G1
- un fragment envoyé chiffré à l’un des 3 premiers comptes à qui vous avez versé des G1
Chaque fragment en clair contient :
- Fragment de récupération pour le compte G1 dont la clef publique est : xxxx…xxxx:xxx
- contenu cryptographique du fragment sous forme de mnémonic
- contenu cryptographique du fragment sous forme de QRcode
- instructions de récupération (récupérer suffisamment de fragments, utiliser tel logiciel pour les assembler et reconstituer votre clef privée/seed en utilisant la procédure “charger/reconstituer” un compte à partir de fragments)
Chaque fragment chiffré contient une fois déchiffré :
- Fragment de récupération pour le compte G1 dont la clef publique est : xxxx…xxxx:xxx
- contenu cryptographique du fragment sous forme de mnémonic
- qui détient les autres fragments (et donc leur nombre)
- combien de fragments sont nécessaires pour reconstituer le secret
(ces 2 dernières lignes étant désactivables pour rendre plus dure le travail d’un attaquant, mais aussi celui du récupérateur légitime)
L’interface devrait aussi demander pour chaque fragment en clair avant génération des fragments chiffrés à qui l’utilisateur compte confier ce fragment ou où il compte le stocker, afin qu’il puisse les retrouver plus facilement au besoin.
Dans tous les cas, nombre de fragments nécessaire et total sont réglables par l’utilisateur, ainsi que modifier les destinataires pour en choisir des personnalisés. Ainsi, si la proposition par défaut ne lui convient pas, il peut changer.
Enfin, après discussion avec @tuxmain il serait possible, et potentiellement préférable, à discuter, de stocker fragmenté non pas la seed, mais une clef délégué ayant besoin d’émettre un document en blockchain une semaine (ou autre délai à définir) avant de pouvoir transférer quoi que ce soit depuis le compte récupéré. De cette manière, si les détenteurs des fragments tentaient de se rassembler pour en faire usage alors que le détenteur légitime a toujours accès à son compte, celui-ci disposerait d’une semaine (ou autre délai défini) pour révoquer cette clef de récupération déléguée (de sharding) avant que sa tentative d’usage frauduleux ne porte à conséquence.
L’idée me semble bonne sur le principe, mais elle nécessite, je crois, des ajouts au protocole, là où sans la partie clef déléguée avec délais, seuls les logiciels clients ont à prendre en charge ces mécanismes.
PS : les fragments chiffrés peuvent aussi bien être envoyé via messagerie cesium+ que par email classique avec en objet “fragment de récupération G1” éventuellement accompagné de la clef publique en clair pour retrouver plus facilement.