Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Security Analysis of Electronic Voting Systems: A Case Study on Diebold's Accuvote-TS - Pr, Papers of Computer Science

An analysis of the security of electronic voting systems, focusing on diebold's accuvote-ts. The authors identify major flaws in the software security, including lack of authentication, key information stored in plaintext, and incorrect use of cryptography. They also discuss various attacks, such as smartcard attacks, election configuration attacks, and tampering with election results.

Typology: Papers

Pre 2010

Uploaded on 08/05/2009

koofers-user-fk1
koofers-user-fk1 🇺🇸

10 documents

1 / 22

Toggle sidebar

Related documents


Partial preview of the text

Download Security Analysis of Electronic Voting Systems: A Case Study on Diebold's Accuvote-TS - Pr and more Papers Computer Science in PDF only on Docsity! Analysis of an Electronic Voting System Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin, Dan S. Wallach IEEE Symposium on Security and Privacy, 2004 Presented by Anirudh Ramachandran (avr@cc) Electronic Voting Systems Diebold Accuvote-TS Smartcard  Increasingly used in the US since 2000 Florida 2000 ''Butterfly Ballot''  Common vendors:  Diebold, Sequoia  28.4% of voters used DRE voting machines in 2004 System and Process Overview  Each voter gets a smartcard outside the voting booth  Card contains voter ID  Voter inserts card at the terminal & records vote  Terminal marks card ''invalid''  After the election, an administrator card or ender card is used to end the election  Election results written to memory card (or transmitted to election center over the Internet) Attacks: overview . Voter Poll Worker | Poll Worker | Internet Provider OS Voting | Section Voters/Officers (with forged | (with access to | (withaccess to | (withaccessto | Developer | Device smartcard) | storage media) | network traffic) | network traffic) Developer Jote multiple times . . . 42 (ree forged smarteard ) Wccess administrative Functi . . . . 44 or clo Modify-s¥stem configtration . . * 4. Medify ballot definition . ‘ ‘ . ‘ 42 he matty affiliation) O}ider S/ISPS Cause votes to be miscounted . . * . . 42 by tampering with configuration Impersonate legitimate voting . . * . . 43 machine to tallying authority \Qreate, delete, and modify vate4 ‘ ‘ ‘ . ‘ 43,45 Link voters with their votes/ . ® * . . 45 Tampéenith audit lo * ‘ . 4.6 élay the start of an electio ‘ ‘ ‘ . ‘ 47 Programmers Smartcard Attacks Smartcard Attacks (2)  First attack: Casting mutliple votes  Voter card marks itself ''used'' by reacting to an unauthenticated message from the terminal  Homebrew cards can simply ignore this message!  But wouldn't the terminal record that the same voter SN was used for multiple votes?  Nope, terminal only records serial numbers for voters who don't vote  A end-of-election check should show that votes cast > # of voters at a location  Useful only if all voter SNs are recorded Smartcard Attacks (3)  Second Attack: Privilege Escalation to Administrator or Ender cards  Only one field in smartcard distinguishes voter cards from admin cards  4-digit PIN required for admin/ender privilege  The best part: PIN is sent in plaintext  Sniff wire and try all consecutive 4-byte strings  ''Ending'' elections (e.g., during lunch) akin to a DoS Attacks on Election configuration and Data Impersonating a Voting Terminal  ISP or poll worker can learn how a voting terminal reports results to tabulation center  All info (username, pw, IP address of tabulation center) stored in registry in cleartext  Adversary has to create a voting terminal ID  Or can respond before the real voting terminal does ''Encryption'' blunders  Both vote records and audit logs are ''encrypted'', but...  #define DESKEY ((des_key*) ”F2654hD4”)  Same everywhere going back to 1997  Can be found with strings(1) or the like  Single DES  DES encryption (CBC mode) always uses a fixed IV  '0'  CRC of plaintext is computed, stored with ciphertext in the clear  Should use a keyed hash that also encrypts the cksum Tampering with election results  Vote records (''encrypted'') may be transmitted over the Internet as cleartext  Attacker can inject votes  Each vote is written sequentially to the record  Voters can be linked to their votes  Vote records have serial numbers for later randomization  LCH is used as the PRNG (not cryptographically secure)  Many problems with audit logging as well Excerpts from Diebold's response  Diebold: "based on the presumption that there is a single correct means of using cryptography."  every use of cryptography in the Diebold code is flawed  D: ''[t]here are stronger forms of compression than DES, but the authors' implication that the keys can be recovered `in a short time' is deliberately misleading''  Compression?!  Could be done in < 3 days in 1998  D: ''followed common professional software engineering practice.''  building software that's intended to be secure, from day one, is different from traditional software engineering Takeaways  Elections : Democracy :: Coup d'état : Dictatorship  Cannot underestimate the lengths to which an adversary might go  Normal design / impl. practices are just not good enough  Big-picture problem:  Attempt to translate physical balloting to DRE balloting without sufficient threat analysis  Copies are easy, tampering is easy, getting it wrong is easy, ... Further reading  Security Analysis of the Diebold AccuVote-TS Voting Machine (Princeton, Sept. 2006)  Physically hack a Diebold machine in < 1 min  http://citp.princeton.edu/voting/
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved