Embed Size (px)
Citation preview
An Architecture For Electronic Voting
by
Clifford Allen McCullough
M.S., University of Colorado at Colorado Springs, 1991
B.S., University of Cincinnati, 1979
A Master’s thesis submitted to the Graduate Faculty of the
University of Colorado at Colorado Springs
in partial fulfillment of the
requirements for the degree of
Master of Engineering
Department of Computer Science
Fall 2012
This thesis for Master of Engineering degree by
Clifford Allen McCullough
has been approved for the
Department of Computer Science
by
____________________________________________________
Edward Chow, Chair
____________________________________________________
Xiaobo Zhou
____________________________________________________
Chuan Yue
__________________Date
ii
iii
McCullough, Clifford Allen (M.E., Information Assurance)
An Architecture For Electronic Voting
Thesis directed by Professor Edward Chow
This thesis proposes an architecture, publicly available, for a deployable system
that is compliant with United States Election Assistance Commission Voluntary Voting
System Guidelines requirements. An architecture is described and a demonstration
system built and evaluated.
The proposed architecture design decisions are based on two general rules of
Information Assurance: 1) Minimize the attack surface; and 2) Mitigate the
vulnerabilities. The web-based voting service should not be nationally centralized. The
system is kept server-centric rather than personal computer-centric. Servers interchange
information only after satisfying Kerberos mutual authentication. Redundancy and
restoring to the state before a fault are paramount. The homomorphic properties of block
Paillier and generalized Paillier cryptography are discussed and evaluated.
The demonstration system is a proof of concept for the proposed architecture.
Cryptographic algorithms for DES, AES, ElGamal, Paillier, and Shamir secret sharing
are demonstrated. Technical difficulties involving Kerberos library functions and
dynamic link library information interchange are overcome. The demonstration system is
not fully compliant with Voluntary Voting System Guidelines requirements. Much future
work remains to achieve that goal.
iv
ACKNOWLEDGEMENTS
This work used the EAS Data Center or EAS Cloud, which is supported by the
College of Engineering and Applied Science, University of Colorado at Colorado
Springs.
TABLE OF CONTENTS
CHAPTER
I. Introduction............................................................................................................12
II. Voluntary Voting System Guidelines Overview...................................................14
Functional Capabilities.....................................................................................14
Security......................................................................................................15
Accuracy....................................................................................................15
Error Recovery...........................................................................................15
Integrity......................................................................................................15
Vote Tabulating Program..........................................................................15
Casting a Ballot..........................................................................................16
Accessibility Requirements..............................................................................17
Security Requirements......................................................................................17
Maintaining Data Integrity........................................................................17
Independent Verification Systems.............................................................17
III. Existing Solutions..................................................................................................19
IV. Proposed Architecture...........................................................................................21
The General Schema.........................................................................................22
The System Architecture...................................................................................23
v
Web Server Redundancy...........................................................................23
Minimize the Attack Surface Area............................................................24
Layered Operating Systems.......................................................................25
Compiled Deployment...............................................................................25
Voting Server Authentication...........................................................................25
Issue Presentation..............................................................................................27
Verifying the Ballot..........................................................................................28
Casting the Ballot..............................................................................................28
Kerberos Mutual Authentication.......................................................................30
General Function Server...................................................................................30
Election Judges Workstation.............................................................................31
General System Redundancy............................................................................32
Paillier Cryptography........................................................................................32
V. The Demonstration System....................................................................................34
Development Platforms....................................................................................36
Voting Server Authentication...........................................................................37
Instructions, Issue Presentation, and Verifying the Ballot................................38
Casting the Ballot..............................................................................................38
The Issue Class..........................................................................................40
vi
The Crypto Class.......................................................................................41
The KTCP Class........................................................................................43
Public Key Server.............................................................................................44
Tally Servers.....................................................................................................45
Deploying the Website......................................................................................47
Election Judges Workstation.............................................................................47
Key Generation Program...........................................................................48
Shared Secret Decryption..........................................................................48
VI. Performance and Comparisons..............................................................................50
Cryptographic Methods....................................................................................50
Generalized Paillier Cryptography...................................................................52
Encryption Key Generation..............................................................................55
Ballots...............................................................................................................59
VII. Lessons Learned....................................................................................................61
Freeware............................................................................................................61
Internet Forums.................................................................................................61
Using Multiple Programming Languages.........................................................61
VIII. Future Work...........................................................................................................63
Web Site Development.....................................................................................63
vii
SQL Server Positioning....................................................................................63
General Functions Server..................................................................................64
Secret Share Encryption and Decryption..........................................................64
Paillier Key Generation.............................................................................64
Ballot Decryption.......................................................................................64
Shared Secret Decryption..........................................................................65
Ballot Tally Application............................................................................65
Error Handling and Logging.............................................................................65
Redundancy.......................................................................................................66
Tally Server Redundancy..................................................................................66
Ballot Generation..............................................................................................67
Multi-Lingual Database....................................................................................67
Precinct Ballots.................................................................................................68
Voter Password Handling.................................................................................68
Password Encryption.................................................................................68
Password Maintenance..............................................................................68
Quorum Login...................................................................................................69
Provisional Ballots............................................................................................69
Write-only Memory..........................................................................................69
viii
Fixed String Sizes.............................................................................................70
Kerberos Mutual Authentication.......................................................................70
Message Digest..........................................................................................70
Client Credentials......................................................................................71
Compilation and Linking...........................................................................71
Blocks versus Generalized Paillier...................................................................72
Platform Firewalls.............................................................................................72
Ballot Re-access Using the Back arrow............................................................72
IX. Summary................................................................................................................73
X. Abbreviations and Acronyms................................................................................75
XI. Works Cited...........................................................................................................77
APPENDICES
A. INSTRUCTIONS TO BUILD A DEMONSTRATION SYSTEM.......................80
B. INSTRUCTIONS TO RUN AN ELECTION........................................................82
C. TRIAL DATA........................................................................................................85
ix
LIST OF TABLES
Table 1. DES, AES, and ElGamal Methods.....................................................................51
Table 2. Block Paillier Method.........................................................................................52
Table 3. Block Paillier Method.........................................................................................53
Table 4. Generalized Paillier Method...............................................................................53
Table 5. DES and AES Key Generation...........................................................................56
Table 6. ElGamal Key Generation....................................................................................56
Table 7. Paillier Key Generation......................................................................................57
Table 8. Ballot Casting Times..........................................................................................60
x
LIST OF FIGURES
Figure 1. Proposed Architecture.......................................................................................22
Figure 2. Ignis 32-bit Development System......................................................................34
Figure 3. Prometheus 64-bit Demonstration System........................................................35
Figure 4. Example Ballot..................................................................................................40
Figure 5. Block Paillier Method.......................................................................................54
Figure 6. Generalized Paillier Method..............................................................................54
Figure 7. ElGamal Key Generation..................................................................................57
Figure 8. Paillier Key Generation.....................................................................................58
xi
CHAPTER 1
INTRODUCTION
Private elections for board of director offices or other business proxy votes have
traditionally been conducted using paper, mail-in ballots. Electronic or online voting is
becoming a popular alternative to paper ballots.
Public elections are the cornerstone of democracy. US citizens overseas or
military personnel deployed overseas currently may use a mail-in, absentee ballot system.
Yet, any mail-in ballot system is perhaps the least secure.
The vote can easily be sold because the voter possesses proof of how the ballot
was cast.
Personal identification of the voter is not required. Basically, only the signature
identifies the voter.
Public and private elections have different security requirements, though many
requirements are common. Whether voting at a polling location or voting after logging in
to an online voting website, the confidentiality and integrity of the vote must be
maintained. Requirements for private elections are governed by the organization hosting
the election. Requirements for public elections, in the United States (US), are governed
by the individual states following federal guidelines (EAC, 2010).
13
Many e-voting architectures are proprietary and are not released to the public for
general review (Jefferson, Rubin, & Simons, 2007). This thesis presents an architecture
for an on-line voting system that addresses the vulnerabilities of web-based voting. The
design presented is not a complete, ready to market solution. The time constraints of a
Master's Thesis do not allow for such an ambitious undertaking. This thesis demonstrates
and discusses the major elements of a web-based voting system, focusing on the
principles of Information Assurance.
In certain cases, this thesis uses specific terminology. A question to be voted
upon is called an issue. An item within an issue is called a candidate. For example, vote
for President, vote for School Board, or vote yes or no for a proposition are all issues.
The individuals running for President, the individuals running for School Board, or
indicating for or against a proposition are all called a candidate. The last example,
indicating for or against a proposition, is an odd usage, but consistent with the specific
terminology.
Chapter 2 of this thesis presents a summary of the requirements for an electronic
voting system. Chapter 3 examines some existing solutions and their problems. The
proposed architecture is discussed in Chapter 4 along with and the reasons for design
choices. Vevo, a working demonstration web-based voting system is presented in
Chapter 5. Chapter 6 includes performance data and is useful in deciding how the
demonstration system may be expanded. Chapters 7 and 8 discuss lessons learned and
potential future work. The thesis is summarized in Chapter 9.
CHAPTER 2
VOLUNTARY VOTING SYSTEM GUIDELINES OVERVIEW
The United States Election Assistance Commission (EAC) was established to
assist election officials share best practices and knowledge (EAC, 2010). The
commission offers Voluntary Voting System Guidelines (VVSG) as "a set of
specifications and requirements against which voting systems can be tested to determine
if the systems provide all of the basic functionality, accessibility and security capabilities
required for these systems." (EAC VVSG Vol I, 2010) The VVSG was used as a system
requirements guide for the design of the proposed architecture.
The remainder of this section provides a summary of the VVSG as it pertains to
this thesis. Only a few of the requirements are included in the summary. Most of the
summarized requirements are addressed by the proposed architecture. Some of the
summarized requirements are not included in the demonstration. But, they are discussed
and were included to illustrate the complexity of developing a complete and EAC
compliant voting system.
FUNCTIONAL CAPABILITIES
VVSG section 2.
15
Security
The system must guard against loss of system integrity, availability,
confidentiality, and accountability.
The system functions execute only in the intended manner and order, and only
under the intended conditions.
Provide safeguards in response to system failure.
Provide security provisions that are compatible with the procedures and
administrative tasks involved in operation.
Accuracy
Include logic and processing methods incorporating parity and checksums to
demonstrate that the system has been designed for accuracy.
Voting devices shall record and retain redundant copies of the original ballot
image. A ballot image is an electronic record of all votes cast by the voter.
Error Recovery
The ability to restore the system to the operating condition existing immediately
prior to an error or failure, without loss or corruption of data previously stored.
Integrity
Protect against a single point of failure.
Vote Tabulating Program
Register and accumulate votes.
16
Casting a Ballot
Protect the secrecy of the vote such that the system cannot reveal any information
about how a particular voter voted.
Record the selection and non-selection of individual vote choices for each contest
and ballot measure.
Record write-in votes.
Allow the voter to select his or her preferences on the ballot in any legal number
and combination.
Indicate to the voter when an insufficient number of selections has been made for
a contest (undervotes).
Indicate to the voter when more than the allowable number of selections have
been made for a contest (overvotes).
Notify the voter before the ballot is cast and counted of the effect of overvoting.
Provide the voter opportunity to correct the ballot for either an undervoted or
overvoted ballot.
Allow the voter, before the ballot is cast, to review the choices and, if the voter
desires, to delete or change the choices before the ballot is cast.
Notify the voter after the vote has been stored successfully that the ballot has been
cast.
Notify the voter that the ballot has not been cast successfully, and provide clear
instruction as to the steps the voter should take.
Provide a capability to retrieve ballot images in a form readable by humans.
17
Provide the ability for election officials to submit test ballots for use in verifying
the end-to-end integrity of the voting system.
ACCESSIBILITY REQUIREMENTS
VVSG section 3.
The voting system shall provide alternative languages accessibility.
The voting system shall be accessible for individuals with disability, including
non-visual accessibility.
SECURITY REQUIREMENTS
VVSG section 7.
Maintaining Data Integrity
Cryptography used to provide protection of data transmitted
over public telecommunications networks shall use NIST
approved algorithms with security strength of at least 112 bits.
Message Authentication Code (MAC) keys shall have a security
strength of at least 112 bits.
Independent Verification Systems
At least two cast vote records of the voter’s selections are
produced and one of the records is then stored in a manner that
it cannot be modified by the voting system. For example, the
18
voting system creates a record of the voter’s selections and then
copies it to unalterable storage media.
Voter Verifiable Paper Audit Trail (VVPAT) systems shall provide a
paper record of the ballot for the voter to review prior to casting
a ballot.
CHAPTER 3
EXISTING SOLUTIONS
There are a variety of private and public e-voting applications available.
(MotionVoter, 2011) and (Vote-Now) offer a private election service. SourceForge
includes a project which promises an open-source electronic voting system for download
(Electronic Voting System, 2009). Though when the web link was checked, the project
had no files available.
(Wilson, 2006) developed a web-based voting service. The service employs
Paillier cryptography and shared secrets. Information is passed between client and server
as XML serializations. The paper discusses and considers the considerable time required
to generate large safe primes. (Evecek, 2007) follows and expands upon this work and
includes pre-computation of safe prime numbers. Neither of these systems are a
complete architecture, compliant with VVSG.
The US Department of Defense’s Federal Voting Assistance Program (FVAP)
proposed an Internet based voting system for the 2004 primary and general elections
named Secure Electronic Registration and Voting Experiment (SERVE) (Jefferson D. D.,
Rubin, Simons, & Wagner, 2004). The FVAP assembled a Security Peer Review Group
(SPRG) to evaluate SERVE. Their report very strongly recommended against deploying
SERVE and SERVE was withdrawn from use (Defense, 2007, p. 11).
20
The SPRG report lists many security concerns regarding electronic voting in
general and Internet voting in particular. These areas of interest include:
Personal Computer (PC)-centric application versus Server-centric application.
Security of the intermediate network.
Voter-verified audit trail.
Control of the voting environment.
Spoofing and man in the middle attacks.
Denial of service attacks.
The ultimate objective of SERVE is to enable voting from any PC from anywhere
in the world (Defense, 2007, p. 11). The SPRG report did not expect that objective to be
accomplished anytime soon. However, this thesis proposes to make improvements
toward that objective.
Many e-voting architectures are proprietary and are not released to the public for
general review. This has the added disadvantage of providing the software with
insufficient scrutiny during certification. (Jefferson, Rubin, & Simons, 2007, p. 2).
CHAPTER 4
PROPOSED ARCHITECTURE
While designing the proposed architecture, the requirements summarized in
section Voluntary Voting System Guidelines Overview, page 14, were used as a guide.
Also influencing design choices were two general rules of Information Assurance:
1. Minimize the attack surface.
2. Mitigate the vulnerabilities.
Minimize the attack surface is rather self-evident. By reducing the opportunity
for attack, one reduces the number of successful attacks.
Mitigate the vulnerabilities involves evaluating the risk associated with an attack.
Risk is typically defined as the likelihood of something adverse occurring multiplied by
the severity of the consequences. (EAC Voting System Testing and Certification
Division, 2011) discusses how risk was evaluated and managed in various voting systems
around the world.
The proposed architecture is depicted in Figure 1.
22
Figure 1. Proposed Architecture
THE GENERAL SCHEMA
A web-based voting service should not be centralized. A centralized voting
service collects more votes in a single location and provides the adversary a greater
potential of influencing the election outcome from a single exploit. By distributing the
voting service away from a national level toward the state or even precinct level, the
potential severity of every system vulnerability is mitigated.
Perhaps the greatest vulnerability to public voting schemes is insider attacks
because an insider has access to the vote tally and thereby a greater number of votes.
Again, by decentralizing and distributing the voting service away from a national level
toward the precinct level, the potential severity of a system attack is mitigated because
fewer votes may be compromised at the precinct level versus the national level.
23
A precinct level voting service has increased tolerance to denial-of-service
attacks. To affect the election outcome, a larger number of sites must be attacked. Thus
the risk is reduced because the severity of any one attack is mitigated.
Place as little control of the ballot as possible in the hands of the voter. If the
voting application is PC-centric rather than server-centric, an adversary has a more direct
opportunity affect the voting application and thereby, to influence the ballot tally. The
proposed architecture keeps voter selections in the Session object. Thus, the voter
selections are stored in the server memory rather than transferred over the Internet
(Boehm & Murach, 2011).
The web application should be published and loaded on the web server as
compiled code rather than as source code such as what the web developer works with.
The adversary can more easily understand and alter the web application if the web server
is executing source code. Compiled code is more difficult to alter than source code.
THE SYSTEM ARCHITECTURE
Web Server Redundancy
To preclude a single point of failure, the architecture must have redundant
components. The requirement is very similar to a distributed web system composed of
multiple servers. (Cardellini, Casalicchio, Colajanni, & Yu, 2002) discuss three methods
of providing scalable and thus distributed web services on multiple servers.
First, their cluster-based web system employs a web-switch at the front end of the
cluster. This is basically the same as the Pound reverse proxy and load balancer (Pound).
Although the Pound application claims it can improve security, the web-switch approach
24
requires an additional layer of service that should not be necessary for a small system and
if not implemented correctly, can bottleneck the data flow (Cardellini, Casalicchio,
Colajanni, & Yu, 2002, p. 279).
Second, the virtual web cluster employs a single virtual Internet Protocol (IP)
address assigned to all servers in the cluster. Each node receives all inbound packets and
filters them to decide whether to accept or discard them. This approach requires
additional programming for one and only one of the redundant servers to accept the
client. Additional programming only adds complexity and increases the attack surface
area.
Third, the distributed web system incorporates an authoritative Domain Name
Service (DNS) server that distributes the load during the address resolution part of the
web-site name look-up. This method has the potential of creating a bottleneck at the
DNS server (Cardellini, Casalicchio, Colajanni, & Yu, 2002, p. 283). However, if the
voting system is deployed to the precinct level as discussed in section The General
Schema, page 22, the load on the server cluster should remain low. The distributed web
system approach provides the best approach for this architecture.
Employing the distributed web system, the Voting servers connect directly to the
outside world. The redundant DNS servers provide the authoritative DNS service to the
voters.
Minimize the Attack Surface Area
The outside world interacts with the voting system only through the Voting
servers. This minimizes the outside-world attack surface area. Behind the Voting servers
is a private network that should not be generally accessible. Comprising the private
25
network are the Kerberos realm administrator and Key Distribution Center (KDC), the
Tally, and the General Function servers. The General Function servers provide services
such as DNS and Network Time Protocol (NTP) to the private network. The voting
system must not have a single point of failure, thus all of the servers have redundant
counterparts.
Layered Operating Systems
The type of Operating System (OS) chosen for the servers provides a layered
defense. The first layer is a Microsoft (MS) operating system. The next layer are all
Linux operating systems. This reduces the likelihood of a vulnerability in the first layer
being used again in the second layer.
Compiled Deployment
The server programs should be developed on separate development systems then
uploaded to the server (see section The Demonstration System, page 34). This is done to
keep the deployed servers as free as possible from extra software that might allow
additional vulnerabilities. A voting system used in US elections would receive the
compiled server program from an Independent Accredited Voting System Test
Laboratory (VSTL) (EAC VVSG Vol II, 2010).
VOTING SERVER AUTHENTICATION
The Voting servers interact with the voting public, and thus, the outside world.
MS Web Server 2008 was chosen as the operating system. The more feature rich MS
Server 2008 was rejected because of its additional features - which would increase the
26
attack surface area. Further, the Server Core Installation option should be used rather
than the Full Installation option. The description provided by the Windows installation
window explains that the Server Core Installation is a minimal installation that reduces
the attack surface.
The Voting server authenticates the voter by checking the username and password
before allowing further access to the ballot. The username and password association is
kept in the redundant Structured Query Language (SQL) servers. The SQL database also
records whether a voter has successfully submitted a ballot and is therefore no longer
eligible for login. The system must include functionality for the redundant SQL servers
to update each other of voter login eligibility and not allow a voter to vote twice because
a server did not receive a synchronization update.
A fully functional, deployed system must also have a means of voters entering
their passwords and changing them periodically. Provisions to assist voters who have
forgotten their password and resetting a password must also be configured.
Other methods of authenticating a voter could be employed. For example,
Kerberos authentication. Kerberos has a built-in password encryption. However,
Kerberos does not have an associated data store that can indicate a voter has successfully
submitted a ballot and is therefore no longer eligible to vote. Changing and resetting a
password must also be configured with a redundant Kerberos-based authentication
system.
Using the user authentication included in the Web Server operating system was
also rejected. Voters should be allowed access to the web application, not the host
operating system. Voter authentication through the operating system would require
27
additional work to limit access of the voter to only the web application and thus increase
the attack surface area.
Thesis section Accessibility Requirements, page 17, relates to voter accessibility,
including requiring ballots in different languages. To facilitate multi-language ballots,
the wording of the ballot issues and candidate names, even the login screen, should be
obtained from a ballot database. The ballot database should reside in the SQL servers.
On the login page, the voter is presented with a choice of language. The instructions,
issue statements, even the navigation text, are then queried from the ballot database, and
presented to the voter in the chosen language. If a voter is sight impaired and cannot
benefit from larger text, audio transcriptions of the issue statements can also be queried
from the ballot database.
ISSUE PRESENTATION
Once the voter gains access to the ballot, the voter should be presented with
instructions and navigation links to the individual issues. The demonstration system
handles and records voter selections through a common Issue programming class. This
approach was chosen to increase the effort required for an adversary to impact the results
of a single issue and still be undetected. By making issue processing common, attempts
to affect the votes for the second candidate, for example, would affect the votes of the
second candidate of all issues. This should increase the likelihood of being noticed and
result in a full audit of the election process and results.
The voter selected information that represents a ballot should be stored in the web
Session object. As long as the voter web session remains active, the ballot information is
retained. If the voter abandons the session or logs out before the ballot is cast, the
28
Session object and thus the ballot information must be deleted. This reduces the chance
of an adversary masquerading as another voter.
VERIFYING THE BALLOT
After the voter completes all issues, a verification page should be presented based
on the information stored in the Session object. A verification web page presents the
voter's selection for each issue. If an issue is undervoted or overvoted, a warning should
be displayed in red lettering for the voter to see. The Instructions page should detail that
undervoting an issue is acceptable whereas overvoting an issue results in discarding that
issue's selections entirely.
This is another instance where a multi-language database should be employed.
By employing a database, the issue statements and candidate names presented on the
ballot would be obtained from the same source as the information presented on the ballot
verification. At least with a common data source, if a mistake is made in the ballot text,
the same mistake will appear on the ballot verification.
Reading the VVSG section 7 (EAC VVSG Vol I, 2010) implies a paper record of
the ballot is required in some form. This is contrary to the objective of this thesis to
provide a web-based voting application and was not implemented. If in fact a paper
record of every ballot is required as described in VVSG section 7, a fully web-based
voting application is not possible.
CASTING THE BALLOT
When the voter approves the ballot verification, the ballot must be encrypted,
assembled, and reliably transferred to all the Tally servers. This presents a design
29
dilemma similar in nature to an operating system writing to a file system - was the entire
operation successful or not? That is to say, did all the redundant Tally servers receive the
ballot and process it correctly?
One potential resolution is to employ three or more Tally servers in a voting
system. By using three servers, if one should become dysfunctional during the election,
redundancy is maintained by the remaining two. Employing four or more servers would
further fortify the redundancy. After the election is closed and the tallies should be
compared, the matching tallies of two or more servers should be accepted.
Another potential resolution is to only record that the voter has successfully voted
(and is ineligible to login again) if all Tally servers report success. If even one server
reports a failure, the voter is given a message that an error has occurred and asked to vote
again later. After the election, compare the raw (encrypted) ballot information and
discard ballots that are not present on all Tally servers. Since only success with all
servers accepts the ballot, any ballot not on all servers was not successfully recorded and
the voter was allowed to vote again. This way, only the final, successful ballot is tallied.
Though, this schema requires that all Tally server’s data is available at the end of the
election. If the one server that did not accept the ballot later crashes, the voter has been
allowed to re-vote, yet the original vote is not disqualified because the information
otherwise used to identify the original vote is lost on the crashed server.
Also note, the VVSG section 7.8.1 requires a record of the voter's selections be
stored on unalterable storage media (EAC VVSG Vol I, 2010, p. 177). This requirement
of the Tally servers could be implemented with a CD ROM or DVD if larger storage is
required.
30
The best alternative for storing a cast ballot, that meets all the requirements, is an
opportunity for further study.
After the ballot is successfully cast, provisions must be made to prevent the voter
from re-accessing the ballot, for example, by using the browser back arrow key. (Boehm
& Murach, 2011, p. 688) discusses this problem and how to deal with it.
KERBEROS MUTUAL AUTHENTICATION
When the various servers exchange information, their mutual identities are first
authenticated using Kerberos protocol. Microsoft Active Directory protocol can also be
used to authenticate principals. This would however require a Windows Domain
Controller in the second layer of operating systems (see section Layered Operating
Systems, page 25).
Kerberos was chosen for the demonstration system because it is open source and
because it can be hosted on a Linux server.
GENERAL FUNCTION SERVER
The General Function redundant servers provide services such as DNS, NTP, and
centralized storage of the cryptographic public key (see section Public Key Server, page
44). These three services were brought together because the risk presented by increasing
the attack surface area of the one server was deemed acceptable.
DNS is an integral part of Kerberos mutual authentication. The Key Distribution
Center (KDC) and Kerberos Application Program Interface (API) use DNS to verify the
correlation of a principal's name and the principal's IP address.
31
Kerberos tickets include time stamp and expiration information. The NTP service
provides a consistent time service to the private network. In many computer systems, a
network time service is synchronized with NTP servers available on the Internet. This
approach would require another link to the outside world. Alternatively, this outside link
can be provided by commercial products such as Global Positioning System (GPS)
receivers that provide high quality timing sources. The NTP service in the General
Function server could synchronize their clocks with the GPS receiver, then provide the
NTP function to the private network. In this manner, the system redundancy requirement
is met and the attack surface area is reduced because the General Function server does
not have additional links to the outside world.
ELECTION JUDGES WORKSTATION
The election judges platform is used to generate the public and private keys that
are used for encryption and decryption of the ballots. The platform is also used to
decrypt ballot tallies and obtain the election results.
Decryption of the ballots or tallies should employ shared secret security (Shamir,
November, 1979). This requires a quorum of judges to be present and to enter their user
name and password to unlock their secret share. Only when the minimum required secret
shares are unlocked are the ballots or tallies decrypted.
Note that the quorum requirement should not include all the judges for the
election. If, for any reason, even one judge is not available, (not to be morbid, but for
example, a judge dies) the ballots or tallies cannot be decrypted.
The election judges workstation can also perform administrative tasks on the
system as a whole. This being the case, in accordance with section Security, page 15, a
32
quorum login feature for administration would be useful. This feature would require a
quorum of judges to authenticate before any administrative tasks could be performed.
During the election, the workstation could be used as an error log terminal. Any
system errors, failed login attempts, or suspicious activity should be sent to the election
judges workstation for logging and presentation on the workstation console. The
workstation should be locked during the election.
If the election judges workstation is not used as a system log terminal, it should be
disconnected from the private network while the election is active.
GENERAL SYSTEM REDUNDANCY
Note that most of the data on redundant servers is static while the election is
active. Tally server data storage changes, but this was dealt with in section Casting the
Ballot, page 28. Only voter login eligibility changes throughout the voting time frame,
and thus, the redundant SQL servers update is critical.
PAILLIER CRYPTOGRAPHY
The cryptographic method chosen for this architecture is Paillier (Paillier, 1999).
The Paillier cryptographic method is homomorphic. This allows the plaintext to be added
by multiplying the cipher text. Thus, the ballots do not need to be decrypted to be tallied.
The Paillier method also allows for a message to be multiplied by a specially
treated random number and, without knowledge of the random number, still allows the
original plaintext message to be decrypted,. This is referred to as cryptographic blinding.
Thus, if two voters select the exact same candidates, the encrypted ballots will be
33
different even though the decrypted ballots will be the same. This mitigates known
plaintext attacks.
The Paillier method has another useful feature described by (Damgard & Jurik,
December 2000). Most cryptographic methods have a fixed plaintext block size that can
be encrypted. If the plaintext is larger than the block, multiple blocks must be encrypted
in ordered sequence. Using generalized Paillier, the block size can be extended in integer
multiples of the key size, allowing the plaintext larger than the key size to be encrypted
and decrypted as one unit. This is very useful if the ballot tally is to be performed by
multiplying the encrypted ballots - performing homomorphic operations on a segmented
ballot may not produce the expected result.
CHAPTER 5
THE DEMONSTRATION SYSTEM
The 32-bit demonstration and development system, also known as Ignis, is shown
in Figure 2. It includes components not needed, or wanted, in a deployed system but
necessary for development of the system programs. Figure 3 shows the 64-bit
demonstration system, also known as Prometheus.
Instructions for building a demonstration system are in Appendix A. Instructions
to run an election are in Appendix B.
35
Figure 2. Ignis 32-bit Development System
Figure 3. Prometheus 64-bit Demonstration System
36
In general, the demonstration system focused on demonstrating voting
functionality rather than system redundancy or complete security. Only the Tally server
function is redundant. Not all security measures or featured discussed in section
Proposed Architecture, page 21, were implemented.
The 32-bit development system was hosted on a Dell T310 server with a quad
core Intel Xeon x3430 processor running at 2.4 GHz and 12 GB of RAM. The
virtualization operating system was ESXi 5.0 from VMware (ESXi Info Center, 2012).
External to the virtualization system were two network data servers and a Dell XPS 410
tower running Windows Vista. The network data servers were used to transfer files
between the various computers and for system backup. The Windows Vista machine was
used to administer the virtualization system and the developement system.
The 64-bit demonstration system was hosted on the UCCS EAS Cloud. “EAS
Cloud is a collection HP, Dell, and Oracle (SUN) servers and storage platforms. It
utilizes both 10 GbE and 1 GbE network connections, and includes storage of Fiber
Channel, iSCSI, and NFS. VMware vSphere 5 is the hypervisor of choice and provides
users with a web portal to build and manage virtual machines, operating systems,
networks, and applications.” (EAS Cloud).
DEVELOPMENT PLATFORMS
For the 32-bit system, Basil, Peabody, and Merlose were the three development
platforms. Basil and Merlose were used to develop the Linux client and server programs
implementing Transmission Control Protocol (TCP) and Kerberized TCP (KTCP).
Peabody was used to develop the Windows client programs implementing TCP and
KTCP, the Paillier encryption and decryption algorithms, and the website program.
37
Each of the development platforms were configured to use Dumas as the NTP and
DNS server, and had Massachusetts Institute of Technology (MIT) Kerberos version 5
(krb5) installed.
In addition, the Linux platforms had KDevelop, g++, M4, and Multiple Precision
Integers and Rationals (MPIR) installed as development tools. KDevelop (KDE
Development Environment) is an Integrated Development Environment (IDE) that
functions very similar to Microsoft Visual Studio. The g++ program (GCC, 2012) is a
versatile C++ compiler. The M4 (GNU M4, 2011) library is required for MPIR. MPIR
(MPIR) was chosen for its ease of programming. MPIR includes C++ class objects and
works well on both Linux and Windows platforms.
The Windows 7 platform had MS Visual Studio (VS) 2010 Professional, Internet
Information Services (IIS) 7.0, SQL Server 2012, and MPIR installed as development
tools. Visual Studio (Visual Studio Editions, 2012) is a versatile IDE for Windows
platforms. It is able to compile a variety of programming languages including C# and C+
+, as well as building a web site. IIS 7.0 (IIS 7 Operations Guide, 2012) and SQL Server
(SQL Server, 2012) were necessary to develop the web site.
The 64-bit system was very similar to the 32-bit system with few exceptions.
Merlose was not installed.
The KDC and Tally servers did not have a second network interface.
There was no network accessible common storage.
Visual Studio 2012 Professional was installed on Peabody.
38
The Voting server could not be built as a 64-bit instance. The 32-bit virtual
machine was imported to the 64-bit system to provide a fully functioning e-vote
system.
VOTING SERVER AUTHENTICATION
The demonstration system uses the MS Web Server with full installation. As
discussed in section Voting Server Authentication, page 25, a more secure choice would
have been the server core installation to reduce the attack surface area. The full
installation, with a GUI interface, was chosen for ease of development and better
demonstration.
For the demonstration system, the SQL server function was moved to the Voting
server. D'Artagnan, the voting server, authenticates the voter by checking the username
and password before allowing further access to the ballot. The username and password
association is kept on D'Artagnan in an instance of Microsoft SQL Server 2012. The
SQL database also records whether a voter has successfully submitted a ballot and is
therefore no longer eligible for login. For ease of demonstration, the password is kept in
the database in plaintext. For a deployed system, the passwords should be stored
encrypted in some manner.
A fully functional, deployed system must also have a means of voters entering
their passwords and changing them periodically. Provisions to assist voters who have
forgotten their password and resetting a password must also be configured. None of
these features were developed in the demonstration system. These features remain for
future work.
39
Section Accessibility Requirements, page 17, discusses a multi-lingual ballot
requirement. The demonstration ballot is written in only one language. No ballot
database is implemented. The login page, navigation nomenclature, issue statements, and
candidate names are hard-coded into the ballot. Implementing these features remains for
future work.
INSTRUCTIONS, ISSUE PRESENTATION, AND VERIFYING THE BALLOT
Initial instructions, issue presentation, ballot verification, and navigation links are
written into the web site program. The web page presented to the voter includes a master
page with the navigation links. Instructions, issue presentation, and ballot verification are
content pages or sub-pages of the master page.
CASTING THE BALLOT
When the voter approves the ballot verification, the CastBallot web page is
loaded. The CastBallot web page is responsible for assembling the encrypted ballot and
transferring the encrypted ballot to the Tally servers. Only if both Tally servers report a
successful ballot receipt is the voter database updated to indicate that the voter should not
be allowed to login again. This is problematic in the case that the first Tally server is
successful but the second Tally server is not. This dilemma is discussed in section
Casting the Ballot, page 28.
The ballot is an assembled text string with each issue comprising one or two lines
within the total string. See Figure 4. Each line is composed of Comma Separated Value
(CSV) fields. An issue-selections line is constructed by concatenating the issue number,
a line-type indicator - B for ballot array, a value representing the Paillier block count (see
40
section Paillier Cryptography, page 32), and the encrypted candidate selection(s), all
separated by commas. A write-in-name line is constructed by concatenating the issue
number, a line-type indicator - W for write-in, the block count, and the encrypted write-in
name, all separated by commas. All the issue lines are terminated by a newline character
and concatenated to form the ballot string.
Figure 4. Example Ballot
The demonstration system includes three programming classes - Issue, Crypto,
and KTCP.
41
The Issue Class
The Issue programming class stores issue candidate checkbox values as a Boolean
array. Before a ballot is assembled, each issue is first checked for validity. If an issue is
found to be invalid, for example it was overvoted, the issue is not included in the ballot.
Note the following peculiarity of the checkbox values. If a voter includes a write-
in name, the write-in checkbox is asserted. This is in addition to the write-in name being
included in the ballot. Thus, for auditing purposes, the accumulated number of write-in
ballots should equal the count of encrypted write-in names.
For a valid issue, the Issue class Ballot method converts the checkbox values to an
integer array. A one for the array value indicates an asserted checkbox. A zero for the
array value indicates a non-asserted checkbox. For auditing purposes, an additional
integer array value is included. This auditing entry is placed after the last checkbox value
and always contains a one. Thus, the accumulated number of auditing entries should
equal the count of encrypted ballots for that issue, even if an issue is undervoted. For
example, if a voter does not assert any checkboxes for an issue, the issue will accumulate
no votes except for the auditing entry which is always a one. This auditing entry
facilitates accumulation of the total votes cast.
The converted integer array is then passed to the Crypto class for encryption. If a
write-in name is indicated for this issue, the write-in name is also passed to the Crypto
class. Note that a fully functional system may need more than one write-in name option.
The Crypto Class
The Crypto class uses Paillier encryption techniques (Paillier, 1999). The
advantages of using Paillier encryption techniques are discussed in section Paillier
42
Cryptography, page 32. Ballot selections come in two types: an integer array indicating
the voter's selection of a candidate, and write-in names. In either case, the Crypto class
creates a specially coded number that it then encrypts.
The Crypto class converts the integer array into a specially coded number
composed of fields of 32 bits for each array element. If the array element is a one, the
number one is placed in the field for that element. If the array element is a zero, the
number zero is placed in the field for that element. In this way, the entire issue can be
coded as a single number.
The following is an example in hexadecimal using 16-bit fields, with the fields
separated by spaces.
Assume the first voter selects the second candidate of four. The coded
number is then generated as 0x0000 0001 0000 0000 0001. Note the addition of
the audit field.
Assume another voter selects the first candidate of four. The coded number
is then generated as 0x0001 0000 0000 0000 0001. Again, the audit field is added.
To accumulate these two ballots, the coded numbers are simply added. The
resulting accumulation would be 0x0001 0001 0000 0000 0002. This indicates an
accumulation of one vote for the first candidate and one vote for the second
candidate and a total of two votes, which is correct.
As long as the total votes do not exceed the field size, accumulation remains
accurate. For the demonstration system, the field size of 32 bits allows a maximum of
232−1 total votes without loss of accuracy.
43
Write-in names are treated in a manner similar yet different from checkboxes.
The concatenated American Standard Code for Information Interchange (ASCII)
representation of the write-in name becomes the specially coded number. For example,
the name Bush becomes the number 0x68737542. Note that the name is backwards with
the last letter being at the most significant part of the coded number. This coding method
automatically creates a null terminated string and facilitates identifying the end of the
write-in name.
Whether generated from an issue array or a write-in name, the coded number is
encrypted using Paillier encryption. The demonstration system uses a 512 bit key. A 512
bit key with a 32 bit checkbox field allows for a maximum of 15 candidates on any issue
(plus one for the audit field), or a write-in name of 64 letters. Programming in the
demonstration web page limits the write-in text boxes to a maximum length of 64
characters. Also, the Paillier encryption algorithm will truncate the write-in name at 64
characters. If more than 15 candidates exist for an issue, or if a longer maximum write-in
name is required, generalized Paillier will easily accommodate the extension.
The largest integer available in normal programming is 64 bits. The Paillier
encryption operations involve integers of more than 1000 bits. Thus, special arithmetic
functions are required. The Paillier encryption functions are programmed in a Dynamic-
Link Library (DLL). This was necessary because the MPIR library used for the large
integer arithmetic is in the C++ programming language and the website uses the C#
programming language.
44
The KTCP Class
The second part of casting a ballot involves the Kerberized Transmission Control
Protocol (KTCP) programming class. The KTCP class Cast method first transmits the
ballot to Porthos tally server. If this information exchange is successful, Cast then
transmits the ballot to Aramis tally server.
The bulk of the KTCP protocol is programmed in a DLL. This was necessary
because the Kerberos API is in the C++ programming language and the website uses the
C# programming language.
KTCP_Send_Receive is the only function within the KTCP DLL used by the
website program. It accomplishes Kerberos mutual authentication, transmission of the
ballot string to the Tally servers, and receipt of the Tally server response.
Only if both Tally servers return an error free response is the ballot casting
considered successful.
The Kerberos version 5 library functions krb5_read_message and
krb5_write_message refused to link. I was forced to write my own versions of these
functions. Note that messages are not encrypted and no message digest is created or
verified. Further, when getting the initial credentials, the password is hard coded rather
than retrieved from a secure password store. Implementing these features is left for
future work.
PUBLIC KEY SERVER
Dumas served as the General Function server in the demonstration system. One
of those general functions was to provide a central point for the distribution of the
cryptographic public key.
45
The cryptographic public key is needed in two locations - at the Voting server to
encrypt the ballot, and at the Tally server to accumulate the ballot. Initially, the public
key was written into the server programs as a constant. This is not a useful design choice
for a deployed system since the programs would have to be recompiled each time the
encryption key is changed.
The public key is loaded into Dumas in a text file. The location of the text file is
compiled into the Public Key server program. When the program starts up, it reads the
public key from the file. If successful, the server program awaits a connection. If not
successful, the server program prints an error message and stops.
For exchanging the public key value, the Voting and Tally servers act as clients,
Dumas provides the service. Kerberos mutual authentication is used to ensure the correct
server and client are participating in the exchange.
The Tally server's interaction with the Public Key server is detailed in section
Tally Servers, page 45. The Voting server acquires the public key each time a voter
successfully logs in to the website. The only variable storage the Voting server program
has available is the Session object. Thus, the public key must be acquired for each
session. If a public key is not successfully obtained, the Voting server cannot encrypt the
ballot so the session is terminated immediately, before the voter spends time voting.
TALLY SERVERS
The Tally servers perform two very simple tasks - they collect the cast ballots and
tally the votes. The Tally server program is written in three parts. The first part fetches
the public key. Without the public key, the Tally server could collect ballots but not
46
tally, or accumulate votes. Therefore, if the public key fetch fails, the program prints an
error message and stops.
The second part of the Tally server program provides the service of listening for a
client connection. Kerberos mutual authentication is required to ensure ballots are only
accepted from authenticated clients. When a ballot is received, it is parsed. The ballot
consists of several text lines separated by the newline character. Each line consists of
Comma Separated Value (CSV) fields. The first field is the issue number. The second
field is an indicator that the encrypted information contains an issue-selection array or a
write-in ballot text. The next field is the Paillier block count. The last field is the
encrypted information.
All collected information is kept in a separate file-system directory named tally.
Issue information is kept separate by issue number. Up to three files may be created for
an issue - the collection of issue-selection arrays, the collection of write-in names, and the
accumulated issue tally. The file names begin with the word Issue, followed by a three
character representation of the issue number, for example Issue003 for the third issue.
Next is appended a single letter - A for an accumulation file, B for a ballot or issue-
selection array file, and W for a write-in file. If provisional balloting is added, the letters
P and V could be appended. P for provisional issue-selection and V or provisional write-
in ballots. This would create a total of five files for an issue.
When a ballot line is processed, its issue number is identified and its type is
identified. Write-in line-types are appended to the correct issue write-in file. Issue-
selection arrays are likewise appended to the correct issue array file. Issue-selection
arrays are also accumulated by retrieving the current tally from the correct issue
47
accumulation file. Utilizing the third part of the Tally server program, the new,
encrypted issue-selection array is added to the current tally to form the new total. This is
possible because of the homomorphic property of Paillier cryptography. The new total is
then written to the correct issue accumulation file.
The VVSG (EAC VVSG Vol I, 2010) requires that the system not have a single
point of failure (see thesis section Integrity, page 15). For this reason, the proposed
architecture includes two Tally servers.
VVSG section 7.8.1 also requires a record of the voter's selections be stored on
unalterable storage media (EAC VVSG Vol I, 2010, p. 177). This feature was not
implemented in the demonstration system. If such a feature were implemented, a CD
ROM or DVD could be employed. However, the technique described above of
separating the ballot lines into individual files would not be appropriate for this write-
only medium. Instead, the entire ballot string should be written separated by a record
indicator.
DEPLOYING THE WEBSITE
The website was developed on Peabody using Visual Studio. When the code was
ready for deployment, the Publish Web Site feature of Visual Studio was used to create a
compiled version of the website. The compiled code was then uploaded and installed on
D'Artagnan.
ELECTION JUDGES WORKSTATION
The election judges workstation was not implemented as a separate item in the
demonstration. Generation of the cryptographic public and private keys and decryption
48
of the ballots were accomplished on Peabody. System administrative functions were
accomplished by the Windows Vista computer through the Ignis vSphere-client and
Prometheus vCenter-client console functions.
Key Generation Program
The demonstration system cryptographic key generation program,
GenPaillierKeyShares, is not fully developed. Usernames and associated passwords are
incorporated into the output file from string array entries rather than being entered by
election judges. User passwords and key shares are not encrypted. However, the
program does demonstrate generating a Paillier public and private key and then
generating secret shares for the private key. A fully developed program is left for future
work.
The total number of shares is currently set at seven with a required quorum of
four. When the program is executed, two text files are created on the desktop -
PubKey.txt and PvtKey.txt. PubKey.txt is the public key, written in the format needed by
the Public Key server in Dumas. PvtKey.txt is the private key shares and associated
share indexes, usernames, and passwords needed by the shared secret decryption
application.
Shared Secret Decryption
The demonstration shared secret decryption application, PailDecShares.exe, is not
fully developed. When the application is executed, a Windows form is presented. The
form is pre-filled with the seven usernames and their associated passwords in plain text.
49
This was done to facilitate the demonstration of shared secret decryption. A fully
developed program is left for future work.
To use this demonstration application, the user first clicks on the Get Keys button.
The private key file PvtKey.txt is expected to be on the Windows desktop. If the file is
not present, an error message is displayed. If the file is successfully read, the Decrypt
button appears on the form.
To decrypt a ballot line, copy the ballot line and paste it into the Encrypted Ballot
text window. If the ballot line is an issue-selection array, select the Array radio button.
If the ballot line is a write-in name, select the Write In radio button. When the Decrypt
button is clicked, the ballot will be decrypted.
Note that if array data is pasted into the Encrypted Ballot window and the Write
In radio button is selected, or write-in data is pasted in and the Array radio button is
selected, nothing bad happens. The output is not as expected, but something will be
presented.
The application is expecting a 512 bit key size. If too large a text string is pasted
into the Encrypted Ballot window, an error message will appear. The Cipher text too
large message may also be caused by extraneous white space at the end of the cipher text.
CHAPTER 6
PERFORMANCE AND COMPARISONS
All of the metrics involve running programs to exercise and measure the time
required by the system components to complete a specific task. The executable programs
that ran on Windows platforms were compiled on Peabody, 32-bit using Visual Studio
2010, and 64-bit using Visual Studio 2012. The Linux executable was compiled on
Basil, 32-bit and 64-bit, using the g++ version 4.6.3.
Five 32-bit and five 64-bit platforms were used for testing all but the metrics in
section Ballots, page 60. Peabody and D’Artagnan were the Windows test platforms.
Basil, Porthos, and Aramis were the Linux test platforms.
CRYPTOGRAPHIC METHODS
Metrics were collected on the performance of several cryptographic methods.
Data Encryption Standard1 (DES) and Advanced Encryption Standard (AES) are two
symmetric key algorithms. Performance data for DES used a 56 bit key and AES used
128, 192, and 256 bit keys. ElGamal and Paillier are asymmetric cryptographic methods
that use modular exponentiation. ElGamal key sizes of 128, 256, and 512 bits were
evaluated. Paillier key sizes of 64, 128, 256, 512, 1024, 2048, and 4096 bits were
1 DES is generally considered to be insecure. Its use has been replaced by triple DES (3DES). The times recorded in these studies are long enough using single DES. To obtain expected times for 3DES, the single DES results may be multiplied by three.
51
evaluated. The same plain text, the Gettysburg Address, was encrypted and decrypted for
each run by each method. The evaluation plain text is 1464 characters plus the
terminating null. All methods encrypted and decrypted an ordered sequence of blocks the
size of their key.
The program EncryptMethods.cpp and supporting programs were created to test
the performance of the cryptographic methods. In a voting system, the cryptographic key
is generated before the election and does not change. Therefore, the encryption and
decryption times were measured separately from the key generation times. For DES and
AES 10,000 runs were conducted and timed. For ElGamal and Paillier 10 runs were
conducted and timed. Ten cycles of run timings were collected and averaged.
All five test platforms of the same bit size started their respective executions at
the same time. Table 1 shows the average run times in seconds for DES, AES, and
ElGamal methods and various key bit-sizes. Table 2 shows the average run times in
seconds for block Paillier method and various key bit-sizes. Note the different number of
runs per record for the various cryptographic methods when reviewing the data.
Table 1. DES, AES, and ElGamal Methods
DESAES 128
AES 192
AES 256
ElGamal 128
ElGamal 256
ElGamal 512
runs / record 10,000 10,000 10,000 10,000 10 10 10
32-bit Linux 81.785 7.948 9.482 11.101 0.626 0.843 1.515
32-bit Windows 35.038 1.823 2.143 2.524 0.729 1.397 3.473
64-bit Linux 49.343 3.970 4.761 5.562 0.307 0.368 0.525
64-bit Windows 27.127 1.494 1.786 2.074 0.448 0.613 1.133
52
Table 2. Block Paillier Method
Paillier 64
Paillier 128
Paillier 256
Paillier 512
Paillier 1024
Paillier 2048
Paillier 4096
runs / record 10 10 10 10 10 10 10
32-bit Linux 0.620 0.833 1.388 3.398 10.206 30.997 92.325
32-bit Windows 0.710 1.261 2.951 9.247 32.041 100.295 305.875
64-bit Linux 0.311 0.349 0.477 0.807 1.914 5.374 15.809
64-bit Windows 0.467 0.591 0.989 2.282 7.267 24.202 76.557
The DES functions used 64-bit unsigned integers. The AES functions used
unsigned char integers as array elements. Both performed about 100 times faster
compared to ElGamal and Paillier methods which used the MPIR mpz_class type.
Notice that Windows platforms performed roughly two to four times faster than
Linux platforms, of the same bit size, when using the standard integer types, but as much
as four times slower when using the MPIR type. The only differences in the executable
programs are from the compiler and the host operating system. This could indicate
significant differences between Gnu (Linux) and Visual Studio (Windows) compiler
optimization.
Sixty-four bit platforms performed as much as five times faster than the 32 bit
platforms. Again, this could indicate how well compilers are optimized to the host
platform.
53
GENERALIZED PAILLIER CRYPTOGRAPHY
The demonstration system used a 512 bit block Paillier cryptographic method. As
discussed in section Paillier Cryptography, page 32, with the Paillier method, an option
exists to encrypt and decrypt a block size larger than the key size. This method is
referred to as generalized Paillier (Damgard & Jurik, December 2000).
Performance data were collected on the time required to encrypt and decrypt the
same plain text, the Gettysburg Address, for various key sizes, using standard block
Paillier method, and generalized Paillier method. The program PaillierGen.cpp and
supporting programs were created to test the performance of block Paillier and
generalized Paillier methods.
For each key size, 10 runs were conducted and timed. Ten cycles of run timings
were collected and averaged. Table 3 shows the average run times in seconds for block
Paillier method. Table 4 shows the average run times in seconds for generalized Paillier
method. For generalized Paillier, the block count - the ratio of the plain text bit-size to
the key size, is important. That block count for the 1464 character input text is also listed
in Table 4.
Table 3. Block Paillier Method
Key Size 64 128 256 512 1024 2048 4096
32-bit Linux 0.607 0.839 1.401 3.397 10.193 30.948 93.351
32-bit Windows 0.660 1.156 2.807 8.600 29.832 94.428 288.980
64-bit Linux 0.357 0.406 0.554 0.930 2.216 6.090 17.806
64-bit Windows 0.470 0.541 0.916 2.073 6.460 22.008 68.873
54
Table 4. Generalized Paillier Method
Key Size 64 128 256 512 1024 2048 4096
block count 183 92 46 23 12 6 3
32-bit Linux 310.699 175.858 151.765 152.606 175.026 202.824 269.460
32-bit Windows 902.606 580.257 515.191 514.770 576.426 674.665 826.454
64-bit Linux 81.945 37.679 31.461 31.181 36.355 41.627 53.746
64-bit Windows 260.224 144.404 127.923 126.033 149.162 171.257 214.675
The run time data was plotted. Figure 5 plots the log of run time versus the log of
key bit-size for block Paillier method. Figure 6 plots the log of run time versus the log of
key bit-size for generalized Paillier method.
64 128 256 512 1024 2048 4096-1.000
-0.500
0.000
0.500
1.000
1.500
2.000
2.500
3.000
32-bit Windows32-bit Linux64-bit Windows64-bit Linux
Key Bit Size
Log(
Run
Tim
e)
Figure 5. Block Paillier Method
55
64 128 256 512 1024 2048 40960.000
0.500
1.000
1.500
2.000
2.500
3.000
3.500
32-bit Windows32-bit Linux64-bit Windows64-bit Linux
Key Bit Size
Log(
Run
Tim
e)
Figure 6. Generalized Paillier Method
For larger key bit-sizes, the log of run time versus log of key size becomes linear
in both plots. For block Paillier, the effect of function overhead influences the lower key
bit-size run times.
For generalized Paillier, the effect of dealing with a large block count influences
the lower key bit-size run times. The additional time for generalized Paillier small key
sizes may be identified by evaluating the Paillier.cpp file, FindI function beginning on
line 132. Two For loops are required to determine the decrypt numerator. For a fixed
plain text, the block count increases for smaller key size (see Table 4). The inner loop
experiences squared growth as the ratio increases. This explains the increase in time for
smaller key sizes.
ENCRYPTION KEY GENERATION
Metrics were collected on the time required to generate the cryptographic keys for
the methods evaluated in section Cryptographic Methods, page 50. The program
56
EncryptKeys.cpp and supporting programs were created to test the key generation times.
DES uses only a 56-bit key. Three key sizes, 128, 192, and 256, were generated for AES.
For ElGamal, key sizes of 64, 128, 256, 512, and 1024 were generated. For Paillier, key
sizes 128, 256, 512, 1024, 2048, and 4096 were generated.
All five test platforms of the same bit-size ran their respective compilations at the
same time. For DES, and AES, 10,000 runs were conducted and timed. For ElGamal,
and Paillier, 10 runs were conducted and timed. Ten cycles of timings were collected and
averaged.
Table 5 shows the average run times in seconds for DES and AES key generation.
Table 6 shows the average run times in seconds for ElGamal key generation. Paillier
average key generation times in seconds are shown in Table 7. It is interesting to note
that the raw data for Linux platforms appears to have a time granularity of one or two
milliseconds. The time granularity for Windows platforms appears to be 15 to 16
milliseconds. This is particularly noticeable in the odd time average for 32-bit Windows,
AES 128 bit key size - this metric just happened to have a lot of 15 and 16 millisecond
runs while other runs in that metric were 0 milliseconds.
57
Table 5. DES and AES Key Generation
DESAES 128
AES 192
AES 256
runs / record 10,000 10,000 10,000 10,000
32-bit Linux 0.001 0.003 0.005 0.013
32-bit Windows 0.001 0.011 0.006 0.016
64-bit Linux 0.001 0.002 0.003 0.004
64-bit Windows 0.001 0.009 0.010 0.015
Table 6. ElGamal Key Generation
ElGamal 64
ElGamal 128
ElGamal 256
ElGamal 512
ElGamal 1024
runs / record 10 10 10 10 10
32-bit Linux 0.028 0.157 2.212 47.469 1276.616
32-bit Windows 0.037 0.420 7.413 181.943 5886.979
64-bit Linux 0.013 0.078 0.636 10.800 243.518
64-bit Windows 0.021 0.160 1.915 39.722 897.332
58
Table 7. Paillier Key Generation
Paillier 64
Paillier 128
Paillier 256
Paillier 512
Paillier 1024
Paillier 2048
Paillier 4096
runs / record 10 10 10 10 10 10 10
32-bit Linux 0.001 0.001 0.010 0.067 0.501 6.870 88.310
32-bit Windows 0.001 0.003 0.015 0.164 1.860 30.291 336.214
64-bit Linux 0.000 0.001 0.004 0.016 0.127 1.356 19.348
64-bit Windows 0.002 0.002 0.005 0.049 0.499 5.455 86.321
The DES and AES key generation times are too quick to be interesting as a graph.
The ElGamal key generation averages are shown in Figure 7. Figure 8 shows the Paillier
average key generation times. The figures show the log of average generation time
versus the log of key bit-size.
64 128 256 512 1024-3.000
-2.000
-1.000
0.000
1.000
2.000
3.000
4.000
5.000
32-bit Windows32-bit Linux64-bit Windows64-bit Linux
Key Bit Size
Log(
Run
Tim
e)
Figure 7. ElGamal Key Generation
59
64 128 256 512 1024 2048 4096-4.000
-3.000
-2.000
-1.000
0.000
1.000
2.000
3.000
32-bit Windows32-bit Linux64-bit Windows64-bit Linux
Key Bit Size
Log(
Run
Tim
e)
Figure 8. Paillier Key Generation
As with the block Paillier encrypt-decrypt time in section Generalized Paillier
Cryptography, page 53, the log of run time versus log of key size becomes linear in both
plots. And, the effect of function overhead influences the lower bit-size run times.
Notice the time difference between generating key for ElGamal and the same size
key for Paillier. Paillier uses a composite key - two random prime numbers half the bit
size of the desired resulting key. Paillier does not need to use two safe prime numbers or
even two strong prime numbers (Rivest & Silverman, 1998). ElGamal uses one safe
prime number. A safe prime is used to facilitate finding the required primitive root.
Choosing a single safe prime number of given bit size for ElGamal is more time
consuming than finding two prime numbers of half the given bit size for Paillier. This
accounts for the time difference in generating ElGamal keys and Paillier keys of the same
size.
60
BALLOTS
The last set of metrics collected involved the time for the servers to interact. In
the proposed architecture, three server interactions occur - Tally server getting the public
key, Voting server getting the public key, and Voting server transferring the ballot to a
Tally server. The Tally server getting the public key occurs only once throughout the
election when the tally service is initiated. Thus, this time was not of interest and was not
measured.
The program BallotTime.cpp and supporting programs were created to test
interaction time for the Voting server to retrieve the public key, and for the Voting server
to transfer the ballot to a Tally server. Both 32-bit and 64-bit systems were measured.
D’Artagnan and Peabody acted as the Voting server. Dumas was the Public Key server.
Porthos was the array ballot Tally server. Aramis was the write-in ballot Tally server.
The time to fetch ten public keys was measured for each record. The times to transfer
one, two, and three array ballots were measured for each record. Likewise, the transfer
times for one, two, and three write-in ballots were measured for each record. Ten records
were generated and averaged.
For one set of averages, D’Artagnan and Peabody were run separately. For
another set of averages, D’Artagnan and Peabody were run at the same time. This
demonstrated the system’s ability to handle multiple service requests at the same time.
Table 8 shows the average times.
61
Table 8. Ballot Casting Times
Key Fetch
Array Ballot 1
Array Ballot 2
Array Ballot 3
Write In 1
Write In 2
Write In 3
runs / record 10 10 10 10 10 10 10
32-bit Separate 4.036 4.057 4.075 4.100 4.149 4.156 4.139
32-bit Coincident 4.118 4.290 4.311 4.339 4.275 4.284 4.310
64-bit Separate 3.380 3.359 3.537 3.506 3.466 3.449 3.442
64-bit Coincident 3.343 3.367 3.411 3.449 3.389 3.406 3.409
Notice that the Coincident times do not vary much from the Separate times.
Further, the 64-bit Coincident times are almost all faster than the 64-bit Separate times.
This is another indication of the system’s ability to handle multiple, coincident service
requests.
Notice that the time to transfer one, two, or three ballots also does not vary
significantly. This implies that the time to transfer a ballot is a small portion of the
overall transfer time. Kerberos mutual authentication is likely responsible for the bulk of
the transfer time.
CHAPTER 7
LESSONS LEARNED
FREEWARE
Freeware comes at a price. I found it often not documented to the degree and
extent of commercial software. Also, the documentation is often not maintained as
current as the freeware release. Problems persist through several updates. Though it
comes at a good dollar price and is invaluable to academic investigation.
INTERNET FORUMS
Internet forums are a good source of information and help. They are also a source
of frustration. Questions must be asked with enough detail to explain the problem
without writing a book no one will read. Forum posts must be polite and respectful, or no
response will be received. Silly questions are quickly identified. The greatest frustration
arises from the lack of a response to a difficult question.
USING MULTIPLE PROGRAMMING LANGUAGES
Not all programming languages play nice in the sandbox. When using Visual
Studio to develop the web site, the choices of programming languages are C# and Visual
Basic. Transferring information between C# and C++ was always tedious. The
63
cryptographic library routines are written in C++. The web server required the C++
library to be dynamically linked - containing only functions, not public variable values.
Any variable whose value is determined by a C++ function and only used by other C++
functions must be passed back to the C# program to be passed on to the next C++
function. For example, the value of the public key is never used in C# but must be stored
in C#.
Passing multi-precision values between languages and between servers was
problematic. I decided on converting MPIR values to strings for this transference. Then
discovered that I could not transfer an array of strings between C# and C++. Thus the
ballot decrypt form is written wholly in C++ and must be compiled using Visual Studio
2010.
CHAPTER 8
FUTURE WORK
WEB SITE DEVELOPMENT
The demonstration web site was developed using C# and hosted on Microsoft
Web Server 2008. Apache also makes a versatile web server (Apache Web Services,
2011). Could performance improvements be achieved by hosting the web site on a
different server? Would web site development be easier or would other complications
arise such as were discovered with interfacing between C# and C++ using DLLs?
SQL SERVER POSITIONING
The proposed architecture places the SQL server in a separate platform on the
private network. The demonstration systems placed the SQL server in the web server.
Evaluate the trade-offs and risk associated with having the SQL server reside with
the web server or in a separate platform. Is there a risk reduction by using a separate
platform? Does the risk reduction of having a separate platform justify the cost of a
separate platform?
65
GENERAL FUNCTIONS SERVER
The proposed architecture places three services in the General Function server.
Evaluate the trade-offs and risk associated with hosting these three services on the same
platform or separate platforms. Is there a significant risk reduction by using separate
platforms. Does the risk reduction of having separate platforms justify the cost of the
separate platforms?
SECRET SHARE ENCRYPTION AND DECRYPTION
Paillier Key Generation
The demonstration program that generates Paillier public keys and private key
shares is not fully developed. The program does not include proper username and
password entry. Possibly a database could be established for retention of the username
and associated secure password. This same database must be available for associated
ballot decryption.
Once all the usernames and passwords are entered, the private key can be
generated and then the secret shares that reconstruct the private key can be generated.
The secret shares should be stored in a secure manner, perhaps encrypted by the user's
password.
Ballot Decryption
The ballots are decrypted by a demonstration program that is not fully developed.
The judges passwords and secret shares should be stored in a secure manner and
associated with their usernames.
66
When a judge enters a username and password, the password should be checked
for validity. If valid, the password is then used to decrypt the secret share. When a
quorum of secret shares have been obtained, the private key may be reconstructed.
Shared Secret Decryption
I originally compiled PaillierDecShares using Visual Studio 2010 which allows
Windows forms written in C++. Later, when the Prometheus machines were configured,
VS 2012 was available, so that was installed. Visual Studio 2012 only allows forms in
Visual Basic and C#. I tried to convert my program to C# but ran into a brick wall when
it came to sending string arrays to a DLL. I need the DLL to run the C++ multiple
precision library routines.
If a way can be found to pass the string arrays of data to the DLL,
PaillierDecShares can be updated.
Ballot Tally Application
Especially for elections with a large number of issues, a more robust decryption
application may be useful. The application would interrogate the Tally servers, decide
which servers have valid votes, and decrypt the accumulation. Refer to section Casting
the Ballot, page 28, for a discussion of valid Tally servers.
ERROR HANDLING AND LOGGING
Any programming for a voting system must include extensive error handling. In
many cases, the demonstration system passed unique error messages to the voter
identifying the error. This was done to enhance the demonstration but should not be done
67
in a deployed system. A deployed system should provide the voter, and possibly the
adversary, as little information as possible about the nature of the error - only that an
error has occurred and that the voter should try again later.
Any system errors as well as many normal activities should be logged, recorded,
and perhaps displayed.
REDUNDANCY
Much work needs to be done to make the system properly redundant.
The voter database that contains whether a voter has successfully voted or is
allowed to login must be redundant. The redundant databases must stay in sync.
The Kerberos KDC and realm admin functions must be redundant.
The private network General Functions server functions - DNS, NPT, Public Key,
must be redundant.
The web servers need to be redundant.
The outside-world authoritative DNS servers need to be redundant.
TALLY SERVER REDUNDANCY
Section Casting the Ballot, page 28, discusses the problematic exchange of the
ballot between the Voting server and the redundant Tally servers.
Should there be two, three, or more redundant Tally servers?
If any Tally server fails to successfully receive and store a ballot, should the Tally
servers that were previously successful delete the ballot or should this be sorted
out after the election closes? Note that deleting an encrypted ballot from the
encrypted accumulation may not be feasible.
68
Can file-system journaling be incorporated into Tally server redundancy? For
example, all Tally servers write the ballot to their journal. If all servers succeed,
only then is the ballot written to media and the ballot casting considered
successful. Or should it be considered successful only after successful media
writing?
BALLOT GENERATION
Develop an application to generate the ballot. Many aspects of the demonstration
ballot are prone to error (trust me, I made most of them :-), e.g. typos. For a production
software package, the ballot should be generated by an application.
Issue parameters, indicating the number of allowed checkboxes and the total
number of candidates, are hard coded in the demonstration. These parameters must
match the number of candidates displayed and the maximum count of selections (e.g.
vote for 3) for this issue. Issue parameters should be in a ballot database, perhaps the
same as the multi-lingual database.
MULTI-LINGUAL DATABASE
The ballot text entries should be obtained from a database. Ballot text entries are
used in two files: Issue??.aspx (where ?? indicates the two digit issue number) and
Verify.aspx.cs. This is not desirable since the same text is presented from two sources.
If the text comes from a single source, a database, at least the same error will be
presented in both places. Also, ballots are required to be multi-lingual. This requirement
is also better accomplished by a database.
69
Login text, instructions, even navigation text should all be presented in the chosen
language. Thus, every page and sub-page of the website is affected by this multi-lingual
requirement.
PRECINCT BALLOTS
If, for example, a county hosts an eVote election. The one system would be
responsible for all the precincts of that county. The same database that handles the
various languages of the ballot could handle several ballots. When a voter logs on, a
determination would be made of which precinct ballot the voter should access.
VOTER PASSWORD HANDLING
Password Encryption
Voter password encryption was not implemented in the demonstration program.
Secure password storage should be implemented.
Password Maintenance
Voters may, even should, periodically change their password. Voters may forget
their password and need their password reset. All of the normal password maintenance
features encountered in normal computer system administration should be implemented.
QUORUM LOGIN
VVSG section 2.1.1 details system security requirements (EAC VVSG Vol I,
2010, p. 19). Administrative functions should only be completed by authorized
70
individuals. Administrative activities can be logged. Even logs can be altered or deleted.
If system administrative activities are only performed if a quorum of officials are present,
the likelihood of improper activities is reduced.
Build an administrative account login feature that requires a quorum of
administrators to authenticate the login.
PROVISIONAL BALLOTS
Section Tally Servers, page 45, discusses how the demonstration Tally servers
collect and store voter candidate selection and write-in information. If a voter is voting
provisionally, their ballot information must be kept separate from the non-provisional
ballot information.
Add necessary functions to collect provisional ballot information, including write-
in information. The voter login database should include information in the voter record
that the voter is a regular voter or a provisional voter.
WRITE-ONLY MEMORY
Section Tally Servers, page 45, includes discussion of the need for the voter's
selections to be stored on unalterable storage media.
How does this fit into section Tally Server Redundancy, page 67?
If more than one unalterable storage media server is used, how should the failure
of one Tally server be handled?
71
FIXED STRING SIZES
Throughout the demonstration coding, especially when interfacing between C#
and C++, fixed size strings are used. For a deployed system, ballot text sizes and all
strings passed between the C# website program and the C++ DLLs will be extremely
variable. Work needs to be done to better handle variable size strings between the
website program and the DLLs.
Also, the maximum size of a message Kerberos is able to transfer is limited to
216−1 characters. Using the demonstration system key size of 512 bits, ballot lines of at
least 1024 bits, or 256 characters are expected. If all issues require two ballot string lines
- one for the issue-selection array and one for the write-in name, 512 characters per issue
may need to be transferred to the Tally servers. This allows a maximum of 128 issues.
If, however, the key size is increased to 2048 bits for greater security, only 32 issues
would be allowed. This may not be enough.
Investigate ways of increasing the message size transferred using the Kerberos
DLL function KTCP_Send_Recieve. This may be as simple as changing the definition of
SIZ_SIZ.
Investigate sending the ballot line string in several parts rather than all at once.
KERBEROS MUTUAL AUTHENTICATION
See section The KTCP Class, page 44.
Message Digest
In the demonstration, source file KTCPdll.cpp functions krb5_read_msg and
krb5_write_msg, messages are not encrypted and no message digest is created or verified.
72
Corresponding changes would need to be made in the Linux and Windows code. Doing
so would improve transmission security.
Client Credentials
In the demonstration, source file KTCPdll.cpp line 285, the client password is
hard coded. It would be better to store and get the password from a secure password
repository. This would also facilitate changing the password from time to time which
would improve security.
The tally server programs and the BallotTime program must be edited and
compiled for the specific target host on which it will run. There should be a way to
retrieve the password and host name from the credentials store. This would simplify
programming by not requiring host-specific compilations.
Compilation and Linking
The krb5 library functions krb5_read_message and krb5_write_message refused
to link. I was forced to write my own versions of these functions. If the krb5 library
functions could be made to link properly, they may offer performance improvements.
Kerberos for Windows Release 3.2.2 does not support 64-bit platforms (MIT
Kerberos, 2007). This precluded the demonstration of a 64-bit web site. Also, the
metrics program that tested server interaction, BallotTime, was compiled as a wholly 32-
bit program. When a 64-bit compatible version of Kerberos for Windows is available,
these programs may be updated.
73
BLOCKS VERSUS GENERALIZED PAILLIER
Evaluate the time requirements and system impact of using key-sized blocks for
the ballot, then encrypting a ballot as a sequence of blocks.
PLATFORM FIREWALLS
The demonstration system does not employ specifically designed firewalls. For
the Ubuntu servers, IPtables should be scripted. For the Windows platforms, the
Windows firewalls should be specifically configured.
BALLOT RE-ACCESS USING THE BACK ARROW
After the ballot is successfully cast, provisions must be made to prevent the voter
from re-accessing the ballot using the back arrow key. I know I addressed this and
thought I had it covered. The demonstration system allows a voter to recast the ballot if
the back arrow key is used before exiting the website. This must be fixed.
CHAPTER 9
SUMMARY
The contributions of this thesis are to provide a proof of concept to the proposed
architecture and deliver a prototype system for future investigations. The cryptographic
libraries developed for this thesis are general in construction and can easily be integrated
into other cryptographic work.
Developing an EAC compliant voting system is a significant undertaking. Such a
system has many requirements and not all requirements are easy to satisfy for a web-
based system - Voter Verifiable Paper Audit Trail for one, redundancy, error recovery,
and accessibility, for others. SERVE, a US government funded solution attempt,
received such severe criticism that it was withdrawn without being fielded (Defense,
2007, p. 11).
The objective of SERVE was to enable voting from any PC from anywhere in the
world (Defense, 2007, p. 11). This seems to me like shooting for the moon when we
cannot first get into orbit. This thesis proposes an architecture to get off the ground. The
proposed system has enough of the basic components described that a functioning system
can be and was built. The Vevo demonstration system provides voter login and balloting,
voter verification of the ballot, submission of the ballot to two Tally servers which each
accumulate the ballots, and the ability for election judges to interrogate the final vote
75
tally. Service principals communicate with each other only after mutual authentication.
Vevo is not fully EAC compliant - the system does not land on the moon. But, it does
provide a publicly available architecture to discuss and build upon.
Design decisions were based on two general rules of Information Assurance: 1)
Minimize the attack surface; and 2) Mitigate the vulnerabilities. There is a long list of
future work described in section Future Work, page 64. Future proposals must be
evaluated against these same two general rules.
The demonstration system is a proof of concept. A development system was built
on a 32-bit server hosting several virtual machines. Issues such as the Kerberos library
functions not linking, Kerberos mutual authentication configuration being format
sensitive, and DLL interface between different programing languages were all resolved.
A second system was built on a 64-bit server maintained by UCCS. Metrics were run on
both systems and comparisons were made. The performance data gave no indication that
a viable web-based voting system could not be achieved. 64-bit systems provide a speed
advantage. Though, some difficulty was encountered compiling fully 64-bit system
components. For example, MIT Kerberos version 5 does not support 64-bit platforms
(MIT Kerberos, 2007). This precluded compiling a 64-bit web site. The 32-bit Voting
server virtual machine was exported from the Ignis system and imported to the
Prometheus system to ensure a fully function system is available at UCCS.
CHAPTER 10
ABBREVIATIONS AND ACRONYMS
3DEC Triple Data Encryption Standard
AES Advanced Encryption Standard
API Application Program Interface
ASCII American Standard Code for Information Interchange
CSV Comma Separated Value
DES Data Encryption Standard
DLL Dynamic-Link Library
DNS Domain Name Service
EAC Election Assistance Commission
FVAP Federal Voting Assistance Program
GPS Global Positioning System
IDE Integrated Development Environment
IIS Internet Information Services
IP Internet Protocol
KDC Key Distribution Center
krb5 MIT Kerberos version 5
KTCP Kerberized Transmission Control Protocol
77
MAC Message Authentication Code
MIT Massachusetts Institute of Technology
MPIR Multiple Precision Integers and Rationals
MS Microsoft
NTP Network Time Protocol
OS Operating System
PC Personal Computer
SERVE Secure Electronic Registration and Voting Experiment
SPRG Security Peer Review Group
SQL Structured Query Language
TCP Transmission Control Protocol
UCCS University of Colorado at Colorado Springs
US United States
VS Visual Studio
VSTL Voting System Test Laboratory
VVPAT Voter Verifiable Paper Audit Trail
VVSG Voluntary Voting System Guidelines
CHAPTER 11
WORKS CITED
Electronic Voting System. (2009). Retrieved March 6, 2012, from http://evotingsys.sourceforge.net/
Apache Web Services. (2011). Retrieved October 18, 2012, from Apache: http://ws.apache.org/
GNU M4. (2011, March 01). Retrieved October 18, 2012, from GNU Operating System: http://www.gnu.org/software/m4/
MotionVoter. (2011). Retrieved March 6, 2012, from http://www.motionvoter.com/
ESXi Info Center. (2012). Retrieved October 12, 2012, from VMware: http://www.vmware.com/products/vsphere/esxi-and-esx/overview.html
GCC. (2012, September 20). Retrieved October 18, 2012, from GNU Compiler Collection: http://gcc.gnu.org/
IIS 7 Operations Guide. (2012). Retrieved October 18, 2012, from Microsoft: http://technet.microsoft.com/en-us/library/cc732976(v=WS.10).aspx
SQL Server. (2012). Retrieved October 18, 2012, from Microsoft: http://technet.microsoft.com/en-US/sqlserver/
Visual Studio Editions. (2012). Retrieved October 18, 2012, from Microsoft: http://www.microsoft.com/visualstudio/eng/products/visual-studio-overview
Boehm, A., & Murach, J. (2011). Murach's ASP.NET 4 Web Programming with C# 2010. US: Mike Murach & Associates, Inc.
Cardellini, V., Casalicchio, E., Colajanni, M., & Yu, P. S. (2002). The State of the Art in Locally Distributed Web-Server Systems. ACM Computing Surveys, Vol 34, No 2, 263-311.
79
Damgard, I. B., & Jurik, M. J. (December 2000). A Generalisation, a Simplification and some Applications of Paillier's Probabilstic Public-Key System. Basic Research in Computer Science, RS-00-45.
Defense, D. o. (2007). Expanding the Use of Electronic Voting Technology for UOCAVA Citizens. Department of Defense.
EAC. (2010). Election Assistance Commission. Retrieved February 29, 2012, from http://www.eac.gov/
EAC Voting System Testing and Certification Division. (2011). A Survey of Internet Voting. Washington, DC 20005.
EAC VVSG Vol I. (2010). Voluntary Voting System Guidelines Volume I. Retrieved August 24, 2012, from United States Election Assistance Commission: http://www.eac.gov/testing_and_certification/voluntary_voting_system_guidelines.aspx
EAC VVSG Vol II. (2010). Voluntary System Guidelines Volume II. Retrieved August 24, 2012, from United States Election Assistance Commission: http://www.eac.gov/testing_and_certification/voluntary_voting_system_guidelines.aspx
EAS Cloud. (n.d.). Retrieved October 11, 2012, from UCCS College of Engineering and Applied Science: http://www.uccs.edu/eas/eas_cloud.html
Evecek, H. (2007, Spring). Applying MESE Processes to Improve Online E-Voting Prototype System with Paillier Threshold Cryptosystem Web Services. Retrieved October 21, 2012, from UCCS CS Dept: http://cs.uccs.edu/~gsc/pub/master/hevecek/doc/Online E-Voting Prototype with PTC Web Services v1.doc
Jefferson, D. D., Rubin, D. A., Simons, D. B., & Wagner, D. D. (2004). A Security Analysis of the Secure Electronic Registration and Voting Experiment (SERVE).
Jefferson, D., Rubin, A., & Simons, B. (2007, June 13). The new report in response to the May 2007 DoD report on Voting Technologies for UOCAVA Citizens. Retrieved March 04, 2012, from http://www.servesecurityreport.org/
KDE Development Environment. (n.d.). Retrieved October 18, 2012, from KDevelop: http://kdevelop.org/
MIT Kerberos. (2007, October 23). Kerberos for Windows Release 3.2.2. Retrieved October 04, 2012, from MIT Kerberos: http://web.mit.edu/kerberos/kfw-3.2/kfw-3.2.2.html
MPIR. (n.d.). Retrieved October 18, 2012, from MPIR: http://www.mpir.org
80
Paillier, P. (1999). Public-Key Cryptosystems Based on Composite Degree Residuosity Clases. Advances in Cryptology - Eurocrypt '99, pp. 223-238.
Pound. (n.d.). Retrieved August 31, 2012, from Apsis Gmbh: http://www.apsis.ch/pound/
Rivest, R. L., & Silverman, R. D. (1998, December 1). Are 'Strong' Primes Needed for RSA? Retrieved October 19, 2012, from RSA: ftp://ftp.rsasecurity.com/pub/pdfs/sp2.pdf
Shamir, A. (November, 1979). How to Share a Secret. Communications of the ACM, 612-613.
Vote-Now. (n.d.). Retrieved March 6, 2012, from https://secure.vote-now.com/
Wilson, B. (2006, Fall). Implementing a Paillier Threshold Cryptography Scheme as a Web Service. Retrieved October 21, 2012, from UCCS CS Dept: http://cs.uccs.edu/~gsc/pub/master/bswilson/doc/BrettWilson_MastersProjectReport_draft.doc
WinMerge. (n.d.). Retrieved October 19, 2012, from WinMerge: http://winmerge.org/
APPENDIX A
INSTRUCTIONS TO BUILD A DEMONSTRATION SYSTEM
1 Notes and CommentsConfiguration files mentioned in this appendix may be found at http://cs.uccs.edu/~gsc/pub/master/cmccullo/src/configs.
Source files to be compiled that are mentioned in the configuration files may be found at http://cs.uccs.edu/~gsc/pub/master/cmccullo/src/sources.
Compilation test elements, such as keys and data, are imbedded in the source files but commented so as not to impact normal operation. A valid public key, private key pair, and encrypted and decrypted data may be found at http://cs.uccs.edu/~gsc/pub/master/cmccullo/src/trial.
1.1 NotesNotes and instructions provided here are for fresh installations. The major sections must be completed in order. My apologies if the instructions are like filling out tax returns - jumping back and forth between papers, but this scheme allowed for modularizing the instructions.
Final disclaimer: These instructions are an amalgamation of what worked. I did not get everything to work, then retest the instructions from scratch. These instructions are believed to be correct and complete. Other than that, good luck.
1.2 CommentsThe instructions include comments, directions, and commands to be entered on the virtual machine CLI. If an instruction begins with the word host, the command that follows should be entered on the CLI of whichever VM is being configured. If an instruction begins with a specific host name, the instruction applies to only that host. Information to be provided by the user, for example a username, will be enclosed in <> symbols. For clarity, I sometimes put comments at the end of a command. Comments are prefixed with a # character and need not be entered.
Understanding of Linux vi editor is implied. Several instructions begin with “append...”. This implies that the information that follows should be appended to the file indicated. Any editor of your choice should work.
82
2 ConfigurationThese configuration sections may be completed in any order.
2.1 Configure Linux ServersSee configLinuxServers.docx
1. configDNSnNTP.docx2. configKerberos.docx
2.2 Configure Windows Web ServerSee configWebServer.docx
2.3 Configure Development Platforms1. See configLinuxDevelop.docx.
a. configDNSnNTP.docxb. configKerberos.docx
2. See configWindowsDevelop.docx.a. mpir_load_notes_v2.docx
3 Configure Mutual AuthenticationSee configMutAuth.docx
4 CompilationThe compilations sections may be completed in any order.
4.1 Compile eVote and Metrics ProgramsSee compilePrograms.docx
4.2 Compile eVote Web SiteSee compileWebSite.docx
5 Running ProgramsSee runElection.docxSee runMetrics.docx
APPENDIX B
INSTRUCTIONS TO RUN AN ELECTION
These instructions follow the same format described in appendix A and used in the configuration files. If an instruction begins with the word host, the command that follows should be entered on the CLI of whichever VM is being configured. If an instruction begins with a specific host name, the instruction applies to only that host. Information to be provided by the user, for example a username, will be enclosed in <> symbols. For clarity, I sometimes put comments at the end of a command. Comments are prefixed with a # character and need not be entered.
1 Kerberos Key Distribution CenterStart Athos. The Kerberos service will start automatically.
2 Public KeyStart Peabody, Basil, and Dumas. The DNS service on Dumas will start automatically.
2.1 Generate Public KeyOn Peabody
1. Double click on GenKeyShares.exe. This should produce two files on the Desktop - PubKey.txt and PvtKey.txt.
2. Open WinSCPa. Logon to Basilb. Copy Desktop\PubKey.txt to Basil ~/Desktop
2.2 Load Public KeyOn Dumas
1. dumas$ cd ~/KNServer2. dumas$ scp [email protected]:~/Desktop/PubKey.txt .3. dumas$ ./KNserver
3 Tally ServersStart both Porthos and Aramis.
1. Be sure to clear the tally foldera. host$ rm -f ~/tally/Issue*.txt
2. Configure both Porthos and Aramisa. host$ cd ~/KTServer
84
b. host$ sudo ./KTserver #KTserver uses restricted ports, must be started with sudo
4 Start the ElectionStart D’Artagnan
Clear the voters database1. Start SQL Server Management Studio2. Connect to SQLExpress3. File | Open | File4. Navigate to ClearVoted.sql (should be on the Desktop)5. In the database selection dropdown in the second toolbox row (left of the Execute
button), select Vevo_voters6. Click Execute
5 TroubleshootingAfter login, “Oops. Lost my brain. Please try again later.” indicates the public key was not retrieved. Ensure Dumas is running KNserver.
After casting a ballot, “Thank you for participating. Have a nice day. no reply” indicates the ballot was not successfully transferred. Ensure both Porthos and Aramis are running KTserver.
After casting a ballot, “Thank you for participating. Have a nice day. 000,Ballot recorded successfully.” indicates success.
6 After the ElectionWhen the election is complete:
1. create tally folders in Basil for Porthos and Aramis.a. basil$ mkdir ~/tallyPorthosb. basil$ mkdir ~/tallyAramis
2. copy the tally folders to Peabody.a. copy the contents of Porthos ~/tally and Aramis ~/tally to Basil.
i. porthos$ scp ~/tally/* admin@basil:~/tallyPorthosii. aramis$ scp ~/tally/* admin@basil:~/tallyAramis
b. use WinSCP to copy the Basil tally folders to Peabody tally folders.3. Compare the tally in Peabody
a. the files in the Porthos tally folder should be identical to the files in the Aramis tally folder. I used WinMerge (WinMerge) to compare the files.
4. View the decrypted dataa. Open PaillierDecShares in Peabody. The election judge’s login names and
passwords are preloaded.b. Click the Get Keys button to evaluate the judges logon information and
retrieve the private key.c. Copy the encrypted data to the Encrypted Ballot window.d. Select if the data is a ballot or write-in.
85
e. Click Decrypt. The decrypted information should appear in the Decrypted Ballot line.
APPENDIX C
TRIAL DATA
This appendix contains trial data from the Vevo e-voting system. The data files may be found at http://cs.uccs.edu/~gsc/pub/master/cmccullo/src/trial.
1 Public key372971baf46384737eec84b2fb4ac44c75c3c1364901228892e6acea03576e2a181bd145a779a076d3269d6574d765887cb8d4c9503215d28c2c46755530d95d1
2 Private keyNote that the commas must be replaced with tabs to accommodate the expected private key file format.
bashful,evote,1,24f6554c2b89ab004323de3d4c88da67856597b0e30659b12c8ecde4a37361b01b78427b69931aded3a3bf3844959c236b6dd2ce92e497de7387626fb95f44225doc,evote,2,99b297846c4308c315e24d22b4ec303ec8cccfd260ac3feb4626bb09dbf9477ed42a90ad351db6060802512c7420c9b5dac858547b7858528f4cb360fafa9a50doppy,evote,3,23b55f57a3183a69a3cb081b6afb01bfa4476bc4a6b3d655b1e0a7734783de1700ec0b16e40206d8e124cdf13ba62baf44b7240b6fa9c1b8bbb5cdf000e1215fegrumpy,evote,4,27facbaf3a9222ca374aec036ab12f797f3a1ba943242f453d47f208edad82b9aba6406ab03e7fbec6b9d9fcdcc6ff71e09a0aabd3d0454c913733b165759fbdfhappy,evote,5,24ab4fefba1c85307aab92784dfa95cc5cd4583227f8fe501bd6937e08134b65abef216f41bc8ff558e06c45a80f37e6e1a6a7a8d721ee69b120c036b1ff2874sleepy,evote,6,cd7453cbd7e12902e90618b0a8a552dabf0d496fdebfe5dd033849a76f282b7abbb6bb7baa1a675783d4ca14e5f3e81236f1e1e563a88d1e337f359e9f49a3e0sneezy,evote,7,337fc2e86e96e026c7c8cdcb561f90177a0d31bcfc8d3bc753cf61f701461f140be9565dbfe49b0e73166922683e4c153d5d56ab477091b45b41f93e0fa664aa4
3 Trial DataThe following encrypted text will decrypt as indicated. The issue accumulation - suffix A, may be generated by multiplying the issue ballots - suffix B, mod N^2.
Note that no two ballots are encrypted the same way. Even though the same candidates are selected, a random factor is included that causes the ciphertext to be different.
3.1 Issue001Aca7ef280148d9a9af12e3654c42fcac7e13c38e1ff03b11727472d7dd3199454114db5f89aab7e8062ea31aeffea9fa117c0e29f220fbff99c47fbf25c4ac717dddbd2a9eb023dba4cc3baa0
87
31ca32c361051a4d2f5601d62d808781f49a3b8a0d980c37c6821fc14259dd6289ab2710b73841406922bd110d4e05881797e60a0, 1, 0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0
3.2 Issue001B40302c309bcd17f30d5a267a1575734d066fe1476f955b23479aa7b6a2fd786046e58f89f9dd5edb095fcb941eef30874b1cc621d473b569c441004038176310c09f40afa1b3bc74ba770e9147d1cfb72e4cda11d71bad1457d51576d1f386d13f0157240f8b4a08c45383185de1845b93d006e3d5b82c2a6e29ab6ba2ca831330, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0
6d832276c4adc432357fa13e266ec38e25bf3acd1d81fe3dc29c62d362d803913f42e83ae7ea841781a4d212067b419e87552e9a31c32284157a08e0e8a33faed1edc72c02d37c0ab982826e30f480537544125d80e0d66556de7c7991cafadeb49f9b30d598e899856a3ecd64f345a66f4736fe4e0cc52a0df9cbc7c65cf91cc0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0
3.3 Issue001W123450465c2840f918f3fe54a3e4500c61322450a1d016f28a33bfe878d82a4765ea30ec90d3ac2c186d549d46a8dedf6f54e488e1ef6a232e583490c152b8861f25ec26c3c1d3e9ab6c9eaf095c4f6dd72cee243e4b288dceadbb8c96f69a8bfbacac4bebf86a7dbe389b3c465397f1f26615c4f9ee695d4a2a76f73157feeb4UC Bearcats
3.4 Issue002A4322ee934db08a257221bd15ed765e8e24549f1d968854fac688119fa95c83bf3f0ad76335e8ad0094fcee3b2192de0d60175ac39d6484c41bf89285eda8551ce9a1ac55cf188135cdbdf63eca99752d2898a4549aa86b06f8142f5024a378f435c549f80e444da71ce1342d9612676d21f0732263838ae7120c8ca2586c3d8e80, 0, 1, 0, 0, 2, 1, 0, 1, 1, 2, 0, 0, 0, 0
3.5 Issue002Ba4f40ba2dfa28429604870cadab7cb6cef894cb4de0dfc5a8a0c847ace0335495e849c05052ecb8a07df868709c1a84880cc17215972fbe0c8c82edb01eba237843723ea2530b9a7a80fd4fbee8a6cbd5428119d480f9b251d7a450a6e9a23353515229933a233a12e00686723eb454fb9ace5b2e06abd8b37c6656c34c71491a0, 0, 1, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0
524ad086fad07e6b716da71118d403dd39586e8ef0d5394cc71c1903fc0a9a60317d730ddd5454d78552590d9bd1fdd4582b5721c00031c2f00932ff57d22b06f0dae329cef93722d8e458208a11b4aacd6e6e35b0534b0acc49c3890b5e845d6f37dbb098063991583e8f4f0c70f098d899fd745da8b5a9637780a4735f29e00, 0, 0, 0, 0, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0
3.6 Issue002W4aef74ef766e719505d2386513c55fd902f46be42654d8fdb66359d8fb5b9fa87ace75b5a5b531dfad3d2866f1c36df1bfd43bc0ec19baaeb1cb60df4090c80f75ff1b783e0c85102a859e2
88
58cac95c4e926d39d672873b1b983948b8badaa889de8496c3753be3eb4a3bb4e8596f28a1c31371b4331a8ce6ee3a51883459a4f0UCCS Mountainlions
3.7 Issue003A5cf72281eac98036a3c91e36c708b159679db230cd65a8a6c7bef77efe8abb6c60b65f36122db15ec566a009e0440766f01dcd4ebf747029e1f2caf314a460ffc33ad296356370663d4a76a4616498354ecbd2b39a0b4581824c318c16ab322b04775507f10e5afd4352cc2cedfb0b7e7ba5c596a30f8223514fd27c74675df1a1, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
3.8 Issue003B3d5a6f3fa6897f6101ca1a0c45ba021a0b04ef6c2a7056cc3c60450f8b36226149470387593f2c4fee51d99195e24f3e463a13d7c33c051e2ae30e000e084cb8b4db02494b5d5c80bcebbda0ad0c973fe0468657dc87ca34ca2d3524bbcf2c6e9229f5052f5245f181fcea46728111e951dc31c7680a33f7232a3586eebb3bfa11, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
1db9598739686855d1a14b2c86cdc9eff5fa7b6cc589e409caba877fd75ac8a11a4ceca3d8402569655c05132bd826bf8c7847217f505df565276d23d9b47119645722e6cdef4896f241f6ea658bbb47ed8265aaf3ceb603d2ed16b4ea7841ca188b732b7b009f1214646484d9784883ce89232ff285515a5876dfb95ca4d7ebb0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
