Presentation is loading. Please wait.

Presentation is loading. Please wait.

Pretty Good Democracy James Heather, University of Surrey

Similar presentations


Presentation on theme: "Pretty Good Democracy James Heather, University of Surrey"— Presentation transcript:

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

2 Plan Security requirements for Internet voting Overview 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)

3 Internet voting

4 Security Requirements
Verifiability, so that no-one can manipulate the output Only eligible voters vote Voters 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 inputs Even if the voter tries to prove how they voted (receipt- freeness) Achieving both is hard, especially for remote voting Most solutions use a “Bulletin Board”, i.e. a public, authenticated broadcast channel with memory

5 Plan Security requirements Overview 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)

6 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 voter Client can’t send wrong vote Bad: No protection against misbehaving server or tallier Code sheet must stay secret Candidate Vote Ack Red 4839 1894 Green 7846 6794 Chequered 3637 5484 Fuzzy 5468 2356 Cross 7893 6422

7 PGD 1.0 (first-past-the-post)
Combines Code Voting with Verifiable tallying High privacy and integrity guarantees from untrusted voting clients Each voter gets a sheet of codes via a “secure” channel one Vote Code for each candidate one Ack They enter the code of their chosen candidate Check they got the correct Ack

8 PGD 1.0 Code sheet example Send 5468 to the Vote Server
Who posts it, encrypted, to the bulletin board Expect Ack 28902 Candidate Vote Red 4839 Green 7846 Chequered 3637 Fuzzy 5468 Cross 7893 Ballot ID: Ack: 28902

9 PGD 1 security properties
Integrity 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 collude Verifiable tallying on a bulletin board

10 PGD 1 security properties (cont'd)
Privacy is guaranteed against an adversary who either Does not observe the voter’s outgoing messages, or Does not see the code sheet In particular, your computer doesn't learn how you voted Receipt-free, but not coercion-resistant

11 PGD 1 Ballot construction
Codes are generated, encrypted, on the Bulletin Board Distributed construction produces, for each Ballot ID: Encrypted codes on the BB listed in a random (candidate) order So 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

12 PGD1 Voting Submitted codes are encrypted by a Vote Server
Matched to the code on the BB using a distributed Plaintext Equivalence Test By 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.

13 PGD 1.0: Some important details
The Vote Server has to prove it knows the contents of the encrypted code Otherwise it can post a random vote The code sheets have to be checked to ensure the candidate-code pairs match those on the bulletin board Open some random selection and use the others for voting

14 Summary: PGD (1.0) Good: Bad:
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 tallying Bad: Coercer can steal the code sheet before the vote A colluding threshold of trustees can misrecord the vote Integrity depends on code secrecy

15 Plan Security requirements Overview 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)

16 Extending PGD to STV, Borda etc
Each voter lists the candidates in their order of preference Obvious extension: send off the codes in order of preference Doesn’t work because a cheating device can rearrange them

17 Plan Security requirements Overview 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)

18 Idea A: Incremental Code sheet has a Vote Code and Ack Code for each candidate Send in Vote Codes in preference order, wait for the Ack Code before sending the next Vote Code Very secure but very slow Cheating device can’t manipulate the vote

19 Plan Security requirements Overview 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 complicated ack checking)

20 Idea C: 2 dimensional table
Each voter receives a code for each candidate, for each preference One Ack 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: Ack: 28902

21 Idea C (cont’d)‏ 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: Ack: 28902 To vote Chequered, Fuzzy, Green, Red: Send 9521, 3455, 1223, 0934 Expect return Ack 28902

22 Idea C: pros and cons Voting in one step; Ack returns in one simple step As strong a defence against cheating client as PGD 1.0 Device can’t change vote without knowing codes Same privacy guarantee as PGD 1.0 Single ack implies receipt-freeness even if the coercer observes ack return

23 Plan Security requirements Overview 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)

24 Idea B: Return Ack codes in ballot order
Each voter receives A list of candidate codes in a random, secret order A list of preference-ack codes in preference order The voter sends the candidate codes in preference order and receives the preference-ack codes in the order the candidates appear on their code sheet

25 Example Preference Pref-Ack Code 1st K 2nd T 3rd C 4th W
Ballot ID: Candidate Vote Code Red 3772 Green 4909 Chequered 9521 Fuzzy 7387 Ballot ID: Pref-Ack W C K T To vote Chequered, Fuzzy, Green, Red: Send 9521, 7387, 4909, 3772 Expect return pref-acks W,C,K,T

26 Idea B: security properties
Integrity: 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 either Does not observe the voter’s communications, or Does not see the code sheet

27 Idea B: pros and cons Voting in one step; Ack returns in one (complicated) step (Somewhat) weaker defence against cheating client than PGD 1.0 Because 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

28 Conclusion Manipulating democracy is an ancient art
Attackers are often insiders Electronic systems offer more opportunities PGD does a decent job of addressing many of the threats Especially untrusted client machines But there are more features to add before fielding in real elections Coercion-resistance Guaranteed Code Sheet secrecy


Download ppt "Pretty Good Democracy James Heather, University of Surrey"

Similar presentations


Ads by Google