A Software-deﬁned Networking-based Detection and Mitigation

Approach against KRACK

Yi Li

, Marcos Serrano

, Tommy Chin

, Kaiqi Xiong

and Jing Lin

Intelligent Computer Networking and Security Lab, University of South Florida, Tampa, U.S.A.

Department of Computing Security, Rochester Institute of Technology, Rochester, U.S.A.

Keywords:

KRACK, Software-deﬁned Networking, WPA2, Network Security.

Abstract:

Most modern Wi-Fi networks are secured by the Wi-Fi Protected Access II (WPA2) protocol that uses a 4-way

handshake. Serious weaknesses have been discovered in this 4-way handshake that allows attackers to perform

key reinstallation attacks (KRACKs) within the range of an Access Point (AP) to intercept personal informa-

tion. In this paper, we study KRACK and present a software-deﬁned networking (SDN)-based detection and

mitigation framework to defend against KRACK. The proposed framework leverages the characteristic of an

SDN controller, a global view of a network, to monitor and manage a Wi-Fi network trafﬁc. It consists of two

main components: detection and mitigation modules. Both of them are deployed on the SDN controller. The

detection module will monitor network trafﬁc and detect the duplicated message 3 of the 4-way handshake.

Once KRACK has been detected, the mitigation module will update the ﬂow table to redirect the attack trafﬁc

to a splash portal, which is a place to store attack trafﬁc. Extensive experimental results demonstrate that the

proposed framework can efﬁciently detect and mitigate KRACK. We achieve an average of 170.926 ms to

detect KRACK and an average of 10.041 ms to mitigate KRACK in our experiments.

1 INTRODUCTION

WPA2 is a widely used protocol developed by the

Wi-Fi Alliance to secure the majority of wireless

networks. A WPA2 encrypted network can defend

against intruders and identity thieves by providing

unique encryption keys when a client is trying to

connect to a network. However, researchers have

discovered some vulnerabilities of WPA2 (Kumkar

et al., 2012; Tsitroulis et al., 2014a). WPA2 uses

two keys, Pairwise Transient Key (PTK) and Group

Temporal Key (GTK), for encryption. A PTK is es-

tablished through the 4-way handshake deﬁned in the

802.11i, and it is unique for each client. A GTK is

randomly generated by Access Point (AP), and it is

shared among all clients. Such APs can be imple-

mented as routers, modems, or gateways. Attackers

can manipulate the GTK to launch attacks since it is

used as an encryption key in the AP and a decryption

key for clients. Attackers can inject forged data trafﬁc

through a GTK to all associated clients. Therefore, it

can possibly result in several types of attacks, such as

man-in-the-middle (MitM) attacks and denial of ser-

vice (DoS) attacks (Teyou and Zhang, 2018).

In October 2017, researchers discovered a seri-

ous ﬂaw in the WPA2 protocol that allows attackers

within the range of an AP to perform KRACK (Van-

hoef and Piessens, 2017). To be precise, attackers can

intercept and steal a client’s information, such as pass-

words, emails, and credit card numbers, that should

be safely encrypted. In some scenarios, it is also pos-

sible for attackers to inject malicious contents or ma-

nipulate data on the website that a client is visiting.

Correct implementation of WPA2 is likely to be af-

fected since this weakness is in the Wi-Fi standard

itself. Furthermore, the researchers have investigated

devices that are still affected by KRACK and devel-

oped generalized attacks based on it (Vanhoef and

Piessens, 2018). Moreover, they have recently discov-

ered an easier way to attack unpatched devices and

bypass the Wi-Fi’s ofﬁcial countermeasure against

KRACK.

In order to alleviate this issue, a framework called

KrackCover was proposed to detect KRACK (Chin

and Xiong, 2018). It will send an alert to the client

once the attack has been detected. The experiment is

conducted in the public network such as coffee shops

and libraries. This approach can effectively warn

clients for potential threats of KRACK. However, it

did not provide any solution to mitigate the attack.

244

Li, Y., Serrano, M., Chin, T., Xiong, K. and Lin, J.

A Software-deﬁned Networking-based Detection and Mitigation Approach against KRACK.

DOI: 10.5220/0007926202440251

In Proceedings of the 16th International Joint Conference on e-Business and Telecommunications (ICETE 2019), pages 244-251

ISBN: 978-989-758-378-0

After a careful investigation of KRACK, we pro-

pose a Software-Deﬁned Networking based detection

and mitigation framework to defend against KRACK.

SDN is an emerging paradigm with the beneﬁts of

network visibility and network device programmabil-

ity, and it is widely used in network security. With the

separation of the control plane and the infrastructure

plane, an SDN network is very easy to be managed

by a centralized SDN controller since it has a global

view of the whole network. Many researchers have

adopted SDN in network management and network

security (Scott-Hayward et al., 2013; Yan et al., 2016;

Xie et al., 2018).

The proposed framework consists of the two main

modules: detection and mitigation. Speciﬁcally, we

apply SDN to a Wi-Fi AP where Wi-Fi’s short-haul

communications are converted into long-haul com-

munications to the Internet using SDN. That is, the

conversion of communication data are processed by

an SDN switch under the management of an SDN

controller. In the detection module of the proposed

framework, the SDN controller inspects each incom-

ing Wi-Fi network request where the duplicated mes-

sage 3 of the 4-way handshake will be detected when

an attacker launches KRACK. We conﬁgure an AP to

be functioned as an OpenFlow vSwitch (OVS), which

is monitored and managed by the SDN controller. The

detection module is deployed on the SDN controller

since the controller has a global view of the network.

First, the SDN controller monitors all the trafﬁc going

through the network. Then, if an attacker launches

KRACK to target a victim, the detection module can

detect this attack by checking duplicated message 3

of the 4-way handshake. Next, once the attack has

been detected, the mitigation module will update the

entries of ﬂow table in the OVS to re-direct the trafﬁc

ﬂows to a splash portal, which is a place to store at-

tack trafﬁc. The proposed framework can effectively

defend against KRACK with the SDN architecture.

The rest of the paper is organized as follows. Sec-

tion 2 presents related work about Wi-Fi security.

Section 3 gives the threat model. Section 4 introduces

the design of the proposed framework. Next, Sec-

tion 5 discusses the evaluation of the proposed frame-

work, such as detection time. Lastly, Section 6 con-

cludes our studies and presents future work.

2 RELATED WORK

Many studies have been done in the security of Wi-

Fi networks (Yang and Huang, 2018; Alblwi and

Shujaee, 2017; Noh et al., 2016). Tsitroulis et

al. (Tsitroulis et al., 2014b) studied the WPA2 se-

curity protocol and presented several vulnerabilities

of the WPA2 protocol. As the increasing number

of devices are connected to Wi-Fi networks, it be-

comes very important to secure those wireless net-

works. Akram et al. (Akram et al., 2018) explored

the security aspect of residential wireless local area

network (WLAN) AP in a real-time scenario. The po-

tential vulnerabilities in media access control (MAC)

ﬁltering, Hidden Service Set Identiﬁer (SSID), and

WPA2 have been investigated. They proposed a three-

layer security mechanism to secure the WLAN AP.

Ghanem et al. (Ghanem and Ratnayake, 2016)

explored potential attacks against WPA2 pre-shared

key (WPA2-PSK), such as deauthentication attacks.

This type of attacks will make Wi-Fi clients to re-

authenticate an AP with the attacker’s intent to cap-

ture the authentication keys during an 802.11 hand-

shake. To prevent this type of attacks, they pro-

posed a novel re-authentication protocol to improve

the 4-way handshake without any hardware upgrade

or cryptography algorithms. Their experimental re-

sults further showed that the proposed protocol ef-

fectively enhance the security of WPA2-PSK without

compromising the performance of the network.

Since 2017 (Vanhoef and Piessens, 2017; Van-

hoef and Piessens, 2018), researchers have been stud-

ied the effects of KRACK and detection methods to

identify the attacks. Feh

er et al. (Feh

er and Sandor,

2018) presented the effects of KRACK and its corre-

sponding user behavior analysis. A quantitative sur-

vey was created and ﬁlled out by 379 people. The sur-

vey results showed that many experienced users had

updated the security patch to avoid KRACK. How-

ever, many users tended to use weak passwords that

attackers can decrypt easily. While they argued that

the best solution to countermeasure KRACK is to up-

date each respective wireless device with its appropri-

ate security patch, some devices cannot be patched for

an update due to end-of-life support by vendors.

The security of the Internet of Things (IoT) is very

important as there are many IoT devices in our daily

life. Terkawi et al. (Terkawi and Innab, 2018) pre-

sented some major impacts of KRACK on IoT. They

studied how attackers can perform KRACK on IoT

and the potential damages that KRACK may pose on

IoT. They showed that KRACK not only will compro-

mise privacy but also will compromise the connected

access control and may pose potential long-term dam-

ages in IoT.

Chin et al. (Chin and Xiong, 2018) proposed a

framework called KrackCover, which is a wireless se-

curity framework for detecting KRACK. KrackCover

is designed to assist in the detection of KRACK and

to provide suggestions to help protect the privacy of

A Software-deﬁned Networking-based Detection and Mitigation Approach against KRACK

245

clients. When KRACK is detected, the alert evokes

the client. KrackCover consists of two virtual ma-

chines (VMs), a mobile phone, and multiple wire-

less antennas for monitoring and capturing all 802.11

messages. For the two VMs, one is used for launch-

ing the attack, and the other is used for detecting the

attack. The experiment was carried out in real-world

Wi-Fi environments, including coffee shops and pub-

lic libraries.

Naitik et al. (Naitik et al., ) ran experiments of

KRACK and presented a detection scheme to detect

the threat. The detection was constructed with the fol-

lowing steps. First, the detection system extracted the

Ethernet layer of network packets followed by the ex-

traction of the IEEE802.1x header and then an extrac-

tion of the WPA key data. At last, the system checks

for duplicated message 3. Victims of the attack were

alerted if duplicate packets were detected.

To detect and mitigate KRACK, Securing

Sam (Sam, 2019) has developed a detector and

has given some mitigation suggestions (Securing

Sam, 2019), such as using Advanced Encryption

Standard (AES), disabling fast roaming, updating

Wi-Fi software in a manual fashion, and actively

monitoring for rogue APs.

SDN has become a popular paradigm due to its

programmability and characteristic of the global view

of a network which can easily be adapted to monitor

and manage network trafﬁc. Many research studies

started to explore the use of SDN to improve net-

work performance and security (Shin et al., 2016;

Cheminod et al., 2017; Manzoor et al., 2018). In this

paper, we utilize the beneﬁts of SDN controller and

proposed a detection and mitigation framework based

on SDN to defend against KRACK.

3 THE THREAT MODEL

KRACK utilizes the ﬂaws of the Wi-Fi standard pro-

tocol to reinstall an already-in-use key. It aimed at

attacking the 4-way handshake of the WPA2 pro-

tocol by manipulating and replaying cryptographic

handshake messages. When a client attempts to con-

nect to a protected network through an AP, the hand-

shake is performed to verify the credentials of both

the AP and the client. In this paper, we focus on the

Linux/Android vulnerability due to the large magni-

tude of devices that are affected by it. KRACK occurs

in the following manners in details.

1. An attacker waits for a client/victim to connect

or reconnect to a Wi-Fi network AP. For the latter sit-

uation, an attacker transmits a specially crafted packet

to dissociate the client from the AP, also known as a

deauthentication attack. Prior to a client connecting

to the AP, the attacker leverages a separate rogue AP

that falsely broadcasts the SSID of a legitimate Wi-

Fi network. Client devices that connect and associate

to the attacker’s rogue AP present the ability for the

attacker to execute a MitM attack.

2. The attacker ﬁrst detects the client’s connec-

tion attempt by capturing the wireless communica-

tion exchange for a WPA2 handshake packet. The at-

tacker then proceeds to stage a rogue Wi-Fi network

with a matching SSID to trick the victim’s machine to

connect to the attacker’s AP. Commonly, wireless de-

vices often connect to an AP with the strongest signal

strength unless designated by a user-deﬁned param-

eter such as an operating system setting or a driver

conﬁguration. A rogue AP for this attack case often

distinguishes itself from other Wi-Fi APs through the

signal strength metric to lure a victim machine to con-

nect to the rogue Wi-Fi network. An attacker may ac-

complish a MitM once a victim connects to a rogue

Wi-Fi network by means of the attacker forwarding

trafﬁc between a legitimate network and the victim.

3. As the new MitM, the attacker then listens

for the WPA2 handshake. During this handshake,

the third message of the handshake exchanges a key

nonce that the attacker will withhold. The attacker

will take these packets and replay them multiple times

to the victim or a target machine. Because a pro-

tocol implementation bug in Linux/Android devices,

the WPA2 key will be cleared at which point the at-

tacker installs an all-zero key, or no encryption.

Effects of KRACK can be disastrous, as other

forms of encryption such as SSL/TLS may be re-

moved in combination with well-known methods. For

this reason, an attacker may obtain any information,

such as credit card numbers, personally identiﬁable

information, or authentication credentials with mini-

mal effort.

4 METHODOLOGY

We propose an SDN-based solution to detect and mit-

igate KRACK. The main modules in this framework

are detection and mitigation. Besides these two main

modules, we also implement an attack module in this

framework. The standard Wi-Fi protocol uses the 4-

way handshake to generate a session key, but it is vul-

nerable to key re-installation attacks. Figure 1 shows

the architecture of the proposed framework. While

the solid black lines represent the normal trafﬁc go-

ing through the wireless network, the red dotted lines

show network trafﬁc generated by attackers, and the

blue dashed lines indicate the wireless trafﬁc with

SECRYPT 2019 - 16th International Conference on Security and Cryptography

246

Figure 1: The Proposed Framework.

detection and mitigation. The SDN controller has

a global view of this network so it can monitor and

manage client authentication requests.

Initially, because of the vulnerability of the 4-way

handshake, an attacker may attack the client easily

through the AP once the client is connected to this

network. When we adopt the SDN paradigm, the

SDN controller will monitor the trafﬁc going through

the network. The AP functions as the OVS since all

end devices are connected to it. The detection module

and mitigation module are deployed on the SDN con-

troller in order to take advantage of the controller. As

shown in the blue dashed lines of Figure 1, labels 1, 2,

3, and 4 represent four different actions in this frame-

work, respectively. They are discussed in detail as fol-

lows. Label 1 represents that an attacker launches the

attack through AP. Label 2 indicates that the detector

on the SDN controller will a) monitor the trafﬁc, b)

detect KRACK, and c) mitigate the attack trafﬁc by

updating the ﬂow table. Label 3 means that after the

SDN controller updates the entries of the ﬂow table,

the attack trafﬁc ﬂows will be redirected to a splash

portal. Label 4 means if the trafﬁc ﬂow is not de-

tected as KRACK, it will be sent to the clients. To

be precise, we divide the framework into three stages:

1) attack stage, 2) detection stage and 3) mitigation

stage.

4.1 Attack Stage

Most Wi-Fi networks are protected by some version

of WPA or WPA2, which rely on the 4-way handshake

deﬁned in the 802.11i protocol. However, the design

of the 4-way handshake has serious ﬂaws that make

it vulnerable to key reinstallation attacks. In the at-

tack stage, we perform KRACK proposed in (Vanhoef

and Piessens, 2017; Vanhoef and Piessens, 2018). A

client/victim is tricked to reinstall an already-in-use

key so that the attacker can steal the victim’s personal

information and even inject false data. KRACK is

Figure 2: The Procedure of Attacking the 4-way Hand-

shake.

achieved by replaying and manipulating messages 3

of the 4-way handshake.

The attack procedure is shown in Figure 2. When

a client is trying to connect to a network, the 4-way

handshake will be executed. The 4-way handshake

provides mutual authentication based on the Pairwise

Master Key (PMK) (a shared master secret) and nego-

tiates a PTK. The PTK is derived from the PMK. The

supplicant (client) receives message 1 and sends mes-

sage 2 to the authenticator (AP). The supplicant will

install the PTK and the GTK after receiving message

3 from the authenticator. Then, a data-conﬁdentiality

protocol will be used to encrypt normal data frames

after the installation of the PTK and the GTK. If the

supplicant does not send message 4 to the authenti-

cator as the response of acknowledgment, the authen-

ticator will think that message 3 may be dropped or

lost. Therefore, the authenticator will retransmit mes-

sage 3 to the supplicant. As a result, the supplicant

will receive message 3 multiple times. Each time the

supplicant receives message 3, the same PTK will be

reinstalled and the associated parameters, such as re-

ceive packet number (i.e. replay counter) and incre-

mental transmit packet number (i.e. nonce), are reset

to their initial values.

In KRACK, an attacker will ﬁrst establish a MitM

position between the supplicant and the authenticator.

The attacker uses this MitM position to prevent mes-

sage 4 from arriving at the authenticator. Then, the

attacker can utilize the retransmission manner of mes-

sage 3 to reinstall an already-in-use PTK and force re-

set the value of nonce and replay counter. By reusing

the nonce and the replay counter, the attacker can at-

tack the data-conﬁdentiality protocol, such as replay,

as well as decrypt and forge the packets. The above

can pose great threats to end user’s privacy.

A Software-deﬁned Networking-based Detection and Mitigation Approach against KRACK

247

Figure 3: (a) Simpliﬁed Layout of an EAPOL Frame (b)

Procedure of the Detection Stage.

4.2 Detection Stage

Since every message in the 4-way handshake is de-

ﬁned using EAPOL frames, it can be used to detect

the duplicated packets. As shown in Figure 3 (a),

the header deﬁnes the n-th message in the handshake.

The replay counter ﬁeld is used to count the replay

frames. When the authenticator sends a message to

the supplicant, the replay counter will be increased

by one. If the supplicant receives the message and

replies to the authenticator, the same replay counter is

used. The nonce ﬁeld can be used to detect the reuse

of nonce since it transmits the fresh session key that

derived from the random nonces generated by suppli-

cant and authenticator. Therefore, the replay counter

ﬁled and nonce ﬁeld are extremely helpful to detect

the reinstallation of an already-in-use key. To be pre-

cise, if message 3 is retransmitted, a duplicated nonce

will be transmitted and we just need to check if there

is a reuse of nonce.

The SDN controller will monitor all the trafﬁc go-

ing through the network by the wireless interface. In

order to detect KRACK, the trafﬁc packets need to

be ﬁltered and captured only EAPOL packets. The

detection procedure is shown in Figure 3 (b). First,

the Ethernet layer is extracted. Then, the IEEE802.1x

header is extracted from the Ethernet layer. Next,

WPA key data is extracted from IEEE802.1x header.

At last, we analyze the WPA key data and check for

the duplicate message 3 from EAPOL packets. If the

reuse of nonce is detected, it will proceed to the miti-

gation stage. If there is no duplicated message 3, then,

it will examine the next trafﬁc ﬂow.

4.3 Mitigation Stage

In an SDN network, the controller manages the trafﬁc

by adding rules in the ﬂow table in the OVS. The con-

troller communicates with the OVS through a secure

channel, which is deﬁned by the OpenFlow Protocol.

An entry of the ﬂow table consists of three important

ﬁelds: a header ﬁeld, an action ﬁeld, and a statis-

tic ﬁeld. The header ﬁeld is used to deﬁne the ﬂow

and the statistic ﬁeld stores the network information

of the ﬂow, such as time-stamp of a packet that was

last seen and the number of ﬂows forwarded. The path

of a ﬂow can be directed in the action ﬁeld. The ﬂow

can be handled by the following actions: forward to a

destination port or ports, encapsulate and forward to

the controller, or forward through the switch’s normal

processing pipeline.

In our study, we set up a splash portal to store at-

tack trafﬁc. We utilized the characteristic of the SDN

network to update the ﬂow rules in the ﬂow table to

prevent the attack trafﬁc to be forwarded to the client.

When KRACK is detected in the detection stage by

checking the duplication of message 3, it will pro-

ceed to the mitigation stage. In this stage, we add

a ﬂow rule in the OVS to forward the attack trafﬁc to

the splash portal instead of forwarding it to the client.

If there is no attack detected, the trafﬁc will be for-

warded through its normal path. In this way, the at-

tack trafﬁc will not be forwarded to the client. Mean-

while, we will send an alert to warn the clients.

4.4 Hardware Conﬁguration

In this study, the experiment was set up in the lab en-

vironment. We constructed an SDN network to de-

tect and mitigate KRACK. We used a Raspberry Pi

3 Model B, which has the speciﬁcation of a Quad

Core 1.2GHz Broadcom BCM2837 64bit CPU and

1GB RAM, as the SDN controller. We utilized

a wireless antenna, an Alfa AWUS036NHA High

Gain, to capture the nearby trafﬁc. We setup Flood-

light (Big Switch Networks, 2018) controller to mon-

itor and update the ﬂow rules. The detection and mit-

igation scripts were deployed on the SDN controller.

A TP-Link AC 1750 Router was used as the AP and

was conﬁgured as an OVS. A desktop with 16GB of

memory and a quad-core processor was used to host

two virtual machines: one was used as an attack ma-

chine and the other was used as a splash portal. The

attack machine was running Kali Linux operating sys-

tem with 2G of memory and a dual-core processor. To

launch KRACK, we utilized two wireless antennas,

a TP-Link WN722n v1 and an Alfa AWUS036NHA

High Gain. The splash portal was running Ubuntu

SECRYPT 2019 - 16th International Conference on Security and Cryptography

248

Table 1: Times Recorded in the Experiment.

Script Metrics Description

Attack Script

Atk1 Time at which attack script begins

Atk2 Time at which ﬁrst message 3 was sent from authenticator

Atk3 Time at which the duplicated message 3 was sent from authenticator

Detection Script

Det1 Time at which ﬁrst message 3 was detected

Det2 Time at which the duplicated message 3 was detected

Det3 Time at which mitigation starts

Mitigation Script

Mtg Time at which mitigation ends

with 1GB of memory and a single core processor.

Lastly, we adopted a Samsung Galaxy S7 Edge to

connect to the SDN wireless network with WPA2 en-

cryption to test our experiment setup.

5 EVALUATION

To run the experiment, we ﬁrst started the Flood-

light in the background to monitor the trafﬁc going

through the network. Next, we conﬁgured the AP to

enable OVS functions. We have adopted an online

KRACK detector courtesy of Securing Sam’s Github

script (Sam, 2019) and modiﬁed it to meet the goal

in our experiment. We have also written a mitiga-

tion script to update the ﬂow table and integrated it

with the modiﬁed detection script. The attack script is

adopted from (Vanhoef and Piessens, 2017) with little

modiﬁcation. We have also modiﬁed both the attack

script and the detection script to keep track of impor-

tant time metrics as shown in Table 1. The detection

script makes use of raw sockets to allow for detailed

packet analysis. The analysis takes place byte by byte,

ensuring the packet meets the criteria of the message

3 in the WPA2 handshake before continuing. Finally,

once we capture the ﬁrst message 3, the key nonce is

stored for future comparison against other packet key

nonces. Success at the detection stage led to the miti-

gation stage, and the controller will reroute the attack

trafﬁc to the splash portal by updating the ﬂow table.

5.1 Experimental Results

The time metrics recorded in the attack script, detec-

tion script, and mitigation script and their description

are showing in Table 1. There are three time metrics

in the attack script, three time metrics in the detection

script, and one time metric in the mitigation script.

By analyzing the time metrics recorded in the exper-

iment, we can obtain some important time measure-

ments such as detection time and mitigation time. We

extracted six time measurements to evaluate our de-

tection and mitigation scheme. The detailed descrip-

tion of six time measurements are given as follows:

1. KRACK Detection Time: It measures the time

of detecting KRACK. It is the time from the mo-

ment the authenticator sent the duplicated message 3

to the moment the duplicated message 3 is detected

by the detection module. Therefore, it is calculated

by Det2 − Atk3.

2. KRACK Mitigation Time: It is deﬁned as

the time from the moment the mitigation starts

to the moment the mitigation ends. That is,

KRACK Mitigation Time = M tg − Det3. After the

duplicated message 3 is successfully detected, the

mitigation starts, the controller will update the ﬂow

table to redirect the trafﬁc to the splash portal. On the

splash portal, we use a socket to listen to the trafﬁc

and record the time when we receive the ﬁrst packet

redirected to it.

3. First Message 3 Detection Time: This is the

time of detecting the ﬁrst message 3. It is the time

from the moment the authenticator sent the ﬁrst mes-

sage 3 to the moment the ﬁrst message 3 is detected

by the detection module. First message 3 detection

time is Det1 − Atk2.

4. Overall Experiment Time: This measures the

overall time taken to run the experiment, from the

time at which attack starts to the time at which mit-

igation ends. It is calculated as Mtg − Atk1.

5. Attack Script Runtime: It is the time from the

moment the attack script begins to the moment the

authenticator sends the duplicated message 3. It can

be calculated as Atk3 − Atk1.

6. Detection Script Runtime: This is the time be-

tween the ﬁrst message 3 detected and the duplicated

message 3 detected. It measures the runtime of the

detection script. It can be calculated by Det2 − Det1.

Figure 4 shows the six time measurements over

500 successful KRACK. The times are recorded in

milliseconds. We can see from the ﬁgure that the pat-

tern of KRACK detection time, ﬁrst message 3 de-

tection time, and overall experiment time are similar.

Since KRACK detection time is the time between du-

A Software-deﬁned Networking-based Detection and Mitigation Approach against KRACK

249

(a)

(b)

(d) (e)

(c)

(f)

Figure 4: Time Measurements Recorded From 500 KRACK.

Table 2: Time Measurements (ms).

Time Name Mean Median Mode Max Min Std

KRACK Detection Time 170.926 163.527 164.819 303.315 12.738 70.410

KRACK Mitigation Time 10.041 10.107 8.351 11.992 8.01 1.176

First Message 3 Detection Time 233.832 227.832 49.839 366.092 49.839 72.805

Overall Experiment Time 296.467 268.851 336.879 479.595 132.003 71.930

Attack Script Runtime 115.456 112.279 109.22 217.079 108.312 12.085

Detection Script Runtime 0.475 0.341 0.318 6.464 0.192 71.930

plicated message 3 sent and detected and the ﬁrst mes-

sage 3 detection time is the time between ﬁrst mes-

sage 3 sent and detected, it demonstrates that our de-

tection rate is pretty robust. Figure 4 (b) presents the

mitigation time of KRACK, where we can see that the

mitigation time is evenly distributed. The mitigation

time includes the time controller responds to update

the ﬂow table and the communication to OVS to nav-

igate the new path to the splash portal. Figure 4 (e)

and (f) shows the running time of both attack script

and detection script over 500 KRACKs. Most running

times during the attacks are stable except for some at-

tacks, they tend to have longer running time.

Table 2 shows the time analysis of these six

time measurements. We analyzed the mean, median,

mode, max, min and stand derivation of these time

measurements. We can see from the table, a success-

ful KRACK requires 115.456 ms on average while

the fastest KRACK detection time is 12.738 ms and

the fastest mitigation time is 8.01 ms. We can see that

the standard derivation of mitigation time is 1.176 ms,

which is very small. It shows that the mitigation time

is usually stable in our experiments. The average time

to detect the ﬁrst message 3 packet is 233.832 ms. De-

tecting KRACK requires an average time of 170.926

ms, and we can see that the maximum KRACK detec-

tion time is much higher than the minimum KRACK

detection time. There could be a propagation delay in

the transmission due to the environmental constraints.

6 CONCLUSIONS AND FUTURE

WORK

In this research, we have proposed an SDN-based de-

tection and mitigation framework to defend against

KRACK. Because of the global view of an SDN

controller, we deployed our detection and mitigation

module on the SDN controller to better monitor and

manage the attack trafﬁc. In the framework, we have

three stages: attack stage, detection stage, and mit-

igation stage. In the attack stage, an attacker tried

to deceive the authenticator to retransmit message 3

SECRYPT 2019 - 16th International Conference on Security and Cryptography

250

and trick the client to reinstall an already-in-use key.

In the detection stage, we monitor all the trafﬁc go-

ing through the SDN network and check for the du-

plicated message 3 transmission to detect KRACK.

Finally, in the mitigation stage, the ﬂow table was up-

dated to navigate the attack trafﬁc to a splash portal.

The experiment was set up in a lab environment and

important time metrics were recorded for evaluating

the framework. Experimental results show that the de-

tection and mitigation scheme in the proposed frame-

work is very efﬁcient to defend against KRACK.

In the future work, we will study the scalabil-

ity of the proposed framework. We will conduct the

experiments in a large scale real-world network. In

the meantime, we will try to attack multiple clients

by exploring different attacks within the umbrella of

KRACK and investigate machine learning schemes to

classify those attacks based on different attack types.

ACKNOWLEDGEMENT

We acknowledge NSF to partially sponsor the re-

search work under grants #1633978, #1620871,

#1636622, #1651280, #1620862, and #1620868, and

BBN/GPO project #1936 through an NSF/CNS grant.

REFERENCES

Akram, Z., Saeed, M. A., and Daud, M. (2018). Real

time exploitation of security mechanisms of residen-

tial WLAN access points. In IEEE iCoMET, pages

1–5.

Alblwi, S. and Shujaee, K. (2017). A survey on wireless se-

curity protocol wpa2. In Int. Conf. security and man-

agement, pages 12–17.

Cheminod, M., Durante, L., Seno, L., Valenza, F., Valen-

zano, A., and Zunino, C. (2017). Leveraging SDN

to improve security in industrial networks. In IEEE

WFCS, pages 1–7.

Chin, T. and Xiong, K. (2018). KrackCover: A wireless

security framework for covering KRACK attacks. In

WASA, pages 733–739.

Feh

er, D. J. and Sandor, B. (2018). Effects of the

WPA2 KRACK attack in real environment. In IEEE

SISY, pages 239–242.

Ghanem, M. C. and Ratnayake, D. N. (2016). En-

hancing WPA2-PSK four-way handshaking after re-

authentication to deal with de-authentication followed

by brute-force attack a novel re-authentication proto-

col. In IEEE CyberSA, pages 1–7.

Kumkar, V., Tiwari, A., Tiwari, P., Gupta, A., and Shrawne,

S. (2012). Vulnerabilities of wireless security proto-

cols (WEP and WPA2). IJARCET, 1(2):34–38.

Manzoor, S., Akber, S. M. A., Menhas, M. I., Imran, M.,

Sajid, M., Talal, H., and Samad, U. (2018). An

SDN enhanced load balancing mechanism for a multi-

controller wiﬁ network. In IEEE ICPESG, pages 1–5.

Big Switch Networks ([Online]. Sept. 2018).

Project Floodlight. Available: http://www.project

ﬂoodlight.org/.

Naitik, S., Lobo, R., Vernekar, P. S., and Shetty, V. G. Miti-

gation of key reinstallation attack in WPA2 Wi-Fi net-

works by detection of nonce reuse. In IRJET, pages

1528–1531.

Noh, J., Kim, J., Kwon, G., and Cho, S. (2016). Secure key

exchange scheme for WPA/WPA2-PSK using public

key cryptography. In IEEE ICCE-Asia, pages 1–4.

Sam, S. ([Online]. 2019). KRACK detector. Available:

https://github.com/securingsam/krackdetector.

Scott-Hayward, S., O’Callaghan, G., and Sezer, S. (2013).

SDN security: A survey. In IEEE SDN4FNS, pages

1–7.

Shin, S., Xu, L., Hong, S., and Gu, G. (2016). Enhancing

network security through software deﬁned networking

(SDN). In IEEE ICCCN, pages 1–9.

Terkawi, A. and Innab, N. (2018). Major impacts of key

reinstallation attack on Internet of things system. In

IEEE NCC, pages 1–6.

Teyou, C. C. T. and Zhang, P. (2018). Solving downgrade

and DoS attack due to the four ways handshake vul-

nerabilities (WIFI). IJEMR, 8(4):1–10.

Tsitroulis, A., Lampoudis, D., and Tsekleves, E. (2014a).

Exposing WPA2 security protocol vulnerabilities.

IJICS, 6(1):93–107.

Tsitroulis, A., Lampoudis, D., and Tsekleves, E.

(2014b). ExposingWPA2 security protocol vulnera-

bilities. IJICS, 6:93–107.

Vanhoef, M. and Piessens, F. (2017). Key reinstallation at-

tacks: Forcing nonce reuse in WPA2. In ACM CCS,

pages 1313–1328.

Securing Sam ([Online]. 2019). KRACK attacks white

paper. Available: https://www.securingsam.com/in

dex.php/2017/08/03/

krackattacks/.

Vanhoef, M. and Piessens, F. (2018). Release the Kraken:

New KRACKs in the 802.11 standard. In ACM CCS,

pages 299–314.

Xie, J., Yu, F. R., Huang, T., Xie, R., Liu, J., and Liu,

Y. (2018). A survey of machine learning techniques

applied to software deﬁned networking (SDN): Re-

search issues and challenges. IEEE Communications

Surveys & Tutorials.

Yan, Q., Yu, F. R., Gong, Q., and Li, J. (2016). Software-

deﬁned networking (SDN) and Distributed Denial of

Service (DDoS) attacks in cloud computing environ-

ments: A survey, some research issues, and chal-

lenges. IEEE Communications Surveys & Tutorials,

18:602–622.

Yang, Q. and Huang, L. (2018). Overview of wireless se-

curity, attack and defense. In Inside Radio: An Attack

and Defense Guide, pages 1–5.

A Software-deﬁned Networking-based Detection and Mitigation Approach against KRACK

251