Class 4 Secure Channels and Practical Considerations CIS 755: Advanced Computer Security Spring 2015 Eugene Vasserman

Administrative stuff Quiz I graded – Any problems? Periodically check main page for news and schedule page for changes and slides How were the “papers” for today? Teleconference information will change – Watch for !

Last time: Basic primitives Confidentiality (encryption) – Symmetric (e.g. AES) – Asymmetric (e.g. RSA) Hash functions Integrity and authentication – Symmetric (authentication codes) – Asymmetric (signatures) Random numbers

Preview of Math in Asymmetric Crypto Diffie-Hellman – Discrete logarithm is “hard” – Computational, decisional (“flavors”) RSA – Prime factorization is “hard” Quantum computing and Shor’s algorithm Elliptic Curves Bilinear Maps

Person-in-the-middle Alice Bob Alice Confidential NOT Authenticated Bob ?

Muahaha! Person-in-the-middle Alice Bob Alice? NOT Confidential NOT Authenticated Bob

Certificates Alice Bob Alice! Confidential Authenticated Bob CRAP!

Confidential? Authenticated? PKI Example: Confidential Bob Alice Bob Alice?

Confidential Authenticated PKI Example: Confidential Bob Alice Bob Alice!

Questions?

In practice: 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

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: xkcd.com

Example: WEP – IV, RC4(IV, k)  (M, c(M)) – Claim: 24-bit IV + 40-bit key = 64-bit security Example: WEP – IV, RC4(IV, k)  (M, c(M)) – Claim: 24-bit IV bit key = 64-bit security On the right: text from Jonathan Katz Problems: Composability Is this secure against chosen-plaintext attacks? – It is randomized… 40-bit key (in some implementations)! – Claims that, with IV, this gives a 64-bit effective key(!) And how is the IV chosen? – Only 24 bits long -- IV repetitions are a problem! – Reset to 0 upon re-initialization – Some implementations increment the IV as a counter A repeating IV allows the attacker to compute the XOR of two plaintexts – We have discussed already how this can be damaging Small IV space means the attacker can build a dictionary of (IV, RC4(IV, k)) pairs – If portions of some plaintexts known, this enables determination of other plaintexts Known-plaintext attacks discovered on this usage of RC4 – Possible because the first byte of plaintext is a fixed, known header! Chosen-plaintext attacks – Send IP traffic/ to the mobile host and watch it get forwarded – Transmit broadcast messages to access point – Authentication spoofing No cryptographic integrity protection – The checksum is linear (i.e., c(x  y) = c(x)  c(y)) and unkeyed, and therefore easy to attack – Allows IP redirection attack – Allows TCP “reaction” attacks Look at whether TCP checksum is valid Form of chosen-ciphertext attack Encryption used to provide authentication of mobile station (access point sends nonce; station returns an encryption of the nonce) – Allows easy spoofing after eavesdropping

Problems: Side channels Side-channel attacks VERY damaging – Power – Timing See news (2013) and cool stuff (2014) pagesnewscool stuff – Error messages! Different errors in SSH leak information (mismatch between implementation and specification of CBC block cipher mode):

Questions?

Exercise How do we design a naïve asymmetric encryption scheme from everything we have learned so far? RSA does not provide integrity. Why? Malleable vs. non-malleable Why might we sometimes want malleable?

Cool stuff Elliptic curves – y 2 = x 3 + ax + b Secure multiparty computation – General existence result Communication complexity Threshold cryptography – Encryption, signatures, secret sharing

More cool stuff Identity-based encryption (IBE) – Time period-based Attribute-based encryption (ABE) Zero-knowledge (ZK) proofs – General existence result in NP – Interactive or non-interactive (NZIK) Strength from number of rounds or predefined Homomorphic encryption

Yet more cool stuff Key management – Key trees Hierarchical, time-based access One-time use tokens – Compare to capabilities Blind signatures Compact signature aggregation Commitments (vs. hashes)

Questions?

Today’s readings Bryant – Designing an Authentication System: a Dialogue in Four Scenes. MIT, (Kerberos V4) Afterword by Ts’o. MIT, (Kerberos V5) Fu, Sit, Smith, and Feamster – Dos and Don'ts of Client Authentication on the Web

User authentication What do we usually think of? – Passwords! In essence: something only you know What does authentication provide? – Access control In essence: access to a limited resource

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

Questions? Why SSL, not Kerberos, for e-commerce? What’s the major difference between SSL certificates and Kerberos tokens? What’s the “SSL equivalent” of a Kerberos server?

Partially implied assumptions Kerberos server is trusted User is not the “client” (software)

V5 and Encrypt-then-MAC Changes in Kerberos V5: – Replay protection beyond timestamps – One fewer layer of encryption – Secure delegation Mechanism for verifying decryption is incorrect: should use encrypt-then-MAC – More secure then MAC-then-encrypt or encrypt-and-MAC (provably secure, in fact!)

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

Exercise How do we handle password-based authentication over an insecure channel?

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