[PP-discussions] Expérience systèmes distribués ?

Sam 23 Jan 15:23:20 CET 2016

Ok et merci.
J’approfondirais quand j’aurais la maquette à présenter et je verrais avec les spécialistes pour tous ces aspects sécurité, mais, a priori, c’est à peu près comme ça que je voyais les choses avec, de toute manière, nécessité d’un annuaire global pour ce que je veux faire.

Je m’explique par un exemple :
- un groupe (section, équipe de travail etc.) installe librement son instance,
- il la référence auprès du central si il y est autorisé
- celui-ci offre ensuite à l’instance un service d’authentification, par exemple valider à partir de son numéro d’adhérent au Parti que c’est bien un Pirate qui veut s’inscrire. 

L’idée est une gestion autonome des groupes mais avec des inscrits pouvant être “certifiés” par la structure centrale et qu’elle sache recompter les voix lors de transferts de vote.
Par exemple : x personnes adoptent une motion dans un groupe, cette motion est transmise au central avec ses votes, et ceux qui ont voté en local sont d’emblées identifiés et ne feront pas de votes doublons si ils viennent modifier leur vote sur le scrutin central.

From: Frédéric Lecointre 
Sent: Saturday, January 23, 2016 12:46 PM
To: Fabbad - PP-fr ; discussions at lists.partipirate.org 
Subject: Re: [PP-discussions] Expérience systèmes distribués ?

Le 23/01/2016 12:07, Fabbad - PP-fr a écrit :

  J’avais parlé ailleurs d’un concept de démocratie liquide et plutôt que d’en rester à un cahier des charges de développement, je développe moi-même.
  J’ai encore 1-2 semaines de boulot pour la présentation d’une maquette fonctionnelle et je tergiverse un peu sur la gestion des données sachant que j’ai prévu un système multi-serveur.

  En gros, si je prends le Parti Pirate : chaque section (ou autre groupe) pourrait gérer son instance de l’appli et faire passer à une instance centrale les propositions/décisions validées à son niveau pour une mise au vote au niveau national.

  Pour la phase de tests, je ne vais pas trop me prendre la tête avec ça, il faudrait déjà que ça fonctionne techniquement et socialement (= participation) sur une instance monoserveur, mais : 

  y a-t-il parmi vous quelqu’un qui a l’expérience de ces architectures et qui pourrait au moins m’assurer que je n’ai pas trop à m’en soucier pour l’instant ?

  Ce que j’ai prévu :
  - seule donnée réellement centralisée : ID unique utilisateur ;
Oui mais tu vas encore te simplifier la vie en utilisant un identifiant unique sur une instance et c'est id at instance qui te sert d'identifiant unique dans ton réseau tout en te permettant d'identifier l'utilisateur dans son instance.

A la fin de cette réponse, je pose quelque chose qui permet de gérer les inscriptions de façon presque anonyme. l'ACR permettant alors de s'inscrire dans une instance. Il faudra prévoir un annuaire global, par webfinger.

  - échanges : par webservice XML (ID, profils utilisateurs...) et du POST basique pour le passage d’une proposition à voter.
  A priori, rien de problématique, mais comme je n’ai jamais eu à gérer ce genre de développements...
Ne présume pas du format d'échange et raisonne en fonction de message à échanger entre deux systèmes. Le reste découlera de l'architecture, des contraintes, du langages, etc. Cela peu se passer avec xmpp par exemple. En ce moment, je m’intéresse fortement à Ice (https://zeroc.com) qui permet de fournir un environnement multi-système mais surtout un bus de messagerie. Il y en a d'autres comme rabbitMQ ou 0MQ.

-----------------------
Toutefois, le principe de clé est intéressant mais ne devrait concerner que l'inscription. Avec le système actuel, le secrétaire peut facilement briser l'anonymat en ayant accès à la fois à la base de données des adhérents contenant le code confidentiel d'inscription et à la fois à la base de données de Liquid feedback. C'est peut être cela qu'il faut renforcer. De plus, les identifiants doivent être créés par l'utilisateur final et de lui seul. Cela évite l'interception décrite plus avant.
Prenons le cas des certificats SSL. Je veux un certificat pour mon site. Je produis une paire de clés, je conserve la clé privé à l'abri. Ensuite, je produis un CSR (Certificat signing request, requête de signature d'un certificat) contenant les informations que je dois fournir (l'url du site à minima) et la clé publique. Je transmets mon certificat à une CA (Certification Authority, autorité de certification) qui signe mon certificat. Cela implique qu'elle approuve les données du CSR et produit un certificat que je peux ensuite utiliser sur mon site. Dans la pratique, et comme un passeport, on ne fait pas confiance au certificat du site web mais à la CA qui l'a signée. Ainsi, si la CA n'est pas approuvée sur mon système, une alerte de sécurité sera affichée. Cela ne veut pas dire que le certificat du site n'est pas valable (techniquement il fonctione très bien, voir par exemple le certificat SNake Oil d'Apache) mais que dans ma configuration, je ne peux pas lui faire confiance n'ayant pas fait confiance au préalable à la CA. SI je décide faire confiance à la CA, le certificat deviendra alors lui aussi de confiance. 

Voici donc en "résumé" le fonctionnement des chaines de certificat x509 pour introduire ce qui suit. 

Appliqué à liquid feedback, ou un autre système équivalent, voici ce qu'il est possible d'obtenir :
0 - Le Parti Pirate génère un certificat racine pour créer une CA qui produit deux certificats CA intermédiaire : Un pour le secrétaire, un pour le gestionnaire liquid feedback. Les personnes ayant accès à un certificat ne doivent en aucun cas accéder à l'autre.
1 - Un nouvel adhérent génère un paire de clé et un CSR qui est transmis au secrétaire à l'inscription.
2 - le secrétaire valide l'inscription, produit un certificat à partir de la CSR et le signe. Il produit en outre un code confidentiel qu'il signe
3 - l'adhérent reçoit son certificat qui tient lieu de carte d'adhérent électronique et de moyen de s'authentifier auprès des différents services de Parti Pirate (forum, ML, wiki, redmine, etc.) mais pas liquid feedback
4 - il génère une nouvelle paire de clé et produit un ACR (Account Creation Request, requête de création de compte) contenant le code confidentiel signé mais pas d'informations nominatives
5 - il envoie l'ACR au gestionnaire Liquid feedback qui va produire un deuxième certificat permettant de s'authentifier auprès du service et sur la confiance en la signature du code confidentiel. A ce stade, ce gestionnaire ne connait pas et ne doit pas connaitre l'identité de l'émetteur de l'ACR. Le code confidentiel est supprimé du système à la création de ce certificat considérant que le préalable à la création de ce certificat est de confirmer que le code confidentiel est bien produit par le secrétaire.
6 - Il se connecte à liquid feedback avec ce deuxième certificat.

J'ai une variante où une partie de l'ACR est créé par le secrétaire avec des informations utiles pour le vote comme la section d'appartenance. Dans ce cas, le code confidentiel disparait plus ou moins et cette partie d'ACR sert de preuve pour le gestionnaire liquid feedback.

Une autre variante consiste à répudier (ou les rendre obsolètes pour la création de nouveaux certificats mais pas pour l'authentification) les CA intermédiaire lorsque physiquement les personnes changent au poste de secrétaire et gestionnaire.

C'est une usine à gaz  enfin une sorte de PKI (Public Key Infrastructure, infrastructure à clés publiques) qui au détriment de la simplicité du procédé (dans la pratique c'est assez fluide) permet des avantages non négligeables :
- les certificats sont produits avec une durée de validité de 365 jours, c'est-à-dire une durée d’adhésion. Ainsi, et automatiquement, un adhérent n'ayant pas renouvelé son adhésion et connu comme tel. Cela désactive sa participation à liquid feedback sans intervention de la part du gestionnaire ni du secrétaire. Actuellement, je ne suis pas sûr que les adhérents n'ayant pas renouvelé leur inscription n'ont plus accès à Liquid Feedback. Oui cela implique la production d'un nouveau certificat de l'étape 2 et de rejouer les étapes 3 à 5
- les certificats sont répudiables en cas de compromission et l'effet de la répudiation est immédiat

Ce procédé implique les considérations suivantes : 
- Le secrétaire et le gestionnaire ne partage pas de données pour qu'à partir du code confidentiel l'un ou l'autre ne soit en mesure de briser l'anonymat. Ce point est critique et demande différents niveaux de protection suivant le degré de certitude que l'on souhaite obtenir.
- L'utilisateur de Liquid feedback doit utiliser la plateforme au travers d'un réseau de type tor afin que le gestionnaire ne puisse pas faire la relation avec son adresse IP. Cela est valable pour la création du deuxième certificat et pour l'utilisation courante de la plateforme
- Liquid feedback ne doit concerner que la partie 4 du processus démocratique, ou enfin il faut trouver un autre système de vote qui ne serve qu'à cela.

-- 
Frédéric Lecointre 
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.partipirate.org/mailman/private/discussions/attachments/20160123/43ea50fa/attachment.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: icon_wink.gif
Type: image/gif
Taille: 170 octets
Desc: non disponible
URL: <http://lists.partipirate.org/mailman/private/discussions/attachments/20160123/43ea50fa/attachment.gif>