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

cludes 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 ma-

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

ever, 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 con-

6
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 / / 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
2 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 ∗/ ) ;
3 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 ∗ / ) ;
4 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 ) {
5 i n t sum = 0 ;
6 f o r ( i n t i = 0 ; i < N ; i ++) {
7 i n t vote = in . p [ i ] . $val ;
8 i f ( v o t e == 1 ) {
9 sum += 1 ;
10 }
11 }
12 }
13 o u t . I n i t i a t i v e C o u n t . $ v a l = sum ;
14 i f ( v o t e s >= N / 2 ) {
15 / / Campaign s u c c e s s f u l
16 out . I n i t i a t i v e R e s u l t . $val = 1;
17 } else {
18 / / Campaign u n s u c c e s s f u l
19 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