E-Voting Hack-a-Vote: Security Issues with Electronic Voting Systems In a quest for election legitimacy, officials are increasingly deploying direct recording electronic (DRE) voting systems. A project to assess their trustworthiness revealed both the ease of introducing bugs into such systems and the difficulty of detecting them during audits. JONATHAN he democratic process rests on a fair, universally According to BANNET, DAVID accessible voting system through which all citi- analysts, this flawed W. PRICE, zens can easily and accurately cast a vote. With state is the result of undisciplined software development and ALGIS RUDYS, T the 2000 US presidential election, however, the a process that failed to encourage developers to anticipate or JUSTIN SINGER, country got a firsthand look at the results of a flawed vot- fix security holes. The closed-source approach to software AND DAN S. ing system, which fueled renewed public interest in vot- development, which shielded the source code from public WALLACH ing system reliability. People became especially en- review and comment, only served to delay the necessary Rice chanted by the computer’s siren song, so election officials scrutiny. Of course, as daily headlines demonstrate, neither a University have increasingly examined and adopted voting systems commitment to software security nor an open-source ap- that rely primarily on computers to record and tabulate proach to software development prevents software security votes. Much of their attention has centered on direct holes. (For example, see www.cert.org/advisories, which recording electronic (DRE) voting systems, which com- lists security holes that have been discovered in the past year.) pletely eliminate paper ballots. Software developers and auditors who follow standard soft- DRE voting systems have some inherent advantages ware engineering practices have proven unable to ship bug- over paper-based voting schemes, including a decrease free software. In general, producing software free from all se- in voter error. If the system’s interface has been well de- curity holes is significantly harder than an attacker’s goal: to signed, for example, it seeks confirmation if the voter find and exploit a single bug. fails to cast a vote in a particular race and disallows mul- We recently conducted a project to demonstrate that tiple votes in the same race. DREs also make it possible electronic voting software is not immune from these secu- to accommodate people with different disabilities, help- rity concerns. Here, we describe Hack-a-Vote, a simplified ing them vote without human assistance. Unfortu- DRE voting system that we initially developed to demon- nately, recent analyses of one popular vendor’s DRE strate how easy it might be to insert a Trojan horse into a voting system indicated numerous security over- voting system. Having accomplished this, we used Hack-a- sights,1,2 including Vote in an associated course project, in which student teams implemented their own Trojan horses, then searched the • Voters can cast multiple votes without leaving a trace. source code for their classmates’ malicious code. The Hack- • Anyone with access to a voting machine can perform a-Vote project revealed the potential damage individuals administrative actions, including viewing partial results can cause with electronic voting systems, the feasibility of and terminating an election early. finding system weaknesses (deliberate or otherwise), and • Communications between voting terminals and the some solutions to mitigate the damage. Hack-a-Vote and central server are not properly encrypted, making it our course assignment are freely available online at www. possible for a malicious “man in the middle” to alter cs.rice.edu/~dwallach/courses/comp527_f2003/vote communication content. project.html. 32 PUBLISHED BY THE IEEE COMPUTER SOCIETY I 1540-7993/04/$20.00 © 2004 IEEE I IEEE SECURITY & PRIVACY E-Voting The Hack-a-Vote system Our demonstration voting machine is a relatively simple Java Swing application that weighs in at about 2,000 lines of code. It has a GUI front end for user interaction, a back end for reading-in election configurations and writing- out ballot images, and voting logic that drives the GUI and records votes. Hack-a-Vote first authenticates the user with a simple PIN authentication scheme inspired by Hart Intercivic’s eSlate (www.hartintercivic.com/solutions/eslate.html), which is used for elections in Houston, Texas, among (a) (b) other places. With eSlate, voters first sign in at their local voting precinct. Every group of eSlate voting terminals is Figure 1. The initial Hack-a-Vote screens. (a) The PIN login screen. connected via a wired network to an election manage- Once a voter enters a PIN, the system invalidates it for future use. ment console. The user approaches the console, and an (b) Following authentication, the system displays selection screens election official prints him or her a four-digit PIN; the containing a series of races. user then goes to any available voting terminal and enters this PIN. Once eSlate validates the PIN, the user can vote. Similarly, in the Hack-a-Vote implementation, the server maintains a list of a few valid PINs that are displayed to the election administrator (we didn’t bother to print the PINs, although it would be an easy extension to add). Once a voter uses a PIN, the system invalidates it and ran- domly generates a new one. Figure 1a shows the PIN login screen. Following authentication, users are presented with voting screens containing a series of races (see Figure 1b). Once they’ve cast a vote in every race, they can view and confirm a summary of their votes (see Figure 2a). When (a) (b) the user confirms the selected candidates, the machine cycles back to the PIN entry screen for the next voter. Figure 2. Additional screens. (a) The Hack-a-Vote confirmation Otherwise, the machine returns to the first ballot and lets screen offers a summary after users have voted. (b) The final tally users change their selections. Once the election closes, screen. the system randomly shuffles and tallies all votes and writes them out to disk. The machine then displays the final tally, as Figure 2b shows. asked students to consider the security threats of running In Hack-a-Vote’s original implementation, we added a national lottery.3 a Trojan horse to the code that prepares votes for writing For Hack-a-Vote, we split students in Comp527, a out to disk. By adding a few extra command-line options, graduate-level computer security course, into groups of we made it possible for the user to indicate a candidate or two for a three-part assignment. For the project’s first political party that should receive extra votes. With a con- phase, the groups assumed the role of Hack-a-Vote devel- figurable probability, the system would modify votes for opers who were paid off by a nefarious organization to rig other candidates before writing them to disk and count- an election without getting caught. We placed no require- ing them. In the student version, we removed the cheat- ments on the type of malicious hack, so long as students ing code (about 150 lines in one file). could justify how it could be used to ruin or bias an elec- tion without being detected. Solutions could thus run the The Hack-a-Vote assignment gamut from denial-of-service attacks to arbitrary biases in The Hack-a-Vote project introduces students to some of the final election tally. The groups spent two weeks pep- the many faces of security, from the malicious hacker’s de- pering their voting machines with Trojans horses. sign of subtle system attacks, to the auditing required to In the second phase, each group received modified uncover those attacks, to the higher level challenges of se- voting systems from two other randomly selected groups cure system design. The project also raises policy implica- in their class. They now assumed the role of independent tions for how governments might regulate voting sys- auditors, with one week to find any security-critical flaws tems. The Hack-a-Vote project was inspired in part by in the altered code. In this phase, we prohibited any direct Ross Anderson’s UK lottery experiment, in which he comparison with the original code, requiring students to www.computer.org/security/ I IEEE SECURITY & PRIVACY 33 E-Voting rely solely on their memory of the voting machine and its class’s hashCode() and equals() methods, the group functionality—a requirement enforced by the university’s made it appear to the hash table that two candidates were honor code. (Otherwise, students could easily locate the same if one’s name was a prefix of the other. As a re- changes using the UNIX diff tool, giving them greater sult, one of the candidates would get all of the other can- powers than a genuine auditor might have when studying didate’s votes, and the other candidate would not appear a voting system.) in the tally at all. Such subtle changes, which can signifi- In the final phase, the focus shifted: We gave students cantly influence an election’s outcome, would go unde- two and a half weeks to fix a problem discovered in the tected by most forms of testing. Diebold voting machine’s smartcard authentication pro- tocol.2 Students first had to consider what security threats Broken authentication a voting system faces. They then designed an improved Groups used several techniques to break Hack-a-Vote’s authentication protocol and used Cryptyc, a crypto- authentication scheme. Among the most common were graphic protocol type checker,4 to model and verify the using back doors to vote without a PIN.