Insecurity of 802.11: WEP Encryption & E-Voting Analysis

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/