2. An Architectural View of Universally Verifiable Election Schemes Berry Schoenmakers Coding & Crypto Group TU Eindhoven IPA Herfstdagen – Security Zwartsluis, November 22, 2005

3. 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

5. 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

6. 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.

7. 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 …

8. 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

9. 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

10. 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

11. Anonymous channels, cont. Client Anonymous channel Server network Server

12. 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!

13. 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

14. 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

15. Universally Verifiable black box Black Box Counting Process using private keys of one or multiple talliers E 1 = Ballot Alice E 2 = Ballot Bob E 3 = Ballot Carol E m = Ballot Diane T = Final Tally Aux = Sub-tallies Verify (E 1,…,E m, T, Aux, public keys of talliers) = accept or reject

16. Single tallier sees everything: Random split between two talliers: Intuition: secret sharing

17. 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?

18. 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)

19. Verifiable MIXes Voter vote2 vote3 encrypt using talliers' public key blind and permute plus ZK proof Vote server vote1 vote3 vote1 vote2 vote1 vote3 MIX server vote1 vote2 vote3 Talliers vote2 vote1 vote3 result Threshold decrypt Attacker …..

20. 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

22. 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)

23. 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

24. 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

25. Vote client – against coercion Encryption of votes Should not be deterministic: From E PK (v) anyone can find vote v Should be probabilistic E PK (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

26. 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

27. 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

28. Bulletin board model Bob 56459845645454766 signed Carol 49135784578454685 signed Tallier #1 Sub-tally 1 32234555459085752 signed Tallier #2 Sub-tally 2 72378867307863836 signed Alice 56805761456784158 signed Sub-tally 10 89873538968735603 signed Tallier #10 …………. Diane 59643456456845463 signed …………. Registered voters Registered talliers Scrutineers/observers (or, just anybody)

29. 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)

30. Implementation of BB Message Receipt

31. 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: n 3 -> (n+1) 3 (polynomial) Cryptanalyst: 2 n -> 2 n+1 (exponential)

32. 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

33. 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 berry@win.tue.nl http://www.win.tue.nl/~berry/