1. Civitas Toward a Secure Voting System Michael Clarkson Cornell University Coin (ca. 63 B.C.) commemorating introduction of secret ballot in 137 B.C. Stevens Institute of Technology March 30, 2009

2. Clarkson: Civitas2 Civitas  Electronic voting system; 21,000 LOC  [Clarkson, Chong, and Myers, Oakland 2008]

3. Clarkson: Civitas3 Evolution of Voting Technology

4. Clarkson: Civitas4

5. 5 State of Secure Electronic Voting Major commercial voting systems are insecure California reviews [Wagner, Wallach, Blaze, et al.] Academics are pessimistic SERVE report [Jefferson et al.]

6. Clarkson: Civitas6 Security of Voting  Was your vote captured correctly?  Was your vote counted correctly?  Can the tally be independently verified?  Is your vote anonymous?  Can anyone sell their vote?  Can voters be coerced? …

7. Clarkson: Civitas7 Potential Threats  Outsiders  Programmers  Election officials  Candidates and parties  Employers, organizations, spouses, …  Voters …Voting systems have some of the strongest and hardest security requirements of any systems

8. Clarkson: Civitas8 Civitas Security Model No trusted supervision of polling places Including voters, procedures, hardware, software Voting could take place anywhere  Remote voting Generalization of “Internet voting” and “postal voting” No unilateral trust in an election authority Instead, mutually distrusting set of authorities  Distributed trust

9. Clarkson: Civitas9 Adversary  Corrupt all but one of each type of election authority  Perform any polynomial time computation  Control network  Coerce voters, demanding secrets or behavior, remotely or physically Security properties: Confidentiality, integrity, availability

10. Clarkson: Civitas10 Integrity Verifiability: Including: Voters can check that their own vote is included Universal verifiability: Anyone can audit the election results; no votes added, changed, or deleted [Sako and Killian 1995] The final tally is correct and verifiable.

11. Clarkson: Civitas11 Confidentiality Voter coercion: Employer, spouse, etc. Coercer can demand any behavior (abstain, sell) Coercer can observe and interact with voter during remote voting  Must prevent coercers from trusting their own observations

12. Clarkson: Civitas12 Confidentiality > receipt-freeness = CR  interaction > anonymity = RF  collusion The adversary cannot learn how voters vote, even if voters collude and interact with the adversary. Coercion resistance: too weak

13. Clarkson: Civitas13 Availability  We assume that this holds  To guarantee, would need to make system components highly available, etc. But it’s really about the votes The final tally of the election is produced. Tally availability:

14. Clarkson: Civitas14 Building Civitas Started with abstract voting protocol… [Juels, Catalano, and Jakobsson, WPES 2005] Extended design to improve security and performance Implemented in security-typed language (Jif) Evaluated security and performance

15. Clarkson: Civitas15 Civitas Architecture bulletin board voter client tabulation teller registration teller ballot box

16. Clarkson: Civitas16 Registration voter client registration teller Voter retrieves credential share from each registration teller; combines to form credential

17. Clarkson: Civitas17 Registration voter client registration teller credential sharecredential

18. Clarkson: Civitas18 Properties of Credentials Verifiable Teller must prove that share is good, but proof is convincing only to voter  Voter can’t sell share Anonymous No subset of shares reveals information about credential  Credentials can’t be linked to voters Unforgeable Creating new credential requires participation of all tellers  Tellers can’t “stuff the ballot box”

19. Clarkson: Civitas19 Registration voter client registration teller JCJ: single trusted registrar Civitas: distributed trust  Improved confidentiality and integrity

20. Clarkson: Civitas20 Voting voter client ballot box Voter submits copy of encrypted choice and credential (plus proofs) to each ballot box

21. Clarkson: Civitas21 Properties of Votes Anonymous Credentials are anonymous Submitted over anonymous channel Replicated  Votes can be deleted only if all ballot boxes collude Non-malleable No one can construct “related” votes  Votes can’t be changed or spoiled

22. Clarkson: Civitas22 Resisting Coercion Voters substitute fake credentials To adversary, fake  real Votes with fake credentials removed during tabulation without revealing which are fake For any behavior adversary demands… Voter complies, with fake credential Voter needs untappable channel to a registration teller

23. Clarkson: Civitas23 Voting voter client ballot box JCJ: no ballot boxes Civitas: distributed storage  Votes highly available

24. Clarkson: Civitas24 Tabulation bulletin board tabulation teller ballot box Tellers retrieve votes from ballot boxes

25. Clarkson: Civitas25 Tabulation bulletin board tabulation teller Tabulation tellers anonymize votes with mix network [Chaum 1981]

26. Clarkson: Civitas26 Mix Network tabulation teller

27. Clarkson: Civitas27 Tabulation bulletin board tabulation teller Tellers eliminate unauthorized credentials; decrypt remaining choices; post proofs

28. Clarkson: Civitas28 Properties of Tabulation Verifiable Tellers post zero-knowledge proofs during tabulation Coercion-resistant No credentials (valid or fake) ever revealed  Voters can undetectably fake credentials

29. Clarkson: Civitas29 Tabulation bulletin board tabulation teller JCJ: O(V 2 ) Civitas: O(B 2 ), B ¿ V  Improved scalability

30. Clarkson: Civitas30 Blocks Block is a “virtual precinct” Each voter assigned to one block Each block tallied independently of other blocks, even in parallel Tabulation time is: Quadratic in block size Linear in number of voters  If using one set of machines for many blocks Or, constant in number of voters  If using one set of machines per block

31. Clarkson: Civitas31 Civitas Architecture bulletin board voter client tabulation teller registration teller ballot box

32. Clarkson: Civitas32 Cryptographic Protocols Leverage the literature: El Gamal; distributed [Brandt]; non-malleable [Schnorr and Jakobsson] Proof of knowledge of discrete log [Schnorr] Proof of equality of discrete logarithms [Chaum & Pederson] Authentication and key establishment [Needham-Schroeder-Lowe] 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]

33. Clarkson: Civitas33 Civitas Security Assurance Design JCJ proof of coercion resistance and verifiability  We extended proof Backes et al. (CSF 2008) verification with ProVerif  Working to verify Civitas Implementation …leverages language-based security

34. Clarkson: Civitas34 Secure Implementation In Jif [Myers 1999, Chong and Myers 2005, 2008] Security-typed language Types contain information-flow policies  Confidentiality, integrity, declassification, erasure If policies in code express correct requirements… (And Jif compiler is correct…) Then code is secure w.r.t. requirements

35. Clarkson: Civitas35 Civitas Policy Examples  Confidentiality: Information: Voter’s credential share Policy: “RT permits only this voter to learn this information” Jif syntax: RT  Voter  Confidentiality: Information: Teller’s private key Policy: “TT permits no one else to learn this information” Jif syntax: TT  TT  Integrity: Information: Random nonces used by tellers Policy: “TT permits only itself to influence this information” Jif syntax: TT  TT

36. Clarkson: Civitas36 Civitas Policy Examples  Declassification: Information: Bits that are committed to then revealed Policy: “TT permits no one to read this information until all commitments become available, then TT declassifies it to allow everyone to read.” Jif syntax: TT  [TT  commAvail  ]  Erasure: Information: Voter’s credential shares Policy: “Voter requires, after all shares are received and full credential is constructed, that shares must be erased.” Jif syntax: Voter  [Voter credConst  T ]

37. Clarkson: Civitas37 Civitas LOC ComponentApprox. LOC Tabulation teller5,700 Registration teller1,300 Bulletin board, ballot box900 Voter client800 Other (incl. common code)4,700 Total Jif LOC13,400 Low-level crypto and I/O (Java and C) 8,000 Total LOC21,400 PolicyDistinct annotations Confidentiality20 Integrity26

38. Clarkson: Civitas38 Real-World Cost Tradeoff: cost of election vs. security, usability, … Current total costs are $1-$3 / voter [International Foundation for Election Systems] We don’t know the total cost for Civitas …Computational cost of advanced cryptography?

39. Clarkson: Civitas39 Tabulation Time vs. Anonymity K = # voters, # tab. tellers = 4, security strength ≥ 112 bits [NIST 2011–2030], 3GHz Xeons

40. Clarkson: Civitas40 Tabulation Time vs. # Voters K = 100 sequential parallel

41. Clarkson: Civitas41 CPU Cost for Tabulation CPU time is 39 sec / voter / authority If CPUs are bought, used (for 5 hours), then thrown away: $1500 / machine = $12 / voter If CPUs are rented: $1 / CPU / hr = 4¢ / voter …for this extra cost, we get increased security

42. Clarkson: Civitas42 Voters submit ordering of candidates: Examples: Condorcet, STV/IRV, Borda, … Ranked Voting Methods Vanilla4 Chocolate1 Strawberry3 Cookie dough2 Mint chocolate chip5

43. Clarkson: Civitas43 Ranked Voting Methods Low-order rankings create a covert channel  Coercion intrinsically possible VanillaX ChocolateX StrawberryX Cookie doughX Mint chocolate chip1 4! completions

44. Clarkson: Civitas44 Civitas Voting Methods Civitas implements coercion-resistant: Condorcet Approval Plurality Intuition: decompose ballot

45. Clarkson: Civitas45 Summary Civitas is a remote voting system Civitas contributes to: Protocols (theory of voting):  Distributed trust in registration for confidentiality  Distributed vote storage for availability  Introduced blocks (virtual precincts) for scalability  Articulated and analyzed trust assumptions  Efficient coercion-resistant Condorcet voting Systems (practice of voting):  Developed full, concrete protocols  Implemented system  Studied performance

46. Clarkson: Civitas46 Related Work Abstract voting schemes: [Baudron et al.; Benaloh; Benaloh and Tuinstra; Boyd; Chaum; Chaum, Ryan, and Schneider Chen and Burminster; Cohen and Fischer; Cramer, Gennaro, and Schoenmakers; Fujioka, Okamoto, and Ohta; Hirt and Sako; Iversen; Kiayias and Yung; Magkos et al.; Merrit; Neff; Niemi and Renvall; Sako and Killian; Ohkubo et al.; Ohta; Okamoto; Park et al.; Rivest] …  Implemented voting systems: Adder [Kiayias, Korman, Walluck] ElectMe [Shubina and Smith] EVOX [Herschberg, DuRette] Helios [Adida, Rivest] Prêt à Voter [Schneider, Heather, et al.; Ryan; Chaum] Punchscan [Stanton, Essex, Popoveniuc, et al.; Chaum] REVS [Joaquim, Zúquette, Ferreira; Lebre] Sensus [Cranor and Cytron] VoteHere [Neff] W-Voting [Kutyłowski, Zagórski, et al.] Civitas: Strongest coercion resistance, first to offer security proofs or information-flow analysis

47. Clarkson: Civitas47 Web Site http://www.cs.cornell.edu/projects/civitas  Technical report with concrete protocols  Source code of our prototype

48. Civitas Toward a Secure Voting System Michael Clarkson Cornell University Stevens Institute of Technology March 30, 2009