[PPT] - On the (In)Security of IPsec in MAC-then-Encrypt Configurations PowerPoint Presentation

SLIDE 1

Motivation The Attacks Concluding Remarks

On the (In)Security of IPsec in MAC-then-Encrypt Configurations

Jean Paul Degabriele Kenneth G. Paterson

Information Security Group Royal Holloway, University of London

CCS 2010

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 1/22

SLIDE 2

Motivation The Attacks Concluding Remarks

Outline

1 Motivation

2 Security of MAC-then-Encrypt in IPsec Preliminaries Using an ESP Trailer Oracle to Recover Plaintext An Oracle Based on IP Fragmentation

3 Concluding Remarks

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 2/22

SLIDE 3

Motivation The Attacks Concluding Remarks

IPsec

IPsec is a suite of protocols that provide security at the IP layer. Three main protocols – AH, ESP , IKE that can be combined in various ways, giving higher configurability. Encryption is provided by ESP , normally using a block cipher in CBC mode. Data origin authentication can be provided either by AH or ESP . Keys can be set manually or automatically through IKE.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 3/22

SLIDE 4

Motivation The Attacks Concluding Remarks

Configuring IPsec

An admin who wants to use IPsec to ensure the confidentiality of network traffic, has to make a number of choices:

Encryption-only, Encrypt-then-MAC, MAC-then-encrypt.
Each of AH or ESP can be operated in Transport or Tunnel mode.
Is replay protection necessary to achieve confidentiality?
Should AH or ESP be used for authentication.

The RFCs provide very little guidance on this matter. There exists no systematic security analysis of the resulting configurations.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 4/22

SLIDE 5

Motivation The Attacks Concluding Remarks

Why Use MAC-then-Encrypt?

SSL uses MAC-then-encrypt, and is widely perceived to be secure. A popular textbook by Stallings discusses several benefits that accrue from MAC-then-encrypt in IPsec. Ferguson and Schneier claim that encrypt-then-MAC as applied in ESP is wrong, and in their book ‘Practical Cryptography’ they recommend MAC-then-encrypt for constructing secure channels. Horton principle: ‘Authenticate what is meant not what is said’. Krawczyk’s proof that MAC-then-encrypt in CBC mode is secure.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 5/22

SLIDE 6

Motivation The Attacks Concluding Remarks

Why NOT MAC-then-Encrypt?

Our paper presents practical attacks against ALL possible MAC-then-encrypt IPsec configurations:

AH in Transport mode followed by ESP in Transport mode.
AH in Transport mode followed by ESP in Tunnel mode.
AH in Tunnel mode followed by ESP in Transport mode.
AH in Tunnel mode followed by ESP in Tunnel mode.

Even when replay protection is enabled. Also in a repeated ESP configuration (ESP in MAC-only followed by ESP in encryption-only).

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 6/22

SLIDE 7

Motivation The Attacks Concluding Remarks

Why NOT MAC-then-Encrypt?

Our paper presents practical attacks against ALL possible MAC-then-encrypt IPsec configurations:

AH in Transport mode followed by ESP in Transport mode.
AH in Transport mode followed by ESP in Tunnel mode.
AH in Tunnel mode followed by ESP in Transport mode.
AH in Tunnel mode followed by ESP in Tunnel mode.

Even when replay protection is enabled. Also in a repeated ESP configuration (ESP in MAC-only followed by ESP in encryption-only).

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 6/22

SLIDE 8

Motivation The Attacks Concluding Remarks

Why NOT MAC-then-Encrypt?

Our paper presents practical attacks against ALL possible MAC-then-encrypt IPsec configurations:

AH in Transport mode followed by ESP in Transport mode.
AH in Transport mode followed by ESP in Tunnel mode.
AH in Tunnel mode followed by ESP in Transport mode.
AH in Tunnel mode followed by ESP in Tunnel mode.

Even when replay protection is enabled. Also in a repeated ESP configuration (ESP in MAC-only followed by ESP in encryption-only).

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 6/22

SLIDE 9

Motivation The Attacks Concluding Remarks

Why NOT MAC-then-Encrypt?

Our paper presents practical attacks against ALL possible MAC-then-encrypt IPsec configurations:

AH in Transport mode followed by ESP in Transport mode.
AH in Transport mode followed by ESP in Tunnel mode.
AH in Tunnel mode followed by ESP in Transport mode.
AH in Tunnel mode followed by ESP in Tunnel mode.

Even when replay protection is enabled. Also in a repeated ESP configuration (ESP in MAC-only followed by ESP in encryption-only).

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 6/22

SLIDE 10

Motivation The Attacks Concluding Remarks

Why NOT MAC-then-Encrypt?

Our paper presents practical attacks against ALL possible MAC-then-encrypt IPsec configurations:

AH in Transport mode followed by ESP in Transport mode.
AH in Transport mode followed by ESP in Tunnel mode.
AH in Tunnel mode followed by ESP in Transport mode.
AH in Tunnel mode followed by ESP in Tunnel mode.

Even when replay protection is enabled. Also in a repeated ESP configuration (ESP in MAC-only followed by ESP in encryption-only).

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 6/22

SLIDE 11

Motivation The Attacks Concluding Remarks

Why NOT MAC-then-Encrypt?

Our paper presents practical attacks against ALL possible MAC-then-encrypt IPsec configurations:

AH in Transport mode followed by ESP in Transport mode.
AH in Transport mode followed by ESP in Tunnel mode.
AH in Tunnel mode followed by ESP in Transport mode.
AH in Tunnel mode followed by ESP in Tunnel mode.

Even when replay protection is enabled. Also in a repeated ESP configuration (ESP in MAC-only followed by ESP in encryption-only).

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 6/22

SLIDE 12

Motivation The Attacks Concluding Remarks

Outline

1 Motivation

2 Security of MAC-then-Encrypt in IPsec Preliminaries Using an ESP Trailer Oracle to Recover Plaintext An Oracle Based on IP Fragmentation

3 Concluding Remarks

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 7/22

SLIDE 13

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 14

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV Dk(·)

Dk(·)
IV

C1 C2 P1 P2

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 15

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV Dk(·)

Dk(·)
IV

C1 C2 P1 P2

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 16

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV Dk(·)

Dk(·)
IV

C1 C2 P1 P2

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 17

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV Dk(·)

Dk(·)
IV

C1 C2 P1 P2

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 18

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV Dk(·)

Dk(·)
IV

C1 C2 P1 P2

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 19

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV Dk(·)

Dk(·)
IV

C1 C2 P1 P2

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 20

Motivation The Attacks Concluding Remarks

Bit Flipping in CBC Mode

CBC encryption Ci = Ek(Pi ⊕ Ci−1); C0 = IV CBC decryption Pi = Dk(Ci) ⊕ Ci−1; C0 = IV Dk(·)

Dk(·)
IV

C1 C2 P1 P2

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 8/22

SLIDE 21

Motivation The Attacks Concluding Remarks

The ESP Trailer Format

Prior to encryption an ESP trailer is appended to the plaintext, extending its length to an integer multiple of the blocksize.

Plaintext Padding ESP trailer

PL = Padding Length NH = Next Header In Tunnel mode NH = 4 0,4 1,1,4 1,2,2,4 1,2,3,3,4

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 9/22

SLIDE 22

Motivation The Attacks Concluding Remarks

The ESP Trailer Format

Prior to encryption an ESP trailer is appended to the plaintext, extending its length to an integer multiple of the blocksize.

Plaintext 1 2 3 4 Padding ESP trailer

PL = Padding Length NH = Next Header In Tunnel mode NH = 4 0,4 1,1,4 1,2,2,4 1,2,3,3,4

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 9/22

SLIDE 23

Motivation The Attacks Concluding Remarks

The ESP Trailer Format

Prior to encryption an ESP trailer is appended to the plaintext, extending its length to an integer multiple of the blocksize.

Plaintext 1 2 3 4 PL NH Padding ESP trailer

PL = Padding Length NH = Next Header In Tunnel mode NH = 4 0,4 1,1,4 1,2,2,4 1,2,3,3,4

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 9/22

SLIDE 24

Motivation The Attacks Concluding Remarks

The ESP Trailer Format

Prior to encryption an ESP trailer is appended to the plaintext, extending its length to an integer multiple of the blocksize.

Plaintext 1 2 3 4 PL NH Padding ESP trailer

PL = Padding Length NH = Next Header In Tunnel mode NH = 4 0,4 1,1,4 1,2,2,4 1,2,3,3,4

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 9/22

SLIDE 25

Motivation The Attacks Concluding Remarks

The ESP Trailer Format

Prior to encryption an ESP trailer is appended to the plaintext, extending its length to an integer multiple of the blocksize.

Plaintext 1 2 3 4 PL NH Padding ESP trailer

PL = Padding Length NH = Next Header In Tunnel mode NH = 4 0,4 1,1,4 1,2,2,4 1,2,3,3,4

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 9/22

SLIDE 26

Motivation The Attacks Concluding Remarks

The ESP Trailer Format

Prior to encryption an ESP trailer is appended to the plaintext, extending its length to an integer multiple of the blocksize.

Plaintext 1 2 3 4 PL NH Padding ESP trailer

PL = Padding Length NH = Next Header In Tunnel mode NH = 4 0,4 1,1,4 1,2,2,4 1,2,3,3,4

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 9/22

SLIDE 27

Motivation The Attacks Concluding Remarks

The ESP Trailer Format

Prior to encryption an ESP trailer is appended to the plaintext, extending its length to an integer multiple of the blocksize.

Plaintext 1 2 3 4 PL NH Padding ESP trailer

PL = Padding Length NH = Next Header In Tunnel mode NH = 4 0,4 1,1,4 1,2,2,4 1,2,3,3,4

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 9/22

SLIDE 28

Motivation The Attacks Concluding Remarks

An ESP Trailer Oracle

Definition An ESP Trailer Oracle is an oracle that when presented with an ESP-protected IP packet, outputs 1 if the underlying plaintext ends in a valid ESP trailer, and outputs 0 otherwise. Such an oracle is an adaptation of Vaudenay’s padding oracle concept from Eurocrypt ’02 to the IPsec setting.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 10/22

SLIDE 29

Motivation The Attacks Concluding Remarks

An ESP Trailer Oracle

Definition An ESP Trailer Oracle is an oracle that when presented with an ESP-protected IP packet, outputs 1 if the underlying plaintext ends in a valid ESP trailer, and outputs 0 otherwise. Such an oracle is an adaptation of Vaudenay’s padding oracle concept from Eurocrypt ’02 to the IPsec setting.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 10/22

SLIDE 30

Motivation The Attacks Concluding Remarks

Outline

1 Motivation

2 Security of MAC-then-Encrypt in IPsec Preliminaries Using an ESP Trailer Oracle to Recover Plaintext An Oracle Based on IP Fragmentation

3 Concluding Remarks

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 11/22

SLIDE 31

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Choose a ciphertext block from an ESP-protected IP packet that we want to decrypt.

ESP header IP headerout C∗

0, C∗ 1, . . . , C∗ i , . . . , C∗ n

* *

Arbitrarily pick another packet – call it the carrier packet. Append a random block R and block C∗

i to the carrier packet and

submit it to the oracle.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 12/22

SLIDE 32

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Choose a ciphertext block from an ESP-protected IP packet that we want to decrypt.

ESP header IP headerout C∗

0, C∗ 1, . . . , C∗ i , . . . , C∗ n

* *

Arbitrarily pick another packet – call it the carrier packet.

ESP header IP headerout C0, C1, C2, . . . , Cn−1, Cn

Append a random block R and block C∗

i to the carrier packet and

submit it to the oracle.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 12/22

SLIDE 33

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Choose a ciphertext block from an ESP-protected IP packet that we want to decrypt.

ESP header IP headerout C∗

0, C∗ 1, . . . , C∗ i , . . . , C∗ n

* *

Arbitrarily pick another packet – call it the carrier packet.

ESP header IP headerout C0, C1, C2, . . . , Cn−1, Cn

Append a random block R and block C∗

i to the carrier packet and

submit it to the oracle.

ESP header IP headerout C0, C1, C2, . . . , Cn−1, Cn, R, C∗

i Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 12/22

SLIDE 34

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

valid

$ $ $ $ $ $ $ $ $ $ in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 35

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

valid

in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 36

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

valid

in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 37

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

valid

in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 38

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

r15 r14 valid

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 39

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

1 r15 r′

14

valid in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 40

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

1 r15 r′

14

valid in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 41

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

1 r15 r′

14

1 r13 valid

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 42

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

2 r15 r′′

14

2 r′

13

valid in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 43

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

2 r15 r′′

14

2 r′

13

valid in

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 44

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

2 r15 r′′

14

2 r′

13

r12 1 valid

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 45

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

14 14 13 1 2 .... valid

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 46

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

14 14 13 1 2 .... valid

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 47

Motivation The Attacks Concluding Remarks

A Decryption Algorithm

From an ESP Trailer Oracle

Dk(·)

Dk(·)
Cn

R C∗

i

Dk(·)

4

14 14 13 1 2 .... valid

TESP = Dk(C∗

i ) ⊕ R

P∗

i = Dk(C∗ i ) ⊕ C∗ i−1.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 13/22

SLIDE 48

Motivation The Attacks Concluding Remarks

Realising the Oracle

An ESP trailer oracle can be realised by using a carrier packet that always generates a reply after IPsec processing. If the ESP trailer is invalid the packet is discarded and no reply is generated. Contrarily if the ESP trailer is valid a reply will be sent over the network.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 14/22

SLIDE 49

Motivation The Attacks Concluding Remarks

Practical Complications

A packet may be dropped for several other reasons – if this happens the oracle is lost. Flipping bits and appending blocks may invalidate the MAC. Replay protection prevents us from using the same carrier packet more than once. We need to preserve a valid internal structure of the IP packet. Our paper describes several ways to solve these problems – we will now present one approach.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 15/22

SLIDE 50

Motivation The Attacks Concluding Remarks

Outline

1 Motivation

2 Security of MAC-then-Encrypt in IPsec Preliminaries Using an ESP Trailer Oracle to Recover Plaintext An Oracle Based on IP Fragmentation

3 Concluding Remarks

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 16/22

SLIDE 51

Motivation The Attacks Concluding Remarks

MAC-then-Encrypt

Example Configuration

In the following attack we will assume AH in Transport mode, followed by ESP in Tunnel mode.

AH IP payload ESP trailer ESP header IP header out IP header in encryption scope authentication scope

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 17/22

SLIDE 52

Motivation The Attacks Concluding Remarks

IP Fragmentation

An IP packet may be split into smaller autonomous fragments by an intermediate gateway. The MF bit is a flag in the IP header indicating that the IP packet is indeed a fragment and there are More Fragments to come.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 18/22

SLIDE 53

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header. The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 54

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

ESP header IP header out

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 55

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

ESP header

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 56

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload ESP header IP header in ?

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 57

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload ESP trailer ESP header IP header in

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 58

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload IP header in

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 59

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload MF = 1

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 60

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload MF = 1

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 61

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload MF = 1

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 62

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload MF = 1

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 63

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload MF = 1

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 64

Motivation The Attacks Concluding Remarks

An Oracle from IP Fragmentation

We flip bits in the IV to set the MF bit to 1 and correct the checksum in the inner IP header.

AH IP payload MF = 1

The inner IP packet is not complete ⇒ cannot verify the MAC! The receiver enters a wait stage, waiting for more fragments. No other fragments exist, the wait stage will eventually timeout and an ICMP Time Exceeded message is sent. The packet is discarded and no further processing takes place. We realised the ESP trailer oracle, and completely bypassed AH processing!

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 19/22

SLIDE 65

Motivation The Attacks Concluding Remarks

Implementing the Attacks

We implemented and verified the validity of our attacks against the OpenSolaris IPsec implementation. The fragmentation attack takes around 10 mins to recover a 128 bit block of plaintext due to the timeout overhead. On a 10Mb Hub our alternative attacks take roughly 70 seconds to recover a 128 bit block of plaintext.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 20/22

SLIDE 66

Motivation The Attacks Concluding Remarks

Conclusions

From a Practical Perspective

All MAC-then-encrypt IPsec configurations are vulnerable to one

r more of our attacks.

Encryption-only configurations of IPsec are already known to be insecure. Thus most of the flexibility provided by IPsec results in insecure configurations – only encrypt-then-MAC provides confidentiality in IPsec. Our attacks highlight the difficulty in designing a secure network protocol – its interaction with the upper and lower layer protocols has to be included in the picture.

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 21/22

SLIDE 67

Motivation The Attacks Concluding Remarks

Conclusions

From a Theoretical Perspective

Krawczyk’s security model considers a very restricted case of MAC-then-encrypt. Security proofs normally assume the cryptographic processing to be atomic and do not consider distinct error messages or fragmentation. Care should be taken in interpreting security proofs with respect to secure protocols in practice. What does the proof assume? How does the model compare to real life?

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 22/22

SLIDE 68

Motivation The Attacks Concluding Remarks

Conclusions

From a Theoretical Perspective

Krawczyk’s security model considers a very restricted case of MAC-then-encrypt. Security proofs normally assume the cryptographic processing to be atomic and do not consider distinct error messages or fragmentation. Care should be taken in interpreting security proofs with respect to secure protocols in practice. What does the proof assume? How does the model compare to real life?

Jean Paul Degabriele, Kenneth G. Paterson | On the (In)Security of IPsec in MAC-then-Encrypt Configurations 22/22