10 YEARS AGO DRAVIDA PERAVAI WROTE TO ELECTION COMMISSION ON MANIPULATING ELECTRONIC VOTING MACHINES

BORN SCIENTIST SEMBIAN MOOTS
DIGITAL BOOTH & FINGER PRINT VOTING 

Appeal to Election Commission of India

The Deputy Election Commissioner

Thiru.R.Balakrishnan

ELECTION COMMISSION OF INDIA

Nirvachan Sadan

Asoka Road

NEW DELHI 110001

Respected Sir

We have immense faith in the impartiality of the Election Commission of India, and after recent elections certain political groups in Tamilnadu raised the bogey of fraudulent machines. An inborn genius, similar to our G.D.Naidu, who lives in a remote village of Kongampattu of Villupuram District in Tamilnadu Mr.Subburayalu alias Sembian, had mooted the idea of using internet polling system through digital booth for fool proof electoral system.

Mr.Sembian writes poetry with ease and his verses within the Tamil grammatical framework will make one wonder it is ancient literary work.

He will be mailing you his poems with music brought in CD form. He plans to set up in his farmland of mango groves a Tamil Heritage Village right adjacent to Puducherry –Villupuram Highway. Having introduced him and his interests we would state that his explanation on vote casting in digital booth written in Tamil is enclosed.

We know that throughout the world this is the fast catching reality and we have reproduced those successful experiments here as prelude to Serbian’s submission which will follow suit. The European E-Identity Management Conference to be held in London on 25 and 26^th June of 2009 will be deliberating what a homegrown genius in a little village will be pondering.

United Kingdom aims to accomplish Finger Print Passport project by October 2010.Mauritiana has finger print voting machines using bio-metric finger print technology, and our request for ECI to move ahead towards this goal. Many scholars have published books on Secure Electronic Voting, Mr.Dimitris A.Gritzalis wrote his book in 2003 in search of perfect voting technology.

Hence keeping in tune with global trends we in India should address to the need to introduce bio-metric finger print technology. Mr.Sembian explains in chaste Tamil his views which come as attachment to our letter.

  

Let us all strive for eminence.

With Regards

Yours fraternally

N.Nandhivarman

General Secretary Dravida Peravai

www.dravidaperavai.org.in

  

[My article in New Indian Express about you is enclosed. It is also available in our website under the title: Nandhivarman in New Indian Express]

The History of Voting Machines

--------------------------------------------------------------------------------

By Mary Bellis

Paper Ballots

The paper ballot system employs uniform official ballots of various stock weights on which the names of all candidates and issues are printed. Voters record their choices, in private, by marking the boxes next to the candidate or issue choice they select and drop the voted ballot in a sealed ballot box.

This paper ballot system was first adopted in the Australian state of Victoria in 1856 and in the remaining Australian states over the next several years. The paper ballot system thereafter became known as the "Australian ballot." New York became the first American State to adopt the paper ballot for statewide elections in 1889.

As of 1996, paper ballots were still used by 1.7% of the registered voters in the United States. They are used as the primary voting system in small communities and rural areas, and quite often for absentee balloting in other jurisdictions. (Image: Patent #340,218 - Combined Tally Sheet and Boll Book - Issued April, 1886 - Inventor, Kinnard)

Mechanical Lever Machines

On mechanical lever voting machines, the name of each candidate or ballot issue choice is assigned a particular lever in a rectangular array of levers on the front of the machine. A set of printed strips visible to the voters identifies the lever assignment for each candidate and issue choice. The levers are horizontal in their un-voted positions.

The voter enables the machine with a lever that also closes a privacy curtain. The voter pulls down selected levers to indicate choices. When the voter exits the booth by opening the privacy curtain with the handle, the voted levers are automatically returned to their original horizontal position. As each lever returns, it causes a connected counter wheel within the machine to turn one-tenth of a full rotation. The counter wheel, serving as the "ones" position of the numerical count for the associated lever, drives a "tens" counter one-tenth of a rotation for each of its full rotations. The "tens" counter similarly drives a "hundreds" counter. If all mechanical connections are fully operational during the voting period, and the counters are initially set to zero, the position of each counter at the close of the polls indicates the number of votes cast on the lever that drives it. Interlocks in the machine prevent the voter from voting for more choices than permitted.

The first official use of a lever type voting machine, known then as the "Myers Automatic Booth," occurred in Lockport, New York in 1892. Four years later, they were employed on a large scale in the city of Rochester, New York, and soon were adopted statewide. By 1930, lever machines had been installed in virtually every major city in the United States, and by the 1960's well over half of the Nation's votes were being cast on these machines.

Mechanical lever machines were used by 20.7% of registered voters in the United States as of the 1996 Presidential election. Because these machines are no longer made, the trend is to replace them with computer-based mark sense or direct recording electronic systems.

Punch cards

Punch card systems employ a card (or cards) and a small clipboard-sized device for recording votes. Voters punch holes in the cards (with a supplied punch device) opposite their candidate or ballot issue choice. After voting, the voter may place the ballot in a ballot box, or the ballot may be fed into a computer vote-tabulating device at the precinct.

Two common types of punch cards are the "votomatic" card and the "data vote" card. With the votomatic, the locations at which holes may be punched to indicate votes are each assigned numbers. The number of the hole is the only information printed on the card. The list of candidates or ballot issue choices and directions for punching the corresponding holes are printed in a separate booklet. (Today's "votomatic" cards are the direct descendents of the original punch card developed from a concept introduced by political scientist and former government administrator Dr. Joseph P. Harris) With the data vote, the name of the candidate or description of the issue choice is printed on the ballot next to the location of the hole to be punched.

Fulton and De Kalb: “Counties in Georgia were the first jurisdictions to use punch cards and computer tally machines when they adopted the system for the 1964 primary election. In the November 1964 Presidential election, these two jurisdictions were joined by Lane County, Oregon, and San Joaquin and Monterey Counties in California, who also adopted the punch card system.

Although many jurisdictions are now switching from punch card systems to more advanced mark sense or DRE systems, Los Angeles County, the Nation's largest election jurisdiction with 3.8 million registered voters, continues to rely on their punch card voting system. In the 1996 Presidential election, some variation of the punch card system was used by 37.3% of registered voters in the United States.

Chad

In U.S. elections, voters use pins to mark the punch cards by hand. The resulting leftover piece of paper is referred to as a piece of chad, a term originating from 1947 of unknown origin. Machines can punch chad out cleanly, but people cannot always do so, resulting in confusing to interpret ballots. New election terms have been used to describe disturbing ballot chad. Hanging chad means one corner of the chad is hanging onto the punch card. Swinging chad means two corners are attached to the ballot card. Tri-chad means three corners are hanging but the hole has been punched. Pregnant chad means a hole is punched through the chad but it still hangs on all four sides. Dimpled chad means there is an indent in the chad but no clean hole has been punched.

Regarding the famous butterfly ballot - the "butterfly" term refers to the plastic guide that shows the voter, which hole to punch.

Related Information: Herman Hollerith

Herman Hollerith invented a punch card tabulation machine system for statistical computation. Herman Hollerith used a punched card device to help analyze the US census data of 1880. In 1896, Hollerith founded the Tabulating Machine Company to make and sell his invention. The company became part of IBM in 1924.

Mark-sense (Optical Scan)

Mark sense systems employ a ballot card on which candidates and issue choices are preprinted next to an empty rectangle, circle, oval, or an incomplete arrow. Voters record their choices by filling in the rectangle, circle or oval, or by completing the arrow. After voting, the voters either place the ballot in a sealed box or feed it into a computer-tabulating device at the precinct. The tabulating device reads the votes using "dark mark logic," whereby the computer selects the darkest mark within a given set as the correct choice or vote. Mark sense technology has existed for decades and been used extensively in such areas as standardized testing and statewide lotteries.

Although mark sense systems are often referred to as optical scan systems, mark sense technology is only one of several methods for recognizing marks on paper through optical reading techniques.

Mark sense systems were used by 24.6% of registered voters in the United States for the 1996 Presidential election, and their use is on the rise.

Direct Recording Electronic (DRE)

The most recent configuration in the evolution of voting systems is known as direct recording electronic, or DRE. They are an electronic implementation of the old mechanical lever systems. As with the lever machines, there is no ballot; the possible choices are visible to the voter on the front of the machine. The voter directly enters choices into electronic storage with the use of a touch-screen, push buttons, or similar device. An alphabetic keyboard is often provided with the entry device to allow for the possibility of write-in votes. The voter's choices are stored in these machines via a memory cartridge, diskette or smart card and added to the choices of all other voters.

In 1996, 7.7% of the registered voters in the United States used some type of direct recording electronic voting system.

History of the Voting System Standards Program

(As of November 1998)

During the 1970's, nearly anyone could cobble together a "voting machine", and sell it to local election officials. Few States had any guidelines for testing or evaluating these devices. Local officials either had to take the salesman's word that the system worked or else depend on the opinion of colleagues who had already bought it. Voting equipment horror stories -- some of them funny, some of them downright chilling -- soon began circulating through the election community. They triggered concerns about the integrity of the voting process.

In February 1975, the General Accounting Office's Office of Federal Elections (predecessor to the Federal Election Commission) signed an interagency agreement with the National Bureau of Standards to develop operational guidelines that election administrators could use to help ensure the accuracy and security of the computer-based vote-tallying process. The resulting March 1975 report, Effective Use of Computing Technology in Vote-Tallying, concluded that one of the basic causes for computer-related election problems was the lack of appropriate technical skills at the State and local level for developing or implementing written standards, against which voting system hardware and software could be evaluated.

This report and comments from State and local election officials led the U.S. Congress to direct the Federal Election Commission (FEC), in conjunction with the National Bureau of Standards (now known as the National Institute of Standards and Technology), to conduct a study on the feasibility of developing voluntary engineering and procedural performance standards for voting systems used in the United States. In early 1984, this three-year effort produced Voting System Standards: A Report on the Feasibility of Developing Voluntary Standards for Voting Equipment.

Based on the recommendations in that report, Congress appropriated funds permitting the Commission to begin developing voluntary national standards for computer-based voting systems. The FEC began the process in July 1984, and completed it with the Commission's approval in January 1990 of the first national performance and test standards for punch card, mark sense, and direct recording electronic voting systems. More than 130 State and local election officials, independent technical experts, vendors, Congressional staff, and others participated in the effort to produce this document. The FEC spent $285,000 on four contracts over the course of this effort.

View More Voting Machine Patents

Every Vote Counts

Part 1: A Look at Voting Machine Patents

By Mary Bellis

In democratic nations, voting is a method by which groups of people choose their leaders and decide public issues. In the United States, voting is considered one of the most important rights of a citizen with that right being guaranteed by the constitution.

In the 1700's, oral elections were conducted. The states later switched to written ballots, requiring the voters to sign their ballots. Some citizens, however, feared that others might react negatively if they voted as they wished. States began using secret ballots so that each voter could choose or vote freely with anonymity.

Today, voting machines are commonly employed to provide secrecy and simplify vote counting. Various types of voting machines are employed including, but not limited to, mechanical levers, electronic scanners, optical scanners and punch card machines.

In honor of all the confusion surrounding the year 2000 presidential election - I have put together a collection of voting machine patents issued throughout the years. Hundreds of voting and electoral devices have been invented - maybe some of them work?

Method and apparatus for voting
Inventor - Roland Harp
Patent #5,585,612
Date - December 17, 1996

Abstract

A voting machine is provided allowing an illiterate, sight impaired or blind individual to cast a vote in privacy and without assistance from another party. The voting machine includes a ballot box having a plurality of voting mechanisms for allowing the individual to cast a vote. One voting mechanism is provided for each election candidate/each side of an election issue. The voting machine also includes an audio player that plays an audio presentation that guides the individual through the voting process by identifying each voting mechanism. A tactile and visual map may also be provided. The map cooperates with the audio presentation to orient the individual for voting. A method is also disclosed.

---

Voting machine with punch card attachment

Inventor - Cothburn O'Neal

Patent #4,025,040

Date - May 24, 1977

A compact, lightweight, manually operated voting machine with provisions for straight ticket, selective and write-in voting, and for choosing two or more candidates from a list of several running at large; with provision for recording each voter's choice on a punch card for computer counting, and including a mechanical counter automatically totaling the votes for each candidate for confirmation of the punch card count.

---

Voting Machine
Inventor - S.R Shoup
Patent #2,054,103
Date - September 15, 1936

---

Voting booth
Inventor - Derry Hobson
Patent #D378, 173
Date - February 25, 1997
The ornamental design for a voting booth, as shown and described.

---

Mobile voting service

Inventor - Oscar Smith

Patent #4,377,367

Date - March 22, 1983

The mobile voting service includes a vehicle having a driving cab and body mounted on a chassis. Preferably four voting booth are disposed inside the vehicle body to take the booths to voters located at various locations such as hospitals, military installations, low income housing areas, nursing homes, industrial plants, businesses, and rural areas to permit them to vote for the candidate of their choice. The vehicle further includes a two-way communication system, office equipment, and a hydraulic lift mounted on the vehicle body adjacent a door opening into the vehicle. The hydraulic lift includes a platform with at least one hydraulic support and hydraulic equipment for raising and lowering the platform with respect to the vehicle body. The hydraulic lift may be used to install the voting booths and office equipment or to permit handicapped voters to enter and exit the vehicle body for voting purposes. The voting vehicle may further include a bathroom and sleeping quarters for the personnel operating the vehicle and voting booths.

Voting Machine Company Agrees to Hand over Source Code

• By Kim Zetter
• June 8, 2009  | 
• 2:26 pm  | 
• Categories: E-Voting

Election officials in Washington, DC, are finally going to get source code for voting machines that produced ‘phantom’ votes during the district’s primary election last September.

Sequoia Voting Systems agreed on Friday, after the city threatened a lawsuit, to hand over the proprietary code. Sequoia will also give election officials documentation describing how the source code and machines were created and maintained, according to the Washington Post.

During the city’s primary election last September, Sequoia’s optical-scan machines added about 1,500 ‘phantom’ votes to races on ballots cast in one precinct.

Sequoia blamed the problem on “static discharge” or human error.

The city has been demanding a look at the source code to determine the problem. But Sequoia initially wanted a $20 million bond from officials guaranteeing they wouldn’t disclose information about the system. Sequoia agreed on Friday to provide the source code without a bond, though the city has agreed to keep the company’s trade secrets confidential. The city can, however, publish information about vulnerabilities that its experts uncover in the system.

Sequoia’s machines are used in 17 states and the District of Columbia.

It’s not the first time that Sequoia’s source code has been examined by outsiders. The company was required to give it to California in 2007 for a top-to-bottom review the state conducted of voting machines used in that state.

Last year, a judge also ordered New Jersey election officials to give source code for the state’s AVC Advantage touch-screen machines to Princeton University computer scientist Andrew Appel and others for a lawsuit that challenged the integrity of Sequoia’s paperless touch-screen voting machines. Voting activists had sued the state to decommission the machines. It was believed to be the first time a court sided with plaintiffs against election officials withholding source code. Appel’s team found several vulnerabilities with the system.

In a separate examination of voting results from the Sequoia machines in New Jersey, Appel also found a discrepancy between summary tapes printed from Sequoia machines during the state’s primary election in 2008 and totals that were recorded on the machine’s memory cards. Summary tapes from machines in one district showed a phantom vote for then-presidential-candidate Barack Obama that didn’t appear in the memory card totals.

The Sequoia machines in Union County, New Jersey, also showed that Republican presidential candidates received 61 votes when only 60 ballots had been cast in the Republican primary. About 60 machines showed such discrepancies. When Union County election officials announced that they planned to have Princeton academics examine the machines to determine what went wrong, Sequoia threatened a lawsuit.

Sequoia initially blamed the problem on election officials (.PDF) for pushing the wrong buttons, but later claimed it uncovered a problem in its software that was creating the vote errors and announced that it had fixed the issue.

LOWER HOUSE PREPARES FOR `FINGERPRINT` VOTING

• Italy News
• Politics News Event

(ANSA) - Rome, February 16 - The House of Deputies on Monday began taking the fingerprints of MPs ahead of a new
voting system based on fingerprint recognition that will be activated in March.
House Speaker Gianfranco Fini has backed the new system, which will put a stop to MPs voting on behalf of absent colleagues. Opposition Democratic Party (PD) MP Roberto Giachetti,
who has lobbied for improved controls on voting, was the first to have his fingerprints taken and said all PD politicians were committed to the new system.
The system has been opposed by some centre-right
politicians as well as government ally the Northern League,
who have argued it is an invasion of privacy.

Rush vote European Parliament on biometrics

2 December, 2004

» 

Compulsory Identification | Privacy | Biometrics

It is likely that the Council of European Justice and Home Affairs ministers will adopt a regulation tomorrow, on 3 December 2004, to fingerprint all EU citizens and residents, to take digital photographs of their faces and to store these data in a gigantic database of 450 million EU citizens. This will be the last step of a procedure that has exploited the democratic deficit of the European Union to an unheard extreme.

Today the European Parliament adopted the proposal but introduced a large number of limitations. MEPs voted to clearly limit the kinds of information to be stored on the passports, they voted against the storage of the data in a central database and in favour of giving Data Protection Authorities oversight over the whole process. But it is unlikely that the Council will take any of these amendments into consideration. Under the European Union's consultation procedure the Council can globally reject all of the Parliament's amendments. Though it is mandatory to at least look at the parliamentary suggestions, it will be almost impossible to do so in this case, since the Council plans to adopt its own plan tomorrow.

Members of the European Parliament were deeply angered by the Council's sudden and belated change of the draft that the Parliament had to vote on. On 25 October 2004, while the Parliament's LIBE (Civil Liberties, Justice and Home Affairs) Committee was voting on its report on the biometric issues, the EU's Justice and Home Affairs ministers met behind closed doors in Luxembourg. They decided to considerably change the document that LIBE was just voting on: Fingerprints were introduced as a second obligatory biometric identifier, and the data were to be stored in a central database. The draft Regulation adopted by the Council was transmitted to the Parliament only a month later, on 26 November 2004.

The Council then black-mailed the Parliament's Conference of Presidents, the body taking decisions on the plenary agenda, to behave as if the proposal had not undergone any significant changes and to leave it on the agenda of the plenary session of 1 and 2 December. If the Presidents had refused, the Council threatened to delay the introduction of the co-decision procedure for immigration and asylum issues. In stead of giving parliament this important power on 1 January, it was to be delayed to 1 April 2005. And if Parliament had decided to refer the new proposal back to the LIBE committee, the Council announced it would just completely ignore Parliament, under some obscure procedure.

More than seventy civil society organizations from the EU and abroad, nine national or regional Data Protection Commissioners and more than two hundred concerned citizens have signed an open letter by Privacy International, State watch and European Digital Rights opposing this proposal. It seems, however, quite unlikely that the Justice and Home Affairs Ministers of the European Union will take the declared will of the EU Parliament or of Civil Society into account when introducing the obligation to fingerprint all their citizens and to store their data in a central database.

PI, State watch and EDRI Open Letter (30.11.2004)
http://www.edri.org/campaigns/biometrics/0411

EU governments blackmail European Parliament into quick adoption of its report on biometric passports (27.11.2004)
http://www.statewatch.org/news/2004/nov/12biometric-passports-blackmai...

Council Draft regulation on biometric passports (23.11.04)
http://www.statewatch.org/news/2004/nov/biometric-proposal.pdf

Parliament report on the Commission proposal for a Council regulation on standards for security features and biometrics in EU citizen's passports, including voting list and all amendments (25.11.2004)
http://www.edri.org/files/BioPass_AllAmend_VoteList.pdf

Provisional agenda for the meeting of the JHA Council (2-3.12.2004)
http://www.eu2004.nl/default.asp?CMS_TCP=tcpAsset&id=1FA5E817CB124...

JHA Council press conference video stream (available after 2 December, 20:00, for one week)
http://europa.eu.int/comm/ebs/bottom_schedule.cfm?jour=5&semaine=4...

(Contribution by Andreas Dietl, EDRI EU Affairs Director)

Leading Nigerian IT Products Provider Integrates M2SYS Fingerprint Software into Third Party National Voting System

Wed, 21 Feb 2007 01:42:37 -0800 PST

By Aria Munro

M2SYS Delivers Rapid Fingerprint Integration Technology to Support Successful Deployment of Biometrically Controlled Nigerian Voting Project

ATLANTA, Ga. — M2SYS Technology announced today that it was selected late in 2006 by a leading Nigerian IT products provider to deliver fingerprint scanners and software for the secure national voting project. After the original local vendor selected for the project faced delays in meeting its timeline for the fulfillment of a portion of needed IT units, Nigerian government officials sought out the help of another company, who turned to M2SYS for assistance.

M2SYS provided its Bio-Plug-in(TM) fingerprint software, which enabled the rapid integration and deployment of a seamless biometric module within the voting software on more than 10,000 notebook computers. Even without having access to the voting software source code, M2SYS’ partner was able to immediately replace the existing fingerprint module due to the unique architecture of Bio-Plug-in(TM).

“We are very pleased that we were given the opportunity to help this important project achieve success,” commented Mizan Rahman, CEO and Chief Scientist of M2SYS. “M2SYS was able to provide fingerprint software needed to ensure an expeditious return on investment for the Nigerian government. Our partner in Nigeria was able to adopt a seamless fingerprint recognition system with the government’s existing third party voting software in a matter of days. This exemplifies the true power of our innovative Bio-Plugin(TM) technology.”

Bio-Plugin(TM) enables software companies to quickly integrate a complete, seamless fingerprint recognition system, including a high-performance 1: N identification engine. Bio-Plug-in(TM) eliminates the system dependencies, extensive development, and specialized knowledge of biometric complexities inherent to fingerprint SDKs.

About M2SYS Technology M2SYS, www.m2sys.com, is a recognized industry leader in fingerprint identity management technology. Anchored by our innovative, patent-pending solution called Bio-Plug-in(TM), we deliver fully functional, turn-key fingerprint recognition software that instantly integrates into third party programs, in many cases with no additional development or system upgrades required.

The company also offers several stand-alone, enterprise applications and desktop security products that guard against identity theft and protect company assets. Our fingerprint software solutions are accelerating the growth of biometric technology adoption in the global marketplace.

Technorati Tags: M2SYS Technology, fingerprint identity management technology, Bio-Plug-in fingerprint software

SPHERE: Related Content — CLICK HERE to See What Else is Out There!

---

About The Author / Editor: Aria C. Munro works in the book publishing industry and has been a content editor for the Neotrope News Network since 2004. Her black video iPod is most often shuffling Invader Zim episode vids and Thomas Dolby or Dead Can Dance tunez.» Learn More about Aria Munro

© 2007 eNewsChannels™ and Neotrope® -

Combating Vote Fraud and Coercion

Combating Vote Fraud

Whenever a vote is cast outside of the guaranteed secrecy of a polling booth, a would-be vote buyer may be able to take physical control of the casting of the ballot. Voice Vote eliminates this practice. All votes, including early and absentee ballots, are cast on Voice Vote voting machines, providing the same certainty that it is the approved voter who votes as on Election Day, and with the same anonymity guaranteed by the protection of a voting booth.

The transparency of Voice Vote undermines the basis of vote buying. Voice Vote provides a means for anyone to print out sample ballots in advance of the election. These sample ballots appear identical to a vote receipt issued after a ballot is cast, including containing a dummy cryptographic signature. Anyone could produce any number of sample ballots before Election Day at almost no cost and in unlimited numbers. A sample ballot would only lack a valid digital signature, and could not be distinguished from an actual, valid ballot receipt until after the election was completed and the verifying keys of legitimate voting sessions were published. The would-be buyer of votes would be confronted with a large number of offers of sample ballots, driving down the return on investment in bought votes to near zero.

To ensure that the purchased votes were not merely sample ballots, the vote buyer would be compelled to collect vote receipts (or key information from the receipts) and to record the identities of the sellers. He would have to ask the vote seller to forgo payment until after the election results had been published. The sellers would have no means of enforcing the completion of the transaction. The inescapably low level of trust between buyer and seller would make this form of vote buying unlikely.

Even worse for the vote buyer, the unique digital signature on each ballot would provide a way for law enforcement officials to mark forged vote receipts, much like marking the currency used to pay off a ransom. This would provide a powerful new tool to law enforcement officials to pressure street-level operatives to "roll over" on the political boss who financed a vote-buying operation.

A valid receipt presented for the first time for payment after the election would similarly be of no value, since Voice Vote provides a means by which anyone can easily print a duplicate receipt of any ballot that was cast. A cryptographically certified ballot receipt is proof that a ballot has been cast, but gives no indication who cast it.

Sample ballots would present no threat to the integrity of the election process proper because digital signatures are unforgeable. Sample ballots would be easily and reliably detected after the publication of the verifying keys. Widespread knowledge of the worthlessness of sample ballots after the publication of the verifying keys would serve to enhance popular confidence in the integrity of the electoral system.

Combating Vote Coercion

A good voting system precludes the disclosure of a voter's election choices except by the action of the voter, but it cannot prevent social pressure to disclose (or to not disclose).

To illustrate how Voice Vote serves to insulate voters against pressure to disclose their vote, consider the following example of a coercive atmosphere: Say that Veronica lives and votes in a precinct that is overwhelmingly forest-friendly, and that she herself belongs to the Forest Fanatic Society. Nevertheless, for reasons that seem good and sufficient to her, she votes for Joe Logger for chief forest ranger.

Scenario A: Community pressure. Suppose that an election system is used that does not issue voter receipts (that is, any current election system). If the Forest Fanatics ask each of their members to state publicly that they voted against Joe Logger, Veronica has three choices: she may refuse to make any statement about her vote, she may disclose it, or she may lie about it.

Now suppose that the Voice Vote system is in effect and that Veronica has been issued a receipt after casting her vote and that all ballots have subsequently been posted on the Internet. If the Forest Fanatics ask all their members to post their ballots on the community bulletin board, Veronica has exactly the same three options: she may refuse to post any ballot, she may post the receipt for her vote, or she may download a ballot from the Internet that was cast against Joe Logger and post it (that is, she may lie about her vote). There is nothing to distinguish a downloaded ballot from one distributed to a voter at the polling place, and nothing to indicate the identity of the voter on any ballot. Therefore, Veronica's posted ballot no more proves how she voted than a verbal statement. Since it would be common knowledge that anyone could download any ballot, the entire practice of exerting social pressure in this way would be discouraged.

Scenario B: Stolen vote. Suppose that the pro-forest sentiment in this jurisdiction is so strong that the precinct election judges and all the poll watchers collaborate to discard Veronica's vote for Joe Logger. In the Voice Vote system, Veronica can prove that her vote has been discarded by producing her digitally signed ballot and trigger an audit of the election, which would be performed using the election authority's printed paper ballots. What's more, she can accomplish this anonymously by sending her digitally signed vote receipt to a vote integrity organization -- say, the Center for Election Responsibility and Trust (CERT). Veronica's vote receipt in the hands of CERT has the same power to challenge the theft of her vote as in has in her hands. In this way, the Voice Vote system greatly enhances the secrecy of the ballot: it allows a voter whose vote has been stolen to not only effectively challenge the theft, but to do so without disclosing her identity.

Scenario C: Suspicion of stolen votes. Suppose that no votes are actually altered or discarded, but Veronica, knowing the strength of pro-forest sentiment, is suspicious that election fraud has occurred. Under the Voice Vote system, her suspicion is dispelled by the fact that she can confirm that her own vote for Joe Logger was properly recorded and by the knowledge that every other voter can likewise check their own vote and can anonymously challenge any instance of vote tampering.

The Voice Vote protocol is designed with the dual objectives of securing elections against tampering and of giving the public confidence in the integrity of the system. These goals are promoted by the combination of well-established cryptography with simplicity, transparency and direct involvement of the public, including in the post-voting phase of the election.

The development of democracy in America is an unfinished and ongoing process. Democracy is about much more than elections and elections are about much more than voting. However, it is reasonable to chart the growth of our democracy by the expansion (and sometimes contraction) of voting rights and the ability of the election system to express the intent of the electorate.

Voter expectations regarding election integrity are not static. Rather, they are shaped by the same forces, including the explosion of information technologies that have given rise to demands for greater transparency in all types of government operations. Voters today expect every citizen to enjoy equal access to an election process that is free from error and corruption. By that standard, the gap between voter expectations for American democracy and the reality of our electoral system has taken a turn for the worse in recent years.

The elections of 2000, 2004 and 2006, and especially Bush v. Gore, highlighted this crisis of confidence. The actions of the courts and the Congress have done little, if anything, to alleviate the growing distrust of many Americans with the ability of the electoral system to reflect their will, to represent their interests and to accurately and reliably record and count their votes. As reported in a Caltech/MIT Voting Technology Project working paper Are Americans Confident Their Ballots Are Counted?

The issue of trust and confidence in the electoral process looms large in the United States in the wake of the disputed 2000 presidential election, especially following the many reports and studies of procedural irregularities, mistakes, and problems associated with the counting and recounting of ballots in Florida and other states.

The Project found in that issues of confidence and trust persist today:

Despite efforts at reform, including passage of the “Help America Vote Act” in 2002, questions persist about the degree of confidence and trust that American citizens and voters have in their electoral process, given that problems again arose in the 2004 presidential election in a number of states, including the pivotal state of Ohio.

In a report titled Challenges Facing the American Electoral System: Research Priorities for the Social Sciences, the National Research Commission on Elections and Voting notes:

It is the view of this Commission that significant reforms in American electoral institutions are very much needed at this juncture in American political history. There is ample evidence that our electoral system does not match – and sometimes frustrates – the promise of American democracy. There is also abundant anecdotal evidence that many Americans have lost confidence in the fairness and neutrality of our electoral processes: one of the more notable features of the weeks immediately following the November election was the proliferation of theories and claims that the presidential election had been stolen.

Voice Vote is designed to address this acute problem by implementing principles that have historically been the goals of democratic elections:

•Anonymity. The voter alone should decide whether and what to disclose about the choices made on the ballot. The voter should have the right to choose whether to disclose nothing, to disclose their vote or even to make false statements about how they voted.

•Accuracy. There should be clarity in the presentation and marking of ballots, so that they represent the true intent of the voter, and there should be zero tolerance for errors in the recording and counting of votes.

•Transparency. Voters should be able to see and to understand all aspects of the system, and the maximum possible amount of information about all votes cast, consistent with the principle on anonymity, should be made public.

•Confidence. Every election should be subject to quick, reliable and automatic verification, and there should be effective recourse in the event that the integrity of the system is shown to have been compromised.

The key to the Voice Vote system is that it brings the public directly into the process of verification. It creates and gives to each voter a cryptographically certified paper record of their vote, tagged with a random identifier, which the voter may compare to the complete set of votes posted on the Internet. This receipt enables each voter to check that their vote is correctly recorded. If a voter's ballot is missing or altered, it gives the voter a way to prove the error or fraud. Any voter may independently count every vote throughout the country. Voice Vote employs technologies that are already in wide use: public key signatures - an established method of verifying the authorship and integrity of documents - and the Internet.

The Voice Vote system consists of specifications for equipment, software and procedures for the conduct of elections which, taken together, improve the security, accuracy and efficiency of elections. Within this framework, Voice Vote permits election authorities, vendors and implementer’s wide latitude. The Voice Vote system elevates the role of voters to co-guarantors with the election authorities of the integrity of the system as well as decision makers.

Wherever possible, Voice Vote preserves familiar election procedures. For example, voters go to a local polling place to cast their ballots. While Voice Vote retains time-tested aspects of voting procedure, it recognizes that the technology of voting is changing, and uses proven and practical technologies to enhance the electoral system.

At the time our Constitution was adopted, more than two centuries ago, the majority of jurisdictions in the United States restricted voting to men of property. John Adams, a founding father, argued, in the same year that the Declaration of Independence was adopted, that permitting men without property to vote would lead to "no end" of similar demands on the part of others, including women and "lads." He made no mention of the fact that slaves, many free Blacks, indentured servants and Native Americans were denied the vote. If one set out down this path, Adams warned, the end result would be to "prostrate all ranks to one common level."

Later, the inimitable Benjamin Franklin posed the contrary hypothetical case of a man who owns a jackass worth $50, and who is therefore entitled to vote. Some years after, the jackass dies. Meanwhile, the man has become more experienced and wiser, but he is no longer entitled to vote. "Pray inform me," asks Franklin, "in who is the right of suffrage? In the man or in the jackass?"

Adams' position is reflected in the originally adopted Constitution, which contains no guarantee of the right to vote. But the sweep of American history vindicates Franklin. Voting rights, along with social and economic rights, have gradually, often against bitter opposition and with some backtracking, been extended so that nearly all may enjoy this most central of our democratic rights.

Alexander Keyssar, in his comprehensive survey of voting in the United States, notes that the same contradictions pointed out by Franklin drove a broadening of voting rights almost immediately after the Constitution was adopted. Between 1790 and 1850 numerous states legislated a secret ballot and lowered economic and residency barriers to voting. The process of industrialization gave new and largely unanticipated meaning to the expansion of the franchise as the burgeoning class of workers, often immigrants, began to integrate into the political process.

Perhaps the strongest and most persistent theme in the history of American democracy and voting rights has been the struggle for African American equality. The first wave of that epic struggle peaked with the Civil War and the Reconstruction period. Following the Civil War, which abolished slavery, the Reconstruction’s XIVth and XVth Amendments to the Constitution (1868 and 1870) first introduced constitutional treatment of voting rights, profoundly altering the Constitution? The XVth Amendment prohibits denial of voting rights based on "race, color, or previous condition of servitude," and it served as the model for the extension of voting rights to other disenfranchised sections of the population. After prolonged struggle, the XIXth Amendment (1919) similarly prohibited denial of voting rights on account of sex, and the XXVIth Amendment (1971) prohibited denial of voting rights on account of age to those 18 or older.

The history of voting rights has not, however, been an uninterrupted march of progress, and legal enactments have not always resulted in the implementation of real rights. Voting rights have grown and shrunk along with the great struggles for social and economic equality. The defeat of Reconstruction (1876) initiated the period of greatest retreat in democratic rights in United States history, effectively disfranchising most African Americans in the South once again. The intent of the XVth Amendment -- to eliminate voting discrimination on the grounds of race or color -- has gradually, and against bitter and continuing resistance, been realized once again only since the passage of the Voting Rights Act in 1965.

Advances in election systems may also involve compromises, tradeoffs and ambiguities. For example, the adoption of our current familiar secret ballot (the "Australian ballot") in Louisville in 1888 was soon followed by its adoption across the United States. It offered a higher level of ballot privacy, but was a significant obstacle to the participation of many illiterate voters, especially recently freed slaves and foreign born citizens, because it required the voter to read the name of the candidate or party he wished to vote for.

As near-universal suffrage has been established more firmly in law in the wake of the passage of the Voting Rights Act, the struggle over voting rights has increasingly shifted to expanding access to voting, to suppressing fraud and intimidation and to the complete and accurate counting of votes. In this context, Voice Vote contributes to the evolving standard of voting rights.

Analysis of an Electronic Voting System

Tadayoshi Kohno Information Security Institute Johns Hopkins University

yoshi@cs.jhu.edu

Adam Stubblefield Information Security Institute Johns Hopkins University

astubble@cs.jhu.edu

Aviel D. Rubin Information Security Institute Johns Hopkins University

rubin@cs.jhu.edu

Dan S. Wallach Department of Computer Science Rice University

dwallach@cs.rice.edu

July 23, 2003

Abstract

Recent election problems have sparked great interest in managing the election process through the use of electronic voting systems. While computer scientists, for the most part, have been warning of the perils of such action, vendors have forged ahead with their products, claiming increased security and reliability. Many municipalities have adopted electronic systems, and the number of deployed systems is rising. For these new computerized voting systems, neither source code nor the results of any third-party certification analyses have been available for the general population to study, because vendors claim that secrecy is a necessary requirement to keep their systems secure. Recently, however, the source code purporting to be the software for a voting system from a major manufacturer appeared on the Internet.

This manufacturer’s systems were used in Georgia’s state-wide elections in 2002, and the company just announced that the state of Maryland awarded them an order valued at up to $55.6 million to deliver touch screen voting systems.1 This unique opportunity for independent scientific analysis of voting system source code demonstrates the fallacy of the closed-source argument for such a critical system. Our analysis shows that this voting system is far below even the most minimal security standards applicable in other contexts.

We highlight several issues including unauthorized privilege escalation, incorrect use of cryptography, vulnerabilities to network threats, and poor software development processes. For example, common voters, without any insider privileges, can cast unlimited votes without being detected by any mechanisms within the voting terminal. Furthermore, we show that even the most serious of our outsider attacks could have been discovered without the source code. In the face of such attacks, the usual worries about insider threats are not the only concerns; outsiders can do the damage. That said, we demonstrate that the insider threat is also quite considerable. We conclude that, as a society, we must carefully consider the risks inherent in electronic voting, as it places our very democracy at risk.

1 Introduction

The essence of democracy is that everyone accepts the results of elections, even when they lose them. Elections allow the populace to choose their representatives and express their preferences for how they will be governed. Naturally, the integrity of the election process is fundamental to the integrity of democracy itself. And, unsurprisingly, history is littered with examples of elections being manipulated in order to influence their outcome.

The design of a “good” voting system, whether electronic or using traditional paper ballots or mechanical devices must be robust against a wide variety of potentially fraudulent behavior. The anonymity of a voter’s ballot must be preserved, both to guarantee the voter’s safety when voting against a malevolent candidate, and to guarantee that voters have no evidence that proves which candidates received their votes. The existence of such evidence would allow votes to be purchased by a candidate. The voting system must also be tamper-resistant to thwart a wide range of attacks, including ballot stuffing by voters and incorrect tallying by insiders. Another important consideration, as shown by the so-called “butterfly ballots” in the Florida 2000 presidential election, is the importance of human factors. A voting system must be comprehensible to and usable by the entire voting population, regardless of age, infirmity, or disability. Providing accessibility to such a diverse population is an important engineering problem and one where, if other security is done well, electronic voting could be a great improvement over current paper systems. Flaws in any of these aspects of a voting system, however, can lead to indecisive or incorrect election results.

1.1 Electronic voting systems

There have been several studies on using computer technologies to improve elections [Cal01, Cal00, Mer00, Nat01, and Rub02]. These studies caution about the risks of moving too quickly to adopt electronic voting machines because of the software engineering challenges, insider threats, network vulnerabilities, and the challenges of auditing. As a result of the Florida 2000 presidential election, the inadequacies of widely-used punch card voting systems have become well understood by the general population. This has led to increasingly widespread adoption of “direct recording electronic” (DRE) voting systems. DRE systems, generally speaking, completely eliminate paper ballots from the voting process. As with traditional elections, voters go to their home precinct and prove that they are allowed to vote there, perhaps by presenting an ID card, although some states allow voters to cast votes without any identification at all. After this, the voter is typically given a PIN or a smartcard or some other token that allows them to approach a voting terminal, enter the PIN or smartcard, and then vote for their candidates of choice. When the voter’s selection is complete, DRE systems will typically present a summary of the voter’s selections, giving them a final chance to make changes. Subsequent to this, the ballot is “cast” and the voter is free to leave. The most fundamental problem with such a voting system is that the entire election hinges on the correctness, robustness, and security of the software within the voting terminal. Should that code have security relevant flaws, they might be exploitable either by unscrupulous voters or by malevolent insiders. Such insiders include election officials, the developers of the voting system, and the developers of the embedded operating system on which the voting system runs. If any party introduces flaws into the voting system software or takes advantage of pre-existing flaws, then the results of the election cannot be assured to accurately reflect the votes legally cast by the voters.

The only known solution to this problem is to introduce a “voter-verifiable audit trail.” [DMNW03].

Most commonly, this is achieved by adding a printer to the voting terminal. When the voter finishes selecting candidates, a ballot is printed on paper and presented to the voter. If the printed ballot reflects the voter’s intent, the ballot is saved for future reference. If not, the ballot is mechanically destroyed. Using this “Mercury method,” [Mer00] the tally of the paper ballots takes precedence over any electronic tallies. As 2 a result, the correctness of the voting terminal software no longer matters; either a voting terminal prints correct ballots or it is taken out of service.

1.2 “Certified” DRE systems

Many government entities have adopted paperless DRE systems without appearing to have critically questioned the security claims made by the systems’ vendors. Until recently, such systems have been dubiously “certified” for use without any public release of the analyses behind these certifications, much less any release of the source code that might allow independent third parties to perform their own analyses. Some vendors have claimed “security through obscurity” as a defense, despite the security community’s universally held belief in the inadequacy of obscurity to provide meaningful protection.

“Security through obscurity” is a long-rejected theory that systems can be made more secure by simply hiding the security mechanisms from public view. While this theory has some validity in situations where the need for security is not great — hiding a spare key to a liquor cabinet just out of sight of small children — the theory has been soundly rejected as a means of serious security [Ker83]. This is because it has the twin faults of not providing serious security from real attackers, who can easily overcome minimal security measures, and of limiting public and general security oversight of the system, which has proven to be the best method for creating and maintaining a truly secure system [Sch00].

Indeed, source code that appears to correspond to a version of Diebold’s voting system appeared recently on the Internet. This appearance, announced by Bev Harris and discussed in her book, Black Box Voting [Har03], gives us a unique opportunity to analyze a widely used, paperless DRE system and evaluate the manufacturer’s security claims. To the best of our knowledge, the code (hereafter referred to as the “Diebold code”) was discovered by others on a publicly available Diebold ftp site in January, 2003. It has since been copied to other sites around the world and its release has been the subject of numerous press reports. To the authors’ knowledge, Diebold has raised no objection to the broad publication and republication of the code to date. Jones discusses the origins of this code in extensive detail [Jon03].

The security of Diebold’s voting system is of growing concern as on July 21, 2003; the company finalized an agreement for up to $55.6 million to deliver touch-screen voting technology to the state of Maryland. The contract includes about 11,000 Diebold touch-screen voting systems. Diebold voting systems were also used in state-wide elections in Georgia in 2002.

1.3 Summary of results

We only inspected unencrypted source code that we believe was used in Diebold’s AccuVote-TS voting terminal [Die03] (the “AVTSCE” tree in the CVS archive). We have not independently verified the current or past use of the code by Diebold or that the code we analyzed is actually Diebold code, although as explained further in Section 6.1, the copyright notices and code legacy information in the code itself are consistent with publicly available systems offered by Diebold and a company it acquired in 2001, Global Election Systems. Also, the code itself built and worked as an election system consistent with Diebold’s public descriptions of its system. We concluded that even if it turned out that the code was not part of a current or past Diebold voting system, analysis of it would be useful to the broader public debate around electronic voting systems security and assist election officials and members of the public in their consideration of not only Diebold systems, but other electronic voting systems currently being marketed nationwide and around the world. We did not have source code to Diebold’s GEMS back-end election management system. Furthermore, we only analyzed source code that could be directly observed and copied from the CVS software archive without further effort. A large amount of the other data made publicly available was protected by very weak compression/encryption software known as PKZip, which requires a password for access to the underlying work. PKZip passwords are relatively easy to avoid, and programs for locating passwords for PKZip files are readily available online. Moreover, passwords that others have located for these files have been freely available online for some time. Nonetheless, we decided to limit our research to only the files that were publicly available without any further effort, in part due to concerns about possible liability under the anti-circumvention provisions of the Digital Millennium Copyright Act. Even with this restricted view of the source code, we discovered significant and wide-reaching security vulnerabilities in the AccuVote-TS voting terminal. Most notably, voters can easily program their own smartcards to simulate the behavior of valid smartcards used in the election. With such homebrew cards, a voter can cast multiple ballots without leaving any trace. A voter can also perform actions that normally require administrative privileges, including viewing partial results and terminating the election early. Similar undesirable modifications could be made by malevolent poll workers (or even maintenance staff) with access to the voting terminals before the start of an election. Furthermore, the protocols used when the voting terminals communicate with their home base, both to fetch election configuration information and to report final election results, do not use cryptographic techniques to authenticate the remote end of the connection nor do they check the integrity of the data in transit. Given that these voting terminals could communicate over insecure phone lines or even wireless Internet connections, even unsophisticated attackers can perform untraceable “man-in-the-middle” attacks.

As part of our analysis, we considered both the specific ways that the code uses cryptographic techniques and the general software engineering quality of its construction. Neither provides us with any confidence of the system’s correctness. Cryptography, when used at all, is used incorrectly. In many places where cryptography would seem obvious and necessary, none is used. More generally, we see no evidence of rigorous software engineering discipline. Comments in the code and the revision change logs indicate the engineers were aware of areas in the system that needed improvement, though these comments only address specific problems with the code and not with the design itself. We also saw no evidence of any change control process that might restrict a developer’s ability to insert arbitrary patches to the code. Absent such processes, a malevolent developer could easily make changes to the code that would create vulnerabilities to be later exploited on Election Day. We also note that the software is written entirely in C++. When programming in an unsafe language like C++, programmers must exercise tight discipline to prevent their programs from being vulnerable to buffer overflow attacks and other weaknesses. Indeed, buffer overflows caused real problems for AccuVote-TS systems in real elections.

2 System overview

Although the Diebold code is designed to run on a DRE device (an example of which is shown in Figure 1), one can run it on a regular Microsoft Windows computer (during our experiments we compiled and ran the code on a Windows 2000 PC).

In the following we describe the process for setting up and running an election using the Diebold system. Although we know exactly how the code works from our analysis, we must still make some assumptions about the external processes at election sites. In all such cases, our assumptions are based on the way the Die bold code works, and we believe that our assumptions are reasonable. There may, however, be additional administrative procedures in place that are not indicated by the source code. We first describe the architecture at a very high level, and then, in Section 2.1 we present an overview of the code. Since the Diebold code can be run both on DRE devices and PCs, we shall refer to a device running the vote collection software as a voting terminal.

SETTING UP. Before an election takes place, one of the first things the election officials must do is specify the Voter Poll Worker Poll Worker Internet Provider OS Voting Section (with forged (with access to (with access to (with access to Developer Device smartcard) storage media) network traffic) to network traffic) Developer

Vote multiple times using forged smartcard

Access administrative functions or close polling station

Modify system configuration

Impersonate legitimate voting machine to tallying authority

Modify ballot definition (e.g., party affiliation)

Cause votes to be miscounted by tampering with configuration

Tamper with audit logs

Create, delete, and modify votes on device

Link votes to voters

Delay the start of an election

Tamper with election results

Insert backdoors into code

This summarizes some of the more important attacks on the system.

Figure 1: A Diebold DRE Voting Machine (photo from http://www.sos.state.ga.us/). Note the smartcard reader in the lower-right hand corner. Political offices and issues to be decided by the voters along with the candidates and their party affiliations.Variations on the ballot can be presented to voters based on their party affiliations. We call this data a ballot definition. In the Diebold system, a ballot definition is encoded as the file election.edb and stored on a back-end server.Shortly prior to the election; the voting terminals must be installed at each voting location. In common usage, we believe the voting terminals will be distributed without a ballot definition pre-installed. Instead, a governmental entity using Diebold voting terminals has a variety of choices in how to distribute the ballot definitions. They may be distributed using removable media, such as floppy disks or storage cards. They may also be transmitted over the Internet or a dial-up connection. This provides additional flexibility to the election administrator in the event of last-minute changes to the ballot.

THE ELECTION. Once the voting terminal is initialized with the ballot definitions, and the election begins, voters are allowed to cast their votes. To get started, however, the voter must have a voter card. The voter card is a memory card or smartcard; i.e., it is a credit-card sized plastic card with a computer chip on it that can store data and, in the case of the smartcard, perform computation. We do not know exactly how the voter gets his voter card. It could be sent in the mail with information about where to vote, or it could be given out at the voting site on the day of the election. To understand the voting software itself, however, we do not need to know what process is used to distribute the cards to voters.

The voter takes the voter card and inserts it into a smartcard reader attached to the voting terminal. The terminal checks that the smartcard in its reader is a voter card and, if it is, presents a ballot to the voter on the terminal screen. The actual ballot the voter sees may depend on the voter’s political party, which is encoded on the voter card. If a ballot cannot be found for the voter’s party, the voter is given a nonpartisan ballot.

At this point, the voter interacts with the voting terminal, touching the appropriate boxes on the screen for his or her desired candidates. Headphones are available for visually-impaired voters to privately interact with the terminal. Before the ballots are committed to storage in the terminal, the voter is given a final chance to review his or her selections. If the voter confirms this, the vote is recorded on the voting terminal and the voter card is “canceled.” This latter step is intended to prevent the voter from voting again with the same card. After the voter finishes voting, the terminal is ready for another voter to use.

REPORTING THE RESULTS. A poll worker ends the election process by inserting an administrator card or an ender card (a special card that can only be used to end the election) into the voting terminal. Upon detecting the presence of such a card (and, in the case of the administrator card, checking a PIN entered by the card user), the poll worker is asked to confirm that the election is finished. If the poll worker agrees, then the voting terminal enters the post-election stage and can transmit its results to the back-end server.

As we have only analyzed the code for the Diebold voting terminal, we do not know exactly how the back-end server tabulates the final results it gathers from the individual terminals. Obviously, it collects all the votes from the various voting terminals. We are unable to verify that there are checks to ensure, for example, that there are no more votes collected than people who are registered at or have entered any given polling location.

Details

We now describe the Diebold system in more detail, making explicit references to the relevant portions of the code. The voting terminal is implemented in the directory Ballot Station/, but uses libraries in the supporting directories Ballot/, DES/, DiagMode/, Shared/, TSElection/, Utilities/, and Voter Card/.

The method CBallotStationApp::DoRun () is the main loop for the voting terminal software. The DoRun () method begins by invoking CBallotStationApp::LoadRegistry (), which loads information about the voting terminal from the registry (the registry keys are stored under HKEY_LOCAL_MACHINE\Software\GlobalElectionSystems\AccuVote-TS4). If the program fails to load the registry information, it believes that it is uninitialized and therefore creates a new instance of the CTSRegistryDlg class that asks the administrator to set up the machine for the first time. The administrator chooses, among other things, the COM port to use with the smartcard reader, the directory locations to store files, and the polling location identifier. The CBallotStationApp::DoRun () method then checks for the presence of a smartcard reader and, if none found, gives the administrator the option to interact with the CTSRegistryDlg again.

The DoRun () method then enters a while loop that iterates until the software is shut down. The first thing DoRun () does in this loop is check for the presence of some removable media on which to store election results and ballot configurations (a floppy under Windows or a removable storage card on a Windows CE device). It then tries to open the election configuration file election.edb. If it fails to open the configuration file, the program enters the CTSElectionDoc::ES_NOELECTION state and invokes CBallotStationApp::Download (), which creates an instance of CTransferElecDlg to download the configuration file. To do the download, the terminal connects to a back-end server using either the Internet or a dial-up connection. The program then enters the CTSElectionDoc::ES_PREELECT state, invokes the CBallotStationApp::PreElect () method, which in turn creates an instance of CPreElectDlg. The administrator can then decide to start the election, in which case the method CPreElectDlg::OnSetForElection () sets the state of the terminal to CTSElectionDoc::ES_

ELECTION.

Returning to the while loop in CBallotStationApp::DoRun (), now that the machine is in the state CTSElectionDoc::ES_ELECTION, the DoRun () method invokes CBallotStationApp: Election (), which creates an instance of CVoteDlg. When a card in inserted into the reader, the reader checks to see if the card is a voter card, administrator card, or ender card. If it is an ender card, or if it is an administrator card and if the user enters the correct PIN, the CVoteDlg ends and the user is asked whether he wishes to terminate the election and, if so, the state of the terminal is set to CTSElectionDoc::ES_POSTELECT. If the user entered a voter card, then DoVote () is invoked (here DoVote () is an actual function; it does not belong to any class). The DoVote () function finds the appropriate ballot for the user’s voter group or, if none exists, opens the nonpartisan ballot (recall that the system is designed to allow voters to vote by group or party). It then creates an instance of CBallotDlg to display the ballot and collect the votes.

We recall that if, during the election process, someone inserted an administrator or ender card into the terminal and chooses to end the election, the system would enter the CTSElectionDoc::ES_POSTELECT state. At this point the voting terminal would offer the ability to upload the election results to some back-end server for final tabulation. The actual transfer of results is handled by the CTransferResultsDlg::OnTransfer () method.

We will present more details about the Diebold system in the following sections.

Smartcards

While it is true that one can design secure systems around the use of smartcards, simply the use of smartcards in a system does not imply that the system is secure. The system must use the smartcards in an intelligent and security-conscious way. Unfortunately, the Diebold system’s use of smartcards provides very little (if any) additional security and, in fact, opens the system to several attacks.

Homebrew smartcards

Upon reviewing the Diebold code, we observed that the smartcards do not perform any cryptographic operations. For example, authentication of the terminal to the smartcard is done “the old-fashioned way:” the terminal sends a clear text (i.e., unencrypted) 8-byte password to the card and, if the password is correct, the card believes that it is talking to a legitimate voting terminal. Unfortunately, this method of authentication is insecure: an attacker can easily learn the 8-byte password used to authenticate the terminal to the card and thereby communicate with a legitimate smartcard using his own smartcard reader.

Furthermore, there is no authentication of the smartcard to the device. This means that nothing prevents an attacker from using his own homebrew smartcard in a voting terminal. One might naturally wonder how easy it would be for an attacker to make such a homebrew smartcard. First, we note that many smartcard vendors sell cards that can be programmed by the user. An attacker who knows the protocol spoken by the voting terminal to the legitimate smartcard could easily implement a homebrew card that speaks the same protocol. Even if the attacker does not a priori know the protocol, an attacker could easily learn enough about the protocol to create new voter cards by attaching a “wiretap” device between the voting terminal and a legitimate smartcard and observing the communicated messages. The parts for building such a device are readily available and, given the privacy of voting booths, might be unlikely to be noticed by poll workers.

An attacker might not even need to use a wiretap to see the protocol in use. Smartcards generally use the ISO 7816 standard smartcard message formats. Likewise, the important data on the legitimate voting card is stored as a file (named 0x3D40 — smartcard files have numbers instead of textual file name) that can be easily read by a portable smartcard reader. Again, given the privacy of voting booths, an attacker using such a card reader would be unlikely to be noticed. Given the ease with which an attacker can interact with legitimate smartcards, plus the weak password-based authentication scheme, an attacker could quickly gain enough insight to create homebrew voting cards, perhaps quickly enough to be able to use such homebrew cards during the same Election Day.

The only impediment to the mass production of homebrew smartcards is that each voting terminal will make sure that the smartcard has encoded in it the correct m_ElectionKey, m_VCenter, and m_DLVersion (see DoVote() in BallotStation/Vote.cpp). The m_ElectionKey and m_DLVersion are likely the same for all locations and, furthermore, for backward-compatibility purposes it is possible to use a card with m_ElectionKey and m_DLVersion undefined. The m_VCenter value could be learned on a per-location-basis by interacting with legitimate smartcards, from an insider, or from inferences based on the m_VCenter values observed at other polling locations.

It is worth pointing out that both the smartcards and readers supported by the code are available commercially over the Internet in small quantities. The smartcards, model number CLXSU004KC0, are available from CardLogix4, where $33.50 buys ten cards. General purpose CyberFlex JavaCards from Schlumberger cost $110 for five cards5. Smartcard reader/writers are available in a variety of models for under $100 from many vendors.

In the following two subsections we illustrate what an attacker could accomplish using homebrew smartcards in voting terminals running the Diebold code.3This, in an of itself, is an immediate red-flag. One of the biggest advantages of smartcards over classic magnetic-stripe cards is the smartcard’s ability to perform cryptographic operations internally with physically protected keys. Since the smartcards in the Diebold system do not perform any cryptographic operations, they effectively provide no more security than traditional magnetic stripe cards.

Multiple voting

In the Diebold system, a voter begins the voting process by inserting a smartcard into the voting terminal. Upon checking that the card is “active,” the voting terminal collects the user’s vote and then deactivates the user’s card (the deactivation actually occurs by changing the card’s type, which is stored as an 8-bit byte on the card, from VOTER_CARD (0x01) to CANCELED_CARD (0x08)). Since an adversary can make perfectly valid smartcards, the adversary could bring a stack of active cards to the voting booth. Doing so gives the adversary the ability to vote multiple times. More simply, instead of bringing multiple cards to the voting booth, the adversary could program a smartcard to ignore the voting terminal’s deactivation command. Such an adversary could use one card to vote multiple times. Will the adversary’s multiple-votes be detected by the voting system? To answer this question, we must first consider what information is encoded on the voter cards on a per-voter basis. The only per-voter information is a “voter serial number” (m_VoterSN in the CVoterInfo class). Because of the way the Diebold system works, m_VoterSN is only recorded by the voting terminal if the voter decides not to place a vote (as noted in the comments in TSElection/Results.cpp, this field is recorded for uncounted votes for backward compatibility reasons). It is important to note that if a voter decides to cancel his or her vote, the voter will have the opportunity to vote again using that same card (and, after the vote has been cast, m_VoterSN will not be recorded).Can the back-end tabulation system detect multiple-vote casting? If we assume the number of collected votes becomes greater than the number of people who showed up to vote, and if the polling locations keep accurate counts of the number of people who show up to vote, then the back-end system, if designed properly, should be able to detect the existence of counterfeit votes. However, because m_VoterSN is only stored for those who did not vote, there will be no way for the tabulating system to count the true number of voters or distinguish the real votes from the counterfeit votes. This would cast serious doubt on the validity of the election results. We point out, however, that we only analyzed the voting terminal’s code; we do not know whether such checks are performed in the actual back-end tabulating system.

Administrator and ender cards

As noted in Section 2, in addition to the voter cards that users use when they vote, there are also administrator cards and ender cards. These cards have special purposes in this system. Namely, the administrator cards give the possessor the ability to access administrative functionality (namely, the administrative dialog Ballot Station/ AdminDlg.cpp), and both types of cards allow the possessor to end the election (hence the term “ender card”).Just as an adversary can manufacture his or her own voter cards, an adversary can manufacture his or her own administrator and ender cards (administrator cards have an easily-circumventable PIN, which we will discuss in Section 3.2). This attack is easiest if the attacker has knowledge of the Diebold code or can interact with a legitimate administrator or ender card. However, an attacker without knowledge of the inner workings of the Diebold system and without the ability to interact directly with a legitimate administrator or ender card may have a difficult time producing a homebrew administrator or ender card since the attacker would not know what distinguishes an administrator or ender card from a normal voter card. (The distinction is that, for a voter card m_CardType is set to 0x01, for an ender card m_CardType is set to 0x02, and for an administrator card m_CardType is set to 0x04.) As one might expect, an adversary in possession of such illicit cards has further attack options against the Diebold system. Using a homebrew administrator card, a poll worker, who might not otherwise have access to the administrator functions of the Diebold system but who does have access to the voting machines before and after the elections, could gain access to the administrator controls? If a malicious voter entered an administrator or ender card into the voting device instead of the normal voter card, then the voter would be able to terminate the election and, if the card is an administrator card, gain access to additional administrative controls.

The use of administrator or ender cards prior to the completion of the actual election represents an interesting denial-of-service attack. Once “ended,” the voting terminal will no longer accept new voters until the terminal is somehow reset. Such an attack, if mounted simultaneously by multiple people, could shut down a polling place. If a polling place is in a precinct considered to favor one candidate over another, attacking that specific polling place could benefit the less-favored candidate. Even if the poll workers were later able to resurrect the systems, the attack might succeed in deterring a large number of potential voters from voting (e.g., if the attack was performed over the lunch hour). If such an attack was mounted, one might think the attackers would be identified and caught. We note that many governmental entities do not require identification to be presented by a voter, instead allowing for “provisional” ballots to be cast. By the time the poll workers realize that one of their voting terminals has been disabled, the perpetrator may have long-since left the scene.

Unprotected PINs

When a user enters an administrator card into a voting terminal, the voting terminal asks the user to enter a 4-digit PIN. If the correct PIN is entered, the user is given access to the administrative controls. Upon looking more closely at this administrator authentication process, however, we see that there is a flaw with the way the PINs are verified. When the terminal and the smartcard first begin communicating, the PIN value stored on the card is sent in clear text from the card to the voting terminal. Then, when the user enters the PIN into the terminal, it is compared with the PIN that the smartcard sent (CPinDlg::OnOK ()). If these values are equal, the system accepts the PIN. Herein lays the flaw with this design: any person with a smartcard reader can easily extract the PIN from an administrator card. The adversary doesn’t even need to fully understand the protocol between the terminal and the device: if the response from the card is n bytes long, the attacker who correctly guesses that the PIN is sent in the clear would only have to try n¡3 possible PINs, rather than 10,000. This means that the PINs are easily circumventable. Of course, if the adversary knows the protocol between the card and the device, an adversary could just make his own administrator card, using any desired PIN

 Terminal-to-card authentication

Let us now consider how the terminal authenticates to the card in more detail (note that this is different from the Administrator PIN; here the terminal is being authenticated rather than the user). The relevant code from VoterCard/CLXSmartCard.cpp is listed below. The code is slightly modified for illustrative purposes, but the developers’ comments have been left intact. SMC_ERROR CCLXSmartCard::Open (CCardReader* pReader) {... [removed code] ...// Now initiate access to the card// If failed to access the file then have unknown card if (SelectFile(0x3d40) != SMC_OK) st = SMC_UNKNOWNCARD; // Else if our password works then all done else if (Verify(0x80, 8, {0xed, 0x0a, 0xed, 0x0a, 0xed, 0x0a, 0xed, 0x0a})== SMC_OK) st = SMC_OK; // Else if manufactures password works then try to change password else if(Verify(0x80, 8, {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08})11 == SMC_OK) {st = ChangeCode(8, {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}, 8, {0xed, 0x0a, 0xed, 0x0a, 0xed, 0x0a, 0xed, 0x0a}); // Else have a bad card } else st = SMC_BADCARD; return st;} In the above code, the SelectFile(0x3d40) command sends the bytes 0x00, 0xA4, 0x00, 0x00,0x02, 0x3D, 0x40, 0x00 to the smartcard in cleartext; this is the ISO 7816 smartcard command for selecting a file on the card (0x3D40 in this case). If passwd is a sequence of 8 bytes, the Verify (0x80, 8, passwd) command sends the bytes 0x00, 0x20 0x00, 0x80, 0x08, passwd [0], passwd [1], passwd[7], 0x00 to the smartcard in cleartext.

There are several issues with the above code. First, hard-coding passwords in C++ files are generally a poor design choice. We will discuss coding practices in more detail in Section 6, but we summarize some issues here. Hard-coding passwords into C++ files suggest a lack of key and password management. Furthermore, even if the developers assumed that the passwords would be manually changed and the software recompiled on a per-election basis, it would be very easy for someone to forget to change the constants in VoterCard/CLXSmartCard.cpp. (Recompiling on a per-election basis may also be a concern, since good software engineering practices would dictate additional testing and certification if the code were to be recompiled for each election.)

The above issues would only be a concern if the authentication method were otherwise secure. Unfortunately, it is not. Since the password is sent in the clear from the terminal to the card, an attacker who puts a fake card into the terminal and records the command from the terminal will be able to learn the password (and file name) and then re-use that password with real cards. An adversary with knowledge of this password could then create counterfeit voting cards. As we have already discussed (see Section 3.1.1), this can allow the adversary to cast multiple votes, among other attacks. Hence, the authentication of the voting terminal to the smartcards is insecure. We find this particularly surprising because modern smartcard designs allow cryptographic operations to be performed directly on the smartcard, making it possible to create systems that are not as easily vulnerable to security breaches.

Furthermore, note the control flow in the above code-snippet. If the password chosen by the designers of the system (“\xED\x0A\xED\x0A\xED\x0A\xED\x0A”) does not work, then CCLXSmartCard: Open () uses the smartcard manufacturer’s default password6 of “\x00\x01\x02\x03\x04\x05\x06\x07.” One issue with this is that it implies that sometimes the system is used with un-initialized smartcards. This means that an attacker might not even need to figure out the system’s password in order to be able to authenticate to the cards. As we noted in Section 3.1, some smartcards allow a user to get a listing of all the files on a card. If the system uses such a card and also uses the manufacturer’s default password of \x00\x01\x02\x03\x04\x05\x06\x07, then an attacker, even without any knowledge of the source code and without the ability to intercept the connection between a legitimate card and a voting terminal, but with access to a legitimate voter card, will still be able to learn enough about the smartcards to be able to create counterfeit voter cards.76 Many smartcards are shipped with default passwords. 7 Making homebrew cards this way is somewhat risky, as the attacker must make assumptions about the system. In particular, the attacker is assuming that his or her counterfeit cards would not be detected by the voting terminals. Without access to the source code, the attacker would never know, without testing, whether it was truly safe to attack a voting terminal. 124 Data storage while the data stored internally on each voting terminal is not as accessible to an attacker as the voting system’s smartcards, exploiting such information presents a powerful attack vector, especially for an election insider. In this section we outline the data storage available to each terminal and then detail how each distinct type of data is stored.

4.1 Data storage overview

Each voting terminal has two distinct types of internal data storage. A main (or system) storage area contains the terminal’s operating system, program executables, static data files such as fonts, and system configuration information, as well as backup copies of dynamic data files such as the voting records and audit logs. Each terminal also contains a removable storage device that is used to store the primary copies of these dynamic data files. When the terminal is running a standard copy of Windows (e.g., Windows 2000) the removable storage area is the first floppy drive; when the terminal is running Windows CE the removable storage area is a removable storage card. Storing the dynamic data on two distinct devices is advantageous for both reliability and security: if either of the two storage mediums fails, data can still be recovered from the copy.

Unfortunately, under Windows CE, which we believe is used in commercial Diebold voting terminals, the existence of the removable storage device is not enforced properly. Unlike other versions of Windows, removable storage cards are mounted as subdirectories under CE. When the voting software wants to know if a storage card is inserted, it simply checks to see if the Storage Card subdirectory exists in the file system’s root directory. While this is the default name for a mounted storage device, it is also a perfectly legitimate directory name for a directory in the main storage area. Thus, if such a directory exists, the terminal can be fooled into using the same storage device for all of the data.8 This would reduce the amount of redundancy in the voting system and would increase the chances that a hardware fault could cause recorded votes to be lost.

4.2 System configuration

The majority of the system configuration information for each terminal is stored in the Windows registry under   HKEY_LOCAL_MACHINE\Software\GlobalElectionSystems\AccuVote-TS4. This includes both identification information such as the terminal’s serial number and more traditional configuration information such as the COM port that the smartcard reader is attached to. All of the configuration information is stored in the clear, without any form of integrity protection. Thus, all an adversary must do is modify the system registry to trick a given voting terminal into effectively impersonating any other voting terminal. It is unclear how the tallying authority would deal with results from two different voting terminals with the same voting ID — at the very least human intervention to resolve the conflict would probably be required.

The Federal Election Commission draft standard9 requires each terminal to keep track of the total number of votes that have ever been cast on it — the “Protective Counter.” This counter is used to provide yet another method for ensuring that the number of votes cast on each terminal is correct. However, as the following code from Utilities/machine.cpp shows, the counter is simply stored as an integer in the file system. Bin in the terminal’s system directory (error handling code has been removed for clarity):

This situation can be easily corrected by checking for the FILE ATTRIBUTE TEMPORARY attribute on the directory as described in http://msdn.microsoft.com/library/enus/wcefiles/htm/_wcesdk_Accessing_Files_on_Other_Storage_Media.asp 9http://fecweb1.fec.gov/pages/vss/vss.html 13 long GetProtectedCounter() {DWORD protected Counter = 0;CString filename = ::GetSysDir(); filename += _T("system. Bin"); CFile file; file.Open (filename, CFile::modeRead | CFile::modeCreate | CFile::modeNoTruncate); file.Read (&protectedCounter, sizeof (protectedCounter)); file. Close (); return protected Counter ;}

By modifying this counter, an adversary could cast doubt on an election by creating a discrepancy between the number of votes cast on a given terminal and the number of votes that are tallied in the election. While the current method of implementing the counter is totally insecure, even a cryptographic checksum would not be enough to protect the counter; an adversary with the ability to modify and view the counter would still be able to roll it back to a previous state. In fact, the only solution that would work would be to implement the protective counter in tamper-resistant hardware token, requiring modifications to the physical voting terminal hardware.

4.3 Ballot definition

The “ballot definition” for each election contains everything from the background color of the screen to the PPP username and password to use when reporting the results. This data is not encrypted or check summed (cryptographically or otherwise) and so can be easily modified by any attacker with physical access to the file. While many attacks, such as changing the party affiliation of a candidate, would be noticed by some voters, many more subtle attacks are possible. By simply changing the order of the candidates as they appear in the ballot definition, the results file will change accordingly. However, the candidate information itself is not stored in the results file. The file merely tracks that candidate 1 got so many votes and candidate 2 got so many other votes. If an attacker reordered the candidates on the ballot definition, voters would unwittingly cast their ballots for the wrong candidate. As with denial-of-service attacks (see Section 3.1.2),

Ballot reordering attacks would be particularly effective in polling locations known to be heavily partisan.

Even without modifying the ballot definition, an attacker can gain almost enough information to impersonate the voting terminal to the back-end server. The terminal’s voting center ID, PPP dial-in number, username, password and the IP address of the back-end server are all available in the clear (these are parsed into a CElectionHeaderItem in TSElection\TSElectionObj.cpp). Assuming an attacker is able to guess or create a voting terminal ID, he would be able to transmit fraudulent vote reports to the backend server by dialing in from his own computer. While both the paper trail and data stored on legitimate terminals could be used to compensate for this attack after the fact, it could, at the very least, delay the election results. (The PPP number, username, password, and IP address of the back-end server are also stored in the registry HKEY_LOCAL_MACHINE\Software\GlobalElectionSystems\AccuVote- TS4\TransferParams. Since the ballot definition may be transported on portable memory cards or floppy disks, the ballot definition may perhaps be easier to obtain from this distribution media rather than from the voting terminal’s internal data storage.)

We will return to some of these points in Section 5.1, where we show that modifying and viewing ballot definition files does not always require physical access to the terminals on which they are stored.

4.4 Votes and audit logs

Unlike the other data stored on the voting terminal, both the vote records and the audit logs are encrypted and check summed before being written to the storage device. Unfortunately, neither the encrypting nor the check summing is done securely. All of the data on a storage device is encrypted using a single, hard coded DES [NBS77] key: #define DESKEY ((des_key*)"F2654hD4") Note that this value is not a hex representation of a key. Instead, the bytes in the string “F2654hD4” are fed directly into the DES key scheduler. If the same binary is used on every voting terminal, an attacker with access to the source code, or even to a single binary image, could learn the key, and thus read and modify voting and auditing records. Even if proper key management were to be implemented, many problems would still remain. First, DES keys can be recovered by brute force in a very short time period [Gil98]. DES should be replaced with either triple-DES [Sch96] or, preferably, AES [DJ02]. Second, DES is being used in CBC mode which requires an initialization vector to ensure its security. The implementation here always uses zero for its IV. This is illustrated by the call to DesCBCEncrypt in TSElection/RecordFile.cpp; since the second to last argument is NULL, DesCBCEncrypt will use the all-zero IV.

DesCBCEncrypt((des_c_block*)tmp, (des_c_block*)record.m_Data, totalSize,

DESKEY, NULL, DES_ENCRYPT); This allows an attacker to mount a variety of cryptanalytic attacks on the data. To correctly implement CBC mode, a source of “strong” random numbers must be used to generate a fresh IV for each encryption [BDJR97]. Suitably strong random numbers can be derived from many different sources, ranging from custom hardware through observation of user behavior. (Jones reports that the vendor may have been aware of this design flaw in their code for several years [Jon01, Jon03]. We see no evidence that this design flaw was ever addressed.) Before being encrypted, a 16-bit cyclic redundancy check (CRC) of the plaintext data is computed. This CRC is then stored along with the ciphertext in the file and verified whenever the data is decrypted and read. This process in handled by the ReadRecord and WriteRecord functions in TSElection/RecordFile.cpp. Since the CRC is an unkeyed, public function, it does not provide any real integrity for the data. In fact, by storing it in an unencrypted form, the purpose of encrypting the data in the first place (leaking no information about the contents of the plaintext) is undermined. A much more secure design would be to first encrypt the data to be stored and then to compute a keyed cryptographic checksum (such as HMAC-SHA1 [BCK96]) of the ciphertext. This cryptographic checksum could then be used to detect any tampering with the plaintexts. Note also that each entry has a timestamp, which will prevent the re-ordering, though not deletion, of records.

Each entry in a plaintext audit log is simply a time stamped, informational text string. At the time that the logging occurs, the log can also be printed to an attached printer. If the printer is unplugged, off, or malfunctioning, however, no record will be stored elsewhere to indicate that the failure occurred. The following code from TSElection/Audit.cpp demonstrates that the designers failed to consider these issues: if (m_Print && print) {CPrinter printer; // If failed to open printer then just return. CString name = ::GetPrinterPort(); if (name.Find(_T("\\")) != -1) name = GetParentDir(name) + _T("audit.log"); if (!printer.Open(name, ::GetPrintReverse(), FALSE)) ::TSMessageBox(_T("Failed to open printer for logging"));} else {Do the printing: : :}

If the cable attaching the printer to the terminal is exposed, an attacker could create discrepancies between the printed log and the log stored on the terminal by unplugging the printer (or, by simply cutting the cable). An attacker’s most likely target will be the voting records, themselves. Each voter’s votes are stored as a bit array based on the ordering in the ballot definition file along with other information such as the precinct the voter was in, although no information that can be linked to a voter’s identity is included. If the voter has chosen a write-in candidate, this information is also included as an ASCII string. An attacker given access to this file would be able to generate as many fake votes as he or she pleased, and such votes would be indistinguishable from the true votes cast on the terminal.

While the voter’s identity is not stored with the votes, each vote is given a serial number. These serial numbers are generated by a linear congruential random number generator (LCG), seeded with static information about the election and voting terminal. No dynamic information, such as the current time, is used. // LCG - Linear Congenital Generator - used to generate ballot serial numbers // A pseudo-random-sequence generator // (per Applied Cryptography, by Bruce Schneier, Wiley, 1996)

While the code’s authors apparently decided to use an LCG because it appeared in Applied Cryptography [Sch96], LCG’s are far from secure. However, attacking this random number generator is unnecessary for determining the order in which votes were cast: each vote is written to the file sequentially. Thus, if an attacker is able to determine the order in which voters cast their ballots, the results file has a nice list, in the order in which voters used the terminal. A malevolent poll worker, for example, could surreptitiously track the order in which voters use the voting terminals. Later, in collaboration with other attackers who might intercept the poorly encrypted voting records, the exact voting record of each voter could be reconstructed.

Physical access to the voting results may not even be necessary to acquire the voting records, if they are transmitted across the Internet. 5 Communicating with the outside world The Diebold voting machines cannot work in isolation. They must be able to both receive a ballot definition file as input and report voting results as output. As described in Section 2, there are essentially two ways to load a voting terminal with an initial election configuration: via some removable media, such as a floppy disk, or over the Internet. In the latter case, the voting terminal could either be plugged directly into the Internet or could use a dial-up connection (the dial-up connection could be to a local ISP or directly to the election authorities modem banks). After the election is over, election results are sent to a back-end post-processing server over the network (again, possibly through a dial-up connection).

Unfortunately, there are a number of attacks against this system that exploit the system’s reliance on and communication with the outside world.

5.1 Tampering with ballot definitions

We first note that it is possible for an adversary to tamper with the voting terminals’ ballot definition file (election.edb). If the voting terminals load the ballot definition from a floppy or removable storage card, then an adversary, such as a poll worker, could tamper with the contents of the floppy before inserting it into the voting terminal. On a potentially much larger scale, if the voting terminals download the ballot definition from the Internet, then an adversary could tamper with the ballot definition file en-route from the back-end server to the voting terminal. With respect to the latter, we point out that the adversary need not be an election insider; the adversary could, for example, be someone working at the local ISP. If a wireless network is used, anybody within radio range becomes a potential adversary. With high-gain antennas, the adversary can be sufficiently distant to have little risk of detection. If the adversary knows the structure of the ballot definition, then the adversary can intercept and modify the ballot definition while it is being transmitted. Even if the adversary does not know the precise structure of the ballot definition, many of the fields inside are easy to identify and change, including the candidates’ names, which appear as plain ASCII text.10

Let us now consider some example attacks that make use of modifying the ballot definition file. Because no cryptographic techniques are in place to guard the integrity of the ballot definition file, an attacker could add, remove, or change issues on the ballot, and thereby confuse the result of the election.

In the system, different voters can be presented with different ballots depending on their party affiliations (see CBallotRelSet::Open(), which adds different issues to the ballot depending on the voter’s m_VGroup1 and m_VGroup2 CVoterInfo fields). If an attacker changes the party affiliations of the candidates, then he may succeed in forcing the voters to view and vote on erroneous ballots. Even in municipalities that use the same ballot for all voters, a common option in voting systems is to allow a voter to select all the candidates from a given political party. Voters may not notice if candidates have incorrect party affiliations listed next to their names, and by choosing to vote a straight ticket, would end up casting ballots for undesirable candidates.

As an example of what might happen if the party affiliations were listed incorrectly, we note that, according to news story11, in the 2000 New Mexico presidential election, over 65,000 votes were incorrectly counted because a worker accidentally had the party affiliations wrong. (We are not claiming, however, that those affiliations were maliciously assigned incorrectly. Nor are we implying that this had an effect on the results of the election.) Likewise, an attacker who can change the ballot definition could also change the ordering of the candidates running for a particular office. Since, at the end of the election, the results are uploaded to the server in the order that they appear in the the ballot definition file, and since the server will believe that the results appear in their original order, this attack could also succeed in swapping the votes between parties in a predominantly partisan precinct. This ballot reordering attack is also discussed in more detail in Section 4.3.

5.2 Preventing the start of an election

Suppose that the election officials are planning to download the configuration files over the Internet and that they are running late and do not have much time before the election starts to distribute ballot definitions manually (i.e., they might not have enough time to distribute physical media with the ballot definition files from central office to every voting precinct). In such a situation, an adversary could mount a traditional

The relevant sections of code are as follows: CTransferElecDlg::OnTransfer() invokes CTSElectionDoc:: CreateEDB(), which reads the data from a CDL2Archive. The way the code works, CDL2Archive reads and writes to a CBufferedSocketFile. Returning to CTSElectionDoc::CreateEDB(), we see that it invokes CTSElectionDB::

Create(), which subsequently invokes CTSElectionFile::Save(). The functions called in CTSElectionFile::Save() read data, such as strings, from the CDL2Archive.

17 Internet denial-of-service attack against the election management’s server and thereby prevent the voting terminals from acquiring their ballot definitions before the start of the election. To mount such an attack effectively, the adversary would ideally need to know the topology of the system’s network, and the name of the server(s) supplying the ballot definition file.12 if a fair number of people from a certain demographic plan to vote early in the morning, then this could impact the results of the election.

Of course, we acknowledge that there are other ways to postpone the start of an election at a voting location that do not depend on the use of this system (e.g., flat tires for all poll workers for a given precinct). Unlike such traditional attacks, however, the network-based attack (1) is relatively easy for anyone with knowledge of the election system’s network topology to accomplish; (2) this attack can be performed on a very large scale, as the central distribution point(s) for ballot definitions becomes an effective single point of

Failure; and (3) the attacker can be physically located anywhere in the Internet-connected world, complicating efforts to apprehend the attacker. Such attacks could prevent or delay the start of an election at all voting locations in a state. We note that this attack is not restricted to the system we analyzed; it is applicable to any system that downloads its ballot definition files using the Internet.

5.3 Tampering with election results

Just as it is possible for an adversary to tamper with the downloading of the ballot definition file (Section 5.1), it is also possible for an adversary to tamper with the uploading of the election results. To make this task even easier for the adversary, we note that although the election results are stored “encrypted” on the voting devices (Section 4.4), the results are sent from the voting devices to the back-end server over an unauthenticated and unencrypted channel. In particular, CTransferResultsDlg::OnTransfer() writes ballot results to an instance of CDL2Archive, which then writes the votes in clear text to a socket without any cryptographic checksum.

Sending election results in this way over the Internet is a bad idea. Nothing prevents an attacker with access to the network traffic, such as workers at a local ISP, from modifying the data in transit. Such an attacker could, for example, decrease one candidates vote count by n and increase the candidate’s count by n. Of course, to introduce controlled changes to the votes, the attacker would require some knowledge of the structure of the messages sent from the voting terminals to the back-end server. If the voting terminals use a modem connection directly to the tabulating authority’s network, rather than the Internet, then the risk of such an attack is less, although still not inconsequential. A sophisticated adversary (or employee of the local phone company) could tap the phone line and intercept the communication. All of these adversaries could be easily defeated by properly using standard encryption suites like SSL/TLS, used throughout the World Wide Web for e-commerce security. We are puzzled why such a widely accepted and studied technology is not used by the voting terminals to safely communicate across potentially hostile networks.

5.4 Attacking the voting terminals directly

In some configurations, where the voting terminals are directly connected to the Internet, it may be possible for an adversary to attack them directly, perhaps using an operating system exploit or buffer overflow attack of some kind. Ideally the voting devices and their associated firewalls would be configured to accept no incoming connections [CBR03]. This concern would apply to any voting terminal, from any vendor, with a direct Internet connection.

Knowledge of the specific servers is unnecessary for a large scale distributed denial of service attack. An attacker simply needs to correctly guess that the ballot definition’s file server is on a specific network (e.g., at the voting system’s vendor or in the municipality’s government).

 Software engineering

When creating a secure system, getting the design right is only part of the battle. The design must then be securely implemented. We now examine the coding practices and implementation style used to create the voting device. This type of analysis can offer insights into future versions of the code. For example, if a current implementation has followed good implementation practices but is simply incomplete, one would be more inclined to believe that future; more complete versions of the code would be of a similar high quality. Of course, the opposite is also true, perhaps even more so: it is very difficult to produce a secure system by building on an insecure foundation.

Of course, reading the source code to a product gives only an incomplete view into the actions and intentions of the developers who created that code. Regardless, we can see the overall software design, we can read the comments in the code and thanks to the CVS repository, and we can even look at earlier versions of the code and read the developers’ commentary as they committed their changes to the archive.

6.1 Code Legacy

Inside costar we found multiple CVS archives. Two of the archives, AccuTouch and AVTSCE implement full voting terminals. The AccuTouch code dates to around 2000 and is copyrighted by “Global Election Systems, Inc.” while the AVTSCE code dates to mid-2002 and is copyrighted by “Diebold Election Systems, Inc.” (The CVS logs show that the copyright notice was updated on February 26, 2002.) Many files are nearly identical between the two systems and the overall design appears very similar. Indeed, Diebold acquired Global Election Systems in September, 2001.13 Some of the code, such as the functions to compute CRCs and DES, dates back to 1996, when Global Election Systems was called “I-Mark Systems.”

This legacy is apparent in the code itself as there are portions of the AVTSCE code, including entire classes that are either simply not used or removed through the use of #ifdef statements. Many of these functions are either incomplete or, worse, do not perform the function that they imply as is the case with Compare Files in Utilities/FileUtil.cpp: BOOL Compare Files (const CString& file1, const CString& file2)

{

/* XXX use a CRC or something similar */BOOL exists1, exists2; HANDLE hFind;

WIN32_FIND_DATA fd1, fd2;exists1 = ((hFind = ::FindFirstFile(file1, &fd1)) != INVALID_HANDLE_VALUE);::FindClose(hFind);exists2 = ((hFind = ::FindFirstFile(file2, &fd2)) != INVALID_HANDLE_VALUE);::FindClose(hFind);

Return (exists1 && exists2 && fd1.nFileSizeLow == fd2.nFileSizeLow);

Currently the code will declare any two files to be the same that have the same size. The author’s comment to use a CRC doesn’t make much sense, as a byte-by-byte comparison would be more efficient. If this code were ever used, its inaccuracies could lead to wide variety of subsequent errors. While most of the preprocessor directives that remove code correctly use #if 0 as their condition, some use #ifdef XXX. There is no reason that a later programmer should realize that defining XXX will cause blocks of code to be reincluded in the system (causing unpredictable results, at best). We also noticed #ifdef LOUISIANA in the code. Prudent software engineering would recommend a single implementation of the voting software, where individual states or municipalities could have their desired custom features expressed in configuration files.

6.2 Coding style

While the system is implemented in an unsafe language (C++), the code reflects an awareness of avoiding such common hazards as buffer overflows. Most string operations already use their safe equivalents, and there are comments reminding the developers to change others (e.g., should really use snprintf). While we are not prepared to claim that there are no buffer overflows in the current code, there are at the very least no glaringly obvious ones. Of course, a better solution would have been to write the entire system in a safe language, such as Java or C#.The core concepts of object oriented programming such as encapsulation are well represented, though in some places C++’s non-typesafe nature is exploited with casts that could conceivably fail. This could cause problems in the future as these locations are not well documented. Overall, the code is rather unevenly commented. While most files have a description of their overall function, the meanings of individual functions, their arguments, and the algorithms within are more often than not undocumented. An extreme example of a complex but completely undocumented function is the CBallotRelSet::Open function from TSElection/TSElectionSet.cpp: void CBallotRelSet::Open (const CDistrict* district, const CBaseunit* baseunit, const CVGroup* vgroup1, const CVGroup* vgroup2)

{

ASSERT (m_pDB != NULL);ASSERT(m_pDB->IsOpen());ASSERT(GetSize() == 0);

ASSERT(district != NULL);ASSERT(baseunit != NULL);if (district->KeyId() == -1) {

Open(baseunit, vgroup1);} else { const CDistrictItem* pDistrictItem = m_pDB->Find(*district); if (pDistrictItem != NULL) {const CBaseunitKeyTable& baseunitTable = pDistrictItem->m_BaseunitKeyTable;int count = baseunitTable.GetSize();for (int i = 0; i < count; i++) {const CBaseunit& curBaseunit = baseunitTable.GetAt(i);if (baseunit->KeyId() == -1 || *baseunit == curBaseunit) {const CBallotRelationshipItem* pBalRelItem = NULL;while ((pBalRelItem = m_pDB->FindNextBalRel(curBaseunit, pBalRelItem))){if (!vgroup1 || vgroup1->KeyId() == -1 ||(*vgroup1 == pBalRelItem->m_VGroup1 && !vgroup2) ||(vgroup2 && *vgroup2 == pBalRelItem->m_VGroup2 &&*vgroup1 == pBalRelItem->m_VGroup1))Add(pBalRelItem);m_CurIndex = 0;Open = TRUE;20

Nothing about this code makes its purpose readily apparent. Certainly, it has two nested loops and is doing all kinds of comparisons. Beyond that, most readers of the code would need to invest significant time to learn the meaning of the various names shown here.

6.3 Coding process

An important point to consider is how code is added to the system. From the CVS logs, we can see that most code updates are in response to specific bugs that needed to be fixed. There are numerous authors who have committed changes to the CVS tree, and the only evidence that we have found that the code undergoes any sort of review process comes from a single log comment: “Modify code to avoid multiple exit points to meet Wyle requirements.” This could refer to Wyle Laboratories whose website claims that they provide all manner of testing services.

There are also pieces of the voting system that come from third parties. Most obviously is the operating system, either Windows 2000 or Windows CE. Both of these OSes have had numerous security vulnerabilities and their source code is not available for examination to help rule out the possibility of future attacks. Besides the operating system, an audio library called “fmod” is used.15 while the source to fmod is available

with commercial licenses, unless the code is fully audited there is no proof that fmod itself does not contain a backdoor.

Due to the lack of comments, the legacy nature of the code, and the use of third-party code and operating systems, we believe that any sort of comprehensive, top-to-bottom code review would be nearly impossible. Not only does this increase the chances that bugs exist in the code, but it also implies that any of the coders could insert a malicious backdoor into the system. The current design deficiencies provide enough other attack vectors that such an explicit backdoor is not required to successfully attack the system. Regardless, even if the design problems are eventually rectified, the problems with the coding process may well remain intact.

6.4 Code completeness and correctness

While the code we studied implements a full system, the implementers have included extensive comments on the changes that would be necessary before the system should be considered complete. It is unclear whether the programmers actually intended to go back and remedy all of these issues as many of the comments existed, unchanged, for months, while other modifications took place around them. It is also unclear whether later version of AVTSCE was subsequently created. (Modification dates and locations are easily visible from the CVS logs.) These comments come in a number of varieties. For illustrative purposes, we have chosen to show a few such comments from the subsystem that plays audio prompts to visually-impaired voters.

² Notes on code reorganization:

/* Okay, I don’t like this one bit. It’s really tough to tell where m Audio Player should live. [...] Reorganization might be in order here. */

² Notes on parts of code that need cleaning up:

/* this is a bit of a hack for now. [...] Calling from the timer message appears to work. Solution is to always do a 1ms wait between audio clips. */

14http://www.wylelabs.com/te.html

15http://www.fmod.org/

21

² Notes on bugs that need fixing:

/* need to work on exception *caused by audio*. I think they will currently result in double-fault. */

There are, however, no comments that would suggest that the design will radically change from a security perspective. None of the security issues that have been discussed in this paper are pointed out or marked for correction. In fact, the only evidence at all that a redesign might at one point have been considered comes from outside the code: the Crypto++ library16 is included in another CVS archive in cvs.tar. However, the library was added in September 2000 and was never used or updated. We infer that one of the

developers may have thought that improving the cryptography would be useful, but then got distracted with other business.

7 Conclusions

Using publicly available source code, we performed an analysis of a voting machine. This code was apparently developed by a company that sells to states and other municipalities that use them in real elections. We found significant security flaws: voters can trivially cast multiple ballots with no built-in traceability, administrative functions can be performed by regular voters, and the threats posed by insiders such as poll workers, software developers, and even janitors, is even greater. Based on our analysis of the development environment, including change logs and comments, we believe that an appropriate level of programming discipline for a project such as this was not maintained. In fact, there appears to have been little quality control in the process. For quite some time, voting equipment vendors have maintained that their systems are secure, and that

the closed-source nature makes them even more secure. Our glimpse into the code of such a system reveals that there is little difference in the way code is developed for voting machines relative to other commercial endeavors. In fact, we believe that an open process would result in more careful development, as more scientists, software engineers, political activists, and others who value their democracy would be paying attention to the quality of the software that is used for their elections. (Of course, open source would not solve all of the problems with electronic elections. It is still important to verify somehow that the binaries running in the machine corresponds to the source code and that the compilers used on the source code are non-malicious.

However, open source is a good start.) Such open design processes have proven successful in projects ranging from very focused efforts, such as specifying the Advanced Encryption Standard (AES) [NBB+00],through very large and complex systems such as maintaining the Linux operating system. Alternatively, security models such as the voter-verified audit trail allow for electronic voting systems that produce a paper trail that can be seen and verified by a voter. In such a system, the correctness burden on the voting terminal’s code is less extreme because voters can see and verify a physical object that embodies their vote. Even if, for whatever reason, the machines cannot name the winner of an election, then the paper ballots can be recounted, either mechanically or manually, to gain progressively more accurate election results.

The model where individual vendors write proprietary code to run our elections appears to be unreliable, and if we do not change the process of designing our voting systems, we will have no confidence that our election results will reflect the will of the electorate. We owe it to ourselves and to our future to have robust, well-designed election systems to preserve the bedrock of our democracy.

16http://www.eskimo.com/˜weidai/cryptlib.html

22 Acknowledgments

We thank Cindy Cohn, David Dill, Badri Natarajan, Jason Schultz, David Wagner, and Richard Wiebe for their suggestions and advice.

References

[BCK96] M. Bellare, R. Canetti, and H. Krawczyk. Keying hash functions for message authentication. In Advances in Cryptology: Proceedings of CRYPTO ’96, pages 1–15. Springer-Verlag, 1996. [BDJR97] M. Bellare, A. Desai, E. Jokipii, and P. Rogaway. A concrete security treatment of symmetric encryption. In Proceedings of the 38th Annual Symposium on Foundations of Computer Science, pages 394–403. IEEE Computer Society Press, 1997. [Cal00] California Internet Voting Task Force. A report on the feasibility of Internet voting, January 2000. http://www.ss.ca.gov/executive/ivote/.

[Cal01] Voting: What is; What Could be, July 2001. http://www.vote.caltech.edu/

Reports/. [CBR03] W. R. Cheswick, S. M. Bellovin, and A. D. Rubin. Firewalls and Internet Security; Repelling the Wily Hacker. Addison-Wesley, Reading, MA, 2003.

[Die03] Diebold Election Systems. AVTSCE/ source tree, 2003. Available in http://users.

actrix.co.nz/dolly/Vol2/cvs.tar. [DJ02] J. Daemen and V. Jijmen. The Design of Rijndael: AES–The Advanced Encryption Standard.Springer, 2002.

[DMNW03] D. L. Dill, R. Mercuri, P. G. Neumann, and D. S. Wallach. Frequently Asked Questions about DRE Voting Systems, February 2003. http://www.verifiedvoting.org/drefaq.asp.

[Gil98] J. Gilmore, editor. Cracking DES: Secrets of Encryption Research, Wiretap Politics & ChipDesign. O’Reilly, July 1998.

[Har03] B. Harris. Black Box Voting: Vote Tampering in the 21st Century. Elon House/Plan Nine, July2003.

[Jon01] D. W. Jones. Problems with Voting Systems and the Applicable Standards, May 2001. Testimonybefore the U.S. House of Representatives’ Committee on Science, http://www.cs.uiowa.edu/˜jones/voting/congress.html.

[Jon03] D. W. Jones. The Case of the Diebold FTP Site, July 2003. http://www.cs.uiowa.

edu/˜jones/voting/dieboldftp.html.

[Ker83] A. Kerckhoffs. La Cryptographie Militaire. Libraire Militaire de L. Baudoin & Cie, Paris,1883.

[Mer00] R. Mercuri. Electronic Vote Tabulation Checks and Balances. PhD thesis, University of Pennsylvania, Philadelphia, PA, October 2000.

23[Nat01] National Science Foundation. Report on the National Workshop on Internet Voting: Issues and Research Agenda, March 2001. http://news.findlaw.com/cnn/docs/voting/nsfe-voterprt.pdf.

[NBB+00] J. Nechvatal, E. Barker, L. Bassham, W. Burr, M. Dworkin, J. Foti, and E. Roback. Report on the Development of the Advanced Encryption Standard (AES), October 2000.

[NBS77] NBS. Data encryption standard, January 1977. Federal Information Processing Standards Publication 46.

[Rub02] A. D. Rubin. Security considerations for remote electronic voting. Communications of the ACM, 45(12):39–44, December 2002. http://avirubin.com/e-voting.security.html.

[Sch96] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley& Sons, New York, second edition, 1996.

[Sch00] B. Schneier. Secrets and Lies. John Wiley & Sons, New York, 2000.

T H E 

M AC H I N E RY O F D E M O C R AC Y:

PROT E C T I N G 

E L E C T I O N S 

I N 

A N

E L E C T RO N I C WO R L D

E X E C U T I V E S U M M A RYBRENNAN CENTER TASK FORCEON VOTING SYSTEM SECURITY,L AWRENCE NORDEN, CHAIRVOTING RIGHTS& ELECTIONS SERIESBRENNAN CENTERFOR JUSTICEAT NYU SCHOOL OF LAW 

ABOUT THE TASK FORCE

In 2005, the Brennan Center convened a Task Force of internationally renowned government, academic, and private-sector scientists, voting machine experts and security professionals to conduct the nation's first systematic analysis of security vulnerabilities in the three most commonly purchased electronic voting systems.

The Task Force spent more than a year conducting its analysis and drafting this report. During this time, the methodology, analysis, and text were extensively peer reviewed by the National Institute of Standards and Technology (“NIST”).

The members of the Task Force are:

Chair

Lawrence D. Norden, Brennan Center for Justice

Principal Investigator

Eric L. Lazarus, DecisionSmith.

Experts

Georgette Asherman, independent statistical consultant, founder of Direct Effects

Professor Matt Bishop, University of California at Davis Lillie Coney, Electronic Privacy Information Center

Professor David Dill, Stanford University

Jeremy Epstein, PhD, Cyber Defense Agency LLC

Harri Hursti, independent consultant, former CEO of F-Secure PLC

Dr. David Jefferson, Lawrence Livermore National Laboratory and Chair of the California Secretary of State’s Voting Systems Technology Assessment and Advisory Board

Professor Douglas W. Jones, University of Iowa

John Kelsey, PhD, NIST

Rene Peralta, PhD, NIST

Professor Ronald Rivest, MIT

Howard A. Schmidt, Former Chief Security Officer, Microsoft and eBay

Dr. Bruce Schneier, Counterpane Internet Security

Joshua Tauber, PhD, formerly of the Computer Science and Artificial Intelligence Laboratory at MIT

Professor David Wagner, University of California at Berkeley

Professor Dan Wallach, Rice University

Matthew Zimmerman, Electronic Frontier Foundation

ABOUT THE EDITOR AND TASK FORCE CHAIR

Lawrence Norden is an Associate Counsel with the Brennan Center, working in the areas of voting technology, voting rights, and government accountability. For the past year, Mr. Norden has led the Brennan Center’s voting technology assessment project. He is the lead author of The Machinery of Democracy: Voting System Security, Accessibility, Usability, Cost (Brennan Center forthcoming 2006) and a contributor to Routledge's forthcoming Encyclopedia of American Civil Liberties. Mr. Norden is a graduate of the University of Chicago and the NYU School of Law. Mr. Norden serves as an adjunct faculty member in the Lawyering Program at the Benjamin N. Cardozo School of Law. He may be reached at lawrence.norden@nyu.edu

ABOUT THE BRENNAN CENTER

The Brennan Center for Justice at NYU School of Law unites thinkers and advocates

In pursuit of a vision of inclusive and effective democracy. The organization’s mission is to develop and implement an innovative, nonpartisan agenda of scholarship, public education, and legal action that promotes equality and human dignity, while safeguarding fundamental freedoms. The Center works in the areas of Democracy, Poverty, Criminal Justice, and Liberty and National Security. Michael Waldman is the Center’s Executive Director.\

ABOUT THE VOTING RIGHTS & ELECTIONS SERIES

The Brennan Center’s Voting Rights & Elections Project promotes policies that protect rights to equal electoral access and political participation. The Project seeks to make it as simple and burden- free as possible for every eligible American to exercise the right to vote and to ensure that the vote of every qualified voter is recorded and counted accurately. In keeping with the Center’s mission, the Project offers public education resources for advocates, state and federal public officials, scholars, and journalists who are concerned about fair and open elections. For more information, please see www. brennancenter. org or call 212-998-6730. This paper is the second in a series, which also includes:

Making the List: Database Matching and Verification Processes for Voter Registration by Justin Levitt, Wendy Weiser and Ana Munoz.

Other resources on voting rights and elections, available on the Brennan Center’s website, include:

Response to the Report of the 2005 Commission on Federal Election Reform (2005) (coauthored with Professor Spencer Overton)

Recommendations for Improving Reliability of Direct Recording Electronic Voting Systems (2004) (co-authored with Leadership Conference on Civil Rights)

A C K N O W L E D G M E N T S

Most importantly, the Brennan Center thanks NIST and its many scientists for devoting so many hours to its extensive and thorough peer review of the analysis and report. The report, in its current form, would not exist without NIST’s many important comments and contributions.

In particular, we thank John Kelsey of NIST for the substantial material and ideas he provided, which have been incorporated into the report and the report’s attack catalogs. We also specially thank Rene Peralta for his original contributions and analysis. Finally, we are enormously grateful to Barbara Guttmann, John Wack and other scientists at NIST, who provided material for the attack catalogs, helped to develop the structure of the report, and edited many drafts.

We are also extremely appreciative of Principal Investigator Eric Lazarus’s enormous

Efforts on behalf of this report. His vision, tenacity, and infectious enthusiasm carried the team through a lengthy process of analysis and drafting. A special debt of gratitude is also owed to election officials throughout the country, who spent many hours responding to surveys and interview questions related to this report. In addition to team members Professor Ronald Rivest and Dr. David Jefferson, we particularly thank Patrick Gill, Woodbury County Auditor and Recorder and Past President of the Iowa State Association of County Auditors; Elaine Johnston, County Auditor, Asotin County, Washington; Harvard L. Lomax, Registrar of Voters for Clark County, Nevada; Debbie Smith, Elections Coordinator, Calaveras County, California; Jocelyn Whitney, Developer and Project Manager for parallel testing activities in the State of California;

Robert Williams, Chief Information Officer for Monmouth County, New Jersey; and Pam Woodside, former Chief Information Officer for the Maryland State Board of Elections. We would also like to acknowledge the National Committee for Voting Integrity for their cooperation and assistance in this effort.

Jeremy Creelan, Associate Attorney at Jenner & Block LLP, deserves credit for conceiving, launching. And supervising the Brennan Center’s voting technology assessment project, including development of this report, as Deputy Director of the Center’s Democracy Program through February 2005. The Program misses him greatly and wishes him well in private practice, where he continues to provide invaluable pro bono assistance.

The Brennan Center is grateful to Task Force member Lillie Coney, Associate Director of the Electronic Privacy Information Center. Among many other contributions, she provided invaluable assistance in assembling the Task Force, and frequently offered the Brennan Center sage strategic advice.

This report also benefited greatly from the insightful and thorough editorial assistance of Deborah Goldberg, Director of the Brennan Center’s Democracy Program. We are extremely grateful to Professor Henry Brady of the University of California at Berkeley and Professor Benjamin Highton of the University of California at Davis for their insights into the possible effects of denial of service attacks on voting systems. The Brennan Center also thanks Bonnie Blader, independent consultant, who provided the Task Force with crucial research, David M.Siegel, independent technology consultant, for his original contributions on the subject of software code inspections, and Tracey Lall, Ph.D. candidate in Computer Science at Rutgers University, who contributed many hours of critical security analysis. Douglas E. Dormer, CPA, CTP provided invaluable assistance

in developing the analysis methodology and in keeping the task force focused.

Joseph Lorenzo Hall also must be thanked for helping the Task Force members understand the diversity and commonality in voting system architectures. Much of the legal research was conducted by Gloria Garcia and Juan Martinez, J.D.

candidates at Benjamin N. Cardozo School of Law, and Annie Lai and S. Michael Oliver, J.D. candidates at NYU School of Law. Lowell Bruce McCulley, CSSP, was exceptionally helpful in creating the attack catalogs. Finally, we thank Brennan Center Research Associates Annie Chen, Lauren Jones, Ana Munoz, and Neema Trivedi for their many hours of dedicated assistance. Generous grants from an anonymous donor, the Carnegie Corporation of New York, the Ford Foundation, the HKH Foundation, the Knight Foundation, the Open Society Institute, and the Rockefeller Family Foundation supported the development and publication of this report. The statements made and views

Expressed in this report is the responsibility solely of the Brennan Center.

C O N T E N T S

T E X T

Introduction                                                                                                                 1

Voting System Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          4

Security Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                        13

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                        19

Endnotes                                                                                                                     20

F I G U R E S

Figure 1. Voting Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       . 1

Figure 2. Election for Governor, State of Pennasota, 2007 . . . . . . . . . . . . . .            . 6

Figure 3. Software Attack Program: Points of Entry . . . . . . . . . . . . . .                      . 9

Figure 4. Possible Attack on DRE with VVPT . . . . . . . . . . . . . . . . . . . . . . .            11

I N T RO D U C T I O N

In these pages, the Brennan Center for Justice at NYU School of Law (the “Brennan Center”) summarizes the nation’s first systematic analysis of security vulnerabilities in the three most commonly purchased electronic voting systems. To develop the analysis, the Brennan Center convened a Task Force of internationally renowned government, academic, and private-sector scientists, voting machine experts, and security professionals. The Task Force examined security threats to the technologies used in Direct

Recording Electronic voting systems (“DREs”), DREs with a voter verified auditable paper trail (“DREs w/ VVPT”) and Precinct Count Optical Scan (“PCOS”) systems. The analysis assumes that appropriate physical security and accounting procedures are in place.

Direct

Recording

Electronic

(DRE)

DRE

with Voter Verified

Paper Trail

(DRE w/ VVPT)

Precinct Count

Optical Scan

(PCOS)

A DRE machine directly records the voter’s selections in each contest, using a ballot that

appears on a display screen. Typical DRE machines have flat panel display screens withtouch-screen input, although other display technologies have been used. The defining characteristic of these machines is that votes are captured and stored electronically. A DRE w/ VVPT captures a voter’s choice both internally in electronic form, and contemporaneously on paper. A DRE w/ VVPT allows the voter to confirm the accuracy of the paper record to provide voter-verification. PCOS voting machines allows voters to mark paper ballots, typically with pencils or pens, independent of any machine. Voters then carry their sleeved ballots to a scanner. At the scanner, they un-sleeve the ballot and insert into the scanner, which optically records the vote.

Microvote Infinity Voting Panel

Hart InterCivic eSlate Sequoia AVC Edge

Sequoia AVC Advantage

ES&S iVotronic

ES&S iVotronic LS

Diebold AccuVote-TS

Diebold AccuVote-TSX

Unilect Patriot

ES&S iVotronic system with Real Time Audit Log

Diebold AccuVote-TSX with AccuView printer

Sequoia AVC Edge with VeriVote printer

Hart InterCivic eSlate with VVPAT

Unilect Patriot with VVPAT

Diebold AccuVote-OS

ES&S Model 100

Sequoia Optech Insight

FIGURE 1

VOTING SYSTEMS

Type of Voting System Description of Voting System Examples of Voting System

1 The full report (the “Security Report”), which has been extensively peer reviewed

By the National Institute of Standards and Technology (“NIST”), may be found

At www.brennancenter.org. Following the analysis outlined here, the Brennan

Center and Task Force members recommend countermeasures that should be

Taken to reduce the technological vulnerability of each voting system.1

CORE FINDINGS

Three fundamental points emerge from the three at analysis in the Security Report:

■ All three voting systems have significant security and reliability vulnerabilities,

Which pose a real danger to the integrity of national, state, and local elections?

■ The most troubling vulnerabilities of each system can be substantially remedied

If proper countermeasures are implemented at the state and local level.

■ Few jurisdictions have implemented any of the key countermeasures that

Could make the least difficult attacks against voting systems much more difficult

to execute successfully.

VOTING SYSTEM VULNERABILITIES

After a review of more than 120 potential threats to voting systems, the Task

Force reached the following crucial conclusions:

For all three types of voting systems:

■ When the goal is to change the outcome of a close statewide election, attacks

that involves the insertion of software attack programs or other corrupt software

are the least difficult attacks.

■ Voting machines that have wireless components are significantly more vulnerable

to a wide array of attacks. Currently, only two states, New York and

Minnesota, ban wireless components on all voting machines.

For DREs without voter verified paper trails:

■ DREs without voter verified paper trails do not have available to them a powerful

Countermeasure to software attacks: post-election automatic routine

Audits that compare paper records to electronic records.

For DREs w/ VVPT and PCOS:

■ The voter verified paper record, by itself, is of questionable security value. The

paper record has significant value only if an automatic routine audit is performed

(and well designed chain of custody and physical security procedures

are followed). Of the 26 states that mandate voter verified paper records,

only 12 require regular audits.

2 THE MACHINERY OF DEMOCRACY: PROTECTING ELECTIONS IN AN ELECTRONIC WORLD

■ Even if jurisdictions routinely conduct audits of voter verified paper records,

DREs w/ VVPT and PCOS are vulnerable to certain software attacks or

Errors. Jurisdictions that conduct audits of paper records should be aware of

these potential problems.

SECURITY RECOMMENDAT I O N S

There are a number of steps that jurisdictions can take to address the vulnerabilities

Identified in the Security Report and make their voting systems significantly

more secure. We recommend adoption of the following security measures:

1. Conduct automatic routine audits comparing voter verified paper records to

The electronic record following every election. A voter verified paper record

Accompanied by a solid automatic routine audit of those records can go a

Long way toward making the least difficult attacks much more difficult.

2. Perform “parallel testing” (selection of voting machines at random and testing

Them as realistically as possible on Election Day.) For paperless DREs, in

particular, parallel testing will help jurisdictions detect software-based attacks,

as well as subtle software bugs that may not be discovered during inspection

and other testing.

3. Ban use of voting machines with wireless components. All three voting systems

are more vulnerable to attack if they have wireless components.

4. Use a transparent and random selection process for all auditing procedures.

For any auditing to be effective (and to ensure that the public is confident in

such procedures), jurisdictions must develop and implement transparent and

random selection procedures.

5. E n s u re decentralized programming and voting system administration.

Where a single entity, such as a vendor or state or national consultant, performs

Key tasks for multiple jurisdictions, attacks against statewide elections

Become easier.

6. Institute clear and effective procedures for addressing evidence of fraud or

Error. Both automatic routine audits and parallel testing are of questionable

Security value without effective procedures for action where evidence of

Machine malfunction and/or fraud are discovered. Detection of fraud without

An appropriate response will not prevent attacks from succeeding.

Fortunately, these steps are not particularly complicated or cumbersome. For the

Most part, they do not involve significant changes in system architecture.

Unfortunately, few jurisdictions have implemented any of these security recommendations.

■ W H AT IS A THREAT ANALYSIS AND WHY IS IT NECESSARY?

In the last several years, few issues in the world of voting systems have garnered as much public attention as voting system security. This attention to voting system security has the potential to be a positive force. Unfortunately, too much of the public discussion surrounding security has been marred by claims and counter- claims that are based on little more than speculation or anecdote. In response to this uninformed discussion, and with the intention of assisting election officials and the public as they make decisions about their voting machines, the Task Force undertook a methodical analysis of potential threats to voting systems.

The threat analysis provides election officials and concerned citizens with quantifiable criteria for measuring the level of security offered by voting systems and potential safety measures. It should assist jurisdictions in deciding (a) which voting systems to certify or purchase, and (b) how to protect those systems from security threats after they have been purchased. The Security Report sets forth the detailed results of that analysis, which are summarized here.

S Y S T E M ATIC THREAT ANALYSES

OF VOTING SYSTEMS ARE LONG OVERDUE.

Most Americans would agree that the integrity of our elections is fundamental to our democracy. We want citizens to have full confidence that their votes will be accurately recorded. Given the current tenor of debate over voting system security, this is reason enough to conduct regular systematic threat analyses of voting systems. Just as importantly, such analyses, if utilized in developing voting system standards and procedures, should reduce the risk of attacks on voting systems. As a nation, we have not always successfully avoided such attacks – in fact, various types of attacks on voting systems and elections have a “long tradition” in American history.2 the suspicion or discovery of such attacks has generally provoked momentary outrage, followed by periods of historical amnesia.

All technology, no matter how advanced, is going to be vulnerable to attack to some degree. The history of attacks on voting systems teaches us how foolish it would be to assume that there will not be attacks on voting systems in the future. But we can educate ourselves about the vulnerabilities and take the proper precautions to ensure that the easiest attacks, with the potential to affect the most votes, are made as difficult as possible. Good threat analyses allow us to identify and implement the best security precautions

There is an additional benefit to this kind of analysis: it should help make our voting systems more reliable, regardless of whether they are ever attacked. Computerized voting systems – like all previous voting systems – have shown themselves vulnerable to error. As detailed in the Security Report, votes have been miscounted or lost as a result of defective firmware (coded instructions in a computer system’s hardware), faulty machine software, defective tally server software, election programming errors, machine breakdowns, malfunctioning input devices, and poll worker error.

“An old maxim in the area of computer security is clearly applicable here: Almost everything that a malicious attacker could attempt could also happen by accident; for every malicious attacker, there may be thousands of people making ordinary careless errors.”4 Solid threat analyses should help to expose and to address vulnerabilities in voting systems, including not only security breaches but also simple malfunctions.

■ W H AT METHODOLOGY WAS USED FOR THE THREAT ANALY S I S?

In developing the study of voting system security vulnerabilities, the Brennan Center brought together some of the nation’s leading election officials, as well as a Task Force of internationally recognized experts in the fields of computer science, election policy, security, voting systems, and statistics. After considering several approaches to measuring the strength of election security, this group unanimously selected a model that: (a) identified and categorized the potential threats against voting systems, (b) prioritized these threats based upon an agreed-upon metric (which would identify how “difficult” each threat is to accomplish from the attacker’s point of view), and (c) determined (utilizing the same metric employed to prioritize threats) how much more difficult each of the catalogued attacks would become after various sets of countermeasures were implemented.

After several months of work, including a public threat analysis workshop hosted by the National Institute of Standards and Technology, the Task Force identified and categorized more than 120 threats to the three voting systems. The threats generally fell into one or more of nine broad categories: (1) the insertion of corrupt software into machines prior to Election Day; (2) wireless and other remote attacks on voting machines on Election Day; (3) attacks on tally servers; (4) miscalibration of voting machines; (5) shut-off of voting machine features intended to assist voters; (6) denial of service attacks; (7) actions by corrupt poll workers or others at the polling place to affect votes cast; (8) vote buying schemes; and (9) attacks on ballots or voter verified paper trails. The Task Force determined that the best single metric for determining the “dif-

Almost everything that a malicious attacker could attempt could also happen by accident.

ficulty” of each of these attacks was the number of informed participants necessary to execute the attack successfully. An “informed participant” is someone whose participation is needed to make the attack work, and who knows enough about the attack to foil or expose it.

For each attack, Task Force members looked at how many informed participants would be necessary to change the outcome of a reasonably close statewide election in which all votes were cast on one of the three voting systems analyzed. The statewide election we looked at was a fictional gubernatorial race between Tom Jefferson and Johnny Adams in a composite jurisdiction, Pennasota. Pennasota was created by aggregating the results of the 2004 presidential election in 10 “battleground” states, as determined by Zogby International polls in the spring, summer, and fall of 2004.

■ W H AT WERE THE GREATEST RISKS REVEALED BY THE THREAT ANALY S I S?

Below is a discussion of the most troubling threats identified in the Security

■■ THE LEAST DIFFICULT AT TACKS USES SOFTWARE AT TACK PROGRAMS.

                                                                 

The “least difficult” attacks against all three systems (as measured by the metric of number of informed participant’s necessary to change the outcome of a statewide election) involve the insertion of corrupt software or other software attack programs in order to take over a voting machine. Significantly, the threat Analysis suggests that all three voting systems are equally vulnerable to software Attacks.

The most basic type of software attack program would target voting machines and switch a certain number of votes from one candidate to another. This alteration of votes could occur at any time on Election Day, as long as it was completed before poll workers printed a paper record of the vote total and extracted the electronic record of votes from the machines. Inserting a software attack program into a voting system for the purpose of affecting an election’s outcome is likely to be technically and financially challenging,

Particularly if the attacker wants to avoid detection. However, a substantial historical

Record of this type of attack against non-voting systems suggests that it can be successfully executed. The Security Report details several ways that an attacker could insert a software attack program without detection.

Specifically, there are several points in the development and use of voting Machine software where software attack programs could be inserted without Detection. Among these points, software attack programs could be inserted Through the “firmware” that is hard-wired into voting machines, during the generation Of “commercial off-the-shelf” (“COTS”) or vendor software used on voting Machines, through software patches and updates meant to improve the performance And capabilities of voting machines, during the creation of configuration Files and election definitions used to interpret voter choice and totals on voting Machines, through network communications between voting machines and Outside sources, as well as through “input/output” devices such as memory cards And printers. There are many hurdles an attacker would have to overcome to ensure that the Insertion of such an attack program changed enough votes to affect the outcome

Significantly, the threat analysis suggests that all three voting Systems are equally vulnerable to software attacks. Firmware is software that is embedded in the voting machine. After careful analysis, the Task Force determined that none of these hurdles is insurmountable. The full Security Report discusses in detail how an attacker could prevail over the following challenges: efforts of vendors to prevent such an attack from occurring (pp. 32–33); gaining sufficient technical knowledge about the way a voting machine and its software works (pp. 36–37); gaining sufficient knowledge about the targeted election (pp. 37–38); creating an attack program that has the ability to change, add, or subtract votes (pp. 39–40); eluding independent testing authority (“ITA”) inspections (pp. 42–45); avoiding detection during machine testing (pp. 44–45); and avoiding detection through records kept on event and audit logs (pp. 45–46).

■■ WIRELESS COMPONENTS CREATE UNNECESSARY RISKS.

The threat analysis shows that machines with wireless components are particularly vulnerable to software attack programs and other attacks. The Security Report concludes that this danger applies to all three voting systems examined. Vendors continue to manufacture and sell machines with wireless components. Among the many types of attacks made possible by wireless components are attacks that exploit an unplanned vulnerability in the software or hardware to get a Trojan horse into the machine. For this type of attack, a Trojan horse would not have to be inserted in advance of Election Day. Instead, an attacker aware of vulnerability in the voting system’s software or firmware could simply show up at the polling station and beam her Trojan horse into the machine using a wireless enabled personal digital assistant.

Thus, virtually any member of the public with some knowledge of software and a personal digital assistant could perform this attack. This is particularly troubling when one considers that most voting machines run on COTS software and/or operating systems; the vulnerabilities of such software and systems are frequently well known.5 against all three systems, attackers could use wireless components to subvert all testing. Specifically, an attack program could be written to remain dormant until it received particular commands via a wireless communication.

This would allow attackers to wait until a machine was being used to record votes on Election Day before turning on the software attack. Attackers could also use wireless communications to gain fine-grained control over an attack program already inserted into a particular set of machines (i.e., switch three votes in the second race on the third machine), or obtain information as to how individuals had voted by communicating with a machine while it was being used.

Finally, wireless networking presents additional security vulnerabilities for jurisdictions

using DREs w/ VVPT and PCOS. A major logistical problem for an attacker changing both electronic and paper records is how to get the new paper records printed in time to substitute them for the old record in transit.

A “Trojan horse” is a type of software attack program that “impersonates” benign ogram.Personal digital assistants (“PDAs”or palmtops) are handheld devices that were originally designed as personal organizers.PDAs can synchronize data with a personal computer. Less networking, the DRE or PCOS can transmit specific information out to the

Attacker about what should appear on those printed records. In short, permitting wireless components on DRE w/ VVPT or PCOS machines makes the attacker’s Job much simpler in practice.

A cryptic knock is an action taken by a user of the machine that will trigger (or silence) the attack behavior. The cryptic knock could come in many forms, depending upon the attack program: voting for a write-in candidate, tapping a specific spot on the machines

Screen, a communication via wireless network, etc.

■■ SYSTEMS WITH PAPER RECORDS ARE STILL SUBJECT TO ATTACK.

Voting systems with some kind of voter verified paper record (i.e., DRE w/VVPT or PCOS) offer an important security advantage against software attack programs Not offered by voting systems without voter verified paper records (i.e. DREs without VVPT): jurisdictions can conduct an audit of the voter verified Paper record and compare that record to the electronic vote totals. Unfortunately, most states that require voter verified paper records do not require Automatic audits of paper records after each election. Our analysis shows that sys -Items with voter verified paper records provide little, if any, security benefit over systems without such records, unless there are regular audits and/or recounts of the paper records. Even assuming that such regular audits and/or recounts are conducted, jurisdictions that use, or are considering purchasing DREs w/ VVPT or PCOS should be aware of threats that are unique to these systems.

■■■ AT TACKS ON DRE W/VVPT

At least one study has suggested that an extremely low percentage of voters who use DREs w/ VVPT review the paper trail. If those findings are correct, an attacker could subvert a recount or audit by creating an attack program that directs the machine to record the wrong vote on both the electronic and paper records. If both records are similarly inaccurate, checking one against the other in an audit or recount will not expose an attack. In practice, this is how it would work in the Governor’s race in Pennasota:

■ when a targeted voter chooses Tom Jefferson, the screen would indicate that she has voted for Tom Jefferson.

■ After she has completed voting in all other races, the DRE would print a Paper record that lists her choices for every race, except for governor. Under The governor’s race, it would state that she has selected Johnny Adams.

■ When the DRE screen asks the voter to confirm that the paper has recorded her vote correctly, one of two things would happen:

■ the voter would fail to notice that the paper has misreported the vote and Accept the paper recording; or

■ the voter would reject the paper record and opt to vote again.

■ if the voter rejects the paper record, the second time around it would show that she voted for Tom Jefferson. This might lead her to believe she had accidentally pressed the wrong candidate the first time. In any event, it would render her less likely to tell anyone that the machine made a mistake. We can imagine the attack visually this way: This attack would not require any additional participants in the conspiracy. Nor, as demonstrated in the Security Report, is it entirely clear that enough voters would notice the misrecorded votes to prevent the attack from working.

The Security Report details countermeasures that should allow jurisdictions to catch this attack. Specifically, even if only a small percentage of voters notice that a machine has misrecorded their vote, there should be an unusually large number of “cancellations” on the paper trail. A jurisdiction that recorded and then reviewed the number of cancellations during a 2% audit would find enough evidence of problems to identify a problem and understand that further investigation was warranted.

Of course, encouraging voters to review the paper records could also substantially reduce the risk of a successful attack on the paper trail.

■ AT TACKS ON PCOS

One of the benefits of PCOS machines over Central Count Optical Scanners (which are very often used in tallying absentee ballots) is that they have an “over/under vote protection.” The over/undervote protection on PCOS scan-ners works as follows: when a voter fills out his ballot, but accidentally fills in two candidates for the same race (overvotes) or accidentally skips a race (under votes), the scanner would refuse to record the vote and send it back to the voter for examination. The voter then has the opportunity to review the ballot and correct it before resubmitting.

Central Count Optical Scanners have been shown to lose far more votes than PCOS. In precincts with over 30% African American voters, for example, the lost or “residual” vote rate for Central Count Optical Scanners has been shown to be as high as 4.1% as compared with 0.9% for PCOS.7 the lack of over/undervote protection on Central Count Optical Scanners may be the reason for this difference.

Our attacker in Pennasota would probably not be able to swing the gubernatorial race from Jefferson to Adams merely by inserting an attack program that would turn off the over/undervote protection on PCOS scanners. Even if we assume that the result of turning off the protection was a loss of 4% of the votes on every scanner, and that all of those votes would have gone to Tom Jefferson, this would result in the loss of only about 20,000 votes. This would still leave Jefferson (who won by about 80,000 votes) with a comfortable (though slimmer) margin of victory.

Nevertheless, this attack could cause the loss of thousands of votes. There are at least three possible ways to catch this attack:

■ Parallel testing (assuming that the attack program has not also figured out a way to shut off when it is being tested);

■ Periodic testing of the ove r / u n d e rvote protection on Election Day ;

■ Counting over/undervotes during an audit of the voter verified paper record to determine whether there are a disproportionate number of such lost votes.

S E C U R I T Y R E C O M M E N DAT I O N S

There is a substantial likelihood that the election procedures and counter measures currently in place in the vast majority of states would not detect a cleverly Designed software attack program. The regimens for parallel testing and automatic routine audits proposed in the Security Report are important tools for defending voting systems from many types of attack, including software attack programs.

Most jurisdictions have not implemented these security measures. Of the 26 states that require a voter verified paper record, only 12 states require automatic audits of those records after every election, and only two of these states – California and Washington – conduct parallel testing. Moreover, even those states that have implemented these countermeasures have not developed the best practices and protocols that are necessary to ensure their effectiveness in preventing or revealing attacks or failures in the voting systems.

R E C O M M E N D ATION #1:

■ CONDUCT AUTOMATIC ROUTINE AUDIT OF PAPER RECORDS.

Advocates for voter verified paper records have been extremely successful in State legislatures across the country. Currently, 26 states require their voting systems to produce a voter verified record, but 14 of these states do not require Automatic routine audits. The Task force has concluded that an independent Voter verified paper trail without an automatic routine audit is of questionable Security value.

By contrast, a voter verified paper record accompanied by a solid automatic routine Audit can go a long way toward making the least difficult attacks much more Difficult. Specifically, the measures recommended below should force an attacker to involve hundreds of more informed participants in her attack.

■ A small percentage of all voting machines and their voter verified paper Records should be audited.

■ Machines to be audited should be selected in a random and transparent way.

■ The assignment of auditors to voting machines should occur immediately before the audits. The audits should take place by 9 a.m., the day after polls close.

■ The audit should include a tally of spoiled ballots (in the case of VVPT Cancellations), over votes, and under votes.

There is a substantial likelihood that the election procedures and countermeasures currently in place in the vast majority of states would not detect cleverly designed software

attack program.

■ a statistical examination of anomalies, such as higher than expected cancellations or under votes and overvotes, should be conducted.

■ Solid practices with respect to chain of custody and physical security of paper records prior to the automatic routine audit should be followed.

R E C O M E N D ATION #2:

■ CONDUCT PARALLEL TESTING.

It is not possible to conduct an audit of paper records of DREs without VVPT,

because no voter verified paper record exists on such machines. This means that Jurisdictions that use DREs without VVPT do not have access to an important and powerful countermeasure. For paperless DRE voting machines, parallel testing is probably the best way to detect most software-based attacks, as well as subtle software bugs that may not be discovered during inspection and other testing. For DREs w/ VVPT and ballot-marking devices, parallel testing provides the opportunity to discover a specific kind of attack (for instance, printing the wrong choice on the voter verified paper record) that may not be detected by simply reviewing the paper record after the election is over. However, even under the best of circumstances, parallel testing is an imperfect security measure. The testing creates an “arms-race” between the testers and the attacker, but the race is one in which the testers can never be certain that they have prevailed.

           

We have concluded that the following steps will lead to more effective parallel testing:

■ The precise techniques used for parallel testing (e.g., exactly how and when the machine is activated, how activation codes/smart cards/etc. are produced to allow voting, etc.) should not be fully determined or revealed until right before the election. Details of how parallel testing is done should change from election to election.

■ At least two of each type of DRE (meaning both vendor and model) should be selected for parallel testing.

■ At least two DREs from each of the three largest counties should be parallel tested.

■ Localities should be notified as late as possible that machines from their precincts will be selected for parallel testing.

■ Wireless channels for voting machines should be closed off, to ensure they cannot receive commands.

Typically, a ballot-marking device is an accessible computer-based voting system that produces a marked ballot. The ballot is marked as the result of voter interaction with visual or audio prompts. Some jurisdictions use ballot-marking devices instead of accessible DREs.

■ Voting machines should never be connected to one another during voting. Some DREs and DREs w/VVPT may be designed so that they cannot function unless they are connected to one another. Election officials should discuss this question with voting system vendors.

■ Voting machines should be completely isolated during the election, and print out or otherwise display their totals before being connected to any central server to send in its tallies.

■ Parallel testing scripts should include details, such as how quickly or slowly to vote, when to make “errors,” and perhaps even when to cast each vote.

■ Parallel testing should be videotaped to ensure that a contradiction between paper and electronic records when parallel testing is complete is not the result of tester error.

While a few local jurisdictions have taken it upon themselves to conduct limited parallel testing, we are aware of only three states, California, Maryland and Washington that have regularly performed parallel testing on a statewide basis. It is worth noting that two of these states, California and Washington, employ Automatic routine audits and parallel testing as statewide countermeasures against Potential attack.

R E C O M M E N D ATION #3:

■ BAN WIRELESS COMPONENTS ON ALL VOTING MACHINES.

Our analysis shows that machines with wireless components are particularly Vulnerable to attack. We conclude that this vulnerability applies to all three voting systems. Only two states, New York and Minnesota, ban wireless components on all machines.11 California also bans wireless components, but only for DRE machines. Wireless components should not be permitted on any voting machine.

R E C O M M E N D ATION #4:

■ MANDATE TRANSPARENT AND RANDOM SELECTION PROCEDURES.

The development of transparently random selection procedures for all auditing procedures is key to audit effectiveness. This includes the selection of machines to be parallel tested or audited, as well as the assignment of auditors themselves. The use of a transparent and random selection process allows the public to know that the auditing method was fair and substantially likely to catch fraud or mistakes in the vote totals. In our interviews with election officials we found that, all too often, the process for picking machines and auditors was neither transparent nor random.

In a transparent random selection process:

■ The whole process is publicly observable or videotaped.

■ The random selection is be publicly verifiable, i.e., anyone observing is able to verify that the sample was chosen randomly (or at least that the number selected is not under the control of any small number of people).

■ The process is simple and practical within the context of current election practice so as to avoid imposing unnecessary burden on election officials.

R E C O M M E N D ATION #5:

■ ENSURE DECENTRALIZED PROGRAMMING AND VOTING SYSTEM ADMINISTRATION.

Where a single entity, such as a vendor or state or national consultant, runs elections or performs key tasks (such as producing ballot definition files) for multiple jurisdictions, attacks against statewide elections become easier. Unnecessary centralized control provides many opportunities to implement attacks at multiple locations.

R E C O M M E N D ATION #6:

■ IMPLEMENT EFFECTIVE PROCEDURES FOR ADDRESSING EVIDENCE OF FRAUD OR ERROR.

Both automatic routine audits and parallel testing are of questionable security value without effective procedures for action where evidence of machine malfunction and/or fraud is uncovered. Detection of fraud without an appropriate response will not prevent attacks from succeeding. In the Brennan Center’s extensive review of state election laws and practices, and in its interviews with election officials for the threat analysis, we did not find any jurisdiction with publicly detailed, adequate, and practical procedures for dealing with evidence of fraud or error discovered during an audit, recount, or parallel testing. The following are examples of procedures that would allow jurisdictions to respond effectively to detection of bugs or software attack programs in parallel testing:

■ Impound and conduct a transparent forensic examination of all machines showing unexplained discrepancies during parallel testing.

■ Where evidence of a software bug or attack program is subsequently found (or no credible explanation for the discrepancy is discovered), conduct a forensic examination of all DREs used in the state during the election. Where a single entity, such as a vendor or state or national consultant, runs elections or performs key tasks for multiple jurisdictions, attacks against statewide elections become easier.

■ Identify the machines that show evidence of tampering or a software flaw that could have affected the electronic tally of votes.

■ Review the reported margin of victory in each potentially affected race. Based upon the (a) margin of victory, (b) number of machines affected, and (c) nature and scope of the tampering or flaw; determine whether there is a substantial likelihood that the tampering or flaw changed the outcome of a particular race.

■ Where there is a substantial likelihood that tampering changed the outcome of a particular race, hold a new election for the office. The following is an illustrative set of procedures that would allow jurisdictions to respond effectively to discrepancies between paper and electronic records during an automatic routine audit:

■ Conduct a transparent investigation of all machines where the paper and electronic records do not match to determine whether there is any evidence that tampering with the paper records has occurred.

■ To the extent that there is no record that the paper records have been tampered with, certify the paper records.

■ If there is evidence that the paper records have been tampered with, give a presumption of authority to the electronic records.

■ After giving a presumption of authority to the electronic records, conduct a forensic investigation on all machines where the paper and electronic records do not match, to determine whether there has been any tampering with the electronic records.

■ If tampering with the electronic records can be ruled out, certify the electronic records.

■ Where there is evidence that both sets of records have been tampered with, conduct a full recount to determine whether and to what extent paper and electronic records cannot be reconciled.

■ At the conclusion of the full recount, determine the total number of machines that report different electronic and paper records.

■ After quantifying the number of machines that have been tampered with, determine the margin of victory in each potentially affected race.

■ Based upon (a) the margin of victory, (b) the number of machines affected, and (c) the nature and scope of the tampering, determine whether there is a substantial likelihood that tampering changed the outcome of a particular race.

■ In the event that a determination is made that there is a substantial likelihood

that tampering changed the outcome of a particular race, hold a new election

for the office.

C O N C LU S I O N

The Task Force has found that the three voting systems most commonly purchased today are vulnerable to attacks and errors that could change the outcome of statewide elections. This finding should surprise no one. A review of the history of both election fraud and voting systems literature in the United States shows that voting systems have always been vulnerable to attack. Indeed, it is impossible to imagine a voting system that could be impervious to attack.

But there are straightforward countermeasures that that will substantially reduce the most serious security risks presented by the three systems. The Task Force’s recommendations point the way for jurisdictions with the political will to protect their voting systems from attack. None of the measures identified here – auditing voter verified paper records, banning wireless components, using transparent and random selection processes for auditing, adopting effective policies for addressing evidence of fraud or error in vote totals, conducting parallel testing – are particularly difficult or expensive to implement. The Brennan Center urges election officials and policy makers to adopt the recommended

security measures as soon as possible.

Adam Winkler

Professor, UCLA School of Law

Paul Lightfoot, Treasurer

President & CEO,

AL Systems, Inc.

BRENNAN CENTER FOR JUSTICE

BOARD OF DIRECTORS AND OFFICERS

BRENNAN CENTER

FOR JUSTICE

AT NYU SCHOOL OF LAW

161 Avenue of the Americas

12th Floor

New York, NY 10013

212-998-6730

www.brennancenter.org

BRENNAN CENTER

FOR JUSTICE

AT NYU SCHOOL OF LAW

161 Avenue of the Americas

12th Floor

New York, NY 10013

212-998-6730

www.brennancenter.org

OUR CONCLUDING REMARKS WITH INVITATION TO THE DEPUTY ELECTION COMMISSIONER Mr.BALAKRISHNAN.

This compiled note on happenings around the world is just sent to draw the attention of Election commission of India to keep its machinery updated to changing needs of times. We in Tamilnadu have kept the JJ virus that tried to hack our democracy out of reach. So personally this writer nurses no grudge over the conduct of the poll.

But Tamil scholars are seeing ghosts behind e-voting machines; hence we brought to your notice the developments in other countries. We also bring to your attention the research that is mid-way where our Tamil Scholar-cum-Scientist Mr.Era.Sembian is designing some new invention for fool proof elections.

We know about you from your Professor Mr.Vijayavenugopal and Orissa Mr.Balasubramani. We invite you to visit the Tamil Heritage Village site where Mr.Sembian is planning, and we wait for your suggestions in creating a visual of past live before our eyes.

With Regards

Yours fraternally

N.Nandhivarman

General Secretary Dravida Peravai

Puducherry 605001.