designing a new electronic voting system - unibo.itdeisnet.deis.unibo.it/nsl/thesis.pdf · 4.3...

ALMA MATER STUDIORUM - UNIVERSITY OF BOLOGNASEDE DI CESENA

SECONDA FACOLTÀ DI INGEGNERIA CON SEDE A CESENACORSO DI LAUREA SPECIALISTICA IN INGEGNERIA

INFORMATICA

Designing A New Electronic Voting System

Thesis : Security System

Supervisor (University of Bologna): Author:

Prof. Franco Callegati Marco Ramilli

Supervisor (University of California Davis):

Prof. Matt Bishop

Session III

Academic Year 2006-2007

ii

Copyright c© 2008

Marco Ramilli ([email protected])

Permission is granted to copy, distribute, and/or modify this docu-ment under the terms of the GNU Free Documentation License, version1.2 or any later version published by the Free Software Foundation, withno Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. Acopy of the license is included in the appendix entitled GNU Free Docu-mentation License.

Keywords

Security, Security Engineering, Security Models

Electronic Voting System, EVote, US - Elections

Vulnerability, Assessment and Penetration Testing

Learning is one experience: all the other is only

information

‘Albert Einstain & Marco Ramilli ‘

Here My Main Sponsors.

University of Bologna. Special Thank for Fellowship 2007.

University of California Davis. Special Thank for giving me access to Se-curity Labs.

National Science Foundation. Special Thank to Alicia Clay Jones, whohas worked very hard during these months.

Contents

1 The Voting Paradigms 11.1 Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 The Standard 72.1 Voting Machines. . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 De-Facto Standard: VVSG. . . . . . . . . . . . . . . . . . . . . 122.3 Known Attacks. . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 Diebold Voting Machine: Discovered Vulnerabilities 222.3.2 Hart Voting Machine: Discovered Vulnerabilities . . 26

3 Proposed Solution 313.1 Glue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Coordinator Examples. . . . . . . . . . . . . . . . . . . . . . . 333.3 Proposed Architecture. . . . . . . . . . . . . . . . . . . . . . . 343.4 Voting Machine Layer. . . . . . . . . . . . . . . . . . . . . . . 353.5 Glue and Gate Layer. . . . . . . . . . . . . . . . . . . . . . . . 383.6 Central Server Layer. . . . . . . . . . . . . . . . . . . . . . . . 40

4 Security of Proposed Architecture. 454.1 Compromised Boot Loader or Compromised OS. . . . . . . . 474.2 Malware and Hardware Installation. . . . . . . . . . . . . . . 484.3 Denial of Services Attacks and Attacks on Tally Servers. . . . 494.4 Smart Card Reverse Engineering. . . . . . . . . . . . . . . . . 494.5 Calibration Machine Attacks. . . . . . . . . . . . . . . . . . . 504.6 How to Correct Wrong Behavior Detected. . . . . . . . . . . 50

5 Conclusion 53

x CONTENTS

A The Ballot File. 55A.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

B Printer Barcodes 59B.1 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

C Automated Input. 63C.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

GNU Free Documentation License 671. APPLICABILITY AND DEFINITIONS . . . . . . . . . . . . . . 682. VERBATIM COPYING . . . . . . . . . . . . . . . . . . . . . . . . 703. COPYING IN QUANTITY . . . . . . . . . . . . . . . . . . . . . 704. MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 715. COMBINING DOCUMENTS . . . . . . . . . . . . . . . . . . . . 736. COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . 747. AGGREGATION WITH INDEPENDENT WORKS . . . . . . . 748. TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . 759. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . 7510. FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . . 76ADDENDUM: How to use this License for your documents . . . 76

Thank You Folks ! 83

List of Figures

1.1 Voting System era . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Punch Card Machine, developed in 1960. . . . . . . . . . . . 9

2.2 Optical Scan Machine. . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Electronic Voting Machine With Electronic Input Device asa pen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Direct Recording Electronic Machine with VVPAT securitymechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Direct Recording, early 1900s. . . . . . . . . . . . . . . . . . . 11

2.6 Direct Recording Electronic Voting System. . . . . . . . . . . 12

2.7 Direct Recording Electronic Voting System, voting phase. . . 12

2.8 Administer Elections. . . . . . . . . . . . . . . . . . . . . . . . 13

2.9 Prepare For Election . . . . . . . . . . . . . . . . . . . . . . . 15

2.10 Gather in-person vote (paper-based). . . . . . . . . . . . . . . 16

2.11 Gather in-person vote (DRE). . . . . . . . . . . . . . . . . . . 17

2.12 Wrap up voting (precinct). . . . . . . . . . . . . . . . . . . . . 18

2.13 Wrap up voting (central). . . . . . . . . . . . . . . . . . . . . . 19

2.14 Red Team Information Flow Map. . . . . . . . . . . . . . . . 21

2.15 Hart Voting Machine. . . . . . . . . . . . . . . . . . . . . . . . 22

2.16 Hart Voting Machine. . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Glue Meta Architecture. . . . . . . . . . . . . . . . . . . . . . 32

3.2 Glue Architecture on Voting Problem. . . . . . . . . . . . . . 35

3.3 Voting Machine Architecture. . . . . . . . . . . . . . . . . . . 36

3.4 Voting Machine Activity Diagram. . . . . . . . . . . . . . . . 38

3.5 Relationship between main voting program and behavior . . 39

xii LIST OF FIGURES

3.6 Glue Activity Diagram. . . . . . . . . . . . . . . . . . . . . . . 413.7 Central Server Activity Diagram. . . . . . . . . . . . . . . . . 42

4.1 Deduction Process. . . . . . . . . . . . . . . . . . . . . . . . . 464.2 Voting Machine Connection. . . . . . . . . . . . . . . . . . . . 48

Chapter 1

The Voting Paradigms

"I believe that voting is the first act of building a community aswell as building a country. "

John Ensign

In a republic, the electorate expresses its will through the election ofrepresentatives. These representatives run the country, on behalf of thebody politic. In order that the representatives represent the wishes of thepeople, the elections in which they are selected must be run fairly andresults computed accurately.

Electronic voting systems carry the promise of improving three aspectsof elections:

1. Speed. Hand-counting votes can be time-consuming, especially incountries like the United States and Italy (Marco – is this right?) inwhich voters cast votes for many races on a single ballot. The largenumber of voters also adds to this complexity.

2. Intelligibility. When mechanical means such as pen and paper areused, the resulting marks may be ambiguous or unintentionally voidthe ballot. For example, in California, signing a ballot voids it. InFlorida, the different interpretations of when a "hanging chad" rep-resented an attempt to punch a hole, and when it was accidental, ledto controversy over the reported results of the election. Although theFlorida 2000 Presidential election is by far the best known example,this has happened in other jurisdictions.

2 The Voting Paradigms

3. Accessibility. People who have disabilities that inhibit their usingtraditional mechanisms such as pencil and paper or hole punchescan frequently use the more malleable interfaces of properly archi-tected electronic voting systems. This ensures *all* enfranchised vot-ers can cast votes, not simply those who can use the equipment.

As with all things, the benefits of electronic voting systems balancewith drawbacks. The one that concerns us in this work is the accuracy andproper recording of votes. The problem is that the vote is recorded as bits,which are not visible to the naked eye, rather than marks on a paper, whichcan be verified without relying on intervening technology. Our problem isto minimize this drawback.

We emphasize "minimize". Eliminating problems with electronic vot-ing machines is no more possible than with pen and paper, or other means.The proper test is whether the use of electronic voting systems introducesmore vulnerabilities that cannot be remediated.

Consider the nature of an election process that uses electronic votingsystems. Essentially, the process must manage the flow of ballots from apoint of origin to a system on which a voter casts her votes, and then toa tallying mechanism that counts the votes. At any point *except* whenthe voter is making her selections, the process must be observable, as is aprocess that uses paper and pencil. We adopt this view to study the designof an election that uses electronic voting systems.

The properties that an election process must meet are many. We focuson a few key properties:

1. Integrity. Ballots cannot be changed once cast, and results are re-ported as determined.

2. Accuracy of the tally. All valid votes are counted, and all invalidvotes are discarded. here, "valid" and "invalid" mean conformingand not conforming to the laws governing legal ballot markings orrepresentations.

3. Secrecy of the ballot. No voter may be able to prove to another partyhow she voted. This prevents vote selling.

1.1 Background. 3

4. Anonymity of the ballot. No party may determine how a voter voted.This prevents an unscrupulous party from forcing a voter to vote ina particular way.

We do not consider other properties, such as the ability to capture thevoter’s vote correctly and to provide a management interface that is easyto use. While these are important, they are orthogonal to the architecturewe present and analyze.

Our proposed architecture relies on a layer of central servers. These areconnected to a layer of voting clients upon which voters cast their votes.The glue ties these together, and consists of a ballots repository amongcentrals servers and voting clients. Gates sit between the voting clientsand the glue, and ensure only correct information passes between them.Additionally, the gates monitor connections to ensure the behavior of thevoting clients and glue matches specification, and report any behavior thatlies outside the spec.

The next section explains this architecture as used for system coordi-nation. We then review electronic voting, and describe a model of settingup and running an election. The fourth and the fifth sections combine thearchitecture and process model, and study how well the result satisfies theabove four properties, as well as what assumptions are necessary. We con-clude with an evaluation of the benefits and drawbacks of this architecturefor electronic voting systems.

At the end of this dissertation some Appendices, I love call them "bitsto remember" on the current machine’s vulnerabilities.

1.1 Background.

During the U.S. presidential election in November 2004, more than 40million voters used about 175,000 electronic Voting Machines in order tovote their new president [1]. Some of the most important election monitor-ing groups as, VerifiedVoting.org and BlackBoxVoting.org, receiving moreof 175,000 calls to its Election Incident Reporting System (EIRS) on dif-ferent problems types[2], are raising concerns about the Electronic Voting


safety [3,4] . According to data published on VerifiedVoting.org [5], fewyears later some Security Teams (UC Red Team, Stanford University, JohnsHopkins, ect.) [6, 7 ] tested the security of most common Voting Machines.In the meantime despite industry tries claims that the problems reportedby VerifiedVting.org have any effect on the past presidential race; but thesecurity test result has been deleterious. The most popular Electronic Vot-ing machine: Direct Recording Electronic (DRE) built by Sequoia Pacific,was vulnerable to at least 120 potential attacks[8] which an attacker couldcompromise each eVoting Machine. A DRE is an electronic machine able tocollect ballots. It use a large display (typically a touchscreen) to visualizethe ballot, a touchscreen monitor or a buttons set to collect the votes and asmart software to record them.The whole machine is covered from a resis-tant anti-shock case and protected by battery backup in order to preventcrashes and power loss. At the end of elections it produces a tabulationof data collected in a removable smart card and a printed copy[9] in orderto verify an eventually smart card data manipulations. Companies put alot of confidence in these few security levels forgetting the capabilities ofattackers who can easily compromise the memory card integrity and/orinstall a malware inside DRE before voting has been started. Can we besure that Machines’ software has recorded the correct ballot ? Can we besure that none could vote more than one time ? These questions are usefulto emphasize some of the most important sets of problems that literaturehas depicted [8,10 ] :

• Insertion of Corrupt Software

• Wireless and Remote Control

• Tally Server counting

• Calibration of the Machine

• Shut Off Voting Machine Features Intended to assist Voters

• Denial Of Service

• Actions by corrupt Poll Workers or Others at the Polling Place toaffect Votes

1.1 Background. 5

• Vote-Buying Schemes

• Attacks on Ballots or VVPT

• Unauthorized privilege escalation

• Incorrect use o Cryptography

According with following history schema [Figure 1.1], Electronic VotingSystem has introduced a new kind of insecurity aspect but it has deleted 3important problem sets like:

1. Counting Errors

2. Communication Errors

3. Written Mistake

The Figure 1.1 shows us the Voting Paradigm Changing (X axis) in re-lationship with different and general set of problems (Y axis). The Vot-ing Paradigms detected are four: signs paradigm, paper paradigm, com-puter paradigm and digital paradigm. The meaning of Digital Paradigmis a future concept of Voting System: the X axis is sorted by temporallogic. The General sets of problems detected are four: counting prob-lems,communication problems, written mistakes problems and computerscience security problems. Every era owns paradigm and owns problemsset. For instance: the Signs era had counting problems, it was difficult to counthundred of hands without make mistakes. On the other hand there were no com-munication or written problems as Papers Voting System.

Observing the history we deduce that Electronic Voting System andHands Voting System have just one insecurity problems set, instead a Pa-per Voting System has at least three insecure problems sets. The paradigmshift from Hands Voting System to Papers Voting System has been causedfrom the voters population growth whereas, at the present time, velocityand safety are so important that have driven a new paradigm shift fromPapers to Electronic. There are no reasons to came back from ElectronicVoting System to Papers or Hands voting System, but there are a lot ofsecurity reasons to encourage a new Electronic Voting System Model inorder to draw up Voting Systems to Digital era .


Figure 1.1: Voting System era

Chapter 2

The Standard

"I’ve learned that two people can look at the same thing andsee something totally different."

Anonymous

After the famous "butterfly election", November 2000 in Florida UnitedStates Of America [32, 33] where many of the punches cards disappeared,the American election system was pilloried on many fronts, especially forusing an outdated counting mechanism. After that fiasco and pushed fromcitizen discontent, politicians and vote experts decided to change the vot-ing technology focusing on electronic voting systems. Two years later theUS government passed the Help American Vote Act (HAVA) [34] givinghundreds of millions of dollars to the project of news electronic voting ma-chines. The companies used these dollars to build news machines underthe HAVA suggestion (not standards yet) and during the 2002 some USstate used these machines to their internal elections[35]. One year later,in early 2003, Bev Harris (election activist) made an amazing discovery[36]. She discovered, using Google with the search string "Global ElectionSystem" (the old name of the current Diebold Election System) a hiddensite which contains the source code of AccuVote-TS; the software used byDiebold to collect the ballots, presents in all Diebold voting machines[35].Researchers and experts at Johns Hopkins University and Rice Universityexamined this source code and published an important report where theyassert the presence of many bugs which cause several catastrophes vul-

8 The Standard

nerabilities [37]. They discovered that each voter was able to vote severaltimes and was able to administrate the machine changing the counters,they asserted that no encrypted storage was performed and no minimaland elementary security stuff was implemented. Of course Diebold claimsthat its system was the "state-of-the-art" of reliability, accuracy and secu-rity [38]. Third part security laboratories have been dragged in this anal-ysis, Science Applications International Corporation (SAIC) and RABATechnologies which wrote in late september 2003 and in early january 2004[39,40] that Diebold voting machines was really dangerous for the entireelection process. Despite that reports, during the U.S. general election in2004, the govern decided to use the Diebold machines causing a big masson election transparency. During the summer 2007 California Secretary ofState decided to start a "top-down" review of the Californian’s voting Sys-tem, in which I had the opportunity to participate. The reviewers visitedDiebold Election Systems, Sequoia Voting Systems, and Hart InterCivic,the major vendors of Electronic Voting Systems: it was again catastrophic[Appendixes].

2.1 Voting Machines.

Voting machines are useful tools built to improve the election pro-cess. They are combination of mechanical, electromechanical, electronicand software components working together in order to define ballots, castand count votes, report eventually errors, report finals results and guaran-tee the safety, the privacy and the security of each polling. Historic votingmachines are made by mechanical component and they print the resultson final paper. Actually the voting machine’s trend is following the elec-tronic way through networks and others communication ways: the elec-tronic voting machine. Every Voting machine includes practices and dif-ferent associated documentation used to identify each machine, each com-ponent and each test that machine has ride out. Voting machine are usedto define, cast and count ballots for this reason it is important to verify thesecurity level that every voting machine has reached; a compromised vot-ing machine may compromise the whole election process hazarding to the

2.1 Voting Machines. 9

democracy. During the history many different kinds of voting machinehave been released, the most famous are the followings :

• Punch Card Machine. This kind of machine (Figure 2.1) was build-ing thinking at the currents computers systems able to read punchedcards. The device appeared like a small clipboard-sized device wherethe voter punched holes in the card with a supplied punch devicelike a palm-pen. After the voting phase the voter placed the ballot ina ballot box made from the pooling director or he placed the ballotdirectly on the computer reader at the precinct.

Figure 2.1: Punch Card Machine, developed in 1960.

• Optical Scan. This machine is known as MarkSense machine. Thevoter fills the ballot, usually filling a rectangle a circle or oval or com-pleting an arrow. After the refilling phase he puts the ballot underan optical scan sensor able to read the voter’s sign. The voting ma-chine uses the "dark mark logic" where machine selects the darkestmark within a given set as the correct choices, understanding andcounting the voting chose. An example of this technique is placedhere: http:en.wikipedia.orgwikiPremier_Election_Solutions . Figure2.2 shows one model of Optical Scan machine, voter puts the filledballot on the bottom of the machine, the machine reads the paper-ballot and shows on display if the grabbed chose is correct. If thevoter recognize him vote, he pushes on "OK" button and her votewill be stored. These machines store ballots image file in a (often)encrypted database placed on local hard disk.

10 The Standard

Figure 2.2: Optical Scan Machine.

• Electronic Voting Machine With Electronic Input Device. This Ma-chine can understand the vote through an electronic pen linked tothe machine. The Figure 2.3 shows the machine with the electronicpen place on the bottom left.

Figure 2.3: Electronic Voting Machine With Electronic Input Device as apen.

• Voter Verified Paper Audit Trail (VVPAT) Electronic Voting Machine.This machine has an independent verification system based on a col-lected paper ballot, this technique should prevent voting fraud se-curity problems and corruption attempts. Exists different kinds ofvoting VVPAT machines but the most used print a human readablepaper with the voter chose. The human voter understand if the votehas been casted well and, if it is, she puts her ballot in a paper-ballot-box used after the election to control the race correctness.

• Direct Recording Machine (DRM). Used in United States Of America

2.1 Voting Machines. 11

Figure 2.4: Direct Recording Electronic Machine with VVPAT securitymechanism.

during the early 1990, this kind of machine is an easy mechanicalmachine, easy to test and friendly with the voters. Every DRM hasa different number of switches for each candidate, after the votingphase the voter has to push to the right button switch in order torecord her ballot.

Figure 2.5: Direct Recording, early 1900s.

• Direct Recording Electronic Voting System (DRE). The most used inUnited States Of America are the most famous electronic voting ma-chines and usually known as E-Vote Machine. This machine is thedirect successor to DRM. In this case the mechanical switches are re-placed by a touch screen monitor and the DRM circuits are replacedby a complex software. The voter makes her chose simply touch-ing on the name of the candidate directly on screen and the machinecasts the vote on its own encrypted and removable storage disk. Atthe end of the election day E-Machine produces two different kindsof exhaustive reports. It produces a report on what stored on en-crypted removable storage disk and a printed report of the collecteddata. The collected data will be sent to the precinct in order to be

12 The Standard

counted.

Figure 2.6: Direct Recording Electronic Voting System.

Figure 2.7: Direct Recording Electronic Voting System, voting phase.

The Figure 2.6 shows a current DRE Voting Machine working, duringthe configuration phase in the early morning of the election day. TheFigure 2.7 shows how DRE is user friendly and how intuitive is thevoting phase using a touch screen with the candidates list.

2.2 De-Facto Standard: VVSG.

Understanding how election system works means understand how thede-facto standard has been written. The following section describes howthe system is working from a very high level view, referring to internalNIST documents. Each diagram has been studied from NIST and writ-ten in Voluntary Voting System Guidelines (VVSG) to be self descriptiveand easy accessible for all the Voting Machines Companies, that empha-size there is no a formal standard yet but only Voluntary Guidelines. For

2.2 De-Facto Standard: VVSG. 13

these reasons the following diagrams will be poorly described by the au-thor. The first step is the election preparation; preparing an election meansorganizing precincts, gather absentee and/or remote votes, prepare forvoting the centrals, organize ballots, ballots images prepare people, placesand be ready to count a the end of the election day. The Figure 2.8 showshow the current Administer Election is working on.

Figure 2.8: Administer Elections.

14 The Standard

Grabbing the voters list, the blank ballots and collecting the filled ballotare actions designed in the following self-explaining diagram (Figure 2.9).It is pretty important underlining that the "Test Precinct equipment" stateis a non safety test but just a working test. That means the tester doesnot test the correctness, the integrity, the safety and the security but hetests only if the machine is working. After the collection (last state Figure2.9) the resulted artifact is the sum of Equipment, voter lists, ballot stylesand/or ballots ready to be sent to the right precinct.

The election process continues inside the polling place where the per-son goes in voting to her favorite candidate. Two different models (Figure2.10 and Figure 2.11) describe the main differences between Paper basedand DRE. Again the diagrams have been built to be self descriptive.

After the important voting phase every polls must be closed, every bal-lot must be counted validated and sent to precinct. This phase has beennamed "Wrap up voting" (on precinct). The same thing happens on thecentral where the precincts send reports, ballots, ballot images and/orprecinct totals. The central job is to collect every precincts stuff analyzeit, compiling general and official reports on the election and issuing theofficial centrals results. The Figures 2.12 and 2.13 show how it happens.

2.2 De-Facto Standard: VVSG. 15

Figure 2.9: Prepare For Election

As mentioned before, these diagrams are not official standards but onlyVoluntary Guidelines; during the fall 2007 NIST and others universitieslike UCDavis started a full-immersion work together in order to definenew real officials standards on Electronic Voting Machine. The main goalof this collaboration is compiling new official standards before the gen-eral U.S. election in november 2008. The new standards will be writtento increase the security and the safety of the machines and to guarantee

16 The Standard

Figure 2.10: Gather in-person vote (paper-based).

the voter’ s privacy. Starting from the following known problems the newstandard will assure that an hypothetical attacker can not break into vot-ing machine using simply attacks or known software bugs.

2.3 Known Attacks. 17

Figure 2.11: Gather in-person vote (DRE).

2.3 Known Attacks.

The Red Team [RT], has been appointed to perform penetration testson DRE voting machine. It produced a great book with over than 120 po-tentials attacks on voting system. In order to understand these differentkinds of attack it is useful guessing the entire voting process as an infor-mation flow between vendor programmers and voters. Quoting the redteam book :

18 The Standard

Figure 2.12: Wrap up voting (precinct).

"The vendor and programmers present the voter with infor-mation about her election choices via the voting machine; thevoter provides the voting machine with her choices; the voterÕs


Figure 2.13: Wrap up voting (central).

choice is then tallied by the voting machines, and this tallied in-formation is (at the close of the polls) provided to poll workers;from the polling place, the vote tallies (whether in paper, elec-tronic, or both forms) from all voting machines are sent to acounty tally center; from there countywide totals are reportedto state election officials and the media."

Following the Red Book’s sentences on the following map (Figure 2.14),which represents the information flow exchanged during the voting pro-cess life, it’s easy to understand where the break points are. System Soft-ware update, Patches, System prototypes, Source Code, Hardware, Soft-ware, Manuals, Memory Card, Ballot Definition, configuration Files, Ma-chine Total Tailed, Testing Phases, Sending processes and Wireless Com-munication must be trusted points in order to considerate the whole pro-

20 The Standard

cess safe. Of course these are assumptions too big and intended to beeasily broken.

"The electronic voting machine is, I think, a very useful tool.The problem is we don’t know what we don’t know."

DeForest Soaries

Nine different kind of attacks has been discovered following the RedTeam Map. The Insertion of Corrupt Software Into Machines Prior to ElectionDay, Wireless and other Remote Control Attacks, Attacks on Tally Servers, Mis-calibration of Machines, Shut off Voting Machine Features Intended to AssistVoters, Denial of Service Attacks, Actions by corrupt poll workers or others at thepolling place to affect votes cast, Vote Buying Schemes and Attacks on Ballotsor VVPT. Describing every detail on each attack topology is outside thegoal of that Dissertation but providing a little taste to understand why itis needed a new Electronic Voting System is mandatory.

One of the most obvious attack happens during the non voting day. Ev-ery voting machine is placed on county deposit, where who has the accesscan easily enter, and inserting malicious code inside the voting machine.Every installed malware may change the ballot, change the result and/orthe vote and may send to remote attacker the final result and so for. Re-mote Wireless control often is very dangerous because the attacker mayperform a remote attack being outside the voting place so no physical ac-cess is required. Using wireless PDA or a common WiFi phone allowing toaccess to the wireless networks, the attacker could enforce the machine toactivate or to deactivate the voting software or a software attack programor can easily read the data recorded by the voting machine. Different kindof attacks should be performed on the tally servers, the central tabula-tors which calculates the total votes for a particular precinct. This kindof attack can be executed before and/or after the election day and it canreach directly the tally server’s database or it may reach the network datastored on database. Having access to database means change directly thetotal amount of votes; these kind of attacks may compromise the whole


Figure 2.14: Red Team Information Flow Map.

election system, instead, modifying vote directly on the network, shouldbe more difficult and less deleterious . Others kind of attacks have beendiscovered like the Miscalibration Attack.In fact if the candidate "A" is onthe right of the screen and the candidate "B" is on the left and if the rightside of the screen doesn’t work, no one is able to vote for "A". So if anattacker will be able to perform this misscalibration can compromise theelection of one polling place. Others problems come directly to the pollingplaces; if an attacker is able to switch-off the power electricity or she isable to damage machine as disabling Assist Voters Feature or damage thememory card and so on, the machines can not work and it can not collectvote. Moreover, Following the Read Team map, we observe that everyred-places have been considered as possible break points inasmuch as awhole trusted model is needed. That means every upgrade, every patchinstalled by Software company must be safe and trusted. It is not so farthinking on a possible corrupting action on software companies and/oron pool workers who during the upgrading phase (or one patching phase)install "malware" (in that case it’s difficult call it malware) on remote ma-

22 The Standard

chine altering the correctness of the election. Yet another problem comesup from the ballots of VVPT which can be manipulated during the trans-portations from company to central, from central to polling places, frompolling places to central and so on.

During last summer another great work on Electronic Voting Machinehas been done in California. The California Secretary of State entered intoa contract with the University of California to test the security of someelectronic voting systems as part of her Top to Bottom Review.

The new RT followed the previous work described on Red Team’s Bookdiscovering more technical Voting Machine’s break points for each ma-chine. The machines analyzed have been Diebold Voting Machine andHart Voting Machine.

2.3.1 Diebold Voting Machine: Discovered Vulnerabilities

The RT’s task was to violate the physical and technological security’sbarrier in order to discover exploits that would violate the accuracy, se-crecy, or availability of voting systems and their respective auditing mech-anisms.

Figure 2.15: Hart Voting Machine.


The first step was to figure out how the machine worked building apotential attack graph like Figure 2.14. The result of the first step’s studyhas been reported and summarized into the following list (took from [43]).

GEMS Server. Diebold election management system software is calledGEMS (Global Election Management Systems). It is run on a serverthat is manually configured by Diebold technicians

AV-TSx. The AV-TSx (AccuVote-TSx Ð also referenced throughout thisdocument simply as TSx) is the DRE (Direct-Recording Electronic)voting terminal on which voters cast ballots.

AV-OS. The AV-OS (AccuVote Optical Scan) is an optical ballot scanner.The AV-OS uses an Espon 40-Pin memory card (or compatible cardÐ though Epson discontinued production of these cards in 1998) tostore configurations and election definitions.

Central Count AV-OS. This AV-OS is connected to the AccuFeed to readpaper ballots in bulk at a central count facility.

AccuFeed. The AccuFeed is used in a central count facility to feed paperballots (cast at the polling places or by absentee voters) into the Cen-tral Count AV-OS.

Smart Cards. Smart cards are used to control the security and adminis-tration of an election. There are four distinct types of smart cards:Security Key Cards, Central Administrator Cards, Supervisor Cards,and Voter Access Cards.

ST-100. The ST-100 smart card reader/writer is connected to the GEMSserver via a serial cable. It is used to encode the various smart cardsused throughout the election process.

DigiPort Server II16. The DigiPort Server II16 is an intelligent networkhub. It translates serial communication into Ethernet (and vice versa)in order to facilitate communication between the Central Count AV-OS units and the GEMS server.

24 The Standard

For a more detailed list see the complete Report [43]. The GEMS serveris used to create and menage all the aspects of an election, creating se-curity and administrative smart card upgrading election definitions onthe other system’s components. It encodes the smart cards to be usedby central pooling place. GEMS server is connected to TSx and to AV-OS which download the election definitions storing the data file in a re-movable memory (aka PCMCIA or EPSON 40-Pin memory for AV-OS). Itmay be used to create paper ballots during the election.The smart cardsprogrammed by GEMS server through the ST-100 are used to program theVoter Card Encoder, to access administrative functions an TSx, to start andto end the election day on voting machines and to accumulate results fromthe PCMCIA cards used in other machines, only if applicable. Every cardis given to a voter who plugging the card into TSx will be able to cast herown vote. Alternatively the voter may receive a paper ballot which will beread by the AV-OS through the scanner or accumulated in order to be readat the central. At the end of the election day every TSx and AV-OS musttransmit the results to GEMS servers using different types of communica-tion, including Ethernet Connection and Serial Modem Connection, andevery smart card must be sent to the central where they will be countedand verified. Assumed that as a correct behavior, RT started a deep re-search on potential vulnerabilities on the current system composed by :Diebold GEMS 1.18.24/AccuVote

1. GEMS software, version 1.18.24

2. AccuVote-TSX with AccuView Printer Module and Ballot Station firmwareversion 4.6.4

3. AccuVote-OS (Model D) with firmware version 1.96.6

4. AccuVote-OS Central Count with firmware version 2.0.12

5. AccuFeed

6. Vote Card Encoder, version 1.3.2

7. Key Card Tool software, version 4.6.1


8. VC Programmer software, version 4.6.1

RT results with two documents: one public [43] and the other one re-served (Of course only the public document can be cited and mentionedin this thesis) where RT describes how the discovered vulnerabilities mayaffect an election. The first set of vulnerabilities have been founded in-side the GEMS server. GEMS server runs over a Windows 2000 withoutproperly patches. Thank to these vulnerabilities RT was able to perform asuccessfully attack keeping the Windows Administrator’s rights. Duringthis phase RT also realized that lots of Windows logging capabilities weredisabled or enabled in very limited states in the configuration providedby Diebold. This means that most malicious actions taken by attackerswould not be traceable. Moreover RT was able to figure out, thanks toAdministrator privileges and network analysis that Diebold technicianscreated a remotely accessible Windows account that, by default configu-ration can be accessed without the need to supply a password. The sec-ond vulnerabilities set has been discovered in the GEMS Database. Withthe Administration credentials RT was able to modify the entire databasewith no warnings changing the election’s results. Another set of prob-lems becomes from the very poorly implemented log system in the GEMSsoftware. RT discovered a particular set of malicious executing actionspath that are not tracked by GEMS. For instance the Administrator is ableto change username and password without being tracked, this is a non-standard computing practice and it could be potentially used by a rougeadministrator to implicate another GEMS user. Unfortunately the config-urations files are often free from control; in fact during the analysis of theconfiguration files, the RT discovered a format string vulnerabilities that,when exploited, caused an election to run smoothly on a TSx unit. Whena voter tried to cast a ballot on a TSx, if the vulnerability has been ex-ploited, the printer would generate an error, and the voter’s ballot wouldbe deleted. The voter is notified about the error via a series of incom-prehensible messages followed by this notification: "Your ballot has beencancelled". Using information gathered through Administration creden-tials RT was able to guess the network’s credentials for the networkinghardware gaining direct access to the remote devices. This access pro-

26 The Standard

vided to the attacker enough privileges to modify every machine’s settingincluding the possibility to install USB drivers for a remote Wireless com-ponent. After the software’s analysis RT focused own attention on hard-ware and physical security. Using simple tools, that could be founded ina typical office, RT was able to violate the hardware security reading andor writing the smart cart content. On one hand reading the memory con-tent means that the attacker can tally the votes building covert channelbetween him and the voters. On the other hand writing memory contentmeans to manipulate software design, blocking the machine or installingmalware. These scenarios may compromise an entire election. RT was ableto perform local privileges escalation thanks to leak founded into pollingplace devices. This vulnerability allows a voter to reset an election or tosend the collected votes via modem to a remote machine. Others problemscome from TSx default key; RT verified that a previously-identified statickey was still in use on the system. If election officials opt to use the statickeys, or if they forget to change them, the TSx units display a particularicon on the screen to warn that the keys in use are insecure. A possibleattacker could observe this icon and use the information being leaked bythe TSx unit to craft more specific attacks for the system. These and oth-ers attacks can be used to perform numerous attack scenarios describedon original report [43]. The aim of this work is not to describe the attackscenarios that can use previous vulnerabilities exploiting the system in or-der to compromise the election; for this reason is suggested as a great andpretty instructive reading the public report available on public CaliforniaState web site [42,43].

2.3.2 Hart Voting Machine: Discovered Vulnerabilities

Again,the RT’s task was to violate the physical and technological se-curity’s barrier in order to discover exploits that would violate the accu-racy, secrecy, or availability of voting systems and their respective auditingmechanisms.

For the second time the first step was to figure out how the machineworked building a potential attack graph like Figure 2.14. The result of


Figure 2.16: Hart Voting Machine.

the first step’s study has been reported and summarized into the followinglist.

BallotNow. BallotNow derives information for printing paper ballots foran election from an MBB.

BOSS. Ballot Origination Software System software application (BOSS) isused to create a BOSS Election database for an election and to con-figure all software and hardware components of the whole system.

eCM Manager. Hart InterCivicÕs eCM Manager is a software applicationthat reads and writes a Key ID, Key GUID, and a signing key to aneCM.

eScan. A precinct based optical ballot scanner. The eScan scans and tabu-lates ballots, storing results to an MBB.

eSlate. A DRE voting unit connected to a JBC. This is the end terminalthat voters use to cast their ballots electronically.

28 The Standard

JBC. The JudgeÕs Booth Controller (JBC) is the console for controlling upto 12 eSlate/DAU voting devices.

MBB. The Mobile Ballot Box (MBB) is a PCMCIA storage card used tostore information about the election, including ballot definitions andcast ballots.

Rally. Used in the voting locations to total the ballots from the MBB andcommunicates remotely to Tally.

SERVO. System for Election Records and Verification of Operations (SERVO)is an election-records and recount-management system for the JBC,eSlate, or eScan voting devices from the Hart Voting System. It isalso used to perform backup of JBC.

Tally. The Tally application directly reads Mobile Ballot Boxes (MBBs) thatwere produced by BOSS and populated with voting data from HartVoting System equipment and indirectly reads MBB data transmittedby the Rally application installed at remote locations for tabulation.

For a more detailed list see the complete Report [42]. The eCM managercreates a cryptographic key, which will be used by various Hart InterCiviccomponents throughout the course of an election The keys are loaded ontoSpyrus USB cryptographic tokens.This key is used by the BOSS applica-tion to create an election database containing all the details to run an elec-tion. After that, BOSS writes some MBBs, in relationship with the numberof pooling places, (for instance a PCMCIA card) to be used in the election.One of this will be used by BallotNow in order to print paper ballots. Ev-ery MBB can not be reused during the election process, so if a MBB will beplugged inside another Hart component, an Error box will block the pro-cess. Of course every MBB are tracked by BOSS. SERVO is used to resetand re-encode the key into the eScan and into the JBC/eSalte units. Whenthe MBB will be plugged inside one of these machines, the eSales is readyfor the pooling place. At the end of the election every MBB can be physi-cally transported to the central headquarters to be counted. The votes aretabulated by Tally, which will use the original key to evaluate the result.Assuming as a correct behavior, RD started a deep research on potential


vulnerabilities on the current system composed by :Hart Intercivic System 6.2.1

1. Ballot Now software, version 3.3.11

2. BOSS software, version 4.3.13

3. Rally software, version 2.3.7

4. Tally software, version 4.3.10

5. SERVO, version 4.2.10

6. JBC, version 4.3.1

7. eSlate/DAU, version 4.2.13

8. eScan, version 1.3.14

9. VBO, version 1.8.3

10. eCM Manager, version 1.1.7

Again, RT’s results with two documents: one public [42] and the otherone reserved (Of course only the public document can be cited and men-tioned in this thesis) where RT describes how the discovered vulnerabili-ties may affect an election. The vulnerabilities discussed on the public doc-ument regard four different system components.The first category is onWindows Vulnerabilities: the Hart Election Management System Serversrun on not patched Windows 2000 server and with insecure default set-tings. The second category is on eScan component. The Red Team locateda vector for overwriting the eScan executable. Although the team did nothave enough time to craft an exploit for altering the total votes, givenmore time, the team is confident that eScan vote tallying could be mod-ified maliciously. The team was also able to access device-level menusthat should be locked with passwords but were not. This access couldallow an attacker vector for altering configuration settings and/or execut-ing a denial of service on the eScan. Some of the findings from previousstudies on precinct count optical scanners were replicated on the eScan,

30 The Standard

and they allowed the RT to maliciously alter vote totals with the poten-tial to affect the outcome of an election. These attacks were low-tech andrequired tools that could be found in a typical office. The third categoryis on JBC where RT verified previous findings on the JBC regarding ac-cess code generation and also discovered that a surreptitious device couldissue commands that caused the JBC to authorize access codes. The lastcategory is on eSlate machine.The eSlate provides a continual audio nar-ration of all on-screen events, including the entering of the access code andvoter selections, and this audio is directed into attached headphones. TheRT found that it was possible to remotely capture this narration Ð whichincludes an audio replication of each vote castÐ without any physical ac-cess to the eSlate. These vulnerabilities may cause some interesting attackscenarios that will compromise the security of a whole election system; formore accessible detail see the public report [42] section IV.

The goal of this dissertation is not describing the details of these at-tacks (some of these on Dissertation’s Appendixes) but showing the cur-rent model’s need: a self organized, always up, trusted system, where nogeneral-trust-concept is needed. The presented model (after it will becomean entire process) does not need any big trust assumption like, for exam-ple "the company A is incorruptible" or "the software is safe" in order towork.

Chapter 3

Proposed Solution

"Research is what I‘m doing when I don‘t know what I‘m do-ing."

Wernher von Braun

3.1 Glue.

Nowadays each digital component is composed and is part-of one ormore complex systems, this is the main reason why coordination seems tobe one of the most important problems to solve in computer Engineering[20,21]. Glue Meta Architecture is one of the most primitive coordinationconcept where each entity communicates through it using tuples by meansof standard Linda primitives [12,13,14]. Client-Server and Pear-to-Pearare the most used communication paradigms on the world but they arenot alone. Glue Meta Architecture is based on associative Blackboard[19];every entity can communicate with others entities writing a tuple on theBlackboard enabling spatial and temporal uncoupling interaction. Client-Server and Pear-to-Pear communication paradigms have a strong tempo-ral bond, in fact both entities must be connected at the same time and theymust be coordinate in order to respect the question-answer protocol. In theGlue Meta Architecture this is not true. Entities are able to communicatewhenever they want and they could not respect the question-and-answerprotocol.

32 Proposed Solution

Glue Meta Architecture as presented in this paper is a programmablecoordination center[15]. Introducing the programmable concept, the Ar-chitecture becomes dynamic and able to change the inserted tuples. Thepossibility to change tuple-meaning, allows coordination center to modifyand to understand the behavior of each Entity building a global systemproperties. This architecture has been built [16] on three entities:

1. Coordination Entities. Entities whose mutual interaction is ruled bythe model, also called the coordinables

2. Coordination Media. Abstractions enabling and ruling entities inter-actions.

3. Coordination Rules. Rules defining the behavior of the coordinationmedia in response to interaction.

Figure 3.1: Glue Meta Architecture.

Every entity could become a coordinables object; for instance Unix-Like processes, Thread, concurrent objects and even human users couldbe part of more high level process. It becomes easy to understand thisidea if we think at traffic light that is a human behavior coordinator dur-ing our drive time or if we think at vehicle code that is a meta coordinatorof human behavior inasmuch as it coordinates the traffic light. On theother hand entities like semaphore, monitors, channels, tuple centers andpipes are considerate coordination media. Coordination rules define the

3.2 Coordinator Examples. 33

behavior of coordination media or can be used in order to understand ifa Coordination Entity respects them. Classical coordination laws exam-ples are: tuples, XML elements, FOL terms, Java Objects and so fourth.The basic idea is to coordinate each entity using a tuple space, every en-tity can read, take or write one or more tuples and the coordinator centercan modify, delete and build tuple in order to respect the global properties(or goal). Communication Language[17] and Coordination Language[18]are really important in order to understand how Entities are able to inter-act but in this paper we do not analyze these problems inasmuch as notpertaining at current problem.

3.2 Coordinator Examples.

Practical examples are often useful to understand how the meta model( Section 3.1), frequently presented as a too much "high level" pattern,works. In this section some daily scenarios, referred to human life willbe presented. The first, the most important and the most spread coordina-tor artifact that everybody use every day is the "air". Thanks to the "air"people are allowed to communicate to each others sending "voice" through"it". The communication between people is the first medium which carriesthe coordination’s information. For instance if we consider the Footballteam as our environment, the coach uses the "air" in order to coordinatethe players’ training and the players use the "air" to improve their ownpractice, asking details to the coach. Another system which uses the "air"as main coordinator, is the Military’s System. The team leader ordains ac-tions to the team and the team must execute it at the same time. Also inthis scenario the "air" has been used from the team leader to coordinatethe entire team. Another daily example comes out considering the sys-tem "tree". Under that environment we can assert that the roots are thegrowth coordinators for the system tree. In fact the roots may adjusting thelymph’s flow, coordinating the tree’s growth. As already mentioned thetraffic lights is a coordinator for the traffic system as the policeman too."Laws and rules" are the main coordinator artifacts of human life. In factthrough "Laws and rules" humans must coordinate their behaviors. For in-


stance the law says that you cannot drive a car if you are under sixteenyears old and if you fail the driver’s test. This easy rule exploit your be-havior constraining you to follow two main steps before driving a car: 1)reach sixteen years old, 2) pass the drive license’s test. These are only fewexamples of coordinators entities that you can find around yourself everyday; inspiring to these scenarios the presented work wants to build a newElectronic Voting System fitting the most abstract assumptions.

3.3 Proposed Architecture.

Following the Glue meta model we describe how to design it in orderto build a new vote architecture. Three is the number of layers we dividedthe problem domain, each layer owns a specific task and performs a spe-cific work.

1. Voting Machines Layer. This layer is composed from Machines ableto acquire vote in the voting places. These machines are spread inall countries, in this way they are subject to most of known attacks[8]. It is our first goal building an infrastructure able to defend themfrom internal and external pushes.

2. Glue and Gates Layer. This layer is composed from two differententities:

(a) Glue. This is the most important entity. Glue represents the bigballot store where every Voting Machine send the ballot as soonas grabbed.

(b) Gate. Is the secondary layer entity, it allows the communicationbetween Voting Machine and Glue. In order to obtain the Gluecommunication control, every entity who wants speaking withGlue must pass through a Gate.

3. Counting Servers Layer. This layer is composed of trusted countingservers machines able to ask to Glue, passing through the Gates, theballots assessment.

3.4 Voting Machine Layer. 35

The Figure 4.1 shows how the three different layers are jointed togetheremphasizing the widespread Glue importance.

Figure 3.2: Glue Architecture on Voting Problem.

The Human Actor interacts whit Voting Machine selecting the rightcandidate, the Voting Machine does not store the fresh ballot but it sendimmediately the ballot to Glue. The Glue is able to understand, using adeduction process, if the machine is compromised. If the machine resultssafe, the Glue store the ballot in its memory. If the machine is not safe Glueis able to correct it. Central servers are able to count the ballot wheneverthey want in order to preserve upgraded race statistics.

The following paragraphs analyze the structure of every single layer.

3.4 Voting Machine Layer.

Every citizen should vote his preferred candidate: this is the main rea-son that makes Voting Machines spread in the countries. The entire set of


Voting Machines has been named Voting Machine Layer. We can not as-sume Voting Machine as safe systems because it is really hard to monitoreach single frame, thus Voting Machine Layer could not deemed safe. Forthis reason we view each Voting Machine as a set of 2 under components[Figure 4.2] :

1. Dummy Machine. It is a pure hardware system before election day.No boot loader and no operative system have been installed dur-ing the previous days. Thanks to designed functions it is able todownload boot loader and operative system from the Glue duringthe election day.

2. Smart Card. This encrypted smart card wraps the Machine Behavior.Dummy Machine needs to encrypted smart card inserted in order tograb the ballot and to send it to Glue system.

Figure 3.3: Voting Machine Architecture.

Dummies Machines as considered before, become Voting Machinesonly after a correct initialization phase where they are filled up with bootloader and operative system. During the beginning of this phase the net-work connection is not safe and it becomes safe only at the end of the keysexchange protocol as shown in Figure 4.3 . The security problems aboutthe network safety and the operative system manipulation will be consid-

3.4 Voting Machine Layer. 37

ered in the Security of Proposed Architecture section. After safe connec-tion has been built, the Voting Machine runs the voting program and itwaits for the behavior stored inside an encrypted smart card. Only withsmart card plugged inside, voting program can grab the ballot and send itimmediately to Glue system where ballot will be stored.

The Figure 4.3 show step by step Voting Client Activity, this activityflow transforms the dummy machine in a Voting Machine in order to beused from human voters.

Behavior is the most important concept to define in order to explainthe Security of whole model. The security of Glue Architecture is basedon Deduction Process that uses behavior to understand the safety of eachmachine. Smart card is the Voting Machine behavior cradle; it frames thethree main functions that create behavior:

1. behavior. This is a designed function built in order to understand ifin the machine is running a parasite process. We assume to know theOperative System downloaded from the Glue.

2. getVote. This is a designed function built in order to grab the ballot.This function resides on encrypted smart card preventing OperativeSystem Reverse Engineering.

3. sendBallot. This is a designed function able to send the ballot toGlue, using a particular design pattern.

The connection during the sending phase is covered by secure tunnel, sonone could listen and replace the design pattern simulating a safe VotingMachine client. While the first two functions (1,2) are equals for each smartcard, the third function could be personalized for a specific number ofsmart cards. Every state, for instance, could have his own function.

The Figure 4.4 shows a possible scenario to use behavior. The main vot-ing program runs without behavior but it is not able to grab ballots andto send them to Glue. After the introduction of smart card, the main pro-gram finds the right functions and becomes able to use behavior. Behaviorenables the others two functions, allowing the communication betweenVoting Machine and Glue, only if it recognizes the entire system.


Figure 3.4: Voting Machine Activity Diagram.

3.5 Glue and Gate Layer.

The Glue Layer has been introduced in order to divide Central Serversfrom Clients, this division is really useful to prevent denial of services at-

3.5 Glue and Gate Layer. 39

Figure 3.5: Relationship between main voting program and behavior .

tacks, in this way no entities can write to Central Servers filling up theservice or the network working-load.Glue is the repository of safe BootLoader and safe Operative System. Every machine able to communicatethrough the Gate with secure tunnel can download them. Each VotingMachine sends ballot to Glue Through Gate. The Glue has the coordi-nator center capabilities and it store each correct ballot making availablethem for counting by Central Servers. Five services are effected by Glueas shown in Figure 4.5 :

1. Build an encrypted channel. This service (Fork_1) is useful in orderto make a secure communication between Glue and Voting Machine.Every ballot sent from Voting Machine to Glue are protected, in thisway no intruder can understand the transmission behavior or exe-cute a man in the middle attack.

2. Boot Loader Offer . This service (Fork_2) allows each machine todownload the safe boot loader. The presence of two Forks meansthat communication between Glue and Voting Machine is not safeduring this downloading, thus an attacker could substitute the BootLoader or even installs a different Boot Loader and Operative Systeminto the machine. These events will be discussed later.

3. Operative System Offer. This service (Fork_2) is similar to point (2)just discussed.


4. Ballot Receive. This service (Fork_2) is the main service able to col-lect the ballots. Every Voting Machine uses this service in order tosend its ballots. Glue is able to understand, using the deduction pro-cess, if the ballot just sent is safe or not. If ballot is correct and safe,this service store it in its central memory. If ballot is not safe, Gluesend a reboot signal to machine in order to correct the bad func-tioning. In order to understand why a simple reboot is enough tocorrect bad functioning, looking Security of Proposed Architectureparagraph.

5. Counting Service.This service (Fork_2) has been built for CentralServers in order to allow the ballots counting. Counting service of-fer ballots but does not remove them from the Glue. Only CentralServers are allowed, passing through their own gates, to count andmake statistics on votes.

Gates are the only way to access at Glue, they are a passive and notprogrammable entities. Gates have an important monitor job; only a writeconnection from Voting Machine to Glue and only a rebooting signal fromGlue to Voting Machine are allowed. We assume gate as safe entities inas-much as installed on Glue.

3.6 Central Server Layer.

During the election day, people are very interested in which candidateis collecting the major number of votes. In order to esteemed real timestatistic Central Servers count, each quantum of time, the total amountof ballots contained in the Glue. Central Server Layer can wrap one ormore Central Servers and each server can count the ballots during differ-ent time-quantum; this is possible because it is an easy "readers and writ-ers" problem [11] where the reader have not a concurrent problems. Everyentity who wants communicate with Glue must build a secure channel. Infact, as shown in Figure 4.6, after the construction of secure tunnel CentralServer is able to count the ballots from Glue.

3.6 Central Server Layer. 41

Figure 3.6: Glue Activity Diagram.


Figure 3.7: Central Server Activity Diagram.

3.6 Central Server Layer. 43

Figure 4.6 show us the easy Counter Server behavior considerate safe.This model can not detect if machines make counting mistakes providingwrong final results.

The next section explains the security of this architecture and biddingexamples and cases of attacks, it explains how Glue model is able to un-derstand if remote machine has been compromised. Moreover Security ofProposed Architecture paragraph show us an easy and fast way to correctcompromised machine.

Chapter 4

Security of Proposed Architecture.

"Remember, extremism in the nondefense of moderation is nota virtue."

Peter Neumann

Aim of this section is explaining, by attacks scenarios, how proposedarchitecture is able to detect corrupted machines and fix them without anyrecoil on the whole voting system. The reading key of attacks scenarios isDeduction Process: the main concept of Glue Architecture Security. We di-vide the entire domain of Proposed Architecture in three different under-domains:

1. What We Know. This under-domain wraps the well known entitiesas Operative System, Memory Processes, Hardware and Machine Be-havior.

2. What We Observe. This under-domain wraps the current knowledgeof the whole System. Glue Architecture is able to observe Tuples (or

46 Security of Proposed Architecture.

something similar, ex. db record or Strings) that represent Votingmachine Behavior.

3. What We Deduce. The elements of this under-domain are two: wecan deduce if analyzed machine is Safe or not safe.

Each under-domain is atomic, that means it is not possible to completeDeduction Process without one of them. Figure 4.7 shows the three mainphases of Deduction Process and how they are chaining together. Twokind of knowledge are present in this process: the basic one represented byWhat We Know (1) and the current one represented by What We Observe(2). Correlating What We Observe (2) to What We Know (1) it is possible toreach the right deduction. For instance if we know every Voting machinefrom a particular area must follow a predetermined patter in order to putits ballot on Glue, and the Glue observes a different designed pattern, wecan deduce that Voting machine has been compromised. This was just aneasy example in order to understand the primitive idea.

Figure 4.1: Deduction Process.

Now we can consider a Voting Machine compromised and we try tofollow the deduction process (Fig 4.7) understanding if we can reach thededuction "Not Safe". The first weak problem could be during the start-up phase: the connection is not safe thus the machine could download acompromised boot loader or moreover a compromised operative system.Others problems arrive from malware installations, from new hardwareinstallation, from denial of service attacks and from smart card reverseengineering. We have dedicated a section illustrating which problems aredeductibles and which problems no.

4.1 Compromised Boot Loader or Compromised OS. 47

4.1 Compromised Boot Loader or Compromised

OS.

During the start-up procedure Dummy Machine downloads Boot Loaderand Operative System from Glue and only after this operation it builds asecure connection with Glue through own gate. During this initial phasesomeone could hijack the traffic or can install on the Voting machine di-rectly the boot loader and the Operative System jumping initial phase.This is the most thorny scenario, in fact during the election phase, afterthe smart card introduction, the machine could not work. Smart mem-ory card has been designed in order to prevent this kind of attack so wecan deduce that machine has been compromised because behavior doesnot recognize the right system. It became easy to understand if we thinkat memory processes. If we know Operative System, we know the run-ning memory processes during the voting phase. Smart Card Behavioris a function that knows them. When Smart Card plugged into DummyMachine, it could not work because the Behavior function can not matchthe current memory processes, thus smart card does not offer the getVoteand sendVote functions to eVoting Program. In this way Voting Machineis not able to grab the Vote. If attacker builds own voting program storedon downloaded OS, Voting Machine is not able to send the grabbed voteto Glue because it does not know the right matching pattern. So In bothcases we can deduce from Tuple observation that machine has been com-promised. Every machine must communicate with Glue using a right be-havior (or tuple pattern); if behavior is not recognized , using a deductionprocess we can deduce that machine has been compromised.

Figure 4.8 shows the secure connection phases; after the boot, DummyMachine using a Public-Private keys protocol as RSA or DSA builds a se-cure channel in order to prevent possible behavior sniffers. If we assumesecure channel enough strong to resist at one day (election day) cryptoanalysis attacks, we can assume that no one can understand and replacebehavior using a sniff-replace technique. Glue Architecture is able to un-derstand Boot Loader and/or Operative System substitution observingMachine Behavior.


Figure 4.2: Voting Machine Connection.

4.2 Malware and Hardware Installation.

A first sight Malware and Hardware installation could seem two differ-ent problems but if you consider that every hardware needs a software towork, you have just associated the two different problems. Most of breakpoints are caused from software patches, updates, configuration files andelections definitions [8]. In Glue architecture every patches and everysoftware update are stored into coordination center where is controlledand assumed safe. No update problems, no configuration files to set-upand no election definition; every machine during start-up phase down-load the last software version available. The only possible scenario is thatattacker installs malware after the OS downloaded, in fact if the malwarehas been installed before start-up phase it will be overwrite. This is thereason why this attack must happen in the voting place (that should beguarded from police) and so it is considerate as difficult, but not impossi-ble, attack. There are a lot of possible scenarios where attackers want toinstall hardware and malware on Voting Machine but, as considered be-fore, each additional running software is composed at least from one run-ning process. If the previous sentence is true (each software is at least oneprocess) no additional hardware and so no additional software could beinstalled because behavior function blocks the gateVote and the sendVotephases recognizing a fake system.

4.3 Denial of Services Attacks and Attacks on Tally Servers. 49

4.3 Denial of Services Attacks and Attacks on Tally

Servers.

The Glue meta Architecture born in order to prevent the Client-to-Client denial of service. Every Client who wants to talk with others Clientsmust post a "post-it" on blackboard that is a coordination center and soable to manage mutual concurrence. The eVontig the scenario looks-alike,no one can talk directly with Tally Servers, every body must talk withGlue. Tally Servers have no services available, they just count, asking toGlue, the total real-time amount of ballots. In this way if one or more ma-chines are infected they can not compromise the whole election phase be-cause they are not able to foul up the Tally Servers. On the other hand Gluearchitecture is a spread and distributed coordination system protected bygates. Every machine has own gate allowing voting machine to talk withGlue; if Voting machine has been compromised and shots lots of messageto Glue it causes a self denial of service, saturating the own gate. MoreoverGlue system observing wrong machine behavior detects the anomaly.

4.4 Smart Card Reverse Engineering.

Every Cryptography algorithms is vulnerable at Brute Force attacks,for this reason it is not possible to assure the global security at cryptogra-phy systems. However cryptography is never leave alone but it is alwaysaccompanied by the right time session. So it becomes right to assume thatcryptography is the right answer to reverse engineering problem. Buildan encrypted smart memory card to prevent reverse engineering is not sodifficult. We need a smart card encryption that resists until the day afterelection day and not more. At the end of election it results not importantif an attacker can understand the behavior, inasmuch as during the nextelection period it will be essential building another smart memory cardwhit another behavior.

The only reverse engineering problem could happen in the followingscenario. We assume attacker is able to emulate the right operative systemcontained in the Glue and we assume he can steal a smart memory card.


With both of memory card and operative system he is able to make a truereverse engineering understanding the voting place behavior. In this casehe is able to perform a man-in-the middle attack on predetermined eVot-ing place. Anyway it is pretty acceptable that steal encrypted smart mem-ory card is quite difficult and it is pretty acceptable to assert that it resultsdifficult, during last days of election, understanding behavior and build-ing a man-in-the-middle attack on eVoting place where has been stolen theencrypted smart card. Moreover we can believe that, if encrypted smartcard has been stolen, some one discovers it and alerts the police, in thisway it is possible to modify the eVoting place smart card behavior.

4.5 Calibration Machine Attacks.

Each Hardware component needs to initialization phase. For instancea touch-screen monitor needs a really important calibration phase whereit sets owns sensors to improve selection accuracy. A smart attacker couldact on this phase in order to tampering with accuracy blocking the voteof one or more candidates. If attacker knows that on the right side thereis him preferred candidate and on the left side the other one, he couldcover with a non visible plastic frame the left side of the Voting MachineMonitor. In this way every body who wants to vote for the candidatesituated on the left can not do it. This problem is not detected from GlueArchitecture. As discussed before, we can state this kind of attack enoughdifficult to be considered an acceptable attack inasmuch as it is reasonablethinking that is difficult to act inside a voting place.

4.6 How to Correct Wrong Behavior Detected.

Historically after detection of a problem the Human behavior focuseson problem solving. We studied how to detect problems now it is usefulunderstand how to repair them dynamically. The Glue model has beenbuild in order to simplify the detection and the security of whole votingsystem, thank to the decouple of the three layers we obtain some interest-ing properties. One of these become really useful in order to correct wrong

4.6 How to Correct Wrong Behavior Detected. 51

behavior detected. The simply way to correct bugs, malwares or everykind of detected problems is to restart the voting machine. Of course onlyGlue is able to reboot machines, else the model falls down in denial ofservice problems. Restarting voting machine implies rebuild initializationphases thus download boot loader and new operative system; the machinewill be initialized from zero.

Chapter 5

Conclusion

"No, I don’t want you to draw any conclusion. I want you tolisten to what I just said. "

Joe Morgan

Future Works Planning future works on this security subject is extremelydifficult; too many variables and too many changes are moving on. Thesimplest and more natural future work will be building a practical infras-tructure of the described architecture. Building a practical software ableto perform the mentioned properties will provide to us a concrete data toanalyze and a concrete platform to test, which will be really useful in or-der to judge the system. Judging the system means performing the sameattack that Read Teaming has done observing how the whole system re-acts. The self recovery properties must come out and the entire architec-ture should work fine without any technical trouble. Another interestingway to follow, continuing the partnership with University of Californiaat Davis, might be the study of a new standard voting process, amplifyingthe VVSG ’s requirements with a deep security section. This study couldalso involve NIST and others political authorities interested to protect thedemocracy.

Lessons learned This work showed a double aspect of the Electronic vot-ing System: the necessity and the problematic. On one hand every bigstate need a Electronic Voting System in order to reduce the voting costs

54 Conclusion

and to speed up the whole voting process but on the other hand Elec-tronic Voting system, as today has been developed, is extremely insecureand fragile. It has become clear that we cannot trust our elections to theelectronic voting machines of todayÕs leading vendors, because too manytrusting assumptions must be done. Whether we will ever be able to trustthem remains an open, but not interesting question. There is not yet a clearconsensus on what standards a voting machine should reasonably be ex-pected to meet. The goal of this work is to describe a novel architecturebased on 3 different layers (Voting Machine, Glue and Central Servers)able to resist at the most network, hardware and social known attacks.Following a bottom up approach and starting from the Read Team vul-nerability’s analysis on the current voting machines, the presented workbuilds a self resistant infrastructure which fights the attackers, giving moreimportance at the coordinator artifact (the Glue) rather then at the votingmachine. Emphasizing the coordinator artifact means abstract the secu-rity of the model on a well-controlled engine, giving free breaths to Vot-ing Machine and counting servers. Moreover the squeezed architectureallows numerous "component’s properties" derived from software engineer-ing studies which permit an easy Entity plug and play . In fact it is veryeasy to introduce a new Voting Machine and a new counting server tothe system; both of them take everything (boot loader, operative systemand trusted software) directly from the coordinator artifact (Glue), whichmeans reduced installation and setup costs. Furthermore adopting suchsolution is possible to build a real time statistics, for the interested medias,and it is possible to allow every political party to have its own counterserver which may count, looking on the coordinator artifact, the votes "onfly". The presented architecture can potentially make significant impactsto our future Electronic Voting Systems and Electronic Voting Applications.

Appendix A

The Ballot File.

In that appendix a short analysis on the ballot file of Hart eSLATE Di-rect Record Electronic Voting System. This file is the core of the whole pro-cess written to hold the vote information. The analysis was performed byFrancis Hsu (University of California, Davis) in 2007. The MBB (memorycard) storing the ballot definitions and votes is a 128 MB PCMCIA flashcard inserted into the JBC. Linux recognizes the hardware as following :

Figure A.1: Linux Recognition.

The data on the card did not appear to conform to a standard file sys-tem. The entire images used to this analysis are available in CD Attachedto this dissertation.The header of the data appears to be laid out in littleindian format

Figure A.2: Raw Data in Little Indian.

The header spells out "Sample County USA 2006" . Continuing with theempty body of a the ballot file, it appears to be laid out in UTF-16, theFigure A.3 proves that in the following way

56 The Ballot File.

Figure A.3: Ballot Data UTF-16.

It becomes interesting try to analyze a full compiled ballot file. We triedto analyze the ballot file in two different moments but with the same vote,in order to understand if the ballot has been encrypted with some kind oftime cheaper.

57

Figure A.4: Compiled Ballot File in t0.

Figure A.5: Compiled Ballot File in t1.

The votes records seem the same, no strong encryption. After different testwe were able to understand the entire section of the ballot.

Figure A.6: Sections.

58 The Ballot File.

A.1 Conclusion

We learned that the ballot file is easy to detect and to compromise, nostrong encryption and no integrity verification on contents. It is easy tomodify the ballot text and so the order of the candidates are not more ca-sual. Moreover the display limits for write-in candidates are inconsistentat different points in the voting process. We assumed this is also applica-ble to names in the ballot definition. We found a maximum character limitof :

25 for user input of the name

21 for displaying the name on the ballot

16 for displaying the name on the ballot confirmation screen

16 for the vote verification page

16 for the paper ballot printout

Appendix B

Printer Barcodes

Each Voting Machine has a printer (eSlate in California) that prints (fol-lowing VVSG suggestion) barcodes when ballots are accepted or rejected.In this appendix has been described the work of Justin Cummins (Univer-sity of California, Davis) who analyzed the eSlate printer barcodes.

Figure B.1: eSlate printer.

The barcodes are two-dimensional, following the PDF417 standard [ref.].The two dimensional barcodes are really easy to decode [SWIPE] thankbarcode decrypter like SWIPE. We started analyzing the differences be-tween 2 different kinds of ballot. The First and the Second ballots wereblank while the third and the fourth ballots were for Lincoln. We toke thebarcode and we cracked it using SWIPE, the following image shows theresults.

60 Printer Barcodes

Figure B.2: Ballots barcodes cracked.

With these few examples it’s difficult to understand how barcodes workbut it is pretty easy realizing that there are some temporal changes fromblank to blank ballots: "1775338;1775338" - "1777650;1777650" and fromblank to voted ballots: "0" - "1" on the 17th argument. Next step is analyz-ing more different ballots each one with just one change from an emptyballot, the simple string encodings are the following.

Figure B.3: More ballots barcodes decoded.

Nothing changes before "ED", between "ED" and "No;No" there are twofactors that change. After that a sequence of factor before "EOR;" whichchange in function on voter’s preferences. Trying with different printer,the barcode follows the same pattern except for the third factor, we pre-sume being printer serial number.

B.1 Conclusion.

Performing a reverse engineering technique, having the ballot formatand the matching barcode, we was able to understand the pattern used toprint the barcode.The working format is:

ACC; eSlate Serial; Print Serial; 1045; 1; 1; 7; 7; ED; BallotKey;BallotKey; No; No; 5; 0; 2; PresVal[0,2-4]; 3; SenatVal[0,2-3]; 4;GovenVal[0-3]; 6; MayorVal[0-2...]; 8; PropVal[0-2]; EOR;

B.1 Conclusion. 61

The format contains many constants. Some of these may refer to a variablenumber followed by it’s value. For example, "6;Mayoral Race Value;". Ifthis is true, the behavior of the scanned barcode software may be unde-fined when a votes key (6 in the example) is used multiple times.

62 Printer Barcodes

Appendix C

Automated Input.

In this appendix has been described how Red team discovered this re-ally original attack through an iPod MP3 player used as input-device toVoting Machine (Hart eSLATE Direct Record Electronic Voting System)exploiting ballots and counters. The tactile input jack is a standard 3.5mmjack used in voting machines to plugging in jelly switches (Figure C.1).

Figure C.1: Jelly Switches.

Red Team discovered that the functionality of such devise could bemimicked through the generation of a specific audio signals. For instancethese devices (jelly switches) use an simply high signal on the left channelfor a click of the red button, and a high signal on the right channel for aclick on the blue (or sometimes green) button. The goal of this attack is toconnect to the input port a signal generator generating 1 Hz monophonicsquare wave in order to emulate the menu navigation of voting machineand eventually emulating the voting phase. Exploiting that, Red teamcreated several Python script that issue signal over typical 3.5mm audiocable to the input port. The scripts made are the following:

gen.py Generates access codes. gen.generate_code_table() will return ahash of access code:next access code, and gen(x, y) will return a listof y sequential access codes, starting with x.

64 Automated Input.

av.py The guts of the AIFF processing to simulate the buttons.

vote.py The good stuff, finally. You specify the contents of a ballot in avery simple text format (There is an example, ’101 layout.txt’, en-closed. It’s the layout of the Precinct 101 test data we have.) Youcreate a vote object with the ballot data file, and you can run the castmethod to cast a single vote. The method takes an access code anda tuple of ballot selections. To select a write-in candidate, just passin someone not in that category as an official candidate. Of coursethis will cause on error in categories with no write-in slot. The mul-ticast() method will cast multiple consecutive access codes’ votes. Ittakes an initial access code, and a number of votes to perform, andselections tuple, just like in cast().

Figure C.2 Shows an example how scripts work, producing the correctaudio file.

Figure C.2: Generating Audio File Example.

Analyzing fragments of code (Figure C.3) we can deduce that the codeassume that the red button is on the left and the blue one on the right. Fol-lowing the reading on Figure C.3 we can assert that: the symbol " *" means"pushing blue button", the symbol " -> " means "pushing red button" andthe symbol " _ " means "Spa" .

C.1 Conclusion 65

Figure C.3: Some Code Example.

It is interesting to realize how they have build the signal, they used aifcPython audio files libraries. Red team uses aifc’s functions setting thecommon audio parameters: setframerate(22050), setsampwidth(1) and set-nchannels(2). On the other hand they wrote the sound frame, modifyingsquare wave thanks "x7Fx81" ( -> ) , "x81x81" ( _ ) and "x81x7F" ( * ).

C.1 Conclusion

A voter who casts her ballot using automated input should be simplyenter the same value but with different meaning. In fact if the controls arenot proper implemented using that technique the voter (attacker) can ex-ploits concurrent vulnerabilities and counter upgrading, collecting morethan one ballot.

66 Automated Input.

GNU Free Documentation License

Version 1.2, November 2002Copyright c© 2000,2001,2002 Free Software Foundation, Inc.

51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

Everyone is permitted to copy and distribute verbatim copies of thislicense document, but changing it is not allowed.

Preamble

The purpose of this License is to make a manual, textbook, or otherfunctional and useful document “free” in the sense of freedom: to assureeveryone the effective freedom to copy and redistribute it, with or withoutmodifying it, either commercially or noncommercially. Secondarily, thisLicense preserves for the author and publisher a way to get credit for theirwork, while not being considered responsible for modifications made byothers.

This License is a kind of “copyleft”, which means that derivative worksof the document must themselves be free in the same sense. It comple-ments the GNU General Public License, which is a copyleft license de-signed for free software.

We have designed this License in order to use it for manuals for freesoftware, because free software needs free documentation: a free programshould come with manuals providing the same freedoms that the softwaredoes. But this License is not limited to software manuals; it can be used forany textual work, regardless of subject matter or whether it is published asa printed book. We recommend this License principally for works whosepurpose is instruction or reference.

68 Automated Input.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium,that contains a notice placed by the copyright holder saying it can be dis-tributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work underthe conditions stated herein. The “Document”, below, refers to any suchmanual or work. Any member of the public is a licensee, and is addressedas “you”. You accept the license if you copy, modify or distribute the workin a way requiring permission under copyright law.

A “Modified Version” of the Document means any work containingthe Document or a portion of it, either copied verbatim, or with modifica-tions and/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter sectionof the Document that deals exclusively with the relationship of the pub-lishers or authors of the Document to the Document’s overall subject (orto related matters) and contains nothing that could fall directly within thatoverall subject. (Thus, if the Document is in part a textbook of mathemat-ics, a Secondary Section may not explain any mathematics.) The relation-ship could be a matter of historical connection with the subject or withrelated matters, or of legal, commercial, philosophical, ethical or politicalposition regarding them.

The “Invariant Sections” are certain Secondary Sections whose titlesare designated, as being those of Invariant Sections, in the notice that saysthat the Document is released under this License. If a section does not fitthe above definition of Secondary then it is not allowed to be designatedas Invariant. The Document may contain zero Invariant Sections. If theDocument does not identify any Invariant Sections then there are none.

The “Cover Texts” are certain short passages of text that are listed, asFront-Cover Texts or Back-Cover Texts, in the notice that says that the Doc-ument is released under this License. A Front-Cover Text may be at most5 words, and a Back-Cover Text may be at most 25 words.

A “Transparent” copy of the Document means a machine-readablecopy, represented in a format whose specification is available to the gen-eral public, that is suitable for revising the document straightforwardly

C.1 Conclusion 69

with generic text editors or (for images composed of pixels) generic paintprograms or (for drawings) some widely available drawing editor, andthat is suitable for input to text formatters or for automatic translation to avariety of formats suitable for input to text formatters. A copy made in anotherwise Transparent file format whose markup, or absence of markup,has been arranged to thwart or discourage subsequent modification byreaders is not Transparent. An image format is not Transparent if used forany substantial amount of text. A copy that is not “Transparent” is called“Opaque”.

Examples of suitable formats for Transparent copies include plain ASCIIwithout markup, Texinfo input format, LaTeX input format, SGML or XMLusing a publicly available DTD, and standard-conforming simple HTML,PostScript or PDF designed for human modification. Examples of trans-parent image formats include PNG, XCF and JPG. Opaque formats includeproprietary formats that can be read and edited only by proprietary wordprocessors, SGML or XML for which the DTD and/or processing tools arenot generally available, and the machine-generated HTML, PostScript orPDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plussuch following pages as are needed to hold, legibly, the material this Li-cense requires to appear in the title page. For works in formats which donot have any title page as such, “Title Page” means the text near the mostprominent appearance of the work’s title, preceding the beginning of thebody of the text.

A section “Entitled XYZ” means a named subunit of the Documentwhose title either is precisely XYZ or contains XYZ in parentheses follow-ing text that translates XYZ in another language. (Here XYZ stands fora specific section name mentioned below, such as “Acknowledgements”,“Dedications”, “Endorsements”, or “History”.) To “Preserve the Title”of such a section when you modify the Document means that it remains asection “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the noticewhich states that this License applies to the Document. These WarrantyDisclaimers are considered to be included by reference in this License, but

70 Automated Input.

only as regards disclaiming warranties: any other implication that theseWarranty Disclaimers may have is void and has no effect on the meaningof this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, eithercommercially or noncommercially, provided that this License, the copy-right notices, and the license notice saying this License applies to the Doc-ument are reproduced in all copies, and that you add no other conditionswhatsoever to those of this License. You may not use technical measures toobstruct or control the reading or further copying of the copies you makeor distribute. However, you may accept compensation in exchange forcopies. If you distribute a large enough number of copies you must alsofollow the conditions in section 3.

You may also lend copies, under the same conditions stated above, andyou may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly haveprinted covers) of the Document, numbering more than 100, and the Doc-ument’s license notice requires Cover Texts, you must enclose the copiesin covers that carry, clearly and legibly, all these Cover Texts: Front-CoverTexts on the front cover, and Back-Cover Texts on the back cover. Bothcovers must also clearly and legibly identify you as the publisher of thesecopies. The front cover must present the full title with all words of thetitle equally prominent and visible. You may add other material on thecovers in addition. Copying with changes limited to the covers, as long asthey preserve the title of the Document and satisfy these conditions, canbe treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly,you should put the first ones listed (as many as fit reasonably) on the actualcover, and continue the rest onto adjacent pages.

C.1 Conclusion 71

If you publish or distribute Opaque copies of the Document number-ing more than 100, you must either include a machine-readable Transpar-ent copy along with each Opaque copy, or state in or with each Opaquecopy a computer-network location from which the general network-usingpublic has access to download using public-standard network protocolsa complete Transparent copy of the Document, free of added material. Ifyou use the latter option, you must take reasonably prudent steps, whenyou begin distribution of Opaque copies in quantity, to ensure that thisTransparent copy will remain thus accessible at the stated location until atleast one year after the last time you distribute an Opaque copy (directlyor through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of theDocument well before redistributing any large number of copies, to givethem a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document un-der the conditions of sections 2 and 3 above, provided that you release theModified Version under precisely this License, with the Modified Versionfilling the role of the Document, thus licensing distribution and modifica-tion of the Modified Version to whoever possesses a copy of it. In addition,you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct fromthat of the Document, and from those of previous versions (whichshould, if there were any, be listed in the History section of the Doc-ument). You may use the same title as a previous version if the orig-inal publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entitiesresponsible for authorship of the modifications in the Modified Ver-sion, together with at least five of the principal authors of the Doc-ument (all of its principal authors, if it has fewer than five), unlessthey release you from this requirement.

72 Automated Input.

C. State on the Title page the name of the publisher of the ModifiedVersion, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacentto the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giv-ing the public permission to use the Modified Version under theterms of this License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections andrequired Cover Texts given in the Document’s license notice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled “History”, Preserve its Title, and add toit an item stating at least the title, year, new authors, and publisher ofthe Modified Version as given on the Title Page. If there is no sectionEntitled “History” in the Document, create one stating the title, year,authors, and publisher of the Document as given on its Title Page,then add an item describing the Modified Version as stated in theprevious sentence.

J. Preserve the network location, if any, given in the Document for pub-lic access to a Transparent copy of the Document, and likewise thenetwork locations given in the Document for previous versions itwas based on. These may be placed in the “History” section. Youmay omit a network location for a work that was published at leastfour years before the Document itself, or if the original publisher ofthe version it refers to gives permission.

K. For any section Entitled “Acknowledgements” or “Dedications”, Pre-serve the Title of the section, and preserve in the section all the sub-stance and tone of each of the contributor acknowledgements and/ordedications given therein.

C.1 Conclusion 73

L. Preserve all the Invariant Sections of the Document, unaltered intheir text and in their titles. Section numbers or the equivalent arenot considered part of the section titles.

M. Delete any section Entitled “Endorsements”. Such a section may notbe included in the Modified Version.

N. Do not retitle any existing section to be Entitled “Endorsements” orto conflict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appen-dices that qualify as Secondary Sections and contain no material copiedfrom the Document, you may at your option designate some or all of thesesections as invariant. To do this, add their titles to the list of Invariant Sec-tions in the Modified Version’s license notice. These titles must be distinctfrom any other section titles.

You may add a section Entitled “Endorsements”, provided it containsnothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approvedby an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, anda passage of up to 25 words as a Back-Cover Text, to the end of the listof Cover Texts in the Modified Version. Only one passage of Front-CoverText and one of Back-Cover Text may be added by (or through arrange-ments made by) any one entity. If the Document already includes a covertext for the same cover, previously added by you or by arrangement madeby the same entity you are acting on behalf of, you may not add another;but you may replace the old one, on explicit permission from the previouspublisher that added the old one.

The author(s) and publisher(s) of the Document do not by this Licensegive permission to use their names for publicity for or to assert or implyendorsement of any Modified Version.

5. COMBINING DOCUMENTS

74 Automated Input.

You may combine the Document with other documents released un-der this License, under the terms defined in section 4 above for modifiedversions, provided that you include in the combination all of the InvariantSections of all of the original documents, unmodified, and list them all asInvariant Sections of your combined work in its license notice, and thatyou preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, andmultiple identical Invariant Sections may be replaced with a single copy.If there are multiple Invariant Sections with the same name but differentcontents, make the title of each such section unique by adding at the endof it, in parentheses, the name of the original author or publisher of thatsection if known, or else a unique number. Make the same adjustment tothe section titles in the list of Invariant Sections in the license notice of thecombined work.

In the combination, you must combine any sections Entitled “History”in the various original documents, forming one section Entitled “History”;likewise combine any sections Entitled “Acknowledgements”, and anysections Entitled “Dedications”. You must delete all sections Entitled “En-dorsements”.

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other doc-uments released under this License, and replace the individual copies ofthis License in the various documents with a single copy that is includedin the collection, provided that you follow the rules of this License for ver-batim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and dis-tribute it individually under this License, provided you insert a copy ofthis License into the extracted document, and follow this License in allother respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT

WORKS

C.1 Conclusion 75

A compilation of the Document or its derivatives with other separateand independent documents or works, in or on a volume of a storage ordistribution medium, is called an “aggregate” if the copyright resultingfrom the compilation is not used to limit the legal rights of the compila-tion’s users beyond what the individual works permit. When the Docu-ment is included in an aggregate, this License does not apply to the otherworks in the aggregate which are not themselves derivative works of theDocument.

If the Cover Text requirement of section 3 is applicable to these copiesof the Document, then if the Document is less than one half of the en-tire aggregate, the Document’s Cover Texts may be placed on covers thatbracket the Document within the aggregate, or the electronic equivalent ofcovers if the Document is in electronic form. Otherwise they must appearon printed covers that bracket the whole aggregate.

8. TRANSLATIONTranslation is considered a kind of modification, so you may distribute

translations of the Document under the terms of section 4. Replacing In-variant Sections with translations requires special permission from theircopyright holders, but you may include translations of some or all Invari-ant Sections in addition to the original versions of these Invariant Sections.You may include a translation of this License, and all the license noticesin the Document, and any Warranty Disclaimers, provided that you alsoinclude the original English version of this License and the original ver-sions of those notices and disclaimers. In case of a disagreement betweenthe translation and the original version of this License or a notice or dis-claimer, the original version will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Ded-ications”, or “History”, the requirement (section 4) to Preserve its Title(section 1) will typically require changing the actual title.

9. TERMINATIONYou may not copy, modify, sublicense, or distribute the Document ex-

cept as expressly provided for under this License. Any other attempt to

76 Automated Input.

copy, modify, sublicense or distribute the Document is void, and will auto-matically terminate your rights under this License. However, parties whohave received copies, or rights, from you under this License will not havetheir licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions ofthe GNU Free Documentation License from time to time. Such new ver-sions will be similar in spirit to the present version, but may differ in detailto address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. Ifthe Document specifies that a particular numbered version of this License“or any later version” applies to it, you have the option of following theterms and conditions either of that specified version or of any later versionthat has been published (not as a draft) by the Free Software Foundation. Ifthe Document does not specify a version number of this License, you maychoose any version ever published (not as a draft) by the Free SoftwareFoundation.

ADDENDUM: How to use this License for your

documents

To use this License in a document you have written, include a copy ofthe License in the document and put the following copyright and licensenotices just after the title page:

Copyright c© YEAR YOUR NAME. Permission is granted tocopy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.2 or anylater version published by the Free Software Foundation; withno Invariant Sections, no Front-Cover Texts, and no Back-CoverTexts. A copy of the license is included in the section entitled“GNU Free Documentation License”.

C.1 Conclusion 77

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,replace the “with . . . Texts.” line with this:

with the Invariant Sections being LIST THEIR TITLES, with theFront-Cover Texts being LIST, and with the Back-Cover Textsbeing LIST.

If you have Invariant Sections without Cover Texts, or some other com-bination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, werecommend releasing these examples in parallel under your choice of freesoftware license, such as the GNU General Public License, to permit theiruse in free software.

78 Automated Input.

Bibliography

[1] G.Gross. E-Voting backers claim successful election; Critics continueto be concerned. IDG News Service. Nov 3, 2004 .

[2] VerifiedVoting.org. Electin incidents project update. November 8,2004

[3] www.blackboxvoting.org .

[4] www.verifiedvoting.org

[5] www.verifiedvoting.org article.php ? id = 5203

[6] www.sos.ca.govelectionselections_vsr.htm

[7] E-Voting Security Security&Privacy

[8] The Machinery of Democracy: Protecting Elections in an ElectronicWorld, Page 8.

[9] http://www.wikipedia.org

[10] Analysis of Electronic Voting System, Tadayoshi Kohno, Adam Stub-blefield, Aviel D. Rubin, Dan S. Wallach. Proceeding of the 2004 IEEESymposium on Security and Privacy (S&P’04)

[11] M. Ben-Ari. Principles of Cocurrent and Distributed Programming.Second Edition.Addison-Wesley.

[12] Carriero, N. and Gelernter, D., Linda in context. Communications ofthe ACM, 32(4): 444-458, 1989.

80 BIBLIOGRAPHY

[13] Ciancarini, P., Tolksdorf, R., Vitali, F., Rossi, D., Knoche, A., Coordi-nating Multiagent Applications on the WWW: A Reference Architec-ture. IEEE Transactions on Software Engineering, 24(5): 362-375, May1998.

[14] Gelernter, D., Generative Communications in Linda. ACM Transac-tions on Programming Languages and Systems, 7(1), January 1985.

[15] A. Omicini, F. Zambonelli. Coordination for Internet ApplicationDevelopment. Autonomous Agents and Multi-Agent Systems, 2,251Ð269 (1999)

[16] Ciancarini, P. (1996).Coordination models and languages as softwareintegrators. ACM Computing Surveys, 28(2):300Ð302.

[17] Gelernter, D. (1985).Generative communication in Linda.ACM Trans-actions on Programming Languages and Systems, 7(1):80Ð112.

[18] Gelernter, D. and Carriero, N. (1992).Coordination languages andtheir significance. Communications of the ACM, 35(2):97Ð107.

[19] Marco Cremonini, Andrea Omicini and Franco Zam-bonelli.Coordination and Access Control in Open DistributedAgent Systems: The TuCSoN Approach

[20] Ciancarini, Paolo and Omicini, Andrea and Zambonelli,Franco.Intelligent Agents VI. Agent Theories, Architectures, andLanguages.6th International Workshop (ATAL’99), Orlando, FL,USA.

[21] Omicini, Andrea AND Zambonelli, Franco AND Klusch, MatthiasAND Tolksdorf, Robert.coordbook2001-preface.

[22] Jonathan Bannet, Davis W. Price, Justin Singer, and Dan S. Wallach.Hack-a-Vote:Security Issues with Electronic Voting System

[23] Michael R. Clarkson, Stephen Chong, Andrew C.Myers. CIVS: A Se-cure Remote Voting System.

BIBLIOGRAPHY 81

[24] Davis Amurao. Computerized Voting: Problems and Solutions.

[25] Chris Armen, Ralph Morelli. E-Voting and Computer Science.

[26] Earl Barr, Matt Bishop, and Mark Gondree. Fixing Federal E-VotingStandards.

[27] Thomas W. Laurer. The Risk of E-Voting

[28] Arthut M. Keller, Davis Mertz, Joseph corenzo Hall, Arnold Urken.Privacy Issues in an Electronic Voting Machine.

[29] Bertrand Haas. Engineering Better Voting Systems.

[30] Joshua Gaines. Democracy’s Downfall:Is the Computing Technologyfor Electronic Voting Secure and Reliable Enough for National Use ?

[31] Rebecca Mercuri.Voting-Machine Risks.

[32] Alan Agresti and Brett Presnell (2002). Misvotes, Undervotes andOvervotes: The 2000 Presidential Election in Florida. Statistical Sci-ence, 17(4):436Ð440 (Voting and Elections, November 2002). Instituteof Mathematical Statistics.

[33] Jonathan N. Wand, Kenneth W. Shotts, Jasjeet S. Sekhon, Jr. WalterR. Mebane, Michael C. Herron, and Henry E. Brady (2001). The But-terfly Did It: The Aberrant Vote for Buchanan in Palm Beach County,Florida. American Political Science Review, 95(4):793Ð810 (December2001).

[34] United States: 107th Congress (2002). Help America Vote Act of 2002.Available at http:www.fec.govhavalaw_ext.txt.

[35] Election Data Services (2004). Overview of Voting Equip-ment Usage in United States, Direct Recording Electronic(DRE) Voting. Statement of Kimball Brace to the United StatesElection Assistance Commission, May 5, 2004. Available athttp:www.electiondataservices.comEDSInc_DREoverview.pdf.

82 BIBLIOGRAPHY

[36] Bev Harris (2004). Black Box Voting: Ballot Tamper-ing in the 21st Century. Talion Publishing. Available athttp:www.blackboxvoting.orgbook.html.

[37] Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin, and Dan S.Wallach (2004). Analysis of an Electronic Voting System. In Proceed-ings of the 2004 IEEE Symposium on Security and Privacy. IEEE Com-puter Society Press.

[38] Diebold Election Systems. Welcome to Diebold Election Systems.http:www.dieboldes.com as of January 24, 2004. Archived copy avail-able at http:web.archive.orgweb20040209133249www2.diebold.comdieboldesdefault.htm.

[39] Science Applications International Corporation (2003).Risk Assessment Report: Diebold AccuVote-TS VotingSystem and Processes, September 2, 2003. Available athttp:www.elections.state.md.uspdfrisk_assessment_report.pdf(retrieved on November 14, 2007).

[40] Warren D. Smith (2000). Range Voting. Available athttp:math.temple.eduw̃dshomepagerangevote.pdf (retrieved onDecember 13, 2007).

[41] Ka-Ping Yee. Building Reliable Voting Machine Software.

[42] http:www.sos.ca.govelectionsvoting_systemsttbrred_hart_final.pdf

[43] http:www.sos.ca.govelectionsvoting_systemsttbrred_diebold.pdf

Thank You Folks !

Finally, with a totally informal and colloquial language I wanna saythank you to all my folks. It’s really complicated remember everybody andit’s even more difficult saying in which way they have been contributing tothis work. So lemme say thank you to my family, you know ... , the familyis where everything started. Thank you to my advisors, Franco and Mattthat have believed in this really innovative research field. Thank you tomy italian friends, Ross, Ambra, Ila, Sara, Macanik, Stefano, Nicola, Cescoand Manuel (..) for the always warm friendship though the huge distance.Thank you to my American friends, Ryan, Katie, Ann, Brant, Karen andMalcom Bont; they helped us to build a new life in the U.S. Thank you toLavinia, of course, she followed my crazy idea to move in U.S for a while.And last but not least thank you to Marco Prandini who really helped mein all my works.

designing a new electronic voting system - unibo.itdeisnet.deis.unibo.it/nsl/thesis.pdf · 4.3...

Documents