Communication method and related apparatus

Abstract

The present application relates to the technical field of wireless communications, and provides a communication method and a related apparatus. The communication method is applied to a non-AP side, and comprises: sending a first request to a first station (AP) or a second AP, wherein the first AP is an AP currently associated with the non-AP, the first request is used for requesting roaming from the first AP to the second AP, the first request comprises key information, and the key information is used for the first AP to query a key; and when the first AP queries the key, receiving a first request response sent by the first AP or the second AP.

Description

Communication methods and related devices Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a communication method and related apparatus. Background Technology

[0002] In wireless communication systems such as Wi-Fi, which conform to the Institute of Electrical and Electronics Engineers (IEEE) 802.11bn (Wi-Fi 8) and later standards, how to ensure the security of the security context information between the STA and the Current AP when the STA moves between the signal coverage areas of two access points (APs) within the same ESS, and seamlessly roams from the current Current AP to the target AP, is a topic worthy of discussion. Summary of the Invention

[0003] This application provides a communication method and related apparatus to ensure and improve the security of the roaming process.

[0004] To achieve the above objectives, this application adopts the following technical solution:

[0005] The first aspect of this application provides a communication method applied to a non-AP side, comprising: sending a first request to a first AP or a second AP, wherein the first AP is an AP currently associated with the non-AP, the first request is used to request roaming from the first AP to the second AP, the first request includes key information, the key information being used by the first AP to query a key; and when the first AP queries the key, receiving a first request response sent by the first AP or the second AP.

[0006] A second aspect of this application provides a communication method applied to a first access point (AP), comprising: receiving key information sent by a non-AP or a second AP, wherein the first AP is associated with the non-AP and the second AP is the destination AP for which the non-AP requests roaming; querying a key based on the key information, wherein the result of the key query is used to indicate whether roaming was successful.

[0007] A third aspect of this application provides a communication method applied to a second access point (AP), comprising: receiving a key sent by a first AP; communicating with a non-AP based on the key or a processed version of the key, wherein the first AP is associated with the non-AP, and the second AP is the destination AP for which the non-AP requests roaming.

[0008] A fourth aspect of this application also provides a wireless communication device, including: a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to perform the method as described in any of the preceding embodiments.

[0009] A fifth aspect of this application also provides a computer-readable storage medium, the computer-readable storage medium including instructions that, when executed, cause the method described in any of the preceding claims to be implemented. Attached Figure Description

[0010] Figure 1a shows a possible WLAN roaming network topology;

[0011] Figure 1b shows a possible seamless roaming architecture;

[0012] Figure 1c shows another possible WLAN roaming network diagram;

[0013] Figure 1d is a schematic diagram of a possible fast roaming process;

[0014] Figure 1e is a schematic diagram of another possible fast roaming process;

[0015] Figure 1f is a schematic diagram of another possible fast roaming process;

[0016] Figure 1g is a schematic diagram of another possible fast roaming process;

[0017] Figure 2A is a possible communication flowchart provided in an embodiment of this application;

[0018] Figure 2A-1 is a possible frame structure diagram provided in an embodiment of this application;

[0019] Figure 2A-2 is another possible frame structure diagram provided in the embodiment of this application;

[0020] Figures 2A-3 are another possible frame structure diagrams provided in the embodiments of this application;

[0021] Figure 2B is another possible communication flowchart provided in an embodiment of this application;

[0022] Figure 2B-1 is another possible frame structure diagram provided in the embodiment of this application;

[0023] Figure 2B-2 is another possible frame structure diagram provided in the embodiment of this application;

[0024] Figures 2B-3 are another possible frame structure diagrams provided in the embodiments of this application;

[0025] Figure 3A is another possible communication flowchart provided in an embodiment of this application;

[0026] Figure 3B is another possible communication flowchart provided in an embodiment of this application;

[0027] Figure 3C is another possible communication flowchart provided in an embodiment of this application;

[0028] Figure 4A is another possible communication flowchart provided in an embodiment of this application;

[0029] Figure 4A-1 is a diagram of a possible encryption / decryption process;

[0030] Figure 4A-2 shows another possible encryption / decryption process;

[0031] Figure 4B is another possible communication flowchart provided in an embodiment of this application;

[0032] Figure 5A is another possible communication flowchart provided in an embodiment of this application;

[0033] Figure 5B is another possible communication flowchart provided in an embodiment of this application;

[0034] Figure 5C is another possible communication flowchart provided in an embodiment of this application;

[0035] Figure 6 is a schematic diagram of the storage of a possible wireless communication device provided in an embodiment of this application. Detailed Implementation

[0036] For ease of understanding, the relevant technologies involved in the embodiments of this application will be described below.

[0037] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0038] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should be noted that the naming of the parameters in this document is for ease of description; other names may be used in practice, and this application does not impose any restrictions on their specific use.

[0039] The messages described in this article include frames, instructions, commands, etc., and the names of device or functional entities, process names, frames, fields, etc. are not unique and are only used to assist in the description of functions, methods, behaviors, information, etc.

[0040] WLAN roaming refers to the behavior of a STA moving between the coverage areas of different APs belonging to the same Extended Service Set (ESS) while maintaining uninterrupted user services. As shown in Figure 1a, the STA maintains uninterrupted service when moving from the coverage area of ​​AP_1 to the coverage area of ​​AP_2. WLAN roaming has the following characteristics: 1. It ensures that the user's IP address remains unchanged, allowing access to the network associated with the initial connection after roaming, and the services that can be performed remain unchanged; 2. It avoids data packet loss or even service interruption caused by excessively long user authentication times during roaming.

[0041] WiFi 7 incorporates an MLO mechanism, as shown in Figure 1a. However, WiFi 7 only allows communication between one AP MLD and one non-AP MLD using multiple links. If the non-AP MLD is far from AP MLD 1, it needs to disconnect from AP MLD 1 and re-establish authentication and association with AP MLD 2. This process will result in link interruption, making seamless roaming impossible.

[0042] Currently, Wi-Fi 8, when discussing seamless roaming, introduces the concept of a Single Mobility Domain (SMD), which supports seamless roaming between different AP MLDs within the same SMD for mobile non-AP multilink devices (MLDs). An SMD can also be called a single mobility domain or something else; this application does not limit the specific terminology. An SMD is defined as multiple AP MLDs within the same Extended Service Set (ESS) forming a virtual SMD architecture. Under this SMD architecture, when a non-AP MLD is associated with one of the AP MLDs, seamless roaming between different AP MLDs within that SMD can be achieved.

[0043] In WiFi 8, there are two main technical approaches to the roaming process: roaming based on Multi-Link Operation (MLO) and roaming based on Fast Basic Service Set Transition (FT), as detailed below:

[0044] 1. Roaming based on MLO

[0045] WiFi 8 avoids the authentication association operation of switching AP MLDs during the movement of non-AP MLDs by defining new Mobility Domains and sharing keys of non-AP MLDs. Currently, WiFi 8 proposes to achieve seamless roaming only through link reconfiguration (establishing a new link with the Target AP MLD and disconnecting the link with the Current AP MLD).

[0046] As shown in Figure 1b, AP MLD 1 and AP MLD 2 belong to a Single Mobility Domain. Within this Single Mobility Domain, a non-AP MLD only needs to authenticate and associate with any one of the AP MLDs. Then, the AP MLDs in the Single Mobility Domain can share their relevant keys with other AP MLDs via a DS (backhaul, or secure channel). (Initial association to an SMD establishes a security context (PMKSA, PTKSA) which applies across all AP MLDs of the SMD). Therefore, when a non-AP MLD moves, it does not need to undergo the authentication and association process with the Target AP MLD again; a link is established directly.

[0047] 2. FT-based roaming

[0048] The 802.11r protocol defines a feature within the same Mobility Domain (MD) that eliminates the need for 802.1X authentication and key negotiation during user roaming through the FT (Fixed Wire) function. This reduces the number of information exchanges, resulting in low latency of service data streams during roaming, ensuring users experience no service interruption and improving their internet browsing experience. Another roaming technology approach in WiFi 8 enhances the FT process defined in 802.11r. This involves defining FT probe request / response frames, where the non-AP MLD exchanges FT probe request / response frames with the current AP MLD to obtain information about nearby AP MLDs. Therefore, the non-AP MLD does not need to switch channels to probe for nearby APs. Furthermore, it defines a context transmission request / response to enable context transmission.

[0049] Another possible improvement is to define new frames to implement multilink setup and trigger context transmission (including reassociation services), for example: define FT multilink setup request / response frames to implement link setup, and define roaming request / response frames to invoke reassociation services.

[0050] It should be noted that the current roaming processes for the two technical approaches mentioned above are only possible, but the transfer or negotiation of security context during roaming still needs to be addressed. Therefore, a security context handling method needs to be proposed to ensure the security of the entire system during roaming.

[0051] To facilitate a better understanding of this solution, the existing technologies that may be involved in this solution will be briefly described below.

[0052] I. Master Key (PMK) Roaming

[0053] Understandably, roaming handover time is a core metric affecting the user experience during wireless roaming. When users employ security policies such as WPA2-802.1X, WPA3-802.1X-AES, or WPA-WPA2-802.1X, and the client selects WPA2 authentication, and the STA supports fast roaming technology, users do not need to complete the 802.1X authentication process again during roaming; they only need to complete the key negotiation process. Thus, through PMK fast roaming, roaming latency for 802.1X users can be shortened, improving the user's internet experience. PMK fast roaming is implemented using paired PMK caching technology. As shown in Figure 1c, the implementation principle of PMK fast roaming is as follows:

[0054] 1. When the STA first accesses the Internet through AP_1, after the STA and AC_1 successfully authenticate and generate a PMK, the STA and AC_1 respectively save the PMK information. Each PMK information corresponds to a PMK-ID. The PMK-ID is calculated from the PMK, SSID, STA's MAC address and Basic Service Set (BSS) identification information ID. AC_1 synchronizes the PMK information to AC_2 through the AC inter-AC tunnel.

[0055] 2. When the STA initiates a reassociation request to AP_2 during roaming, the reassociation request frame contains PMK-ID information.

[0056] 3. After receiving the request, AP_2 promptly notifies AC_2 of the user handover message.

[0057] 4. AC_2 searches for the PMK corresponding to the STA in the PMK cache table based on the PMK-ID information carried by the STA. If the PMK is found, it is assumed that the STA has already performed 802.1X authentication, and the authentication process is skipped directly. The cached PMK is used to start key negotiation.

[0058] II. 802.11r Fast BSS Transition (FT) Roaming

[0059] The 802.11r protocol defines a fast roaming mechanism within the same Mobility Domain (MD) that eliminates the need for 802.1X authentication and key negotiation during user roaming through the Financial Wire (FT) function. This reduces the number of information exchanges, resulting in low latency of service data flow during roaming, ensuring users do not experience service interruption and improving their internet experience. According to the protocol standard definition, 802.11r fast roaming includes two modes: 1) Over-the-Air mode, where the STA directly performs FT authentication with the FAP (AP_2); 2) Over-the-DS mode, where the STA performs FT authentication with the FAP (AP_2) through the HAP (AP_1). The 802.11r fast roaming process within an AC includes the following steps:

[0060] 1. When the STA first accesses the network through AP_1, the STA successfully authenticates with the AC and generates a PMK.

[0061] a. The AC generates PMK-R0 (calculated from SSID, MDID, AC's MAC address and STA's MAC address) and PMK-R1 for each AP (calculated from PMK-R0, AP's MAC address and STA's MAC address) based on PMK, and then sends PMK-R1 to AP_1.

[0062] b.STA and AC generate and install a Pairwise Transit Key (PTK) and a Group Temporal Key (GTK) through a four-way handshake and a two-way handshake for key negotiation, respectively. If it is an open system authentication, no PMK will be generated.

[0063] 2. During roaming, STA initiates an FT authentication request to AP_2 and sends PMK-R1 to AP_2.

[0064] 3. After receiving the request, AP_2 generates and installs PTK based on the information contained therein and PMK-R1, and starts the reassociation timer to send an 802.11FT authentication response to STA.

[0065] In the case of 802.1X authentication, during the FT authentication process, if the AP does not cache the user's PMK information, the AP will report the authentication information to the AC and wait for the AC to process it. If the AP has cached the user's PMK information and it matches the information carried in the terminal authentication request, the AP will not report the authentication information to the AC.

[0066] If it is an open system authentication or PSK authentication, the AP will not report the authentication information to the AC.

[0067] 4. After receiving the response, the STA generates and installs the PTK based on the information contained therein. The STA then sends a reassociation request to AP_2.

[0068] 5. After receiving the reassociation request, AP_2 closes the reassociation timer and sends a reassociation response to the STA. If the AC has configured a STA blacklist or whitelist, during the FT reassociation process, the AP will first send a reassociation response to the STA, then report the STA's reassociation request to the AC, and wait for the AC to process it.

[0069] 6. After receiving the response, the STA completes the roaming process.

[0070] The specific process of using the Over-the-Air method for fast 802.11r roaming within the AC is shown in Figure 1d, and the process of using the Over-the-DS method for fast 802.11r roaming within the AC is shown in Figure 1e.

[0071] Additionally, the 802.11r fast roaming process between ACs is as follows:

[0072] 1. When the STA first accesses the network through AP_1, the STA successfully authenticates with AC_1 and generates PMK.

[0073] a. AC_1 generates PMK-R0 (calculated from SSID, MDID, AC's MAC address and STA's MAC address) and PMK-R1 corresponding to AP_1 (calculated from PMK-R0, AP's MAC address and STA's MAC address) based on PMK, and sends PMK-R1 to AP_1.

[0074] b.STA and AC generate and install PTK and GTK respectively through a four-way handshake and a two-way handshake of key negotiation.

[0075] c. AC_1 synchronizes PMK information to AC_2 through the AC-AC tunnel.

[0076] d.AC_2 generates PMK-R0 and the corresponding PMK-R1 for AP_2 based on PMK, and then sends PMK-R1 to AP_2.

[0077] If it is an open system authentication, PMK will not be generated.

[0078] During roaming, STA initiates an FT authentication request to AP_2.

[0079] 2. After receiving the request, AP_2 generates and installs PTK based on the information contained therein and PMK-R1, and starts the reassociation timer to send an 802.11FT authentication response to STA.

[0080] 3. After receiving the response, the STA generates and installs the PTK based on the information contained therein. The STA then sends a reassociation request to AP_2.

[0081] 4. After receiving the reassociation request, AP_2 closes the reassociation timer and sends a reassociation response to the STA. If the AC has configured a STA blacklist or whitelist, during the FT reassociation process, the AP will send a reassociation response to the STA, then report the STA's reassociation request to the AC and wait for the AC to process it.

[0082] 5. After receiving the response, the STA completes the roaming process.

[0083] The specific process of fast 802.11r roaming between ACs using the Over-the-Air method is shown in Figure 1f, and the process of fast 802.11r roaming between ACs using the Over-the-DS method is shown in Figure 1g. These will not be elaborated upon in this application.

[0084] However, existing technologies have a number of problems, including: 1. Large interaction latency in PMK fast roaming: In PMK fast roaming, PMK is shared between ACs. After the STA roams to the Target AP, the Target AP needs to request PMK from the Target centralized control device AC, and then perform a four-way handshake between the STA and the Target AP to achieve key negotiation. However, these interactions introduce large latency, which cannot meet the requirement of WiFi 8 seamless roaming to minimize latency during roaming. Therefore, it is possible to further simplify the security context interaction process during roaming, which can significantly reduce the latency of the roaming process. 2. In FT fast roaming, the FT authentication request sent by the STA to the Target AP contains an unprotected PMK-R1, posing a security risk such as key leakage: In FT fast roaming, the FT authentication request contains PMK-R1 shared by the STA and the Current AP. However, at this time, a secure association has not yet been established between the STA and the Target AP. The PMK-R1 in the FT authentication request is likely to be intercepted by an attacker, who can deduce the same PTK key based on other intercepted random numbers and other information, thereby intercepting and decrypting the data between the STA and the Target AP. Therefore, protecting the security context transmitted between the STA and the target can improve the security of the roaming process, thereby enhancing the overall security and reliability of the system. 3. In FT fast roaming, the context interaction between APs is not protected, posing a security risk: In FT fast roaming, although key negotiation between the STA and the target AP is eliminated, the direct security context interaction between the current AP and the target AP is not protected. Even within the same MD, if APs interact via wireless signals, an attacker can still control other APs in the same MD to intercept the security context and deduce the same key, thereby intercepting and decrypting data between the STA and the target AP. Therefore, protecting the security context transmitted between APs can improve the security of the roaming process, thereby enhancing the overall security and reliability of the system. 4. In seamless roaming, all APs within the SMD use the same PTK. Once one AP is attacked and its PTK is leaked, the entire SMD will no longer be secure: Within the same SMD, if all APs share the same PTK, once an attacker controls one AP to intercept the security context and deduce the same key, the data transmitted between the STA and all APs will be decrypted and intercepted. Therefore, providing a key isolation mechanism to ensure that the STA and different APs use different PTKs can limit attacks to the STA and malicious APs, thereby protecting the security of data transmitted between the STA and other APs, and thus improving the overall security and reliability of the system.

[0085] In view of this, this application provides various communication methods to solve the problems mentioned above. To facilitate a better understanding of this solution, this application discusses several different scenarios, including but not limited to the following four scenarios:

[0086] Scenario 1: The Current AP and Target AP communicate via a secure channel, and the same PTK is used to communicate with both before and after non-AP roaming.

[0087] Scenario 2: The Current AP and Target AP communicate via a secure channel, and different PTKs are used to communicate with both before and after non-AP roaming.

[0088] Scenario 3: The Current AP and Target AP are not on a secure channel, and the same PTK is used to communicate with both before and after non-AP roaming;

[0089] Scenario 4: The Current AP and Target AP are not connected via a secure channel, and different PTKs are used to communicate with both before and after non-AP roaming.

[0090] For ease of description, the Current AP is named the First AP and the Target AP is named the Second AP. In practical applications, these names can also be used; this application is merely an example. It should be noted that the communication method proposed in this application can be applied to both single-link and multi-link scenarios. When applied to a multi-link scenario, the First AP is the First AP MLD, the Second AP is the Second AP MLD, and the non-AP is the Non-AP MLD. The following description will use a multi-link scenario as an example; a similar scheme can be used for single-link scenarios.

[0091] Scenario 1: The first AP MLD and the second AP MLD are connected via a secure channel, and the same PTK is used to communicate with both the first and second AP MLDs before and after non-AP MLD roaming.

[0092] Please refer to Figure 2A for a possible communication method, which includes, but is not limited to, at least one of the following steps:

[0093] 201A, non-AP MLD and the first AP MLD undergo authentication and four-way handshake processes;

[0094] IEEE 802.1x is a port-based network access control technology that provides a reliable framework for user authentication and key distribution, ensuring that only authenticated users and devices can access network resources. After a non-AP MLD passes 802.1x authentication, the first AP MLD receives a Session Key identical to the non-AP MLD. The first AP MLD and the non-AP MLD use this Session Key as their PMK (Primary Key). Subsequently, the first AP MLD and the non-AP MLD perform a four-way handshake to ensure reliable communication and data integrity. It should be noted that during this process, both the first AP MLD and the non-AP MLD verify whether the other party possesses a PMK identical to their own. If they do not match, the four-way handshake process fails.

[0095] Given that the aforementioned authentication process and four-way handshake process are relatively mature technologies, this application will not elaborate further. After the non-AP MLD and the first AP MLD complete 802.1x authentication and a four-way handshake, both parties generate and save the same first PMK.

[0096] 202A, non-AP MLD and the first AP MLD each deduce the same first PTK based on the saved PMK;

[0097] 203A, non-AP MLD, and the first AP MLD each generate and save the same first PTK id;

[0098] In this application, the first pairwise transit key (PTK) id is used to uniquely identify the first PTK generated separately by the non-AP MLD and the first AP MLD. It should be noted that the first PTK id can also be expressed as the first PTK name or other forms, which are not limited here. Since the first PTKs generated by both parties in step 202A are completely identical, a possible reason for generating the first PTK id is that no secure association has been established between the non-AP MLD and the first AP MLD. The reassociation request cannot carry the key, and the first PTK id is only known to the non-AP MLD and the first AP MLD, thus preventing the first PTK from being leaked. In this application, the first PTK id can be generated and stored by both the non-AP MLD and the first AP MLD based on the same information and algorithm. Specifically, this includes:

[0099] The first PTK ID is generated based on one or more of the following information:

[0100] First PTK, First PMK, First PMK id, PMKR1 Name, Non-AP side random number SNonce, First AP MLD side random number ANonce1, ID of the BSS where the First AP MLD and Non-AP MLD are located, i.e., BSSID, Address information of Non-AP MLD (non-AP MLD ADDR), Address information of First AP MLD (first AP MLD ADDR), and / or a specific string, such as "ROAMING", etc.

[0101] The specific algorithm for generating the first PTK ID is not limited, but includes, but is not limited to, the following algorithms:

[0102] First PTK id = Truncate-128(SHA-256(PMKR1Name||“FT-PTKN”||SNonce||ANonce||BSSID||STA-ADDR)); or,

[0103] First PTK id = Truncate-128(HMAC-SHA-256(PMK,“PTK id”||AA||SPA)); or,

[0104] First PTK id = Truncate-128(Hash(PTK||non-AP MLD-ADDR||CurrentAP MLD-ADDR)); or,

[0105] First PTK id = ExtractBits(PTK, 0, 128).

[0106] It should be noted that the length of the first PTK id in the above-described algorithm can be adjusted based on actual needs. For example, when the first PTK id is carried in the reserved bits of the corresponding frame, its length should not exceed the maximum value that the bit can identify. For instance, in the Link Reconfiguration Request frame, there are 8 reserved bits in the Reconfiguration Multi-Link element, which can be used to contain the first PTK id. Therefore, an algorithm similar to the above first PTK id = ExtractBits(PTK, 0, 8) can be used.

[0107] After the first PTK ID is generated, both the non-AP MLD and the first AP MLD can store the correspondence between the first PTK ID and the first PTK itself. The first PTK itself includes the first PTK or information that can uniquely correspond to the first PTK, including but not limited to the ID or address information of the non-AP MLD. The correspondence can be stored in a list, index, etc.

[0108] Optionally, the first AP MLD can generate the first PTK ID and send it to the non-AP MLD. For example, the first AP MLD can generate the first PTK ID locally and then send the first PTK ID to the non-AP MLD, such as carrying the first PTK ID in the 4-way handshake message 3, or carrying the first PTK ID in other signaling or message frames and sending it to the non-AP MLD.

[0109] Alternatively, the non-AP MLD generates the first PTK ID and sends it to the first AP MLD. For example, when establishing a security association with the first AP MLD, the non-AP MLD has already exchanged information such as address and random number during the four-way handshake. The non-AP MLD can generate the first PTK ID locally and then send it to the first AP MLD, for example, by carrying the first PTK ID in the 4-way handshake message 4, or by carrying the first PTK ID in other signaling or message frames and sending it to the first AP MLD.

[0110] In summary, this application does not limit the specific method by which the first AP MLD or non-AP MLD obtains the first PTK id.

[0111] 204A, non-AP MLD identifies the second AP MLD as the AP to be roamed;

[0112] When a non-AP MLD needs to roam, a second AP MLD is selected as the AP to be roamed. In this embodiment, the first AP MLD and the second AP MLD can be in the same SMD, which is a security domain. The first AP MLD and the second AP MLD are connected by a secure channel (such as a wired connection).

[0113] Each AP within the SMD can use the same key (such as the first PTK). The second AP MLD can request the first PTK from the first AP MLD using the first PTK ID. After the first AP sends the first PTK to the second AP MLD, subsequent non-AP MLDs establish a security association between the first PTK and the second AP MLD to complete roaming preparation.

[0114] 205A, the non-AP MLD sends the first request to the first AP MLD;

[0115] After the non-AP MLD determines that the AP to be roamed is the second AP MLD and has obtained the ID or address information of the second AP MLD, it may optionally send a first request to the first AP MLD. The first request is used to trigger the roaming preparation process or the roaming process. The first request carries key information, which is used by the first AP MLD to determine the key.

[0116] It should be noted that the first AP MLD may also obtain the ID or address information of the second AP MLD.

[0117] In this embodiment, the key information may include, but is not limited to, at least one of the following: a first PTK id, the id or address information of a non-AP MLD. In this application, the first request may be named in various ways, such as a Roaming Add Link Request or other requests, and this application does not impose any specific limitations.

[0118] Taking the first request, the Roaming Add Link Request, as an example, it can be a standalone MAC frame (e.g., the Roaming Add Link Request frame), or it can be contained within a MAC frame (e.g., the Link Reconfiguration Request frame), or it can contain information such as the first PTK id within a MAC frame (e.g., the Link Reconfiguration Request frame). Taking the Link Reconfiguration Request frame as an example, the Link Reconfiguration Request frame can contain the aforementioned PTK id information by defining new information or elements, as shown in Table 1 below; or by defining new fields in existing information or elements, such as the first PTK id shown in Figure 2A-1; or by defining new bits in existing fields; or by reusing reserved bits in existing fields. For example, the Reconfiguration Multi-Link element in the Link Reconfiguration Request frame has 8 reserved bits, which can be used to contain the PTK id, as shown in the Reseved field in Figure 2A-1.

[0119] Table 1

[0120] 206A, The first AP MLD queries the key based on the key information;

[0121] As mentioned above, after establishing a security association with the non-AP MLD, the first AP MLD generates a first PTK and a first PTK ID, and saves the corresponding relationship between the PTK ID and the PTK, and / or the corresponding relationship between the device identifier or device address and the PTK. This relationship can be a storage list, index, etc. After receiving the first request from the non-AP MLD, the first AP MLD queries the key based on the key information carried therein. In this embodiment, the key is the first PTK. Specifically, this includes the following methods:

[0122] When the key information includes the first PTK id, based on the correspondence between PTK id and PTK, query whether there exists a first PTK corresponding to the first PTK id;

[0123] When the key information includes the non-AP MLD id or the non-AP MLD address information, based on the correspondence between the device identifier or device address and the PTK, query whether the first PTK corresponding to the non-AP MLD id or the non-AP MLD address information exists;

[0124] When the key information includes the first PTK id and the non-AP MLD id or the non-AP MLD address information, the first PTK is queried based on the above two correspondences or one of them. Optionally, the first AP MLD can further compare whether the two PTKs queried based on the two correspondences are consistent to determine whether the frame carrying the key information, such as the first request, has been tampered with. Specifically, based on the correspondence between PTK id and PTK, the first PTK1 corresponding to the first PTK id is queried; based on the correspondence between device identifier or device address and PTK, the first PTK2 corresponding to the non-AP MLD id or the non-AP MLD address information is queried; if the first PTK1 and the first PTK2 are consistent, then the first PTK1 is determined to be the first PTK.

[0125] 207A. The first AP MLD sends a second request to the second AP MLD;

[0126] 208A. The second AP MLD sends a second request response to the first AP MLD;

[0127] 209A. The first AP MLD sends a first request response to the non-AP MLD;

[0128] The 210A, non-AP MLD and the second AP MLD communicate based on the first PTK.

[0129] If the first PTK query is successful, the first AP MLD sends the first PTK to the second AP MLD. Specifically, it can send a second request to the second AP MLD, which can be a Context Transfer Request. This second request is used to send the first PTK to the second AP MLD. Otherwise, the first AP MLD sends a transmission failure indication to the second AP MLD, such as a context request failure indication.

[0130] After receiving the second request carrying the first PTK, the second AP MLD saves the first PTK and replies to the first AP MLD with a second request response containing an indication of the transmission result. This second request response can be a Context Transfer Response, a Remote Response, or an FT Response. This message is used to reply to the first AP MLD about the transmission status of the first PTK. In actual implementation, the name and structure of the second request response are not limited; for example, it can be Context Transfer Response or others. Furthermore, the format of the second request response and the way it carries information such as the first PTK are similar to those described above for the first request, and will not be repeated here. Similarly, the second request response can be a separate MAC frame (e.g., a Context Transfer Response frame, a Remote Response, or an FT Response frame), or it can be included in a MAC frame, or the information such as the first PTK ID contained therein can be included in a MAC frame. To facilitate better understanding, taking the second request response as a Remote Response as an example, the MAC frame can contain the aforementioned first PTK and other information by defining new information or elements, as shown in Table 2; or by defining new fields in existing information or elements, as shown in Figure 2A-2; or by defining new bits in existing fields, as shown in Table 3; or by reusing reserved bits in existing fields.

[0131] Table 2

[0132] Table 3

[0133] Alternatively, the first PTK ID included in the second request response can also be an existing robust security network element. ， A new first PTK section is added to RSNE. For example, if an RSNE field exists, it can be set as follows:

[0134] —The version field should be set to 1.

[0135] —(#4226) The Pairwise Cipher Suite Count field should be set to 1.

[0136] —(#4226)AKM Suite Count field shall be set to 1.

[0137] —PMKID Count field shall be set to 1.

[0138] —PMKID List field shall contain the PMKR0Name.

[0139] —All other fields shall be as specified in 9.4.2.23 (RSNE) and 12.6.3 (RSNA policy selection in an infrastructure BSS).

[0140] —First PTK.

[0141] Alternatively, the first PTK can be carried in the RSNE field, as shown in Figure 2A-3, in the Pairwise Cipher Suite List.

[0142] It should be noted that if the query for the first PTK is successful in step 206A, and the second request response indicates that the first PTK transmission was successful (e.g., a Context Transfer Response indicating successful context transfer), then the first AP MLD replies to the non-AP MLD with a first request response. This first request response can be a Roaming Add Link Response, used to indicate successful roaming or successful roaming preparation. Otherwise, the first AP MLD indicates to the non-AP MLD that roaming has failed or roaming preparation has failed. This first request response is used to reply to the non-AP MLD regarding the first PTK transmission status.

[0143] Subsequently, the non-AP MLD roams to the second AP MLD, and both parties use the first PTK to protect the channel and data.

[0144] It should be noted that in the above embodiments, the first AP MLD receives key information from the non-AP MLD to query the key, i.e., the first PMK. In this application, the first AP MLD can also receive key information from the second AP MLD to query the key. Please refer to Figure 2B, which shows another communication method provided by an embodiment of this application, including but not limited to at least one of the following steps:

[0145] 201B, non-AP MLD and the first AP MLD undergo authentication and four-way handshake processes;

[0146] 202B, non-AP MLD and the first AP MLD each deduce the same first PTK based on the saved PMK;

[0147] 203B, non-AP MLD, and the first AP MLD each generate and save the same first PTK id;

[0148] 204B, non-AP MLD determines the second AP MLD as the AP to be roamed;

[0149] In this embodiment, steps 201B to 204B are similar to steps 201A to 204A in the embodiment shown in FIG2A, and will not be described in detail here.

[0150] 205B, the non-AP MLD sends the first request to the second AP MLD;

[0151] After the non-AP MLD identifies the second AP MLD as the AP to be roamed, it obtains the second AP MLD's ID or address information and sends a first request to the second AP MLD. The first request sent by the non-AP MLD to the second AP MLD includes the first PTK ID, the non-AP MLD's ID or address information, and optionally, the first AP MLD's ID or address. In practice, the first request can be a separate MAC frame (e.g., a Roaming Add Link Request frame), or it can be included in a MAC frame (e.g., a Reassociation Request frame), or the aforementioned first PTK ID and other information can be included in a MAC frame (e.g., a Reassociation Request frame). Taking the first request as a Reassociation Request frame as an example, the Reassociation Request frame can include the PTK id by defining new information or elements, as shown in Table 4. This can be done by adding a PTK id to an existing table to define the corresponding PTK; or by defining a new field in an existing information or element, as shown in Figure 2B-1; or by defining a new bit in an existing field; or by reusing reserved bits in an existing field. For example, the Multi-Link element in the Reassociation Request frame has 5 reserved bits that can be used to include the PTK id, as shown in the circled area of ​​Figure 2B-2.

[0152] Table 4

[0153] 206B. The second AP MLD sends a second request to the first AP MLD;

[0154] The second AP MLD sends a second request to the first AP MLD. The second request may be a Context Transfer Request. The second request includes key information, which includes, but is not limited to, at least one of the following: a first PTK ID, a non-AP MLD ID, or address information. The second request is used to request the first PTK from the first AP MLD.

[0155] In this application, the name and structure of the second request are not limited. For example, the second request can be a Context Transfer Request, a Remote Request, or an FT Request, etc. In actual implementation, the second request can be an independent MAC frame (e.g., a Context Transfer Request frame, a Remote Request, an FT Request frame, etc.), or it can be included in a MAC frame, or the aforementioned first PTK id and other information contained therein can be included in a MAC frame.

[0156] Taking the second request as a Remote Request as an example, the MAC frame can contain the aforementioned first PTK id and other information by defining new information or elements, as shown in Table 5; or by defining new fields in existing information or elements, as shown in Figure 2B-3; or by defining new bits in existing fields, as shown in Table 6; or by reusing reserved bits in existing fields.

[0157] Table 5

[0158] Table 6

[0159] Alternatively, including the first PTK id in the second request can be done by adding the first PTK id part to the existing RSNE field. For example, if the RSNE field exists, it can be set as follows:

[0160] The version field should be set to 1.

[0161] —(#4226) The Pairwise Cipher Suite Count field should be set to 1.

[0162] —(#4226) The Suite Count field for AKM kits shall be set to 1.

[0163] —The PMKID count field should be set to 1.

[0164] —The PMKID list field should contain the PMKR0Name.

[0165] —PTKID Count field shall be set to 1.

[0166] —PTKID List field shall contain the PTKID.

[0167] —....

[0168] Alternatively, the first PTK id can be carried in the first PMK id part of the RSNE field, as shown in Figure 2A-3.

[0169] 207B, The first AP MLD queries the key based on the key information;

[0170] In this embodiment, step 207B is similar to step 207A shown in Figure 2A, and will not be described in detail here.

[0171] 208B, The first AP MLD sends a second request response to the second AP MLD;

[0172] 209B. The second AP MLD sends a first request response to the non-AP MLD;

[0173] 210B, the non-AP MLD and the second AP MLD communicate based on the first PTK.

[0174] The first AP MLD replies to the second AP MLD with a second request response, such as a Context Transfer Response. If the first AP MLD successfully queries the first PTK in step 206B, the second request response includes the first PTK; if the query for the first PTK fails, the second request response includes an error message indicating that the PTK query failed or the context request failed.

[0175] Subsequently, the non-AP MLD roams to the second AP MLD, and both parties use the first PTK to protect the channel and data.

[0176] In summary, in the embodiments shown in Figures 2A and 2B, the first AP MLD and the second AP MLD are located within the same SMD, and the SMD is considered a single security domain. A secure channel (e.g., a wired connection) connects the first AP MLD and the second AP MLD. Each AP within the SMD can use the same key, such as the first PMK. The first AP MLD sends the first PTK to the second AP MLD. Subsequently, the non-AP MLD establishes a secure association with the second AP MLD based on the first PTK, completing roaming preparation. The first AP MLD and the second AP MLD directly share the security context (information required for key derivation, or the PTK) through the secure channel (security domain in the SMD), avoiding the prior art where the second AP MLD requests the PMK from the relevant second AC and then performs key negotiation and other interactions between the non-AP MLD and the second AP MLD. This simplifies the roaming process and reduces roaming latency.

[0177] Scenario 2: A secure channel exists between the first AP MLD and the second AP. Before and after roaming, the non-AP MLD uses different PTKs to communicate with both. Please refer to Figures 3A, 3B, and 3C for other possible communication methods provided in this application. See Figure 3A, which specifically includes, but is not limited to, at least one of the following steps:

[0178] 301A, non-AP MLD and the first AP MLD perform authentication process and four-way handshake process;

[0179] 302A, non-AP MLD, and the first AP MLD each deduce the same first PTK based on the saved PMK;

[0180] 303A, non-AP MLD, and the first AP MLD each generate and save the same first PMK id and / or first PTK id;

[0181] 304A, non-AP MLD identifies the second AP MLD as the AP to be roamed;

[0182] In this embodiment, steps 301A, 302A, and 304A are similar to steps 201A, 202A, and 204A in the embodiment shown in FIG2A, and will not be described in detail here.

[0183] Optionally, if present, the method by which the non-AP MLD and the first AP MLD generate and save the first PTK id in step 303A is similar to step 203A in the embodiment shown in Figure 2A, and will not be described in detail here.

[0184] Optionally, in step 303A, the methods for generating and saving the first PMK id for both the non-AP MLD and the first AP MLD include the following:

[0185] In this embodiment, the first PMK id is used to uniquely identify the first PMK generated between the non-AP MLD and the first AP MLD through the authentication process. The first PMK id can also be expressed as PMK name or other forms, which are not limited here. The first PMK generated by both parties is exactly the same. The reason for generating the first PMK id and the implementation method of generating the first PMK id are similar to the relevant content of the first PTK id in step 203A, and will not be repeated here.

[0186] The first PMK id is generated based on one or more of the following information:

[0187] The structure includes: First PMK, "First PMK Name" (a specific string, the exact content of which is not limited), AA, SPA, non-AP MLD side random number SNonce, first AP MLD side random number ANonce, the BSS ID of the first AP MLD and non-AP MLD (i.e., BSSID), non-AP MLD address information (non-AP MLD ADDR), and first AP MLD address information (first AP MLD ADDR). Here, AA is the MAC address of the AP, and SA is the MAC address of the client.

[0188] In this embodiment, there are multiple algorithms for generating the first PMK id, including but not limited to at least one of the following:

[0189] First PMK id = Truncate-128(HMAC-SHA-256(PMK,“PMK Name”||AA||SPA)); or,

[0190] First PMK id = Truncate-128(Hash(PMK||non-AP MLD-ADDR||Current AP MLD-ADDR)); or,

[0191] The first PMK id = ExtractBits(PMK, 0, 128).

[0192] It should be noted that the length of the first PMK id in the above-described algorithm can be adjusted based on actual needs. For example, when the first PMK id is carried in the reserved bits of the corresponding frame, its length should not exceed the maximum value that the bit can identify. For instance, in the Reconfiguration Multi-Link element of the Link Reconfiguration Request frame, there are 8 reserved bits that can be used to contain the first PMK id. In this case, the algorithm described above, such as first PMK id = ExtractBits(PMK, 0, 8), can be used.

[0193] After the first PMK ID is generated, both the non-AP MLD and the first AP MLD should save the correspondence between the first PMK ID and the first PMK itself. The first PMK itself includes the first PMK or information that can uniquely correspond to the first PMK, including but not limited to the ID or address information of the non-AP MLD. The correspondence can be stored in a list, index, etc.

[0194] Optionally, the first AP MLD can generate the first PMK id and send it to the non-AP MLD; or, the non-AP MLD can generate the first PMK id and send it to the first AP MLD.

[0195] It should be noted that the aforementioned SNonce (Station Nonce) is a random number used only once in cryptography to ensure that data is not reused during communication and to prevent replay attacks. During the Wi-Fi four-way handshake, the SNonce is generated by the STA (client) and interacts with the AP (access point) to generate a key for encrypting wireless data. In other implementations, the SNonce can also be other forms of random numbers; this is not limited here.

[0196] In summary, this application does not limit the specific method by which the first AP MLD or non-AP MLD obtains the first PMK id.

[0197] 305A, non-AP MLD sends the first request to the first AP MLD;

[0198] In this embodiment, step 305A is similar to step 205A shown in Figure 2A, except that the key information in the first request in step 305A includes the first PMK id and / or the first PTK id, and may also include a non-AP MLD side random number. That is, the key information in the roaming add link request in step 305A includes, but is not limited to, at least one of the following: the first PTK id and / or the first PMK id, the non-AP MLD id or the non-AP MLD address information, and the non-AP MLD side random number SNonce (or non-AP side random number).

[0199] 306A, the first AP MLD queries the key based on the key information;

[0200] In step 306A, the first AP MLD queries the key based on the key information in a manner similar to step 206 in Figure 2A. The difference lies in that in step 306A, the first AP MLD queries the first PTK and / or the first PMK based on the first PTK id and / or the first PMK id, and / or the non-AP MLD id / address information. Similar to querying the first PTK based on the first PTK id, querying the first PMK based on the first PMK id includes, when the key information includes the first PMK id, querying whether the first PMK corresponding to the first PMK id exists based on the correspondence between PMK id and PMK; or, querying whether the first PMK corresponding to the non-AP id or the non-AP address information exists based on the correspondence between device identifier or device address and PMK; or, when the key information includes the first PMK id and the non-AP id or the non-AP address information, querying the first PMK based on the correspondence between PTK id and PMK. The first PMK1 corresponding to the id is used to query the first PMK2 corresponding to the non-AP id or the non-AP address information based on the correspondence between the device identifier or device address and the PMK; if the first PMK1 and the first PMK2 are the same, then the first PMK1 is determined to be the first PMK.

[0201] 307A. The first AP MLD sends a second request to the second AP MLD;

[0202] In this embodiment, step 307A is similar to step 207A in Figure 2A, except that the second request in step 307A includes the first PMK and / or the first PTK queried in step 306A, and also includes the non-AP MLD side random number SNonce.

[0203] 308A, the second AP MLD generates and saves the second PTK;

[0204] In this embodiment, the second AP MLD derives the second PTK based on one or more of the following information: first PTK, first PMK, non-AP MLD side random number SNonce, second AP MLD side random number ANonce2, non-AP MLD id / ADDR, first AP MLD id / ADDR, "Pairwisekeyexpansion" (a specific string, the specific string content is not limited), AA, SA, where AA is the MAC address of the second AP MLD and SA is the MAC address of the non-AP MLD.

[0205] It should be noted that the PMK derivation of PTK is one of the key steps in ensuring wireless communication security. This process mainly occurs during the four-way handshake defined in the 802.11i standard. The relevant steps are described below:

[0206] 1. Generating PMK: PMK is typically generated using a pre-shared key (PSK) or through the 802.1X authentication process. In PSK mode, PMK is generated using the PBKDF2 function based on the user-input password and SSID.

[0207] 2. Four-way handshake begins: After the client (STA) and access point (AP) establish a connection, the AP will send a random number (ANonce) to the client.

[0208] 3. Client generates SNonce: The client generates its own random number (SNonce) and sends it along with its MAC address to the AP.

[0209] 4. PTK Derivation: Both the AP and the client possess PMK, ANonce, SNonce, the AP's MAC address, and the client's MAC address. PTK is generated using a pseudo-random function (PRF), and the formula may include, but is not limited to:

[0210] PTK = PRF(PMK, "Pairwisekeyexpansion", Min(AA, SA) || Max(AA, SA) || Min(ANonce, SNonce) || Max(ANonce, SNonce)); PTK = PRF(PMK, "Pairwisekeyexpansion", Min(AA, SA) || Max(AA, SA) || Min(ANonce, SNonce) || Max(ANonce, SNonce)); or,

[0211] PTK = KDF-Hash-Length(PMK, “FT-PTK”, SNonce || ANonce || BSSID || STA-ADDR); or, PTK = PRF-X(PMK, “PTKDerivation”, SPA || AA || SNonce || ANonce[||DHss]); or, PTK = KDF-HASH-NNN(PMK, “PTK Derivation”, SPA || BSSID || DHss)

[0212] New PTK =

[0213] PRF(PTK, "Pairwisekeyexpansion", Min(AA, SA) || Max(AA, SA) || Min(ANonce, SNonce) || Max(ANonce, SNonce)); PTK = PRF(PMK, "Pairwisekeyexpansion", Min(AA, SA) || Max(AA, SA) || Min(ANonce, SNonce) || Max(ANonce, SNonce)); or,

[0214] New PTK = KDF-Hash-Length(PTK, “FT-PTK”, SNonce || ANonce || BSSID || STA-ADDR); or,

[0215] New PTK = PRF-X(PTK, “PTKDerivation”, SPA || AA || SNonce || ANonce[||DHss]); or,

[0216] New PTK = KDF-HASH-NNN(PTK, “PTK Derivation”, SPA || BSSID || DHss).

[0217] 5. Composition of PTK: PTK is actually composed of three keys: EAPOL-Key Confirmation Key (KCK), EAPOL-Key Encryption Key (KEK), and Temporal Key (TK). Among them, KCK is used to verify the integrity of EAPOL messages, KEK is used to encrypt EAPOL messages, and TK is used to encrypt the actual data frames.

[0218] 6. Verification and Confirmation: The AP uses KCK to verify the integrity of messages sent by the client. If verification is successful, the AP sends a confirmation message to the client, and the client also uses KCK to verify this message. After both parties confirm that there are no errors, PTK is successfully derived and used for subsequent data encryption.

[0219] 309A. The second AP MLD sends a second request response to the first AP MLD;

[0220] In this embodiment, step 309A is similar to step 208A in Figure 2A, except that the second request response in step 309A also includes the second AP MLD side random number ANonce2.

[0221] It should be noted that if the second AP MLD successfully derives the new PTK (i.e., the second PTK), the second AP MLD saves the second PTK and then replies to the first AP MLD with a second request response, such as a Context Transfer Response. This response contains a random number ANonce2 from the second AP MLD side and indicates that the context transfer was successful. The name, format, and implementation of information such as ANonce2 in the second request response are similar to the description of the second request response in step 208A of Figure 2A, and will not be repeated here.

[0222] Additionally, ANonce2 (AP Nonce2), similar to SNonce, is a random number used only once to ensure that data is not reused during communication, preventing replay attacks. During the Wi-Fi four-way handshake, ANonce2 is generated by the second AP MLD (access point) and interacts with the non-AP MLD (client) to generate a key for encrypting wireless data. In possible implementations, ANonce2 can also be other forms of random numbers; this is not limited here.

[0223] 310A. The first AP MLD sends a first request response to the non-AP MLD;

[0224] In this embodiment, step 310A is similar to step 209A in Figure 2A, except that the first request response in step 310A also includes a second AP MLD side random number ANonce2.

[0225] 311A, non-AP MLD generates and saves the second PTK;

[0226] In this step, the non-AP MLD uses the same information and algorithm as the second AP MLD to generate the second PTK, which is consistent with step 308A. The specifics will not be elaborated here.

[0227] The 312A non-AP MLD and the second AP MLD communicate based on the second PTK.

[0228] Subsequently, the non-AP MLD roams to the second AP MLD, and both parties use their respective generated second PTKs to protect the channel and data.

[0229] It should be noted that in the above embodiments, the first AP MLD receives key information from the non-AP MLD to query the key, i.e., the first PMK and / or the first PTK. In this application, the first AP MLD can also receive key information from the second AP MLD to query the key. Please refer to Figure 3B, which shows another communication method provided by an embodiment of this application, including but not limited to at least one of the following steps:

[0230] 301B, non-AP MLD and the first AP MLD perform authentication process and four-way handshake process;

[0231] 302B, non-AP MLD and the first AP MLD each deduce the same first PTK based on the saved PMK;

[0232] 303B, non-AP MLD, and the first AP MLD each generate and save the same first PMK id and / or first PTK id;

[0233] 304B, non-AP MLD identifies the second AP MLD as the AP to be roamed;

[0234] In this embodiment, steps 301B to 304B are similar to steps 301A to 304A shown in Figure 3A, and will not be described in detail here.

[0235] 305B, non-AP MLD sends the first request to the second AP MLD;

[0236] In this embodiment, step 305B is similar to step 205B shown in Figure 2B. The difference is that the key information in the first request in step 305B includes the first PMK id and / or the first PTK id, and may also include a non-AP MLD side random number, which will not be elaborated here.

[0237] 306B. The second AP MLD sends a second request to the first AP MLD;

[0238] In this embodiment, step 306B is similar to step 206B shown in Figure 2B. The difference is that the key information in the second request in step 306B includes the first PMK id and / or the first PTK id, and may also include a non-AP MLD side random number, which will not be described in detail here.

[0239] 307B, The first AP MLD queries the key based on the key information;

[0240] In this embodiment, step 307B is similar to step 306A shown in Figure 3A, and will not be described in detail here.

[0241] 308B, The first AP MLD sends a second request response to the second AP MLD;

[0242] In this embodiment, step 308B is similar to step 208B shown in FIG2B, except that the second request response in step 308B includes the first PMK and / or the first PTK.

[0243] 309B, The second AP MLD generates and saves the second PTK;

[0244] In this embodiment, step 309B is similar to step 308A shown in Figure 3A, and will not be described in detail here.

[0245] 310B, The second AP MLD sends a first request response to the non-AP MLD;

[0246] In this embodiment, step 310B is similar to step 209B shown in Figure 2B, except that the first request response in step 310B also includes a second AP MLD side random number ANonce2.

[0247] 311B, non-AP MLD generates and saves the second PTK;

[0248] 312B, the non-AP MLD and the second AP MLD communicate based on the second PTK.

[0249] In this embodiment, steps 311B and 312B are similar to steps 311A ​​and 312A shown in Figure 3A, and will not be described in detail here.

[0250] Furthermore, in Figures 3A and 3B above, both the non-AP MLD and the second AP MLD generate the same second PTK. In this application, the second AP MLD can also generate the second PTK and send it to the non-AP MLD, or the non-AP MLD can generate the second PTK and send it to the second AP MLD. The former will be used as an example for specific explanation below. Please refer to Figure 3C, which provides another possible communication method for an embodiment of this application, specifically including but not limited to at least one of the following steps:

[0251] 301C, non-AP MLD and the first AP MLD perform authentication process and four-way handshake process;

[0252] 302C, non-AP MLD, and the first AP MLD each deduce the same first PTK based on the saved PMK;

[0253] 303C, non-AP MLD, and the first AP MLD each generate and save the same first PMK id and / or first PTK id;

[0254] 304C, non-AP MLD determines the second AP MLD as the AP to be roamed;

[0255] 305C, non-AP MLD sends the first request to the first AP MLD;

[0256] 306C, the first AP MLD queries the key based on the key information;

[0257] 307C. The first AP MLD sends a second request to the second AP MLD;

[0258] 308C, the second AP MLD generates and saves the second PTK;

[0259] In this embodiment, steps 301C to 308C are similar to steps 301A to 308C shown in Figure 3A, and will not be described in detail here.

[0260] 309C, the second AP MLD encrypts the second PTK to obtain the third PTK;

[0261] After the second AP MLD generates the second PTK, it can send the second PTK to the non-AP. In order to ensure the security of the second PTK transmission, the second AP MLD can encrypt the second PTK to obtain the third PTK. Specifically, the first PTK and / or the first PMK can be used to encrypt the second PTK. The encryption method can be an existing encryption method, which will not be elaborated here.

[0262] Optionally, in this embodiment, the second AP MLD may also use other information to encrypt the second PTK. It is understood that the other information needs to be known by the non-AP MLD so that the non-AP MLD has the ability to decrypt the third PTK.

[0263] 310C, The second AP MLD sends a second request response to the first AP MLD;

[0264] In this embodiment, step 310C is similar to step 209A in Figure 2A, except that the second request response in step 309A also includes a third PTK.

[0265] 311C. The first AP MLD sends a first request response to the non-AP MLD;

[0266] In this embodiment, step 311C is similar to step 210A in Figure 2A, except that the first request response in step 311A ​​also includes a third PTK.

[0267] 312C, non-AP MLD decrypts the third PTK to obtain the second PTK;

[0268] After obtaining the third PTK, the non-AP MLD decrypts the third PTK using the first PTK and / or the first PMK to obtain the second PTK. The specific decryption method can use existing decryption methods, which will not be elaborated here.

[0269] The 313C non-AP MLD and the second AP MLD communicate based on the second PTK.

[0270] It should be noted that the first AP MLD receives key information from the non-AP MLD (carried in the first request in step 305C) to query the key, namely the first PMK and / or the first PTK. If the second AP MLD generates the second PTK and encrypts it before sending it to the non-AP MLD, it can be similar to Figure 2B or Figure 3B, combined with the step of the first AP MLD receiving key information from the second AP MLD to query the key. The specifics will not be elaborated here.

[0271] Combining Figures 3A to 3C, the first AP MLD and the second AP MLD are located within the same SMD, which is considered a single security domain. The Current AP MLD and the Target AP MLD are connected via a secure channel (e.g., a wired connection). Each AP within the SMD uses a different key (different PTK). The second AP MLD sends a first PMK and / or a first PTK to the second AP MLD. The non-AP MLD and the second AP MLD respectively deduce a new second PTK based on the first PMK and / or the first PTK. Subsequently, the non-AP MLD establishes a secure association with the second AP MLD based on the second PTK, completing roaming preparation. Furthermore, the request sent by the non-AP MLD to the second AP MLD contains a key identifier calculated from the key, a random number, and the address. This identifier is only stored locally by the non-AP MLD and the first AP MLD. Even if an attacker obtains the key identifier, they cannot obtain the key, ensuring the security of the link between the non-AP MLD and the second AP MLD.

[0272] Scenario 3: There is no secure channel between the first AP MLD and the second AP MLD, and the same PTK is used to communicate with both before and after the non-AP MLD roams.

[0273] Please refer to Figure 4A, which illustrates a possible communication method, including but not limited to at least one of the following steps:

[0274] 401A. The management device configures the first public-private key pair on the first AP MLD;

[0275] 402A. The management device configures a second public / private key pair on the second AP MLD;

[0276] 403A: The first AP MLD and the second AP MLD exchange their respective public keys;

[0277] In this embodiment, different public-private key pairs are configured on the first AP MLD and the second AP MLD. Specifically, a first public-private key pair, including a first public key and a first private key, is configured on the first AP MLD, and a second public-private key pair, including a second public key and a second private key, is configured on the second AP MLD. The public-private key pair configuration process can be that the first AP MLD and the second AP MLD apply for the public-private key pair from a Certificate Authority (CA) respectively, or it can be configured by the Wireless Access Point Controller (AC) or other management nodes, or it can be configured manually; there is no limitation here. The private key is stored locally on the first AP MLD and the second AP MLD, while the public key can be publicly disclosed.

[0278] Because key encryption based on public and private keys and the generation of digital signatures are required, the public keys of the first AP MLD and the second AP MLD need to be shared with each other. In some implementations, public key sharing can be achieved through frame interaction between the first AP MLD and the second AP MLD (including forwarding relevant frames through a distributed system (DS)), or by the AC, DS, or other management nodes during or after configuring the public and private key pair, or through manual configuration, or by carrying their own public key or a certificate containing the public key through beacon frames or other broadcast frames, or other methods, which are not limited here.

[0279] In some implementations, the public keys of the first AP MLD and the second AP MLD can be sent to each other through other frame exchanges. For example, during the authentication four-way handshake process between the non-AP MLD and the first AP MLD, the first AP MLD sends its first public key to the non-AP MLD. The non-AP MLD then carries the first public key of the first AP MLD in the frame it sends to the second AP MLD. Subsequently, the second AP MLD carries its second public key in the frames it sends to the first AP MLD, thereby achieving public key sharing. The specific implementation method of public key sharing between the first AP MLD and the second AP MLD is not limited here.

[0280] 404A, non-AP MLD and the first AP MLD undergo authentication process and four-way handshake process;

[0281] 405A, non-AP MLD, and the first AP MLD each generate and save the same first PTK id;

[0282] In this embodiment, steps 404A and 405A are similar to steps 201A and 203A shown in Figure 2A, and will not be described in detail here.

[0283] It should be noted that a quick FT Probe and a quick FT-Multi-link Setup / Link Reconfiguration process are performed before the roaming process. After completion, the non-AP MLD has identified the second AP MLD to be roamed and has obtained the ID or address information of the second AP MLD. At the same time, the first AP MLD may also have obtained the ID or address of the second AP MLD.

[0284] 406A, the non-AP MLD sends the first request to the first AP MLD;

[0285] In this embodiment, step 406A is similar to step 205A as shown in Figure 2A, except that the first request in step 406A also includes the public key of the first AP MLD, i.e., the first public key.

[0286] 407A, the first AP MLD queries the key based on the key information;

[0287] In this embodiment, step 407A is similar to step 206A as shown in Figure 2A, and will not be described again here.

[0288] 408A: The first AP MLD encrypts the first PTK based on the second public key, generates the fourth PTK, and generates a digital signature using the first private key;

[0289] In this application, an asymmetric encryption algorithm can be used to encrypt the first PTK obtained from the query to generate a fourth PTK, and then a digital signature can be calculated based on the fourth PTK and the first private key to achieve encryption and integrity protection of the first PTK.

[0290] Because asymmetric encryption algorithms require two keys for encryption and decryption—a public key and a private key—they must possess both simultaneously. The public and private keys are mutually exclusive; if the public key is used to encrypt data, only the corresponding private key can decrypt it, and vice versa. The basic process of encrypting transmitted information using an asymmetric encryption algorithm is shown in Figure 4A-1. Specifically, Client A first generates a key pair, using one as the public key. Client B, having obtained the public key, then uses this key to encrypt the information before sending it to Client A. Client A then uses the corresponding private key to decrypt the encrypted information, thus achieving confidential data transmission.

[0291] To prevent tampering with transmitted information, a signature mechanism based on asymmetric encryption algorithms can be used, as shown in Figure 4A-2. When Client A sends ciphertext, it performs a hash calculation on the plaintext data and encrypts the resulting hash value using Client A's private key to obtain a signature. The signature and password are then sent to Client B. Upon receiving the data, Client B decrypts the ciphertext using its private key. To verify whether the decrypted data has been tampered with, it needs to calculate a hash value on the decrypted plaintext. Next, it needs to obtain the hash value recorded by Client A, which is stored in the digital signature. At this point, Client A's public key is used to decrypt the signature, obtaining the hash value calculated by the client on the plaintext before sending it. The two hash values ​​are compared; if they do not match, it indicates that the data has been modified.

[0292] It should be noted that (1) the hash value is calculated by Client A on the plaintext. The server performs a hash calculation on the decrypted plaintext. If it is inconsistent with the record of Client A, it means that the data has been tampered with; (2) Client A encrypts the hash value with its private key and sends it to Client B. Client B can only decrypt it using Client A's public key to obtain the hash value; the third party cannot tamper with the data unless it knows Client A's private key; (3) both parties should use the same hash algorithm Q.

[0293] In this embodiment of the application, the first AP MLD is equivalent to the aforementioned Client A, the second AP MLD is equivalent to the aforementioned Client B, the key to be protected (first PTK or first PMK) is equivalent to the aforementioned plaintext A, and the generated digital signature is equivalent to the aforementioned signature A.

[0294] 409A. The first AP MLD sends a second request to the second AP MLD;

[0295] In this embodiment, step 409A is similar to step 207A shown in Figure 2A. The difference is that the second request in step 409A includes the encrypted first PTK, i.e., the fourth PTK, and also includes a digital signature. Other details will not be elaborated here.

[0296] 410A, the second AP MLD verifies the digital signature and decrypts the fourth PTK to obtain the first PTK;

[0297] After obtaining the fourth PTK and the digital signature, the second AP MLD uses the first public key to verify the digital signature. If the verification is successful, it uses the second private key to decrypt the fourth PTK to obtain the first PTK and saves the first PTK. If the digital signature verification fails, or if the digital signature verification is successful but the decryption of the fourth PTK fails, the context transmission is determined to have failed.

[0298] The specific method for verifying the digital signature and decrypting the fourth PTK to obtain the first PTK can be the same as the Client B operations involved in step 408A, which will not be elaborated here.

[0299] 411A. The second AP MLD sends a second request response to the first AP MLD;

[0300] 412A. The first AP MLD sends a first request response to the non-AP MLD;

[0301] 413A, the non-AP MLD and the second AP MLD communicate based on the first PTK.

[0302] In this embodiment, steps 411A to 413A are similar to steps 208A to 210A shown in FIG2A, and will not be described again here.

[0303] It should be noted that in the above embodiment 4A, the first AP MLD receives key information from the non-AP MLD to query the key, i.e., the first PMK. In this application, the first AP MLD can also receive key information from the second AP MLD to query the key. Please refer to Figure 4B, which shows another communication method provided by an embodiment of this application, including but not limited to at least one of the following steps:

[0304] 401B. The management device configures the first public-private key pair on the first AP MLD;

[0305] 402B. The management device configures the first public / private key pair on the second AP MLD;

[0306] 403B, the first AP MLD and the second AP MLD exchange their respective public keys;

[0307] 404B, non-AP MLD and the first AP MLD perform authentication and four-way handshake procedures;

[0308] 405B, non-AP MLD, and the first AP MLD each generate and save the same first PTK id;

[0309] In this embodiment, steps 401B to 405B are similar to steps 401A to 405A shown in FIG4A, and will not be described again here.

[0310] 406B, the non-AP MLD sends the first request to the second AP MLD;

[0311] In this embodiment, step 406B is similar to step 205B shown in Figure 2B, except that the first request in step 406B also includes the first public key of the first AP MLD.

[0312] 407B, The second AP MLD sends a second request to the first AP MLD;

[0313] In this embodiment, step 407B is similar to step 206B shown in Figure 2B, except that the second request in step 407B also includes the second public key of the second AP MLD.

[0314] 408B, the first AP MLD queries the key based on the key information;

[0315] In this embodiment, step 408B is similar to step 207A shown in Figure 2A, and will not be described in detail here.

[0316] 409B. The first AP MLD encrypts the first PTK based on the second public key, generates the fourth PTK, and uses the first private key to generate a digital signature;

[0317] 410B, The first AP MLD sends a second request response to the second AP MLD;

[0318] In this embodiment, step 410B is similar to step 208B shown in Figure 2B, except that the second request response in step 208B includes the first PTK, while the second request response in step 410B includes the fourth PTK and also includes a digital signature.

[0319] 411B. The second AP MLD verifies the digital signature and decrypts the fourth PTK to obtain the first PTK;

[0320] In this embodiment, steps 409B and 411B are similar to steps 409A and 411A shown in Figure 4A, and will not be described again here.

[0321] 412B. The second AP MLD sends a first request response to the non-AP MLD;

[0322] 413B, the non-AP MLD and the second AP MLD communicate based on the first PTK.

[0323] In this embodiment, steps 412B and 413B are similar to steps 209A and 210A shown in Figure 2B, and will not be described again here.

[0324] Combining Figures 4A and 4B, the channel between the first AP MLD and the second AP MLD is insecure (e.g., wireless connection). Both can pre-configure public-private key pairs through an AC or other management unit. The first AP MLD uses asymmetric encryption and a digital signature to protect the first PTK and sends it to the second AP MLD. The second AP MLD verifies the digital signature and decrypts to obtain the first PTK. Subsequently, the non-AP MLD establishes a secure association between the first PTK and the second AP MLD, completing roaming preparation. The first and second AP MLDs each configure their own public-private key pairs and share their public keys with each other. Subsequent security context interactions use asymmetric encryption and digital signatures, effectively ensuring the confidentiality and integrity of the security context, preventing interception and tampering, and improving the security of the roaming process. Furthermore, the use of asymmetric encryption avoids interactions such as sharing the PMK between the first and second AP MLDs, simplifying the roaming process and reducing roaming latency.

[0325] Scenario 4: There is no secure channel between the first AP MLD and the second AP MLD, and different PTKs are used to communicate with the two before and after the non-AP MLD roams.

[0326] Please refer to Figure 5A for a possible communication method, which includes, but is not limited to, at least one of the following steps:

[0327] 501A. The management device configures the first public / private key pair on the first AP MLD;

[0328] 502A. The management device configures the first public / private key pair on the second AP MLD;

[0329] 503A, the first AP MLD and the second AP MLD exchange their respective public keys;

[0330] 504A, non-AP MLD and the first AP MLD perform authentication process and four-way handshake process;

[0331] 505A, non-AP MLD, and the first AP MLD each generate and save the same first PTK id;

[0332] In this embodiment, steps 501A to 505A are similar to steps 401A to 405A shown in FIG4A, and will not be described again here.

[0333] 506A, the non-AP MLD sends the first request to the first AP MLD;

[0334] In this embodiment, step 506A is similar to step 305A shown in Figure 3A, except that the first request in step 506A also includes the first public key of the first AP MLD. Other details will not be elaborated here.

[0335] 507A, the first AP MLD queries the key based on the key information;

[0336] In this embodiment, step 507A is similar to step 306A shown in Figure 3A, and will not be described again here.

[0337] 508A, the first AP MLD encrypts the first PTK and / or the first PMK based on the second public key, generates the fourth PTK and / or the fourth PMK, and generates a digital signature using the first private key;

[0338] In this embodiment, step 508A is similar to step 408A shown in Figure 4A, except that step 508A may use a similar method to encrypt the first PTK and / or the first PMK to generate the fourth PTK and / or the fourth PMK.

[0339] 509A. The first AP MLD sends a second request to the second AP MLD;

[0340] In this embodiment, step 509A is similar to step 307A shown in Figure 3A. The difference is that the second request in step 307 includes the first PMK and / or the first PTK, while the first request in step 509A includes the encrypted first PMK and / or the first PTK, i.e. the fourth PMK and / or the fourth PTK. The second request in step 509A also includes the digital signature generated in step 508A. Other details are not described here.

[0341] 510A, the second AP MLD verifies the digital signature and decrypts the fourth PTK and / or the fourth PMK to obtain the first PTK and / or the first PMK;

[0342] In this embodiment, step 510A is similar to step 410A shown in Figure 4A, except that step 510A may use a similar method to decrypt the fourth PTK and / or the fourth PMK to generate the first PTK and / or the first PMK. Other specific details will not be elaborated here.

[0343] 511A, The second AP MLD generates and saves the second PTK;

[0344] 512A. The second AP MLD sends a second request response to the first AP MLD;

[0345] 513A. The first AP MLD sends a first request response to the non-AP MLD;

[0346] 514A, non-AP MLD generates and saves the second PTK;

[0347] The 515A, non-AP MLD and the second AP MLD communicate based on the second PTK.

[0348] In this embodiment, steps 511A to 515A are similar to steps 308A to 312A shown in FIG3A, and will not be described again here.

[0349] It should be noted that in the above embodiments, the first AP MLD receives key information from the non-AP MLD to query the key, i.e., the first PMK and / or the first PTK. In this application, the first AP MLD can also receive key information from the second AP MLD to query the key. Please refer to Figure 5B, which shows another communication method provided by an embodiment of this application, including but not limited to at least one of the following steps:

[0350] 501B. The management device configures the first public-private key pair on the first AP MLD;

[0351] 502B. The management device configures the first public / private key pair on the second AP MLD;

[0352] 503B, the first AP MLD and the second AP MLD exchange their respective public keys;

[0353] 504B, non-AP MLD and the first AP MLD perform authentication and four-way handshake procedures;

[0354] 505B, non-AP MLD, and the first AP MLD each generate and save the same first PTK id;

[0355] In this embodiment, steps 501A to 505A are similar to steps 401A to 405A shown in FIG4A, and will not be described again here.

[0356] 506B, the non-AP MLD sends the first request to the second AP MLD;

[0357] In this embodiment, step 506B is similar to step 305B shown in Figure 3B, except that the first request in step 506B also includes the first public key of the first AP MLD. Other details will not be elaborated here.

[0358] 507B, The second AP MLD sends a second request to the first AP MLD;

[0359] In this embodiment, step 507B is similar to step 306B shown in Figure 3B, except that the second request in step 506B also includes the second public key of the second AP MLD. Other details will not be elaborated here.

[0360] 508B, the first AP MLD queries the key based on the key information;

[0361] In this embodiment, step 508B is similar to step 306A shown in Figure 3A, and will not be described in detail here.

[0362] 509B, The first AP MLD encrypts the first PTK and / or the first PMK based on the second public key, generates the fourth PTK and / or the fourth PMK, and generates a digital signature using the first private key;

[0363] In this embodiment, step 509B is similar to step 508A shown in Figure 5A, and will not be described in detail here.

[0364] 510B, The first AP MLD sends a second request response to the second AP MLD;

[0365] In this embodiment, step 510B is similar to step 308B shown in Figure 3B, except that the second request response in step 308B includes the first PTK and / or the first PMK, while the second request response in step 510B includes the encrypted first PTK and / or the first PMK, i.e., the fourth PTK and / or the fourth PMK, as well as the digital signature generated in step 509B. Other specific details will not be elaborated here.

[0366] 511B. The second AP MLD verifies the digital signature and decrypts the fourth PTK and / or the fourth PMK to obtain the first PTK and / or the first PMK;

[0367] In this embodiment, step 511B is similar to step 510A shown in Figure 5A, and will not be described in detail here.

[0368] 512B, The second AP MLD generates and saves the second PTK;

[0369] 513B, The second AP MLD sends a first request response to the non-AP MLD;

[0370] 514B, non-AP MLD generates and saves the second PTK;

[0371] The 515B non-AP MLD and the second AP MLD communicate based on the second PTK.

[0372] In this embodiment, steps 512B to 515B are similar to steps 309B to 312B shown in Figure 3B, and will not be described in detail here.

[0373] Furthermore, in Figures 5A and 5B above, both the non-AP MLD and the second AP MLD generate the same second PTK. In this application, the second AP MLD can also generate the second PTK and send it to the non-AP MLD, or the non-AP MLD can generate the second PTK and send it to the second AP MLD. The former will be used as an example for specific explanation below. Please refer to Figure 5C, which provides another possible communication method for an embodiment of this application, specifically including but not limited to at least one of the following steps:

[0374] 501C, The management device configures the first public-private key pair on the first AP MLD;

[0375] 502C, The management device configures the first public / private key pair on the second AP MLD;

[0376] 503C, the first AP MLD, and the second AP MLD exchange their respective public keys;

[0377] 504C, non-AP MLD and the first AP MLD perform authentication process and four-way handshake process;

[0378] The 505C, non-AP MLD, and first AP MLD each generate and save the same first PTK id;

[0379] In this embodiment, steps 501C to 505C are similar to steps 401A to 405A shown in FIG4A, and will not be described again here.

[0380] 506C, the non-AP MLD sends the first request to the first AP MLD;

[0381] 507C, the first AP MLD queries the key based on the key information;

[0382] 508C, the first AP MLD encrypts the first PTK and / or the first PMK based on the second public key, generates the fourth PTK and / or the fourth PMK, and generates a digital signature using the first private key;

[0383] 509C, The first AP MLD sends a second request to the second AP MLD;

[0384] 510C, the second AP MLD verifies the digital signature and decrypts the fourth PTK and / or the fourth PMK to obtain the first PTK and / or the first PMK;

[0385] 511C, The second AP MLD generates and saves the second PTK;

[0386] In this embodiment, steps 506C to 511C are similar to steps 506A to 511A shown in FIG5A, and will not be described again here.

[0387] 512C, the second AP MLD encrypts the second PTK to obtain the third PTK;

[0388] 513C, The second AP MLD sends a second request response to the first AP MLD;

[0389] 514C. The first AP MLD sends a first request response to the non-AP MLD;

[0390] 515C and non-AP MLD decrypt the third PTK to obtain the second PTK;

[0391] The 516C non-AP MLD and the second AP MLD communicate based on the second PTK.

[0392] In this embodiment, steps 512C to 516C are similar to steps 309C to 313C shown in FIG3C, and will not be described again here.

[0393] It should be noted that in Figure 5C above, the first AP MLD receives key information from the non-AP MLD (carried in the first request in step 506C) to query the key, namely the first PMK and / or the first PTK. If the second AP MLD generates the second PTK and encrypts it before sending it to the non-AP MLD, it can be similar to Figure 4B or Figure 5B, combined with the step of the first AP MLD receiving key information from the second AP MLD to query the key. The specifics will not be elaborated here.

[0394] Combining Figures 5A to 5C, the channel between the first AP MLD and the second AP MLD is insecure (e.g., wireless connection). Both can pre-configure public / private key pairs through an AC or other management unit. The first AP MLD uses asymmetric encryption and a digital signature to protect the first PMK or first PTK and sends it to the second AP MLD. The second AP MLD verifies the digital signature and decrypts to obtain the first PMK or first PTK. Subsequently, the non-AP MLD and the second AP MLD deduce the second PTK based on the PMK or PTK respectively, and establish a secure association based on the second PTK, completing roaming preparation. The non-AP MLD and the second AP MLD re-deduce a new PTK based on keys such as PTK or PMK, random numbers, and addresses, effectively providing a key isolation mechanism. This ensures that the non-AP MLD uses different PTKs with different AP MLDs, limiting attacks to the non-AP MLD and malicious AP MLDs, thus protecting the security of data transmitted between the non-AP MLD and other AP MLDs, thereby improving the overall security and reliability of the system.

[0395] The figures above illustrate in detail the communication methods provided in the embodiments of this application. Please refer to Figure 6, which is a storage diagram of a wireless communication device in an embodiment of this application. The wireless communication device includes a processor and a memory. The memory stores computer programs, and the processor calls and runs the computer programs stored in the memory to execute the methods provided by any embodiment of the channel determination method or channel switching method of this application, as well as any non-conflicting combination thereof. The storage medium 20 of the wireless communication device in this embodiment stores instruction / program data 21. When this instruction / program data 21 is executed, it implements the methods provided by any embodiment of the communication method of this application, as well as any non-conflicting combination thereof. The instruction / program data 21 can be formed into a program file and stored in the storage medium 20 in the form of a software product, so that a computer device (which may be a personal computer, server, or network device, etc.) or processor executes all or part of the steps of the methods in various embodiments of this application. The aforementioned storage medium 20 includes various media capable of storing program code, such as a USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or terminal devices such as computers, servers, mobile phones, and tablets.

[0396] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0397] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0398] The above are merely embodiments of this application and do not limit the scope of this patent application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

[0399] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0400] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0401] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0402] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0403] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0404] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0405] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0406] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0407] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0408] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0409] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method applied to a non-AP side, characterized in that, include: Send a first request to a first site AP or a second AP, wherein the first AP is the AP currently associated with the non-AP, the first request is used to request roaming from the first AP to the second AP, and the first request includes key information, the key information being used by the first AP to query a key; When the first AP finds the key, it receives a first request response sent by either the first AP or the second AP.

2. The method according to claim 1, characterized in that, The first AP and the second AP are in the same mobile domain SMD.

3. The method according to claim 1 or 2, characterized in that, When the communication method is applied to a multi-link scenario, the first AP is a first AP multi-link device (MLD), the second AP is a second AP MLD, and the non-AP is a non-AP MLD.

4. The method according to any one of claims 1 to 3, characterized in that, Before sending the first request to the first AP or the second AP, the method further includes: The authentication and association processes are performed with the first AP; Perform a four-way handshake process with the first AP.

5. The method according to claim 4, characterized in that, After performing the four-way handshake process with the first AP, the method further includes: Generate and save the first master key PMK; A first temporary key PTK is generated based on the first PMK, and both the first PMK and the first PTK are shared with the first AP.

6. The method according to claim 5, characterized in that, After generating the first PTK based on the first PMK, the method further includes: Obtain the first PTK identifier information ID, which is shared by the first AP; And / or, Obtain the first PMK id, which is shared by the first AP.

7. The method according to claim 6, characterized in that, Obtaining the first PTK ID includes: The first PTK id is generated based on one or more of the following information: the first PTK, the first PMK, the first PMK id, the PMKR1 Name, the random number on the non-AP side, the random number on the first AP side, the IDs of the BSS where the first AP and the non-AP are located, the address information of the non-AP, the address information of the first AP, and / or a specific string.

8. The method according to claim 7, characterized in that, The method further includes: Send the first PTK id to the first AP.

9. The method according to claim 6, characterized in that, Obtaining the first PTK ID includes: Receive the first PTK id sent by the first AP.

10. The method according to claim 6, characterized in that, Obtaining the first PMK ID includes: The first PMK ID is generated based on one or more of the following information: the first PMK, the name of the first PMK, AA, SPA, random number on the first AP side, random number on the non-AP side, the ID of the BSS where the first AP and the non-AP are located, the address information of the non-AP, and the address information of the first AP.

11. The method according to claim 10, characterized in that, The method further includes sending the first PMK id to the first AP.

12. The method according to claim 6, characterized in that, Obtaining the PMK id includes: receiving the first PMK id sent by the first AP.

13. The method according to any one of claims 1 to 12, characterized in that, Before sending the first request to the first AP or the second AP, the method further includes: The second AP is determined to be the AP to be switched.

14. The method according to any one of claims 6 to 13, characterized in that, When the first request is sent to the first AP, the key information includes, but is not limited to, at least one of the following parameters: the first PTK id and / or the first PMK id, the non-AP id or the non-AP address information, and a non-AP side random number.

15. The method according to claim 14, characterized in that, The first request response is sent by the first AP. When the first AP queries the corresponding first PTK and / or first PMK based on the first request, the first request response is used to indicate that roaming is successful or roaming preparation is successful.

16. The method according to any one of claims 6 to 13, characterized in that, When the first request is sent to the second AP, the key information includes, but is not limited to, at least one of the following parameters: the first PTK id and / or the first PMK id, the non-AP id or the address information of the non-AP, the first AP id or the address information of the first AP, and a random number on the non-AP side.

17. The method according to claim 16, characterized in that, The first request response is sent by the second AP.

18. The method according to claim 16 or 17, characterized in that, The first request response also includes a second AP-side random number.

19. The method according to claim 18, characterized in that, The method further includes: Based on the non-AP side random number, the second AP side random number, the first PTK / the first PMK, a second PTK is generated and saved, and the second PTK is shared by the second AP.

20. The method according to any one of claims 14 to 17, characterized in that, The first request response also includes a third PTK, which is obtained by encrypting the second PTK based on the first PTK / the first PMK.

21. The method according to claim 20, characterized in that, The method further includes: Based on the first PMK or the first PTK, the third PTK is decrypted to obtain and save the second PTK.

22. The method according to claim 14 or 16, characterized in that, Before sending the first request to the first site AP or the second AP, the method further includes: Receive the first public key sent by the first AP, the first public key being configured on the first AP by the management device; The first request also includes the first public key.

23. A communication method applied to a first AP side, characterized in that, include: Receive key information sent by a non-AP or a second AP, wherein the first AP is associated with the non-AP and the second AP is the destination AP for which the non-AP requests roaming; The key is queried based on the key information, and the result of the key query is used to indicate whether roaming is successful or roaming preparation is successful.

24. The method according to claim 23, characterized in that, The key information includes, but is not limited to, at least one of the following: a first PTK id and / or a first PMK id, the non-AP id or the address information of the non-AP, the first AP id or the address information of the first AP, and a non-AP side random number; the key includes the first PMK and / or the first PTK.

25. The method according to claim 24, characterized in that, The key information received from the non-AP or the second AP includes: Receive a first request sent by the non-AP, the first request being for requesting roaming from the first AP to the second AP, the first request including the key information; or... Receive a second request sent by the second AP, the second request including the key information.

26. The method according to claim 25, characterized in that, After querying the key based on the key information, the method further includes: The key is sent to the second AP.

27. The method according to claim 26, characterized in that, Sending the key to the second AP includes: The key is encrypted and sent to the second AP.

28. The method according to claim 27, characterized in that, The encryption of the key includes: The first PTK and / or the first PMK are encrypted using the second public key to generate the second PTK and / or the second PMK. A digital signature file is generated using a first public key, wherein the first public key is the public key in the first public-private key pair configured by the management device for the first AP, and the second public key is the public key in the second public-private key pair configured by the management device for the second AP. The first AP and the second AP exchange their respective public keys.

29. The method according to any one of claims 26 to 28, characterized in that, When receiving the first request sent by the non-AP, sending the key to the second AP includes: A third request is sent to the second AP, the third request including the key.

30. The method according to claim 29, characterized in that, After sending the third request to the second AP, the method further includes: Receive the third request response sent by the second AP; Send a first request response to the non-AP, the first request response being used to indicate successful roaming or successful roaming preparation.

31. The method according to any one of claims 26 to 28, characterized in that, When receiving a second request from the second AP, sending the key to the second AP includes: Send a second request response to the second AP, the second request response including the key.

32. The method according to any one of claims 23 to 31, characterized in that, Before receiving the key information sent by the non-AP or the second AP, the method further includes: The authentication and association processes are performed with the non-AP. Perform a four-way handshake process with the non-AP.

33. The method according to claim 32, characterized in that, After performing the four-way handshake process with the non-AP, the method further includes: Generate and save the first master key PMK; A first PTK is generated based on the first PMK, and the first PMK and the first PTK are shared with the non-AP.

34. The method according to claim 33, characterized in that, After generating the first PTK based on the first PMK, the method further includes: Obtain the first PTK ID, which is shared by the non-AP. And / or, Obtain the first PMK id, which is shared by the non-AP.

35. The method according to claim 34, characterized in that, Obtaining the first PTK ID includes: The first PTK id is generated based on one or more of the following information: the first PTK, the first PMK, the first PMK id, the PMKR1 Name, the random number on the non-AP side, the random number on the first AP side, the IDs of the BSS where the first AP and the non-AP are located, the address information of the non-AP, the address information of the first AP, and / or a specific string.

36. The method according to claim 35, characterized in that, The method further includes: Send the first PTK id to the non-AP.

37. The method according to claim 34, characterized in that, Obtaining the first PTK ID includes: Receive the first PTK id sent by the non-AP.

38. The method according to claim 34, characterized in that, Obtaining the first PMK ID includes: The first PMK ID is generated based on one or more of the following information: the first PMK, the name of the first PMK, AA, SPA, random number on the first AP side, random number on the non-AP side, the ID of the BSS where the first AP and the non-AP are located, the address information of the non-AP, and the address information of the first AP.

39. The method according to claim 38, characterized in that, The method further includes sending the first PMK id to the non-AP.

40. The method according to claim 34, characterized in that, Obtaining the PMK id includes: receiving the first PMK id sent by the non-AP.

41. The method according to any one of claims 34 to 40, characterized in that, The key information includes, but is not limited to, at least one of the following parameters: the first PTK id and / or the first PMK id, the non-AP id or the non-AP address information, and a non-AP side random number.

42. The method according to claim 41, characterized in that, The key query based on the key information includes: When the key information includes the first PTK id, based on the correspondence between PTK id and PTK, query whether there exists a first PTK corresponding to the first PTK id; And / or, When the key information includes the first PMK id, based on the correspondence between PMK id and PMK, query whether there exists a first PMK corresponding to the first PMK id.

43. The method according to claim 41, characterized in that, The key query based on the key information includes: When the key information includes the non-AP id or the non-AP address information, based on the correspondence between the device identifier or device address and the PTK, query whether there is a first PTK corresponding to the non-AP id or the non-AP address information; And / or, Based on the correspondence between device identifier or device address and PMK, query whether the first PMK corresponding to the non-AP id or the non-AP address information exists.

44. The method according to claim 41, characterized in that, The key query based on the key information includes: When the key information includes the first PTK id and the non-AP id or the non-AP address information, based on the correspondence between PTK id and PTK, the first PTK1 corresponding to the first PTK id is found, and based on the correspondence between device identifier or device address and PTK, the first PTK2 corresponding to the non-AP id or the non-AP address information is found. If the first PTK1 is the same as the first PTK2, then the first PTK1 is determined to be the first PTK; And / or, When the key information includes the first PMK id and the non-AP id or the non-AP address information, based on the correspondence between the PTK id and PMK, the first PMK1 corresponding to the first PMK id is queried, and based on the correspondence between the device identifier or device address and PMK, the first PMK2 corresponding to the non-AP id or the non-AP address information is queried; If the first PMK1 is the same as the first PMK2, then the first PMK1 is determined to be the first PMK.

45. The method according to any one of claims 41 to 44, characterized in that, The first context forwarding request includes, but is not limited to, at least one of the following: the first PTK and / or the first PMK, the non-AP id or the non-AP address information, and a non-AP side random number.

46. ​​The method according to claim 45, characterized in that, The third request also includes the first public key.

47. The method according to claim 45 or 46, characterized in that, The third request response includes a second AP-side random number; the first request response includes a second AP-side random number.

48. The method according to any one of claims 41 to 44, characterized in that, The second request also includes the second public key.

49. The method according to any one of claims 23 to 48, characterized in that, The first AP and the second AP are in the same mobile domain SMD.

50. The method according to any one of claims 23 to 49, characterized in that, When the communication method is applied to a multi-link scenario, the first AP is a first AP multi-link device (MLD), the second AP is a second AP MLD, and the non-AP is a non-AP MLD.

51. A communication method applied to a second AP side, characterized in that, include: Receive the key sent by the first AP; Based on the key or the processed key, communication is conducted with the non-AP. The first AP is associated with the non-AP, and the second AP is the destination AP for the non-AP to request roaming.

52. The method according to claim 51, characterized in that, The key includes a first PTK and / or a first PMK.

53. The method according to claim 51 or 52, characterized in that, Before receiving the key sent by the first AP, the method further includes: Receive a first request sent by the non-AP, the first request being used to request the triggering of a roaming process, the first request carrying key information; A second request is sent to the first AP, the second request carrying the key information.

54. The method according to claim 53, characterized in that, The key information includes, but is not limited to, at least one of the following: the first PTK id and / or the first PMK id, the non-AP id or address information, and the non-AP side random number.

55. The method according to claim 52, characterized in that, The key for receiving the first AP includes: Receive a third request sent by the first AP, the third request including but not limited to the following information: the first PTK and / or the first PMK, the non-AP ID or address information, and the non-AP side random number.

56. The method according to claim 55, characterized in that, The method further includes: The second PTK is generated using the third request and the second AP-side random number; A third request response is sent to the first AP, the third request response carrying a random number from the second AP side.

57. The method according to claim 56, characterized in that, The method further includes: The second PTK is generated using the third request and the second AP-side random number; The second PTK is encrypted based on the first PTK and / or the first PMK to obtain the third PTK; The third PTK is sent to the non-AP MLD.

58. The method according to claim 56, characterized in that, The processed key includes the second PTK.

59. The method according to any one of claims 51 to 58, characterized in that, The method further includes: The two APs exchange public keys from their respective public-private key pairs. The first AP corresponds to the first public-private key pair, and the second AP corresponds to the second public-private key pair.

60. The method according to claim 59, characterized in that, The first request includes the first public key in the first public-private key pair, and the second request includes the public key in the second public-private key pair.

61. The method according to claim 60, characterized in that, The second request response includes a first PTK and / or a first PMK encrypted based on the second public key, and a digital signature generated based on the first private key in the first public-private key pair.

62. The method according to claim 59, characterized in that, The second request also includes a first PTK and / or a first PMK encrypted based on the second public key, and a digital signature generated based on the first private key in the first public-private key pair.

63. The method according to claim 61 or 62, characterized in that, The method further includes: Verify the digital signature based on the first public key; The encrypted first PTK and / or first PMK are decrypted based on the second private key in the second public-private key pair to obtain the first PTK and / or first PMK.

64. The method according to claim 63, characterized in that, After decrypting the encrypted first PTK and / or first PMK based on the second private key in the second public-private key pair to obtain the first PTK and / or first PMK, the method further includes: Generate a fourth PTK based on the first PTK and / or the first PMK; The fourth PTK is encrypted based on the first PTK and / or the first PMK to generate the fifth PTK; Send the fifth PTK to the non-AP.

65. The method according to claim 64, characterized in that, Sending the fifth PTK to the non-AP includes: The fifth PTK is sent to the non-AP via the first AP.

66. The method according to any one of claims 51 to 65, characterized in that, The first AP and the second AP are in the same mobile domain SMD.

67. The method according to any one of claims 51 to 66, characterized in that, When the communication method is applied to a multi-link scenario, the first AP is a first AP multi-link device (MLD), the second AP is a second AP MLD, and the non-AP is a non-AP MLD.

68. A wireless communication device, comprising: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method as described in any one of claims 1 to 67.

69. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed, cause the method according to any one of claims 1 to 67 to be implemented.

Images