Class 5 Practical Considerations and Physical Security CIS 755: Advanced Computer Security Spring 2015 Eugene Vasserman

Administrative stuff New teleconference information Quiz II after class – Let me know if there are any problems Exam I next week – Proctor, or my office – Review/guide will be posted on Canvas Schedule has been corrected How was the paper for today?

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?

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

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

Giving, storing, and wiping secrets Credentials Password security Storage security Input security – Ctrl-Alt-Del Forgetfulness security – Encryption? –

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

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

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):

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

Trouble hiding in abstraction layers Hardware – CPU and drive drive architectures, e.g. SSD – Caches, RAM type – “Cold boot”: 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?)

Always state your assumptions!

In practice: Problems Composability: Attack on PKCS #1 v2 standard-compliant RSA OAEP leaks plaintext bits: / This attack also leaks plaintext bits in a lot of systems that use CBC block cipher mode:

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?

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; }

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# “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

Summary 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

Questions?

More problems Compromised certificate authorities “Wildcard” certificates – e.g. *.mozilla.org Implementation: – Incorrect verification of common names \n in common name – Incorrect validation of trust chains Not checking common names at all

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

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

Trusted computing base (TCB) Software-level TCB Hardware-enforced software constraints Hardware-level TCB TPM:

Blu-Ray DRM References “Broadcast encryption” An Overview of the Advanced Access Content System (AACS). Henry, Sui, and Zhong. Technical report, Revocation and Tracing Schemes for Stateless Receivers. Naor, Naor, and Lotspeich. Crypto,

Decryption Figure from the Overview tech report

Efficient keying and revocation Figures from the Overview tech report

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

Questions? Reading discussion