Civitas Toward a Secure Voting System

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?

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

4
Caveat

• This work is about advancing the science
• Not about selling a particular system
• Civitas isnt suitable for running a national
  election (yet)

5
Civitas Security Requirements
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, IEEEall
  on Internet)

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

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

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.
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.
12
Civitas Voting Scheme
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 wont discuss why it works in this talk
• Verified in ProVerif Backes, Hritcu, and Maffei,
  CSF 2008

14
JCJ Protocol Architecture
Issue credentials
registrar
tabulation teller
Tabulate, using mix network
bulletinboard
tabulation teller
voterclient
tabulation teller
15
Problem 1
registrar
tabulation teller
bulletinboard
tabulation teller
voterclient
tabulation teller
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

17
Distributed Registrar
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
tabulation teller
voterclient
tabulation teller
18
Civitas Registration Protocol
registration teller
registration teller
registration teller
voterclient
also designated-verifier ZKproof to convince
voter without allowing transfer of credential
19
Problem 2
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
tabulation teller
voterclient
tabulation teller
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.
21
Distributed Vote Storage
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
tabulation teller
ballot box
ballot box
voterclient
tabulation teller
22
Civitas Vote Storage Protocol
voterclient
Transmit all votesusing simplecommitmentprotoco
l
Win Vote availability, scales easily
23
Problem 3
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
tabulation teller
ballot box
ballot box
voterclient
tabulation teller
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

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

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

27
Civitas Implementation
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

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

30
Civitas Policy Examples

• Confidentiality
• Information Voters credential share
• Policy RT permits only this voter to learn this
  information
• Jif syntax RT ? Voter
• Confidentiality
• Information Tellers 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

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

32
Civitas LOC
Component Approx. LOC
Tabulation teller 5,700
Registration teller 1,300
Bulletin board, ballot box 900
Voter client 800
Other (incl. common code) 4,700
Total Jif LOC 13,400
Low-level crypto and I/O (Java and C) 8,000
Total LOC 21,400
Policy Distinct annota-tions
Confidentiality 20
Integrity 26
33
Evaluation Civitas Security
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.

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.

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

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.

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, Kutylowski
  et al., Zúquete et al.,

39
EvaluationCivitas Cost and Performance
40
Real-World Cost

• Society makes a tradeoff on
• Cost of election, vs.
• Security, usability,
• Current total costs are 1-3 / voter
  International Foundation for Election Systems
• We dont know the total cost for Civitas
• But with our implementation, we can investigate
  one piece
• Computational cost of employing cryptography

41
Tabulation Time vs. Anonymity
voters K, tab. tellers 4, security
strength 112 bits NIST 20112030
42
Tabulation Time vs. Voters
sequential
K 100
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

44
Ranked Voting
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

46
Conclusion
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

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 Kutylowski, Zagórski, et al.
• Civitas Strongest coercion resistance, first to
  offer security proofs plus information-flow
  analysis

49
Web Site

• http//www.cs.cornell.edu/projects/civitas
• Technical report with concrete protocols
• Source code of our prototype

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.
51
Extra Slides
52
Unresolved Issues

• Distribute trust in voter client
• Eliminate in-person registration
• Still need untappable channel
• Study credential management
• UI for faking
• Implement high availability
• App-level DOS is a problem.
• Improve performance/anonymity trade-off
• Replace plaintext equivalence tests with group
  signatures? Traore and Araujo 2007

53
Paper

• What paper does
• Convince voter that his vote was captured
  correctly
• What paper does next
• Gets dropped in a ballot box
• Immediately becomes insecure
• Chain-of-custody, stuffing, loss, recount
  attacks
• Hacking paper elections has a long and
  (in)glorious tradition Steal this Vote, Andrew
  Gumbel, 2005
• 20 of paper trails are missing or illegible
  Michael Shamos, 2008
• What paper doesnt
• Guarantee that a vote will be counted
• Guarantee that a vote will be counted correctly

54
Cryptography

• The public wont trust cryptography.
• It already does
• Because experts already do
• I dont trust cryptography.
• You dont trust the proofs, or
• You reject the hardness assumptions

55
Resisting Coercion

• Key idea
• Voters invent fake credentials
• To adversary, fake ? real
• Votes with fake credentials are removed during
  tabulation

56
Resisting Coercion
If the adversary demands that the voter Then the voter
Submits a particular vote Does so with a fake credential.
Sells or surrenders a credential Supplies a fake credential.
Abstains Supplies a fake credential to the adversary and votes with a real one.
57
Selling Votes

• Requires selling credential
• Which requires
• Adversary tapped the untappable channel, or
• Adversary authenticated in place of voter
• Which requires
• Voter transferred ability to authenticate to
  adversary something voter
• Has too easy
• Knows need incentive not to transfer
• Is hardest to transfer