Roenne, Peter

Open Repository and Bibliography - Luxembourg

JCJ with Improved Verifiability GuaranteesPeter Browne RønneSnT, University of Luxembourg, Luxembourg City, Luxembourgpeter.roenne@uni.luAbstract. Using an additional zero-knowledge proof we improve theverifiability guarantees for the JCJ e-voting protocol [4], meaning thatneither the Registration nor the Tally Tellers can collude to break veri-fiability.1 IntroductionIn their seminal paper Juels, Catalano and Jakobsson [4] investigated pos-sible coercion attacks in e-voting and suggested a coercion-resistant protocol.This protocol was later implemented as Civitas [3] with several specifications,in particular for the registration procedure. Many papers have investigated thesecurity properties of this protocol and several modifications and alternativeshave been suggested, see e.g. [5] for an overview. The scheme is in its core quitesimple: The voters have secret credentials provided to them by a set of Registra-tion Tellers. When casting a ballot, the voter append her encrypted credential.A coerced voter can simply provide the coercer with a fake credential. Ballotscontaining invalid credentials are discarded in the tally by the use of plaintextequivalence tests done by a (threshold) set of Tally Tellers.One problem of JCJ/Civitas is that it has verifiability trust in the Registra-tion and Tally Tellers. If all the Registration Tellers collude, or a threshold setof the Tally Tellers, they know the credentials being used by the voters and cancast valid ballots on behalf of any voter. Depending on the verifiability defini-tion, JCJ thus does not satisfy eligibility verifiability, see e.g. [8]. In JCJ this isespecially troublesome since the adversary can also use this to change the votesof honest voters, e.g. if the update policy is last vote counts, the adversary willcast his choice as late as possible overruling the already cast honest vote.1 Thisdoes not invalidate the security promises of Civitas which assumes no such col-lusion of Tellers. However this could, arguably should, be worrisome to a voter,1 This might be detected by an alert voter since JCJ/Civitas chooses to perform theweeding of votes before mixing (which in turn might be troublesome in dynamiccoercion scenarios). In general, the percentage of voters actually doing such secu-rity checks are generally low, and even if a voter reports such an event it would bedisputable since the voter could have cast the extra votes herself. A robust blamingseems to endanger coercion-resistance and is necessary in order to avoid voters ma-liciously denouncing a valid election after the tally has been announced. Thus it isbetter to prevent this situation from happening at all.who does not know if the election has been manipulated by colluding Tellers orperhaps a hacker capable of attacking a few central security points.In this note we remove the verifiability trust in the Tellers, completely withinthe setup of JCJ/Civitas, and with the mild price of a longer zero-knowledgeproof for the vote casting part and a simple change in the registration procedure.The idea is very simple, Civitas assumes (as also suggested in JCJ) that eachvoter has a designated verifier key. We let the credential depend on this key suchthat only the voter knows the discrete logarithm of the credential. Ballots arethen cast with a proof of knowledge of this discrete logarithm. Now, even if theTellers collude, they can get to know the credentials, but under assumption ofhardness of the discrete logarithm problem they cannot use this to cast a validvote. To our knowledge this idea has not been reported earlier.2 Protocol StructureTo keep this note short we will assume that the reader is familiar with Civitas[3] and only display the differences. The main participants are the voters, Vi, theRegistration Tellers, RTj , and the Tally Tellers, TTk. The cryptography is basedon a DDH secure group of prime order q and generator g. Let enc(v;KTT) denoteElGamal encryption in this group and KTT be the (threshold) public key of theTally Tellers. We also assume that the voters are provided with an infrastructureof designated verifier keys dvki = gxi .2.1 RegistrationThe registration is quite similar to Civitas. For each eligible voter Vi, eachRegistration Teller RTj picks randomly cij ∈ Zq and publishes enc(gcij ;KTT)on the Bulletin Board in a row marked for voter Vi. From RTj voter Vi getscij and a zero-knowledge proof designated to dvki of correct encryption of gcij .For each voter the ciphertexts of the credential shares are multiplied togetherand further multiplied with enc(dvki;KTT) encrypted with trivial randomness.By the homomorphic property of ElGamal this gives an encryption of the votercredential Ci = gci := g∑j cij+xi . The difference to Civitas is that the voter getscij instead of gcij and the extra multiplication with dvki (or some public key ofthe voter).22 We have here followed Civitas closely, but we could also construct the keys gxi duringthe registration interactively. The important part is that the registration authoritiesdo not know xi and the voter does, as in a designated verifier key infrastructure.One can also use erasure of data at the end of registration as is suggested in JCJas an alternative to designated verifier proofs. In both cases an interactive proof ofknowledge of xi should be given during registration where we anyway assume nocoercion (another possibility is to keep the term gxi under encryption and split foreach Teller and the proofs changed accordingly). This is in order to stop a coercerfrom determining gxi before registration without divulging the secret key xi to thevoter, which in turn could create receipts and also allow forced abstention attacks.If the voter is coerced, she chooses at random an alternative value c′i ∈ Zqand shows gc′i as her credential to the coercer. The proofs can be faked with hersecret designated verifier key and this key could even be revealed to the coercer,at least after registration.2.2 Vote CastingLike in JCJ/Civitas a ballot is cast via an anonymous channel to the BulletinBoard. Given a credential C and a vote choice v, the ballot has the form( enc(C;KTT), enc(v;KTT), pi1, pi2, pi3 ) .Here pi1, pi2, pi3 are non-interactive zero-knowledge proofs (NIZKPs). Just like inCivitas, pi1 is a proof that the ciphertext for the vote is well-formed, and pi2 is aproof that C and v are simultaneously known which is done by demonstratingknowledge of the random coins used in the encryptions. This proof prevents theballot from being malleable. The proof pi3 is our novel part and is a proof ofknowledge of the discrete logarithm of the encrypted credential. To specify theproof let enc(C;KTT) := (a, b). The proof is now done by choosing a random sand publishingas, bs, Cs,DLK(as, a),DLE(as, a, bs, b),DLK(Cs, g),DLE(as, g, bs/Cs,KTT)where DLK(a, g) is a NIZKP of knowledge of the discrete logarithm of a relativeto g and DLE(a, g, b, g′) is a NIZKP of equality of the discrete logarithm of a andb with respect to generators g and g′. These are efficiently implemented by usingthe Fiat-Shamir transformation on Schnorr [7] and Chaum-Pedersen proofs [2].The first part of pi3 shows that we lift a, b to the same known power and thenwe show that Cs is the plaintext of this encryption, and finally that we know itsdiscrete logarithm. Since s is known, this shows that we know logg C. This givessoundness. Zero-knowledge follows from the employed NIZKPs and DDH for theextra elements, given that the adversary does not know the randomness in theencryption and the secret key of KTT, in which case he would anyway know C.Full proofs are postponed for a long version of this note.To avoid having malleability in the proofs we include both encryptions in thehashes of the Fiat-Shamir heuristic, see also [1]. If this is also done for pi1, wecan drop the proof pi2 and in this case the extra overhead compared to Civitasis just 3 hashes and 7 exponentiations.Finally, the tally can be done like in JCJ/Civitas.3 Security & CommentsWe see that it is no longer possible to cast valid ballots unless you know thediscrete logarithm of the credential. The Registration Tellers do not know thiseven if they are all colluding, unless they somehow know the secret key of dvki,in which case they anyway could attack verifiability during registration. TheTally Tellers, if colluding, could decrypt the credentials, but do not know thediscrete logarithms. Such misbehavior can now give rise to privacy or possiblycoercion attacks, but no longer endangers verifiability. We emphasize that thisscheme does not improve on coercion-resistance, but only the verifiability guar-antees, and it has the same assumptions as JCJ/Civitas for coercion-resistance.In JCJ this is done by assuming that the registration phase proceeds withoutany corruption, and will also require that the two set of tellers are not colluding,see further [4].Note that more user-friendly versions of the protocol e.g. using hardware withpin-codes [6,5] are still possible if adapted. In the future it would be importantto examine the security of the protocol in detail, cast the cryptography in thesetting of bilinear maps to remove the random oracle assumption, and furtherdevelop the protocol e.g. using secret registration (towards the Tellers) for betterand everlasting privacy.Acknowledgements. We would like to thank Peter Y.A. Ryan, Vincenzo Iovinoand Steve Kremer for discussions, and the reviewers for comments and sugges-tions. Further, Peter B. Rønne is supported by the INTER-Sequoia project fromFonds National de la Recherche, Luxembourg, which is joint with the ANRproject SEQUOIA ANR-14-CE28-0030-01.References1. David Bernhard, Olivier Pereira, and Bogdan Warinschi. How not to prove yourself:Pitfalls of the fiat-shamir heuristic and applications to helios. In Xiaoyun Wang andKazue Sako, editors, Advances in Cryptology - ASIACRYPT 2012 - 18th Interna-tional Conference on the Theory and Application of Cryptology and InformationSecurity, Beijing, China, December 2-6, 2012. Proceedings, volume 7658 of LectureNotes in Computer Science, pages 626–643. Springer, 2012.2. David Chaum and Torben P. Pedersen. Wallet databases with observers. InErnest F. Brickell, editor, Advances in Cryptology - CRYPTO ’92, 12th AnnualInternational Cryptology Conference, Santa Barbara, California, USA, August 16-20, 1992, Proceedings, volume 740 of Lecture Notes in Computer Science, pages89–105. Springer, 1992.3. Michael R. Clarkson, Stephen Chong, and Andrew C. Myers. Civitas: A securevoting system. In In IEEE Symposium on Security and Privacy, 2008.4. Ari Juels, Dario Catalano, and Markus Jakobsson. Coercion-resistant electronicelections. In Proceedings of the 2005 ACM Workshop on Privacy in the ElectronicSociety, WPES 2005, Alexandria, VA, USA, November 7, 2005, pages 61–70, 2005.5. Stephan Neumann, Christian Feier, Melanie Volkamer, and Reto E. Koenig. To-wards A practical JCJ / civitas implementation. IACR Cryptology ePrint Archive,2013:464, 2013.6. Stephan Neumann and Melanie Volkamer. Civitas and the real world: Problems andsolutions from a practical point of view. In Seventh International Conference onAvailability, Reliability and Security, Prague, ARES 2012, Czech Republic, August20-24, 2012, pages 180–185. IEEE Computer Society, 2012.7. Claus-Peter Schnorr. Efficient signature generation by smart cards. J. Cryptology,4(3):161–174, 1991.8. Ben Smyth, Steven Frink, and Michael R. Clarkson. Computational election ver-ifiability: Definitions and an analysis of helios and JCJ. IACR Cryptology ePrintArchive, 2015:233, 2015.

JCJ with Improved Verifiability Guarantees

http://orbilu.uni.lu/bitstream/10993/29212/1/Civitas-VFinal.pdf

JCJ with Improved Verifiability Guarantees

Abstract

Similar works

Full text

Available Versions

Open Repository and Bibliography - Luxembourg