Author: Olivier Pereira

Le test d’intrusion que Swiss Post a organisé pour son système de vote, est arrivé à sa fin ce dimanche 24 mars.

Suites de la découverte d’une trappe dans sVote.

Il y a deux semaines, Sarah Jamie Lewis, Vanessa Teague et moi annoncions l’existence d’une trappe dans l’un des mécanismes que le système sVote utilise pour prouver que l’intégrité des votes a été préservée lors du processus de dépouillement — il s’agissait plus précisément d’une trappe dans la preuve de mélange des bulletins de vote, qui permettrait de modifier ces votes de manière indétectable.

La publication de cette trappe ne devait avoir de conséquence pour aucune élection: le système publié par Swiss Post n’a pas encore été utilisé.
Il est cependant apparu que le code dans lequel la trappe était présente, qui a été réalisé par la société Scytl, était déployé au même moment pour des élections dans l’état du New South Wales (NSW) en Australie, au travers du  système iVote dont le code n’est pas ouvert à l’examen public. La Commission électorale de l’état du NSW (NSWEC), a immédiatement déclaré que l’erreur avait été corrigée, à temps avant que le décompte n’ait lieu, et que l’élection ne serait pas affectée. Le NSW a ainsi pu bénéficier des effets de l’ordonnance de la Chancellerie fédérale suisse imposant le libre accès au code source de ses systèmes de vote (à partir d’un certain niveau d’usage), soulignant ainsi les avantages d’un débat public sur la sécurité de systèmes critiques.

Un nouveau problème

Nous faisons état aujourd’hui de notre découverte d’un second problème critique dans sVote, totalement indépendant du premier: il est possible d’invalider des bulletins de vote parfaitement valides, sans que les processus d’audit ne le détectent. A nouveau, le problème se situe dans les mécanismes de preuve d’intégrité des bulletins de vote du protocole sVote, qui permettent cette fois à une machine en charge du déchiffrement des bulletins de vote d’invalider un nombre quelconque de bulletins, tout en apportant toutes les preuves requises par le système. Notre rapport montre en effet qu’il est possible de falsifier les preuves de correction des opérations de déchiffrement utilisées dans sVote, et de convaincre n’importe quel auditeur que des bulletins sont invalides, alors que ces bulletins sont en réalité valides.

Interpellés par ce problème, nous avons immédiatement averti Swiss Post et NSWEC de notre découverte, et des premiers pas de notre investigation de ses conséquences: ce problème, qui aurait dû pouvoir être examiné en détail hors de tout déploiement du système Swiss Post, se trouvait à présent susceptible d’avoir un impact sur une élection en cours en NSW. Ce samedi, la NSWEC a spontanément annoncé que ce nouveau problème n’avait pas d’impact sur leur système.

Une tentation pourrait être de minimiser l’importance de cette nouvelle faille dans la mesure où, pour le moment, elle semble “seulement” permettre d’invalider des bulletins de vote. Et ces bulletins déclarés invalides, bien que conformes aux procédures d’audit du système, risquent de susciter des questions. (Trouver la réponse à apporter à ces questions semble par contre plus complexe: comment détecter qui a triché sans violer la confidentialité des votes si on ne peut pas croire les preuves fournies par le système?)

Ce serait passer à côté de deux autres points. Premièrement, le problème n’est pas isolé, ce qui soulève la question de la présence d’autres faiblesses.  Outre la trappe identifiée précédemment, notre rapport fait état d’un certain nombre d’autres faiblesses dans les mécanismes de preuve présents dans le code de sVote: le problème identifié dans la preuve de déchiffrement se retrouve à d’autres endroits dans le système, d’autres difficultés existent, mais leur impact nous est encore inconnu. Deuxièmement, et de manière plus fondamentale, mesurer l’importance des faiblesses du protocole sVote à leur impact en terme d’attaques possibles passe à côté de l’objectif principal que vise ce protocole, et qui est requis par la Chancellerie fédérale suisse: offrir des élections vérifiables.

Qu’est-ce qu’une élection vérifiable?

L’organisation d’élections vérifiables passe par deux étapes:

1. La définition d’un processus d’audit qui indique la procédure à suivre pour vérifier les résultats d’une élection, et
2. La démonstration qu’un audit réussi garantit que le résultat de l’élection est correct.

La faille que nous avons identifiée montre, tout comme la précédente, que les hypothèses faites dans cette démonstration ne sont pas satisfaites, parce que les preuves fournies par le système peuvent être falsifiées. En l’état, sVote ne permet donc pas l’organisation d’élections vérifiables.

Pour plus d’informations:

• Communiqué par Vanessa Teague.
• Communiqué par Swiss Post
• Une introduction à des techniques cryptographiques pour l’organisation d’élections vérifiables.

Cette recherche a bénéficié du soutien du F.R.S.-FNRS via le projet SeVote.

En collaboration avec Sarah Jamie Lewis et Vanessa Teague, nous avons effectué quelques coups de sonde dans le code du système suisse de vote par internet sVote.

La pratique du vote par internet connaît un développement croissant en Suisse: au départ, depuis 2003, de référendums à  portée limitée, le vote par internet a été graduellement proposé à  un nombre croissant de citoyens.

La Chancellerie fédérale suisse balise ce déploiement, en imposant des contraintes de sécurité allant croissant selon la proportion des électeurs qui seraient autorisés à  voter par internet.

Le système de vote électronique de la Poste suisse, basé sur le protocole sVote développé par la société Scytl, est le premier à  avoir passé la barre d’une certification pour plus de 30% de votants, et à  voir ainsi son usage autorisé jusqu’à  une proportion de 50% des votants d’un canton.

Swiss Post souhaite aujourd’hui que sVote puisse franchir cette barre des 50%, et le système doit pour cela satisfaire un certain nombre de conditions fort strictes. Notamment:

• Les votants ou les vérificateurs doivent avoir la possibilité, dans le respect du secret du vote, d’identifier toute manipulation aboutissant à une falsification des résultats (Art 5).
• Le code source du logiciel du système doit être publié. […] Toute personne a le droit non seulement d’examiner, de modifier, de compiler et d’exécuter le code source à des fins idéales, mais aussi de rédiger des études en la matière et de les publier. (Art. 7.a et 7.b)

Suite à la publication de ce code, nous avons effectué des coups de sonde afin de déterminer la manière dont il pourrait garantir les propriétés de vérifiabilité  annoncées et requises.

Notre investigation nous a mené à  la mise en évidence d’une trappe dans le système sVote, trappe qui pourrait permettre aux opérateurs du système de vote, ou à  une personne qui serait parvenue à  s’introduire dans leur système informatique, de modifier un nombre quelconque de votes, et d’ainsi produire un résultat d’élection qui ne serait pas conforme aux votes transmis par les électeurs. De manière préoccupante, cette trappe permettrait de modifier les votes d’une manière qui est indétectable par les mécanismes de vérification spécifiés par la système. Dès lors, l’usage de ces mécanismes de vérification convaincrait, à  tort, à n’importe quel auditeur de la correction des résultats.  Qui plus est, même en connaissant le fonctionnement de la trappe, il ne serait pas possible de détecter la manipulation en examinant les “preuves” fournies par le système : l’exploitation de cette trappe ne laisse aucune trace.

L’existence de cette trappe est préoccupante. L’interprétation la plus évidente serait que les mécanismes cryptographiques présents dans le système ont été mis en œuvre de manière erronée: la présence de cette trappe peur être expliquée par la mise en œuvre de protocoles cryptographiques par des personnes bien intentionnées mais n’ayant qu’une compréhension très superficielle de ceux-ci. Bien sûr, si une personne mal intentionnée souhaitait introduire une trappe dans un système, il serait préférable de choisir une trappe qui pourrait être présentée, si elle venait à  être découverte, comme une erreur involontaire ou une négligence. Notre examen du code ne nous donne aucune indication allant dans un sens ou dans l’autre.

La découverte de cette trappe pose évidemment de nombreuses questions.

• Est-il possible que cette trappe ait déjà  été exploitée dans une élection?
  La version du code de sVote que nous avons examinée n’a, à  notre connaissance, jamais été déployée. S’il s’avérait que la partie du code contenant la trappe avait été déployée dans d’autres contextes, il resterait possible de tester son éventuelle exploitation en reproduisant la procédure de décompte au moyen de mécanismes cryptographiques effectivement vérifiables (et ce pour autant que les données nécessaires sont encore disponibles).
• Scytl a publié différents documents présentant des preuves de la vérifiabilité du système sVote. Ces preuves sont-elles erronées?
  Nous n’avons aucune indication que les “preuves” proposées sont erronées. Les preuves de la sécurité de sVote ne sont proposées que moyennant des hypothèses particulièrement fortes, portant notamment sur la sécurité des composants de sVote, pris individuellement.  Notre analyse montre que certaines de ces hypothèses ne sont pas satisfaites, ce qui rend ces preuves inopérantes. Une analyse détaillée de sVote, qui se passerait de ces hypothèses ou les affaiblirait sensiblement, et qui serait plus proche de ce qui est fait pour d’autres protocoles critiques (comme TLS 1.3), est essentiellement hors de ce qu’il est possible de réaliser avec les connaissances actuelles et moyennant un effort raisonnable. Bon nombre de chercheurs dans le monde travaillent à  améliorer ces méthodes d’analyse, qui peuvent sensiblement améliorer la compréhension du fonctionnement d’un système et révéler des erreurs ou omissions.
• Est-il possible de modifier sVote pour retirer cette trappe?
  Oui: il existe différents mécanismes cryptographiques, bien documentés dans la littérature scientifique, dont la mise en œuvre permettrait de démontrer et de vérifier, à  l’avenir, l’absence de cette trappe. Swiss Post propose aujourd’hui d’utiliser une solution de ce type.
• Est-il possible qu’il existe d’autres trappes ou vulnérabilités critiques dans sVote?
  Ce système est remarquablement complexe, et notre analyse n’a procédé que par coups de sonde sur une période de temps très limitée — le code source contient plus de 6000 fichiers. Notre analyse reste bien trop partielle que pour suggérer qu’il n’y aurait pas d’autre vulnérabilité importante dans ce système.

Pour plus d’informations:

• Notre rapport technique préliminaire est disponible depuis la page Trapdoor commitments in the SwissPost e-voting shuffle proof.
• Communiqué de la Chancellerie fédérale suisse.
• Communiqué de presse de Swiss Post

Cette recherche a bénéficié du soutien du F.R.S.-FNRS via le projet SeVote.