Analysis of the Diebold AccuVoteTS Voting Machine
Center for Information Technology Policy and
Dept. of Computer Science at Princeton University
Security Analysis of the Diebold AccuVoteTS Voting Machine
Ariel J. Feldman*, J. Alex Halderman*, and Edward W. Felten*,†
Center for Information Technology Policy and Dept. of Computer Science, Princeton University
†Woodrow Wilson School of Public and International Affairs, Princeton University
September 13, 2006
This paper presents a fully independent security study of a Diebold AccuVoteTS voting machine, including its hardware and software. We obtained the machine from a private party. Analysis of the machine, in light of real election procedures, shows that it is vulnerable to extremely serious attacks. For example, an attacker who gets physical access to a machine or its removable memory card for as little as one minute could install malicious code; malicious code on a machine could steal votes undetectably, modifying all records, logs, and counters to be consistent with the fraudulent vote count it creates. An attacker could also create malicious code that spreads automatically and silently from machine to machine during normal election activities—a votingmachine virus. We have constructed working demonstrations of these attacks in our lab. Mitigating these threats will require changes to the voting machine’s hardware and software and the adoption of more rigorous election procedures.
The Diebold AccuVoteTS and its newer relative the AccuVoteTSx are together the most widely deployed electronic voting platform in the United States . In the November 2006 general election, these machines are scheduled to be used
in 357 counties representing nearly 10% of registered voters. Approximately half these counties—including all of Maryland and Georgia—will employ the AccuVoteTS model. More than 33,000 of the TS machines are in service nationwide.
This paper reports on our study of an AccuVoteTS, which we obtained from a private party. We analyzed the machine’s hardware and software, performed experiments on it, and considered whether real election practices would leave it suitably secure. We found that the machine is vulnerable to a number of extremely serious attacks that undermine the accuracy and credibility of the vote counts it produces.
The Diebold AccuVoteTS voting machine in our lab
Computer scientists have generally been skeptical of voting systems of this type, Direct Recording Electronic (DRE), which are essentially generalpurpose computers running specialized election software. Experience with computer systems of all kinds shows that it is exceedingly difﬁcult to ensure the reliability and security of complex software or to detect and diagnose problems when they do occur. Yet DREs rely fundamentally on the correct and secure operation of complex software programs. Simply put, many computer scientists doubt that paperless DREs can be made reliable and secure, and they expect that any failures of such systems would likely go undetected.
Previous security studies of DREs afﬁrm this skepticism (e.g., [4, 14, 17, 24, 30]), but to our knowledge ours is the ﬁrst public study encompassing the hardware and software of a widely used DRE. The famous paper by Kohno, Stubbleﬁeld, Rubin, and Wallach  studied a leaked version of the source code for parts of the Diebold AccuVoteTS software and found many design errors and vulnerabilities, which are generally conﬁrmed by our study. Our study extends theirs by including the machine’s hardware and operational details, by ﬁnding and describing several new and serious vulnerabilities, and by building working demonstrations of several security attacks.
The main ﬁndings of our study are:
Malicious software running on a single voting machine can steal votes with little if any risk of detection. The malicious software can modify all of the records, audit logs, and counters kept by the voting machine, so that even careful forensic examination of these records will ﬁnd nothing amiss. We have constructed demonstration software that carries out this votestealing attack.
Anyone who has physical access to a voting machine, or to a memory card that will later be inserted into a machine, can install said malicious software using a simple method that takes as little as one minute. In practice, poll workers and others often have unsupervised access to the machines.
AccuVoteTS machines are susceptible to votingmachine viruses—computer viruses that can spread malicious software automatically and invisibly from machine to machine during normal preand postelection activity. We have constructed a demonstration virus that spreads in this way, installing our demonstration votestealing program on every machine it infects.
While some of these problems can be eliminated by improving Diebold’s software, others cannot be remedied without replacing the machines’ hardware. Changes to election procedures would also be required to ensure security.
The details of our analysis appear below, in the main body of this paper. Given our ﬁndings, we believe urgent action is needed to address these problems. We discuss potential mitigation strategies in more detail below in Section 5.
The machine we obtained came loaded with version 4.3.15 of the Diebold BallotStation software that runs the machine during an election.1
This version was deployed in 2002 and certiﬁed by the National Association of State Election Directors (NASED) . While some of the problems we identify in this report may have been remedied in subsequent software releases (current versions are in the 4.6 series), others are architectural in nature and cannot easily be repaired by software changes. In any case, subsequent versions of the software should be assumed insecure until fully independent examination proves otherwise.
Though we studied a speciﬁc voting technology, we expect that a similar study of another DRE system, whether from Diebold or another vendor, would raise similar concerns about malicious code injection attacks and other problems. We studied the Diebold system because we had access to it, not because it is
1The behavior of our machine conformed almost exactly to the behavior speciﬁed by the source code to BallotStation version 4.3.1, which leaked to the public in 2003.
necessarily less secure than competing DREs. All DREs face fundamental security challenges that are not easily overcome.
Despite these problems, we believe that it is possible, at reasonable cost, to build a DREbased voting
system—including hardware, software, and election procedures—that is suitably secure and reliable. Such a system would require not only a voting machine designed with more care and attention to security, but also an array of safeguards, including a welldesigned voterveriﬁable paper audit trail system, random audits and forensic analyses, and truly independent security review.2
Structure of the Paper
The remainder of this paper is structured as follows. Section 2 describes several classes of attacks against the AccuVoteTS machine as well as routes for injecting malicious code. Section 3 discusses the machine’s design and its operation in a typical election, focusing on design mistakes that make attacks possible. Section 4 details our implementation of demonstration attacks that illustrate the security problems. Section 5 examines the feasibility of several strategies for mitigating all of these problems. Section 6 outlines prior research on the AccuVote system and DREs more generally. Finally, Section 7 offers concluding remarks.
2 Attack Scenarios
Elections that rely on Diebold DREs like the one we studied are vulnerable to several serious attacks. Many of these vulnerabilities arise because the machine does not even attempt to verify the authenticity of the code it executes. In this section we describe two classes of attacks—vote stealing and denialofservice— that involve injecting malicious code into the voting machine. We then outline several methods by which code can be injected and discuss the difﬁculty of removing malicious code after a suspected attack.
2.1 Classes of Attacks
2.1.1 VoteStealing Attacks
The AccuVoteTS machine we studied is vulnerable to attacks that steal votes from one candidate and give them to another. Such attacks can be carried out without leaving any evidence of fraud in the system’s logs. We have implemented a demonstration attack to prove that this is possible; it is described in Section 4.2.
To avoid detection, a votestealing attack must transfer votes from one candidate to another, leaving the total number of votes unchanged so that poll workers do not notice any discrepancy in the number of votes reported. Attacks that only add votes or only subtract votes would be detected when poll workers compared the total vote count to the number of voters who checked in at the front desk.3
The machine we studied maintains two records of each vote—one in its internal ﬂash memory and one on a removable memory card. These records are encrypted, but the encryption is not an effective barrier to a votestealing attack. Malicious software running on the machine would modify both redundant copies of the record for each vote it altered. Although the voting machine also keeps various logs and counters that record a history of the machine’s use, a successful votestealing attack would modify these records so they were consistent with the fraudulent history that the attacker was constructing. In the Diebold DRE we studied, these records are stored in ordinary ﬂash memory, so they are freely modiﬁable by malicious software.
2Current testing agencies are often referred to as “independent testing agencies” (ITAs), but “independent” is a misnomer, as they are paid by and report to the voting machine vendor.
3It might be possible to subtract a few votes without detection (if poll workers interpret the missing votes as voters who did not vote in that race) or to add a few votes to compensate for real voters who did not cast ballots; but in any case transferring votes from one candidate to another is a more effective attack.
Such malicious software can be grafted into the BallotStation election software (by modifying and recompiling BallotStation if the attacker has the BallotStation source code, or by modifying the BallotStation binary), it can be delivered as a separate program that runs at the same time as BallotStation, it can be grafted into the operating system or bootloader, or it can occupy a virtualized layer below the bootloader and operating system . The machine contains no security mechanisms that would detect a well designed attack using any of these methods. However it is packaged, the attack software can modify each vote as it is cast, or it can wait and rewrite the machine’s records later, as long as the modiﬁcations are made before the election is completed.
The attack code might be constructed to modify the machine’s state only when the machine is in election mode and avoid modifying the state when the machine is performing other functions such as preelection logic and accuracy testing. The code could also be programmed to operate only on election days. (Elections are often held according to a wellknown schedule—for example, U.S. presidential and congressional elections are held on the Tuesday following the ﬁrst Monday of November, in evennumbered years.) Obviously, it could be programmed to operate only on
election days, or only at certain times of day.
By these methods, malicious code installed by an adversary could steal votes without being detected by election ofﬁcials.4
Vote counts would add up correctly, the total number of votes recorded on the machine would be correct, and the machine’s logs and counters would be consistent with the results reported—but the results would be fraudulent.
2.1.2 DenialofService Attacks
Denialofservice (DoS) attacks aim to make voting machines unavailable on election day or to deny ofﬁcials access to the vote tallies when the election ends. It is often known in advance that voters at certain precincts, or at certain times, will vote disproportionately for one party or candidate. A targeted DoS attack can be designed to distort election results or to spoil an election that appears to be favoring one party or candidate. Several kinds of DoS attacks are practical because of the ease with which malicious code may be executed on the voting machines.
One style of DoS attack would make voting machines unavailable on election day. For example, malicious code could be programmed to make the machine crash or malfunction at a preprogrammed time, perhaps only in certain polling places. In an extreme example, an attack could strike on election day, perhaps late in the day, and completely wipe out the state of the machine by erasing its ﬂash memory. This would destroy all records of the election in progress, as well as the bootloader, operating system, and election software. The machine would refuse to boot or otherwise function. The only way to restore such a machine to a working state would be to have a service technician visit, install a special EPROM chip on the machine’s motherboard, and reboot the machine from that EPROM. If many machines failed at once, available technicians would be overwhelmed. The result would be a fresh install of the machine’s software, with all records of past and current elections still lost. (We have created a demonstration version of this attack, which is described below in Section 4.4.) A similar style of DoS attack would try to spoil an election by modifying the machine’s vote counts or logs in a manner that would be easy to detect but impossible to correct, such as by injecting malicious code that adds or removes so many votes that the results at the end of the day are obviously wrong. A widespread DoS attack of either style could require the election to be redone.
4Ofﬁcials might try to detect such an attack by parallel testing. As we describe in Section 5.3, an attacker has various countermeasures to limit the effectiveness of such testing.
2.2 Injecting Attack Code
To carry out these attacks, the attacker must somehow install his malicious software on one or more voting machines. If he can get physical access to a machine for as little as one minute, he can install the software manually. The attacker can also install a voting machine virus that spreads to other machines, allowing him to commit widespread fraud even if he only has physical access to one machine or memory card.
2.2.1 Direct Installation
An attacker with physical access to a machine would have least three methods of installing malicious software . The ﬁrst is to create an EPROM chip containing a program that will install the attack code into the machine’s ﬂash memory, and then to open the machine, install the chip on its motherboard, and reboot from the EPROM.5
The second method is to exploit a back door feature in Diebold’s code to manually install the attack ﬁles from a memory card. When the machine boots, it checks whether a ﬁle named
exists on the removable memory card. If such a ﬁle is present, the machine boots into Windows Explorer rather than Diebold’s BallotStation election software. An attacker could insert a memory card containing this ﬁle, reboot the machine, and then use Explorer to copy the attack ﬁles onto the machine or run them directly from the card.
The third method exploits a service feature of the machine’s bootloader. On startup, the machine checks the removable memory card for a ﬁle named
fboot.nb0. If this ﬁle exists, the machine replaces the bootloader code in its onboard ﬂash memory with the ﬁle’s contents. An attacker could program a malicious bootloader, store it on a memory card as
fboot.nb0, and reboot the machine with this card inserted, causing the Diebold bootloader to install the malicious software. (A similar method would create a malicious operating system image.)
The ﬁrst method requires the attacker to remove several screws and lift off the top of the machine to get access to the motherboard and EPROM. The other methods only require access to the memory card slot and power button, which are both behind a locked door on the side of the machine. The lock is easily picked—one member of our group, who has modest locksmithing skills, can pick the lock consistently in less than 10 seconds. Alternatively, this slot can be reached by removing screws and opening the machine. Some attackers will have access to keys that can open the lock—all AccuVoteTS machines in certain states use identical keys , there are thousands of keys in existence, and these keys can be copied at a hardware or lock store.
A poll worker, election ofﬁcial, technician, or other person who had private access to a machine for as little as one minute could use these methods without detection. Poll workers often do have such access; for instance, in a widespread practice called “sleepovers,” machines are sent home with poll workers the night before the election .
2.2.2 Voting Machine Viruses
Rather than injecting code into each machine directly, an attacker could create a computer virus that would spread from one voting machine to another. Once installed on a single “seed” machine, the virus would spread to other machines by methods described below, allowing an attacker with physical access to one machine (or card) to infect a potentially large population of machines. The virus could be programmed to install malicious software, such as a votestealing program or denialofservice attack, on every machine it infected.
5When the machine is rebooted, it normally emits a musical chime that might be noticed during a stealth attack; but this sound can be suppressed by plugging headphones (or just a headphone connector) into the machine’s headphone jack.
To prove that this is possible, we constructed a demonstration virus that spreads itself automatically from machine to machine, installing our demonstration votestealing software on each infected system. Our demonstration virus, described in Section 4.3, can infect machines and memory cards. An infected machine will infect any memory card that is inserted into it. An infected memory card will infect any machine that is powered up or rebooted with the memory card inserted. Because cards are transferred between machines during vote counting and administrative activities, the infected population will grow over time.
Diebold delivers software upgrades to the machines via memory cards: a technician inserts a memory card containing the updated code and then reboots the machine, causing the bootloader to install the new code from the memory card. This upgrade method relies on the correct functioning of the machine’s bootloader, which is supposed to copy the upgraded code from the memory card into the machine’s ﬂash memory. But if the bootloader were already infected by a virus, then the virus could make the bootloader behave differently. For example, the bootloader could pretend to install the updates as expected but instead secretly propagate the virus onto the memory card. If the technician later used the same memory card to “upgrade” other machines, he would in fact be installing the virus on them. Our demonstration virus illustrates these spreading techniques.
Memory cards are also transferred between machines in the process of transmitting election deﬁnition ﬁles to voting machines before an election. According to Diebold,
Data is downloaded onto the [memory] cards using a few [AccuVote] units, and then the stacks
of [memory] cards are inserted into the thousands of [AccuVote] terminals to be sent to the
(, p. 13) If one of the few units that download the data is infected, it will transfer the infection via the “stacks of [memory] cards” into many voting machines.
2.3 Difﬁculty of Recovery
If a voting machine has been infected with malicious code, or even if infection is suspected, it is necessary to disinfect the machine. The only safe way to do this is to put the machine back into a knownsafe state, by, for example, overwriting all of its stable storage with a known conﬁguration.
This is difﬁcult to do reliably. We cannot depend on the normal method for installing ﬁrmware upgrades from memory cards, because this method relies on the correct functioning of the bootloader, which might have been tampered with by an attacker. There is no foolproof way to tell whether an update presented in this way really has been installed safely.
The only assured way to revert the machine to a safe state is to boot from EPROM. This involves making an EPROM chip containing an update tool, inserting the EPROM chip into the motherboard, setting the machine to boot from the chip, and powering it on. On boot, the EPROMbased updater would overwrite the onboard ﬂash memory, restoring the machine to a known state. Since this procedure involves the insertion (and later removal) of a chip, it would probably require a service technician to visit each machine.
If the disinfection process only reinstalled the software that was currently supposed to be running on the machines, then the possibility of infection by malicious code would persist. Instead, the voting machine software software should be modiﬁed to defend against installation and viral spreading of unauthorized code. We discuss in Section 5 what software changes are possible and which attacks can be prevented.
3 Design and Operation of the AccuVoteTS
Before presenting the demonstration attacks we implemented, we will ﬁrst describe the design and operation of the AccuVoteTS machine and point out design choices that have led to vulnerabilities.
The machine (pictured on page 1) interacts with the user via an integrated touchscreen LCD display. It authenticates voters and election ofﬁcials using a motorized smart card reader, which pulls in cards after they are inserted and ejects them when commanded by software. On the right side of the machine is a headphone jack and keypad port for use by people with disabilities, and a small metal door with a lightweight lock of a variety commonly used in ordinary desk drawers and ﬁle cabinets. Behind this door is the machine’s power switch, a keyboard port, and two PC Card slots, one containing a removable ﬂash memory card and the other containing a modem card used to transfer ballot deﬁnitions and election results. The machine is also equipped with a small thermal roll printer for printing records of initial and ﬁnal vote tallies.
Internally, the machine’s hardware strongly resembles that of a laptop PC or a Windows CE handheld device. The motherboard, described in detail in Figure 1, includes a 133 MHz SH3 RISC processor, 32 MB of RAM, and 16 MB of ﬂash storage. The machine’s power supply can switch to a builtin rechargeable battery in case power is interrupted.
In normal operation, when the machine is switched on, it loads a small bootloader program from its onboard ﬂash memory. The bootloader loads the operating system—Windows CE 3.0—from ﬂash, and then Windows starts the Diebold BallotStation application, which runs the election. Unfortunately, the design of the machine allows an attacker with physical access to the inside of the machine’s case to force it to run code of her choice .
A set of two switches and two jumpers on the motherboard controls the source of the bootloader code that the machine runs when it starts. On reset, the processor begins executing code starting at address 0xA0000000. The switches and jumpers control which of three storage devices—the onboard ﬂash memory, an EPROM chip in a socket on the board, or a proprietary ﬂash memory module in the “ext ﬂash” slot—is mapped into that address range. A table printed on the motherboard lists the switch and jumper conﬁgurations for selecting these devices. The capability to boot from a removable EPROM or ﬂash module is useful for initializing the onboard ﬂash when the machine is new or for restoring the onboard ﬂash’s state if it gets corrupted, but, as we discussed in Section 2, it could also be used by an attacker to install malicious code.
When we received the machine, the EPROM socket was occupied by a 128 KB EPROM containing a bootloader that was older than, but similar to, the bootloader located in the onboard ﬂash. The bootloader contained in the EPROM displays a build date of June 22, 2001 whereas the bootloader contained in the onboard ﬂash displays June 7, 2002. The machine came conﬁgured to boot using the onboard ﬂash memory. On our machine, the onboard ﬂash memory is divided into three areas: a 128 KB bootloader, a 3.3 MB GZIPed operating system image, and a 10 MB ﬁle system partition.
3.2 Boot Process
When the machine is booted, the bootloader copies itself to RAM and initializes the hardware. Then it looks for a memory card in the ﬁrst PC Card slot, and if one is present, it searches for ﬁles on the card with special names. If it ﬁnds a ﬁle called
fboot.nb0, it assumes that this ﬁle contains a replacement bootloader, and it copies the contents of this ﬁle to the bootloader area of the onboard ﬂash memory, overwriting the current bootloader. If it ﬁnds a ﬁle called
nk.bin, it assumes that this ﬁle contains a replacement operating system image in Windows CE Binary Image Data Format , and it copies it to the OS area of the onboard ﬂash, overwriting the current OS image. Finally, if it ﬁnds a ﬁle called
EraseFFX.bsq, it erases the entire ﬁle system area of the ﬂash. The bootloader does not verify the authenticity of any of these ﬁles in any way, nor does it notify the user or ask the user to conﬁrm any of the changes that it makes. As Hursti  suggests, these mechanisms can be used to install malicious code.
If none of these ﬁles are present, the bootloader proceeds to uncompress the operating system image Figure 1: The machine’s motherboard incorporates a (A) HITACHI SUPERH SH7709A 133 MHZ RISC MICROPROCESSOR, (B) HITACHI HD64465 WINDOWS CE INTELLIGENT PERIPHERAL CONTROLLER, two (C) INTEL STRATAFLASH 28F640 8 MB FLASH MEMORY CHIPS, two (D) TOSHIBA TC59SM716FT 16 MB SDRAM CHIPS, and a socketed (E) M27C1001 128 KB ERASABLE PROGRAMMABLE READONLY MEMORY (EPROM). A (F) PRINTED TABLE lists jumper settings for selecting the boot device from among the EPROM, onboard ﬂash, or “ext ﬂash,” presumably an external memory inserted in the
Connectors on the motherboard attach to the (H)
THERMAL ROLL PRINTER, and (J) SECURETECH
CARD READER/WRITER, and receive power from the
TRANSMITTER AND RECEIVER, (O)
SERIAL KEYPAD CONNECTOR, and (P)
are readily accessible through holes in the machine’s case. A (Q)
POWER SWITCH, (R) PS/2
KEYBOARD PORT, and two (S) PC CARD SLOTS
are reached by opening a locked metal door, while a (T)
and (U) PS/2
are not exposed at all. An (V)
is audible through the case.
BATTERY, which are managed by a (M) PIC
stored in onboard ﬂash and copy it to RAM, then it jumps to the entry point of the operating system kernel. The operating system image is a kind of archive ﬁle that contains an entire Windows CE 3.0 installation, including the kernel’s code, the contents of the
directory, the initial contents of the Windows registry, and information about how to conﬁgure the machine’s ﬁle system.
When Windows starts, the kernel runs the process
Filesys.exe, which in turn unpacks the registry and runs the programs listed in the
registry key . On our machine, these programs are the Debug Shell
shell.exe, the Device Manager
device.exe, the Graphics, Windowing, and Events Subsystem
gwes.exe, and the Task Manager
taskman.exe. This appears to be a standard registry conﬁguration .
The Device Manager is responsible for mounting the ﬁle systems. The 10MB ﬁle system partition on the onboard ﬂash is mounted at
\FFX. This partition appears to use the FlashFX ﬁle system, a proprietary ﬁle system from Datalight, Inc . The memory card, if it is present, is mounted at
\Storage Card, and may use the FAT or FAT32 ﬁle system. The root ﬁle system, mounted at
\, is stored in RAM rather than nonvolatile memory, which causes any ﬁles written to it to disappear when the machine is rebooted or otherwise loses power. This design could be leveraged by an attacker who wished to use the ﬁle system for temporarily storing data or malicious code without leaving evidence of these activities.
Diebold has customized
so that it au
tomatically launches the BallotStation application,
\FFX\ Bin\BallotStation.exe. Another customization causes
to behave differently depending on the contents of any memory cards in the PC Card slots. If a memory card containing a ﬁle called
is present at startup,
will invoke Windows Explorer instead of BallotStation (Figure 2). Windows Explorer would give an attacker access to the Windows Start menu, control panels, and ﬁle system, as on an ordinary Windows CE machine. The,
process also searches the memory card for ﬁles with names ending in
. These ﬁles are simple scripts in a Dieboldproprietary binary format that automate the process of updating and copying ﬁles. Like the special ﬁles that the bootloader recognizes,
without authentication of any kind. While
requests conﬁrmation from the user before running each
script, we found multiple stackbased buffer overﬂows in its handling of these ﬁles. This suggests that a malformed
ﬁle might be able to bypass the conﬁrmation and cause the machine to execute ma
licious code. Figure 2: Windows Explorer running on the AccuVoteTS
3.3 BallotStation Software and Procedures
All of the machine’s votingrelated functions are implemented by BallotStation, a userspace Windows CE application. BallotStation operates in one of four modes: PreDownload, PreElection Testing, Election, and PostElection. Each mode corresponds to a different phase of the election process and is intended to have its own associated election procedures. Here we describe the software’s operation under typical election procedures. Actual procedures may vary somewhat from place to place.
At any given time, the machine’s mode is determined by the contents of the currentlyinserted memory
card. Speciﬁcally, the current election mode is stored in the header of the election results ﬁle,
\Storage Card\CurrentElection\election.brs. When one memory card is removed and another is inserted, the machine immediately transitions to the mode speciﬁed by the newly inserted card. In addition, if the machine is rebooted, when BallotStation restarts it will return to the mode speciﬁed by the currently inserted memory card. As a result, if a machine is powered off while an election is taking place, it will return to Election mode when it is turned back on.
3.3.1 Election Setup
Typically, the voting machines are stored by the local government or the voting machine vendor in a facility with some degree of access control. Before the election (sometimes the night before, or in other cases the same morning) the machines are delivered to polling places where they are set up and prepared by poll workers. Prior to the election, poll workers may conﬁgure BallotStation by inserting a memory card containing a ballot description—essentially, a list of races and candidates for the current election. If, instead, a card containing no recognizable election data is inserted into the machine, BallotStation enters PreDownload mode (shown in Figure 3A). In this mode, the machine can download a ballot deﬁnition by connecting to a Windows PC running Diebold’s GEMS server software.
After election deﬁnitions have been installed, BallotStation enters PreElection Testing mode (shown in Figure 3B). Among other functions, PreElection Testing mode allows poll workers to perform socalled “logic and accuracy” (L&A). During L&A testing, poll workers put the machine into a simulation mode where they can cast several test votes and then tally them, checking that the tally is correct. Because the voting software is in L&A mode, these votes are not counted in the actual election.
After any L&A testing is complete, the poll workers put the machine into Election mode. The software prints a “zero tape” which tallies the votes cast so far. Since no votes have been cast, all tallies should be zero. Poll workers check that this is the case, and then sign the zero tape and save it.
When a voter arrives at the polling place, she checks in at a front desk where several poll workers are stationed. The voter announces her identity (and provides whatever evidence of identity is required by elections law). The identity is checked against a list of registered voters. Assuming the voter is registered and has not yet voted, poll workers record that the voter has voted. At this point the poll workers give the voter a “voter card,” a special smart card that signiﬁes that the voter is entitled to cast a vote.6
The voter waits until the voting machine is free and then approaches the machine to cast her vote.
To cast a vote, the voter ﬁrst inserts her voter card. The machine validates the voter card and presents the voter with a user interface (shown in Figure 3C) allowing her to express her vote by selecting candidates and answering questions. After making and conﬁrming her selections, the voter pushes a button on the user interface to cast her vote. The machine modiﬁes the voter card, marking it as invalid, and then ejects it. After leaving the machine, the voter returns the nowinvalid voter card to the poll workers, who may reenable it for use by another voter.
3.3.3 PostElection Activities
At the end of the election, poll workers insert an “Ender Card” to tell the voting software to stop the election and enter PostElection Mode (shown in Figure 3D).7
Poll workers can then use the machine to print a
found numerous vulnerabilities and design ﬂaws in BallotStation’s smart card authentication scheme , which remain uncorrected in the machine we studied.
7They can also use a “Supervisor Card” for this purpose. Supervisor cards enable access to extra setup and administrative operations in preand postelection modes.
Figure 3: Screenshots depicting BallotStation’s four primary modes: (A) PREDOWNLOAD, (B) PREELECTION
TESTING, (C) ELECTION, and (D) POSTELECTION.
“result tape” showing the ﬁnal vote tallies. The poll workers check that the total number of votes cast is consistent with the number of voters who checked in at the front desk. Assuming no discrepancy, the poll workers sign the result tape and save it. Members of the public are invited to watch this procedure and to see the contents of the result tape, including the vote tallies.
After the result tape is printed, the election results are transferred to the central tabulator, a PC running the GEMS software described above. Like the ballot deﬁnitions, the election results may be transferred over a local area network, a phone line, or a serial cable. Once results from all machines have reached the central tabulator, the tabulator can add up the votes and report a result for the election.
For convenience, it is also possible to “accumulate” the results from several machines into a single AccuVote voting machine, which can then transmit the accumulated results to the central tabulator in a single step. To accumulate results, one machine is put into accumulator mode, and then the memory cards from all of the local machines are inserted (in sequence) into the accumulator machine, which reads the election results and combines them into a single ﬁle, that will be transferred to the central tabulator or used as an input to further accumulation steps.
If a recount is ordered, the result tapes are rechecked for consistency with voter checkin data, the result tapes are checked for consistency with the results stored on the memory cards, and the tabulator is used again to sum up the results on the memory cards. Further investigation may examine the state stored on memory cards and a machine’s onboard ﬁle system, such as the machine’s logs, to look for problems or inconsistencies.
Exact procedures vary from place to place, and many polling places add additional steps to deal with multiple voter populations (e.g. different parties or electoral districts) and other complicating factors. We omit these details in our description, but we have considered them in our analysis and except where noted below they do not affect the results.
4 Implementing Demonstration Attacks
To conﬁrm our understanding of the vulnerabilities in the Diebold AccuVoteTS system, and to demonstrate the severity of the attacks that they allow, we constructed demonstration implementations of several of the attacks described above and tested them on the machine. We are not releasing the software code for our demonstration attacks to the public at present; however, a video showing some of our demonstration attacks in operation is available online at http://itpolicy.princeton.edu/voting.
4.1 Backup and Restore
As a prerequisite to further testing, we developed a method for backing up and restoring the complete contents of the machine’s onboard ﬂash memory. This allowed us to perform experiments and develop other demonstration attacks without worrying about rendering the machine inoperable, and it ensured that we could later restore the machine to its initial state for further testing and demonstrations.
We began by extracting the EPROM chip from its socket on the motherboard and reading its 128 KB contents with a universal EPROM programmer. We then disassembled the bootloader contained on the chip using IDA Pro Advanced , which supports the SH3 instruction set. Next, we created a patched version of the EPROM bootloader that searches any memory card8
in the ﬁrst PC Card slot for ﬁles named
flash.img. If it ﬁnds a ﬁle named
backup.cmd, it writes the contents of the onboard ﬂash to the ﬁrst 16 MB of the memory card, and if it ﬁnds a ﬁle named
flash.img, it replaces the contents of the onboard ﬂash with the contents of that ﬁle. We programmed our modiﬁed bootloader into a
8While Diebold sells specialpurpose memory cards for use in the machine, we were able to substitute a CompactFlash card (typically used in digital cameras) and a CompactFlashtoPC Card adapter.
new, standard, 128 KB EPROM chip and inserted it into the motherboard in place of the original chip. By changing the position of switches and jumpers on the motherboard, as described in Section 3, we conﬁgured the machine to boot using the code in the chip instead of the normal bootloader in its onboard ﬂash memory.
The EPROM bootloader already contains code for checking for the existence of ﬁles on a memory card and for erasing and writing to the onboard ﬂash in order to process the special ﬁles described in Section 3. As a result, our modiﬁed bootloader is able to call that code when it needs to perform those operations. Furthermore, since the onboard ﬂash is mapped into the physical address space, reading from the onboard ﬂash is as straightforward as reading from RAM. However, since the original EPROM bootloader does not contain code for writing to a memory card, we needed to add code that issued the proper write commands via the memory card conﬁguration registers .
4.2 Stealing Votes
Several of the demonstration attacks that
we have implemented involve installing code onto AccuVoteTS machines that changes votes so that, for a given race, a favored candidate receives a speciﬁed percentage of the votes cast on each affected machine. Since any attacks that signiﬁcantly alter the total number of votes cast can be detected by election ofﬁcials, our demonstration software steals votes at random from other candidates in the same race and giving them to the favored candidate. The software switches enough votes to ensure that the favored candidate receives at least the desired percentage of the votes cast on each compromised voting machine.
Election results (i.e., the record of votes cast) are stored in ﬁles that can be modiﬁed by any program running on the voting machine. For the currently running election, the primary copy of the election results is stored on the memory card at
\Storage Card\ CurrentElection\election.brs
and a backup copy is stored in the machine’s onboard ﬂash memory at
\FFX\ AccuVoteTS\BallotStation\Cur rentElection\election.brs. Our
software works by directly modifying both Figure 4: Our demonstration votestealing control panel
of these ﬁles.
Our demonstration votestealing software is implemented as a userspace Windows CE application written in C++ that runs alongside Diebold’s BallotStation application. Since our software runs invisibly in the background, ordinary users of BallotStation would not notice its presence. It is preprogrammed with three parameters hardcoded into the binary: the name of the race to rig, the name of the candidate who is supposed to win, and the minimum percentage of the vote that that candidate is to receive.
Alternatively, an attacker could create a graphical user interface that allows more immediate, interactive control over how votes would be stolen. We have also created a demonstration of this kind of attack, as shown in Figure 4. In practice, a real attacker would more likely design a votestealing program that functioned invisibly, without a user interface.
Our demonstration votestealing applications can easily be generalized to steal votes on behalf of a particular party rather than a ﬁxed candidate, to steal votes only in certain elections or only at certain dates or times, to steal votes only or preferentially from certain parties or candidates, to steal a ﬁxed fraction of votes rather than trying to ensure a ﬁxed percentage result, to randomize the percentage of votes stolen, and so on. Even if the attacker knows nothing about the candidates or parties, he may know that he wants to reduce the inﬂuence of voters in certain places. He can do this by creating malicious code that randomly switches a percentage of the votes, and installing that code only in those places. Any desired algorithm can be used to determine which votes to steal and to which candidate or candidates to transfer the stolen votes.
Every time a new memory card is inserted into the machine, our demonstration votestealing software looks for an election deﬁnition ﬁle on the card located at
\Storage Card\CurrentElection\ election.edb
and, if one is present, determines whether the current election contains a race it is supposed to rig. If no such race is found, the software continues to wait. If a target race is found, it searches that race for the name of the favored candidate, and if it is found, records the favored candidate’s position in the race’s “base rotation order.” The base rotation order of the candidates in a given race is the order that votes are recorded in the election results ﬁle. This order may or may not differ from the order that the candidates are displayed on the ballots that are shown to voters. The software must keep track of the favored candidate’s position in the race’s base rotation order so that it can compute which value in each election result record needs to be changed to give a vote to the favored candidate.
Once the demonstration votestealing software has loaded the election description, it polls the election result ﬁles every 15 seconds to see if they have been changed. Since BallotStation tries to obtain an exclusive lock on these ﬁles every time it accesses them, if BallotStation attempted to open the results ﬁles while the demonstration votestealing software had them open, then BallotStation would receive an error that would be displayed to the user of the voting machine possibly causing the attack to be discovered. To avoid this situation, before attempting to open the result ﬁles, the votestealing software suspends the BallotStation process. If the votestealing software succeeds in opening the ﬁles, it keeps BallotStation suspended until it is ﬁnished accessing the result ﬁles. If it is unable to obtain a lock on the ﬁles, the software resumes BallotStation and tries to open the ﬁles again later. These brief suspensions of the BallotStation process would not be noticeable to voters because they occur infrequently and each last only a fraction of a second.
If the demonstration votestealing software successfully opens the result ﬁles during one of its polling attempts, it ﬁrst checks the result ﬁles’ headers to see whether the machine is currently in Election mode. If it is not, the software does not change any votes. This feature ensures that the software would not be detected during Logic and Accuracy testing, which occurs when the machine is in PreElection Testing mode. The software could be further enhanced so that it would only change votes during a speciﬁed period on election day, or so that it would only change votes in the presence or absence of a “secret knock.” A secret knock is a distinctive sequence of actions, such as touching certain places on the screen, that an attacker executes in order to signal malicious software to activate or deactivate itself.
If the machine is in election mode and the demonstration votestealing software successfully opens the result ﬁles, then the software checks whether any new ballots have been cast since the last time it polled the ﬁles. For each new ballot cast, the software determines whether the race being rigged is on that ballot, and if so, determines whether the corresponding result record contains a vote for the favored candidate or for an opponent. The software maintains a data structure that keeps track of the location of every result record that contains a vote for an opponent of the favored candidate so that it can come back later and change some of those records if necessary. Since each result record is only labeled with the ID number of the ballot to which it corresponds, the software must look up each record’s ballot ID in the election deﬁnition ﬁle in order to determine which candidates the votes in the record are for.
Once it has parsed any newly cast ballots, the software switches the minimum number of votes necessary to ensure that the favored candidate gets at least the desired percentage of the vote. The votestealing software chooses which votes to switch by selecting entries at random from its data structure that tracks votes for the opponents of the favored candidate. After the necessary changes have been made to the result ﬁles, the software closes the ﬁles, resumes the BallotStation process, and continues to wait in the background.
The steps described above are all that is necessary to alter every electronic record of the voters’ intent that an AccuVoteTS machine produces. Several of the machine’s supposed security features do not impede this attack. The socalled “protective counter,” supposedly an unalterable count of the total number of ballots ever cast on the machine, is irrelevant to this attack because the votestealing software does not change the vote count.9
The machine’s audit logs are equally irrelevant to this attack because the only record they contain of each ballot cast is the log message “Ballot cast.” Furthermore, the fact that election results are stored redundantly in two locations is not an impediment because the votestealing software can modify both copies. Finally, as we discuss in Section 2, the fact that the election results are encrypted does not foil this attack.
4.3 Demonstration Voting Machine Virus
In addition to our demonstration votestealing attacks, we have developed a voting machine virus that spreads the votestealing code automatically and silently from machine to machine. The virus propagates via the removable memory cards that are used to store the election deﬁnition ﬁles and election results, and for delivering ﬁrmware updates to the machines. It exploits the fact that, when the machine boots, the Diebold bootloader will install any code found on the removable memory card in a ﬁle with the special name
. As a result, an attacker could infect a large population of machines while only having temporary physical access to a single machine or memory card.
Our demonstration virus takes the form of a malicious bootloader that infects a host voting machine by replacing the existing bootloader in the machine’s onboard ﬂash memory. Once installed, the virus deploys our demonstration votestealing software and copies itself to every memory card that is inserted into the infected machine. If those cards are inserted into other machines, those machines can become infected as well.
The cycle of infection proceeds as follows. When the virus is carried on a memory card, it resides in a 128 KB bootloader image ﬁle named
fboot.nb0. This ﬁle contains both the malicious replacement bootloader code and a Windows CE executable application that implements the demonstration votestealing application. The votestealing executable is stored in a 50 KB region of the bootloader ﬁle that would normally be unused and ﬁlled with zeroes.
When a card carrying the virus is inserted into a voting machine and the machine is switched on or rebooted, the machine’s existing bootloader interprets the
ﬁle as a bootloader update and copies the contents of the ﬁle into its onboard ﬂash memory, replacing the existing bootloader with the malicious one. The original bootloader does not ask for conﬁrmation before replacing itself. It does display a brief status message, but this is interspersed with other normal messages displayed during boot. These messages are visible for less than 20 seconds and are displayed in small print at a 90 degree angle to the viewer. After the boot messages disappear, nothing out of the ordinary ever appears on the screen.
Once a newly infected host is rebooted, the virus bootloader is in control. Since the bootloader is the ﬁrst code that runs on the machine, a virus bootloader is in a position to affect all aspects of system operation. While booting, the virus bootloader, like the ordinary bootloader, checks for the presence of a memory card
9In any event, the “protective counter” is simply an integer stored in an ordinary ﬁle, so an attack that needed to modify it could do so easily .
in the ﬁrst PC Card slot. However, if it ﬁnds a bootloader software update on the card, it pretends to perform a bootloader update by printing out the appropriate messages, but actually does nothing.10
Thus, once a machine has been infected, the only way to remove the virus bootloader is to restore the machine’s state using an EPROMresident bootloader.
If a memory card is present, the virus bootloader copies itself to the card as a ﬁle named
so that it can spread to other machines. If the card already contains a ﬁle with that name, the bootloader replaces it. Consequently, if a service technician performing bootloader updates tries to update an infected machine using a card containing an
ﬁle, the infected machine will not be updated (although it will pretend to be), and all subsequent machines that the technician tries to update using the same card will receive the virus bootloader instead of the updated one. Similarly, updates to the BallotStation software or operating system can also propagate the virus.
The malicious bootloader also copies the votestealing executable to the memory card as a ﬁle named
AV.EXE. Then, immediately before starting Windows, the virus bootloader scans the region of RAM occupied by the operating system image (0x8C080000–0x8C67FFFF) for the hardcoded string in the
binary that points to the BallotStation executable
and replaces it with
\Storage Card\AV.EXE. Consequently, when Windows starts,
will launch the demonstration votestealing application instead of BallotStation.
When the demonstration votestealing application on the memory card starts, it ﬁrst renames the legitimate BallotStation executable to
\FFX\Bin\AccuVote.exe, and then it copies itself to the machine’s onboard ﬂash memory with the name
\FFX\Bin\BallotStation.exe. It adopts the name of the BallotStation executable so it will still run at startup even if the machine is booted without a memory card in the ﬁrst PC Card slot. Next, it copies the malicious boot loader image from the card to the onboard ﬂash . Thereafter, the software periodically checks whether an uninfected memory card is present in the machine, and, if so, it copies the virus ﬁles onto the card so that other machines where the card is used will become infected. Finally, the votestealing application runs in the background changing votes in the manner described in Section 4.2.
4.4 Demonstration DenialofService Attack
To illustrate how malicious software running on an AccuVoteTS could launch a denialofservice (DoS) attack, we developed a demonstration attack program that, on command, erases the contents of both the currentlyinserted memory card and the machine’s onboard ﬂash memory. This attack not only destroys all records of the election currently in progress (both the primary and backup copies), but also renders the machine inoperable until a service technician has the opportunity to dismantle it and restore its conﬁguration.
The demonstration DoS program is comprised of a userspace Windows CE executable that triggers the attack and a malicious bootloader that functions like an ordinary bootloader, except that upon receiving the appropriate signal, it completely erases the currentlyinserted memory card and the machine’s onboard ﬂash memory. The userspace trigger program works by ﬁrst writing a special value to a part of the machine’s onboard ﬂash memory that is accessible from userspace programs and then crashing the machine by invoking the
Windows CE API call. The
API is supposed to put the system in a lowpower ”sleep” mode from which it can later ”wakeup,” but when this API is invoked on an AccuVoteTS, the machine simply crashes. When the machine is rebooted (which must be done manually), the malicious bootloader notices that the special value has been written to the machine’s on
10In order to avoid printing out fake update messages when the copy of
on the card was put there by the virus bootloader itself, whenever the virus bootloader copies itself to a card, it sets the hidden, system, and readonly FAT attributes of the resulting
ﬁle. Then, when the virus bootloader checks for the presence of the
ﬁle on the card, it only prints out fake update messages if the ﬁle does not have those attributes. Alternatively, the virus bootloader could identify copies of itself by examining the contents of the
ﬁle for some characteristic bit string.
board ﬂash memory. On this signal, it completely erases the contents of both the currentlyinserted memory card and the machine’s onboard ﬂash memory. In so doing, the malicious bootloader destroys all of the data, software, and ﬁlesystem formating on both the memory card and the onboard ﬂash memory.
In order to account for the possibility that the malicious bootloader never gets a chance to completely erase both storage media or that the memory card is removed before the machine is rebooted, the userspace trigger program deletes as much as it can before crashing the machine. It deletes all of the ﬁles on the memory card and on the machine’s onboard
ﬁle system including both the primary and backup copies of the election results (election.brs), the audit logs (election.adt), and the BallotStation executable. When it deletes these ﬁles, it overwrites each of them with garbage data to make it less likely that the ﬁles’ data will ever be recovered.
While our demonstration DoS attack is triggered by a user’s command, a real attacker could create malicious software that only triggers the above attack on a speciﬁc date and time, such as on election day. An attacker could also design the attack to launch in response to a speciﬁc trend in voting during an election, such as an apparent victory for a particular candidate. Like a votestealing attack, a DoS attack could be spread by a virus.
The vulnerabilities that we describe can be mitigated, to some extent, by changing voting machine designs and election procedures. In this section we discuss several mitigation strategies and their limitations.
5.1 Modiﬁcations to DRE Software and Hardware
The AccuVoteTS machine is vulnerable to computer viruses because it automatically loads and runs code found on memory cards without authenticating it. Its software could be redesigned to prevent the spread of viruses, however. One approach would be to digitally sign all software updates and have the machine’s software verify the signature of each update before installing it. Such a change would ensure that only updates signed by the manufacturer or another trusted certifying authority could be loaded.
It would also be helpful to require the person using the machine to conﬁrm any software updates. Conﬁrmation of updates would not prevent a malicious person with physical access to the mchine from loading an update, but at least it would make the accidental spread of a virus less likely while the machine was being used by honest election ofﬁcials.
While redesigning the voting machine’s software can help mitigate some of the security problems that we identify, there are other problems inherent in the AccuVoteTS hardware architecture that cannot be addressed by software changes. For example, there is nothing to stop an adversary who has physical access to the machine from booting and installing his own malicious software by replacing the socketed EPROM chip on the motherboard. Furthermore, because all of the machine’s state is kept in rewritable storage (RAM, ﬂash memory, or a memory card), it is impossible to create tamperproof logs, records, and counters. In addition, as is the case with ordinary PCs, it is difﬁcult to determine with certainty that the machine is actually running the software that it is supposed to run. Rootkit techniques  and virtualization technologies , which are often used to conceal malware in the PC setting, could be adapted for use on the voting machines.
Researchers have proposed various strategies for building specialized hardware capable of maintaining tamperproof and tamperevident logs, records, and counters (e.g., ), as well as software strategies that provide more limited protection (e.g., ). Alhough such methods could prevent attacks that aim to alter
11Adding signatures would not be effective if a machine has already been infected with malicious code; machines would need to be booted from EPROM and completely restored to a known state before their software were updated to a version that checked signatures.
votes after they have been recorded, they could not prevent malicious code from changing future votes by altering data before it is sent to the storage device.
Assuring a computer’s software conﬁguration is also a notoriously difﬁcult problem, and research has focused on mechanisms to ensure that only approved code can boot  or that a machine can prove to a remote observer that it is running certain code . For example, commercial systems such as Microsoft’s Xbox game console have incorporated mechanisms to try to resist modiﬁcation of the boot code or operating system, but they have not been entirely successful . Although mechanisms of this type are imperfect and remain subjects of active research, they seem appropriate for voting machines because they offer some level of assurance against malicious code injection. It is somewhat discouraging to see voting machine designers spend much less effort on this issue than game console designers.
While changes to the hardware and software of voting machines can reduce the threats of malicious code injection and log tampering, no purely technical solution can eliminate these problems.
5.2 Limiting Access to Machines and Memory Cards
Despite the best efforts of hardware and software designers, any physical access to a computer still raises the possibility of malicious code installation, so election offcials should limit access to voting machines’ internals, their memory cards, and their memory card slots to the extent possible.
There is some beneﬁt in sealing the machine’s case, memory card, and card bay door with individually numbered tamperevident seals, in the hope of detecting illicit accesses to these areas. While these measures may expose some classes of attacks, they make denialofservice attacks easier. Suppose, for example, that a malicious voter cuts a seal while an election is in progress. If machines with broken seals are treated as completely untrustworthy, then cutting the seal is itself an effective denialofservice attack. If broken seals are usually ignored when everything else seems to be in order, then an attacker has a good chance of successfully inserting malicious code that cleans up after itself. There seems to be no fully satisfactory compromise point between these two extremes.
Even leaving aside the possibility that voters will deliberately break seals, broken seals are an unfortunately common occurrence. The most comprehensive study of AccuVote DRE election processes in practice examined the May 2006 primary election in Cuyahoga County, Ohio, which used AccuVoteTSx machines. The study found that more than 15% of polling places reported at least one problem with seals .
The available evidence is that machines and memory cards are not handled with anything approaching the necessary level of care. For example, the Cuyahoga County study  reported many procedural weaknesses:
“A lack of inventory control and gaps in the chain of custody of mission critical assets (i.e. DRE memory cards, [DREs], . . . )” (p. 103)
“the systems of seals, signatures and other security features of the. . . machine memory cards were not implemented on a consistent basis” (p. 109)
“It appears that memory cards are regularly removed and reinserted when a DRE becomes outofservice. Security tabs are broken and no log of this remove and replace activity is maintained. . . There is no indication that a record comparing memory card to DRE serial number is kept.” (p. 138)
“Security seals are not checked for integrity at the end of Election Day, nor are they matched with a deployment list of Security seal serial numbers. There is no attempt to reconcile memory cards intended for the precinct with memory cards removed from the DREs at the end of the day. . . Therefore, it is unknown whether these memory cards were tampered with during Election Day.” (p. 139)
“There is no established chain of custody during the transfer of the memory cards. . . from the vote center to the BOE [Board of Elections].” (p. 140)
“Security seals are collected upon return to the BOE, but these serial numbers are neither logged nor checked against the original security seal serial numbers deployed with the memory cards. Therefore, it is unknown whether these memory cards were tampered with during transport to the BOE from the polling location.” (p. 140)
These problems require immediate attention from election ofﬁcials.
Security seals do some good, but it is not a solution simply to assume that seals will always be used, always be checked, and never be broken. Inevitably, some seals will be missing or broken without an explanation, providing potential cover for the insertion of malicious code or a voting machine virus.
5.3 Effective Parallel Testing
In parallel testing, election ofﬁcials choose some voting machines at random and set them aside, casting simulated votes on them throughout election day and verifying at the end of the election that the machines counted the simulated votes correctly. The goal of parallel testing is to trigger and detect any votestealing software that may be installed on the machines.
A challenge in parallel testing is how to make the simulated voting pattern realistic. If the pattern is unrealistic in some respect—if, say, the distribution of votes throughout the day doesn’t match what a real voting machine would see—then votestealing software may be able to tell the difference between a real election and parallel testing, allowing the software to steal votes in the real election while leaving results unchanged in parallel testing.
Parallel testing is also vulnerable to a “secret knock” attack by a testing insider. Generally, parallel tests are carried out by representatives from all political parties to ensure impartiality. However, if one representative has placed vote altering code on the machines, she could disable the code on the machine being tested by issuing a surreptitious command. For example, the code might watch for a speciﬁc sequence of touches in a normally unused area of the screen and deactivate its vote altering function in response. Preventing this kind of attack requires carefully scripting the testing procedure.
Alternatively, a secret knock might be used to activate malicious code. In this scheme, malicious voters would perform the secret knock on the machines being used to collect real votes, or a malicious election worker would perform it surreptitiously when setting up the machines, and votestealing software would wait for this secret knock before operating. Machines chosen for parallel testing would not see the secret knock and so would count votes honestly. This approach has the drawback (for the attacker) of requiring a signiﬁcant number of malicious voters or a malicious poll worker to participate, though these participants would not have to know all the details of the attack.
These possibilities reduce the usefulness of parallel testing in practice, but we think it can still be a worthwhile precaution when conducted according to rigorously controlled procedures.
5.4 Effective WholeSystem Certiﬁcation
Despite their very serious security ﬂaws, the Diebold DREs were certiﬁed according to federal and state standards. This demonstrates that the certiﬁcation processes are deﬁcient. The Federal Election Commission’s 2002 Voting System Standards  say relatively little about security, seeming to focus instead on the machine’s reliability if used nonmaliciously.
The U.S. Election Assistance Commission issued voluntary voting system guidelines  in 2005. These are considerably more detailed, especially in the area of security, than the FEC’s 2002 standards. Though it would not be entirely fair to apply the 2005 guidelines to the pre2005 version of the AccuVote software we studied, we do note that the AccuVoteTS hardware architecture may make it impossible to comply with the 2005 guidelines, in particular with the requirement to detect unauthorized modiﬁcations to the system software (see , Volume I, Section 7.4.6). In practice, a technology can be deployed despite noncompliance with certiﬁcation requirements, if the testing agencies fail to notice the problem.
In general, the certiﬁcation process seems to rely more on testing than analysis. Testing is appropriate for some properties of interest, such as reliability in the face of heat, cold, and vibration, but testing is illsuited for ﬁnding security problems. As discussed frequently in the literature, testing can only show that a system works under speciﬁc, predeﬁned conditions; it generally cannot ensure that there is no way for an attacker to achieve some goal by violating these conditions. Only a competent and thorough security analysis can provide any conﬁdence that the system can resist the full range of realistic attacks.
Weak certiﬁcation would be less of a problem if information about the system’s design were more widely available to the public. Researchers and other experts would be able to provide valuable feedback on voting machine designs if they had the information to do so. Ideally, strong certiﬁcation procedures would be coupled with public scrutiny to provide the highest assurance.
5.5 VoterVeriﬁable Paper Trail and Random Audits
The most important strategy for mitigating votestealing attacks is to use a voterveriﬁable paper audit trail (VVPAT) coupled with random audits. The VVPAT creates a paper record, veriﬁed visually by the voter, of how each vote was cast. This record can be either a paper ballot that is deposited by the voter in a traditional ballot box, or a ballotunderglass system that keeps the paper record within the voting machine but lets the voter see it . A VVPAT makes our votestealing attack detectable. In an allelectronic system like the Diebold DREs, malicious code can modify all of the logs and records in the machine, thereby covering up its vote stealing, but the machine cannot modify already created paper records, and the accuracy of the paper records is veriﬁed by voters.
Paper trails have their own failure modes, of course. If they are poorly implemented, or if voters do not know how or do not bother to check them, they may have little value [2, 9]. The real advantage of a paper trail is that its failure modes differ signiﬁcantly from those of electronic systems, making the combination of paper and electronic recordkeeping harder to defraud than either would be alone. Requiring a wouldbe vote stealer to carry out both a codeinjection attack on the voting machines and a physical ballot box stufﬁng attack would signiﬁcantly raise the difﬁculty of attacking the system.
Paper ballots are only an effective safeguard if they are actually used to check the accuracy of the machines. This need not be done everywhere. It is enough to choose a small fraction of the polling places at random and verify that the paper ballots match the electronic records there. If the polling places to recount are chosen by a suitable random procedure, election ofﬁcials can establish with high probability that a full comparison of paper and electronic records would not change the election’s result.
Another limitation of VVPATs is that they cannot stop a denialofservice attack from spoiling an election by disabling a large number of voting machines on election day. Given this possiblity, if DREs are used, it is worthwhile to have an alternative voting technology available. A decidedly lowtech system such as paper ballots may be suitable for this purpose.
6 Related Work
Several previous studies have criticized the security of the Diebold AccuVote DRE systems. The ﬁrst major study of these machines was published in 2003 by Kohno
, who did not have access to a machine but did have a leaked version of the source code for BallotStation. They found numerous security ﬂaws and concluded that the software’s design did not show evidence of any sophisticated security thinking.
Public concern in light of Kohno’s study led the state of Maryland to authorize two security studies. The ﬁrst study, by SAIC, reported that the system was “at high risk of compromise,” but much of the basis for this conclusion was redacted in the public version of SAIC’s report . RABA, a security consulting ﬁrm, was hired to do another independent study of the Diebold machines. RABA had access to a number of machines and some technical documentation. Their study  was generally consistent with Kohno’s ﬁndings, and found some new vulnerabilities. It suggested design changes to the Diebold system, and some steps that Maryland might take to reduce the risk of security problems. The state of Maryland responded by adopting many of RABA’s suggestions .
A further security assessment was commissioned by the Ohio Secretary of State and carried out by the Compuware Corporation . This study examined several DRE systems, including the AccuVoteTS running the same version of BallotStation as our machine, and concluded that several high risk security problems were present.
In 2006, in response to reports that Harri Hursti had found ﬂaws in Diebold’s AccuBasic subsystem, the state of California asked Wagner, Jefferson, and Bishop to perform a study of AccuBasic security issues. Their report  found several vulnerabilities.
Later in 2006, Hursti released a report describing several security weaknesses in Diebold’s software relating to the automatic installation of unauthenticated software .
Our work builds on these previous reports. Our ﬁndings generally conﬁrm the behaviors and vulnerabilities described by Kohno
et al., RABA, Wagner
et al., and Hursti, and demonstrate through proofofconcept attack implementations that the vulnerabilities can be exploited to change election results. To our knowledge, our work is the ﬁrst comprehensive, public description of these aspects of Diebold’s design.
Several studies discuss general issues in the design of softwarebased attacks on DRE voting machines. Kelsey  catalogs the attacker’s design choices; our analysis conﬁrms that all or nearly all of the attack options Kelsey discusses can be carried out against the Diebold machine we studied. The Brennan Center report  offers a broader but less technical discussion; its discussion of malicious software injection attacks is based partially on Kelsey’s analysis.
Additionally, there is an extensive literature on electronic voting in general, which we will not attempt to survey here.
From a computer security standpoint, DREs have much in common with desktop PCs. Both suffer from many of the same security and reliability problems, including bugs, crashes, malicious software, and data tampering. Despite years of research and enormous investment, PCs remain vulnerable to these problems, so it is doubtful, unfortunately, that DRE vendors will be able to overcome them.
Nevertheless, the practical question facing public ofﬁcials is whether DREs provide better security than other election technologies, which have their own history of failure and fraud. DREs may resist smallscale fraud as well as, or better than, older voting technologies; but DREs are much more vulnerable to largescale fraud. Attacks on DREs can spread virally, they can be injected far in advance and lurk passively until election day, and they can alter logs to cover their tracks. Procedures designed to control smallscale fraud are no longer sufﬁcient—DREs demand new safeguards.
In 2003, Diebold claimed that the AccuVoteTS software provided strong security guarantees: The correctness of the software has been proven.. . . The assertion that there are
exploitable attack vectors is false. The implication that malicious code could be inserted into the system is baseless. (, p. 25, emphasis in original) Our analysis shows conclusively that these statements by Diebold were incorrect—there are several exploitable attack vectors and malicious code can be inserted into the system.
We expect Diebold to respond to this paper by offering similar assurances about other versions of their software and about their closely related AccuVoteTSx product. In light of past experience, public ofﬁcials should remain skeptical until such claims are conﬁrmed by independent investigators with full access to the machines and software.
Public ofﬁcials who had planned to rely on Diebold DREs for the November 2006 elections face a dilemma. The changes needed to conduct secure elections with the AccuVoteTS cannot plausibly be implemented by November. One option is to switch to a backup election technology such as precinctcount paper ballots. Such a change is costly and carries some risk. The other option is to implement some partial countermeasures against malicious code and viral attacks, and hope for the best.
Electronic voting machines have their advantages, but experience with the AccuVoteTS and other paperless DREs shows that they are prone to very serious vulnerabilities. Making them safe, given the limitations of today’s technology, will require safeguards beginning with a voterveriﬁable paper audit trail and truly independent security evaluation.
We thank Andrew Appel, Jeff Dwoskin, Laura Felten, Shirley Gaw, Brie Ilenda, Scott Karlin, Yoshi Kohno, David Robinson, Avi Rubin, Adam Stubbleﬁeld, Dan Wallach, and Harlan Yu for technical help, information, and feedback. We are especially grateful to the party who provided us the machine to study.
This material is based upon work supported under a National Science Foundation Graduate Research Fellowship. Any opinions, ﬁndings, conclusions or recommendations expressed in this publication are those of the authors and do not necessarily reﬂect the views of the National Science Foundation.
 William A. Arbaugh, David J. Farber, and Jonathan M. Smith. A secure and reliable bootstrap architecture. In
IEEE Symposium on Security and Privacy, pages 65–71, May 1997.
 Brennan Center Task Force on Voting System Security. The machinery of democracy: Protecting elections in an electronic world. Available at http://www.brennancenter.org/programs/downloads/ Full20Report.pdf, 2006.
 CompactFlash Association. CF+ and CompactFlash speciﬁcation revision 3.0. Available at http:// www.compactﬂash.org/cfspc3 0.pdf, 2004.
 Compuware Corporation. Direct recording electronic (DRE) technical security assessment report. Available at http://www.sos.state.oh.us/sos/hava/compuware112103.pdf, November 2003.
 Datalight, Inc. FlashFX family product details. Available at http://datalight.com/products/ﬂashfx/ productdetails.php.
 DataRescue sa/nv. IDA Pro Disassembler. Available at http://www.datarescue.com/idabase.
 Diebold Election Systems Inc. Checks and balances in elections equipment and procedures prevent alleged fraud scenarios. Available at http://www.diebold.com/checksandbalances.pdf, July 2003.
 Election Data Services. 2006 voting equipment study, statebystate equipment summary. Available at http://www.electiondataservices.com/VE20Summary20by20Type2020061107 counties.pdf.
 Election Science Institute. DRE analysis for May 2006 primary, Cuyahoga County, Ohio. Available at http://bocc.cuyahogacounty.us/GSC/pdf/esi cuyahoga ﬁnal.pdf, August 2006.
 Federal Election Commission. Voting system standards. Available at http://www.eac.gov/election resources/vss.html, 2002.
 Nola Haug. Vendor proposal evaluation ﬁndings report and addendum. Available at http://www.sos. state.oh.us/sos/hava/ﬁndings091003.pdf, September 2003.
 Greg Hoglund and Jamie Butler.
Rootkits: Subverting the Windows Kernel. AddisonWesley Professional, 2005.
 Andrew Huang.
Hacking the Xbox: An Introduction to Reverse Engineering. No Starch Press, 2003.
 Harri Hursti. Diebold TSx evaluation: Critical security issues with Diebold TSx. Available at http: //www.bbvdocs.org/reports/BBVreportIIunredacted.pdf, May 2006.
 John Kelsey. Strategies for software attacks on voting machines. In
NIST Workshop on Threats to Voting Systems, September 2005.
 Samuel T. King, Peter M. Chen, YiMin Wang, Chad Verbowski, Helen J. Wang, and Jacob R. Lorch. SubVirt: Implementing malware with virtual machines. In
IEEE Symposium on Security and Privacy, May 2006.
 Tadayoshi Kohno, Adam Stubbleﬁeld, Aviel D. Rubin, and Dan S. Wallach. Analysis of an electronic voting system. In
IEEE Symposium on Security and Privacy, May 2004.
 Maryland State Board of Elections. Response to: Department of legislative services trusted agent report on Diebold AccuVoteTS voting system. Available at http://mlis.state.md.us/Other/voting system/sbe response.pdf, January 2004.
 Rebecca Mercuri.
Electronic Vote Tabulation: Checks and Balances. PhD thesis, University of Pennsylvania, 2001.
 Microsoft Corporation. Conﬁguring the process boot phase. Available at http://msdn.microsoft.com/ library/enus/wcehardware5/html/wce50conConﬁguringtheProcessBootPhase.asp.
 Microsoft Corporation. Filesys.exe boot process. Available at http://msdn.microsoft.com/library/enus/ wcedata5/html/wce50conFilesysexeBootProcess.asp.
 Microsoft Corporation. Windows CE binary image data format speciﬁcation. Available at http://msdn. microsoft.com/library/enus/wceosdev5/html/wce50conWindowsCEBinaryImageDataFormatbin.asp.
 Open Voting Consortium. Worst ever security ﬂaw found in Diebold TS voting machine. Available at http://www.openvotingconsortium.org/blog/2006jul31/worst ﬂaw ever in diebold touch screen voting machine revealed, 2006.
 RABA Technologies. Trusted agent report: Diebold AccuVoteTS voting system. Available at http: //www.raba.com/press/TA Report AccuVote.pdf, January 2004.
 Bruce Schneier and John Kelsey. Cryptographic support for secure logs on untrusted machines. In
USENIX Security Symposium, January 1998.
 Science Applications International Corporation. Risk assessment report: Diebold AccuVoteTS voting system and processes (redacted version). Available at http://www.dbm.maryland.gov/dbm publishing/ public content/dbm search/technology/toc voting system report/votingsystemreportﬁnal.pdf, September 2003.
 Marc Songini. Evoting security under ﬁre in San Diego lawsuit.
Computerworld, August 2006.
 Trusted Computing Group. TCG TPM speciﬁcation. Available at https://www.trustedcomputinggroup. org/specs/TPM.
 United States Election Assistance Commission. Voluntary voting systems guidelines. Available at http://www.eac.gov/vvsg intro.htm, 2005.
 David Wagner, David Jefferson, and Matt Bishop. Security analysis of the Diebold AccuBasic interpreter. Available at http://www.ss.ca.gov/elections/voting systems/security analysis of the diebold accubasic interpreter.pdf, February 2006.
Ariel J. Feldman*, J. Alex Halderman*, and Edward W. Felten*,†
Center for Information Technology Policy and Dept. of Computer Science, Princeton University
†Woodrow Wilson School of Public and International Affairs, Princeton University
For the most recent
version of this paper, answers to frequently asked questions, and
videos of demonstration attacks, see: