outline
play

Outline Usability and security (contd) Elections and their security - PDF document

Outline Usability and security (contd) Elections and their security CSci 5271 Introduction to Computer Security Announcements intermission Day 24: Electronic voting System security of electronic voting Stephen McCamant Exercise sets 2


  1. Outline Usability and security (cont’d) Elections and their security CSci 5271 Introduction to Computer Security Announcements intermission Day 24: Electronic voting System security of electronic voting Stephen McCamant Exercise sets 2 and 3 debrief University of Minnesota, Computer Science & Engineering Cryptography for voting Trusted UI Smartphone app permissions Smartphone OSes have more Tricky to ask users to make trust fine-grained per-application permissions decisions based on UI appearance Access to GPS, microphone Lock icon in browser, etc. Access to address book Attacking code can draw lookalike Make calls indicators Phone also has more tempting targets Lock favicon Users install more apps from small Picture-in-picture attack providers Permissions manifest Time-of-use checks Android approach: present listed of iOS approach: for narrower set of requested permissions at install time permissions, ask on each use Can be hard question to answer Proper context makes decisions clearer hypothetically But, have to avoid asking about Users may have hard time understanding common things implications iOS app store is also more closely User choices seem to put low value on curated privacy

  2. Trusted UI for privileged actions Outline Usability and security (cont’d) Trusted UI works better when asking Elections and their security permission (e.g., Oakland’12) Say, “take picture” button in phone app Announcements intermission Requested by app System security of electronic voting Drawn and interpreted by OS OS well positioned to be sure click is real Exercise sets 2 and 3 debrief Little value to attacker in drawing fake Cryptography for voting button Elections as a challenge problem History of (US) election mechanisms For first century or so, no secrecy Elections require a tricky balance of Secret ballot adopted in late 1800s openness and secrecy Punch card ballots allowed machine Important to society as a whole counting But not a big market Common by 1960s, as with computers Still common in 2000, decline thereafter Computer security experts react to How to add more technology and still proposals that seem insecure have high security? Election integrity Secrecy, vote buying and coercion Alice’s vote can’t be matched with her Tabulation should reflect actual votes name (unlinkable anonymity) No valid votes removed Alice can’t prove to Bob who she voted No fake votes inserted for (receipt-free) Best: attacker can’t change votes Best we can do to discourage: Easier: attacker can’t change votes Bob pays Alice $50 for voting for Charlie without getting caught Bob fires Alice if she doesn’t vote for Charlie

  3. Election verifiability Politics and elections In a stable democracy, most candidates We can check later that the votes were will be “pro-election” tabulated correctly But, details differ based on political Alice, that her vote was correctly cast realities Anyone, that the counting was accurate “Voting should be easy and convenient” Especially for people likely to vote for me In paper systems, “manual recount” is a “No one should vote who isn’t eligible” privileged operation Especially if they’d vote for my opponent Errors and Florida Precinct-count optical scan Detectable mistakes: Good current paper system, used here Overvote: multiple votes in one race in MN Undervote: no vote in a race, also often intentional Voter fills in bubbles with pen Undetectable mistakes: vote for wrong Ballot scanned in voter’s presence candidate Can reject on overvote 2000 presidential election in Florida Paper ballot retained for auditing illustrated all these, “wake-up call” Vote by mail Vote by web? By mail universal in Oregon and An obvious next step Washington Many other states have lenient absentee But, further multiplies the threats systems No widespread use in US yet Some people are legitimately absent Unusual adversarial test in D.C. Security perspective: makes thoroughly compromised by U. Michigan buying/coercion easy team Doesn’t appear to currently be a big problem

  4. DRE (touchscreen) voting Adding an audit trail “Direct-recording electronic”: basically VVPAT: voter-verified paper audit trail just a computer that presents and counts votes DRE machine prints a paper receipt In US, touchscreen is predominant that the voter looks at interface Goal is to get the independence and Cheaper machines may just have buttons verifiability of a paper marking system Simple, but centralizes trust in the machine Outline HW2 due Tuesday/Sunday Usability and security (cont’d) Elections and their security 11:55pm tomorrow for 10 points extra credit, recommended Announcements intermission Otherwise, 11:55pm Sunday System security of electronic voting Connecting your browser is a Exercise sets 2 and 3 debrief mini-exercise on firewalls and proxies Cryptography for voting Project meetings and presentations Exercise set 5 Presentations run next two weeks Last exercise set covers privacy Will post random schedule, allow swaps systems, voting Plan 12 minutes plus 3 minutes of questions Relatively shorter than previous ones Final progress meetings next week Posted just now, due Thursday 12/5 Mini-update by email if you’d like Last progress report still due Monday 12/2

  5. Outline Trusted client problem Usability and security (cont’d) Everything the voter knows is mediated by the machine Elections and their security (For Internet or DRE without VVPAT) Announcements intermission Must trust machine to present and record accurately System security of electronic voting A lot can go wrong Exercise sets 2 and 3 debrief Especially if the machine has a whole desktop OS inside Cryptography for voting Or a bunch of poorly audited custom code Should we use DRE at all? US equipment market Voting machines are low volume, pretty One answer: no, that’s a bad design expensive More pragmatic: maybe we can make But jurisdictions are cost-conscious this work DREs have advantages in cost, disability Makes are mostly small companies access One was temporarily owned by the larger If we implemented them well, they should Diebold be OK Big market pressures: regulations, ease Challenge: evaluating them in advance of administration Security ecosystem Diebold case study Major manufacturer in early 2000s Voting fraud appears to be very rare During a post-2000 purchasing boom Few elections worth stealing Since sold and renamed Important ones are watched closely Thoroughly targeted by independent Stiff penalties deter in-US attackers researchers Downside: No feedback from real Impolitic statement, blood in the water attacks Later state-authorized audits found Main mechanism is certification, with its comprehensive problems limitations Your reading: from California

  6. Physical security Buffer overflows, etc. Format string vulnerability Locked case; cheap lock as in hotel ✧P❛❣❡ ✪❞ ♦❢ ✪❞✧ mini-bar Was this audited? Device displays management menu on detected malfunction ❚❈❍❆❘ ♥❛♠❡❀ Can be triggered in booth by unspecified ❴st♣r✐♥t❢✭✫♥❛♠❡✱ use of paperclip ❴❚✭✧❭❭❙t♦r❛❣❡ ❈❛r❞❭❭✪s✧✮✱ Tamper-evident seals? Not a strong ❢✐♥❞❉❛t❛✳❝❋✐❧❡◆❛♠❡✮❀ protection Web-like vulnerabilities OpenSSL mistakes In management workstation software: Good news: they used OpenSSL SQL injection Bad news: old, buggy version Authentication logic encoded only in Insufficient entropy in seeding PRNG enabled/disabled UI elements Good interface from desktop Windows E.g., buttons grayed out if not missing in WinCE administrator Every device ships with same certificate Not quite as obviously wrong as in web and password context But still exploitable with existing tools Election definitions Secrecy problems Integrity “protected” by unkeyed, Limited, since the DRE doesn’t see non-crypto checksum registration information Can change bounding boxes for buttons But, records timestamp and order of Without changing checksum! voting Can modify candidate names used in Could be correlated with hidden camera final report or corrupted poll worker E.g. to fix misspelling; security implication mentioned in comment

  7. Voting machine viruses Subtle ways to steal votes Two-way data flow between voting and Change a few votes your way, revert if office machines the voter notices Hijacking vuln’s in software on both Compare: flip coin to split lunch sides Control the chute for where VVPAT ✦ can write virus to propagate receipts go between machines Exchange votes between provisional Leverage small amount of physical and regular voters access Outline Invariants for buffer overflows Usability and security (cont’d) How to ensure complex code is safe? Elections and their security Understand the logic, where it’s Announcements intermission possibly broken System security of electronic voting Should lead to a minimal fix My example had an extra bug Exercise sets 2 and 3 debrief Cryptography for voting EER, reference monitor ❛❧✐❝❡✲r❡❛❞ and ❛❧✐❝❡✲✇r✐t❡ Fuzzy checking for passwords? Both tools are missing half the needed Less symmetry that for biometrics, bad checks side effects One solution: drop privileges Reference monitor without HW Another solution: design so only half support? privileges needed Inspiration from HW setup

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend