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.

Cogito, ergo sum — René Descarte looking for the Truth

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.