August 8, 2022

Switzerland’s E-voting: The Threat Model

Part 5 of a 5-part series starting here

Switzerland commissioned independent expert reviews of the E-voting system built by Swiss Post.   One of those experts concluded, “as imperfect as the current system might be when judged against a nonexistent ideal, the current system generally appears to achieve its stated goals, under the corresponding assumptions and the specific threat model around which it was designed.”

I have explained the ingenious idea (in the Swiss Post system) behind client-side security:  because the voter’s computer may be quite insecure, because the client-side voting app may be under control of a hacker, keep certain secrets on paper that the computer can’t see.  Professor Ford, the systems-security expert, points out that part of the threat model is:  if the printing contractor is corrupt, that prints the paper and mails it, then the system is insecure.

The new threat model in 2022. But I’ll now add something to the threat model that I would not have thought about last year:  Step one of the voter’s workflow is, “type in a 20-character password from the paper into the voting app.”

Start voting key:

In the old days (2020 and before) the voter would do this using a physical or on-screen keyboard.  In the modern era (2022) you might do this using Apple’s “live text”, in which you aim your phone camera at anything with text in it, and then you can copy-paste from the picture.  And, of course, if you do that, then the phone sees all the secrets on the paper.

So the security of the Swiss Post E-voting system relies entirely on a trick–that the voter’s computer can’t know the secret numbers on a piece of paper–that has been made obsolete by advances in consumer technology.

Voter behavior as a component of the threat model.  Experts in voting protocols came to realize, over the past two decades, the importance of dispute resolution in a voting protocol.  That is, suppose a voter comes to realize, while participating in an e-voting system (or at a physical polling-place) that the election system is not properly tallying their vote.  Can the voter prove this to the election officials in a way that appropriate action will be taken, and their vote will be tallied correctly?   If not, then we say the dispute resolution system has failed.

Also, experts have come to understand that voters are only human: they overlook things and they don’t check their work.  So the voting system must have a human-centered design that works for real people.

In my previous post I described the Swiss Post E-voting protocol:

  1. The voter receives a printed sheet in the mail;
  2. The voter copies the start-voting-key into the browser (or voting app);
  3. The voter selects candidates in the app;
  4. The app encodes the ballot using the serial number, and transmits to the servers;
  5. The servers send back “return codes” to the app, which then displays them to the voter;
  6. The voter looks up the return codes on the printed sheet to make sure they match the candidate selections.

But what if most voters omit step 6, checking the return codes?  Then the voting app could get away with cheating: encode the wrong candidates, the server will send return codes for those wrong candidates, and the voter won’t notice.

To address that problem, Swiss Post added more steps to the protocol:

  1. Voter enters “ballot casting key” into the app to confirm that they’ve checked the return codes; app transmits that to servers
  2. Servers transmit another return-code to confirm.
  3. Voter checks that the “vote cast return code” displayed by the app matches the one on the paper.
Ballot casting key: 8147-1584-8
Vote cast return code: 0742-5185

This protocol is becoming ridiculously complex – not exactly human-centered.  Even so, here’s how the app could cheat:  fail to transmit the “ballot casting key” to the servers, and make up a fake “Vote cast return code”.  If the voter omits step 9, then the app has gotten away with cheating: it didn’t manage to cast a vote for the wrong candidate, but it did manage to cancel the voter’s ballot.

And what’s the voter supposed to do if the return codes don’t match?  Recall what’s printed in red on the paper:

Choice Return Code:
Question 1: 
YES: 1225
NO: 7092
EMPTY: 2812

Question 2:
YES: 9817
NO: 2111
EMPTY: 6745

Please check that your device displays the correct choice return codes.  If you cannot see the correct codes or in case of doubt, please contact the election authorities (0XX/ XXX XX XX).

And what should the authorities do if voters call that phone number and claim that the return codes don’t match?  This video (found on this page) suggests the answer: the voter is told, “we didn’t count your e-vote, you should vote on paper by physical mail instead.”

A big danger is that voters skip step 6 (diligently check every return code against the paper printout) and proceed directly to step 7 (enter the “casting key” to submit their ballot).  Would voters really do that?  Of course they would: research has shown over and over that voters don’t carefully reconfirm on paper the choices they made on-screen.

You might think, “I’ll check my own result, so it’s OK.”  But if thousands of your fellow voters are careless with step 6, that allows the voting app (if hacked) to change thousands of their votes, which can change the outcome of your election.  For a full analysis, see Ballot-Marking Devices (BMDs) Cannot Assure the Will of the Voters (here’s the non-paywall version).

In conclusion, the protocol has many, many steps for the voter to follow, and even then it’s not robust against typical voter behavior.   These issues were left out of the threat model that the experts examined.

Other threats:    For brevity, I didn’t even describe some other threats that the experts should probably consider in their next-round evaluation.  For example:

  • When the (hacked) app transmits a fake vote and displays a fake return-code, it could also display a (fake) “return code doesn’t match, try again” button.  If the user clicks there, then the app transmits the real vote (the one the voter selected) and gets back the real return code.  In that case, the app hasn’t succeeded in stealing this voter’s vote, but the voter is reassured and doesn’t alert the hotline.
  • That last point is an indication of a more general threat:  the hacked app can change the protocol, at least the part of the protocol that involves interaction with the voter, by giving the voter fraudulent instructions.  There could be a whole class of threats there; I invite the reader to invent some.
  • Back to step 9:  Suppose an attacker hacks thousands of voter computers/phones, so thousands of voters get bad return codes (because their vote has been stolen), and some percentage of them will notice (in step 9) and call the phone number to report.  That is, a couple hundred calls come in to the hotline.  Hundreds of calls to the hotline is evidence either that thousands of votes are being stolen, or that hundreds of voters are falsely reporting.  Should the election be re-run?  The point is, the election protocol is not complete without a written protocol for what the authorities should do in this case.  And unfortunately, there’s nothing good they can do; which is already a serious flaw in the whole system.
  • I discussed, “the (hacked) computer might be able to see what’s on the paper.”  But consider this:  within a few years after deployment of such a system, it’s easy to imagine that voters will pressure election administrators, “can’t you just e-mail my voter-sheet to me (as a PDF) instead of sending paper in physical mail?”  Then it’s trivial for a (hacked) computer or phone to see all the return codes on the voter sheet.  It will be natural for an election administrator to forget that the security of this whole system relies on the fact that the computer can’t see the paper; sending the “paper” as a PDF defeats that crucial security mechanism.
  • The same is true if the voter-sheet is faxed to the voter; fax is internet, these days.


  1. In the USA, I think we could/should do voting via secure kiosks installed at government and municipal buildings (city hall, schools, libraries, post offices, etc.). The kiosks could use biometrics to confirm the voter’s ID, and record video of the voter for human confirmation. The actual voting could also be done by printing a completed paper ballot that is later machine counted, in order to provide a paper trail. The kiosks could also allow voting to be conducted over a longer period, such as an entire month, to minimize the need to wait in line.

  2. Keith Douglas says:

    Were external experts brought in to create an independent review of the threat model created (hopefully as a community exercise rather than purely internally) by Swiss Post, *prior* to the system implementation?

  3. Patrick O'Callaghan says:

    I’ve only scanned these articles quickly, but I don’t see any discussion of the social threat of e-voting, by which I mean the potential for bribery or coercion when voters are not isolated in a voting booth. Of course this vulnerability already exists with postal voting, but since that accounts for a small proportion of votes in most jurisdictions it hasn’t normally been considered a serious issue. If e-voting becomes ubiquitous, it very well could become one.

  4. Anonymous says:

    What is there to stop someone watching over the voters shoulder while they vote? That leaves the ballot open to bribery and intimidation.

  5. Para Parasolian says:

    I think the biggest threat is that a large number of people get back invalid result codes from the server. This is a DoD attack.

  6. Mukesh Tiwari says:

    Excellent write-up Andrew and Vanessa! One thing I would like to point out the use of formal verification in counting ballots. The idea is that the vote-counting algorithm used in an election should be formally verified, all the way up to machine code. In addition, this code should be available for public so that everyone can inspect and ensure that it correctly implements the vote-counting method. Now anyone can compile and run this code on their machine to verify the outcome of an election, leading to manyfold increase in scrutineers.

    In my personal opinion, I would like to see more Coq –insert your favorite theorem prover here– code and proofs than Java or C code used for conducting elections. In fact, now there are ways to get verified C programs (VST) and compile them using CompCert to get the highest amount of performance. However, the current companies, deploying evoting solutions, don’t have any motivation to do this. Do you think it would be good idea if we enforce, by law, these companies to only deploy formally verified software and make it open source?