← Tous les articles

Et si le logiciel changeait après avoir été testé ?

Le logiciel de vote a réussi tous les tests. Puis quelqu'un est entré dans un bureau électoral, a copié l'ensemble du système sur un disque dur, et s'en est allé. Que signifie « certifié » après cela ?

On est le matin du 7 janvier 2021, et une équipe d'experts en informatique judiciaire franchit la porte du bureau électoral du comté de Coffee, en Géorgie — laissée ouverte par des élus du comté qui avaient toutes les clés. Ce ne sont pas des enquêteurs. Ce ne sont pas des auditeurs. Ils passent les heures suivantes à copier tout : le serveur du système de gestion des élections, les machines de marquage des bulletins, le scanner haute vitesse, le logiciel de vote Dominion de Géorgie au niveau de l'État. L'ensemble du système. Ils repartent avec tout sur des disques durs.

Le système qu'ils ont copié avait été testé. Il avait été certifié. Il avait mené une véritable élection.

Rien de tout cela n'a arrêté ce qui s'est passé ensuite.

Ce que « certifié » certifie réellement

Avant que tout système de vote ne touche à un vrai bulletin, il passe par un processus de certification. Un laboratoire de test examine le matériel et le logiciel. Il vérifie que la machine fait ce que dit la documentation. Il émet un rapport. La juridiction accepte le système.

Cela semble rigoureux. Et pour un moment donné, c'est le cas.

Mais la certification est une photographie, pas une caméra de surveillance. Elle capture le système tel qu'il existait le jour où le laboratoire l'a examiné. Ce qui arrive à ce système entre le laboratoire et votre bureau de vote — et entre les élections — est une question entièrement différente, et elle reste largement sans réponse par le processus de certification lui-même.

L'écart critique est celui-ci : personne ne prouve régulièrement, d'une manière que le public peut vérifier de façon indépendante, que le logiciel qui s'exécute le jour de l'élection est le même logiciel qui a réussi le test.

Cet écart a un nom. On l'appelle le problème de l'échange de logiciel avant l'élection. Ce n'est pas théorique.

Coffee County : quand les clés tombent entre les mauvaises mains

L'incident de Coffee County, documenté dans les dépositions de l'affaire fédérale Curling c. Raffensperger et plus tard dans un acte d'accusation du comté de Fulton, est la démonstration la plus claire du monde réel de la raison pour laquelle le secret est une stratégie de sécurité fragile pour les logiciels électoraux.

L'intégrité du système reposait, en partie, sur l'hypothèse que seules les personnes autorisées y auraient accès. Cette hypothèse s'est effondrée au moment où un élu du comté a laissé l'équipe d'experts en informatique judiciaire entrer. Plusieurs personnes impliquées dans la violation ont ensuite plaidé coupable. Le bureau du secrétaire d'État de Géorgie l'a décrit comme un accès non autorisé en violation de la loi de l'État.

Mais voici la question qui persiste après les aveux de culpabilité : que faites-vous d'un système de vote dont le logiciel a été copié et se trouve maintenant quelque part que vous ne contrôlez pas ?

La réponse honnête, selon le modèle de certification actuel, est : pas grand-chose. Vous pouvez changer les mots de passe. Vous pouvez appliquer des correctifs aux systèmes. Vous pouvez affirmer, comme l'ont fait les élus, que la violation n'a pas affecté l'intégrité des élections ultérieures. Mais vous ne pouvez le prouver à personne qui n'est pas déjà enclin à vous faire confiance — car le système n'a jamais été conçu pour être indépendamment vérifiable en premier lieu.

Comme documenté dans l'affaire Curling, le témoignage d'experts présenté à la cour incluait des conclusions selon lesquelles une cyberattaque pourrait plausiblement échanger ou supprimer des votes et compromettre le système. La cour a jugé que le système de tabulation basé sur les codes QR « ne fournit pas un enregistrement de bulletin vérifiable et auditable car il s'appuie sur le code QR pour la tabulation des votes et ce code lui-même ne peut pas être lu et vérifié par l'électeur. » Un imprimé papier n'est pas un enregistrement vérifiable par l'électeur si l'imprimé encode le vote réel dans un code-barres qu'aucun humain ne peut lire.

La sécurité par l'opacité a échoué à Coffee County parce que l'opacité échoue toujours à la fin. Quelqu'un a toujours les clés.

Le problème plus profond : que se passe-t-il entre la certification et le jour de l'élection ?

Coffee County est la version dramatique d'un problème banal.

Les systèmes électoraux reçoivent des correctifs, des changements de configuration et des mises à jour logicielles tout au long de leur vie opérationnelle. Les vendeurs poussent des correctifs. Les comtés appliquent des mises à jour. Les cartes mémoire sont reprogrammées entre les élections. C'est une maintenance logicielle normale et raisonnable — et elle se produit presque entièrement hors de la vue du public.

L'examen de haut en bas de la Californie en 2007, au cours duquel des informaticiens de l'Université de Californie ont examiné le code source des systèmes de vote certifiés, ont trouvé des vulnérabilités graves dans chaque système qu'ils ont étudié — y compris les risques de logiciels malveillants qui pourraient se propager entre les machines. L'examen EVEREST de l'Ohio la même année, qui a étudié des systèmes certifiés de trois grands vendeurs, a conclu que tous possédaient des « défaillances critiques en matière de sécurité » et a noté que les journaux d'audit étaient couramment falsifiables ou effaçables par les personnes qu'ils étaient censés surveiller. C'étaient des systèmes certifiés, en utilisation active, examinés par des experts indépendants qui se sont vu donner accès au code source.

La leçon de la Californie et de l'Ohio est la même que celle de Coffee County : « c'était certifié » est le début de la question, pas la fin.

Le Bureau de la comptabilité générale des États-Unis a essentiellement fait ce point en 2005 — dans un rapport publié il y a plus de deux décennies — en constatant que les efforts fédéraux pour améliorer la sécurité des systèmes de vote étaient en cours mais « des activités clés restaient incomplètes », notamment l'établissement de dépôts de logiciels sécurisés et le partage d'informations sur les vulnérabilités. Certains de ces écarts se sont depuis réduits. Le problème structurel ne l'a pas.

L'expérience de Princeton, et pourquoi elle importe toujours

En 2006, les chercheurs de Princeton Ariel Feldman, J. Alex Halderman et Edward Felten ont obtenu une véritable machine Diebold AccuVote-TS — le type de machine utilisé partout aux États-Unis — et y ont eu accès physique pendant environ une minute. Ce qu'ils ont créé était un virus de vol de votes qui pouvait s'installer via la carte mémoire, modifier les totaux tout en gardant tous les enregistrements internes cohérents, et se propager d'une machine à l'autre pendant les opérations normales du jour de l'élection.

La machine était certifiée. Le logiciel avait réussi les tests.

L'article de Princeton a maintenant près de vingt ans, et les systèmes de vote ont changé. Mais la leçon structurelle n'a pas changé : si vous ne pouvez pas vérifier de façon indépendante que le logiciel qui s'exécute le jour de l'élection est le logiciel que vous avez inspecté, alors l'inspection n'établit pas grand-chose.

Un système certifié puis mis à jour, certifié puis corrigé, ou certifié puis copié n'est pas nécessairement le système que le laboratoire a testé. Et selon la plupart des cadres de certification actuels, il n'existe pas de mécanisme régulier, indépendant et public pour vérifier.

Les constructions reproductibles : la solution technique qui change la question

Il existe un concept d'ingénierie logicielle qui aborde cela directement. Il s'appelle une construction reproductible.

Voici l'idée en langage simple. Quand le logiciel est compilé — quand le code source lisible par l'humain est converti en binaire qui s'exécute réellement sur une machine — le processus produit généralement une sortie légèrement différente à chaque fois, selon les horodatages, les paramètres du compilateur et d'autres variables. Cela signifie que même si vous publiez votre code source, une partie indépendante qui le compile elle-même obtiendra un binaire qui ne correspond pas exactement au binaire s'exécutant sur la machine déployée. Vous ne pouvez pas vérifier, bit par bit, que le code en cours d'exécution correspond au code publié.

Une construction reproductible change cela. Quand une construction est reproductible, n'importe qui qui prend le code source publié et suit le processus de construction documenté obtient exactement le même binaire, octet par octet. Vous pouvez alors comparer un hash cryptographique du binaire sur la machine déployée au hash du binaire compilé indépendamment. S'ils correspondent, vous savez quel code s'exécute. S'ils ne correspondent pas, quelque chose a changé — et vous pouvez découvrir quoi.

Ce n'est pas de la science-fiction. Le projet Debian Linux poursuit les constructions reproductibles depuis 2013. Le navigateur Tor les atteint. Bitcoin Core les atteint. Ce sont des systèmes réels et déployés où les parties indépendantes peuvent confirmer que le binaire correspond au code source publié.

Pour le logiciel de vote, les constructions reproductibles signifieraient ceci : après toute mise à jour ou changement de configuration, la juridiction publie le hash binaire. N'importe qui — un journaliste, un chercheur, une campagne, un groupe de défense des électeurs — peut indépendamment compiler le code source et vérifier si le hash correspond. S'il ne correspond pas, c'est un fait public et falsifiable.

C'est ce que cela signifie de remplacer « faites-nous confiance » par « vérifiez par vous-même. » Pas un audit par des élus vérifiant leurs propres systèmes. Pas un instantané de certification. Une chaîne continue, indépendante et publiquement vérifiable du code source à la machine en cours d'exécution. En savoir plus sur cet écart et ce qu'une véritable solution ressemble.

Pourquoi le code source ouvert est nécessaire mais pas suffisant

Le système VSAP du comté de Los Angeles, certifié en 2018 en tant que premier système de tabulation électorale certifié en code source ouvert de Californie, est un développement véritablement positif. La propriété publique des logiciels de vote et le code source ouvert signifient que le processus de comptage peut être inspecté par des experts indépendants plutôt que caché en tant que secret commercial du vendeur.

Mais le code source ouvert résout seulement la première partie du problème : quelqu'un peut-il voir le code source ? Il ne répond pas par lui-même à la deuxième partie : le code sur la machine est-il le même que le code dans le dépôt ?

La Suisse a découvert cette limite en 2019. Swiss Post a publié le code source complet de son système de vote par internet pour examen public — un acte remarquable de transparence. Les chercheurs indépendants Sarah Jamie Lewis, Olivier Pereira et Vanessa Teague l'ont lu. Ce qu'ils ont trouvé était une trappe cryptographique : une autorité qui connaissait les valeurs secrètes pouvait générer une preuve de mélange qui réussissait la vérification mathématique alors qu'elle avait réellement modifié les votes. La faille était invisible dans une boîte noire certifiée. Elle devint détectable au moment où la source a été publiée et que les cryptographes indépendants regardèrent.

La publication a permis la détection. Mais la détection s'est produite parce que quelqu'un a regardé attentivement les preuves cryptographiques elles-mêmes — et a découvert que la preuve pouvait mentir.

La leçon : le code source ouvert est un préalable, pas une garantie. Les constructions reproductibles ajoutent la deuxième couche — en prouvant que le code que vous lisez est le code qui a s'exécuté. Et les audits cryptographiques indépendants ajoutent la troisième — en prouvant que même si le code s'exécutait correctement, sa conception ne permet pas la manipulation cachée.

Les trois sont nécessaires. La plupart des systèmes électoraux n'en ont aucun.

Ce que vous ne pouvez pas vérifier en ce moment, et ce qui le rendrait vérifiable

Voici l'état actuel des choses, énoncé clairement.

Quand une élection se termine et que les élus annoncent le résultat, vous êtes en position de vérifier certaines choses : vous pouvez vérifier si les totaux des bulletins papier du recompte manuel correspondent aux totaux des machines (comme l'a démontré le recompte manuel à l'échelle de l'État de Géorgie en 2020, à environ un dixième de pour cent près). Vous pouvez examiner les journaux de chaîne de garde des bulletins papier. Vous pouvez observer le décompte.

Ce que vous ne pouvez pas vérifier — dans la plupart des juridictions, par aucun mécanisme actuellement disponible au public — c'est si le logiciel qui a tabulé ces bulletins était le logiciel que le laboratoire de test a examiné, ou s'il a été modifié à un moment quelconque entre la certification et le jour de l'élection.

Vous faites confiance à une chaîne que vous ne pouvez pas voir.

La solution n'est pas mystérieuse. Elle exige :

  1. Des constructions reproductibles, afin que le binaire sur chaque machine puisse être vérifié indépendamment par rapport au code source publié.
  2. Des valeurs de hash publiées, signées et horodatées, chaque fois que le logiciel ou la configuration est mise à jour — avant toute élection que ce logiciel touchera.
  3. Des audits de compilation indépendants, où les parties extérieures au vendeur et à l'autorité électorale compilent le code eux-mêmes et vérifient que les hashes correspondent.
  4. Des bulletins papier que l'électeur peut lire, afin que, quoi que fasse ou ne fasse le logiciel, il existe un artefact indépendant — marqué par l'électeur, lisible par un humain, comptable à la main — qui peut régler la question.

Ce dernier point importe le plus quand les trois premiers échouent. Le recompte manuel de Géorgie en 2020 a confirmé le résultat de la machine à environ un dixième de pour cent précisément parce que des bulletins papier existaient qui ont été marqués par les électeurs et lisibles sans logiciel. La préoccupation du tribunal de Curling concernant le système QR de Géorgie était exactement que l'imprimé papier encode le vote tabulé sous une forme qu'aucun humain ne peut lire sans une machine — ce qui signifie qu'un « recompte manuel » de ces bulletins est en réalité un nouveau scan, faisant confiance à nouveau à la même chaîne logicielle.

Le papier ne suffit pas si le papier ne peut pas être lu. Le logiciel ne suffit pas s'il ne peut pas être vérifié. Le seul système qui est résilient contre un échange de logiciel est celui où le enregistrement marqué par l'électeur, lisible par un humain, est à la fois l'entrée du décompte et le contrôle indépendant du logiciel qui le compte.

Aucune assurance du secrétaire d'État ne change cela. Aucun communiqué de presse « l'audit a confirmé les résultats » n'y répond. La question est de savoir si quelqu'un en dehors du système peut vérifier indépendamment ce qui s'est exécuté. En ce moment, dans la plupart des endroits, la réponse est non.

La vérité partageante

La certification vous dit que le logiciel a réussi un test une fois. Elle ne vous dit pas que le logiciel qui s'est exécuté le jour de l'élection est le logiciel qui a été testé. Cet écart n'est pas une conspiration — c'est un problème d'ingénierie avec une solution connue. Les juridictions qui construisent pour la vérifiabilité n'ont pas besoin que vous les fassiez confiance. C'est tout l'intérêt.

Explorer l'écart d'échange de logiciel en détail | Voir la fréquence des écarts d'intégrité dans le monde | La version de deux minutes

Sources

Voir tous les articlesExplorer les lacunes