New MIT Paper Roundly Rejects Blockchain Voting as Solution to Election Woes

An encryption inventor and the head of MIT’s Digital Currency Initiative are among authors of a new paper that points out why blockchain and voting are a bad pairing.

Nov 16, 2020 at 5:01 a.m. UTC
Updated Sep 14, 2021 at 10:31 a.m. UTC



The report's authors are Ron Rivest, MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) professor and one of the creators of RSA encryption; Michael Specter; Sunoo Park; and Director of MIT’s Digital Currency Initiative (DCI) Neha Narula. The paper was published on the research team's website this week and is being reviewed by a major cybersecurity journal for publication this winter.. 

“I haven't yet seen a blockchain system that I would trust with a county-fair jellybean count, much less a presidential election," said Rivest in a blog post accompanying the report. 

Why online voting isn’t like digital banking


One reason is that those systems have “higher tolerances for failure.” For example, if an issue were to occur, such as credit card fraud, you could block your card and a bank might even reimburse you. But when it comes to election, there is little remedy if a vote is altered or not delivered, particularly given that online voting systems might not always recognize when one of these actions occurred. 

Another is that anonymity, or at least detaching the way you voted from your identity, is an important part of any electoral process. While a bank or shop can offer you a receipt, proving you did something to detect or prevent fraud, with voting, it’s important no such receipt exists so votes can’t be coerced or sold. 

“For elections there is no insurance or recourse against a failure of democracy,” Rivest says. “There is no means to ‘make voters whole again’ after a compromised election.”

And the cybersecurity issues are numerous. 

Issues with cybersecurity in online voting

One issue with online voting is that it opens itself up to attacks that are both scalable and undetectable. 

In terms of scale, according to the report, a zero-day Android vulnerability only cost $60,000 to acquire in 2012. A zero-day vulnerability is a security flaw that is known about but for which a patch isn’t yet available. 

The authors estimate that testing and weaponizing such a vulnerability would increase the associated costs by two orders of magnitude, meaning an election exploit could cost $6 million. While that may seem like a large sum, it’s little for a nation-state adversary, especially in comparison with the roughly $768 million that was spent on the 2016 U.S. presidential election. This makes a scalable attack on an election system attractive, in terms of getting a bang for your buck. 

Such an attack could also be undetectable, resulting in large numbers of votes being exploited. This is, in part, due to the number of vendors and devices that would have to be involved. 

“Voting system flaws might be introduced by the voting software vendor, the hardware vendor, the manufacturer or any third party that maintains or supplies code for these organizations,” reads the report. 

“A voter using a phone to vote depends not only on the phone vendor, but on the hardware companies providing drivers for the device, the baseband processor, the authors of third-party code in the voting software, the manufacturer of the physical device and the network or any other systems that the device relies upon to cast the vote.”

No concrete solutions to non-hypothetical problems

Even important tools like encryption don’t offer a concrete solution. While encryption does offer some protections, it doesn’t prevent system bugs. Plus, implementing it is difficult, not to mention there are numerous examples of flaws in a system allowing cryptographic protocols to become compromised. 

These concerns aren’t just hypotheticals. The report notes that  electronic-only voting devices at polling stations used in Georgia and Maryland, for example, have previously been shown to be vulnerable, and internet voting systems in cities like Washington, D.C., and countries including Estonia and Switzerland were found to be vulnerable to serious failures. 

For comparison, tried-and-true methods such as mail-in ballots make a large-scale attack on them incredibly difficult to conduct with any ease because of substantial friction points, like needing physical access to the ballots. 

When asked whether there were lessons the U.S. could take from other countries when it comes to voting online, an MIT CSAIL spokesperson said, “None that are positive. Online voting systems will suffer from major vulnerabilities for the foreseeable future, given the state of computer security and the high stakes in political elections.”

The arguments for blockchain-based voting – and why they don’t hold up

The report lays out a number of arguments that have been held up by blockchain proponents. These include using coins as votes, using a permissioned blockchain and employing zero-knowledge proofs for secret ballots. 

Voting with coins

Coins as votes is one model the report identifies as problematic. In it, a registered voter has a public/private key pair created by the voting authority, with each voter sending their public key to the voting registry. 

“Then, the voter registry spends one coin to each public key. To vote, each user spends their coin to the candidate of their choice. After a period, everyone can look at the blockchain, total up each candidate's coins, and select the one with the most coins as the winner,” reads the report. 

The issue here is that it doesn’t provide a secret ballot – all the votes are on a public blockchain. It also relies on users being able to get their votes on the blockchain in a certain amount of time, something that could be compromised through distributed denial-of-service attack, making the network unavailable to users. 

An adversary could drive up transaction fees on a public blockchain, further hampering the “vote.” Or the blockchain could be compromised if a majority of the miners or validators collude, creating multiple versions of the blockchain. 

Finally, it relies on private key management, something that is user-dependent and, as cryptocurrencies have shown, something people are often bad at implementing. 

Permissioned blockchains

Another proposal the report challenges is using a permissioned blockchain. A permissioned blockchain is one in which a central actor approves who can be a part of it. There is also usually a control layer that governs what actions participants have permission to perform.

Like voting with coins, use of this strategy would still suffer from key management vulnerabilities. Furthermore, permission parameters would also keep users from reading the blockchain to verify their votes were counted in order to preserve the secrecy of people’s votes. 

A permissioned blockchain would also likely run on a smaller number of servers, with most of them running the same operating system, meaning it would be easier to compromise. 

Zero-knowledge proofs

A final proposal that MIT examines is the use of zero-knowledge proofs (ZKPs). ZKPs are a cryptographic technique that allows two parties on the internet, such as an app and a user, to verify information with each other without sharing the underlying data related to this information. This would seemingly help ease the tension between secrecy and making a vote publicly verifiable. 

But the report notes that, aside from the potential bugs in ZKPs and challenging cryptographic processes, it also doesn’t prevent physical monitoring by “coercers or vote buyers.” 

Additionally, the report argues that “zero-knowledge proofs are designed for a setting where the party with secret information wants to keep it secret (that's why they're using zero-knowledge proofs) - they generally do not prevent that party from revealing information voluntarily.”

A final and fundamental concern about any digital processes such as these, however, is that they rely on various vendors, hardware and software, all of which add additional complexities and likely vulnerabilities to the voting process. 

“The biggest issue is that blockchain-based approaches require that voters use software in which a single bug could undetectably change what they see - for example, showing them that their vote was cast for a certain candidate when it actually wasn’t,” said a MIT CSAIL spokesperson.  “Blockchain is ripe for situations where election results could be changed in ways that are undetectable, or, even if detected, would be irreparable without running an entire new election.”

The report also plays up that elections have stakes beyond just losing money, as would be the case if these online voting tools were compromised in regards to cryptocurrencies. 

Blockchain has lots of potential, just not for actual voting

The report notes it isn't addressing voting within a blockchain, such as EOS holders voting for validators in consensus networks, or Augur users using REP to vote on contract outcomes. These may fulfill some aspects of voting, but don’t map onto the system of political elections well, and leave many vulnerabilities that can't be accounted for. 

The report also recognizes it’s focusing on voting, not areas such as voter registration management or auditing. 

In conclusion, the report notes that blockchain and online voting don’t address fundamental security concerns; instead, they introduce more vulnerabilities than are present in current in-person and mail-in ballot systems. 

“If vote-casting is entirely software-based, a malicious system could fool the voter about how the vote was actually recorded,” said Rivest in an accompanying blog. “Democracy – and the consent of the governed – cannot be made contingent on whether some software correctly recorded voters’ choices.”

