Shulou(Shulou.com)06/01 Report--

Recently, the WPA2 was cracked (that is, the KRACK loophole * *), there was a lot of uproar on the Internet, because the impact of this loophole was so great that everyone was worried for a moment, so there were people who changed passwords, upgraded the system, patched, wrote strategies, and so on, of which experts were the most active. For a while, the media and forums saw many insights and technical analysis articles about KRACK vulnerabilities * *. If you take a casual look at Baidu, you can find many masterpieces. For example: http://www.cnbeta.com/articles/tech/661599.htm, I don't know how the KRACK loophole that caused such a great impact was said to be "actually very weak" in this article. Another example: http://net.zol.com.cn/660/6603551.html, this article is clear-cut that "the world's Wi-Fi is no longer safe", this understanding is correct, but why the article is not in-depth analysis, more is quoting the content of the paper of the person who exposed KRACK vulnerabilities, so it can not be counted as a technical analysis article, it is just a press release. There are people who want to make a fortune by advertising KRACK loopholes, this is understandable, but people with a little knowledge of network technology all know that KRACK vulnerabilities are loopholes in Wi-Fi security technology agreements, which are underlying technical agreements, while so-and-so Wi-Fi butler is just a defense software for upper applications, anti-virus may be OK, how can the problem of underlying technical protocols be solved? It's a bit unorthodox to mislead by this advertisement. It should be noted that the theory of stop-gap measures in traditional Chinese medicine is absolutely impossible in network technology! If it can be solved, the problem of × × has also been solved a long time ago, and there are many such articles. I will not enumerate them one by one. You can read Baidu on your own.

As a veteran who has been immersed in the wireless network industry and has been engaged in wireless network security technology research for 16 years, I did not want to say anything about it. After all, I have been out of the industry for almost two years, and I am only half an industry insider. However, after seeing a wide range of articles by experts, to tell you the truth, it is a bit unbearable, ah, without in-depth technical analysis, transporting others seems professional and lively, but it does not help to understand the problem correctly. naturally, you can't solve the problem itself. So I, an old expert, can only take some time to write this article through the process of reproducing KRACK vulnerabilities and combining with some past research. I hope that through these technical theoretical and practical data, I can deeply analyze the root causes of WPA2 security vulnerabilities and Wi-Fi security problems. After reading my brick, it will take some time. .

All right, let's get down to business.

On October 17, 2017, foreign social media Twitter revealed a loophole pronouncing the death of the wireless network WPA2 security protocol, which made IEEE a bit embarrassed, because IEEE had been trying to claim and prove that WAP2 was safe. Mathy Vanhoef (Marty Vanhofer), a security researcher from relevant institutions in Belgium, found that there is a "key reinstallation * *" (Key Reinstallation Attack,KRACK) loophole in WPA2 authentication and key agreement protocol, and detailed the new * * through a special website https://www.krackattacks.com. For more information, please see the paper Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 (https://papers.). Mathyvanhoef.com/ccs2017.pdf).

According to the research results of Mathy Vanhoef, almost all devices that support Wi-Fi (such as devices running Android, Linux, iOS, MAC OS, OS X, Windows, OpenBSD and other operating systems) are affected by this vulnerability, and the transmitted data is at risk of being sniffed and tampered with. * * users can obtain data and information in the Wi-Fi network, such as credit cards, e-mails, account numbers, photos, etc., which does great harm.

It is important to note that this is not an engineering implementation problem, because Microsoft, Apple, Google, Linux open source community, and so on, these companies and developers can not make the same mistake at the same time! This is the problem of Wi-Fi technical standards, so the vulnerability discoverer Mathy Vanhoef joked that "all products implemented in accordance with Wi-Fi technical standards are not immune, while some products do not comply with Wi-Fi standards, but are lucky to dodge a bullet." .

In fact, since the first Wi-Fi security technology in 1997, a variety of security loopholes have emerged one after another, from the initial WEP to the later WPA, and then to WPA2, which was once claimed to be secure by IEEE, security vulnerabilities have been exposed again and again, and this KRACK vulnerability is only one of these security vulnerabilities, and it will never be the last one. It can be seen that the security problems of Wi-Fi are serious. Therefore, Belgian experts made it clear that "Wi-Fi security (WPA2) is dead."

Let's first take a look at the development and evolution of Wi-Fi security technology (excerpt from a technical analysis article written when I was working on wireless network security technology):

WEP security protocol was proposed in 1997, which is the security protocol originally used by the wireless LAN standard. Its security architecture is that the base station carries out one-way authentication to users, and adopts open system authentication and shared key authentication algorithm, which is simple and easy to forge. Its encryption mechanism is 64-bit RC4 stream encryption algorithm, static key, low security strength. It was completely cracked in 2001.

WPA security protocol was proposed in 2002 to alleviate the security pressure from industry and users. The software upgrade scheme for WEP protocol can be implemented by upgrading the original WEP equipment software, but there are still a large number of security loopholes, mainly: security architecture loopholes (lack of independent identity of base stations, base stations and background transmission of master keys bring security risks and lead to poor scalability. Compatibility with the cracked WEP mechanism leads to vulnerabilities in the whole system, etc.) The design of security protocol is insecure and lack of robustness (incomplete protocol design, low level of hash algorithm, denial of service caused by invalid frame retransmission, etc.).

WPA2 security protocol was proposed in 2004, using AES-128 block cipher algorithm. However, the identity authentication protocol used by WPA2 is the same as WPA, and there are still loopholes in security architecture and security protocol design, which are vulnerable to vulnerabilities.

(the author's note: the old man's prophecy came true, and WPA2 suffered from KRACK vulnerabilities. ^ _ ^)

In order to analyze why Wi-Fi security can not stand the test, we must start with its security architecture.

Figure 1 schematic of Wi-Fi security architecture

As shown in figure 1, the initial WEP security is negligible and its architecture has no security at all. After being easily cracked, Wi-Fi adopted the so-called more secure IEEE 802.1x architecture, but still could not escape the fate of being cracked. Why?

As we all know, IEEE 802.1x was originally a security architecture on wired networks, but Wi-Fi completely copied it to wireless Lans. However, the wired network with physical contact is different from the wireless network without physical contact, which only depends on electromagnetic propagation. It is problematic to apply the security architecture of wired network to wireless network directly. IEEE is obviously aware of this, but unfortunately, instead of looking for an architectural solution, they overlay a four-step handshake protocol on top of this unreasonable architecture, hoping to make up for its architectural flaws to some extent. Little do you realize that the infrastructure is not reliable, and the higher you build the house, the more likely it is to go wrong. The result of this wrong way of thinking of IEEE is that over the years, all kinds of security problems in Wi-Fi have emerged one after another, often in patches made to solve the previous security problem, but new security problems have been introduced. Take this KRACK*** as an example, the problem lies in the superimposed four-step handshake protocol.

Figure 2 four-step handshake protocol for Wi-Fi

As shown in figure 2, KRACK*** mainly occurs in the four-step handshake process in the authentication and key establishment phase. Through simple message simulation, one side of the security protocol interaction is induced to resend a message in the key exchange protocol. After receiving the retransmitted message, the other party installs the installed key again, and resets IV and other related information during installation. As a result, the same key uses the same IV to encrypt the data again, resulting in security hazards such as data replay, decryption and even forgery. This * applies not only to WPA2 but also to WPA, and both Wi-Fi networks with pre-shared key mechanism and IEEE 802.1x mechanism are affected by this vulnerability.

By the way, the essential reason for Wi-Fi 's insecurity is a flaw in the design of its security architecture, ignoring this essential problem, and trying to plug this loophole by adding a message exchange protocol will only end up plugging more and more vulnerabilities, as in this KRACK. We can also expect that this will happen to WPA3 in the future! Because there is no change in its security architecture, it just replaces the four-step handshake protocol affected by KRACK in WPA2. How is this approach different from "waiting for death" to cure the symptoms but not the root causes?

Let's unveil the mystery of key reinstallation (KRACK) and take a look at it:

Key reinstallation does different harm to different data confidentiality protocols. Replay and decryption can be implemented against AES-CCMP,***, which makes it possible to hijack TCP streams and inject malicious data; the impact on WPA-TKIP and GCMP,*** is even more catastrophic, not only replaying, decrypting, but also forgery. The hazards are shown in Table 1:

Replay *

Decrypt *

Forge *

Four-step handshake

TKIP

AP- > Client

Client- > AP

Client- > AP

CCMP

AP- > Client

Client- > AP

GCMP

AP- > Client

Client- > AP

Client- > AP

Multicast key handshake

TKIP

AP- > Client

CCMP

AP- > Client

GCMP

AP- > Client

Fast switching

TKIP

Client- > AP

AP- > Client

AP- > Client

CCMP

Client- > AP

AP- > Client

GCMP

Client- > AP

AP- > Client

AP- > Client

Inter-station key handshake

TKIP

Initiator Client- > peer Client

Peer Client- > initiator Client

Peer Client- > initiator Client

CCMP

Initiator Client- > peer Client

Peer Client- > peer Client

GCMP

Initiator Client- > peer Client

Peer Client- > initiator Client

Peer Client- > initiator Client

KRACK vulnerability is based on the theoretical basis of cryptography, that is, block encryption algorithms using the same encryption key can not use the same IV for session encryption. If IV is reused, there must be security vulnerabilities. Due to space constraints, I will not repeat it here.

At present, the public vulnerability and disclosure (Common Vulnerabilities & Exposures,CVE) website has reserved a vulnerability number for KRACK, including the ten listed below, all based on the above principles.

L CVE-2017-13077: reassemble as a pair of encryption keys (PTK) in a four-way handshake

L CVE-2017-13078: reinstall the group key (GTK) in a four-way handshake

L CVE-2017-13079: reinstall the full group key (IGTK) in a four-way handshake

L CVE-2017-13080: reinstall the group key in the group key grip (GTK)

L CVE-2017-13081: reinstall the full group key (IGTK) in the group key grip

L CVE-2017-13082: accept a retransmitted fast BSS handoff (FT) reassociation request and process it as a pair of encryption keys (PTK-TK)

L CVE-2017-13084: reinstall the STK key in the PeerKey handshake

L CVE-2017-13086: reinstall TDLS PeerKey (TPK) in the TDLS (Tunneled Direct-Link Setup, channel direct link establishment) handshake

L CVE-2017-13087: reinstall group key (GTK) when handling wireless network management (WNM) hibernation mode response frame

L CVE-2017-13088: reinstall full group key (IGTK) when handling wireless network management (WNM) hibernation response Fram

KRACK*** involves not only the four-step handshake (4-way Handshake) of Wi-Fi security protocol, but also other protocol components, including group key handshake (GroupKey Handshake), inter-site key handshake (PeerKey Handshake), fast handoff handshake (Fast BSS Transition (FT) Handshake) and almost all security protocol processes, as shown in the red circle in figure 3, resulting in pairwise transmission of keys (Pairwise Transient Key,PTK) and group temporary keys (Group Temporal Key). GTK), intersite key STK, Multicast Management and Protection key (Integrity GTK,IGTK), etc. will be reinstalled. TK in the figure refers to PTK, GTK, and IGTK.

Figure 3 schematic diagram of the execution of the security protocol module of IEEE 802.11

It can be seen from figure 3 that although the inter-station key handshake protocol is composed of two subprotocols, the PMK,SMK used by SMK handshake to negotiate four-step handshake is not directly used to protect communication data, so it will not be affected by KRACK***, so the KRACK to inter-site key protocol is only concentrated on its second stage, that is, the four-step handshake protocol after SMK handshake. Because the second phase of the four-step handshake protocol is used to negotiate and load the key STK of the data confidentiality protocol The fast switching handshake is accomplished by embedding the four-way handshake protocol in the physical association framework; the KRACK handshake method for group keys is not essentially different from the four-step handshake protocol.

The four-step handshake protocol is the most important and basic component of the Wi-Fi security mechanism. It not only completes the authentication between the client and the AP, ensures that both parties have a consistent pairwise master key PMK (from the result of PSK or IEEE 802.1x authentication), but also completes the negotiation and distribution of session keys, including PTK for protecting unicast service data, GTK for protecting broadcast / multicast service data, and IGTK for protecting multicast management frames.

Fig. 4 schematic diagram of four-step handshake protocol

In figure 4, a brief description of the four-step handshake protocol related to the session key is as follows:

(1) Client exports PTK after receiving Msg1

(2) AP exports PTK after receiving Msg2

(3) the client installs PTK/GTK/IGTK after receiving Msg3

(4) AP installs PTK after receiving Msg4

(5) after installation, the client and AP use the PTK/GTK/IGTK for encryption, decryption or integrity protection, respectively.

For the reception and retransmission of Msg3 in the IEEE 802.11 standard, see its 12.7.6.4 and Fig.13-17 corresponding descriptions. For ease of reading, screenshots of the relevant parts of the standard are shown in figures 5 and 6.

Figure 5 receiving and processing of Msg3 by client

Figure 6 reception and processing of Msg3 message retransmission in the client state machine

All four messages carry the Key Replay Counter field, which is used as a message counter to match messages between the sender and the sender. The standard defines that this field is strictly used incrementally. The values of Key Replay Counter used in Msg1 and Msg2 in the correct process are rsidentMsg3 and rssg3 are used in Msg4, and rushi1 is used. The definition of Key Replay Counter indicates that each time AP is used by 1, the client takes the value of Key Replay Counter in the valid interaction message received as its own Key Replay Counter. At the same time, the standard also defines that for each Msg3 received by the client, if the value of the Key Replay Counter field has been used (less than or equal to the current Key Replay Counter), it will quietly discard the message (that is, no processing will be done). Therefore, if the normal Msg4 is lost, as indicated in the red font in figure 7, then the AP needs to resend the Msg3. At this time, in order to ensure that the client receives and processes the retransmitted message, according to the expression in figure 5 and figure 6, we can know that the AP must be used after adding 1 to the Key Replay Counter, that is, the AP will resend the Msg3 and reassemble the packet, in which the Key Replay Counter uses rns2. Therefore, the client will fully follow the message processing process of receiving a new Msg3. According to figure 5, the client installs the key every time it receives the Msg3, and the key parameters used to reset the encryption include IV, etc., so the client receives the retransmitted Msg3 and reinstalls the installed key (the key is still the same key, IV-related information is also reset again), as shown in figure 7.

Fig. 7 schematic diagram of retransmission of Msg3 when Msg4 is lost

It can be seen that KRACK*** occurs spontaneously when Msg4 is lost due to background noise, that is, Client that accepts plaintext retransmission of Msg3 may reuse IV in the absence of a * user. At this point, * * users can use some means to force the AP not to receive the Msg4 and resend the Msg3, thus causing the KRACK***.

After the client opens the 802.1x port after issuing Msg4, some clients only receive a four-step handshake message in ciphertext, and some are allowed to receive a four-step handshake message in plaintext. The process is described in two cases below:

1. * method of retransmitting Msg3 in plaintext

Fig. 8 schematic diagram of plaintext retransmission Msg3

If the client, that is, the victim, still accepts to retransmit the Msg3 in clear text after loading the session key, the key reinstallation is simple, as shown in figure 8. First of all, * people will use a band-based middleman, so they can control the handshake package. In stage 1, the * prevents the AP from receiving Msg4;. In stage 2, the victim loads the PTK and GTK/IGTK keys after sending the Msg4, and opens the IEEE 802.1x port to begin normal data transmission. In phase 3, the AP can forward the retransmission Msg3 to the victim because it did not receive the Msg4, causing it to reload the PTK and GTK/IGTK, and reset the IV and retransmission counters used by the data confidentiality protocol. In this case, when the victim transmits its next data frame, the data confidentiality protocol will use the old IV, as shown in stage 5. This means that the user can wait any time before forwarding the retransmitted Msg3 to the victim to control a certain number of IV that will be reused.

The goal of phase 4 is to complete the handshake for the AP part. Because the victim has loaded the PTK, which means that its next Msg4 is encrypted, it usually rejects the encrypted Msg4 before the PTK is loaded. Therefore, the IEEE 802.11 standard defines that the AP needs to accept a four-way handshake with an arbitrary retransmission counter (see its description of 12.7.6.5, for ease of reading, see figure 9 for screenshots of the relevant parts of the standard), not just the last one. That is, when receiving Msg4, AP verifies whether the Key Replay Counter field value has been used during the current four-way handshake, that is, AP accepts retransmission counters that have been sent to Client messages before and have not been sent back by Client. At this point, AP will accept the old unencrypted Msg4, which is the message with the retransmission counter riter1. In short, AP loads PTK, etc., opens the 802.1x port, and starts sending encrypted data frames to Client.

Figure 9 receiving and processing of Msg4 messages by AP

Although figure 9 only illustrates the reuse of Client sending IV, KRACK*** allows playback of data frames. After Client reinstalls GTK in phase 3, data retransmitted by AP via broadcast or multicast can be replayed. This is because the retransmission counter is also reset when the key is reinstalled. Especially in the case of key update, that is, four-step handshake update, it is easier to replay whether unicast or multicast.

Another * * for plaintext Msg3 retransmission is shown in figure 10, in which authentication and key agreement in Client are completed by the main CPU software, and data encryption is done by the hardware, that is, the network card NIC. In phase 1, first let Client and AP exchange Msg1 and Msg2, then block the first Msg3 so that it is not immediately forwarded to Client, but wait for AP to retransmit the second Msg3; phase 2, * send two Msg3 in succession to Client, and the wireless network card implementing the data confidentiality protocol has not yet loaded PTK, so the received two plaintext packets are forwarded to the main CPU in sequence. In phase 3, the CPU that implements the four-way handshake protocol receives the first Msg3 and has the wireless network card load the PTK In stage 4, the CPU will normally process the second Msg3 from the received sequence and send out the Msg4 in response, because the network card has already loaded the PTK, so the Msg4 will be encrypted when the IV is x (a certain value, other data may have been sent). After that, CPU asks the wireless network card to load the PTK again, and the wireless network card will also reset the IV and retransmission counters related to the PTK. This means that the next data frame will reuse IV from 1 to x.

Fig. 10 second schematic diagram of plaintext retransmission Msg3

2. * method of encrypting and retransmitting Msg3

Fig. 11 schematic diagram of ciphertext retransmission Msg3

In stage 1, the person asked the victim to make an initial four-way handshake with AP, and after the handshake was successful, initialized the reinstallation of the PTK; in stage 2, the person did not immediately forward the first Msg3, but waited for the AP to retransmit the Msg3, and then sent the two Msg3 to the victim in sequence. The network card will use the current PTK to decrypt the two messages and then forward them to the receiving sequence of the CPU. In phase 3, CPU will process the first Msg3 and load the new PTK;. In phase 4, CPU will pull the second Msg3 from the receiving sequence. When the PTK is loaded, the Msg4 will be encrypted and sent with the new PTK and IV as 1. After that, CPU will have the Nic reinstall the PTK and reset the IV and retransmission counters. Finally, the next data frame sent by the victim will be encrypted with the new PTK and IV as 1.

In particular, KRACK also found a more frightening loophole for the four-way handshake, that is, when the four-step handshake Msg3 retransmission causes the PTK/GTK/IGTK to reinstall, the client will reinstall an all-zero encryption key. Mathy Vanhoef believes that the vulnerability is caused by the Wi-Fi security technology standard, which recommends that TK (PTK/GTK/IGTK) be purged from memory after it is installed. KRACK leads to the installation of all-zero key, which means that the security of data communication has been lost, and the security mechanism of WAP/WPA2 will exist in vain.

In the demo released by Mathy Vanhoef, there is a video showing how to conduct a complete * * process, the core of which is to "reinstall the now-cleared encryption key and effectively install an all-zero key." .

Now, from the perspective of engineering implementation, let's take a closer look at whether products implemented in accordance with the Wi-Fi standard have such behavior:

First of all, we conduct a code-side analysis to clarify its logic and key reinstallation process. For this reason, I specially downloaded the wpa.c file in the Linux system to read in detail, and found the key code implementation process.

Figure 12 Code snippet of Wi-Fi security protocol implementation (1)

Figure 12 shows the code snippet that calls the wpa_supplicant_install_ptk function in the wpa_supplicant_process_3_of_4 function. STA receives and processes the third frame, and after calling the wpa_supplicant_send_4_of_4 function to send the fourth frame, it calls the wpa_supplicant_install_ptk function to install PTK.

Figure 13 Code snippet for the implementation of Wi-Fi security protocol (2)

Figure 13 is a code snippet of the wpa_supplicant_install_ptk function. In the wpa_supplicant_install_ptk function, when PTK is installed, call the following code to clear the buffer of PTK.

/ * TK is not needed anymore in supplicant * /

Os_memset (sm- > ptk.tk, 0, WPA_TK_MAX_LEN)

From the code side, there is indeed a problem, but for the sake of rigor, it is necessary to conduct a more in-depth analysis and get the evidence that echoes it.

In order to verify this situation, the author built a set of WIFI access point environment. A wireless router and a mobile phone with Android 6.0 + kernel as the client. When the two perform normal access actions and grab packets during this process, they do see the message of a four-step handshake, as shown in figure 14:

Fig. 14 Wi-Fi four-step handshake protocol process to grab packets

Figure 14 is an EAPOL type of data opened using wireshark, that is, a four-way handshake packet. The author deliberately makes AP continue to retransmit the third packet, so I will see a lot of EAPOL messages. Through the packet grab analysis, we do see the four-step handshake process, but the packet analysis can not prove whether the full zero key has been installed.

In order to capture the installation process of the all-zero key, the author decided to use memory analysis to analyze this Android phone client in order to get real and accurate key information.

Connect the mobile phone to the computer for debugging. The changing process of the key can be observed by means of memory analysis. The analysis environment is as follows:

Figure 15 memory analysis environment

We still carried out the above steps to retransmit the third package repeatedly. After testing and debugging the memory information, we finally found the most direct evidence of all-zero key installation:

Figure 16 memory analysis data

As shown in the above two pictures, we can see. When the client receives the third packet for the first time, it does install a random key, but after receiving the retransmission instruction, the system will clear the key memory, and then go to the zero-cleared area to install. It is completely consistent with the results of our initial analysis!

At this point, we have finished the analysis of Wi-Fi security issues and KRACK vulnerabilities.

Postscript:

Originally, I wanted to meet this deadline, but the author could not help but talk about another WLAN security technology (yes, the WAPI technology proposed by China). After all, in those 16 years, I studied not only Wi-Fi security technology, but also a lot of research on WAPI security technology. To tell you the truth, technically, WAPI is indeed much safer than Wi-Fi, but it is a pity that the vital resources in the industry (such as chips, drivers, operating systems, etc.) are not in the hands of the Chinese, so that we do not have such a good technology as WAPI, but it is hard for us to be squeezed out by others' monopoly advantage of industrial resources. it is funny that some people are still talking sarcastically, thinking that the moon abroad must be fuller than that at home! I wonder if these people still feel that the moon is full abroad after all kinds of security problems in Wi-Fi over the years.

Well, I will not sigh, directly say that after careful analysis of the conclusion: KRACK*** is invalid to WAPI!

Why would you say that? Let's take a look at the architecture of WAPI security technology, as shown in the following figure:

Figure 17 WAPI Security Technology Architecture

As we all know, WAPI is a wireless LAN security technology independently put forward by our country, and it is also one of the only two WLAN security technologies in the world (the other is Wi-Fi security technology). Unlike Wi-Fi security technology, which is constantly tinkering with the defective architecture, WAPI security technology has adopted the advanced ternary peer-to-peer security architecture from the beginning of its design, which directly realizes the peer-to-peer two-way authentication between AP and the client. It can also be seen from the WAPI technical standards that technicians have considered a variety of possible security threats in the process of protocol design. These include * methods such as key reinstallation, and are clearly specified in the relevant technical standards of WAPI. For example, a robust processing method is adopted in the process of WAPI security protocol interaction. For retransmitted messages, the receiver will choose to discard or respond according to the needs. Even if the response is selected, it will only resend the previously sent messages as is, nothing more. The key installation will never be performed again, so that the premise of KRACK*** is not valid, and the subsequent * * is out of the question.

Write at the end:

Although safety is a thing, you won't know it's good if you don't suffer some losses! However, the old brick home is here to remind you to pay attention to the security of the wireless network while you haven't suffered a big loss. After all, no matter how you mend, the lost sheep will never come back!

Main references

[1] Mathy Vanhoef, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, https://www.krackattacks.com.

[2] IEEE Std 802.11. 2016. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Spec.

[3] IEEE Std 802.11ac. 2013. Amendment 4: Enhancements for Very High Throughput for Operation in Bands below 6 GHz.

[4] IEEE Std 802.11ad. 2012. Amendment 3: Enhancements for Very High Throughput in the 60 GHz Band.

[5] IEEE Std 802.11i. 2004. Amendment 6: Medium Access Control (MAC) Security Enhancements.

[6] IEEE Std 802.11r. 2008. Amendment 2: Fast Basic Service Set (BSS) Transition.

[7] GB 15629.11-2003/XG1-2006, information technology systems-telecommunications and information exchange-specific requirements for local and metropolitan area networks-part 11: wireless local area network media access control and physical layer specification amendment no. 1.

[8] CBWIPS/Z 008-2008 focus WAPI key management implementation guide.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.