1 / 18

Electronic voting Past, present, and future

Explore the history, challenges, and future of electronic voting technologies. Discover the pros and cons of different systems and the need for verifiability. Join the movement for secure and transparent elections.

shanahan
Download Presentation

Electronic voting Past, present, and future

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Electronic voting Past, present, and future David Wagner U.C. Berkeley

  2. Hand-counted paper ballots The gold standard for transparency/security.But: Very time-consuming to count, with many races.

  3. Punchcards

  4. Problems with punchcard ballots

  5. Lever machines Not ideal: How do you know your vote counts?

  6. Optical scan ballots Efficient counting. But not so handicap-accessible.

  7. DREs (touchscreens) Easy to use, accessible. But how do you know whether your vote was recorded & counted correctly?

  8. Overview of technologies Used in ‘04? Secure? Optical scan 34% Yes Paperless DRE 30% NoDRE with VVPAT 1% Yes Lever machine 14% Not ideal Punchcard 13% Yes Paper ballot 1% Yes Ballot marking device 0% Yes Internet voting 0% No way

  9. Trends in e-voting • E-voting is taking off. • Election officials love it, and so do many voters. • HAVA requires modernizing by 2006. • But: Paperless DREs pose security risks. • Voters have no way to verify whether their vote was recorded correctly. • There is no way to perform a meaningful recount. • A single malicious insider could throw a close election. This might not be detected.

  10. The sad state of affairs • Current certification process for DREs is broken. • Unable to verify the correctness & security of computerized voting machines. • Has missed major flaws. • Confidence in existing machines has been shaken. • Hopkins, SAIC, Raba find flaws in Diebold AV TS. • Ohio finds security bugs in DREs from all major vendors. • Opinion: Today’s paperless DREs do not (cannot?) adequately protect the integrity of elections.

  11. A call to arms • We’ve gotta do better, gosh darn it! • And, we can do better, I believe. • It’s all about verifiability.

  12. VVPAT DRE prints paper ballot, which voter verifies but cannot take home. End-to-end integrity check -- don’t have to trust the software.

  13. Ballot marking device Print paper ballot. Deposit ballot into ballot box. End-to-end integrity -- don’t have to trust software.

  14. Opportunities for research • Still, existing solutions require paper. • Can we do better? • Challenge: Can we build a safe, paperless DRE? • Reasons for optimism: • KISS. After understanding the problem well, we should be able to build a much simpler DRE. (Not running WinCE! Not 100Kloc!) • Advances in formal verification in past 5 years. • Embedded microprocessors getting cheaper: use this to reduce the TCB. • Key principle: Design for verification.

  15. Open questions for hardware folks • Append-only storage medium. • Example: paper. • EEPROM? Nope, you can overwrite it. • CD-ROM? Mechanical failure rate too high. Too complex. Not designed for this. • Verifiably one-way “data diode”. • CPU #1 --> CPU #2 (but data can’t flow back) • Should be easy to verify one-way property • Provides simple protection domains. => Would enable architectures with smaller TCB. • Simple, verifiably-correct user interaction. • Touchscreen? Complexity of decoding might make verification hard. Calibration issues. • Audio + text-to-speech?

  16. Open questions for software folks • Architectures that reduce the size of the TCB. • Split “vote selection” from “confirm + cast”? Then only casting core has to be trusted. • Precompute each screen image, so that UI becomes a simple bitblt? Attractive, but have to explore functionality vs. security tradeoffs. • “vote casting” --> “ballot storage”? Can reboot “casting” component after each new voter, so it becomes stateless. => Good for privacy. • How do we verify code does what we want? • What is the correct spec? • Does code meet the spec? • Java + JML/ESC/Java? Spec# + Boogie? SPARK? C + informal proofs? Macroscope? CCured? • Lots more…

  17. Summary • Voting is a cool application • Opportunity for big impact • One of the first applications of software where it really, absolutely has to be secure • Challenging research questions; solutions would find applications elsewhere • Great opportunity; we can do so much better than current practice. • Let’s go build something! Who is on board?

More Related