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.

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