Ipsec and SSL/TLS Cryptography 2, Part 2, Lecture 5

Home , Data link layer, IPsec, Network layer, Physical layer

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

Ruben Niederhagen

June 2nd, 2014 / department of mathematics and computer science 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, ... )

Cryptography in the TCP/IP stack 2/38

application layer application data (HTTP, SMTP...) application layer

transport layer session (TCP, UDP, ...) transport layer

network layer IP packets network layer

data-link layer frames data-link layer

physical layer physical layer

Alice Bob

/ department of mathematics and computer science Cryptography in the TCP/IP stack 2/38

application layer application data (HTTP, SMTP...) application layer

transport layer session (TCP, UDP, ...) transport layer

network layer IP packets network layer

data-link layer frames data-link layer

physical layer physical layer

Alice Bob

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, ... )

/ department of mathematics and computer science data-link layer security

Data-Link Layer Security 3/38

I encrypt all network packets between network links, e.g., WAP2

I point-to-point security between network interfaces

I transparent encryption and decryption for higher layers

I authentication between endpoints

/ department of mathematics and computer science Data-Link Layer Security 3/38

data-link layer security

I encrypt all network packets between network links, e.g., WAP2

I point-to-point security between network interfaces

I transparent encryption and decryption for higher layers

I authentication between endpoints

/ department of mathematics and computer science network layer security

Network Layer Security 4/38

Internet LAN router ISP router

I encrypt IP packets, main protocol IPsec

I point-to-point security between entities identiﬁed by IP addresses, e.g. routers, ﬁrewalls

I routers encrypt and decrypt unnoticed by higher layers

I authentication of routers to each other

/ department of mathematics and computer science Network Layer Security 4/38

network layer security

Internet LAN router ISP router

I encrypt IP packets, main protocol IPsec

I point-to-point security between entities identiﬁed by IP addresses, e.g. routers, ﬁrewalls

I routers encrypt and decrypt unnoticed by higher layers

I authentication of routers to each other

/ department of mathematics and computer science transport layer security

Transport Layer Security 5/38

Internet

web server application server

I encrypt sessions and messages, e.g. TLS/SSL

I communication between web browser and server, or email clients and servers

I entities identiﬁed by connections, port numbers

I encrypt and authenticate sessions

/ department of mathematics and computer science Transport Layer Security 5/38

transport layer security

Internet

web server application server

I encrypt sessions and messages, e.g. TLS/SSL

I communication between web browser and server, or email clients and servers

I entities identiﬁed by connections, port numbers

I encrypt and authenticate sessions

/ department of mathematics and computer science Transport Layer Security 5/38

transport layer security

Internet

web server application server

I encrypt sessions and messages, e.g. TLS/SSL

I communication between web browser and server, or email clients and servers

I entities identiﬁed by connections, port numbers

I encrypt and authenticate sessions

/ department of mathematics and computer science SMTP

transport layer security

IMAP

transport layer security

Transport Layer Security 6/38

mail server

Internet

mail server

/ department of mathematics and computer science Transport Layer Security 6/38

SMTP

transport layer security

mail server

Internet

IMAP

transport layer security

mail server

/ department of mathematics and computer science Transport Layer Security 6/38

SMTP

transport layer security

mail server

Internet

IMAP

transport layer security

mail server

/ department of mathematics and computer science application layer security

Application Layer Security 7/38

Internet

mail server mail server

I add security to standard message formats (e.g. S/MIME)

I for email: entire link between two user mail clients is protected

I authentication of sender and data

I end users have control over their keys (but need to know what they are doing, how to use PKI)

I end-to-end security

/ department of mathematics and computer science Application Layer Security 7/38

application layer security

Internet

mail server mail server

I add security to standard message formats (e.g. S/MIME)

I for email: entire link between two user mail clients is protected

I authentication of sender and data

I end users have control over their keys (but need to know what they are doing, how to use PKI)

I end-to-end security

/ department of mathematics and computer science 8/38

Network Layer Security IPsec

/ department of mathematics and computer science IPsec 9/38

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 conﬁdentiality,

I some traffic flow confidentiality,

I protection against replay attacks. IPsec protocols

I AH - Authentication Header,

I ESP - Encapsulating Security Payload.

/ department of mathematics and computer science I Message authentication/integrity: Hash-based Message Authentication Code (HMAC), Must have: • HMAC-SHA1-96. May have: • HMAC-MD5-96. These are symmetric algorithms, need a pre-shared secret key.

IPsec - crypto algorithms 10/38

See RFC4835

I Encryption: block ciphers in Cipher Block Chaining (CBC) mode. Must have: • no encryption, • AES-CBC with 128-bit keys, • TripleDES-CBC (168-bit keys).

/ department of mathematics and computer science These are symmetric algorithms, need a pre-shared secret key.

IPsec - crypto algorithms 10/38

See RFC4835

I 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 Message Authentication Code (HMAC), Must have: • HMAC-SHA1-96. May have: • HMAC-MD5-96.

/ department of mathematics and computer science IPsec - crypto algorithms 10/38

See RFC4835

I 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 Message Authentication Code (HMAC), Must have: • HMAC-SHA1-96. May have: • HMAC-MD5-96. These are symmetric algorithms, need a pre-shared secret key.

/ department of mathematics and computer science SA parameters:

I sequence number, sequence number overﬂow,

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.

IPsec – Security Associations 11/38

I Concept to formalize unidirectional security relationships between two parties.

I Enforce security policy deﬁned in Security Policy Database (SPDB).

I Security Association Database (SADB) contains list of active security associations (SA).

/ department of mathematics and computer science IPsec – Security Associations 11/38

I Concept to formalize unidirectional security relationships between two parties.

I Enforce security policy deﬁned in Security Policy Database (SPDB).

I Security Association Database (SADB) contains list of active security associations (SA). SA parameters:

I sequence number, sequence number overﬂow,

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.

/ department of mathematics and computer science A security association can be used

I 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).

IPsec – Security Associations 12/38

The Security Policy Database describes how to treat certain IP packets (BYPASS, DISCARD, PROTECT). Which SA to use for certain traﬃc 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 oﬀ from the IP packet (headers).

/ department of mathematics and computer science IPsec – Security Associations 12/38

The Security Policy Database describes how to treat certain IP packets (BYPASS, DISCARD, PROTECT). Which SA to use for certain traﬃc 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 oﬀ from the IP packet (headers).

A security association can be used

I 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).

/ department of mathematics and computer science 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 diﬀerent source and destination addresses,

I provides data ﬂow conﬁdentiality to some extent,

I can be used between hosts, gateways or host-gateway.

IPsec – Modes of Operation 13/38

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.

/ department of mathematics and computer science IPsec – Modes of Operation 13/38

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 diﬀerent source and destination addresses,

I provides data ﬂow conﬁdentiality to some extent,

I can be used between hosts, gateways or host-gateway.

/ department of mathematics and computer science IPsec – Modes of Operation 14/38

transport mode

Internet

host gateway gateway host

tunnel mode Internet local network

host gateway

/ department of mathematics and computer science IPsec – Modes of Operation 14/38

transport mode

Internet

host gateway gateway host

tunnel mode local network Internet local network

gateway gateway

/ department of mathematics and computer science IPsec – Authentication Header 15/38 The 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) — identiﬁes a SA,

I sequence number,

I authentication data — contains the MAC of the packet, also called Integrity Check Value (ICV).

/ department of mathematics and computer science IPsec – Authentication Header 16/38

TCP Protocol TCP Segment Data 6 Header

IP Header IP Data

ICV (truncated HMAC) is computed over:

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

I Auth. Header (except authentication data ﬁeld),

I IP data. Excluded ﬁelds are set to zero for HMAC computation.

/ department of mathematics and computer science IPsec – Authentication Header 16/38

IPSec Transport Mode

TCP Protocol Next Header TCP Segment Data 51 6 Header

IP Header Auth. Header IP Data

Authenticated Fields

ICV (truncated HMAC) is computed over:

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

I Auth. Header (except authentication data ﬁeld),

I IP data. Excluded ﬁelds are set to zero for HMAC computation.

/ department of mathematics and computer science IPsec – Authentication Header 16/38

IPSec Tunnel Mode

Protocol Next Header Protocol TCP 51 4 TCP Segment Data 6 Header

IP Header IP Data

IP Header Auth. Header original IP Datagram (encapsulated)

Authenticated Fields

ICV (truncated HMAC) is computed over:

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

I Auth. Header (except authentication data ﬁeld),

I IP data. Excluded ﬁelds are set to zero for HMAC computation.

/ department of mathematics and computer science IPsec – Authentication Header 17/38

Anti-replay protection prevents resending copies of authenticated packets.

I Uses sequence number ﬁeld.

I For each new SA, sequence counter set to 0.

I Keep track of overﬂow (sequence number is 32 bits), negotiate new SA when counter reaches 232 − 1.

I Check whether counter is in window of ﬁxed 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 window and packet authenticates.

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

/ department of mathematics and computer science IPsec – Encapsulating Security Payload 18/38

The Encapsulating Security Payload provides:

I conﬁdentiality, 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.

/ department of mathematics and computer science IPsec – Encapsulating Security Payload 19/38

TCP Protocol TCP Segment Data 6 Header

IP Header IP 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 ﬁelds, only ESP header and data.

/ department of mathematics and computer science IPsec – Encapsulating Security Payload 19/38

IPSec Transport Mode

TCP Protocol TCP Segment Data Next Header 50 Header 6 ESP Auth. IP Header ESP Header IP Data ESP Trailer Data

Encrytped Fields

Authenticated Fields

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 ﬁelds, only ESP header and data.

/ department of mathematics and computer science IPsec – Encapsulating Security Payload 19/38

IPSec Tunnel Mode

Protocol Next Header Protocol TCP 50 TCP Segment Data 4 6 Header

IP Header IP Data ESP Auth. IP Header ESP Header original IP Datagram (encapsulated and encrypted) ESP Trailer Data

Encrytped Fields

Authenticated Fields

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 ﬁelds, only ESP header and data.

/ department of mathematics and computer science 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 ﬁelds than authentication in ESP, in particular source and destination addresses in the IP header.

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

Combining Security Associations 20/38

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-only Conﬁgurations, IEEE Symposium on Security and Privacy 2007

/ department of mathematics and computer science Combining Security Associations 20/38

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-only Conﬁgurations, 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 ﬁelds than authentication in ESP, in particular source and destination addresses in the IP header.

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

/ department of mathematics and computer science IKE has two phases:

I Phase 1: negotiate security association to establish secure authenticated communication channel.

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

Internet Key Exchange (IKE) 21/38

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 Diﬃe-Hellman key exchange,

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

/ department of mathematics and computer science Internet Key Exchange (IKE) 21/38

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 Diﬃe-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 secure authenticated communication channel.

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

/ department of mathematics and computer science 22/38

Transport Layer Security SSL/TLS

/ department of mathematics and computer science SSL/TLS provides a secure channel between server and client:

I conﬁdentiality

I server/client authentication

I message integrity

SSL/TLS 23/38

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 traﬃc, email, etc.,

I had to work well with HTTP,

I provides transparency for higher layers.

/ department of mathematics and computer science SSL/TLS 23/38

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 traﬃc, 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 conﬁdentiality

I server/client authentication

I message integrity

/ department of mathematics and computer science 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.

SSL/TLS 24/38

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, . . .

/ department of mathematics and computer science SSL/TLS 24/38

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.

/ department of mathematics and computer science SSL/TLS Handshake 25/38

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 Diﬃe 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.

/ department of mathematics and computer science SSL/TLS Handshake (cont.) 26/38

I Server → Client: ServerHello • ServerRandom: random number, • Session ID: implementation speciﬁc, 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: ServerKeyExchange for DHE: Pa, random a, for ECDHE: [a]P, random a, for RSA: –

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

/ department of mathematics and computer science SSL/TLS Handshake (cont.) 27/38

I Client → Server: ClientKeyExchange for 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 previous handshake messages.

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

/ department of mathematics and computer science 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.

SSL/TLS Handshake (cont.) 28/38

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

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

/ department of mathematics and computer science SSL/TLS Handshake (cont.) 28/38

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

I Server → Client: Finished • Encrypted Finished massaged contaning hash over the previous handshake 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.

/ department of mathematics and computer science SSL/TLS Record Protocol 29/38

Record protocol to exchange encrypted and authenticated data:

I Payload data is split into fragments which are protected and transmitted independently; when received, fragments are decrypted and veriﬁed 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 record such as type of data (e.g. Handshake or ApplicationData), length, and SSL version.

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

/ department of mathematics and computer science 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 fragment if does not verify, return bad_record_mac alert. This introduced diﬀerent types of errors that an attacker can distinguish.

Padding Oracle Attack 30/38

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 speciﬁc format.

/ department of mathematics and computer science Padding Oracle Attack 30/38

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 speciﬁc 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 fragment if does not verify, return bad_record_mac alert. This introduced diﬀerent types of errors that an attacker can distinguish.

/ department of mathematics and computer science Padding Oracle Attack 31/38

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!

/ department of mathematics and computer science Suppose an attacker wants to ﬁnd M2 from ciphertext (C0, C1, C2,... )

I M2 = DK (C2) ⊕ C1.

I Guess the last byte of M2 to be g, 0 I compute C1 = C1 ⊕ 00| ... |00|g ⊕ 00| ... |00|01, 0 I submit C = (C1, 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. 0 I Go on using C1 = C1 ⊕ 00| ... |00|g|g0 ⊕ 00| ... |00|02|02.

Padding oracle attack on CBC encryption 32/38

CBC mode encryption: CBC mode decryption:

I C0 = IV I C0 = IV ,

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

/ department of mathematics and computer science I Guess the last byte of M2 to be g, 0 I compute C1 = C1 ⊕ 00| ... |00|g ⊕ 00| ... |00|01, 0 I submit C = (C1, 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. 0 I Go on using C1 = C1 ⊕ 00| ... |00|g|g0 ⊕ 00| ... |00|02|02.

Padding oracle attack on CBC encryption 32/38

CBC mode encryption: CBC mode decryption:

I C0 = IV I C0 = IV ,

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

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

I M2 = DK (C2) ⊕ C1.

/ department of mathematics and computer science 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. 0 I Go on using C1 = C1 ⊕ 00| ... |00|g|g0 ⊕ 00| ... |00|02|02.

Padding oracle attack on CBC encryption 32/38

CBC mode encryption: CBC mode decryption:

I C0 = IV I C0 = IV ,

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

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

I M2 = DK (C2) ⊕ C1.

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

/ department of mathematics and computer science 0 I Go on using C1 = C1 ⊕ 00| ... |00|g|g0 ⊕ 00| ... |00|02|02.

Padding oracle attack on CBC encryption 32/38

CBC mode encryption: CBC mode decryption:

I C0 = IV I C0 = IV ,

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

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

I M2 = DK (C2) ⊕ C1.

I Guess the last byte of M2 to be g, 0 I compute C1 = C1 ⊕ 00| ... |00|g ⊕ 00| ... |00|01, 0 I submit C = (C1, 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.

/ department of mathematics and computer science Padding oracle attack on CBC encryption 32/38

CBC mode encryption: CBC mode decryption:

I C0 = IV I C0 = IV ,

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

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

I M2 = DK (C2) ⊕ C1.

I Guess the last byte of M2 to be g, 0 I compute C1 = C1 ⊕ 00| ... |00|g ⊕ 00| ... |00|01, 0 I submit C = (C1, 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. 0 I Go on using C1 = C1 ⊕ 00| ... |00|g|g0 ⊕ 00| ... |00|02|02.

/ department of mathematics and computer science Padding oracle attack on CBC encryption 33/38

Ciphertext Ciphertext

block cipher block cipher Key Key decryption decryption

Initialization Vector (IV)

Plaintext Plaintext

/ department of mathematics and computer science Padding oracle attack on CBC encryption 33/38

Ciphertext Ciphertext

block cipher block cipher Key Key decryption decryption

Initialization Vector (IV)

Plaintext Plaintext

/ department of mathematics and computer science Padding oracle attack on CBC encryption 33/38

Ciphertext ⊕g ⊕ 01 Ciphertext

block cipher block cipher Key Key decryption decryption

Initialization Vector (IV)

01 Plaintext Plaintext

/ department of mathematics and computer science Padding oracle attack on CBC encryption 33/38

Ciphertext ⊕g ⊕ 02 | ⊕ g0 ⊕ 02 Ciphertext

block cipher block cipher Key Key decryption decryption

Initialization Vector (IV)

02|02 Plaintext Plaintext

/ department of mathematics and computer science Padding oracle attack on CBC encryption 34/38

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

I More complicated in practice: In case of invalid record, session is terminated, 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 username and password to login.

I Compute password within a few hours.

/ department of mathematics and computer science Padding oracle attack on CBC encryption 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 is applied. "Small timing channel": Lucky 13

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

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

/ department of mathematics and computer science OpenSSL Heartbleed Bug 36/38

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 HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest.

OpenSSL failed to check actual length of payload data.

/ department of mathematics and computer science OpenSSL Heartbleed Bug 37/38

/ department of mathematics and computer science Don’t use NULL, EXPORT.