CMSC 414 Computer and Network Security Lecture 11

1. CMSC 414Computer and Network SecurityLecture 11 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, 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 • Authentication spoofing

5. “Insecurity of 802.11” • No cryptographic integrity protection • The checksum is linear (i.e., c(xy) = c(x)c(y)) and unkeyed, and therefore easy to attack • Allows IP redirection attack • Allows TCP “reaction” attacks • Look at whether TCP checksum is valid • Form of chosen-ciphertext attack • Encryption used to provide authenticationof mobile station (access point sends nonce; station returns an encryption of the nonce) • Allows easy spoofing after eavesdropping

6. “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

7. 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

8. 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

9. 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

10. “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

11. “…Attacks on SSH” • Previous examples illustrated bad cryptography • Here we will see an example of good cryptography being ‘circumvented’

12. “…Attacks on SSH” • Focus only on the symmetric-key encryption and integrity protection mechanism for SSH packets • Recall CBC mode: ci = Fk(pi ci-1) • Chosen-ciphertext attack on CBC mode…

13. SSH • SSH uses a variant of CBC mode • This variant can be proven secure against chosen-ciphertext attacks

14. Proof model? decryption of ciphertext, or error c’1, …, c’n c1, …, cn … c’1, …, c’n Even after this interaction, adversary learns no information about original plaintext

15. Real world? • Different error messages returned depending on the error condition • If packet_length not in correct range, terminate the session and send SSH2_MSG_DISCONNECT • If packet_length not a multiple of the block length, terminate session with no error message • Else accept packet_length bytes until MAC can be checked; different error message sent in this case • This does not match the formal model!

16. Real world? • SSH sends/receives communication block-by-block c’1 c’2 c’3 c1, …, cn … c’n decryption of ciphertext, or error

17. This enables attacks! • Focus on packet_length ciphertext block • If SSH2_MSG_DISCONNECT message sent right away, then the attacker learns that the most significant 14 bits of decrypted length field are not all 0 • Leaks that they are all 0 with probability 2-14 • If above check passes and length check does not fail, then 4 least significant bits of decrypted length field equal 12 • Happens with probability 2-4 • If above checks pass, then attacker injects blocks until the MAC check fails • Reveals exact value of decrypted length field

18. Side channel attacks

19. Side channel attacks • We have seen already one example of how reality can differ from the (standard) formal models used in cryptography • More generally, 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’

20. 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

21. 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)

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

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

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

25. 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/