Receipt-free Voting Joint work with Markus Jakobsson, C. Andy Neff Ari Juels RSA Laboratories

Cast of characters u Voting authority u Attacker u Voter (Alice, and Bob, Charlie...) I Like Ike

Basic Internet voting Eve Charlie Bob Alice

Basic Internet voting Digitally signed by Eve Digitally signed by Charlie Digitally signed by Bob Digitally signed by Alice A vote for Al B re A vote for G.W. Gush A vote for Al Bore A vote for G.W. Gush Final Tally: Gush 2 Bore 1

BORE Alice knows randomization, so ciphertext ballot is a proof or receipt Alice Knees

Receipt-freeness u Receipt-freeness property: Alice cannot open ballot or prove contents u Prevents simple blackmail u References: BT94,SK95,HS00

What receipt-freeness doesn’t defend against u Vote buying –Sale of authentication key –Vote-buying schemes (e.g., vote-auction.com; –Anonymous peer-to-peer networks u Compromise of voting authority servers –Limited defense in HS00

What receipt-freeness doesn’t defend against u Shoulder surfing u Randomization attack –Attacker pre-specifies form of Alice’s ciphertext, leading to random result u Forced-abstention attack u Receipt-freeness won’t do for real applications!

Receipt-free Voting Joint work with Markus Jakobsson, C. Andy Neff Ari Juels RSA Laboratories

Coercion-free Voting Joint work with Markus Jakobsson, C. Andy Neff Ari Juels RSA Laboratories

First key tool: Mix network Randomly permutes and re-encrypts inputs Mix network

What does a mix network do? Key property: We can’t tell which output corresponds to a given input ?

Example application: Anonymizing bulletin board or From Bob From Charlie From Alice

From Bob From Charlie From Alice “I love Alice” “Nobody loves Bob” “I love Charlie” Is it Bob, Charlie, self-love, or other? Example application: Anonymizing bulletin board or

Another application: Voting Digitally signed by Eve Digitally signed by Charlie Digitally signed by Bob Digitally signed by Alice A vote for Al B re A vote for G.W. Gush A vote for Al Bore A vote for G.W. Gush Final Tally: Gush 2 Bore 1

A quick look under the hood

Mix Structure Server 1 Server 2 Server 3 m1 m2 m3 re-encrypt and permute re-encrypt and permute re-encrypt and permute m2 m3 m1 m3 m2 m3 m1

Mix Structure m2 m3 m1 Threshold decryption Blinding Re-mixing

Properties u Privacy preserved, i.e., permutation hidden if at least one server is honest u Soundness achievable by having servers prove correct permutation Mix network

Second key tool Threshold one-way functions –Denoted by B() and B’() –Essentially undeniable signature –B(m) = m x for shared key x

Third key tool u Anonymous credential = Voting key –Essentially a group signature key v a la Atienese et al. (Crypto ‘00) v Other approaches possible –Carries hidden, identifying tag, called tag i –Special enhancement: Also includes validator val i = B(tag i ), where B is threshold one-way function tag i val i

A little more notation Let E[m] denote El Gamal ciphertext on m: –Private key held distributively –Authorities can jointly decrypt ciphertext –B(E[m]) = E[B(m)] (due to El Gamal homomorphism)

Our new scheme Core ideas: –Voter employs anonymous credential –We don’t know who voted (at time of voting) or what was voted –Validator required for vote to count –Adversary cannot tell whether or not validator is correct v Attacker cannot tell whether a vote is valid or not

Security model u Registration: –Attacker cannot interfere with registration process or –User is forced by, e.g., hardware, to do erasing u Before voting: –Attacker can provide keying or other material to voter (even entire ballot) u During vote: –Votes may be posted anonymously (for strongest security) or semi-anonymously (for weaker guarantees) –Bulletin board is universally accessible u At all times: –Attacker has access to all public information, i.e., encrypted and decrypted ballots

Voting: Anatomy of a ballot tag i val i tag i val i vote i proof i NIZK proof that tag i ciphertext is valid for credential Anonymous credential signature validator = B(tag i )

tag 3 val 3 vote 3 proof 3 Tallying Ballots Step 1: Check group signatures and proofs Authority 1Authority 2... ? ? ? ? tag 1 val 1 vote 1 proof 1 tag 2 val 2 vote 2 proof 2 tag n val n vote n proof n

Tallying Ballots Step 2: Mixing ballots Authority 1Authority 2... tag 1 val 1 vote 1 tag 2 val 2 vote 2 tag n’ val n’ vote n’ re-encryption tag 1 val 1 vote 1 tag 2 val 2 vote 2 tag n’ val n’ vote n’...

Tallying Ballots Step 3: Joint blinding and decryption of validators Authority 1Authority 2 tag 1 val 1 vote 1 tag 2 val 2 vote 2 tag n’ val n’ vote n’ tag 1 vote 1 tag 2 vote 2 tag n’ vote n’ B’(val 1 ) B’(val 2 ) B’(val n’ )... B’ blinding prevents authorities from recognizing validators

Tallying Ballots Step 4: Elimination of duplicates by validator Authority 1Authority 2 equal validators... tag 1 vote 1 tag 2 vote 2 tag n’ vote n’ B’(val 1 ) B’(val 2 ) B’(val n’ ) tag 3 vote 3 B’(val 3 )

Tallying Ballots Step 5: Re-mixing ballots Authority 1Authority 2 re-encryption tag 1 B’(val 1 ) vote 1 tag 2 B’(val 2 ) vote 2 tag n’ B’(val n ) ’ vote n’ tag 1 vote 1 tag 2 vote 2 B’(val 1 ) B’(val 2 ) tag n’ vote n’ B’(val n’ ) Remixing required so that adversary does not recognize weeding based on number of ballots he cast

Tallying Ballots Step 6: Verification of validators Authority 1Authority 2 Authorities compute C 1 = B’(B(E[tag i ])) = E[B’(B(tag i ))] Authorities do distributed comparison of C 1 with C 2 = E[B’(val i )] If ciphertexts are equal, then validator is correct Otherwise ballot is invalid and is thus removed tag i vote i E[tag i ] If correct, B’(val i ) = B’(B(tag i )) B’(val i )

Tallying Ballots Step 7: Joint decryption of valid votes Authority 1Authority 2 Gush = Bore vote 1 vote 2 vote 3 Winner!

Voter cannot sell or prove vote Key idea: Attacker cannot tell a false validator from a real one –If attacker demands voting key, voter can provide false validator –If attacker demands that voter cast a certain type of vote, and demands pointer(s) v Voter can vote as demanded using false validator v Voter can re-vote using correct validator

Collusion with minority coalition of servers resisted u Correct validators only computable by majority u Mixing is private and robust if majority is honest

No randomization or forced abstention u Randomization: Voter can use false validator to post false ballot… and later vote for real u Forced abstention: Group signature (+ anonymous channel) provides anonymity

Resistance to shoulder-surfing u Voter can vote multiple times u Weeding policy provides for re-vote –E.g., last vote might count (needs extra phase)

Is it practical? u Overhead is just a few times that of basic, mixed-based voting –Hirt-Sako ‘00 requires untappable channels, linear cost in number of candidates, no write-ins, etc. u Not just practical, but essential for Internet voting!

Questions?

Additions u Votes can be countersigned by polling station, indicating priority u If registrar publishes voting roll with blinded validators, we can verify publicly that all participants are on roll –Requires an additional mixing step u Careful modeling required and largely unaddressed