Debunking e-Voting Myths and Legends
Do Androids Dream of Electronic Voting?
Whenever I talk about our e-voting project, itugen, there is always someone arguing that only paper ballots can be fully trusted. Most of the concerns I see are indeed valid, and I agree that all existing electronic systems, at least the ones I have reviewed, showed some unacceptable flaws in one way or another. It is perfectly legitimate to point out problems with electronic voting; it is even necessary for the sake of democracy. However, I sometimes feel that the criticism is not fair, as if people were seeing paper voting as the last defense against technology.
For example the following sentence from The Myth of “Secure” Blockchain Voting by David Jefferson, which gave rise to this post title, states that e-voting simply cannot meet voting requirements:
Public elections have unique security and privacy requirements much more stringent than those in other applications such as e-commerce because election officials must always know exactly who is voting to verify eligibility and prevent double voting, but they must not be able to trace particular ballots to the individual voters that cast them. These requirements are easily met with paper ballots at a polling place, but they cannot be met reliably and securely with any online system, with or without blockchains.
Such a statement, given without justification, followed by other valid justified concerns does not follow a scientific approach and is counter-productive. Paper-based voting has many flaws as well regarding fraud, cost, resources, and security. The last point is a hot topic right now, as Covid-19 is impacting French elections as we speak and primary elections in the U.S. are under debate. I believe e-voting done right is a way to bring democracy to a new level.
A lot of this disbelief comes from current implementations. Electronic voting has been used for many years now, and it started with voting machines that are still in use today. To put it simply, voting machines are a terribly bad idea; they suffer from most of the issues associated with paper ballots because they require polling stations, and they combine these with new problems related to the handling, securing, maintaining, etc. of the voting machine. I won’t describe the problems here; they can be found easily online.
The other e-voting implementations, the ones that I will discuss from now on in this post, are online-based. Instead of using a dedicated voting machine in a polling station, users vote online from their own devices. Unlike voting machines, these implementations are solving a lot of the issues with paper ballots, but they also come with new problems, mainly:
- Authentication: How do we ensure that only eligible voters can vote without requiring users to show up at polling stations?
- Black box: How do we ensure that the system is behaving properly?
Of all the e-voting systems used in real elections that I know of, none gave full satisfaction when reviewed by researchers:
2020 — West Virginia moves away from voting app
2019 — Swiss Post suspends its e-voting system
2019 — Breaking the encryption scheme of the Moscow internet voting system
2018 — Massive increase in voting traffic prevented many voters from voting for Ontario municipal elections
2015 — ‘Major vulnerability’ revealed in the online voting system could have compromised 66,000 electronic votes in Australia
e-voting done right
itugen, powered by recent advances in blockchain consensus and zero-knowledge proofs, is solving the aforementioned problems. Its main properties are as follows; if you want more details, I refer you to our white paper, which was submitted and accepted for presentation at the ITASEC 2020 conference last month.
- All ballots are publicly available on an immutable public ledger, and yet, nobody can trace any ballot.
- Double voting is prevented thanks to a pseudonym added to the ballot that anonymously identifies a user for an election.
- Zero-knowledge proofs do ensure that the pseudonym is properly constructed so that the same user cannot generate another pseudonym and a valid proof at the same time.
e-voting done badly
In the following, we review concerns raised in “The Myth of ‘Secure’ Blockchain Voting”, published on verifiedvoting.org, as well as in a report from 2015 entitled “The Future of Voting: End-to-End Verifiable Internet Voting — Expert Statements”, published on usvotefoundation.org (links are provided in the Reference section at the end of this article).
Blockchain vulnerabilities: The example given in The Myth of “Secure” Blockchain Voting is a very good argument in favor of blockchains:
For example, in Bitcoin, if a subset of co-owners (known as “miners”) commanding a majority of the aggregate computing power should collude with one another, they can arbitrarily decide what transactions are added the chain, potentially resulting in large-scale theft.
A major part of the bitcoin mining power is indeed concentrated in a few actors (3 out of 4 bitcoin blocks are mined by 7 pools). They must be the most respectable people on earth: there are bitcoins worth $150 billion, yet nobody has hacked it yet!
The truth is that only valid transactions (i.e., signed by both parties) can be included in a block, so theft attacks are limited to the so-called double-spend issue, which is easily avoided if you wait for the recommended number of blocks (it was 6 blocks the last time I checked) before accepting a transaction. Bottom line: blockchains are a cryptographically proven secure ledger.
Authentication: This is a real issue; however, it is not applicable because our protocol does not deal with user registration, for which requirements depend on the type of election. Instead, we assume that the voter is identified with a private key generated during voter registration. The key is always kept private and is never revealed by the user.
For instance, for state elections, the administration already manages a list of voters, and users have to register in person using their ID cards. This process can be used in conjunction with our protocol. The administration will need to associate a public key with a user for an election. Let me state it again: registration is a major concern, but it should not be handled by an e-voting protocol. There are several self-sovereign identity (SSI) projects that provide interesting solutions to this issue.
Malware: This is another real issue, for which there is simply no solution. If the device you use cannot be trusted, then it could replicate the voting application and make you believe whatever it wants. But this reasoning works for any technology; there is pretty much nothing that we can fully trust, yet we are using computers for many, many things.
Is that a reason not to use any tool? To doubt is necessary, but it must not be excessive. In our case, everyone can see all the ballots on the blockchain, so it is very easy to check whether your vote was properly cast post factum using another device.
Another point is that mobile devices have built-in security measures that make them good candidates for e-voting use cases. In particular, applications come from a trusted store that screens applications and regularly removes doubtful applications. Besides, mobile applications are well isolated, do not have system privileges, and cannot do much harm. As a result, banking applications and pay-with-phone solutions are widely used on mobile phones.
Some additional measures can mitigate the consequences of malware, such as:
- Limiting data that can leak from a malware application, since the client application only needs the user private key to construct a valid ballot.
- The authority managing the election and the list of public keys could send notifications (SMS, e-mail) if it does not receive a valid proof that a user voted.
Denial of Service: Denial of Service attacks are very common, as they are generic and can target any server by overwhelming it with fake traffic, usually from a botnet. Specific attacks targeting OS or other software vulnerabilities are harder to do but are also real threats. Needless to say, a decentralized application is the best answer to these threats, as hackers have to attack many nodes of the network in order to be effective.
Data breach: Thanks to the public blockchain, only public information is stored on the servers, and so there is no risk of data breach. Although the registration authority may want to keep some user information private, such information cannot be used in the voting protocol, as the user private key of the vote, which never reaches the servers, is necessary to generate a valid proof.
Openness, Transparency, Auditing: Our protocol is completely transparent; users send their votes themselves in the blockchain. All votes stay there and are never modified. Besides, we do not re-implement cryptographic protocols: we use existing open-source ones, written by independent academic teams.
e-voting properties
As I was saying before, we do need a more neutral, scientific treatment of e-voting. Fortunately, it is a subject of research, and researchers have come up with security properties to describe e-voting protocols. We present them with a description and then an explanation of why itugen satisfies the property.
Eligibility: YES
- Description: Only registered voters can vote, and nobody can submit more votes than allowed.
- itugen: We provide a cryptographic proof that the voter is registered. Double votes are identified, thanks to the ballot pseudonym.
Fairness: YES
- Description: No preliminary results that could influence other voters’ decisions are made available.
- itugen: Our current protocol can easily achieve this property by encrypting the vote before putting it on the blockchain and decrypting it at the end of the poll.
Robustness: YES
- Description: The protocol can tolerate a certain number of misbehaving voters.
- itugen: Misbehaving users cannot produce a valid vote. It won’t even be added to the blockchain. In addition, we will add anti-spam features to avoid attacks from massive groups of users.
Integrity: YES
- Description: Assurance of the accuracy and consistency of votes.
- itugen: Votes are unalterable thanks to the immutability of the blockchain.
Individual Verifiability: YES
- Description: Each voter can check whether his vote was counted correctly.
- itugen: Each voter can see the vote that corresponds to his pseudonym.
Universal Verifiability: YES
- Description: Anybody can verify that the announced result corresponds to the sum of all votes.
- itugen: All votes are in the blockchain.
Vote Privacy: YES
- Description: The votes are kept private; the voter and their vote cannot be linked.
- itugen: The zero-knowledge proof does not reveal the user name, and the pseudonym is generated using quantum-resistant cryptography.
Receipt-Freeness: Not yet
- Description: In order to prevent vote-buying, a voter cannot construct a receipt to prove to a third party that he voted for a certain candidate.
- itugen: Our protocol can be extended to add this feature. For instance, by adding an extra layer, voting would be done with a voting token retrieved with the pseudonym. Since the token is not related to the user anymore, he cannot link it to himself. However, we have not formally analyzed this solution, and it is not part of our white paper yet.
Coercion-Resistance: No
- Description: Even when a voter interacts with a coercer during the entire voting process, the coercer cannot be sure whether he followed his instructions or actually voted for another candidate.
- itugen: Such a property is probably impossible to achieve for any protocol. Even with a voting booth, some users can take a selfie of their vote, or they could film the entire session using Google glasses. itugen actually allows to mitigate this issue up to a certain point, for instance by allowing double voting and taking into account only the last vote. Biometric features could also be considered.
Nobody’s perfect
As a conclusion, we can see that it is important to assess the properties of a protocol, its pros and cons, but in a fair way.
Furthermore, no protocol will ever be perfect. In the case of itugen, the weak points are:
- Private key: There is not much we can do if you give your private key to somebody.
- Public key: One must trust that the list of voters’ public keys is correct.
- Coercion: Voting is not done in a public environment.
So another important aspect is all the processes that are put around the protocol and that help mitigate its core issues, including:
- SSI: Authentication systems
- Key management: Procedures for users to revoke and change compromised keys
- Notifications: Provide feedback to users using other means than the voting application, such as e-mail and SMS
- Audit: Everything is recorded on the blockchain, so frauds can be investigated
- Automation: Massive fraud can be avoided by preventing automated treatments with captcha-like methods
References
itugen (https://itugen.com/)
A Formal Taxonomy of Privacy in Voting Protocols (https://core.ac.uk/download/pdf/54030272.pdf)
The Myth of “Secure” Blockchain Voting (https://www.verifiedvoting.org/wp-content/uploads/2018/10/The-Myth-of-_Secure_-Blockchain-Voting-1002.pdf)
The Future of Voting: End-to-End Verifiable Internet Voting — Expert Statements (https://usvotefoundation-drupal.s3.amazonaws.com/prod/E2EVIV_expert_statements.pdf)
