Civitas: A Secure Voting System

Michael R. Clarkson Stephen Chong Andrew C. MyersDepartment of Computer Science

Cornell University{clarkson,schong,andru}@cs.cornell.edu

Cornell University Computing and Information ScienceTechnical Report 2007-2081

May 2007Revised August 2007∗

Revised November 2007

Abstract

Civitas is the first electronic voting system that is coercion-resistant, universally and voterverifiable, and suitable for remote voting. This paper describes the design and implementationof Civitas. Assurance is established in the design through security proofs, and in the imple-mentation through information-flow security analysis. Experimental results give a quantitativeevaluation of the tradeoffs between time, cost, and security.

1 IntroductionElectronic voting is now a reality—and so are the many errors and vulnerabilities in commercialvoting systems [55, 3, 11, 83]. Voting systems are hard to make trustworthy because they havestrong, conflicting security requirements:

• Integrity of election results must be assured so that all voters are convinced that votes arecounted correctly. Any attempt to corrupt the integrity of an election must be detected andcorrectly attributed.

• Confidentiality of votes must be maintained to protect voters’ privacy, to prevent selling ofvotes, and to defend voters against coercion.

Integrity is easy to obtain through a public show of hands, but this destroys confidentiality. Confi-dentiality can be obtained by secret ballots, but this fails to assure integrity. Given the civic impor-tance of elections, violations of these requirements can have dramatic consequences. Many securityexperts therefore have been skeptical about electronic voting [69, 29, 32, 49, 60], arguing that as-surance in voting systems is too hard to obtain and that their deployment creates unacceptable risks.

Attention on electronic voting has focused on the problem of supervised voting, in which votersinteract with a computing device under the supervision of election authorities. However, we argue

∗The original name of this voting system was CIVS. This revision changed the name to Civitas.

1

that the right problem to solve is the more general problem of remote voting, in which there isno supervision of voters or computing devices. As hard as secure supervised voting may be, secureremote voting is even harder. Electronic voting systems are often designed for trusted polling placeswith human supervision and certified hardware and software. But all components, including clients,servers, and networks, of a remote voting system are potentially malicious. Nevertheless, Internetvoting, an instance of remote voting, is increasingly used by diverse and important groups, suchas Debian [27], the Association for Computing Machinery [2], and (though it ultimately canceledthe project) the U.S. military [48]. Even U.S. government elections appear to be reducing thesupervision of voting. Voters in the state of Oregon vote only by postal mail, another instance ofremote voting, and all states receive a substantial fraction—enough to change the outcome of manyelections—of their ballots by mail as absentee ballots.

Despite existing pessimism, this paper argues that it is possible today to build a secure, practical,remote voting system.1 Civitas, our prototype, guarantees strong security properties in the presenceof a strong adversary. These security properties, coercion resistance and verifiability (defined inSection 2), are the most ambitious security requirements yet identified for voting systems. Similarly,Civitas is secure against a more powerful adversary than any other implemented voting system. Toachieve this, Civitas is constructed using principled techniques:

• Security proofs. The design of Civitas is a refinement of a cryptographic voting schemeby Juels, Catalano, and Jakobsson [52]. The Civitas voting scheme is provably secure: theoriginal scheme was proved secure by Juels et al., and we extend the proof to account for ourchanges to the scheme.

• Secure information flow. The implementation of Civitas was carried out in Jif [61, 63], a lan-guage whose compiler verifies (and run-time system enforces) that programs use informationonly in accordance with programmer-specified information-flow security policies.

These techniques are a strong basis for our argument that Civitas, despite its complexity, is secure.The combination of proofs and compiler-assisted reasoning yields assurance in both the design andimplementation of the system. To evaluate the security offered by Civitas, Section 4 identifies thetrust assumptions on which the security proofs rely. Any successful attack on the system mustviolate at least one of the assumptions. We discuss such attacks and suggest possible defenses inSection 8.

In addition to security, practical performance is a goal of Civitas. Previous work on securevoting falls roughly into two categories: theoretical voting schemes that have not been implementedand have not been shown to scale to large elections, and voting system implementations that doappear to scale to large elections but offer insufficient assurance of confidentiality and integrity.Civitas resolves this conflict between security and practicality by demonstrating, for the first time,that strong security properties can be offered by a scalable voting system. For reasonable securityparameters, the marginal cost of tabulating a Civitas election is as low as 4¢ per voter, which ispractical.

The most important contribution of this work is the Civitas system itself. Civitas is the first vot-ing system that provably satisfies coercion resistance and verifiability; no other implemented voting

1Note our distinction between voting systems, which are software implementations, voting schemes, which are cryp-tographic protocols, and voting methods, which are algorithms that aggregate voters’ preferences to produce a collectivedecision.

2

system offers comparable security guarantees. Thus, Civitas takes an important step in bringingsecure electronic voting to reality. In addition, the development of Civitas has led to several novelcontributions:

• A provably secure voter registration protocol, which distributes trust over a set of registrationauthorities.

• A scalable design for vote storage that ensures election integrity without expensive fault tol-erance mechanisms.

• A performance study demonstrating the practicality of secure remote voting.

• A coercion-resistant construction for implementing a ranked voting method. Such methods,described in Section 9, have advantages over the standard method of plurality voting.

• A concrete, complete, publicly available specification of the cryptographic protocols requiredfor a coercion-resistant, verifiable, remote voting scheme. This specification (located in Ap-pendix B ) leverages numerous results in the cryptographic and voting literature.

This paper describes and evaluates Civitas. Section 2 explains the security requirements andthreat model for a coercion-resistant, verifiable, remote voting system. The following sectionspresent Civitas: its architecture and voting scheme (Section 3), the trust assumptions on whichthe scheme is based (Section 4), the implementation of cryptographic components (Section 5), tech-niques used to achieve scalability (Section 6), and the use of Jif in implementation (Section 7). Se-curity is evaluated in Section 8 through a discussion of possible attacks and corresponding defenses.Implementation of ranked voting methods is described in Section 9. The performance of Civitas isevaluated in Section 10. Related work is reviewed in Section 11, and Section 12 concludes.

2 Security ModelA secure remote voting system must satisfy two strong requirements.2 The first, an integrity require-ment, is that no adversary can change the final tally to be different than if all votes were publiclyannounced and tallied in the presence of all voters. The second, a confidentiality requirement, is thatno adversary can learn any more about votes than is revealed by the final tally.3 No real-world vot-ing system of which we are aware simultaneously satisfies both of these requirements—and manyvoting systems fail to satisfy even one of the requirements. For example, the commercial votingsystems currently deployed in the U.S. seem to offer no guarantee of integrity [83].

Previous work has proposed several security properties to fulfill these requirements. For in-tegrity, we require Civitas to satisfy the following property:

Verifiability. The final tally is verifiably correct: each voter can check that their own vote isincluded in the tally (voter verifiability); and anyone can check that all cast votes are counted,that only authorized votes are counted, and that no votes are changed during counting (universalverifiability).4

2A third requirement that could be added is availability of the election system and results. We defer discussion ofavailability to Section 8 because the techniques necessary to achieve it are mostly orthogonal to the techniques used toachieve integrity and confidentiality.

3These intuitive requirements are instances of the correctness and privacy requirements of secure multi-party compu-tation [39].

4Universal verifiability was originally stated by Sako and Kilian [71].

3

Although we have defined “verifiability” informally for simplicity, Civitas actually satisfies theformal definition given by Juels et al. [52].

For confidentiality, a common, simple property is anonymity: the adversary cannot learn themap from voters to votes. This property is accompanied by the strong assumption that voters willnot act to violate their own anonymity. In remote voting, this assumption is unreasonable: votebuying, a well-known phenomenon in real-world supervised elections, could have a large impact byinducing voters to reveal their votes.

Moreover, in remote voting, adversaries may be able to coerce voters with virtual, or evenphysical, threats. For example, the adversary might be the voter’s employer or domestic partner.Against such adversaries, it is necessary to ensure that voters can lie to the adversary about thevotes they submit, and that voters can appear to comply with any behavior that the adversary de-mands of them. This guarantees that confidentiality is maintained even when voters collude withthe adversary.5 Thus for confidentiality, we require Civitas to satisfy the following property:

Coercion Resistance. Voters cannot prove whether or how they voted, even if they can interactwith the adversary while voting.

Again, we have defined the term “coercion resistance” informally here, but Civitas actually satisfiesthe formal definition given by Juels et al. [52].6 This requires Civitas to defend against attacks inwhich the adversary demands secrets (e.g., cryptographic material) known to the voter. Civitas mustalso defend against attacks in which the adversary demands that a voter submit any particular valueas a vote. The value might be a legitimate vote or a random value, or even a demand that the voterabstain—i.e., submit no value at all.

The above discussion of security requirements has frequently mentioned the adversary. It isprudent to assume that the adversary can corrupt various components of the election system, aswell as the election authorities, agents who provide the components. More specifically, we requireCivitas to be secure with respect to the following threat model, essentially due to Juels et al. [52]:

Strong Adversary. The adversary may corrupt a threshold of the election authorities; coercevoters, demand their secrets, and demand any behavior of them—remotely or in the physical pres-ence of the voter; control all public channels on the network; and perform any polynomial-timecomputation.

Section 4 identifies a threshold of uncorrupted authorities that is sufficient to guarantee security ofCivitas.

The Strong Adversary definition suggests the existence of non-public channels. In fact, we as-sume the existence of some anonymous channels, on which the adversary cannot identify the sender,and some untappable channels, which the adversary cannot use at all. An untappable channelmust provide perfect secrecy, either by being physically untappable or implementing information-theoretic encryption—e.g., a one-time pad. We argue that these assumptions are reasonable andnecessary in Section 4.

5Removing interaction with the adversary results in receipt-freeness, a weaker property originally defined by Be-naloh [7].

6“Coercion resistance” is used informally throughout the literature. Juels et al. [52] and Delaune et al. [28] recentlygave formal definitions in the computational and symbolic models, respectively, of cryptography. The informal definitiongiven above is consistent with both.

4

registrationtellersregistration

tellersregistrationteller

voterclient

ballotboxballotboxballotboxballotbox

tabulation teller

tabulation teller

tabulation teller

tabulation teller

bulletinboard

verifiablereencryption mix

acquirecredential

vote

eliminate bad votesmix votes

decrypt resultsauditcommit

sign,retrievevotes

Figure 1: Civitas architecture

3 ArchitectureCivitas comprises five kinds of agents: a supervisor, a registrar, voters, registration tellers, andtabulation tellers. Some of these are depicted in Figure 1. The agents other than voters are electionauthorities.

• The supervisor administers an election. This includes creating the election by specifying theballot design, the registrar, and the tellers; and starting and stopping the election.

• The registrar authorizes voters for an election by posting each voter’s identifier (an arbitrarystring, perhaps a name, email address, or registration number) and public keys.

• Registration tellers are responsible for generating the credentials that voters use to cast theirvotes.

• Tabulation tellers tally votes in a way that is both coercion-resistant and universally verifiable.

These agents use two underlying storage services: a publicly readable, insert-only bulletin boardto which election authorities post signed messages, and a set of ballot boxes that accept votes fromvoters.

The Civitas voting scheme refines a voting scheme developed by Juels, Catalano, and Jakobsson(JCJ) [52]. Similar to a JCJ election, a Civitas election has three phases: setup, voting, and tabula-tion. Discussion of the cryptographic protocols involved in these phases is deferred to Section 5.

Setup phase. First, the supervisor creates the election by posting the registrar’s public key and theballot design on an empty bulletin board. The supervisor also identifies the tellers by posting theirindividual public keys. The agreement of the registrar and the tellers to participate in the election isobtained out-of-band. The registrar posts identifiers for all authorized voters along with their publickeys.

Second, the tabulation tellers collectively generate a public key for a distributed encryptionscheme, and post it on the bulletin board. Decryption of messages encrypted under this key requiresall tabulation tellers to participate.

Finally, the registration tellers generate credentials, which are used to authenticate votes anony-mously. Each credential is associated with a single voter. Like keys in a public-key cryptosystem,

5

credentials are pairs of a public value and a private value: the public credential and the privatecredential. All public credentials are posted on the bulletin board. Credentials are generated in adistributed fashion, such that each registration teller holds a share of the private credentials. Thus,valid private credentials can be forged or leaked only if all registration tellers collude.

Voting phase. Voters register to acquire their private credentials. Each registration teller authenti-cates a voter using the voter’s public key, then releases the private credential share to the voter. Thevoter combines all of these shares to construct the full private credential. To vote, the voter submitsa private credential and a choice of a candidate (both encrypted), along with a proof that the voteis well-formed, to some or all of the ballot boxes. This replication of the vote is used to guaranteeavailability of the vote for tabulation.

Tabulation phase. The tabulation tellers collectively tally the election, proceeding through severalsubphases:

1. Retrieve data. All tabulation tellers retrieve the votes from each ballot box and the publiccredentials from the bulletin board.

2. Verify proofs. Each vote is checked to verify the proof that the vote is well-formed. Anyvote with an invalid proof is discarded. (For efficiency, our implementation actually mergesthis with the next subphase.)

3. Eliminate duplicates. Only one submitted vote is retained for each credential. Any dupli-cates are eliminated according to a revoting policy.

4. Anonymize. Both the list of submitted votes and the list of authorized credentials are anon-ymized by applying a random permutation, implemented with a verifiable reencryption mix.In the mix, each tabulation teller in turn applies its own random permutation.

5. Eliminate unauthorized votes. The credentials in the anonymized votes are comparedagainst the anonymized authorized credentials. Any votes with invalid credentials are dis-carded.

6. Decrypt. The remaining choices, but not credentials, are decrypted. The final tally is publiclycomputable.

Revoting. Voters might submit more than one vote per credential. The supervisor has the flex-ibility to specify a policy on how to tally such revotes. If revotes are not allowed, then all votessubmitted under duplicate credentials are eliminated. If revotes are allowed, then the voter mustinclude a proof in later votes to indicate which earlier votes are being replaced. This proof mustdemonstrate knowledge of the credential and choice used in both votes, preventing an adversaryfrom revoting on behalf of a voter.

Verifying an election. Tabulation is made publicly auditable by requiring each tabulation tellerto post proofs that it is honestly following the protocols. All the tabulation tellers verify theseproofs as tabulation proceeds, and an honest teller refuses to continue when it discovers an invalidproof. (Recovery is discussed in Section 8.) Anyone can verify these proofs during and aftertabulation. This achieves universal verifiability. A voter can also verify that his vote is present inthe set retrieved by the tabulation tellers. This achieves voter verifiability.

6

Lying to an adversary. To lie about a private credential, the voter locally runs an algorithm toproduce fake private credential shares that, to an adversary, are indistinguishable from valid shares.The voter can substitute the resulting fake private credential for his real private credential and be-have however the adversary demands. For example, the voter might abstain from voting with thefake credential, submit an adversary-supplied vote with the fake credential, or surrender the fakecredential to the adversary. This key idea, due to JCJ, is what enables coercion resistance.

4 Trust AssumptionsThe security of Civitas depends on the following necessary, and reasonable, assumptions.

Trust Assumption 1. The adversary cannot simulate a voter during registration.

There must be some period of time during which the adversary cannot simulate the voter, oth-erwise the system could never distinguish the adversary from the voter. Registration is a good timefor this assumption because it requires authentication and can be done far in advance of the election.Civitas authenticates voters with their private keys, so this assumption restricts the adversary fromdemanding this particular secret from a voter. Additional mechanisms, such as tamper-resistanthardware, could enforce non-transferability of the voter’s private key.

Trust Assumption 2. Each voter trusts at least one registration teller, and the channel from thevoter to the voter’s trusted registration teller is untappable.

This assumption guarantees that the voter can construct a convincing fake credential, whichrequires modifying at least one of the shares received during registration. The voter must trustthe teller who issued that share not to reveal that it is fake. Moreover, any agent who observedthe original share in transit on the network could detect the modification, even if the share wasencrypted. So an untappable channel is required for distribution of this one share. (Other messagesin the system can still use public channels that the adversary controls.) In-person registration or aone-time pad could be used to implement an untappable channel, and Section 8 discusses how tomitigate attacks on Civitas when no untappable channel is available.

While an untappable channel is a strong assumption, it is actually the weakest known assump-tion for a coercion-resistant voting scheme [71, 24, 42, 5, 52]. Eliminating this assumption wouldrequire a distributed, incoercible construction of credentials. While results on incoercible multi-party computation [13] might help, no practical construction is yet known. This has been an openproblem for at least a decade [25].

Trust Assumption 3. Voters trust their voting clients.

A corrupt voting client could violate coercion resistance by sending the plaintext of the voter’scredential and choice to the adversary, and it could violate verifiability by modifying the voter’scredential or choice before encrypting it. A poorly designed user interface could also lead to avote being cast contrary to the voter’s intentions. Civitas diminishes these threats because votersare not restricted to any particular client implementation; rather, voters may choose the client fromwhich they vote. The client could be provided by an organization the voter trusts, such as their ownpolitical party. Section 8 discusses how to defend against attacks on the client.

Trust Assumption 4. The channels on which voters cast their votes are anonymous.

7

Without this assumption, the adversary could trivially violate coercion resistance by observingnetwork traffic and learning which voters have voted. Anonymizing networks [30] could be used toimplement an anonymous channel. (Timing attacks on the anonymizing network are unlikely to beeffective because a vote typically fits into just three packets.) Note that if this assumption fails, anadversary still cannot learn the voter’s vote or credential.

Trust Assumption 5. Voters trust that at least one of the ballot boxes to which they submit theirvotes is correct.

A correct ballot box returns all the votes that it accepted to all the tabulation tellers. This isweaker than standard assumptions such as Byzantine fault tolerance [15] (which would require thatno more than f ballot boxes fail, for some number f ) and multi-party computation [39] (whichwould require a majority of honest ballot boxes).

Trust Assumption 6. There exists at least one honest tabulation teller.

If all tellers were corrupted, then the adversary could trivially violate coercion resistance bydecrypting all credentials and votes. Additional fault tolerance techniques [34, 20, 72] could makeit more difficult for the adversary to corrupt all of the tellers. Note that this assumption is notnecessary for verifiability, which is achieved by the proofs that tellers post during tabulation.

Trust Assumption 7. The Decision Diffie-Hellman (DDH) assumption, the RSA assumption, andthat SHA-256 implements a random oracle.

DDH and RSA are standard cryptographic assumptions. A violation of these would yield attacksagainst many systems—not just Civitas. The more fundamental assumption for Civitas is DDH, asthe JCJ security proof is a reduction from it. SHA-256 is discussed in the next section.

5 Cryptographic ComponentsImplementation of Civitas requires many cryptographic components. This section gives an overviewof how these are used during an election; Appendix B contains a complete specification of theprotocols. Many of the components require posting messages to the bulletin board, and all suchposts must be signed by the principal who makes the post. Also, a variety of zero-knowledge proofsare used to enforce the honest execution of protocols. These proofs are made non-interactive via theFiat-Shamir heuristic [33], so their security is in the random oracle model [6]. Civitas implementsa random oracle with SHA-256.

Security proof. Several of the components described below instantiate oracles assumed by the JCJvoting scheme. The security of Civitas follows from the JCJ security proof [52] and the individualsecurity proofs of each component, cited below. For the registration oracle, which we constructedourselves, we give a security proof in Appendix A.

5.1 Setup phaseKeys. During setup, the supervisor posts RSA public keys representing the election authorities.These keys are used for authentication of principals and messages. The choice of RSA is for con-venience, since many real-world organizations already have RSA keys, but could be replaced by

8

another cryptosystem. The tabulation tellers also generate a distributed El Gamal public key, de-scribed below. The registrar posts both an RSA public key and an El Gamal public key for eachvoter. Voters are authenticated by their RSA public keys, and their El Gamal public keys are usedto construct proofs during registration, as described below. Civitas assumes that the supervisor andregistrar are trusted to certify this binding between public keys and principals, or that there is someexternal mechanism, such as a public-key infrastructure, to certify the binding.

Encryption Scheme. Civitas implements a distributed El Gamal scheme similar to Brandt’s [10].The supervisor posts a message (p, q, g) describing the cryptosystem parameters: a prime p =2kq + 1, where q is also prime, and a generator g of the order q subgroup of Z∗p. This subgroup,denoted M, is the message space of the cryptosystem. The tabulation tellers run a protocol togenerate an El Gamal public key KTT for which each teller holds a share of the correspondingprivate key. Encryption of message m under key K with randomness r is denoted Enc(m; r;K).We omit r and K from this notation when they are unimportant or clear from context. Decryptionof a ciphertext c that was encrypted under key KTT, denoted Dec(c), requires all tabulation tellers.

El Gamal encryption is homomorphic with respect to multiplication. That is, Enc(m)·Enc(n) =Enc(m · n). El Gamal also permits a probabilistic reencryption operation, denoted Reenc(c) fora ciphertext c, which produces a new encryption of the same plaintext. Encryption can also bemade non-malleable, preventing the use of homomorphisms and reencryption, by the use of Schnorrsignatures [75]. Civitas uses non-malleable encryption until the tabulation phase, where malleabilityis required.

Civitas uses two zero-knowledge proofs to ensure the honesty of tellers during key generationand during decryption. The first is a proof of knowledge of a discrete logarithm due to Schnorr [74].Given a message v and generator g, this proof shows knowledge of an x such that v ≡ gx (mod p).The second is a proof of equality of discrete logarithms due to Chaum and Pedersen [18]. Given mes-sages v and w and generators g and h, this proof shows there exists an x such that v ≡ gx (mod p)and w ≡ hx (mod p).

Credential generation. Civitas uses a novel construction for credential generation and distribu-tion, based on ideas found in earlier work [25, 42, 52]. The security of this construction is proved inAppendix A. For each voter, each registration teller individually generates a credential share, poststhe public part of the share, and stores the private part. The voter’s public credential is publiclycomputable from the posted shares.

More concretely, a private credential share is a random element ofM. For each voter, registra-tion teller i chooses a random element si and posts Enc(si;KTT) on the bulletin board as the publiccredential share Si. The resulting public credential S for the voter is

∏i Enc(si;KTT), which by the

homomorphic property is equal to Enc(∏i si;KTT).

5.2 Voting phaseRegistration. To acquire a private credential, a voter contacts each registration teller and authen-ticates using the RSA keys posted by the registrar. Civitas uses the Needham-Schroeder-Lowe [58]protocol to authenticate a shared AES session key. The voter requests the registration teller’s share siof the private credential. The registration teller responds with (si, r, S′i, D), where S′i = Enc(si; r)and D is a designated-verifier reencryption proof (DVRP) due to Hirt and Sako [42]. The proof

9

shows that S′i is a reencryption of Si, the public credential share. Construction of this proof re-quires the voter’s El Gamal public key. The voter verifies that S′i was computed correctly from siand r, then verifies the DVRP. These verifications convince the voter, and only the voter, that theprivate share is correct with respect to the public share posted on the bulletin board—i.e., that Si isan encryption of si. After retrieving all the shares, the voter constructs private credential s, wheres =

∏i si.

Voting. To cast a vote, the voter posts an unsigned message 〈Enc(s;KTT),Enc(v;KTT), P 〉 toeach of the ballot boxes, where s is the voter’s private credential, v is the voter’s desired choice, andP is a zero-knowledge proof. P shows that the vote is well-formed with respect to the ballot designof the election, and that the submitter knows the plaintext credential and choice. The latter defendsagainst an adversary who attempts to post functions of previously cast votes. P is implemented inpart with a 1-out-of-L reencryption proof due to Hirt and Sako [42]. Given C = {ci | 1 ≤ i ≤ L}and c, this reencryption proof shows there exists an i such that ci = Reenc(c). P also uses anadaptation of a proof due to Camenisch and Stadler [12] to show knowledge of the plaintexts.

Lying to the adversary. The key to coercion resistance is the ability to construct fake credentials.The voter chooses at least one registration teller and substitutes a random group element s′i ∈M forthe share si that registration teller sent to the voter. The voter can construct a DVRP that causes thefake share to look valid to the adversary, unless the adversary has corrupted the registration tellerthe voter chose (in which case the adversary already knows the real share), or unless the adversaryobserved the channel used by the registration teller and voter during registration (in which case theadversary has seen the real proof). By Trust Assumption 2, there exists some teller and channel thatthe adversary does not control, so it is always possible for voters to lie about their credentials.

5.3 Tabulation phaseBallot boxes. Civitas utilizes a very simple yet efficient ballot box construction. Each ballot boxoperates independently, never needing to contact any other ballots boxes. Ballot boxes function asinsert-only logs: every vote submitted is recorded, without any checking of the validity of the vote.When the supervisor closes the election, each ballot box posts a commitment to its contents on thebulletin board. The supervisor then posts his own signature on all these commitments. This definesthe set of votes to be tabulated. Thus, if a voter posts his vote to at least one correct ballot box,then his vote will be tabulated. (A malicious supervisor could violate this by excluding a correctballot box. This trust in the supervisor could be eliminated by using a more expensive agreementprotocol.)

An important security property emerges from this construction: the system achieves just enoughavailability to guarantee universal verifiability, which requires that all votes are available for tabu-lation. The construction does not achieve the complementary property of availability of electionresults, which is discussed in Section 8. The benefit of this construction is scalability: no heavy-weight fault tolerance protocols are needed.

Mix network. A mix network is used to anonymize the submitted votes and authorized creden-tials. Civitas implements a reencryption mix network made verifiable by randomized partial check-

10

ing [46], in which each teller in the network performs two permutations.7

Duplicate and invalid credential elimination. It would be easy to eliminate votes containing du-plicate or invalid credentials if credentials could be decrypted then compared. However, this wouldfail to be coercion-resistant: all valid private credentials would be revealed, so voters could never lieabout credentials. Instead, a zero-knowledge protocol called a plaintext equivalence test (PET) isused to compare ciphertexts. Given c and c′, a PET reveals whether Dec(c) = Dec(c′), but nothingmore about the plaintexts of c and c′. Civitas implements a PET protocol due to Jakobsson andJuels [45]. For duplicate elimination, a PET must be performed on each pair of submitted creden-tials. Similarly, to eliminate invalid credentials, PETs must be performed to compare each submittedcredential with every authorized credential. These pairwise tests cause credential elimination to takequadratic time.

6 ScalabilityA practical voting system should scale to a large number of voters, using computing resourcesproportional to the number of voters. There are two main challenges for scalability in Civitas. First,elimination of duplicate and invalid credentials takes quadratic time. Second, tabulation requireseach teller to perform computation for each vote.

Our solution to both challenges is to assign voters into blocks. Voters are guaranteed anonymitywithin their own block, and the tally for each block can be computed independently. The implemen-tation of blocking is straightforward. The registrar assigns each voter to a block, and each submittedvote identifies, in plaintext, the block in which its (purported) credential resides. The vote proof isextended to make this block identifier non-malleable. The resulting anonymity can be compared tothat in real-world voting precincts, where voters are anonymous within their precincts, but precinctresults are public. Unlike in real-world precincts, the assignment into blocks need not be based onphysical location. For example, the registrar might assign voters to blocks in a way that is verifiablypseudorandom, reducing the risk of reprisal by the adversary against an entire block of voters.

Blocking also enables the production of early returns. A randomly chosen fraction of the blocksmay be tabulated and used to predict the outcome of the entire election. Under appropriate as-sumptions, such as random assignment of voters to blocks, this predictor may be correct with highprobability.

Table 1 identifies the parameters in which an election scales, and the number of modular ex-ponentiations performed per block by individual agents: registration tellers (RT), tabulation tellers(TT), and voters. (Tabulation time is dominated by modular exponentiations.) The table distin-guishes protocol exponentiations, which are required by the Civitas voting scheme regardless of theimplementation of the bulletin board, from bulletin board (BB) exponentiations, which are requiredby the particular implementation used in our prototype. These BB exponentiations result from RSAsignatures and verifications. Exponentiations are counted under the assumption that there are noduplicate votes and that no voters abstain, maximizing the number of PETs required. Parameter Adescribes the number of election authorities of each type—i.e., if A = 4, then there are four regis-tration tellers, four tabulation tellers, and four ballot boxes. Regardless of the value of A, there is asingle bulletin board.

7Randomized partial checking reveals a small amount of information about the permutation performed by the mixnetwork; this can be reduced using more sophisticated permutations [40]. Mix networks based on zero-knowledgeproofs [36, 65] offer better anonymity at the cost of more expensive verification.

11

Table 1: Modular exponentiations per block

Agent Action Protocol BBRT Generate all credentials 4K K

Distribute all credentials 14K –Voter Retrieve a credential 12A A

Vote 4C + 7 –TT Retrieve data – AK +A+ 1

Verify proofs 4M(C + 1) –Eliminate duplicates

(M2

)(8A− 1) 3A

Anonymize (mixes) 2(A+ 1)(M +K) 2AEliminate invalids KM(8A− 1) 3ADecrypt K(4A− 1) A

A = Number of authorities of each typeC = Number of choices on ballotK = Min. number of voters per blockM = Max. number of submitted votes per block

Blocking transforms duplicate elimination from O(N2) PETs, where N is the number of allsubmitted votes, to O(BM2) PETs, where B = b VK c is the number of blocks and V is the numberof voters. Invalid credential elimination changes fromO(V N) toO(BKM). The critical scalabilitygain from blocking is that the B factor in each of these terms is easily parallelizable: a different setof machines can be used to implement the tabulation tellers for each block. Tabulation time thendepends on M and K, but not V . This allows performance to scale independently of the number ofvoters.

7 Implementation in JifOur prototype of Civitas is implemented in an extended version of the Jif 3.0 programming lan-guage [61, 63]. Jif is a security-typed language [81] in which program variables are annotated withsecurity policies. The Jif compiler verifies that the program uses information in accordance withthese policies. This specification and automatic enforcement of security policies provides assurancein our implementation of Civitas.

In Jif, security policies are expressed using the decentralized label model [62], which allowsspecification of confidentiality and integrity requirements of principals. For example, the confiden-tiality label {RT1 � voter} means that principal RT1 owns the labeled information but permitsprincipal voter to learn it. Similarly, the integrity label {RT1 � supervisor} means that RT1permits principal supervisor to affect the labeled information. Because labels express securityrequirements explicitly in terms of principals, they are useful for constructing systems like Civitas,in which principals need to cooperate yet are mutually distrusting.

The Jif extension in which Civitas is implemented adds declassification and erasure policies [21],which allow principals to state conditions on when policies may be changed. Declassification poli-cies allow the set of readers of information to be expanded, thus declassifying information, and

12

erasure policies mandate conditions upon which the set of readers must be restricted, thus erasinginformation. Such policies are useful in expressing the security requirements of Civitas.

For example, declassification policies are used in the implementation of mix networks. Eachtabulation teller must commit to random bits, after which the bits are revealed, combined, andused to audit the mix. No bits may be revealed until all tellers have committed. In the code,this requirement is expressed as an declassification policy: the confidentiality label on the variablestoring the random bits of TTi indicates that the information is readable only by TTi until conditionallCommitted is satisfied, upon which the information may be declassified to be readable by allprincipals. This condition becomes true at the program point where all commitments have beenreceived.

As another example, erasure policies are used during registration. Each registration teller muststore a private credential share for each voter until the voter requests it. After this, the teller mayerase the share, ensuring that the secrecy of the share cannot later be compromised.8 In the codeimplementing the teller, the variable storing the share is labelled with an erasure policy indicatingthat the information becomes unreadable by all principals when condition delivered is satisfied. Thiscondition becomes true at the program point where receipt of the share has been acknowledged bythe voter. The Jif compiler inserts code at that point to erase the information from memory.

Our implementation of Civitas totals about 14,000 lines of Jif code. About 8,000 additional linesof Java code are used to perform I/O and to implement cryptographic operations such as encryptionand zero-knowledge proofs.

8 Attacks and DefensesAll systems can be attacked. This section discusses possible attacks against Civitas, and correspond-ing defenses.

Attacks on the voter client. Much of the concern about the security of electronic voting hasinvolved attacks on direct-recording electronic (DRE) voting terminals [55, 53]. With DRE voting,the voter uses a voting machine that is provided by a local election authority, with little recourseagainst untrustworthy authorities. The analogous component of Civitas is the machine and softwarethat implements the voter client. A key difference between the two kinds of systems is that inCivitas, voters have the ability to choose a voter client that they trust. Voters are not constrainedto use their own machine and software, which are often untrustworthy [69]; instead, they can use aclient provided by any organization that they trust, such as their political party, their university, orother social organizations. Civitas does not require any particular client implementation, only thatthe client follows a particular protocol. Therefore, these organizations might choose to implementtheir own client software on their own hardware. Such client diversity would be valuable because itwould raise the cost of mounting an attack, thus reducing the incentive to attack clients. Our ownprototype of the voter client is written in Jif, and the source code will be publicly available. Thisimplementation strategy makes it easier to establish trust in the Civitas software than in proprietaryvoting systems, and it aids organizations in implementing their own voter clients.

Even trusted voter clients might later be compromised. The machine, including the networkconnection, could hijacked by the adversary. And any level of the software stack could contain

8A consequence of erasure is that if a voter loses a share, then the teller is unable to reissue it. Instead, tellers wouldneed to be able to revoke shares and issue new shares. This is left as future work.

13

vulnerabilities or be compromised by malicious code such as a virus. Against such attacks, a rea-sonable defense is to decompose the voting client into multiple components and distribute trust overthose components [17, 50, 85, 56]. Another possibility is to leverage emerging trusted computingtechnology [80]. Making such defenses coercion-resistant is left as future work.

Attacks on registration. Voters may attempt to sell their identity so an adversary can registeron their behalf. Or, an adversary may try to coerce a voter into revealing the voter’s private key,which the adversary could then use to register as the voter. Defending against these attacks seemsto require authentication mechanisms that prevent the adversary from masquerading as the voter.For example, registration may need to be performed in person or by mail. This is a plausiblesolution, since registration may be done far in advance of the actual election. Moreover, if TrustAssumptions 2 and 6 are strengthened to honesty of tellers across multiple elections, credentials canbe reused.

Attacks on the network. Civitas is secure in the presence of an adversary that has considerablecontrol over the network. The adversary is assumed to be able to read and modify network traffic, ex-cept for the limitations expressed by Trust Assumption 2 (untappable channels) and Trust Assump-tion 4 (anonymous channels). Our Civitas implementation secures all channels with encryption,signing, and authentication protocols, but does not actually implement anonymity or untappabilityof channels.

The untappable channel is used to prevent the following attack. Suppose the adversary cantap all channels to registration tellers and record the encrypted traffic between the voter and theregistration tellers. Further suppose that the adversary can compromise the registration client sothat it records all credential shares received from tellers. The adversary can then ask the client toreveal the plaintext credential shares corresponding to the encrypted network messages. The votercan no longer lie about any credential shares without being detected.

This attack assumes an adversary who has compromised the network and also can induce votersto register using a compromised client. So a possible defense is to employ better authenticationmechanisms during registration, as discussed above. Our implementation of the registration clientemploys another defense: enforced erasure of all credential shares from the client once the voter’scredential is constructed. This prevents the voter from reporting them to the adversary.

Attacks on election authorities. Trust Assumptions 2, 5, and 6 allow all but one of each of thetypes of election authorities to be compromised, while still guaranteeing coercion resistance andverifiability. Certain attacks may still be mounted by corrupting some small sets of authorities:

• A corrupt registration teller may fail to issue a valid credential share to a voter. The voter candetect this, but coercion resistance requires that the voter cannot prove that a share is valid orinvalid to a third party. Defending against this could involve the voter and another electionauthority, perhaps an external auditor, jointly attempting to re-register the voter. The auditorcould then attest to the misbehavior of a registration teller.

• The bulletin board may fail. Because bulletin board messages are signed, altered messagesare detectable. Deletion of messages is an attack on availability, discussed below.

14

• A corrupt registrar may add fictitious voters or remove legitimate voters from the electoralroll. Each tabulation teller can defend against this by refusing to tabulate unless the electoralroll is correct, according to some external policy.

• A corrupt supervisor could post an incorrect ballot design, stop an election early, or evenattempt to simulate an election with only one real voter. Voters and tabulation tellers shouldcease to participate in the election once the supervisor exhibits such behavior.

Attacks on availability. Civitas does not guarantee availability of either election authorities orthe results of an election. However, the design of Civitas accommodates complementary techniquesfor achieving high availability.

To improve the availability of authorities (tellers, ballot boxes, and the bulletin board), theycould be implemented as Byzantine fault-tolerant services [15, 68]. Also, the encryption schemeused by Civitas could be generalized from the current distributed scheme to a threshold scheme. Thiswould enable election results to be computed when some tabulation tellers become unresponsiveor exhibit faulty behavior, such as posting invalid zero-knowledge proofs. Recovery from thesefaults would necessitate restarting the subphase of tabulation during which the failure is detected,substituting new tellers for the faulty tellers.9 Also, the Civitas trust assumptions must be updatedfor this scenario. For a threshold scheme requiring k out of n tabulation tellers to participate indecryption, no more than k − 1 tellers may be corrupted, otherwise coercion resistance could beviolated. For availability, a new trust assumption must be added: at least k tellers do not fail. Underthis assumption, the adversary could increase tabulation time by forcing at most n− k restarts.

To defend against application-level denial-of-service attacks, standard techniques such as rate-limiting and puzzles could be employed. These do not, however, prevent the adversary from inject-ing a large number of invalid votes, inflating tabulation time. A possible defense, which is left forfuture work, is to require a block capability in each submitted vote. The registrar issues each voteran unforgeable capability for the voter’s assigned block, and tabulation tellers check it during theverification subphase. The adversary must then compromise a voter and learn the block capabilityto successfully inflate tabulation time for that block, and must repeat this attack for each block.

Attacks outside the security model. Some real-world attacks, such as social engineering, are noteasily characterized by formal security models. Civitas offers resistance to some of these attacks.For example, malicious authorities might attempt to exploit human fallibility at following proto-cols [53]. However, the Civitas voting protocol requires the voter to prepare just a single messageand send a copy of it to all the ballot boxes. So there is little human fallibility to exploit duringvoting (although the registration protocol may be more susceptible). As another example, maliciousauthorities might attempt to prevent voters from accessing the voting system during an election.In real-world supervised voting, this attack might be effected by denying voters access to pollingstations, or providing a disincentive (such as threatening to make them pay past parking tickets ortaxes) for voters to enter the station. Civitas blunts such attacks by virtue of being a remote votingsystem. Voters are not restricted to voting in a single physical location; potentially, they could votefrom any location.

9Since the adversary might attempt to use partial information from aborted subphases, such as partially completedmixes, restarted subphases might need to employ verifiable pseudorandomness for any random values used in the proto-cols.

15

But ultimately, formal security models cannot characterize all real-world attacks. Such attackshave included attempts to confuse or misinform voters about the dates, significance, and proceduresof elections. Mitigation of such attacks is important for real-world deployments, but beyond thescope of this paper.

9 Ranked Voting MethodsPlurality voting, in which each voter chooses a single candidate and the winner is the candidate whoreceives the most votes, is the best-known voting method. However, it is subject to the spoiler effect,in which the presence of minor candidates affects the outcome. The spoiler effect is mitigated byranked voting methods, in which each voter submits a (partial or total) ordering of the candidates.Ranked voting methods are used by many organizations and by several countries; examples of suchmethods include single transferable vote (a.k.a. instant runoff), the Condorcet family of methods,and the Borda count [9]. Ranked methods are attractive because they enable voters to express moreinformation about their preferences, and that information can be used to produce a better collectivedecision. For example, Condorcet methods extend the principle of majority rule to ranked prefer-ences. A candidate who would defeat every other candidate in one-on-one elections is declared theCondorcet winner.

Coercion resistance is a challenge with ranked voting methods because ordered preferencesintroduce a covert channel: voters can encode information into low-order preferences in their votes.For example, if there are twenty candidates, a voter’s lowest ten preferences probably will notinfluence the outcome of the election, so at least 10! distinct values can be encoded, allowing votersto covertly identify themselves.

Civitas implements a Condorcet voting method, in addition to plurality voting and approvalvoting. No other voting system of which we are aware has a coercion-resistant implementation ofany ranked voting method. Civitas eliminates the covert channel by encoding the voter’s rankinginto

(C2

)votes, where C is the number of candidates. Each vote expresses one of three preferences

between candidates i and j: (1) i is preferred over j, (2) j over i, or (3) i and j are tied. Aftervotes are decrypted, these anonymized preferences are used to select the winner. This encodingincreases the resources needed to tabulate an election, but offers coercion resistance: the adversaryis unable to learn more about an individual voter’s low-order preferences than can be learned fromthe aggregate preferences of all voters, which are revealed by the final tally.

10 PerformanceA voting system is practical only if tabulation can be completed in reasonable time, with reasonablecost and security. Civitas offers a tradeoff between these three factors, because tabulation can becompleted more quickly by accepting higher cost or lower security. The goal of the performancestudy presented here is to show that reasonable tradeoffs exist between these factors, and that per-formance scales as predicted by the analysis in Section 6.

Notions of reasonable time, cost, and security may differ depending on the election or the ob-server. In current U.S. elections, accurate predictions of election results are available within a fewhours. Therefore, we choose a target tabulation time of five hours. The two most important param-eters affecting security are the minimum number of voters within each block (K) and the numberof tabulation tellers (A). As reasonable values for these parameters, we choose K = 100 andA = 4. Anonymity within 100 voters seems comparable to what is available in current real-world

16

elections, where results are tabulated at a precinct level and precinct workers might correlate voterswith ballots; random block assignment (Section 6) might even offer stronger anonymity than real-world elections. Similarly, four mutually distrusting authorities offer better oversight than manyreal-world elections.

Experiment design. We used Emulab [84] as an experiment testbed. The experiments ran on ma-chines containing 3.0 GHz Xeon processors and 1 GB of RAM, networked on a 1 Gb LAN. Notethat only tabulation tellers actually need hardware that is this fast. In particular, voters could usesubstantially less powerful hardware without significant impact on performance or on the votingexperience. Our machines ran Red Hat Linux 9.0 and Java 1.5.0 11. For RSA, AES, and SHAimplementations, we used the Bouncy Castle JCE provider 1.33. For the remaining cryptographicfunctionality, including El Gamal and zero-knowledge proofs, we implemented our own crypto-graphic library. We used a C library, GMP 4.2.1, for implementations of modular exponentiationand multiplication.

Key lengths were chosen to meet or exceed NIST recommendations [4] for the time period2011–2030. We used 128-bit AES keys, 2048-bit RSA keys, and 224-bit El Gamal keys from a2048-bit group—i.e., |p| = 2048 and |q| = 224. The average time to perform a modular exponenti-ation for this size El Gamal group was 3.7 ms.

Each experiment simulated all phases of a complete election. All the cryptographic protocolsand operations described in Section 5 were carried out in full. Therefore, the experimental resultsshould be representative of a real deployment. All experiments used plurality ballots with threecandidates, and no voters abstained, so C = 3, N ≥ V , and M ≥ K. Experiments were repeatedthree times, and we report the sample mean. The sample standard deviation was always less than2% of the mean.

Setup and voting time. The setup and voting phases of an election are not computationally in-tensive. Generation of keys and credentials in the setup phase scales linearly in the number ofauthorities and voters respectively, and can be conducted offline. During the voting phase, votersretrieve credential shares from registration tellers, and submit votes to ballot boxes. Experimentsindicate that voting time is reasonable: about 325 ms for a voter to acquire a credential share froma registration teller, and about 20 ms to submit a vote to a ballot box. Thus, for four authorities,it takes a voter less than 1.4 seconds to retrieve credentials and submit a vote. From the registra-tion teller’s perspective, it takes approximately 200 ms of CPU time to distribute a single voter’scredential share. Thus, a registration teller could process 18,000 voters per hour.

Tabulation time and space. Tabulation of each block is independent of other blocks, and com-bining the block tallies is a negligible part of the total tabulation time. This is demonstrated inFigure 2(a), where the tabulation tellers process blocks sequentially, and V is a multiple of K. Thedata from this graph indicate that Civitas requires 39 seconds per voter per authority to tabulatea single block. In five hours, Civitas can tabulate votes from 500 voters on one set of machines.Parameters A and K have non-linear effects on tabulation time, as shown in Figure 2(b) and Fig-ure 2(c). Communication increases quadratically in A, and PETs take time proportional to K2.Civitas can tabulate a single block of 200 voters in less than five hours.

The independence of block tabulation can be exploited to decrease tabulation time in at least twoways. First, blocks can be tabulated in parallel, as discussed in Section 6. Given a set of tabulationteller machines for each block, the data in Figure 2(a) predict that tabulation could be completed

17

(a)

0 100 200 300 400 500 600 700 800 900 10000123456789

10

V

Wal

l clo

ck (

hr.)

(b)

1 2 3 4 5 6 7 80

0.5

1

1.5

2

2.5

3

A

Wal

l clo

ck (

hr.)

(c)

0 50 100 150 200 250 3000123456789

10

K

Wal

l clo

ck (

hr.)

(d)

0 10 20 30 40 50 60 701

1.52

2.53

3.54

4.55

% Chaff

Wal

l clo

ck (

hr.)

Figure 2: Tabulation time vs. (a) Voters: K = 100, A = 4; (b) Authorities: K = V = 100; (c)Anonymity: V = K,A = 4; (d) Chaff: K = V = 100, A = 4

18

in about 65 minutes, independent of V . Second, by computing early returns (Section 6), a goodpredictor of election results can be obtained more quickly than the full tabulation. Because of thelinear tradeoff between time and machines at the granularity of blocks, the remaining measurementsin this study are for tabulation of a single block.

The memory footprint of Civitas is very small. With M = 100, the active set is never morethan 8 MB. The size of the active set scales linearly in M , so modern machines could easily fittabulation in memory for substantially larger values of M (and of K, since K ≤ M ). The storagespace needed for the entire bulletin board is also reasonable: less than 620 MB for an election whereK = 100, V = 100, and A = 4.

Chaff. We refer to votes containing invalid and duplicate credentials as chaff because they areeliminated during tabulation. Because chaff increases the number of votes in a block, it increases thetabulation time similarly to increasing anonymity parameter K. Figure 2(d) shows how tabulationtime varies as a function of the percentage of chaff votes in each block. With fraction c chaff (splitbetween invalid and duplicate credentials), there areM = V

1−c votes in a block. All the other graphsin this study assume c = 0. Because of coercion resistance, the percentage of chaff votes submittedby honest voters should be small. Adversary-submitted chaff votes are discussed in Section 8.

Cost. A government election in a stable western democracy currently costs $1–$3 per voter [43].Civitas would increase the cost of computing equipment but could eliminate the cost of maintain-ing secure polling places and printing ballots. A dual-core version of our experiment machines iscurrently available for about $1,500, so the machine cost to tabulate votes from 500 voters in fivehours (with K = 100 and A = 4) is at worst $12 per voter, and this cost could be amortized acrossmultiple elections. Moving to multicore CPUs would also be likely to reduce tabulation time, sincetabulation is CPU-bound (utilization is about 70–85% during our experiments), has a small memoryfootprint, and can be split into parallel threads that interact infrequently. Costs could be reduceddramatically if trust requirements permit leasing compute time from a provider. One provider cur-rently offers a rate of $1 per CPU per hour on processors similar in performance to our experimentmachines [79]. At this rate, tabulation for 500 voters would cost about 4¢ per voter—clearly in therealm of practicality.

Reducing the security parameters also reduces cost. For example, halving K approximatelyquarters tabulation time. So for a ten-hour, K = 50, A = 3 election, the cost per voter should beabout ten times smaller than a five-hour, K = 100, A = 4 election. El Gamal key lengths alsohave a significant impact. Figure 2(c) shows that, for 224-bit keys from a 2048-bit group, K canbe as high as 200 while maintaining a tabulation time of under five hours. With 160-bit keys froma 1024-bit group (secure, according to NIST [4], from 2007–2010), K can be increased to 400.Using 256-bit keys from a 3072-bit group (secure until after 2030) currently requires decreasing Kto 125.

11 Related WorkCryptographic voting schemes can be divided into three categories, depending on the technique usedto anonymize votes: homomorphic encryption, blind signatures, and mix networks. Here we cite afew examples of each type.

In schemes based on homomorphic encryption [7, 25, 70, 42], voters submit encrypted votesthat are never decrypted. Rather, the submitted ciphertexts are combined (using some operation that

19

commutes with encryption) to produce a single ciphertext containing the election tally, which is thendecrypted. Blind signature schemes [35, 67, 66] split the election authority into an authenticatorand tallier. The voter authenticates to the authenticator, presents a blinded vote, and obtains theauthenticator’s signature on the blinded vote. The voter unblinds the signed vote and submits it viaan anonymized channel to the tallier. In mix network schemes [16, 71, 5, 59], voters authenticateand submit encrypted votes. Votes are anonymized using a mix, and anonymized votes are thendecrypted.

Despite a plethora of voting schemes, few voting systems have actually been implemented,and none of these offers confidentiality guarantees as strong as in Civitas. Nor are any of theseaccompanied by security proofs. Sensus [26], based on a blind signature scheme known as FOO92[35], offers no defense against coercion. Neither does EVOX [41], also based on FOO92. Bothsystems allow a single malicious election authority to vote on behalf of voters who abstain. EVOX-MA [31] addresses this by distributing authority functionality. REVS [51, 57] extends EVOX-MAto tolerate failure of distributed components, but does not address coercion. ElectMe [77] is basedon blind signatures and claims to be coercion resistant, but its threat model is weaker than that ofCivitas: it assumes the adversary cannot corrupt election authorities. If the adversary learns theciphertext of a voter’s “ticket,” the scheme fails to be receipt-free. ElectMe also is not universallyverifiable: voters can verify their votes are recorded correctly, but the computation of the tally is notpublicly verifiable. Adder [54] implements a homomorphic scheme in which voters authenticateto a trusted “gatekeeper.” If an adversary were to corrupt this gatekeeper, then Adder would failto be coercion-resistant. Kiayias [54] surveys several voting systems from the commercial world,including VoteHere [82]. These proprietary systems do not generally make their implementationspublicly or freely available, nor do they appear to offer coercion resistance.

Four voting systems were recently submitted to the VoComp [76] competition. The W-Voting(a.k.a. Voting Ducks) submission [56] offers a limited amount of coercion resistance, but requiresvoters to sign votes, which appears susceptible to attacks in which coercers insist either that the voterabstain or submit a vote prepared by the coercer. It also requires voters to submit new votes (whichcancel older votes) if they wish to comply with a coercer. So unlike Civitas, an adversary couldsuccessfully coerce a voter by forcing the voter to submit a new vote, then keeping the voter undersurveillance until the end of the election. The remaining VoComp submissions—Pret a Voter [73],PunchScan [19], and Prime III [38]—offer lesser degrees of coercion resistance, are not designedfor remote voting, and require greater trust in election authorities than Civitas.

To optimize the JCJ scheme, Smith [78] proposes replacing PETs with reencryption into a deter-ministic, distributed cryptosystem. However, the proposed construction is insecure. The proposedencryption function is Enc(m; z) = mz , where z is a secret key distributed among the tellers. Thisscheme is malleable: given Enc(m), an adversary can easily construct Enc(mk) for any k, leadingto an attack on coercion resistance. To test whether s is a valid private credential, the adversary caninject a vote using s2 as the private credential. After the proposed encryption function is appliedduring invalid credential elimination, the adversary can test whether any submitted credential is thesquare of any authorized credential; if so, then s is valid with high probability. Araujo et al. [1] arestudying another possible replacement for PETs, based on group signatures.

20

12 ConclusionThis paper describes a complete design, implementation, and evaluation of a provably secure remotevoting system. To our knowledge, this has not been done before. Civitas provides stronger secu-rity than previously implemented voting systems. It is secure against a stronger adversary, whichcan corrupt most of the system and can try to coerce voters. Experimental results show the cost,tabulation time, and security can be practical for real-world elections.

Civitas is based on a previously known voting scheme, but the development of a secure, scalableimplementation led to new technical advances: a secure registration protocol and a scalable votestorage system. Civitas thus contributes to both the theory and practice of electronic voting. Themany cryptographic protocols required to implement Civitas (and other secure voting systems) aredistributed throughout the literature, where they are described at various levels of abstraction. Thiswork makes a modest contribution by collecting these and presenting them (in Appendix B ) in aconcrete form that other system builders could use.

Perhaps the most important contribution of this work is strong evidence that, contrary to con-ventional wisdom, secure electronic voting is possible—and even feasible. We are optimistic aboutthe future of voting systems constructed, like Civitas, using principled techniques.

AcknowledgmentsWe thank Michael George, Anil Nerode, Nathaniel Nystrom, Tom Roeder, Peter Ryan, Fred B. Schnei-der, Tyler Steele, Hakim Weatherspoon, Lantian Zheng, and Lidong Zhou for discussions about thiswork; Jed Liu, Tudor Marian, and Tom Roeder for consultation on performance experiments; andthe anonymous reviewers of CCS’07 and Oakland’08 for their comments. Preliminary versions ofthis work were presented at FEE’05 [22] and Dagstuhl Seminar 07311 [23]. We thank the partici-pants of these workshops for their feedback.

This work was supported by the Department of the Navy, Office of Naval Research, ONR GrantN00014-01-1-0968; Air Force Office of Scientific Research, Air Force Materiel Command, USAF,grant number F9550-06-0019; National Science Foundation grants 0208642, 0133302, 0430161,and CCF-0424422 (TRUST); and a grant from Intel Corporation. Michael Clarkson was supportedby a National Science Foundation Graduate Research Fellowship and an Intel PhD Fellowship; An-drew Myers was supported by an Alfred P. Sloan Research Fellowship. The views and conclusionscontained herein are those of the authors and should not be interpreted as necessarily represent-ing the official policies or endorsements, either express or implied, of these organizations or theU.S. Government. The U.S. Government is authorized to reproduce and distribute reprints for Gov-ernmental purposes notwithstanding any copyright notation thereon.

References[1] Roberto Araujo, Sebastien Foulle, and Jacques Traore. On Coercion-Resistant Schemes with

Linear Work. In Proc. of Frontiers of Electronic Voting: Dagstuhl Seminar 07311, DavidChaum, Miroslaw Kutylowski, Ronald L. Rivest, Peter Y. A. Ryan, organizers, July 2007.

[2] Association for Computing Machinery. SIG Elections. www.acm.org/sigs/elections,2007.

21

[3] Jonathan Bannet, David W. Price, Algis Rudys, Justin Singer, and Dan S. Wallach. Hack-a-Vote: Security Issues with Electronic Voting Systems. In IEEE Security & Privacy, 2(1):32–37, January 2004.

[4] Elaine Barker, William Barker, William Burr, William Polk, and Miles Smid. Recommenda-tion for Key Management. NIST, Special Publication 800-57 Part 1, March 2007.

[5] Olivier Baudron, Pierre-Alain Fouque, David Pointcheval, Guillaume Poupard, and JacquesStern. Practical Multi-Candidate Election System. In Proc. of ACM Symposium on Principlesof Distributed Computing, pages 274–283, Newport, Rhode Island, August 2001.

[6] Mihir Bellare and Phillip Rogaway. Random Oracles Are Practical: A Paradigm for DesigningEfficient Protocols. In Proc. of ACM Conference on Computer and Communications Security,pages 62–73, ACM, Fairfax, Virginia, November 1993.

[7] Josh Daniel Cohen Benaloh. Verifiable Secret-Ballot Elections. Ph.D. Thesis, Yale University,September 1987.

[8] Dan Boneh, Antoine Joux, and Phong Q. Nguyen. Why Textbook ElGamal and RSA En-cryption Are Insecure. In Proc. of International Conference on the Theory and Applicationof Cryptology and Information Security (ASIACRYPT), pages 30–43, Kyoto, Japan, December2000.

[9] Steven J. Brams and Peter C. Fishburn. Voting Procedures. In Handbook of Social Choice andWelfare, volume 1, chapter 4, Kenneth J. Arrow, Amartya K. Sen, and Kotaro Suzumura, ed.Elsevier, 2002.

[10] Felix Brandt. Efficient Cryptographic Protocol Design Based on Distributed El Gamal En-cryption. In Proc. of International Conference on Information Security and Cryptology, pages32–47, Seoul, Korea, December 2005.

[11] Brennan Center for Justice. The Machinery of Democracy: Voting System Security, Accessi-bility, Usability, and Cost. New York University, October 2006.

[12] Jan Camenisch and Markus Stadler. Efficient Group Signature Schemes for Large Groups.In Proc. of International Cryptology Conference (CRYPTO), pages 410–424, Santa Barbara,California, August 1997.

[13] Ran Canetti and Rosario Gennaro. Incoercible Multiparty Computation. In Proc. of IEEE Sym-posium on Foundations of Computer Science, pages 504–513, Burlington, Vermont, October1996.

[14] Ran Canetti, Cynthia Dwork, Moni Naor, and Rafail Ostrovsky. Deniable Encryption. In Proc.of International Cryptology Conference (CRYPTO), pages 90–104, Santa Barbara, California,August 1997.

[15] Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance. In Proc. of ACMSymposium on Operating System Design and Implementation, pages 173–186, New Orleans,Louisiana, February 1999.

[16] David Chaum. Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms. InCommunications of the ACM, 24(2):84–88, 1981.

[17] David Chaum. SureVote. www.surevote.com, International patent WO 01/55940 A1, 02August 2001, 2007.

[18] David Chaum and Torben Pryds Pedersen. Wallet Databases with Observers. In Proc. ofInternational Cryptology Conference (CRYPTO), pages 89–105, Santa Barbara, California,August 1992.

[19] David Chaum, Jonathon R. Stanton, Aleks Essex, and others. PunchScan Voting System.

22

www.punchscan.org, 2007.[20] Liming Chen and Algirdas Avizienis. N-Version Programming: A Fault Tolerance Approach

to Reliability of Software Operation. In International Symposium on Fault-Tolerant Comput-ing, 1978.

[21] Stephen Chong and Andrew C. Myers. Language-Based Information Erasure. In Proc. ofIEEE Computer Security Foundations Workshop, pages 241–254, Aix-en-Provence, France,June 2005.

[22] Michael R. Clarkson and Andrew C. Myers. Coercion-Resistant Remote Voting Using Decryp-tion Mixes. In Proc. of Workshop on Frontiers in Electronic Elections, Milan, Italy, September2005.

[23] Michael R. Clarkson, Stephen Chong, and Andrew C. Myers. Civitas: A Secure RemoteVoting System. In Proc. of Frontiers of Electronic Voting: Dagstuhl Seminar 07311, DavidChaum, Miroslaw Kutylowski, Ronald L. Rivest, Peter Y. A. Ryan, organizers, July 2007.

[24] Ronald Cramer, Matthew Franklin, Berry Schoenmakers, and Moti Yung. Multi-AuthoritySecret-Ballot Elections with Linear Work. In Proc. of International Conference on the The-ory and Applications of Cryptographic Techniques (EUROCRYPT), pages 72–83, Saragossa,Spain, May 1996.

[25] Ronald Cramer, Rosario Gennaro, and Berry Schoenmakers. A Secure and Optimally EfficientMulti-Authority Election Scheme. In Proc. of International Conference on the Theory and Ap-plications of Cryptographic Techniques (EUROCRYPT), pages 103–118, Konstanz, Germany,May 1997.

[26] Laurie Faith Cranor and Ron K. Cytron. Sensus: A Security-Conscious Electronic PollingSystem for the Internet. In Proc. of Hawaii International International Conference on Systems,pages 561–570, IEEE Computer Society, 1997.

[27] Debian Project. Debian Vote Engine (Devotee). www.debian.org/vote, 2007.[28] Stephanie Delaune, Steve Kremer, and Mark Ryan. Coercion-Resistance and Receipt-Freeness

in Electronic Voting. In Proc. of IEEE Computer Security Foundations Workshop, pages 28–42, Venice, Italy, July 2006.

[29] David L. Dill, Bruce Schneier, and Barbara Simons. Voting and Technology: Who Gets toCount Your Vote? In Communications of the ACM, 46(8):29–31, August 2003.

[30] Roger Dingledine, Nick Mathewson, and Paul F. Syverson. Tor: The Second-GenerationOnion Router. In Proc. of USENIX Security Symposium, pages 303–320, San Diego, Califor-nia, August 2004.

[31] Brandon William DuRette. Multiple Administrators for Electronic Voting. Bachelor’s Thesis,Massachusetts Institute of Technology, May 1999.

[32] David Evans and Nathanael Paul. Election Security: Perception and Reality. In IEEE Security& Privacy, 2(1):24–31, January 2004.

[33] Amos Fiat and Adi Shamir. How to Prove Yourself: Practical Solutions to Identification andSignature Problems. In Proc. of International Cryptology Conference (CRYPTO), pages 186–194, Santa Barbara, California, August 1986.

[34] Stephanie Forrest, Anil Somayaji, and David Ackley. Building Diverse Computer Systems. InProc. of IEEE Workshop on Hot Topics in Operating Systems, Cape Cod, Massachusetts, May1997.

[35] Atsushi Fujioka, Tatsuaki Okamoto, and Kazuo Ohta. A Practical Secret Voting Scheme forLarge Scale Elections. In Proc. of International Conference on the Theory and Applications

23

of Cryptographic Techniques (EUROCRYPT), pages 244–251, Balatonfured, Hungary, May1992.

[36] Jun Furukawa. Efficient and Verifiable Shuffling and Shuffle-Decryption. In IEICE Trans-actions on Fundamentals of Electronics, Communications and Computer Sciences, E88-A(1):172–188, 2005.

[37] Taher El Gamal. A Public Key Cryptosystem and a Signature Scheme Based on DiscreteLogarithms. In IEEE Transactions on Information Theory, 31(4):469–472, 1985.

[38] Juan E. Gilbert, E. Vincent Cross, II, and others. Prime III Voting System. www.primevotingsystem.com, 2007.

[39] Oded Goldreich, Silvio Micali, and Avi Wigderson. How to Play Any Mental Game Or aCompleteness Theorem for Protocols with Honest Majority. In Proc. of ACM Symposium onTheory of Computing, pages 218–229, 1987.

[40] Marcin Gomułkiewicz, Marek Klonowski, and Mirosław Kutyłowski. Rapid Mixing and Se-curity of Chaum’s Visual Electronic Voting. In Proc. of European Symposium on Research inComputer Security, pages 132–145, 2003.

[41] Mark Herschberg. Secure Electronic Voting Over the World Wide Web. Master’s Thesis,Massachusetts Institute of Technology, 1997.

[42] Martin Hirt and Kazue Sako. Efficient Receipt-Free Voting Based on Homomorphic Encryp-tion. In Proc. of International Conference on the Theory and Applications of CryptographicTechniques (EUROCRYPT), pages 539–556, Bruges, Belgium, May 2000.

[43] International Foundation for Election Systems. Getting to the CORE—A Global Survey onthe Cost of Registration and Elections. United Nations Development Program, June 2006.

[44] International Organization for Standardization. Information Technology—SecurityTechniques—Key Management—Part 3: Mechanisms Using Asymmetric Techniques.ISO/IEC 11770-3, 1999.

[45] Markus Jakobsson and Ari Juels. Mix and Match: Secure Function Evaluation Via Cipher-texts. In Proc. of International Conference on the Theory and Application of Cryptology andInformation Security (ASIACRYPT), pages 162–177, Kyoto, Japan, December 2000.

[46] Markus Jakobsson, Ari Juels, and Ronald L. Rivest. Making Mix Nets Robust for ElectronicVoting By Randomized Partial Checking. In Proc. of USENIX Security Symposium, pages339–353, San Francisco, California, August 2002.

[47] Markus Jakobsson, Kazue Sako, and Russell Impagliazzo. Designated Verifier Proofs andTheir Applications. In Proc. of International Conference on the Theory and Applications ofCryptographic Techniques (EUROCRYPT), pages 143–154, Saragossa, Spain, May 1996.

[48] David Jefferson, Aviel D. Rubin, Barbara Simons, and David Wagner. A SecurityAnalysis of the Secure Electronic Registration and Voting Experiment (SERVE). www.servesecurityreport.org/paper.pdf, January 2004.

[49] David Jefferson, Aviel D. Rubin, Barbara Simons, and David Wagner. Analyzing InternetVoting Security. In Communications of the ACM, 47(10):59–64, October 2004.

[50] Rui Joaquim and Carlos Ribeiro. CodeVoting: Protecting Against Malicious Vote Manipula-tion At the Voter’s PC. In Proc. of Frontiers of Electronic Voting: Dagstuhl Seminar 07311,David Chaum, Miroslaw Kutylowski, Ronald L. Rivest, Peter Y. A. Ryan, organizers, July2007.

[51] Rui Joaquim, Andre Zuquete, and Paulo Ferreira. REVS—A Robust Electronic Voting System.In Proc. of IADIS International Conference on e-Society, Lisbon, Portugal, June 2003.

24

[52] Ari Juels, Dario Catalano, and Markus Jakobsson. Coercion-Resistant Electronic Elections.In Proc. of Workshop on Privacy in the Electronic Society, pages 61–70, Alexandria, Virginia,November 2005.

[53] Chris Karlof, Naveen Sastry, and David Wagner. Cryptographic Voting Protocols: A SystemsPerspective. In Proc. of USENIX Security Symposium, 2005.

[54] Aggelos Kiayias, Michael Korman, and David Walluck. An Internet Voting System SupportingUser Privacy. In Proc. of Annual Computer Security Applications Conference, pages 165–174,IEEE Computer Society, Miami Beach, Florida, December 2006.

[55] Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin, and Dan S. Wallach. Analysis of anElectronic Voting System. In Proc. of IEEE Symposium on Security and Privacy, pages 27–42,Berkeley, California, May 2004.

[56] Mirosław Kutyłowski, Filip Zagorski, and others. W-Voting System. w-vote.im.pwr.wroc.pl, 2007.

[57] Ricardo Lebre, Rui Joaquim, Andre Zuquete, and Paulo Ferreira. Internet Voting: ImprovingResistance to Malicious Servers in REVS. In Proc. of IADIS International Conference onApplied Computing, Lisbon, Portugal, March 2004.

[58] Gavin Lowe. An Attack on the Needham-Schroeder Public Key Authentication Protocol. InInformation Processing Letters, 56(3):131–136, November 1995.

[59] Emmanouil Magkos, Mike Burmester, and Vassilis Chrissikopoulos. Receipt-Freeness inLarge-Scale Elections Without Untappable Channels. In Proc. of IFIP Conference on E-Commerce, E-Business, E-Government, pages 683–694, Zurich, Switzerland, October 2001.

[60] Rebecca Mercuri. Statement on Electronic Voting. www.notablesoftware.com/RMstatement.html, 2007.

[61] Andrew C. Myers. JFlow: Practical Mostly-Static Information Flow Control. In Proc. of ACMSymposium on Principles of Programming Languages, pages 228–241, San Antonio, Texas,January 1999.

[62] Andrew C. Myers and Barbara Liskov. Protecting Privacy Using the Decentralized LabelModel. In ACM Transactions on Software Engineering and Methodology, 9(4):410–442, Oc-tober 2000.

[63] Andrew C. Myers, Lantian Zheng, Steve Zdancewic, Stephen Chong, and Nathaniel Nystrom.Jif: Java Information Flow. www.cs.cornell.edu/jif, Software Release, July 2001.

[64] NIST. Digital Signature Standard (DSS). January 2000. FIPS 186-2.[65] C. Andrew Neff. Verifiable Mixing (Shuffling) of ElGamal Pairs. www.votehere.org/vhti/

documentation/egshuf-2.0.3638.pdf, April 2004.[66] Miyako Ohkubo, Fumiaki Miura, Masayuki Abe, Atsushi Fujioka, and Tatsuaki Okamoto. An

Improvement on a Practical Secret Voting Scheme. In Proc. of Information Security Workshop,pages 225–234, Kuala Lumpur, Malaysia, November 1999.

[67] Tatsuaki Okamoto. Receipt-Free Electronic Voting Schemes for Large Scale Elections. InProc. of Security Protocols Workshop, pages 25–35, Paris, France, April 1997.

[68] R. A. Peters. A Secure Bulletin Board. Master’s Thesis, Technische Universiteit Eindhoven,June 2005.

[69] Aviel D. Rubin. Security Considerations for Remote Electronic Voting. In Communicationsof the ACM, 45(12):39–44, December 2002.

[70] Kazue Sako and Joe Kilian. Secure Voting Using Partially Compatible Homomorphisms.In Proc. of International Cryptology Conference (CRYPTO), pages 411–424, Santa Barbara,

25

California, August 1994.[71] Kazue Sako and Joe Kilian. Receipt-Free Mix-Type Voting Scheme—A Practical Solution to

the Implementation of a Voting Booth. In Proc. of International Conference on the Theoryand Applications of Cryptographic Techniques (EUROCRYPT), pages 393–403, Saint Malo,France, May 1995.

[72] Fred B. Schneider and Lidong Zhou. Distributed Trust: Supporting Fault-Tolerance andAttack-Tolerance. Cornell University, Technical Report 2004-1924, January 2004.

[73] Steve Schneider, James Heather, Peter Ryan, and others. Pret a Voter Voting System. www.pretavoter.com, 2007.

[74] Claus-Peter Schnorr. Efficient Signature Generation By Smart Cards. In Journal of Cryptology,4(3):161–174, 1991.

[75] Claus-Peter Schnorr and Markus Jakobsson. Security of Signed ElGamal Encryption. In Proc.of International Conference on the Theory and Application of Cryptology and InformationSecurity (ASIACRYPT), pages 73–89, Kyoto, Japan, December 2000.

[76] Alan T. Sherman. University Voting Systems Competition. vocomp.org, David Chaum,concept creator, 2006.

[77] Anna M. Shubina and Sean W. Smith. Design and Prototype of a Coercion-Resistant, VoterVerifiable Electronic Voting System. In Proc. of Conference on Privacy, Security and Trust,pages 29–39, Fredericton, New Brunswick, Canada, October 2004.

[78] Warren D. Smith. New Cryptographic Election Protocol with Best-Known Theoretical Prop-erties. In Proc. of Workshop on Frontiers in Electronic Elections, Milan, Italy, September2005.

[79] Sun Microsystems. Sun Grid Compute Utility: Users Guide. March 2007.[80] Melanie Volkamer, Ammar Alkassar, Ahmad-Reza Sadeghi, and Stefan Schulz. Enabling the

Application of Open Systems Like PCs for Online Voting. In Proc. of Workshop on Frontiersin Electronic Elections, 2006.

[81] Dennis Volpano and Geoffrey Smith. A Type-Based Approach to Program Security. In Proc.of International Joint Conference on the Theory and Practice of Software Development, pages607–621, Lille, France, April 1997.

[82] VoteHere, Inc. Independent Audit Solutions for Validation and Verification of Election Results(Corporate Website). votehere.com, C. Andrew Neff, Chief Scientist, 1998.

[83] David Wagner and Matthew Bishop. Voting Systems Top-to-Bottom Review. www.sos.ca.gov/elections/elections_vsr.htm, 2007.

[84] Brian White, Jay Lepreau, Leigh Stoller, Robert Ricci, Shashi Guruprasad, Mac Newbold,Mike Hibler, Chad Barb, and Abhijeet Joglekar. An Integrated Experimental Environment forDistributed Systems and Networks. In Proc. of ACM Symposium on Operating System Designand Implementation, pages 255–270, Boston, Massachusetts, December 2002.

[85] Andre Zuquete, Carlos Costa, and Miguel Romao. An Intrusion-Tolerant E-Voting ClientSystem. In Proc. of Workshop on Recent Advances in Intrusion-Tolerant Systems, pages 23–27, Lisbon, Portugal, March 2007.

26

A Security of RegistrationThe JCJ scheme assumed a registrar R, which was trusted to generate and to maintain the con-fidentiality of private credentials. Civitas distributes this functionality and trust over a set REGof registration tellers. We must show that REG securely implements R. In particular, the Civitasregistration scheme is coercion-resistant if:

1. The private credentials generated by REG are uniformly distributed, and

2. Fake credentials are indistinguishable from valid credentials.

(These requirements were extracted from steps 2 and 5 of the JCJ simulation proof of coercionresistance.)

Assume that REG consists of only two tellers, RTH and RTC . Teller RTH is an honest teller,whereas RTC is corrupted by the adversary. This is without loss of generality, since Trust Assump-tion 2 assumes a single honest teller, and the actions of multiple corrupted tellers can be simulatedby a single corrupt teller.

Let sC be the private credential share generated for a voter by RTC , and similarly for sH .Then the voter’s private credential is s = sH · sC . Also, recall that shares are chosen from spaceM = QRp. The following lemma states that REG does generate uniformly distributed privatecredentials.

Lemma 1. ∀sC . {sH ←M : sH · sC} = {s←M : s}

Proof. Since (M, ·) is a group, there is a unique sH = s · s−1C .

Toward proving the indistinguishability of fake and valid credentials, let (Gen, Enc, Dec) bean indistinguishable public-key encryption scheme. Let Enc(m;K; r) denote the encryption ofmessage m with public key K using random coins r. As before, letM be the message space of thescheme. Let O be the space of random coins, and let ≈ denote computational indistinguishability.

Let (DVRP, DVRP) be a designated-verifier reencryption proof (DVRP) [42]. This is a proofthat either the prover knows the private key k corresponding to the public key K of the verifier,or that two ciphertexts c and c′ decrypt to the same plaintext. A valid DVRP, constructed asDVRP(K, c, c′;w), is produced by a prover using a witness w to prove c′ is a reencryption of c.A fake DVRP, constructed as DVRP(K, c, c′; k), is produced by a verifier, and proves knowledge ofk. Intuitively, the key security property is that a valid proof is indistinguishable from a fake proof;formal definitions can be found in Jakobsson et al. [47].

To distribute a credential share s to voter V , an honest registration teller sends

(s, r′,DVRP(KV , S, S′;w))

to the voter, where S = Enc(s;KTT; r) is the public share posted on the bulletin board, S′ =Enc(s;KTT; r′), and witness w is a function of r and r′. This establishes to the voter that S′

is an encryption of s, and S′ is a reencryption of S. The security of this registration scheme isfundamentally based on the ability, resulting from the DVRP, of voters to lie about the credentialshare. This is described by the following experiment:

27

RegExp(n, b) =KTT, kTT ← Gen(1n);KV , kV ← Gen(1n);s←M; r ← O; r′ ← O;S ← Enc(s;KTT; r); S′ ← Enc(s;KTT; r′);P ← DVRP(KV , S, S

′;w);s←M; r ← O;S ← Enc(s; KTT; r);P ← DVRP(KV , S, S; kV );if b then

output (KTT,KV , S, s, r′, P )

elseoutput (KTT,KV , S, s, r, P ).

If b = 1, the voter tells the truth about his share, otherwise he lies and fakes a DVRP. Thefollowing lemma says that, to an adversary, these two cases are indistinguishable.

Lemma 2. {RegExp(n, 0)}n∈N ≈ {RegExp(n, 1)}n∈N

Proof. (A sketch of a simple hybrid argument.) Define three hybrids:

H0 = {KTT,KV , S, s, r′, P} = RegExp(n, 0)

H1 = {KTT,KV , S, s, r′, P ′}

H2 = {KTT,KV , S, s, r, P} = RegExp(n, 1),

where P ′ = DVRP(KV , S, S′; kV ). By the definition of a designated-verifier proof, H0 ≈ H1.

To show that H1 ≈ H2, assume for contradiction that there exists a distinguisher D that hassome non-negligible advantage in distinguishing H1 and H2. Using D, we can construct a machineA that breaks the indistinguishability of the encryption scheme, as follows. Machine A is givenKTT, challengesm0 andm1, and a ciphertext c that encrypts one of the challenges. It then constructsinstances of H1 and H2, where S = c, s = s = m0, and other values are sampled randomly, andasks D to distinguish them. Note that A can construct a fake DVRP because it generates the keypair (KV , kV ).

By the polynomial transitivity of indistinguishability, we conclude H0 ≈ H2.

Let Cred be the information obtained by the adversary when the voter presents a valid credentialand FakeCred be the information from a fake credential, where

Cred = {KTT,KV , SH , sH , r′H , PH , SC , sC , r

′C , PC}

FakeCred = {KTT,KV , SH , sH , rH , PH , SC , sC , r′C , PC}.

Indistinguishability of valid and fake credentials, and the security of REG, then follows, as the votercan lie about share sH .

Corollary 1. Cred ≈ FakeCred

Proof. Immediate from Lemma 2.

28

Theorem 1. Registration is coercion-resistant.

Proof. Immediate from Lemma 1 and Corollary 1.

29

B Protocol SpecificationIn the following protocols, El Gamal cryptosystem parameters (p, q, g) are implicitly used as inputto all protocols (except parameter generation itself). A hash function, denoted hash , is used in someprotocols. In zero-knowledge proofs, hash is assumed to implement a random oracle; elsewhere, itmust be collision-resistant and one-way. Let O be a space of random bits of appropriate length ineach context that it is used.

B.1 Encryption schemeCivitas implements an El Gamal encryption scheme over a multiplicative group of integers moduloa prime p, where p = 2kq+1 and q is also prime. The message spaceM of this scheme is the orderq subgroup of Z∗p. The plaintext space is Zq. Plaintexts must be encoded into the message spacebecause El Gamal encryption leaks the (extended) Legendre symbol of the plaintext [8].

The algorithms below describe standard, non-malleable, and distributed constructions of El Ga-mal encryption. An algorithm for distributed encryption is omitted because it is identical to thestandard algorithm. The standard construction is due to El Gamal [37]; non-malleable, Schnorr andJakobsson [75]; and distributed, Brandt [10].

ALGORITHM: El Gamal Parameter Generation

Due to: Our adaptation of the DSA parameter generation algorithm [64]Input: Security parameters l and kOutput: Parameters (p, q, g), where |p| = l and |q| = k

1. Select a random k-bit prime q

2. Select a random l-bit number p. Round p − 1 down to a multiple of 2q by setting p equalto p − (p mod 2q) + 1. Unless p is prime and |p| = l, repeat. After 2log2(l)+2 tries, startover by picking a new q.

3. h← [1..p− 1]; g = h(p−1)/q mod p; repeat until g 6≡ 1 (mod p) and g 6≡ −1 (mod p)

4. Output (p, q, g)

ALGORITHM: El Gamal Key Generation

Input: El Gamal parameters (p, q, g)Output: Public key y, private key x

1. x← Z∗q

2. y = gx mod p

3. Output (y, x)

30

ALGORITHM: Encode

Input: m ∈ Z∗qOutput: M ∈M

1. M = gm mod p

ALGORITHM: El Gamal Encryption

Input: Public key y, message m ∈ Z∗qOutput: Enc(m; y)

1. M = Encode(m)

2. r ← Z∗q

3. Output (gr mod p,Myr mod p)

ALGORITHM: El Gamal Reencryption

Input: Public key y, ciphertext c = (a, b)Output: Reenc(c)

1. r ← Z∗q

2. Output (agr mod p, byr mod p)

ALGORITHM: El Gamal Decryption

Input: Private key x, ciphertext c = (a, b)Output: Dec(c;x)

1. M = bax mod p

2. Output M . Note that M has not been decoded to an element in Z∗q . Doing so is apparentlyan open problem, unless p is a safe prime (i.e., k = 1)—in which case, the Legendresymbol can be used for encoding and decoding.

31

ALGORITHM: Non-Malleable El Gamal Encryption

Input: Public key y, message m ∈ Z∗qOutput: NMEnc(m; y)

1. r, s← Z∗q

2. (a, b) = Enc(m; y; r)

3. c = hash(gs mod p, a, b) mod q

4. d = (s+ cr) mod q

5. Output (a, b, c, d)

ALGORITHM: Non-Malleable El Gamal Decryption

Input: Private key x, ciphertext e = (a, b, c, d)Output: NMDec(e;x)

1. V = hash(gda−c mod p, a, b) mod q

2. Abort if V 6= c

3. Output Dec((a, b);x)

ALGORITHM: Commitment

Input: Message mOutput: Commit(m)

1. Output hash(m)

32

PROTOCOL: Distributed El Gamal Key Generation

Public input: Parameters (p, q, g)Output: Public key Y , public key shares yi, private key shares xi

1. Si: xi ← Z∗q ; yi = gxi mod p

2. Si: Publish Commit(yi)

3. Si: Barrier: wait until all commitments are available

4. Si: Publish yi and proof KnowDlog(g, yi)

5. Si: Verify all commitments and proofs

6. Y =∏i yi mod p is the distributed public key

7. X =∑

i xi mod q is the distributed private key

PROTOCOL: Distributed El Gamal Decryption

Public input: Ciphertext c = (a, b), public key shares yiPrivate input (Si): Private key share xiOutput: DistDec(c;X)

1. Si: Publish decryption share ai = axi mod p and proof EqDlogs(g, a, yi, ai)

2. Si: Verify all proofs

3. A =∏i ai mod p

4. M = bA mod p

5. Output M . See above note on El Gamal Decryption.

33

B.2 Zero-knowledge proofsPROTOCOL: KnowDlog

Due to: Schnorr [74]Principals: Prover P and Verifier VPublic input: h, vPrivate input (P ): x s.t. v ≡ hx (mod p)

1. P : Compute:

• z ← Zq• a = hz mod p

• c = hash(v, a) mod q

• r = (z + cx) mod q

2. P → V : a, c, r

3. V : Verify hr ≡ avc (mod p).

PROTOCOL: EqDlogs

Due to: Chaum and Pedersen [18]Principals: Prover P and Verifier VPublic input: f, h, v, wPrivate input (P ): x s.t. v ≡ fx (mod p) and w ≡ hx (mod p)

1. P : Compute:

• z ← Zq• a = fz mod p

• b = hz mod p

• c = hash(v, w, a, b) mod q

• r = (z + cx) mod q

2. P → V : a, b, c, r

3. V : Verify f r ≡ avc (mod p) and hr ≡ bwc (mod p).

34

PROTOCOL: DVRP

Due to: Hirt and Sako [42]Principals: Prover P and Verifier VPublic input: Public key hV of V

El Gamal ciphertexts e = (x, y) and e′ = (x′, y′)Public key h under which e and e′ are encryptedLet E = (e, e′)

Private input (P ): ζ s.t. x′ ≡ xgζ (mod p) and y′ ≡ yhζ (mod p)Output: DVRP(hV , e, e′; ζ)

1. P : Compute:

• d,w, r ← Zq• a = gd mod p

• b = hd mod p

• s = gw(hV )r mod p

• c = hash(E, a, b, s) mod q

• u = (d+ ζ(c+ w)) mod q

2. P → V : c, w, r, u

3. V : Compute:

• a′ = gu/(x′/x)c+w mod p

• b′ = hu/(y′/y)c+w mod p

• s′ = gw(hV )r mod p

• c′ = hash(E, a′, b′, s′) mod q

4. V : Verify c = c′

35

PROTOCOL: FakeDVRP

Due to: Hirt and Sako [42]Principals: Prover PPublic input: Public key hP of P

El Gamal ciphertexts e = (x, y) and e = (x, y)Public key h under which e and e are encryptedLet E = (e, e)

Private input (P ): Private key zP of POutput: DVRP(hP , e, e; zP )

1. P : Compute:

• α, β, u← Zq• a = gu/(x/x)α mod p

• b = hu/(y/y)α mod p

• s = gβ mod p

• c = hash(E, a, b, s) mod q

• w = (α− c) mod q

• r = (β − w)/(zP ) mod q

2. P → V : c, w, r, u

3. V : c, w, r, u will verify as a DVRP, as above.

36

PROTOCOL: ReencPf

Due to: Hirt and Sako [42]Principals: Prover P and Verifier VPublic input: L ∈ N

C = {(ui, vi) | 1 ≤ i ≤ L}c = (u, v)

Private input (P ): t ∈ [1..L] and r ∈ Zq s.t. (u, v) = (grut mod p, yrvt mod p)

1. P : Compute:

• di, ri ← Zq, i ∈ [1..L]

• {(ai, bi) | i ∈ [1..L]}, where:

ai = (uiu )digri mod p

bi = (viv )diyri mod p

• E = u, v, u1, . . . , uL, v1, . . . , vL

• c = hash(E, a1, . . . , aL, b1, . . . , bL) mod q

• w = (−rdt + rt) mod q

• D = c− (∑

i∈[1..t−1,t+1..L] di) mod q

• R = (w + rd′t) mod q

• dvi ={di : i 6= tD : i = t

• rvi ={ri : i 6= tR : i = t

2. P → V : (dv1, . . . , dvL, r

v1 , . . . , r

vL)

3. V : Compute:

• {(avi , bvi ) | i ∈ [1..L]}, where:

avi = (uiu )d

vi gr

vi mod p

bvi = (viv )d

vi yr

vi mod p

• c′ = hash(E, av1, . . . , avL, b

v1, . . . , b

vL) mod q

• D′ =∑

i∈[1..L] dvi mod q

4. V : Verify c′ = D′

37

PROTOCOL: VotePf

Due to: Camenisch and Stadler [12]Principals: Prover P and Verifier VPublic input: Encrypted credential (a1, b1)

Encrypted choice (a2, b2)Vote context ctx (election identifier, etc.)Let E = (g, a1, b1, a2, b2, ctx )

Private input (P ): α1, α2 s.t. ai ≡ gαi (mod p)

1. P : Compute:

• r1, r2 ← Zq• c = hash(E, gr1 mod p, gr2 mod p) mod q

• s1 = (r1 − cα1) mod q

• s2 = (r2 − cα2) mod q

2. P → V : c, s1, s2

3. V : Compute c′ = hash(E, gs1ac1, gs2ac2) mod q

4. V : Verify c = c′

38

B.3 Main protocolsPROTOCOL: Plaintext Equivalence Test (PET)

Due to: Jakobsson and Juels [45]Principals: Tabulation tellers TTiPublic input: cj = Enc(mj ;KTT) = (aj , bj) for j ∈ {1, 2}Private input (TTi): Private key share xi

Let R = (d, e) = (a1/a2, b1/b2)Output: If m1 = m2 then 1 else 0

1. TTi: zi ← Z∗q ; (di, ei) = (dzi , ezi)

2. TTi: Publish Commit(di, ei)

3. TTi: Barrier: wait until all commitments are available

4. TTi: Publish (di, ei) and proof EqDlogs(d, e, di, ei)

5. TTi: Verify all commitments and proofs

6. Let c′ = (∏i di,

∏i ei)

7. All TT: Compute m′ = DistDec(c′) using private key shares

8. If m′ = 1 then output 1 else output 0

ALGORITHM: Mix

Due to: Jakobsson, Juels, and Rivest [46]Input: List L of ciphertexts [c1, . . . , cm],

verification direction dir ∈ {in, out}Output: RPC reencryption mix of L

1. π ← Space of permutations over m elements

2. If dir = in then p = π else p = π−1

3. r1 ← Z∗q . . . ; rm ← Z∗q ; w1 ← O; . . . ; wm ← O

4. LR = [Reenc(cπ(1); r1), . . . ,Reenc(cπ(m); rm)]

5. LC = [Commit(w1, p(1)), . . . ,Commit(wm, p(m))]

6. Output LR, LC

39

PROTOCOL: MixNet

Due to: Jakobsson, Juels, and Rivest [46]Principals: Tabulation tellers TT1, . . . ,TTnPublic input: List L of ciphertexts [c1, . . . , cm]Output: Anonymization of L

1. For i = 1 to n, sequentially:

(a) Let Mixi,j denote the jth mix performed by the ith teller.Define Mix0,2.LR = L.

(b) Let L1 = Mixi−1,2.LR

(c) TTi : Publish Mixi,1 = Mix(L1, out)

(d) Let L2 = Mixi,1.LR

(e) TTi : Publish Mixi,2 = Mix(L2, in)

(f) TTi : qi ← O; publish Commit(qi)

2. All TTi: Publish qi; verify all other tellers’ commitments

3. Let Q = hash(q1, . . . , qn)

4. All TTi:

(a) Let Qi = hash(Q, i)

(b) For j in [1..m], publish rj , wj , and p(j) from Mixi,1+Qi[j]

(c) Verify all commitments (w and p) and reencryptions (r) from all other tellers, i.e.:

i. Verify wj and p(j) against Mixi,1+Qi[j].LC [j]ii. If Qi[j] = 0 then verify Reenc(Mixi−1,2.LR[p(j)]; rj) = Mixi,1.LR[j], else if

Qi[j] = 1 then verify Reenc(Mixi,1.LR[j]; rj) = Mixi,2.LR[p(j)]

5. Output Mixn,2.LR

40

PROTOCOL: Register

Due to: Needham-Schroeder-Lowe [58] (steps 1–8)Our own adaptation of ideas from [25, 42, 52] (steps 9–11)

Principals: Registration teller RTi and Voter VPublic input: KTT, KRTi ,

voter’s El Gamal public key KVE, voter’s RSA public key KVR

,election identifier eid , voter identifier vid , teller identifier rid ,public credential Si = EncEG(si;KTT; r)

Private input (RTi): Private credential si and encryption factor r ∈ Z∗qPrivate input (V ): kVR

1. V : NV ← N

2. V → RTi: EncRSA(eid , vid , NV ;KRTi)

3. RTi: Verify that vid is a voter in eid and lookup credential si

4. RTi: NR ← N ; k ← GenAES(1l)

5. RTi → V : EncRSA(rid , NR, NV , k;KVR)

6. V : Verify rid and NV

7. V → RTi: NR

8. RTi: Verify NR

9. RTi: r′ ← Z∗q ; w = r′ − r; S′i = EncEG(si;KTT; r′)

10. RTi → V : EncAES(si, r′,DVRP(KVE, Si, S

′i;w)); k)

11. V : Verify S′i = EncEG(si;KTT; r′), and verify DVRP against Si from bulletin board

To register, voter V completes protocol Register with each registration teller RTi. After con-structing a complete private credential s =

∏i si, the voter may erase all shares si, DVRPs, and

session key k.In protocol Register, N is the space of nonces and l is the security parameter for AES. As

discussed in Section 5, the use of RSA could be replaced by another cryptosystem, but the voter’sEl Gamal key is necessary for the DVRP. The use of AES could similarly be replaced by anothercryptosystem, perhaps even a construction of deniable encryption [14].

The authentication protocol used in steps 1–8 of Register is not strictly an implementation ofNeedham-Schroeder-Lowe because step 7 is not encrypted under KRTi . This is admissible becausenonce NR is not used to construct the session key k. In this respect, the authentication protocol issimilar to ISO/IEC 11770-3 Key Transport Mechanism 6 [44].

41

PROTOCOL: Vote

Due to: Juels, Catalano, and Jakobsson [52]Principals: Voter V , ballot boxesPublic input: KTT, vote context ctx ,

well-known candidate ciphertext list C = (c1, . . . , cL)Private input (V ): Private credential s and candidate choice ct for some t

1. V : rs ← Z∗q ; es = Enc(s;KTT; rs)

2. V : rv ← Z∗q ; ev = Reenc(ct;KTT; rv)

3. V : vote = (es, ev ,VotePf(es, et , ctx , rs, rv),ReencPf(C, ev , t, rv))

4. V → ballot boxes: vote

42

PROTOCOL: Tabulate

Due to: Juels, Catalano, and Jakobsson [52]Principals: Tabulation tellers TT1, . . . ,TTn, Bulletin board ABB

Ballot boxes VBB1, . . . ,VBBm, Supervisor SupPublic input: KTT, contents of ABBPrivate input (TTi): Private key share xi of KTTOutput: Election tally

1. All VBB i: Post Commit(received votes) on ABB

2. Sup: Post endorsement of all received VBB commitments

3. All TTi: Proceed sequentially through the following phases. Each phase has a list (e.g.,A, B, etc.) as output. In each phase that uses such a list as input, verify that all othertellers are using the same list. Use ABB as a public broadcast channel for any subprotocolthat requires publication of a value; all posts to ABB must (as usual) be signed, and allmessages retrieved from it should have their signatures verified.

Retrieve Votes. Retrieve all votes from all endorsed VBBs. Verify the VBB commit-ments. Let the list of votes be A.

Check Proofs. Verify all VotePfs and ReencPfs in retrieved votes. Eliminate any voteswith an invalid proof. Let the resulting list be B.

Duplicate Elimination. Run PET(si, sj) for all 1 ≤ i < j ≤ |B|, where sx is the en-crypted credential in vote B[x]. Eliminate any votes for which the PET returns 1according to a revoting policy; let the remaining votes be C.

Mix Votes. Run MixNet(C) and let the anonymized vote list be D.

Mix Credentials. Retrieve all credentials from ABB and let this list be E. RunMixNet(E) and let the anonymized credential list be F .

Invalid Elimination. Run PET(si, tj) for all 1 ≤ i ≤ |F | and 1 ≤ j ≤ |D|, wheresi = F [i] and tj = D[j]. Eliminate any votes (from D) for which the PET returns 0.Let the remaining votes be G.

Decrypt. Run DistDec on all encrypted choices in G. Output the decryptions as H , thevotes to be tallied.

Tally. Compute tally of H using an election method specified on ABB by Sup. Verifytally from all other tellers.

4. Sup: Endorse tally

43