IPsec and SSL/TLS - Cryptography 2, Part 2, Lecture 5

/ department of mathematics and computer science

IPsec and SSL/TLSCryptography 2, Part 2, Lecture 5

Ruben Niederhagen

June 2nd, 2014

2/38


Cryptography in the TCP/IP stack

application layer

transport layer

network layer

data-link layer

physical layer

Alice

application layer

transport layer

network layer

data-link layer

physical layer

Bob

application data (HTTP, SMTP...)

session (TCP, UDP, ...)

IP packets

frames

I application layer security (SSH, S-MIME, PGP, . . . )I transport layer security (TLS/SSL, . . . )I network layer security (IPsec, . . . )I data-link layer security (WEP, WPA, WPA2, . . . )

3/38


Data-Link Layer Security

data-link layer security

I encrypt all network packets between network links, e.g., WAP2I point-to-point security between network interfacesI transparent encryption and decryption for higher layersI authentication between endpoints

4/38


Network Layer Security

LAN router ISP router

Internet

network layer security

I encrypt IP packets, main protocol IPsecI point-to-point security between entities identified by IP addresses,e.g. routers, firewalls

I routers encrypt and decrypt unnoticed by higher layersI authentication of routers to each other

5/38


Transport Layer Security

Internet

web server application server

transport layer security

I encrypt sessions and messages, e.g. TLS/SSLI communication between web browser and server,or email clients and servers

I entities identified by connections, port numbersI encrypt and authenticate sessions

6/38


Transport Layer Security

mail server

Internet

mail server

SMTP


IMAP


7/38


Application Layer Security

mail server

Internet

mail server

application layer security

I add security to standard message formats (e.g. S/MIME)I for email: entire link between two user mail clients is protectedI authentication of sender and dataI end users have control over their keys(but need to know what they are doing, how to use PKI)

I end-to-end security

8/38


Network Layer SecurityIPsec

9/38


IPsec

IP packet: IP header IP data (payload)

IPsec was mandatory for IPv6 and is now optional; optional for IPv4.

IPsec provides cryptographic functionality to protect IP packets:I packet integrity,I packet origin authentication,I confidentiality,I some traffic flow confidentiality,I protection against replay attacks.

IPsec protocolsI AH - Authentication Header,I ESP - Encapsulating Security Payload.

10/38


IPsec - crypto algorithms

See RFC4835I Encryption: block ciphers in Cipher Block Chaining (CBC) mode.Must have:

• no encryption,• AES-CBC with 128-bit keys,• TripleDES-CBC (168-bit keys).

I Message authentication/integrity: Hash-based MessageAuthentication Code (HMAC),Must have:

• HMAC-SHA1-96.May have:

• HMAC-MD5-96.

These are symmetric algorithms, need a pre-shared secret key.

11/38


IPsec – Security Associations

I Concept to formalize unidirectional security relationships betweentwo parties.

I Enforce security policy defined in Security Policy Database (SPDB).I Security Association Database (SADB) contains list of active securityassociations (SA).

SA parameters:I sequence number, sequence number overflow,I anti-replay window,I AH information: authentication algorithm, key, key lifetime, etc.,I ESP information: encryption algorithm, key, key lifetime, etc.,I lifetime of the SA,I IPsec protocol mode (tunnel, transport, see below),I maximal packet size.

12/38


IPsec – Security Associations

The Security Policy Database describes how to treat certain IP packets(BYPASS, DISCARD, PROTECT).Which SA to use for certain traffic is derived from selectors such as

I destination IP address,I source IP address,I transport layer protocol,I source and destination ports.

Most selectors are read off from the IP packet (headers).

A security association can be usedI for one communication direction (bidirectional needs two SAs),I for AH or ESP; can be combined, e.g. ESP then AH.

SAs are negotiated by public-key mechanisms (see below).

13/38


IPsec – Modes of Operation

Transport mode:I only the payload of the IP packet is protected,I header is not encrypted in ESP, parts of it are authenticated in AH,I data is protected from source to destination,I header information is completely in the clear,I used only between hosts.

Tunnel mode:I entire IP packet is protected (i.e. IP header and data),I becomes the payload of a new IP packet,I may contain different source and destination addresses,I provides data flow confidentiality to some extent,I can be used between hosts, gateways or host-gateway.

14/38



host gateway

Internet

gateway host

transport mode

host

Internet

gateway

local network

tunnel mode

14/38



host gateway

Internet

gateway host

transport mode

local network

gateway

Internet

gateway

local network

tunnel mode

15/38


IPsec – Authentication HeaderThe Authentication Header provides

I data integrity,I authentication of IP packets,I protection against replay attacks.

First two by use of a Message Authentication Code (MAC),e.g. HMAC-SHA1-96.

IP packet is expanded with an AH that contains items such as:I next header — type of the header following this header,I payload length — length of AH,I Security Parameter Index (SPI) — identifies a SA,I sequence number,I authentication data — contains the MAC of the packet,also called Integrity Check Value (ICV).

16/38


IPsec – Authentication Header

IP DataIP Header

Protocol6

TCPHeader

TCP Segment Data

ICV (truncated HMAC) is computed over:

I immutable IP header fields (fields that do not change in transit),e.g., source address, IP header length,

I Auth. Header (except authentication data field),I IP data.

Excluded fields are set to zero for HMAC computation.

16/38



IP DataAuth. Header

Next Header6

IP Header

Protocol51

Authenticated Fields

IPSec Transport Mode

TCPHeader

TCP Segment Data





16/38



original IP Datagram (encapsulated)Auth. Header

Next Header4

IP Header

Protocol51


IP DataIP Header

Protocol6

IPSec Tunnel Mode

TCPHeader

TCP Segment Data





17/38



Anti-replay protection prevents resending copies of authenticated packets.

I Uses sequence number field.I For each new SA, sequence counter set to 0.I Keep track of overflow (sequence number is 32 bits),negotiate new SA when counter reaches 232 − 1.

I Check whether counter is in window of fixed size.I Right edge = highest sequence number so far received(with valid authentication).

I Mark numbers of received packets with valid authentication.I Advance window if new sequence number falls to the right of windowand packet authenticates.

I Discard packet if number falls to the left of window or packet doesnot authenticate.

18/38


IPsec – Encapsulating Security Payload

The Encapsulating Security Payload provides:I confidentiality, i.e. encryption with block cipher in CBC mode, e.g.AES-CBC,

I functionality as in AH like authentication, anti-replay (optional).ESP adds an ESP header, encrypts the payload and adds an ESP trailer.An ESP packet contains:

I security parameter index (SPI),I sequence number,I payload data (encrypted),I padding – to achieve data length a multiple of 32 bits (encrypted),I padding length (encrypted),I next header (encrypted),I (optional) authentication data.

19/38



IP DataIP Header

Protocol6

TCPHeader

TCP Segment Data

I In transport mode, only data is encrypted,i.e. source and destination are in the clear.

I In tunnel mode, the whole package is encrypted,i.e. real source and destination addresses are hidden.

I Authentication not over IP header fields, only ESP header and data.

19/38



IP DataESP Header ESP Trailer

Next Header6

ESP Auth.DataIP Header

Protocol50

Encrytped Fields


IPSec Transport Mode

TCPHeader

TCP Segment Data




19/38



original IP Datagram (encapsulated and encrypted)ESP Header ESP Trailer

Next Header4

ESP Auth.DataIP Header

Protocol50

Encrytped Fields


IP DataIP Header

Protocol6

IPSec Tunnel Mode

TCPHeader

TCP Segment Data




20/38


Combining Security Associations

Using ESP in encryption-only mode is insecure:I manipulate data of inner encrypted IP packets,I use padding checks to build an ESP trailer oracle.

Degabriele/Paterson Attacking the IPsec Standards in Encryption-onlyConfigurations, IEEE Symposium on Security and Privacy 2007

Recall: SA can be combined for AH and ESP if ESP Auth. unavailable.I For protecting communication against active adversary,need authenticated encryption (gives CCA security).

I AH covers more header fields than authentication in ESP,in particular source and destination addresses in the IP header.

I Can do encrypt-then-MAC, i.e. first ESP then AH in transport mode,this gives authenticated encryption.

21/38


Internet Key Exchange (IKE)

Provides key management for IPsec via public-key crypto.AH and ESP need security associations and secret keys.

IKE consists of:I Oakley Key Determination Protocol,based on Diffie-Hellman key exchange,

I Internet Security Association and Key Management Protocol(ISAKMP), framework for key management and negotiation of SAs.

IKE has two phases:I Phase 1: negotiate security association to establish secureauthenticated communication channel.

I Phase 2: establish SAs for other services such as AH, ESP.

22/38


Transport Layer SecuritySSL/TLS

23/38


SSL/TLS

Secure Sockets Layer (SSL) and Transport Layer Security (TLS):I TLS is a variant of SSLv3,I SSL originally designed for web environment by Netscape,I design goals: security of web traffic, email, etc.,I had to work well with HTTP,I provides transparency for higher layers.

SSL/TLS provides a secure channel between server and client:I confidentialityI server/client authenticationI message integrity

24/38


SSL/TLS

SSL/TLS runs on top of TCP:I Transparent for application layer protocols,I SSL/TLS connection acts like a secured TCP connection,I most protocols running over TCP can be run over SSL/TLS instead,e.g., HTTP → HTTPS, SMTP → SMTPS, . . .

Protocols in SSL/TLS:I Handshake Protocol: initiate session.Authenticate server/client, establish keys.

I Record Protocol: data transfer.Compute MAC for integrity, encrypt MAC and data.

I Alert Protocol: alert the other side of exceptional conditions.E.g., errors and warnings.

25/38


SSL/TLS Handshake

I Client → Server: ClientHello• ClientRandom: random number,• Session ID (when resuming a session),• List of available CipherSuites:pk key exchange, pk auth, sym encryption, hash alg.

Example: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

ECDH Elliptic curve Diffie Hellman key exchange.ECDSA Elliptic curve digital signature algorithm.AES_128_CBC AES with 128-bit key in CBC mode.SHA256 SHA with 256-bit output for HMAC.

26/38


SSL/TLS Handshake (cont.)

I Server → Client: ServerHello• ServerRandom: random number,• Session ID: implementation specific, random number,• Chosen CipherSuite.

I Server → Client: Certificate• Server sends server certificate to client,client obtains server’s public key and verifies certificate.

I Server → Client: ServerKeyExchangefor DHE: Pa, random a,for ECDHE: [a]P , random a,for RSA: –

I Server → Client: ServerHelloDone• Message marks end of server messages.

27/38



I Client → Server: ClientKeyExchangefor DHE: Pb, random b,for ECDHE: [b]P , random b,for RSA: random value encrypted with server public key.

I Client → Server: ChangeCipherSpec• Notify that client switched to new CipherSuite.

I Client → Server: Finished• Encrypted Finished massaged contaning hash over the previoushandshake messages.

Client and server compute Pab or [ab]P respectively.

28/38



I Server → Client: ChangeCipherSpec• Notify that client switched to new CipherSuite.

I Server → Client: Finished• Encrypted Finished massaged contaning hash over the previoushandshake messages.

Interrupted session can be resumed:I Server and client are supposed to store session ID and MasterSecret,I client sends session ID in ClientHello,I reduced protocol: Hello, ChangeCipherSpec and Finished messages,I new keying data is exchanged,I new session keys are derived.

29/38


SSL/TLS Record Protocol

Record protocol to exchange encrypted and authenticated data:I Payload data is split into fragmentswhich are protected and transmitted independently;when received, fragments are decrypted and verified independently.

I Each fragment is authenticated with a MAC which is appended;MAC is over a sequential number (anti-replay) and the content.

I Data fragment and MAC are encrypted.I A record header is attached to the encrypted data,containing information necessary for interpreting the recordsuch as type of data (e.g. Handshake or ApplicationData),length, and SSL version.

I (header || encrypted fragment and MAC) is sent.

30/38


Padding Oracle Attack

TLS prior to version 1.1 was susceptible to a padding oracle attack;TLS today has trouble with the “Lucky 13” attack.

I Before encrypting with AES-CBC,need to pad data||MAC-tag to the AES block size (16 bytes).

I The padding sets each byte in the pad to the pad length,i.e., padding has specific format.

At the server side on receipt of an encrypted record:I decrypt record with the client encryption key,I check pad format,if not valid, return decryption_failed alert,

I if pad format okay, check MAC on fragmentif does not verify, return bad_record_mac alert.

This introduced different types of errors that an attacker can distinguish.

31/38


Padding Oracle Attack

Padding oracle:I Attacker submits ciphertexts of choice,I learns whether the last bytes of a plaintext are a valid pad;I if not valid, server returns decryption_failed,I if valid, server returns bad_record_mac.

Gives rise to a chosen-ciphertext attack!

32/38


Padding oracle attack on CBC encryption

CBC mode encryption: CBC mode decryption:I C0 = IV

I Ci = EK (Ci−1 ⊕Mi ).

I C0 = IV ,I Mi = DK (Ci )⊕ Ci−1.

Suppose an attacker wants to find M2 from ciphertext (C0,C1,C2, . . . )

I M2 = DK (C2)⊕ C1.I Guess the last byte of M2 to be g ,I compute C ′1 = C1 ⊕ 00| . . . |00|g ⊕ 00| . . . |00|01,I submit C = (C ′1,C2) to the server and wait for response.I If g is the last byte of M2, the decryption of C will have a valid pad;I if not, the pad will not be valid,I try all 256 possible bytes for g until the correct one g0 is found.I Go on using C ′1 = C1 ⊕ 00| . . . |00|g |g0 ⊕ 00| . . . |00|02|02.

32/38





I C0 = IV ,I Mi = DK (Ci )⊕ Ci−1.


I M2 = DK (C2)⊕ C1.

I Guess the last byte of M2 to be g ,I compute C ′1 = C1 ⊕ 00| . . . |00|g ⊕ 00| . . . |00|01,I submit C = (C ′1,C2) to the server and wait for response.I If g is the last byte of M2, the decryption of C will have a valid pad;I if not, the pad will not be valid,I try all 256 possible bytes for g until the correct one g0 is found.I Go on using C ′1 = C1 ⊕ 00| . . . |00|g |g0 ⊕ 00| . . . |00|02|02.

32/38





I C0 = IV ,I Mi = DK (Ci )⊕ Ci−1.


I M2 = DK (C2)⊕ C1.I Guess the last byte of M2 to be g ,I compute C ′1 = C1 ⊕ 00| . . . |00|g ⊕ 00| . . . |00|01,I submit C = (C ′1,C2) to the server and wait for response.

I If g is the last byte of M2, the decryption of C will have a valid pad;I if not, the pad will not be valid,I try all 256 possible bytes for g until the correct one g0 is found.I Go on using C ′1 = C1 ⊕ 00| . . . |00|g |g0 ⊕ 00| . . . |00|02|02.

32/38





I C0 = IV ,I Mi = DK (Ci )⊕ Ci−1.


I M2 = DK (C2)⊕ C1.I Guess the last byte of M2 to be g ,I compute C ′1 = C1 ⊕ 00| . . . |00|g ⊕ 00| . . . |00|01,I submit C = (C ′1,C2) to the server and wait for response.I If g is the last byte of M2, the decryption of C will have a valid pad;I if not, the pad will not be valid,I try all 256 possible bytes for g until the correct one g0 is found.

I Go on using C ′1 = C1 ⊕ 00| . . . |00|g |g0 ⊕ 00| . . . |00|02|02.

32/38





I C0 = IV ,I Mi = DK (Ci )⊕ Ci−1.


I M2 = DK (C2)⊕ C1.I Guess the last byte of M2 to be g ,I compute C ′1 = C1 ⊕ 00| . . . |00|g ⊕ 00| . . . |00|01,I submit C = (C ′1,C2) to the server and wait for response.I If g is the last byte of M2, the decryption of C will have a valid pad;I if not, the pad will not be valid,I try all 256 possible bytes for g until the correct one g0 is found.I Go on using C ′1 = C1 ⊕ 00| . . . |00|g |g0 ⊕ 00| . . . |00|02|02.

33/38



block cipherdecryption

Key

Plaintext

Ciphertext

Initialization Vector (IV)


Key

Plaintext

Ciphertext

33/38




Key

Plaintext

Ciphertext



Key

Plaintext

Ciphertext⊕g ⊕ 01

01

33/38




Key

Plaintext

Ciphertext



Key

Plaintext

Ciphertext⊕g ⊕ 02 | ⊕ g0 ⊕ 02

02|02

34/38



I For AES we can find one plaintext block with at most 16 · 256chosen ciphertext queries to the padding oracle.

I More complicated in practice: In case of invalid record, session isterminated, new keys need to be negotiated.

I Still valid attack if the same message is encrypted in various sessions.I Example: IMAP over TLS: every few minutes client sends usernameand password to login.

I Compute password within a few hours.

35/38



Solutions:I Make alert message and time the same in both cases.I RFCs: always perform a MAC check as if zero-length padding isapplied. "Small timing channel": Lucky 13

I Encrypt-then-MAC avoids the problem because change is detectedbefore decryption.

I MAC-then-CBC is authenticated encryption, but padding oracledestroys it.

36/38


OpenSSL Heartbleed Bug

Bug in the implementation of the Heartbeat Extension (RFC 6520):

struct {HeartbeatMessageType type;uint16 payload_length;opaque payload[HeartbeatMessage.payload_length];opaque padding[padding_length];

} HeartbeatMessage;

[...]When a HeartbeatRequest message is received [...],the receiver MUST send a corresponding HeartbeatResponsemessage carrying an exact copy of the payload of the receivedHeartbeatRequest.

OpenSSL failed to check actual length of payload data.

37/38


OpenSSL Heartbleed Bug

38/38


Which SSL/TLS Cipher Suites to use?

Don’t use NULL, EXPORT.

38/38



Don’t use DES, MD5.

38/38



Don’t use RC4, CBC.

38/38



Don’t use anonymous and PSK.

38/38



Use ephemeral key exchange!

38/38



Be careful with DSS/ECDSA.

IPsec and SSL/TLS - Cryptography 2, Part 2, Lecture 5

Documents

Transcript of IPsec and SSL/TLS - Cryptography 2, Part 2, Lecture 5