May 22, 2022

A PDF File Is Not Paper, So PDF Ballots Cannot Be Verified

new paper by Henry Herrington, a computer science undergraduate at Princeton University, demonstrates that a hacked PDF ballot can display one set of votes to the voter, but different votes after it’s emailed – or uploaded – to election officials doing the counting.

For overseas voters or voters with disabilities, many states provide “Remote Accessible Vote By Mail,” or RAVBM, a system that allows voters the ability to download and print an absentee ballot, fill it out by hand on paper, and physically mail it back.  Some states use commercial products, while others have developed their own solutions.  In general, this form of RAVBM can be made adequately secure, mainly because the voters make their own marks on the paper.  

In some forms of RAVBM, the voter can fill out the ballot using an app on their computer before printing and mailing it.  This is less secure: if malware on the voter’s computer has “hacked” the voting app, what’s printed out may differ from what the voter indicated on the screen, and voters are not very good at reviewing the printouts and noticing such changes.

The most dangerous form of RAVBM is one that allows electronic ballot return, in which the voter uploads or emails a PDF file. Thirty states allow overseas voters to do electronic ballot return, either by email, fax, or web-portal upload, as shown in Table 5 (pages 34-35) of Herrington’s longer paper, Ballot Acrobatics: Altering Electronic Ballots using Internal PDF Scripting

The danger is that malware on the voter’s computer could send a different PDF file than the one that the voter has viewed and verified.  A hacker who wanted to steal an election could propagate such malware to thousands of voters’ computers.  The malware could alter the operation of the voting app, the PDF viewer, the browser, or the email/upload software.  There is a clear scientific consensus on this: According to “Securing the Vote, Protecting American Democracy,” a 2018 report released by the National Academies of Sciences, Engineering, and Medicine: the internet “should not be used for the return of marked ballots . . . as no known technology guarantees the secrecy, security, and verifiability of a marked ballot transmitted over the Internet.” 

Electronic ballot return is promoted by technology vendors, Democracy Live and  Voatz; and by Nevada, with its own EASE, system, which gives voters “the option of saving the ballot materials as a PDF file and emailing the document as an attachment to the respective county clerk or registrar’s office.” Democracy Live uses OmniBallot, an electronic method of delivering and returning ballots.

In all of these cases, the “final” ballot that the voter reviews is a PDF file.* The election-app vendors are implicitly relying on your intuition that “it’s a document” and we humans think we can read a document. At 8:32 in this Democracy Live promotional video, “this ballot happens to be a document.” Clearly, in the video, it’s a PDF, viewed in a PDF viewer, and from Specter and Halderman (2021) we know it’s a PDF.

It’s dangerous enough that the PDF you view may not be the PDF that’s transmitted to the election administrator.  But even if it were the same PDF file, what you see now is not necessarily what you get later.

A recent article by Herrington, “Altering Electronic Ballots Using PDF Scripting,” contains a live demonstration (on page 2) of a PDF ballot that changes what votes are marked from one minute to the next.  Of course, a real election hacker wouldn’t produce a PDF whose votes change every minute; the voter might notice that. The real threat model is between verification time and vote counting time.  Herrington demonstrates a minute-by-minute change for the convenience of his readers.

A voter might mark a ballot using the EASEVoatz, or Democracy Live app provided by their county election office, then inspect it using a browser or PDF viewer:

Ballot with vote for Emily Stone

By inspecting the ballot, the voter might think they have verified their selection of candidates.  Then they email or upload this PDF ballot, as instructed.

But when the election administrator processes that very same PDF file to count the votes, the filled-in oval has moved from one name to another:

Ballot with vote for Jenny Wagoner

The vote has been hacked!

PDF files are not static; they contain active program software.  If a hacker has infected thousands of voters’ home computers with vote-stealing malware, that malware can corrupt the operation of the official ballot-marking app to produce dynamic PDF files.  

You might think, “my computer probably isn’t hacked, so I’ll take that risk.”  But the real risk is not only your computer.  A hacker can spread the same malware to the computers of thousands of your fellow citizens, and steal their votes in that same election—and the election result can be altered.  That’s not democracy, that’s hackocracy.

In conclusion:  Mark your ballots on physical paper.   And tell your state and local election officials not to adopt electronic ballot return. For example, you can refer them to this 2020 report of the U.S. Cybersecurity and Infrastructure Security Agency (CISA), which says,  “Electronic ballot return is high risk. Electronic ballot return, the digital delivery of a voted ballot back to the election authority, faces significant security risks to voted ballot integrity, voter privacy, and system availability.   There are no compensating controls to manage electronic ballot return risk using current technologies. While many risks associated with electronic ballot return have a physical analog with the risk associated with the mailing of ballots, the comparison can miss that electronic systems provide the opportunity to rapidly affect voting at scale.”

*The use of PDF for this purpose in Democracy Live and Voatz is confirmed by independent peer-reviewed analysis: (1) Specter, Michael, and J. Alex Halderman. “Security analysis of the Democracy Live online voting system.” 30th USENIX Security Symposium (USENIX Security 21), 2021; and (2) Specter, Michael A., James Koppel, and Daniel Weitzner. “The Ballot is Busted Before the Blockchain: A Security Analysis of Voatz, the First Internet Voting Application Used in US Federal Elections.” 29th USENIX Security Symposium (USENIX Security 20), 2020;  and, (3) the use of PDF in EASE is stated in plain language on Nevada’s web site.

ES&S Uses Undergraduate Project to Lobby New York Legislature on Risky Voting Machines

The New York State Legislature is considering a bill that would ban all-in-one voting machines. That is, voting machines that can both print votes on a ballot and scan and count votes from a ballot – all in the same paper path.

This is an important safeguard because such machines, if they are hacked by the installation of fraudulent software, can change or add votes that the voter did not intend and never got a chance to see on paper.

One voting machine company, Elections Systems and Software (ES&S), which makes an all-in-one voting machine, the ExpressVote XL, is lobbying hard against this bill. As part of its lobbying package, ES&S is claiming that “Rochester Institute of Technology researchers found zero attacks” on the ExpressVote XL, based on an article (included in ES&S’s lobbying package) from Rochester Institute of Technology entitled “RIT cybersecurity student researchers put voting machine security to the test.

If this were actually a scientific article, one could critique it as actual science.  But it’s not a scientific paper:  The article is written by Scott Bureau, Senior Communications Specialist, RIT Marketing and Communications in the RIT public relations department. 

The article describes an undergraduate student “capstone project.”  The students were interviewed by ES&S, allowed ES&S to inspect their testing site, and then signed a nondisclosure agreement with ES&S.  The students made up two attack scenarios, then spent 10 days trying to find attacks.  They found some vulnerabilities, but not one that could change votes.

The students made public a one-page poster describing their project. It’s fine for undergraduate student work; capstone projects are a really useful part of engineering education.  But it’s not a scientific paper that describes their methods, the limitations placed upon them by needing permission from ES&S, or, in any detail – their results.

Even so, the students describe enough for me to notice that they missed three of the most important attack scenarios:

  • Hacker intrusion into the ES&S corporate engineering network, stealing cryptographic keys and source code, or altering the software to be installed into all ExpressVote XL machines nationwide in the next software update.
  • Hacker intrusion into the county election administrator’s network, stealing cryptographic keys and allowing manipulation of ballot-definition downloads.
  • Stealing an ExpressVote XL anywhere in the country, not just in New York, and tearing it apart to reverse engineer and steal crypto keys.
  • There may be many other attacks.  That’s why penetration testing can never prove that a computer system is secure: pen-testing only examines the attacks that the pen-testers happen to think of.

These are standard attacks. These are the ones that can be so effective and dangerous that there is good reason for banning such voting machines.    Maybe those Rochester students are aware of such attacks. Maybe not. But it seems unlikely that ES&S would have given permission for such experiments. That’s why respectable academic security researchers don’t restrict their activities to those in the comfort zone of the corporations whose products they are examining.It is irresponsible and misleading of ES&S to characterize an undergraduate student project, conducted under conditions controlled by ES&S, described in a publicity puff-piece written by a public-relations flack, as “RIT researchers found zero attacks.”

Blockchains and voting

I’ve been asked about a number of ideas lately involving voting systems and blockchains. This blog piece talks about all the security properties that a voting system needs to have, where blockchains help, and where they don’t.

Let’s start off a decade ago, when Daniel Sandler and I first wrote a paper saying blockchains would be useful for voting systems. We observed that voting machines running on modern computers have overwhelming amounts of CPU and storage, so let’s use it in a serious way. Let’s place a copy of every vote on every machine and let’s use timeline entanglement (Maniatis and Baker 2002), so every machine’s history is protected by hashes stored on other machines. We even built a prototype voting system called VoteBox that used all of this, and many of the same ideas now appear in a design called STAR-Vote, which we hope could someday be used by real voters in real elections.

What is a blockchain good for? Fundamentally, it’s about having a tamper-evident history of events. In the context of a voting system, this means that a blockchain is a great place to store ballots to protect their integrity. STAR-Vote and many other “end-to-end” voting systems have a concept of a “public bulletin board” where encrypted votes go, and a blockchain is the obvious way to implement the public bulletin board. Every STAR-Vote voter leaves the polling place with a “receipt” which is really just the hash of their encrypted ballot, which in turn has the hash of the previous ballot. In other words, STAR-Vote voters all leave the polling place with a pointer into the blockchain which can be independently verified.

So great, blockchain for the win, right? Not so fast. Turns out, voting systems need many additional security properties before they can be meaningfully secure. Here’s a simplified list with some typical vocabulary used for these security properties.

  • Cast as intended. A voter is looking at a computer of some sort and indicates “Alice for President!”, and our computer handily indicates this with a checkbox or some highlighting, but evil malware inside the computer can silently record the vote as “Bob for President!” instead. Any voting system needs a mechanism to defeat malware that might try to compromise the integrity of the vote. One common approach is to have printed paper ballots (and/or hand-marked paper ballots) which can be statistically compared to the electronic ballots. Another approach is to have a process whereby the machine can be “challenged” to prove that it correctly encrypted the ballot (Benaloh 2006, Benaloh 2007).
  • Vote privacy. It’s important that there is no way to identify a particular voter with how they voted. To understand the importance of vote privacy, consider a hypothetical alternate where all votes were published, in the newspaper, with the voter’s name next to each vote. At that point, you could trivially bribe or coerce people to vote in a particular way. The modern secret ballot, also called the Australian ballot, ensures that votes are secret, with various measures taken to make it hard or impossible for voters to violate this secrecy. When you wish to maintain a privacy property in the face of voting computers, that means you have to prevent the computer from retaining state (i.e., keeping a private list of the plaintext votes in the order cast) and you have to ensure that the ciphertext votes, published to the blockchain, aren’t quietly leaking information about their plaintext through various subliminal channels.
  • Counted as cast. If we have voters taking home a receipt of some sort that identifies their ciphertext vote in the blockchain, then they also want to have some sort of cryptographic proof that the final vote tally includes their specific vote. This turns out to be a straightforward application of homomorphic cryptographic primitives and/or mixnets.

If you look at these three properties, you’ll notice that the blockchain doesn’t do much to help with the first two, although they are very useful for the third.

Achieving a “cast as intended” property requires a variety of mechanisms ranging from paper ballots and spot challenges of machines. The blockchain protects the integrity of the recorded vote, but has nothing to say about its fidelity to the intent of the voter.

Achieving a “vote privacy” property requires locking down the software on the voting platform, and for that matter locking down the entire computer. And how can that lock-down property be verified? We need strong attestations that can be independently verified. We also need to ensure that the user cannot be spoofed into running a fake voting application. We can almost imagine how we can achieve this in the context of electronic voting machines which are used exclusively for voting purposes. We can centrally deploy a cryptographic key infrastructure and place physical controls over the motion of the machines. But for mobile phones and personal computers? We simply don’t have the infrastructure in place today, and we probably won’t have it for years to come.

To make matters worse, a commonly expressed desire is to vote from home. It’s convenient! It increases turnout! (Maybe.) Well, it also makes it exceptionally easy for your spouse or your boss or your neighbor to watch over your shoulder and “help” you vote the way they want you to vote.

Blockchains do turn out to be incredibly helpful for verifying a “counted as cast” property, because they force everybody to agree on the exact set of ballots being tabulated. If an election official needs to disqualify a ballot for whatever reason, that fact needs to be public and everybody needs to know that a specific ballot, right there in the blockchain, needs to be discounted, otherwise the cryptographic math won’t add up.

Wrapping up, it’s easy to see how blockchains are an exceptionally useful primitive that can help build voting systems, with particular value in verifying that the final tally is consistent with the cast ballot records. However, a good voting system needs to satisfy many additional properties which a blockchain cannot provide. While there’s an intellectual seduction to pretend that casting votes is no different than moving coins around on a blockchain, the reality of the problem is a good bit more complicated.