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

2. Administrative stuff New teleconference information Monday office hours moving to 2:30 (will be 2:30 – 4) starting March 23 rd – Except no office hours on March 23 rd :( Exam I – Thoughts? – Post-mortem Quiz next week

3. Distributed Systems: Definition “A system of multiple communicating entities performing a coordinated function” “A system where a computer that you’ve never heard of, located somewhere you’ve never been, can cause your computer to stop functioning correctly” –Humorous paraphrase of Lamport

4. Distributed Systems: Why? Increased robustness (maybe) – Eliminating single point of failure Resource sharing – e.g. Beocat – e.g. a mobile device and a server Improved scalability (maybe) – e.g. Beocat

5. 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” in previous slides How?

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

7. My voice is my passport; authorize me! User A says: – I want access to resource R – Kerberos server, authenticate me! R does not know if A has rights to access R Kerberos server: – Checks if A is who she says she is – Checks if A is authorized for access to R R trusts Kerberos server but not A

8. Authentication → capability → access Kerberos server issues a “token” T to A – T is tied to A – T expires – T cannot be generated by anyone other than Kerberos server (cannot be forged) T tells resource R that: – T was issued by the Kerberos server – A has the right to access R for a limited time

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

10. Always state your assumptions!

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

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. Hard(?)-to-spot bugs: goto fail static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err;... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail;... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }

14. Physical security Why use physical security? – Do Kerckhoffs’ principle and/or Shannon’s maxim apply? Tamper evidence Tamper resistance Properties? Differences? Assumptions? Trade-offs? Real-world examples

15. Exercise Design and sketch an implementation of an expiring capability (similar to a Kerberos token) in terms of what we have learned so far

16. Questions? Reading discussion