[Cocorico] avancement 27/10/2016

Jean-Marc_Le_Roux · Octobre 27, 2016, 9:40

Bonjour,

le projet « Cocorico » (la plateforme de vote) avance à vive allure, notamment en raison de son utilisation pour le 1er tour de LaPrimaire.org qui a commencé depuis le 25/10 ! Voilà donc un récapitulatif sommaire des changements apportés depuis le 6/10.

Merci à Yoann Aubineau pour ses contributions sur les « webhooks ».
Merci à Thibauld pour son travail d’intégration/test dans LaPrimaire.org.

1. Gestion des webhooks

Les plateformes tierces (ex : LaPrimaire.org) qui intègrent la plateforme de vote peuvent maintenant suivre le déroulé d’un vote sans se fier au navigateur de l’utilisateur. Les webhooks permettent une communication serveur/serveur entre Cocorico et la plateforme tierce.

2. Ajout d’un firewall

Le serveur limite maintenant l’accès aux seuls ports suivants :

8 (ping)
22 (ssh)
80 (http)
443 (https)

3. Support de Safari

Le navigateur Safari est maintenant supporté à partir de la version 9.1.

4. Meilleure sécurisation du smart contract de vote

Le smart contract (le code exécuté sur la blockchain) a été modifier pour gérer plusieurs états et permettre certaines actions en fonction de cet état :

open : le vote est « ouvert », les fonctions registerVoter(), vote() et close() peuvent être appelées, la fonction getResults() ne peut pas être appelée
close : le vote est « fermé », les fonctions registerVoter(), vote() et close() ne peuvent pas être appelées, la fonction getResults() peut être appelée

En gros, on peut voter tant que le vote est « ouvert », mais pas avoir les résultats.
Et inversement quand le vote est « fermé ».
Pour des raisons de sécurité, on peut « fermer » un vote, mais pas le rouvrir.
Ceux sont des choix d’implémentation à débattre avec des implications énorme qui vont jusqu’à remettre en question la constitutionnalité du vote (rien que ça…).

Le smart contract a également été modifié pour mieux remonter les erreurs.

5. Réécriture du service d’inscription des bulletins de vote sur la blockchain

Ce service souffrait de nombreux défauts, qui pouvaient entraîner des bulletins de vote dans un état indéterminé. Le service a été entièrement réécrit pour être plus fiable et mieux tirer partie de l’architecture multi-processus.

La gestion des erreurs a également été améliorée et permet d’avoir un suivi de toutes les erreurs qui se sont manifestées lors du traitement d’un bulletin en particulier.

6. Traitement multi-processus des bulletins de vote

Les bulletins de vote ne sont plus gérés par un seul mais plusieurs processus. Chaque processus passant quasiment tout son temps à attendre/ne rien faire, cela n’a que peu d’impact sur les performances. Mais cela permet de distribuer le risque de panne.

Ces processus pourraient tourner sur des machines séparées, voir sur les machines de citoyens volontaires qui hébergeraient déjà la blockchain.

Il en est de même pour tous les autres services, comme les webhooks.

7. Résilience du service de traitement des bulletins de vote

Jusqu’ici, lorsque ce service plantait, il fallait le redémarrer à la main. Lorsqu’un des processus de traitement des bulletins tombe, il va automatiquement être relancé après 30 secondes.

Il en est de même pour tous les autres services, comme les webhooks.

8. Création d’un framework de test

Le code qui est en commun avec tous les différents tests (API, app, etc…) a été mis dans un package commun pour en augmenter la maintenabilité. Ce framework permet de tester toute la procédure de vote en simulant la création de votes et l’envoie d’un nombre donné de bulletins en 50 lignes de code.

9. Embryon de tests pour l’application Web

Début de travail sur l’automatisation du lancement et du pilotage d’un navigateur Web qui va aller tester l’application Web. Ces tests vont simuler l’utilisation de l’application Web dans des conditions quasi réelle (vrai navigateur, vrais clicks, vrai formulaires à remplir, etc…) mais piloté par du code pour tester la procédure de vote et en valider le bon déroulé.

Ces tests seront automatisés pour permettre de vérifier que chaque modification du code ne cause pas de régression sur la procédure de vote telle qu’elle sera suivie par les vrais utilisateurs.

10. Ajout de traductions

Certains éléments de l’interface - notamment les boutons pour imprimer/télécharger la preuve de vote - ont été traduits en français.

11. Nouvelles options de configuration de la blockchain

La configuration de la plateforme permet maintenant de déclarer la « target gas limit », une valeur qui permet d’influencer le nombre de transactions qui pourront être stockées dans un block de la blockchain. Augmenter cette valeur permet de traiter plus de transactions dans un même temps, et donc de mieux répondre aux problématiques de charge.

12. Configuration explicite de la langue/locale

Il est maintenant possible de forcer la locale utilisée en ajoutant le paramètre « lang » dans une URL (par exemple https://cocorico.cc/?lang=fr-FR pour forcer le français). La locale sélectionnée est alors enregistrée dans un cookie pour que la navigation reste cohérente tout le temps de la session.

13. Logs en JSON pour l’API Web

L’API Web écrit maintenant ses logs en JSON pour permettre l’automatisation de leur traitement. Ces logs sont également plus verbeux pour permettre un meilleur suivi du fonctionnement de l’API.

14. Configuration de déploiement extensible

La configuration de la plateforme peut maintenant être étendue/surchargée sans modifier la configuration principale. Cela permet par exemple de créer une/des instances privées/dédiées de la plateforme sans modifier la configuration originale. C’est ce qui a été utilisé pour déployer https://laprimaire.cocorico.cc.

Les configurations additionnelles peuvent ainsi être versionnées sur un dépôt séparé, notamment pour des raisons de confidentialité.

15. Automatisation du déploiement/renouvellement des certificats SSL

Le(s) certificat(s) SSL sont obtenus et renouvelés automatiquement grâce à let’s encrypt.

16. Correction d’un bug sur le nombre de propositions par vote

Un bug limitait le nombre de propositions (valeurs de bulletin) possibles pour chaque vote à 3. Ce bug a été résolu pour permettre par exemple à LaPrimaire.org d’implémenter le jugement majoritaire avec 5 propositions (« très bien », « bien », etc…).

17. Automatisation des backups

Il est maintenant possible d’automatiser le déploiement d’une machine qui sera dédiée au backup automatique des données de la plateforme. Cette sauvegarde intervient automatiquement toutes les heures de façon incrémentale. Il est donc possible de revenir à n’importe quelle date dans le temps, heure par heure. Les données sauvegardées sont :

tous les logs (API Web, blockchain, services…)
la blockchain
les files de traitement

A votre disposition si vous avez des questions !

Julien · Octobre 27, 2016, 6:46

J’ai pas tout compris. Mais ça me fait briller les yeux de voir que ça avance bien.

Jean-Marc_Le_Roux · Octobre 27, 2016, 6:51

C’est pour ça que je poste ici : pour que vous posiez des questions

Janique · Octobre 27, 2016, 8:29

Woooow ! Bon je vais lire tout ça e tête reposée, je me suis inscrite sur La Primaire pour voter, donc, je vais expérimenter. Très excitant!

Sly · Octobre 27, 2016, 11:42

D abord bravo, belles avancees et tout mes souhaits de réussite pour la mise en prod pour laprimaire.org.

Tu sauvegardes l’ etat de la blockchain a chaque heure? C’est pas un peu gourmand ouf? Est ce que tu peux donner des user case (etude de cas/ d’impact) pour illustrer les choix que vous avez pris? Notamment pour les non technophiles afin que tout le monde comprenne bien l interet du SSL des logs etc…

Jean-Marc_Le_Roux · Octobre 28, 2016, 6:31

C’est une sauvegarde incrémentale. Donc à priori, à un petit delta prêt (les méta données de chaque sauvegarde), la totalité des backups fait le même poids que les dernières données sauvegardées.

La plupart des choix sont des best-practices. Même des choses qui peuvent sembler très nouvelles font finalement intervenir des recettes classiques. Je pense notamment au fait d’utiliser une file de messages entre l’API Web - qui doit répondre en quelques millisecondes - et la blockchain - qui répond au mieux en quelques secondes.

Là ou il doit y’avoir une discussion je pense c’est sur le point « 4. Meilleure sécurisation du smart contract de vote ». Les implications sont bien plus larges que leur seul aspect technico-technique. Pour faire simple :

A - une blockchain « publique » permet nécessairement de pouvoir librement consulter toutes les transactions de bulletin de vote faites vers un contrat de vote en particulier ; et donc de reconstituer les résultats du vote avant qu’il ne soit terminé. Mais…
B - une blockchain « privée » ne permet pas du tout de consulter les transactions de bulletin de votes ou l’urne numérique, et nous prive donc de l’intérêt essentiel de la blockchain.

A lire sur le sujet (notamment le point 3) :

Why Many Smart Contract Use Cases Are Simply Impossible

Hiding data in a smart contract is about as secure as hiding it in
the HTML code of a web page. Sure, regular web users won’t see it,
because it’s not displayed in their browser window. But all it takes is
for a web browser to add a ‘View Source’ function (as they all have),
and the information becomes universally visible.

Similarly, for data hidden in smart contracts, all it takes is for
someone to modify their blockchain software to display the contract’s
full state, and all semblance of secrecy is lost.

A half-decent programmer could do that in an hour or so.

Et quand il dit « an hour or so » il est gentil, par ce que ça prend quasiment qu’une seule ligne de code… Donc c’est 59 minutes à boire un café et 1 minute à coder.

En conclusion on a choisi la blockchain pour être dans le cas A, pour des raisons de confiance, de transparence et de fiabilité. Mais le cas A implique que n’importe qui peut connaitre les résultats du vote en temps réel, ce qu’on ne veut à priori pas pour éviter un biais. Même si on décide nous de ne pas les afficher, ils sont techniquement consultables et d’autres pourraient décider de les afficher.

Je ne vais pas rentrer dans le détail, mais j’en suis venu à la conclusion que c’est mathématiquement impossible : toute solution qui permet de ne pas avoir les résultats accessibles en temps réel va nécessairement rendre opaque la procédure de vote/le contenu de l’urne numérique, et donc sacrifier la transparence/confiance/fiabilité/neutralité du système.

Il faut donc entamer un travail pour soit :

démontrer que c’est faux ;
se mettre d’accord sur cet état de fait et arriver à trouver des paliatifs.

Concernant le 1, je place peu d’espoirs. Quand je dis « mathématiquement impossible » ci-dessus, je le pense littéralement : je pense qu’on peut littéralement écrire la preuve mathématique.

Il faudrait surement créer un sujet séparé là dessus et faire un atelier.

fredericrivain · Novembre 3, 2016, 12:34

Petite question (navré si elle a déjà été posée): quels types de tests de sécurité ont été faits sur la plate-forme ? Avez-vous pu faire par exemple des tests de type bug bounty platform (HackerOne, BountyFactory…) ? Merci d’avance.

Jean-Marc_Le_Roux · Novembre 3, 2016, 4:00

Il y’a des tests automatisés qui s’assurent du bon comportement de l’API. Le but est notamment de vérifier le comportement en cas de tentative de double vote ou de vote non autorisé/non authentifié.

D’autres fonctionnalités orientées sécurité ont été mises en place cette semaine. J’en parlerai quand le 1er tour sera fini.

Rien d’aussi poussé, faute de temps/resources.
Ca serait bien d’avoir un volontaire pour mettre ça en place et faire le suivi.
Tu peux t’en charger ?

Janique · Novembre 5, 2016, 8:32

Un gros hack vient d’avoir lieu, 49 pays sont concernés. D’après ce que j’ai lu, (article dans Médium) les Shadow Brokers s’amusent à mettre en jeu la sécurité des élections américaines. Bluff ou réalité? La cybersecurite revient sur le devant de la scène aux US en tout cas.

Ludovic_69620 · Novembre 15, 2016, 2:44

Salut @Jean-Marc_Le_Roux, as-tu du nouveau tout tout frais sur le sujet ?
On participe à OuiShare Drink à Lyon sur les civic Tech et ils nous demande de faire une présentation de MaVoix ainsi que de la plateforme de vote.
Je vais mettre à jour notre power point du 15 octobre grâce à ton post du 27 et je voulais savoir si tu avais breaking news total amazing en réserve !

Merci

Jean-Marc_Le_Roux · Novembre 16, 2016, 9:05

anthony-o · Novembre 30, 2016, 12:48

Et pourquoi ne pas partir sur une blockchain publique mais dont l’adresse n’est révélée qu’à la fin du vote ?
Ainsi avec les preuves de vote on peut s’assurer qu’il s’agit bien de cette blockchain, et par ailleurs on ne peut pas faire de statistiques temps réel durant le vote.

Ou encore, les valeurs des vote sont encryptées avec une clé publique, et la clé privée n’est révélée qu’à la fin du vote à tout le monde ? Ici tout le monde peut s’assurer que la blockchain avance, est utilisée, mais la vérification ne se fait qu’à la fin. Ceci implique bien sûr que l’organisateur révèle cette clé pour de vrai à la fin et donc qu’on lui fait confiance sur cette révélation.

Jean-Marc_Le_Roux · Novembre 30, 2016, 1:20

Les transactions sont créées et signées dans le navigateur. L’API Web est un simple « passe plat ». Le navigateur doit donc avoir toutes les informations pour créer cette transaction. Ce qui implique donc que toutes les informations que tu évoques sont, elles aussi, publiques.

Donc ça ne change à priori pas le fait qu’on peut suivre en temps réel le scrutin.

anthony-o · Novembre 30, 2016, 3:17

Pas si les valeurs sont encryptées par le navigateur web à l’aide de la clé publique du vote : les valeurs de votes seraient alors encryptées et non disponible. A la fin du vote, l’organisateur révèle la clé privée et tout le monde peut décoder les valeurs et les vérifier. Ça ne se tient pas ?

Sly · Novembre 30, 2016, 3:25

@anthony-o il y a incompréhension

API Web : sur un serveur quelque part
navigateur : sur le poste de l’utilisateur

Le code javascript qui génère les transactions est exécuté sur le navigateur pas sur un serveur centralisé, c’est voulu, c’est mieux, donc c’est chez l’utilisateur. Si on passe la clé privée de l’API au navigateur, elle n’est plus privée car le navigateur l’obtient. Si on fait l’inverse ca veut dire passer la valeur de vote du navigateur à l’API là ouille ouille ouille pas cool. Donc pas jouable…

anthony-o · Novembre 30, 2016, 3:54

Pour le coup je comprends tout à fait cette partie mais je persiste.

Ce que je propose c’est que lors de la création du vote sur le navigateur, ce dernier va chercher la clé publique du vote, encrypte la valeur de son vote avec celle-ci, et fait tout le reste comme actuellement.
Cette clé publique ne sert qu’à encrypter la valeur du vote et correspond bien sûr à la partie publique d’une clé asymétrique d’encryption dont l’organisateur détient la clé privée.

Dans la blockchain nous auront donc que des votes avec valeurs encryptées (toutes les autres infos étant comme aujourd’hui). Normalement, ça interdit à quiconque (excepté l’organisateur) de pouvoir décrypter ces valeurs et donc de faire des stats pendant le vote.

A la fin du vote, la clé privée d’encryption est révélée à tout le monde par l’organisateur, et donc à partir de là n’importe qui peut utiliser cette clé pour décrypter l’ensemble des valeurs de vote.

On peut même améliorer le système en faisant en sorte que cette clé asymétrique soit générée quelque-part sur un serveur par un processus automatique, qui diffuse la clé publique pendant le vote, et la clé privée à la fin du vote de manière à ce que même l’organisateur ne puisse pas y avoir accès.

Jean-Marc_Le_Roux · Novembre 30, 2016, 7:07

J’imagine qu’on pourrait effectivement avoir une clef privée qui déchiffre et de multiples clefs publiques dérivées qui chiffrent. Cependant, on ne peut pas utiliser de chiffrement asymétrique sur la blockchain (cf cette issue).

Le mieux c’est de ne pas discuter de ça sur le forum, mais de venir sur le gitter ou aux hackathons.