1. Attacking the IPSec Standards in Encryption- only Configurations Jean Paul Degabriele and Kenneth G. Paterson Presented by Chan Wing Cheong Mar 31, 2008

2. Agenda IPSec Introduction Attacks against Encryption-only IPSec Configurations Case study: Attack against HP-UX Critique

3. IPSec Introduction

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

5. AH Protocol AH Transport Mode −Original IP header is retained AH Tunnel Mode −The original IP packet is encapsulated in a new packet

6. ESP Protocol ESP Transport Mode −Original IP header is retained ESP Tunnel Mode −The original IP packet is encapsulated in a new packet

7. 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 −P 0, P 1,…,P n : Plain Text Blocks −C 0, C 1,…,C n : Cipher Text Blocks −IV: Init Vector

8. Cipher-Block Chaining (CBC) Encryption: C 0 = IV, C i = e(C i-1 XOR P i ) Decryption: P i = C i-1 XOR d(C i )

9. IKE Protocol Diffle-Hellman Algorithm −Generate shared secret key (session key) from public keys, without revealing private keys

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

11. IPSec Demo (1) – using IKE First exchange – Security Association Payload 16.159.165.62 proposes 3DES- CBC encryption algorithm and MD5 hash, which is accepted by 16.159.165.75

12. IPSec Demo (1) – using IKE Second exchange – Key Exchange Payload 16.159.165.62 and 16.159.165.75 exchange Diffle- Hellman public keys to compute a shared secret key

13. IPSec Demo (1) – using IKE Third exchange – Identification Payload 16.159.165.62 and 16.159.165.75 exchange identification data encrypted by shared secret key

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

15. IPSec Demo (2) – using preshared key No key exchange because preshared key is used ESP payload can be decrypted using preshared key

16. IPSec Demo (2) – using preshared key Cipher text C 0 : 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector) C 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 C 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 C 3 : 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 C 4 : 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(C 1 ): 4500 0030 6625 0000 4006 a8db 109f a53e d(C 2 ): 6ce6 0ab6 a007 1730 4f68 ea91 6d6f f5f1 d(C 3 ): ffeb e281 43a2 18bb 7e3d 57c5 950b 6531 d(C 4 ): 14f8 9127 5444 01ba 68db 72c9 d067 ddf5 CBC mode, perform XOR P 1 = C 0 XOR d(C 1 ):4500 0030 6625 0000 4006 a8db 109f a53e P 2 = C 1 XOR d(C 2 ):109f a54b cb37 0017 1233 dd81 0000 0000 P 3 = C 2 XOR d(C 3 ):7002 8000 de52 0000 0204 05B4 0303 0001 P 4 = C 3 XOR d(C 4 ):0102 0304 0506 0708 090a 0b0c 0d0e 0e04

17. 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 text 4500 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

18. 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-numbershttp://www.iana.org/assignments/protocol-numbers −IP(4), TCP(6), UDP(17), ICMP(1), ESP(50), AH(51)

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

20. 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 text 4500 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

21. Attacks against Encryption-only IPSec Configurations

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

23. Attack 1: Padding Oracle P 1,…,P n : Plain Text Blocks (total n blocks) P i,1, P i,2,…,P i,t : Bytes within Plain Text Block P i (t bytes per block) C 0, C 1,…,C n : Cipher Text Blocks (total n blocks and C 0 = IV) C i,1, C i,2,…,C i,t : Bytes within Cipher Text Block C i (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 C i Attacker submits two-block cipher text R,C i 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…) R t XOR d(C i ) t = 0, d(C i ) t can then be computed P i,t = C i-1,t XOR d(C i ) t, P i,t can then be computed Attacker tries at most 256 values of R t to get pad length = 0 and therefore P i,t

24. Attack 1: Padding Oracle Now the attacker learns P i,t and wants to know P i,t-1 The attacker fixes R t so that R t XOR d(C i ) t = 1, vary R t-1 and submit R,C i to padding Oracle If padding is correct, padding must be 1 and Pad Length must be 1 R t-1 XOR d(C i ) t-1 = 1, d(C i ) t-1 can then be computed P i,t-1 = C i-1,t-1 XOR d(C i ) t-1 Attacker tries at most 256 values of R t-1 to get padding = 1,1 Fix R t, R t-1 and repeat the process to try padding = 1,2,2 Eventually all bytes in d(C i ) and P i can be obtained Notes on Padding Oracle Attack IPSec has Next Header byte at the end Whether such padding Oracle indeed exists

25. 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 P k (0≤k≤ 6) and corresponding cipher texts C k (0≤k≤ 6), with source IP = Host A, dest IP = Host B, TTL = 1 Assume: P k contains 20 bytes of IP header, k+12 bytes of payload, padding, Pad Length and Next Header Therefore P 0 ends with 1,2,3,4,5,6,6,4 and P 6 ends with 0,4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header (20 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data (12 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (k bytes) | Padding |Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P k has 5 blocks and therefore C k has 6 blocks (C k 0 = IV)

26. Attack 2: Chosen Plain Text Attacker wants to decrypt C i Attacker submits 6-block cipher text C 6 0, C 6 1, C 6 2, C 6 3, R 6, C i to dest host R 6 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 R 6 XOR d(C i ) ends with 0,4, last 2 bytes of d(C i ) can be computed P i = C i-1 XOR d(C i ), last 2 bytes of P i can be computed

27. Attack 2: Chosen Plain Text Now the attacker wants to the remaining bytes of P i Attacker submits 6-block cipher text C 5 0, C 5 1, C 5 2, C 5 3, R 5, C i to dest host R 5 6 = R 6 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(C i ) and P i can be obtained Notes on Chosen Plain Text Attack Requires chosen plain text and cipher text (Source IP, Dest IP, TTL value)

28. 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 P k and C k (0≤k≤ 6) to proceed chosen plain text attack Lemma P i = C i-1 XOR d(C i ), if bit flip occurs in C 0 = IV, changes occur on P 1 only Preparation 1. The attacker collects D 0, D 1,…,D n from IPSec payload (D 0 = IV) 2. Flip the bits 6 and 7 of the block D 0 3. Vary the bytes 4 and 5 of block D 0 4. Submit the modified payload to dest host 5. Repeat steps 3, 4 for all possible values of bytes 4, 5 until dest host reply with ICMP type 12 “parameter problem”

29. 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”

30. Attack 3: Option Processing Attacker follows chosen plain text attack to decrypt C i Attacker submits cipher text D 0, D 1,…,D n, R 6, C i 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 R 6, C i, 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” Repeat the process until all bytes in d(C i ) and P i can be obtained Notes on Option Processing Attack Requires dest host to perform relaxed IP packet length checking

31. 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 P k and C k (0≤k≤ 6) to proceed chosen plain text attack Lemma P i = C i-1 XOR d(C i ), if bit flip occurs in C 0 = IV, changes occur on P 1 only Preparation 1. The attacker collects D 0, D 1,…,D n from IPSec payload (D 0 = IV) 2. Flip the bits 72 and 73 of the block D 0 3. Vary the bytes 10 and 11 of block D 0 4. Submit the modified payload to dest host 5. Repeat steps 3, 4 for all possible values of bytes 10, 11 until dest host reply with ICMP type 3 “protocol unreachable”

32. 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”

33. Attack 4: Protocol Field Attacker follows chosen plain text attack to decrypt C i Attacker submits cipher text D 0, D 1,…,D n, R 6, C i 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 R 6, C i, 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” Repeat the process until all bytes in d(C i ) and P i can be obtained Notes on Protocol Field Attack Requires dest host to perform relaxed IP packet length checking Does not work against 64-bit block size

34. Case Study: Attack Against HP-UX

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

36. 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 text C 0 : 0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector) C 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 C 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 C 3 : 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 C 4 : ba89 6b95 0624 df5c bb71 8966 6038 6e91 ICMP generating cipher text D 0 : 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D 3 : 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b95 0624 df5c bb71 8966 6038 6e91

37. Preparation Phase Cipher text with modified init vector is injected to the network

38. Preparation Phase ICMP protocol unreachable packet is observed because protocol field has been tampered This ICMP generating packet can then be used as padding oracle

39. Attack Phase (against C 1 byte 14) Replace the last two blocks by random block R and cipher text C 1 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(C 1 ) XOR R = 0, d(C 1 ) = a5, P 1 = C 0 XOR d(C 1 ) = a5 ICMP generating cipher text D 0 : 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D 3 : 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b95 0624 df5c bb71 8966 6038 6e91 Attack cipher text (attack against bytes 14,15 of C 1 ) D 0 : 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 R : 0000 0000 0000 0000 0000 0000 0000 XXXX C 1 : 7c79 affd 9df0 18bb 7c39 5271 9608 6530

40. Attack Phase (against C 1 byte 14) Replace the last two blocks by random block R and cipher text C 1, 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

41. Attack Phase (against C 1 byte 14) ICMP is observed when the last two bytes of R = a500 to a5ff R = a5 d(C 1 ) XOR R = 0 d(C 1 ) = a5 C 0 = all zero P 1 = C 0 XOR d(C 1 ) = a5 The byte 14 of P 1 is therefore a5

42. Attack Phase (against C 1 byte 13) Replace the last two blocks by random block R and cipher text C 1 d(C 1 ) = a5, fix byte 14 of R to a4 so that d(C 1 ) 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(C 1 ) XOR R = 1, d(C 1 ) = 9f, P 1 = C 0 XOR d(C 1 ) = 9f ICMP generating cipher text D 0 : 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D 3 : 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b95 0624 df5c bb71 8966 6038 6e91 Attack cipher text (attack against byte 13 of C 1 ) D 0 : 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 R : 0000 0000 0000 0000 0000 0000 00XX a400 C 1 : 7c79 affd 9df0 18bb 7c39 5271 9608 6530

43. Attack Phase (against C 1 byte 13) Fix byte 14 of R to a4 so that d(C 1 ) XOR R = 1 Systematically vary byte 13 of R to produce correct padding The most likely correct padding is 1, PL = 1

44. Attack Phase (against C 1 byte 13) ICMP is observed when the byte 13 of R = 9e R = 9e d(C 1 ) XOR R = 1 d(C 1 ) = 9f C 0 = all zero P 1 = C 0 XOR d(C 1 ) = 9f The byte 13 of P 1 is therefore 9f

45. Attack Phase (against C 1 byte 12) Replace the last two blocks by random block R and cipher text C 1 d(C 1 ) = 9fa5, fix byte 13,14 of R to 9da7 so that d(C 1 ) 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(C 1 ) XOR R = 1, d(C 1 ) = 10, P 1 = C 0 XOR d(C 1 ) = 10 ICMP generating cipher text D 0 : 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 D 3 : 15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 D 4 : ba89 6b95 0624 df5c bb71 8966 6038 6e91 Attack cipher text (attack against byte 12 of C 1 ) D 0 : 0000 0000 0000 0000 00c0 00c0 0000 0000 (Init Vector) D 1 : 7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 D 2 : 8fe9 6281 9df0 18bb 7c39 5271 9608 6530 R : 0000 0000 0000 0000 0000 0000 XX9d a700 C 1 : 7c79 affd 9df0 18bb 7c39 5271 9608 6530

46. Attack Phase (against C 1 byte 12) Fix byte 13,14 of R to 9da7 so that d(C 1 ) XOR R = 2,2 Systematically vary byte 12 of R to produce correct padding The most likely correct padding is 1,2, PL = 2

47. Attack Phase (against C 1 byte 12) ICMP is observed when the byte 12 of R = 11 R = 11 d(C 1 ) XOR R = 1 d(C 1 ) = 10 C 0 = all zero P 1 = C 0 XOR d(C 1 ) = 10 The byte 12 of P 1 is therefore 10

48. Attack Phase Cipher Text C 0 :0000 0000 0000 0000 0000 0000 0000 0000 (Init Vector) C 1 :7c79 affd 6b30 1727 5d5b 3710 6d6f f5f1 C 2 :8fe9 6281 9df0 18bb 7c39 5271 9608 6530 C 3 :15fa 9223 5142 06b2 61d1 79c5 dd69 d3f1 C 4 :ba89 6b95 0624 df5c bb71 8966 6038 6e91 Plain Text P 1 :4500 0030 6625 0000 4006 a8db 109f a53e P 2 :109f a54b cb37 0017 1233 dd81 0000 0000 P 3 :7002 8000 de52 0000 0204 05B4 0303 0001 P 4 :0102 0304 0506 0708 090a 0b0c 0d0e 0e04 We have retrieved byte 14 of C 1 = 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

49. Critique

50. 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 check Red Hat Enterprise Linux 5, kernel 2.6.18, /net/ipv4/esp4.c /*... check padding bits here. Silly. :-) */ Requires RFC4303 defined padding pattern −How should RFC define “random padding”

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

52. Preventing Attack Include authentication in IPSec configuration Change shared secret key frequently

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

54. 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/