Civitas Michael Clarkson Cornell Stephen Chong Harvard

Civitas Michael Clarkson Cornell Stephen Chong Harvard
Andrew Myers Cornell IACR Board Meeting / CRYPTO August 19, 2008 Coin (ca. 63 B.C.) commemorating introduction of secret ballot in 137 B.C.

Civitas Features: Status: …Suitable for IACR?
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? Suitable for IACR? Yes or no, offers interesting features that should be kept in mind when evaluating other systems. Clarkson: Civitas

Civitas Security Requirements

Security Model No trusted supervision of polling places Remote voting
Including voters, procedures, hardware, software Voting could take place anywhere Remote voting Generalization of “Internet voting” and “postal voting” Interesting problem to solve! To begin, we wanted to build a system that did not rely on trusted supervision of polling places. This means that neither the voters, the procedures that are used, the hardware, or the software are supervised. Voting could therefore take place from anywhere. The term for this is “remote voting”, of which Internet voting is one instance. Remote voting is a very interesting problem to tackle. It is a more general problem than supervised voting. That is, a secure remote voting system is also secure in a context with trusted supervision. And eliminating trusted supervision is a worthwhile goal, because it is the source of many vulnerabilities. Remote voting is also interesting because our society is trending towards one in which interactions can be carried out from any place at any time. This includes voting. Remote voting is becoming more common in both public elections and organizational elections. For example, the states of Oregon and Washington now vote (almost) entirely remotely. IACR  Clarkson: Civitas

Adversary Always: Almost always: Security properties:
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 In remote voting, we must be concerned about an adversary with strong capabilities. In Civitas, we assume that the adversary may corrupt all but one of each type of election authority. Election authorities are agents who conduct the election. They might be humans, organizations, or software provided by these. There are different types because the authorities have different responsibilities: registration, vote storage, and tabulation. In remote voting, an adversary may also attempt to coerce voters, demanding secrets or arbitrary behavior from them, even in the physical presence of the voter. We need to protect voters against this. But we also assume that there will be some time when the voter is not in the control of the adversary. We make two other standard assumptions: The adversary can control the network, and perform any polynomial time computation. We do make an exception regarding the network during voter registration, which I’ll return to a little later. Against this adversary, we want Civitas to satisfy certain security properties. One reason that it’s hard to build secure voting systems is that these properties that are sometimes in tension with one another. I’ll frame my discussion of these properties in terms of three aspects of security that people often discuss, confidentiality, integrity, and availability. Clarkson: Civitas

The final tally is correct and verifiable.
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. Let me start with integrity. Civitas satisfies an integrity property which we call verifiability. Informally, this property says that the final tally of the election is correct and verifiable. This includes that voters can check that their own votes are included in the final tally, which is known as voter verifiability. And that anyone can check that the final tally was computed correctly, including that no votes are dropped, added, or change during tallying. This is known as universal verifiability. These integrity properties are sorely lacking in current real-world systems. It wouldn’t be as difficult to build secure voting systems if all we had to worry about was integrity. But we also need to worry about confidentiality. IACR  Clarkson: Civitas

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 Perhaps the biggest challenge with confidentiality in remote voting is voter coercion. You can imagine that the coercer might be someone such as the voter’s employer or spouse. Such a coercer might be able to demand any behavior of the voter. For example, the coercer might demand that the voter submit a particular vote, submit a random vote, or even abstain from the election. Note that this generalizes vote buying, which is just one behavior the coercer might demand. Coercers might be able to observe and interact with the voter, even being in the physical presence of the voter---perhaps standing over the voter’s shoulder as the voter votes. This leads to a requirement for remote voting systems: the voting system must prevent a coercer from trusting his own observations. Clarkson: Civitas

Hierarchy: [Delaune, Kremer, and Ryan, CSFW 2006]
Confidentiality > receipt-freeness > 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 This leads to a confidentiality property known as coercion resistance, which says that the adversary cannot learn how voters vote, even if voters collude and interact with the adversary. And it is stronger than other properties you might have seen before, such as anonymity (which allows the voter to collude and interact), or receipt freeness (which allows the voter to collude but not interact). This relationship was established in work by DKR. IACR ? Clarkson: Civitas

The final tally of the election is produced.
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. Finally, let’s talk about availability. Ultimately, what we want is that the final tally of the election is produced, and various components may need to remain available to make this happen. In Civitas, we assume that this property will hold. This is different than confidentiality or integrity, which we’ll use cryptographic mechanisms to guarantee. If we wanted to guarantee tally availability---which would be important for real-world elections---we would need to at least make system components highly available. This might be done with standard reliable systems techniques, and we kept this in mind as we designed Civitas. (This included minimizing communication, as well as the number of hosts in the system that have to be available at any given time.) But we didn’t actually implement high availability. IACR ? Clarkson: Civitas

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 Civitas is based on a voting scheme invented by Juels, Catalano, and Jakobsson. I’ll refer to this as the JCJ scheme. JCJ gave formal, mathematical definitions of the coercion resistance and verifiability properties, constructed a voting scheme, and proved that the scheme satisfies the properties. Clarkson: Civitas

Civitas Architecture registration teller registration teller
tabulation teller ballot box bulletin board ballot box tabulation teller ballot box voter client tabulation teller Clarkson: Civitas

Registration registration teller registration teller registration teller bulletin board tabulation teller ballot box voter client Voter retrieves credential share from each registration teller; combines to form credential Clarkson: Civitas

Voting bulletin board tabulation teller registration teller ballot box ballot box ballot box voter client Voter submits copy of encrypted choice and credential (+ ZK proofs) to each ballot box Clarkson: Civitas

Resisting Coercion Voters invent fake credentials
To adversary, fake  real Votes with fake credentials removed during tabulation Clarkson: Civitas

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

Tellers retrieve votes from ballot boxes
Tabulation voter client registration teller tabulation teller ballot box bulletin board ballot box tabulation teller ballot box tabulation teller Tellers retrieve votes from ballot boxes Clarkson: Civitas

decrypt remaining choices;
Tabulation voter client registration teller ballot box tabulation teller bulletin board tabulation teller tabulation teller Tabulation tellers anonymize votes with mix network; eliminate unauthorized credentials; decrypt remaining choices; post ZK proofs Clarkson: Civitas

Civitas Architecture registration teller registration teller registration teller tabulation teller ballot box bulletin board ballot box tabulation teller ballot box voter client tabulation teller Verifiability: Tellers post zero-knowledge proofs during tabulation Coercion resistance: Voters can undetectably fake credentials Clarkson: Civitas

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] Implementation requires concrete protocols. So building Civitas required filling in the missing details of the abstract protocol design, including implementing a number of other protocols from the literature. Clarkson: Civitas

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 Protocols may be secure in their design, but their implementation can be another story. We wanted assurance that our implementation of Civitas was itself secure. We gained this by implementing Civitas in a language called Jif, whose name stands for Java plus information flow. It is a security typed language, in which types contain information flow policies. These policies express requirements on the confidentiality and integrity of information. The Jif compiler and runtime enforce those policies. This means that if the policies in the code express the right security requirements, and the Jif compiler is correct, then the code is secure w.r.t. the requirements. Clarkson: Civitas

Civitas Security Evaluation
To evaluate the security of Civitas, we analyzed the assumptions that the security proofs make. This is a natural place to focus our attention, because in security, assumptions equate to vulnerabilities.

Civitas Trust Assumptions
DDH, RSA, random oracle model. The adversary cannot masquerade as a voter during registration. Voters trust their voting client. At least one of each type of authority is honest. The channels from the voter to the ballot boxes are anonymous. Each voter has an untappable channel to a trusted registration teller. We call these the trust assumptions for Civitas. Clarkson: Civitas

DDH, RSA, random oracle model. The adversary cannot masquerade as a voter during registration. Voters trust their voting client. At least one of each type of authority is honest. The channels from the voter to the ballot boxes are anonymous. Each voter has an untappable channel to a trusted registration teller. Verifiability and Coercion resistance Coercion resistance Clarkson: Civitas

DDH, RSA, random oracle model. The adversary cannot masquerade as a voter during registration. Voters trust their voting client. At least one of each type of authority is honest. The channels from the voter to the ballot boxes are anonymous. Each voter has an untappable channel to a trusted registration teller. VER + CR CR Clarkson: Civitas

Civitas Cost Evaluation
The security of Civitas is not the only thing we analyzed. We also conducted a performance study of Civitas.

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? Society today makes a tradeoff when it comes to the cost of elections. We balance cost with other factors like security and usability. The International Foundation for Election Systems estimates that the current total cost of an election in a Western democracy is $1-$3 per voter. And we get some level of security for that cost. I’d like to compare that $1-$3 cost to what the cost of Civitas would be, but I don’t know the total cost of a Civitas election. What I do know is that using Civitas would incur at least one new cost not generally present in real-world elections---the computational cost of performing all the cryptography during tabulation. So using our implementation, we investigated what the tabulation cost of Civitas would be. Clarkson: Civitas

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 But in the real-world, it isn’t just asymptotics that matter. It’s cost. The previous graph’s data reveal that tabulation takes about 39 sec / voter / authority. Suppose that you had to buy all the hardware to tally the selection, use it for 5 hours, then throw it away afterwards. Then at a cost of $1500 per machine (which is what the machines we ran these experiments on cost at the time we ran the experiments), the cost to tabulate the election would be $12 per voter. Or, suppose that you could rent CPU time at a price of one dollar per CPU per hour --- in fact Sun offers just this --- than the cost to tabulate the election would be four cents per voter. Would society pay this extra cost for more secure elections? I don’t know. As I said before, it’s a tradeoff. IACR ? Clarkson: Civitas

Conclusion This brings me almost to the end of my talk, so let me begin to wrap up.

Summary Civitas provides security: Civitas provides assurance:
Remote voting Verifiability Coercion resistance (strongest?) Civitas provides assurance: Security proofs Explicit trust assumptions Information-flow analysis of implementation (first?) I've told you today about Civitas, a secure remote voting system that we implemented. IACR  Clarkson: Civitas

Technical Issues Web interfaces Testing BFT bulletin board
Threshold cryptography Anonymous channel integration IACR  Clarkson: Civitas

Research Issues Distribute trust in voter client
Eliminate in-person registration Credential management Application-level DoS Clarkson: Civitas

Web Site Technical report with concrete protocols
Technical report with concrete protocols Source code of our prototype If you'd like to learn more about Civitas, you can visit this URL. Our website has a technical report containing a concrete specification of the protocols that Civitas uses, and a prototype implementation that you can download. Clarkson: Civitas

Extra Slides Clarkson: Civitas

Paper What paper does: What paper does next: What paper doesn’t:
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

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

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

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 After implementing Civitas, we ended up with the following LOC. About 13,000 are in Jif, which makes this the largest system yet implemented in Jif. About 8000 LOC are Java, with a tiny bit of C, to implement numeric operations for crypto, and to implement low-level I/O. In the Jif code, there are 20 distinct confidentiality policies, and 26 distinct integrity policies. Clarkson: Civitas

Civitas Policy Examples
Confidentiality: Information: Voter’s credential share Policy: “RT permits only this voter to learn this information” Jif syntax: RT  Voter 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 Let me give you a few examples of how we use Jif policies in Civitas. As an example of a confidentiality policy, consider a voter’s credential share, stored by a registration teller. That teller should permit only the voter to learn that information. In the code, this requirement is expressed as RT -> voter (though I’m simplifying). As an example of an integrity policy, consider the ballot design of an election. Suppose there’s an election supervisor whose job it is to specify this. Then the tabulation tellers, who need to check that all the votes conform to this design, would require that only the supervisor can influence the ballot design. In Jif, this is expressed as TT <- Sup Clarkson: Civitas

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 ] Jif also permits richer kinds of confidentiality requirements to be expressed as policies. Declassification policies allow information to become more public. For example, bit commitments are used during the tabulation protocols. The bits that are committed to must remain secret until all the tellers have committed, at which point they become public knowledge. We can express this as a declassification policy, though I’ll omit the somewhat complicated Jif syntax. Erasure policies require information to become more secret; perhaps even erased completely. For example, a voter’s credential shares are only needed to construct the full credential. Once this is done, there is no reason to keep them around. In fact, deleting them improves coercion resistance. This is a policy that can be expressed in Jif, which will at run-time automatically delete the information. Clarkson: Civitas

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 Reusing real-world mechanism, can bootstrap into a system offering stronger security One way to satisfy both of these assumptions is to use in-person registration. This is not an absolute requirement, though it seems reasonable if you want strong assurance in the authentication of voters. Also, voters need not register in-person with all tellers. In-person registration would actually be implemented much like real-world voting is today. The registration teller would need to be trusted to correctly authenticate a voter, and thus prevent an adversary from registering on behalf of a voter. The issue of the credential would need to happen in a registration booth, which would offer the same privacy that a voting booth does today. And registration need not happen on the same day for all voters; it could be an ongoing process. Although this does compromise our goal of a fully remote system, the credential obtained by an in-person registration could be reused to vote remotely in many elections. This reveals something interesting: we can use the same mechanism as in the real world today (in-person authentication + booth) to bootstrap and get a voting system that can offer stronger security than the real world, and even allow remote voting. Clarkson: Civitas

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, Kutyłowski et al., Zúquete et al., …] This is a rather strong assumption, but I want to point out that it's not the same assumption made in real-world voting systems. In particular, we are not introducing a DRE. (DRE stands for direct recording electronic, typified by touchscreen vote-capture systems.) Unlike with DRE's, voters are not required to trust a single, closed source implementation. Rather, voters can obtain a client from, or travel to a client provided by any organization that they trust. Ideally, of course, we would instead like to discharge this assumption by refactoring the client into distinct pieces, and distribute trust over those pieces, much as we distributed trust over a set of tellers. And there is ongoing research in this area, which I hope that one day can be integrated into Civitas. Clarkson: Civitas

Blocks Block is a “virtual precinct” Tabulation time is:
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 The benefit of blocks is the tabulation time, while still remaining quadratic in the block size, can now be linear in the number of voters. And that's assuming that we use one set of machines to tabulate the election for all blocks. But suppose we have a set of machines per block: then tabulation time would actually be constant in the number of voters, for a given block size. Clarkson: Civitas

Tabulation Time vs. Anonymity
First, you’ll recall that tabulation time is quadratic in the block size. This graph shows wall clock time to tabulate on the y axis vs. the block size on the x axis. We assume that there are four tabulation tellers. You can see that, for a tabulation time of 1 hour, we can have up to 100 voters in a block. Also, the graph confirms that tabulation is quadratic in the block size. # voters = K, # tab. tellers = 4, security strength ≥ 112 bits [NIST 2011–2030] Clarkson: Civitas

Tabulation Time vs. # Voters
sequential parallel So fixing the block size at 100, Let’s look at how what happens when we vary the number of voters. In this graph, the y-axis is still wall clock time to tabulate the election, and the x-axis is now the number of voters. A single set of machines is used to tally all the blocks. As you can see, we get exactly the linear performance that we expected. However, given a set of machines per block, Civitas could tally any number of voters in about an hour. K = 100 Clarkson: Civitas

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 Ranked voting methods allow voters to express more detailed preferences than standard (plurality) voting. Examples include Condorcet, Borda, STV/IRV, etc. These methods are desirable because they can help to eliminate spoiler effects and to defend against strategic voting. Implementing coercion-resistant ranked voting is tricky, because rankings can be used to signal a voter’s identity. (Italian attack is like the “Netflix attack”---another high dimensional space.) Civitas implements Condorcet, approval, and plurality voting. And in principle, we could implement any summable voting method (in which a ballot can be decomposed in a particular way). The TR for this paper gives a new construction for coercion-resistant Condorcet, based on homomorphic encryption, that is far more efficient than previous constructions. Clarkson: Civitas

Civitas Michael Clarkson Cornell Stephen Chong Harvard

Similar presentations

Presentation on theme: "Civitas Michael Clarkson Cornell Stephen Chong Harvard"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Civitas Michael Clarkson Cornell Stephen Chong Harvard

Similar presentations

Presentation on theme: "Civitas Michael Clarkson Cornell Stephen Chong Harvard"— Presentation transcript:

Similar presentations

About project

Feedback