← Tous les articles

Vote ouvert : nécessité, non pas tendance

Le logiciel qui compte votre vote est un secret — et les responsables qui vous demandent de leur faire confiance n'ont aucun moyen de prouver qu'il fonctionne comme prévu.

Le 7 janvier 2021 — le matin après l'invasion du Capitole — une équipe de médecine légale informatique est entrée dans le bureau des élections du comté de Coffee, en Géorgie, et en est repartie avec une copie de tout. Le système de gestion électorale. Les appareils de marquage de bulletins. Le logiciel Dominion à l'échelle de l'État. Tout, gravé sur des disques et emporté à la porte.

Le système de vote du comté de Coffee avait été traité comme un secret digne de protection. Cacher le code, sécuriser les machines, faire confiance aux responsables. Cette stratégie s'est effondrée au moment où quelqu'un ayant une clé a décidé que les règles ne s'appliquaient pas à lui.

Le secret n'est pas la sécurité. Coffee County l'a prouvé. Mais il y a une leçon plus profonde cachée sous le gros titre — et elle s'applique que quelqu'un fasse irruption ou non.

Le problème avec le code secret, c'est que personne ne peut le vérifier

Quand une machine de vote exécute un logiciel propriétaire, seules les personnes qui peuvent lire ce code sont le fournisseur et, parfois, une petite équipe de testeurs approuvés par le gouvernement qui signent des accords de confidentialité. Vous ne pouvez pas le lire. Votre commissaire du comté ne peut pas le lire. Le secrétaire d'État qui le certifie ne peut probablement pas le lire.

Ce que tout le monde obtient à la place, c'est une promesse : nous l'avons testé, c'est bon, faites-nous confiance.

Ce n'est pas un modèle de sécurité. C'est un arrangement commercial.

Les chercheurs de Princeton qui ont démonté une machine Diebold AccuVote-TS en 2006 — le même type d'écran tactile déployé auprès de millions d'électeurs américains — ont découvert que le logiciel pouvait être subverti en environ une minute avec une carte mémoire. Non seulement altéré : subverti d'une manière qui réécrivait chaque journal et compteur pour rester cohérent en interne, ne laissant aucune trace détectable. Le code pouvait même se propager lui-même à d'autres machines lors des transferts normaux de la nuit électorale. Les chercheurs ont publié cela parce qu'ils avaient la machine. Ils pouvaient lire le logiciel. La plupart des gens n'ont jamais cette chance.

L'AccuVote-TS n'était pas une exception. C'était une fenêtre — brièvement ouverte — sur des systèmes normalement verrouillés.

Et voici la question inconfortable : si c'est ce qu'une analyse indépendante a trouvé en une semaine, qu'est-ce qui pourrait persister non détecté dans des systèmes qui n'ont jamais été examinés publiquement ? Nous n'avons aucun moyen de le savoir. C'est tout le problème.

« Nous l'avons audité » est une affirmation, non une conclusion

Les responsables aiment dire que les audits après élection confirment les résultats. Parfois c'est vrai. Souvent c'est plus compliqué.

Au comté d'Antrim, au Michigan, en novembre 2020, des résultats officieux erronés ont été publiés. Non pas légèrement décalés — des milliers de votes dans la mauvaise colonne. L'erreur a été détectée, mais pas par un mécanisme de sécurité interne. Elle a été détectée parce que le résultat était absurdement invraisemblable pour un comté que tous savaient fortement républicain. Une erreur plus subtile, dans un comté plus serré, aurait pu passer inaperçue.

Ensuite, en décembre, les responsables ont effectué un recompte manuel complet de chaque bulletin présidentiel pour vérifier le total révisé des machines. Le recompte manuel a montré un écart de douze voix par rapport au total des machines sur environ 15 700 bulletins exprimés. Douze voix.

Dans une course unilatérale, douze voix, c'est une erreur d'arrondi. Mais voici le problème : dans une vraie course serrée — décidée par cinquante voix, ou vingt, ou cinq — un recompte manuel qui est lui-même décalé d'une douzaine de voix ne peut rien résoudre. Il ne peut pas. Pas mathématiquement. L'audit manuel « étalon-or » porte sa propre erreur humaine irréductible : des marques ambiguës, la fatigue à 2 h du matin, des appels d'arbitrage contestés rendus différemment par différentes paires de mains.

Quand le Michigan Department of State a dit que l'audit « confirmait l'exactitude », c'était une assurance. Ce n'était pas une preuve. L'écart de douze voix ne disparaît pas parce qu'un responsable tient une conférence de presse.

L'argument réel ici n'est pas que quelqu'un a triché. L'argument est que « le secrétaire d'État dit que c'est bon » et « un recompte manuel l'a confirmé » sont des substituts à la vérifiabilité indépendante — et les substituts ne sont pas la vraie chose.

Ce que le code ouvert signifie réellement pour un système de vote

Les gens entendent « vote en code ouvert » et imaginent des hackers invités à paralyser l'élection. C'est la mauvaise image.

Le code ouvert signifie que le code source du logiciel — chaque instruction que la machine exécute — est publié où n'importe qui peut le lire. Les chercheurs en sécurité. Les universitaires. Votre neveu qui a suivi deux cours de programmation. D'autres fournisseurs. Les journalistes. Les groupes de surveillance indépendants. N'importe qui.

C'est important pour une raison qui semble presque trop simple : vous ne pouvez pas cacher une porte dérobée dans du code que tout le monde peut lire. Ou plutôt, vous pouvez essayer, mais la probabilité de détection s'effondre à mesure que le nombre de lecteurs indépendants augmente.

La recherche moderne sur les votes cryptographiques va plus loin. Le code ouvert est la fondation, mais la structure construite dessus est ce qui transforme « vous pouvez le lire » en « vous pouvez le prouver ».

Voici comment les pièces s'assemblent :

Le code source public signifie que n'importe qui peut inspecter ce que le logiciel est censé faire. C'est l'étape un, mais seulement l'étape un — parce que le code que vous compilez et le code réellement exécuté sur une machine peuvent être des choses différentes.

Les compilations reproductibles comblent cet écart. Si le processus de compilation d'un système de vote est reproductible, cela signifie que quiconque prend le code source publié et suit les étapes publiées arrivera à un binaire — le fichier exécutable réel de la machine — qui est bit-à-bit identique au binaire exécuté sur les machines certifiées. Vous pouvez vérifier le hash. S'il correspond, la machine exécute ce qu'elle dit exécuter. S'il ne correspond pas, vous le savez immédiatement, sans faire confiance à la parole de quiconque.

Une couche d'intégrité cryptographique va encore plus loin. Des techniques comme le vote vérifié de bout en bout (E2E-V) permettent à chaque électeur de recevoir un reçu qui lui permet — et à quiconque d'autre — de confirmer que son bulletin a été exprimé comme prévu, enregistré tel qu'exprimé, et compté tel qu'enregistré, sans révéler pour qui il a voté. Les mathématiques sont publiques. La vérification est publique. Le résultat ne nécessite de faire confiance à aucun responsable, aucun fournisseur, ni aucun auditeur.

Ensemble, ces trois couches changent la question de « faites-vous confiance au fournisseur ? » à « pouvez-vous vérifier les mathématiques vous-même ? »

Ce changement, c'est tout.

Pourquoi Coffee County prouve que le secret est la mauvaise stratégie

Revenons un moment à Coffee County, parce que la leçon n'est pas tout à fait ce que la plupart des articles ont suggéré.

La violation a été traitée principalement comme une histoire de sécurité de la garde : des personnes non autorisées ont accédé à un système auquel elles n'étaient pas censées accéder. Vrai. Mais sous cette histoire se trouve une hypothèse structurelle qui a rendu la violation si conséquente en premier lieu.

Le modèle de sécurité du système dépendait du maintien du logiciel secret.

Si le logiciel avait été en code ouvert, « ils ont obtenu une copie du code » serait considérablement moins alarmant — parce que n'importe qui aurait pu avoir une copie du code. L'intégrité de l'élection ne reposerait pas sur le maintien du code caché. Elle reposerait sur les mathématiques : les engagements cryptographiques, les journaux d'audit publics, les dossiers vérifiables que n'importe qui pouvait vérifier et que personne ne pouvait discrètement modifier.

Ce que les gens qui sont entrés dans ce bureau ont pris était propriétaire. Sa valeur en tant que prix dépendait entièrement du fait qu'il soit un secret. Un système construit pour la transparence et la preuve de manipulation n'aurait pas remis entre leurs mains presque autant.

La reconstruction de Lawfare de l'épisode Coffee County vaut le coup d'être lue en entier. Les rapports du Atlanta Journal-Constitution ajoutent des détails supplémentaires sur ce qui a été copié et comment cela s'est propagé. Ensemble, ils illustrent un principe que les professionnels de la sécurité comprennent depuis des décennies : les systèmes qui reposent sur l'obscurité sont fragiles exactement de la manière qui compte le plus.

Le problème des compilations reproductibles n'est pas théorique

« Les compilations reproductibles » semble être une question d'entretien du développement logiciel. Ce n'est pas le cas.

Voici le problème concret qu'il résout. Imaginez qu'un fournisseur de machines de vote publie son code source. Les journalistes et les chercheurs le lisent. Semble correct. Le laboratoire de certification le teste. Réussit. Le secrétaire d'État le certifie.

Maintenant imaginez que quand le fournisseur compile ce code dans le binaire qui s'exécute réellement sur les machines, il apporte une petite modification. Pas dans la source publiée — à l'étape de compilation. Une seule instruction différente. Le binaire sur chaque machine déployée diffère du binaire que n'importe qui a audité, d'une manière qu'aucune vérification papier post-élection ne détectera, d'une manière qu'un audit limité en risque ne détectera pas, d'une manière qu'un recompte complet ne détectera pas à moins que le dossier papier lui-même n'ait été compromis.

Vous ne pouvez pas détecter cela sans compilations reproductibles. Avec elles, vous pouvez : compiler la source vous-même, comparer le hash, et savoir. Instantanément. Sans faire confiance à quiconque.

Ce n'est pas un scénario hypothétique construit à des fins rhétoriques. L'attaque de la chaîne d'approvisionnement contre SolarWinds — qui n'avait rien à voir avec les élections mais tout à voir avec le principe — a montré que les acteurs sophistiqués peuvent modifier le logiciel à l'étape de compilation, laissant le code source qui semble propre tout en déployant des binaires qui ne le sont pas. La même surface d'attaque existe dans le logiciel de vote partout où les compilations ne sont pas indépendamment reproductibles.

Aucun système de vote américain actuellement déployé à grande échelle n'offre de compilations indépendamment reproductibles que n'importe quel membre du public peut vérifier. Cet écart est réel. Il est mesurable. Et il n'est pas comblé par aucun responsable vous disant que le système a été testé.

Voir comment cet écart se compare d'un bout à l'autre des juridictions mondiales →

Ce que « vérifiable » signifie réellement — et ce qu'il ne signifie toujours pas

Il vaut la peine d'être précis ici, car « vérifiable » est utilisé de manière imprécise.

Un audit limité en risque, comme celui que le Colorado a lancé en 2017 ou la Géorgie a déployé à l'échelle de l'État en 2020, est une véritable amélioration par rapport aux contrôles aléatoires à pourcentage fixe. L'examen manuel des bulletins de papier donne une confiance statistique que le comptage des machines est correct — si le papier est digne de confiance et si l'échantillonnage est véritablement aléatoire.

Ce sont de vrais « si ». Mais même un RLA parfait ne vérifie que si le papier et les machines étaient d'accord. Il ne vous dit pas si le logiciel qui a exécuté ces machines était ce qu'il prétendait être. Il ne vérifie pas l'étape de compilation. Il ne permet pas à un électeur de confirmer que son bulletin spécifique a été inclus et compté. Il confirme le total par rapport au papier ; il ne rend pas le logiciel lui-même vérifiable.

Un système en code ouvert, avec compilations reproductibles et vérifiable de bout en bout, ne remplace pas les audits. Il donne aux audits quelque chose de solide sur quoi se tenir.

La hiérarchie ressemble à ceci :

  • Logiciel fermé et propriétaire : faire confiance entièrement au fournisseur
  • Code ouvert seulement : faire confiance qu'aucun n'a inséré quelque chose de malveillant dans la compilation
  • Code ouvert + compilations reproductibles : faire confiance que le code publié et le binaire exécuté correspondent, vérifiable indépendamment
  • Code ouvert + compilations reproductibles + vérifiabilité E2E : faire confiance aux mathématiques, pas aux gens

Chaque couche supprime une autre chose à laquelle vous devez avoir confiance. L'objectif n'est pas la perfection. L'objectif est de rendre la question « cela a-t-il fonctionné correctement ? » répondable par n'importe qui ayant un ordinateur et du temps pour vérifier — pas seulement par des responsables ayant un intérêt à dire oui.

La vérité partageable

Voici la ligne qui vaut la peine d'être capturée :

« Chaque fois qu'un responsable électoral dit « faites-nous confiance, nous l'avons audité », il vous demande de faire confiance aux auditeurs. L'objectif du vote vérifiable est que vous ne deviez pas avoir à le faire. »

Les cas dans cet article — le code qui ne pouvait pas être vérifié, les résultats qui étaient faux jusqu'à ce qu'ils soient manifestement faux, le logiciel copié du bureau d'un comté sur un disque dur — ne sont pas des arguments selon lesquels les élections sont truquées. Ce sont des arguments selon lesquels le modèle actuel demande un niveau de confiance que l'architecture ne peut justifier.

Les pistes papier aident. Les audits aident. Mais ce n'est pas suffisant si le logiciel générant les résultats est une boîte noire, si les binaires exécutés sur les machines ne peuvent pas être vérifiés indépendamment par rapport au code source public, et si les électeurs n'ont aucun moyen mathématique de confirmer que leur bulletin a été compté.

Qu'est-ce qui rendrait cela vérifiable par n'importe qui ? Trois choses, actuellement non résolvées dans la plupart des juridictions américaines :

  1. Le code source public complet pour chaque système de vote — non pas du code disponible sous NDA, mais véritablement public
  2. Les compilations reproductibles avec des hashes publiés que n'importe qui peut vérifier
  3. Les reçus cryptographiques de bout en bout pour que les électeurs individuels puissent auditer l'inclusion de leur propre bulletin

Jusqu'à ce que ces trois choses existent, « l'audit a confirmé cela » est une déclaration sur ce que les responsables ont trouvé quand ils ont regardé. Ce n'est pas une déclaration que n'importe qui en dehors de la salle peut vérifier indépendamment.

Ce n'est pas une théorie du complot. C'est une exigence d'ingénierie.

Lire la version 2 minutes de ces écarts → Voir quels systèmes et juridictions ont des écarts de source secrète aujourd'hui → Explorez les défaillances de compilation reproductible dans l'atlas des écarts →

Sources

Voir tous les articlesExplorer les lacunes