Civitas A Secure Remote Voting System

1. CivitasA Secure Remote Voting System Michael Clarkson, Stephen Chong, Andrew Myers Cornell University Dagstuhl Seminaron Frontiers of Electronic Voting July 31, 2007

2. Goals Civitas(name was originally CIVS) Strong,provablesecurity Practicalperformance Remotevoting Clarkson: CIVS

3. Terminology • Voting system: (software) implementation • Voting scheme: cryptographic construction • Voting method: algorithm for choosing between candidates Clarkson: CIVS

4. Security of Civitas • Satisfies strong security properties • Coercion-resistant • Universally verifiable • Against a powerful adversary • With distributed trust in authorities • Election authority: An agent providing some component of the election system • Three different types: registration teller, ballot box, tabulation teller • Using principled techniques • Cryptographic security proofs (by us and others) • Language-based security: Jif (Java + Information Flow) Clarkson: CIVS

5. Remote Voting with Civitas • No supervision of voting or voters • The right problem to solve: • More general problem than supervised voting • Internet voting (Debian, ACM, SERVE) • Absentee ballots Clarkson: CIVS

6. Practicality of Civitas • Implementation • 22,000 LOC in Jif, Java, and C • Performance study • Election tallied in 35 sec / voter / authority • Cost is about 4¢ / voter • Cf. current election costs of $1-$3 / voter [International Foundation for Election Systems] Clarkson: CIVS

7. Civitas: Outline • Security requirements • Design • Based on scheme due to Juels, Catalano, and Jakobsson (JCJ) [WPES ’05] • We added: • Distributed registration • Lightweight ballot box • Blocking • But this talk is not about mechanisms • Security evaluation • Performance study Clarkson: CIVS

8. Confidentiality (Privacy) • No adversary can learn any more about votes than is revealed by the final tally • Anonymity: hide map from voter to vote • Receipt-freeness: prohibit proof of vote • Coercion-resistance: adaptive • Including forced abstention or randomization [JCJ; Delaune, Kremer, and Ryan ‘06] Stronger Voters cannot prove whether or how they voted, even if they can interact with the adversary while voting. Clarkson: CIVS

9. Integrity (Correctness) • Universal verifiability: • Including: • The votes they cast are included • Only authorized votes are counted • No votes are changed during tallying [JCJ, Sako and Killian ’95] All voters can verify that the final tally is correct Clarkson: CIVS

10. Availability • Unavailability of votes can compromise integrity • Missing votes not universally detectable • So need to guarantee availability of votes • Otherwise, availability not guaranteed • Software systems implementing authorities • Results of election • Orthogonal extensions possible • Byzantine fault tolerance • Threshold cryptography Clarkson: CIVS

11. Adversary • May corrupt all but one of each type of election authority • May coerce voters, demanding any secrets or behavior, remotely or physically • May control network • May perform any polynomial time computation [JCJ] Clarkson: CIVS

12. Civitas Architecture registrar tabulation teller bulletinboard tabulation teller voterclient tabulation teller JCJ scheme Clarkson: CIVS

13. Civitas Architecture registration teller registration teller registration teller tabulation teller bulletinboard tabulation teller voterclient tabulation teller Civitas scheme Clarkson: CIVS

14. Civitas Architecture registration teller registration teller registration teller tabulation teller ballot box bulletinboard ballot box tabulation teller ballot box voterclient tabulation teller Civitas scheme What makes this secure? Why do we believe it is? Clarkson: CIVS

15. Security Evaluation • Cryptographic reduction proof by JCJ • Voting scheme provably achieves coercion resistance and universal verifiability • We extended that proof for our distributed registration construction • And we instantiated various oracles, ZK proofs • Gain insight by reviewing election process and assumptions used in proofs Clarkson: CIVS

16. Cryptography registration teller registration teller registration teller tabulation teller ballot box bulletinboard ballot box tabulation teller ballot box voterclient tabulation teller Assumption 1. DDH, RSA, random oracle model. Clarkson: CIVS

17. Registration registration teller registration teller registration teller tabulation teller ballot box bulletinboard obtain credential ballot box tabulation teller ballot box voterclient tabulation teller Assumption 2. The adversary cannot masquerade as voter during registration. Implement with: strong authentication, non-transferable secrets. Clarkson: CIVS

18. Registration registration teller registration teller registration teller tabulation teller ballot box bulletinboard obtain credential ballot box tabulation teller ballot box voterclient tabulation teller Assumption 3. Each voter trusts at least oneregistration teller and has untappable channel to that teller. Why: weakest known assumption for coercion resistance Implement with: advance, in person registration; information-theoretic encryption Clarkson: CIVS

19. Voting registration teller registration teller registration teller tabulation teller ballot box bulletinboard ballot box tabulation teller ballot box voterclient tabulation teller Assumption 4. Voters trust their voting client. Reasonable: voter can choose client Clarkson: CIVS

20. Voting registration teller registration teller registration teller tabulation teller ballot box bulletinboard ballot box tabulation teller ballot box voterclient submit vote tabulation teller Assumption 5. The channels from the voter tothe ballot boxes are anonymous. Why: otherwise coercion resistance trivially violated. Clarkson: CIVS

21. Voting registration teller registration teller registration teller tabulation teller ballot box bulletinboard ballot box tabulation teller ballot box voterclient submit vote tabulation teller Assumption 6. Each voter trusts at least oneballot box to make vote available for tallying. Why: expensive fault tolerance not required. Clarkson: CIVS

22. Tabulation registration teller anonymize and authenticate votes registration teller registration teller tabulation teller retrieve votes audit ballot box bulletinboard ballot box tabulation teller ballot box voterclient tabulation teller Assumption 7. At least one tabulation teller is honest. Why: keeps tellers from decrypting votes too earlyor cheating throughout tabulation. Clarkson: CIVS

23. Implementation • Civitas implemented in Jif [Myers ’99, Chong and Myers ’04 ‘05] • Security-typed language • Static-type checking and dynamic enforcement of information-flow policies • Yields assurance • Code is correct with respect to policies • Policies can be audited and certified Clarkson: CIVS

24. Protocols • Proof of knowledge of discrete log [Schnorr] • Proof of equality of discrete logarithms [Chaum & Pederson] • Designated-verifier reencryption proof [Hirt & Sako] • 1-out-of-L reencryption proof [Hirt & Sako] • Signature of knowledge of discrete logarithms [Camenisch & Stadler] • Reencryption mix network with randomized partial checking [Jakobsson, Juels & Rivest] • Plaintext equivalence test [Jakobsson & Juels] Clarkson: CIVS

25. Protocols • Proof of knowledge of discrete log [Schnorr] • Proof of equality of discrete logarithms [Chaum & Pederson] • Designated-verifier reencryption proof [Hirt & Sako] • 1-out-of-L reencryption proof [Hirt & Sako] • Signature of knowledge of discrete logarithms [Camenisch & Stadler] • Reencryption mix network with randomized partial checking [Jakobsson, Juels & Rivest] • Plaintext equivalence test [Jakobsson & Juels] Quadratic in # voters and votes Clarkson: CIVS

26. Blocking • Assign voters into blocks • Block is a “virtual precinct” • Anonymity guaranteed within a block • Each block tallied independently of other blocks, even in parallel • Implementation • Protocols extended to include blocks • Registrar implements policy on assignment • Best policy might be uniform random • Reasonable block size? We use 100. • Tabulation time is: • Quadratic in block size (thus anonymity) • Linear in number of voters Clarkson: CIVS

27. Performance Study • Experimental design • Emulab: 3 GHz CPUs for tab. tellers • Keys: 1024 ElGamal, 2048 RSA, 256 AES • Experiments repeated three times, sample mean reported, stdev < 2% • Parameters: • V: number of voters • A: number of authorities of each type • K: minimum number of voters in a block Clarkson: CIVS

28. Tabulation Time vs. # Voters Use once then throw away: $1500/machine = $12/voter parallel sequential 35 sec / voter / authority $1/CPU/hr = 4¢/voter (K = 100, A = 4) Clarkson: CIVS

29. Tabulation Time vs. Anonymity (V = K, A = 4) Clarkson: CIVS

30. Tabulation Time vs. # Authorities (K = V = 100) Clarkson: CIVS

31. Extension: Ranked Voting • Voters submit (partial) order on candidates • E.g. Condorcet, Borda, STV • Civitas implements coercion-resistant Condorcet • Tricky because rankings can be used to signal identity (“Italian attack”) • Use ballot decomposition from FEE’05 • Civitas also implements approval and FPTP ballots Clarkson: CIVS

32. Related Work • Voting schemes […] • Implemented (academic) voting systems: • Sensus [Cranor and Cytron] • EVOX [Herschberg, DuRette] • REVS [Joaquim, Zúquette, Ferreira; Lebre] • ElectMe [Shubina and Smith] • Adder [Kiayias, Korman, Walluck] • VoComp: • Prêt à Voter [Schneider, Heather, et al.; Ryan; Chaum] • Prime III [Gilbert, Cross, et al.] • Punchscan [Stanton, Essex, Popoveniuc, et al.; Chaum] • Voting Ducks [Kutyłowski, Zagórski, et al.] Clarkson: CIVS

33. Summary • Civitas is a secure, practical, remote voting system • Security: • Based on JCJ proof • Assumptions • Implementation in Jif • Performance: • Linear (or constant) in number of voters, quadratic in anonymity • As low as 4¢ per voter Clarkson: CIVS

34. Future Work • Improve performance/anonymity trade-off • Construct untappable channel • Security proof for composition • UC definitions and constructions? • Distribute trust in voter client • Implement high availability Clarkson: CIVS

35. Resources • Technical report with concrete protocols http://www.cs.cornell.edu/people/clarkson/papers/clarkson_civs_tr.pdf • Source code to be released Clarkson: CIVS

36. CivitasA Secure Remote Voting System Michael Clarkson, Stephen Chong, Andrew Myers Cornell University Dagstuhl Seminaron Frontiers of Electronic Voting July 31, 2007

37. Extra Slides Clarkson: CIVS

38. Registration and Voting Times • For A=4, total voter time to register and vote is 1.5sec • 350ms for voter to retrieve credential from registration teller • 230ms CPU time for registration teller to retrieve a voter’s credential • 25ms for voter to submit vote to ballot box • Registration teller throughput > 15,000 voters / hr Clarkson: CIVS

39. Tab. Time vs. % Chaff (K = V = 100, A = 4) Clarkson: CIVS

40. % CPU Util. vs. # Voters (K = 100, A = 4) Clarkson: CIVS

41. Attacks: Voter Client • Unlike DRE systems, voter can choose supplier of client (hardware and software) • Transfer trust to an organization they trust • Publicly available protocols and implementation Clarkson: CIVS

42. Attacks: Registration • Strong authentication to prevent adversary from masquerading as voter • Registration by mail or in person Clarkson: CIVS

43. Attacks: Network • Tappable channel exploitable only if adversary: • Compromises network and • Induces voter to use compromised client during registration • Valid registration clients can erase credential shares Clarkson: CIVS

44. Attacks: Availability • BFT, threshold cryptography • Rate-limiting and puzzles to mitigate application-level DOS • But PETs still a fundamental problem Clarkson: CIVS

45. Attacks: Authorities • Corrupt registration teller • Need third-party intervention • Failed bulletin board • Integrity guaranteed, not availability • Corrupt registrar or supervisor • Must verify against external policy (electoral roll, ballot design, etc.) Clarkson: CIVS