October 6, 2022

Archives for June 2022

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

How NOT to Assess an E-voting System

by Vanessa Teague, an Australian computer scientist, cryptographer, and security/privacy expert.

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

Australian elections are known for the secret ballot and a long history of being peaceful, transparent and well run. So it may surprise you to learn that the Australian state of New South Wales (NSW) is home to one of the world’s largest Internet voting projects, second only to Moscow’s by absolute number. In the 2021 New South Wales local government elections, 652,983 votes were received from the Internet, including more than one third of votes for the Sydney city council.

The system suffered substantial downtime throughout polling day and the day before. There is no way to tell how many voters were disenfranchised. Electoral Commission estimates give a total of about 20,000 people who registered to use iVote but did not receive a voting credential in time to vote. About half of these probably voted on paper; the rest were disenfranchised. In many councils, the number of disenfranchised people was enough to change the election outcome. As a consequence, the Supreme Court of New South Wales voided the results in three local councils, though the results are highly uncertain in many other councils too. 

iVote has had serious reliability issues and security concerns since its inception. The protocol does not provide any genuine verification, either for the voter to check that their vote reflects their intentions, or for election observers to verify that the complete set of votes has been properly included and decrypted. In 2015, Alex Halderman and I showed that it was vulnerable to an Internet-based attacker who could take over the voting session and substitute a different vote. In 2017, a different set of colleagues found that a version of the vote could be decrypted directly by the server. In 2019, when Thomas Haines, Sarah Jamie Lewis, Olivier Pereira and I found serious cryptographic errors in the Swiss Internet voting system, the NSW Electoral Commission announced that iVote had the same problems

Unlike Switzerland, NSW attempted no serious reassessment of either the regulations or the system design. Even when their appointed auditing team raised concerns about hardcoded passwords, a possible opportunity to delete votes without detection, and inadequate procedures for ensuring that the executed code matched the audited code, the NSW Electoral Commission simply ran iVote again in 2021. No regulations were altered, and they continued to threaten jail time for sharing the source code, though the sharing of source code in Switzerland had led to the identification and correction of serious problems in NSW.

We don’t have demographic or political data, either about who tried to use iVote or who was most impacted by its downtime. We do know, from NSW Electoral Commission reports, that about half of the voters affected by iVote’s downtime went to a polling place and voted on paper. This is extremely unlikely to be a random half—most probably, it was the well-off, healthy voters without caring responsibilities, long working hours on a Saturday, or physical or mobility challenges. The people actually excluded from the franchise by iVote’s downtime were people who were not easily able to suddenly make alternative arrangements, who probably included the more disadvantaged people often used as a justification for running Internet voting. There would have been some who were not able to vote on paper under any circumstances (such as those with physical disabilities) and those who suddenly found themselves under covid isolation orders despite intending to vote in a polling place. These people had no other voting option in NSW (the voters with disabilities should have been offered a verifiable voting option, but they weren’t). However, some of those disenfranchised by iVote’s downtime were people who would have had ample opportunity to apply for a mail-in vote, if they had known in advance that iVote would fail. Unreliable voting systems are most damaging to the voting rights of the people dependent upon them.

The main long-term consequence of iVote’s downtime is that NSW elections will become much more secure and trustworthy because they will stop using iVote.

Internet voting is not part of Australia’s proud history of innovative electoral progress. It is more accurately seen as part of a pattern of public-sector disregard for electronic security and privacy, which includes driver’s licenses, health data, and covid-tracing records. Serious, evidence-based security concerns were repeatedly ignored.

By the time the reruns & possible lawsuits are settled, it will be much more expensive than running the election properly the first time.

Undetectable fraud remains the primary concern. The worst thing about this election was not that ten thousand or more people were disenfranchised, but that 652,983 votes were included in the tally without the slightest evidence that they accurately reflected the voting intentions of eligible voters.

(Next part: How the Swiss Post E-voting system addresses client-side vulnerabilities)

How to Assess an E-voting System

Part 1 of a 5-part series

If I can shop and bank online, why can’t I vote online?   David Jefferson explained in 2011 why internet voting is so difficult to make secure,  I summarized again in 2021 why internet voting is still inherently insecure, and many other experts have explained it too.  Still, several countries and several U.S. states have offered e-voting to some of their citizens.  In many cases they plunge forward without much consideration of whether their e-voting system is really secure, or whether it could be hacked to subvert democracy.  It’s not enough just to take the software vendor’s word for it.

Switzerland is a country that wanted to do it right, fumbled, and in the process learned that an important part of getting it right is a careful (and expensive) study, that’s independent of the vendor selling the system, and independent of the governmental body that’s purchasing the system.   The study wasn’t particularly expensive—about half a million Swiss francs, which is about half a million US dollars—but that’s half a million that most U.S. states or other countries have not spent before rushing to deploy a system.  After the study, the Swiss government’s conclusion was, “The e-voting system currently being developed by Swiss Post has been significantly improved. However, further developments, some of them substantial, are still required.

In 2000 the Swiss Parliament directed the Federal Chancellery to study the feasibility of e-voting, and based on those studies, several cantons (the “counties” or “states” of Switzerland) experimented with pilots starting about 2010.  In 2019 the Swiss Post (the national post office) deployed a system based on cryptographic “mixnets” that were supposed to assure that only authorized votes were cast while also preserving the secret ballot.  Mixnets are a decades-old scientific idea for e-voting, to enable voters to check that their vote has been counted, while preserving the secret ballot (so voters can’t prove to anyone else how they voted).  

Pretty soon, four scientists (from Norway, Canada, Belgium, and Australia) published a paper showing that the cryptographic design of the Swiss Post mixnet was flawed, allowing opportunities for undetectable fraud.  In July 2019, Swiss Post ceased offering its system to the cantons.  The Federal Chancellery was commissioned to work with the cantons to redesign the trial phase of e-voting.  The Chancellery than commissioned independent scientists to do several separate studies:

• A cryptographic protocol study of the theoretical design, by experts in cryptography;

• A systems security study of the software itself, by an expert in operating systems security;

Infrastructure and operation of the Swiss Post in running the system; and

Network security of the e-voting infrastructure.

I’ve read some of those reports, and they’re very good.  The scientists in question are world-renowned in their specific fields of expertise.    They were able to ask for clarifications and explanations from the software architects at Swiss Post. The Chancellery estimates that these “independent experts … commissioned to conduct the examinations” will cost up to a million Swiss francs, by the time these and the next round of studies are complete (see B.1 on pages 41-42 of this report).  That may seem like a lot, but in reading these reports it’s clear that a lot of time and effort went into them—cryptographic protocols and software systems are complicated, and analyzing them takes a lot of time.

If you want to read the System Architecture documentation and the source code for yourself, Swiss Post has made it all available in a public repository.  That kind of transparency is admirable.

For  the Australian State of New South Wales, for France, for those U.S. states that permit internet ballot return for voters living abroad, my question is this:  Why did you adopt an e-voting system just on the say-so of the system vendor?  Where is your independent scientific study by world-class experts?  Where is your million-dollar budget item to assess the system before imposing its insecurities on the public, on the candidates, upon democracy itself?  Because most likely the system you adopted is even less secure than the Swiss Post system, the one that Switzerland decided to pause and revamp.

Coming next in Part 2: How Not to Assess an E-voting System, by Vanessa Teague

Most top websites are not following best practices in their password policies

By Kevin Lee, Sten Sjöberg, and Arvind Narayanan

Compromised passwords have consistently been the number one cause of data breaches by far, yet passwords remain the most common means of authentication on the web. To help, the information security research community has established best practices for helping users create stronger passwords. These include:

  • Block weak passwords that have appeared in breaches or can be easily guessed.
  • Use a strength meter to give users helpful real-time feedback. 
  • Don’t force users to include specific character-classes in their passwords. 

While these recommendations are backed by rigorous research, no one has thoroughly investigated whether websites are heeding the advice.

In a new study, we empirically evaluated compliance with these best practices. We reverse-engineered the password policies at 120 of the top English-language websites, like Google, Facebook, and Amazon. We found only 15 of them were following best practices. The remaining 105 / 120 either leave users at risk for password compromise or frustrated from being unable to use a sufficiently strong password (or both). The following table summarizes our findings:

We compare our key findings with best practices from prior research.

We found that more than half of the websites allowed the most common passwords, like “123456”, to be used. Attackers can guess these passwords with minimal effort, which opens the door to account hijacking.

Amazon allowed us to change the password on our account to “11111111”, a common and easily-guessed password.

Few websites had adopted strength meters, and of those, we found websites misusing meters to encourage complex passwords over strong, hard-to-guess passwords (e.g., preferring the predictable “Password123” over “bdmt7gg82nkc”—which we had randomly generated on our password manager). This not only defeats the purpose of password strength meters, but can lead to more user frustration.

Facebook using its password strength meter as a nudge towards incorporating specific character types in passwords.

Finally, we found almost half of the websites requiring users to include specific character-classes in their password, despite decades of research against it and outcry from users themselves

Intuit requires passwords include uppercase characters, lowercase characters, numbers, and symbols.

Our study reveals a huge gap between research and practice when it comes to password policies. Passwords have been heavily researched, yet few websites have implemented password policies that reflect the lessons learned. At the same time, research has not paid attention to practice. In our paper, we discuss ways for both sides to come together to address this disconnect. One idea for future research: directly engage with system administrators, in order to understand their mindset on password security. Perhaps password policy is meant to be security theater—giving users a sense of safety without actually improving security. Or maybe websites have shifted their attention to adopting other authentication technologies, like SMS-based multi-factor authentication (which also suffers from severe weaknesses, as we discovered in previous research on SIM swaps and number recycling). Perhaps websites have to deal with security audits from firms like Deloitte recommending outdated practices. Or maybe websites face other practical constraints that the information security community doesn’t know about. 

Our peer-reviewed paper is located at passwordpolicies.cs.princeton.edu.