Selene: V oting with T ransparent V erifiability and Coercion Mitigation Peter Y A Ryan Vincenzo Iovino and Peter Roenne Université du Luxembourg Voting’16 26 Feb 2016 1
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 oters 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 oter Ballot Boufiltre Asterix Obelix Idefix X Panoramix Abraroucourix 7490012
V oter - 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 oter 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 o ff 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. • V oters have secret signing and trapdoor keys.
The Setup • For each voter we want to post to the WBB: • PK i , { n i } PK , TDC i { n i } • TDC i =T rap Door Commitment for voter i. • { n i } PK will be used in the tabulation. • TDC i { n i } will be used in notifying the voter of the tracker.
Selene Set - up • Generate su ffi cient tracker numbers n j and compute g^n j and post to the WBB. • Form ( ElGamal ) encryption under the Teller’s PK of the g^n j : { g^n j } PK . • Put these through a sequence of verifiable re - encryption mixes and assign the resulting shu ffl ed, re - encrypted numbers to the voters’ Ids ( PK i ) . • PK i :, { g^n π( i ) } PK_T
Set - up • The result is posted to the WBB rows of the form: • PK i , { g n_ π( i ) } PK • Note: since the n π( i ) have gone through multiple mixes, no single entity knows the assignment. But the verifiable shu ffl ing 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: ( x i , h i :=g^x i ) • • Pedersen like commitments: • g n_i ⋅ h i r_i
T rapdoor commitments • Suppose that we have t T rustees. • Now, for each voter i, each T rustee T j generates a fresh random r_i,j, computes g r_i,j and h ir_i,j , where h i = PK i . • and publishes the encryptions in a table: • { g r_i,j } PK_T and { h ir_i,j } PK • Note that we can require ZK proofs of well - formedness of ({ g r } PK , { h ir } PK )
Distributed construction • For each voter i we now form the product over the t Tellers of these: • { g r_i } PK = ∏ j=1t { g r_i,j } PK • { h ir_i } PK = ∏ j=1t { h ir_i,j } PK
Set - up • Now take the product of the { h i r_i } PK with the { g n_i } PK previously posted: • { g n_i } PK ⊗ { h i r_i } PK = { g n_i ⋅ h i r_i } PK • The T rustees now perform a ( verified ) threshold decryption to yield the ( Pedersen ) trapdoor commitments: • g n_i ⋅ h i r_i
Set up • On the WBB we now have rows of the form: • PK i , { g n_i } PK , g n_i ⋅ h _i r_i • Ready for the i - th voter ‘s ballot. • The Tellers retain their g r_i,j terms in secret.
V oting • To vote, the voter forms: • Sig Vi ({ |V ote i | } PK ) • Where { |X| } denotes plaintext aware encryption such as Cramer - Shoup, and sends this to the server: • This is posted to the WBB: • PK i , g n_i ⋅ h _i r_i, , { g^ n i } , Sig Vi ({ |V ote i | } PK ) • Proofs and signatures are checked.
Tabulation • W e extract the last two terms of the tuple, and strip o ff the signature and ZK proofs: • ({ g n_i } PK , { V ote i } PK ) • These are now put through verifiable, parallel, re - encryption mixes and threshold decrypted: • ( g n_i , V ote i ) • From which is derived: • ( n i , V ote i )
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 g n_i ⋅ h _i r_i as the “beta” components of an ElGamal encryption under the voter’s PKs. • T rustee T_j reveals to V_i g r_i,j through a private ( anonymous ) channel.
Revealing the trackers • The voter can now form the product of these to give g r_i and can then form the ElGamal cryptogram: • ( g r_i , h _ir_i, ⋅ g n_i ) • which she can decrypt as usual with her secret key x i to reveal: g n_i , and hence n_i. • Note: we could combine the g r_i,j and just send g r_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 ( g r_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 ( g r_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 ote_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?
Recommend
More recommend
