July 3, 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:
ti6v-kvtc-yiju-hh5h-pjsk

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.

What the Assessments Say About the Swiss E-voting System

(Part 4 of a 5-part series starting here)

In 2021 the Swiss government commissioned several in-depth technical studies of the Swiss Post E-voting system, by independent experts from academia and private consulting firms.  They sought to assess, does the protocol as documented guarantee the security called for by Swiss law (the “ordinance on electronic voting”, OEV)?  Does the system as implemented in software correctly correspond to the protocol as documented?  Are the networks and systems, on which the system is deployed, adequately secure?

Before the reports even answer those questions, they point out: “the engineers who build the system need to do a better job of documenting how the software, line by line, corresponds to the protocol it’s supposed to be implementing.”  That is, this kind of assessment can’t work on an impenetrable black-box system; the Swiss Post developers have made good progress in “showing their work” so that it can be assessed, but they need to keep improving.

And this is a very complex protocol, and system, because it’s attempting to solve a very difficult problem:  conduct an election securely even though some of the servers and most of the client computers may be under the control of an adversary.   The server-side solution is to split the trust among several servers using a cryptographic consensus protocol.  The client-side solution is what I described in the previous post: even if the client computer is hacked, it’s not supposed to be able to succeed in cheating because there are certain secrets that it can’t see, printed on the paper and only visible to the voter.

Now, does the voting protocol work in principle?  The experts on cryptographic voting protocols say, “The Swiss Post e-voting system protocol documentation, code and security proofs show continuing improvement. The clarity of the protocol and documentation is much improved on earlier versions [which] has exposed many issues that were already present but not visible in the earlier versions of the system; this is progress. … There are, at present, significant gaps in the protocol specification, verification specification, and proofs. … [S]everal of the issues that we found require structural changes …. ”

And, is the system architecture secure?  The expert on system security says, “the SwissPost E-voting system [has] been evolving … for well over a decade. … The current generation of the system under audit takes many important and valuable measures for security and transparency that are to this author’s knowledge unprecedented or nearly-unprecedented among governmental E-voting programs worldwide. At a technical level, these measures include individual and universal verifiability mechanisms, trust-splitting of critical functions across four control components, the incorporation of an independent auditor role in the E-voting process, and the adoption of a reproducible build process for the E-voting software.  [I see] ample evidence overall of both a system and a development process represent[ing] an exemplar that other governments worldwide should examine closely, learn from, and adopt similar state-of-the-art practices where appropriate.”

But on the other hand, he says, “the current system under audit is still far from the ideal system that … perhaps any expert well-versed in this technology domain – would in principle like to see. Some issues [include] the current system’s reliance on a trusted and fully-centralized printing authority, and its exclusion of coercion or vote-buying as a risk to be taken seriously and potentially mitigated.  [And] Explicit documentation of the architecture’s security principles and assumptions, and how the concrete system embodies them, is still incomplete or unclear in many respects … The architecture’s trust-splitting across four control components strengthens vote privacy, but does not currently strengthen either end-to-end election integrity or availability … The architecture critically relies on an independent auditor for universal verifiability, but the measures taken to ensure the auditor’s independence appear incomplete … While the system’s abstract cryptographic protocol is well-specified and rigorously formalized, the security of the lower-level message-based interactions between the critical devices – especially the interactions involving offline devices – do not yet appear to be fully specified or analyzed.”

In conclusion,  the cryptographic-protocol experts recommend, “We encourage the stakeholders in Swiss e-voting to allow adequate time for the system to thoroughly reviewed before restarting the use of e-voting,”  while the system-security expert concludes, “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.”

In the next part of this series:  Threats that the experts didn’t think of.

How the Swiss Post E-voting system addresses client-side vulnerabilities

(Part 3 of a 5-part series starting here)

In Part 1, I described how Switzerland decided to assess the security and accuracy of its e-voting system.  Swiss Post is the “vendor” developing the system, the Swiss cantons are the “customer” deploying it in their elections, and the Swiss Parliament and Federal Chancellery are the “regulators,”  deciding whether it’s secure enough for the cantons to use.

Internet voting has inherent vulnerabilities that need to be addressed by any e-voting solution:

  • The server:  bugs in the server that receives e-ballots and counts them; vulnerabilities in the server that allow hackers to penetrate and alter the vote-counting software; the possibility that insiders can use their access to subvert the vote counts.
  • The client:  bugs in the voter’s voting-app or browser app; vulnerabilities in the voter’s browser or operating system or hypervisor or BIOS that allow hackers to subvert the app so that it changes the ballot, after the voter sees it but before it is encrypted and transmitted.
  • The communications network: possibility that attackers can change votes in transit, or cause ballots to be lost, or to commit denial-of-service attacks.
  • Authentication of voters:  association of a physical human being with a set of digital credentials.

Of these, the communications network is probably the easiest to address with known technology (end-to-end encryption/authentication).  Authentication of voters can be very difficult or less difficult depending on societal infrastructure.  (Since Switzerland has no universal digital ID card, they address this issue by mailing a sheet of paper to each voter before each election, with an authorization key.)  The server and insider threats can (perhaps) be addressed by splitting the server’s responsibilities among independent machines managed by independent trusted people, and using cryptographic protocols that prove consensus – and this is definitely an important part of the Swiss Post solution.

But it’s that other part, insecurities in the client, that the Swiss Post system tries to address in a more solid and responsible way than almost any other e-voting system deployed in other countries in public elections.  A few other countries (and U.S. states, and Australian states) have deployed e-voting – typically in a limited way, only for citizens living abroad – and every one of them that I know of can be hacked on the client side.  If the hacker installs a modified browser on your laptop computer, or hacks the operating system of your phone, then the voting app can be made to display to you the candidate choices that you indicated, but then encrypt, authenticate, and transmit a different set of votes.   And if the e-voting system has some feature that lets you “check” whether your votes were recorded correctly at the server, then the hack can subvert that feature too, to reassure you.

And the Swiss method of securing the client is:  Send a sheet of paper through the mail.   Before each election, the election administrator sends to each e-voter a personalized paper.  At the top is a numeric key, randomly chosen for that voter alone.  At the beginning of the voting session, the voter types the key into the voting app.

(at the top of the paper sheet is this box)

The voter then selects candidates in the app, and the app uses the voter’s key to encrypt/authenticate the vote selections, and transmit them to a server.

If we stopped here, it would be insecure:  the app could cheat, and encrypt a ballot with candidates that the voter didn’t choose.

The next step is that the servers return “result codes.”  These are calculated based on the private key, known to the server but not to the voter or the client-side app, associated with the start-voting-key that the voter typed in.  The voting app displays these result codes.

Then the voter looks up the result codes on the sheet of paper, and checks that they correspond to the candidates that were chosen.

If the system is working correctly, then the voting app (even if hacked) can’t know what the result codes are supposed to be.  The (hacked) app can’t display the right result codes unless it gets them from the server, and it can’t get them from the server unless it has encrypted the right candidates in the first place.  And it can’t see what result codes are written on the paper, unless the voter’s computer has some sort of camera attached to it ¯\_(ツ)_/¯.  Do computers have cameras? Really?  And why would the camera ever be aimed at the paper sheet during the process of entering the start-voting-key?

If the Swiss Post e-voting system might possibly be secure, it’s only because of the out-of-band communication channel that is completely out of reach of the voter’s computer.  That is: a sheet of paper sent through the mail, to the voter.

So the Swiss Post e-voting system isn’t exactly paperless.  It is not a “pure” internet voting system.  Scientists do not know how to make an adequately secure internet voting system without paper.  (And by the way, the thoughtless use of paper doesn’t help:  for example, when you upload or e-mail a PDF file to an election administrator who then prints it out onto paper before feeding it through the optical-scan voting machine.  That’s not a “paper trail”, because the voter can’t see it, and it doesn’t make the system secure.)

In the next part of this series, I’ll analyze what problems remain in the Swiss Post system: some problems raised in the reports commissioned by the Chancellery, and some things that they haven’t thought of.

Next part: What the Assessments Say About the Swiss E-voting System