The Ballot is Busted Before the Blockchain: A Security Analysis of Voatz, the First Internet Voting Application Used in U.S. Federal Elections

The Ballot is Busted Before the Blockchain: A Security Analysis of Voatz, the First Internet Voting Application Used in U.S. Federal Elections. Could ballots be compromised before Voatz’s advertised safeguards mattered? Specter, Koppel, and Weitzner presented this 2020 analysis at the USENIX Security Symposium. Voatz had already been used in U.S. elections and promoted a collection of technical safeguards, despite having no public formal security model. The researchers examined whether a malicious API server could compromise ballots before any blockchain or mixnet stage.

Voatz promoted several layers of protection, including hardware-backed key storage and a voter-checked audit trail. But the client exposed no proof that submissions were authenticated to or included in a blockchain. Even under assumptions favorable to the backend, a malicious API server could observe or alter votes before any blockchain or mixnet stage. It could also suppress legitimate votes or invent new ones.

The security question was essentially a test of trust boundaries. The researchers considered attackers who could manipulate communications, control a supporting identity or API service, or gain root-level control of a voter’s phone. Could they learn or change a secret choice? Could they suppress a ballot or expose identity and IP information? This framing evaluates what each attacker can actually do instead of assuming that a collection of security technologies protects every stage of voting.

The team conducted a clean-room, black-box analysis of the Android app. In plain terms, they redirected all of the app’s communications to a server they built themselves, allowing them to exercise the client without contacting Voatz or third-party production services. Dynamic testing used 2 Android devices: one officially supported model and one unsupported model. Both were modified to provide root-level access. The test harness combined Java hooks with a Python server implementation so the researchers could examine how the client behaved under their control.

On a rooted Android device, an attacker could disable the Zimperium defensive component by overriding its software entry points. The attacker could then read authentication data and vote history. The same access could alter a ballot while continuing to display the voter’s original selection, or suppress a vote while displaying apparent success. The server side created another trust problem. Even under assumptions favorable to the backend, a malicious API server could observe votes or prevent them from going through. It could also alter or invent votes before they reached a blockchain or mixing stage. The client provided no proof that its submissions were authenticated to, or included in, a blockchain.

The researchers systematically compared attacker positions with possible consequences. Depending on whether attackers controlled communications, a supporting service, or the voter’s device, they could expose voter information and ballot choices or interfere with whether ballots were recorded correctly. A potential network leak involved the sizes of encrypted messages. Because ballot-option metadata was compressed before encryption, a passive observer could potentially infer the selected candidate. That attack required prior knowledge of the ballot options and a server that did not make message lengths uniform. The app also exposed extensive personal data and included many third-party libraries.

The testing boundary is important. The researchers did not examine the iOS client or Voatz’s production backend. They also did not inspect the blockchain implementation, audit portal, or a live election configuration. Some diagrams were reconstructed, and some receipt behavior could not be confirmed. The encrypted-message-length attack also depended on specific knowledge and server behavior. These results therefore establish serious client-visible attack paths, but they do not establish a complete compromise of the production election system.

For election security architects and procurement teams, the practical lesson is to evaluate the entire route from voter intent through recording and tallying, rather than accepting a blockchain label as evidence of security. The authors recommended abandoning high-stakes deployments in the near term and publishing source code, system designs, threat models, and operational details for scrutiny. After disclosure, Mason County, Washington, and then West Virginia discontinued planned Voatz use. Independent review should ask whether voters and observers can verify ballot inclusion and tallying, and whether software failure could change an election result without detection.

Specter, Koppel, and Weitzner showed that control of the Android client or API layer could undermine voting before a blockchain could help. Election security and procurement teams should require public threat models and evidence that each recorded vote reflects the voter’s choice and reaches the final tally. Architecture claims alone are not enough. The study did not establish a complete compromise of the untested production system or a live election.