Designing A New Electronic Voting System

(1)

ALMA MATER STUDIORUM - UNIVERSITY OF BOLOGNA SEDE DI CESENA

SECONDA FACOLTÀ DI INGEGNERIA CON SEDE A CESENA CORSO 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

(2)

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 Docudocu-mentation License, version 1.2 or any later version published by the Free Software Foundation, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the appendix entitled GNU Free Docu-mentation License.

(3)

Keywords

Security, Security Engineering, Security Models Electronic Voting System, EVote, US - Elections Vulnerability, Assessment and Penetration Testing

(4)

(5)

Learning is one experience: all the other is only

information

(6)

(7)

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, who has worked very hard during these months.

(8)

(9)

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 as a pen. . . 10

2.4 Direct Recording Electronic Machine with VVPAT security mechanism. . . 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

(12)

3.6 Glue Activity Diagram. . . 41

3.7 Central Server Activity Diagram. . . 42

4.1 Deduction Process. . . 46

(13)

Chapter 1 The Voting Paradigms

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

John Ensign

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

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

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

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

(14)

3. Accessibility. People who have disabilities that inhibit their using traditional mechanisms such as pencil and paper or hole punches can 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 balance with drawbacks. The one that concerns us in this work is the accuracy and proper 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, which can be verified without relying on intervening technology. Our problem is to 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 introduces more vulnerabilities that cannot be remediated.

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

The properties that an election process must meet are many. We focus on 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 invalid votes are discarded. here, "valid" and "invalid" mean conforming and not conforming to the laws governing legal ballot markings or representations.

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

(15)

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 in a particular way.

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

Our proposed architecture relies on a layer of central servers. These are connected to a layer of voting clients upon which voters cast their votes. The glue ties these together, and consists of a ballots repository among centrals servers and voting clients. Gates sit between the voting clients and the glue, and ensure only correct information passes between them. Additionally, the gates monitor connections to ensure the behavior of the voting clients and glue matches specification, and report any behavior that lies 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 setting up and running an election. The fourth and the fifth sections combine the architecture and process model, and study how well the result satisfies the above four properties, as well as what assumptions are necessary. We con-clude with an evaluation of the benefits and drawbacks of this architecture for electronic voting systems.

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

1.1 Background.

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

(16)

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

(17)

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 Voting System has introduced a new kind of insecurity aspect but it has deleted 3 important 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 Paradigm is a future concept of Voting System: the X axis is sorted by temporal logic. The General sets of problems detected are four: counting prob-lems,communication problems, written mistakes problems and computer science security problems. Every era owns paradigm and owns problems set. For instance: the Signs era had counting problems, it was difficult to count hundred 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 and Hands Voting System have just one insecurity problems set, instead a Pa-per Voting System has at least three insecure problems sets. The paradigm shift from Hands Voting System to Papers Voting System has been caused from the voters population growth whereas, at the present time, velocity and safety are so important that have driven a new paradigm shift from Papers to Electronic. There are no reasons to came back from Electronic Voting System to Papers or Hands voting System, but there are a lot of security reasons to encourage a new Electronic Voting System Model in order to draw up Voting Systems to Digital era .

(18)

(19)

Chapter 2 The Standard

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

Anonymous

After the famous "butterfly election", November 2000 in Florida United States Of America [32, 33] where many of the punches cards disappeared, the American election system was pilloried on many fronts, especially for using an outdated counting mechanism. After that fiasco and pushed from citizen discontent, politicians and vote experts decided to change the vot-ing technology focusvot-ing on electronic votvot-ing systems. Two years later the US government passed the Help American Vote Act (HAVA) [34] giving hundreds of millions of dollars to the project of news electronic voting ma-chines. The companies used these dollars to build news machines under the HAVA suggestion (not standards yet) and during the 2002 some US state 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 Election System" (the old name of the current Diebold Election System) a hidden site which contains the source code of AccuVote-TS; the software used by Diebold to collect the ballots, presents in all Diebold voting machines[35]. Researchers and experts at Johns Hopkins University and Rice University examined this source code and published an important report where they assert the presence of many bugs which cause several catastrophes

(20)

vul-nerabilities [37]. They discovered that each voter was able to vote several times and was able to administrate the machine changing the counters, they asserted that no encrypted storage was performed and no minimal and elementary security stuff was implemented. Of course Diebold claims that its system was the "state-of-the-art" of reliability, accuracy and secu-rity [38]. Third part secusecu-rity laboratories have been dragged in this anal-ysis, Science Applications International Corporation (SAIC) and RABA Technologies which wrote in late september 2003 and in early january 2004 [39,40] that Diebold voting machines was really dangerous for the entire election process. Despite that reports, during the U.S. general election in 2004, the govern decided to use the Diebold machines causing a big mass on election transparency. During the summer 2007 California Secretary of State decided to start a "top-down" review of the Californian’s voting Sys-tem, in which I had the opportunity to participate. The reviewers visited Diebold 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, electronic and software components working together in order to define ballots, cast and count votes, report eventually errors, report finals results and guaran-tee the safety, the privacy and the security of each polling. Historic voting machines are made by mechanical component and they print the results on final paper. Actually the voting machine’s trend is following the 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 used to define, cast and count ballots for this reason it is important to verify the security level that every voting machine has reached; a compromised vot-ing machine may compromise the whole election process hazardvot-ing to the

(21)

2.1 Voting Machines. 9

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

• Punch Card Machine. This kind of machine (Figure 2.1) was build-ing thinkbuild-ing at the currents computers systems able to read punched cards. The device appeared like a small clipboard-sized device where the voter punched holes in the card with a supplied punch device like a palm-pen. After the voting phase the voter placed the ballot in a ballot box made from the pooling director or he placed the ballot directly 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. The voter fills the ballot, usually filling a rectangle a circle or oval or com-pleting an arrow. After the refilling phase he puts the ballot under an optical scan sensor able to read the voter’s sign. The voting ma-chine uses the "dark mark logic" where mama-chine selects the darkest mark within a given set as the correct choices, understanding and counting the voting chose. An example of this technique is placed here: http:en.wikipedia.orgwikiPremier_Election_Solutions . Figure 2.2 shows one model of Optical Scan machine, voter puts the filled ballot on the bottom of the machine, the machine reads the paper-ballot and shows on display if the grabbed chose is correct. If the voter recognize him vote, he pushes on "OK" button and her vote will be stored. These machines store ballots image file in a (often) encrypted database placed on local hard disk.

(22)

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 to the machine. The Figure 2.3 shows the machine with the electronic pen place on the bottom left.

Figure 2.3: Electronic Voting Machine With Electronic Input Device as a pen.

• 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 of voting VVPAT machines but the most used print a human readable paper with the voter chose. The human voter understand if the vote has 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.

(23)

2.1 Voting Machines. 11

Figure 2.4: Direct Recording Electronic Machine with VVPAT security mechanism.

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

Figure 2.5: Direct Recording, early 1900s.

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

(24)

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, during the configuration phase in the early morning of the election day. The Figure 2.7 shows how DRE is user friendly and how intuitive is the voting phase using a touch screen with the candidates list.

2.2 De-Facto Standard: VVSG.

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

(25)

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 means organizing precincts, gather absentee and/or remote votes, prepare for voting the centrals, organize ballots, ballots images prepare people, places and be ready to count a the end of the election day. The Figure 2.8 shows how the current Administer Election is working on.

(26)

Grabbing the voters list, the blank ballots and collecting the filled ballot are actions designed in the following self-explaining diagram (Figure 2.9). It is pretty important underlining that the "Test Precinct equipment" state is a non safety test but just a working test. That means the tester does not test the correctness, the integrity, the safety and the security but he tests only if the machine is working. After the collection (last state Figure 2.9) the resulted artifact is the sum of Equipment, voter lists, ballot styles and/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 (Figure 2.10 and Figure 2.11) describe the main differences between Paper based and 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 been named "Wrap up voting" (on precinct). The same thing happens on the central where the precincts send reports, ballots, ballot images and/or precinct totals. The central job is to collect every precincts stuff analyze it, compiling general and official reports on the election and issuing the official centrals results. The Figures 2.12 and 2.13 show how it happens.

(27)

2.2 De-Facto Standard: VVSG. 15

Figure 2.9: Prepare For Election

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

(28)

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

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

(29)

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 tests on DRE voting machine. It produced a great book with over than 120 po-tentials attacks on voting system. In order to understand these different kinds of attack it is useful guessing the entire voting process as an infor-mation flow between vendor programmers and voters. Quoting the red team book :

(30)

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; the voter provides the voting machine with her choices; the voterÕs

(31)

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 a county tally center; from there countywide totals are reported to 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 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

(32)

pro-cess safe. Of course these are assumptions too big and intended to be easily 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 Red Team Map. The Insertion of Corrupt Software Into Machines Prior to Election Day, Wireless and other Remote Control Attacks, Attacks on Tally Servers, Mis-calibration of Machines, Shut off Voting Machine Features Intended to Assist Voters, Denial of Service Attacks, Actions by corrupt poll workers or others at the polling place to affect votes cast, Vote Buying Schemes and Attacks on Ballots or VVPT. Describing every detail on each attack topology is outside the goal of that Dissertation but providing a little taste to understand why it is 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 access can easily enter, and inserting malicious code inside the voting machine. Every installed malware may change the ballot, change the result and/or the vote and may send to remote attacker the final result and so for. Re-mote Wireless control often is very dangerous because the attacker may perform a remote attack being outside the voting place so no physical ac-cess is required. Using wireless PDA or a common WiFi phone allowing to access to the wireless networks, the attacker could enforce the machine to activate or to deactivate the voting software or a software attack program or can easily read the data recorded by the voting machine. Different kind of attacks should be performed on the tally servers, the central tabula-tors which calculates the total votes for a particular precinct. This kind of attack can be executed before and/or after the election day and it can reach directly the tally server’s database or it may reach the network data stored on database. Having access to database means change directly the total amount of votes; these kind of attacks may compromise the whole

(33)

Figure 2.14: Red Team Information Flow Map.

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

(34)

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

During last summer another great work on Electronic Voting Machine has been done in California. The California Secretary of State entered into a contract with the University of California to test the security of some electronic voting systems as part of her Top to Bottom Review.

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

2.3.1 Diebold Voting Machine: Discovered Vulnerabilities

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

(35)

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

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

AV-TSx. The AV-TSx (AccuVote-TSx Ð also referenced throughout this document 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) to store configurations and election definitions.

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

AccuFeed. The AccuFeed is used in a central count facility to feed paper ballots (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 GEMS server via a serial cable. It is used to encode the various smart cards used throughout the election process.

DigiPort Server II16. The DigiPort Server II16 is an intelligent network hub. 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.

(36)

For a more detailed list see the complete Report [43]. The GEMS server is used to create and menage all the aspects of an election, creating se-curity and administrative smart card upgrading election definitions on the other system’s components. It encodes the smart cards to be used by 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). It may be used to create paper ballots during the election.The smart cards programmed by GEMS server through the ST-100 are used to program the Voter Card Encoder, to access administrative functions an TSx, to start and to end the election day on voting machines and to accumulate results from the PCMCIA cards used in other machines, only if applicable. Every card is given to a voter who plugging the card into TSx will be able to cast her own vote. Alternatively the voter may receive a paper ballot which will be read by the AV-OS through the scanner or accumulated in order to be read at the central. At the end of the election day every TSx and AV-OS must transmit the results to GEMS servers using different types of communica-tion, including Ethernet Connection and Serial Modem Conneccommunica-tion, and every smart card must be sent to the central where they will be counted and 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 firmware version 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

(37)

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 mentioned in this thesis) where RT describes how the discovered vulnerabilities may affect an election. The first set of vulnerabilities have been founded in-side the GEMS server. GEMS server runs over a Windows 2000 without properly patches. Thank to these vulnerabilities RT was able to perform a successfully attack keeping the Windows Administrator’s rights. During this phase RT also realized that lots of Windows logging capabilities were disabled or enabled in very limited states in the configuration provided by Diebold. This means that most malicious actions taken by attackers would not be traceable. Moreover RT was able to figure out, thanks to Administrator privileges and network analysis that Diebold technicians created 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. With the Administration credentials RT was able to modify the entire database with no warnings changing the election’s results. Another set of prob-lems becomes from the very poorly implemented log system in the GEMS software. RT discovered a particular set of malicious executing actions path that are not tracked by GEMS. For instance the Administrator is able to change username and password without being tracked, this is a non-standard computing practice and it could be potentially used by a rouge administrator to implicate another GEMS user. Unfortunately the config-urations files are often free from control; in fact during the analysis of the configuration files, the RT discovered a format string vulnerabilities that, when exploited, caused an election to run smoothly on a TSx unit. When a 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 would be deleted. The voter is notified about the error via a series of incom-prehensible messages followed by this notification: "Your ballot has been cancelled". Using information gathered through Administration creden-tials RT was able to guess the network’s credencreden-tials for the networking hardware gaining direct access to the remote devices. This access

(38)

pro-vided to the attacker enough privileges to modify every machine’s setting including 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 in a typical office, RT was able to violate the hardware security reading and or writing the smart cart content. On one hand reading the memory con-tent means that the attacker can tally the votes building covert channel between him and the voters. On the other hand writing memory content means to manipulate software design, blocking the machine or installing malware. These scenarios may compromise an entire election. RT was able to perform local privileges escalation thanks to leak founded into polling place devices. This vulnerability allows a voter to reset an election or to send the collected votes via modem to a remote machine. Others problems come from TSx default key; RT verified that a previously-identified static key was still in use on the system. If election officials opt to use the static keys, or if they forget to change them, the TSx units display a particular icon on the screen to warn that the keys in use are insecure. A possible attacker could observe this icon and use the information being leaked by the TSx unit to craft more specific attacks for the system. These and oth-ers attacks can be used to perform numerous attack scenarios described on original report [43]. The aim of this work is not to describe the attack scenarios that can use previous vulnerabilities exploiting the system in or-der to compromise the election; for this reason is suggested as a great and pretty instructive reading the public report available on public California State 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 auditing mechanisms.

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

(39)

Figure 2.16: Hart Voting Machine.

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

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

BOSS. Ballot Origination Software System software application (BOSS) is used 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 application that reads and writes a Key ID, Key GUID, and a signing key to an eCM.

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 terminal that voters use to cast their ballots electronically.

(40)

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

MBB. The Mobile Ballot Box (MBB) is a PCMCIA storage card used to store information about the election, including ballot definitions and cast ballots.

Rally. Used in the voting locations to total the ballots from the MBB and communicates 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 is also used to perform backup of JBC.

Tally. The Tally application directly reads Mobile Ballot Boxes (MBBs) that were produced by BOSS and populated with voting data from Hart Voting System equipment and indirectly reads MBB data transmitted by the Rally application installed at remote locations for tabulation. For a more detailed list see the complete Report [42]. The eCM manager creates a cryptographic key, which will be used by various Hart InterCivic components throughout the course of an election The keys are loaded onto Spyrus USB cryptographic tokens.This key is used by the BOSS applica-tion to create an elecapplica-tion database containing all the details to run an elec-tion. After that, BOSS writes some MBBs, in relationship with the number of 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 be plugged inside another Hart component, an Error box will block the pro-cess. Of course every MBB are tracked by BOSS. SERVO is used to reset and re-encode the key into the eScan and into the JBC/eSalte units. When the MBB will be plugged inside one of these machines, the eSales is ready for 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 are tabulated by Tally, which will use the original key to evaluate the result. Assuming as a correct behavior, RD started a deep research on potential

(41)

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 other one 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 vulnerabilivulnerabili-ties discussed on the public doc-ument regard four different system components.The first category is on Windows Vulnerabilities: the Hart Election Management System Servers run on not patched Windows 2000 server and with insecure default set-tings. The second category is on eScan component. The Red Team located a vector for overwriting the eScan executable. Although the team did not have enough time to craft an exploit for altering the total votes, given more time, the team is confident that eScan vote tallying could be mod-ified maliciously. The team was also able to access device-level menus that should be locked with passwords but were not. This access could allow an attacker vector for altering configuration settings and/or execut-ing a denial of service on the eScan. Some of the findexecut-ings from previous studies on precinct count optical scanners were replicated on the eScan,

(42)

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 and required tools that could be found in a typical office. The third category is on JBC where RT verified previous findings on the JBC regarding ac-cess code generation and also discovered that a surreptitious device could issue commands that caused the JBC to authorize access codes. The last category is on eSlate machine.The eSlate provides a continual audio nar-ration of all on-screen events, including the entering of the access code and voter selections, and this audio is directed into attached headphones. The RT found that it was possible to remotely capture this narration Ð which includes an audio replication of each vote castÐ without any physical ac-cess to the eSlate. These vulnerabilities may cause some interesting attack scenarios that will compromise the security of a whole election system; for more 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 no general-trust-concept is needed. The presented model (after it will become an 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 to work.

(43)

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 or more complex systems, this is the main reason why coordination seems to be one of the most important problems to solve in computer Engineering [20,21]. Glue Meta Architecture is one of the most primitive coordination concept where each entity communicates through it using tuples by means of standard Linda primitives [12,13,14]. Client-Server and Pear-to-Pear are the most used communication paradigms on the world but they are not alone. Glue Meta Architecture is based on associative Blackboard[19]; every entity can communicate with others entities writing a tuple on the Blackboard 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 they must be coordinate in order to respect the question-answer protocol. In the Glue Meta Architecture this is not true. Entities are able to communicate whenever they want and they could not respect the question-and-answer protocol.

(44)

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

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

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

3. Coordination Rules. Rules defining the behavior of the coordination media 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 could be part of more high level process. It becomes easy to understand this idea 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 coordinator of human behavior inasmuch as it coordinates the traffic light. On the other hand entities like semaphore, monitors, channels, tuple centers and pipes are considerate coordination media. Coordination rules define the

(45)

3.2 Coordinator Examples. 33

behavior of coordination media or can be used in order to understand if a Coordination Entity respects them. Classical coordination laws exam-ples are: tuexam-ples, 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 center can 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 not pertaining 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 will be 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 carries the coordination’s information. For instance if we consider the Football team as our environment, the coach uses the "air" in order to coordinate the players’ training and the players use the "air" to improve their own practice, 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 in this scenario the "air" has been used from the team leader to coordinate the entire team. Another daily example comes out considering the sys-tem "tree". Under that environment we can assert that the roots are the growth coordinators for the system tree. In fact the roots may adjusting the lymph’s flow, coordinating the tree’s growth. As already mentioned the traffic lights is a coordinator for the traffic system as the policeman too. "Laws and rules" are the main coordinator artifacts of human life. In fact through "Laws and rules" humans must coordinate their behaviors. For

(46)

in-stance the law says that you cannot drive a car if you are under sixteen years 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 few examples of coordinators entities that you can find around yourself every day; inspiring to these scenarios the presented work wants to build a new Electronic Voting System fitting the most abstract assumptions.

3.3 Proposed Architecture.

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

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

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

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

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

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

(47)

3.4 Voting Machine Layer. 35

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

Figure 3.2: Glue Architecture on Voting Problem.

The Human Actor interacts whit Voting Machine selecting the right candidate, the Voting Machine does not store the fresh ballot but it send immediately the ballot to Glue. The Glue is able to understand, using a deduction process, if the machine is compromised. If the machine results safe, the Glue store the ballot in its memory. If the machine is not safe Glue is able to correct it. Central servers are able to count the ballot whenever they 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

(48)

Voting Machines has been named Voting Machine Layer. We can not as-sume Voting Machine as safe systems because it is really hard to monitor each single frame, thus Voting Machine Layer could not deemed safe. For this 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 to download boot loader and operative system from the Glue during the election day.

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

Figure 3.3: Voting Machine Architecture.

Dummies Machines as considered before, become Voting Machines only after a correct initialization phase where they are filled up with boot loader 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 keys exchange protocol as shown in Figure 4.3 . The security problems about the network safety and the operative system manipulation will be

(49)

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 it waits for the behavior stored inside an encrypted smart card. Only with smart card plugged inside, voting program can grab the ballot and send it immediately to Glue system where ballot will be stored.

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

Behavior is the most important concept to define in order to explain the Security of whole model. The security of Glue Architecture is based on Deduction Process that uses behavior to understand the safety of each machine. Smart card is the Voting Machine behavior cradle; it frames the three main functions that create behavior:

1. behavior. This is a designed function built in order to understand if in the machine is running a parasite process. We assume to know the Operative 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 Operative System Reverse Engineering.

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

The connection during the sending phase is covered by secure tunnel, so none could listen and replace the design pattern simulating a safe Voting Machine client. While the first two functions (1,2) are equals for each smart card, the third function could be personalized for a specific number of smart 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 and to send them to Glue. After the introduction of smart card, the main pro-gram finds the right functions and becomes able to use behavior. Behavior enables the others two functions, allowing the communication between Voting Machine and Glue, only if it recognizes the entire system.

(50)

Figure 3.4: Voting Machine Activity Diagram.

3.5 Glue and Gate Layer.

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

(51)

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 the service or the network working-load.Glue is the repository of safe Boot Loader and safe Operative System. Every machine able to communicate through the Gate with secure tunnel can download them. Each Voting Machine sends ballot to Glue Through Gate. The Glue has the coordi-nator center capabilities and it store each correct ballot making available them for counting by Central Servers. Five services are effected by Glue as shown in Figure 4.5 :

1. Build an encrypted channel. This service (Fork_1) is useful in order to make a secure communication between Glue and Voting Machine. Every ballot sent from Voting Machine to Glue are protected, in this way 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 to download the safe boot loader. The presence of two Forks means that communication between Glue and Voting Machine is not safe during this downloading, thus an attacker could substitute the Boot Loader or even installs a different Boot Loader and Operative System into the machine. These events will be discussed later.

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

(52)

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 to send 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, Glue send a reboot signal to machine in order to correct the bad func-tioning. In order to understand why a simple reboot is enough to correct bad functioning, looking Security of Proposed Architecture paragraph.

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

Gates are the only way to access at Glue, they are a passive and not programmable entities. Gates have an important monitor job; only a write connection from Voting Machine to Glue and only a rebooting signal from Glue 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 candidate is collecting the major number of votes. In order to esteemed real time statistic Central Servers count, each quantum of time, the total amount of ballots contained in the Glue. Central Server Layer can wrap one or more 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. Every entity who wants communicate with Glue must build a secure channel. In fact, as shown in Figure 4.6, after the construction of secure tunnel Central Server is able to count the ballots from Glue.

(53)

3.6 Central Server Layer. 41

(54)

(55)

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 providing wrong final results.

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

(56)

(57)

Chapter 4 Security of Proposed Architecture.

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

Peter Neumann

Aim of this section is explaining, by attacks scenarios, how proposed architecture is able to detect corrupted machines and fix them without any recoil on the whole voting system. The reading key of attacks scenarios is Deduction 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 entities as Operative System, Memory Processes, Hardware and Machine Be-havior.

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

(58)

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

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

Each under-domain is atomic, that means it is not possible to complete Deduction Process without one of them. Figure 4.7 shows the three main phases of Deduction Process and how they are chaining together. Two kind of knowledge are present in this process: the basic one represented by What 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 to reach the right deduction. For instance if we know every Voting machine from a particular area must follow a predetermined patter in order to put its ballot on Glue, and the Glue observes a different designed pattern, we can deduce that Voting machine has been compromised. This was just an easy example in order to understand the primitive idea.

Figure 4.1: Deduction Process.

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

(59)

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 Loader and Operative System from Glue and only after this operation it builds a secure connection with Glue through own gate. During this initial phase someone 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, after the smart card introduction, the machine could not work. Smart mem-ory card has been designed in order to prevent this kind of attack so we can deduce that machine has been compromised because behavior does not recognize the right system. It became easy to understand if we think at memory processes. If we know Operative System, we know the run-ning memory processes during the voting phase. Smart Card Behavior is a function that knows them. When Smart Card plugged into Dummy Machine, it could not work because the Behavior function can not match the current memory processes, thus smart card does not offer the getVote and sendVote functions to eVoting Program. In this way Voting Machine is not able to grab the Vote. If attacker builds own voting program stored on downloaded OS, Voting Machine is not able to send the grabbed vote to Glue because it does not know the right matching pattern. So In both cases 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 bebe-havior is not recognized , using a deduction process we can deduce that machine has been compromised.

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

(60)

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 to work, you have just associated the two different problems. Most of break points are caused from software patches, updates, configuration files and elections definitions [8]. In Glue architecture every patches and every software update are stored into coordination center where is controlled and assumed safe. No update problems, no configuration files to set-up and no election definition; every machine during start-up phase down-load the last software version available. The only possible scenario is that attacker installs malware after the OS downloaded, in fact if the malware has been installed before start-up phase it will be overwrite. This is the reason why this attack must happen in the voting place (that should be guarded from police) and so it is considerate as difficult, but not impossi-ble, attack. There are a lot of possible scenarios where attackers want to install 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 one process) no additional hardware and so no additional software could be installed because behavior function blocks the gateVote and the sendVote phases recognizing a fake system.

(61)

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-to-Client who wants to talk with others Client-to-Clients must post a "post-it" on blackboard that is a coordination center and so able to manage mutual concurrence. The eVontig the scenario looks-alike, no one can talk directly with Tally Servers, every body must talk with Glue. Tally Servers have no services available, they just count, asking to Glue, 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 Glue architecture is a spread and distributed coordination system protected by gates. Every machine has own gate allowing voting machine to talk with Glue; if Voting machine has been compromised and shots lots of message to Glue it causes a self denial of service, saturating the own gate. Moreover Glue 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 cryptogracryptogra-phy is never leave alone but it is always accompanied by the right time session. So it becomes right to assume that cryptography is the right answer to reverse engineering problem. Build an encrypted smart memory card to prevent reverse engineering is not so difficult. We need a smart card encryption that resists until the day after election day and not more. At the end of election it results not important if an attacker can understand the behavior, inasmuch as during the next election period it will be essential building another smart memory card whit another behavior.

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

Designing A New Electronic Voting System

Designing A New Electronic Voting System

Thesis : Security System

Prof. Franco Callegati

Marco Ramilli

Prof. Matt Bishop

Session III

Keywords

Learning is one experience: all the other is only

information

Contents

List of Figures

Chapter 1

The Voting Paradigms

1.1

Background.

Chapter 2

The Standard

2.1

Voting Machines.

2.2

De-Facto Standard: VVSG.

2.3

Known Attacks.

2.3.1

Diebold Voting Machine: Discovered Vulnerabilities

2.3.2

Hart Voting Machine: Discovered Vulnerabilities

Chapter 3

Proposed Solution

3.1

Glue.

3.2

Coordinator Examples.

3.3

Proposed Architecture.

3.4

Voting Machine Layer.

3.5

Glue and Gate Layer.

3.6

Central Server Layer.

Chapter 4

Security of Proposed Architecture.

4.1

Compromised Boot Loader or Compromised

OS.

4.2

Malware and Hardware Installation.

4.3

Denial of Services Attacks and Attacks on Tally

Servers.

4.4

Smart Card Reverse Engineering.