VOTING SECURITY REVIEW   SEPTEMBER 2006   2

I. Introduction

Massachusetts conducts voting primarily on optical scan voting equipment. Section 301(a)(3) of the Help America Vote Act (HAVA) (42 U.S.C. §15472) requires that "The voting system shall (A) be accessible for individuals with disabilities, including nonvisual accessibility for the blind and visually impaired, in a manner that provides the same opportunity for access and participation (including privacy and independence) as for other voters; (B) satisfy the requirement of subparagraph (A) through the use of at least one direct recording electronic voting system or other voting system equipped for individuals with disabilities at each polling place." Because this provision takes effect in 2006, Massachusetts is required to provide at least disabled-accessible voting system for each precinct. Ordinary optical scan systems are not compliant because a voter with visual disabilities is not able to mark an optical scan ballot without assistance.

Before an electronic voting system can be used in Massachusetts, it must be approved by the Secretary of the Commonwealth. 54 M.G.L. §32. The Massachusetts statutes are not specific about security requirements for voting systems. Accordingly, the Secretary has provided regulations relating to approval of such systems. 950 CMR §50.02(2) states that, "Equipment shall be designed so as to maximize accuracy and prevent fraud." The emphasis in this report is on prevention and detection of fraud.

Because the security of electronic voting systems has been questioned in various forums and published reports, the Secretary of the Commonwealth of Massachusetts, its chief election officer, engaged me as a consultant to perform an independent security review of three proposed systems, the Hart InterCivic ("Hart") eSlate, Election Systems & Software ("ES&S") AutoMARK and Diebold Election Systems ("Diebold") TSx with GEMS. The vendors furnished documentation of their systems in advance and appeared with their equipment for review at the offices of the Secretary of the Commonwealth. Hart was reviewed on August 2, 2006, ES&S on August 3, 2006 and Diebold on August 7, 2006. The reviewing process was recorded on videotape and transferred to DVD. The reviews were confined to security matters and did not concern compliance with other aspects of Massachusetts law. The reviews did not constitute certification examinations.

In conducting the reviews I have considered the risks and scenarios presented in various recent published reports, including, the CRS Reports, the Compuware Report2, the Carrier article3, GAO-05-9564, the Hart Ohio Security Assessment5, the California

"Election Reform and Electronic Voting Systems (DREs): Analysis of Security Issues." Congressional Research Service (Nov. 4, 2003).

2 "Direct Recording Electronic (DRE) Technical Security Assessment Report," Compuware, Inc. (Nov. 21, 2003), commissioned by the Ohio Secretary of State.

Michael A. Carrier, "Vote Counting, Technology, and Unintended Consequences," 79 St. John's L. Rev. 645 (2005).

4 "Elections: Federal Efforts to Improve Security and Reliability of Electronic Voting Systems Are Under Way, but Key Activities Need to be Completed." (Sept. 2005).

VOTING SECURITY REVIEW   SEPTEMBER 2006   3

Secretary of State's Diebold staff report6, the Common Cause Report, the California Consultant's Reports (eSlate)8, and the Brennan Center Report9. I have also read and considered the documents listed in Appendix A concerning the systems under review. Because these reports have provoked fear and misunderstanding even among the educated public, it is necessary to deal with all of their allegations head-on.

It makes no sense to brand a particular voting system (or any type of system, for that matter) as "secure" or "not secure." Security is meaningful only with respect to a fully articulated catalog of threats. Once the threats and countermeasures are enumerated, determining whether a system is sufficiently secure against those threats becomes a matter of risk assessment. Different states may choose to assign differing probabilities and downsides to various successful threats. The probabilities are never zero, though they may be negligibly small. To insist that a voting system reduce the probability of success of a set of threats to zero is to rule out the use of voting systems entirely, as no system ever built by man has been entirely impervious to intrusion.

The Brennan Center Report is fairly thorough in detailing not only attack modes but "points of attack," namely events or places in the process at which an intruder might be able to gain access to, or introduce malware into, a voting system.

The voting system security threats considered in this report fall into these categories:

•  Machine failure. Failure of a voting machine that might result in misrecording of votes or the loss of votes already cast. There is great voter concern when a voting machine ceases to operate during the election because of the fear that votes already recorded on the machine might be lost or altered as a result of the failure. The VVPAT mechanism is a safeguard against that type of failure since the paper record exists for the votes previously cast. In the case where the machine begins misrecording subsequent to the failure, the VVPAT is effective only if voters actually review the VVPAT for correctness.

•  Software errors. Bugs in any component of the software used to set up and conduct an election that might result in misrecording or mistabulation of votes. Software errors are contrasted with "malware," below.

•  Malware. As used in the report, "malware" means software (or firmware) that has been deliberately created or modified to perform in a manner different from its documented function, and includes other pieces of software (and

6 "Technical Security Reassessment Report: Hart InterCivic Direct Recording Electronic (DRE) Device," Compuware Corp., Sept. 16, 2005, commissioned by the Secretary of State of Ohio, labeled as confidential but freely available over the Internet.

6 "Diebold Election Systems, Inc.... [long list of system components] ... Staff Review and Analysis" (Nov. 14, 2005).

"Election Reform: Malfunction and Malfeasance — A Report on the Voting Machine Debacle." (2006)

s "California Secretary of State Consultant's Report on Hart Intercivic," by Paul Craft (Feb. 25 2006), and "California Secretary of State Consultant's Report on Hart Intercivic System 6.2," by Paul W. Craft and Kathleen A. McGregor (Aug. 4, 2006).

9 "The Machinery of Democracy: Protecting Elections in an Electronic World," The Brennan Center for Justice (2006).

VOTING SECURITY REVIEW   SEPTEMBER 2006   4

firmware), such as viruses and Trojans, that modify election software or cause it to perform in a manner other than its documented behavior. In this regard, malware is understood differently from software errors, which are not deliberate. Malware and its creator may take conscious steps to conceal the malware and thus evade or reduce the probability of detection. The creation or insertion of malware might conceivably occur at many different stages, e.g. at the vendor (known or unknown to vendor's management), at the ITA, in the warehouse, at the jurisdiction, at the polling place, etc., and we must evaluate what, if anything, the system does to resist or reveal such intrusions. For example, if someone attempted to patch an .exe file, would that exploit be detected?

•  Calibration errors. Touchscreens and optical scanners must be calibrated. The touchscreen must be set to recognize properly the physical location of a touch. Poor touchscreen calibration may lead to a touch for one candidate being mistaken as a touch for a different candidate. An optical scanner must be able to set to recognize marks in specific places and at certain light intensities. Poor calibration can lead to misreading of marks, hence counting of votes for the wrong candidate.

•  Tampering with ballot setup information. For each type of tampering attack, it must be considered separately whether attack could be performed by insiders (that is, parties with special access privileges, such as the original vendor, maintenance personnel, the jurisdiction's IT director, poll workers, etc.), and whether it could be mounted by knowledgeable outsiders (such as hackers or voters).

•  Tampering with uncast ballots. An election outcome can be affected by various forms of tampering that fall short of modifying software. For example, if the list of candidates presented to the voter is incorrect or incomplete, the voter is not given a meaningful choice. While steps are taken to ensure that slates are complete and correct, it is possible that the slates may be modified after such checking but before the election.

•  Tampering with cast ballots. Most electronic voting machines make internal electronic records on non-volatile memory of ballot images of votes cast by voters. These are generically referred to as Cast Vote Records (CVRs). Some systems do not record vote totals, but compute them fresh each time they are requested by processing all of the CVRs. This means that if it were possible to alter the CVRs after they had been recorded, the totals would be affected. A VVPAT is a CVR on a physical medium. Clearly having a VVPAT increases the probability that alteration to just the electronic CVRs would be detected. However, this is true only if something is actually done with the VVPAT other than to store it away in a container.

•  Tampering with vote totals. Vote totals produced by individual voting machines are printed out at the close of polls and signed by the appropriate poll officials. Copies are posted at the polling place and also sent to the jurisdiction for tabulation. In most cases these become the official record of the election, and the original signed documents are used in the canvass to determine the winner of the election. Reporting that proceeds on election

VOTING SECURITY REVIEW   SEPTEMBER 2006   5

night is generally unofficial only and is there to provide the press and public with a quick assessment of who has won. However, the election night totals are never final. Generally absentee, military and provisional ballots have yet to be counted, so the election night results are unofficial in the sense that that they are not used to determine winners. Nevertheless, the public becomes concerned when the official and unofficial results differ, especially as to outcome. Therefore it is necessary to prevent even unofficial vote totals from being manipulated.

•  Attacks directed at assistive mechanisms. These are attacks that depend on the fact that disabled voters are often unable to take advantage of various protective mechanisms afforded to voters without disabilities. For example, unsighted voters are unable to read the voter-verified paper trail or the touchscreen display. Therefore, a potential attack would be to print a false paper trail for any voter who is using an audio ballot. The audio information would be played properly, but the vote would be recorded incorrectly in the machine and a corresponding false paper trail could be written, which the voter would be unable to verify. If the voter attempted to verify the ballot through audio means, no discrepancy would be observed.

•  Attacks on auditing mechanisms. Most voting systems accumulate administrative data that can later be used to pinpoint election irregularities. These include event logs, timestamps indicating each time the machine was activated for voting, maintenance logs and logs of manual changes to election data. Some types of tampering can readily be detected if the log records are maintained faithfully. Therefore, the success of certain attacks depends on the attacker being able to modify or erase evidence of his attack.

•  Privacy leaks. Determining how voters voted through electronic emissions or other inferences from data provided by the election system. For example, the sequential voter-verified paper trail offered by Diebold and ES&S has the potential to expose the vote of every voter at a polling place, and active measures must be taken to ensure that it will not be possible after an election to reconstruct the order in which voters cast their ballots. Otherwise, that ordering could be matched up against the paper trail to determine each voter's choices.

•  Denial of service attacks. Efforts to stall or disable voting entirely at selected polling places. Examples include physical attacks on the voting machines to render them inoperative, or trapdoors in the voting software to cause the machines to stop working at a particular time, or software that accepts data from a voter having inside knowledge, whose result is to halt the machine.

Test mode

All voting system offer a variety of test modes in which system functions can be tested and verified without casting official ballots. The role of these test modes is often misunderstood. Test mode never serves to defend against malware. Obviously, if someone has modified election software and wants to avoid getting caught, he will ensure

VOTING SECURITY REVIEW   SEPTEMBER 2006   6

that the system works properly when in test node, but not in election mode. Thus the purpose of test mode cannot be to detect the presence of altered software. Test mode is offered to verify ballot setup and to ensure that normal system functions are operational. Testing for malware must be performed in a different way.

Logic and Accuracy Testing has great value in uncovering errors, as opposed to malware, however, and must be fully utilized, particularly to verify accessible ballots. It can be effective in locating irregularities inserted by malware in ballot setup software, the effective of which is to corrupt static files (as opposed to executables.) The reason it is effective is that these static files cannot be selectively enabled or disabled during an election unless the system firmware has been tampered with. Therefore, there is no way for the system to behave differently in LAT than it will during an election if only static files are altered.

Daisy chaining

Daisy chaining is the act of connecting multiple voting machines, typically in serial fashion, via a single bus cable that passes through all of them. This is done in some cases to provide electric power to all units without the need for multiple wall outlets or power strips. It may also be done to allow data to be routed from each machine to some central device for accumulation or tabulation. The practice has been decried by some security commentators on the grounds that (1) it increases the risk of manipulation of multiple machines from a single place; (2) it presents a privacy risk if vote records are transmitted across a wire since a different voting machine might record the data and/or an eavesdropper might be able to pick up inductive signals from the wire; and (3) it fosters the suspicion that different voting machines might be engaging in unsafe activities made possible through communication. It is true that the first and last of these would be eliminated by outlawing daisy chaining, but this hardly seems warranted in the case of VVPAT systems or ones that can be parallel tested.

Election definition

Voting machines cannot present a slate to the voter unless they are informed of all the offices and candidates. Generating all the ballot styles needed for all polling places in a jurisdiction is known as election definition or ballot setup. It is also often referred to by the misnomer "ballot programming," which is incorrect since no computer programming is involved. Ballot definition involves setting up geographic boundaries for a jurisdiction, defining precincts, and then listing all candidates and issues on which voters in each precinct are entitled to vote. It is a laborious process sometimes performed by vendors under contract to the jurisdiction. The fact that employees of private corporations have a role in the conduct of elections has given rise to the fear that the corporations control U.S. elections in some way.

The charge is unfounded. Because election setup involves only static data (and not computer programs), and the static data is completely proofread and verified during Logic and Accuracy Testing (LAT), which is a public event at which representatives of

VOTING SECURITY REVIEW   SEPTEMBER 2006   7

political parties verify that all candidates are present and in their proper positions on the ballot.

Voting System Testing

Voting systems are tested by the vendor, by the Independent Testing authority, by the state during certification, by hired consultants, by the jurisdiction at acceptance, by warehouse employees before each election, and at pre-election LAT. They may also be tested during the election by a method called Parallel Testing (discussed later) and post-election Logic and Accuracy Testing. In the even of a claim of irregularity, the machines can be subjected to forensic examination after the fact.

Some of the tests (such as ITA testing) are intended to detect malware inserted by a party other than the tester. It is of course possible to hypothesize that all persons ever involved in the testing process at whatever level were colluding to conceal malware. There is no technological response to such an allegation. Even making the system source code public would not serve to put the charge to rest10. Therefore, each jurisdiction must decide for itself whether it is willing to rely on the administrative separation of responsibility to guard against such collusion.

COTS Software

Most voting systems depend on or make use of commercial off-the-shelf (COTS) software. For example, the Windows operating system is COTS, as is often the Basic Input-Output System (BIOS) of a computer, programs for viewing documents, such as Adobe Acrobat Reader, etc. COTS software under Microsoft Windows, Diebold does not own or control the Windows source code11. As a general matter under the 2002 FEC standards, COTS is exempt from ITA source code review. Part of the logic behind this policy is the unavailability of the source to the ITA, but also the view that if COTS software is truly off-the-shelf, then it will not contain any malware specifically directed to voting system generally, and particularly not toward any specific voting system, which may change at frequent intervals. Whether these assumptions behind COTS software are realistic is again part of the risk assessment process.

The fact that there may not be a source code review of COTS software does not mean that it never gets tested or evaluated. The system is stress-tested at ITA with a huge number of ballots, is tested at certification and, under ideal conditions, is tested in parallel during the election (to defeat time-sensitive code that causes the system to behave properly at all times except when a real election is in progress.) Whether such testing is sufficient is also part of risk assessment.

io It may be alleged, for example, that the object code actually used in the machine may not correspond to the publicly released source code.

ii The situation is somewhat different for Windows CE, which is used in the Diebold TSx touchscreen machine. In that case the COTS is actually customized based on input from Diebold for the particular platform on which it runs. This issue is discussed later in connection with the TSx review.

VOTING SECURITY REVIEW   SEPTEMBER 2006   8

COTS Hardware

All voting systems depend on or make use of commercial off-the-shelf (COTS) hardware. For example, Window-based software runs on IBM-compatible PCs using standard, commercially available processors. It is hypothetically possible that an Intel engineer responsible for the design of the Pentium IV chip has inserted rogue components designed to interfere only with elections. The fact that I personally find such a prospect to be ludicrous is not sufficient reason to ignore it. The question is, if such an act occurred, would it be detected. The answer is yes because of the VVPAT and parallel testing, both discussed below.

VVPAT

The Voter-Verified Paper Audit Trail provides the voter with evidence that the machine has correctly understood and recorded the voter's choices. If the VVPAT is used in a recount, the theory is that any flaw, intentional or otherwise, in the software will not interfere with the jurisdiction's ability to count the votes as they were cast by the voters. The success of the VVPAT, assuming that it complies with other election law requirements, depends on voters actually verifying it, maintaining a complete and reliable chain of custody over the paper records, and providing a reliable means of counting the VVPAT should it be necessary. When properly deployed, the VVPAT serves as a check against many tampering threats that have been articulated in the literature. A lot must be read into the phrase "properly deployed." If it is assumed that visually impaired voters cannot check the paper trail, then a mode of attack is to record the ballots of those voters incorrectly both in the electronic record and the paper record (while playing the "correct" names to voter via audio), and relying on the fact that the alteration will not be caught since the records cannot be checked. Thus the VVPAT does not provide the same protection to disabled voters as it does to regular voters.

I believe this to be a distinction without a difference, since whether the VVPAT is operating properly can be determined by testing, and, if it is working, it can be relied on by voters even without verification. However, the scenario has been proposed that the electronic records might be altered only on Election Day, and thus would evade any testing performed before or after the election. This problem is addressed by parallel testing, below.

Parallel Testing

Parallel testing means testing a voting system on Election Day, at the same time that real voting is taking place. The main purpose of parallel testing is to detect malware that takes effect only during the election but is dormant at all time before and after the election. Such malware is hypothetically possible on machines having an onboard clock. The resident software, by interrogating the clock, can determine whether a real election is in progress. If a machine is tested during the election, the malware is unable to determine that the machine is really under test, and so the effects of the malware will be observed.

VOTING SECURITY REVIEW   SEPTEMBER 2006   9

A problem is that on most systems it is not possible to cast test ballots on a voting machine during the election, since the test ballots would be counted as regular ballots.

Parallel testing in its ideal form consists in having officials appear unannounced at randomly selected polling places and sequestering in each one a voting machine that will not be used for real voters, but will be used by test volunteers who will cast votes on the machines all day long from randomly-generated scripts while being videotaped. The results that should be produced by the scripts are known, and the results actually obtained by the machine can be compared with the known results. The most likely cause of any discrepancy is mechanical error by the volunteer, which can be caught and corrected from the video tape. Any remaining discrepancy reveals some problem with the voting system, which may result from malfunction, software error or malware.

It is critical in conducting parallel testing to treat the machine being tested exactly the same way as normal voting machines. That is, the machine should not be moved after being turned on, the behavior and tempo of volunteer voters must match that of regular voters, all procedures for activating the machines, inserting voter cards, closing the polls, etc., must be performed in the same manner. Otherwise, the process is open to the criticism that clever malware could have detected the fact that the system was being parallel tested. Whether such malware can exist is matter for risk assessment. Since know one knows how voters behave in practice (because of a gross lack of data), it is extremely unlikely that anyone could build software to mimic or recognize that behavior, much less maintain a demographic database hidden in the system of how voters in the 200,000 polling places in the United States behave, but once again this a matter for each jurisdiction's risk assessment.

Malware that operates by switching votes from one candidate to another, if present on the machine being parallel tested, will be detected. On pure ballot marking systems, such as AutoMark, since the marking machine performs no tabulation, parallel testing is easy. All one need do is, at several random times on Election Day, have a pair of pollworkers mark ballots on the machine. The testers can verify that the correct slate of candidates was presented and that the ballots are marked properly. These test ballots can be marked "TEST" or "VOID" and treated as spoiled ballots without affecting the outcome of the election.

For DRE systems, the question in parallel testing is how many machines need be tested in an effective parallel test. The answer depends on the resumed threat model. If it is believed that malware has been inserted at the vendor and is therefore present in every machine in the state, it is sufficient to test one machine to reveal the exploit. If it is believed that only one machine in the entire state has been tampered with, then parallel testing would only guarantee to uncover the intrusion if every device in the state were tested. This is an impossibility, since we must allocate sufficient machines for voting, and these cannot be subjected to parallel testing.

Software/Firmware Upgrades

VOTING SECURITY REVIEW   SEPTEMBER 2006   10

Even assuming that a voting system is sufficiently secure for elections, the system must be upgraded periodically. That is, components of its software and firmware must be replaced by new versions. This is necessary because of COTS operating system changes, after-discovered security vulnerabilities, bugs, new features and changes to election law. A good example is the HAVA requirement to add assistive interfaces by 2006. This could not be done without upgrading both software and firmware. However, what controls are there to prevent the upgrade process from being used to introduce unauthorized code or malware?

Unfortunately, the process of performing a legitimate upgrade must be efficient. If it took just one hour to upgrade a voting machine, then about 50 man-years of effort would be needed to install one upgrade nationwide12. Since machines are typically upgraded three times per year, the process would be prohibitively slow and expensive. The question is how to perform authorized upgrades quickly without opening a security hole. In general, this is done by connecting a laptop containing the new software/firmware to a voting machine (or inserting removable media into the machine) and initiating an authorization process requiring credentials, then invoking the upgrade mechanism. In a proper system, these activities are logged electronically and digitally signed to prevent alteration of the audit log. Even so, how are we to know that the upgraded software is properly certified and is not simply a Trojan?

Some jurisdictions distribute authorized upgrades by making copies from a standard release sent by the ITA. However, this procedure just results in relocating points of trust. We must rely on the person performing the installation to use the official release, and the upgrade should be witnessed by disinterested observes. Digitally signing the release media is effective if the voting machine has not been corrupted to eliminate verification of digital signatures. Checking MD5 hashes against the National Software Reference Library would be effective if there were a trustworthy way to obtain the hashes from the installation media and, preferably, from the voting machine after installation has been performed. As a general matter, control of voting system software upgrades is weak from the security viewpoint. This means that indirect verification methods, such as parallel testing, rise in importance as a means of verifying upgrades.

Direct verification, such as by reliable export of software/firmware for independent checking, would reduce dependence on indirect methods. However, the software/firmware cannot be relied upon to export itself (in case it has been corrupted), so a hardware mechanism should be provided.

The COTS software upgrade problem is somewhat worse. Upgrades to the Windows operating system, sometimes made necessary by newly discovered security vulnerabilities, are often performed over the Internet. This requires connecting a dedicated election laptop to the public Internet, a thoroughly unwise idea because of the possibility of malware infection. COTS software upgrades should only be made from

12 Assuming that there are only 100,000 voting machines in the United States, probably a low estimate.

VOTING SECURITY REVIEW   SEPTEMBER 2006   11

removable media supplied by the ITA from digitally signed copies furnished by the vendor and examined by the ITA.

Rogue Compilers

It has been pointed out many times that perfect, clean voting system source code is not a guarantee of freedom from malware if the code is compiled on corrupted compilers. That is, the compiler may alter or insert object code that does not correspond to the source code on which it is operating. The complier might be "alerted' to the fact that this code is to be corrupted by the presence of an innocuous character string or otherwise unremarkable sequence of source code statements. This is surely hypothetically possible. The question is how the corrupt compiler might have been created or introduced into the process.

It is true that vendor might employ a rogue compiler of its own design. It might then feel confident in exposing its pristine source code for all to see, yet manufacture corrupted object code inside its factory. This scenario will not be successful. The ITA uses compilers of its own and creates a "witness build" of the voting system on its own premises. An MD5 hash of the object code and the object code itself is maintained by the ITA and can be used for comparison purposes in the event of an alleged irregularity.

It has been floated about that possibly all compilers, or the main commercial ones, such as Borland C, might have been corrupted by programmers at Borland, and therefore the compiler used for the witness build at the ITA might be as corrupt as the one used by the vendor, and anyone else, for that matter, who might want to verify the object code. Without commenting on the likelihood of this attack, I point out that its effects would be detected in parallel testing.

Physical security

As an overall matter, physical security in voting systems is illusory. While various devices may impress voters psychologically, such as locks, seals and tamper-evident tape, each of these is relatively easy to foil and no election should depend solely on physical security for its integrity. The security of desktops and laptops used for ballot setup and tabulation is usually worse, since such machines do not provide for locks or seals.

Cryptographic tokens, passwords and other authentication mechanisms restrict access by outside intruders, but neither they nor physical security are effective against insiders. The tamper-evident seal is a good example of a hurdle but not a complete bar. This is a roll of adhesive tape having sections bearing non-repeating serial numbers. The manufacturer guarantees that no serial numbers are duplicated, even over its entire manufacturing run of the product. The seal is "tamper-evident" in that if an attempt is made to remove it, a warning message is left behind to indicate that intrusion has occurred. Such seals can be forged, and can even be removed in ways that do not cause

VOTING SECURITY REVIEW   SEPTEMBER 2006   12

the warning to appear13. It is unlikely that in an election setting anyone would check whether a forged seal was in use, though it is expected that routine checks would at least confirm serial numbers. This is not to argue against the use of seals, but merely a plea that their limits be appreciated.

Even if the seals are genuine and intact, they do not protect against insider threats. What we have, therefore, is a collection of checks, certifications, tests, physical perimeters, human witnesses and administrative procedures that collectively present either obstacles to intrusion or means for detecting intrusion. It is up to each jurisdiction to determine whether it considers the entire set of security measures adequate in any given implementation.

The Review Process

The reviews were conducted in a conference room in the McCormack Office Building at One Ashburton Place, Boston. Each vendor brought and set up its equipment in those premises. The reviews were attended by vendor representatives and staff of the Secretary of State and, on occasion, other state offices. The exams in total lasted just over 15 hours for the three systems.

This security review does not pretend to be a complete security analysis of any of the three systems examined. Such reviews have been performed by other organizations, and are referenced in Appendix A. The starting premise in this case was that all three systems are voter-verified (two by paper trails and one by virtue of an optical ballot), and thus interest was confined to security threats that would not be discovered in a voter-verified system as used in Massachusetts. Massachusetts does not utilize modems or Internet transmission of even unofficial vote totals, and the election night results tallied on electronic tabulation systems are not used in the canvass prior to certification of winners. This means that attacks on jurisdiction-wide systems (i.e. city and town systems in Massachusetts), while undesirable, would not result in any loser being declared a winner. The significant security attacks in this setting would have to be directed to the voting machines themselves, rather than the jurisdiction's central setup or tabulation software. Thus attention was paid to the origin of the software, how to authenticate that it corresponds to properly certified software, and ways the software or firmware in a voting machine might be replaced, either with authorized or unauthorized versions.

Each vendor was given an opportunity to make any presentation or demonstration it wished. We then set about to list all the system components, what software or firmware they contain, how that software is generated and distributed, and how it came to be present in the machine. I was particularly interested in the provenance of each item of software and what protection it might afford against substitution or tempering. I then made various attempts, as appropriate for each type of system, to corrupt the software in

is See Chapter 12, "Security Printing and Seals," in Prof. Ross Anderson's excellent and eye-opening book, "Security Engineering," available at http://www.cl.cam.ac.uk/–rjal4/book.html.

VOTING SECURITY REVIEW   SEPTEMBER 2006   13

the machine and any election data, including vote totals. Extensive discussion was held with each vendor as to how various threats would be detected and parried.

Following the examinations, I was provided with DVDs, which I reviewed in their entirety in preparing this report.

H. Hart eSlate

This section is based on the security review performed on August 2, 2006 and Hart InterCivic's response dated August 15, 2005 to a request from the Commonwealth of Massachusetts for a "Voting System Equipped for Accessibility."

System structure

eSlate is a generic term for a comprehensive system that includes ballot definition hardware and software, voting machines, assistive interfaces and tally hardware and software. (eSlate is also the name of the DRE voting terminal on which the voter votes.) Below is an inventory of system components and the security issues they raise.

eSlateTM 4.2.13. This is the DRE voting terminal with which the voter interacts. It is not a touchscreen but presents instead a physical button and wheel interface as well as a color display screen. The regular voter votes by turning the wheel and pressing buttons to make selections. The disabled voter votes using one or more assistive interfaces (possibly also including the butt and wheel interface), as described under "Disabled Access Unit." below.

The result of voting on eSlate is that a CVR is created and stored in three separate places, flash memory in the eSlate, flash memory in the JBC and on the MBB inserted in the JBC. All three of these records must be identical, or the system will not continue in operation. After an election, each of these records can be extracted. Therefore, any exploit that only alters one or two of them can be detected. An exploit that successfully changes all three must be exposed in a different manner.

eSlate is not configured as a general-purpose computer but is an embedded system based on the Motorola Coldfire 5307 processor running the Precise MQX 32-bit real-time operating system. The source code to the operating system is in Hart's possession and the OS and eSlate software are compiled together to yield a single integrated file. No other programs can run on eSlate unless the firmware is modified. The OS is not multithreaded and the device has no hard disk. All the software runs from firmware. While the software is operating, it is continuously performing a cyclic redundancy check to detect whether there has been any alteration to the firmware. This is not done specifically as a defense against tampering but to ensure that firmware device errors do not affect the election process. Each eSlate has an electronic serial number that is installed at manufacture.

VOTING SECURITY REVIEW   SEPTEMBER 2006   14

Each eSlate is provided with a thermal VVPAT printer housed in a separate compartment next to the eSlate box. Both of these components fit into a tray on a stand to raise them to a convenient height for voting and a black privacy curtain is provided to prevent other from observing the activities at the eSlate. This voter-verified capability is referred to by Hart as its Verifiable Ballot Option (VBO) 1.8.3.

eSlate has two communication interfaces: (1) a serial port driven through a stripped-down version of the RS-485 protocol, allowing communication with the Judge's Booth Controller, and (2) an interface to the VVPAT printer to which a connection is made automatically when the eSlate in installed in the voting booth.. There are no modem or LAN ports.

Each eSlate has an onboard battery capable of powering the unit for 18 hours of use, if properly charged. The VVPAT printer is separately powered. At a polling location, the eSlates are daisy-chained both for AC power and for communications with the JBC. However, the data connection is a pass-through — votes from individual eSlates are not read or processed by other eSlates, and the daisy chain is not interrupted if one or more individual eSlates fail during an election. The only effective data connection, therefore, is between an eSlate and the JBC.

The principal eSlate security issues concern the origin of the software and firmware, the physical and electrical security of the device prior to and during an election, the proper correspondence between recorded votes and the paper trail, the permanence of the audit log, faithful display of ballot sent by the JBC and the alterability of Cast Vote records.

eSlate contains no dip switches or wireless components. It is assembled by Suntron in Sugar Land, Texas under contract to Hart. Because the manufacturing process is essentially unauditable, we must rely on testing methods to verify the behavior of the hardware. Suntron subjects its employees to security checks and implements secure procedures in its factory, but there is no way to tell in a specific instance whether a machine has been assembled from genuine components. The ultimate check is through the VVPAT and parallel testing.

Disabled Access UnitTM (DAU). This is a physical unit that, when installed in a standard eSlate, provides alternative access features for disabled voters, including an audio ballot function, jelly switches and sip-and-puff interface. The DAU allows insertion of a PCMCIA memory card (MBB Card) containing audio ballot information. This is separate from the MBB inserted into the JBC.

The principal DAU security issues concern the origin of its software and firmware, the correspondence among the ballot, the displayed candidate names and the spoken candidate names, and the accurate audio summary of the ballot for review by the voter before casting a vote.

VOTING SECURITY REVIEW   SEPTEMBER 2006   15

Judge's Booth ControllerTM (JBC). This is a console installed at the polling place that allows an election judge to manage up to 12 eSlates. If a polling location requires more than 12 eSlates, additional JBCs will be needed. The function of the JBC is to activate a selected eSlate for a particular voter, generate and print out a temporary Access Code enabling the voter to vote, store voting, status and audit information, and to record Cast Vote Records (CVRs) on the Mobile Ballot Box (MBB) PCMCIA inserted in the device.

When a voter votes, a Cast Vote Record produced by the eSlate (and also stored on the eSlate in non-volatile memory) is transmitted to the JBC. The JBC produces totals reports at the close of polls by adding up the individual CVRs.

The JBC has a serial port originally designed for use with a modem (now disabled), a parallel port for a printer and/or firmware burner, and a serial port to connect to daisy-chained eSlates. It also carries on onboard battery that can power the unit for 18 hours. Each JBC has an electronic serial number installed at manufacture.

The principal JBC security issues concern the origin of its software and firmware, the physical and electrical security of the device prior to and during an election, proper generation of Access Codes, correct communication of ballot data to the eSlates, secure receipt and storage of CVRs and reliable tabulation.

The JBC contains no dip switches or wireless components.

Mobile Ballot BoxTM (MBB). This is Hart's generic term for computer PCMCIA memory card that has several uses, including holding the election database and formatted ballots for use by the JBC, holding cast vote records and audit data from a polling location, and holding audio files to be played for visually impaired voters on eSlate.

The principal MBB security issues concern the origin of its data, whether rogue information or program may reside on it, the degree to which its contents may be altered before or after an election, and physical handling procedures to defend against substitution of MBBs.

Ballot Origination Software SystemTM (BOSS) 4.3. This is a Windows software application that enables jurisdictions to build election databases, format ballots, and electronically write multiple ballot types to the MBBs. It runs on a desktop computer or equivalent, recommended to be standalone.

The principal Boss security issues concern the origin of the software, operating system and BIOS, the degree to which the data contents can be altered inside of BOSS or "out of band" (outside of BOSS), the ability to verify the integrity of the software and files, and resistance to intrusions such as viruses and Trojans.

Boss and several other eSlate applications run on desktop/laptops. The laptops supplied by Hart (which are not mandatory) are Dell machines with hardware (including BIOS) as shipped by Dell. Dell is aware of the disposition of these machines because they are

VOTING SECURITY REVIEW   SEPTEMBER 2006   16

purchased through Hart's commercial account. It is hypothetically possible that someone at Dell could arrange for these laptops to be configured differently (e.g. with a different BIOS) from standard machines. Even if such an exploit were successful, it would be caught by the VVPAT and parallel testing.

In 98% of the cases the jurisdiction uses a Dell computer supplied by Hart instead of one of its own. Hart modifies the machine by locking down Windows to prevent running other applications. For example, the "Start" bar, allowing a user to choose what program to run, is absent. This protects against casual intruders but could be circumvented by an insider.

Boss and the other desktop/laptop programs make use of the Sybase database engine, which is supplied in OEM form to Hart for inclusion in its systems. The Boss user interface is written in PowerBuilder, a high-level Sybase product designed for creating database application programs. The Boss ballot generation portion is written in C. A user with a separate copy of Sybase may be able to read and alter database files. However, they are password-protected. This is no barrier to an insider, but as discussed below, alteration of database files before an election will be detected. The Sybase files are not encrypted. Examining them is Notepad revealed large amounts of election data in plain text.

Ta11yTM 4.3. This is the software application that tabulates and generates reports from CVRs on the MBBs. It runs on a desktop or equivalent under Windows. While the output of Tally I unofficial, it is relied upon by the public and the press and therefore must resist manipulation.

Virtually all voting tabulation programs allow manual adjustment of vote totals. While this feature appears horrifying to the uninitiated, it is necessary in an environment in which regular ballots, absentee ballots, military ballots and provisional ballots are counted at different times and on different equipment. The issue is not whether vote totals can be changed, but whether there is an indelible audit trail recording who made each change and what the change was. Tally produces such an audit log, which is stored in a password-protected database. The log entries contain the username of the person making the alteration, the nature of the alteration and the data that was changed.

The principal Tally security issues concern the origin of the software, operating system and BIOS on the machine running the software, the physical and electrical security of the machine, the ability to verify the integrity of the software and files and whether totals reports can be altered after they are generated.

Ra11yTM 2.3. This is a laptop application used to run satellite data collection sites at which CVRs can be read from MBBs brought from multiple polling places for transmission to Tally at a centralized location. It would be used sparingly in Massachusetts, if at all, as it is designed for large, geographically dispersed jurisdictions for which driving time is a factor in assembling results for tabulation.

VOTING SECURITY REVIEW   SEPTEMBER 2006   17

eCM Manager 1.1. This is laptop software necessary to support Hart's removable crypto tokens that are used for two-factor authentication to gain access to certain restricted election functions.

System for Election Records and Verification OperationsTM (SERVO) 4.2. This is a laptop-based election records and asset management system that maintains equipment history and election records. SERVO is used to recover data from equipment in the event an MBB is lost or damaged. It also has an administrative role in maintaining eSlate equipment and MBBs, keeping inventories and reading audit logs, and if it is corrupted there will not be sufficient evidence to resolve claims of irregularity. Therefore, the security of SERVO needs to be evaluated.

Trans. Software used for managing translation of ballot information into multiple languages, the key issue being to ensure that all translations of the ballot have exactly the same candidates in the same positions. Trans is used for both alternative language ballots and audio ballots. The relevant security questions are: (1) does Trans maintain the association between candidates on ballots in different languages properly; and (2) how secure is the output of Trans from later manipulation?

Firmware burn utility. This is software running on a laptop that is used to flash new firmware into the JBC and eSlate. Obviously anyone who has access to this software and obtains physical access to the devices has the potential to corrupt all of the firmware in a jurisdiction's machines. While it is normally available only to Hart employees, there is no way to know whether any copies are circulating outside Hart. It also means that Hart employees could potentially be the source of an insider threat. The interesting question, raised several times during the review, is how can a jurisdiction determine exactly what firmware is resident in the eSlate and JBC? If it cannot, then what defenses are there to the introduction of malware? Fortunately, the VVPAT and parallel testing would reveal any intrusion in all but the most unlikely scenarios.

Cryptographic tokens

The security mechanisms used in eSlate were designed by @stake, a computer security firm which was subsequently acquired by Symantec, Inc. Various (not all) files are digitally signed using keys that are set by eCM Manager and installed on physical USB tokens that must be inserted in particular computers and counter-authenticated with a user-entered PIN for digital signing to occur. The signed data on the MBBs includes ballot definitions and CVRs. For example, if an attempt is made to load an altered MBB into a JBC, it will not succeed because the digital signature will not be correct. The possibility of an outsider (one who does not have access to the keys and PINs) modifying an MBB is virtually zero in any reasonable amount of time (e.g. less than a year) Any rational model of a threat addressed to MBBs can therefore be confined to insiders.