Aller au contenu

Élection du Conseil de Laboratoire✯

English version here

Addresse de l'élection

https://e-vote.limos.fr

Pour les instructions fournies par l'éditeur du logiciel Belenios, vous pouvez vous rendre sur le site belenios.org.

Instructions pour l’électeur✯

Avant le début de l’élection, l’électeur reçoit un mail avec son code de vote et l’url de l’élection. La page de l’élection affiche l’heure d’ouverture lorsqu’elle n’est pas encore ouverte.

Pendant l’élection, l’électeur peut se rendre sur la page de l’élection et voter de la manière suivante :

  • l’électeur saisit son code de vote. Cette étape peut être faite automatiquement, si l’url de l’élection reçue par l’électeur a été personnalisée avec le code de vote (cas d’un envoi de codes de vote par le serveur notamment).
  • il a alors accès aux questions de l’élection et sélectionne ses candidats
  • l’ordinateur chiffre ses choix (à l’aide d’un programme JavaScript) et affiche à l’électeur un numéro de suivi, qui est une empreinte du bulletin. Ce numéro de suivi est également envoyé par mail lorsque l’électeur a fini de voter.
  • une fois que l’électeur a vérifié ses choix, il est invité à s’authentifier. Il reçoit alors un mot de passe éphémère à son adresse email, qu’il saisit dans l’interface de vote. D’autres moyens d’authentification sont possibles (par exemple un envoi préalable d’un mot de passe suivant les élections).
  • note : un électeur peut voter à nouveau. Seul le dernier vote est pris en compte.

Un tutoriel vidéo est disponible en ligne.

Le système de vote Belenios est vérifiable.

  • l’électeur peut s’assurer que son bulletin de vote est bien pris en compte, en vérifiant que son numéro de suivi apparait bien dans l’urne, en consultant la page voir les bulletins acceptés sur la page d’accueil de l’élection. Il doit protester si ce n’est pas le cas. Si l’électeur vote plusieurs fois, seul son dernier numéro de suivi apparait.

  • l’électeur doit également protester vivement s’il reçoit un mail de confirmation sans avoir voté ou s’il reçoit un mail de confirmation avec un numéro de suivi différent de celui affiché à l’écran pendant la phase de vote. Quelqu’un a probablement réussi à ajouter un bulletin en son nom. Cela peut être par exemple l’indice d’une attaque par un administrateur système ayant accès au mail de l’électeur si le mot de passe et le code de vote sont envoyés sur la même adresse.

Un électeur peut également vérifier l’intégralité du processus du vote. C’est à dire qu’au lieu de simplement vérifier la présence de son bulletin dans l’urne, il peut vérifier la conformité de tous les bulletins, monitorer l’urne pour vérifier qu’aucun bulletin ne disparait et enfin s’assurer que le résultat proclamé correspond aux bulletins dans l’urne. Pour ce faire, il doit suivre les instructions de l’auditeur.

Instructions pour la commission électorale✯

A minima, la commission électorale consulte la page d’accueil de l’élection dès qu’elle ouverte et vérifie que :

  • le nombre d’électeurs affiché correspond à la liste électorale;
  • la valeur Empreinte de la liste électorale affichée correspond à l’empreinte de la liste électorale voters.txt fournie (par le système informatique ou l’administrateur de l’élection). Le calcul de l’empreinte peut être fait avec l’une des commandes décrites ici.
  • la liste électorale voters.txt correspond bien aux électeurs légitimes, avec le nombre de voix associé dans le cadre d’un vote pondéré.
  • la liste des questions et des réponses correspond bien à ce qui a été déterminé pour ce scrutin. Les questions et les réponses associées apparaissent dans le fichier $UUID.bel. Ce fichier peut être obtenu en cliquant sur données publiques dans le bandeau en bas de la page d’accueil de l’élection.

Idéalement, la commission électorale accomplit également le travail de l’auditeur ou mandate une personne pour le faire (des services informatiques par exemple).

Instructions pour l’auditeur✯

Tout le monde connaissant l’url de l’élection peut être auditeur. L’url d’une élection est de la forme PREFIXE/elections/UUID/, où, par exemple, PREFIXE=https://e-vote.limos.fr et UUID=8GVH85AoSyweXG.

Un auditeur va, en particulier, assurer que :

  • les données de l’élection (les clés publiques, la liste des codes de vote publics, etc) sont cohérentes et ne changent pas au cours du temps ;
  • l’urne, qui contient les votes chiffrés, évolue de manière cohérente : aucun bulletin n’est retiré à moins que ça soit un bulletin avec le même code de vote (cela correspond à un revote) ;
  • l’urne ne contient que des bulletins bien formés (avec des preuves zero-knowledge valides, et un code de vote valide) ;
  • l’intégrité des fichiers actifs (HTML, Javascript, etc.) utilisés par les électeurs et les autorités est préservée ;
  • le résultat de l’élection correspond aux bulletins chiffrés, grâce aux preuves zero-knowledge de bon déchiffrement produites par les autorités de déchiffrement.

La sécurité de Belenios s’appuie sur le fait que les vérifications décrites ci-dessous sont effectuées par au moins une personne honnête.

Note: ces vérifications sont aussi effectuées automatiquement par nos serveurs pour les élections qui sont mises en place avec un niveau de sécurité maximal (autorité de code de vote externe et au moins deux autorités de déchiffrement externes).

Préparation Pour effectuer ces tests, des logiciels sont nécessaires. Nous décrivons ici comment exécuter les vérifications en utilisant belenios-tool dont les sources sont disponibles à partir du Gitlab Inria et qui est installable sous Linux Debian/Ubuntu avec sudo apt install belenios-tool. Ensuite, l’auditeur doit se créer un dossier de travail workdir où les données d’audit de l’élection seront sauvegardées au fur et à mesure des téléchargements, sous la forme d’un dépôt git.

Afin de vérifier que les codes HTML/Javascript utilisés par les électeurs, les autorités de déchiffrement et l’autorité de code de vote, ne sont pas modifiés par un serveur corrompu, l’auditeur doit trouver le “bon” code de tous ces programmes. Il doit ensuite s’assurer que le serveur fournit ces fichiers de manière fidèle. Tout d’abord, un fichier de référence doit être créé. Pour cela, on copie celui des sources de Belenios :

cp path/to/sources/belenios/contrib/reference_template.json workdir/hashref

Ensuite, il y a plusieurs solutions pour assurer que les fichiers servis par le serveur sont valides, lorsque l’on audite l’élection identifiée par UUID :

  • soit l’auditeur fait simplement confiance aux fichiers téléchargés la première fois et vérifie qu’ils ne varient pas au cours du temps (principe TOFU). Alors la commande d’audit est la suivante : ./monitor_elections.py --url PREFIX --wdir workdir --checkhash yes --hashref workdir/hashref --outputref workdir/hashref --uuid UUID

  • Chaque fois qu’un fichier change (y compris lors de la première exécution), cela va afficher un message d’alerte.

  • soit l’auditeur récupère les sources, recompile le code, démarre un serveur local, et utilise la commande précédente pour remplir le fichier workdir/hashref avec des données de confiance. Puis il peut copier ce fichier comme référence pour l’audit de la vraie élection qui est hébergée sur le serveur externe. La commande est alors la même que ci-dessus.

  • soit l’auditeur fait confiance à une personne bien identifiée qui a publié une version signée avec gpg du fichier de référence. Dans ce cas, des arguments supplémentaires doivent être passés au programme d’audit : l’url de cette version signée, ainsi qu’un trousseau de clé gpg contenant la clé publique de la personne, en tant que clé de confiance. Dans le cas de notre plateforme de vote, un tel fichier est fourni par le développeur principal de Belenios, Stéphane Glondu. Nous donnons la ligne de commande correspondante, devant être adaptée pour un autre serveur ou une autre personne de confiance : ./monitor_elections.py --url https://vote.belenios.org/ --wdir workdir --checkhash yes --hashref workdir/hashref --outputref workdir/hashref --sighashref https://vote.belenios.org/monitoring-reference/reference.json.gpg --keyring workdir/trustdb.gpg --uuid UUID

Dans tous les cas, l’auditeur va régulièrement exécuter une commande d’audit que nous appellerons monitor_elections. Il est possible de rediriger les messages avec l’option --logfile. Alors, seuls les comportements anormaux seront rapportés sur stdout/stderr, ce qui rend possible d’exécuter la commande depuis une crontab et d’être alerté en cas de problème.

Phase de vote. Pendant l’élection, il est attendu de l’auditeur :

  • dans le cas où l’auditeur a accès à la liste électorale voters.txt (ce qui est le cas de la commission électorale), qu’il vérifie que le nombre de votants affiché sur la page principale de l’élection correspond à la liste électorale, ainsi que le poids total de l’élection, s’il s’agit d’une élection à poids, et que l’empreinte de la liste électorale correspond à celle qui a été sauvegardée auparavant, par exemple en utilisant une des commandes suggérées ici ;

  • si l’auditeur n’a pas accès à la liste électorale, qu’il vérifie que le nombre d’électeurs et le poids total de l’élection affichée sur la page principale de l’élection correspondent aux données officielles.

  • qu’il exécute fréquemment monitor_elections. Idéalement, cela doit être effectué à des moments non-prédictible dans le temps, à partir d’adresses IP variées reflétant la diversité des électeurs et des autorités. Le but est qu’un serveur corrompu ne puisse pas deviner si les requêtes viennent d’un auditeur ou d’un votant ou d’une autorité. Voici quelques recommandations pour qu’un auditeur puisse se faire passer pour un utilisateur :

  • comme déjà mentionné, les requêtes au serveur doivent être fréquentes, mais pas à intervalle régulier ou prédictible ;
  • non seulement les adresses IP doivent varier, mais également les informations de configuration du navigateur (type de navigateur et version, système, extensions actives, fuseau horaire, langue, résolution de l’écran, etc), à partir d’un grand nombre de configurations réellement utilisées par des humains ;
  • les adresses IP doivent refléter les lieux variés et les fournisseurs d’accès de la population des électeurs ;
  • l’ordre dans lequel les fichiers sont demandés au serveur doit refléter l’ordre d’une visite typique des électeurs et des autorités, avec un délai plausible (mais non-prédictible) entre chaque requête.

Notons que le script fourni par belenios-tool n’offre pas de support pour tout ceci.

Après l’élection. Après l’élection, il est attendu de l’auditeur :

  • qu’il exécute de nouveau monitor_elections. La page de l’élection contient désormais un fichier result.json et cette commande va vérifier les preuves cryptographiques associées au résultat de l’élection ;
  • qu’il vérifie que le résultat mentionné dans le fichier result.json correspond au résultat publié sur la page principale de l’élection. Cette vérification doit être effectuée manuellement.

Note : Si l’outil en ligne de commande belenios-tool est utilisé, la confiance dans les tests effectués repose en partie dans la confiance en l’outil. Il est possible d’implémenter son propre logiciel de vérification à partir des spécifications de Belenios, disponibles ici.

Comment calculer l’empreinte d’un fichier ?✯

Pour calculer l’empreinte d’un fichier, vous devez utiliser la même fonction de hachage que celle utilisée dans Belenios. Nous proposons ici plusieurs solutions pour calculer cette empreinte en ligne de commande. Nous utilisons le fichier voters.txt en exemple mais vous pouvez bien sûr le remplacer par un autre fichier.

sha256sum voters.txt | xxd -p -r | base64 | tr -d "="

(ou bien shasum -a256 au lieu de sha256sum par exemple sur MacOS)

ou encore :

cat voters.txt | python3 -c "import hashlib,base64,sys;m=hashlib.sha256();m.update(sys.stdin.read().encode());print(base64.b64encode(m.digest()).decode().strip('='))"

Vous pouvez également utiliser l’outil en ligne mis à disposition par Belenios.

Authors: Bastien, Boris LONJON, Vincent Mazenod