Lecture 17 SSL TLS history architecture

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

History of SSL/TLS • SSL (secure socket layer) v 2 – Released in 1995 with Netscape 1. 1 – Key generation algorithm kept secret – Reverse engineered & broken by Wagner & Goldberg • SSLv 3 – 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 v 2 and v 3 2

SSL Architecture SSL Handshake Protocol SSL Change Cipher Spec. Protocol SSL Alert Protocol HTTP, etc. SSL Record Protocol TCP IP • • 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 3

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 hello, crypto offered, RA certificate, crypto selected, RB (K = f(S, RA, RB)) Bob Alice {S}Bob, {keyed hash of messages} session keys derived from K • who is authenticated in this exchange? • Bob can optionally send “certificate request” in message 2 to authenticate Alice, not currently deployed 4

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 crypto offered, RA {S}B, {keyed hash of messages} Bob Alice session-id, mycert, crypto selected, RB, {keyed hash of msgs} {keyed hash of messages} session keys derived from K, RA, RB 5

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

Key Computation • “pre-master key”: S • “master key”: K = f(S, RA, RB) • 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 7

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

The Trust Model • PKI: Oligarchy model with X. 509 certificates • Browsers come configured with a set of trusted root CAs (Veri. Sign, 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. 9

Attacks on v 2 • downgrade attack – no integrity protection for the list of requested cipher suites; attacker can force parties to use weaker crypto – in v 3, 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 – v 3 added a “finished” message to indicate there is no more data to be sent 10

Secure Electronic Transaction (SET) • Application-layer e-commerce protocol • Developed by Visa & Master. Card 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 11

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 12

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 13