Know the Protocol! - How to Prevent Undetected Vote Manipulation on the Verified Swiss Post E-Voting System

Introduction

I’m a Swiss voter living abroad, and like all Swiss expats from Basel-Stadt, St.Gallen or Thurgau, I’ve been invited to vote over the internet in this year’s national election. Switzerland’s e-voting system is supposed to have safeguards to protect the election against malicious actors, however as a computer scientist, I have found a flaw in the practical implementation of one of those safeguards.

In this article, I explain to Swiss voters what they, as individuals, can do to help protect their own vote against this attack, which is especially important for the ongoing national election since a limited number of manipulations can already affect seat distribution and allocation.

I reported these findings more than 90 days ago to Swiss Post, which provides the election software, and I have respected their requested non-disclosure period, however without feedback within the stipulated time. My findings were produced using public documentation, the Swiss Post e-voting source code [6], and the e-voting paper information sent to Swiss expats, in my case from the canton of St.Gallen.

The Swiss Post e-voting system aims to protect your vote against vote manipulation and interference. The goal is to achieve this even if your own computer is infected by undetected malware that manipulates a user vote. This protection is implemented by special return codes (Prüfcode), printed on the sheet of paper you receive by physical mail. Your computer doesn’t know these codes, so even if it’s infected by malware, it can’t successfully cheat you as long as, you follow the protocol.

Unfortunately, the protocol isn’t explained to you on the piece of paper you get by mail. It’s only explained to you online, when you visit the e-voting website. And of course, that’s part of the problem! If your computer is infected by malware, then it can already present to you a bogus website that instructs you to follow a different protocol, one that is cheatable. To demonstrate this, I built a proof-of-concept demonstration.

Quick Remedy [For Swiss citizens eligible for online voting]

As a quick solution, in the absence of Swiss Post’s action to prevent abuse, I hereby provide you with the needed process description so that you can be sure that the vote you give is the vote entering the voting system. I will outline each step and provide images of what you should see on the e-voting platform in step-by-step instructions.

Should any of the user interfaces be displayed differently, please take a photograph and report it to the e-voting helpdesk of your canton.

Before we start, I strongly suggest using an up-to-date web browser on a personal, non-shared device with all the latest security updates installed. Whenever possible, vote in private-browsing/incognito mode, to reduce attack vectors of tracking, browsing history and browser plugins.

Step 1: Accept the Legal Terms (Gesetzliche Bestimmungen)

Please read the legal terms and accept them by pressing the button labelled with “Ja, ich habe sie zur Kenntnis genommen.”

Step 2: Start Voting (Stimmabgabe starten)

Please enter the initialisation code (Initialisierungscode) from the voter identity card (Stimmrechtsausweis) and your date of birth, and press “Weiter”.

Step 3: Choose (Stimme erfassen)

Choose the party list and candidates and apply cross-vote and aggregation according to your preference.

Step 4: Review (Kontrollieren und verschlüsseln)

Review your choice, and make sure that it matches with your selection from step 3.

Step 5: Verify (Verifizieren und abgeben)

This step is crucial. Please follow it very carefully!

The verification page should display a return code (Prüfcode) for the list and individual return codes for each candidate. Please compare each displayed number to the corresponding one on the voter identity card.

Should the webpage ask you to enter the return codes instead of displaying them, or similarly, if wrong return codes are displayed, take a photograph, terminate the voting process and inform the helpdesk.

If, and only if, all return codes are displayed on the webpage and match to the paper codes, enter the ballot casting key (Bestätigungscode) and press “Stimme abgeben”.

Step 6: Confirm (Stimme abgeben)

Last but not least, check the vote cast return code (Finalisierungscode) displayed on the screen agains t the one on your paper sheet. Should the webpage not display the expected number or ask you to enter the vote cast return code, please take a photograph of it, stop the voting process, and inform the helpdesk.

If you made it here and all the codes matched, your choice of candidates should be registered correctly.

I understand that following a stranger’s advice on the internet is not what you might have been taught. That’s why I am publishing this in my name. Additionally, providing detailed explanations in a second part adds further credibility to the story. Should you still be in doubt , I suggest to rely on paper voting for the time being.

Technical Report

This section provides an in-depth technical analysis of the threat model, security guarantees and insights into how this vulnerability can be exploited. Please note that the technical report is based on the voting material from June 18 2023 vote and the published test system (V1.3.0) and thus slightly diverges from the previous section in terms of appearance . However, under the hood, the functionality is identical.

Disclaimer

My primary expertise is technical. The interpretation of the VEleS (Verordnung der Bundeskanzlei über die elektronische Stimmabgabe) used in this report reflects my understanding of the law.

Trust Assumptions for Individual Verifiability

Before jumping into the details about the vulnerability, we introduce the concept of individual verifiability in voting and its underlying trust assumptions as these requirements imposed by the Swiss legislator are understandably stronger than what is required for most other systems.

The important difference relevant to our case is the guarantee the voting system must provide even in case of compromised or vulnerable user devices. While voter secrecy does not have to be guaranteed in such a case, individual verifiability must be upheld even under these circumstances. In other words, the voter must still be able to identify manipulation of their vote if the user device contains an undetectable virus.

How does Swiss Post provide individual verifiability in an environment of undetectable viruses or tampering on the client device?

To answer this question, we examine the voting protocol under the hood, which reveals a clever idea: To prevent a client-side vulnerability from operating undetected as a man-in-the-middle, some of the information needs to be passed via a second channel, that is outside of the reach of the user device.

This is where the “choice return codes” come into play. As part of the voting documents physically sent to each voter, user-specific choice return codes are generated and printed on the sheet for each possible vote decision (yes/no/blank, or candidates/list). Once the voter sends the votes to the server, the voting server recomputes only the choice return code of the specific vote choice.

A man-in-the-middle does not know the choice return code of the user’s actual vote if it changes the vote between the voter and the voting server. As the user must compare the choice return codes specific to his selection to the codes displayed on the screen, a manipulation would become evident in that step.

How can we defeat this approach?

Given the findings from the previous step, it seems impossible to successfully operate as a man-in-the-middle, right? Especially as the presented scheme has even been formally verified!

Well, since we cannot find a way to break it, we simply modify the scheme itself. Hence, any guarantees, even those established by formal, mathematical proofs, are no longer applicable.

In the 22 October 2023 election documents, the instructions about verifying return codes are not printed in the paper document; they are only on the website. In our proof-of-concept attack, we provide completely different instructions on the website, intercept the user vote and modify the verification scheme using a customised web browser plugin that operates silently in the background. Under individual verifiability, the user should still be able to detect any manipulation, even with such a plugin present (VEleS Art 5.2, Explanatory Report Sec. 4.2.1).

Let’s jump into the inner workings of the malicious code.

The browser plugin is on standby until the voter starts the voting process. It then modifies the user’s vote to the attacker’s choice, which it fetches from a remote server before the vote.

The crucial part comes next. For unmodified votes, the user-expected choice return code matches with the returned one by the voting server. Therefore, no manipulation is necessary. However, for modified votes, the browser plugin has no way of knowing the correct choice return code.

In this case, the browser plugin modifies the user interface by showcasing an alternative verification scheme. Instead of displaying the choice return codes, it modifies all the texts and instead provides input fields to enter and verify the choice return codes.

For fields where the plugin has un-manipulated information, it verifies them truthfully. For the manipulated votes, the plugin also pretends to verify the results but always returns that they have been successfully verified. Several additional measures, such as hiding the user input after entering, help to further prevent detection.

Since all the instruction texts are adjusted to match this new verification scheme, and as there is no information about the initial verification scheme provided on the physical documents, an ordinary voter will not deem this to be suspicious. Therefore, this approach breaks the guarantees of individual verifiability, which would require a user to detect such an attack.

Thus, the voter gladly enters the ballot casting key (Bestätigungscode) to finalise the vote. Due to voter secrecy, there is no way to see which choices have been selected after this step, and the manipulation goes undetected by both the voter and the voting system. Not only does our attack show that using the Swiss Post’s e-voting system as used in St. Gallen allows manipulation and thus undermines the core principles of Swiss democracy, but it also shows that the used system breaks the law (VEleS Art 5.2, Explanatory Report Sec. 4.2.1), as under individual verifiability, any vote manipulation should be detectable by the user.

To showcase the practicability of such an approach, we implemented a proof-of-concept Firefox web browser plugin paired with a Python-based backend server. Once the user enters the e-voting webpage, the plugin activates and fetches the attacker’s vote choices from the server. It subsequently manipulates the votes and modifies the verification scheme to keep the voter believing their vote is correctly submitted. For completeness, the plugin also extracts all information such as vote choice and date of birth and sends it to the backend.

We provide two demonstration videos of the proof-of-concept plugin. The first video runs in no-demo mode, operating fully transparently in the background. The second video provides detailed prompts explaining what information and which step is currently executed.

Practical Implications

According to a press release by the Swiss chancellery, about 65,000 voters, respectively 1.2% of the total voters are eligible for e-voting. With a voter participation rate typically below 50% [3], this leads to a worst-case vote manipulation capacity of roughly 2.4%.

While the number of online voters and the reach of an attack might be lower than 1.2%, the current legislative basis allows for an electorate of up to 30% on a canton level and 10% on a national level, which would be even more detrimental for future elections or votes with low result margin.

Looking back at the vote from June 18 2023, all three national votes had a margin of victory well above 2.4%. Therefore, we conclude that, even if all votes would have been manipulated, the outcome would not have been changed.

However, for the ongoing national election, this manipulation capacity could potentially change the distribution of parliamentary seats between parties and the allocation of candidates within a party.

Swiss Post’s and the Swiss Chancellor’s Stance on this Reporting

The Swiss Post and Swiss Chancellery are disputing my classification (C.1, Manipulation that goes undetected by the voter and the system [5]) of this report. Furthermore, the CVSS score (Common Vulnerability Scoring System) has been reduced from 7.3 to 0. Their standpoint is that this approach modifies the theoretical cryptographic protocol and thus falls outside the threat model of individual verifiability.

In the remainder of this section, we explain our stance and why we think it is important to treat this vulnerability seriously.

1) Legal uncertainty whether it falls inside or outside of the threat model

It is still unclear to me whether their standpoint holds from a legal perspective as the VEIeS Art 5.2 and Explanatory Report Sec. 4.2.1 mandates that the voter must be able to detect a vote manipulation even on an infected user device, and no specific reference to a law stating otherwise was provided.

Are you a lawyer in this field and would be willing to refine this paragraph with me? Please reach out!

2) Scalability

A major part of what makes this attack dangerous is its potential scalability. While offline voting by letter is decentralised on a town or canton level, the interception and modification of large volumes of votes is inherently difficult. In our case however, such a browser plugin can be deployed to thousands or millions of devices, making large-scale, undetected vote manipulation much more practical.

3) Practicability

To contextualise the practicality of such an attack, we provide some food for thought:

In February 2020, Google removed 500 Chrome browser extensions that secretly uploaded private browsing data and redirected victims to malware-laced websites [12]. In June of the same year, another 106 malicious Chrome extensions with an estimated 32 million downloads were reported, with the capability of taking screenshots, reading the clipboard, and harvesting credential tokens and passwords while controlled by a remote server [8]. Similarly, a sophisticated attacker could add our malicious code to a legitimate, widely deployed browser add-on for example an advertisement-blocking plugin, to stay undetected.

Furthermore, the e-voting platform applies no restriction on user devices and whether their operating systems and software are up-to-date. McAfee reported 60 Android apps containing malware, with over 100 million downloads in South Korea alone this year[9]. Similarly, millions of Android smartphones come with factory pre-installed malware [10].

State actors have shown their capability numerous times in the past to infect whole ecosystems with their malware, for example, by using the Maui ransomware targeting the healthcare and public health sector[11] in May 2021.

The Reporting Timeline

14.06:2023: [me] Initial discovery
18.06.2023: [info] National vote day
29.06.2023: [me] Submission of the report via their bug bounty program [5]
29.06.2023: [Swiss Post] Confirmation of receipt (status: new -> under review)
16.08.2023: [Swiss Government] Approval by the federal council to allow e-voting in Basel-Stadt, St.Gallen and Thurgau for the national election on 22. October 2023 [4]
24.08.2023: [me] Checking in for any updates and offering to provide help in the digestion of my report (after 60 days)
27.09.2023: [info] 90-day non-disclosure period expiration
28.09.2023: [me] Informing the Swiss chancellery and offering to coordinate this publication
28.09.2023: [Swiss Post] Downgrade of the report from a vulnerability to a purely informational report (status: review -> completed)
28.09.2023: [Swiss Post] Wrap up and apology for the late reply
29.09.2023: [Swiss chancellery] Provision of their assessment and green light for the publication
06.10.2012: [me] Article publication

Publication of CVD Findings

It is of great importance to further promote and encourage people to make use of responsible vulnerability disclosure, which is why I share the initial report to give people the opportunity to see how such a vulnerability report could look.

I will however withhold the proof-of-concept source code until the end of the ongoing national election for security reasons, as the currently deployed version is still vulnerable, and there are no immediate fixes planned by Swiss Post. Furthermore, we found and reported further findings, which are either of a more theoretical nature or do not scale well. We will describe them later as part of a broader study.

Conclusion – A Trilogy

The Good

From what I have seen during my analysis of the Swiss Post e-voting platform reading through extensive legislative literature, explanatory reports, documentation and audit reports, I am glad to see the substantial efforts and resources invested towards building a secure online voting system. Combining forces by bringing in experts from academia and the private industry in designing and verifying most aspects further enhances trust in the system. Re-assessing the system state and re-authorising a carefully chosen number of voters based on risk management builds a solid foundation for testing the system in a productive environment. Furthermore, this encourages people like me to assess such systems, which is further enhanced by providing source code and a test environment, as not to disrupt live systems.

The Bad

Responding to a vulnerability disclosure report for the first time after more than 90 days leaves little room to express and discuss any differences in interpretation of the laws and severity of a report. To be fair, a representative of the Swiss Post reached out to me personally after the end of the non-disclosure period, explaining that they were busy preparing for the national elections. However, it is especially crucial to follow up swiftly on potential threats during ongoing elections due to the imminent influence and potential trust implications in the final result.

Even with a Master’s degree in computer science, I have difficulties matching the source code to the public documentation and the theoretical protocol. While third parties have formally verified the cryptographic protocol [7], it is difficult to compare the provably correct theoretical protocol to the actual implementation by Swiss Post due to the code size and complexity (over 60,000 lines of Java code, distributed over almost 800 files). Additionally, the possibility for an attacker to force clients to deviate from the intended protocol has not yet been thoroughly studied, leading to vulnerabilities like the one whose risk we showcased.

The Ugly

Whether or not this vulnerability is within the scope of the trust model defined in VEleS 2022, a simple, fast and cost-effective mitigation solution would have been to inform the participating cantons about the problem and mandate them to add extensive and clear instructions about the exact voting procedure to the voting material, including pictures of the user interface.

Unfortunately, in contrast to the vote on 18. Juni 2023 where a brief instruction sheet was included, this was omitted this time, and instead, a reference to the voting website for more information was provided. As our attack targets exactly the change of the voting procedure on the website, this plays further into the hands of an attacker. Furthermore, voters who have already submitted their vote online and are unsure if their voting process has been tampered with have no means to verify if their intended selection of members of parliament has been registered correctly. That is why I believe that the Swiss Post’s stance of hiding behind the applicability of the law is of strong concern. Regardless of the choice of words, the intention of the law is clear - an honest voter following the instructions provided has to be able to detect any deliberate or inadvertent misuse of their voting rights, which includes the manipulation of votes.

Final Words

With this blog post, we seek to enhance the security of the ongoing national elections by providing mitigation instructions for the reported vulnerability, including background information to understand its working principles and implications.

As a researcher, it feels like my duty to provide a remedy and a profound understanding to reduce risk in the deployed voting system and further strengthen trust in one of our most precious treasures, the direct democracy.

Acknowledgement

I am extremely grateful for all the comments, opinions and discussions with cyber experts and colleagues from academia, industry and the public sector that heavily contributed to shaping this article. A special thanks goes to Prof. Andrew Appel, Prof. David Basin, Karin Holzhauser and Pascal Brunner.

Personal Note

Your feedback is important to me. Please reach out via email if you have any questions, critiques, concerns, or other valuable input.

Are you an eligible e-voter from Basel-Stadt or Thurgau? Please let me know what documentation you got together with the voter identity card.

Furthermore, should you be an eligible Swiss e-voter and encounter a counterfeit voting page, please send me a screenshot (without personal data of course)!