Transport Layer Security

Cryptography and Security in Communication Networks Transport Layer Security ETTI - Master - Advanced Wireless Telecommunications

Secure channels Secure data delivery on insecure networks Create a secure channel using a protocol that can provide the required security services. Internet Alice Trudy Bob Typical protocol components Authenticated key-establishment protocol provides a master shared secret for the current session. Operational keys for SKE and MAC are derived using a PRF from the master secret. Message authentication with MAC & appropriate encapsulation. Message encryption using SKE & appropriate encapsulation. Other mechanisms, e.g., for stream integrity, anti-replay. Octavian Catrina 2

Secure channels and network layers 1/3 At what layer should we create a secure channel? Depends on the problem we have to solve! Security requirements for DL, NL, TL and applications. E.g., protect all packets exchanged over WLAN; authenticate IP routing info advertisements; authenticate DNS records; provide authentication and integrity and/or confidentiality for interactive application sessions (e.g., HTTP) or messages (e.g., e-mail). WLAN LAN WAN LAN Host Access Point LAN switch Router WAN switch WAN switch Router LAN switch Host Appl. Appl. TL TL NL - - NL - - NL - NL DL DL DL DL DL DL DL DL DL PHY PHY PHY PHY PHY PHY PHY PHY PHY Octavian Catrina 3

Secure channels & network layers 2/3 Security at Data-link layer Advantages: Covers all traffic on a link (upper layer protocols and apps). Best way to protect all traffic on wireless (radio) channels. Best way to control network access, at edge. Transparent for upper layer protocols & apps. Hardware implementation (NIC). Main limitations: Per-hop security, not end-to-end. Security at Network layer (IP) Advantages: Covers all IP traffic end-to-end (assuming IP end-to-end). Transparent for upper layer protocols & apps. Hardware implementation possible. Main limitations: Low flexibility & application control (same security for all). Datagram security only. No data stream integrity. Octavian Catrina 4

Secure channels & network layers 3/3 Security at Transport/Session layer Advantages: End-to-end data stream security. Applications can control what security services are used. Limitations: Not fully transparent for users and applications. Difficult to ensure appropriate security for all applications run by employees on their PCs. No protection for lower layer traffic. No hardware implementation. Security at application level Advantages: Security services fully adapted to application needs. Disadvantages: We have to design & implement security per application (much harder for secure protocols). Octavian Catrina 5

Authenticated encryption Authenticated encryption Combination of encryption and message authentication. Never use encryption without MAC. If confidentiality is not necessary, use MAC alone. Composition of MAC and encryption schemes Variant Protected message Example Provable security Encrypt then MAC (ETM) MAC then Encrypt (MTE) MAC and Encrypt (MAE) E K1 (m) MAC K2 (E K1 (m)) IPsec Secure composition independent of schemes. Recommended method. E K1 (m MAC K2 (m)) TLS Secure composition for certain (usual) combinations of schemes. E K1 (m) MAC K2 (m) SSH Not provable as general composition method (secure in particular cases). Dedicated authenticated-encryption schemes More efficient than composition techniques. Examples: CCM (Counter with CBC-MAC Mode), NIST SP800-38C. E.g., IEEE 802.11i. GCM (Galois/Counter Mode), NIST SP800-38D. E.g., IEEE 802.1ae. Octavian Catrina 6

TLS (Transport Layer Security) protocol

TLS protocol TLS protocol Provides a secure communication channel on top a reliable transport protocol, usually TCP. Widely used by in Web browsers and servers (http over TLS: https://...). A.k.a. SSL: Secure Socket Layer. Security services HTTP FTP... TLS (a.k.a SSL) TCP Secure connection setup, including key exchange with server authentication and (optionally) client authentication. Authenticated encryption of application data (SE + MAC). Development and standardization Originally developed by Netscape; last version: SSL v3.0. Adopted by IETF as TLS 1.0, specified in RFC 2246. Current spec.: TLS 1.2, RFC 5246, 2008 (and other RFCs). Octavian Catrina 8 IP

TLS sessions and connections TLS session Association between a client and a server that defines a set of cryptographic security parameters. These parameters can be shared among multiple TLS connections. Session setup provides: Negotiation of cryptographic mechanisms ("cipher-suites"). Server and client authentication. Exchange of basic key material. TLS connection Transient connection associated with a TLS session, offering reliable and secure data transport: Data integrity (authentication) using HMAC (MD5 or SHA-1). Data confidentiality using an encryption scheme based on a block cipher (e.g., AES, 3DES), RC4 stream cipher, etc. Fast connection setup: new keys computed using the session's (pre-)master secret and connection nonces. Octavian Catrina 9

TLS / SSL TLS architecture HTTP, FTP, SMTP, POP3, IMAP4, LDAP, etc. Handshake Protocol Change Cipher Protocol Alert Protocol Record Protocol TCP Record protocol Encapsulates user data, providing data authentication and confidentiality. Encapsulates TLS control messages: Handshake, Change Cipher, Alert. Handshake protocol Session and connection setup. Change Cipher protocol Single message: starting to use new cipher-suite & keys agreed-upon. Alert protocol Error notifications. Octavian Catrina 10

TLS Record protocol 1/2 Data processing A user data stream is processed as a sequence of data blocks (fragments) with length up to (about) 2 14 octets. A sequence number is assigned to each fragment. Data processing (outline): Application data Fragment 1 Fragment 2... Fragment n Compress MAC Encrypt Processing per block: Compress (optional). Compute MAC, append MAC and padding. Encrypt all this using a SE scheme. Octavian Catrina 11

Records TLS Record protocol 2/2 TLS must determine the sequence of encrypted blocks in the octet stream delivered by TCP, in order to process received data (decryption & MAC). Same problem for control messages. The TLS record format provides the payload encapsulation necessary for this purpose. Record format: Data record processing (details): Record header Record type Protocol version Record length seq_num record header record data (compressed) MAC MAC key Record payload record header record data (compressed) MAC padding User data (compression, MAC, encryption) or TLS control message(s) record header Encrypt Init. Value (IV) Encryption key encrypted & integrity-protected data Octavian Catrina 12

TLS Handshake Protocol 1/2 Session setup Cipher-suite negotiation. Key exchange with server and client authentication. Client Example (simplified) Negotiate cipher-suite, exchange random nonces. Server Cipher-suites I suggest. My random nonce R C Session-id. Cipher-suite I choose. My random nonce R S. Certificate for my public-key (PK S ) Choose cipher-suite. Choose pre-master secret S, encrypt it, and send it to server. Compute master secret K = PRF(S, R C, R S ), and derive from K, R C, R S the keys for MAC and encryption. Key exchange. In this example, key transport using RSA encryption and (implicit) server authentication. Our secret E PKS (S). Handshake integrity check (MAC(msgs)) Handshake integrity (MAC(msgs)), proof I know the keys) Data, encrypted and integrity protected with keys derived from K Decrypt pre-master secret S. Compute master secret K = PRF(S, R C, R S ), and derive from K, R C, R S the keys for MAC & encryption. Octavian Catrina 13

TLS Handshake Protocol 2/2 Session resumption Handshake that allows to reuse authentication and shared secrets across multiple connections, perform fast re-keying of the current connection (new session secrets using fresh nonces), and to re-negotiate the cipher-suite. Example: Re-keying a connection (simplified) Client Client and server have set up a session identified by session-id and share the session's master key K. Server Session-id. Cipher. New random nonce R' C Derive from K, R' C, R' S new keys for MAC and encryption. Session-id. Cipher. New nonce R' S. Integrity check (MAC(msgs)) Integrity check (MAC(msgs)) Derive from K, R' C, R' S new keys for MAC and encryption. Data, encrypted and integrity protected with keys derived from K Octavian Catrina 14

Key exchange methods Ephemeral Diffie-Hellman DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA. Best method. DH key exchange with one-time DH secrets. Server and (optionally) client authentication using RSA or DSS signatures. Variants for integer groups and elliptic curve groups. RSA encryption The pre-master secret is encrypted with the server s public RSA key. This also authenticates the server. The server can request client authentication using RSA or DSS signature. Pre-shared keys Introduced in RFC 4279, Dec. 2005. Others Fixed Diffie-Hellman (DH_RSA, DH_DSS). The server has a fixed DH key-pair (with certificate). This also authenticates the server. The server can request client authentication using DH key or using RSA or DSS signature. Kerberos,. Octavian Catrina 15

TLS Pseudo-Random Function (PRF) TLS 1.2 (RFC 5246) defines a PRF based on HMAC with the hash function SHA-256. This PRF takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length. Data expansion function: P(key, seed) = HMAC( key, A(1) seed ) HMAC( key, A(2) seed ) HMAC( key, A(3) seed )... where " " denotes concatenation, A(0) = seed A(i) = HMAC( key, A(i-1) ) PRF: PRF(key, label, seed) = P(key, label seed) where "label" is an ASCII string. key seed key seed In HMAC Out In HMAC Out A(1) key seed key 256 bits = 32 bytes In HMAC Out In HMAC Out A(2) key seed key In HMAC Out In HMAC Out A(3)...... - The data expansion function P() is iterated until the required quantity of data is obtained. (e.g., for 80 bytes, P() is iterated 3 times, creating 332 = 96 bytes of data; the last 16 bytes are discarded). - E.g., TLS uses this PRF to generate from a master secret (as key) and random nonces (as seed) the data authentication and data encryption keys for each direction of a TLS connection. Octavian Catrina 16

TLS session setup: Overview Client Optional message, depending on AKE variant. Server Negotiate cipher suite, exchange connection nonces. Key exchange (KE) with server and optionally client authentication. Several KE methods. Client and server compute a master secret and then derive data encryption and data authentication keys for each direction. ChangeCipherSpec: Client commits agreed cipher-suite and keys. Next messages are encrypted and authenticated. ClientFinished: MAC with master secret authenticates handshake, confirms key knowledge, etc. ClientHello (suggested cipher-suites, client nonce) ServerHello (chosen cipher-suite, server nonce, session-id) ClientCertificate (client certificate) ClientKeyExchange (key material) ServerCertificate (server certificate) ServerKeyExchange (key material) CertificateRequest (what client certificate) CertificateVerify (proof I know my private key) ChangeCipherSpec ClientFinished(MAC(handshake messages)) ChangeCipherSpec ServerFinished(MAC(handshake messages)) Done. Can start secure data transfer. SeverKeyExchange: Optional, e.g., used with DH variant of AKE. CertificateRequest: Sent if the server wants the client to authenticate itself (with digital signature). ClientCertificate: Sent if the server asks for client authentication. CertificateVerify: Client authenticator (based on digital signature). ChangeCipherSpec: Server commits agreed ciphersuite and keys. Next messages are encrypted and authenticated. ClientFinished: MAC with master secret authenticates handshake, confirms key knowledge, etc. Octavian Catrina 17

DH+DSS KE with server authentication 1/2 ClientHello (M1) Version: 3.3 (TLS 1.2) Client ClientNonce: Random[28] + GMT_seconds[4] SuggestedCipherSuites: TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,... DSS/DSA = Digital Signature Server Standard/Algorithm Server actions after receiving M1: KS SRV = Server's DSS private (signing) key. KV SRV = Server's DSS public (verification) key. - Select cipher suite. Select the DH domain parameters dh_p, dh_g. - Generate the server's DH parameters: dh_xs and dh_ys = (dh_g) dh_xs mod dh_p. - Construct and send next messages... Client actions after receiving M2: - Validate the server s certificate chain. - Verify signature in M2c, and store server's DH public parameters: dh_p, dh_g, dh_ys. - Generate the client's DH parameters: dh_xc and dh_yc = (dh_g) dh_xc mod dh_p. - Generate pre_master_secret = (dh_ys) dh_xc mod dh_p. - Generate secrets from pre_master_secret: master_secret = PRF(pre_master_secret, "master secret" ClientNonce ServerNonce) key_block = PRF(master_secret, "key expansion" ClientNonce ServerNonce) Take successive bytes from key_block for: client-write-mac, server-write-mac, client-write-key, server-write-key, client-write-iv, server-write-iv - Apply client-write parameters to write M3b and all subsequent messages (encrypted and authenticated). ServerHello (M2a) Version 3.3 (TLS 1.2) ServerNonce: Random[28] + GMT_seconds[4] SessionID: 0x945D6F22 ChosenCipherSuite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA ServerCertificateChain (M2b) Subject: AltName=www.some.com Public Key:... (= DSS KV SRV ) Issuer: DN=Verisign... ServerKeyExchange (M2c) ServerDHParams: dh_p, dh_g, dh_ys DSS_sign(KS SRV, ClientNonce ServerNonce ServerDHParams) ServerHelloDone (M2d) (Client can proceed with next handshake phase) Octavian Catrina 18

DH+DSS KE with server authentication 2/2 Client ClientKeyExchange (M3a) ClientDiffieHellmanPublic: dh_yc ChangeCipherSpec (M3b) (Further traffic starting with next message will be protected under agreed cipher suite and keys) ClientFinished (M3c) PRF(master_secret, "client finished", Hash(handshake_msgs)) where handshake_msgs = M1 M2 M3a Server Server actions after receiving M3: - Generate pre_master_secret = (dh_yc) dh_xs mod dh_p. - Generate secrets from pre_master_secret exactly like the client: a master_secret and then client-write-mac, server-write-mac, client-write-key, server-write-key, client-write-iv, server-write-iv - Apply client-write parameters to read M3c and all subsequent messages (encrypted and authenticated). - Verify PRF (MAC) in M3c (authenticates all handshake messages, confirms that the client knows the keys, etc.). - Apply server-write parameters to write M4b and all subsequent messages (encrypted and authenticated). Client actions after receiving M4: - Apply server-write parameters to read M4b and all subsequent messages (encrypted and authenticated). - Verify PRF (MAC) in M4b (authenticates handshake messages, confirms that server knows the keys, etc.). ChangeCipherSpec (M4a) (Further traffic starting with next message will be protected under agreed cipher suite and keys) ServerFinished (M4b) PRF(master_secret, "server finished", Hash(handshake-msgs)) where handshake_msgs = M1 M2 M3a M3c The Hash value in ClientFinished and ServerFinished is computed on the concatenation of previous TLS Handshake protocol messages (without ChangeCipherSpec, alerts, etc.). Octavian Catrina 19

RSA KE with mutual authentication 1/2 Client Server ClientHello (M1) Version: 3.3 (TLS 1.2) ClientNonce: Random[28] + GMT_seconds[4] SuggestedCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA, Client actions after receiving M2: - Validate the server s certificate chain. - Generate random pre_master_secret (48 bytes). - Generate secrets from pre_master_secret: - Compute master_secret = PRF(pre_master_secret, "master secret" ClientNonce ServerNonce) key_block = PRF(master_secret, "key expansion" ClientNonce ServerNonce) - Take successive bytes from key_block for: client-write-mac, server-write-mac, client-write-key, server-write-key, client-write-iv, server-write-iv - By sending the (optional) CertificateRequest the server asks the client to authenticate using a digital signature. - Construct and send next messages... KE SRV = Server's RSA public (encryption) key. KV CLI = Client's RSA public (verification) key. KS CLI = Client's RSA private (signing) key. Server actions after receiving M1: - Select cipher suite. - Construct and send next messages... ServerHello (M2a) Version 3.3 (TLS 1.2) ServerNonce: Random[28] + GMT_seconds[4] SessionID: 0x35DD84F0 ChosenCipherSuite: TLS_RSA_WITH_AES_128_CBC_SHA256 ServerCertificateChain (M2b) Subject: DN=BigBankHomeBkgDiv Public Key:... (RSA KE SRV ) Issuer: DN=BigBank... Subject: DN=BigBank Public Key: 0xD9783BB2208F3... Issuer: DN=Verisign... CertificateRequest (M2c) Type: RSA_signing AcceptableCAs: BigBankHomeBkgDiv ServerHelloDone (M2d) (Client can proceed with next handshake phase) Octavian Catrina 20

RSA KE with mutual authentication 2/2 Client Server ClientCertificateChain (M3a) Subject: DN = Alice Public Key:... (RSA KV CLI ) Issuer: DN = BigBankHomeBkgDiv... ClientKeyExchange (M3b) RSA_encrypt(KE SRV, pre_master_secret) CertificateVerify (M3c) RSA_sign(KS CLI, handshake_msgs) where handshake_msgs = M1 M2 M3a M3b ChangeCipherSpec (M3d) (Further traffic starting with next message will be protected using agreed cipher suite and keys) ClientFinished (M3e) PRF(master_secret, "client finished", Hash(handshake_msgs)) where handshake_msgs = M1 M2 M3a M3b M3c Client actions after receiving M4: - Apply server-write parameters to read M4b and all subsequent messages (encrypted and authenticated). - Verify PRF (MAC) in M4b (authenticates handshake messages, confirms that server knows the keys, implicitly authenticates the server, etc.). Server actions after receiving M3: - Authenticate the client: Verify the client's certificate chain and the client's signature in M3c. - Decrypt pre_master_secret from M3b. - Generate secrets from pre_master_secret exactly like the client: a master_secret and client-write-mac, server-write-mac, client-write-key, server-write-key, client-write-iv, server-write-iv - Apply client-write parameters to read M3e and all the subsequent messages (encrypted and authenticated). - Verify PRF (MAC) in M3e (authenticates handshake messages, confirms that client knows they keys, etc.). - Construct and send last messages... ChangeCipherSpec (M4a) (Further traffic starting with next message will be protected using agreed cipher suite and keys) ServerFinished (M4b) PRF(master_secret, "server finished", Hash(handshake_msgs)) where handshake_msgs = M1 M2 M3a M3b M3c M3e Octavian Catrina 21

HTTP+TLS and Password authentication Example: Access to an on-line digital library, restricted to subscribers. (1) TLS connection setup Server authentication and confidentiality (2) User authentication User-id and Password transferred using the secured connection Octavian Catrina 22

Resuming a session Client E.g., new TLS connection, for other op with same server after setting up a TLS session. Server ClientHello (M1) Version 3.3 ClientNonce: Random[28] + GMT_seconds[4] SuggestedCipherSuites: TLS_DHE_DSS_WITH_AES_128_CBC_SHA SessionID: 0x945D6F22 (previously established) ChangeCipherSpec (M3a) Server and client update key_block using the session's master_secret and the new nonces. (Further traffic starting with next message will be protected under agreed cipher suite and keys) ServerHello (M2a) Version 3.3 ServerNonce: Random[28] + GMT_seconds[4] SessionID: 0x945D6F22 ChosenCipherSuite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA ChangeCipherSpec (M2b) (Further traffic starting with next message will be protected under agreed cipher suite and keys) ServerFinished (M2c) PRF(master_secret, "server finished, Hash(handshake_msgs)) where handshake_msgs = M1 M2a ClientFinished (M3b) PRF(master_secret, "client finished, Hash(handshake_msgs)) where handshake_msgs = M1 M2a M2c Octavian Catrina 23