Civitas
Michael Clarkson
Stephen Chong
Andrew Myers
Cornell
Harvard
Cornell
IACR Board Meeting / CRYPTO
August 19, 2008
Coin (ca. 63 B.C.) commemorating introduction of secret ballot in 137 B.C.
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?
Clarkson: Civitas
2
Civitas
Security Requirements
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 
Clarkson: Civitas
4
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
Clarkson: Civitas
5
Integrity
Verifiability:
The final tally is correct and verifiable.
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]
IACR 
Clarkson: Civitas
6
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
Clarkson: Civitas
7
Confidentiality
Coercion resistance:
The adversary cannot learn how voters vote, even if
voters collude and interact with the adversary.
> receipt-freeness
> anonymity
too weak for remote voting
Hierarchy: [Delaune, Kremer, and Ryan, CSFW 2006]
IACR ?
Clarkson: Civitas
8
Availability
Tally availability:
The final tally of the election is produced.
• We assume that this holds
• To guarantee, would need to make system
components highly available
IACR ?
Clarkson: Civitas
9
Civitas
Design and Implementation
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
Clarkson: Civitas
11
Civitas Architecture
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
Clarkson: Civitas
tabulation teller
bulletin
board
tabulation teller
12
Registration
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
tabulation teller
bulletin
board
tabulation teller
Voter retrieves credential share from each registration teller;
combines to form credential
Clarkson: Civitas
13
Voting
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
tabulation teller
bulletin
board
tabulation teller
Voter submits copy of encrypted choice and credential
(+ ZK proofs) to each ballot box
Clarkson: Civitas
14
Resisting Coercion
Voters invent fake credentials
– To adversary, fake  real
– Votes with fake credentials removed during tabulation
Clarkson: Civitas
15
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.
Clarkson: Civitas
16
Tabulation
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
tabulation teller
bulletin
board
tabulation teller
Tellers retrieve votes from ballot boxes
Clarkson: Civitas
17
Tabulation
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
tabulation teller
bulletin
board
tabulation teller
Tabulation tellers anonymize votes with mix network;
eliminate unauthorized credentials;
decrypt remaining choices;
post ZK proofs
Clarkson: Civitas
18
Civitas Architecture
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
Verifiability:
Tellers post zero-knowledge
proofs during tabulation
Clarkson: Civitas
tabulation teller
bulletin
board
tabulation teller
Coercion resistance:
Voters can undetectably fake
credentials
19
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]
Clarkson: Civitas
20
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
Clarkson: Civitas
21
Civitas
Security Evaluation
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.
Clarkson: Civitas
23
Civitas Trust Assumptions
1.
DDH, RSA, random oracle model.
2.
The adversary cannot masquerade as a voter during registration.
Verifiability and
Coercion resistance
Voters trust their voting client.
3.
4. At least one of each type of authority is honest.
Coercion resistance
5.
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
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.
VER + CR
CR
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
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.
VER + CR
CR
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
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.
VER + CR
CR
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
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.
VER + CR
CR
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
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.
VER + CR
CR
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
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.
VER + CR
CR
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
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.
VER + CR
CR
The channels from the voter to the ballot boxes are anonymous.
6. Each voter has an untappable channel to a trusted registration
teller.
Clarkson: Civitas
31
Civitas
Cost Evaluation
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 don’t know the total cost for Civitas.
Cost of cryptography?
Clarkson: Civitas
33
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 cost…Increased security
IACR ?
Clarkson: Civitas
34
Conclusion
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 
Clarkson: Civitas
36
Technical Issues
• Web interfaces
• Testing
• BFT bulletin board
• Threshold cryptography
• Anonymous channel integration
IACR 
Clarkson: Civitas
37
Research Issues
• Distribute trust in voter client
• Eliminate in-person registration
• Credential management
• Application-level DoS
Clarkson: Civitas
38
Web Site
http://www.cs.cornell.edu/projects/civitas
• Technical report with concrete protocols
• Source code of our prototype
Clarkson: Civitas
39
http://www.cs.cornell.edu/projects/civitas
Extra Slides
Clarkson: Civitas
41
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 doesn’t:
– Guarantee that a vote will be counted
– Guarantee that a vote will be counted correctly
Clarkson: Civitas
42
Cryptography
“The public won’t trust cryptography.”
– It already does…
– Because experts already do
“I don’t trust cryptography.”
– You don’t trust the proofs, or
– You reject the hardness assumptions
Clarkson: Civitas
43
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
Clarkson: Civitas
44
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)
Total Jif LOC
Low-level crypto and I/O
(Java and C)
Total LOC
Clarkson: Civitas
4,700
Policy
Distinct
annotations
Confidentiality
20
Integrity
26
13,400
8,000
21,400
45
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
46
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
47
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:
Pro:

System not fully remote
Credential can be used remotely for many elections
Reusing real-world mechanism, can bootstrap into a system offering stronger
security
Clarkson: Civitas
48
Voting Client Trust Assumption
Civitas voting client is not a DRE:
– Voters are not required to trust a single (closedsource) 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, Kutyłowski et al., Zúquete et al., …]
Clarkson: Civitas
49
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
Clarkson: Civitas
50
Tabulation Time vs. Anonymity
# voters = K, # tab. tellers = 4,
security strength ≥ 112 bits [NIST 2011–2030]
Clarkson: Civitas
51
Tabulation Time vs. # Voters
sequential
parallel
K = 100
Clarkson: Civitas
52
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
Clarkson: Civitas
53