Une trappe dans sVote, le système suisse de vote par internet

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.