CS294S: Build a Voting System Dan Boneh, David L. Dill, Andrew Bortz Course Goal: Investigate security engineering issues in e-voting. • Specify, design, implement a demonstration e-voting.

Download Report

Transcript CS294S: Build a Voting System Dan Boneh, David L. Dill, Andrew Bortz Course Goal: Investigate security engineering issues in e-voting. • Specify, design, implement a demonstration e-voting.

CS294S: Build a Voting
System
Dan Boneh, David L. Dill,
Andrew Bortz
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.
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
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
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).
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.
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.
Election system components
Ballot info
(offices,
candidates)
Precinct
Info
Election Management
System
Ballot
Styles,
Precincts
Totals
Cast Vote Records
Event logs
Voter
Authentication
Smart
card
Reports
Voting terminall
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
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
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
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.
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.
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
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!
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.
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.
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.
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.
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.
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.
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
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.