Class 5 Practical Considerations and Physical Security CIS 755: Advanced Computer Security Spring...
-
Upload
jeremy-doyle -
Category
Documents
-
view
215 -
download
1
Transcript of Class 5 Practical Considerations and Physical Security CIS 755: Advanced Computer Security Spring...
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