soh.am  does c.s. research, builds robots, codes, does stand-up, has a podcast & writes.

You are reading something Soham Sankaran wrote. Return to the writing index.
Feel free to find him on twitter @sohamsankaran or email him at soham@(this website).

The Infrastructure of Democracy is Broken

Voting machines everywhere are broken, insecure, and unauditable. As long as this is true, democracy is in peril. Here's what we should do to fix them.

Published March 29, 2019

Two weeks ago, DARPA announced that they were awarding award a $10 million contract to Galois to work on an open source secure voting system. This is excellent news. Coincidentally, I'd recently been thinking about starting a company to build voting machines on similar principles, so I thought I might publish a short memo I wrote a few months ago laying out why we need something like this and what I think an ideal system of this nature would look like.

It is important to note that Galois does not (as of now) intend to bring voting machines to market -- it merely intends its designs to serve as the inspiration for a new breed of machines. It remains essential for actual businesses to form around these ideas.

The memo follows below.

. . .

Beneath the fog conjured by the endless culture wars, the disintegration of long-accepted norms of civil society, and the accelerating erosion of freedoms all over the world, is a seldom-mentioned but staggeringly important truth: the infrastructure of democracy is broken.

I don't mean this metaphorically at all. As much of the world concentrates -- mistakenly, I'd argue -- on the impact of social-media disinformation on political campaigns, voting machines -- the direct, physical manifestation of democratic infrastructure -- remain hopelessly broken the world over. At Defcon (a) (b) after Defcon, in paper after paper, security researchers have found massive, irredeemable security flaws in voting machines that are deployed today, flaws that allow votes to be added, changed, discarded, and de-anonymized. The companies that make these machines have responded with lies (a) (b) and lawsuits (a) (b) (c). Voters across the world complain that these machines often visibly register the wrong votes -- the companies cry user error. The United States Congress requests cooperation from the manufacturers on quickly fixing vulnerabilities -- the companies don't even show up to the hearings. These machines that ensure the sovereignty of the people are outdated hunks of junk built in secret by 3 anti-competitive (a) (b) regional monopolies (page 14 of link) owned by secretive private equity firms.

To my mind, here is what we should want from our voting machines in order to guarantee accuracy and security in a way that is both real and legible to the people:

(1) That their hardware and software design be as open as possible, modulo a relatively trivial amount of obfuscation for security purposes, and that they be provided at low cost to security researchers with no restrictions on publishing the resultant research, with a particular emphasis on encouraging the publication of vulnerabilities found. This alone would be a revolution in the field. Why? It may seem counterintuitive, but hiding the design of a system in order to prevent penetration, a philosophy that is known as 'security through obscurity', does not work in practice. This is especially true when potential adversaries include nation state actors who can likely compromise someone in your circle of trust. Even if you attempt to use obscurity as only one layer of security in your system, the attack surface of any non-trivial system is so large that you're trading off security for obscurity by not exposing your system to the scrutiny of the world outside your organization, in particular to the white-hat and academic security communities.

(2) That their UX be empirically tested to ensure maximal ease-of-use and understanding for all voters, including those with disabilities. Why? In Texas this year, voters found themselves confused by a voting machine that would register an incorrect vote if they clicked something before the interface even loaded. This was chalked up to 'user error' by the company and the Texas Secretary of State. I am of the opinion that in situations like this, there is no user error, only designer error. Voting machine UX design must be driven by empirical work on machine usability beyond the insufficient minimal regulatory standards. There are entire fields of research -- Human-Computer Interaction and Usable Security -- dedicated to these sorts of problems, but their work does not seem to have been leveraged by voting machine manufacturers at all.

(3) That they produce paper ballots in addition to electronic vote casting for post-facto auditing. Why? This allows for the voter to quickly sanity check that their vote is correct, and produces two independent reconcilable records of the election, one of which is a physical record that is difficult to quickly tamper with or erase.

(4) That they be anonymous, that is, that no voter in the system can be traced back to their vote. Why? You don't want government officials (or anyone else) to ascertain how someone voted, then target them in the future.

(5) That they be verifiable, that is, that a voter can verify that their vote has been counted in some mathematically provable way, and at the same time receipt-free, that is, that no voter can produce evidence to a third-party that they voted a certain way. Why? Security aside, the key problem with present day voting systems is that the voter has no way of knowing that their vote was actually counted beyond a vague faith in the sanctity of the system. Ideally, you want the voter to be able to go online after the vote count but before the election is certified and verify that their ballot was counted correctly. Nevertheless, you don't want to do this in some naive way that allows a voter to prove to someone else that they voted a certain way, since this would allow them to be bribed or coerced very easily. Note that this means that the paper ballot from (3) must not be marked with the voter's name or any identifying information, and must be displayed in such a manner that the voter can view it, but not in such a manner that it becomes an actual receipt that allows them to prove how they themselves voted.

(6) That their software and hardware be spot-checkable by any interested party. Why? There is no point ensuring that there are no vulnerabilities in the hardware and software of a voting machine design if one cannot verify, quickly and on-demand, whether a given voting machine is actually running said hardware and software. Without this capability, the losers could cry foul about transparency, and they would be right to.

No voting machine currently deployed in the US or India (my two countries of interest) meets any reasonable definition of the requirements 1, 2, 5, and 6. I believe it is possible to build a voting machine that meets all of these criteria. In undergrad, I (along with Sachith Gullapalli and Lincoln Swaine-Moore) was part of a team that built what is to my knowledge the first practical implementation (link to our tech report) of one specific existing receipt-free verifiable voting protocol (Tal Moran and Moni Naor, 2006) meeting criteria 3, 4, and 5 -- while criterion 5 may seem intuitively impossible, it is indeed possible to accomplish using non-interactive zero-knowledge proofs. Our work extended the protocol to deal with issues of live dispute resolution and voters potentially 'crying wolf'. About a decade before that, in 2007, a group of cryptographers led by David Chaum formulated the Punchscan system, which also meets criteria 3-5 using a clever combination of cryptography and physical ballot marking, and additionally was even open source. A successor system to this, Scantegrity II, was actually used in local elections in Takoma Park, Maryland, in 2009 and 2011, but apparently has not been used in the wild subsequently (at least as far as I can tell).

I've been toying with the idea of starting a company to build a new voting system designed to meet requirements 1-6, as well as be cheap, portable, and easy to deploy.

Here's what I would do. First, build prototype system and publish the specifications publicly.

Second, set the security community loose on this system and watch them (almost certainly) rip its 'security guarantees' to shreds.

Third, use their insights to build a new prototype and repeat the process. After a few iterations of this, I suspect I would have the most secure voting system ever designed, hardened through repeated exposure to adversaries.

I would not, however, stop there. Doing these sorts of adversarial exercises regularly and publicly would be baked into the DNA of the company. A system like this is never finished, and its security is never complete.

Actual technology aside, an integral part of this would need to be making the case to government officials, legislators, and voters all over the world that this is the right approach to voting infrastructure through a public relations campaign combining journalism highlighting vulnerabilities in current systems, fiction dealing with vote-hacking doomsday scenarios, and publicity stunts involving Defcon-style live machine hacks.

I think this is the right approach to an incredibly important problem. It would be ideal if a large number of competing companies used this approach to populate the voting machine market with real choices that are open, secure, and usable. You -- yes, you! -- should consider working on this too.

Feel free to email me with questions, ideas, and suggestions (contact information below).

. . .

Soham Sankaran is not dead yet, much to the disappointment of both blockchain enthusiasts and the people listed on his life insurance policy.

He can be contacted at (his first name) [at] soh.am.

You can read more of his writing at soh.am/writes, and follow him on twitter @sohamsankaran.