This post is about OWE Encryption, in the next post we will learn about the testing of OWE for a replay attack, some negative test scenarios and we will check how the OWE AP behaves for those scenarios.

Opportunistic Wireless Encryption (OWE) Provides the Wireless Encryption for the open Networks. This Method uses Diffie-Hellman Key exchange. It provides only the Encryption not the authentication.

Make sure that you are able to understand the key hierarchy before you go through the post. Follow the below links to understand about the Keys hierarchy.

4-Way Hand Shake WPA2

4-Way Hand Shake WPA3

Before we learn about OWE, we will have to understand the Diffie-Hellman Key exchange.

Diffie-Hellman Key Exchange Using Prime Numbers

Observe the below Figure 1 and understand the basic DH key exchange.

1. Both the parties agree upon P and G [Should be Known Before the exchange]
2. They generate the private keys (Don’t Exchange the private Keys).
3. They Generate the Public Keys by using the private key, P and G. And public keys will be exchanged.
4. Both the Parties generate the same Shared Secret at the end.

Diffie-Hellman Key Exchange Using Elliptic Curve

Now we know how basic Diffie-Hellman key exchange works. Now we will get into the Elliptic-curve Diffie Hellman. The concept in Elliptic curve Diffie-Hellman is similar to the one we saw above. But here use algebraic curves to generate the keys. These keys are nothing but points on the elliptic curve.

These are the steps to generate the shared secret on Elliptic Curve.

1. Both parties should agree upon elliptic curve E. And the Generator G.
   1. As per the standard they have to use DH group 19. They should be agreed upon using the same elliptic curve E and generator G.
      1. E— the elliptic curve.
      2. G — a point on E that is set as the base point [Generator]

Observe the below diagram to understand the derivation of a shared secret by using the Diffie-Hellman algorithm. Because of the properties of the elliptic curve both Alice and Bob will generate the same shared secret.

Below are the steps involved in Opportunistic Wireless Encryption.

1. OWE Discovery
2. OWE Association
3. OWE Post Association
4. 4-way handshake

Before we learn about the OWE , Observe the below diagram to understand the frame exchanges involved in OWE.

Step 1 : OWE Discovery

Access Point Advertise the support for OWE in the beacon and probe response. Observe the below figure to see the beacon of a OWE enabled AP. PMF mandatory in the OWE.

Step 2 : OWE Association Frame Exchange

After the Open System Authentication Request and Response Frames , we have a OWE Association Procedure. As shown in the Figure 1, prime number will be P and G are based on the DH group. Here DH group is DH-19.

Observe the below Sniffer capture for Association Request Frame that is involved in the OWE.

The client adds her public key in the 802.11 association request, and the AP adds his public key in the 802.11 association response. Public key in DH-19 Group will be a X point on the Elliptic Curve Cryptography. Observe the below capture for Association Request frame.

Observe the below frame for the Association response frame from the AP.

Once the Association Frame exchange is done then, both the parties will generate the keys, and Diffie-Hellman key exchange is finished.

Step 3 : OWE Post Association

Once the Association is finished now both the peers will generate the PMK. Once both the peers generate the shared secret , now the PMK will get generated. The below are the steps to generate the PMK.

Steps in Generating PMK

z = F(DH(x, Y))
prk = HKDF-extract(C | A | group, z)
PMK = HKDF-expand(prk, “OWE Key Generation”, n)

x= private key
Y= public key (Client/APs)
z=shared secret derived from DH ECC

HKDF=HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

“C | A | group” = Concatenation of the client’s public key, and the AP’s public key and the two-octet group from the Diffie-Hellman Parameter element (here the group is 19. So, the value is 2 byte group ID (0013). Here the Generated prk will be sent as a salt to the PMK derivation HKD function.

n=Bit length of the digest produced by that hash algorithm. DH-19 will use the SHA-256 algorithm. Here n is the length 32 Bytes.

PRK and Z will get deleted once the PMK is generated.

Observe the below following Supplicant logs that got generated after the Association Phase.

Logs on AP Side

OWE: DH shared secret – hexdump(len=32): f0 a5 e2 27 cf a8 db 0d fe 4f 0a 1e 5f d3 e7 85 de dd 4c c7 45 cd 34 4b 1c 54 8e e8 33 93 4b 30
OWE: prk – hexdump(len=32): 77 33 9e 6d 22 1a 53 2b 05 c3 bd 4f 9b 4e 92 50 5f 81 9d e3 e8 f6 2b c0 ab d0 7a 18 9d 20 75 4c
OWE: PMK – hexdump(len=32): b0 0b 14 69 4d 16 90 c3 0d 62 3d 27 b6 24 94 c8 78 fd 14 08 0a 47 34 6e 83 12 28 db 17 03 bb 47

Observe the below log on client side

Logs on Client Side

OWE: DH shared secret – hexdump(len=32): f0 a5 e2 27 cf a8 db 0d fe 4f 0a 1e 5f d3 e7 85 de dd 4c c7 45 cd 34 4b 1c 54 8e e8 33 93 4b 30
OWE: prk – hexdump(len=32): 77 33 9e 6d 22 1a 53 2b 05 c3 bd 4f 9b 4e 92 50 5f 81 9d e3 e8 f6 2b c0 ab d0 7a 18 9d 20 75 4c
OWE: PMK – hexdump(len=32): b0 0b 14 69 4d 16 90 c3 0d 62 3d 27 b6 24 94 c8 78 fd 14 08 0a 47 34 6e 83 12 28 db 17 03 bb 47

Observe that both the Client and AP has generated the same Shared Secret, PRK, and PMK. Once we get the PMK generated we will get the renaming keys required for data encryption.

Step 4: 4-way Handshake

Once we get the PMK , then we will generate the PTK.

GTK and IGTK will be sent by the AP in the M3 by wrapping them with KEK.

With this we have all the keys required to encrypt the Unicast , Broadcast traffic. Now OWE Association is finished. In the above scenario both client and AP will generate the same PTK.

Observe the below supplicant log from the AP Side

Supplicant Log on AP Side

WPA: PMK – hexdump(len=32): b0 0b 14 69 4d 16 90 c3 0d 62 3d 27 b6 24 94 c8 78 fd 14 08 0a 47 34 6e 83 12 28 db 17 03 bb 47
WPA: PTK – hexdump(len=48): 17 85 46 2a 0a 2b 49 c5 79 62 a5 02 cf a1 66 8b 25 36 4b ef e2 51 48 de 4b 0d 89 ed ae b3 4e d6 b9 73 98 40 7d 2e e1 9b 3c 99 7d 83 61 81 3a e8
WPA: KCK – hexdump(len=16): 17 85 46 2a 0a 2b 49 c5 79 62 a5 02 cf a1 66 8b
WPA: KEK – hexdump(len=16): 25 36 4b ef e2 51 48 de 4b 0d 89 ed ae b3 4e d6
WPA: TK – hexdump(len=16): b9 73 98 40 7d 2e e1 9b 3c 99 7d 83 61 81 3a e8

Observe the below supplicant log on Client Side

Supplicant log Client Side

WPA: PMK – hexdump(len=32): b0 0b 14 69 4d 16 90 c3 0d 62 3d 27 b6 24 94 c8 78 fd 14 08 0a 47 34 6e 83 12 28 db 17 03 bb 47
WPA: PTK – hexdump(len=48): 17 85 46 2a 0a 2b 49 c5 79 62 a5 02 cf a1 66 8b 25 36 4b ef e2 51 48 de 4b 0d 89 ed ae b3 4e d6 b9 73 98 40 7d 2e e1 9b 3c 99 7d 83 61 81 3a e8
WPA: KCK – hexdump(len=16): 17 85 46 2a 0a 2b 49 c5 79 62 a5 02 cf a1 66 8b
WPA: KEK – hexdump(len=16): 25 36 4b ef e2 51 48 de 4b 0d 89 ed ae b3 4e d6
WPA: TK – hexdump(len=16): b9 73 98 40 7d 2e e1 9b 3c 99 7d 83 61 81 3a e8

IGTK will be sent to the Client in the M3 message by encrypting the IGTK in M3 with the KEK.

Check the below post to properly understand the GTK/IGTK wrapping , unwrapping.

GTK/IGTK Unwrapping

Deauthentication/Disassociation

These frames are encrypted and protected as the PMF is enabled by default in the OWE , and the peer verifies the generated 8 Byte MIC in the Broadcast Deauthentication/Disassociation Frame, and it will be encrypted using IGTK.

Observe the below Broadcast Deauthentication Frame. Disassociation frame also looks the same way.

Check the below post to understand the Broadcast Deauthentication frame Verification in detail.

Protected Broadcast Deauthentication/Disassociation

In the case of unicast deauthenticate/Disassociation frame , we have total 10 bytes of data, here 2 bytes is the encrypted data and 8 bytes of generated MIC using CCMP. Unicast Deauthentication frames will be encrypted with the TK.

Observe the below capture for the Unicast Deauthentication Frame. Unicast Disassociation frame also looks the same way.

Check the below post to understand the unicast Deauthentication Frame Verification in detail.

Protected Unicast Deauthentication/Disassociation

This is all about OWE.

In the next post we will have a look about the few testing scenarios that are involved in the OWE and we will check the behaviour of the AP when there is a replay attack on the OWE AP.