Your SlideShare is downloading. ×
Electronic voting system security
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Electronic voting system security


Published on

The purpose of this paper is to examine the main security problems in electronic voting systems, particularly security threats to DRE voting systems and security threats to the Internet voting …

The purpose of this paper is to examine the main security problems in electronic voting systems, particularly security threats to DRE voting systems and security threats to the Internet voting systems. It will focus on how security problems can be addressed. The paper is divided into four parts. The first part will pinpoint the criteria of using electronic voting systems while focusing on the main security problems in DRE and Internet based voting systems and will suggest their solutions. The second and third parts will propose secure reference architecture for electronic and internet based voting systems while the last part will be the conclusion.

Published in: Technology, Business

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Electronic Voting System Security Muhammad Adeel Javaid Member Vendor Advisory Council, CompTIA Abstract: The purpose of this paper is to examine the main security problems in electronic voting systems, particularly security threats to DRE voting systems and security threats to the Internet voting systems. It will focus on how security problems can be addressed. The paper is divided into four parts. The first part will pinpoint the criteria of using electronic voting systems while focusing on the main security problems in DRE and Internet based voting systems and will suggest their solutions. The second and third parts will propose secure reference architecture for electronic and internet based voting systems while the last part will be the conclusion. Keywords: Electronic Voting System, Electronic Voting System Security, Internet Voting Introduction: One of the most significant current discussions in Computer Science is security in using electronic voting systems. These systems play a decisive role in democratic organizations and are a new technology which helps electors to cast their ballots in an election using computerized systems. There are different forms of voting systems. The first type is a punched card, introduced in 1980 (Lauer, 2004), which is a sheet of paper that contains perforated holes, used to store digital information. The second type is an optical scan system which uses an optical scanner to read and count votes marked on a paper ballot by colouring a circle with a pencil (Armen and Morelli, 2005), and was introduced in the 1960s (Lauer, 2004). One of the newest types of voting-counting system is a Direct- Recording Electronic Voting Machine (DRE) (Armen and Morelli, 2005). It is the first computerized system which enables voters to cast their votes using a touch-screen (Lauer, 2004). The final form of electronic voting is the Internet voting system which enables voters to cast their ballots from home or anywhere else using the web. With the rapid development of technology, the use of computers has become more convenient to make ballots through using different means such as the Internet, telephone and a private computer network. Such means offer a large number of advantages of using electronic voting systems such as precision in the voting process, quickness of implementation, accessibility for disabled voters (Bederson et al., 2003) and lack of sophistication. Despite these advantages, however, electronic voting systems have a number of limitations in security issues. It has been a controversial issue in democratic societies, because electronic voting can lead to electoral fraud as Lauer (2004) points out. 1
  • 2. Security Criteria for Electronic Voting Systems The objective of electronic voting is reliability and accuracy in recording electors‘ votes to make the voting process fair and transparent. Neumann (1993) suggests that electronic voting systems should follow some vital requirements in order to achieve the integrity of the election process; the first standard is that an elector should vote only once in each election. The second is that electronic voting systems should support an audit log containing the vote records to detect errors and modifications. The third standard is that voters‘ preferences should be confidential. The voting system should also be operable to accomplish tasks at the same time throughout the election process. The fourth standard is that voting systems should be protected from fraud and exchange. The last criterion is that the vote results should be recorded and shown precisely. Figure.1 below shows the architecture of an electronic voting system. Fig. 1 Electronic Voting System Architecture 2
  • 3. Security Problems Security Threats to DRE Voting Systems 1.1.1 The Diebold software The DRE system is manufactured by Diebold Corporation in United State. There are some security limitations of using DRE systems. One of the most serious weaknesses of the Diebold software is that the source code, which is a programme comprising a set of instructions written in computer programming languages, is not disclosed to the public (Garera and Rubin, 2007). The Diebold software is closed-source, which means that it has protected copyright and does not allow other programmers to modify it or examine it except the owner of the software. As a result, a serious problem with the Diebold software, which is used to conduct elections, is that the software may be exposed to a wide range of modifications by developers of the software to influence the voting process, raising concerns about the integrity of the voting results (PenhaLopes, 2005). Garera and Rubin (2007) note that releasing the source code to the public to detect errors or to know how the votes are counted is unacceptable by the owner of DRE systems, because they desire to retain copyright. Although the owners of the Diebold machines assert that the software is ‗‗reliable and secure‘‘ (Amurao, 2006, p. 2), there is still doubt that programmers of the Diebold code can manipulate the source code in support of a specific candidate through allowing to more votes to be counted (Amurao, 2006). In addition to above and upon reviewing the Diebold code, we observe that the smartcards also do not perform any cryptographic operations. This, in and of itself, is an immediate red flag. One of the biggest advantages of smartcards over classic magnetic-stripe cards is the smartcards‘ ability to perform cryptographic operations internally, and with physically protected keys. Because of a lack of cryptography, there is no secure authentication of the smartcard to the voting terminal. This means that nothing prevents an attacker from using his or her own homebrew smartcard in a voting terminal. One might naturally wonder how easy it would be for an attacker to make such a homebrew smartcard. First, we note that user-programmable smartcards and smartcard readers are available commercially over the Internet in small quantities and at reasonable prices. Second, an attacker who knows the protocol spoken between voting terminals and legitimate smartcards could easily implement a homebrew card that speaks the same protocol. Once the adversary knows the protocol between the terminal and the smartcards, the only impediment to the mass production of homebrew smartcards is that each voting terminal will make sure that the smartcard has encoded in it the correct m_ElectionKey, m_VCenter, and m_DLVersion. The m_ElectionKey and m_DLVersion are likely the same for all locations and, furthermore, for backward-compatibility purposes it is possible to use a card with m_ElectionKey and m_DLVersion undefined. The m_VCenter value could be learned on a per-location-basis by interacting with legitimate smartcards, from an insider, or from inferences based on the m_VCenter values observed at other polling locations. In short, all the necessary information to create homebrew counterfeit smartcards is readily available. 3
  • 4. When creating a secure system, getting the design right is only part of the battle. The design must then be securely implemented. We now examine the coding practices and implementation style used to create the voting system. This type of analysis can offer insights into future versions of the code. For example, if a current implementation has followed good implementation practices but is simply incomplete, one would be more inclined to believe that future, more complete versions of the code would be of a similar high quality. Of course, the opposite is also true, perhaps even more so: it is very difficult to produce a secure system by building on an insecure foundation. Of course, reading the source code to a product gives only an incomplete view into the actions and intentions of the developers who created that code. Regardless, we can see the overall software design, we can read the comments in the code, and, thanks to the CVS repository, we can even look at earlier versions of the code and read the developers‘ commentary as they committed their changes to the archive. Inside cvs.tar we find multiple CVS archives. Two of the archives, AccuTouch and AVTSCE, implement full voting terminals. The AccuTouch code, corresponding to AccuVote-TS version 3, dates from December 1998 to August 2001 and is copyrighted by ―Global Election Systems, Inc.,‖ while the AVTSCE code, corresponding to the AccuVote-TS version 4 system, dates from October 2000 to April 2002 and is copyrighted by ―Diebold Election Systems, Inc.‖ (Diebold acquired Global Election Systems in September 2001.) Although the AccuTouch tree is not an immediate ancestor of the AVTSCE tree (from the CVS logs, the AVTSCE tree is actually an import of another AccuTouch-CE tree that we do not have), the AccuTouch and AVTSCE trees are related, sharing a similar overall design and a few identical files. From the comments, some of the code, such as the functions to compute CRCs and DES, date back to 1996 and a company later acquired by Global Election Systems called ―IMark Systems.‖ The same DES key has been hardcoded into the system since at least the beginning of the AccuTouch tree. 1.1.2 Database of GEMS in Diebold DRE A Global Election Management System (GEMS) is the software which runs on Diebold DRE machines (Armen and Morelli, 2005). The GEMS software uses the Microsoft Access database as a Database Management System (DBMS) to store the votes (ibid). Armen and Morelli (2005) point out that the Access database used in GEMS has insufficient protection and is susceptible to hacking. The deficiency of security in the database of GEMS is thus a major problem with using the Diebold DRE machines. Ordinary or professional users can access the database through Microsoft Access rather than the GEMS software and tamper with voting outcome (ibid). Harris (2004) argues in his book ‗Black Box Voting‘ that using the Microsoft Access database to store the electro‘s votes can affect the level of security of the GEMS programme and the fairness of the voting process. It seems that the security feature of the database of the GEMS programme is deficient and vulnerable to a series of attacks. 4
  • 5. 1.1.3 Audit ability and Verifiability In traditional elections, using a paper ballot is the way that assures voters that their votes were calculated and as well as preventing tampering with the voting results. According to Jefferson etal. (2004), a common criticism of Direct-Recording Electronic (DRE) voting systems is that DRE systems do not include a Voter-Verified Audit Trail (VVAT) which is a printer used to print a paper-based record of the voters‘ selections (Balzarotti et al., 2008). The use of VoterVerified Audit Trails to verifying and auditing votes is a crucial factor to prevent an adversary from modifying and tampering with the voting outcome. Direct- Recording Electronic voting machines do not provide this a means (Amurao, 2006; Bederson et al., 2003). The lack of verification is therefore a major defect in DRE systems, because it is impossible to prove that votes have been counted as Bederson et al. (2003) state. For this reason it might lead to a security breach and as a result may reflect negatively on the integrity of the election process. According to Bederson et al. (2003, p. 146), there is concern about the credibility of DRE systems, because they are ‗‗paperless‘‘. Table-1 below summarizes some of more important attacks on electronic voting system. Table.1 Important Attacks on Electronic Voting System 1.2 Security Threats to Internet Voting Systems It is becoming increasingly difficult to ignore the importance of voting through the Internet. In spite of the fact that the Internet voting systems have a great number of advantages such as reducing cost, flexibility and convenience, there are several serious problems which can make democratic communities think twice before deciding to adopt Internet voting systems. This part will present effects of Denial of Service attacks, malicious software and spoofing attacks on these systems. 5
  • 6. 1.2.1 Denial of Service Attacks (DoS) A Denial of Service attack is an attempt by an attacker to make a server unavailable to using either temporarily or permanently (Lau et al., 2000). This type of attack aims to prevent legitimate citizens from accessing the election web through disrupting a host server through various ways of attacks as Jefferson et al., 2004 reveal. There are four patterns of Denial of Service attacks as Lau et al. (2000) show; the first type of attack is to flood the election web server with a series of messages to obstruct the network and prevent voters from accessing the election web. The second attack is to disconnect connections between two computers to prevent access the election web. The third attempt is to make the election web unreachable to a particular system or a legal user. The fourth attempt is to prevent a specific person from accessing the election web. Such DoS attacks can result in serious security problems and influence the justice of the election, as these attacks can prevent the electors from voting through making the election web server unreachable. The Internet voting systems can, therefore, be vulnerable to various malicious attacks. 1.2.2 Virus Infestation and Malicious Software Not only does a Denial of Service attack threaten democratic societies with electoral fraud, but malicious code, known as malware, also is one of the most serious security threats in using the Internet voting system. Malware is software designed to damage computer systems and most malicious codes are distributed through Trojan horses, viruses and worms (Jefferson et al., 2004). Some personal computers do not have sufficient security and are easily prone to virus infestation. According to Jefferson et al. (2004), there are two threats of malicious code for the Internet voting systems. The first threat aims to plant malicious software into the election web server by developers, designing the system, to destroy the vote data. The second threat is the distribution of malicious software into voters‘ computers, thus affecting the election process. Such malicious software may be difficult to detect it sufficiently, because some anti-virus programmes cannot detect new viruses; therefore, it can affect the voting process without the voters‘ knowledge. It does this by altering the electors‘ inputs or dropping their votes from the list of the vote or through preventing them from voting as Jefferson et al. (2004) note. The absence of sufficient security in the election web server and electors‘ computers within the election process raises concerns about the integrity of the vote when using the Internet. 1.2.3 Spoofing Attacks Another security challenge of using Internet voting systems is Man-in-the-Middle attacks, in which an attacker attempts to obstruct communication between a client and a server (Jefferson et- al., 2004). There are several methods for an adversary to become a Man-in-the-Middle; one of them is spoofing attacks, which deceive voters that they are communicating with the election web server. For instance, when a voter types the name of an official election website into a web browser, an attacker would redirect voters to another fake election web server. This attack would mislead voters that they are at a real voting website, consequently exploiting electors‘ votes to tamper with votes in favour of a particular preferred party (Amurao, 2006). Not only does a 6
  • 7. spoofing attack alter the voting data, but also it could result in an invasion of personal privacy through mining the personal information of voters, including their date of birth, name and signature. Solutions of Security Problems Now we will suggest the effective solutions for security problems of electronic voting system as given below:     The Use of Open-Source Software Using Voter Verifiable Audit Trails (VVAT) Using Layer (SSL) protocol Using a Digital signature scheme 1.3 The Use of Open-Source Software As already mentioned above, one of the major flaws in using electronic voting systems is that the type of software used such systems is closed-source, which has been generally criticized for inadequate security and reliability. As Penha-Lopes (2005) points out, using a closed-source code in proprietary electronic voting software is ‗‗highly questionable‘‘ (p. 412). It is, however, suggested that the use of open-source software may enhance some security limitations of electronic voting software as Armen and Morelli (2005) indicate. Open-source software refers to the source code which is released to the public to be examined and verified to design software based on their needs. For example, Linux is a common operation system which is built on opensource code. The purpose of the use of an open-source code is to build and develop security and reliability in electronic voting software, since an open-source code enables developers and experts to discover errors and modifications that may manipulate the voting results. Not only does open-source software improve the security and reliability in using electronic voting systems, but it also encourages the public to depending on electronic voting systems and building electors‘ confidence again in the electoral process (Parakh and Kak, 2007). It is tempting to think that the use of open-source software is the appropriate solution to such systems. Since there is no guarantee that the code source, which has been inspected, is the same code source used in electronic voting systems. It could, thus, be argued that exposure an opensource code for the public may lead to further problems. For instance, when a source code becomes disclosed, the public can recognise some shortcomings in a source code written. It may, in turn, be exploited by hackers to change and tamper with the software‘s code source. Rubin (2002) mentions an example illustrating that using an open-source code is vulnerable to be attacked. Back orifice 2000 (BO2K) is a computer software designed for controlling a computer from a remote location. This software is based on open-source code. Some attackers use this programme negatively to modify the source code to be difficult detection by protection software so that they can tamper 7
  • 8. with voters‘ inputs (Rubin, 2002). This may be evidence that an open-source code would be highly questionable. 1.3.1 Using Voter Verifiable Audit Trails (VVAT) As we have said above, the lack of a Voter Verifiable Audit Trail is one of the fundamental security problems of using electronic voting systems. A practical solution minimizing errors and tampering with the vote results is to provide a Voter Verifiable Audit Trail (VVAT), also known as a Voter Verified Paper Audit Trail (VVPAT), for electronic voting systems as Lauer (2004) and Karlof et al. (2005) suggest. A Voter Verified Paper Audit Trail (VVPAT) refers to a type of vote receipt printed by electronic voting systems to confirm that votes have been computed as they were entered (Balzarotti et al., 2008). The objective of VVAT in the electoral processes is to confirm and assure voters that their votes have been recorded correctly inside the system as they were entered (Karlof et al., 2005). Moreover, it is possible to return to a ballot box, where votes are placed, in case there is some doubt about the integrity of the electronic record (ibid). The use of VVAT can also preserve electors‘ votes as a backup paper system in case of exposure to attacks such as a DoS attack or even to recover from modifications in the voting results (Karlof et al., 2005). There is a current consensus that the use of VVAT method in electronic voting systems is the best form of verification of the voting outcome (Jefferson et al., 2004; Karlof et al., 2005; Lauer, 2004; Parakh and Kak, 2007). Bearing this in mind, using VVAT appears to raise concerns of relying on VVAT as proof if there is suspicion about the fairness of the election. This may result in a lack of trust in the ability of electronic voting systems to run the electoral process. It might, thus, shake voters‘ confidence in the credibility of the voting outcome. 1.3.2 Using Layer (SSL) Protocol As already stated above, the major problem that poses a threat to electronic voting systems is a Man-in-the-Middle attack which can impact negatively on the voting process. However, there is a possible solution, which may mitigate the threat of a Man-in-the-Middle attack, using the Secure Socket Layer (SSL) protocol (Jefferson et al., 2004). The SSL protocol refers to protecting sensitive data sent between a voter and a voting server over the network through the process of encryption (Wagner and Schneier, 1996). The key feature of using the SSL Protocol is to distinguish between a SSL election web and a non-SSL election web (Rubin, 2002). Encryption of data transmitted from a voter to a legitimate election web server is also one of the distinguishing features of using the SSL protocol (Hubbers et al., 2005). This data cannot, in turn, be disclosed by attackers, it is only between the voter and the voting server (Hubbers et al., 2005). It can be concluded that the aim of the SSL protocol is to prevent a third party from manipulating the voting outcome and to guarantee data integrity. Despite these advantages of using the SSL Protocol, however, it seems that the use of the SSL protocol is vulnerable to hacking through the decrypting of transmitted data as Jefferson et al. (2004) state. For example, a Man-in-the-Middle attack has the ability to be an SSL gateway, which connects computers, between a voter and an election web server (Jefferson et al., 2004); hence an adversary can convince victims that they are communicating with a legal election web server. However, using cryptographic methods such as the SSL encryption protocol to provide secure communication 8
  • 9. over a network is an insufficient solution to create trustworthy electronic voting systems. The voters have also the primary responsibility to know the difference between a legitimate election web server and a malicious server through noticing the web address. Most legal web servers use the Secure Hypertext Transfer Protocol (HTTPS) to encrypt and decrypt web pages in a browser. This may assist in raising the level of awareness of voters when typing a legal election web address in their browsers. As Rubin (2002) points out, most users have a lack of knowledge regarding recognising the types of web addresses. 1.3.3 Using a digital signature scheme As we have said above, one security limitation of Diebold DRE is that it uses Microsoft Access as a database for its software GEMS. One can gain access the database with ease. This may, in turn, be susceptible to hacking and compromise data integrity in election processes. Using cryptographic techniques as a digital signature scheme may be an appropriate solution to address the security problem, thus protecting input data in the database for the electronic voting systems (Ibrahim et al., 2003). A digital signature scheme is a type of cryptography used to authenticate that a digital document sent is digitally signed by a legal sender to convince a recipient that this signed document was entered by the legitimate sender (Juels et al., 1997). This scheme uses two types of algorithms. The first algorithm is the private key, which decrypts digital information or documents that were encrypted by the public key. The second algorithm is the public key, which is used to encrypt and verify digital information and documents in order to be decrypted with help private key (Juels et al., 1997; Ibrahim et al., 2003). The purpose of a digital signature is to verify that input data comes from an authorised voter and as a result prevent unauthorised users such as attackers or illegitimate voters, from accessing the election data centre and to guarantee the integrity of input data (Ibrahim et al., 2003). On the other hand, using a cryptographic digital signature scheme may only solve the problem of voter authentication, as this scheme helps to verify that a voter is an eligible as Ibrahim et al. (2003) note. But there is increasing concern about the secrecy of votes sent over the network. One security requirement that should be available in electronic voting systems to protect voters‘ privacy is confidentiality as Ibrahim et al. (2003) stress. Using a digital signature scheme is sufficient to prove that a voter is eligible, but is not adequate to remain electors‘ votes completely confidential. Ibrahim et al. (2003) indicate that one effective solution to protect voters‘ privacy is a blind signature scheme. The aim of a blind signature scheme is to conceal the content of a vote while verifying that the voter is legitimate (Ibrahim et al., 2003). Using both a digital signature scheme and a blind signature scheme may address the limitations of authentication and confidentiality in the electronic voting systems. 2. Secure Electronic Voting System Architecture Designing secure systems requires attention to many levels. Our approach begins by ensuring that there is no single point of failure after the ballot leaves the eyes of the voter. The security starts with the general system concept and goes down to specific ways that the code is written to avoid introducing reliability problems at any stage. The key advantage of this n- version architecture (Fig 2) is that structurally there is no way the whole system can be compromised without compromising a very significant number of the parts [T Selker and J Goler 2004]. 9
  • 10. The principle of redundancy is central. It enables the system to continue to work even if there is a failure somewhere along the line. Having multiple programs that process each stage of the ballot casting can establish improved reliability; regardless of how they are written, regardless of who has written them, and regardless of whether they are the same code. Because these versions can be transmitting over different networks, the system is more reliable. Because these are different programs, subverting one of them would not affect the others and still would ultimately enable an accurate vote to be cast. More importantly, if different people and organizations write these modules, intentional tampering of one module, such as putting in an Easter egg (a secret module of code that invokes undocumented functionality), would not affect the integrity of other modules. However, to be sure these new measures are effective; the system will have to be tested beforehand. By forcing each module to comply with the abstraction-function behavior that we specify, the architecture will be uniformly black-box testable. In addition, there must be no difference between a test vote and a real vote, as far as the software is concerned. In our system we separate the aspect of user interface from the rest of the voting system. The intent is to allow user- interface designers to build the best possible user interface for every type of user. A user who is blind might use a different interface from a user who has little motor control. However, we have dealt with a remedy to the possibility of a person entering an unintended vote. In an n-version user interface system, there could be a series of digital cameras that would snap digitally signed pictures of the ballot on the screen as a way of providing an additional audit trail independent of the rest of the system. Alternatively, different device drivers that read the screen could record their observation to provide the independent audit trails. Once the user has filled out the ballot, the next step is to authenticate the voter. A back-end system checks the person‘s name against a database of registered voters. The registration server signs the vote, along with various electronic witnesses which see only hashed data. The ‗witnesses‘ sign the vote to indicate that a valid voter, as assessed by the registration server, cast it. At this point the signed, blinded ballots are then sent to a variety of aggregation servers to be counted. 10
  • 11. Fig.2 Proposed Secure Architecture 2.1 Scope of Proposed Architecture The proposed e-voting system makes up a relatively small part of the whole election process. From a technical viewpoint the elections are made up of the following components:      calling of elections registration of candidates preparation of polling list voting (a subset of which is e-voting) counting of votes Figure.3 given below illustrates the scope as mentioned above. 11
  • 12. Figure.3 Scope of Electronic Voting System Design Elements of Secure Electronic Voting System 2.1.1 The User Interface Perhaps the most vital component of any voting architecture is the user interface. This architecture allows for the user- interface modules to be developed independently of the rest of the architecture. This flexibility permits faster progress incorporating human factors‘ research in improving the voting experience. Other work establishes user-interface quality assessment. This architecture recommends that all available effort be put into building a user interface that is extremely effective for efficient and accurate voting. The user interface takes two inputs — the interface definition and the blank ballot. Both of these components are XML documents. The interface definition describes the way in which the UI is to render a ballot. The user interface collects the votes of the user, as well as the registration data. It then encrypts the ballot using keys from the aggregators. The registration information is added to the encrypted ballots, and the resulting packages are then transmitted to the registration system. When the user approves the ballot, there will be an n-version type system of digital cameras mounted to the DRE that can take a picture of the ballot, or redundant device drivers that observe the actual ballot on the screen and record the contents. To prevent the production of an actual receipt, the picture can only include the ballot itself, and no other features, so that either the ballot is showing entirely or the ballot is obfuscated, so a user cannot put his or her face in the 12
  • 13. way, or put a piece of paper saying ‗Alice Bobster‘ in the way. Nevertheless, since the digital photograph back-up is not used as the primary counting mechanism, this problem is of little concern for coercion and vote buying. 2.1.2 The Registration System The registration system is the centre of this voting architecture. The registration server has access to the roster of all registered voters. When the registration receives a ballot package containing registration information and an encrypted ballot, it looks at the database, checks to see if the user is valid, and then makes an entry in the database checking off the user as having sent a vote to the aggregator. Each registration module extracts the encrypted ballot, signs it, and then sends it to the witness modules for their signatures. Once the witnesses return their signatures, the signatures can be appended to the encrypted ballot. Then the whole ballot package (without individual identifying information) is shipped off to the aggregators. 2.1.3 The Witness Module The witnesses are the simplest of the modules. They take as input an encrypted ballot and produce a signature. Signatures are produced using MD5/RSA. The ballot is digested, and a hash is produced, which when combined with the witness‘s private key, produces a number that, as far as we know, can only be produced by the holder of the private key. Witnesses do not maintain a record of the ballots coming through them, as they are meant to be lightweight implementations, preferably using separate databases or smart cards so they can be handled easily. Witness modules are to be provided by independent organizations (e.g. political parties, watchdog organizations). 2.1.4 The Aggregator Module The aggregator module takes encrypted ballot packages as input. The packages contain the encrypted ballot and a series of signatures produced by the registration system and witnesses. The aggregator parses the signatures and uses the witness public keys to verify the signatures. The aggregator then determines that a set threshold of signatures verify and then decrypt the ballot. Once the ballot is in plain text, the selections are parsed and recorded. Both the encrypted and plain text versions of the ballot will also be stored in a repository. 2.1.5 Messaging Protocol The messaging protocol is based on XML. Communication between modules is simple. The listening module waits for connections; the signalling module then initiates a socket connection, opens an output stream, then an input stream, and writes a string containing the command to the listening module. The module then does its processing and writes a string of commands indicating its response. The output stream is closed first, and then the input stream is closed. Standard sockets are used to connect between various components. The prototype 13
  • 14. implementation uses the Java Socket and ServerSocket classes that are conveniently provided by JDK 1.4. 2.2 Security and Reliability via Architecture The architecture of this system uses modularity and threshold agreement for fault and hack tolerance. Redundant audit trails enforce certain security and reliability. Modularity is an important cornerstone of any system that can be scrutinized. Each component we have developed is a few hundred lines at the most. And most of that is simply placing the data into a database. The tightness of the software code allows it to be quickly and easily certified to do what it is intended to do, for its compliance with the protocol that demands plug-and-play interaction with the rest of the architecture, as well as code that is easily viewed by outside agencies to determine its accuracy and correctness. Additionally, the separation into interoperable modules creates a voting system that could be modified in one aspect without affecting the certification of another aspect or component. This modularization dramatically lowers the cost in time and money for certification as systems are created and improved. The most important part of modularity, however, is that by separating the modules by steps we can analyze security in each stage. Each module keeps track of the other modules it is supposed to send and receive information from, as well as the public keys of those servers. Modules are defined by a contract that indicates what they are to send, receive, and process. By creating a standard contract, anyone can write to the standard and plug a module into the working environment. The architecture itself enforces security and reliability while improving maintainability. 3. Internet Voting Proposed Architecture Fig. 4 below shows a high level architecture of the proposed AMS system for internet based voting purpose. The proposed system can be viewed as a generalized messaging system which is able to deliver anonymous messages to a destination reliably; therefore the system is referred to as Anonymous Messaging System (AMS). Internet voting is a special application supported by the system. AMS is used to transport messages or votes in the context of Internet voting, through an Anonymous Peer-to-Peer Network (APN). It replaces a website voting server as the initial repository of the votes. It consists of the following components: 1. The e3 Secure Applet is the voting applet as shown in Figure.4 below. It is compiled with the AMS Sender. 2. The AMS Sender is a minimal Java implementation of the P2P network client. The Sender has a generalized interface that can be connected to other P2P networks. 3. The APN is a service provided by a number of established Internet-mounted computers, some of which are visible as seed nodes. The APN seed nodes are available to engage the AMS Senders from voter browsers. 4. The AMS Receiver is an application which polls the APN for vote files. 5. The Staging Servers are the vote tabulation servers which connect to the AMS messaging services to periodically retrieve votes. 14
  • 15. Figure.4 Proposed AMS System Architecture Voting with this system may occur in a number of ways, the most likley being: 1. Seed nodes of the APN which will be used by any AMS are chosen in advance. The IP addresses of these seed nodes are allocated at random and encoded into unique voter authentication credentials. 2. Voter authentication credentials are issued to voters via a non-Internet channel, such as registered paper mail, in person etc. 3. The voter is instructed to access a voting applet created for the election. The applet is placed in a large P2P cache site such as Coral. 4. The applet boots in the voter‘s browser and requests the authentication credentials. It obtains the one or a few APN seed node IP addresses from the credentials. 5. The applet guides the voter through voting. At the close of the session, the applet uses the AMS Sender to contact the allocated seed nodes. 6. The voter‘s vote is encrypted by the applet. A unique name for the vote file is derived from the access credentials. 7. The applet may try more than one seed node address. It inserts the vote file and reports back to the voter that the file was lodged on the APN. It may insert more than one copy of the vote file. 8. The applet issues the voter a receipt which can be used with an existing receipt checking service which is available after polling. 9. AMS Receivers poll the APN with the same file names as are created from authentication details by the AMS Sender. Distributing the task of collecting the vote over a number of hidden machines reduces the chance of a single failure affecting voting. The AMS Receiver servers do not need to be registered with 15
  • 16. the DNS and their locations on the Internet are much harder to determine that that of the current website voting server. AMS Receivers can also be configured to collect overlapping lists of votes, each of which is also inserted in duplicate. This also provides some resistance against incomplete or failed vote insertions or any loss in the APN. A collateral benefit of the APN is that it becomes much harder to find the voters. In a client/server arrangement, the client is connected directly to the server and so the IP address of the client can be recorded. If a voter has a fixed line DSL or cable connection to their home and their IP can be associated with their identity, then there is some likelihood that IP might provide for tying a voter to their voter by way of relating IP to time (In WWW logs) and time to vote in database logs. This becomes very difficult if there is an intervening APN. A second benefit of this model is that most APNs have state. This means that if the entire electoral board is challenged, votes can be retrieved from the APN directly if a court order can obtain the voter credential lists and the cryptographic key to decrypt votes. Whether actual voter identity it kept mapped to voter credentials depends on the jurisdiction of the vote. Conclusion The purpose of the current paper was to examine the main security problems of using electronic voting systems and the best solution for these problems. As mentioned in the introduction to this paper, using electronic voting systems may offer substantial benefits for democratic societies, although there are some security flaws in using these systems. It has been proposed that electronic voting systems should meet security requirements to make the voting process more secure, reliable and confidential. It should be noted that voting systems have inadequate protection that can be easily exposed to attack. This paper discussed different serious threats of denial of service attacks on voting systems. A Man-in the-Middle attack may also pose a particular challenge to voting systems. It can be seen that the database used in Diebold DRE is insufficient security. However, it has been argued that using open-source software for voting systems may overcome threats from software‘s developers and increase voters‘ confidence in relying on voting systems. It seems that cryptographic techniques such as a digital signature scheme may be immune from alteration and forgery in the voting results and may lead to significant improvements in the security of the database used in Diebold DRE machines. Using a blind signature scheme may be the best solution for confidentiality of electronic voting systems. It is suggested that a Voter Verifiable Audit Trail (VVAT) may be a fundamental element to improve the transparency and integrity of voting outcome. The e-voting architecture proposed in the paper provides a means to vote over open networks in a way that is reliable, secure, and private. Due to its modularity and common specifications, it is easy to implement, improve and it is inexpensive. The system uses COTS equipment for the all of the back-end systems, reducing the likelihood of fraud with the system components as well as keeping the cost down. These innovations make it particularly attractive for implementation within a limited budget option. 16
  • 17. References: 1. Trusted agent report: Diebold AccuVote-TS voting system. Tech. rep., RABA Technologies, 2004. 2. Races to watch: The senate. The New York Times (Nov. 2006). 3. Top-to-bottom review of california‘s voting systems. Califor- nia Secretary of State, Aug. 2007. 4. Software reviews and security analyses of florida voting sys- tems. Florida State University‘s Security and Assurance in Information Technology Laboratory, Feb. 2008. 5. Election operations assessment: Threat trees and matrices and threat instance risk analyzer (TIRA) (DRAFT). University of South Alabama for the U.S. Election Assistance Commission, Dec. 2010. 6. ANTONYAN, T., NICOLAOU, N., SHVARTSMAN, A. A., AND SMITH, T. Determining the causes of AccuVote optical scan voting terminal memory card failures. In 2010 Electronic Vot- ing Technology Workshop/Workshop on Trustworthy Elections, Washington, DC (2010). 7. BARR, E., BISHOP, M., DEFIGUEIREDO, D., GONDREE, M., AND WHEELER, P. Toward clarifying election systems standards. Tech. Rep. CSE-2005-21, Department of Computer Science, University of California at Davis, 2005. 8. T SELKER and J GOLER, The SAVE system—secure architecture for voting electronically, BT Technology Journal Vol. 22 No. 4 October 2004 9. BULDAS, A., AND MÄGI, T. Practical security analysis of E- Voting systems. In Advances in Information and Computer Security, A. Miyaji, H. Kikuchi, and K. Rannenberg, Eds., vol. 4752 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg, 2007, pp. 320–335. 10. CORDERO, A., WAGNER, D., AND DILL, D. The role of dice in election audits— extended abstract. IAVoSS Workshop on Trustworthy Elections 2006 (WOTE 2006) (June 2006). 11. HALDERMAN, J. A., RESCORLA, E., SHACHAM, H., AND WAGNER, D. You go to elections with the voting system you have: Stop-Gap mitigations for deployed voting systems. USENIX/ACCURATE Electronic Voting Technology Workshop (Aug. 2008). 12. HALL, J. L. Improving the security, transparency and efficiency of california‘s 1% manual tally procedures. USENIX/ACCURATE Electronic Voting Technology Workshop 2008 (July 2008). 13. HALL, J. L., MIRATRIX, L. W., STARK, P. B., BRIONES, M., GINNOLD, E., OAKLEY, F., PEADEN, M., PELLERIN, G., STANIONIS, T., AND WEBBER, T. Implementing Risk- Limiting Post-Election audits in california. Electronic Vot- ing Technology Workshop/Workshop on Trustworthy Elections 2009 (EVT/WOTE 2009) (Aug. 2009). 14. KOHNO, T., STUBBLEFIELD, A., RUBIN, A. D., AND WAL- LACH, D. S. Analysis of an electronic voting system. Pro- ceedings of the IEEE Symposium on Security and Privacy (2004), 27–40. 15. MCDANIEL, P., BLAZE, M., VIGNA, G., BUTLER, K., ENCK, W., HURSTI, H., MCLAUGHLIN, S., TRAYNOR, P., AVIV, A., ˇ CERNÝ, P., CLARK, S., CRONIN, E., SHAH, G., SHERR, M., KEMMERER, R., BALZAROTTI, D., BANKS, G., COVA, M., FELMETSGER, V., ROBERTSON, W., VALEUR, F., HALL, J. L., AND 17
  • 18. QUILTER, L. Everest: Eval- uation and validation of election-related equipment, standards and testing (academic final report), Dec. 2007. 16. NORDEN, L., AND LAZARUS, E. The machinery of democ- racy: Protecting elections in an electronic world: Brennan cen- ter task force on voting system security. Brennan Center for Justice at NYU School of Law, 2006. 17. PARDUE, H., LANDRY, J., AND YASINSAC, A. A risk assess- ment model for voting systems using threat trees and monte carlo simulation. In Requirements Engineering for e-Voting Systems (RE-VOTE), 2009 First International Workshop on (2009), p. 55–60. 18. RAUNAK, M., CHEN, B., ELSSAMADISY, A., CLARKE, L., AND OSTERWEIL, L. Definition and analysis of election pro- cesses. Software Process Change (2006), 178Ð185. 19. SALTER, C., SAYDJARI, O., SCHNEIER, B., AND WALL- NER, J. Toward a secure system engineering methodolgy. In Proceedings of the 1998 workshop on New security paradigms (1998), ACM, pp. 2–10. 18