Coercion Mitigation Peter Y A Ryan Vincenzo Iovino and Peter - - PowerPoint PPT Presentation

Selene: V

• ting with

T ransparent V erifiability and Coercion Mitigation

Voting’16 26 Feb 2016 1

Peter Y A Ryan Vincenzo 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 V erifiability

• 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).

V

• ters 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 à V

• ter Ballot

Boufiltre Asterix Obelix Idefix Panoramix Abraroucourix 7490012

X

V

• ter-friendly V

erification

• 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.

• V
• ter verification steps can be burdensome and

non-intuitive.

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

ThreeBallot....

T racker Numbers

• A very simple approach: give each voter a private

tracker number and post these along with the votes in the clear.

• V

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

T racker numbers

• 347563

Obelix 947253 Asterix 556884 Panoramix 569331 Idefix 586994 Idefix 607855 Obelix 374823 Obelix

But….

• W

e 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
• rder q in which DDH believed to be “hard”.
• Tellers hold shares of a threshold election PK.
• V
• ters 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 =T

rap 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.

T racker 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

T rapdoor commitments

• Suppose that we have t T

rustees.

• Now, for each voter i, each T

rustee 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 T

rustees 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.

V

• ting
• To vote, the voter forms:
• SigVi({|V
• tei|}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({|V
• tei|}PK)
• Proofs and signatures are checked.

Tabulation

• W

e extract the last two terms of the tuple, and strip off the signature and ZK proofs:

• ({gn_i}PK , {V
• tei}PK)
• These are now put through verifiable, parallel, re-

encryption mixes and threshold decrypted:

• (gn_i, V
• tei)
• From which is derived:
• (ni , V
• tei)

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.

• W

e treat the gn_i⋅h_ir_i as the “beta” components

• f an ElGamal encryption under the voter’s PKs.
• T

rustee 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 {V
• te_i}

before posting, see Belenios RF, using malleable signatures.

• Now the voter does not know the randomization
• f 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
• T

rust model for devices etc.

Thank you!