Le déroulé d'une votation avec xVote

De la transparence statique du code à la transparence dynamique de l'exécution

La nécessaire accessibilité du texte du programme, le besoin de la transparence statique

Auparavant, une remarque : il ne suffit pas que le code du système de vote soit accessible*, lisible même plus ou moins publiquement.
   (*) Actuellement, il est soit pas du tout accessible (propriétaire ou secret défensesécurité -sic), soit de manière très restrictive, à titre individuel (dûment motivé et arbitrairement accepté), sous engagement de confidentialité et dans des conditions ne permettant pas une réelle étude.

Il faut que la licence du logiciel permette :
  1. d'obtenir librement le code par tous [par les expertises les plus variées] et de partout, et le consulter sans restriction,
  2. de le copier et de le transmettre à d'autre [p.ex. annoté] pour participer collectivement à son étude,
  3. d'être distribué sous forme électronique pour pouvoir l'analyser avec des outils logiciels (p.ex. contrôle sémantique, traçage, profileur, etc.),
  4. de modifier le code pour l'expérimentation (p.ex. d'alternatives, enrichissements de données, collectes d'états et journalisations, etc).
C'est le cas des licences OSI, telles les GPL.

La totalité d'xVote est sous licence CeCILL-CIS, soit la traduction en français de la GPLv2, adaptée au droit européen (CeCILL*) et particulièrement suisse (CIS**). Les documents sont en Creative Common. De plus, l'implantation et son évolution sont réalisées selon les usages participatifs de l'OSS et avec leurs outils publics (forums, blog, wiki, launchpad, etc.).
   (*) Licence des établissements publics français. (**) Licence de la commission informatique suisse, des cantons (version avec médiation et arbitrage).

En plus, le nécessaire contrôle publique de l'exécution du programme, le besoin de la transparence dynamique

Mais ce n'est pas tout, il ne suffit pas de publier, même en GPL, le code logiciel. Là aussi c'est insuffisant : car rien ne prouve qu'un programme en cours d'exécution sur une machine distante est bien celui qui a été étudié !

Il faut aussi que :
  1. des preuves (juridiquement valides) du bon déroulement soient construites tout au long des opérations,
  2. qu'aucune information critique ne soit transmise aux logiciels des serveurs dont l'état est inconnu,
  3. que les garanties de bonne fin, sans falsification possible grâce au protocole, soient obtenues sur le poste du votant* dont le logiciel exécuté est sous contrôle public (à l'inverse de ceux des serveurs).
Le logiciel client peut, après avoir été étudié, être compilé et soit utilisé**, soit comparé au code binaire distribué pour les citoyens; le compilateur (et bibliothèque tierces, et relieur) utilisé est librement disponible.
   (*) Vous verrez ci-dessous que le fonctionnement du protocole d'xVote fait du poste du votant un observateur, un contrôleur complet du processus, donc l'organisateur ou le chef d'orchestre du vote.
   (**) En fait, on peut librement constituer sont propre logiciel client, p.ex. pour étude ou contrôle, du moment qu'il suit le protocole de vote intégralement publié (en passant, pour l'ensemble d'xVote, les protocoles et formats sous-jacents sont strictement standards : normes IETF, WC3, ECMA, OASIS, ISO, etc).
Il s'agit là de transparence dynamique, par opposition à la seule disponibilité du code source (GPL) qui apporte la seule transparence statique. De plus, de par sa structure en grappes de serveurs et sur plusieurs sites, xVote complète la transparence dynamique en permettant, (1) le contrôle croisé de chaque site par l'autre, et (2) en cas d'audit, la pose de sondes ou renifleurs (sniffers) sur les réseaux locaux pour contrôler la bonne exécution des logiciels serveur. Du fait du strict partitionnement de l'information, et comme pour la journalisation des opérations des serveurs, cette saisie de données ne rompt en aucun cas le secret du vote.

Le déroulement d'une votation, avec un aperçu du protocole sous-jacent à un vote

Voici donc, ci-après, le déroulé des opérations d'un scrutin, un déroulé simplifié et débarrassé tant des détails de confort/souplesse pour l'utilisateur, des éléments cryptographiques avancés (p.ex. créations/dérivations/validations de clefs en cascade), des finesses protocolaires ou des procédures de sécurisation (dont, p.ex. les confidentialités/intégrités/authentifications des transactions).
Pour une vue plus complète, mais non technique, vous pouvez lire l'utilisation d'xVote (par le citoyen) et l'organisation d'xVote (point de vue de l'administration/politiciens). Pour une illustration, vous pouvez avoir sous les yeux le schéma général, et sa légende.

Les préparatifs d'un scrutin

Le responsable (magistrat ou haut fonctionnaire) responsable des votations certifie les clefs publiques des serveurs d'Habilitation et de Scrutation, il rassemble les observateurs politiques, ou scrutateurs (ou commission électorale, etc.). En leur présence, et celle d'un notaire, sur un poste informatique dédié (non connecté, isolé), la clef de l'Urne est générée; il s'agit d'une clef asymétrique, paire de clefs duales publique/privée. La partie publique de cette clef est utilisée pour chiffrer les bulletins, sur le poste de l'électeur, afin de préserver leur confidentialité jusqu'au dépouillement, où la clef privée sera utilisée pour les déchiffrer.
La partie publique de l'Urne est certifiée. La clef privée est décomposée une première fois entre le responsable du vote dans l'Administration publique et la commission politique, et cette deuxième partie est redécomposée (avec redondance et seuil de reconstruction) entre les diverses factions de la commission politique. Chacun reçoit son membre chiffré et sécurisé sur une carte électronique. La clef privée est effacée, et -de plus- le poste de création est scellé et remis au notaire, etc.
(NB : optionnellement, une copie intégrale de la clef privée peut être sauvegardée dans un support de sécuritép, remis au notaire sous scellé/signé par les membres de la commission politique).
Les clefs de serveurs certifiées, et la clef de l'Urne, sont transmises dans les serveurs. Je n'aborde pas ici le reste de la mise en place des sites serveur.
Pour mémoire, il y a deux principaux sites serveurs : l'Habilitation sous contrôle de l'administration publique et la Scrutation, celle-ci oeuvrant pour le compte de la commission politique. Il s'agit de centres informatiques distincts, avec des équipes séparées sous des autorités différentes. Il n'y a pas de connexions entre les deux sites, sauf pour l'envoi (push) des bulletins de la scrutation à l'Urne, et pour certaines transactions, précises et protocolées, en cas de résolution de réclamations.

Le vote d'un électeur

Soit l'électeur a téléchargé l'installateur de l'application de vote (depuis un site sécurisé, il est en possession de la trace du certificat de ce site), a déroulé cette installation gigogne et distribuée, et lance l'application de vote localement, soit il utilise le service de bureau déporté et lance directement l'application à distance.
L'application se contrôle et obtient les éléments du vote courant, qu'elle vérifie; elle s'apprête à entrer en contact avec le service d'Habilitation (autorisation de vote).
Un certain nombre d'opérations d'optimisation et de contrôle ont lieu, soit avec le chargement, soit avec le démarrage. Je ne rentre pas dans les détails.

L'identité numérique

Si le citoyen possède déjà une identité numérique, il s'authentifie simplement avec celle-ci.
Si l'électeur n'a pas (encore) d'identité numérique, il a reçu sa carte de vote (papier) par la poste et utilise les codes qui s'y trouvent pour s'authentifier (en les complétant par sa date de naissance et -pour les citoyens suisses- avec sa/une de ses commune[s] d'origine[s]); une identité numérique personnelle lui est alors délivrée, celle-ci est normalisée et peut être utilisée universellement.
Là aussi, je ne rentre pas dans le détail. Vous pouvez parcourir la phase 2 du diagramme du protocole simplifié.

L'obtention personnel du droit de vote

L'application entre en contact avec l'Habilitation et reçoit la carte de vote virtuelle pour le scrutin. Elle génère un jeton de droit de vote, l'anonymise et la joint à la carte de vote, et requiert du citoyen la signature électronique de celle-ci.
Le (logiciel du poste du) citoyen génère une clef d'électeur anonyme (une clef duale, ou asymétrique publique/privée, comme pour l'identité numérique), et masque la partie publique par une opération arithmétique (un produit arbitraire): Il envoie cette clef publique masquée à l'Habilitation. La carte de vote est explicite (en XML, avec nom, etc.), elle contient, avec les indications de scrutin, circonscription et droits de vote, cette partie clef publique masquée et désormais signée -avec les droits associés- par l'Habilitation.
La clef publique masquée, les éléments d'informations impersonnelles, tous signés par l'Habilitation. ainsi qu'un jeton anonyme (méreau) d'autorisation, la clef publique et le masque, sont envoyés à la Scrutation pour validation. La scrutation vérifiée le méreau, la cohérence de la clef publique avec le masque et sa version masquée, valide (selon la circonscription) la clef masquée en la signant, et mémorise la clef anonyme non masquée avec les informations impersonnelles (droits). La clef masquée validée est retournée au (poste du) citoyen.
L'application retourne la carte de vote complétée et signée à l'habilitation et reçoit le droit de vote validé par celle-ci, avec un bulletin de vote.
La carte de vote est complétée par la clef d'électeur anonyme masquée, la validation par la Scrutation, un élément de récupération. Le citoyen signe numériquement la carte (avec son identité certifiée) et l'envoie à l'Habilitation. L'Habilitation contrôle la cohérence, valide (signe) la clef publique masquée, et retourne celle-ci avec un bulletin de vote (dépendant de la circonscription et des droits de vote). Le bulletin (en XML) est explicite, complet avec tous les titres et intitulés.
Le (poste du) citoyen démasque la clef publique validée, la signature reste valide après ce démasquage. Il s'agit donc d'une signature en aveugle (par l'Habilitation).

Le dépôt anonyme du bulletin

Le citoyen complète le bulletin de vote dématérialisé selon ses choix. Lorsqu'il a fini, le droit de vote scelle le bulletin (garantie d'authenticité et intégrité) et le citoyen vérifie ses choix. Le bulletin scellé est chiffré sous la clef publique de l'Urne électronique et envoyé par un cheminement intraçable à l'Urne.
Le bulletin rempli est toujours littéral, il contient la totalité du texte (sémantiquement) que le citoyen a eu sous les yeux, et contient ses réponses intégrales. Le bulletin est en XML, et des règles de transformations associées (XSLT) le traduisent en XForm pour l'affichage/saisie et inversément pour la suite du traitement.
Le bulletin est signé avec la clef privée anonyme d'électeur, c'est l'équivalent de l'estampille des anciens bureaux de vote : une gommette signée par le président du bureau et compostée par le vice-président, attestant que le bulletin a bien été rempli par un électeur (anonyme) reconnu, qui l'avait reçue à son arrivée, après s'être présenté. Le bulletin signé est non seulement garanti authentique, mais aussi intègre - il ne peut être modifié sans invalider la signature. Le bulletin signé est alors chiffré sous la clef (publique) de l'Urne et envoyé à la Scrutation avec la clef publique anonyme d'électeur.
Comme pour les connexions précédentes au site serveur de la Scrutation, le renvoi du bulletin se fait au travers d'un surréseau d'intraçabilité (une chaîne de proxy cryptographiques, soit Tor, soit JonDoe, au choix) afin de masquer l'adresse IP du citoyen.
Outre le gite temporel induit par ce routage, la Scrutation attend un délai aléatoire avant de déposer le bulletin, complété avec les informations impersonnelles (droits), dûment numéroté et relié au précédent, signé par la Scrutation, dans l'urne de l'administration publique. L'administration ne peut se baser sur l'ordre des demandes d'Habilitation et celui de l'arrivée des bulletins pour en induire un lien.
Le citoyen reçoit un récépissé lui garantissant l'inclusion de son bulletin dans le scrutin (non probant pour un tiers, ce qui empêche la vente de voix).
Le (poste du) citoyen avait tiré une trace (hash) du bulletin signé/chiffré, cette trace est sauvegardée avec divers moyens de récupération. Seul le citoyen peut l'avoir extraite (à cause d'un suffixe arbitraire), mais cette trace n'est pas probante pour un tiers (le citoyen pourrait avoir choisi le suffixe de manière à valider aussi un bulletin rempli différemment -collision des valeurs de hachage).
La Scrutation a émis un premier récépissé, avec cette trace signée, immédiatement lors de la réception du bulletin, l'Urne en émet un autre (avec son numéro d'ordre), aussi signé par son serveur, lorsqu'elle reçoit le bulletin depuis la Scrutation. Cette dernière tient le récépissé de l'Urne à disposition du citoyen.

Le dépouillement du scrutin

Lors de la clôture du scrutin, la commission politique (le scrutateurs) prend connaissance des journaux du site serveur de scrutation (nombre d'estampilles, de bulletins, etc.) et se rend vers l'Urne. Avec le responsable des votations de l'administration, la commission politique reconstitue la clef privée de l'Urne et procède au déchiffrement (et vérification) des bulletins.
Les bulletins déchiffrés sont toujours littéraux (le texte exact avec les réponses intégrales), ils sont authentifiés et garantis intègres par les signatures des clefs privées anonymes d'électeurs, et vérifiables avec les clefs publiques correspondantes validées par l'Habilitation (et indirectement par le contrôle politique avec la signature du bulletin par la Scrutation). Les bulletins sont numérotés et chainés entre eux, et donc exhaustifs et complets. La liste des bulletins peut être valablement recomptée (vérifiées) par des tiers.
Le dépouillement final se fait par parcours direct des bulletins déchiffrés et validés, comme une base de données (textuelle), mais en XML (XQuery).

La résolution des réclamations et des contestations

Durant le scrutin, les réclamations sont intégralement résolvables, après le scrutin les contestations le sont aussi, et ce avec des éléments juridiquement probants
Avant la clôture, directement par une transaction, protocolée (sans évitement possible) et sans fuite d'information, entre l'Habilitation et la Scrutation; après la clôture -en cas de contestation individuelle- avec la participation obligatoire du citoyen (établissant sa bonne fois) dans une transaction triangulaire. Les journaux, horodatés et signés, ont relevé toutes les opérations (NB: l'information transitant par chaque serveur est insuffisante pour lever le secret du vote), certaines données sont notariées, etc.
Par ailleurs, le citoyen (mais seulement lui, avec la clef privée de sa capacité d'électeur anonyme, ou avec son identité numérique -donnant accès à ~) peut contrôler le bon contenu de son bulletin dépouillé, provenant de l'Urne et intégré dans le décompte.

Conclusions

Les subtilités protocolaire, l'ordonnancement des opérations et la syntaxe des objets, sont bien plus complexes que présentés ici. Pourtant, même résumé, c'est déjà bien assez long et je vous remercie d'être arrivé jusqu'ici !

Ce que cet aperçu montre, c'est qu'il est possible d'offrire une complète transparence, tant du programme (statique) que de l'exécution (dynamique), et ce à l'ensemble des citoyens. De plus, cette totale transparence a lieu tout en garantissant inconditionnellement le secret du vote. Un secret garanti en particulier grâce à la scission des opérations nominale (autorisation de vote) et anonyme (dépôt du bulletin) auprès de deux autorités distinctes, dont les informations qu'elles manipulent sont strictement partitionnées. Enfin, le citoyen peut à tout moment contrôler la bonne fin, et obtenir la résolution probante de ses réclamations ou contestation.

Les pilotes proposés actuellement à l'électorat n'ont, évidemment et de loin, rien de tout cela !
Outre une politique d'épais secret, si critiquée, et à cause d'une approche simpliste, les pilotes actuels ne remplissent pas la loi, la jurisprudence et les usages/doctrine du droit suisse (voir quelques commentaires en regard des critères légaux). Outre l'absence de contrôle démocratique (black box), aucun de ces pilotes ne protège inconditionnellement le secret du vote : pour chacun d'eux, l'administration publique (et tous ceux ayant accès aux serveurs) peut remonter du bulletin déposé à l'électeur. Des bulletins peuvent être supprimés, ajoutés, modifiés sans laisser de trace. Par ailleurs, les pilotes sont gravement vulnérables à une attaque du poste du votant (espionnage et manipulation du remplissage du bulletin), sans que cette attaque ne soit détectée.