attacking the ipsec standards in encryption- only configurations jean paul degabriele and kenneth g....

Attacking the IPSec Standards in Encryption-only Configurations

Jean Paul Degabriele and Kenneth G. Paterson

Presented by Chan Wing Cheong

Mar 31, 2008

Agenda• IPSec Introduction• Attacks against Encryption-only IPSec

Configurations• Case study: Attack against HP-UX• Critique

IPSec Introduction

IPSec Standard• RFC 2401-2412, RFC 4301-4309• A protocol suite defined by IETF to provide the

following security services for IP networks:

−Authentication Header (AH)Provides integrity and authentication

−Encapsulating Security Payload (ESP)Primarily provides encryption but can also provide limited authentication

−Internet Key Exchange (IKE)Establish Security Association (SA)Generates and distributes keys for ESP

AH Protocol• AH Transport Mode

−Original IP header is retained

• AH Tunnel Mode−The original IP packet is encapsulated in a new

packet

ESP Protocol• ESP Transport Mode

−Original IP header is retained

• ESP Tunnel Mode−The original IP packet is encapsulated in a new

packet

ESP Protocol• Encrption Algorithm

−DES-CBC (64-bit key, 64-bit block size)

−3DES-CBC (192-bit key, 64-bit block size)

−AES-CBC (128/192/256-bit key, 128-bit block size)

• Convention−P0, P1,…,Pn: Plain Text Blocks

−C0, C1,…,Cn: Cipher Text Blocks

−IV: Init Vector

Cipher-Block Chaining (CBC)• Encryption: C0 = IV, Ci = e(Ci-1 XOR Pi)

• Decryption: Pi = Ci-1 XOR d(Ci)

IKE Protocol• Diffle-Hellman Algorithm

−Generate shared secret key (session key) from public keys, without revealing private keys

IPSec Demo (1) – using IKE• HP-UX version 11.23

−telnet from 16.159.165.62 to 16.159.165.75

• IPSec version A.02.00.01• ESP tunnel mode, using 128-bit AES-CBC• No authentication• IKE

−3DES-CBC encryption, MD5 hash

−IKE produces one-time session key

IPSec Demo (1) – using IKEFirst exchange –

Security Association Payload

16.159.165.62 proposes 3DES-CBC encryption algorithm and MD5 hash, which is accepted by 16.159.165.75

IPSec Demo (1) – using IKESecond exchange

– Key Exchange Payload

16.159.165.62 and 16.159.165.75 exchange Diffle-Hellman public keys to compute a shared secret key

IPSec Demo (1) – using IKEThird exchange –

Identification Payload

16.159.165.62 and 16.159.165.75 exchange identification data encrypted by shared secret key

IPSec Demo (2) – using preshared key• HP-UX version 11.23

−telnet from 16.159.165.62 to 16.159.165.75

• IPSec version A.02.00.01• ESP tunnel mode, using 128-bit AES-CBC• No authentication• Manual preshared key, no IKE

−Preshared key: 128-bit all zero’s

−Init vector: 128-bit all zero’s

−ESP payload can be decrypted using preshared key

IPSec Demo (2) – using preshared keyNo key exchange

because preshared key is used

ESP payload can be decrypted using preshared key

IPSec Demo (2) – using preshared key• Cipher text

C0: 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector)

C1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1

C2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530

C3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1

C4: ba89 6b95 0624 df5c bb71 8966 6038 6e91

• Decrypt using AES, key = 128-bit all zero’s, init vector = 128-bit all zero’s

d(C1): 4500 0030 6625 0000 4006 a8db 109f a53e

d(C2): 6ce6 0ab6 a007 1730 4f68 ea91 6d6f f5f1

d(C3): ffeb e281 43a2 18bb 7e3d 57c5 950b 6531

d(C4): 14f8 9127 5444 01ba 68db 72c9 d067 ddf5

• CBC mode, perform XOR

P1 = C0 XOR d(C1): 4500 0030 6625 0000 4006 a8db 109f a53e

P2 = C1 XOR d(C2): 109f a54b cb37 0017 1233 dd81 0000 0000

P3 = C2 XOR d(C3): 7002 8000 de52 0000 0204 05B4 0303 0001

P4 = C3 XOR d(C4): 0102 0304 0506 0708 090a 0b0c 0d0e 0e04

IPSec Demo (2) – using preshared key• IP Header (RFC 791)

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| IHL |Type of Service| Total Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identification |Flags| Fragment Offset |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Time to Live | Protocol | Header Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Destination Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Plain text4500 0030 6625 0000 4006 a8db 109f a53e

109f a54b cb37 0017 1233 dd81 0000 0000

7002 8000 de52 0000 0204 05B4 0303 0001

0102 0304 0506 0708 090a 0b0c 0d0e 0e04

IPSec Padding• CBC mode must operate in whole blocks• Padding

(RFC4303)

The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, .... When this padding scheme is employed, the receiver SHOULD inspect the Padding field.

• Pad Length (PL)• Next Header (NH)

−http://www.iana.org/assignments/protocol-numbers

−IP(4), TCP(6), UDP(17), ICMP(1), ESP(50), AH(51)

http://www.iana.org/assignments/protocol-numbers

http://www.iana.org/assignments/protocol-numbers

IPSec Padding• Valid Pattern for ESP Tunnel Mode

−0,4−1,1,4−1,2,2,4−1,2,3,3,4

• Valid Pattern for ESP Transport Mode−0,NH−1,1,NH−1,2,2,NH−1,2,3,3,NH

IPSec Padding• ESP Packet (RFC 4303)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------- | IV (optional) | ^ p ^e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a |n | Rest of Payload Data (variable) | | y |c ~ ~ | l |r | | | o |y + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a |p | | TFC Padding * (optional, variable) | v d |t +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- |i | | Padding (0-255 bytes) | |o +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |n | | Pad Length | Next Header | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------

• Plain text4500 0030 6625 0000 4006 a8db 109f a53e109f a54b cb37 0017 1233 dd81 0000 00007002 8000 de52 0000 0204 05B4 0303 00010102 0304 0506 0708 090a 0b0c 0d0e 0e04

Attacks against Encryption-only IPSec Configurations

IPSec Attacks• This paper describes attacks which break

any RFC-compliant encryption-only IPSec implementation−Padding Oracle Attack

−Chosen Plain Text Attack

−Option Processing Attack

−Protocol Field Attack

• The first few attacks may not be realistic and practical, but they reflect how attack methods are improved and refined

Attack 1: Padding Oracle• P1,…,Pn: Plain Text Blocks (total n blocks)

• Pi,1, Pi,2,…,Pi,t: Bytes within Plain Text Block Pi (t bytes per block)

• C0, C1,…,Cn: Cipher Text Blocks (total n blocks and C0 = IV)

• Ci,1, Ci,2,…,Ci,t: Bytes within Cipher Text Block Ci (t bytes per block)

• Assume: there is no Next Header byte at the end of packet• Assume: there is an Oracle that tells whether the padding is correct

• Attacker wants to decrypt Ci

• Attacker submits two-block cipher text R,Ci to padding Oracle• If padding is correct, it is most likely that Pad Length = 0

(there is slim chance that padding can be 1,1 or 1,2,2 or 1,2,3,3…)

• Rt XOR d(Ci)t = 0, d(Ci)t can then be computed

• Pi,t = Ci-1,t XOR d(Ci)t, Pi,t can then be computed

• Attacker tries at most 256 values of Rt to get pad length = 0 and therefore Pi,t

Attack 1: Padding Oracle• Now the attacker learns Pi,t and wants to know Pi,t-1

• The attacker fixes Rt so that Rt XOR d(Ci)t = 1, vary Rt-1 and submit R,Ci to padding Oracle

• If padding is correct, padding must be 1 and Pad Length must be 1

• Rt-1 XOR d(Ci)t-1 = 1, d(Ci)t-1 can then be computed

• Pi,t-1 = Ci-1,t-1 XOR d(Ci)t-1

• Attacker tries at most 256 values of Rt-1 to get padding = 1,1

• Fix Rt, Rt-1 and repeat the process to try padding = 1,2,2

• Eventually all bytes in d(Ci) and Pi can be obtained

Notes on Padding Oracle Attack• IPSec has Next Header byte at the end• Whether such padding Oracle indeed exists

Attack 2: Chosen Plain Text• Assume: ESP Tunnel Mode is used• Assume: block size = 64 bits (trivial to adapt the attack to 128-bit

block)• Assume: there are 7 chosen plain texts Pk (0≤k≤ 6) and

corresponding cipher texts Ck (0≤k≤ 6), with source IP = Host A, dest IP = Host B, TTL = 1

• Assume: Pk contains 20 bytes of IP header, k+12 bytes of payload, padding, Pad Length and Next Header

• Therefore P0 ends with 1,2,3,4,5,6,6,4 and P6 ends with 0,4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IP Header (20 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Payload Data (12 bytes) |

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (k bytes) | Padding |Pad Length | Next Header |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Pk has 5 blocks and therefore Ck has 6 blocks (Ck0 = IV)

Attack 2: Chosen Plain Text• Attacker wants to decrypt Ci

• Attacker submits 6-block cipher text C60, C6

1, C62, C6

3, R6, Ci to dest host

• R6 does not affect IP header after decryption• If padding is not correct, the packet will be silently dropped by dest

host• If padding is correct, most likely PL = 0 and NH = 4, and Host B will

reply with ICMP type 11 “time to live exceeded”• ICMP reply may be encrypted, attacker needs to monitor 9-block

cipher text from Host B to Host A

• R6 XOR d(Ci) ends with 0,4, last 2 bytes of d(Ci) can be computed

• Pi = Ci-1 XOR d(Ci), last 2 bytes of Pi can be computed

Attack 2: Chosen Plain Text• Now the attacker wants to the remaining bytes of Pi

• Attacker submits 6-block cipher text C50, C5

1, C52, C5

3, R5, Ci to dest host

• R56 = R6

6 XOR 1 so that PL = 1• If padding is correct, padding = 1, PL = 1 and NH = 4, and dest host

will reply with ICMP time exceeded packet (9-block cipher text if encrypted)

• Repeat the process until all bytes in d(Ci) and Pi can be obtained

Notes on Chosen Plain Text Attack• Requires chosen plain text and cipher text (Source IP, Dest IP, TTL

value)

Attack 3: Option Processing• Assume: ESP Tunnel Mode is used• Assume: block size = 64 bits (trivial to adapt the attack to 128-bit

block)• Assume: Dest host performs relaxed IP packet length checking• The attacker needs Pk and Ck (0≤k≤ 6) to proceed chosen plain text

attack

LemmaPi = Ci-1 XOR d(Ci), if bit flip occurs in C0 = IV, changes occur on P1 only

Preparation1. The attacker collects D0, D1,…,Dn from IPSec payload (D0 = IV)2. Flip the bits 6 and 7 of the block D0

3. Vary the bytes 4 and 5 of block D0

4. Submit the modified payload to dest host5. Repeat steps 3, 4 for all possible values of bytes 4, 5 until dest host

reply with ICMP type 12 “parameter problem”

Attack 3: Option Processing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Flip the bits 6 and 7 of IV so that header length changes from 5 to 6• Header Checksum = 1’s complement sum of 16-bit header words• Vary the bytes 4 and 5 of IV to produce different values of ID so that

original checksum can still be obtained• The first 4 bytes of payload will then be interpreted as option• Most likely the option is incorrectly formatted, and dest host will

reply with ICMP type 12 “parameter problem”

Attack 3: Option Processing• Attacker follows chosen plain text attack to decrypt Ci

• Attacker submits cipher text D0, D1,…,Dn, R6, Ci to dest host• If padding is not correct, the packet will be silently dropped by dest

host• If padding is correct, most likely PL = 0 and NH = 4

• After appending R6, Ci, the header length is not correct but is still processed by dest host due to relaxed length checking

• Dest host will reply with ICMP type 12 “parameter problem”


Notes on Option Processing Attack• Requires dest host to perform relaxed IP packet length checking

Attack 4: Protocol Field• Assume: ESP Tunnel Mode is used• Assume: block size = 128 bits (does not work on 64-bit block

size)• The attacker needs Pk and Ck (0≤k≤ 6) to proceed chosen plain

text attack

LemmaPi = Ci-1 XOR d(Ci), if bit flip occurs in C0 = IV, changes occur on P1 only

Preparation1. The attacker collects D0, D1,…,Dn from IPSec payload (D0 = IV)2. Flip the bits 72 and 73 of the block D0

3. Vary the bytes 10 and 11 of block D0

4. Submit the modified payload to dest host5. Repeat steps 3, 4 for all possible values of bytes 10, 11 until dest

host reply with ICMP type 3 “protocol unreachable”

Attack 4: Protocol Field 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Flip the bits 72 and 73 of IV so that Protocol value is increased by 192

• Protocol numbers from 140 to 252 are currently unassigned• Header Checksum = 1’s complement sum of 16-bit header words• Vary the bytes 10 and 11 of IV until a correct checksum is obtained• If the checksum is correct, the dest host will reply with ICMP type 3

“protocol unreachable”

Attack 4: Protocol Field• Attacker follows chosen plain text attack to decrypt Ci

• Attacker submits cipher text D0, D1,…,Dn, R6, Ci to dest host• If padding is not correct, the packet will be silently dropped by dest

host• If padding is correct, most likely PL = 0 and NH = 4

• After appending R6, Ci, the header length is not correct but is still processed by dest host due to relaxed length checking

• Dest host will reply with ICMP type 3 “protocol unreachable”


Notes on Protocol Field Attack• Requires dest host to perform relaxed IP packet length checking• Does not work against 64-bit block size

Case Study:Attack Against HP-UX

Case Study: Attack Against HP-UX• HP-UX version 11.23

−Source: 16.159.165.62

−Dest: 16.159.165.75

• IPSec version A.02.00.01• ESP tunnel mode, using 128-bit AES-CBC• No authentication• Manual preshared key, no IKE

−Preshared key: 128-bit all zero’s

−Init vector: 128-bit all zero’s

Preparation Phase• Flip the bits 72 and 73 of IV so that Protocol value is increased

by 192• Vary the bytes 10 and 11 of IV until a correct checksum is

obtained• This new cipher text will generate ICMP “protocol unreachable”

reply

Original cipher textC0: 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector)C1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1C2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530C3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1C4: ba89 6b95 0624 df5c bb71 8966 6038 6e91

ICMP generating cipher textD0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530D3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1D4: ba89 6b95 0624 df5c bb71 8966 6038 6e91

Preparation PhaseCipher text with

modified init vector is injected to the network

Preparation PhaseICMP protocol

unreachable packet is observed because protocol field has been tampered

This ICMP generating packet can then be used as padding oracle

Attack Phase (against C1 byte 14)• Replace the last two blocks by random block R and cipher text C1

• Total packet length is preserved• Systematically vary the last two bytes of R to produce correct padding• The most likely correct padding is PL = 0• ICMP reply is observed for XXXX = a500 to a5ff• It turns out that HP-UX does not inspect Next Header (NH) byte• R = a5, d(C1) XOR R = 0, d(C1) = a5, P1 = C0 XOR d(C1) = a5


Attack cipher text (attack against bytes 14,15 of C1)D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530R : 0000 0000 0000 0000 0000 0000 0000 XXXXC1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530

Attack Phase (against C1 byte 14)Replace the last

two blocks by random block R and cipher text C1, and inject the modified cipher text to the network

Systematically vary the last two bytes of R to produce correct padding

The most likely correct padding is PL = 0

Attack Phase (against C1 byte 14)ICMP is observed

when the last two bytes of R = a500 to a5ff

R = a5

d(C1) XOR R = 0

d(C1) = a5

C0 = all zero

P1 = C0 XOR d(C1) = a5

The byte 14 of P1 is therefore a5


• d(C1) = a5, fix byte 14 of R to a4 so that d(C1) XOR R = 1• Systematically vary byte 13 of R to produce correct padding• The only correct padding is 1, PL = 1• ICMP reply is observed for XX = 9e• R = 9e, d(C1) XOR R = 1, d(C1) = 9f, P1 = C0 XOR d(C1) = 9f


Attack cipher text (attack against byte 13 of C1)D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530R : 0000 0000 0000 0000 0000 0000 00XX a400C1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530

Attack Phase (against C1 byte 13)Fix byte 14 of R

to a4 so that d(C1) XOR R = 1

Systematically vary byte 13 of R to produce correct padding

The most likely correct padding is 1, PL = 1


when the byte 13 of R = 9e

R = 9e

d(C1) XOR R = 1

d(C1) = 9f

C0 = all zero

P1 = C0 XOR d(C1) = 9f

The byte 13 of P1 is therefore 9f


• d(C1) = 9fa5, fix byte 13,14 of R to 9da7 so that d(C1) XOR R = 0202• Systematically vary byte 12 of R to produce correct padding• The only correct padding is 1,2, PL = 2• ICMP reply is observed for XX = 11• R = 11, d(C1) XOR R = 1, d(C1) = 10, P1 = C0 XOR d(C1) = 10


Attack cipher text (attack against byte 12 of C1)D0: 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector)D1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1D2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530R : 0000 0000 0000 0000 0000 0000 XX9d a700C1: 7c79 affd 9df0 18bb 7c39 5271 9608 6530

Attack Phase (against C1 byte 12)Fix byte 13,14 of

R to 9da7 so that d(C1) XOR R = 2,2

Systematically vary byte 12 of R to produce correct padding

The most likely correct padding is 1,2, PL = 2


when the byte 12 of R = 11

R = 11

d(C1) XOR R = 1

d(C1) = 10

C0 = all zero

P1 = C0 XOR d(C1) = 10

The byte 12 of P1 is therefore 10

Attack Phase• Cipher Text

C0: 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector)

C1: 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1

C2: 8fe9 6281 9df0 18bb 7c39 5271 9608 6530

C3: 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1

C4: ba89 6b95 0624 df5c bb71 8966 6038 6e91

• Plain Text

P1: 4500 0030 6625 0000 4006 a8db 109f a53e

P2: 109f a54b cb37 0017 1233 dd81 0000 0000

P3: 7002 8000 de52 0000 0204 05B4 0303 0001

P4: 0102 0304 0506 0708 090a 0b0c 0d0e 0e04

• We have retrieved byte 14 of C1 = a5, byte 13 = 9f, byte 12 = 10• The process can be repeated to get byte 0 to byte 14• Byte 15 cannot be retrieved because HP-UX does not inspect NH byte

Critique

Attack Requirement• Requires strict IPSec padding check

−Vulnerable to Bellovin attack if padding check is not strictly enforced

−Open Solaris, HP-UX perform padding check

−Linux does not perform padding checkRed Hat Enterprise Linux 5, kernel 2.6.18, <srcdir>/net/ipv4/esp4.c

/* ... check padding bits here. Silly. :-) */

• Requires RFC4303 defined padding pattern−How should RFC define “random padding”

Attack Requirement• Requires CBC mode encryption

−CBC is widely used because, if not so, encrypting the same plaintext using the same key always produces the same output

• Requires encryption-only configuration−HP-UX does not support encryption-only

configuration since IPSec A.02.01 (Oct 2005)

• Requires IPSec tunnel mode−The attack can actually be adapted against

IPSec transport mode, with further preparation tasks

Preventing Attack• Include authentication in IPSec

configuration• Change shared secret key frequently

Critique• IP packet has well defined data pattern

−Poor randomness of data makes attack easier

• IP header is located at the beginning of data−Can be easily modified via CBC mode init vector

• Generic encryption algorithm may not be suitable for IPSec

• The attack does not work against HP-UX because Protocol field is inspected before Next Header

Acknowledgement• AES Decryption Tool

−http://people.eku.edu/styere/Encrypt/JS-AES.html

−http://www.hanewin.net/encrypt/aes/aes-test.htm

• Packet Injection Tool−http://nemesis.sourceforge.net/

• Illustration−http://docs.hp.com/

−http://www.wikipedia.org/

attacking the ipsec standards in encryption- only configurations jean paul degabriele and kenneth g....

Documents