1. Class 7 Practical Considerations CIS 755: Advanced Computer Security Spring 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 ScholarGoogle 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/ 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  E SK (K), E K (M) Signatures: – Password  Secret Key  M, Sig SK (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/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. 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 Problems: Composability 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 authentication of 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 US CERT Vulnerability Note VU#864643 “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