Method and apparatus for device authentication in wireless local area network

Abstract

Embodiments of the present disclosure provide a method (60) for execution by a first device and a device for the method (60). The method (60) may comprise: obtaining (S602) identification information for a first device during a first association with a second device; determining (S604), during the first association, one or more parameters for verification; determining (S606) first verification information based at least on the one or more parameters; and transmitting (S608) the first message for the second association with the second device. The first message includes identification information for the first device and first verification information. Verification information of the device may be provided in a frame. Therefore, illegal devices can be further distinguished.

Description

Technical Field

[0001] Various example embodiments relate generally to communication technology, and more particularly to methods and apparatus for device authentication in a wireless local area network. Background Art

[0002] This section introduces aspects that may help to better understand the present disclosure. Therefore, the statements in this section should be read in this light, and should not be understood as an admission about what is in the prior art or what is not in the prior art.

[0003] In a wireless communication network (such as a wireless LAN), a communication device (such as a non-access point station, non-APSTA) can access the network via another communication device (such as an access point, AP) to obtain various services.

[0004] The communication between non-AP STA and AP is expected to be protected. However, in some scenarios, attackers will try to pretend to be a legitimate non-AP STA or AP. In particular, the attacker will obtain the device identification information of the non-AP STA or AP, because sometimes they must be transmitted without encryption or they may be intercepted and decrypted. Then, the attack will be performed by exploiting the identification information of the legitimate non-AP STA or AP. It is difficult for devices in the network to distinguish such attacks from normal communications. Summary of the invention

[0005] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these or other challenges. Various embodiments are proposed herein to solve one or more of the problems disclosed herein. Specific methods and apparatus for device authentication in a wireless local area network may be provided to improve the privacy and security of the wireless network.

[0007] A first aspect of the present disclosure provides a method performed by a first device. The method may include: obtaining identification information for the first device during a first association with a second device; determining one or more parameters for verification during the first association; determining first verification information based at least on the one or more parameters; and transmitting a first message for a second association with the second device. The first message includes identification information for the first device and the first verification information.

[0008] In an exemplary embodiment of the present disclosure, the identification information includes at least one of the following: an identifier ID, a random medium access control address RMA.

[0009] In an exemplary embodiment of the present disclosure, the one or more parameters for verification include at least one of the following: a key shared by the first device and the second device, a first initial frame number value, and a second initial frame number value. The first initial frame number value is the same as the second initial frame number value, or is different from the second initial frame number value. The first initial frame number value is for a frame sent from the first device to the second device, and the second initial frame number value is for a frame sent from the second device to the first device.

[0010] In an exemplary embodiment of the present disclosure, at least one of the first initial frame number value and the second initial frame number value has a fixed value, and the fixed value is secretly shared between the first device and the second device; or at least one of the first initial frame number value and the second initial frame number value has a random value, and the random value is publicly shared.

[0011] In an exemplary embodiment of the present disclosure, the first verification information includes a first frame number value and a first verification check field. The first device runs a first counter to determine the first frame number value based on the first initial frame number value and the number of frames transmitted from the first device to the second device before the first message, or based on the first initial frame number value and the number of frames exchanged by the first device and the second device before the first message. The first verification check field is determined using a formula shared between the first device and the second device, at least based on a key.

[0012] In an exemplary embodiment of the present disclosure, the first verification check field is also determined based on the first frame number value.

[0013] In an exemplary embodiment of the present disclosure, the first verification check field is also determined based on additional data related to at least one of the first message, the first device, and the second device. The additional data includes at least one of the following: public information, private information. The public information includes at least one of the following: a field in a media access control header, a public key, a public ID, a random number, and a public signature. The private information includes at least one of the following: a private key, a private ID, a private signature, or a random number.

[0014] In an exemplary embodiment of the present disclosure, the first frame number value and the first verification information are encrypted in the first message.

[0015] In an exemplary embodiment of the present disclosure, the first message includes a unicast management frame or a broadcast management frame.

[0016] In an exemplary embodiment of the present disclosure, the first message includes at least one of the following: a probe request, an authentication frame sent from the first device, an association request, and an action frame.

[0017] In an exemplary embodiment of the present disclosure, the action frame may be, for example, a public action frame, an FTM request, or the like.

[0018] In some embodiments, the 4-step handshake frame may not carry authentication information.

[0019] In an exemplary embodiment of the present disclosure, the method may further include: receiving a second message including identification information for the first device and / or the second device and second verification information. The second verification information includes a second frame number value and a second verification check field.

[0020] In an exemplary embodiment of the present disclosure, the method may further include: determining a third frame number value and a third verification check field; comparing the third frame number value with the second frame number value, and the third verification check field with the second verification check field; and determining that the second message is from an attacker based on at least one of the following: whether the third frame number value is greater than the second frame number value, wherein the third frame number value is determined based on a frame number value successfully received in a previous frame; whether the third frame number value is not equal to the second frame number value, wherein the third frame number value is determined based on a second initial frame number value and the number of frames exchanged by the first device and the second device before the second message; or whether the third verification check field is not equal to the second verification check field. The third frame number value is determined by the first counter based on a frame number value successfully received in a previous frame, or based on the second initial frame number value and the number of frames exchanged by the first device and the second device before the first message. The third verification check field is determined based on at least one of a key or a third frame number value using a formula shared between the first device and the second device.

[0021] In an exemplary embodiment of the present disclosure, the second frame number value and the second verification information are encrypted in the second message.

[0022] In an exemplary embodiment of the present disclosure, the second message includes a unicast management frame.

[0023] In an exemplary embodiment of the present disclosure, the second message includes at least one of the following: a probe response, an authentication frame sent from the second device, an association response, or an action frame.

[0024] In an exemplary embodiment of the present disclosure, the action frame may be, for example, a public action frame, an FTM request, or the like.

[0025] In some embodiments, the 4-step handshake frame may not carry authentication information.

[0026] In an exemplary embodiment of the present disclosure, the first device includes a non-AP STA or an access point AP in a wireless local area network operating according to the 802.11 standard. The second device includes an AP or a non-AP STA in the wireless local area network.

[0027] A second aspect of the present disclosure provides a method performed by a second device. The method may include: obtaining identification information for the first device during a first association with the first device; determining one or more parameters for verification during the first association; and receiving a first message for a second association with the first device. The first message includes identification information for the first device and first verification information.

[0028] In an exemplary embodiment of the present disclosure, the identification information includes at least one of the following: an identifier ID, or a random media access control address RMA.

[0029] In an exemplary embodiment of the present disclosure, the one or more parameters for verification include at least one of the following: a key shared by the first device and the second device, a first initial frame number value, and a second initial frame number value. The first initial frame number value is the same as the second initial frame number value, or is different from the second initial frame number value. The first initial frame number value is for a frame sent from the first device to the second device, and the second initial frame number value is for a frame sent from the second device to the first device.

[0030] In an exemplary embodiment of the present disclosure, at least one of the first initial frame number value and the second initial frame number value has a fixed value, and the fixed value is secretly shared between the first device and the second device; or at least one of the first initial frame number value and the second initial frame number value has a random value, and the random value is publicly shared.

[0031] In an exemplary embodiment of the present disclosure, the first verification information includes a first frame number value and a first verification check field.

[0032] In an exemplary embodiment of the present disclosure, the method may further include: determining a fourth frame number value and a fourth verification check field; comparing the fourth frame number value with the first frame number value, and the fourth verification check field with the first verification check field; and determining that the first message is from an attacker based on at least one of the following: whether the fourth frame number value is greater than the first frame number value, wherein the fourth frame number value is determined based on a frame number value successfully received in a previous frame; whether the fourth frame number value is not equal to the first frame number value, wherein the fourth frame number value is determined based on a first initial frame number value and the number of frames exchanged by the first device and the second device before the first message; or whether the fourth verification check field is not equal to the first verification check field. The fourth frame number value is determined by a second counter based on a frame number value successfully received in a previous frame, or based on the first initial frame number value and the number of frames exchanged by the first device and the second device before the first message. The fourth verification check field is determined based on at least a key using a formula shared between the first device and the second device.

[0033] In an exemplary embodiment of the present disclosure, the fourth verification check field is further determined based on a fourth frame number value.

[0034] In an exemplary embodiment of the present disclosure, the fourth verification check field is also determined based on additional data related to at least one of the first message, the first device, or the second device. The additional data includes at least one of the following: public information, private information. The public information includes at least one of the following: a field in a media access control header, a public key, a public ID, a random number, or a public signature. The private information includes at least one of the following: a private key, a private ID, a private signature, a random number.

[0035] In an exemplary embodiment of the present disclosure, the first frame number value and the first verification information are encrypted in the first message.

[0036] In an exemplary embodiment of the present disclosure, the first message includes a unicast management frame or a broadcast management frame.

[0037] In an exemplary embodiment of the present disclosure, the first message includes at least one of the following: a probe request, an authentication frame sent from the first device, an association request, or an action frame.

[0038] In an exemplary embodiment of the present disclosure, the method may further include: transmitting a second message, the second message including identification information for the first device and / or the second device and second verification information. The second verification information includes a second frame number value and a second verification check field. The second device runs a second counter to determine the second frame number value based on the second initial frame number value and the number of frames transmitted from the second device to the first device before the second message, or based on the second initial frame number value and the number of frames exchanged by the first device and the second device before the second message. The second verification check field is determined based on at least one of a key or a second frame number value using a formula shared between the first device and the second device.

[0039] In an exemplary embodiment of the present disclosure, the second frame number value and the second verification information are encrypted in the second message.

[0040] In an exemplary embodiment of the present disclosure, the second message includes a unicast management frame or a broadcast management frame.

[0041] In an exemplary embodiment of the present disclosure, the second message includes at least one of the following: a probe response, an authentication frame sent from the second device, an association response, or an action frame.

[0042] In an exemplary embodiment of the present disclosure, the first device includes a non-AP STA or an access point AP in a wireless local area network operating according to the 802.11 standard. The second device includes an AP or a non-AP STA in the wireless local area network.

[0043] A third aspect of the present disclosure provides a first device, comprising a component configured to: obtain identification information for the first device during a first association with a second device; determine one or more parameters for verification during the first association; determine first verification information based at least on the one or more parameters; and transmit a first message for a second association with the second device. The first message includes identification information for the first device and the first verification information.

[0044] In an exemplary embodiment of the present disclosure, the component is further configured to perform a method according to any one of the embodiments in the first aspect.

[0045] In an exemplary embodiment of the present disclosure, a component includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause execution of a first device.

[0046] A fourth aspect of the present disclosure provides a second device, comprising a component configured to: obtain identification information for the first device during a first association with the first device; determine one or more parameters for verification during the first association; and receive a first message for a second association with the first device. The first message includes identification information for the first device and first verification information.

[0047] In an exemplary embodiment of the present disclosure, the component is further configured to perform a method according to any one of the embodiments in the second aspect.

[0048] In an exemplary embodiment of the present disclosure, a component includes: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause execution of a second device.

[0049] The fifth aspect of the present disclosure provides a computer-readable storage medium storing instructions, which, when the instructions are executed by at least one processor of a first device, causes the at least one processor of the first device to execute a method according to any one of the embodiments in the first aspect; or, when the instructions are executed by at least one processor of a second device, causes the at least one processor of the second device to execute a method according to any one of the embodiments in the second aspect.

[0050] Embodiments of the present invention provide many advantages. According to embodiments of the present disclosure, an improved method for device authentication in a wireless local area network can be provided. Authentication information of the device can be provided in a frame. Therefore, illegal devices can be further distinguished.

[0051] In particular, the authentication information is generated based on one or more specific parameters for authentication determined during the first association between the first device and the second device. Therefore, it is difficult for an attacker to pretend to be the first device or the second device during other association processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The above and other aspects, features and benefits of various embodiments of the present disclosure will become more fully apparent from the following detailed description with reference to the accompanying drawings, by way of example, in which the same reference numerals or letters are used to designate the same or equivalent elements. The accompanying drawings are shown to facilitate a better understanding of the embodiments of the present disclosure and are not necessarily drawn to scale, wherein:

[0053] Figure 1 is a diagram showing an existing identification method for a non-AP STA and / or an AP using RMA in the 802.11 standard.

[0054] Figure 2 is a diagram showing a process against a replay attack.

[0055] Figure 3 is a diagram showing the process of attacking the Evil Twin.

[0056] Figure 4 is a diagram showing a method for an attacker to obtain device identification information (eg, ID or RMA) of a legitimate non-AP STA and AP.

[0057] Figure 5 is a diagram illustrating an attacker acting as a non-AP STA or an AP.

[0058] Figure 6a is a flowchart illustrating a method performed by a first device according to an exemplary embodiment of the present disclosure.

[0059] Figure 6b is a flowchart illustrating additional steps of a method performed by a first device according to some embodiments of the present disclosure.

[0060] Figure 7a is a flowchart illustrating a method performed by a second device according to an exemplary embodiment of the present disclosure.

[0061] Figure 7b is a flowchart illustrating additional steps of a method performed by a second device according to some embodiments of the present disclosure.

[0062] Figure 7c is a flowchart illustrating additional steps of a method performed by a second device according to some embodiments of the present disclosure.

[0063] Figure 8a is a block diagram illustrating an exemplary structure for a first device according to an exemplary embodiment of the present disclosure.

[0064] Figure 8b is a block diagram illustrating an exemplary structure for a second device according to an exemplary embodiment of the present disclosure.

[0065] Fig. 9 is a block diagram illustrating a device / computer-readable storage medium according to an embodiment of the present disclosure.

[0066] Fig.10a is a block diagram showing exemplary device units for a first device suitable for performing a method according to an embodiment of the present disclosure.

[0067] Fig.10b is a block diagram showing an exemplary device unit suitable for executing the method according to an embodiment of the present disclosure, with respect to a second device.

[0068] Fig.11is a diagram showing the use of a proposed information element, Authentication Information Element (VIE), and verifying whether a frame is from an authenticated STA or from an attacker.

[0069] Fig.12 is a diagram showing an example of a Authentication Information Element (VIE) and its fields - Frame Number (FN) and Authentication Check (VC).

[0070] Fig.13a is a diagram illustrating an example of definition for a verification information element (VIE) according to an embodiment of the present disclosure.

[0071] Fig.13b is a diagram illustrating an example of a verification information element (VIE) format according to an embodiment of the present disclosure.

[0072] Fig.14 is a diagram illustrating a proposed verification information element (VIE) in a probe request according to an embodiment of the present disclosure.

[0073] Fig.15 is a diagram illustrating an example scenario of constructing a VIE.

[0074] Fig.16 is a diagram illustrating an example scenario of use of VIE[FN, VC] and attacker detection according to an embodiment of the present disclosure.

[0075] Fig.17a is a diagram illustrating a first example scenario regarding an increase in a frame number value.

[0076] Fig.17b is a diagram illustrating a second example scenario regarding an increase in a frame number value.

[0077] Fig.17c is a diagram illustrating a third example scenario regarding an increase in a frame number value.

[0078] Fig.17d is a diagram illustrating a fourth example scenario regarding an increase in a frame number value.

[0079] Fig.17e is a diagram illustrating a fifth example scenario regarding an increase in frame number value. DETAILED DESCRIPTION

[0080] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for better understanding, rather than limiting the scope of the present disclosure. The features, advantages and characteristics of the present disclosure described can be combined in any suitable manner in one or more embodiments.

[0081] Generally, all terms used herein will be interpreted according to their ordinary meanings in the relevant technical field, unless a different meaning is clearly given and / or implied from the context in which it is used. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless the steps are clearly given and / or implied from the context. Any feature of any embodiment disclosed herein may be applied to any other embodiment, where appropriate.

[0082] As used herein, the term "network" or "communication network" refers to a network that complies with any suitable communication standard, such as for the Internet or any wireless network. For example, wireless communication standards may include WLAN, New Radio (NR), Long Term Evolution (LTE), LTE-Advanced, etc. In the following description, the terms "network" and "system" may be used interchangeably.

[0083] The term "communication device" refers to any terminal device that can access a communication network and receive services therefrom. By way of example and not limitation, a communication device refers to a mobile terminal, a user equipment (UE), or other suitable device. A communication device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a wearable device, a vehicle-mounted wireless terminal device, a vehicle, etc.

[0084] As an example, a communications apparatus may refer to a device configured to communicate in accordance with one or more communications standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE), such as any 802.11 standard, or standards promulgated by any other organization, such as the 3rd Generation Partnership Project (3GPP).

[0085] As another example, in an Internet of Things (IoT) scenario, a communication device may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another terminal device and / or network device. Specific examples of such machines or devices are sensors, metering devices (such as power meters), industrial machinery, or household or personal appliances (e.g., refrigerators, televisions), personal wearable devices (such as watches), etc. In other scenarios, a communication device may represent a vehicle or other device that is capable of monitoring and / or reporting its operating status or other functions associated with its operation.

[0086] It should be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element without departing from the scope of the exemplary embodiments. As used herein, the term "and / or" includes any and all combinations of one or more associated listed terms.

[0087] As used herein, “at least one of: ” and “at least one of ” and similar expressions (wherein a list of two or more elements is connected by “and” or “or”) mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0088] The following is an example only and not a limitation to illustrate the application scenario in an 802.11 network.

[0089] By way of illustrative example and not limitation, embodiments of the present disclosure may be related to privacy enhancements for the 802.11bi and 802.11bh family of standards, particularly focusing on replay and evil twin attacks and user authentication against devices using random MAC addresses (RMA).

[0090] In conventional 802.11 standards, STAs use fixed, unencrypted MAC addresses in frame headers, which causes security issues by allowing others to track STAs based on their MAC addresses. In order to prevent STAs from being tracked and improve the privacy and security of 802.11, MAC address randomization (i.e., random change MAC (RCM)) has become a common technology. In this regard, the 802.11bh and 802.11bi groups focus on using RMA to identify STAs without reducing user privacy.

[0091] 802.11bh focuses on identifying a device (i.e., non-AP STA) by MAC randomization in the pre-association phase, while after association (i.e., post-association), the device (i.e., non-AP STA) still does not change the MAC address. On the other hand, IEEE802.11bi addresses privacy issues as part of its work and management to address the situation where non-AP STA can also change its MAC address after association. Note that non-AP STA is abbreviated as STA in this disclosure.

[0092] Figure 1 is a diagram showing an existing identification method for a non-AP STA and / or an AP using RMA in the 802.11 standard.

[0093] like Figure 1 As shown, the non-AP STA and / or AP obtains device identification information (eg, ID or RMA) in a first association, and uses the allocated device identification information (eg, ID or RMA) in (multiple) subsequent associations.

[0094] In order to identify non-AP STAs with RMA, there are multiple proposals, namely [22 / 187r2, 22 / 925r2, 22 / 895r1, 22 / 888r2, 22 / 158r3] in 802.11bh, and [22 / 114r3] in 802.11bi. Basically, when a non-AP STA first associates with an AP, the proposed mechanism allocates device identification information (e.g., ID or RMA) to the non-AP STA, and then the non-AP STA uses the allocated device identification information (e.g., ID or RMA) in (multiple) subsequent associations, such as Figure 1 As shown. Specifically, the non-AP STA uses STA_MAC in its first association. After the STA associates with the AP using STA_MAC, it is assigned device identification information (e.g., ID or RMA, depending on the identification method). After the non-AP STA disconnects and associates with the AP again (subsequent association), it uses the previously assigned (e.g., from the first association) device identification information (e.g., ID or RMA) (depending on the identification method), and is therefore identified by the AP.

[0095] After the non-AP STA receives a beacon from the AP, the first association may involve a process for a probe message, an authentication message, an association message, a 4-way handshake, a data connection, and a disconnection. Such a message may be any type of frame and may be used for a request or a response, etc.

[0096] After the non-AP STA receives the beacon from the AP, the subsequent association may involve procedures for other probe messages, authentication messages, association messages, 4-step handshake, and data connection.

[0097] Note that a non-AP STA and / or AP may be assigned multiple device identification information (e.g., multiple IDs or multiple RMAs) in one association (e.g., a first association) and use at least one of them in (multiple) subsequent associations (e.g., a second association).

[0098] Figure 2 is a diagram showing a process against a replay attack.

[0099] like Figure 2 As shown, an attacker intercepts (eg, listens to) a secure channel, copies packets / frames from a user, and sends these packets / frames to the network for manipulation.

[0100] A replay attack occurs when an attacker listens to (i.e., sniffs) secure network communications (i.e., the original communications between a user and a legitimate AP), intercepts the communications, and then delays or resends (i.e., replays) the packets to mislead the receiver (e.g., the network). Note that the hacker does not even need to decrypt the packets after capturing them from the network. The attack can succeed simply by resending them in their entirety.

[0101] Figure 3 is a diagram showing the process of attacking against the evil twin.

[0102] like Figure 3 As shown, the attacker AP listens to and replicates the legitimate AP, and acts like a legitimate AP to trick users into connecting to the attacker AP itself. The Evil Twin attack works by tricking users into connecting to a fake Wi-Fi (Wireless Fidelity) access point that disguises a legitimate network. To do this, the attacker sets up a Wi-Fi AP by replicating the SSID (Service Set Identifier) ​​and / or BSSID (Basic Service Set Identifier) ​​as a nearby legitimate Wi-Fi network. The attacker may perform a DoS (Denial of Service) attack on the legitimate access point, which will cause it to go offline. Thereafter, the original communication between the user and the legitimate AP will fail, and the user (i.e., the client) will then automatically connect to the attacker AP (i.e., the fake access point).

[0103] So there might be some issues.

[0104] The above RMA identification method has similar logic: a legitimate non-AP STA and / or AP (referred to herein as non-AP STA) is assigned device identification information (e.g., ID or RMA) in an association (e.g., a first association), and the non-AP STA and / or AP uses the assigned device identification information (e.g., ID or RMA) in a subsequent association (e.g., a second association). In other words, the non-AP STA and / or AP uses the pre-assigned device identification information (e.g., ID or RMA) (i.e., in the current association, the non-AP STA and / or AP is using the device identification information (e.g., ID or RMA) assigned from the previous association). Note that the non-AP STA and / or AP may be assigned multiple device identification information (e.g., multiple IDs or multiple RMAs) in one association (e.g., a first association), and at least one of the multiple device identification information is used in (multiple) subsequent associations (e.g., a second association). The embodiments of the present disclosure do not distinguish between a single device identification information or multiple device identification information, that is, the solution proposed in the embodiments can cover both single device identification information and multiple device identification information cases. For simplicity, both cases (single and multiple device identification information) are referred to as the same in this disclosure.

[0105] This approach (i.e., using pre-assigned device identification information) raises some concerns about replay and evil twin attacks, where an attacker can obtain the device identification information (e.g., ID or RMA) of a non-AP STA and / or AP and use (copy) the device identification information (e.g., ID or RMA) to impersonate a non-AP STA or AP. Note that pre-association frames (probe, authentication, association, action, and part of the 4-step HS) are usually not well protected because the non-AP STA and AP do not have a security association when sending these frames, so these frames are more vulnerable to attacks.

[0106] Figure 4 is a diagram showing a method for an attacker to obtain device identification information (eg, ID or RMA) of a legitimate non-AP STA and / or AP.

[0107] like Figure 4 As shown, obtaining the device identification information (eg, ID or RMA) may occur in a number of ways including the following.

[0108] (1) The attacker intercepts frames in which device identification information (e.g., ID or RMA) is assigned to legitimate non-AP STAs and / or APs. There may be several types of frames in which non-AP STAs and / or APs are assigned device identification information (e.g., ID or RMA), including probe messages, authentication messages, association messages, or 4-step handshakes during association (e.g., first association). The attacker may intercept any of these frames and obtain the device identification information (e.g., ID or RMA) of non-AP STAs and / or APs.

[0109] (2) The attacker listens to (sniffs) frames in which legitimate non-AP STAs and / or APs send device identification information (e.g., ID or RMA) to / from the AP. There may be several possible frames in which STAs and / or APs carry device identification information (e.g., ID or RMA), including in probe messages, authentication messages, association messages, or 4-way handshakes in (multiple) subsequent associations. The attacker may sniff any of these frames and obtain the device identification information (e.g., ID or RMA) of the non-AP STA and / or AP.

[0110] Figure 5 is a diagram illustrating an attacker acting as a non-AP STA or an AP.

[0111] After the attacker obtains the device identification information (e.g., ID or RMA) of a legitimate non-AP STA, it can act like a non-AP STA or AP. In both cases, because the attacker has the device identification information (e.g., ID or RMA) of a non-AP STA, the attacker can use them to impersonate a legitimate non-AP STA or AP, such as Figure 5 shown.

[0112] Some examples of attacks are described below.

[0113] If an attacker impersonates a non-AP STA, then - An attacker can send a probe request to discover a network, and the AP will not understand that the request is from an attacker (for the AP, if the non-AP STA carries previously assigned device identification information (e.g., ID or RMA), it is considered a legitimate non-AP STA). The AP will then reply to the probe request with a probe response, resulting in the exposure of information (such as information elements (IEs) carrying network information) to the attacker (note that 802.11REVme_D1.3.pdf defines at least 111 IEs for probe responses). -An attacker can send authentication frames and association frames to start the association process, and the AP will accept these requests (by sending authentication and association responses) because the attacker carries device identification information (e.g., ID or RMA), resulting in the leakage of network-related information (such as the network's capabilities and security information) and key generation-related information (such as PMK). - The attacker can send a 4-step handshake (HS) frame to complete the association process and start data communication. Even though the attacker uses device identification information (e.g., ID or RMA) (note that the STA needs to use the correct password to complete the 4-step HS), it is rejected by the AP because the attacker does not have the password of the network (incorrect password), but the use of device identification information (e.g., ID or RMA) still results in some 4-step HS message exchanges, exposing key generation related information (such as PTK). It should also be noted that since the rejection of the incorrect password occurs in the 4-step HS, it means that the attack through the probe / authentication / association request is still effective even if the attacker does not use the correct password.

[0114] If an attacker impersonates an AP: - An attacker can send a beacon frame, and the legitimate non-AP STA will think that the AP is the real AP, and the non-AP STA will start the connection process with the attacker. -An attacker can send a probe response, authentication response, association response, and 4-step handshake messages to a non-AP STA in response to the probe request, authentication request, association request, and 4-step handshake messages, and the non-AP STA will not understand that these response frames are from the attacker and will therefore continue with these frame exchanges, resulting in the attacker obtaining critical information (discussed in the previous paragraph).

[0115] As described above, when non-AP STAs and / or APs use pre-assigned device identification information (e.g., single or multiple IDs or RMA) for identification purposes, an attacker may copy and use the device identification information of the non-AP STA and / or AP (obtained by (1) intercepting frames exchanging device identification information or (2) sniffing and copying frames carrying device identification information) to impersonate a legitimate non-AP STA or AP. It is important to recall that pre-association frames (part of probe, authentication, association, action, and 4-step HS) are more vulnerable to attacks due to the lack of security establishment between the non-AP STA and the AP. Therefore, an attacker can launch some of the above-mentioned attacks. To mitigate these types of attacks, non-AP STAs and APs need to ensure (verify) that broadcast management frames (e.g., broadcast probe requests, beacons, some broadcast action frames) and / or unicast management frames (e.g., directed probes, authentication / association / action) are from a verified STA (non-AP STA or AP).

[0116] FIG. 6 is a flowchart illustrating a method performed by a first device according to an exemplary embodiment of the present disclosure.

[0117] As shown in FIG6 , method 60 may include: step S602, obtaining identification information for the first device during a first association with the second device; step S604, determining one or more parameters for verification during the first association; step S606, determining first verification information based on at least one or more parameters; and step S608, transmitting a first message for a second association with the second device. The first message includes identification information for the first device and the first verification information.

[0118] According to an embodiment of the present disclosure, verification information of a device may be provided in a frame. Therefore, illegal devices may be further distinguished. In particular, the verification information is generated based on one or more specific parameters for verification determined during a first association between a first device and a second device. Therefore, it is difficult for an attacker to pretend to be the first device or the second device in other association processes.

[0119] In an exemplary embodiment of the present disclosure, the identification information includes at least one of the following: an identifier ID, a random medium access control address RMA.

[0120] In an exemplary embodiment of the present disclosure, the one or more parameters for verification include at least one of the following: a key shared by the first device and the second device, a first initial frame number value, and a second initial frame number value. The first initial frame number value is the same as the second initial frame number value, or is different from the second initial frame number value. The first initial frame number value is for a frame sent from the first device to the second device, and the second initial frame number value is for a frame sent from the second device to the first device.

[0121] In an exemplary embodiment of the present disclosure, at least one of the first initial frame number value and the second initial frame number value has a fixed value, and the fixed value is secretly shared between the first device and the second device; or at least one of the first initial frame number value and the second initial frame number value has a random value, and the random value is publicly shared.

[0122] For example, the first initial frame number value and the second initial frame number value may be configured, or a random number may be determined based on a certain rule, for example, generated based on a secret key or a public key. If the initial frame number value is configured (fixed value), it is shared secretly. If it is a random value, it is shared publicly.

[0123] In an exemplary embodiment of the present disclosure, the first verification information includes a first frame number value and a first verification check field. The first device runs a first counter to determine the first frame number value based on the first initial frame number value and the number of frames transmitted from the first device to the second device before the first message, or based on the first initial frame number value and the number of frames exchanged by the first device and the second device before the first message. The first verification check field is determined using a formula shared between the first device and the second device, at least based on a key.

[0124] In an exemplary embodiment of the present disclosure, the first verification check field is also determined based on the first frame number value.

[0125] In an exemplary embodiment of the present disclosure, the first verification check field is also determined based on additional data related to at least one of the first message, the first device, and the second device. The additional data includes at least one of the following: public information, private information. The public information includes at least one of the following: a field in a media access control header, a public key, a public ID, a random number, and a public signature. The private information includes at least one of the following: a private key, a private ID, a private signature, or a random number.

[0126] According to the embodiments of the present disclosure, it is difficult for an attacker to generate verification information.

[0127] In an exemplary embodiment of the present disclosure, the first frame number value and the first verification information are encrypted in the first message.

[0128] In an exemplary embodiment of the present disclosure, the first message includes a unicast management frame or a broadcast management frame.

[0129] In an exemplary embodiment of the present disclosure, the first message includes at least one of the following: a probe request, an authentication frame sent from the first device, an association request, and an action frame. The action frame may be, for example, a public action frame and an FTM request.

[0130] In an exemplary embodiment of the present disclosure, the action frame may be, for example, a public action frame, an FTM request, or the like.

[0131] In some embodiments, the 4-step handshake frame may not carry verification information. The 4-step handshake frame may carry a device identification.

[0132] According to an embodiment of the present disclosure, such authentication information can be widely used, and thus legitimate devices can be protected in extraordinary scenarios.

[0133] Figure 6b is a flow chart illustrating additional steps of a method performed by a first device according to some embodiments of the present invention.

[0134] like Figure 6b As shown, the method 60 may further include: step S610, receiving a second message, the second message including identification information for the first device and / or the second device and second verification information. The second verification information includes a second frame number value and a second verification check field.

[0135] In an exemplary embodiment of the present disclosure, the method 60 may further include: step S612, determining (S612) a third frame number value and a third verification check field; step S614, comparing (S614) the third frame number value with the second frame number value, and the third verification check field with the second verification check field; and step S616, determining (S616) that the second message is from an attacker based on at least one of the following: whether the third frame number value is greater than the second frame number value, wherein the third frame number value is determined based on a frame number value successfully received in a previous frame; whether the third frame number value is not equal to the second frame number value, wherein the third frame number value is determined based on a second initial frame number value and the number of frames exchanged by the first device and the second device before the second message; or whether the third verification check field is not equal to the second verification check field. The third frame number value is determined by the first counter based on a frame number value successfully received in a previous frame, or based on the second initial frame number value and the number of frames exchanged by the first device and the second device before the first message. The third authentication check field is determined based on at least one of a key or a third frame number value using a formula shared between the first device and the second device.

[0136] According to an embodiment of the present disclosure, a specific method for distinguishing attack messages may be provided.

[0137] In an exemplary embodiment of the present disclosure, the second frame number value and the second verification information are encrypted in the second message.

[0138] In an exemplary embodiment of the present disclosure, the second message includes a unicast management frame.

[0139] In an exemplary embodiment of the present disclosure, the second message includes at least one of the following: a probe response, an authentication frame sent from the second device, an association response, or an action frame.

[0140] In an exemplary embodiment of the present disclosure, the action frame may be, for example, a public action frame, an FTM request, or the like.

[0141] In some embodiments, the 4-step handshake frame may not carry authentication information.

[0142] In an exemplary embodiment of the present disclosure, the first device includes a non-AP STA or an access point AP in a wireless local area network operating according to the 802.11 standard. The second device includes an AP or a non-AP STA in the wireless local area network.

[0143] Figure 7a is a flowchart illustrating a method performed by a second device according to an exemplary embodiment of the present disclosure.

[0144] As shown in FIG7 , method 70 may include: step S702, during a first association with a first device, obtaining identification information for the first device; step S704, during the first association, determining one or more parameters for verification; and step S706, receiving a first message for a second association with the first device. The first message includes identification information for the first device and first verification information.

[0145] In an exemplary embodiment of the present disclosure, the identification information includes at least one of the following: an identifier ID, or a random media access control address RMA.

[0146] In an exemplary embodiment of the present disclosure, the one or more parameters for verification include at least one of the following: a key shared by the first device and the second device, a first initial frame number value, and a second initial frame number value. The first initial frame number value is the same as the second initial frame number value, or is different from the second initial frame number value. The first initial frame number value is for a frame sent from the first device to the second device, and the second initial frame number value is for a frame sent from the second device to the first device.

[0147] In an exemplary embodiment of the present disclosure, at least one of the first initial frame number value and the second initial frame number value has a fixed value, and the fixed value is secretly shared between the first device and the second device; or at least one of the first initial frame number value and the second initial frame number value has a random value, and the random value is publicly shared. In an exemplary embodiment of the present disclosure, the first verification information includes a first frame number value and a first verification check field.

[0148] Figure 7b is a flowchart illustrating additional steps of a method performed by a second device according to some embodiments of the present disclosure.

[0149] like Figure 7b As shown, method 70 may also include: step S708, determining a fourth frame number value and a fourth verification check field; step S710, comparing the fourth frame number value with the first frame number value, and the fourth verification check field with the first verification check field; and step S712, determining that the first message comes from an attacker based on at least one of the following: whether the fourth frame number value is greater than the first frame number value, wherein the fourth frame number value is determined based on a frame number value successfully received in a previous frame; whether the fourth frame number value is not equal to the first frame number value, wherein the fourth frame number value is determined based on a first initial frame number value and the number of frames exchanged by the first device and the second device before the first message; or whether the fourth verification check field is not equal to the first verification check field. The fourth frame number value is determined by a second counter based on a frame number value successfully received in a previous frame, or based on the first initial frame number value and the number of frames exchanged by the first device and the second device before the first message. The fourth verification check field is determined using a formula shared between the first device and the second device, at least based on a key.

[0150] In an exemplary embodiment of the present disclosure, the fourth verification check field is further determined based on a fourth frame number value.

[0151] In an exemplary embodiment of the present disclosure, the fourth verification check field is also determined based on additional data related to at least one of the first message, the first device, or the second device. The additional data includes at least one of the following: public information, private information. The public information includes at least one of the following: a field in a media access control header, a public key, a public ID, a random number, or a public signature. The private information includes at least one of the following: a private key, a private ID, a private signature, a random number.

[0152] In an exemplary embodiment of the present disclosure, the first frame number value and the first verification information are encrypted in the first message.

[0153] In an exemplary embodiment of the present disclosure, the first message includes a unicast management frame or a broadcast management frame.

[0154] In an exemplary embodiment of the present disclosure, the first message includes at least one of the following: a probe request, an authentication frame sent from the first device, an association request, or an action frame. The action frame may be, for example, a public action frame or an FTM request.

[0155] Figure 7c is a flowchart illustrating additional steps of a method performed by a second device according to some embodiments of the present disclosure.

[0156] In an exemplary embodiment of the present disclosure, method 70 may further include: step S714, transmitting a second message, the second message including identification information for the first device and / or the second device and second verification information. The second verification information includes a second frame number value and a second verification check field. The second device runs a second counter to determine the second frame number value based on the second initial frame number value and the number of frames transmitted from the second device to the first device before the second message, or based on the second initial frame number value and the number of frames exchanged by the first device and the second device before the second message. The second verification check field is determined based on at least one of a key or a second frame number value using a formula shared between the first device and the second device.

[0157] In an exemplary embodiment of the present disclosure, the second frame number value and the second verification information are encrypted in the second message.

[0158] In an exemplary embodiment of the present disclosure, the second message includes a unicast management frame or a broadcast management frame.

[0159] In an exemplary embodiment of the present disclosure, the second message includes at least one of the following: a probe response, an authentication frame sent from the second device, an association response, or an action frame.

[0160] In an exemplary embodiment of the present disclosure, the first device includes a non-AP STA or an access point AP in a wireless local area network operating according to the 802.11 standard. The second device includes an AP or a non-AP STA in the wireless local area network.

[0161] According to an embodiment of the present disclosure, the STA and the AP each obtain an identifier (eg, ID or RMA). The STA or the AP uses its own identifier (eg, ID or RMA).

[0162] When there is an attack (disguised STA or AP), the STA should verify the frames from the real AP, and the AP should verify the frames from the STA. To this end, FN+VC (IE) is used for unicast management (from STA to AP, from AP to STA) and broadcast management (from STA to each frame, from AP to each frame).

[0163] A key (VK) is defined between each STA and the AP and is stored at the STA and AP for future use.

[0164] For unicast management frames, a unique VK should be determined for each STA-AP pair.

[0165] For broadcast management frames, a single VK should be determined for all STA-AP pairs (basically, one single key for all STAs and APs).

[0166] FIG. 8 is a block diagram illustrating an exemplary structure for a first device according to an exemplary embodiment of the present disclosure.

[0167] like Figure 8a As shown, the first device 80 includes a component 800, which is configured to: obtain identification information for the first device during a first association with a second device; determine one or more parameters for verification during the first association; determine first verification information based on at least one or more parameters; and transmit a first message for a second association with the second device. The first message includes identification information for the first device and the first verification information.

[0168] In an exemplary embodiment of the present disclosure, the component 800 is further configured to perform a method according to any embodiment of the first aspect, such as Figure 6a , Figure 6b shown.

[0169] In an exemplary embodiment of the present disclosure, the component 800 includes: at least one processor 802; and at least one memory 804 storing instructions that, when executed by the at least one processor 802, cause the execution of the first device 80.

[0170] Figure 8b is a block diagram illustrating an exemplary structure for a second device according to an exemplary embodiment of the present disclosure.

[0171] like Figure 8b As shown, the second device 81 includes a component 810, which is configured to: obtain identification information for the first device during a first association with the first device; determine one or more parameters for verification during the first association; and receive a first message for a second association with the first device. The first message includes identification information for the first device and first verification information.

[0172] In an exemplary embodiment of the present disclosure, component 810 is further configured to perform a method according to any embodiment of the second aspect, such as Figure 7a , 7b , as shown in 7c.

[0173] In an exemplary embodiment of the present disclosure, the component 810 includes: at least one processor 812; and at least one memory 814 storing instructions that, when executed by the at least one processor 812, cause execution of the second device 81.

[0174] The processors 802, 812 may be any kind of processing components, such as one or more microprocessors or microcontrollers, and other digital hardware that may include a digital signal processor (DSP), dedicated digital logic, etc. The memories 804, 814 may be any kind of storage components, such as read-only memory (ROM), random access memory, cache memory, flash memory devices, optical storage devices, etc.

[0175] Fig. 9 is a block diagram illustrating a device / computer-readable storage medium according to an embodiment of the present disclosure.

[0176] like Fig. 9 As shown, the computer-readable storage medium 90 stores instructions 91. When the instructions (91) are executed by at least one processor of the first device, the at least one processor of the first device executes the method according to any embodiment of the first aspect, for example Figure 6a , 6b As shown; or when instruction (91) is executed by at least one processor of the second device, at least one processor of the second device executes the method according to any embodiment of the second aspect, for example Figure 7a , 7b , as shown in 7c.

[0177] In addition, the present disclosure may also provide a carrier, which contains the computer program / instructions as described above. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium. The computer-readable storage medium may be, for example, an optical disc or an electronic memory device, such as a RAM (random access memory), a ROM (read-only memory), a flash memory, a magnetic tape, a CD-ROM, a DVD, a Blu-ray disc, etc.

[0178] Fig.10a is a block diagram showing exemplary device units for a first device suitable for performing a method according to an embodiment of the present disclosure.

[0179] As shown in FIG. 10 , the first device 10 may include: an acquisition unit 102 configured to obtain (S602) identification information for the first device during a first association with a second device; a first determination unit 104 configured to determine (S604) one or more parameters for verification during the first association; a second determination unit 106 configured to determine (S606) first verification information based on at least one or more parameters; and a sending unit 108 configured to transmit (S608) a first message for a second association with the second device. The first message includes identification information for the first device and the first verification information.

[0180] In an exemplary embodiment of the present disclosure, the first device 10 is further configured to execute the method of any embodiment in the first aspect, such as Figure 6a , Figure 6b shown.

[0181] Fig.10b is a block diagram showing an exemplary device unit suitable for executing the method according to an embodiment of the present disclosure, with respect to a second device.

[0182] As shown in FIG10 , the second device 11 may include: an acquisition unit 112 configured to obtain (S702) identification information for the first device during a first association with the first device; a determination unit 114 configured to determine (S704) one or more parameters for verification during the first association; and a receiving unit 116 configured to receive (S706) a first message for a second association with the first device. The first message includes identification information for the first device and first verification information.

[0183] In an exemplary embodiment of the present disclosure, the second device 11 is further configured to execute the method according to any embodiment of the first aspect, such as Figure 7a , 7b , as shown in 7c.

[0184] The term "unit" may have a conventional meaning in the field of electronics, electrical devices and / or electronic devices, and may include, for example, electrical and / or electronic circuit systems, devices, modules, processors, memories, logical solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, processes, calculations, output and / or display functions, etc., such as those described herein.

[0185] As used in this disclosure, the term "circuitry" may refer to one or more or all of the following: (a) hardware circuit implementation only (such as implementation in analog and / or digital circuits only) and (b) a combination of hardware circuitry and software such as (where applicable): (i) a combination of analog and / or digital hardware circuits and software / firmware and (ii) any portion of hardware processor(s) with software (including digital signal processor(s), software and memory(s) that work together to enable a device (such as a mobile phone or server) to perform various functions) and (c) Hardware circuits and / or processor(s), such as microprocessor(s) or portions of microprocessor(s), that require software (e.g., firmware) to operate, but which may not be present when the software is not required to operate.

[0186] The definition of circuitry applies to all uses of the term in this disclosure, including any claims. As yet another example, as used in this disclosure, the term circuitry also covers an implementation of only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example (and if applicable to a particular claim element), a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in a server, cellular network device, or other computing or network device.

[0187] With these units, the device may not need a fixed processor or memory, and any kind of computing resources and storage resources may be arranged from at least one network node / device / entity / device related to the communication system. Virtualization technology and network computing technology (e.g., cloud computing) may be further introduced to improve the efficiency of network resource utilization and network flexibility.

[0188] The techniques described herein can be implemented by various components, so that the device that implements one or more functions of the corresponding device described in the embodiment includes not only the components of the prior art, but also the components for implementing one or more functions of the corresponding device described in the embodiment, and the device may include a separate component for each separate function, or a component that can be configured to perform two or more functions. For example, these techniques can be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules / units), or a combination thereof. For firmware or software, it can be implemented by a module (e.g., a process, a function, etc.) that performs the functions described herein.

[0189] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit system that executes instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuit system without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of those specific embodiments, the processing circuit system may be configured to perform the described functionality regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuit system itself or other components of the computing device, but are generally enjoyed by the computing device as a whole and / or by end users and wireless networks.

[0190] The term "non-transitory" as used herein is a limitation of the medium itself (ie, tangible, not a signal), and not a limitation on data storage persistence (eg, RAM vs. ROM).

[0191] As described in the above exemplary embodiments of the present disclosure, a legitimate STA (non-AP STA or AP) may be a STA that has a successful association (between a non-AP STA and an AP) and exchanges valid device identification information (e.g., ID or RMA), and is able to use the device identification information (e.g., ID or RMA) in (multiple) subsequent associations.

[0192] In order to achieve verification, an embodiment of the present disclosure proposes to define an information element (IE), which contains at least a frame number (FN) and a verification check (VC) to be used in unicast (e.g., probe message, authentication message, association message, action message, etc.) and broadcast (e.g., broadcast probe request, beacon, etc.) management frames. As an example and not a limitation, the embodiment of the present disclosure uses the name "Verification Information Element (VIE)" for the proposed information element.

[0193] In short, when a non-AP STA first associates with an AP (ESS), the non-AP STA and / or the AP obtain device identification information (e.g., ID or RMA). During this first association, the non-AP STA and the AP (ESS) also determine the key to be used for the verification information element (VIE). In (multiple) subsequent associations, the non-AP STA sends unicast management frames (e.g., probe / authentication / association / action requests) and broadcast management frames (e.g., broadcast probe requests) with its own VIE, and the AP sends unicast management frames (e.g., probe / authentication / association / action responses) and broadcast management frames (e.g., beacons) with its own VIE. By doing so, even if an attacker uses the device identification information (e.g., ID or RMA) of the non-AP STA and / or the AP, the non-AP STA and the AP can verify the VIE and identify the attacker.

[0194] Fig.11 is a diagram showing the use of a proposed information element, Authentication Information Element (VIE), and verifying whether a frame is from an authenticated STA or from an attacker.

[0195] like Fig.11 As shown in , the main steps between the non-AP STA and the AP in the embodiment of the present disclosure may include the following steps.

[0196] In step 1, a non-AP STA first associates with an AP (ESS), and the non-AP STA and / or the AP obtain device identification information (eg, ID or RMA).

[0197] In step 2, during the first association, the non-AP STA and the AP determine the key to be used for the proposed authentication information element (VIE). Note that for unicast management frames, the key is determined for each non-AP STA and AP pair, or for all non-AP STA and AP pairs, while for broadcast management frames, the same single key is determined for one or more non-AP STAs and the AP. Therefore, there may be two keys. One key may be for unicast management frames and 4-step HS frames, and the other key may be for broadcast management frames.

[0198] For example, the key may be determined as follows.

[0199] In phase 1), one side generates a key and sends it to the other side - (like IGTK in WiFi). For example, AP generates key = 123 and sends it to STA. For example, STA generates key = 123 and sends it to AP.

[0200] In phase 2), each side uses the other key to generate the same key.

[0201] For example, the STA and the AP have another key (such as PTK), and they derive a key based on the key (PTK).

[0202] In phase 3), one side sends additional information to the other side to generate a key.

[0203] For example, the AP sends a random value (such as Nonce) to the STA, and the STA generates a key based on the random value (Nonce).

[0204] It should be noted that the key derivation function may be any standard function in 802.11 or a non-standard function other than 802.11.

[0205] An example function may be: key = HMAC-SHA256 (PTK, MAC address). That is, the key is calculated based on the HMAC-SHA256 method, and the input parameters may include the PTK and the MAC address.

[0206] Furthermore, the verification information may be generated by a function using a key, additional data, or FN.

[0207] For example, VC=HMAC-SHA256(key, FN, additional data); or VC=HMAC-SHA256(key, additional data).

[0208] For use in connection with broadcast management frames, the key may be shared by one or more STAs, and in particular it may be a stored key, such as a stored IGTK.

[0209] In step 3, in (multiple) subsequent associations (e.g., second associations), the non-AP STA and / or AP use the previously assigned device identification information (e.g., ID or RMA). The non-AP STA sends its own verification information element (VIE) in unicast management frames (e.g., probe, authentication, association request, action frames) and broadcast management frames (e.g., broadcast probe request). The AP verifies the received verification information element (VIE) in the received unicast and broadcast frames, and ensures that the (verified) frame is from a verified STA (i.e., non-AP STA), not from an attacker using the device identification information (e.g., ID or RMA) of the non-AP STA.

[0210] In step 4, when verifying a non-AP STA, the AP sends its own verification information element (VIE) in unicast management frames (e.g., probe, authentication, association response, action frames) and broadcast management frames (e.g., beacons). The non-AP STA verifies the received verification information element (VIE) in the received unicast management frames and broadcast management frames, and ensures (verifies) that these frames are from a verified STA (i.e., AP).

[0211] In an embodiment of the present disclosure, if there is a replay attack (the FN value increases by 1 in each confirmed unicast management frame), verification is performed by checking the frame number (FN) of the VIE, and if the VC of the transmitter and the VC of the receiver match, verification is performed by checking the verification check (VC) of the VIE.

[0212] In an embodiment of the present disclosure, each side (non-AP STA and AP) may need to maintain two counters for FN values; one for request frames and one for response frames.

[0213] According to the embodiments of the present disclosure, the following advantages may be achieved: Using the verification information element (VIE), the AP (ESS) can verify the non-AP STA from the pre-association unicast management request frame (eg, probe / authentication / association / action request).

[0214] In addition, the non-AP STA can authenticate the AP from the pre-association unicast management response frame (eg, Probe / Authentication / Association / Action Response).

[0215] Furthermore, based on the authentication, an attacker (impersonating a non-AP STA or AP) can be immediately identified.

[0216] An embodiment of the present disclosure proposes to define an information element (IE) called "Verification Information Element (VIE)", which contains at least a frame number (FN) and a verification check (VC) field to be used in a unicast management frame (e.g., a probe message, an authentication message, an association message, an action message, etc.) and a broadcast management frame (e.g., a broadcast probe request, a beacon, etc.) to verify a STA (non-AP STA or AP) when device identification information (e.g., ID or RMA) is used for identification purposes, thereby identifying an attacker when the attacker uses the device identification information (e.g., ID or RMA) of a non-AP STA and / or AP. In this context, an attacker can disguise as a non-AP STA or AP.

[0217] The frame format and usage of the Verification Information Element (VIE) (including the Frame Number (FN) and Verification Check (VC) fields) for unicast and broadcast management frames may be described below. An example is given to illustrate the VIE definition for a probe request.

[0218] The construction, transmission and reception of the Verification Information Element (VIE) will be described below.

[0219] In addition, an example of how to detect an attacker with the help of VIE when the attacker uses device identification information (eg, ID or RMA) of a non-AP STA and / or AP will be described.

[0220] In some exemplary embodiments of the present disclosure, each side (STA or AP) may maintain its own FN value. FN may be a fixed initial value (secret sharing). FN may be random (public sharing).

[0221] In some other exemplary embodiments of the present disclosure, both sides maintain a single FN value. FN can be a fixed initial value (secret sharing). FN can be random (public sharing, such as unicast).

[0222] In some exemplary embodiments of the present disclosure, VC is calculated based on a key (VK).

[0223] In some exemplary embodiments of the present disclosure, the VC input parameter does not include FN. In some other exemplary embodiments of the present disclosure, the VC input parameter includes FN.

[0224] VC input parameters may include additional data, such as MAC address, keyID, MAC header field, Nonce, seed, etc.

[0225] Fig.12 is a diagram showing an example of a Authentication Information Element (VIE) and its fields - Frame Number (FN) and Authentication Check (VC).

[0226] Regarding the example of the verification information element (VIE) frame format, the verification information element (VIE) may include at least two fields, namely, Fig.12 The frame number (FN) and verification check (VC) shown in .

[0227] Fig.13a is a diagram illustrating an example of definition for a verification information element (VIE) according to an embodiment of the present disclosure.

[0228] Fig.13b is a diagram illustrating an example of a verification information element (VIE) format according to an embodiment of the present disclosure.

[0229] Currently 802.11REVme_D1.3 defines several information elements (see Table 9-128 in 802.11REVme_D1.3 - Element ID). Fig.13a , Fig.13bAs shown in , the proposed verification information element (VIE) may be Element ID = 255, Element ID Extension = 94, Scalable = No, Fragmentable = No. This IE may have many fields, such as Element, Length Element ID Extension, Frame Number Value, and Verification Check.

[0230] In another embodiment, in addition to the FN and VC fields, the VIE may also contain other fields, such as an ID field (such as a key ID) and an initial FN value.

[0231] Regarding the verification information element (VIE) in the unicast management frame and the broadcast management frame, the verification information element (VIE) can be defined for many unicast management frames and broadcast management frames, including beacons, directed probe requests, broadcast probe requests, probe responses, authentication frames, association messages, reassociation messages, action frames. In order to show an example of defining VIE for a unicast management frame, it can be explained that VIE is defined for a probe request frame. Any other unicast management frame and broadcast management frame can be defined in the same or similar manner.

[0232] Fig.14 is a diagram illustrating a proposed verification information element (VIE) in a probe request according to an embodiment of the present disclosure.

[0233] Currently, 802.11REVme_D1.3 defines 41 items in the probe request frame body (see Table 9.66 in 802.11REVme_D1.3). Fig.14 As shown in , regarding the example of the verification information element (VIE) in the probe request, the proposed verification information element (VIE) order may be Order = 42. This field carries at least the frame number (FN) and verification check (VC) of the verification information element (VIE) used to verify the STA.

[0234] Examples of construction and transmission and reception of verification information elements (VIEs) may be further described.

[0235] The verification information element (VIE) contains at least two fields, namely: frame number (FN) and verification check (VC), such as Fig.12 shown.

[0236] The frame number (FN) may be used for replay protection and may be a non-negative integer that increases monotonically in every broadcast management frame and acknowledged unicast management frame.

[0237] The process for FN can be defined as follows.

[0238] 1-The receiver shall maintain a receive replay counter.

[0239] 2-The receiver shall set the receive replay counter to the value of FN.

[0240] 3- The sender shall set the FN field to a monotonically increasing non-negative integer each time it sends a unicast management frame and / or a broadcast management frame.

[0241] 4-The receiver receives the frame and shall compare the FN value in the received frame with the receive replay counter. If the received FN value is less than or equal to the replay counter value, the receiver shall ignore the frame.

[0242] For the Authentication Check (VC), it may be an encrypted value derived based on the key negotiated between the non-AP STA and the AP (along with additional data).

[0243] The process definition for VC is as follows:

[0244] 1-The transmitter should calculate the VC value using an encryption function based on the key negotiated between the non-AP STA and the AP (along with some other additional information) and send it to the receiver.

[0245] 2-The receiver receives the frame and saves the received VC value.

[0246] 3- The receiver then calculates its own VC value and compares its own VC value with the received VC value. If they match, the receiver accepts the frame, otherwise it discards the frame.

[0247] Fig.15 is a diagram illustrating an example scenario of constructing a VIE.

[0248] The sender (e.g., non-AP STA) and the receiver (e.g., AP) determine the key and initial counter value for FN. The key is used to generate the VC field. When the sender sends the first unicast management frame, it inserts the negotiated initial FN value ( Fig.15 100) and the calculated VC value ( Fig.15 In each unicast management frame, the sender increases the FN value (for the second unicast management frame, FN=101), and the receiver tracks the FN value to perform replay protection. In addition, in each frame, a new VC value is inserted into VIE (for the second unicast management frame, VC=a2b2). It should be noted that such verification information can also be used in broadcast management frames.

[0249] In one embodiment, the FN and VC values ​​may be encrypted again for added protection. As an example, the sender and receiver may use a hash function based on another key to encrypt the FN and VC values. In this case, for example, the original FN value (100) becomes a hashed FN value (e.g., 697), and the original VC value (a1b1) becomes a hashed VC value (e.g., aBcD). Since only the sender and receiver have the key for the hash, only they can decrypt these fields to their original values.

[0250] In another embodiment, the transmitter and the receiver may set an initial value for the FN field for the replay counter.

[0251] In another embodiment, one of the input parameters of the VC generation function may be a FN value.

[0252] In another embodiment, the additional data used for VC generation may include at least public information (such as fields in a MAC header, a public key, a public ID, and a public signature) and private information (such as a private key, a private ID, and a private signature).

[0253] Regarding the example of detecting an attacker via the use of a Verification Information Element (VIE), the information implementation of the use of the VIE and the detection of an attacker may be illustrated. In this regard, the following example may be given.

[0254] Fig.16 is a diagram illustrating an example scenario of use of VIE[FN, VC] and attacker detection according to an embodiment of the present disclosure.

[0255] For purposes of illustration and not limitation, an example scenario (e.g. Fig.16 ) may include the following steps mainly related to unicast management frames. However, it should be noted that such verification information may also be used in broadcast management frames.

[0256] In step 1: non-AP STA (in the first association) associates with AP with AP_MAC using its STA_MAC address and is assigned device identification information: STA_RMA1. AP is also assigned device identification information: AP_RMA1.

[0257] In step 2: the non-AP STA and the AP determine a key (key1) and two initial frame number (FN) values ​​(FN=100 for the AP side and FN=200 for the STA side). Key1, FN=100 and FN=200 will not be disclosed outside the non-AP STA and the AP.

[0258] The non-AP STA disconnects after a period of time.

[0259] In step 3: the non-AP STA wants to associate with the AP again (in the second association) using the previously allocated (from the first association) device identification information (STA_RMA1). The AP also uses its own device identification information AP_RMA1 in the second association.

[0260] In sub-step I, the non-AP STA starts sending unicast management frames (eg, probe requests) with its device identification information (STA_RMA1) and verification information element (VIE).

[0261] To construct the VIE, the non-AP STA starts the frame number (FN) field at 100 (the initial value determined previously) and increases it by 1 for each frame (101, 102, etc.). The non-AP STA generates the verification check (VC) field based on the previously determined key (key1) and additional data. The VC field is also regenerated in each frame.

[0262] As an example, the first probe request frame is [FN=100, VC=a1b1] and the second probe request frame is [FN=101, VC=a2b2].

[0263] In sub-step II. For each received unicast management frame (probe request), the AP checks the FN and VC fields.

[0264] For FN, the AP knows the initial value (100). This means that it expects the initial FN field of the initial frame to be 100, and the next FN field to be 101. For VC, the AP generates its own VC field (called VC') and verifies that the value matches the VC value of the received frame. Note that since the AP has the same key (key1) and uses the same formula as the non-AP STA, it can generate the same VC field. If the values ​​match, the AP recognizes that the frames are from a verified non-AP STA.

[0265] In this example, the AP receives the first probe request frame with [FN=100, VC=alb1]. FN matches the initial determined value. The AP also generates its own VC value VC'=alb1 based on the key (key1) that matches the received VC=alb1. Therefore, the first probe request is considered valid.

[0266] The AP also sends its unicast management frame (i.e., the first probe response) using its own VIE. In this example, for the first probe response frame, the VN is constructed as [FN=200, VC=x1y1]. After the non-AP STA receives the frame, it checks the FN and VC values ​​and determines that it is a valid frame.

[0267] The AP receives the second probe request frame as [FN=101, VC=a2b2]. Similarly, the FN of the received frame matches the AP's counter value. Moreover, the AP's generated VC value (VC'=a2b2) also matches the VC field of the received frame. This frame is also considered valid. In addition, the AP also sends a second probe response using [FN=201, VC=x2y2], and this frame is determined to be valid on the non-AP side.

[0268] In step 4: the attacker listens to the probe request frame from the non-AP STA and calculates the device identification information (STA_RMA1) of the non-AP STA. At this time, the attacker uses the device identification information (STA_RMA1) of the non-AP STA to send an authentication request to the AP. As an example, in this context, there may be three possible attack methods.

[0269] In attack 1, the attacker sends the same probe request as the non-AP STA sent before (using the same FN and VC fields, ie, [FN=100, VC=a1b1]).

[0270] When the AP receives this frame, it recognizes that the received frame is using FN = 100. This value has been used before (by a non-APSTA), so the AP rejects the authentication request (unauthenticated frame). Note that the AP expects unicast management frames with FN = 102 based on its counters.

[0271] In attack 2, the attacker sends the correct FN number expected by the AP [FN=102] (note that the attacker can eavesdrop on unicast management frames (e.g., probe requests) sent from non-AP STAs and calculate the correct FN value if the FN value is not protected, as is the case in this example) and the previously used (e.g., first probe) VC value [VC=a1b1].

[0272] When the AP receives the frame, the FN value of the received frame matches. However, the VC value [VC=a1b1] of the received frame was previously used (by the non-AP STA) with FN=100.

[0273] Therefore, the AP rejects the authentication request (unauthenticated frame).

[0274] In attack 3, the attacker sends the correct FN number expected by the AP [FN=102] (note that the attacker can eavesdrop on the unicast management frames sent from the non-AP STA and calculate the correct FN value if the FN value is not protected, as is the case in this example) and a self-generated VC value [VC=xxx].

[0275] When the AP receives the frame, the FN value of the received frame matches. However, the VC value of the received frame [VC=xxx] does not match the VC value (VC') generated by the AP. Since the VC fails, the AP rejects the authentication request (unauthenticated frame). Note that since the attacker does not know the key (key1) and / or the calculation formula, it is almost impossible for the attacker to generate a VC that will match the AP's VC (VC').

[0276] For example, to improve privacy and security, the key and / or calculation formula may be designed to be extremely difficult for an attacker to obtain or decrypt (eg, relatively long and / or complex).

[0277] Fig.17a is a diagram illustrating a first example scenario regarding an increase in a frame number value.

[0278] like Fig.17a As shown, the same initial frame number value "100" is used for frames from both the first device and the second device. The frame number will increase with each frame in the frames sent. Therefore, frame 1 (from STA) has frame number 100, frame 2 (from AP) has frame number 101, frame 3 (from STA) has frame number 102, and frame 4 (from AP) has frame number 103.

[0279] In addition, each frame may include Fig.17a The specific validation check fields shown in .

[0280] Fig.17b is a diagram illustrating a second example scenario regarding an increase in frame number values.

[0281] like Fig.17b As shown, a first initial frame number value of "100" is used for frames from STAs, and a second initial frame number value of "200" is used for frames from APs. The frame number will increase with each frame in the transmitted frame. Therefore, frame 1 (from STA) has frame number 100, frame 2 (from AP) has frame number 200, frame 3 (from STA) has frame number 101, and frame 4 (from AP) has frame number 201.

[0282] In addition, each frame may include Fig.17b The specific validation check fields shown in .

[0283] Fig.17cis a diagram illustrating a third example scenario regarding an increase in a frame number value.

[0284] like Fig.17c As shown, in the second association (Ass), the first initial frame number value "100" is used for frames from STA, and the second initial frame number value "200" is used for frames from AP. The frame number will increase with each frame sent. Therefore, frame 1 (from STA) has frame number 100, frame 2 (from AP) has frame number 200, frame 3 (from STA) has frame number 101, and frame 4 (from AP) has frame number 201.

[0285] Subsequently, a disconnection may occur between the STA and the AP.

[0286] The initial frame number value will be reset as in the previous connection.

[0287] Therefore, in the third association, frame 1 (from STA) has frame number 100, frame 2 (from AP) has frame number 200, frame 3 (from STA) has frame number 101, and frame 4 (from AP) has frame number 201.

[0288] In addition, each frame may include specific authentication check fields, such as Fig.17c as shown in .

[0289] Fig.17d is a diagram illustrating a fourth example scenario regarding an increase in a frame number value.

[0290] like Fig.17d As shown, in the second association (Ass), the first initial frame number value "100" is used for the frame from the STA, and the second initial frame number value "200" is used for the frame from the AP. The frame number will increase with each frame in the transmitted frame. Therefore, frame 1 (from the STA) has a frame number of 100, frame 2 (from the AP) has a frame number of 200, frame 3 (from the STA) has a frame number of 101, and frame 4 (from the AP) has a frame number of 201.

[0291] Subsequently, a disconnection may occur between the STA and the AP.

[0292] The initial frame number value will be reset to be different from the previous connection, which can be 500, 600.

[0293] Therefore, in the third association, frame 1 (from STA) has frame number 500, frame 2 (from AP) has frame number 600, frame 3 (from STA) has frame number 501, and frame 4 (from AP) has frame number 601.

[0294] In addition, each frame may include Fig.17d The specific validation check fields shown in .

[0295] Fig.17e is a diagram illustrating a fifth example scenario regarding an increase in frame number value.

[0296] like Fig.17e As shown in FIG. 1 , in the second association (Ass), a first initial frame number value of "100" is used for frames from STAs, and a second initial frame number value of "200" is used for frames from APs. The frame number will increase with each frame in the transmitted frames. Therefore, frame 1 (from STA) has frame number 100, frame 2 (from AP) has frame number 200, frame 3 (from STA) has frame number 101, and frame 4 (from AP) has frame number 201.

[0297] Subsequently, a disconnection may occur between the STA and the AP.

[0298] The initial frame number value and the current frame number value may not be reset but may be stored.

[0299] Therefore, successively, in the third association, frame 1 (from STA) has frame number 102 , frame 2 (from AP) has frame number 202 , frame 3 (from STA) has frame number 103 , and frame 4 (from AP) has frame number 203 .

[0300] In addition, each frame may include Fig.17e The specific validation check fields shown in .

[0301] Therefore, according to an exemplary embodiment of the present disclosure, non-AP STA and AP should ensure (verify) that unicast management frames (e.g., probe request / response, authentication request / response, association request / response) are from a verified STA (non-AP STA or AP) in order to avoid messages from an attacker. In this context, an embodiment of the present disclosure proposes to define an information element (IE) to be included in a unicast management frame (e.g., a probe message, an authentication message, an association message, an action message, etc.), which is to be used so that non-AP STA and AP will ensure that these frames are from a verified STA (non-AP STA or AP), thereby avoiding the mentioned possible replay and evil twin attacks. In particular, the information element may contain at least a frame number (FN) and a verification check (VC).

[0302] It should be understood that the above embodiments are only for illustration and not limitation. Without departing from the basic characteristics of the present disclosure, the present disclosure can be performed in other ways except those specifically set forth herein. All changes to these embodiments that do not depart from the meaning and equivalents of the appended claims are intended to be included herein.

[0303] References

[0304] 802.11REVme_D1.3, Reference: IEEE P802.11-REVme TM / D1.3, June 2022, Draft Standard for Information technology-Telecommunications and information exchange between systems Local and metropolitan area networks-Specific requirements / D1.3, June 2022, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, prepared by the 802.11 Working Group of the LAN / MAN Standards Committee of the IEEE Computer Society.

[0305] [22 / 187r2], Reference: IEEE 802.11-22 / 0187r2, Network generated device ID, Date: 2022-03-10, Jouni Malinen, Qualcomm

[0306] [22 / 925r2], Reference: IEEE 802.11-22 / 0925r2, Proposed Text for MAAD for TGbh Draft 0.2, Date: 2022-07, Graham SMITH (SRT Wireless)

[0307] [22 / 895r1], Reference: IEEE 802.11-22 / 0895r1, Proposed Text for Identifiable Random MAC, IRM-3, Date: 2022-06, Graham SMITH (SRT Wireless)

[0308] [22 / 888r2], Reference: IEEE 802.11-22 / 0888r2, Rule-based random MAC STA identification (RRCM), Date: 2022-06-12, Orhan OkanMutgan, Nokia, et al.

[0309] [22 / 158r3], Reference: IEEE 802.11-22 / 0158r3, STA generated Device ID, Date: 2022-02-08, Jouni Malinen, Qualcomm, Inc.

[0310] [22 / 114r3], Reference: IEEE 802.11-22 / 0114r3, Enhanced Randomized and Changing MAC address (ERCM), Date: 2022-05-10, Stéphane Baron, Canon, et al.

[0311] Abbreviation Explanation

[0312] AP Access Point

[0313] FTM fine timing measurements

[0314] IE Information Element

[0315] PMK Pairwise Master Key

[0316] PTK Pairwise Temporary Key

[0317] RCM randomly changes MAC

[0318] RMA Random MAC Address

[0319] STA Station

[0320] ESS Extended Service Set

[0321] MAAD MAC address assignment

[0322] IRMA can identify random MAC addresses

[0323] RRCM randomly changes MAC addresses based on rules

[0324] FN frame number

[0325] VC Verification

[0326] VIE Verification Information Elements

[0327] 4-step HS 4-step handshake

[0328] ID Identifier

[0329] IGTK Integrity Group Temporal Key

Claims

1. A method (60) performed by a first device, include: During a first association with a second device, obtaining (S602) identification information for the first device; During said first association, determining (S604) one or more parameters for verification; Based at least on the one or more parameters, determining (S606) first verification information; and transmitting (S608) a first message for performing a second association with the second device; The first message includes the identification information for the first device and the first verification information.

2. The method (60) according to claim 1, The identification information includes at least one of the following: an identifier ID and a random medium access control address RMA.

3. The method (60) according to claim 1 or 2, wherein the one or more parameters used for verification include at least one of the following: a key shared by the first device and the second device, a first initial frame number value, and a second initial frame number value; wherein the first initial frame number value is the same as the second initial frame number value, or is different from the second initial frame number value; and The first initial frame number value is for a frame sent from the first device to the second device, and the second initial frame number value is for a frame sent from the second device to the first device.

4. The method (60) according to claim 3, wherein at least one of the first initial frame number value and the second initial frame number value has a fixed value, and the fixed value is secretly shared between the first device and the second device; or At least one of the first initial frame number value and the second initial frame number value has a random value, and the random value is publicly shared.

5. The method (60) according to claim 3, The first verification information includes a first frame number value and a first verification check field; wherein the first device operates a first counter to determine the first frame number value based on the first initial frame number value and the number of frames transmitted from the first device to the second device before the first message, or based on the first initial frame number value and the number of frames exchanged by the first device and the second device before the first message; The first verification check field is determined using a formula shared between the first device and the second device based on at least the key.

6. The method (60) according to claim 5, The first verification check field is also determined based on the first frame number value.

7. The method (60) according to any one of claims 5 to 6, wherein the first verification check field is further determined based on additional data related to at least one of the first message, the first device, and the second device; The additional data includes at least one of the following: public information, private information; The public information includes at least one of the following: a field in a media access control header, a public key, a public ID, a random number, and a public signature; and The private information includes at least one of the following: a private key, a private ID, a private signature, or a random number.

8. The method (60) according to any one of claims 5 to 7, The first frame number value and the first verification information are encrypted in the first message.

9. The method (60) according to any one of claims 1 to 8, The first message includes a unicast management frame or a broadcast management frame.

10. The method (60) according to claim 9, The first message includes at least one of the following: a probe request, an authentication frame sent from the first device, an association request, and an action frame.

11. The method (60) according to any one of claims 1 to 10, further comprising: include: receiving (S610) a second message, the second message including identification information for the first device and / or the second device and second verification information; The second verification information includes a second frame number value and a second verification check field.

12. The method (60) according to claim 11, further comprising: include: Determining (S612) a third frame number value and a third verification check field; comparing (S614) the third frame number value with the second frame number value, and the third verification check field with the second verification check field; as well as Determining (S616) that the second message is from an attacker based on at least one of the following: whether the third frame number value is greater than the second frame number value, wherein the third frame number value is determined based on a frame number value successfully received in a previous frame; whether the third frame number value is not equal to the second frame number value, wherein the third frame number value is determined based on the second initial frame number value and the number of frames exchanged by the first device and the second device before the second message; or whether the third verification check field is not equal to the second verification check field; wherein the third frame number value is determined by the first counter based on a frame number value successfully received in a previous frame, or based on the second initial frame number value and the number of frames exchanged by the first device and the second device before the first message; The third verification check field is determined using a formula shared between the first device and the second device based on at least one of the key or the third frame number value.

13. The method (60) of claim 11 or 12, wherein the second frame number value and the second authentication information are encrypted in the second message.

14. The method (60) of any one of claims 11 to 13, wherein the second message comprises a unicast management frame.

15. The method (60) of claim 14, wherein the second message comprises at least one of: a probe response, an authentication frame sent from the second device, an association response, or an action frame.

16. The method (60) according to any one of claims 1 to 15, Wherein the first device comprises a non-APSTA or an access point AP in a wireless local area network operating according to the 802.11 standard; and The second device includes an AP or a non-AP STA in the wireless local area network.

17. A method (70) performed by a second device, include: During a first association with a first device, obtaining (S702) identification information for the first device; During said first association, determining (S704) one or more parameters for authentication; as well as receiving (S706) a first message for performing a second association with the first device; The first message includes the identification information and first verification information for the first device.

18. The method (70) according to claim 17, The identification information includes at least one of the following: an identifier ID, or a random media access control address RMA.

19. The method (70) according to claim 17 or 18, wherein the one or more parameters used for verification include at least one of the following: a key shared by the first device and the second device, a first initial frame number value, and a second initial frame number value; wherein the first initial frame number value is the same as the second initial frame number value, or is different from the second initial frame number value; and The first initial frame number value is for a frame sent from the first device to the second device, and the second initial frame number value is for a frame sent from the second device to the first device.

20. The method (70) according to claim 19, wherein at least one of the first initial frame number value and the second initial frame number value has a fixed value, and the fixed value is secretly shared between the first device and the second device; or At least one of the first initial frame number value and the second initial frame number value has a random value, and the random value is publicly shared.

21. The method (70) according to claim 19, The first verification information includes a first frame number value and a first verification check field.

22. The method (70) of claim 20, further comprising: include: Determining (S708) a fourth frame number value and a fourth verification check field; comparing (S710) the fourth frame number value with the first frame number value, and the fourth verification check field with the first verification check field; as well as Determining (S712) that the first message is from an attacker based on at least one of the following: whether the fourth frame number value is greater than the first frame number value, wherein the fourth frame number value is determined based on a frame number value successfully received in a previous frame; whether the fourth frame number value is not equal to the first frame number value, wherein the fourth frame number value is determined based on the first initial frame number value and the number of frames exchanged by the first device and the second device before the first message; or whether the fourth verification check field is not equal to the first verification check field; wherein the fourth frame number value is determined by a second counter based on a frame number value successfully received in a previous frame, or based on the first initial frame number value and the number of frames exchanged by the first device and the second device before the first message; Wherein the fourth verification check field is determined based on at least the key using a formula shared between the first device and the second device.

23. The method (70) according to claim 22, The fourth verification check field is also determined based on the fourth frame number value.

24. The method (70) according to any one of claims 22 to 23, wherein the fourth verification check field is further determined based on additional data associated with at least one of the first message, the first device, or the second device; The additional data includes at least one of the following: public information, private information; The public information includes at least one of the following: a field in a media access control header, a public key, a public ID, a random number, or a public signature; and The private information includes at least one of the following: a private key, a private ID, a private signature, and a random number.

25. The method (70) of any one of claims 20 to 24, wherein the first frame number value and the first authentication information are encrypted in the first message.

26. The method (70) of any one of claims 17 to 25, wherein the first message comprises a unicast management frame or a broadcast management frame.

27. The method (70) of claim 26, wherein the first message comprises at least one of: a probe request, an authentication frame sent from the first device, an association request, or an action frame.

28. The method (70) according to any one of claims 17 to 27, further comprising: include: transmitting (S714) a second message, wherein the second message includes identification information for the first device and / or the second device and second verification information; The second verification information includes a second frame number value and a second verification check field; wherein the second device operates a second counter to determine the second frame number value based on the second initial frame number value and the number of frames transmitted from the second device to the first device before the second message, or based on the second initial frame number value and the number of frames exchanged by the first device and the second device before the second message; and The second verification check field is determined based on at least one of the key or the second frame number value using a formula shared between the first device and the second device.

29. The method (70) according to claim 28, The second frame number value and the second verification information are encrypted in the second message.

30. The method (70) according to claim 28 or 29, The second message includes a unicast management frame or a broadcast management frame.

31. The method (70) according to any one of claims 28 to 30, The second message includes at least one of the following: a probe response, an authentication frame sent from the second device, an association response, or an action frame.

32. The method (70) according to any one of claims 17 to 31, The first device comprises a non-APSTA or an access point AP in a wireless local area network operating according to the 802.11 standard; and The second device includes an AP or a non-AP STA in the wireless local area network.

33. A first device (80), comprising a component (800), wherein the component (800) is configured to: During a first association with a second device, obtaining identification information for the first device; During said first association, determining one or more parameters for authentication; determining first verification information based at least on the one or more parameters; as well as transmitting a first message for making a second association with the second device; The first message includes the identification information for the first device and the first verification information.

34. The first device (80) according to claim 33, wherein the component (800) is further configured to perform the method according to any one of claims 2 to 16.

35. The first device (80) according to claim 33 or 34, wherein the component (800) include: at least one processor (802); as well as At least one memory (804) stores instructions that, when executed by the at least one processor (802), cause execution of the first device (80).

36. A second device (81), comprising a component (810), wherein the component (810) is configured to: During a first association with a first device, obtaining identification information for the first device; During said first association, determining one or more parameters for authentication; and receiving a first message for performing a second association with the first device; The first message includes the identification information and first verification information for the first device.

37. The second device (81) according to claim 36, wherein the component (810) is further configured to perform the method according to any one of claims 18 to 32.

38. The second device (81) according to claim 36 or 37, wherein the component (810) include: at least one processor (812); as well as At least one memory (814) storing instructions which, when executed by the at least one processor (812), cause execution of the second means (81).

39. A computer-readable storage medium (90) storing instructions (91), which, when the instructions (91) are executed by at least one processor of a first device, cause the at least one processor of the first device to execute a method according to any one of claims 1 to 16; or, when the instructions (91) are executed by at least one processor of a second device, cause the at least one processor of the second device to execute a method according to any one of claims 17 to 32.

Images