Outline
1 Potential & current situation
Electronic voting: practice and theory
Mark Ryan
University of Birmingham
Network security lecture
2 March 2011
Electronic voting: potential
Electronic voting potentially offers
Efficiency
higher voter participation
greater accuracy
lower costs
Better security
vote-privacy even in presence
of corrupt election authorities
voter verification, i.e. the
ability of voters and observers
to check the declared
outcome against the votes
cast.
2 Desired properties
3 Trust assumptions
4 Example 1: FOO (1992)
5 Example 2: Helios (2009)
6 Example 3: JCJ/Civitas (2008) (main focus)
7 Conclusions
Current situation
The potential benefits have turned out to be hard to realise.
In UK
Governments world over have May 2007 elections included 5 local authorities that piloted a range
been trialling e-voting, e.g. of electronic voting machines.
USA, UK, Canada, Brasil, the Electoral Commission report concluded that the implementation and
Netherlands and Estonia. security risk was significant and unacceptable and recommends that
no further e-voting take place until a sufficiently secure and
Can also be useful for transparent system is available.
smaller-scale elections
(student guild, shareholder
In USA:
voting, trade union ballots,
local government). Diebold controversy since 2003 when code leaked on internet.
Kohno/Stubblefield/Rubin/Wallach analysis concluded Diebold
system far below even most minimal security standards. Voters
without insider privileges can cast unlimited votes without being
detected.
Current situation in USA, continued Situation in USA 2008 election
Several other states followed Californias lead, and decertified
In 2007, Secr. of State for California commissioned
electronic voting machines.
top-to-bottom review by computer science academics of
the four machines certified for use in the state. Result is a But other states have continued to use touch-screen systems, having
catalogue of vulnerabilities, including invested massively. (E.g., the state of Colorado spent $41M on
electronic voting systems for its 3M voters, on machines that
appalling software engineering practices, such as hardcoding crypto
California has now decertified. . . )
keys in source code; bypassing OS protection mechanisms, . . .
Diebold, one of the main suppliers, tried unsuccessfully to sell their
susceptibility of voting machines to viruses that propogate from
e-voting business. Instead, they rebranded it Premier Election
machine to machine, and that could maliciously cause votes to be
Solutions and revised their forecasts downwards.
recorded incorrectly or miscounted
weakness-in-depth, architecturally unsound systems in which even
as known flaws are fixed, new ones are discovered.
In response to these reports, she decertified all four types of voting
machine for regular use in California, on 3 August 2007.

Current situation in Estonia Internet voting and coercion resistance

Estonia is a tiny former Soviet republic (pop. 1.4M), nicknamed

e-Stonia because of its tech-savvy character.
Oct. 2005 local election allowed voters to cast ballots on internet.
There were 9,317 electronic votes cast out of 496,336 votes in total
(1.9%) participated online.
Officials hailed the experiment a success. Said no reports of hacking
or flaws. System based on linux.
Voters need special ID smartcard, a $24 device that reads the card,
and a computer with internet access. About 80% of Estonian voters
have the cards anyway, also used since 2002 for online banking and
tax records.
The possibility of coercion (e.g. by family members) seems very hard to
avoid for internet voting.
In Estonia, the threat is somewhat mitigated:
Election system allows multiple online votes to be cast by the same
person during the days of advance voting, with each vote cancelling
the previous one.
System gives priority to paper ballots; a paper ballot cancels any
previous online ballot by the same person.

Feb. 2007 general election: 30,275 voters used internet voting.

Where are we? Desired properties

1 Potential & current situation

Verifiability Incoercibility
Outcome of election is Your vote is private
even if you try to
2 Desired properties verifiable by voters
and observers cooperate with a coercer
even if the coercer is the
You dont need to trust
3 Trust assumptions election software election authorities

4 Example 1: FOO (1992)

5 Example 2: Helios (2009)

6 Example 3: JCJ/Civitas (2008) (main focus)

Usability
Vote & go
7 Conclusions Verify any time

Examples Voting system: desired properties in more detail

Verifiable Privacy: the fact that a particular voted in a particular way is not
Incoercible revealed to anyone
Receipt-freeness: a voter cannot later prove to a coercer that she voted
raising hands using Tor in a certain way
Coercion-resistance: a voter cannot interactively cooperate with a
? coercer to prove that she voted in a certain way
Individual verifiability: a voter can verify that her vote was really counted
Universal verifiability: a voter can verify that the published outcome
really is the sum of all the votes
Eligibility verifiability: a voter can verify that only eligible votes have
website voting been counted
Fairness no early results can be obtained which could influence the
remaining voters

Usable . . . and all this even in the presence of corrupt election authorities!
Are these properties even simultaneously satisfiable?
Contradiction?
Eligibility: only legitimate
voters can vote, and only once
Effectiveness: the number of
votes for each candidate is
published after the election
Privacy: the fact that a
particular voted in a particular
way is not revealed to anyone
(not even the election
authorities)
How could it be secure?
Where are we?
Contradiction?
Receipt-freeness: a voter
cannot later prove to a coercer
that she voted in a certain way
Individual verifiability: a
voter can verify that her vote
was really counted
Individual verifiability
(stronger): . . . , and if her
vote wasnt counted, she can
prove that.
Trust assumption possibilities
1 Potential & current situation
2 Desired properties
3 Trust assumptions
4 Example 1: FOO (1992)
5 Example 2: Helios (2009)
6 Example 3: JCJ/Civitas (2008) (main focus)
7 Conclusions
Nothing is required-to-be-trusted
Some hardware or software is Some hardware or software is
required-to-be-trusted required-to-be-trusted
but you can audit it on some but you can bring/make/source
cut/choose basis your own
e.g. PaV, Helios 2.0 e.g. FOO, JCJ/Civitas
Some hardware or software is
required-to-be-trusted
and you just have to assume
it is
e.g. current DRE solutions
Security by trusted client software Where are we?

1 Potential & current situation

2 Desired properties

3 Trust assumptions

4 Example 1: FOO (1992)

5 Example 2: Helios (2009)

trusted by user
not trusted by user
does not need to be 6 Example 3: JCJ/Civitas (2008) (main focus)
doesnt need to be
trusted by authorities
trusted by anyone
or other voters 7 Conclusions

First, some cryptoraphy FOO 92 protocol [FujiokaOkamotoOhta92]

Blind signatures
Normally, when Alice signs a Alice aDministrator Collector
message M, creating { blind (commit (v, c), b)} A 1

SignSKA (M), she knows what

the message M is. { blind (commit (v, c), b)} D 1 I

In a blind signature, Bob can Commitments

unblind (...) = { commit (v, c)} D 1
ask her to sign a blinded version Alice can send Bob a
of the message, blindb (M). commitment commitc (M) to a II
{ commit(v, c)} D 1

After she signs it, he can message M.

unblind it. Later, she can reveal c and M, publ. (l , commit(v, c ))
unblindb (SignSKA (blindb (M))) = and Bob can verify that it is (l , c )
SignSKA (M) indeed the correct M that she
committed to. III
open(...) = v
Alice cannot lie, e.g., cannot
publ. v
find some other c 0 and M 0 that
have the same commitment
commitc 0 (M 0 ).
FOO 92 properties Where are we?
Let us consider for each one whether FOO has it or not:
Eligibility 1 Potential & current situation
Fairness
Privacy 2 Desired properties
Receipt-freeness
Coercion-resistance 3 Trust assumptions
Individual verifiability
Universal verifiability 4 Example 1: FOO (1992)
Eligibility verifiability
5 Example 2: Helios (2009)
4 out of 8. . . . not too bad, but not good enough!

FOO usability in a real election: an exercise for the reader. 6 Example 3: JCJ/Civitas (2008) (main focus)

7 Conclusions

Election of president at University of Louvain Zero-knowledge proofs

The election No coercion Problem

resistance I give you an encryption Solution
Helios 2.0 Only enck (v ) of a value v . I give you a
recommended How do you know that I zero-knowledge proof
25,000 potential voters that I know the v inside
for know v (E.g., that I
5000 registered, 4000 voted enck (v ).
low-coercion didnt copy someone
Educated, but not technical
environments elses ballot)? I give you a zero
30% voters checked their vote Re-votes are How do you know that v knowledge proof that the
No valid complaints allowed, but satisfies certain v inside enck (v ) satisfies
dont help constraints, e.g., that it is the relevant constraints
Verifiability w.r.t. insider a valid vote?
Anyone can write code to verify coercer
the election Zero-knowledge proofs are cryptographic objects, that (among other
Sample python code provided applications) provide unforgeable proof about values hidden inside
[Adida/deMarneffe/Pereira/-
encryptions. They dont reveal the value itself, but prove something
Quisquater 09]
about it.
Elgamal encryption Helios 2.0

Public parameters: a group

Homomorphic combination
G , and a generator g .
Private key x (c1 , d1 ) (c2 , d2 ) =
Public key h = g x (g r1 +r2 , g m1 +m2 hr1 +r2 )

Encryption of m: Verifiable, distributed decryption

r
(c, d) = (g , m h ) r The decryption key can be
held among a set of key
Variation: holders. User prepares ballot
Each keyholder is required (encrypted vote) on her Ballots are checked &
(c, d) = (g r , g m hr ) to participate in the computer, together with homomorphically
ZKPs to show that it is a combined into a single
decryption.
Decryption of (c, d) valid vote. encrypted outcome.
(assuming variation): Each keyholder also creates Cut-and-choose Outcome is decrypted
a zero-knowledge proof auditability provides by threshold of talliers.
0 d that he performed his part assurance of correctness
gm = Proof of correct
cx correctly. Not much guarantee of decryption.
privacy on client side.

Where are we? Verifiability and Incoercibility

1 Potential & current situation JCJ Civitas is the only protocol (to my knowledge) that achieves both
verifiability and incoercibility in strong forms. This makes it of great
2 Desired properties theoretical interest, although its complexity may make it unusable in
practice.
3 Trust assumptions How does it achieve these properties?
Incoercibility
4 Example 1: FOO (1992) Verifiability Voters cannot prove that a given value
Everything is their credential. Votes under invalid
5 Example 2: Helios (2009) that the credentials may be cast, but wont be
servers counted. Observers can verify that
6 Example 3: JCJ/Civitas (2008) (main focus) process is votes with incorrect credentials werent
published counted, but they cant see which ones
7 Conclusions those were.
Verifiable reencryption mixes JCJ/Civitas step-by-step

Problem
Solution: a verifiable reencryption mix Voter obtains her credential d.
We want to shuffle a 1

bunch of encryptions It takes as input the bunch of She obtains it in several parts, each one from a different Registrar.
{v }m encryptions {v }mpk . She puts them together herself
pk , like putting them
into a big box, closing it, It re-randomises them all. She cant prove to anyone the validity of her credential.
and shaking it for a long It outputs the results. 2 Voter casts her ballot:
time! 0

How to verify it did the mix correctly? ({v }m m

pkT , {d}pkR , zkp)
But we want to be sure
that Ask it to do another mix. 3 System removes malformed ballots.
0
What comes out of Flip a coin. System verifiably re-encrypts and mixes ({v }m m
pkT , {d}pkR ) part.
4

the box is what goes If heads, ask it to prove the 5 System compares all the {v }m
pkT parts using a plaintext equivalence
in, as a whole correspondence between the input test (PET), and discards duplicates.
No-one can link any and the result of the second mix. 6 System uses PETs to remove any ineligible votes
particular object that If tails, ask it to prove the
comes out with a
7 Keyholders decrypt using verifiable threshold decryption.
correspondence between the output
particular object that and the result of the second mix.
went in

JCJ-Civitas JCJ-Civitas: verifiability

Ballot Electoral register
{v }mpk , {d }mpk' , zkp
T R
m' '
{d }pk , Anne Jones All the intermediate stages are
R

published. Eligibility verifiability

Voter with The mixnet proofs are Voters construct a secret
remove malformed credential through interaction
credential d ballots
published.
with multiple registrars.
The decryption proofs are
published A public part of the credential
is published on the electoral
A voter can check her encrypted register, for public scrutiny.
vote is among the inputs to the first Voters submit their vote with a
mix; then she can check the overall differently randomised public
remove duplicates correctness of the mix, and the part of the credential.
decryption.
I This means that any observer
remove ineligible ballots
Any observer can check all the can verify that all the votes
mixes, the decryptions, and the cast are cast by eligible voters.
decrypt
tallying.
results
Conclusions

Electronic voting is coming, whether we like it or not.

Sadly, the current systems are woefully inadequate.
in the USA and UK, they dont manage to satisfy basic security
properties, like resistance to virus attacks and to tampering.
They dont even try to satisfy stronger properties, like privacy
guarantees against corrupt election officials, universal and individual
verifiability.
There are many academic protocols which have much better
properties, although some of them underestimate the importance of
usability issues.