Proposal For Secure Electronic Voting Willem Wyndham, Spencer Chen, Saurav Das University Of Maryland, College Park September 29, 2016

1

Abstract We present a new electronic voting system that employs blockchain technologies along with cryptographic techniques to obtain verifiable results while still retaining voter privacy. At a high-level, a vote is encrypted and the a proof of the vote is sent to a public blockchain from an electronic polling station. A centralized authority then decrypts all the votes and posts the tally along with a proof that the reported results are correct and the voter can check that their vote was cast.

1

Introduction

There is a need to update voting technologies to improve trust, reliability, and convenience [1]. We introduce a novel system for electronic voting based on a public blockchain. This system ensures that encrypted votes on the blockchain are reliably counted, while ensuring voter privacy. The primary way voters cast their ballots is by using electronic voting stations, which will send the encrypted ballots to the blockchain. We designed the system with the following criteria in mind, based on previous literature [2]. • Privacy - Keeping an individual’s vote secret • Eligibility - Allowing only registered voters to vote, with each such voter voting only once • Hiding interim results - Partial results should not be released during the voting period • Verifiability - The ability to trust the vote tallying process

2

• Receipt-Freeness - Voters should be unable to prove to a third party that they voted in a particular way. This is required to prevent coercion [3] • Convenience - Voters must be able to vote easily, and everyone who is eligible must be able to vote

2

Current Voting System

There are many different ways to vote today. We will therefore discuss some of the drawbacks to modern voting and discuss how these may or may not appear in our system. Currently it is possible to vote without attending a public polling location. A voter can vote remotely through the use of absentee ballots for residents that are temporarily out of state or through vote-by-mail systems such as Oregon. While these systems help to increase voter participation, they make fraud much easier and rely on the US postal service to not lose ballots and to time stamp them correctly. By discussing these various methods we provide background on the positives and negatives that we can consider in our proposal.

2.1

Paper Ballot

Paper ballots are the traditional tool used for voting. Paper ballots are usually punched or marked by a human and then tallied by machine. Paper ballots come at a much cheaper cost than electronic systems. They also reduce the attack surface on an election by removing the possibility of a soft-

3

ware/hardware attack. Paper ballots rely on physical security and trust in the polling stations to not manipulate them and to properly handle them.

2.2

Electronic Voting Machine

We define an electronic voting machine to refer to computers that a user can use to submit a vote. This would include many current systems such as the Direct Recording Electronic system. As with many electronics, there is am inherent problem with being able to modify software in order to insert malicious code. There have been many proof of concept attacks against types of direct recording electronic systems such as the Diebold AccuVote-TS voting machine. These systems have been shown to be modified by an attacker in a little under a minute [4]. As part of our proposal we acknowledge that end point security is critical to our voting systems and discuss the topic later on.

2.3

Vote by Mail

Voting by mail allows votes to not physically attend a location and still vote. Voting by mail includes both Oregon’s current system as well as absentee ballots. Even though the physical security for the ballot is removed, Oregon voting fraud appears to be rare. Oregon has implemented a system that has many rigorous checks when registering to vote by mail [5]. Oregon’s success is important to our proposal. As we discuss later, we find that in our system there may not be the rigorous physical checks. A specific implementation could look at the determinants Oregon is successfully using. 4

2.4

Centralized Online Voting

Our proposal defines centralized online voting to be a voting system where users interact with website to vote is recorded and tallied in an electronic system. The online voting identifies many advantages such as convenience for the voter and quickness of results. The online voting system also introduces hosts of problems that have not been considered. The online voting systems have to worry about issues such as privacy, fraud, voting under duress, and corruption. Online voting has been in used in Estonia and many similar concerns have been voiced about the system. Issues such as being corruption and the ability to conduct a recount are concerns [6]. Our proposal is an electronic system that handles counting votes with security, privacy and accountability. In a specific implementation, our proposal could be a pure online voting system or be electronic voting machines interacting with our electronic system. We discuss general ideas about an implementation regarding electronic voting machines in a later section.

3

Our Solution

We propose using physical voting locations with machines licensed by the government. Each machine contains a copy of a global public key which is used to encrypt ballots. Upon registering to vote, a voter is given a special card that contains their public id and is used to verify them to the machine. When a voter casts a vote, their ballot along with a randomly generated salt r2 is encrypted with the government public key. This prevents the user from creating a reproducible ciphertext, which 5

could be used to prove how the voted. The voter is also given a randomly generated number r1 that serves as their receipt. Their id and r1 are hashed and eventually added to a Merkle tree [7] which allows the voter to check if their ballot was successfully sent to be counted. A Merkle tree is a cryptographic tree data structure where the leaves of the tree are the hashed data we want to check. Each internal node is the hash of the two children. Checking if a hash is a member of the tree is done in logarithmic time which makes checking membership fast. This allows voters to check to see how their vote is being tallied while still providing receipt-freeness to the contents of their vote.

3.1

Blockchain

The voter’s data is sent to the blockchain. A blockchain is a distributed, decentralized store of information. Because it is decentralized, every piece of information stored on it is agreed upon by several peers. The blockchain provides accuracy of transactions but not privacy as long as no single entity controls a majority of the nodes on the blockchain. We use the Ethereum blockchain implementation as it is Turing-complete, allowing for full programmability. Ethereum [8] provides a new language called serpent for users to make more complicated smart contracts. Smart contracts are publicly visible programs that run reliably on the blockchain. Thus, Ethereum still suffers from the lack of privacy of the original blockchain. However, although the blockchain is publicly visible, the contents within the contract can be encrypted cipher-text. Hawk [9] is an extension of Ethereum that allows for programmers to write programs which compile into all the needed parts of a cryptographic protocol between the users of the smart con6

tract. These parts include the smart contract that will run on the each node in an Ethereum network, a program to be run by the clients and a program that is executed by a special third party called a manager. In our system, clients will be each voting machine. The smart contract will be a program running on the blockchain that will coordinate sending data to the computation server. The Hawk manager will be the government server that will handle decrypting and be responsible for tallying votes. In Hawk the manager is not trusted to do computation correctly and thus must provide proof through a zero-knowledge proof that they did the computation correctly. Hawk also prepares for the case that the manager and the clients can abort early, which will not be the case for our scenario. For a general overview of our solution see Figure 1.

Figure 1: Diagram of Proposal

7

3.2

Zero-Knowledge Proofs

Zero-knowledge proofs (ZKP) are signatures that prove that a computation was done as expected [10]. Anyone can look at the list of hashes sent to the authentication and tallying servers and then confirm that the tally is the result of a certain computation. This computation does not reveal any information about the individual votes, but allows the government to prove that it tallied the votes accurately. That is, the ZKP can show that the computation did in fact use all the available votes, without revealing what the actual votes were. In our threat model we protect against the government manipulating the votes at counting time. In our scheme, we use Hawk to generate both the smart contract and the code to run on the government machines that tally the votes and create the ZKP.

3.3

Endpoint Security

Our proposal above resolves many of the issues of privacy and accountability through modern cryptography. The above proposal does not take into account the integrity of the equipment used in the transaction. We propose secure voting machines which would have tamper proof sensors that would alert authorities if the machines are handled during non-voting hours when the machines are not being watched by poll workers. During registration, each potential voter will be assigned an id number for authentication during the voting process. This id number can be placed onto government issued cards, such as a driver’s license. On election day, the voter will use a specialized voting booth at a public voting location. Each

8

voting booth will be monitored and protected. The voter would present identification to either a software or human and receive a prompt to vote. For voters that submit absentee ballots, their vote can be entered into the a voting machine by a poll worker while being monitored. Upon voting, the machine would send the necessary encrypted data to the blockchain and return a receipt to check voting status. This receipt would be mailed back to the absentee voter.

3.4

Electronic Ballot Machines

Although online implementations would be more accessible, an online voting system is too high risk to implement in the near future. As discussed above, an online voting system would have a very large attack surface and serious hacking groups could silently change an election [1]. Our suggested implementation is to use electronic ballot machines. Although current ballot machines may not be secure, they do provide more of a measure of trust than user owned computers might. For example, these ballot machines will not access the internet except through specifically white-listed sources.

4

Proof of Concept

To implement our idea we rely on Hawk to compile the following code into a smart contract, and user and manager code. The public part is our smart contract that will allow the votes to tallied in private by the manager. Hawk also has a notion of time so that the votes once cast are frozen and

9

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

/ / E l e c t i o n for i n i t i a t i v e with N v o t e r s HawkDeclareParties ( I n i t i a t i v e C o u n t , I n i t i a t i v e R e s u l t , /∗ N Voting P a r t i e s ∗/ ) ; H a w k D e c l a r e T i m e o u t s ( / ∗ h a r d c o d e d t o Time E l e c t i o n e n d s ∗ / ) ; p r i v a t e c o n t r a c t t a l l y V o t e s ( I n p &i n , Outp &o u t ) { i n t sum = 0 ; f o r ( i n t i = 0 ; i < N ; i ++) { i n t vote = in . p [ i ] . $val ; i f ( v o t e == 1 ) { sum += 1 ; } } } o u t . I n i t i a t i v e C o u n t . $ v a l = sum ; i f ( v o t e s >= N / 2 ) { / / Campaign s u c c e s s f u l out . I n i t i a t i v e R e s u l t . $val = 1; } else { / / Campaign u n s u c c e s s f u l out . I n i t i a t i v e R e s u l t . $val = 0;

20

}

21 22

}

Figure 2: Hawk Code won’t be analyzed until the voting period has ended. Figure 2 shows a proposed initiative and how the contract would tally the votes. This code would run on the manager and each voter is given one coin to spend on the election. If the initiative has a majority of votes it receives a coin to their result wallet. Currently Hawk’s performance for the manager scales linearly with the number of clients. They tested a second-price auction with 100 participants and found that it took 2.85 minutes with 4 cores, while on chain computation was only 20 seconds. Client execution time was independent of the number of clients and took 40 seconds, though the authors have ideas on how to improve this by a factor of 10. Not included is an implementation of the merkle tree, but many are available.

10

5

Conclusion and Future Work

Our proposal satisfies privacy and the ability to check votes, voting under duress, availability of interim results, undecided votes, and voting aftermath. We use the blockchain as a ledger to record that a vote has been cast. We also use cryptographic primitives to ensure the votes remain private and are tallied correctly. A Merkle tree on the blockchain serves to prove to voters that their vote was included. By using physical voting locations and maintaining receipt-freeness, we mitigate the threat of voting under duress. Since Hawk has the notion of freezing computation until a predefined time we cannot compute interim results until after the election has finished. Only voters that vote are part of the smart contract. This prevents the votes of abstaining voters from being used. The ZKP provided by the government serves to prove to skeptical parties that the tally is correct. There are several possible ways to expand the implementation. The first possibility is to use homomorphic encryption to allow computation on the cipher text without decryption. One use case is to allow the government to encrypt the data with its key, then retrieve the cipher texts from the blockchain of each vote and add them together. The sum would remain a ciphertext which could be decrypted to reveal a final tally. This would add another layer of privacy for voters as the government would never see their individual vote. Traditionally computation on encrypted data was expensive, but some methods claim to achieve addition of two 32 bit integers in 0.1 milliseconds [11]. This could be added to our solution by changing the manager in Hawk. Another possible addition is to use threshold encryption to decrypt votes rather than just traditional public/private key pairs. This would mean that no one party could decrypt the ciphertext, and could make the system more robust. Hawk [9] already addresses using multiparty computation to achieve this, but

11

advises that it will have bad performance. This would mean the work to decrypt would be spread across multiple computers, thus no one computer can get the result. Though this has a performance overhead it would add again to the privacy of the votes. The next improvement is the use of trusted hardware. Intel has a special set of extensions called Software Guard Extensions (SGX) which allow for special memory enclaves where integrity and confidentiality of computation is protected even from privileged code, e.g. kernel code, running on the machine [12]. Similarly, ARM has an extension called TrustZone and a team at MSR authored Trusted Language Runtime (TLR) on top of .NET microframework, which allows for programmers to safely and easily write code high level code in languages such as C# for the trusted hardware that can communicate with trusted remote parties [13]. This could make end-to-end online voting systems more viable by providing another layer of protection against malicious code. Eventually this could mean expanding use of the blockchain to allow voters to cast their vote on a mobile phone. The last improvement is to allow for instant runoff elections. Instant runoff elections allow voters to rank their choices for each candidate. Then if no candidate receives a majority the last place candidate is removed and votes are redistributed [14]. This could be implemented by using different number of coins in voting.

References [1] Bob Fitrakis and Harvey Wasserman. Distrust of 2016’s hackable election is a media landslide with just one solution: Hand-counted paper ballots. Free Press, 2016.

12

[2] L. (Lauretha) Rura, B. (Biju) Issac, and M. K. (Manas) Haldar. Implementation and evaluation of steganography based online voting. International Journal of Electronic Government Research. [3] S. Delaune, S. Kremer, and M. Ryan. Coercion-resistance and receipt-freeness in electronic voting. [4] Edward Felten Ariel Feldman, Alex Halderman, 2007. [5] Kate Brown. Vote fraud is extremely rare and always unacceptable, apr 2010. [6] Barbara Simons. Report on the estonian internet voting system, sep 2011. [7] Ralph C Merkle. A digital signature based on a conventional encryption function. In Conference on the Theory and Application of Cryptographic Techniques, pages 369–378. Springer, 1987. [8] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, 2014. [9] Ahmed Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalampos Papamanthou. Hawk : The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts. [10] Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. Pinocchio: Nearly practical verifiable computation. In Security and Privacy (SP), 2013 IEEE Symposium on, pages 238–252. IEEE, 2013. [11] Liangliang Xiao, Osbert Bastani, and I-Ling Yen. An efficient homomorphic encryption protocol for multi-user systems. [12] Victor Costan and Srinivas Devadas. Intel sgx explained. Technical report, Cryptology ePrint Archive, Report 2016/086, 2016. https://eprint. iacr. org/2016/086.

13

[13] Nuno Santos, Himanshu Raj, Stefan Saroiu, and Alec Wolman. Trusted language runtime (tlr): enabling trusted applications on smartphones. In Proceedings of the 12th Workshop on Mobile Computing Systems and Applications, pages 21–26. ACM, 2011. [14] Jason Keller and Joe Kilian. A Linked-List Approach to Cryptographically Secure Elections Using Instant Runoff Voting, pages 198–215. Springer Berlin Heidelberg, Berlin, Heidelberg, 2008.

14