James Heather University of Surrey Peter Y A Ryan University of Luxembourg Vanessa Teague University of Melbourne Plan Security requirements for Internet voting Overview of PGD 1 Extensions ID: 237745
Download Presentation The PPT/PDF document "Pretty Good Democracy" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Pretty Good Democracy
James Heather, University of Surrey
Peter Y A Ryan, University of Luxembourg
Vanessa Teague, University of MelbourneSlide2
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)Slide3
Internet votingSlide4
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 memorySlide5
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)Slide6
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
CodeGood:Authenticates server to voterClient can’t send wrong voteBad: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
6422Slide7
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
AckSlide8
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: 3884092844
Ack
: 28902Slide9
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 boardSlide10
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-resistantSlide11
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 vulnerabilitySlide12
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
.Slide13
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 votingSlide14
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 tallying
Bad:
Coercer can steal the code sheet before the vote
A colluding threshold of trustees
can
misrecord the vote
Integrity depends on code secrecySlide15
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)Slide16
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 themSlide17
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)Slide18
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 voteSlide19
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)Slide20
Idea C: 2 dimensional table
Each voter receives a code
for
each candidate,
for
each preference
One
Ack
Candidate
1
st
2
nd
3
rd
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: 28902Slide21
Candidate
1
st
2
nd
3
rd
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, 0934
Expect return
Ack
28902
Idea C (cont’d)Slide22
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
returnSlide23
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)Slide24
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 sheetSlide25
Example
To vote
Chequered, Fuzzy, Green, Red:
Send 9521, 7387, 4909, 3772
Expect 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
1
st
K
2
nd
T
3
rd
C
4
th
W
Ballot ID: 3884092844
Pref-Ack
W
C
K
TSlide26
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 sheetSlide27
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 voteSlide28
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