WEP shared key authentication uses the RC4 symmetric stream cipher to encrypt data. This authentication method requires the same static key pre-configured on the server and client. Both the encryption mechanism and encryption algorithm can bring security risks to the network.

The Wi-Fi Alliance developed Wi-Fi Protected Access (WPA) to overcome the shortcomings of WEP before more secure policies were provided in 802.11i. WPA still uses the RC4 algorithm, but it uses an 802.1X authentication framework and supports Extensible Authentication Protocol-Protected Extensible Authentication Protocol (EAP-PEAP) and EAP-Transport Layer Security (EAP-TLS) authentication, and defines the Temporal Key Integrity Protocol (TKIP) encryption algorithm.

Later, 802.11i defined WPA2. WPA2 uses Counter Mode with CBC-MAC Protocol (CCMP), a more secure encryption algorithm than those used in WPA.

Both WPA and WPA2 support 802.1X authentication and the TKIP/CCMP encryption algorithms, ensuring better compatibility. The difference lies in the protocol packet format.

Link Authentication

Link authentication can be completed in open system authentication or shared key authentication mode. WPA and WPA2 support only open system authentication. For details, see "Link Authentication" in STA Access.

Access Authentication

802.1X authentication can be used to authenticate wireless and wired users, whereas PSK authentication is specific to wireless users.

PSK authentication requires that a STA and an AC be configured with the same PSK. The STA and AC authenticate each other through key negotiation. During key negotiation, the STA and AC use their PSKs to decrypt the message sent from each other. If the messages are successfully decrypted, the STA and AC have the same PSK. If they use the same PSK, PSK authentication is successful; otherwise, PSK authentication fails.

Key Negotiation

802.11i defines two key hierarchies: pairwise key hierarchy and group key hierarchy. The pairwise key hierarchy protects unicast data exchanged between STAs and APs. The group key hierarchy protects broadcast or multicast data exchanged between STAs and APs.

During key negotiation, a STA and an AC use the pairwise master key (PMK) to generate a pairwise transient key (PTK) and a group temporal key (GTK). The PTK is used to encrypt unicast packets, and the GTK is used to encrypt multicast and broadcast packets.

• In 802.1X authentication, a PMK is generated in the process shown in Figure 23-1.

• In PSK authentication, the method to generate a PMK varies according to the form of the PSK, which is configured using a command:
  • If the PSK is a hexadecimal numeral string, it is used as the PMK.
  • If the PSK is a character string, the PMK is calculated using a hash algorithm based on the PSK and service set identifier (SSID).

Key negotiation consists of unicast key negotiation and multicast key negotiation.

• Unicast key negotiation

  Key negotiation is completed through a four-way handshake between a STA and an AC, during which the STA and AC send EAPOL-Key frames to exchange information, as shown in Figure 23-3.

  Figure 23-3 Unicast key negotiation
  

  The unicast key negotiation process consists of the following steps:

  1. The AC sends an EAPOL-Key frame with a random value (ANonce) to the STA.
  2. The STA calculates the PTK using its own MAC addresses and the MAC address of the AC, the PMK, ANonce, and SNonce, and sends an EAPOL-Key frame to the AC. The EAPOL-Key frame carries the SNonce, robust security network (RSN) information element, and message integrity code (MIC) of the EAPOL-Key frame. The AC calculates the PTK using the MAC addresses of its own and the STA, PMK, ANonce, and SNonce, and validates the MIC to determine whether STA's PMK is the same as its own PMK.
  3. The AC sends an EAPOL-Key frame to the STA to request the STA to install the PTK. The EAPOL-Key frame carries the ANonce, RSN information element, MIC, and encrypted GTK.
  4. The STA sends an EAPOL-Key frame to the AC to notify the AC that the PTK has been installed and will be used. The AC installs the PTK after receiving the EAPOL-Key frame.

• Multicast key negotiation

  Multicast key negotiation is completed through a two-way handshake. The two-way handshake begins after the STA and AC generate and install a PTK through a four-way handshake. Figure 23-4 shows the two-way handshake process.

  Figure 23-4 Multicast key negotiation
  

  The multicast key negotiation process consists of the following steps:

  1. The AC calculates the GTK, uses the unicast key to encrypt the GTK, and sends an EAPOL-Key frame to the STA.
  2. After the STA receives the EAPOL-Key frame, it validates the MIC, decrypts the GTK, installs the GTK, and sends an EAPOL-Key ACK frame to the AC. After the AC receives the EAPOL-Key ACK frame, it validates the MIC and installs the GTK.

Data Encryption

WPA and WPA2 support the TKIP and CCMP encryption algorithms.

• TKIP

  Unlike WEP, which uses a static shared key, TKIP uses a dynamic key negotiation and management mechanism. Each user obtains an independent key through dynamic negotiation. User keys are calculated using the PTK generated in key negotiation, the MAC address of the sender, and the packet sequence number.

  TKIP uses MICs to ensure the integrity of frames received on the receiver and validity of data sent by the sender and receiver. This mechanism protects information integrity. A MIC is calculated using the MIC key generated during key negotiation, the destination MAC address, source MAC address, and data frame.

• CCMP

  While WEP and TKIP use a stream cipher algorithm, CCMP uses an Advanced Encryption Standard (AES) block cipher. The block cipher algorithm overcomes defects of the RC4 algorithm and provides a higher level of security.

WPA3-Personal

Compared with WPA2-Personal, WPA3-Personal increases reliability of password-based authentication. WPA3-Personal introduces Simultaneous Authentication of Equals (SAE) that provides higher security. Replacing PSK authentication of WPA2-Personal, SAE can defend against offline dictionary attacks and increase the difficulty in brute force cracking. SAE provides forward secrecy. Even if an attacker knows the password on the network, the attacker cannot decrypt the obtained traffic. This greatly improves the security of networks running WPA3-Personal. WPA3-Personal supports only the AES encryption mode.

SAE adds an SAE handshake before the four-way handshake process of WPA/WPA2-PSK to dynamically negotiate a pairwise master key (PMK). The PMK used in WPA/WPA2-PSK is related only to the SSID and PSK. SAE leverages dynamic random variables to negotiate the PMK. With SAE, the PMK negotiated using SAE each time is different, improving security. Figure 23-5 shows the SAE exchange process.

Figure 23-5 SAE exchange process

The SAE handshake can be initiated by either the STA or AP and involves the following phases:

1. Key exchange phase (SAE Commit)

   In this phase, a four-way handshake PMK is generated. The two authentication entities (AP and STA) both send a password element of an ECC group (PWE) encapsulated by random numbers. The PWE is a key derived from the password and the MAC address of the peer end. Based on the encapsulated PWE, the PMK is generated through calculation. When the SAE Commit phase is complete, both the authentication entities generate PMKs but do not know whether their PMKs are the same.

2. Key verification phase (SAE Confirm)

   The purpose of this phase is to verify that the two entities have the same PMK. A part of the PMK is used to check the integrity of the Commit packet sent in the previous phase. If both entities can pass the check, they have the same PMK and can perform the four-way handshake.

When the SAE exchange is complete, a PMK is generated for the four-way handshake. The four-way handshake process is similar to that in WPA2-PSK authentication.

SAE attack defense

The SAE handshake uses many complex algorithms. If an attacker continuously uses many different MAC addresses to send SAE Commit packets, the SAE handshake is frequently triggered, consuming a large amount of computing resources. As a result, a DoS attack is launched.

To defend against such attacks, WPA3 stipulates that when the number of concurrent SAE interaction packets reaches the threshold, the SAE Commit packets exchanged in a new SAE handshake must carry a token that uniquely identifies a user based on the user MAC address. If no token is carried, the SAE handshake cannot be performed, thereby improving security.

Quick reconnection after an intermittent STA disconnection

WPA3-Personal allows a STA to quickly reconnect to the network after an intermittent disconnection. After the STA reconnects to the network, it uses open system authentication instead of an SAE handshake. The reassociation request packet carries the PMKID, which will be checked by the AP. If the PMKID is the same as that on the AP, the AP uses the previous PMK for a four-way handshake without an SAE handshake. In this way, the connection can be quickly re-established.

Transition mode

WPA2 is still widely used. To enable WPA3-incapable STAs to access a WPA3-configured network, the Wi-Fi Alliance defines the WPA3-Personal transition mode. That is, WPA3 and WPA2 can coexist for a period of time in the future. The transition mode supports only the AES encryption mode but does not support the TKIP encryption mode.

In WPA3 transition mode, the access process for WPA2 STAs is the same as that for STAs using WPA2-PSK authentication, with PMF in optional mode. However, for WPA3 STAs, the access process uses WPA3-SAE authentication, with PMF in mandatory mode.

WPA3-Enterprise

Enterprises, governments, and financial institutions can use WPA3-Enterprise for higher security. WPA3-Enterprise is developed based on WPA2-Enterprise and provides an optional mode WPA3-Enterprise 192-bit. This mode has the following advantages:

• Data protection: The Suite-B 192-bit security suite is used to increase the key length.
• Key protection: The HMAC-SHA-384 algorithm is used to export keys in the four-way handshake phase.
• Traffic protection: The 256-bit Galois/Counter Mode Protocol (GCMP-256) is used to protect wireless traffic after STAs go online.
• PMF: The 256-bit Galois Message Authentication Code (GMAC-256) is used to protect multicast management frames.

Identity Authentication

WAPI provides two identity authentication modes: certificate-based mode (WAPI-CERT) and pre-shared key-based mode (WAPI-PSK).

• WAPI-CERT: A STA and an AC authenticate each other's certificate. The certificates must be loaded on the STA and AC and verified by an authentication service unit (ASU). After certificate authentication is complete, the STA and AC use the temporal public key and private key to generate a base key (BK) for key negotiation.

  The WAPI-CERT mode is applicable to large-scale enterprise networks or carrier networks that can deploy and maintain an expensive certificate system.

  Figure 23-8 shows the WAPI certificate authentication process.

  Figure 23-8 WAPI certificate authentication
  

  The WAPI certificate authentication process is as follows:

  1. Authentication activation

     When a STA requests to associate or re-associate with an AC, the AC checks whether the user is a WAPI user. If the user is a WAPI user, the AC sends an authentication activation packet to trigger the certificate authentication process.

  2. Access authentication request

     The STA sends an access authentication request carrying the STA's certificate and the system time to the AC. The system time is the access authentication request time.

  3. Certificate authentication request

     When the AC receives the access authentication request, it records the access authentication request time and sends a certificate authentication request to the ASU. The certificate authentication request carries the STA's certificate, access authentication request time, the AC's certificate, and a signature generated using the AC's private key and the preceding information.

  4. Certificate authentication response

     When the ASU receives the certificate authentication request, it authenticates the AC's signature and certificate. If the AC's signature and certificate are invalid, the authentication fails. If they are valid, the ASU authenticates the STA's certificate.

     After the authentication is complete, the ASU constructs a certificate authentication response with the STA's certificate authentication result, AC's certificate authentication result, and a signature generated using the authentication results, and sends the certificate authentication response to the AC.

  5. Access authentication response

     When the AC receives the certificate authentication response, it checks the signature to obtain the STA's certificate authentication result, and controls access of the STA based on the certificate authentication result. The AC then forwards the certificate authentication response to the STA. The STA checks the signature generated by the ASU to obtain the AC's certificate authentication result, and determines whether to associate with the AC based on the result.

     If the certificate authentication succeeds, the AC accepts the access request. If the certificate authentication fails, the AC disassociates the STA from the network.

• WAPI-PSK: The STA and AC have the same PSK configured before authentication. The PSK is converted into a BK during authentication.

  The WAPI-PSK mode does not require an expensive certificate system, so it is applicable to individual users or small-scale enterprise networks.

Key Negotiation

After the AC is authenticated by the ASU, the AC initiates key negotiation with the STA. Key negotiation consists of two stages: unicast key negotiation and multicast key negotiation.

• Unicast key negotiation

  The STA and AC obtain a unicast encryption key and unicast integrity key through unicast key negotiation and use these keys to ensure the security of unicast data exchanged between them.

  During unicast key negotiation, the STA and AC use the KD-HMAC-SHA256 algorithm to calculate a unicast session key (USK) based on the BK. In addition to the USK, the STA and AC also negotiate the encryption key and identity key used to generate the multicast key.

  Figure 23-9 shows the unicast key negotiation process.

  Figure 23-9 WAPI unicast key negotiation
  

  The unicast key negotiation process is as follows:

  1. Unicast key negotiation request

     After a BK is generated, the AC sends a unicast key negotiation request packet to the STA.

  2. Unicast key negotiation response

     After the STA receives the unicast key negotiation request packet, it performs the following steps:

     1. Checks whether this negotiation process is triggered to update the unicast key.
        • If so, the STA proceeds to step b.
        • If not, the STA proceeds to step c.

        WAPI allows the STA to directly send a unicast key negotiation response to the AC to initiate a unicast key update.

     2. Checks whether the challenge of the AC is the same as the challenge that is obtained in last unicast key negotiation and saved locally. If the two challenges are different, the STA drops the unicast key negotiation request packet.
     3. Generates a random challenge, and then uses the KD-HMAC-SHA256 algorithm to calculate a USK and the AC's challenge used for the next unicast key negotiation based on the BK, the AC's challenge, and the STA's challenge.
     4. Uses the message authentication key and HMAC-SHA256 algorithm to calculate a message authentication code, and sends it to the AC with a unicast key negotiation response packet.

  3. Unicast key negotiation ACK

     After the AC receives the unicast key negotiation response packet, it performs the following steps:

     1. Checks whether the AC's challenge is correct. If the AC's challenge is incorrect, the AC drops the unicast key negotiation response packet.
     2. Uses the KD-HMAC-SHA256 algorithm to calculate a USK and the AC's challenge used for the next unicast key negotiation based on the BK, AC's challenge, STA's challenge. The AC then calculates the local message authentication code using the message authentication key and HMAC-SHA256 algorithm, and compares the local message authentication code with that in the received unicast key negotiation response packet. If the two message authentication codes are different, the AC drops the unicast key negotiation response packet.
     3. Checks the WAPI information element in the response packet if this is the first unicast key negotiation after the BK is generated. If the network type is BSS, the AC checks whether the WAPI information element in the response packet is the same as that in the association request packet it received before. If they are different, the AC sends a Deauthentication frame to disassociate the STA. If the network type is IBSS (ad-hoc network), the AC checks whether the unicast key algorithm supports the information element in the response packet. If not, the AC sends a Deauthentication frame to disassociate the STA.
     4. Uses the message authentication key and HMAC-SHA256 algorithm to calculate a message authentication code, and sends it to the STA with a unicast key negotiation ACK packet.

• Multicast key negotiation

  Multicast key negotiation is performed after unicast key negotiation is complete. The AC advertises the multicast keys to the STA in this process.

  The AC uses the multicast encryption key and multicast integrity key derived from the multicast master key (MMK) to encrypt broadcast or multicast data it sends, and sends a multicast key advertisement packet to the STA. The STA obtains the multicast encryption key and multicast integrity key from the multicast key advertisement packet to decrypt the broadcast or multicast data it receives.

  Figure 23-10 shows the multicast key negotiation process.

  Figure 23-10 WAPI multicast key negotiation
  

  The multicast key negotiation process is as follows:

  1. Multicast key advertisement

     The AC uses the random number algorithm to calculate an MMK, encrypts the MMK using the negotiated unicast key, and sends an advertisement packet to notify the STA of the MMK.

  2. Multicast key response

     After the STA receives the multicast key advertisement packet, it performs the following steps:

     1. Calculates the checksum using the message authentication key identified by the unicast key identifier, and compares the checksum with the message authentication code. If the checksum is different from the message authentication code, the STA drops the multicast key advertisement packet.
     2. Checks whether the key advertisement identifier is increasing. If not, the STA drops the multicast key advertisement packet.
     3. Decrypts the multicast key to obtain the 16-byte master key and uses the KD-HMAC-SHA256 algorithm to extend it to 32 bytes. The first 16 bytes indicate the encryption key, and the last 16 bytes indicate the integrity key.
     4. Saves the key advertisement identifier and sends a multicast key response packet to the AC.
     5. After the AC receives the multicast key response packet, it performs the following steps:
        1. Calculates the checksum using the message authentication key identified by the unicast key identifier, and compares the checksum with the message authentication code. If the checksum is different from the message authentication code, the AC drops the multicast key response packet.
        2. Compares fields (such as key advertisement identifier) in the multicast key response packet with corresponding fields in the multicast key advertisement packet it has sent. If all the fields are the same, the multicast key negotiation is successful. Otherwise, the AC drops the multicast key response packet.

Key Update

WAPI features a dynamic key negotiation mechanism, but there may still be security risks if a STA uses the same encryption key for a long time. To enhance security, WAPI provides a time-based key update mechanism.

Time-based key update: The unicast and multicast keys of a STA have an aging time (configured using a command). When the aging time of the current unicast or multicast key expires, the STA and AC negotiate a new unicast or multicast key.