Security Evaluation of ES&S Voting Machines andElection Management System

Adam Aviv Pavol Cerny Sandy Clark Eric Cronin Gaurav Shah Micah Sherr Matt Blaze{aviv,cernyp,saender,ecronin,gauravsh,msherr,blaze}@cis.upenn.edu

Department of Computer and Information ScienceUniversity of Pennsylvania

AbstractThis paper summarizes a security analysis of the DREand optical scan voting systems manufactured by ElectionSystems and Software (ES&S), as used in Ohio (and manyother jurisdictions inside and outside the US). We foundnumerous exploitable vulnerabilities in nearly every com-ponent of the ES&S system. These vulnerabilities enableattacks that could alter or forge precinct results, installcorrupt firmware, and erase audit records. Our analysisfocused on architectural issues in which the interactionsbetween various software and hardware modules leads tosystemic vulnerabilities that do not appear to be easilycountered with election procedures or software updates.Despite a highly compressed schedule (ten weeks) dur-ing which we audited hundreds of thousands of lines ofsource code (much of which runs on custom hardware),we discovered numerous security flaws in the ES&S sys-tem that had escaped the notice of the certification author-ities. We discuss our approach to the audit, which was partof Project EVEREST, commissioned by Ohio Secretary ofState Jennifer Brunner.

1 IntroductionIn response to concerns about the security and reliabil-ity of electronic voting systems, Ohio Secretary of StateJennifer Brunner initiated the “Evaluation & Validationof Election-Related Equipment, Standards and Testing(EVEREST)” [18] study in October 2007. Similar inscope to the California Secretary of State’s top-to-bottomreview of electronic voting systems [8, 7, 2, 15, 3, 25,6, 23], the EVEREST project aimed to identity poten-tial weaknesses in Ohio’s voting systems – specifically,systems developed by Election Systems and Software(ES&S), Hart InterCivic (Hart), and Premier Election So-lutions (formerly Diebold).

In this paper, we summarize the results of our audit ofthe ES&S voting system for the Ohio EVEREST study.

EVEREST was the first major study of ES&S voting sys-tems, despite the system’s popularity (ES&S claims to bethe world’s largest e-voting systems vendor [1], support-ing more than 67 million voter registrations with 97,000touchscreen voting machines installed in 20 states and30,000 optical ballot readers present in 43 states [4]), andonly the second comprehensive study that examined allcomponents – from backend registration systems to fron-tend ballot casting – of any electronic voting system. In aten week period, our seven-member team was tasked withanalyzing the nearly 670,000 lines of source code thatcomprise the ES&S system, encompassing twelve pro-gramming languages and five hardware platforms1.

Currently deployed electronic voting systems are inar-guably complex (often involving hundreds of thousandsof lines of code), and are subject to numerous potentialattacks, including denial-of-service, alteration or forgeryof precinct counts, compromise of official tallies, machinefirmware, ballot displays, audit/recount data, and ballotsecrecy violations, among others. Since an exhaustive ex-ploration of the entire system was infeasible given our tenweek mandate (to say nothing of the huge code base), ourapproach focused on examining the modules that we be-lieved to be most likely problematic – in particular, thosedealing with pseudorandom number generators, cryptog-raphy, memory management, and input processing.

Despite our admittedly incomplete analysis, we identi-fied numerous critical vulnerabilities in nearly every com-ponent of the ES&S system. We describe serious practicaland undetectable attacks that could be carried out by poll-workers, and in many cases, individual voters. (As a note-worthy example, a voter can surreptitiously delete all vote

1During the EVEREST study, we examined the specific ES&S hard-ware and software versions (see appendix for specific version numbers)that are certified for use in Ohio. Although other states may use differ-ent ES&S components, we believe that most of our findings, particularlythe systemic issues identified in Section 4, are likely applicable to otherversions of the system as well.

1

data and audit logs stored on a touchscreen voting ma-chine using a Palm handheld device and a small magnet.)Such attacks could alter or forge precinct results, installcorrupt firmware, and erase audit records. Of particularconcern, several attacks could spread virally, propagatingbetween voting machines and backend systems, and viceversa.

This paper focuses on architectural issues of the ES&Svoting system. We describe vulnerabilities in each of theES&S components, and show how the interaction of thevarious software and hardware modules leads to systemicvulnerabilities that do not appear to be easily counteredwith election procedures or software updates. In partic-ular, we saw evidence of four fundamental and pervasivedeficiencies that gave rise to many of the most serious se-curity flaws.

2 Related WorkThe security and reliability of electronic voting systemshave long been a matter of concern. In 2003 Kohno etal. [17] published a study in which they listed numeroussecurity flaws found in a leaked version of the DieboldBallotStation source code. Since that time, several states,most notably Maryland [20], Ohio [14], California [24],and Florida [11, 10, 25] have authorized independentstudies of the voting systems used in their elections. Ad-ditionally, several independent researchers have releasedreports analyzing voting machine hardware and softwaresecurity [9, 12, 13].

All of these studies report numerous security vulner-abilities in the machines or software they reviewed, andwith one exception [8], all of the studies focus their at-tention on an individual model of a voting machine (pre-dominantly Diebold Accuvote DREs), or a single aspectof a voting system, such as the backend database or thefirmware. The first documented in depth analysis of anentire state’s voting system was performed by the Califor-nia Top-to-Bottom Review [8]. However, ES&S systemswere not evaluated in that study.

A few studies have examined the ES&S products. Thereview commissioned by Florida Department of State [25]looked exclusively at the iVotronic firmware version8.0.1.2. It did not examine any of the other ES&S soft-ware or hardware. The review commissioned by the Cali-fornia Office of the Secretary of State [5], published afterthe EVEREST study, looked at the source code used byES&S machines, but did not analyze the hardware. Ad-ditionally, our analysis was conducted in parallel with ananalysis by an independent security assessment companyMicroSolved, Inc., with SysTest Labs [19]. While thisconcurrent study found many vulnerabilities, they did not

Figure 1: The high level overview of the ES&S Unity vot-ing system with user input to each stage of the election.

Figure 2: An ES&S “Personalized Electronic Ballot”(PEB) used to transport ballots and results between theiVotronic and Unity.

have access to the source code.To our knowledge, our report provides the first com-

prehensive, in depth analysis of the entire ES&S votingsystem.

3 ES&S System OverviewIn this section we will describe how the individual com-ponents of the ES&S system inter-operate to conductan election. We will begin by providing a high leveloverview, and then discuss relevant components in moredetail.

3.1 Architectural High Level OverviewThe election management system (EMS) from ElectionSystems & Software (ES&S) prepares, collects, and tab-ulates elections using either paper ballots or touchscreenterminals (or a combination of both). It contains softwarefor managing all stages of an election, as well as specialhardware interfaces for configuring and retrieving resultsfrom the election devices. The high level architecture ofthe ES&S system is shown in Figure 1.

2

Unity is the election management software suite. It iscomprised of a number of individual programs which in-teract with one another through shared data files (collec-tively referred to as the “database”). Election Data Man-ager is used to initialize the database with jurisdiction,voter, and candidate information. ES&S Image Managerand iVotronic Image Manager are used to design the ap-pearance of paper and touchscreen ballots. The ElectionReporting Manager is used to collect and tally electionresults, and the Audit Manager is used to verify electionresults using audit data. All interaction between Unity andvoting hardware is controlled by the Hardware Program-ming Manager program.

The iVotronic is a touchscreen direct recording elec-tronic voting terminal (DRE). There are two distinct typesof iVotronic terminals, distinguished by colored insertsalong the sides: red supervisor terminals and blue voterterminals. Both types of iVotronic terminals are activatedusing special hardware tokens called Personalized Elec-tronic Ballots (PEBs), which are also used to store ballotdefinitions and election results (see Figure 2). PEBs aretypically programmed via a supervisor terminal at the startof an election, and read using either a supervisor terminalor a dedicated PEB Reader connected to the machine run-ning the Election Reporting Manager at the end of an elec-tion. A PEB can be used in multiple iVotronics as long asthey are qualified for the same election and polling place.

The voter iVotronics also use Compact Flash cards tostore large ballots, audio ballots, and election result auditfiles. A printer which provides a voter-verified paper audittrail, known as the Real-Time Audit Log is connected tothe iVotronic.

The Model 100 is a machine for scanning and validat-ing/tallying paper ballots at a polling location. The Model100 uses PCMCIA Memory Cards to hold ballot defini-tions and tallies.

The Model 650 is a machine for batch scanning and tal-lying paper ballots at a central election office. The Model650 uses Zip Disks to hold ballot definitions and electiontallies.

3.1.1 UnityUnity is the Windows-based software suite for manag-ing elections. It contains tools for creating and manag-ing election databases (Election Data Manager), design-ing the appearance of ballots (ES&S and iVotronic ImageManagers), tabulating and reporting results (Election Re-porting Manager). Additionally, there is a tool to audit theuse of the other components of Unity (Audit Manager),and a tool for abstracting programming and communi-cating with the various hardware components used by

several Unity components (Hardware Programming Man-ager). The various components of Unity communicatewith each other indirectly through common files storedon the Windows filesystem.

3.1.2 Hardware ComponentsIn this subsection we will review the different hardwarecomponents of the ES&S voting system. These includethe DRE iVotronic interfaces, the M100, and the M650. Inaddition, some of the media interfaces used by the hard-ware components will be discussed in more detail.

The iVotronic is a touchscreen DRE based on an Intel386 processor with 1 MB of SRAM. There are four in-ternal flash memory devices. There are two serial portsfor input/output on the iVotronic, one connected to a stan-dard DB9 serial port at the top of the iVotronic, and theother to an infrared transceiver. The external serial port isused to connect to the RTAL printer or a communicationspack to report from the field, or to a computer runningUnity HPM or ERM in the central election office. Theinfrared serial port is used to communicate with the Per-sonalized Electronic Ballot hardware tokens. The left sideof the iVotronic case has a molded socket to hold a PEBallowing IR communication as well as activation of theiVotronic power switch through a magnetic reed switch.A Compact Flash slot is also located next to the printerserial port. There are two types of iVotronic terminalsused in elections: red “Supervisor iVotronics” are used bypoll workers or elections officials to administer the elec-tion, and blue “Voter iVotronics” are used by voters to casttheir votes.

The red iVotronic Supervisor Terminal is used tomanage PEBs and the contents of their flash memory be-fore, during and after elections. It plays a far more sig-nificant role in the Voter Activated Voting mode (whichis not used in Ohio elections, thus not studied in our re-port), where at least one Supervisor Terminal must be atevery polling place. In the Poll Worker Activated Votingmode used in Ohio, a Master PEB for each polling lo-cation is created from HPM using a Supervisor Terminalconnected via null modem cable. Afterward, each Mas-ter PEB is then cloned several times using a SupervisorTerminal (standalone from Unity) in order to produce theSupervisor PEBs needed while the polls are open. At thispoint, the supervisor terminal is no longer required foropening, closing, or tallying the election.

The blue iVotronic Voter Terminal is the iVotronicused by voters to cast their ballot. When a qualified Su-pervisor PEB is inserted the iVotronic prompts the pollworker to select the correct ballot to be voted on. If aSupervisor PEB is inserted while holding the “Vote” but-

3

ton above the touchscreen, a service menu appears. Thismenu allows various settings of the terminal to be ad-justed, and also provides the interface for opening andclosing the polls. While in the service menu, actions per-formed are logged to the RTAL printer.

The Real-Time Audit Log Printer (RTAL) is a con-tinuous feed thermal printer that provides the function ofVVPAT (Voter Verifiable Paper Audit Trail) on an iV-otronic machines. It is connected to the iVotronic by astandard 9-pin RS232 serial cable, and mounted behind aPlexiglas window next to the iVotronic.

The Personalized Electronic Ballot (PEB) is a palm-sized device containing a PIC micro-controller, 2MB offlash storage, a bi-directional infrared (IR) transceiver,and battery. The PEB is activated by a magnetic reedswitch, and contains a magnet to activate the correspond-ing reed switch in the iVotronic PEB socket. The micro-controller firmware implements the passive half of a verysimple command/response protocol between the PEB andhost over the PEB IR port using IrDA SIR (Serial In-frared). The primary operation is reading and writing 128byte blocks of the PEB’s flash memory, or verifying theintegrity of blocks using a cyclic redundancy check (CRC)stored with each block. The last memory block of the PEBis known as the Election Qualification Code (EQC) block,and serves to authenticate the PEB to the iVotronic. PEBs,along with the compact flash cards can be used to storevote tally information for an election.

The Model 100 (M100) is a voter-operated optical scanballot counter intended for use at the polling location. Itis mounted on top of a secure ballot box which holds theaccepted (and counted) ballots and provides physical se-curity for the M100. The M100 provided in our studyused one set of identically keyed locks for physical pro-tection of the M100 and ballots, and a second differentlykeyed lock for selecting the mode of the M100. Unity (viathe HPM) and the M100 use specially formatted PCMCIASRAM flash storage cards for all communications. Thecards are formatted so that a small header can be loadedinto the M100’s RAM which contains pointers into theSRAM for ballot definitions and results counters. Thesame header information also informs the M100 if thiscard is formatted for a firmware upgrade.

The Model 650 (M650) is a centralized high-speed op-tical ballot counter intended for use at a central electionsoffice. It scans batches of ballots, possibly from multipleprecincts, and tabulates results to be transferred to Unity.Additionally, an Iomega Zip 100 drive is used to trans-fer ballot definitions and perform firmware updates to theM650, and carry results from the M650 to Unity. TheM650 uses FAT32 formatted 100MB Zip disks to load

ballot configurations and store tallies of counted ballots.The files on the disk are copied by the Hardware Program-ming Manager. In Windows, these disks are mounted tothe desktop and accessible to any Windows applicationwith no special libraries.

The hardware and software system components are de-scribed in detail in Chapter 5 of [18].

4 Systemic and Architectural IssuesThere are fundamental security deficiencies throughoutthe ES&S Unity EMS, iVotronic DRE and M100 opticalscanner software and hardware. Virtually every mecha-nism for assuring the integrity of precinct results and forprotecting the back-end tallying system can be circum-vented. Election results can be tampered within the ES&Ssystem by exploiting any of a number of different vulnera-bilities that were discovered. The normal access providedto individual precinct poll workers (and in some cases tovoters themselves) is sufficient to conduct attacks that al-ter county-wide election results and that, in some cases,cannot be detected or recovered from through audits orrecounts.

Perhaps more importantly, we show how the interac-tion of the various software and hardware modules leadsto systemic vulnerabilities that can spread throughout thesystem. There is a strong potential for practical attacksthat propagate “virally” from the field back to the countyelection management system. That is, a single circum-vented piece of precinct hardware (such as a memory cardreturned from a precinct for vote tallying) can effectively“take over” the county-wide back-end tally system, altercounty-wide results reported in the current election, andthen corrupt the installed firmware of additional precincthardware in subsequent elections. The broad scope ofsuch attacks provides great leverage to the adversary andcan be extraordinarily difficult to detect, trace, or recoverfrom. Different possibilities of how the firmware of eachcomponent can be altered by inputs from other compo-nents are described in Section 5.

Both the DRE (iVotronic) and the precinct-based opti-cal scan (M100) systems are subject to many exploitablevulnerabilities. However, the DRE system provides morevectors for attacks that cannot be recovered from throughmanual recounts. While there are many specific errors andweaknesses in various parts of the ES&S software (andwhich are detailed in our earlier public report[18]), ourfocus is on systemic weaknesses throughout the system’soverall design and implementation. Hence, the followingis just a partial sample of the vulnerabilities we discov-ered. These weaknesses render the system as a whole dif-ficult to secure in practice. We identify four fundamental,

4

Figure 3: A PEB emulator running on a Palm device sim-ulates an initialization PEB during an open election, reset-ting all iVotronic passwords.

Figure 4: Unhindered access to printer connection allowsdisabling the iVotronic VVPAT audit log as well as theability to print unauthorized data to the audit log.

pervasive deficiencies that give rise to the most seriousvulnerabilities we found: ineffective access control, crit-ical errors in input processing, ineffective protection offirmware and software and, ineffective cryptography anddata authentication.

4.1 Ineffective Access Control

The firmware and configuration of the ES&S precincthardware can be easily tampered with in the field. Vir-tually every piece of critical data at a precinct – includingprecinct vote tallies, equipment configuration and equip-ment firmware – can be compromised through exposedinterfaces, without knowledge of passwords and withoutthe use of any specialized proprietary hardware.

4.1.1 iVotronic passwords and PEB-based accesscontrols

Access to the iVotronic DRE configuration is protected byseveral hardware and password mechanisms, all of whichcan be defeated through apparently routine poll worker(and in some cases voter) access.

The primary mechanisms for preparing iVotronic DREsemploy the Personalized Electronic Ballot (PEB) inter-face. As described in Section 3.1.2, a PEB is a smallmodule that communicates with the iVotronic via a mag-netically switched infrared bidirectional data interface onthe terminal. PEBs are used as external memory devicesthat communicate through a simple protocol that allowsthe iVotronic to read and write memory blocks stored inthe PEB. Access to PEB memory is not protected by en-cryption or passwords, although some of the data storedon them is encrypted (see Section 4.4). PEBs themselvesare proprietary devices but they employ IrDA, which is awidely-used infrared communication standard.

Some of the PEB’s functions are intended to be per-formed at the county headquarters (e.g., loading ballotdefinitions and basic configurations), while others are per-formed by poll workers (e.g., opening the terminals at thebeginning of the day, enabling a voter to use a particularballot, closing the terminal and collecting vote totals).

In spite of the proprietary nature of the “official” PEB,it is relatively simple to emulate a PEB to an iVotronicor to read or alter the contents of a PEB using only inex-pensive and commercially available IrDA-based comput-ing devices (such as Palm Pilot PDAs and various mobiletelephones).

Most of the administrative and poll worker functions ofthe iVotronic (e.g., pre-election ballot loading, enablingvoting, etc) require the insertion of a properly configured“supervisor” PEB and, in some cases, the entry of a pass-word on the terminal touchscreen. However, it is possibleto defeat both of these security mechanisms. This makespractical several possible attacks at polling stations.

Unauthorized screen calibration and configurationOne of the simplest, and yet most important, configu-ration parameters of the iVotronic is the calibration ofits touchscreen. Calibration (which is done through thescreen itself) affects how voters’ tactile input maps to dif-ferent locations on the screen. If performed incorrectly ordeliberately altered, voter choices might not be correctlyrecorded. Calibration can be performed, for example, in amanner that allows most input to behave normally, but thatdenies access to specific screen regions corresponding toa candidate selection.

Access to the screen calibration function of the iV-

5

otronic terminal requires the use of a supervisor PEB dur-ing power-up (e.g., after voting or at idle times). No pass-word is required. Any supervisor PEB is sufficient forthis purpose, even one not specifically configured for thecorrect precinct or obtained from some other jurisdiction(e.g., through secondary markets such as eBay). A home-made PEB emulator (e.g., a specially programmed PalmPilot and a small magnet) is also sufficient. The procedurerequires about a minute and is, from a distance, largely in-distinguishable from normal voter behavior2.

While a maliciously calibrated terminal may be noticedby voters and can, in principle, be corrected in the field,the attack is extremely simple for a poll worker (or otherperson with access to a PEB) to carry out and practicaleven without a PEB, and so may represent a serious prac-tical threat. We note that iVotronic behavior consistentwith such attacks has been reported in various jurisdic-tions during actual elections [21].

Undocumented PEB features can bypass passwordchecks Many of the more sensitive iVotronic adminis-trative functions (closing the polls, clearing the terminal,etc) require the entry of passwords in addition to the in-sertion of a supervisor PEB. However, there is a specialQuality Assurance (QA) PEB type recognized by the iV-otronic that behaves essentially as a supervisor PEB butthat, when used, does not require the entry of any pass-words. This PEB type does not appear to have been docu-mented in any of the ES&S manuals or training materialsprovided to us during our review3.

This undocumented PEB feature can be used to neu-tralize the security of any iVotronic administrative fea-tures that depend on passwords. Anyone with such a PEB(whether emulated or acquired) effectively has a back-door that bypasses this basic security check. QA PEBs areno more difficult to emulate than regular supervisor PEBs;the only difference being a single character changed in thecommunication protocol.

Note that while the QA PEB bypasses password checks,there is another iVotronic security feature required for ac-cess to some (but not all) administrative functions, Forthese functions, a PEB must be configured with the cor-rect Election Qualification Code (EQC) (a 32 bit randomnumber assigned for each election). However, as notedin the next section, precinct poll workers (and others withbrief access to the poll worker equipment) can easily ex-tract this code from the precinct’s supervisor PEB using a

2Further details about this vulnerability can be found in Sections7.2.8 and 7.2.13 of [18].

3Further details about this vulnerability can be found in Sections7.2.10, 7.2.11 and 7.2.12 of [18].

palmtop computer.Note that even without the EQC, however, an attacker

(who needs no more access than that provided to a normalvoter) with a QA PEB (or an emulated QA PEB) can do agreat deal of harm to an iVotronic terminal. For example,the EQC is not required for the “clear-and-test” routineon an iVotronic terminal, which erases all stored votes andrenders the terminal useless for the rest of the election day.

Unauthorized PEB copying and alteration Anyonewith physical access (or close proximity) to PEBs caneasily extract or alter their memory. This requires onlya small magnet and a conventional IrDA-based palmtopcomputer because PEBs themselves enforce no passwordsor access control features4.

The ease of reading and altering PEB memory facil-itates a number of powerful attacks against a precinct’sresults and even against county-wide results. An attackerwho extracts the correct EQC, cryptographic key, and bal-lot definition can perform any election function on a corre-sponding iVotronic terminal. An attacker who has accessto a precinct’s main PEB when the polls are being closedcan alter the precinct’s reported vote tallies, and can in-ject code that takes control over the county-wide back-endsystem (and that thus affects the results reported for all ofa county’s precincts).

Individual precinct poll workers have many dutiesthat involve handling PEBs throughout the election day(whenever a voter votes, for example), and so are in a nat-ural position to carry out attacks that involve altering orreading PEB memory without engaging in suspicious ac-tivity.

4.1.2 Physical security, locks and sealsMany aspects of the ES&S system’s security as a wholedepend on the integrity of the interfaces and removablemedia associated with precinct equipment. Some of theseare protected by software security (e.g., access passwords,encryption, etc); potential attacks against such mecha-nisms are discussed elsewhere (see Sections 4.1 and 4.4).Many interfaces and media are also protected (partly orentirely) by physical mechanisms: locks, seals, and pro-cedures.

Several features of the iVotronic’s physical security areespecially problematic. A primary mechanism for loggingevents (including those potentially associated with an at-tack) is the RTAL printer5. However, the cable connect-

4Further details about this vulnerability can be found in Sections7.2.2, 7.2.3 and 7.2.4 of [18].

5Further details about this vulnerability can be found in Section7.2.14 of [18].

6

ing the printer is readily accessible to the voter and canbe removed easily and without tools or overtly suspiciousactivity (see Figure 4). Using the unprotected printer in-terface, the attacker can also print arbitrary messages in-cluding VVPAT ballots. In addition, it is important to notethat the PEB interface is exposed and facilitates the at-tacks noted above.

The mechanical locks supplied with all of the ES&Sprecinct equipment were uniformly of very low-securitydesigns that can be easily picked or otherwise bypassed.Many locks use keys that are apparently identical inequipment shipped to different customers, and so wouldprovide little security even if the locks were improved6.

More importantly, all but most sophisticatedcommercially-available tamper seals are often sur-prisingly easily to defeat [16]. Even if effective atrevealing tampering, seals are inherently limited in theprotection they provide. As noted in previous studies [6],seals do not prevent tampering; at best they can detect it.But in an election, even reliable detection of tamperingmay be unsatisfying, since if a seal is found to be brokenonce polling has started, it is unclear what should bedone. If the compromised equipment is used, fraudulentvotes may be counted. If it is not used, previously castlegitimate votes may be lost (making breaking a seal asimple way for an attacker to destroy votes).

4.2 Critical Errors in Input ProcessingWe identified two critical components of the ES&S sys-tem which suffer from exploitable errors in functions thatprocess input over their external interfaces. Both theUnity and the iVotronic terminal have buffer overflows,that allow an attacker who can provide input (e.g., on aPEB or memory card) to effectively take control over thesystem.

We found numerous buffer overflows throughout theES&S system. Several of these buffer overflows haveextremely serious practical security implications. An at-tacker who can present input using an iVotronic PEB oran M100 memory card can take control over the resultsreported by the entire county election system.

Most seriously, the nature of these vulnerabilitiesmeans that there are few barriers to obtaining the accessrequired to exploit them. In the case of the iVotronic sys-tem, voter access to the terminal is sufficient. In the caseof the Unity system, brief access to any iVotronic or M100optical scan results media returned back to the county forprocessing is sufficient.

6Further details about this vulnerability can be found in Sections7.3.4 and 7.3.5 of [18].

4.2.1 UnityThe Unity election management system processes allprecinct results and produces the tally reports that, in mostcases, constitute the official tallies in races. After polls areclosed, precinct-counted ballot results are received intoUnity through several different media, including iVotronicPEBs, iVotronic CF cards, and M100 PCMCIA memorycards.

While Unity appears to correctly process properly-formatted results from such media, buffer overflows inUnity allow a maliciously altered input to execute arbi-trary code on the computer on which Unity runs.

Attack via a PEB A stack-based buffer overflow inUnity can be exploited when election, pre-election, ortesting results are processed. An attacker can exploit thisvulnerability by creating a specially-crafted PEB that willallow arbitrary code execution. As a result, an attackerhas the ability to gain full control of the machine runningthe Unity server7.

Attack via a M100 PCMCIA memory card Aspecially-crafted PCMCIA memory card can take advan-tage of the underlying assumptions by Unity on the max-imal number of precincts reported per card to exploit abuffer overflow and take full control of the Unity server8.

Corrupting county-wide results PCMCIA cards re-turning results from precincts are not checked by Unityto see if they correspond to cards that were actually con-figured for the M100 scanners being used at the pollinglocation. A poll worker can thus take a card with elec-tion results and insert additional results for a precinct forwhich the card was not configured for. A malicious pollworker can therefore not only modify the results for his orher own precinct, he or she can influence the results forother precincts as well. A careful and attentive operatorusing Unity can catch this attack, in case he or she hasa list of cards (their serial numbers) and the number ofprecincts that should be reported for each card.

Note that because these vulnerabilities affect the cen-tral counting system, a corrupted media attack conductedfrom any single precinct can corrupt results for the entirecounty9.

7Further details about this vulnerability can be found in Section 7.1.1of [18].

8Further details about this vulnerability can be found in Section 7.1.2of [18].

9Further details about this vulnerability can be found in Sections7.1.3 of [18].

7

4.2.2 iVotronicThe iVotronic terminal firmware has several exploitablebuffer overflow errors in its PEB input processing func-tions. These buffer overflows allow a PEB containingcarefully-structured data (or an emulated PEB) to takecontrol over the terminal10. The implications of attacksagainst iVotronics are discussed in Section 4.3.

It is straightforward to exploit the iVotronic buffer over-flows in several different ways (by emulation of a QA orsupervisor PEB or by writing data to a precinct’s supervi-sor PEB) at various times (while opening polls and duringthe polling day), and with various degrees of access (as apoll worker or as a voter). The exposed nature of the PEBport and the many different scenarios under which it canbe exploited make attacks against the iVotronic very diffi-cult to effectively guard against under operational electionconditions.

4.3 Ineffectively Protected Software andFirmware

The integrity of election results depends heavily on theintegrity of the software and firmware that runs the cen-tral election management system and the precinct hard-ware. The consequences of any attack that alters, replacesor otherwise compromises this software or firmware aresweeping and often impossible to recover from. The se-curity features that protect election software and firmwarefrom unauthorized tampering are therefore among themost critically important safeguards in the system as awhole.

We found exploitable vulnerabilities that allow an at-tacker to replace or alter the firmware and software of vir-tually every component of the ES&S system, either bycircumventing access controls or by triggering softwareerrors.

4.3.1 iVotronic firmwareThe iVotronic terminal is based on an Intel 80386 embed-ded computer processor controlled by firmware stored onan internal flash memory chip. The firmware is designedto be field-updated through an administrative menu func-tion, with new firmware loaded though the terminal’s CFcard interface. Four security mechanisms are intended toprotect against unauthorized firmware loading:• Access to the firmware update menu function re-

quires a supervisor (or QA) PEB.

• A 6-8 character password is required to enablefirmware update.

10Further details about this vulnerability can be found in Sections7.2.5, 7.2.6 and 7.2.7 of [18].

• The firmware is loaded through the CF card inter-face, which can be protected by a sealed slidingcover.

• The firmware update function is disabled while thepolls are open.

Unfortunately, these mechanisms are ineffective. Thereare several practical ways for an attacker to bypass eachof these security mechanisms and successfully replace oralter the iVotronic firmware, without knowledge of anypasswords or secret election parameters, possession of aPEB, or breaking any seals. These attacks can be carriedout even when the polls are open. It is possible, for ex-ample, for a voter (with no inside assistance) to load newfirmware into an iVotronic after he or she is finished vot-ing.

We found at least three different vectors that an attackercould exploit to load unauthorized iVotronic firmware un-der various circumstances.

Via direct replacement of the internal flash chip: TheiVotronic terminal housing can be disassembled eas-ily without breaking the seal that protects the CFslot. Disassembling requires only the use of a readilyavailable Torx security screwdriver. Once the hous-ing has been removed, the internal flash chip can beremoved from its socket, reprogrammed with a stan-dard flash writer, and replaced. Note that while sur-reptitious terminal disassembly is unlikely to be pos-sible in an active polling place, it may be an attrac-tive option for an attacker who enjoys unsupervisedaccess to stored terminals (e.g., the night before anelection).

Via the firmware update menu: This is the most di-rect attack against firmware. As discussed before, anattacker can emulate a QA PEB and bypass the pass-word check. If the polls are open, they can be closedby using an emulated QA PEB to clear the termi-nal first. Note that with this approach, the firmwaremust be loaded though the external CF card interface,which might be protected with a tamper-evident seal(although that seal can be bypassed by removing thehousing).

Via the PEB interface, during the polling day: Thisis perhaps the most serious practical threat to the iV-otronic firmware. As discussed in Section 4.2, er-rors in the iVotronic’s PEB input processing codeallow anyone with access to the PEB slot on theface of the terminal (including a voter) to load ma-licious software that takes complete control over theiVotronic’s processor. Once loaded, this software can

8

alter the terminal firmware, change recorded votes,mis-record future votes, and so on throughout theelection day and in future elections.

Any compromise of the iVotronic firmware is ex-tremely serious; it can be very difficult to detect whethersuch firmware has been used in a live election or mean-ingfully recover once it has. The firmware controls everyaspect of the ballot presented to voters, the recorded votes,and the interface to the tally system. Because the RTALprinter is under the control of the firmware, compromisedfirmware can easily print misleading choices that evadethe notice of voters or that cancels the printed ballot (re-placing it with other choices) after the voter has left. Thediscovery of compromised firmware at a terminal castsdoubt upon every vote cast at that machine (and, becauseof additional bugs in the Unity back-end, on the integrityof the results reported county-wide as well).

Compounding the problem is the fact that there are ap-parently no tools available to counties in the ES&S systemthat reliably extract or audit the actual firmware present inany given terminal. The iVotronic firmware code includesa number of internal consistency checks intended to de-tect corrupted firmware. While these checks may be ableto detect accidental memory errors, they are ineffectiveagainst maliciously installed firmware, which can simplybypass or omit the integrity check functions.

4.3.2 Unity softwareNo single component of the ES&S system is more im-portant to the integrity of election results than the centralUnity election management system. Unity is a complexsoftware suite, consisting of many components that sharea common database. Securing a county’s Unity systemtherefore depends on each of its components (and on thecomputing platforms on which it runs, Windows).

Because Unity (at least as used in Ohio) apparently runsonly in a single, secure location in each county, with pre-sumably only trusted staff permitted access to the comput-ers, attack vectors involving unauthorized direct physicalaccess by poll workers, voters or others are a less signif-icant threat here than in precinct equipment sent to thefield. However, because the Unity system processes elec-tronic data received from precincts, it is subject to a num-ber of indirect – yet devastating – attacks that can origi-nate with poll workers or voters, even if they cannot them-selves physically touch the Unity computers.

Attacks via input from precincts As described in Sec-tion 4.2.1, malicious input carried on iVotronic and M100results media can take over the Unity system when it is

loaded for counting. This enables many of the most seri-ous and comprehensive attacks we discovered.

4.3.3 M100 firmwareFirmware can be loaded into the M100 via a speciallystructured PCMCIA card, the same card used duringpolling for ballot definitions and other precinct param-eters. If new firmware is present on the card when theM100 is turned on, there is a brief screen prompt and thenew firmware is loaded. No password is required. TheM100 does not perform cryptographic integrity checks onfirmware uploads. Any correctly formatted PCMCIA cardwith M100 firmware (including malicious code created byan attacker) can be installed and accepted as valid. Anypoll worker (or other person) with access to the PCMCIAcard slot can thus easily load new firmware11.

Because the firmware is loaded from the same PCM-CIA cards used to load ballot definitions, corrupt firmwarecan also be loaded into the M100 by a corrupted Unitysystem when an election is provisioned.

M100 firmware controls how ballot definitions are in-terpreted, the counting and recording of votes, the formatof data returned to Unity, and the acceptance and rejectionof ballots. The consequences of corrupt M100 firmwareare serious, especially given the vulnerabilities in Unityresults processing. However, since the paper ballots re-main available, they can be recounted if an attack mighthave occurred.

Unfortunately, as with the iVotronic, there is no mech-anism for reliably determining or auditing the actualfirmware installed in an M100, so attacks on these devicesmay be difficult to detect or confirm.

4.4 Ineffective Cryptography and Data Au-thentication

Much of the critical election data in the ES&S system– ballot definitions, precinct vote tallies, and so on –are communicated between the central county headquar-ters and precincts through small removable storage media.In iVotronic DRE-based systems, the primary media arePEBs and, in some cases, CF memory cards. In M100-based precinct counted optical scan systems, the primarymedia are PCMCIA memory cards.

These media share two important characteristics thatmake them attractive targets for attack: they have no in-trinsic security properties of their own and they may passthrough many hands on the way to polling places, duringthe polling day, and back from polling places. That is, it is

11Further details about this vulnerability can be found in Section 7.3.1of [18].

9

simple to read or alter data on these media, and many peo-ple may have the opportunity to do so during an election.For example, iVotronic PEBs are handled by poll workersall through an election day, with memory that can be reador written with a standard palmtop computer and a smallmagnet. PCMCIA and CF cards, similarly, can be readilyread or altered with standard laptop computers.

Data stored on such media should be secured by theuse of cryptographic techniques that prevent meaningfulaccess to data without knowledge of the correct key.

Unfortunately, the ES&S system does not employ cryp-tography at all in the M100-based optical scan system.The iVotronic DRE system does use cryptography, buterrors in its implementation render the protection com-pletely ineffective. The lack of effective cryptographicprotection enables a large fraction of the exploitable vul-nerabilities in the whole system.

Unauthenticated M100 data M100 PCMCIA cards areused to load ballot definitions and firmware into the M100and to report tallies back to the Unity system. The datafor each of these functions are not cryptographically pro-tected; an attacker with access to an M100 PCMCIA cardcan easily forge or modify this data. A linear cyclic redun-dancy code (CRC) is included with the PCMCIA data, butan attacker can easily calculate this; CRC codes are notkeyed and are not designed to provide security against de-liberate data modification12.

Ineffective iVotronic cryptography The iVotronicDRE uses the Blowfish [22] cipher to protect data storedon the PEB and the CF card. Unfortunately, the man-ner in which the encrypted data are stored on the PEBseffectively neutralizes the cryptographic protection. ThePEB contains an EQC, encoded using an unkeyed (non-cryptographic) algorithm. The EQC is used to encrypt theBlowfish key, which is used to the encrypt the rest of thedata on the PEB. Remarkably, both the EQC and the en-crypted key (which, again, is encrypted using the EQC)are present on the PEB. Although much of data on thePEB is encrypted, there is sufficient unencrypted informa-tion stored along with it that allows an attacker to triviallydiscover the key13.

Lack of results integrity in Unity The obvious at-tacks enabled by the lack of cryptographic protection of

12Further details about this vulnerability can be found in Sections7.3.3 and 7.3.6 of [18].

13Further details about this vulnerability can be found in Section 7.2.1of [18].

precinct media include alteration or forgery of data, unau-thorized loading of firmware, as discussed in the rest ofthis report.

Additional vulnerabilities are introduced by Unity’spoor validation of various reported precinct data. In par-ticular, the precinct results reported on an incoming M100PCMCIA card are not checked against the precincts forwhich the card was originally provisioned. This allowsanyone with access to a card to add tally results for extraprecincts, which will be added to (or supplant, dependingon the mode the Unity operator is using) the true precinctresults when read into the database, as described in Sec-tion 4.2.1.

5 Viral Propagation through Com-ponent Interaction

The software or firmware of almost every major compo-nent of the ES&S system can be altered or replaced byinput from the other components with which it communi-cates. In particular, note that, by design or software flaw:

• The Unity system software can be modified by elec-tion results media originating from iVotronics andM100s (due to Unity buffer overflows)

• The iVotronic firmware can be modified by configu-ration media originating from the Unity system (dueto iVotronic buffer overflows).

• The M100 firmware can be modified by configura-tion media originating from the Unity system (due tothe design of the M100 firmware management func-tions).

• A compromised iVotronic can modify a PEB suchthat it carries a malicious payload which infects otheriVotronics on which it is subsequently used. ThisiVotronic to iVotronic propagation can happen, forexample, while a master PEB is being used to runLogic-and-Accuracy tests on the iVotronic terminalsbeing used in a particular election.

This confluence of vulnerabilities creates a “closedloop” for viral propagation into every part of the ES&Ssystem through the compromise of a single system com-ponent. The viral loops in the system are depicted on Fig-ure 5.

For example, a voter can compromise an iVotronic ter-minal though its PEB slot. The iVotronic, then, may beprogrammed to create results media (at the end of the elec-tion day) that, in turn, corrupts the software of the centralUnity system. The compromised Unity system, in turn,may be programmed to load corrupted firmware into all

10

Unity

iVotroniciVotronic M100

Election Headquarters

Results

Ballots

Ballots

Results

Open/Close

Figure 5: Viral loops through ES&S components

M100s and iVotronics in the county when provisioning asubsequent election. At this point, every major compo-nent of the system is running compromised code, whichoriginated with a single attacker with only voter access ina single precinct. Needless to say, such an attack repre-sents a grave threat to the integrity of the elections of anyjurisdiction to which this happens14.

6 Reviews by Commercial Consul-tants

In addition to our analysis, two commercial contractorsexamined the ES&S systems as part of Project EVEREST.SysTest Labs, a NIST approved testing lab performed au-dits of the documentation, county election procedures andthe hardware, software and firmware versions. A pro-fessional security assessment company, MicroSolved, Inc(MSI) performed independent vulnerability analysis andpenetration testing.

The MSI team applied a systematic evaluation method-ology of attack surface mapping, threat modeling, andpoor trust/cascading failure analysis to assess where tofocus their attention, and then used standard pen-testingtools including attacking physical security, network scan-ning and ’fuzzing’ to locate and exploit several vulnera-bilities in the ES&S system. These methods were espe-cially successful at attacking the Windows 2003 serversand Windows XP Professional workstations used to man-age the election and host the Unity software, and at findingthe physical vulnerabilities that would allow an attackeraccess to the system internals.

These methods were less successful in exploiting thevulnerabilities found in the ES&S components. For ex-ample MSI noticed that a simple magnet could activatethe iVotronic DRE, and the MSI team was also able to ac-cess many of the open, unprotected ports, but were unableto tamper with the serial protocols. Because of this, MSIwas not able to demonstrate that many of the attacks theyenvisioned in their threat model were actually practicalrather than merely possible. Therefore they were unaware

14This attack scenario is described in detail in Section 9.3.11 of [18].

of the vulnerability of Unity to an attack on any of it’s in-dividual components, and they couldn’t discover the moreserious vulnerabilities which involve interactions betweencomponents and could lead to viral propagation.

7 ConclusionAs detailed in the previous sections, we found signifi-cant and pervasive vulnerabilities throughout the ES&Ssystem. In both optical scan and DRE configurationsthe system suffers from vulnerabilities that can be rela-tively easily exploited by individual poll workers or vot-ers (at precincts and under election conditions) that notonly compromise the results from individual machines,but that can inject arbitrary malicious code into the backend tally system that reports the official county-wide elec-tion results. Several closed viral loops are present, al-lowing, under some conditions, a single compromise ofa single precinct machine to permanently control the en-tire county election system. Audit mechanisms that mightdetect and recover from such attacks are easily defeatedor not present at all. For example, there is no mechanismfor extracting and auditing the firmware installed in an iV-otronic or M100.

By themselves, the weaknesses reported here representserious practical concerns; we found, after all, exploitablevulnerabilities in a widely fielded e-voting system usedacross the US and elsewhere. But perhaps an even moreserious concern is the systemic failure – at every stage – ofthe various standards, certification and testing processesthat were intended to prevent these vulnerabilities fromappearing in the first place.

We note in particular that, in contrast to the “official”Independent Testing Authority (ITA) practices, we fol-lowed no particular methodology or standard practicesin conducting our experiments and analysis. Because ofthe very limited time and other resources available to us,we adopted an almost entirely ad hoc approach, focus-ing our attention on those parts of the system that webelieved might harbor exploitable vulnerabilities. Whilewe used some source code analysis tools (e.g., Fortify),we applied them only selectively. That is, rather than a“certificational” process in which the evaluator checks forcompliance with a finite set of criteria, we adopted thetriage strategy of an attacker, seeking out weaknesses inthe places we thought we would be most likely to findthem and moving on to the next.

Our approach has the disadvantage of depending, to amuch larger extent than the certificational approach, onthe expertise (and luck) of the analysts. And a negativeresults from such an analysis, where no vulnerabilities arefound, would say little about whether any are present. But

11

in our case the approach paid off handsomely.It is worth noting that, in parallel to our study, the State

of Ohio contracted two private consultancies to performmore traditional certification studies of the ES&S system.While the scope of and resources provided to these studies(by SysTest and MicroSolved) were not completely iden-tical to ours, the overall goal was the same: a security as-sessment of the system identifying specific deficiencies.While commercial certificational studies reported a fewproblems that we missed, the vast majority of the mostsweeping and systemic vulnerabilities were found onlythrough our ad hoc analysis.

AcknowledgmentsThis paper draws primarily from our work on ProjectEVEREST [18], in particular Chapters 4, 5, 6, 7 and 8.Penetration testing and attack scenario development forES&S was preformed by the WebWise Security team:Giovanni Vigna, Richard Kemmerer, Davide Balzarotti,Greg Banks, Marco Cova, Viktoria Felmetsger, WilliamRobertson, and Fredrik Valeur. We held numerous discus-sions and collaborations with the Penn State team: PatrickMcDaniel, Kevin Butler, William Enck, Harri Hursti,Steve McLaughlin, and Patrick Traynor, and with our pol-icy consultants Joseph Lorenzo Hall and Laura Quilter.Infrastructure for the U. Penn voting laboratory was sup-ported in part by a gift from Barbara and Morris Pearl.Project EVEREST was sponsored by Ohio Secretary ofState Jennifer Brunner.

References[1] ES&S About. http://www.essvote.com/HTML/

about/about.html.[2] Robert Abbot, Mark Davis, Joseph Edmonds, Luke Florer,

Elliot Proebstel, Brian Porter, Sujeet Shenoi, and JacobStauffer. UC Red Team Report: Diebold Elections Sys-tems, Inc. University of California, Berkeley under con-tract to the California Secretary of State, July 2007.

[3] Robert Abbot, Mark Davis, Joseph Edmonds, Luke Flo-rer, Elliot Proebstel, Brian Porter, Sujeet Shenoi, and JacobStauffer. UC Red Team Report: Hart InterCivic. Univer-sity of California, Berkeley under contract to the CaliforniaSecretary of State, July 2007.

[4] About ES&S: Did You Know? http://www.essvote.com/HTML/about/dyk.html.

[5] Atsec Information Security Corporation. ES&S Unity3.0.1.1 source code review, February 2008. http://www.sos.ca.gov/elections/voting_systems/unity_3011_source_code.pdf.

[6] Matt Blaze, Arel Cordero, Sophie Engle, Chris Karlof,Naveen Sastry, Micah Sherr, Till Stegers, and Ka-Ping Yee.Source code review of the sequoia voting system. Univer-sity of California, Berkeley under contract to the CaliforniaSecretary of State, July 2007.

[7] Joseph Calandrino, Ariel Feldman, Alex Halderman,David Wagner, Harlan Yu, and William Zeller. Source codereview of the Diebold voting system. University of Cali-fornia, Berkeley under contract to the California Secretaryof State, July 2007.

[8] California Secretary of State. Top-To-Bottom Review, July2007. http://www.sos.ca.gov/elections/elections_vsr.htm.

[9] Ariel Feldman, J. Alex Halderman, and Edward Felten.Security analysis of the Diebold AccuVote-TS voting ma-chine. In Proceedings of the 2007 Usenix/ACCURATEElectronic Voting Technology Workshop, August 2007.

[10] David Gainey, Michael Gerke, and Alec Yasinsac. Soft-ware Review and Security Analysis of the Diebold Vot-ing Machine Software: Supplemental Report. Securityand Assurance in Information Technology (SAIT) Labora-tory, Florida State University, For the Florida Departmentof State, August 2007.

[11] Ryan Gardner, Alec Yasinsac, Matt Bishop, TadayoshiKohno, Zachary Hartley, John Kerski, David Gainey, RyanWalega, Evan Hollander, and Michael Gerke. Software Re-view and Security Analysis of the Diebold Voting MachineSoftware. Security and Assurance in Information Technol-ogy (SAIT) Laboratory, Florida State University, For theFlorida Department of State, July 2007.

[12] Harri Hursti. The Black Box Report: Critical Security Is-sues with Diebold Optical Scan Design. Black Box Voting,July 2005.

[13] Harri Hursti. Diebold TSx Evaluation: Critical SecurityIssues with Diebold TSx. Black Box Voting, Unredactedrelease July 2, 2006, May 2006.

[14] InfoSENTRY Services, Inc. Volume 1, Computerized Vot-ing Systems, Security Assessment: Summary of Findingsand Recommendations . For Ohio Secretary of State,November 2003.

[15] Srinivas Inguva, Eric Rescorla, Hovav Shacham, and DanWallach. Source code review of the Hart InterCivic votingsystem. University of California, Berkeley under contractto the California Secretary of State, July 2007.

[16] Roger G. Johnston. Tamper-indicating seals. AmericanScientist, 94:515–523, November-Decemeber 2006.

[17] Tadayoshi Kohno, Adam Stubblefield, Aviel Rubin, andDan Wallach. Analysis of an Electronic Voting System.In Proceedings of the IEEE Symposium on Security andPrivacy, May 2004.

[18] Patrick McDaniel, Matt Blaze, and Giovanni Vigna et al.EVEREST: Evaluation and Validation of Election-RelatedEquipment, Standards, and Testing (academic report). Forthe Ohio Secretary of State, December 2007.

12

[19] Microsolved, Inc. EVEREST Project: ES&S System Ex-ecutive Summary Report. For the Ohio Secretary of State,2007.

[20] RABA Innovative Solution Cell (RiSC). Trusted AgentReport: Diebold AccuVote-TS Voting System. RABATechnologies LLC for the Maryland General Assembly,January 2004.

[21] Dan Rather. The trouble with touch screens. HDNet: DanRather Reports, August 2007. http://www.hd.net/drr227.html.

[22] Bruce Schneier. Description of a new variable-length key,64-bit block cipher (Blowfish). Fast Software Encryp-tion: Cambridge Security Workshop Proceedings (Decem-ber 1993), LNCS 809:191–204, 1994.

[23] Giovanni Vigna, Richard Kemmerer, Davide Balzarotti,Greg Banks, Marco Cova, Viktoria Felmetsger, WilliamRobertson, and Fredrik Valeur. Security Evaluation of theSequoia Voting System: Public Report; UC Red TeamReport: Sequoia Voting Systems. University of Califor-nia, Berkeley under contract to the California Secretary ofState, July 2007.

[24] David Wagner, David Jefferson, and Matt Bishop. Secu-rity Analysis of the Diebold AccuBasic Interpreter. Vot-ing Systems Technology Assessment Advisory Board (VS-TAAB), February 2006.

[25] Alec Yasinsac, David Wagner, Matt Bishop, Ted Baker,Breno de Medeiros, Gary Tyson, Michael Shamos, andMike Burmester. Software review and security analysis ofthe ES&S iVotronic 8.0.1.2 voting machine firmware. Forthe Florida Department of State, February 2007.

Appendix: Software VersionsThe source code analysis and red teams were providedwith the following versions of the Unity environment andsource code by the vendor:

Component Application VersionUnity 3.0.1.1

Audit Manager 7.3.0.0Election Definition Manager 7.4.4.0Election Reporting Manager 7.1.2.1Hardware Program Manager 5.2.4.0Data Acquisition Manager 6.0.0.0ESS Image Manager 7.4.2.0iVotronic Image Manager 2.0.1.0

iVotronic Firmware 9.1.6.29.1.6.4

M100 Firmware 5.2.1.0M650 Firmware 2.1.0.0RMCOBOL RT 7.5.01COBOL WOW RT 3.12

13