1 / 25

CMSC 414 Computer and Network Security Lecture 11

CMSC 414 Computer and Network Security Lecture 11. Jonathan Katz. “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)!

betty_james
Download Presentation

CMSC 414 Computer and Network Security Lecture 11

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

More Related