Pretty Good Democracy James Heather, University of Surrey Peter Y A Ryan, University of Luxembourg Vanessa Teague, University of Melbourne

Pretty Good Democracy

James Heather, University of SurreyPeter Y A Ryan, University of LuxembourgVanessa Teague, University of Melbourne

PlanSecurity requirements for Internet votingOverview of PGD 1 Extensions to expressive voting schemes

Protocol A (simple but slow)Protocol C (fast but big code sheets)Protocol B (fast and small code sheets, but

complicated ack checking)

Internet voting

Security RequirementsVerifiability, so that no-one can manipulate the

outputOnly eligible voters voteVoters should get evidence that their vote was

Cast as they intended Counted as cast

Everyone gets evidence votes were properly tallied

Privacy, so coercers can't manipulate the inputsEven if the voter tries to prove how they voted

(receipt-freeness)Achieving both is hard, especially for remote

votingMost solutions use a “Bulletin Board”, i.e. a

public, authenticated broadcast channel with memory

PlanSecurity requirementsOverview of PGD 1 Extensions to expressive voting schemes



Background: Code Voting (Chaum ‘01)Each voter receives a code

sheet, where each candidate gets a unique Vote Code and Ack Code

Voter sends Vote Code, checks correct Ack Code

Good:Authenticates server to voterClient can’t send wrong vote

Bad:No protection against

misbehaving server or tallierCode sheet must stay secret

Candidate Vote Ack

Red 4839 1894

Green 7846 6794

Chequered 3637 5484

Fuzzy 5468 2356

Cross 7893 6422

PGD 1.0 (first-past-the-post)

Combines Code Voting with Verifiable tallyingHigh privacy and integrity guarantees from untrusted voting clients

Each voter gets a sheet of codes via a “secure” channelone Vote Code for each candidateone Ack

They enter the code of their chosen candidateCheck they got the correct Ack

PGD 1.0 Code sheet exampleSend 5468 to the Vote

ServerWho posts it,

encrypted, to the bulletin board

Expect Ack 28902

Candidate Vote

Red 4839

Green 7846

Chequered 3637

Fuzzy 5468

Cross 7893

Ballot ID: 3884092844

Ack: 28902

PGD 1 security propertiesIntegrity assumes secrecy of code sheet

Codes authenticate the voter to the server Ack code authenticates the trustees to the voter

Requires a threshold to decrypt and return it No intervening adversary can substitute another vote code Each vote is correctly registered

If not more than a threshold of trustees colludeVerifiable tallying on a bulletin board

PGD 1 security properties (cont'd)Privacy is guaranteed against an adversary who either

Does not observe the voter’s outgoing messages, orDoes not see the code sheet

In particular, your computer doesn't learn how you votedReceipt-free, but not coercion-resistant

PGD 1 Ballot constructionCodes are generated, encrypted, on the Bulletin BoardDistributed construction produces, for each Ballot ID:

Encrypted codes on the BB listed in a random (candidate) orderSo nobody knows which codes correspond to which cand’s, or even which are on the same sheet Described by an encrypted “onion” as in Prêt à voter

Unencrypted codes for the code sheets Printing these out is the main privacy vulnerability

PGD1 VotingSubmitted codes are

encrypted by a Vote ServerMatched to the code on the BB

using a distributed Plaintext Equivalence TestBy a set of trustees who share the election pub key

This gives an index A threshold of trustees is needed to compute the Ack So receipt of the Ack proves a threshold of trustees got the vote

Tallying is by standard techniques involving mixing and zero knowledge proofs on the bulletin board, see e.g. Prêt à voter.

PGD 1.0: Some important detailsThe Vote Server has to prove it knows the

contents of the encrypted codeOtherwise it can post a random vote

The code sheets have to be checked to ensure the candidate-code pairs match those on the bulletin boardOpen some random selection and use the others

for voting

Summary: PGD (1.0)Good:

A cheating client can’t mis-cast or drop the vote•Unless they know the codes

A coercer can’t find out the vote afterwards Unless they have both the code sheet and control of the device

•Verifiable tallyingBad:

Coercer can steal the code sheet before the voteA colluding threshold of trustees can misrecord the voteIntegrity depends on code secrecy

PlanSecurity requirementsOverview of PGD 1Extensions to expressive voting schemes



Extending PGD to STV, Borda etc

Each voter lists the candidates in their order of preferenceObvious extension: send off the codes in order of preference

Doesn’t work because a cheating device can rearrange them




Idea A: IncrementalCode sheet has a Vote Code and Ack Code for each candidateSend in Vote Codes in preference order,

wait for the Ack Code before sending the next Vote CodeVery secure but very slow

Cheating device can’t manipulate the vote

PlanSecurity requirementsOverview of PGD 1 (previous work)Extensions to expressive voting schemes (this

work)Protocol A (simple but slow)Protocol C (fast but big code sheets)Protocol B (fast and small code sheets, but


Idea C: 2 dimensional tableEach voter receives a code

for each candidate, for each preferenceOne AckCandidate 1st 2nd 3rd 4th

Red 3772 5839 4892 0934

Green 4909 5345 1223 2225

Chequered 9521 5893 3333 3209

Fuzzy 7387 3455 3352 3409

Ballot ID: 3884092844 Ack: 28902

Candidate 1st 2nd 3rd 4th

Red 3772 5839 4892 0934

Green 4909 5345 1223 2225

Chequered 9521 5893 3333 3209

Fuzzy 7387 3455 3352 3409

Ballot ID: 3884092844 Ack: 28902

To vote Chequered, Fuzzy, Green, Red:Send 9521, 3455, 1223, 0934Expect return Ack 28902

Idea C (cont’d)

Idea C: pros and consVoting in one step; Ack returns in one simple stepAs strong a defence against cheating client as PGD 1.0

Device can’t change vote without knowing codesSame privacy guarantee as PGD 1.0

Single ack implies receipt-freeness even if the coercer observes ack return




Idea B: Return Ack codes in ballot orderEach voter receives

A list of candidate codes in a random, secret orderA list of preference-ack codes in preference order

The voter sends the candidate codes in preference orderand receives the preference-ack codes

in the order the candidates appear on their code sheet

Example

To vote Chequered, Fuzzy, Green, Red:Send 9521, 7387, 4909, 3772Expect return pref-acks W,C,K,T

Candidate Vote Code

Red 3772

Green 4909

Chequered 9521

Fuzzy 7387

Ballot ID: 3884092844

Preference Pref-Ack Code

1st K

2nd T

3rd C

4th W

Ballot ID: 3884092844

Pref-AckW

C

K

T

Idea B: security propertiesIntegrity: A cheating client (who doesn’t know the

meaning of the preference codes) can swap two preferences undetectably only if it knows which two positions on the code sheet they correspond to.Not great if there are only 2 candidates

Privacy is guaranteed against an adversary who eitherDoes not observe the voter’s communications, orDoes not see the code sheet

Idea B: pros and consVoting in one step; Ack returns in one (complicated) step(Somewhat) weaker defence against cheating client

than PGD 1.0Because if the device can guess or discover the candidates’

ballot positions, it can swap the votes(Somewhat) weaker privacy than PGD 1.0

Because if an attacker observes the code sheet and the pref-ack return they can learn the vote

ConclusionManipulating democracy is an ancient art

Attackers are often insidersElectronic systems offer more opportunities

PGD does a decent job of addressing many of the threatsEspecially untrusted client machines

But there are more features to add before fielding in real electionsCoercion-resistanceGuaranteed Code Sheet secrecy

Documents

Pretty Good Democracy James Heather, University of Surrey Peter Y A Ryan, University of Luxembourg Vanessa Teague, University of Melbourne