Civitas

1
Civitas
IACR Board Meeting / CRYPTO August 19, 2008
Coin (ca. 63 B.C.) commemorating introduction of
secret ballot in 137 B.C.
2
Civitas

• Features
• Designed for remote voting, coercion resistance,
  verifiability
• Supports plurality, approval, Condorcet methods
• Status
• Paper in Oakland 2008
• Publicly available 21,000 LOC (Jif, Java, and
  C)
• Prototype
• Suitable for IACR?

3
Civitas Security Requirements
4
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
• Interesting problem to solve!

IACR ?
5
Adversary

• Always
• May perform any polynomial time computation
• May corrupt all but one of each type of election
  authority
• Distributed trust
• Almost always
• May control network
• May coerce voters, demanding secrets or behavior,
  remotely or physically
• Security properties
• Confidentiality, integrity, availability

6
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.
IACR ?
7
Confidentiality

• Voter coercion
• Employer, spouse, etc.
• Coercer can demand any behavior (vote buying)
• Coercer can observe and interact with voter
  during remote voting
• Must prevent coercers from trusting their own
  observations

8
Confidentiality

• gt receipt-freeness gt anonymity
• Hierarchy Delaune, Kremer, and Ryan, CSFW
  2006

Coercion resistance
The adversary cannot learn how voters vote, even
if voters collude and interact with the adversary.
too weak for remote voting
IACR ?
9
Availability

• We assume that this holds
• To guarantee, would need to make system
  components highly available

Tally availability
The final tally of the election is produced.
IACR ?
10
Civitas Design and Implementation
11
JCJ Scheme

• Juels, Catalano, and Jakobsson, WPES 2005
• Formally defined coercion resistance and
  verifiability
• Constructed voting scheme
• Proved scheme satisfies coercion resistance and
  verifiability
• Backes, Hritcu, and Maffei, CSF 2008
• Verified simplification in ProVerif

12
Civitas Architecture
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
tabulation teller
ballot box
ballot box
voterclient
tabulation teller
13
Registration
registration teller
registration teller
registration teller
voterclient
Voter retrieves credential share from each
registration tellercombines to form credential
14
Voting
ballot box
ballot box
ballot box
voterclient
Voter submits copy of encrypted choice and
credential ( ZK proofs) to each ballot box
15
Resisting Coercion

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

16
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.
17
Tabulation
tabulation teller
bulletinboard
ballot box
tabulation teller
ballot box
ballot box
tabulation teller
Tellers retrieve votes from ballot boxes
18
Tabulation
tabulation teller
bulletinboard
tabulation teller
tabulation teller
Tabulation tellers anonymize votes with mix
networkeliminate unauthorized
credentials decrypt remaining choices post ZK
proofs
19
Civitas Architecture
registration teller
registration teller
registration teller
tabulation teller
bulletinboard
ballot box
tabulation teller
ballot box
ballot box
voterclient
tabulation teller
20
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

21
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

22
CivitasSecurity Evaluation
23
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

24
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

Verifiability andCoercion resistance
Coercion resistance
25
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

VER CR
CR
26
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

VER CR
CR
27
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

VER CR
CR
28
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

VER CR
CR
29
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

VER CR
CR
30
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

VER CR
CR
31
Civitas Trust Assumptions

1. DDH, RSA, random oracle model.
2. The adversary cannot masquerade as a voter during
   registration.
3. Voters trust their voting client.
4. At least one of each type of authority is
   honest.
5. The channels from the voter to the ballot boxes
   are anonymous.
6. Each voter has an untappable channel to a trusted
   registration teller.

VER CR
CR
32
CivitasCost Evaluation
33
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.
• Cost of cryptography?

34
CPU Cost for Tabulation

• For reasonable security parameters,
• 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
• Increased costIncreased security

IACR ?
35
Conclusion
36
Summary

• Civitas provides security
• Remote voting
• Verifiability
• Coercion resistance (strongest?)
• Civitas provides assurance
• Security proofs
• Explicit trust assumptions
• Information-flow analysis of implementation
  (first?)

IACR ?
37
Technical Issues

• Web interfaces
• Testing
• BFT bulletin board
• Threshold cryptography
• Anonymous channel integration

IACR ?
38
Research Issues

• Distribute trust in voter client
• Eliminate in-person registration
• Credential management
• Application-level DoS

39
Web Site

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

40
http//www.cs.cornell.edu/projects/civitas
41
Extra Slides
42
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

43
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

44
Selling Votes

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

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

47
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

48
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
• Reusing real-world mechanism, can bootstrap into
  a system offering stronger security

49
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
• Discharge? Distribute trust in client.
• Benaloh, Chaum, Joaquim and Ribeiro, Kutylowski
  et al., Zúquete et al.,

50
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

51
Tabulation Time vs. Anonymity
voters K, tab. tellers 4, security
strength 112 bits NIST 20112030
52
Tabulation Time vs. Voters
sequential
K 100
53
Ranked Voting Methods

• Voters submit ranking of candidates
• e.g., Condorcet, Borda, STV
• Help avoid spoiler effects
• Defend against strategic voting
• Italian attack
• Civitas implements coercion-resistant Condorcet,
  approval and plurality voting methods
• Could do any summable method