Division de fichier de révocation

J’ai annoncé que je voulais faire un logiciel pour générer et diviser (avec le un fichier de révocation, afin de confier les morceaux à différentes personnes de confiance, pour que celles-ci puissent les réunir et révoquer le compte en cas de problème.

Ceci est motivé par de multiples occurrences d’oublis de mots de passe par des nouveaux membres.

Les personnes ayant besoin d’un tel programme sont souvent des non-geeks, ainsi il faut qu’ils puissent les utiliser sur leur propre machine, potentiellement un téléphone. Déjà je pense que Python n’est pas adapté : installer les dépendances est compliqué et est source d’imprévus. Faire fonctionner Python sur Windows peut être galère, et sur téléphone c’est parfois impossible.

Un exécutable (donc en Rust) multi-plateformes est très bien, sauf qu’il ne sera pas utilisable sur téléphone. Si on retient cette solution, il faudra se demander si la console est envisageable ou si il faut faire une GUI.

Enfin, une page web à télécharger en un fichier, ça marche partout, mais il faut tout faire en JS, pfffff.

Ou alors en Rust, avec une version exécutable et une version web (à télécharger), si j’arrive à faire marcher WASM dans un .html ouvert par le navigateur.

Qu’en pensez-vous ?

3 J'aimes

Je pense plusieurs choses :

  • Ce procédé ne doit pas être réservé au fichier de révocation, on pourrait aussi l’appliquer aux identifiants secrets et à la clef privée. Bref à n’importe quelle info qu’il ne faut pas perdre.
  • La clef du succès du logiciel est à trouver dans le fait de ne rien avoir à donner physiquement. Il faut absolument faire un système client serveur qui transmet d’un appareil à l’autre les fichiers en wifi/lan/bluetooth/3/4/5G or whatever.
  • Il faut que ce soit archi simple, ludique et que cela fonctionne partout. On ne pourra pas faire l’économie de plusieurs langages je pense.
  • Le mieux est de bien penser un protocole et de l’implémenter avec le langage le plus adéquat par appareil.

Bref, je suis d’accord que c’est un outil indispensable pour aider les utilisateurs à se sécuriser et sur lequel il faut absolument travailler. Je veux bien aider à débroussailler tout ça.

Pour l’inspiration uniquement :

https://www.2daygeek.com/wormhole-securely-share-files-from-linux-command-line/

Autant il y a 3 ans c’était la galère autant maintenant l’éco-système rust+wasm a bien maturé et tu n’as plus besoin de te soucier du wasm, tu peux facilement faire une SPA en pure Rust avec le framework yew :

Un starter template pour dev avec maj en temps réel via webpack :

Et le book très complet : https://yew.rs/docs/en/intro/

Pourquoi ? Le processus pourrait se dérouler pendant un apéro, le fragment peut être passé par QR code, clé USB… On peut ajouter une option pour le chiffrer afin de l’envoyer par mail.

Les inconvénients du client-serveur sont que tout le monde doit allumer sa machine en même temps que le serveur, que ce n’est pas toujours possible si ce dernier est en 4G, et qu’il faut un système pour obtenir les adresses des serveurs (serveur central ou DHT+QR code).

Pour le bluetooth, il faudra faire une appli, je ne sais pas faire et ça posera des complications pour la portabilité.

Du coup il faudrait intégrer plusieurs modes de communication : on aurait le choix entre QR code, enregistrer le fichier, envoyer par mail (via un SMTP centralisé du coup), client-serveur, IPFS, plateforme d’hébergement centralisée…

Le problème est que les possesseurs des fragments ne devraient pas connaître ces infos, donc c’est le possesseur du compte qui doit rassembler les fragments, ce qui nécessite de faciliter cette procédure. Le fichier de révocation peut être rassemblé par n’importe quel geek de l’entourage sans risque, même si le propriétaire du compte est mort. On pourrait en parler sur l’autre forum.

@elois merci pour les liens !

Ce que je veux dire c’est que cette idée ne dépassera pas le stade d’outil pour geek et va créer une fracture technologique si elle n’est pas plug’n play et ludique.

Bien sûr cela n’enlève pas la possibilité de faire la distribution/reconstitution par les moyens classiques dont tu parles, mais je pense que l’échange physique de fichier par clef usb ne sera pas pratique pour la majorité des gens.

Je ne vois pas en quoi le contenu de ce qui est distribué est important. Soit la procédure de reconstitution est garantie d’être réalisée uniquement par l’émetteur du fichier, soit la procédure est non sécurisée et il faut la revoir.

Bref, je le répète mais il faut aller au bout de cette idée que je trouve importante, et viser haut sous peine de ne convaincre que les geeks. Ce n’est pas un « petit » projet. Il va demander beaucoup de travail et de réflexion.

Ça envisage de laisser télécharger le ficher de révocation sur téléphone ici ?

Non, le problème du fichier de révocation qui fait semblant de se télécharger sur mobile est un bug de Cesium. A voir avec son auteur ou ses contributeurs. Ce sujet parle de tout autre chose. :sweat_smile:

1 J'aime

Moi aussi. Je ne parlais pas du bug.

Pardon , je ne veux pas digresser. Je m’explicite.

Si le fichier de révoc doit être divisé et partagé simplement, par un outil convivial, et tout ça, il faut penser smartphone, non? Pour le diviser, il faut bien le télécharger puis le découper. Faut + Faut = Vrait ?

Effectivement le programme devrait aussi permettre de télécharger le fichier de révocation complet, mais ce n’est pas le but principal.

J’ai avancé dans ma réflexion sur le sujet. Je te partage ici mes idées. Je ne suis pas sûr que cela soit dans la lignée de ce que tu voulais commencer à faire, mais que cela ne t’empêche en rien d’avancer sur tes idées et même de coder. Ce que je propose ne doit en rien te bloquer dans ton élan, juste te donner des idées pour avancer. Pour ma part je réfléchis avec Sakia en tête…

J’ai pensé à une intégration complète dans les clients. Le plus facile pour les utilisateurs.

Le client du certificateur, qui affichent les certifications émises, propose pour chacune de télécharger un fragment du fichier de révocation depuis le client du certifié.

Pour le téléchargement, quelque soit le mode de transfert, le certifié doit exporter physiquement ou par le réseau un fragment non déjà transmis. Le fragment est calculé par le client du certifié et stocké ensuite par le client du certificateur.

Le client peut alors afficher…

…pour le certificateur :

  • La liste des certifications émises avec un logo affichant si un fragment de la révocation est stocké par le client.

…pour le certifié :

  • La liste des certifications reçues avec un logo affichant si un fragment a été transmis.

Les fragments peuvent ensuite être récupérés de client à clients dans le sens inverse si besoin.

Ici, la confiance dans le code libre du client est primordial, et l’utilisation en local aussi, pour être sûr que personne sauf le certifié ne puisse reconstituer le fichier entier.

Le protocole d’échange entre client doit permettre l’échange entre différents clients (Sakia, Cesium, SIlkaj, etc). Et être simple. Le mieux serait d’avoir plusieurs moyens d’échange (clef usb, QRcode, wifi, bluetooth, etc…).

1 J'aime

Je suis d’accord que le mieux serait d’intégrer tout ça dans les clients existants, principalement Cesium pour la partie génération. (pour profiter de sa portabilité) C’est pourquoi je vais commencer par le backend, ça nous laissera le temps d’imaginer l’interface.

Il semble possible d’intégrer du Rust dans Electron, donc ça devrait marcher dans toutes les formes de Cesium. (mais sous Android et iOS je ne sais pas comment ça marche)

En revanche, est-il pertinent de se limiter aux certificateurs ? Un proche de confiance, qui ne veut pas être membre ou qui n’est pas encore certifié, pourrait très bien assumer cette tâche.

Non, bien sûr, mais là la personne de confiance est responsable du stockage des fragments et doit donc être un geek bien organisé… De même du côté du certifié qui doit se souvenir à qui il a donné des fragments. C’est beaucoup moins user-friendly mais doit bien sûr rester possible.

Je viens d’y penser : il serait utile qu’une fois que la personne se souvient bien de ses identifiants, elle puisse « désactiver » le fichier de révocation fragmenté, pour gagner en indépendance.

Je pense que ce n’est pas possible sans révoquer l’identité puis en créer une nouvelle, mais avec toutes les applications de la crypto que je découvre en permanence, pourquoi pas. (mais là sans appareils de stockage quantique je ne vois vraiment pas :stuck_out_tongue: )

À moins de modifier le protocole pour pouvoir révoquer un document de révocation, soit avec un nonce relié à l’identité, soit en publiant le hash signé du document, mais cette fonctionnalité risque de rendre plus difficile la révocation d’une identité volée ou dont on a perdu les identifiants.

J’ai prévu de développer un projet similaire mais plus orienté accès au compte que révocation.
Du coup, je viens de poster la note d’intention et les recherches préalable que j’ai fait sur le sujet (notamment le prototype dont s’inspirer) :

Si tu veux qu’on y travail ensemble, c’est avec plaisir ! Et on peut même se payer le luxe de le faire en présentiel vu qu’on est tout les deux sur Bordeaux :wink:

4 J'aimes