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

Sam 23 Jan 12:46:12 CET 2016

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 <http://en.wikipedia.org/wiki/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/a50068ed/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/a50068ed/attachment.gif>