1. 1 Lecture 17: SSL/TLS history, architecture basic handshake session initiation/resumption key computation negotiating cipher suites application: SET

2. 2 History of SSL/TLS SSL (secure socket layer) v2 –Released in 1995 with Netscape 1.1 –Key generation algorithm kept secret –Reverse engineered & broken by Wagner & Goldberg SSLv3 –Fixed and improved, released in 1996 –Public design process PCT (private communications technology): Microsoft’s version of SSL TLS (transport layer security): IETF’s version, yet to be deployed, incompatible with v2 and v3

3. 3 SSL Architecture Record Protocol: Message encryption/authentication Handshake P.: Identity authentication & key exchange Alert P.: Error notification (cryptographic or otherwise) Change Cipher P.: Activate the pending crypto suite IP TCP SSL Record Protocol HTTP, etc. SSL Alert Protocol SSL Change Cipher Spec. Protocol SSL Handshake Protocol

4. 4 Basic SSL/TLS Handshake Protocol SSL is on top of TCP: uses TCP’s character stream, breaks the stream into records with headers and encrypts to provide: encrypted and integrity protected stream to the upper layers Alice Bob hello, crypto offered, R A certificate, crypto selected, R B {S} Bob, {keyed hash of messages} session keys derived from K (K = f(S, R A, R B )) {keyed hash of messages} who is authenticated in this exchange? Bob can optionally send “certificate request” in message 2 to authenticate Alice, not currently deployed

5. 5 Session Initiation session vs. connection: “sessions” are relatively long-lived. Multiple “connections” (TCP) can be supported under the same SSL session. (designed for HTTP 1.0) without costly public key operations if Bob wants to resume session later (have multiple connections) – he sends Alice session_id and stores Alice Bob crypto offered, R A session-id, mycert, crypto selected, R B, {keyed hash of msgs} {S} B,{keyed hash of messages} session keys derived from K, R A, R B {keyed hash of messages}

6. 6 Session Resumption (Connection Establishment) Alice sends session-id, if Bob remembers, new connection (keys) can be established (session resumed) by just exchanging nonces is connection resumption stateless? Alice Bob session-id, crypto offered, R A session-id, crypto selected, R B, {keyed hash of msgs} {keyed hash of messages} session keys derived from K, R A, R B

7. 7 Key Computation “pre-master key”: S “master key”: K = f(S, R A, R B ) For each connection, 6 keys are generated from K and the nonces (two more Rs). –3 keys for each direction: encryption, integrity, IV – why do we need separate keys for encryption and integrity protection? may be unnecessarily complex but gets the job done

8. 8 Negotiating Cipher Suites Cipher suite: A complete package specifying the crypto to be used. (encryption algorithm, key length, integrity algorithm, etc.) 24 (v2) to 16 (v3 and TLS) bits is reserved to id the cipher suites ~30 predefined standard cipher suites. 256 values reserved for private use. Selection: –v2: Alice proposes a set of suites; Bob returns a subset of them; Alice selects one (which doesn’t make much sense) –v3: Alice proposes a set of suites; Bob selects one.

9. 9 The Trust Model PKI: Oligarchy model with X.509 certificates Browsers come configured with a set of trusted root CAs (VeriSign, AT&T, Entrust/Nortel, etc.) Additions to the root CA list by user is possible. Typically, only the server is authenticated. Client authentication is optional. No certificate revocation mechanism. Even expiration dates are not enforced.

10. 10 Attacks on v2 downgrade attack – no integrity protection for the list of requested cipher suites; attacker can force parties to use weaker crypto –in v3, at the end of the handshake (protected) Bob and Alice exchange a “finished” messages which contains the digest of the previous messages truncation attack – SSL depended on TCP for closing connection; attacker can close connectivity by sending TCP close message –v3 added a “finished” message to indicate there is no more data to be sent

11. 11 Secure Electronic Transaction (SET) Application-layer e-commerce protocol Developed by Visa & MasterCard consortium, 1996 –officially supported by Visa in 2003 Provides security, authentication, order transaction, payment authorization, etc. Both the merchant & customer are authenticated by X.509 certificates

12. 12 SET Problems of e-commerce over SSL/TLS: –malicious merchants (stealing credit card numbers) –malicious customers (using stolen credit card no.s) SET solution: –Bank (B) acts as an intermediary between the customer (C) & the merchant (M) –M forwards C’s info. to B, encrypted with B’s key –B does: authenticate C’s public key signature decrypt the transaction info. (amount, card number, etc.) issue payment authorization & send it to B –more on that in next slide

13. 13 SET Dual Signature concerns –merchant needs to know order information (OI) only –bank needs to know payment information (PI) only –needs to be a way to bind both kinds of info without revealing it to the wrong party dual sig by customer –customer’s private key {H{H{PI} || H{OI}}} = dual signature (DS) merchant can verify the info when it has OI and H{PI} and customer’s public key (how?) bank can verify the info when it has PI, H{OI} and customer’s public key