1 / 57

Civitas Toward a Secure Voting System

Civitas Toward a Secure Voting System. Michael Clarkson, Stephen Chong, Andrew Myers Cornell University IEEE Symposium on Security and Privacy May 21, 2008. Coin Crawford 413, ca. 63 B.C., commemorates secret ballot introduced 137 B.C. State of Secure Electronic Voting.

nikki
Download Presentation

Civitas Toward a Secure Voting System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CivitasToward a Secure Voting System Michael Clarkson, Stephen Chong, Andrew MyersCornell University IEEE Symposium on Security and Privacy May 21, 2008 Coin Crawford 413, ca. 63 B.C., commemorates secret ballot introduced 137 B.C.

  2. State of Secure Electronic Voting • Major commercial voting systems are insecure • California top-to-bottom reviews [Wagner, Wallach, Blaze, et al.] • Much pessimism about secure voting • SERVE report [Jefferson et al.] • How secure a voting system can we build? Clarkson: Civitas

  3. Civitas • Civitas: Electronic voting system we built • Publicly available • 21,000 LOC (Jif, Java, and C) • Started with abstract voting protocol… • Extended design to improve security and performance • Implemented in security-typed language (Jif) • Evaluated security and performance Clarkson: Civitas

  4. Caveat • This work is about advancing the science… • Not about selling a particular system • Civitas isn’t suitable for running a national election (yet) Clarkson: Civitas

  5. Civitas Security Requirements Clarkson: Civitas

  6. Security Model • No trusted supervision of polling places • Including voters, procedures, hardware, software • Voting could take place anywhere • Thus, remote voting • Generalization of “Internet voting” and “postal voting” • Interesting problem to solve: • More general than supervised voting • Trusted supervision is the source of many vulnerabilities • Trend toward remote interactions • Public elections (absentee ballots, Oregon, Washington, Estonia) • Organizational elections (Debian, ACM, IEEE—all on Internet) Clarkson: Civitas

  7. Security Model • Adversary • May corrupt all but one of each type of election authority • Agents who conduct the election • May coerce voters, demanding secrets or behavior, remotely or physically • But voter isn’t under constant surveillance • May control network • With one exception during registration • May perform any polynomial time computation • Security properties • Strong, in tension • Confidentiality, integrity, availability… Clarkson: Civitas

  8. Integrity Verifiability: Including: • Voter verifiability: Voters can check that their own vote is included • Universal verifiability: Anyone can check that only authorized votes are counted, no votes are changed during tallying [Sako and Killian 1995] The final tally is correct and verifiable. Clarkson: Civitas

  9. Confidentiality • Voter coercion • Employer, spouse, etc. • Coercer can demand any behavior • Particular vote, random vote, abstain • Generalizes vote buying • Coercer can observe and interact with voter during remote voting • Must prevent coercers from trusting their own observations Clarkson: Civitas

  10. Confidentiality Stronger than receipt-freeness, which is stronger than anonymity • [Delaune, Kremer, and Ryan] • Which are too weak for remote voting Coercion resistance: The adversary cannot learn how voters vote, even if voters collude and interact with the adversary. Clarkson: Civitas

  11. Availability • We assume that this holds • To guarantee, would need to make system components highly available • Use reliable systems techniques • Byzantine fault tolerance, threshold cryptography • Civitas designed, but not implemented, with this in mind • We do not assume that votes remain available Tally availability: The final tally of the election is produced. Clarkson: Civitas

  12. Civitas Voting Scheme Clarkson: Civitas

  13. JCJ Scheme • Civitas is based on JCJ scheme • [Juels, Catalano, and Jakobsson, WPES 2005] • JCJ: • Formally defined coercion resistance and verifiability • Constructed voting scheme • Not implemented • Proved scheme satisfies coercion resistance and verifiability • I won’t discuss why it works in this talk • Verified in ProVerif [Backes, Hritcu, and Maffei, CSF 2008] Clarkson: Civitas

  14. JCJ Protocol Architecture Verifiability:Tellers post zero-knowledge proofs during tabulation Coercion resistance:Voters can undetectably fake credentials Issue credentials registrar tabulation teller Tabulate, using mix network bulletinboard tabulation teller voterclient tabulation teller Clarkson: Civitas

  15. Problem #1 registrar tabulation teller bulletinboard tabulation teller voterclient tabulation teller Clarkson: Civitas

  16. Problem #1: Trusted Registrar • JCJ: Trusts single agent to issue credentials to voters • Could violate coercion resistance • Could vote on behalf of voters • Civitas: Distributes trust over set of registration tellers • We extended JCJ security proof to prove Civitas is still coercion resistant Clarkson: Civitas

  17. Distributed Registrar registration teller registration teller registration teller tabulation teller bulletinboard tabulation teller voterclient tabulation teller Clarkson: Civitas

  18. Civitas Registration Protocol credential share credential registration teller registration teller registration teller voterclient also: designated-verifier ZKproof to convince voter without allowing transfer of credential Clarkson: Civitas

  19. Problem #2 registration teller registration teller registration teller tabulation teller bulletinboard tabulation teller voterclient tabulation teller Clarkson: Civitas

  20. Problem #2: Vote Storage • JCJ: Trusts single bulletin board to store all the votes • Could lose votes • Unavailable votes not universally verifiable • So implement with BFT…? • Could scale poorly • Civitas: Distributes vote storage over set of ballot boxes Vote availability: Votes are available for tabulation. Clarkson: Civitas

  21. Distributed Vote Storage registration teller registration teller registration teller tabulation teller ballot box bulletinboard ballot box tabulation teller ballot box voterclient tabulation teller Clarkson: Civitas

  22. Civitas Vote Storage Protocol tabulation teller ballot box tabulation teller ballot box ballot box tabulation teller voterclient Transmit all votesusing simplecommitmentprotocol Win: Vote availability, scales easily Clarkson: Civitas

  23. Problem #3 registration teller registration teller registration teller tabulation teller ballot box bulletinboard ballot box tabulation teller ballot box voterclient tabulation teller Clarkson: Civitas

  24. Problem #3: Tabulation Scalability • JCJ: Tabulation protocol is quadratic in number of voters • Civitas: Divide voters into blocks • Block is a “virtual precinct” • Each voter assigned to one block • Each block tallied independently of other blocks, even in parallel Clarkson: Civitas

  25. Blocks 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 Clarkson: Civitas

  26. Blocks • Coercion resistance • Voters no longer anonymous within whole population • But still anonymous within block • Also true in real precincts • Assignment to blocks • Based on physical location • Leads to risk of reprisal, as in real precincts • Based on random assignment • Mitigates risk • Made possible by remote voting Clarkson: Civitas

  27. Civitas Implementation Clarkson: Civitas

  28. Protocols • JCJ: Un- or partially-specified • Implementation requires concrete protocols • Civitas: Full protocol details, and code • Uses many protocols from 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] Clarkson: Civitas

  29. Secure Implementation • Civitas implemented in Jif Java + Information Flow[Myers 1999, Chong and Myers 2005, 2008] • Security-typed language • Types contain information-flow policies • Policies express confidentiality and integrity requirements on information • Jif compiler and runtime enforce policies • If policies in code express correct requirements… • (And Jif compiler is correct…) • Then code is secure w.r.t. requirements Clarkson: Civitas

  30. 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 Clarkson: Civitas

  31. 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 ] Clarkson: Civitas

  32. Civitas LOC Clarkson: Civitas

  33. Evaluation: Civitas Security Clarkson: Civitas

  34. Civitas Trust Assumptions • DDH, RSA, random oracle model. • The adversary cannot masquerade as a voter during registration. • At least one of each type of authority is honest. • Each voter has an untappable channel to a trusted registration teller. • Voters trust their voting client. • The channels from the voter to the ballot boxes are anonymous. Clarkson: Civitas

  35. Civitas Trust Assumptions • DDH, RSA, random oracle model. • The adversary cannot masquerade as a voter during registration. • At least one of each type of authority is honest. • Each voter has an untappable channel to a trusted registration teller. • Voters trust their voting client. • The channels from the voter to the ballot boxes are anonymous. Clarkson: Civitas

  36. Registration Trust Assumptions • One way to discharge is with in-person registration • Not an absolute requirement • Though for strong authentication, physical presence (“something you are”) is reasonable • Need not register in-person with all tellers • Works like real-world voting today: • Registration teller trusted to correctly authenticate voter • Issue of credential must happen in trusted “registration booth” • But doesn’t need to happen on special day • Con: System not fully remote • Pro: Credential can be used remotely for many elections • Insight: Reusing real-world mechanism, can bootstrap into a system offering stronger security Clarkson: Civitas

  37. Civitas Trust Assumptions • DDH, RSA, random oracle model. • The adversary cannot masquerade as a voter during registration. • At least one of each type of authority is honest. • Each voter has an untappable channel to a trusted registration teller. • Voters trust their voting client. • The channels from the voter to the ballot boxes are anonymous. Clarkson: Civitas

  38. Voting Client Trust Assumption • Civitas voting client is not a DRE • Voters are not required to trust a single (closed-source) implementation • Civitas allows open-source (re)implementations of the client • Voters can obtain or travel to implementation provided by organization they trust • Possibility to discharge: • Distribute trust in client [Benaloh, Chaum, Joaquim and Ribeiro, Kutyłowski et al., Zúquete et al., …] Clarkson: Civitas

  39. Evaluation:Civitas Cost and Performance Clarkson: Civitas

  40. Real-World Cost • Society makes a tradeoff on • Cost of election, vs. • Security, usability, … • Current totalcosts are $1-$3 / voter [International Foundation for Election Systems] • We don’t know the total cost for Civitas • But with our implementation, we can investigate one piece: • Computational cost of employing cryptography Clarkson: Civitas

  41. Tabulation Time vs. Anonymity # voters = K, # tab. tellers = 4, security strength ≥ 112 bits [NIST 2011–2030] Clarkson: Civitas

  42. Tabulation Time vs. # Voters parallel sequential K = 100 Clarkson: Civitas

  43. 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 Clarkson: Civitas

  44. Ranked Voting Clarkson: Civitas

  45. Ranked Voting Methods • Voters submit ranking of candidates • E.g. Condorcet, Borda, STV • Help avoid spoiler effects • Defend against strategic voting • Tricky because rankings can be used to signal identity (“Italian attack”) • Civitas implements coercion-resistant Condorcet, approval and plurality voting methods • Could do any summable method • New construction [in TR] for efficient Condorcet tabulation • Based on homomorphic encryption Clarkson: Civitas

  46. Conclusion Clarkson: Civitas

  47. Summary • Civitas is an implemented 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 protocols • Implemented system • Studied performance Clarkson: Civitas

  48. Related Work • Abstract voting schemes: [Adida and Rivest; 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] • 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 plus information-flow analysis Clarkson: Civitas

  49. Web Site http://www.cs.cornell.edu/projects/civitas • Technical report with concrete protocols • Source code of our prototype Clarkson: Civitas

  50. CivitasToward a Secure Voting System http://www.cs.cornell.edu/projects/civitas Michael Clarkson, Stephen Chong, Andrew MyersCornell University Coin Crawford 413, ca. 63 B.C., commemorates secret ballot introduced 137 B.C.

More Related