← Tous les articles

Le vote open-source est nécessaire — mais ce n'est toujours pas suffisant. Voici le reste.

Le comté de Los Angeles a passé une décennie à construire le système de vote le plus transparent du monde — open-source, propriété publique, indépendamment auditable. La Suisse a fait la même chose. Les chercheurs ont quand même trouvé une porte dérobée cachée. Voici ce que les deux cas ont manqué.

Nous sommes le 21 août 2018, et un officiel de l'État de Californie se tient devant un microphone sur le point de dire quelque chose qui n'a jamais été dit auparavant dans l'histoire de l'État : le comté de Los Angeles vient de voir son système de dépouillement certifié — et pour la première fois, le logiciel qui compte les votes appartient au public.

Pas à un fournisseur. Pas à une entreprise privée protégée par la loi sur les secrets commerciaux. Au public.

Le système s'appelle VSAP — Voting Solutions for All People. Il a fallu des années et des dizaines de millions de dollars pour le construire. Il a été conçu de zéro pour servir la plus grande juridiction électorale des États-Unis, remplaçant des machines propriétaires obsolètes. Et son code source — les instructions réelles qui disent à l'ordinateur comment compter votre vote — a été publié pour que chacun puisse le lire.

C'est, franchement, une étape importante. Et c'est toujours insuffisant.

Cet écart — entre le code ouvert et le dépouillement vérifié — est le sujet de cet article.

Pourquoi le code source secret a toujours été la mauvaise réponse

Pour comprendre pourquoi VSAP est important, il faut comprendre ce qu'il a remplacé.

Pendant des décennies, le logiciel qui comptait les votes américains était un secret commercial. Les fournisseurs arguaient que leur code était une propriété intellectuelle propriétaire. Les responsables électoraux devaient prendre leur parole sur le fait que les machines fonctionnaient correctement. Les chercheurs qui ont obtenu des machines par d'autres moyens — comme l'équipe de Princeton qui a récupéré un Diebold AccuVote-TS et a passé quelques semaines avec en 2006 — ont découvert qu'ils pouvaient installer du code de vol de votes en moins d'une minute qui se propagerait machine par machine et altérerait tous les journaux internes pour rester cohérent. La machine rapporterait le dépouillement falsifié en toute confiance.

Le code était secret. La falsification était invisible.

Coffee County, en Géorgie en 2021, a montré l'autre côté de cette même épée : garder le code secret ne le garde pas en sécurité. Une équipe de criminalistique a été admise au bureau des élections et en est repartie avec une copie de tout le système de vote Dominion — le système de gestion des élections, les tablettes de sondage, les dispositifs de marquage des bulletins, le scanner, tout. Le secret comme stratégie de sécurité n'est aussi solide que le plus coopératif des initiés dans la pièce.

Le code open-source casse les deux de ces modes de défaillance. Vous ne pouvez pas cacher un virus de vol de votes dans du code que tout le monde peut lire. Vous n'avez pas besoin de voler le secret parce qu'il n'y en a pas.

Mais au moment où vous publiez la source, vous posez une nouvelle question. La question n'est plus « que dit le code ? » La question devient : « Le code qui s'exécute réellement le soir des élections est-il le même code qui se trouve sur GitHub ? »

Et cette question s'avère être très difficile à répondre.

La leçon suisse : code ouvert, faille cachée

En 2019, la Poste suisse et son fournisseur espagnol Scytl ont fait quelque chose qui ressemblait à l'étalon-or de la transparence. Ils ont publié le code source complet du système de vote par Internet de la Suisse avant l'utilisation prévue dans les votes fédéraux contraignants. Les chercheurs indépendants pouvaient lire chaque ligne.

Les chercheurs Sarah Jamie Lewis, Olivier Pereira et Vanessa Teague les ont pris au mot. Ce qu'ils ont trouvé à l'intérieur de la cryptographie n'était pas une faute de frappe. Ce n'était pas une bogue insouciante. C'était une trappe — une structure mathématique enfouie dans la preuve de mélange du mixnet qui permettait à quiconque tenait certaines valeurs secrètes de générer une transcription de vérification qui passerait chaque vérification tout en ayant altéré les votes en dessous.

Le système prétendait offrir une « vérifiabilité universelle ». Une preuve valide confirmerait que le mélange était correct. Mais si vous connaissiez les valeurs de la trappe, vous pouviez faire passer cette preuve pour un mélange qui n'était pas du tout correct.

Ils ont appelé leur rapport Ceci n'est pas une preuve — « This is not a proof. » La Poste suisse et Scytl ont reconnu la découverte. Les autorités suisses ont suspendu le système. Une décennie de travail, une version complète du code public — et la faille était toujours là, invisible jusqu'à ce que des cryptographes externes creusent les mathématiques.

Voici la leçon qui n'apparaît pas dans le communiqué de presse : le code open-source est nécessaire car il rend l'inspection indépendante possible. Il n'est pas suffisant car l'inspection doit réellement avoir lieu, par des personnes qualifiées pour trouver ce qu'elles cherchent, et ensuite les corrections doivent être vérifiablement appliquées.

Publier le code est le début de l'histoire, pas la fin.

Le problème de la reproductibilité : du code à la machine en fonctionnement

Rendons cela concret. Imaginez que vous êtes un membre du conseil municipal du comté de Los Angeles. Vous pouvez lire le code source VSAP. Vous le trouvez propre. Vous êtes satisfait que le code soit correct.

La nuit électorale arrive. Quelque part dans un entrepôt, une machine s'éveille et commence à compter les bulletins.

Comment savez-vous que la machine exécute le code que vous avez lu ?

L'écart entre « code source » et « logiciel en fonctionnement » s'appelle le processus de compilation. Le code source est un texte lisible par les humains. Un ordinateur exécute du binaire compilé — des instructions machine qu'un compilateur produit à partir de ce texte. Le processus de compilation n'est pas automatique, évident ou vérifiable à l'œil nu. Il implique des choix : quelle version du compilateur, quels drapeaux, quelles dépendances, dans quel ordre.

Si deux personnes compilent le même code source à l'aide de compilateurs différents, elles produisent souvent des binaires différents. Et si les binaires sont différents, vous ne pouvez pas dire en les regardant si la différence est innocente (un paramètre d'optimisation différent) ou malveillante (une instruction ajoutée).

Ce n'est pas une préoccupation théorique. Elle a été décrite avec une précision mortelle dans la conférence du Turing Award de Ken Thompson en 1984, « Reflections on Trusting Trust ». Thompson a montré que vous pouviez insérer une porte dérobée dans un compilateur qui ajouterait invisiblement du code malveillant à tout programme qu'il compilerait — y compris les futures versions du compilateur lui-même — sans laisser de trace dans aucun code source que quelqu'un puisse lire.

La solution, développée au cours de la dernière décennie dans le monde des logiciels libres, s'appelle les builds reproductibles. L'idée : si un processus de compilation est déterministe — mêmes entrées, mêmes sorties, à chaque fois — alors n'importe quel tiers indépendant peut compiler la même source et comparer l'empreinte numérique du binaire par rapport à ce qui est réellement installé sur la machine. Si les empreintes correspondent, la machine exécute ce que le code dit.

Si elles ne correspondent pas, quelque chose a changé entre le code et la machine. Ce n'est pas une préoccupation philosophique. C'est une défaillance de sécurité.

Nous avons couvert cela plus en détail dans notre article sur les builds reproductibles. Version courte : sans eux, « open source » signifie « vous pouvez lire la recette ». Cela ne signifie pas « ce qui est sorti du four est ce que la recette décrit ».

L'architecture open-source de VSAP est un véritable progrès. Mais l'open-source sans un processus de compilation documenté et reproductible laisse un écart qu'aucun audit du code source ne peut combler.

L'attestation : prouver que la machine est la machine

Les builds reproductibles vous disent si un binaire correspond à la source. L'attestation est l'étape qui lie une machine spécifique à un binaire vérifié spécifique à un moment spécifique dans le temps.

Pensez-y comme une chaîne de signatures. La juridiction certifie un binaire. Le binaire est signé cryptographiquement. Lorsque la machine s'amorce le jour des élections, elle mesure son propre état logiciel et génère un rapport signé — une « mesure » — qui peut être vérifiée par rapport à la valeur certifiée. Si quelque chose a été modifié, la mesure ne correspondra pas. Ce n'est pas exotique ; c'est déjà ainsi qu'un smartphone moderne protège son processus de démarrage.

Dans la pratique actuelle des systèmes électoraux, l'équivalent est un hachage — une empreinte numérique — qui est censé être vérifié par rapport à la version certifiée avant le déploiement. Mais « censé être » porte beaucoup de poids dans cette phrase. Les vérifications sont souvent manuelles, peu fréquentes, ou font confiance à une chaîne de contrôle qui peut elle-même avoir des lacunes.

Considérez ce qui s'est passé à Coffee County : l'ensemble du logiciel du système a été copié et distribué par des personnes ayant un accès physique légitime au bureau. Les systèmes ont réussi leurs vérifications pré-électorales. Une comparaison de hachage après coup vous dirait si le binaire a changé sur la machine qui est restée au bureau. Elle ne vous dirait pas ce qui a été fait avec la copie qui a quitté.

L'attestation ne résout pas seule le problème des menaces d'initiés. Mais cela signifie que chaque machine, au démarrage, peut être invitée à prouver ce qu'elle exécute — et la réponse peut être vérifiée par rapport à un registre public avant qu'un seul vote ne soit comptabilisé.

La chaîne de contrôle : la couche physique que le code ne peut pas remplacer

Voici à quoi ressemble un système open-source entièrement auditable à 2 h du matin le soir des élections : une carte mémoire sort d'un tabulateur, va dans un sac scellé signé par des observateurs de plusieurs partis, est enregistrée dans un registre, transportée par deux personnes qui ne sont pas du même parti, et arrive à une installation centrale où son sceau est vérifié avant que les données ne soient lues.

Et voici à quoi ressemble quand cette chaîne se brise : la Cour constitutionnelle autrichienne en 2016 a annulé un ballottage présidentiel — non parce que la fraude a été trouvée, mais parce que dans plusieurs districts, les bulletins de vote par correspondance avaient été ouverts et comptabilisés par des personnes non autorisées en dehors de la fenêtre légalement requise, sans les témoins requis. Environ 77 000 votes ont été affectés par des violations procédurales prouvées, ce qui a dépassé la marge gagnante de 30 000 votes. La cour n'a trouvé aucune fraude. Elle a quand même annulé l'élection, parce que les procédures qui auraient rendu la fraude détectable n'avaient pas été suivies — et une manipulation non détectée est indiscernable d'une manipulation non détectée.

La même logique s'applique à une machine de vote avec un code open-source parfait et une compilation reproductible. Si la carte mémoire contenant les résultats est manipulée par une seule personne sans témoins avant d'arriver au dépouillement, la chaîne de contrôle est brisée. L'exactitude du code est sans pertinence. Vous ne pouvez pas prouver que la carte contient la sortie que la machine a produite.

La chaîne de contrôle physique n'est pas une procédure héritée que la technologie remplace. C'est l'ancre qui connecte le monde logiciel au monde physique. Sans elle, une preuve cryptographique parfaite du dépouillement flotte librement, détachée de tout bulletin physique que quelqu'un peut revérifier.

Les audits : la vérification qui ferme la boucle

La Cour constitutionnelle fédérale allemande a énoncé le principe aussi clairement que n'importe quelle cour l'a fait : les étapes essentielles d'une élection doivent être « examinables par le citoyen de manière fiable et sans aucune connaissance spécialisée ». La Cour a dit cela en 2009, annulant l'utilisation des ordinateurs de vote Nedap à l'élection fédérale de 2005. Les machines ne stockaient les votes que dans la mémoire électronique. Aucun dossier indépendamment vérifiable. Aucune vérification qu'un non-expert puisse effectuer. La cour a trouvé cela inconstitutionnel — indépendamment du fait que les machines aient jamais mal fonctionné.

Le code open-source satisfait partiellement cette exigence pour les citoyens techniquement alphabétisés. Un audit cryptographiquement vérifiable la satisfait pour tous.

L'audit de recomptage manuel de l'État de Géorgie en 2020 — environ 5 millions de bulletins présidentiels, examinés par 159 comtés en moins de six jours — a confirmé le dépouillement des machines à environ un dixième de pour cent près. C'est un résultat significatif. Un bulletin de vote papier que l'électeur a marqué à la main, compté par une personne que l'électeur aurait pu en principe regarder, vérifié par rapport à un total de machine : c'est une chaîne qu'un citoyen ordinaire peut tracer sans diplôme en cryptographie.

Mais même cette chaîne a ses limites. Le Colorado a mené le premier audit électoral à risque limité à l'échelle de l'État en 2017, offrant une confiance statistique que le résultat rapporté était correct. Un audit à risque limité est plus rigoureux qu'une vérification à pourcentage fixe : il échantillonne plus de bulletins dans les courses serrées, moins dans les victoires écrasantes, et fournit une probabilité définie qu'un résultat erroné aurait été détecté. Le Colorado continue à resserrer son risque limité. C'est la direction de la progression.

La leçon de tous les deux : un audit ne fonctionne que s'il y a quelque chose de digne de confiance à auditer. Un bulletin de vote papier qu'un électeur a marqué et a pu inspecter est digne de confiance. Un code QR que l'électeur ne peut pas lire — que une cour fédérale a trouvé dans Curling v. Raffensperger « ne fournit pas un dossier de bulletin vérifiable et auditable » parce que le code lui-même tabule le vote et l'électeur ne peut pas le vérifier — n'est pas une piste d'audit. C'est une machine qui se fait confiance à elle-même.

Open-source + builds reproductibles + attestation + chaîne de contrôle converge vers ceci : un dossier durable, lisible par les humains que l'électeur a personnellement vérifié, que n'importe quel tiers indépendant peut recompter, et dont le chemin depuis la main de l'électeur jusqu'au dépouillement final est documenté à chaque étape par plusieurs partis ayant des intérêts conflictuels.

La liste de contrôle que personne n'a complètement remplie

Voici la liste réelle de ce que l'« open-source » vous donne et ce qu'il ne donne pas :

Ce que l'open-source vous donne :

  • La capacité pour les experts qualifiés de lire le code et de trouver des bogues ou des portes dérobées
  • La capacité de comparer la logique déclarée du dépouillement par rapport à ce qu'elle devrait faire
  • L'élimination des arguments de secret commercial qui bloquent la recherche en sécurité
  • Une base pour les builds reproductibles et l'audit communautaire

Ce que l'open-source ne vous donne pas :

  • La preuve que le binaire en exécution correspond à la source (nécessite les builds reproductibles)
  • La preuve qu'une machine spécifique exécute le binaire certifié (nécessite l'attestation)
  • La preuve que les résultats n'ont pas été altérés entre la machine et le dépouillement (nécessite la chaîne de contrôle)
  • La preuve que le dépouillement reflète les bulletins papier dans la boîte (nécessite des audits par rapport à un dossier papier vérifié par l'électeur)

La Suisse a publié sa source et a quand même caché une trappe — non parce que la publication était inutile, mais parce que la publication sans examen prolongé, expert et contradictoire a laissé le piège sans être déclenché trop longtemps. Le comté de Los Angeles a publié sa source et mérite le crédit. La question pour la prochaine décennie est de savoir si chaque comté qui utilise VSAP peut vérifier indépendamment que le binaire sur chaque machine correspond à ce que la source dit, et que chaque carte mémoire a voyagé une chaîne ininterrompue de la machine au dépouillement.

La transparence n'est pas un moment unique. C'est un processus qui s'exécute du référentiel de code source au sac scellé sur la table à 2 h du matin.

Ce qui rendrait réellement cela vérifiable

Si vous vouliez construire un système où n'importe quel tiers indépendant — pas seulement un officiel, pas seulement un fournisseur — pourrait vérifier la chaîne entière du code au résultat certifié, il ressemblerait à ceci :

Un : Code source publié dans un référentiel versionné et immuable avec un hachage cryptographique pour chaque version.

Deux : Un processus de compilation documenté et scripté que n'importe quel tiers peut reproduire, produisant un binaire dont le hachage correspond au hachage certifié.

Trois : Attestation pré-électorale : chaque machine, avant de traiter un bulletin, génère une mesure signée de son propre état logiciel. Cette mesure est vérifiée par rapport au hachage certifié et enregistrée publiquement.

Quatre : Dossiers papier vérifiés par l'électeur — des bulletins que l'électeur a personnellement inspectés qui reflètent des choix lisibles par les humains, pas des codes-barres que l'électeur ne peut pas lire.

Cinq : Audits de routine à risque limité qui échantillonnent les bulletins papier par rapport aux dépouillements des machines, dimensionnés à la marge de la course, menés par des observateurs de plusieurs partis, avec les résultats publiés au niveau du scrutin.

Six : Résultats lisibles par machine, au niveau du scrutin, publiés au moment où ils sont certifiés — pas après coup, pas dans un format nécessitant une demande d'accès à l'information, mais dans un fichier .csv ou .xml que n'importe qui peut télécharger et rapprocher des bandes de scrutin.

Aucune de ces étapes n'est exotique. Elles existent toutes quelque part dans la pratique actuelle. Aucune juridiction n'a implémenté l'ensemble d'entre elles d'un bout à l'autre, avec vérification indépendante à chaque lien.

C'est l'écart. Pas « open-source vs. source fermée ». L'écart est entre publier le code et rendre la chaîne entière — du code source à la machine à la machine au bulletin au dépouillement — indépendamment vérifiable par quiconque veut vérifier.

Jusqu'à ce que cette chaîne soit complète et publique, « open-source » est une amélioration nécessaire. Ce n'est pas une réponse achevée.

Voir comment cet écart apparaît dans les juridictions du monde entier →

Lisez la version de 2 minutes sur pourquoi l'open-source est nécessaire mais pas suffisant →

Explorez les écarts spécifiques dans les builds reproductibles et l'attestation →

Sources

Voir tous les articlesExplorer les lacunes