An Architectural View of
Universally Verifiable
Election Schemes
Berry Schoenmakers
Coding & Crypto GroupTU Eindhoven
IPA Herfstdagen – Security Zwartsluis, November 22, 2005
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: Easy to understand. Transparent: in principle, observers may monitor the
process for correct execution.
Disadvantage: 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. Thou shalt keep each voter's choices an inviolable secret.
II. Thou shalt allow each eligible voter to vote only once, and only for those offices for which she is authorized to cast a vote.
III. Thou shalt not permit tampering with thy voting system, nor the exchange of gold for votes.
IV. Thou shalt report all votes accurately. V. Thy voting system shall remain operable
throughout each election. VI. 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:
Voter goes to kiosk, uses computer without identification/authentication
Broadcast signal picked up by antenna on a mast or satellite ? Geographically trace sender
Cryptographically realized: 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
Anonymouschannel
ServernetworkServer
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
Signing
using private key
Message Signature
Verify (Message, Signature, public key of signer) = accept or reject
Black Box
(e.g., HSM)
Signing
using private key
Universally Verifiable black box
Black Box
Counting Process
using private keys
of one or
multiple talliers
E1 = Ballot Alice
E2 = Ballot Bob
E3 = Ballot Carol
Em = Ballot Diane
T = Final Tally
Aux = Sub-tallies
Verify (E1,…,Em, T, Aux, public keys of talliers) = accept or reject
Single tallier sees everything:
Random split between two talliers:
Intuition: secret sharing
Tallier Alice Yes 1 Bob No 0 Carol Yes 1 Diana No 0 Total 2
Tallier 1 Tallier 2 Alice Yes -1287 +1288 Bob No -1999 +1999 Carol Yes -769 +770 Diana No -1334 +1334 Total -5389 +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:
Multiply all encrypted votes to get encryption of sum Decrypt only such a ciphertext
Verifiable MIX, either 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
Voter
Voter
Voter
Voter
vote2
vote3
encrypt using talliers' public key
blind and permuteplus ZK proof
Vote server
vote1
vote3
vote1
vote2
vote2
vote1
vote3
MIX server MIX server
vote1
vote2
vote3
Talliers
vote2
vote1
vote3
result
Thresholddecrypt
Attacker
…..
Election Stages Initialization: key generation/select PKI Registration: active or automatic
List of eligible voters Voting Data collection/mixing Tallying Scrutinizing Destruction:
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:
Electronic ID card Digital Signatures
User interface for casting vote 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: From EPK(v) anyone can find vote v
Should be probabilistic 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 open-
source 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
Bob56459845645454766
signedCarol49135784578454685
signed
Tallier #1
Sub-tally 132234555459085752
signed
Tallier #2Sub-tally 272378867307863836
signed
Alice 56805761456784158
signed
Sub-tally 1089873538968735603
signed Tallier #10
………….
Diane59643456456845463
signed
………….
………….
………….
Registered voters Registered
talliers
Scrutineers/observers(or, just anybody)
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
Message
MessageMessageMessageMessageMessage
Receipt
Receipt
Receipt
Receipt
Receipt
Receipt
Performance Issues PCs vs factoring records
April 1991 Intel i486: 32 bit RSA 100 = 331 bits factored
May 2005 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 groupDept. of Math. and CS
Eindhoven University of TechnologyP.O. Box 513
5600 MB EindhovenNetherlands
[email protected]://www.win.tue.nl/~berry/
Top Related