It's Not Safe Yet: Online Voting in Practice

It's Not Safe Yet: Online Voting in Practice

Speakers: Michael Specter, Assistant Professor, Georgia Tech

Conference: Voting Village

YouTube: https://www.youtube.com/watch?v=g0GXWp4QmAs

Overview

In "It's Not Safe Yet: Online Voting in Practice," Michael Specter, an Assistant Professor at Georgia Tech, presents a critical security analysis of internet voting systems that were actually deployed in high-stakes U.S. federal elections. Drawing from his extensive research conducted during his PhD at MIT, Specter meticulously dissects the vulnerabilities and inherent flaws in two prominent systems: Votes, a mobile application, and Democracy Live, a web-based platform. The talk not only exposes severe technical shortcomings but also delves into the broader socio-technical and policy challenges that plague the adoption and secure implementation of online voting.

Specter's presentation is a stark warning against the premature and often misguided integration of technology into the electoral process. He argues that while the allure of increased accessibility and reduced complexity is strong, the reality of deployed internet voting systems falls far short of fundamental security and privacy guarantees. The research highlights how these systems, far from simplifying the voting process, introduce a complex web of third-party dependencies and obscure cryptographic implementations that render them susceptible to scalable and remote attacks, ultimately jeopardizing the integrity and trustworthiness of elections.

The significance of this talk extends beyond mere technical critique. Specter reveals a persistent cycle of vendor hostility, misleading documentation, and a lack of public scrutiny that hinders good-faith security research. His personal experience, including legal battles related to the Computer Fraud and Abuse Act, underscores the urgent need for policy reform and greater collaboration between researchers, election officials, and policymakers to safeguard democratic processes against poorly secured technology. This article will explore the detailed findings, technical vulnerabilities, defensive implications, and broader takeaways from Specter's essential research.

Background

▶ Watch: First security analysis of US high-stakes internet voting (0:00)

The foundation of any secure voting system, whether in-person or online, rests upon a set of well-defined cryptographic properties. Michael Specter begins by outlining these critical requirements: Correctness and Usability, ensuring ballots are counted as intended and only accessible to eligible voters; Privacy, guaranteeing an attacker cannot learn a voter's selection; Receipt-freeness, a more nuanced concept where a voter cannot prove how they voted after the fact, preventing vote buying; and Coercion Resistance, meaning a voter cannot cooperate with an attacker to prove their vote under duress. Finally, End-to-End (E2E) Verifiability is often considered table stakes for internet voting, providing voters with cryptographic proof that their vote was counted correctly. Specter notes the apparent contradiction between receipt-freeness and E2E verifiability, a challenge cryptographers have historically sought to reconcile.

Traditional in-person voting typically addresses these concerns through a combination of physical and socio-technical mechanisms. Privacy is maintained by voting booths, receipt-freeness by surrendering ballots, and coercion resistance by poll workers. E2E verifiability, in a cryptographic sense, is often absent, replaced by a robust system of adversarial checks and balances. Specter illustrates this with an example of a vote counting facility where staff from different political parties monitor each other, and public observation is encouraged, with legal recourse for discrepancies. This multi-layered, human-centric approach forms a "sociotechnical system" designed to ensure integrity.

However, this traditional model faces two primary critiques that drive the push for internet voting. First, the lower complexity argument posits that the "beauty and purity of mathematics" could replace the cumbersome human processes, paper trails, and legal complexities of in-person voting. Second, the desire for increased voter access is a significant motivator, particularly for individuals with disabilities, overseas or military voters, or during emergencies like a global pandemic. These arguments suggest that internet voting could provide a more accessible and streamlined electoral experience.

The cryptographic community has long explored internet voting, with foundational work on mixnets (inspiring technologies like Tor) initially driven by this very problem. Numerous E2E verifiable systems like Helios, Civitas, and Apoke have been designed. Despite this academic interest, the deployment of such systems in high-stakes U.S. elections has been contentious. Specter notes that in 2020, West Virginia passed a law allowing disabled voters (roughly 22% of their adult population by CDC guidelines) to use the Votes mobile app, while Delaware and New Jersey permitted 100% of their primary voters to use Democracy Live due to emergency measures.

This rapid deployment occurred despite a broad consensus among computer scientists, including the National Academies, that "at this time no ballot should be cast over the internet." Specter's research was motivated by this disconnect, aiming to concretely assess how well deployed internet voting systems actually achieve established security goals (correctness, privacy, receipt-freeness, coercion resistance, E2E verifiability) and to identify other overlooked real-world problems such as user privacy and authentication. His findings, presented in this talk, ultimately led to significant restrictions and abandonment of these systems in many jurisdictions.

Key Findings

▶ Watch: Explaining receipt-freeness, coercion resistance, and end-to-end verifiability (2:00)

Michael Specter's analysis of the Votes mobile app and Democracy Live web application revealed systemic security deficiencies across both platforms, leading to their widespread rejection or limitation in various jurisdictions. The core impact of his research was immediate: all jurisdictions except Utah County, Utah, dropped Votes for the primary, and New Jersey and Delaware halted or severely limited the use of Democracy Live, often restricting it to ballot delivery only (where voters would print, mark, and mail their ballots).

Specter's methodology involved assuming various adversaries with specific powers and illustrating potential attacks. These adversaries included on-device malware, company servers, network adversaries (e.g., an ISP), and third parties involved in the system. Crucially, neither Votes nor Democracy Live achieved the fundamental security goals of End-to-End (E2E) Verifiability, Receipt-freeness, or Coercion Resistance.

For the Votes mobile app, key findings included:

• Bypassable Malware Detection: Votes utilized a third-party in-app antivirus called Zmpirium. However, if an attacker controlled the device (e.g., via root access), they could disable Zmpirium by manipulating the Java runtime, making it report a "clean" device. With Zmpirium disabled, the attacker had complete control, compromising all communications and rendering any receipts meaningless.
• Vulnerable Vote History Database: The app stored a user's vote history and authentication credentials in an encrypted on-device database, protected by an 8-digit numeral-only PIN. While the encryption key was tied to the Android KeyStore and fingerprint authentication (when available), the limited PIN space (10^8 combinations) made it vulnerable to brute-force attacks. Specter calculated that with a guess rate of 0.5 milliseconds per attempt, an attacker with forensic access could decrypt the database in roughly 1.5 hours, gaining access to past votes and voter authentication data.
• Custom Cryptography Flaws: Votes implemented a highly unusual custom cryptographic protocol on top of standard HTTPS (TLS). After establishing a TLS connection, it would generate 100 ECDSA key pairs, discard all but the 57th secret key, and send 100 public keys to the server. The server would perform a similar process, and then a shared AES-GCM key would be derived from the 57th key agreement. Specter noted this was "incredibly strange" and likely intended for obfuscation rather than security. More critically, the protocol lacked server public key verification, enabling active man-in-the-middle (MITM) attacks. Furthermore, nothing was ever signed from the device, meaning the API server could unilaterally alter or dismiss votes without detection. There was no E2E verifiability protocol, nor any clear involvement of the promised blockchain.
• Ciphertext Length Leakage (Network Adversary): When a voter submitted their ballot, the app sent the metadata only for their selected candidate. Votes' custom protocol encrypted this data before compression, unlike standard HTTPS which compresses (e.g., via gzip) before encryption. This meant the ciphertext length directly correlated to the length of the uncompressed data (e.g., candidate description). A passive network adversary (like an ISP) could observe the packet sizes and infer the voter's selection, compromising ballot privacy.
• Third-Party PII Exposure: Votes used Jumio for identity verification, which required users to submit photos of their ID and face, along with their device's GPS location. This sensitive Personally Identifiable Information (PII) was sent to Jumio's servers (whose developers are predominantly in India), enabling a third party to reject applications and collect highly personal data, including the precise location of military voters in theater.

For the Democracy Live web app, key findings included:

• Similar Broad Vulnerabilities: As a web application running on AWS, it shared many of the same vulnerabilities to on-device malware, compromised company servers, and network adversaries (though Specter noted they "didn't try to do anything more because at a certain point it was like kicking a dead horse"). It also lacked E2E verifiability, receipt-freeness, and coercion resistance.
• Extensive PII Collection and Tracking: Democracy Live collected the voter's name, address, date of birth, Social Security Number, and a browser fingerprint (a highly persistent user tracking agent, unlike clearable cookies).
• Google Analytics Integration: The system used Google Analytics, transmitting voter IDs and party affiliations to Google.
• No Privacy Policy: The absence of a clear privacy policy meant Democracy Live could, as far as was known, do "whatever they want with this data."
• Secret Ballot Uploads: Even when voters intended to print and physically mail their ballots, Democracy Live often uploaded their secret ballot selections to its servers, collecting sensitive information without the voter's explicit knowledge or consent.

Specter concludes that the idealized vision of "trusting the beauty and purity of mathematics" in internet voting ultimately devolves into "trusting these companies, the browser, the internet connection, the hosting services, myriad third parties, and even mobile phone developers like OPPO and OnePlus," significantly complicating the security landscape.

Technical Deep Dive

▶ Watch: Sociotechnical system for in-person voting security (3:30)

The technical vulnerabilities uncovered by Specter's team highlight fundamental design and implementation flaws in deployed internet voting systems. The analysis of Votes' custom cryptography and its impact on privacy is particularly illuminating.

Votes' Custom Cryptographic Protocol:

Votes attempted to layer its own cryptographic protocol on top of TLS (Transport Layer Security), which is the standard encryption used for secure web communication (HTTPS). The sequence of operations was highly unusual:

1. An initial standard HTTPS connection was established, providing baseline transport encryption.
2. The voter's device then generated 100 ECDSA (Elliptic Curve Digital Signature Algorithm) key pairs (public and private keys).
3. Curiously, the device would then discard all secret keys except for the 57th one.
4. All 100 public keys were then transmitted to the Votes server.
5. The Votes server mirrored this process, generating its own 100 key pairs and selecting its 57th.
6. A key agreement (likely using ECDH, Elliptic Curve Diffie-Hellman) was performed using the 57th selected keys from both sides.
7. This key agreement then generated an AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) shared key.
8. All subsequent communication was encrypted using this derived AES-GCM key.

Specter characterized this as "incredibly strange" and primarily an act of obfuscation. While AES-GCM is a strong symmetric encryption algorithm, layering it on top of an already encrypted TLS channel without a clear security benefit raised immediate red flags. The arbitrary selection of the 57th key seemed designed to confuse an observer analyzing network traffic with tools like Wireshark or tcpdump.

The critical security flaws in this custom protocol were:

• No Server Public Key Verification: The client device did not verify the server's public key. This omission is a cardinal sin in secure communication, making the system vulnerable to active man-in-the-middle (MITM) attacks. An attacker could intercept the connection, impersonate the Votes server, and exchange keys with the client, thereby decrypting and re-encrypting all traffic.
• No Device Signing or Non-Ephemeral Keys: The device never sent a non-ephemeral public key and never signed any communication. This means that the Votes API server had complete unilateral control over the data. There was no cryptographic proof that the vote originated from the user's device or that it hadn't been tampered with by the server. This directly undermines E2E verifiability.
• Lack of Blockchain Integration: Despite claims of blockchain involvement, Specter's analysis found no evidence of communication with a blockchain or any mechanism to prove that a vote was recorded on one.

Ciphertext Length Leakage Attack (Network Adversary):

This vulnerability demonstrates how even seemingly innocuous information like packet size can compromise privacy when cryptographic protocols are misused.

• When a voter interacted with the Votes app, the ballot configuration was generated from JSON (JavaScript Object Notation) data. This JSON included metadata for each candidate, such as descriptions and URLs.
• Crucially, when a voter submitted their ballot, the app transmitted **only the metadata of the selected candidate**, not a generic "option 1" or "candidate B."
• Votes' custom cryptographic protocol encrypted this data before any compression could occur. In contrast, standard HTTPS connections typically gzip-compress data before encryption. Gzip compression significantly reduces the size of the data and helps to obfuscate the original content's length, making it harder to infer information.
• Because Votes encrypted uncompressed data, the length of the resulting ciphertext was roughly equivalent to the length of the original data.
• Specter illustrated this with a graph: if a candidate had a short description and another had a long description, the packet size for a vote cast for the former would be noticeably smaller than for the latter.
• This allowed an unprivileged network adversary (e.g., an ISP or a compromised Wi-Fi router) to observe the size of the encrypted packets. By mapping packet lengths to known candidate metadata lengths, the adversary could infer which candidate a voter selected, effectively breaking ballot secrecy. This is a classic side-channel attack based on data length.

PIN Brute-Force Attack on On-Device Database:

The Votes app stored sensitive user data, including vote history and authentication credentials, in an encrypted database on the device. While this database was protected by a PIN and Android KeyStore, the implementation was weak:

• The PIN was 8 digits long and numeral-only.
• This limited the keyspace to 10^8 (100 million) possible combinations.
• Specter calculated that a forensic attacker could attempt a PIN guess every 0.5 milliseconds.
• This translates to being able to brute-force the PIN and decrypt the database in approximately 1.5 hours. This vulnerability allows an attacker with post-election device access to uncover a voter's entire vote history.

Zmpirium Bypass:

Votes integrated Zmpirium, a third-party in-app antivirus, to scan the device for malware and exploits. However, this protection could be trivially bypassed:

• If an attacker had control over the device (e.g., through rooting or a separate malware infection), they could manipulate the Java runtime environment where Zmpirium executed.
• By intercepting Zmpirium's calls or modifying its execution flow, the attacker could force it to return a "device clean" status, regardless of actual device integrity. This rendered Zmpirium's presence meaningless, allowing the attacker to maintain full control over the voting process on the device.

These technical deep dives illustrate that the systems were not merely imperfect but fundamentally insecure, failing to uphold basic cryptographic principles and introducing novel vulnerabilities through their custom and poorly implemented security measures.

Demo / Proof of Concept

▶ Watch: Arguments for internet voting: complexity reduction and increased access (5:30)

While Michael Specter's talk did not feature a live, interactive demonstration of an exploit, the presentation included detailed explanations and visual aids that served as compelling proofs of concept for the identified vulnerabilities. For instance, the discussion of the ciphertext length leakage included a hypothetical graph illustrating how packet sizes would differ when voting for candidates with short versus long descriptions. This visual representation clearly demonstrated how a network adversary could infer a voter's choice by merely observing encrypted packet lengths, effectively acting as a proof of concept for the side-channel attack.

Similarly, the explanation of the 8-digit PIN brute-force attack was accompanied by a calculation of the time required (1.5 hours), which quantifies the feasibility of the attack. The method for bypassing the Zmpirium in-app antivirus was described in terms of controlling the Java runtime, outlining the logical steps an attacker would take. The custom cryptographic protocol's flaws were detailed with diagrams showing the sequence of key exchanges and encryption layers, highlighting the lack of server public key verification and device signing.

In essence, Specter's presentation functioned as a detailed technical walk-through of the attack vectors, providing sufficient information and conceptual evidence to validate the existence and impact of the flaws, even without a real-time exploit execution. The research papers themselves, on which the talk is based, would contain the full technical specifics and potentially code snippets or experimental setups used to confirm these vulnerabilities.

Defensive Implications

▶ Watch: Historical cryptographic research on internet voting systems (6:50)

The findings presented by Michael Specter carry profound defensive implications for election officials, policymakers, and the broader security community. The core message is clear: internet voting systems, as currently deployed, are not safe for high-stakes elections.

1. Avoid Internet Voting for High-Stakes Elections: The most direct implication is that jurisdictions should cease or, at minimum, severely restrict the use of internet voting systems for federal or state elections. The inherent complexity of securing end-user devices, combined with the demonstrated flaws in vendor implementations, makes these systems vulnerable to scalable and remote attacks that could compromise entire election outcomes.
2. Mandate Pre-Deployment Independent Security Audits: Specter's research highlights a recurring problem: systems are deployed before any public, independent security analysis. Election officials must demand rigorous, public security audits by qualified, neutral third parties before any internet voting system is put into use. These audits should not be limited to vendor-provided documentation but involve full access to code, network traffic, and system architecture.
3. Demand Formal Documentation and Cryptographic Rigor: Vendors often use vague or misleading terms like "doubly anonymized" or "E2E vote encryption" without adhering to established cryptographic definitions. Election officials must insist on formal, peer-reviewed cryptographic specifications and clear, verifiable documentation of all protocols and security mechanisms. Any claims must be backed by transparent evidence and adhere to industry best practices.
4. Understand the Full Trust Chain: The talk underscores that internet voting introduces trust in a vast ecosystem of third parties, including hosting providers (AWS), identity verification services (Jumio), analytics providers (Google Analytics), and even mobile OS and device manufacturers (Oppo, OnePlus). Election officials need to conduct thorough supply chain risk assessments for every component and service involved, recognizing that a compromise anywhere in this chain can undermine the entire system.
5. Prioritize Privacy and Data Minimization: The extensive collection of Personally Identifiable Information (PII), browser fingerprints, and voter IDs, often transmitted to third parties without explicit consent or clear privacy policies, is unacceptable. Any voting system must adhere to strict principles of data minimization and ensure that sensitive voter data is neither collected unnecessarily nor shared with external entities.
6. Support Legal Protections for Good-Faith Security Research: The vendor hostility and legal threats faced by Specter and other researchers (including the Computer Fraud and Abuse Act concerns) create a chilling effect on essential public interest security research. Policymakers must enact legislation that explicitly protects good-faith security researchers from legal repercussions when identifying and responsibly disclosing vulnerabilities in critical infrastructure, including election systems.
7. Invest in Robust Certification and Regulation: The current voting systems market is "largely unregulated," leading to "market failure" where poor security is a "rational choice" for vendors due to information asymmetry. Stronger federal and state regulations, coupled with mandatory, transparent certification processes that prioritize security over convenience or cost, are essential to break this cycle.
8. Proactive Engagement with Researchers: Specter explicitly calls for collaboration with election officials, indicating his lab's willingness to engage before systems are deployed. Establishing channels for proactive engagement with academic and independent security researchers can help identify and mitigate issues early, fostering a culture of transparency and continuous improvement rather than adversarial confrontation.
9. Focus Cryptography Efforts on Solvable Problems: While internet voting for casting and tallying remains intractable, researchers should focus cryptographic efforts on other areas of election security where they can provide genuine benefits, such as secure voter registration, audit mechanisms for paper-based systems, or post-election audits.

In summary, defenders—election officials, IT security teams, and policymakers—must adopt a highly skeptical and risk-averse stance towards internet voting. The current state of practice demonstrates that the risks far outweigh any perceived benefits, demanding a fundamental re-evaluation of how technology is integrated into the democratic process.

Key Takeaways

• Internet voting is fundamentally hard: Securing internet voting systems is incredibly challenging in theory and even more so in practice, leading to scalable and remote attacks that can compromise election integrity.
• Deployed systems lack core security guarantees: Existing internet voting systems consistently fail to achieve essential properties like End-to-End Verifiability, Receipt-freeness, and Coercion Resistance, making them vulnerable to manipulation and privacy breaches.
• Expanded trust perimeter and third-party risks: Introducing internet or mobile voting inevitably extends the trust boundary to numerous unexpected third parties (e.g., hosting providers, identity verification services, analytics companies, mobile OS developers), each representing a potential point of failure or compromise.
• Cryptography alone is not a panacea: Simply applying cryptography does not solve the fundamental challenges of internet voting. Poor implementation, custom protocols, and a focus on obfuscation rather than rigorous design often introduce new vulnerabilities, while core issues like access and privacy remain unaddressed.
• Unsustainable "deploy, research, press, fix" cycle: The current model of deploying insecure systems, followed by independent researchers identifying flaws, public outcry, and then limited fixes, is unsustainable and indicative of a market failure driven by a lack of regulation and transparency.
• Urgent need for policy, regulation, and research protection: Stronger regulations, mandatory pre-deployment public security audits, and legal protections for good-faith security research (e.g., reform of the Computer Fraud and Abuse Act) are critical to breaking the cycle of insecurity and safeguarding democratic elections.

About the Speaker(s)

Michael Specter is an Assistant Professor at Georgia Tech, where he leads a laboratory focused on security, privacy, and democracy. His research delves into issues related to applied cryptography, system security, and policy, often intersecting with law and economics. Prior to joining Georgia Tech, Specter conducted the pivotal research presented in this talk during his PhD in Electrical Engineering and Computer Science (EECS) at MIT. Following his doctoral studies, he served as a Senior Research Scientist at Google, further solidifying his expertise in large-scale system security. His work consistently highlights the critical importance of rigorous security analysis in civic systems and the broader implications of technology on democratic processes.