SA Query Request/Response Encryption/Decryption/Verification in WPA3/WPA2-PMF (802.11w)

In this post we will learn about SA Query procedure, we will learn about how the SA Query Procedure works and how the frames gets verified the client as well as AP.

Verification of this SA Query procedure will be same for WPA2-PMF or WPA3, if we know the temporal key. without having the private key , it is not possible to decrypt the CCMP traffic.

We have already learnt about the SA Query Procedure in the earlier posts, and we have already learnt when this SA Query request is going to get triggered.

In this post we will learn about how the SA query request and response will get verified and how the encryption/decryption happens, and we will verify the SA query Request/Response in a wireshark with real time example.

Go through the below link to learn about the SA Query Procedure in depth.

Protected Management Frames

Before we go through the SA query procedure , have a look at the below links to know how the encryption keys will get generated , so that it will be easier to understand this post. And you will know the purpose of the different keys.

WPA3-Keys Generation


SA-Query Procedure

The below figure shows the one of the examples to know when this SA Query procedure is going to get triggered.

This image has an empty alt attribute; its file name is pmf-1.jpg
Figure 1 : Attacker Sending a Spoofed Association Request to the AP

Test Scenario to trigger the SA Query Procedure

Below scenario is the one of the examples to trigger SA Query Procedure.

  • AP and STA has a secure PMF Association.
  • Now Assume that Attacker has Spoofed the MAC Address of a Connected Station and sends the Association Request to the AP.
  • Now the AP gets the Association Request from the spoofed MAC Address , it wants to check whether the Association Request has come from the genuine client or from the Attacker. AP wants to check this because sometimes AP will still have the Valid Association even if the real client gets disconnected.
  • Now the AP wants to check whether the real client still exists or it is a Fake Association Request.
  • At this point AP triggers the SAQuery Procedure to know whether the client still exists.
    • Now the AP sends the SAQuery Request to the Client, If the client gives SAQuery Response, it means that the association request has come from the Fake client.
    • If the Client doesn’t give SAQuery response , it means that real client got disconnected.

SA Query Request/Response Frame Format

The below figure is the SA Query Frame Request Frame format. It is a Management Action Frame.

Figure 2 : SA Query Request Frame Format

The below figure the SA Query Response Frame Format.

Figure 2 : SA Query Response Frame Format

Here Transaction identifier is used to identify the SAQuery Session, and it going to be unique for the SAQuery Request/Response frames. This 2 Byte data is going to be the random from the initiator.

If the Initiator sends the SA Query request to the receiver, it has some 2 Byte transaction identifier and the receiver has to respond with the same transaction identifier to the initiator. We can’t see this in wireshark because it is encrypted.

Transaction Identifier is Unique for SA Query Procedure.

SA Query Request/Response Verification

Below capture shows the SAQuery Request and Response frame details. I have captured the required frames in wireshark. This SA Query Request and Response procedure has 12 Bytes of encrypted data.

Figure 3 : SAQuery Request/Response Frame in a Wireshark

Length of Encrypted Data for SA Query = 12 Bytes

SA Query Action : 1 Byte

SA Query Action : 1 Byte

SA Query Transaction ID : 2 Byte

CCMP MIC for Data : 8 Byte

Total = 12 Byte of Encrypted Data

Now we will decrypt the SA Query Request frame. Before we decrpyt the request frame we should be knowing the Temporal Key that got generated at the time of 4-way handshake. Verifying this SA Query procedure will be same for WPA2-PMF and WPA3 if we know the TK.

SA Query Request Decrypt

Before we decrypt the SA Query Frames , we should know the what is the input that we are going to give to the CCMP program to decrypt the data.

Input to the CCMP to decrypt the SA Query Frames.

1) Temporal Key to the CCMP.

2) Packet Number (We can get this from the CCMP Header, we should properly pull the Packet Number from CCMP header)

3) Encrypted Frame. (output will be the plain text)

Now we will open the SA Query Request frame from wireshark and then we will decrypt the SA Query Request. We have to decrypt the data using the CCMP and it is not an easy task to that without private key. And we should properly give the input to the CCMP program to do that, and it is not an easy task to do that, it takes little effort.

Observe the below SAQuery Request Frame and its Encrypted data.

Figure 4 : SA Query Request Frame

Now we will decrypt the SAQuery Request frame and observe the below details after the decryption. Once we decrypt the SA Query Request we will see the below info and we will get the plain text. The below figure shows the decrypted the SA Query Request frame and we can see the SA Query frame details in a clear text.

Figure 5 : Decrypted SA Query Frame

Note that In the above decryption process, we see the plain text data of SAQuery Request.

SA Query Category : 08

SA Query Request : 00

Transaction Identifier : 29 02

Note that Responder should also send SA Query Response with the same Transaction Identifier so that the initiator verifies that it has come from the genuine client and MIC also should be verified.

SA Query Response Decrypt

Now we will decrypt the SA Query Response and then we will verify the transaction identifier that is being sent in the SA Query Response frame.

Observe the below Wireshark capture for SA Query Response frame.

Figure 6 : SA Query Response Frame

Now we will decrypt the SA Query response frame and then we will verify the text that is being sent in the SA Query response frame.

Figure 7 : Decrypted SA Query Response Frame

Now observe that the transaction identifier is same in the SA Query response as well. And the generated MIC also will get verified at the receiver to make sure that it has been sent from the genuine client.

Observe that the Transaction identifier is same in the Response as well, and it should be the same or the SA Query procedure fails.

Note that In the above decryption process, we see the plain text data of SAQuery Response.

SA Query Category : 08

SA Query Response : 01

Transaction Identifier : 29 02 (It should be same as seen in the SA Query Request)


If the Transaction Identifier is not the same as what the sender has sent in the SA Query Request Frame , then the AP ignores the Response frame.

The same Transaction identifier should be maintained for the SAQuery Session.

So, This is how the SA Query Request and Response gets verified. If you want to decrypt the traffic we should have the Temporal Key which is used to encrypt the Unicast data between client and AP. MIC value should also get verified properly based on the data that is being sent. If the MIC fails the AP/Client ignores the frames.