1. Class 13 Review CIS 755: Advanced Computer Security Spring 2015 Eugene Vasserman http://www.cis.ksu.edu/~eyv/CIS755_S15/

2. Administrative stuff TEVAL offered – please fill it out :) Even/especially if you thought this class was horrible! No class or office hours after May 3 rd Quiz this week Final exam on May 13 th (2:00 – 3:50) – Review document will be posted today – Come to front office on May 13 th at 2 PM 1

3. The most important slide of the class What are the take-away messages? – Think like an adversary – Kerckhoffs’ principle and Shannon’s maxim – Be able to search for solutions – Read papers – Reuse, reuse, reuse (correctly!) – State assumptions (be sure they hold) – Be able to admit “I don’t know” – not everyone can engineer every solution 2

4. I’m sure this is someone’s law… If a security system is too difficult to use, users will find a way to get around it – Corollary: Getting the job done is more important than security Has more immediate potentially bad outcomes 3

5. Things to remember I can be wrong; papers can be wrong; anyone can be wrong! If you don’t understand something, ask! What does “secure” mean? Who is the adversary, and why? There is such a thing as too much security If too hard to use, users will bypass security Attacks only get better 4

6. Some things to remember Theoretical to practical in ~10 years – Chosen ciphertext attack – HDMI – CBC chosen plaintext attack Attacks only get better – Look at history of MD5 – Look at history of SHA (e.g. SHA-0) Some things are a bad idea in the first place, e.g. “trusted” hardware 5

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

8. Safety vs. security Think like an adversary! Random → malicious faults Engineering for security: “What’s the worst that can happen?” Assume it will… Always, always, ALWAYS state your assumptions! 7

9. Security: Fundamental differences Real world: physical, intuitive – Risk assessment People are not even good at this in the real world! – Trusted vs. trustworthy – Forensics, physical evidence Forgery – Fail “evident,” e.g. theft – Scale of failures 8

10. More basics Trusted vs. trustworthy – e.g. the recent SSL Certificate Authority fiasco Risk, hazard, vulnerability – Adversary, ROI, scale Assurance levels – “Rainbow” book series, Common Criteria Method of returning to secure states Fail-closed/secure or fail-open/insecure? 9

11. Basic cryptographic primitives Confidentiality (encryption) – Symmetric (e.g. AES) – Asymmetric (e.g. RSA) Hash functions (e.g. SHA1) Integrity and authentication – Symmetric (message authentication codes) – Asymmetric (signatures) Key agreement Random numbers 10

12. Block cipher modes of operation ECB, CBC, CTR, OFB, CFB, GCM, XEX, XTS Differences, i.e. why do we care? – Some are parallelizable (GCM) Also provides authentication! – Some are self-synchronizing (CFB) Trick question: Block ciphers vs. stream ciphers vs. pseudorandom number generators (PRNG)? 11

13. Security (strength) Key size * – Commonly 2 256 for AES, 2 2048 for RSA – What is a [good] key? Underlying cryptosystem/primitives Composition e.g. MAC with broken underlying hash function may not itself be broken 12

14. Modes of operation (ECB) Images borrowed from Wikipedia :) 13

15. Modes of operation (CBC) Images borrowed from Wikipedia :) 14

16. Recall: MACs “Keyed hash” (MAC from a cryptographically-secure hash function) – Hash  Block cipher (CBC or CFB)  MAC Hybrid modes e.g. CBC-MAC – Secrecy plus authenticity (2-party) Remember to use different keys for MAC and encryption… why? 15

17. Modes of operation (CFB) Images borrowed from Wikipedia :) 16

18. Modes of operation (CTR) Images borrowed from Wikipedia :) VS. ECB 17

19. 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/ 18

20. Access control Authentication → access No authentication → no access What are we protecting? Who is our adversary? – Threat model Who is trusted? Where does enforcement occur? 19

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

22. More considerations Correct tool for the job – Requirements (before, not after) – spend time on this Correct usage of the tool Documentation! Weakest links Pay attention to potential non-cryptographic issues such as side/covert channels – But you can never eliminate them: PROVABLE Think / test like an adversary 21

23. Current state of symmetric encryption DES is too weak (56-bit key) 3DES is weak (168-bit keys but only 2 112 security – meet-in-the-middle attack) Recent weaknesses in AES: – AES-256 (2 254.4 ) AES-192 (2 189.7 ) AES-128 (2 126.1 ) http://research.microsoft.com/en- us/projects/cryptanalysis/aesbc.pdf 22

24. Current state of hash functions MD5 is broken – http://www.win.tue.nl/hashclash/ http://www.win.tue.nl/hashclash/ SHA-1 is known to be weak – http://theory.csail.mit.edu/~yiqun/shanote.pdf (2 69 ) http://theory.csail.mit.edu/~yiqun/shanote.pdf – http://eprint.iacr.org/2004/304 (2 106, generalizable) http://eprint.iacr.org/2004/304 – SHA-256 (variant) is even weaker SHA-3 currently in “development” (NIST) – We have a winner: all hail Keccak (SHA-3)! – http://csrc.nist.gov/groups/ST/hash/sha-3/ http://csrc.nist.gov/groups/ST/hash/sha-3/ 23

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

26. Distributed systems: Security Eliminating a single point of failure – Denial of service protection (robustness) Eliminating a single point of trust – What if your boss is malicious? If we want to reap benefits of distributed system designs, we have to take care of the “maybes” How? 25

27. Distributed systems: Privacy Local system – local information Distributed system – more access to potentially private information Privacy vs. authentication Sometimes privacy is not a security requirement, sometimes it is Are there other potential security requirements related to privacy? 26

28. Source routing with capabilities B, data S3 S2 S1 B S3 S2 S1 A 27

29. eCash Broker WitnessClient Merchant 28

30. Chaum Mixes Bob Alice Output in lexographic order 29

31. Global Adversary vs. Mix Bob Alice 30

32. Tor ABC TCP over TCP (UGH!) 31

33. Tor hidden services ABCDEF 32

34. Global adversary vs. Tor Bob Alice Entire Tor network 33

35. Tor network positioning attack ABCM 34

36. Tor linkability attack ABC 35

37. Tor selective DoS attack ABC 36

38. Tor and bridges 37

39. Enumerating Freenet Run a Freenet node; wait for nodes to contact you Or just query random “locations” 38

40. ISP Anonymity ISP AS1 AS2 Anonymizing Network 39

41. ISP Censorship resistance ISP AS1 AS2 Anonymizing Network Membership Concealing Network 40

42. secret Covert auth. !! Hi? Hi! XX Hi? ?? !!?? 41

43. Steganographic embedding Linux 2.6 TCP SYN packet header with embedded MAC 42

44. Adeona 43

45. Novel Ideas in OTR Off-the-record – How is this different from what we’ve already discussed (e.g. signatures)? – Threat model Why OTR? Theoretical issues Practical considerations – More on this next week 44

46. Tools and Concepts Deniability – Symmetric authentication – Symmetric malleable encryption – Key exposure Long-term keys – Authentication Perfect forward secrecy 45

47. Final Exam Significantly longer than exams I and II (10)True/False (5)Multiple choice (8)Fill-in-the-blank (7)Short answer – But some include sub-questions – Different point values depending on difficulty and importance 46