IPA Herfstdagen – Security
Zwartsluis, November 22, 2005
An Architectural View of
Universally Verifiable
Election Schemes
Berry Schoenmakers
Coding & Crypto Group
TU Eindhoven
Introduction

Focus on fully electronic elections


Remote internet case
Universally verifiable schemes

This talk:



hiding cryptographic details
focus on underlying infrastructure required
Architectural view:



abstraction of crypto core
stages and roles in an election
central role of Bulletin Board
Paper-based elections

Advantages:



Disadvantage:


Easy to understand.
Transparent: in principle, observers may monitor the
process for correct execution.
Requires physical presence of voters, talliers, observers
Fundamental properties:


Security: election result must be verifiably correct
Privacy: individual votes must remain secret
Six commandments (M. Shamos ‘93)
I.
II.
III.
IV.
V.
VI.
Thou shalt keep each voter's choices an
inviolable secret.
Thou shalt allow each eligible voter to vote only
once, and only for those offices for which she is
authorized to cast a vote.
Thou shalt not permit tampering with thy voting
system, nor the exchange of gold for votes.
Thou shalt report all votes accurately.
Thy voting system shall remain operable
throughout each election.
Thou shalt keep an audit trail to detect sins
against Commandments II-IV, but thy audit trail
shall not violate Commandment I.
Requirements for voting systems









Only registered voters may vote
Each voter may vote only once
Ballot secrecy (privacy)
Universal verifiability of election result
Robustness
No interaction between voters
No vote duplication (copying someone’s
encrypted vote without knowing the vote),
or other means of influence (intermediate
election results)…
No coercion, vote-selling
…
Hard nut to crack

Privacy and verifiability at the same time

Ballot Secrecy:


even when the system is fully audited, all
individual votes should remain private
Universal (Public) Verifiability:

anyone (incl. observers, auditors) is able to verify
the integrity of the election result against the
encrypted votes cast by legitimate voters
Scenario (or Modality)

Fully electronic election, including:





registration/authentication of voters
representation/distribution ballot forms
all results stored electronically, no paper backup
remote voting, from any location, over a public
network, using an electronic client device
No anonymous channels
Anonymous channels


Hide sender of a message, for the receiver/network
Physically realized:



Cryptographically realized:




Voter goes to kiosk, uses computer without
identification/authentication
Broadcast signal picked up by antenna on a mast or satellite ?
 Geographically trace sender
Path through networks of servers, onion routing
Verifiability not supported
Political issue: allowed to use?
But, would hide if one votes at all
Anonymous channels, cont.
Client
Anonymous
channel
Server
Server
network
Non-anonymous communication


Do not hide who is voting, but what is voted for.
Consequence: full separation of voter
authentication and vote encryption:


makes it easy to exclude double voting
Voter authentication

Ranging from weak to strong:
 UserID/password
 Challenge/response, possibly using hardware tokens


(e.g., as used for Internet banking access control,
ChipKnip)
Digital signatures, PKI
Vote encryption



Public key algorithm
Non-standard (due to verifiability)
But should become standardized!
Problem: level of trust in insiders

Attackers



Outsiders, i.e., anyone on the Internet:
 May try to attack the SSL connection or the server.
 Relatively easy to counter
Insiders, i.e., those who run the election:
 May try to alter the election result
 May try to learn people’s votes
 Much harder to counter
"Those who cast the votes decide nothing.
Those who count the votes decide everything."
Josef Stalin
Verifiability of Digital Signatures
Black Box
Message
(e.g.,
HSM)
Signing
Signature
Signing
using private key
using private key
Verify (Message, Signature, public key of signer) = accept or reject
Universally Verifiable black box
E1 = Ballot Alice
Black Box
E2 = Ballot Bob
E3 = Ballot Carol
Counting Process
T = Final Tally
Aux = Sub-tallies
using private keys
of one or
multiple talliers
Em = Ballot Diane
Verify (E1,…,Em, T, Aux, public keys of talliers) = accept or reject
Intuition: secret sharing

Single tallier sees everything:
Alice
Bob
Carol
Diana
Total

Yes
No
Yes
No
Tallier
1
0
1
0
2
Random split between two talliers:
Alice
Bob
Carol
Diana
Total
Yes
No
Yes
No
Tallier 1
-1287
-1999
-769
-1334
-5389
Tallier 2
+1288
+1999
+770
+1334
+5391
+2
Single vs. Multiple Talliers

Single tallier can decrypt



anything it likes (individual ballots)
anytime it likes (during election)
Multiple talliers must agree to decrypt:


threshold decryption: t out of n
general access structures:



≥ 3 Windows + ≥ 5 Linux + ≥ 2 Suns OR Macs
Scalable, distributed trust
How to organize / implement different talliers?


Who installs the software?
How many independent implementations?
Inside black box

Homomorphic encryption:



Verifiable MIX, either



Multiply all encrypted votes to get encryption of sum
Decrypt only such a ciphertext
Using efficient zero-knowledge proofs
Unforgeable, anonymous sigs
 blind signatures, group signatures, credentials
Tallying can be done in (overlapping) clusters:


Per city, per county
Female vs. male, age-groups (statistics)
Verifiable MIXes
vote1
Attacker
Voter
Voter
Voter
vote2
vote1
vote2
vote2
vote3
vote3
vote1
Vote server
MIX server
…..
MIX server
vote3
vote3
vote2
vote2
vote1
vote1
Talliers
result
Voter vote3
encrypt using talliers' public key
blind and permute
plus ZK proof
Threshold
decrypt
Election Stages


Initialization: key generation/select PKI
Registration: active or automatic






Voting
Data collection/mixing
Tallying
Scrutinizing
Destruction:


List of eligible voters
burning of ballot forms in “Pope” elections
Elections can be run in parallel
Election Roles

Election officials


incl. registrars
incl. providers:








Software/Hardware
PKI
Vote server
Network – Bulletin Board
Storage (data processors)
(Many) voters
Talliers, MIXers
Scrutineers (observers, auditors)
Vote client



Platform: smart cards, mobile phones, PDAs,
set-top boxes, PCs. Must be non-compromised.
Mixture of software/hardware
Voter authentication:



User interface for casting vote


Electronic ID card
Digital Signatures
Distinguish vote client vs. browsing candidates (is
done beforehand using a different client).
Publicly available specification of voting protocol

one can program client oneself, if one likes
Vote client, cont.

Minimize work for voter, trade-off:




Encryption e(i): simple public key encryption
Encryption E(i): more bulky, homomorphic encryption
Voter just encrypts candidate number as e(i)
Encryption e(i) is transformed into E(i)



done by joint protocol between some parties
Encryption E(i) is further processed
Vote-and-go property: signed receipt implies
that no further checking is needed
Vote client – against coercion

Encryption of votes

Should not be deterministic:


Should be probabilistic




From EPK(v) anyone can find vote v
EPK(v,r) with r sufficiently long, sufficiently random string
Requires good random source!
But, voter may reveal r to prove to a coercer
what the vote (encryption is `committing’)
Randomizer (e.g., special smart card):



must cooperate to cast a vote successfully
cannot change vote
uses additional randomness s.t. voter doesn’t know r
Talliers, MIXers, etc.


Must protect their sensitive data, secrets
Performance issues, depending on scheme

e.g., MIXing is computationally quite expensive:



big data sets
many secret values: blinding factors, permutation
total number of threshold decryptions to be done:


homomorphic case: in principle just one
after MIXing: each vote is decrypted individually
Vote server


Open specification, but not necessarily opensource to hide implementation details
(competitive advantage, verifiable anyway)
Possibly running in a data center


HSM for signature generation
Vote server must ensure reliability:


voter must be able to deliver its vote
issue: denial of service


by outsiders: overloading a server
by insiders: server refuses votes from certain sources
Bulletin board model
Alice
56805761456784158
signed
Bob
56459845645454766
Sub-tally 1
32234555459085752
signed
signed
Tallier #1
Carol
49135784578454685
signed
Sub-tally 2
72378867307863836
………….
Registered
voters
Tallier #2
signed
………….
………….
Registered
talliers
………….
Diane
59643456456845463
Sub-tally 10
89873538968735603
signed
Scrutineers/observers
(or, just anybody)
signed
Tallier #10
Bulletin Board

Properties (public broadcast channel):





Anyone can read BB
Nobody can erase anything from BB
Voters, talliers, officials write ballots to their own
sections, signed with their public keys
BB produces signed receipts (threshold signature)
Implemented as a kind of Byzantine agreement

Replicated design prevents denial-of-service


if < 1/3 of the BB servers is malicious, then BB is reliable
e.g., Rampart toolkit (Mike Reiter)
Implementation of BB
Receipt
Message
Receipt
Message
Message
Message
Message
Message
Receipt
Receipt
Receipt
Receipt
Performance Issues

PCs vs factoring records

April 1991



May 2005



Intel i486: 32 bit
RSA 100 = 331 bits factored
AMD Athlon: 64 bit
RSA 200 = 663 bits factored
Good guys vs bad guys:



One extra key bit, twice as much work to crack
Cryptographer:
n3 -> (n+1)3 (polynomial)
Cryptanalyst:
2n -> 2n+1
(exponential)
Solution = Protocol+Infrastructure


Voting protocol: cryptographic core of the system,
protects even against insiders (who run the system)
Security infrastructure: required to stop a multitude of
attacks, related to e.g.:





Security of client and server computers
Security of (voting) application software
Security of communication between these computers
…………….
Shortcomings of the cryptographic protocol, in
particular, the lack of universal verifiability, cannot be
remedied by strengthening the security infrastructure
Author’s address
Berry Schoenmakers
Coding and Crypto group
Dept. of Math. and CS
Eindhoven University of Technology
P.O. Box 513
5600 MB Eindhoven
Netherlands
[email protected]
http://www.win.tue.nl/~berry/