An Architecture for Electronic Voting

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

iv

McCullough, Clifford Allen (M.E., Information Assurance)

An Architecture For Electronic Voting

Thesis directed by Professor Edward Chow

This thesis proposes an architecture, publicly available, for a deployable system that is compliant with United States Election Assistance Commission Voluntary Voting System Guidelines requirements. An architecture is described and a demonstration system built and evaluated.

The proposed architecture design decisions are based on two general rules of Information Assurance: 1) Minimize the attack surface; and 2) Mitigate the vulnerabilities. The web-based voting service should not be nationally centralized. The system is kept server-centric rather than personal computer-centric. Servers interchange information only after satisfying Kerberos mutual authentication. Redundancy and restoring to the state before a fault are paramount. The homomorphic properties of block Paillier and generalized Paillier cryptography are discussed and evaluated.

The demonstration system is a proof of concept for the proposed architecture. Cryptographic algorithms for DES, AES, ElGamal, Paillier, and Shamir secret sharing are demonstrated. Technical difficulties involving Kerberos library functions and dynamic link library information interchange are overcome. The demonstration system is not fully compliant with Voluntary Voting System Guidelines requirements. Much future work remains to achieve that goal.

iv

Acknowledgements

This work used the EAS Data Center or EAS Cloud, which is supported by the College of Engineering and Applied Science, University of Colorado at Colorado Springs.

Table of Contents

Chapter

I.  Introduction 12

II.  Voluntary Voting System Guidelines Overview 14

Functional Capabilities 14

Security 15

Accuracy 15

Error Recovery 15

Integrity 15

Vote Tabulating Program 15

Casting a Ballot 16

Accessibility Requirements 17

Security Requirements 17

Maintaining Data Integrity 17

Independent Verification Systems 17

III.  Existing Solutions 19

IV.  Proposed Architecture 21

The General Schema 22

The System Architecture 23

Web Server Redundancy 23

Minimize the Attack Surface Area 24

Layered Operating Systems 25

Compiled Deployment 25

Voting Server Authentication 25

Issue Presentation 27

Verifying the Ballot 28

Casting the Ballot 28

Kerberos Mutual Authentication 30

General Function Server 30

Election Judges Workstation 31

General System Redundancy 32

Paillier Cryptography 32

V.  The Demonstration System 34

Development Platforms 36

Voting Server Authentication 37

Instructions, Issue Presentation, and Verifying the Ballot 38

Casting the Ballot 38

The Issue Class 40

The Crypto Class 41

The KTCP Class 43

Public Key Server 44

Tally Servers 45

Deploying the Website 47

Election Judges Workstation 47

Key Generation Program 48

Shared Secret Decryption 48

VI.  Performance and Comparisons 50

Cryptographic Methods 50

Generalized Paillier Cryptography 52

Encryption Key Generation 55

Ballots 59

VII.  Lessons Learned 61

Freeware 61

Internet Forums 61

Using Multiple Programming Languages 61

VIII.  Future Work 63

Web Site Development 63

SQL Server Positioning 63

General Functions Server 64

Secret Share Encryption and Decryption 64

Paillier Key Generation 64

Ballot Decryption 64

Shared Secret Decryption 65

Ballot Tally Application 65

Error Handling and Logging 65

Redundancy 66

Tally Server Redundancy 66

Ballot Generation 67

Multi-Lingual Database 67

Precinct Ballots 68

Voter Password Handling 68

Password Encryption 68

Password Maintenance 68

Quorum Login 69

Provisional Ballots 69

Write-only Memory 69

Fixed String Sizes 70

Kerberos Mutual Authentication 70

Message Digest 70

Client Credentials 71

Compilation and Linking 71

Blocks versus Generalized Paillier 72

Platform Firewalls 72

Ballot Re-access Using the Back arrow 72

IX.  Summary 73

X.  Abbreviations and Acronyms 75

XI.  Works Cited 77

APPENDICES

A.  Instructions to Build a Demonstration System 80

B.  Instructions to Run an Election 82

C.  Trial Data 85

xi

List of Tables

Table 1. DES, AES, and ElGamal Methods 51

Table 2. Block Paillier Method 52

Table 3. Block Paillier Method 53

Table 4. Generalized Paillier Method 53

Table 5. DES and AES Key Generation 56

Table 6. ElGamal Key Generation 56

Table 7. Paillier Key Generation 57

Table 8. Ballot Casting Times 60

xi

List of Figures

Figure 1. Proposed Architecture 22

Figure 2. Ignis 32-bit Development System 34

Figure 3. Prometheus 64-bit Demonstration System 35

Figure 4. Example Ballot 40

Figure 5. Block Paillier Method 54

Figure 6. Generalized Paillier Method 54

Figure 7. ElGamal Key Generation 57

Figure 8. Paillier Key Generation 58

xi

13

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

13

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.

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.

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.

·  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.

·  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.

20

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).

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).

20

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: