See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221593201

ANonce encryption in 802.11i 4-way handshake protocol

Conference Paper · January 2009

DOI: 10.1145/1821748.1821839 · Source: DBLP

CITATIONS READS
3 914

2 authors, including:

Y.L. Ho
Multimedia University
8 PUBLICATIONS   40 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Y.L. Ho on 29 September 2017.

The user has requested enhancement of the downloaded file.

 ANonce Encryption in 802.11i 4-way Handshake
Protocol
Aidil Izani Jafri
Multimedia University
Jalan Ayer Keroh Lama
75450 Melaka, Malaysia
aidil.izani.jafri04@mmu.edu.my
ABSTRACT
802.11i is the latest security standard for wireless LAN
(WLAN). It provides data confidentiality and integrity. The
802.11i 4-way handshake and key management remains
secure against any attack which could compromise the key.
However, availability protection is still an issue as 802.11i
is subjected to denial of service attacks. Since Message 1 in
the 4-way handshake is not protected by any mechanism,
forging these messages is possible. This paper presents a
light and simple implementation to deter DoS attacks
against the 4-way handshake protocol.
Categories and Subject Descriptors
C.2.2 [Computer-Communication Networks]:
Network Protocols
General Terms
Security
Keywords
802.11i, 4-way handshake protocol, ANonce, WLAN
Security, DoS attack
1. INTRODUCTION
Wireless LAN (WLAN) has becoming more popular
among home users and enterprise users because of its
mobility, wide availability of hardware and affordable
price. 802.11 is one of the standards of WLAN set by the
IEEE. The 802.11 [13] has undergone various amendments
to improve its bandwidth, range, functionalities and
security.
The earliest form of security adopted in the early stages of
WLAN is the Wired Equivalent Privacy (WEP) protocol
[4]. After a few years, it was shown to be insecure and
replaced with the Wi-Fi Protected Access (WPA) protocol.
There are two types of WPA applications: WPA Pre-shared
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
MoMM2009, December 14–16, 2009, Kuala Lumpur, Malaysia.
Copyright 2009 ACM 78-1-60558-659-5/09/0012...$5.00.
Yean Li Ho
Multimedia University
Jalan Ayer Keroh Lama
75450 Melaka, Malaysia
ylho@mmu.edu.my
Key (PSK) for home and SOHO users and WPA Extensible
Authentication Protocol (EAP), which is mainly for
enterprise users [4]. WPA maintained its reputation as
secure protocol for quite some time until vulnerabilities
were found inside the 4-way handshake protocol. It is
possible for an attacker to obtain a passphrase by capturing
the 4-way handshake messages and performing a dictionary
attack on the captured packets [6, 4, 5]. After the discovery
of this vulnerability, 802.11i was initiated to resolve the
problem, and Wi-Fi Protected Access 2 (WPA2), which
implements the technology and standards from 802.11i [12]
was born. A major improvement introduced by WPA2 is
the deployment of Counter Mode with Cipher Block
Chaining Message Authentication Code Protocol (CCMP)
[21], which utilizes the Advanced Encryption Standard
(AES) [14].
Although 802.11i is able to protect the key or passphrase
from being compromised, it is not completely secure.
Despite the evolution of WLAN security protocols from
WEP to WPA2, WLAN is still vulnerable to various denial
of service (DoS) attacks such as radio frequency jamming,
disassociation and deauthentication attacks [1], and
flooding [11, 8]. Specifically, the 802.11i 4-way handshake
is vulnerable to certain denial of service attacks including
the 1 Message DoS attack and the reflection attack [7].
These particular attacks will cause failure or an incomplete
4-way handshake. Hence, the client station will be unable
to authenticate itself to the access point under the
circumstances. Clearly, a new mechanism is needed to
counter these attacks and to ensure continuous availability
of data and network connectivity.
This paper focuses on addressing the problem of DoS
attacks against the 4-way handshake protocol in deterring
the 1 Message DoS attack. It explores previously conducted
studies and research of proposed solutions [11, 8]. This
paper introduces a new proposed solution by encrypting
Message 1 to maintain its confidentiality. The main
contribution of this paper is the design of the proposed
solution and the analysis of the results obtained from the
implementation of the proposed solution.
This paper is segmented according to the following
arrangement. Section 2 explains the overview of 802.11i 4-
way handshake protocol. Section 3 summarizes the related
works which have previously been done by others to
protect 802.11i 4-way handshake protocol from denial of
service attacks. Section 4 describes our proposed solution
in detail, the results analysis and future improvements to
strengthen it. Section 5 concludes the paper.
2. IEEE 802.11i
1
The IEEE 802.11i introduces the standard of CCMP [21]
based on a well known strong block cipher, the Advanced
Encryption Standard (AES) [12,14]. This eliminates the use
of the weak RC4 stream cipher key [9] in WPA and
increases the strength of the key in IEEE 802.11i with the
AES algorithm.
2.1 The 4-way Handshake Protocol
Figure 1. 802.11i 4-way handshake protocol [3, 4]
In WPA2, the PSK is generated from a 256-bit string
passphrase ranging from 8 to 63 characters [6]. In this
protocol, the pairwise master key (PMK) is actually equal
to the pre-shared key (PSK) [6]:
PMK = PBKDF22 (passphrase, SSID, SSID length, 4096,
256)
Initially, the authenticator will generate a random number,
ANonce. This element is then encapsulated inside Message
1 along with a sequence number. The sequence number is
used to prevent replay attacks [6, 4].
Upon receiving Message 1, the supplicant will generate
SNonce and derive a pairwise transient key (PTK) based on
the PMK, the received ANonce and the generated SNonce.
The derivation of the PTK can be expressed as in [6]:
PTK = PRF-X (PMK, Pairwise key expansion,
Min(Authenticator_MAC, Supplicant_MAC) ||
Max(Aauthenticator_MAC, Supplicant_ MAC) ||
Min(ANonce, SNonce) || Max(ANonce, SNonce))
1 supplicant before the supplicant has a chance to send
Counter Mode CBC Message Authentication Code
Protocol
2 to re-generate a new SNonce value and derive a new PTK
Password-Based Key Derivation Function from RSA
Public Key Cryptography Standards
PTK contains 4 temporal keys; key encryption key (KEK)
to protect the confidentiality of the handshake, key
confirmation key (KCK) for integrity of the handshake,
temporal key (TK) for data encryption and temporal MIC
key (TMK) for data authentication [6, 4].
The supplicant will then generate its own random number,
SNonce and compute the Message Integrity Code (MIC)
[2,9] using KCK. The purpose of the MIC is to ensure the
integrity of Message 2 [2,6,9]. Prior to receiving Message 2
from the supplicant, the authenticator will first extract the
SNonce, compute the PTK and derive temporal keys. The
KCK is used to verify the MIC in Message 2. If the
verification succeeds, the authenticator proceeds to send
Message 3 (consisting of Group Transient Key (GTK)
which is encrypted with KEK plus the MIC) [6].
Once the supplicant receives Message 3, it will verify the
MIC through the same process. If verification is successful,
the supplicant will install the PTK and GTK. Finally,
Message 4 is sent to the authenticator as an
acknowledgement message that PTK and GTK have been
successfully installed and the handshake is completed [6,4].
2.2 Weaknesses of the 4-way Handshake
Protocol
The principal factor which leads to the 1 Message DoS is
the lack of confidentiality and integrity of Message 1 in the
802.11i 4-way handshake protocol [6, 8]. In the standard 4-
way handshake, the ANonce sent from the authenticator to
the supplicant is transmitted in plaintext [6]. Since there is
no method of authentication or privacy protection at this
point, an attacker is able to capture and spoof this message
[11, 3, 7, 8].
Figure 2. One message denial of service attack
(Situation 1) [3, 7, 8]
Figure 2 shows an example of the 1 Message DoS attack on
the supplicant. In this situation, the attacker sends a forged
Message 1 which contains a new ANonce value to the
Message 2 to the authenticator. This causes the supplicant
value based on the ANonce received from the attacker [8].
Assume that these new values are SNonce’, PTK’ and
ANonce’. When the client sends Message 2 to the
authenticator, the MIC verification will fail because PTK ≠
PTK’ [3, 8]. Therefore, the handshake is incomplete.

Another situation of a similar DoS attack is shown in

Figure 3. When an attacker sends a spoofed Message 1, the
supplicant is forced to generate a new SNonce, derive a
new PTK based on the new ANonce and SNonce, and
finally store the new PTK [8]. Once the supplicant receives
Message 3 from the authenticator, the supplicant will verify
the MIC in Message 3 with its PTK. However, since the
new PTK value is different from the PTK used by the
authenticator, the MIC verification fails, resulting in an
incomplete handshake [8]. Hence, the supplicant fails to be
authenticated. The attacker can also choose to flood the
supplicant with spoofed Message 1. As a result, the
supplicant will experience memory exhaustion because it
needs to re-store the new ANonce, SNonce and PTK every
time it receives the spoofed Message 1 [8].
Figure 4. Message 1 authentication using MIC [8]

3.2 Nonce Re-use

In this method, the supplicant will re-use the same values
of SNonce until the legitimate handshake is completed and
PTK is installed in both the supplicant and authenticator
[8]. This approach requires the supplicant to store the
SNonce and derive a PTK based on the stored SNonce and
the received ANonce. When the supplicant receives
Message 3 from the authenticator, the supplicant will
derive a PTK again from the stored SNonce and received
ANonce to verify the MIC in Message 3.

The advantage of this approach is that it eliminates memory

Figure 3. One message denial of service attack
(Situation 2) [3, 7, 8]
exhaustion [8]. The supplicant is not required to store each
SNonce which is computed after receiving each Message 1.
However, more computational power is required at the
supplicant side due to the fact that the computation of PTK
is done twice. Hence, if an attacker is able to perform
Message 3 flooding on the client, it might lead to CPU
exhaustion [8].

3. RELATED WORKS 3.3 Enhanced 2-way Handshake Protocol

There are several solutions and implementations which had
been proposed to defend against denial of service attacks
on the 4-way handshake protocol [11, 3, 8, 1].

3.1 Message 1 Authentication

This solution proposes an authentication method in
Message 1 to ensure its integrity [8]. The basic concept is
to add the MIC inside Message 1. Before any messages are
exchanged in the 4-way handshake, both supplicant and
authenticator should already have a shared common secret
key which is the PMK. It is used by the authenticator to
derive the PTK, which is then used to compute the MIC.
When the supplicant receives Message 1, it will derive the
PTK from the PMK and use the derived PTK to verify the
value of the MIC. If verification is successful, the
supplicant will proceed to calculate the SNonce. Message 1
and Message 3 are still distinguishable by the secure bit [8]. Figure 5. Enhanced 2-way handshake protocol [11]
This proposed solution redesigns the WPA / WPA2
handshake into a 2-way handshake [11]. It consists of two
messages, MsgA and MsgB. Figure 5 depicts the proposed
solution.
MsgA which is sent by the authenticator, is encrypted with
the PMK. MsgA consist of ANonce, RNonce, and the SID,
which is the supplicant’s identification information (i.e.
MAC address) [11]. When the supplicant receives MsgA, it
will decrypt the packet and compare the SID value with its
own to verify if the authenticator is legitimate. If the
authenticator is successfully verified, MsgB will be sent to
the authenticator. Note that the RNonce in MsgB is the
same as the RNonce in MsgA [11]. Next, the authenticator
only needs to verify the value of RNonce before deriving
and installing the PTK.
The enhanced 2-way handshake protocol does not involve
any MIC, thus it uses less processing power [11]. This
simplified solution reduces the information exchange
between the supplicant and authenticator. However,
security is dependent on the PMK as it is used directly as
the key to encrypt both messages. Thus, the strength of the
key must be strong enough to withstand the success rate of
a dictionary or brute force attack.
3.4 Static and Dynamic 4-way Handshake
Protocol
There are three forms of the static 4-way handshake
protocol [3]:
i. Standard static solution
ii. Static solution with trade-off variant
iii. Static solution with trade-off variant and memory
release.
The methodology in the standard static solution is almost
similar to the method in nonce re-use as described in
section 3.2. The supplicant does not store the PTK value.
Instead, it stores the SNonce and re-computes the PTK
based on the stored SNonce and the received ANonce [3].
Static solution with trade-off variant requires the supplicant
to store all three values; ANonce, SNonce and PTK [3]. It
compares the value of the stored ANonce with the ANonce
in Message 3 before verifying the MIC. Memory
exhaustion occurs not only during a denial of service attack
scenario, but also during a normal no-attack scenario [3].
The third type of static solution overcomes this problem by
deleting the SNonce and ANonce values upon receiving
Message 3 from authenticator. This improved approach has
lower performance than the first standard static solution but
better performance compared to the second static solution
[3].
The dynamic solution adopts all three types of static
solutions with an additional intelligent software module;
which monitors the system parameters and memory,
controls the CPU load and threshold levels and is able to
switch between the three static solutions based on the
threshold value [3]. This implementation successfully
avoids denial of service attacks and flooding attacks [3].
4. PROPOSED SOLUTION
The proposed solution introduced in this paper attempts to
deter this type of DoS attack by using the Advanced
Encryption Standard (AES) [14] to ensure Message 1
confidentiality.
4.1 ANonce Encryption
At the initial stage of the 4-way handshake, both the
authenticator and the supplicant should already have
knowledge of the passphrase or PMK [11, 8]. Since PMK =
PBKDF2 (passphrase, SSID, SSID length, 4096, 256) [6],
it can be used as a key for encryption process.
When the authenticator generates the ANonce, it will use
the PMK as the key to encrypt the ANonce before sending
to the supplicant. In this paper, the AES cipher feedback
(AES-CFB) [20] block cipher mode is chosen to encrypt
the ANonce. Once the supplicant receives Message 1, it
will decrypt the ciphertext to obtain the ANonce. If both
passphrases used by the authenticator and the supplicant are
the same, the decrypted ciphertext will return a correct
ANonce value. If different passphrases were used to
encrypt or decrypt the ciphertext, the resulting ANonce will
be invalid as it contains symbols and special characters
which are unreadable. The ANonce will only be stored and
be used to compute PTK only if the ANonce is valid,
otherwise it will be rejected and dropped.
Figure 6. 4-way handshake with ANonce encryption
The proposed solution was implemented by using Python
[15] and the pyCrypto module [10] to simulate the Message
1 exchange between 3 nodes; the authenticator, the
supplicant, and the attacker. Two different simulations
were done. The first one was done to simulate the standard
4-way handshake, and the other one to simulate the
proposed solution. In the first simulation, all ANonce were
not encrypted and in the second simulation, the both the
authenticator and the supplicant used the same passphrase
as the key whereas the attacker used a different or no
passphrase. In both simulations, 50 packets were sent by
the attacker with 0.2, 0.02 and 0.002 second delay to
simulate typical network conditions, and the authenticator to distinguish between Message 1 coming from the
sent 5 packets randomly. authenticator or from an attacker’s node. Thus, the
supplicant accepts all transmissions of Message 1, re-
4.2 Results computes and re-stores the PTK over and over again until
all the allocated memory is used up. Additionally, the
Table 1 and Table 2 show the results from both supplicant was unable to verify the MIC in Message 3 since
simulations. the new recomputed PTK value is different from the PTK
used by the authenticator. This leads to an incomplete and
Table 1: 1 Message DoS flooding attack on the standard failed handshake.
4-way handshake
Delay Average time until Average In the second simulation, only legitimate packets which
(seconds) memory exhaustion throughput were sent by the authenticator were received and stored
(second) (packets per whereas the other packets sent by the attacker were
second) dropped. This proves that ANonce encryption can eliminate
0.200 1.825 5 the memory exhaustion threat and subsequently the 4-way
0.020 0.310 32 handshake failure caused by 1 Message DoS attack. The
0.002 0.160 64 overall message transmission performance was measured
by the time taken for the authenticator to encrypt each
Table 2: 1 Message DoS flooding attack on the proposed ANonce. From the results in Table 3, the time taken to
solution encrypt a packet is 0.00022 seconds. Since this value is so
Delay Average time until Average small, it can be considered almost negligible.
(seconds) memory throughput
exhaustion(second) (packets per The advantages of ANonce encryption is better
second) performance as compared to the Message 1 Authentication
0.200 - 5 method [8] because it does not require computing of the
0.020 - 32 MIC and complex integrity checking. The enhanced 2-way
0.002 - 64 Handshake Protocol proposed a solution which encrypts
more than one element (ANonce, RNonce and SID) and
The performance of the proposed solution was tested by major change from the 4-way handshake model as
sending 50 packets of unencrypted and encrypted ANonce proposed by 802.11i standard to a 2-way handshake [11].
without any delays between each packet. Three separate Since the MIC is completely stripped from the 2-way
tests were done to find the average value. handshake, the absence of integrity protection could pose a
Table 3: Performance comparison new threat to the implementation. The proposed solution in
Test 1 2 3 Average this paper only requires the encryption of the ANonce, thus
Without 0.031 0.031 0.031 0.031 reducing the computational power and time as compared to
ANonce the enhanced 2-way handshake. As ANonce encryption
encryption only involves modification to Message 1, it still maintains
(seconds) the other 4-way handshake message transmissions which
contain the MIC, thus preserving the authentication
With ANonce 0.031 0.047 0.047 0.042
mechanism which protects the integrity of Messages 2, 3
encryption
and 4.
(seconds)
Referring to Table 1, the time taken until memory The static and dynamic 4-way handshake solution requires
exhaustion occurs decreases rapidly if the attacker sends a a thorough investigation on the behavior of CPU and
higher number of packets per second. memory consumption in order to set the threshold [3].
However, different sets of devices or networks might have
Results from Table 2 show that the supplicant does not different behaviors and this adds to the complexity of the
experience any memory exhaustion at all, from the implementation, resulting in false accepts or false rejects.
beginning till the end of each simulation test. The proposed solution in this paper only requires firmware
modification in both supplicant and authenticator [11,8].
The proposed solution’s performance can be assessed by
referring to Table 3. For each packet sent, t = (average time Nevertheless, the proposed solution in this paper reveals a
/ 50); it takes 0.00062 seconds to send one unencrypted new vulnerability. Since the PMK is computed from the
packet and 0.00084 seconds to encrypt and send the packet. passphrase, it is possible for the attacker to obtain the
Hence, an average 0.00022 second difference is the time PMK. If the attacker manages to capture Message 1 during
needed for the authenticator to encrypt the packet. the 4-way handshake, the attacker could perform a
dictionary or brute-force attack against the captured
4.3 Evaluation Message 1. Thus, the strength of key depends on the
strength of the passphrase.
The results from both simulations prove that memory
exhaustion can be deterred by implementing the proposed Some improvements will be made to the proposed solution
solution. In the first simulation, the supplicant was unable in future work to obtain a more secure implementation.
 Further studies and analysis is needed to implement a better
encryption or block cipher mechanism to counter its
weakness.
One possible improvement is by introducing the
cryptographic hash function such as MD5 [19] or MD6
[16,17,18]. This could be done by hashing the pairwise
master key (PMK) prior to encrypting the ANonce. The
results from this hash will create a 32-bit hexadecimal
value which is considered to be a strong key. This process
can be done by both authenticator and supplicant to encrypt
and decrypt the ANonce.
5. CONCLUSION
The 802.11i security protocol is able to avoid any attack or
attempts to compromise the PMK or passphrase. It provides
data encryption and data authentication. However, it fails to
defend against certain DoS attacks such as the 1 Message
DoS attack on the 4-way handshake. After defining the
problem and studying other defense mechanisms, a new
proposed solution called the ANonce encryption is
designed and evaluated. This proposed solution was tested
using simulations. Results from the simulations proved that
it could deter 1 Message DoS attack/flooding and prevent
memory exhaustion. However, the proposed solution might
open the possibility for an attacker to perform a dictionary
or brute-force attack and then, if successful, obtain the
passphrase and compromise the overall security.
Consequently, enhancements will be made to the proposed
solution in future work.
6. REFERENCES
[1] Bellardo, J., and Savage,S. 2003. 802.11 Denial-of-
Service Attacks: Real Vulnerabilities and Practical
Solutions. In Proceedings of USENIX Security
Symposium.
[2] Cagalj, M., Capkun, S., Rengaswamy, R.,
Tsigkogiannis, I., Srivastava, M., Hubaux, J. P. 2006.
Integrity (I) Codes: Message Integrity Protection and
Authentication Over Insecure Channels. In IEEE
Symposium on Security and Privacy. Oakland,
California, USA.
[3] De Rango, F., Lentini, D.C., and Marano, S. 2006.
Static and Dynamic 4-Way Handshake Solutions to
Avoid Denial of Service Attack inWi-Fi Protected
Access and IEEE 802.11i. In EURASIP Journal on
Wireless Communications and Networking, 1-19.
[4] Edney, J., and William, A. A. 2003. Real 802.11
Security: Wi-Fi Protected Access and 802.11i.
Addison-Wesley. Boston.
[5] Fluhrer, S., Mantin, I., and Shamir. 2001.
A.Weaknesses in the Key Scheduling Algorithm of
RC4. In Proceedings of the 8th Annual International
Workshop on Selected Areas in Cryptography.1-24.
[6] Guillaume, L. June 2005. Wi-Fi security – WEP,
WPA and WPA2. In Hackin9. Available at
http://www.hakin9.org.
View publication stats
[7] He, C., and Mitchell, J. C. 2005. Security Analysis
and Improvements for IEEE 802.11i. In NDSS.
[8] He, C., and Mitchell, J. C. 2004. Analysis of the
802.11i 4-Way Handshake. In WiSe'04. 43-50.
[9] Huang, J., Susilo, W., Seberry, J. December 2004.
Observations on the Message Integrity Code in IEEE
802.11 Wireless LANs. In WITSP'04. Adelaide,
Australia.328-332.
[10] Kuchling, A. M. September 2008. Python
Cryptography Toolkit. Available at
http://www.amk.ca/ python/code/crypto.html
[11] Liu,J., Ye,X., Zhang, J., and Li, J. 2008. Security
Verification of 802.11i 4-way Handshake Protocol.
In ICC 2008.1642-1647.
[12] IEEE Standard 802.11i-2004. 2004. 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.
[13] IEEE Standard 802.11-1999. 1999. Information
technology – Telecommunications and information
exchange between systems – Local and metropolitan
area networks – Specific requirements – Part 11:
Wireless LAN Medium Access Control and Physical
Layer specifications.
[14] National Institute of Standards and Technology.
November, 2001. Announcing the Advanced
Encryption Standard (AES). In Federal Information
Processing Standards Publication 197.
[15] Python: http://www.python.org
[16] Rivest, R. L. The MD6 hash function - A proposal to
NIST for SHA-3.
[17] Rivest, R. L. The MD6 Hash Algorithm. Available at
http://groups.csail.mit.edu/cis/md6/
[18] Rivest, R. L., Agre, B., Bailey D.V., Crutchfield C.,
Dodis, Y., Fleming, K.E., Khan, A., Krishnamuthy,
J., Lin, Y., Reyzin, L., Shen, E., Sukha, J.,
Sutherland, D., Tromer, E. and Yin, Y.L. October
2008. The MD6 Hash Function-A proposal to NIST
for SHA-3. Rivest’s CRYPTO’08. Available at
http://groups.csail. mit.edu/cis/md6/submitted-2008-
10-27/ Supporting_ Documentation/md6_report.pdf
[19] Robshaw, M. J. B. November 1996.On Recent
Results for MD2, MD4 and MD5”,In RSA
Laboratories’ Bulletin.
[20] RSA Laboratories. 2009. What is Cipher Feedback
Mode? Available at http://www.rsa.com/
rsalabs/node. asp?id=2172
[21] Shim, J.H., Kwon, T. W., Kim, D. W., Suk, J. H.,
Choi, Y.H., and Choi, J.R. 2003.Compatible Design
of CCMP and OCB AES Cipher for Wireless LAN
Security. In SOC Conference, 2003. Proceedings
IEEE International [Systems-on-Chip].