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
Strong,provablesecurity
Practicalperformance
Remotevoting
3
Terminology

• Voting system (software) implementation
• Voting scheme cryptographic construction
• Voting method algorithm for choosing between
  candidates

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)

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

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

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

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

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

12
Civitas Architecture
registrar
tabulation teller
bulletinboard
tabulation teller
voterclient
tabulation teller
JCJ scheme
13
Civitas Architecture
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
tabulation teller
voterclient
tabulation teller
Civitas scheme
14
Civitas Architecture
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
tabulation teller
ballot box
ballot box
voterclient
tabulation teller
Civitas scheme
What makes this secure? Why do we believe it is?
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

16
Cryptography
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
tabulation teller
ballot box
ballot box
voterclient
tabulation teller
Assumption 1. DDH, RSA, random oracle model.
17
Registration
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
obtain credential
tabulation teller
ballot box
ballot box
voterclient
tabulation teller
Assumption 2. The adversary cannot masquerade
as voter during registration.
Implement with strong authentication,
non-transferable secrets.
18
Registration
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
obtain credential
tabulation teller
ballot box
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
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
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.
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.
22
Tabulation
registration teller
anonymize and authenticate votes
registration teller
registration teller
tabulation teller
retrieve votes
audit
bulletinboard
ballot box
tabulation teller
ballot box
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.
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

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

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

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 lt 2
• Parameters
• V number of voters
• A number of authorities of each type
• K minimum number of voters in a block

28
Tabulation Time vs. Voters
sequential
35 sec / voter / authority 1/CPU/hr 4/voter
(K 100, A 4)
29
Tabulation Time vs. Anonymity
(V K, A 4)
30
Tabulation Time vs. Authorities
(K V 100)
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 FEE05
• Civitas also implements approval and FPTP ballots

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 Kutylowski, Zagórski, et al.

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

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

35
Resources

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

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
38
Registration and Voting Times

• For A4, 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 voters credential
• 25ms for voter to submit vote to ballot box
• Registration teller throughput gt 15,000 voters /
  hr

39
Tab. Time vs. Chaff
(K V 100, A 4)
40
CPU Util. vs. Voters
(K 100, A 4)
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

42
Attacks Registration

• Strong authentication to prevent adversary from
  masquerading as voter
• Registration by mail or in person

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

44
Attacks Availability

• BFT, threshold cryptography
• Rate-limiting and puzzles to mitigate
  application-level DOS
• But PETs still a fundamental problem

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