1 / 26

Insecurity of 802.11: WEP Encryption & E-Voting Analysis

This lecture discusses the vulnerabilities of WEP encryption in 802.11 networks and the flaws in an e-voting system, including poor cryptography and padding oracle attacks.

Download Presentation

Insecurity of 802.11: WEP Encryption & E-Voting Analysis

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. CMSC 414Computer and Network SecurityLecture 10 Jonathan Katz

  2. “Insecurity of 802.11” • WEP encryption: IV, RC4(IV | k)  (M, c(M)) • Is this secure against chosen-plaintext attacks? • It is randomized… • 40-bit key (in some implementations)! • Claims that, with IV, this gives a 64-bit effective key(!) • And how is the IV chosen? • Only 24 bits long -- IV repetitions are a problem! • Reset to 0 upon re-initialization • Some implementations increment the IV as a counter

  3. “Insecurity of 802.11” • A repeating IV allows the attacker to compute the XOR of two plaintexts • We have discussed already how this can be damaging • Small IV space means the attacker can build a dictionary of (IV, RC4(IV | k)) pairs • If portions of some plaintexts known (e.g., predictable fields), this enables determination of other plaintexts

  4. “Insecurity of 802.11” • Known-plaintext attacks discovered on this usage of RC4 • Possible because the first byte of plaintext is a fixed, known header! • Chosen-plaintext attacks • Send IP traffic/e-mail to the mobile host and watch it get forwarded! • Transmit broadcast messages to access point

  5. “Insecurity of 802.11” • Encryption used to provide authenticationof mobile station (access point sends nonce; station returns an encryption of the nonce) • Allows easy spoofing after eavesdropping • Enables chosen-plaintext attacks (by masquerading as access point) • What would have been the right primitive to use?

  6. “Insecurity of 802.11” • No cryptographic integrity protection • CRC-32 checksum is linear (i.e., c(xy) = c(x)c(y)) and unkeyed, and therefore easy to attack • Can effect arbitrary shifts of an unknown message • Allows IP redirection attack – change destination IP address of a packet to one owned by the attacker • Allows TCP “reaction” attacks • Modify ciphertexts, and look at whether TCP checksum is accepted by the receiver • Form of chosen-ciphertext attack

  7. “Analysis of E-Voting System” • This paper should scare you… • Magnitude of possible attacks by voters • Not just the security flaws, but also the reaction of Diebold and govt. officials… • Vulnerable to attacks by voters, as well as attacks by insiders • Security through obscurity did not help • In this case, code was leaked

  8. Desiderata? • Security against voters • No double voting • No voting outside place of residence • Unable to disrupt the election, or tamper with results • Privacy of others’ votes • Security against insiders (election officials, district heads, programmers, tech staff, …) • Privacy of votes, except end-of-day total • Unable to disrupt the election, or tamper with results • Public verifiability of the entire process

  9. Overview of Diebold system • Voting terminals initialized; ballots installed • On voting day, voters given voting card • Voter inserts card, gets ballot, makes choices • After confirmation, voting card is “cancelled” • Election is closed by inserting an admin card • Results can be uploaded for tabulation

  10. Poor cryptography • Smartcards have no cryptographic functionality • Possible to create home-made voting cards! • Cast multiple votes by disabling “cancellation”, or overwriting card • Change party affiliation • No cryptographic protection for admin cards • Only a weak PIN…if any • Possible to shut down the election! • Bad audit mechanism for detecting over-voting • Detected over-vote would nullify the election

  11. “Analysis of E-Voting System” • Most data stored without any integrity • Possible to modify ballots, vote total, or even the software • No authentication of data sent to back-end server • Hard-coded, non-random DES key! • CBC mode with IV = 0! • Deterministic encryption… • Linking voters to votes (encrypted votes stored sequentially) • CRC used instead of a secure MAC • Poor random number generation

  12. “Padding oracle attacks” • Chosen-ciphertext attack, relying on a single bit of information from the receiver • Is the decrypted message padded properly? • We look at one example

  13. “Padding oracle attacks” message L m1 m2 m3 0 plaintext Encrypt using CBC mode… IV c0 c1 c2 c3

  14. “Padding oracle attacks” • Step 1: recover L • Flip a bit in c2 • Results in a flipped bit in the final plaintext block • Causes decryption error iff in the ‘0’ portion • Determine L using binary search

  15. “Padding oracle attacks” • Submit ciphertext IV’ | c0 | R | ck, where IV’ chosen so that L’ = 2n-1 • Decryption error iff final bit of recovered plaintext is 1 • I.e., [F-1K(ck)  R]n = 1 • Given ck-1, this is enough to learn the last bit of mk • Repeat the same basic idea for all the bits (except some care needed for the first)

  16. Other crypto “pitfalls”? • Even good cryptography can be ‘circumvented’ by adversaries operating ‘outside the model’ • Systems are complex, and your model may not exactly match reality • Side channel attacks • Misuse of crypto (e.g., poor key management)

  17. Side channel attacks

  18. Side channel attacks • Cryptographic analysis treats primitives/protocols as black boxes • In reality, primitives and protocols implemented in the real world by hardware/software • This may lead to (other) attacks ‘outside the model’

  19. Side channel attacks • CPU retains state in the form of caches, branch prediction buffer, stack data, memory, disk… • Interaction with users influences resource usage, page protections, scheduling • Timing attacks, power analysis, EM radiation, heat/sound/disk access patterns • Especially in embedded systems

  20. Side channel attacks • Side channel attacks may be used to break the crypto • E.g., timing attacks, power analysis • Side channel attacks may also be used to circumvent crypto entirely • E.g., EM radiation from monitors/keyboards, extracting keys from memory or data from disk • (Really more of a systems issue than a crypto issue)

  21. Simple timing attack • Consider the following code for verifying a MAC Vrfy(k, m, t){ correct = MAC(k,m); for (i=0 to 15) if correct[i] != t[i] return FALSE; return TRUE; } • Assume adversary able to measure the response time until authentication fails • Do you see the attack?

  22. Preventing timing attacks • Timing analysis • Make all operations take the same amount of time • Randomize amount of time operations take (essentially a variant of the above)

  23. “Cold boot attacks” • Attacks on disk encryption products, exploiting poor key management along with the fact that memory contents can be recovered

  24. Basic setup Encpw(k) pw data Enck(data) k RAM Encrypted hard drive What happens when computer is shut off (or put in standby)?

  25. Setup 2 k pw ok TPM k RAM Before correct password entered, k is loaded into memory

  26. Key observations • If memory can be probed, possible to recover k (and then read all data on hard drive) without the correct password • First case: k not scrubbed after power down • Memory decays over time • But not too quickly, and this process can be slowed by cooling • Second case: k should be loaded only after successful password is entered • Video at http://citp.princeton.edu/memory/media/

More Related