Enhanced Open – Same Same But Encrypted

Introduction

Besides “Wi-Fi Protected Access” version 3 (WPA3) there has also been an update to open networks by the Wi-Fi Alliance in 2018 [1]. The term open networks refers to networks/SSIDs that do not require a credential (e.g. password) for a connection. This convenience is preserved with Enhanced Open.

However, open previously meant that there is no authentication and no encryption, whereby the latter will be changed by Enhanced Open. As data is then encrypted, it is impossible to read any transferred data on such a network by just sniffing the air. It can be compared to HTTPS, where no (user) credentials are required to securely connect to a website. 

Please note: From a Wi-Fi Alliance point of view, Enhanced Open is not part of WPA3 and there is no such thing as WPA3-Open. Enhanced Open is a separate feature in the security program focused solely on open networks.

Now, let’s dig into the details of Enhanced Open to see the benefits and shortfalls.

Changes to Open

Open Connection Establishment

Before the details of Enhanced Open are explained, we should take a look at the current connection establishment of an open network. The following graph shows only three types of frames, which are all unencrypted: Authentication, Association and Data. In contrast to a connection establishment for WPA2 or WPA3, no EAP 4-way-handshake is used as no key is required and ergo no encryption of data frames is possible. So after the “Association Response” frame from the AP to the client, data frames are exchanged without any encryption.

Open Connection Flow Chart

Cryptographic Consistency

Enhanced Open requires the AES CCMP-128 [2] encryption method, with an 128 bit key, and does not allow any old and broken methods like TKIP or even WEP. CCMP-128 is the default encryption method of WPA2 and WPA3, so nothing new or fancy is added for this new encryption method.

Protected Management Frames (PMF)

All Enhanced Open devices need to use PMF, so it is activated implicitly as soon as the user connects to an Enhanced Open SSID. PMF delivers a protection against forging management frames, e.g. an attacker can disassociate any user by claiming to be the Access Point (AP) that the client is currently connected to. Although it has been around for a longer time, even as a requirement for WFA 802.11ac (VHT) certification, the market adoption was rather low. A more detailed look into this topic is given by my previous blog post on Protected Management Frames (802.11w). Enhanced Open uses the “Management Frame Protection Required” mode with SHA-256 [3] for Hashes.

Opportunistic Wireless Encryption

Enhanced Open uses the Opportunistic Wireless Encryption (OWE) methodology that is defined by RFC 8110 [4] written by Dan Harkins and Warren Kumari. The following figure is a Beacon for an OWE SSID. Although this is an open network, an RSN element (!) is present with. It includes OWE as Auth Key Management index 18 and, as already mentioned above, AES CCMP-128 as group and pairwise cipher suite.

Please note, that legacy open networks do not include such an RSN element as no encryption keys are negotiated.

Enhanced Open Beacon

OWE, just like WPA3-Personal, offers a much better method of establishing a secure connection over an unsecure medium – the Diffie-Hellman (DH) key exchange [5] in combination with a Prime Modulus Group or an Elliptic Curve Group. Since the latter is made mandatory for OWE, the following explanations refer to it.

There already exist some predefined curves as Diffie-Hellman groups 19, 20 and 21 (group order r) with given prime numbers p of certain (bit-)lengths. For example DH-19 refers to the 256-bit elliptic curve defined as NIST p-256 [6] with the prime number p = 2^(256) – 2^(224) + 2(192) + 2(96) – 1 = 1,157920892×10⁷⁷ and the elliptic curve equation: y² = x³ – 3x + b, where b is given by a certain 384 bit number.

Enhanced Open Connection Establishment

As encryption requires keys, the main difference to the open connection establishment is the added EAP key handshake to derive a transmission key for data encryption. Furthermore, the Association Frames now include public keys, one from the client and one from the AP. After the EAP key message no. 4, encrypted data frames are exchanged between an AP and a client.

As indicated in the figure above, the Association Request and Response contain additional information – the public key material of client and AP. See the following figures for the details of the Association frames. Before the Association takes place, both sides choose a random number (its private key from now on) and multiply it by the Generator G of the chosen DH-Group to retrieve the public key.

Enhanced Open Association Request

Enhanced Open Association Response

Notice: How do AP and client choose a DH-Group when none of the frames previous to association phase contain any details about that? Well, they don’t agree on or choose a DH-Group , it’s more like trial and error. The client tries one (DH-19 is the default group) in his Association Request and if the AP accepts this, it answers with his public key and the same group number in the Association Response. If the AP requires a different group than the one offered by the client, it has to deny the association with a failure code of 77 / 0x4d (Wireshark: “Authentication is rejected because the offered finite cyclic group is not supported”) and the client has to try again with a different group.

Association Response with an unsupported DH-Group status code

Establishing a Pairwise Master Key in OWE with ECC

The following paragraphs require knowledge about hash functions, scalars, points/vectors and operations on them. Please jump to the next section, called “Security Considerations”, in case you are not interested in this detailed explanation.

After the Association, a Pairwise Master Key (PMK) is created on both sides by using elliptic curve (or optional finite field) cryptography. As DH-Group 19 refers to an elliptic curve, we will continue with elliptic curve cryptography.

The private key Priv is a scalar and the public key Pub, created by Priv multiplied by Generator G, is a point on the given elliptic curve of the DH-Group. At first, the function DH() multiplies the scalar Priv with the elliptic curve point Pub of the other party and retrieves a new point on the curve called new_point. This new_point is then fed into the function F() to retrieve a new_scalar. All public keys, the number of the used DH-Group as octet in little-endian format (e.g. DH-Group 19 is 0x13), and the new_scalar are handed to the HMAC-based Key Derivation Extract Function (HKDF-extract) to create a pseudorandom key prk. The Pairwise Master Key is finally calculated via HMAC-based Key Derivation Expansion Function (HKDF-expand) based on the prk, the string “OWE Key Generation” and the desired bit length n of PMK (as defined by the Hash algorithm to be used according to the chosen DH-Group: 256 (19), 384 (20) or 512 (21) bits).

STA:
new_point(STA) = DH(Priv(STA), Pub(AP))
AP:
new_point(AP) = DH(Priv(AP), Pub(STA))
Result:
DH(Priv(STA), Pub(AP)) = DH(Priv(AP), Pub(STA))
=> new_point(STA) = new_point(AP)
=> Call it just "new_point"

new_scalar = F(new_point)
prk = HKDF-extract(Pub(STA) | Pub(AP) | <DH-Group as octet>, new_scalar)
PMK = HKDF-expand(prk, "OWE Key Generation", n)

Notice: The HMAC-based Key Derivation Functions are defined in RFC 5869 [7] and not further discussed in this post.

Furthermore, a PMKID is created by hashing the public keys and extracting the leftmost 128 bit of the result. The hash function to be used depends on the size of the prime defining curve p.

PMKID = Truncate-128(Hash(Pub(STA) | Pub(AP))

with Hash() using:
SHA-256: when len(p) <= 256 (DH-19)
SHA-384: when 256 < len(p) <= 384 (DH-20)
SHA-512: when 384 < len(p) (DH-21)

Due to an existing PMKID, a client is able to reassociate to an AP by using the same PMK as before and therefore only require new transmission keys. This saves some time/load on both sides of the connection and is called PMK Caching.

Security Considerations

First of all, it is rather nontransparent to the end user to know if an open SSID provides OWE or not. The Wi-Fi icon on the client device will not show a lock-symbol besides the SSID name like it does for a network that uses WPA2 or WPA3. Let’s hope that such information will be provided in further/advanced details for an SSID on every OS.

In the past, some small venues like coffee shop, bars or restaurants used a WPA2-Personal SSID with a passphrase displayed somewhere in/at the venue. They think that they introduced some sort of security instead of using an open SSID without encryption. However, this is deceptive as a publicly displayed passphrase (“Public-PSK”) enables attackers to decrypt recorded, encrypted frames quite easily. Enhanced Open should be used for that use case as it offers encryption without any credentials that need to be maintained and, more importantly, attackers can not decrypt recorded frames without breaking the Diffie-Hellman key exchange first.

For both, Enhanced Open and the described “Public-PSK” scenario, there is the possibility of an active attack. Just like HTTPS, it is also up to the user to know if the browser/client connected to the right server/AP as no authentication takes place before the secure connection is established and the server/AP side can decrypt/read all the entered user data. This means that the user has to believe that the device connected to the right AP and not an “evil twin”-AP or man in the middle (MITM) AP. Such an “evil-AP” would be able to decrypt/read/modify the exchanged data between the client and the AP.

If end-to-end security of traffic is still important (it should be!), a VPN-connection is still required on an Enhanced Open network.

Transition Mode

As the amount of clients supporting Enhanced Open will grow over time while “legacy” clients will (always?) exist and most likely outnumber the EO-clients for the next decade or even longer, a solution was designed to satisfy both types of clients. A transition mode exists that allows to configure an open SSID with an Enhanced Open “Buddy”-SSID. In contrast to WPA3-Personal, where a single SSID is used and two AKMs are part of the RSN element, the EO-Buddy-SSID requires another BSS*. This means that for each open SSID with EO-Transition Mode enabled, a “BSS1” with no RSN element (open) and a second “BSS2” with a hidden SSID and a RSN element are spawned on the same radio. Unfortunately, this increases the channel utilization as a second beacon is required, which takes up more air-time. Take a look at the following picture, that shows the two Beacons of the same open network.

“Legacy” Open Beacon in OWE Transition Mode

As shown above, the Beacon (and the Probe Response) of the open SSID, e.g. “LANCOM-OPEN”, contains new information. A vendor specific information element with the title “Wi-Fi Alliance: OWE Transition Mode” is added to it, that tells a client about the EO-Buddy-SSID called “LANCOM-OPEN-OWE” and its BSSID. An Enhanced Open capable client will use this information from the Beacon and start a (unicast) Probe Request directed to this EO-BSSID to connect to the encrypted open network automatically. A legacy client will ignore this extra information and connect to the open network just like before.

Notice: Each vendor might use a different routine to name the corresponding OWE SSID, LANCOM adds “-OWE” to the original SSID name.

Enhanced Open Transitional Mode Beacon

On the other hand, the Beacon of the BSS2 also includes this additional vendor specific information element, telling clients about the “legacy” open SSID and its BSSID.

*Background: Since the EO-SSID requires an RSN element to be part of Beacons and Probe Responses, it is inconsistent to the Beacons and Probe Responses of an open SSID, which do not include the RSN element. The RSN element typically defines the security methodology to be used for the connection, something that is not required for an “legacy” open SSID. It is expected to cause troubles if legacy clients see an RSN element for an open SSID.

KRACK-Attacks

Maybe you heard of the so called KRACK-attacks by Mathy Vanhoef [8] that breaks WPA2 without obtaining the real key (Passphrase). As Enhanced Open uses the same EAPoL 4-Way Handshake like WPA2 (and WPA3) to exchange transmission keys, it could be attacked by KRACK as well. However, if you want to get a nice WFA Enhanced Open sticker on your device, WFA makes sure that your device is “KRACK-save”.

Conclusion

The vision by the Wi-Fi Alliance for Enhanced Open is to get rid of cleartext over the air and at the same time preserving the user experience of an open SSID. Enhanced Open offers a solid method to establish a secured connection that offers enhancements to the “legacy” open networks and the “Public-PSK” scenario.

With the introduction of the transition mode, network operators can easily offer this new security standard right away, without the fear of loosing any legacy clients on their hotspot. On the other hand, it is hard to figure out, if an open network offers Enhanced Open capabilities without using a tool like Wi-Fi Explorer or inSSIDer as the Wi-Fi symbol will not show a lock symbol right next to the SSID in the scanned SSID list. Furthermore, a slight increase of air time is introduced do to the need of a second BSSID for the Enhanced Open SSID.

Network operators should keep an eye on “evil APs” to prevent active attacks on users and end users should still use VPN connections if end-to-end security is desired.

Links

[1] WFA Press Release

[2] CCMP (Wikipedia article)

[3] SHA-256 (Wikipedia article)

[4] IETF RFC 8110

[5] Diffie-Hellman Key Exchange (Wikipedia article)

[6] Elliptic Curve P-256

[7] IETF RFC 5869

[8] KRACK Attacks