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
• 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
2
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
3
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
4
Civitas Security Requirements
Clarkson: Civitas
5
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
6
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
7
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]
Clarkson: Civitas
8
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
9
Confidentiality
Coercion resistance:
The adversary cannot learn how voters vote,
even if voters collude and interact with the
adversary.
Stronger than receipt-freeness, which is
stronger than anonymity
– [Delaune, Kremer, and Ryan]
– Which are too weak for remote voting
Clarkson: Civitas
10
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
– 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
Clarkson: Civitas
11
Civitas Voting Scheme
Clarkson: Civitas
12
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
13
JCJ Protocol Architecture
Issue credentials
registrar
tabulation teller
bulletin
board
voter
client
Verifiability:
Tellers post zero-knowledge
proofs during tabulation
Clarkson: Civitas
tabulation teller
Tabulate,
using mix
network
tabulation teller
Coercion resistance:
Voters can undetectably
fake credentials
14
Problem #1
registrar
tabulation teller
bulletin
board
voter
client
Clarkson: Civitas
tabulation teller
tabulation teller
15
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
16
Distributed Registrar
registration
registration
registration
teller
teller
teller
tabulation teller
bulletin
board
voter
client
Clarkson: Civitas
tabulation teller
tabulation teller
17
Civitas Registration Protocol
registration
teller
registration
teller
registration
teller
credential share
voter
client
credential
Clarkson: Civitas
also: designated-verifier ZK
proof to convince voter
without allowing transfer
of credential
18
Problem #2
registration
registration
registration
teller
teller
teller
tabulation teller
bulletin
board
voter
client
Clarkson: Civitas
tabulation teller
tabulation teller
19
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
20
Distributed Vote Storage
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
Clarkson: Civitas
tabulation teller
bulletin
board
tabulation teller
21
Civitas Vote Storage Protocol
tabulation teller
ballot box
voter
client
ballot box
ballot box
tabulation teller
Transmit
all votes
using simple
commitment
protocol
tabulation teller
Win: Vote availability, scales easily
Clarkson: Civitas
22
Problem #3
registration
registration
teller
registration
teller
teller
tabulation teller
ballot box
ballot box
ballot box
voter
client
Clarkson: Civitas
tabulation teller
bulletin
board
tabulation teller
23
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
24
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
25
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
26
Civitas Implementation
Clarkson: Civitas
27
Protocols
• JCJ: Un- or partially-specified
– Implementation requires concrete protocols
• Civitas: Full protocol details, and code
– Uses many protocols from the literature:
•
•
•
•
•
•
•
•
•
Clarkson: Civitas
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]
28
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
29
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
30
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
31
Civitas LOC
Component
Approx.
LOC
Tabulation teller
5,700
Registration teller
1,300
Bulletin board, ballot box
Voter client
Other (incl. common code)
Total Jif LOC
Low-level crypto and I/O
(Java and C)
Total LOC
Clarkson: Civitas
Policy
900
800
4,700
Distinct
annotations
Confidentiality
20
Integrity
26
13,400
8,000
21,400
32
Evaluation: Civitas Security
Clarkson: Civitas
33
Civitas Trust Assumptions
1.
DDH, RSA, random oracle model.
2.
The adversary cannot masquerade as a voter during
registration.
3.
At least one of each type of authority is honest.
4.
Each voter has an untappable channel to a trusted
registration teller.
5.
Voters trust their voting client.
6.
The channels from the voter to the ballot boxes are
anonymous.
Clarkson: Civitas
34
Civitas Trust Assumptions
1.
DDH, RSA, random oracle model.
2.
The adversary cannot masquerade as a voter during
registration.
3.
At least one of each type of authority is honest.
4.
Each voter has an untappable channel to a trusted
registration teller.
5.
Voters trust their voting client.
6.
The channels from the voter to the ballot boxes are
anonymous.
Clarkson: Civitas
35
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
36
Civitas Trust Assumptions
1.
DDH, RSA, random oracle model.
2.
The adversary cannot masquerade as a voter during
registration.
3.
At least one of each type of authority is honest.
4.
Each voter has an untappable channel to a trusted
registration teller.
5.
Voters trust their voting client.
6.
The channels from the voter to the ballot boxes are
anonymous.
Clarkson: Civitas
37
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
• Possibility to discharge:
– Distribute trust in client
[Benaloh, Chaum, Joaquim and Ribeiro, Kutyłowski et al.,
Zúquete et al., …]
Clarkson: Civitas
38
Evaluation:
Civitas Cost and Performance
Clarkson: Civitas
39
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
– But with our implementation, we can
investigate one piece:
• Computational cost of employing cryptography
Clarkson: Civitas
40
Tabulation Time vs. Anonymity
# voters = K, # tab. tellers = 4,
security strength ≥ 112 bits [NIST 2011–2030]
Clarkson: Civitas
41
Tabulation Time vs. # Voters
sequential
parallel
K = 100
Clarkson: Civitas
42
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
43
Ranked Voting
Clarkson: Civitas
44
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
45
Conclusion
Clarkson: Civitas
46
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
47
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
48
Web Site
http://www.cs.cornell.edu/projects/civitas
• Technical report with concrete protocols
• Source code of our prototype
Clarkson: Civitas
49
Civitas
Toward a Secure Voting System
http://www.cs.cornell.edu/projects/civitas
Michael Clarkson, Stephen Chong, Andrew Myers
Cornell University
Coin Crawford 413, ca. 63 B.C., commemorates secret ballot introduced 137 B.C.
Extra Slides
Clarkson: Civitas
51
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]
Clarkson: Civitas
52
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
53
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
54
Resisting Coercion
• Key idea:
Voters invent fake credentials
• To adversary, fake  real
• Votes with fake credentials are removed
during tabulation
Clarkson: Civitas
55
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
56
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
Clarkson: Civitas
57