Proposed Architecture - College of Engineering and Applied Science
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.
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. iv
TABLE OF CONTENTS
CHAPTER
I.
II.
Voluntary Voting System Guidelines Overview .................................................. 14
Independent Verification Systems ............................................................ 17
III.
IV.
v
Web Server Redundancy........................................................................... 23
Minimize the Attack Surface Area ........................................................... 24
Layered Operating Systems ...................................................................... 25
V.
Instructions, Issue Presentation, and Verifying the Ballot ............................... 38
vi
Key Generation Program .......................................................................... 48
VI.
VII.
Using Multiple Programming Languages ........................................................ 61
VIII.
vii
Secret Share Encryption and Decryption ......................................................... 64
viii
Ballot Re-access Using the Back arrow ........................................................... 72
IX.
X.
XI.
APPENDICES
A.
INSTRUCTIONS TO BUILD A DEMONSTRATION SYSTEM .......................80
B.
INSTRUCTIONS TO RUN AN ELECTION........................................................82
C.
ix
LIST OF TABLES
x
LIST OF FIGURES
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).
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
13 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.
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.
15
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 voting system creates a record of the voter’s selections and then copies it to unalterable storage media.
18
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
Kerberos Realm Admin
Key Distribution Center
Ubuntu Server
Kerberos Realm Admin
Key Distribution Center
Ubuntu Server
Voting Server
MS Web Server
Internet
Service
Provider
Outside
World
Voting Server
MS Web Server evote Private
Network
Tally Server
Ubuntu Server
SQL Server
Ubuntu Server
Tally Server
Ubuntu Server
SQL Server
Ubuntu Server
Legend:
Service(s)
Operating System
General Function Server
Ubuntu Server
General Function Server
Ubuntu Server
DNS server
DNS server
Figure 1. Proposed Architecture
GPS
Receiver
Election Judges
Workstation
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
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.
Western Digital
1TB
WD1TB
Western Digital
2TB
WD2TB Dell XPS 410
Windows Vista
Internet
Service
Provider
Outside
World
Cliff’s
World
1 Gbps
Network
Ignis
Dell T310
ESXi
Kerberos Realm Admin
Key Distribution Center
Ubuntu Server 12.04
Athos.evote
192.168.128.129/28
192.168.0.129/24
Broadband
Modem Netgear FV318
- Firewall
- DHCP
Tally 1 Server
Ubuntu Server 12.04
Porthos.evote
192.168.128.130/28
192.168.0.130/24
Tally 2 Server
Ubuntu Server 12.04
Aramis.evote
192.168.128.131/28
192.168.0.131/24
Keebox
8 Port GB Switch
Gb2 – Ignis2
Demo
Outside World
DNS server
NTP server
Public Key server
Ubuntu Server 12.04
Dumas.evote
192.168.128.133/28
192.168.0.133/24 eVote Private Network
192.168.128.128/28
Linux Development
Linux 12.04
Basil.evote
192.168.128.134/28
192.168.0.134/24
Voting Server
Windows Web Server 2008 dArtagnan.evote
192.168.128.132/28
192.168.0.132/24
Web Development
Windows 7
Peabody.evote
192.168.128.135/28
192.168.0.135/24
Linux Development
Linux 12.04
Merlose.evote
192.168.128.136/28
192.168.0.136/24
Gb1 – Ignis1
Legend:
Service(s)
Operating System
Fully Qualified Domain Name eVote addr admin addr
Demo-admin Network
192.168.0.0/24
Figure 2. Ignis 32-bit Development System
35
Prometheus
EAS Cloud eVote Resource Pool
Kerberos Realm Admin
Key Distribution Center
Ubuntu Server 12.04
Athos.evote
192.168.128.129/28
Tally 1 Server
Ubuntu Server 12.04
Porthos.evote
192.168.128.130/28
Tally 2 Server
Ubuntu Server 12.04
Aramis.evote
192.168.128.131/28
Legend:
Service(s)
Operating System
Fully Qualified Domain Name eVote addr
Internet
Service
Provider
Outside
World
Demo
Outside World
DNS server
NTP server
Public Key server
Ubuntu Server 12.04
Dumas.evote
192.168.128.133/28 eVote Private Network
192.168.128.128/28
Linux Development
Linux 12.04
Basil.evote
192.168.128.134/28
Voting Server
Windows Web Server 2008 dArtagnan.evote
192.168.128.132/28
Web Development
Windows 7
Peabody.evote
192.168.128.135/28
Demo-admin Network
128.198.x.x
Figure 3. Prometheus 64-bit Demonstration System
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).
36
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.
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.
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.
37
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
38 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.
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
39 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
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
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.
40
Figure 4. Example Ballot
The demonstration system includes three programming classes - Issue, Crypto, and KTCP.
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 writein name, the write-in checkbox is asserted. This is in addition to the write-in name being
41 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
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
42 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
2 32 − 1 total votes without loss of accuracy.
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
43 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.
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.
44
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.
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.
45
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 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
46
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 issueselection 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 writein 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. Issueselection 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 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 writeonly medium. Instead, the entire ballot string should be written separated by a record indicator.
47
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 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.
48
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.
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
49 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 59. 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 Standard 1 (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 runs / record
DES
AES
128
AES
192
AES
256
ElGamal
128
10,000 10,000 10,000 10,000 10
ElGamal
256
10
ElGamal
512
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 runs / record
32-bit Linux
32-bit Windows
64-bit Linux
64-bit Windows
Paillier
64
10
Paillier
128
10
Paillier
256
10
Paillier
512
10
Paillier
1024
10
Paillier
2048
10
Paillier
4096
10
0.620 0.833 1.388 3.398 10.206 30.997 92.325
0.710 1.261 2.951 9.247 32.041 100.295 305.875
0.311 0.349 0.477 0.807 1.914 5.374 15.809
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.
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
53 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
Table 3. Block Paillier Method
Key Size
32-bit Linux
32-bit Windows
64-bit Linux
64-bit Windows
64
0.607
0.660
0.357
0.470
128
0.839
1.156
0.406
0.541
256
1.401
2.807
0.554
0.916
512 1024 2048 4096
3.397 10.193 30.948 93.351
8.600 29.832 94.428 288.980
0.930
2.073
2.216
6.460
6.090
22.008
17.806
68.873
Table 4. Generalized Paillier Method
Key Size block count
32-bit Linux
32-bit Windows
64-bit Linux
64-bit Windows
64
183
128
92
256
46
512
23
1024
12
2048
6
4096
3
310.699 175.858 151.765 152.606 175.026 202.824 269.460
902.606 580.257 515.191 514.770 576.426 674.665 826.454
81.945 37.679 31.461 31.181 36.355 41.627 53.746
260.224 144.404 127.923 126.033 149.162 171.257 214.675
54
key bit-size for generalized Paillier method.
3,000
2,500
2,000
1,500
1,000
0,500
0,000
-0,500
-1,000
64 128 256 512 1024 2048 4096
Key Bit Size
32-bit Windows
32-bit Linux
64-bit Windows
64-bit Linux
Figure 5. Block Paillier Method
3,500
3,000
2,500
2,000
1,500
1,000
0,500
0,000
64 128 256 512 1024 2048 4096
Key Bit Size
Figure 6. Generalized Paillier Method
32-bit Windows
32-bit Linux
64-bit Windows
64-bit Linux
55
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
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
56
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.
Table 5. DES and AES Key Generation
DES
AES
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 runs / record
ElGamal
64
10
ElGamal
128
10
ElGamal
256
10
ElGamal
512
10
ElGamal
1024
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
57
Table 7. Paillier Key Generation runs / record
Paillier
64
10
Paillier
128
10
Paillier
256
10
Paillier
512
10
Paillier
1024
10
Paillier
2048
10
Paillier
4096
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.
5,000
4,000
3,000
2,000
1,000
0,000
-1,000
-2,000
-3,000
32-bit Windows
32-bit Linux
64-bit Windows
64-bit Linux
64 128 256
Key Bit Size
512 1024
Figure 7. ElGamal Key Generation
58
-1,000
-2,000
-3,000
-4,000
3,000
2,000
1,000
0,000
64 128 256 512 1024 2048 4096
Key Bit Size
32-bit Windows
32-bit Linux
64-bit Windows
64-bit Linux
Figure 8. Paillier Key Generation
As with the block Paillier encrypt-decrypt time in section Generalized Paillier
Cryptography, page 52, 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.
59
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.
60
Table 8. Ballot Casting Times runs / record
Key
Fetch
10
Array
Ballot 1
10
Array
Ballot 2
10
Array
Ballot 3
10
Write In
1
10
Write In
2
10
Write In
3
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
62 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?
64
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.
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.
65
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
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
66 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
67 out after the election closes? Note that deleting an encrypted ballot from the encrypted accumulation may not be feasible.
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
68 presented in both places. Also, ballots are required to be multi-lingual. This requirement is also better accomplished by a database.
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.
69
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 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 writein 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 66?
If more than one unalterable storage media server is used, how should the failure of one Tally server be handled?
70
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
2 16 − 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 43.
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.
71
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 32bit program. When a 64-bit compatible version of Kerberos for Windows is available, these programs may be updated.
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.
72
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 webbased 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 tally. Service principals communicate with each other only after mutual authentication.
74
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 63. 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.
DES
DLL
DNS
EAC
FVAP
3DEC
AES
API
ASCII
CSV
GPS
IDE
IIS
IP
KDC krb5
KTCP
CHAPTER 10
ABBREVIATIONS AND ACRONYMS
Triple Data Encryption Standard
Advanced Encryption Standard
Application Program Interface
American Standard Code for Information Interchange
Comma Separated Value
Data Encryption Standard
Dynamic-Link Library
Domain Name Service
Election Assistance Commission
Federal Voting Assistance Program
Global Positioning System
Integrated Development Environment
Internet Information Services
Internet Protocol
Key Distribution Center
MIT Kerberos version 5
Kerberized Transmission Control Protocol
SQL
TCP
UCCS
US
VS
VSTL
VVPAT
VVSG
MAC
MIT
MPIR
MS
NTP
OS
PC
SERVE
SPRG
Message Authentication Code
Massachusetts Institute of Technology
Multiple Precision Integers and Rationals
Microsoft
Network Time Protocol
Operating System
Personal Computer
Secure Electronic Registration and Voting Experiment
Security Peer Review Group
Structured Query Language
Transmission Control Protocol
University of Colorado at Colorado Springs
United States
Visual Studio
Voting System Test Laboratory
Voter Verifiable Paper Audit Trail
Voluntary Voting System Guidelines
76
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.
78
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
79
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_MastersProjectRep ort_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 Comments
Configuration 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
Notes
Notes 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
Comments
The 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.
2 Configuration
These configuration sections may be completed in any order.
2.1
Configure Linux Servers
See configLinuxServers.docx
1.
configDNSnNTP.docx
2.
configKerberos.docx
2.2
Configure Windows Web Server
See configWebServer.docx
2.3
Configure Development Platforms
1.
See configLinuxDevelop.docx. a.
configDNSnNTP.docx b.
configKerberos.docx
2.
See configWindowsDevelop.docx. a.
mpir_load_notes_v2.docx
3 Configure Mutual Authentication
See configMutAuth.docx
4 Compilation
The compilations sections may be completed in any order.
4.1
Compile eVote and Metrics Programs
See compilePrograms.docx
4.2
Compile eVote Web Site
See compileWebSite.docx
5 Running Programs
See runElection.docx
See runMetrics.docx
81
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 Center
Start Athos. The Kerberos service will start automatically.
2 Public Key
Start Peabody, Basil, and Dumas. The DNS service on Dumas will start automatically.
2.1
Generate Public Key
On Peabody
1.
Double click on GenKeyShares.exe. This should produce two files on the
Desktop - PubKey.txt and PvtKey.txt.
2.
Open WinSCP a.
Logon to Basil b.
Copy Desktop\PubKey.txt to Basil ~/Desktop
2.2
Load Public Key
On Dumas
1.
dumas$ cd ~/KNServer
2.
dumas$ scp admin@192.168.128.134:~/Desktop/PubKey.txt .
3.
dumas$ ./KNserver
3 Tally Servers
Start both Porthos and Aramis.
1.
Be sure to clear the tally folder a.
host$ rm -f ~/tally/Issue*.txt
2.
Configure both Porthos and Aramis a.
host$ cd ~/KTServer
83 b.
host$ sudo ./KTserver started with sudo
#KTserver uses restricted ports, must be
4 Start the Election
Start D’Artagnan
Clear the voters database
1.
Start SQL Server Management Studio
2.
Connect to SQLExpress
3.
File | Open | File
4.
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_voters
6.
Click Execute
5 Troubleshooting
After 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 Election
When the election is complete:
1.
create tally folders in Basil for Porthos and Aramis. a.
basil$ mkdir ~/tallyPorthos b.
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:~/tallyPorthos ii.
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 data a.
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.
e.
Click Decrypt. The decrypted information should appear in the Decrypted
Ballot line.
84
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 key
372971baf46384737eec84b2fb4ac44c75c3c1364901228892e6acea03576e2a181bd145a7
79a076d3269d6574d765887cb8d4c9503215d28c2c46755530d95d1
2 Private key
Note that the commas must be replaced with tabs to accommodate the expected private key file format. bashful,evote,1,24f6554c2b89ab004323de3d4c88da67856597b0e30659b12c8ecde4a373
61b01b78427b69931aded3a3bf3844959c236b6dd2ce92e497de7387626fb95f44225 doc,evote,2,99b297846c4308c315e24d22b4ec303ec8cccfd260ac3feb4626bb09dbf9477e d42a90ad351db6060802512c7420c9b5dac858547b7858528f4cb360fafa9a50 doppy,evote,3,23b55f57a3183a69a3cb081b6afb01bfa4476bc4a6b3d655b1e0a7734783de
1700ec0b16e40206d8e124cdf13ba62baf44b7240b6fa9c1b8bbb5cdf000e1215fe grumpy,evote,4,27facbaf3a9222ca374aec036ab12f797f3a1ba943242f453d47f208edad82 b9aba6406ab03e7fbec6b9d9fcdcc6ff71e09a0aabd3d0454c913733b165759fbdf happy,evote,5,24ab4fefba1c85307aab92784dfa95cc5cd4583227f8fe501bd6937e08134b6
5abef216f41bc8ff558e06c45a80f37e6e1a6a7a8d721ee69b120c036b1ff2874 sleepy,evote,6,cd7453cbd7e12902e90618b0a8a552dabf0d496fdebfe5dd033849a76f282b
7abbb6bb7baa1a675783d4ca14e5f3e81236f1e1e563a88d1e337f359e9f49a3e0 sneezy,evote,7,337fc2e86e96e026c7c8cdcb561f90177a0d31bcfc8d3bc753cf61f701461f1
40be9565dbfe49b0e73166922683e4c153d5d56ab477091b45b41f93e0fa664aa4
3 Trial Data
The 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
Issue001A
ca7ef280148d9a9af12e3654c42fcac7e13c38e1ff03b11727472d7dd3199454114db5f89aa b7e8062ea31aeffea9fa117c0e29f220fbff99c47fbf25c4ac717dddbd2a9eb023dba4cc3baa0
86
31ca32c361051a4d2f5601d62d808781f49a3b8a0d980c37c6821fc14259dd6289ab2710b7
3841406922bd110d4e05881797e60a
0, 1, 0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0
3.2
Issue001B
40302c309bcd17f30d5a267a1575734d066fe1476f955b23479aa7b6a2fd786046e58f89f9d d5edb095fcb941eef30874b1cc621d473b569c441004038176310c09f40afa1b3bc74ba770 e9147d1cfb72e4cda11d71bad1457d51576d1f386d13f0157240f8b4a08c45383185de1845 b93d006e3d5b82c2a6e29ab6ba2ca83133
0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0
6d832276c4adc432357fa13e266ec38e25bf3acd1d81fe3dc29c62d362d803913f42e83ae7e a841781a4d212067b419e87552e9a31c32284157a08e0e8a33faed1edc72c02d37c0ab9828
26e30f480537544125d80e0d66556de7c7991cafadeb49f9b30d598e899856a3ecd64f345a
66f4736fe4e0cc52a0df9cbc7c65cf91cc
0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0
3.3
Issue001W
123450465c2840f918f3fe54a3e4500c61322450a1d016f28a33bfe878d82a4765ea30ec90d
3ac2c186d549d46a8dedf6f54e488e1ef6a232e583490c152b8861f25ec26c3c1d3e9ab6c9e af095c4f6dd72cee243e4b288dceadbb8c96f69a8bfbacac4bebf86a7dbe389b3c465397f1f2
6615c4f9ee695d4a2a76f73157feeb4
UC Bearcats
3.4
Issue002A
4322ee934db08a257221bd15ed765e8e24549f1d968854fac688119fa95c83bf3f0ad76335e
8ad0094fcee3b2192de0d60175ac39d6484c41bf89285eda8551ce9a1ac55cf188135cdbdf6
3eca99752d2898a4549aa86b06f8142f5024a378f435c549f80e444da71ce1342d9612676d
21f0732263838ae7120c8ca2586c3d8e8
0, 0, 1, 0, 0, 2, 1, 0, 1, 1, 2, 0, 0, 0, 0
3.5
Issue002B
a4f40ba2dfa28429604870cadab7cb6cef894cb4de0dfc5a8a0c847ace0335495e849c05052 ecb8a07df868709c1a84880cc17215972fbe0c8c82edb01eba237843723ea2530b9a7a80fd
4fbee8a6cbd5428119d480f9b251d7a450a6e9a23353515229933a233a12e00686723eb454 fb9ace5b2e06abd8b37c6656c34c71491a
0, 0, 1, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0
524ad086fad07e6b716da71118d403dd39586e8ef0d5394cc71c1903fc0a9a60317d730ddd
5454d78552590d9bd1fdd4582b5721c00031c2f00932ff57d22b06f0dae329cef93722d8e4
58208a11b4aacd6e6e35b0534b0acc49c3890b5e845d6f37dbb098063991583e8f4f0c70f0
98d899fd745da8b5a9637780a4735f29e0
0, 0, 0, 0, 0, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0
3.6
Issue002W
4aef74ef766e719505d2386513c55fd902f46be42654d8fdb66359d8fb5b9fa87ace75b5a5b
531dfad3d2866f1c36df1bfd43bc0ec19baaeb1cb60df4090c80f75ff1b783e0c85102a859e2
87
58cac95c4e926d39d672873b1b983948b8badaa889de8496c3753be3eb4a3bb4e8596f28a1 c31371b4331a8ce6ee3a51883459a4f0
UCCS Mountainlions
3.7
Issue003A
5cf72281eac98036a3c91e36c708b159679db230cd65a8a6c7bef77efe8abb6c60b65f36122 db15ec566a009e0440766f01dcd4ebf747029e1f2caf314a460ffc33ad296356370663d4a76 a4616498354ecbd2b39a0b4581824c318c16ab322b04775507f10e5afd4352cc2cedfb0b7e
7ba5c596a30f8223514fd27c74675df1a
1, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
3.8
Issue003B
3d5a6f3fa6897f6101ca1a0c45ba021a0b04ef6c2a7056cc3c60450f8b36226149470387593 f2c4fee51d99195e24f3e463a13d7c33c051e2ae30e000e084cb8b4db02494b5d5c80bcebb da0ad0c973fe0468657dc87ca34ca2d3524bbcf2c6e9229f5052f5245f181fcea46728111e9
51dc31c7680a33f7232a3586eebb3bfa1
1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
1db9598739686855d1a14b2c86cdc9eff5fa7b6cc589e409caba877fd75ac8a11a4ceca3d84
02569655c05132bd826bf8c7847217f505df565276d23d9b47119645722e6cdef4896f241f
6ea658bbb47ed8265aaf3ceb603d2ed16b4ea7841ca188b732b7b009f1214646484d978488
3ce89232ff285515a5876dfb95ca4d7ebb
0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
