This content was originally published on the SpecterOps blog. The original can be found here: https://posts.specterops.io/war-never-changes-attacks-against-wpa3s-enhanced-open-part-2-understanding-owe-90fdc29126a1
In early 2019, myself and fellow Denver-based researcher Steve Darracott (@theDarracott) set 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 .
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 https://github.com/s0lst1c3/owe-lab
Next, run the
lab-setup script to initialize the lab:
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
- 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
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.
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
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
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:
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
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
To tear down the virtual environment, use the
rmmod command as shown in the following example:
Alternatively, you can use the
disable-hwsim script included in the lab environment:
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:
- https://posts.specterops.io/modern-wireless-attacks-pt-i-basic-rogue-ap-theory-evil-twin-and-karma-attacks-35a8571550ee (you can just read the post instead of the whole series)
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.
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):
Expanding the bottommost menu in the screenshot above reveals two new menus:
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:
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:
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
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
wlan1interfaces, and bring your
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
Wireshark from your lab directory and tell it to listen on your
hwsim0 interface as shown in the following screenshot:
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
# 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:
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:
Next, expand the “RSN Information” tag as shown in the following screenshot:
Next, expand the “Auth Key Management List > Auth Key Management Suite (AKM) Suite” tags as shown in the following screenshot:
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
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.
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
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.
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:
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_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
# 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:
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 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”.
This part is very important: expanding this vendor specific element reveals the BSSID of the access point, along with its SSID (“owe-hidden”).
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
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:
We can use the following filter to isolate the connection process in
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
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
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).