CS 683 - Security and Privacy Fall 2019 Instructor: Karim Eldefrawy - PowerPoint PPT Presentation

CS 683 - Security and Privacy Fall 2019 Instructor: Karim Eldefrawy University of San Francisco http://www.cs.usfca.edu/~keldefrawy/teaching /fall2019/cs683/cs683_main.htm 1

Lecture 12 Transport Layer Security/ Secure Socket Layer (TLS/SSL) (Chapter 9 in KPS)

What is this lecture about?

SSL: Secure Sockets Layer v widely deployed security v original goals: protocol § Web e-commerce § supported by almost all transactions browsers, web servers § encryption (especially § the “s” in https credit-card numbers) § billions $/year over SSL § Web-server authentication v mechanisms: [Woo 1994], § optional client implementation: Netscape authentication v variation -TLS: transport layer § minimum hassle in doing business with new security, RFC 2246 merchant v provides v available to all TCP § confidentiality applications § integrity § secure socket interface § authentication

SSL and TCP/IP Application Application SSL TCP TCP IP IP normal application application with SSL SSL provides application programming interface v (API) to applications C and Java SSL libraries/classes readily available v

Could do something like PGP: - Pretty Good Privacy (PGP) K A used to secure email . . K A (H(m)) - K A is Alice’s private key used K S m K A ( ) H( ) to sign - K B is Bob’s public key used . to encrypt to Bob a session + K S ( ) key K S + m Internet . K S K B ( ) K B (K S ) K B v but want to send byte streams & interactive data v want set of secret keys for entire connection v want certificate exchange as part of protocol: handshake phase

Toy SSL: a Simple Secure Channel v handshake: Alice and Bob use their certificates, private keys to authenticate each other and exchange a shared secret v key derivation: Alice and Bob use shared secret to derive set of keys v data transfer: data to be transferred is broken up into series of records v connection closure: special messages to securely close connection

Toy: a Simple Handshake MS: master secret EMS: encrypted master secret

Toy: Key Derivation v considered bad to use same key for more than one cryptographic operation § use different keys for message authentication code (MAC) and encryption v four keys: § K c = encryption key for data sent from client to server § M c = MAC key for data sent from client to server § K s = encryption key for data sent from server to client § M s = MAC key for data sent from server to client v keys derived from key derivation function (KDF) § takes master secret and (possibly) some additional random data and creates the keys

Toy: Data Records v why not encrypt data in constant stream as we write it to TCP? § where would we put the MAC? If at end, no message integrity until all data processed. § e.g., with instant messaging, how can we do integrity check over all bytes sent before displaying? v instead, break stream in series of records § each record carries a MAC § receiver can act on each record as it arrives v issue: in record, receiver needs to distinguish MAC from data § want to use variable-length records length data MAC

Toy: Sequence Numbers v problem: attacker can capture and replay record or re-order records v solution: put sequence number into MAC: § MAC = MAC(M x , sequence||data) § note: no sequence number field, M x = MAC key v problem: attacker could replay all records v solution: use nonce

Toy: Control Information v problem: truncation attack: § attacker forges TCP connection close segment § one or both sides thinks there is less data than there actually is v solution: record types, with one type for closure § type 0 for data; type 1 for closure v MAC = MAC(M x , sequence||type||data) data length type MAC

Toy SSL: Summary bob.com encrypted

Toy SSL isn ’ t complete v how long are fields? v which encryption algorithms to use? v want negotiation? § allow client and server to support different encryption algorithms § allow client and server to choose together specific algorithm before data transfer

SSL Cipher Suite v cipher suite common SSL symmetric § public-key algorithm ciphers § symmetric encryption algorithm § DES – Data Encryption § MAC algorithm Standard: block v SSL supports several cipher § 3DES – Triple strength: block § RC2 – Rivest Cipher 2: block suites § RC4 – Rivest Cipher 4: v negotiation: client, server stream agree on cipher suite SSL Public-key encryption § client offers choice § RSA § server picks one

Real SSL: Handshake (1) Purpose server authentication 1. negotiation: agree on crypto algorithms 2. establish keys 3. client authentication (optional) 4.

Real SSL: Handshake (2) client sends list of algorithms it supports, along with 1. client nonce server chooses algorithms from list; sends back: 2. choice + certificate + server nonce client verifies certificate, extracts server ’ s public 3. key, generates pre_master_secret, encrypts with server ’ s public key, sends to server client and server independently compute encryption 4. and MAC keys from pre_master_secret and nonces client sends a MAC of all the handshake messages 5. server sends a MAC of all the handshake messages 6.

Real SSL: Handshake (3) last 2 steps protect handshake from tampering v client typically offers range of algorithms, some strong, some weak v man-in-the middle could delete stronger algorithms from list v last 2 steps prevent this § last two messages are encrypted

Real SSL: Handshake (4) v why two random nonces? v suppose Trudy sniffs all messages between Alice & Bob v next day, Trudy sets up TCP connection with Bob, sends exact same sequence of records § Bob (Amazon) thinks Alice made two separate orders for the same thing § solution: Bob sends different random nonce for each connection. This causes encryption keys to be different on the two days § Trudy ’ s messages will fail Bob ’ s integrity check

SSL Record Protocol data data data MAC MAC fragment fragment encrypted encrypted record record header header data and MAC data and MAC record header: content type; version; length MAC: includes sequence number, MAC key M x fragment: each SSL fragment 2 14 bytes (~16 Kbytes)

SSL Record Format 1 byte 2 bytes 3 bytes content length SSL version type data MAC data and MAC encrypted (symmetric algorithm)

Real SSL Connection everything henceforth is encrypted TCP FIN message follows

Key Derivation v client nonce, server nonce, and pre-master secret input into pseudo random-number generator (PRG). § produces master secret v master secret and new nonces input into another random-number generator: “ key block ” v key block sliced and diced: § client MAC key § server MAC key § client encryption key § server encryption key § client initialization vector (IV) § server initialization vector (IV)