Skip to content →

War Never Changes: Attacks Against WPA3’s Enhanced Open — Part 2: Understanding OWE

This content was originally published on the SpecterOps blog. The original can be found here:

In early 2019, myself and fellow Denver-based researcher Steve Darracott (@theDarracottset out to answer the question — “is Opportunistic Wireless Encryption (OWE) susceptible to abuse and attack, and if so, how?”. Ultimately, we succeeded in implementing multiple working proof of concept attacks, which we demonstrated at the DEF CON Wireless Village last summer. This series of blog posts documents our research efforts and conclusions, and discusses how OWE fits into the current wireless threat model.

In Part I of this series, we provided historical context and background information that helps fit this research into the current wireless threat model. If you haven’t read this post yet, you can find it here:


In this second part of the series, we’ll provide an overview of how OWE works. There are already some good write-ups that provide this info at a high level, so this will be more of a hands-on technical deep device.

What is OWE?

Simply put: OWE is a means of adding encryption to open networks, which is something the 802.11 standard has been missing for the past 20 years. OWE is intended to be indistinguishable from open WiFi from a user’s perspective — the user simply connects to the OWE protected network and, after a brief key exchange and handshake, all subsequent communication is encrypted [1].

At first glance, this sounds great — until you find out that OWE only protects against passive attacks. As you may recall from the previous entry in this series, passive attacks haven’t actually worked since the early 2000s. That’s right — the WiFi Alliance’s response to 20 years of absolutely savage abuse of the 802.11 protocol was to introduce a mitigation for something that stopped being an actual threat nearly 20 years ago.

Yeah, it doesn’t make sense to me either, and we’ll talk more about that in Part III of this series. For now let’s make sure we understand how OWE works at a technical level.

OWE follows a five phase process that starts with network discovery and culminates in encrypted data transfer between the client and access point. We’ll go over each of these phases in the sections that follow, along with some prerequisite background information.

The Lab Environment

Should you wish to follow along with the examples in this writeup, I have provided a suite of setup scripts for creating a ready-to-use lab environment.

Disclaimer: Please note that these setup scripts are targeted towards Kali 5.3.7 and I’m not planning on maintaining them or providing support for any other operating system. Software is not static — if you’re reading this in the year 2025 or something like that and the setup script doesn’t work, well… you’re on your own.

To create the lab environment, first use git clone to obtain the scripts from Github:

git clone

Next, run the lab-setup script to initialize the lab:

cd owe-lab

If the lab-setup script complete successfully, you should have an owe-labdirectory that looks like this:

As you can see from the screenshot above, the setup script will create a lab environment with each of the following components:

  • Virtual AP and Base Station
  • Wireshark Dev Branch
  • EAPHammer
  • AP and Station Configuration Files
  • Hardware Simulator Control Scripts

I’ll briefly describe each of these components in the sections that follow.

Virtual AP and Base Station

These are just recent versions of wpa_supplicant and hostapd with dependencies resolved and compiled with support for OWE and Simultaneous Authentication of Equals (SAE).

Wireshark Dev Branch

We’ll be using Wireshark for both analysis and verification that everything within the lab is doing what its supposed to be doing. For OWE and SAE support, we need the latest version of Wireshark, which can only be compiled from source. Fortunately, the script takes care of this, making short work of what is otherwise a pretty idiosyncratic build process.

A senior member of the Wireshark dev team.


Wireless attack suite with OWE support for proof-of-concept attacks (the byproduct of this research).

AP and Station Configuration Files

The lab environment includes a conf-files directory containing a set of wpa_supplicant and hostapd configuration files for open networks, OWE, and OWE Transition mode. At the time of our research, hostapd’s implementation of OWE was still in development. Consequently, none of the configuration parameters necessary to create or connect to an OWE access point were documented. With no publicly available documentation to go by, we ended up resorting to a whitebox code review of hostap‘s unit testing suite (over 100,00 lines of code) to construct this relatively simple set of working configuration files.

Hardware Simulator Control Scripts

The mac80211 wifi stack (kernel subsystem that deals with wifi) ships with a kernel module named mac80211_hwsim that can be used to simulate an arbitrary number of virtual wireless interfaces, and transmit virtual WiFi traffic between them. This writeup uses the mac80211_hwsim almost exclusively. To be clear — you could certainly perform most of the steps outlined in this guide using physical hardware. But given that OWE-compatible hardware isn’t widely available yet, and given that the hardware that’s out there tends to be expensive, using hardware simulators can be a good option for most people. Additionally, from an R&D standpoint, it’s beneficial to work with virtual hardware to avoid introducing uncontrolled variables into the environment.

To enable the mac80211_hwsim kernel module, use modprobe as shown in the example below. The radios variable is used to specify the number of virtual interfaces created.

modprobe mac80211_hwsim radios=3

Alternatively, you can just run the enable-hwsim script included with the lab environment:


Loading the mac80211_hwsim module

Once you’ve enabled mac80211_hwsim, you can view the interfaces you created using the iwconfig command. In Kali (and any other Debian-based distro for that matter), the newly created interfaces will follow the convention wlanX, where X is a non-negative integer. You’ll also notice a newly created interface named hwsim0. This is actually a tap interface that can be used to capture traffic sent between the wlanX interfaces.

To tear down the virtual environment, use the rmmod command as shown in the following example:

rmmod mac80211_hwsim

Alternatively, you can use the disable-hwsim script included in the lab environment:

Removing the mac80211_hwsim module

Background Info

Before we proceed any further, we need to go over some background info. If you’re unfamiliar with how 802.11 works, I recommend skimming through the following blog post, since it includes most of the information you need to understand the rest of this writeup:

In addition to the information in the blog post referenced above, we need briefly cover the following concepts:

  • Type-Length Value (TLV) Encoding
  • Information Elements
  • Robust Security Network (RSN) Elements
  • Authentication Key Management (AKM) suite selectors

Elements and Type-Length-Value (TLV) Encoding

Type-Length-Value (TLV) is an encoding scheme that is used within communication protocols to append information to individual messages (in this case, packets). TLV relies on data structures called elements.

The anatomy of a TLV element

Elements (shown in the diagram above) are variable length byte strings that are divided into three sections. Each of these sections represents one of the following fields, which are listed in order:

  • Type: This fixed length field contains a binary code that indicates the element’s data type
  • Length: This fixed length field contains the size of the element in bytes.
  • Value: This variable-length field contains the element’s data (or payload).

The first two fields in the element (type and length) describe how the third field in the element should be interpreted and processed.

Information Elements (IEs)

Information Elements (IEs) are elements used to add metadata to Management Frames (MFs). Beacon frames, probe requests, probe responses, and association frames are all constructed by appending IEs to one another.

Let’s focus on beacon frames for a minute. As you may recall, beacon frames are periodically broadcast by access points (APs) to advertise their presence and capabilities to nearby stations. IEs are the data structure that makes this possible. To illustrate, let’s open a beacon frame in Wireshark and view how it’s constructed. For this example, I’m using the following sample capture from the Wireshark wiki (feel free to either follow along or just look at the screenshots):

The very first packet in the capture is a beacon frame. Selecting this frame in Wireshark reveals three drop-down menus (depending on Wireshark’s configuration, they may already be expanded):

Wireshark Example

Expanding the bottommost menu in the screenshot above reveals two new menus:

Tagged and Fixed Parameters

We’re interested in the drop-down labeled “Tagged parameters”. Expanding the “Tagged parameters” menu reveals a list of IEs, which known as “tags” in Wireshark:

Information Elements

To see 802.11’s use of TLV encoding in action, click on the “SSID parameter set” IE to expand it as shown in the following screenshot:

Expanding the “SSID parameter set” tag in Wireshark

The first field of the IE (tag number) indicates its data Type, which in this case is an “SSID parameter set”. The next field of the IE is the Length of its Value field, which in this case is 9. The IE’s final field is its Value, which we know is a 9-byte SSID due to the IE’s Type and Length fields.

Most of the beacon frame’s metadata is stored in IEs that follow this Type-Length-Value format. Other management frames are constructed using a similar system.

OWE In a Nutshell

OWE Phase 1: Network Discovery

So why did we just spend so much time talking about Type-Length-Value (TLV) encoding and Information Elements (IEs?). They’re pretty important to understanding how OWE works at the packet level. To see how, let’s examine OWE’s authentication process in Wireshark.

Begin by enabling your simulated WiFi interfaces using the enable-hwsim script provided with the lab environment:


Next, tell Network Manager to relinquish control over your hwsim0wlan0, and wlan1interfaces, and bring your hwsim0wlan0, and wlan1 interfaces online:

nmcli device set wlan0 managed off
nmcli device set wlan1 managed off
nmcli device set hwsim0 managed off
ifconfig wlan0 up
ifconfig wlan1 up
ifconfig hwsim0 up
Using nmcli to set wlan0 and hwsim0 to unmanaged mode

Next, open Wireshark from your lab directory and tell it to listen on your hwsim0 interface as shown in the following screenshot:

Selecting the hwsim0 interface in Wireshark

Next, instantiate an OWE access point using hostapd. We’ll do this by providing hostapd with the following configuration file, which can be found in your lab’s conf-files directory:

# use interface wlan0
interface=wlan0# set ssid to "owe"
ssid=owe# manually set BSSID
bssid=a6:44:ce:d8:61:6f# set channel to 1
channel=1 # require Protected Management Frames (PMF)
ieee80211w=2# enable full IEEE 802.11i/RSN
wpa=2# set key management element to OWE
wpa_key_mgmt=OWE # set RSN pairwise cipher to CCMP

To start the access point, just pass hostapd the relevant configuration file as shown in the following command:

./hostapd conf-files/hostapd-owe.conf
Starting hostapd

Back in your Wireshark window, filter for beacon frames from your access point using the following filter:

wlan.fc.subtype == 0x8 && wlan.bssid == a6:44:ce:d8:61:6f

Once you’ve applied the filter, select one of the packets and expand the “Tagged parameters” menu as shown in the following screenshot:

Expanding the “Tagged parameters” menu in Wireshark

Next, expand the “RSN Information” tag as shown in the following screenshot:

Expanding the “RSN Information” tag in Wireshark

Next, expand the “Auth Key Management List > Auth Key Management Suite (AKM) Suite” tags as shown in the following screenshot:

Examining AKM Suite selectors in Wireshark

Here’s the important part: notice the value of the “Auth Key Management (AKM) type” element. Access points (APs) that support OWE advertise their support for the protocol using an Authentication and Key Management (AKM) Suite Selector that is added to the RSN element of all beacons and probe response frames that the AP issues. Base stations that support OWE recognize the presence of this element and use it to identify nearby access points that support OWE.

Now let’s examine what happens when we connect a base station to the AP. To do this, we’ll use our lab’s wpa_supplicant binary with the following configuration file:

# OWE network
ssid="owe" # connect to SSID "owe"
frequency=2412 # connect to channel 1 (center freq 2412)
key_mgmt=OWE # use OWE
proto=RSN # use RSN
ieee80211w=2 # use Protected Management Frames (PMF)
pairwise=CCMP # set pairwise cipher suite to CCMP

To connect to the OWE access point, pass wpa_supplicant the relevant configuration file as shown in the following command:

./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-owe.conf

The base station will recognize the AP as OWE-compliant, and initiate open-system authentication with it (open-system authentication is a just a fancy way of saying “no authentication actually occurs”). You can see the authentication process taking place in Wireshark using the following filter:

wlan.fc.type_subtype == 0xb
Filtering for authentication frames in Wireshark

OWE Phase 2: Association

Once the client device has performed open-system authentication with the access point (AP), the client and AP transition to the 802.11 association process. It is during association that OWE’s Diffie-Hellman (DH) Key Exchange and 4-way handshake occur.

Remember that OWE is a form of public-key cryptography — both the client and AP need to be able to exchange DH keys with one another in order to communicate securely. As with the network discovery phase, this key exchange is facilitated using Information Elements (IEs) that are appended to association request and response frames. When the base station sends an association request to the access point, a DH Parameter element is appended to the probe request frame. This DH parameter element contains the base station’s public key. The access point then replies with an association response frame, to which its public key is appended within its own DH parameter element.

The OWE Association Process

Let’s examine this process by isolating the association process using the following filter (which filters for association request and response frames):

wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1
Filtering for association requests and responses in Wireshark

If we select the first packet that is displayed (which is an association request), we’ll notice that it contains an extended tag named “OWE Diffie-Hellman Parameter” as shown in the following screenshot.

Notice the OWE DH Parameter tag at the bottom of this screenshot

Expanding the “OWE Diffie-Hellman Paramater” tag reveals the base station’s public key:

Similarly, selecting the corresponding association response frame also reveals the presence of an extended tag named “OWE Diffie-Hellman Paramater” which contains the AP’s public key.

The process of exchanging public keys in this manner is known as a Diffie-Hellman (DH) Key Exchange.

OWE Phase 3: Post-Association

Once the client and AP have completed the association process as well as the DH Key Exchange, the Pairwise Master Key (PMK) is created. The PMK is assigned a unique identifier known as a Pairwise Master Key Identifier (PMKID). The AP then initiates a 4-way handshake with the client in which the PMK is used to create encryption keys.

You can see this handshake take place in Wireshark by isolating EAPOL packets with the following filter:

Note: there are two 4-way handshakes occurring in this screenshot

OWE Phase 4: Data Transfer

At this point the client and AP have established an encrypted connection to one another, which will be used to protect all subsequent data transfer.

Notice that one thingis eerily absent from this entire process: certificates. Take a few moments to think about the implications of this, since it will be relevant to the attacks we describe later on in this series.

OWE Transition Mode

OWE Transition mode was designed to provide open network access to both newer, OWE capable devices, as well as legacy devices that don’t support OWE.

Here’s how it works. Access points configured to use OWE Transition Mode actually serve two Basic Service Sets (BSSs) simultaneously. The first BSS is an open hotspot with a visible ESSID. The second BSS is configured to use OWE, and is given a randomly generated ESSID that differs from the ESSID of the open hotspot. This second OWE is also hidden, which means that it can only be discovered using directed probe requests.

To create an access point that follows this configuration, we use a configuration file similar to the one shown below. Note that this configuration file sets up two BSSs the same wireless interface — one open, and one with OWE support. The owe_transition_ssid and owe_transition_bssid configuration parameters are used to tie the two BSSs together. If this configuration file seems confusing, don’t be afraid to move on. It’ll make more sense after examining what the AP and station are doing in Wireshark.

# general ---interface=wlan0 
ieee80211w=1 # owe_transition ---wpa=2
owe_transition_bssid=fe:e1:de:ce:a5:ed# populate_owe_transition_open_bss ---bss=wlan0_0

Let’s take a look at what this configuration file actually does by using it to create an OWE Transition mode AP, then analyzing it in Wireshark. Begin by start hostapd with configuration file shown in the following command:

./hostapd conf-files/hostapd-owe-transition.conf

Next, filter for beacon frames in Wireshark using the following filter:

wlan.fc.type_subtype == 0x8

You should see a series of beacon frames transmitted by two distinct access points, as shown in the following screenshot.

Notice the two distinct access points beaconing in this screenshot

Notice that approximately half of these beacon frames are coming from a BSS with SSID set to “transition” while the rest come from a BSS whose SSID is hidden. Let’s focus in on the the visible network by filtering for its BSSID:

wlan.ssid == transition

If we select one of the beacon frames and expand its tagged parameters as shown in the next screenshot, we see a vendor specific element of type “OWE Transition Mode”.

Note the “Vendor Specific” tag at the bottom of this screenshot

This part is very important: expanding this vendor specific element reveals the BSSID of the access point, along with its SSID (“owe-hidden”).

The vendor specific “OWE Transition Mode” element contains the BSSID and SSID of the hidden OWE access point

This vendor specific element is one of the keys to how OWE Transition Mode functions — to connect to the transition mode AP, base stations first issue a probe request for the AP’s open ESSID. Base stations that support OWE will check for the presence of the OWE Transition Mode element in the AP’s probe response as well as any subsequent beacon frames transmitted by the AP. If the element is present, the station will then make a probe request for the hidden BSS’s ESSID to initiate a connection with it. Client devices that do not support OWE will ignore the OWE Transition mode element and simply connect to the open BSS.

Let’s examine this process from the station’s perspective. We’ll begin by telling wpa_supplicant to treat our Transition Mode access point as an open ESS by passing it the following config file:

# OWE network

Initialize wpa_supplicant using the following command and observe as it connects to the Transition mode AP:

./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-transition-open.conf

We can also see the station connecting to the AP from the AP’s perspective:

wpa_supplicant connecting to the Transition Mode AP as an open network

We can use the following filter to isolate the connection process in Wireshark (substitute 02:00:00:00:01:00 for the hardware address of your station).

wlan.addr == 02:00:00:00:01:00 && wlan.addr == fe:e1:de:ce:a5:ed && wlan.fc.type == 0x0
Filtering for Probe Response, Authentication, and Association frames in Wireshark

As can be seen in the screenshot shown above, the process is identical to what would happen with an open network.

Now let’s perform the same analysis, this time passing wpa_supplicant a config file that tells it to treat our Transition Mode AP as an OWE ESS:

# OWE network

You can see this process in action (from the client’s perspective) in the following screenshot, which shows debug output generated by wpa_supplicant as it connects to an OWE Transition Mode hotspot.

./wpa_supplicant -i wlan1 -c conf-files/wpa_supplicant-transition-open.conf
wpa_supplicant discovers the hidden OWE AP and connects to it

In the screenshot shown above, wpa_supplicant first attempts to connect to the open hotspot. It then learns that the open hotspot is actually an OWE Transition Mode network, and parses the ESSID of its hidden OWE BSS is from the vendor specific tag. Finally, wpa_supplicant roams to the hidden OWE BSS.


The next and final post in this series will focus on the limitations of OWE — both in terms of its relevance to current threat models and in in terms of specific weaknesses that can be abused by attackers. It will also focus on what OWE gets right — namely the introduction of mandatory Protected Management Frames (PMF).



Published in Wireless


Leave a Reply

Your email address will not be published. Required fields are marked *