1 / 14

Class 7 Practical Considerations CIS 755: Advanced Computer Security Spring 2014

Class 7 Practical Considerations CIS 755: Advanced Computer Security Spring 2014. Eugene Vasserman http://www.cis.ksu.edu/~eyv/CIS755_S14/. Administrative stuff. Project proposal due next week No office hours tomorrow Use Google Scholar Projects – more clarification Quiz returned.

pancho
Download Presentation

Class 7 Practical Considerations CIS 755: Advanced Computer Security Spring 2014

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. Class 7Practical ConsiderationsCIS 755: Advanced Computer SecuritySpring 2014 Eugene Vasserman http://www.cis.ksu.edu/~eyv/CIS755_S14/

  2. Administrative stuff • Project proposal due next week • No office hours tomorrow • Use Google Scholar • Projects – more clarification • Quiz returned

  3. Giving, storing, and wiping secrets • Credentials • Password security • Storage security • Input security • Ctrl-Alt-Del • Forgetfulness security • Encryption? • https://citp.princeton.edu/research/memory/

  4. Implementation considerations • Kerckhoffs’ principle and Shannon’s maxim • Especially tempting to violate in case of “dirty” code – I’ve been there! • Watch your (unstated) assumptions • Example: Unsanitized (untrustworthy) input • Adversaries • Side-channels • Performance

  5. NEVER BUILD YOUR OWN WHEN SOLUTION EXISTS!!! NEVER COMPOSE YOUR OWN WHEN LIBRARY EXISTS!!!

  6. Problems: Side channels • Side-channel attacks VERY damaging • Power • Timing • Error messages • Different errors in SSH leak information (mismatch between implementation and specification of CBC block cipher mode): http://portal.acm.org/citation.cfm?id=586112

  7. Optimizations • Asymmetric encryption: • Password  Secret Key  ESK(K), EK(M) • Signatures: • Password  Secret Key  M, SigSK(h(M)) • Why do this? Why is this safe? • Symmetric: • Password  Key derivation/stretching/strengthening function  K

  8. Trouble hiding in abstraction layers • Hardware • CPU and drive drive architectures, e.g. SSD • Caches, RAM type • “Cold boot”: https://citp.princeton.edu/research/memory/ • Operating system • Swap/paging file(s) • Scheduling (process, access, I/O, etc.) • Language and development tools • Compilation, (dynamic) optimization • Handling of temporary files (OS?) • Handling of mapped memory (OS?)

  9. Always state your assumptions!

  10. In practice: Problems • Composability: http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html • Attack on PKCS #1 v2 standard-compliant RSA OAEP leaks plaintext bits: http://www.springerlink.com/content/tw5tuqb3hxbn9grq/ • This attack also leaks plaintext bits in a lot of systems that use CBC block cipher mode: http://lasecwww.epfl.ch/pub/lasec/doc/Vau02a.ps

  11. Problems: Composability • Example: WEP • IV, RC4(IV, k) (M, c(M)) • Claim: 24-bit IV + 40-bit key = 64-bit security • Example: WEP • IV, RC4(IV, k)  (M, c(M)) • Claim: 24-bit IV + 40-bit key = 64-bit security • On the right: text from Jonathan Katz • 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 • 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 • 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 • 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

  12. Maintenance: Debian and OpenSSL • Cause: Valgrind and Purify complain about bad code • Result: Predictable random numbers • How? In md_rand.c: //MD_Update(&m, buf, j); … //MD_Update(&m, buf, j); /* purify complains */ • What happened?

  13. SSL 3.0/TLS 1.0 vulnerabilities • US CERT Vulnerability Note VU#864643: SSL 3.0 and TLS 1.0 allow chosen plaintext attack in CBC modes • “An attacker with the ability to pose as a man-in-the-middle and to generate specially-crafted plaintext input could decrypt the contents of an SSL- or TLS-encrypted session. This could allow the attacker to recover potentially sensitive information (e.g., HTTP authentication cookies).” • NOT new – known CBC-mode attacks

  14. Questions? Reading discussion

More Related