A (Brief) Comparison of Cryptographic Schemes for Electronic Voting Tartu, Estonia May 17, 2004 Berry Schoenmakers Technical University of Eindhoven The Netherlands

Personal Experiences Cryptography, since 1993 (CWI, DigiCash, TUE) Privacy-protecting electronic payment systems e.g., eCash system at DigiCash (Chaum’s blind signatures) Electronic voting schemes since 1994 homomorphic approach ‘shadow election’ May 1998 during Dutch national elections technical advisor of VoteHere EU project CyberVote (Sept. 2000 – March 2003) consultancy for the Dutch government KOA-initiative (“Kiezen Op Afstand”) upcoming experiment for ex-patriots (by touch-phone and internet) (Next “wave:” other practical two/multiparty computations, e.g. millionaires, private matching, secure auctions, …)

Paper-based elections Advantages: Easy to understand. Transparent: in principle, observers may monitor the process for correct execution. Disadvantage: Requires physical presence of voters, talliers, observers Fundamental properties: Security: election result must be verifiably correct Privacy: individual votes must remain secret

Electronic elections Solve security and privacy issues: By trust? By legal measures? By technology? Yes, using cryptography! Cryptographic approaches to electronic elections have been studied since the early 80s. Electronic elections form a primary example of a secure multiparty computation.

“Trusted party scenario” Voting: 1. Voter connects to voting server through an SSL connection (as with “secure web servers”) 2. Voter authenticates himself/herself 3. Voter casts a vote Tallying: Server (trusted party) sums all the votes and announces the election result

Problem: level of trust in insiders Attackers Outsiders, i.e., anyone on the Internet: May try to attack the SSL connection or the server. Relatively easy to counter Insiders, i.e., those who run the election: May try to alter the election result May try to learn people’s votes Much harder to counter "Those who cast the votes decide nothing. Those who count the votes decide everything." Josef Stalin

Bulletin board model Sub-tally 1 Sub-tally 2 …………. Registered voters Alice 56805761456784158 signed Tallier #1 Sub-tally 1 32234555459085752 signed Bob 56459845645454766 signed Carol 49135784578454685 signed Tallier #2 Sub-tally 2 72378867307863836 signed Diane 59643456456845463 signed …………. Registered voters Registered talliers Sub-tally 10 89873538968735603 signed Tallier #10 …………. Scrutineers/observers (or, just anybody)

Election Roles Election Officials Voters select a PKI (“one (wo)man, one key pair”) for authentication of voters, talliers and officials run the Bulletin Board server(s) assumption: access to Bulletin Board is not anonymous Voters large-scale elections many voters, “vote&go” Talliers (possibly incl. MIXers) scalable distributed trust possibly a large number of talliers, e.g. 100 talliers Scrutineers (or, observers, auditors) can be anyone: universal verifiability

Bulletin Board = server network Properties (public broadcast channel): Anyone can read BB Nobody can erase anything from BB Voters, talliers, officials write ballots to their own sections, signed with their public keys BB produces signed receipts (threshold signature) Implemented as a kind of Byzantine agreement Replicated design prevents denial-of-service by BB if < 1/3 of the BB servers is malicious, then BB is reliable e.g., Rampart toolkit (Mike Reiter)

Requirements for voting systems Only registered voters may vote Each voter may vote only once Ballot secrecy (privacy) Public verifiability of election result Robustness No interaction between voters No vote duplication (copying someone’s encrypted vote without knowing the vote)

Authentication vs. encryption Separate voter authentication from vote encryption: makes it easy to exclude double voting Voter authentication Ranging from weak to strong: UserID/password Challenge/response, possibly using hardware tokens (e.g., as used for Internet banking access control, ChipKnip) Digital signatures, PKI Vote encryption Special protocols

Hard nut to crack Privacy and verifiability at the same time Ballot Secrecy: even when the system is fully audited, all individual votes should remain private Public Verifiability: anyone (incl. observers, auditors) is able to verify the integrity of the election result against the encrypted votes cast by legitimate voters

Modern cryptography Achieving privacy and verifiable security at the same time cannot be solved using conventional (public key) encryption and authentication techniques only. but requires advanced techniques such as: zero-knowledge proofs of knowledge verifiable secret sharing homomorphic encryption threshold decryption

Universally verifiable voting Homomorphic schemes: Benaloh et al. mid 80s Sako-Kilian 1994 Cramer-Franklin-Schoenmakers-Yung 1996, Cramer-Gennaro-Schoenmakers 1997 First practical homomorphic encryption protocols Damgård-Jurik 2001 (using Paillier cryptosystem) Verifiable MIXes Sako-Kilian 1996 Neff 2000 First practical publicly verifiable mix protocol Furukawa-Sako 2001 Groth 2003 Important innovation: efficient zero-knowledge proofs

Verifiable black box E1 = Ballot Alice Black Box Counting Process using private keys of talliers E1 = Ballot Alice E2 = Ballot Bob T = Final Tally Aux = Sub-tallies E3 = Ballot Carol Em = Ballot Diane Verify (E1,…,Em, T, Aux, public keys of talliers) = accept or reject

Some intuition: secret sharing Single tallier sees everything: Random split between two talliers:

ElGamal encryption (a, b) m m uses uses Receiver’s private key: x Receiver’s public key: h = gx Sender encrypts plaintext m: (a, b) = (gw, hw m), using a random w Receiver decrypts ciphertext (a, b): b / ax = m (a, b) Receiver m m Sender ciphertext plaintext plaintext h x uses uses

Homomorphic ElGamal encryption Consider a vote v Î {1,0} @ {yes,no} Ballot is ElGamal encryption of vote gv: (a, b) = (gw, hw gv), Homomorphic property: (a, b) * (a', b') = ( gw+w', hw+w' gv+v' ) Tallying: decrypt product of all ElGamal encryptions to find sum of votes.

Use of zeroknowledge proofs Question: How to prevent voters from sending in ballots like these? (a, b) = (gw, hw g2) double yes (a, b) = (gw, hw g-4) -4 times yes (a, b) = (gw, hw g1000) 1000 times yes Answer: use zero-knowledge proofs to prove that each ElGamal encryption contains either g0 or g1 without revealing any additional information.

Homomorphic approach Each voter Vi post an ElGamal encryption: (ai, bi) = (gwi, hwi gvi) plus a zero-knowledge proof that vi=0 or vi=1 Compute (Pi ai , Pi bi) = (gW, hW gT) with W = Si wi and T = Si vi Talliers threshold-decrypt (gW, hW gT) to get gT and finally T

Verifiable MIXes ….. encrypt using talliers' public key SSL/WTLS channels (authenticated) vote1 Voter Attacker vote1 vote2 vote3 vote3 vote2 vote3 ….. vote2 vote2 vote2 Voter Voter vote3 vote1 vote1 vote1 Vote server (aka "bulletin board") MIX server MIX server Talliers Each MIX server takes the votes on the bulletin board, transforms and changes their order and puts them back on the board. This type of provable MIX based solutions has been proposed by Masayuki Abe and Markus Jakobsson. An alternative way is to use traditional MIXes First the voter obtains anonymous authorization from the vote server using blind signatures Then the voter sends his vote and the authorization to the tallier via a MIX network. In order to do this, the voter has to decide the sequence of MIXes to use, and repeatedly encrypt the message with the public key of each MIX in the sequence. This is essentially the scheme that the iSOCO internet voting expert (Andreu Ribera Jorba) uses in his thesis. The drawbacks are: blind signatures are expensive mobile node has to perform many encryptions; security can be increased by increasing the number of MIXes, but this also increases the load on the mobile node. In the provable MIX approach shown in the slide, the mobile node performs only one encryption and one standard signature. The rest of the work is done by the servers. result Voter vote3 encrypt using talliers' public key (Modified El Gamal encryption) transform and permute decrypt

Cryptographic techniques Blinding of ElGamal encryptions: Input: (a, b) = (g w, h w m) Output: (a', b') = (a, b)*(g r, h r) = (g w+r, h w+r m) where r is random plus a zero-knowledge proof of correctness Verifiable MIX, e.g. 2 x 2 MIX: E1 Secret, random π, secret blinding E'π(1) E2 E'π(2) plus a ZK proof

Performance: Work per player Counting modular exponentiations m voters, n talliers, m >> n Complexity of zero-knowledge proof: f Homomorphic Verifiable MIX Voter O(f) O(1) BB O(mf) O(mn) Tallier O(m) MIXer n.a. O(m), sequential Scrutineer

Solution = Protocol + Infrastructure Voting protocol: cryptographic core of the system, protects even against insiders (who run the system) Security infrastructure: required to stop a multitude of attacks, related to e.g.: Security of client and server computers Security of (voting) application software Security of communication between these computers ……………. Shortcomings of the cryptographic protocol cannot be remedied by strengthening the security infrastructure

Author’s address Berry Schoenmakers berry@win.tue.nl Coding and Crypto group Dept. of Math. and CS Eindhoven University of Technology P.O. Box 513 5600 MB Eindhoven Netherlands berry@win.tue.nl http://www.win.tue.nl/~berry/