Class 5Practical Considerations

and Physical SecurityCIS 755: Advanced Computer Security

Spring 2015

Eugene Vasserman

http://www.cis.ksu.edu/~eyv/CIS755_S15/

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?–https://citp.princeton.edu/research/memory/

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

http://portal.acm.org/citation.cfm?id=586112

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

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

Always state your

assumptions!

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

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

• “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, 2007.

http://cacr.uwaterloo.ca/techreports/2007/cacr2007-25.pdf

• Revocation and Tracing Schemes for Stateless Receivers. Naor, Naor, and Lotspeich. Crypto, 2001.

http://www.iacr.org/archive/crypto2001/21390040.pdf

Decryption

Figure from the Overview tech report

Efficient keying and revocation

Figures from the Overview tech report

Questions?

Reading discussion