1. Mathy Vanhoef

2. Introduction:
 WPA-TKIP Protocol
 Existing Attacks
New Attacks:
 Denial of Service
 Fragmentation Attack
 MIC Reset Attack

3. We will cover:
 Connecting
 Sending & receiving packets
 Quality of Service (QoS) extension
Design Constraints:
 Must run on legacy hardware
 Uses (hardware) WEP encapsulation

4.  Defined by EAPOL and results in a session key
 What people normally capture & crack

5.  Result of handshake is 512 bit session key
 Renewed after rekeying timeout (1 hour)
EAPOL protection DataEncr MIC1 MIC2
 DataEncr key: used to encrypt packets
 MIC keys (Message Integrity Code):
 Verify integrity of data. But why two?

6.  WPA-TKIP designed for old hardware
 Couldn’t use strong integrity checks (CCMP)
 New algorithm called Michael was created
 Weakness: plaintext + MIC reveals MIC key
 To improve security two MIC keys are used
 MIC1 for AP to client communication
 MIC2 for client to AP communication

7. TSC Data MIC CRC
Encrypted
 Calculate MIC to assure integrity
 WEP Encapsulation:
 Calculate CRC
 Encrypt the packet using RC4
 Add replay counter (TSC) to avoid replays

8. TSC Data MIC CRC
Encrypted
 WEP decapsulation:
 Verify TSC to prevent replays
 Decrypt packet using RC4
 Verify CRC
 Verify MIC to assure authenticity

9.  Replay counter & CRC are good, but MIC not
 Transmission error unlikely
 Network may be under attack!
Defense mechanism on MIC failure:
 Client sends MIC failure report to AP
 AP silently logs failure
 Two failures in 1 min: network down for 1 min

10.  Defines several QoS channels
 Implemented by new field in 802.11 header
QoS TSC Data MIC CRC
unencrypted Encrypted
 Individual replay counter (TSC) per channel
 Used to pass replay counter check of receiver!

11. Channel TSC
0: Best Effort 4000
1: Background 0
2: Video 0
3: Voice 0
 Support for up to 8 channels
 But WiFi certification only requires 4

12. Introduction:
 WPA-TKIP Protocol
 Existing Attacks
New Attacks:
 Denial of Service
 Fragmentation Attack
 MIC Reset Attack

13.  Martin Beck: TU-Dresden, Germany
 Erik Tews: TU-Darmstadt, Germany
 First known attack on TKIP, requires QoS
 Decrypts ARP reply sent from AP to client
 MIC key for AP to client
 Takes at least 8 minutes to execute

14. QoS TSC Data MIC CRC
QoS TSC Data MIC’ CRC'
 Remove last byte
 CRC can be corrected if last byte is known
 Try all 256 values & send using diff. priority
 On correct guess: MIC failure report

15.  Takes 12 minutes to execute
 Limited impact: injection of 3-7 small packets

16.  An improved attack on TKIP
 2009/11: targets DHCP Ack packet
 Cryptanalysis for RC4 and Breaking WPA-TKIP
 2011/11: Removes QoS requirement
 Falsification Attacks against WPA-TKIP in a realistic
environment
 2012/02: Reduces execution time to 8 minutes

17.  Unpublished (Martin Beck, 2010)
 Suggests fragmentation attack
 Not implemented, unrealistic usage example
 MIC Reset Attack
 Implemented, but PoC not available
 Incorrect theoretical analysis
 Suggests a decryption attack
 Not implemented & contains essential flaw

18. Papers about Denial of Service (DoS) attacks:
 802.11 DoS attack: real vulnerabilities and
practical solutions
 2003: Not specific to TKIP, but WiFi in general
 A study of the TKIP cryptographic DoS attack
 2007: Requires man-in-the-middle position

19. Introduction:
 WPA-TKIP Protocol
 Existing Attacks
New Attacks:
 Denial of Service
 Fragmentation Attack
 MIC Reset Attack

20.  MIC = Michael(MAC dest,
MAC source,
MIC key,
priority,
data)
 Rc4key = MixKey(MAC transmitter,
key,
TSC)

21.  Key observations:
 Individual replay counter per priority
 Priority influences MIC but not encryption key
 Two MIC failures: network down
 What happens when the priority is changed?

22.  Capture packet, change priority, replay
On Reception :
 Verify replay counter
 Decrypt packet using RC4
 Verify CRC (leftover from WEP)
 Verify MIC to assure authenticity

23.  Capture packet, change priority, replay
On Reception :
 Verify replay counter OK
 Decrypt packet using RC4 OK
 Verify CRC (leftover from WEP) OK
 Verify MIC to assure authenticity FAIL
 Do this twice: Denial of Service

24.  Disadvantage: attack fails if QoS is disabled
 Cryptanalysis for RC4 and breaking WPA:
 Capture packet, add QoS header, change priority,
replay
On Reception:
 Doesn’t check whether QoS is actually used
 Again bypass replay counter check
 MIC still dependent on priority

25.  Example: network with 20 connected clients
 Old deauthentication attack:
 Must continuously sends packets
 Say 10 deauths per client per second
 (10 * 60) * 20 = 12 000 frames per minute
 New attack
 2 frames per minute

26.  Specifically exploits flaws in WPA-TKIP
 Takes down network for 1 minute yet requires
no man-in-the-middle position
 Requires sending only two packets to take
down the network for 1 minute

27. Introduction:
 WPA-TKIP Protocol
 Existing Attacks
New Attacks:
 Denial of Service
 Fragmentation Attack
 MIC Reset Attack

28. What is needed to inject packets:
 MIC key
 Result of Beck & Tews attack
 Unused replay counter
 Inject packet on unused QoS channel
 Keystream corresponding to replay counter
 Beck & Tews results in only one keystream…
 How can we get more? First need to know RC4!

29.  Stream cipher
 XOR-based
This means: Ciphertext
Plaintext
Keystream
 Predicting the plaintext gives the keystream

30. Simplified:
 All data packets start with LLC header
 Different for APR, IP and EAPOL packets
 Detect ARP & EAPOL based on length
 Everything else: IP
 Practice: almost no incorrect guesses!
 Gives us 12 bytes keystream for each packet

31.  But is 12 bytes enough to send a packet?
 No, MIC & CRC alone are 12 bytes.
If only we could somehow combine them…
 Using 802.11 fragmentation we can combine
16 keystreams to send one large packet

32. Data MIC
Data1 Data2 Data16 MIC
TSC1 Data1 CRC1 TSC16 Data16 MIC CRC16
 MIC calculated over complete packet
 Each fragment has CRC and different TSC
 12 bytes/keystream: inject 120 bytes of data

33.  Beck & Tews attack: MIC key AP to client
 Predict packets & get keystreams
 Combine short keystreams by fragmentation
 Send over unused QoS channel
What can we do with this?
 ARP/DNS Poisoning
 Sending TCP SYN packets: port scan!

34. A few notes:
 Scan 500 most popular ports
 Detect SYN/ACK based on length
 Avoid multiple SYN/ACK’s: send RST
Port scan of internal client:
 Normally not possible
 We are bypassing the network firewall / NAT!

35.  Fragmentation attack implemented!
 Slightly improved & verified prediction of packets
 Verified usage of 802.11 fragmentation
 Realistic example: portscan

36. Introduction:
 WPA-TKIP Protocol
 Existing Attacks
New Attacks:
 Denial of Service
 Fragmentation Attack
 MIC Reset Attack

37. Assume we know the MIC key
 We know the initial MIC state for packets
Attack idea:
 Construct a packet, so that after processing
it, the state is equal to the inital state.
 We can then append a random packet to it,
knowing that its MIC value is valid.

38. Targeted packet
Prefix Magic Data MIC
State1
 State1: initial state of every packet

39. Targeted packet
Prefix Magic Data MIC
State2
 State1: initial state of every packet
 State2: state after processing prefix

40. Targeted packet
Prefix Magic Data MIC
State3
 State1: initial state of every packet
 State2: state after processing prefix
 State3: equal to state1 due to magic bytes

41. Targeted packet
Prefix Magic Data MIC
State4
 State1: initial state of every packet
 State2: state after processing prefix
 State3: equal to state1 due to magic bytes
 State4: equal to MIC of targeted packet!

42. How to calculate the magic bytes?
 Method suggested in unpublished paper
 Essentially a birthday attack
 Has been verified, indeed works
Theoretical analysis:
 Was done very informal & contained errors
 Done correctly using probability theory

43.  The prefix attack can be used to decrypt the
targeted packet.
Unpublished paper:
 Suggested the prefix to be a ping request
 Reply will echo the data = targeted packet
 Flaw: ping request contains checksum
 As the targeted packet is unknown, we cannot
calculate the checksum, packet will be dropped

44.  The prefix attack can be used to decrypt the
targeted packet.
Solution:
 Prefix is UDP packet to closed port
 UDP doesn’t require a checksum
 Assuming port is closed, host will reply with
ICMP unreachable containing the UDP packet
 Make it reply to external ip 

45. In practice:
 Capture a packet from AP to client
 Send the prefix using fragmentation
 Send the targeted packet
 Reply of client contains complete packet
 Assumes client isn’t running a firewall
 Rudimantary PoC is working

46.  Correct theoretical analysis
 Using clear assumptions & probability theory
 Verified by practical experiments!
 Working decryption attack:
 Their suggestion contained an essential flaw
 Different technique based on UDP packets
 Rudimentairy proof of concept is working (WIP)

47.  Highly efficient Denial of Service
 Very reliable PoC
 Fragmentation to launch actual attacks
 Verified that fragmentation works
 Reliable PoC portscan attack
 MIC reset to decrypt AP to client packets
 Correct theoretical analysis
 UDP technique
 PoC is work in progress