Selene: Voting with Transparent Verifiability and

Coercion Mitigation

Voting’16 26 Feb 2016 1

Peter Y A RyanVincenzo Iovino and Peter Roenne

Université du Luxembourg

Outline

• End-To-End verifiability

• Outline of Selene I

• The sting in the tail-Selene II

• Discussion

Why “Selene”?

• Greek god of the moon.

• A pale reflection of Helios.

E2E Verifiability

• Goal: voters can confirm that their vote is accurately counted, without introducing coercion threats.

• Typically, voters get a “protected receipt”, i.e. an encrypted/encoded version of their vote.

• Cast receipts are posted to a secure web bulletin board (WBB). Voters can verify that their receipt is correctly posted.

• A (universally) verifiable, anonymising tabulation is performed on the posted receipts.

Indirection

Key Requirements

– Integrity/accuracy: the count accurately reflects (legitimate) votes cast.

– Individual verifiability: every voter can confirm that her vote is accurately recorded.

– Universal verifiability: anyone can verify that the recorded ballots are accurately tabulated.

– (Universal) Eligibility verifiability: anyone can verify than only valid votes are cast, and no voter casts more than one vote (needs PKI or similar).

Secrecy Requirements

– Ballot secrecy: the way a voter casts her vote should be known only to the voter.

– Receipt-freeness: there must be no way for a voter to construct a proof of how she voted (post hoc).

– Coercion resistance: a voter can always cast a vote according to her intent while appearing to comply with a coercer’s instructions, (before, during and after the voting ceremony).

And.....

–Usability–Understandability– Availability

– Accountability

– Accessibility

– Resilience/recoverability

– etc. etc....

Prêt à Voter Ballot

BoufiltreAsterixObelixIdefix

PanoramixAbraroucourix

7490012

X

Voter-friendly Verification

• But we often encounter hostility to the use of encrypted ballots and the expectation to be able to find a vote in the clear on the WBB.

• Voter verification steps can be burdensome and non-intuitive.

• Crypto-free verification: Randell-Ryan, Rivest’s ThreeBallot....

Tracker Numbers

• A very simple approach: give each voter a private tracker number and post these along with the votes in the clear.

• Verification is simple and intuitive-no need to handle encrypted ballots etc.

Tracker numbers

•

347563 Obelix947253 Asterix556884 Panoramix569331 Idefix586994 Idefix607855 Obelix374823 Obelix

But….

• We have to guarantee that voters get unique trackers.

• The association of trackers to voters must be kept secret.

• Largely ignored by the crypto/security community, aside maybe for “boardroom” style contexts.

Coercion Attack

• Coercer requires the voter to reveal her tracker number so that he can check how she voted.

• Note however: the coercer has to require the voter to reveal her tracker before the ballots are posted. Otherwise the voter just pulls something suitable off the WBB.

• So what if voters only learn their number after posting!?

The goal

• To ensure that each voter is assigned a unique tracker number.

• To notify the voters of their trackers (after trackers/voters have been posted) in a way that provides high assurance but is deniable.

• And we want to do this in a way that ensures no single entity knows the assignment.

Selene I

• Assume standard DH/ElGamal style setup:

• g generator of the large cyclic group of prime order q in which DDH believed to be “hard”.

• Tellers hold shares of a threshold election PK.

• Voters have secret signing and trapdoor keys.

The Setup

• For each voter we want to post to the WBB:

• PKi, {n i}PK, TDCi{ni}

• TDCi =Trap Door Commitment for voter i.

• {ni}PK will be used in the tabulation.

• TDCi{ni} will be used in notifying the voter of the tracker.

Selene Set-up

• Generate sufficient tracker numbers nj and compute g^nj and post to the WBB.

• Form (ElGamal) encryption under the Teller’s PK of the g^nj : {g^nj}PK.

• Put these through a sequence of verifiable re-encryption mixes and assign the resulting shuffled, re-encrypted numbers to the voters’ Ids (PKi).

• PKi:, {g^nπ(i)} PK_T

Set-up

• The result is posted to the WBB rows of the form:

• PKi, {gn_π(i)}PK

• Note: since the nπ(i) have gone through multiple mixes, no single entity knows the assignment. But the verifiable shuffling preserves the uniqueness.

Tracker Commitments

•

Now we want a distributed construction for the trap-door commitments to the tracker numbers.

• Assume voters have SK/PK pairs: (xi, hi:=g^xi)

• Pedersen like commitments:

• gn_i⋅hir_i

Trapdoor commitments

• Suppose that we have t Trustees.

• Now, for each voter i, each Trustee Tj generates a fresh random r_i,j, computes gr_i,j and hir_i,j , where hi = PKi.

• and publishes the encryptions in a table:

• {gr_i,j}PK_T and {hir_i,j}PK

• Note that we can require ZK proofs of well-formedness of ({gr}PK, {hir}PK)

Distributed construction

• For each voter i we now form the product over the t Tellers of these:

• {gr_i}PK = ∏ j=1t {gr_i,j}PK

• {hir_i}PK = ∏ j=1t {hir_i,j}PK

Set-up

• Now take the product of the {hir_i} PK with the {gn_i}PK previously posted:

• {gn_i}PK ⊗ {hir_i}PK = {gn_i⋅hir_i}PK

• The Trustees now perform a (verified) threshold decryption to yield the (Pedersen) trapdoor commitments:

• gn_i⋅hir_i

Set up

• On the WBB we now have rows of the form:

• PKi, {gn_i}PK, gn_i⋅h_ir_i

• Ready for the i-th voter ‘s ballot.

• The Tellers retain their gr_i,j terms in secret.

Voting• To vote, the voter forms:

• SigVi({|Votei|}PK)

• Where {|X|} denotes plaintext aware encryption such as Cramer-Shoup, and sends this to the server:

• This is posted to the WBB:

• PKi, gn_i⋅h_ir_i,, {g^ ni} , SigVi({|Votei|}PK)

• Proofs and signatures are checked.

Tabulation• We extract the last two terms of the tuple, and

strip off the signature and ZK proofs:

• ({gn_i}PK , {Votei}PK)

• These are now put through verifiable, parallel, re-encryption mixes and threshold decrypted:

• (gn_i, Votei)

• From which is derived:

• (ni , Votei)

Revealing the trackers

• After the decrypted trackers and votes have been available on the WBB for a while, we notify the voters of their tracker.

• We treat the gn_i⋅h_ir_i as the “beta” components of an ElGamal encryption under the voter’s PKs.

• Trustee T_j reveals to V_i gr_i,j through a private (anonymous) channel.

Revealing the trackers

• The voter can now form the product of these to give gr_i and can then form the ElGamal cryptogram:

• (gr_i, h_ir_i, ⋅ gn_i)

• which she can decrypt as usual with her secret key xi to reveal: gn_i, and hence n_i.

• Note: we could combine the gr_i,j and just send gr_i to the voter, but requires more trust.

Coercion Resistance

• If V_i is coerced she can compute, with knowledge of the trapdoor, an alternative (gr_i)ʹ value which will open the encryption to whichever tracker number she needs to satisfy the coercer.

• On the other hand, without the knowledge of secret trapdoor, this is intractable, so revealing the wrong tracker to the voter should not be feasible for an attacker.

(Preliminary)Analysis

• Uniqueness of trackers assigned to voters follows from the mix construction.

• Need to ensure that Vi gets the correct, assigned tracker. This follows from the fact that it will be intractable for anyone but the voter to compute alternative (gr_i)ʹ that will open the commitment to an alternative valid tracker.

Discussion

• The fact that voters get to check their vote in the clear in the WBB seems to change the trust model, in particular for the voter device!?

• e.g., it may be possible to avoid the need for “Benaloh” challenges?!

• But dispute resolution becomes harder.

• Using voting codes could help.

Increased Coercion Resistance

• The scheme doesn’t provide coercion resistance against a coercer who demands the voter reveal her SK.

• A further possibility is to re-encrypt the {Vote_i} before posting, see Belenios RF, using malleable signatures.

• Now the voter does not know the randomization of the posted, re-encrypted vote.

Discussion

• So we seem to have a scheme which provides a very direct, intuitive way for voters to check that their vote is accurately included in the tally.

• It also provides a good degree of receipt-freeness.

• But there is a problem.....

The sting in the tail!

• Suppose that the coercer C is himself a voter. A coerced voter V might by chance chose C’s tracker.

• Or, C might simply claim that this is his tracker number, even if in reality it isn’t!

• How should V respond?

Discussion

• Not a problem if the coercer is not a voter.

• Maybe acceptable of the threat environment is mild.

• In many situations, the simplicity of the verification probably outweighs this threat.

• But it would be nice to address it.

Alternative constructions

• Or generate an (equal) number of dummy trackers for each candidate. If coerced the voter can request a suitable dummy tracker instead of her real one.

Selene as an add-on!?

• Seems possible to think of Selene (I and II) as possible add-ons to existing schemes.

• Could even potentially be added on dynamically:

• Add Selene I to a disputed election using encrypted ballots, e.g. Helios.

• Add Selene II if a high level of coercion is reporting prior to and during voting.

Conclusions

• Selene seems to provide a high degree of transparency for the verification while providing a good level of coercion resistance.

• Where coercion threats are regarded as serious, Selene II could be used, but at a cost in terms of transparency of verifiability.

Open questions

• Can we avoid TSitT while maintaining transparency and usability?

• Analysis, proofs.

• Dispute resolution

• Trust model for devices etc.

Thank you!