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

berry@win.tue.nlhttp://www.win.tue.nl/~berry/