Electronic voting system security

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

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

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 ﬂag. 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 undeﬁned. 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

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 ﬁles. 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

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

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
etal., 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

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

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

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

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

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

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

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

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 ﬁles.
5. The Staging Servers are the vote tabulation servers which connect to the AMS messaging
services to periodically retrieve votes.

14

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

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

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 ﬂorida voting systems. 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 efﬁciency 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

QUILTER, L. Everest: Eval- uation and validation of election-related equipment,
standards and testing (academic ﬁnal report), Dec. 2007.
16. NORDEN, L., AND LAZARUS, E. The machinery of democ- racy: Protecting elections
in an electronic world: Brennan center 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 assessment 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.
Deﬁnition and analysis of election processes. 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

Electronic voting system security

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (10)

Ähnlich wie Electronic voting system security

Ähnlich wie Electronic voting system security (20)

Mehr von Adeel Javaid

Mehr von Adeel Javaid (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Electronic voting system security