CS294S: Build a Voting System

1. CS294S: Build a Voting System Dan Boneh, David L. Dill, Andrew Bortz

2. Course Goal: Investigate security engineering issues in e-voting. • Specify, design, implement a demonstration e-voting system. • Make it highly secure. • Show that it can cheat, undetectably.

3. Desired Results • Learn about technology and policy of voting technology. • Learn about secure system design • Security goals • Threats • Coding practices • Appropriate use of cryptography • Standards compliance • Other issues • Reliability • User interfaces • Accessibility

4. Project • Students will work in groups • Major modules of voting system will be implemented. • We will simplify as necessary. • Implementation will be as conformant with VVSG as feasible. • Modules should be testable, demonstrable in isolation • Java-based

5. Election lifecycle Before election • Format ballots • Set up precincts/ballot styles • Load election info (ballot styles) into machines. • Install updated firmware • Test machines (sometimes called “logic and accuracy” testing -- L&A testing). • Usually this involves running scripts and checking the results. • Some votes may be cast on touch-screens. • Machines transported to polling places (or whatever).

6. Polling Place Operations • Physical setup of machines • Election open • Print “Zero tape” • Go into “election mode” • Voting (more detail later) • Election close • Accumulate votes for all machines in polling place • Print “results tape” (candidate totals) • (Optional) Modem results into election office • Collect all materials, seal them in containers, transport to election office.

7. After Election • Results are entered into server at central office • Totals from individual precincts • Electronic ballots (“cast vote records”) • Event logs from machines • Reality: Absentee, early, provisional votes must also be tallied • Reports of various kinds are generated (e.g. PDFs), posted on Internet, etc. • There may need to be recounts • “Electronic recount” -- add up votes in computer a second time. • “Manual recount” -- print copies of cast vote records, count them by hand.

8. Election system components Ballot info (offices, candidates) Election Management System Reports Precinct Info Ballot Styles, Precincts Totals Cast Vote Records Event logs Voter Authentication Voting terminall Smart card

9. Election Management System • Database of precincts and ballot styles • Necessary for voting terminal setup • Necessary for interpreting and reporting results. • Prepares ballot logic and ballot layout • “vote for any three” • Database of election results • Precinct results • Cast vote records (electronic ballots) • Event logs • Report generation • County-wide summary • Precinct-by precinct summary • Turnout, blank ballots, undervotes • Ballot image reports • Event log reports

10. Voting Terminal Components • File system • Highly reliable • Tamper evident • GUI • Needs to minimize voter errors • Should “inspire voter confidence” • Election logic and data • Protocols for election open, close, etc. • Cast vote records • Event log

11. Requirement: Accuracy Candidate totals should reflect voter intent. Sources of inaccuracy: • Voter confusion, carelessness • User interface weirdness (e.g, “jumping votes”) • Software bugs, hardware failures • Administrative error • Tallying problems (e.g., Access capacity issues) • Fraud

12. Requirement: Availability Voters need to be able to vote Causes of failure: • Software unreliability (crashes, freezes) • Hardware problems • Failed components • Dead batteries • Administrative error (e.g., failure to plug machine in) • Insufficient capacity/provisioning • Denial of service.

13. Requirement: Transparency Elections must provide proof of accuracy • Processes must be observable • Paperless e-voting doesn’t do very well on this • Results must be auditable (it must be possible to check results independently). • There are many aspects of election auditing.

14. Requirement: Privacy Voters votes should be secret • This is to prevent intimidation • Creates major problems for fraud detection and prevention. • Can be violated in subtle ways. • Sophisticated methods hard to stop • Electronic emissions • Spy cameras in polling places

15. Requirement: Non-coercibility • Voter should not be able to prove how he/she voted to a third party to prevent vote-selling/coercion. • Vote selling has been a major problem in the U.S. (and elsewhere). • Hard to stop • Absentee voting • Cell phone cameras • This is a case where we want to enable fraud!

16. Requirement: Accessibility Federal and state law require that people with disabilities be able to vote “privately and independently” • The variety of disabilities makes this challenging. • Multiple disabilities especially so. • Most machines provide audio interfaces/tactile buttons for blind voters. • Touch screens easier for people with limited dexterity.

17. Requirement: Minority Languages • According to the Voting Rights Act, election materials must be provided in certain minority languages, if there are enough speakers of that language with limited English proficiency in that jurisdiction (detailed rules are complicated) • Los Angeles has 7 languages. • Audio ballots must be provided in multiple languages, too.

18. Security Considerations Threats are severe • Adversaries are formidable • Candidates, zealots • Foreign governments • Businesses • Organized crime • Substantial resources available • Hundreds of millions of $ spent on Presidential campaigns. • Governmental decisions involve large sums of money.

19. Attackers • Programmers at vendor, COTS operating system programmer, sysadmin, hardware designers. • Difficult or impossible to stop or detect. • Election officials (including IT), shippers, warehouse guards. • Poll workers • Voters We will try to defend against all but the first.

20. Standards • Standards • FEC 1990, 2002 VSS • EAC VVSG goes into effect 2008 • Equipment purchased with HAVA money must meet these in the future. • Many states require that equipment meet the standards • Security requirements almost non-existent.

21. Certification • Done by private “laboratories” called ITAs. They are paid by the vendors. • ITAs interpret standards and compare with designs. • “shake and bake” tests • Source code inspection (but not COTS). • Testing • Many states require federal certification, and have additional inspections & testing.

22. Interesting security issues • Novel insider attacks • Who can come up with the best one? • Software authentication • Uncertified software has been a problem. • Can TCG help? • Encryption-based write-once memory • Cheating user interfaces

23. Initial assignment • Read papers on security analysis of voting systems. • Find good attacks in NIST workshop attack catalog • Browse VVSG • Vendor websites: Diebold, Sequoia, ES&S, Hart Intercivic. Look for demos on web sites (including election office web sites). • Verify.stanford.edu photoessay • Verifiedvoting.org, blackboxvoting.org Next Monday: Form teams.