At the height of the blockchain frenzy, many evangelists were proclaiming that blockchains would provide solutions to most of humanities problems, and in particular that they would enable secure, online voting. Much of the initial frenzy has died down now, and few blockchain “solutions” have actually emerged. Regarding voting, a few blockchain based schemes have been proposed and some even been trialled. Whether any of these are secure in a meaningful sense is very doubtful, despite grandiose claims by their advocates.
So, let’s examine that claim that blockchains can enable secure voting, either remote or in-person, or at least help. At first glance this seems quite plausible: many so-called “end-to-end verifiable” voting schemes have invoked the notion of a “Secure Public Bulletin Board”, in effect an append-only public ledger. In most cases, it was never explained how such an entity would actually be implemented, it was simply assumed that such a magical beast could somehow be invoked. So here at least it seems that blockchains can help, and indeed they can, up to a point. But we have to be careful: blockchains, or more generally distributed ledger technologies (DLT), come in many flavours, permissioned vs permission-less, private vs public, decentralised vs distributed. So, if we are to advocate the use of a DLT we have to be clear what flavour we have in mind.
So, could Bitcoin style, fully decentralised blockchains be used for voting? The answer seems to be: probably not. Leaving aside issues of latency, i.e. the time for transactions to be confirmed-currently about 10 minutes for Bitcoin, it seems quite dangerous to leave the acceptance of rejection of submitted ballots to an unknown, unaccountable pool of miners from around the globe. We already know about the 51% attack and indeed other forms of attack requiring smaller percentages of the mining pool.
So, it would seem wiser for voting to opt for a distributed but not fully decentralised solution, in which a selected set of trustees collaborate to maintain the ledger. Such entities would be chosen to be (widely) trusted but independent, for example the political parties, pro-democracy organisation like the League of Women Voters in the US etc. But now we are into more traditional forms of Byzantine consensus.
It is worth noting at this point that the Bitcoin style blockchains did not come out the blue. Many of the ingredients were already know to and used by cryptographers and dependability folk: Crypto hashes, hash chains, consensus algorithms etc. Nakamoto brought these together in a novel way to achieve a novel form of consensus, under certain assumptions, in which anyone can in principle participate as a miner. This is certainly interesting, and has spurred a lot of fascinating research, but as argued above, seems inappropriate for voting. At first glance, Nakamoto consensus seems democratic, in that anyone can contribute. In reality though it is only entities able afford the specialised mining hardware who can participate effectively.
So, DLTs can contribute to one aspect of challenge of securing voting systems, can they help with others aspects? For this we need to identify what are the real challenges and what are the unsolved (or only partly solved) problems. I will not detail all the challenges, just focus on the principle one: how to ensure verifiability while at the same time preventing coercion or vote–buying? This is particularly challenging in the remote, internet context, where we cannot enforce the isolation of the voter at the time of casting, and we may have active attackers interacting with the voter before, during and after the voting period, demanding that the voter give up credentials, passwords, and to follow detailed instructions on how exactly to cast the ballot.
The transparency required for verifiability is clearly in conflict with the secrecy requirements, and this tension is typically resolved by use of “modern” cryptography, public key crypto, zero-knowledge proofs, homomorphic cryptography etc. Typically votes are encrypted before being posted to the public ledger and it is essential that the voter be able to confirm to their own satisfaction that this encryption is performed correctly. However, we must take great care in how we do this: any proof provided to the voter must not be transferable to a coercer or vote-buyer. Furthermore, we don’t want to have to trust the software on the encrypting device so we typically allow the voter to “audit” the encryption in some form of cut-and-choose procedure to detect a corrupted encryption device or app.
But even this is not enough: a voter might perform such an audit and claim that the vote revealed when the encryption is opened up does not agree with the vote they input. Now we have to decide if the voter is telling the truth as to what vote they input, and it really was the device cheating, or they are lying, or possibly just mistaken, in which case the device may be perfectly honest. This is often referred to as “dispute resolution” and designing a system that provides this while avoiding any coercion threats is a challenge that researchers have been bashing their heads against for about three decades. Reasonable solutions exist for the in-person case, but to date none are known for the remote case.
And we must add to these requirements that whatever design and interface we come up with must be supremely simple to use and understand, the system must be usable by people with a wide spectrum of ability, who might only use it once every few years. Put all of these requirements together and we have arguably the greatest challenge facing security engineers. It is quite possible, even probable, that no solution exists that will fully meet all of these requirements, at least for the remote context.
So, to return to our question: can DLTs help solve this challenge. As far as I can see there is nothing that DLTs can bring to the table that help with the coercion threat, and based on discussions with other researchers in this field, this is the generally held view of people who have devoted time and effort to this challenge.
So, we are left with the key, high-level question: should we be attempting internet voting at all? As so often, the answer depends on the context. For critical, binding elections, the answer is, for the time being at any rate, a resounding “No!”. We have no technology at present capable of securing internet voting, in the sense of making it verifiable, coercion resistant and usable. Solutions do exist that can provide two of these requirements, but achieving all three simultaneously remains out of reach.
Of course, there are plenty of elections for which the stakes are much lower, where the motivation and resources of potential attackers will be much lower, hence much milder threat scenarios. For such elections, satisfactory solutions do exist and indeed are used, just as a cash-box is enough to secure the takings at a lemonade stand. For high-stake elections, of the US president or a referendum on membership of the European Union to take a couple of random examples, we do not have locks that can withstand state actors, or even in some cases script-kiddies.
Research and development on securing elections continues and progress is being made. In terms of deployment, we should move cautiously from low-stake elections towards higher stake. In this, DLTs do have role to play, at least helping to implement the notion of a secure bulletin board, and perhaps also the maintenance of an electoral role, but for the other challenges thrown up be secure voting we need different tools and ideas, many yet to be invented.