Information frame transmission method, device and computer readable storage medium

Abstract

The application provides an information frame transmission method, device and computer readable storage medium. The method comprises the following steps: sending a first information frame to a second device; wherein the first information frame comprises public key information of the first device and ML-KEM information; receiving a second information frame sent by the second device; wherein the second information frame comprises encrypted text information based on the public key information, a first MIC and ML-KEM information of the second device; decrypting the encrypted text information based on private key information of the first device to obtain a first ML-KEM shared key; generating a second MIC according to the first ML-KEM shared key; and sending a third information frame to the second device; wherein the third information frame comprises the second MIC.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an information frame transmission method, device and computer-readable storage medium. Background Technology

[0002] WiFi (Wireless Network Communication Technology) connection involves three phases: Probe, Authentication, and Association. In the Probe phase, the Station (STA) searches for an Access Point (AP). In the Authentication phase, the AP authenticates the STA. After successful authentication, the STA connects to the AP in the Association phase.

[0003] According to the IEEE (Institute of Electrical and Electronics Engineers) 802.11az protocol, in an infrastructure BSS network, a STA (Station) not associated with an AP can use the Pre-association Sexurity Negotiation (PASN) process to establish a Pairwise Transient Key Security Association (PTKSA) with the AP. Currently, this PASN interaction is based on traditional public-key algorithms, which are vulnerable to attacks from quantum computers, posing potential security risks. Therefore, improving the security of PASN interactions is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] This application provides an information frame transmission method, device, and computer-readable storage medium.

[0005] In a first aspect, embodiments of this application provide an information frame transmission method, applied to a first device, comprising:

[0006] Send a first information frame to the second device; wherein the first information frame includes the public key information of the first device and ML-KEM-based information;

[0007] Receive a second information frame sent by the second device; wherein the second information frame includes encrypted text information based on the public key information, a first MIC, and ML-KEM information of the second device;

[0008] The encrypted text information is decrypted based on the private key information of the first device to obtain the first ML-KEM shared key;

[0009] Generate a second MIC based on the first ML-KEM shared key;

[0010] A third information frame is sent to the second device; wherein the third information frame includes the second MIC.

[0011] Secondly, embodiments of this application provide an information frame transmission method, applied to a second device, comprising:

[0012] Receive a first information frame sent by the first device; wherein the first information frame includes the public key information and ML-KEM information of the first device;

[0013] Based on the public key information, encrypted text information and a second ML-KEM shared key are generated, and a first MIC is generated based on the second ML-KEM shared key;

[0014] Send a second information frame to the first device; wherein the second information frame includes the encrypted text information, the first MIC, and the ML-KEM information of the second device;

[0015] The system receives a third information frame sent by the first device; wherein the third information frame includes a second MIC generated by the first device.

[0016] Thirdly, embodiments of this application provide an information frame transmission method, applied to a first device, comprising:

[0017] Send a first information frame to the second device; wherein the first information frame includes the first public key information and ML-KEM information of the first device;

[0018] Receive a second information frame sent by the second device; wherein the second information frame includes first encrypted text information based on the first public key information, the second public key information of the second device, and the ML-KEM information of the second device;

[0019] Based on the first private key information of the first device, the first encrypted text information is decrypted to obtain the first ML-KEM shared key;

[0020] Generate a second encrypted text message and a second ML-KEM shared key based on the second public key information;

[0021] A first MIC is generated based on at least one of the first ML-KEM shared key and the second ML-KEM shared key;

[0022] Send a third information frame to the second device; wherein the third information frame includes the second encrypted text information and the first MIC;

[0023] The device receives a fourth information frame sent by the second device; wherein the fourth information frame includes a second MIC generated by the second device.

[0024] Fourthly, embodiments of this application provide an information frame transmission method, applied to a second device, comprising:

[0025] Receive a first information frame sent by the first device; wherein the first information frame includes the first public key information and ML-KEM information of the first device;

[0026] Generate a first encrypted text message and a third ML-KEM shared key based on the first public key information;

[0027] Send a second information frame to the first device; wherein the second information frame includes the first encrypted text information, the second public key information of the second device, and the ML-KEM information of the second device;

[0028] The device receives a third information frame sent by the first device; wherein the third information frame includes second encrypted text information based on the second public key information and a first MIC generated by the first device.

[0029] Based on the second private key information of the second device, the second encrypted text information is decrypted to obtain the fourth ML-KEM shared key;

[0030] A second MIC is generated based on at least one of the third ML-KEM shared key and the fourth ML-KEM shared key;

[0031] A fourth information frame is sent to the first device; wherein the fourth information frame includes the second MIC.

[0032] Fifthly, embodiments of this application provide a communication device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the information frame transmission method provided in any one of the first to fourth aspects of embodiments of this application.

[0033] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the information frame transmission method provided in any one of the first to fourth aspects of embodiments of this application.

[0034] Further details regarding the above embodiments and other aspects of this application, as well as their implementations, are provided in the accompanying drawings, detailed description, and claims. Attached Figure Description

[0035] Figure 1 A flowchart illustrating an information frame transmission method provided in an embodiment of this application;

[0036] Figure 2 This is a schematic diagram illustrating an interaction between communication devices transmitting authentication frames, provided in an embodiment of this application.

[0037] Figure 3 A schematic diagram of the structure of the first information frame provided in an embodiment of this application;

[0038] Figure 4 This is a schematic diagram of the structure of a second information frame provided in an embodiment of this application;

[0039] Figure 5 Another flowchart illustrating the information frame transmission method provided in this application embodiment;

[0040] Figure 6 This is another flowchart illustrating the information frame transmission method provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram illustrating an interaction of information frames transmitted between communication devices according to an embodiment of this application.

[0042] Figure 8 Another structural schematic diagram of the first information frame provided in the embodiments of this application;

[0043] Figure 9 Another structural diagram of the second information frame provided in the embodiments of this application;

[0044] Figure 10 A schematic diagram of the structure of a third information frame provided in an embodiment of this application;

[0045] Figure 11 A schematic diagram of the structure of the fourth information frame provided in an embodiment of this application;

[0046] Figure 12 A schematic flowchart illustrating another information frame transmission method provided in this application embodiment.

[0047] Figure 13 This is another interactive schematic diagram of information frame transmission between communication devices provided in an embodiment of this application;

[0048] Figure 14 A schematic diagram of the structure of the first public key information provided in the embodiments of this application;

[0049] Figure 15 Another structural schematic diagram of the first information frame provided in the embodiments of this application;

[0050] Figure 16Another schematic diagram of the structure of the second information frame provided in the embodiments of this application;

[0051] Figure 17 A schematic diagram of the structure of an information frame transmission device provided in an embodiment of this application;

[0052] Figure 18 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application;

[0053] Figure 19 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application;

[0054] Figure 20 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application;

[0055] Figure 21 This is another flowchart illustrating the information frame transmission method provided in an embodiment of this application;

[0056] Figure 22 This is another interactive schematic diagram of information frame transmission between communication devices provided in the embodiments of this application;

[0057] Figure 23 This is another flowchart illustrating the information frame transmission method provided in an embodiment of this application;

[0058] Figure 24 This is another flowchart illustrating the information frame transmission method provided in an embodiment of this application;

[0059] Figure 25 This is another interactive schematic diagram of information frame transmission between communication devices provided in the embodiments of this application;

[0060] Figure 26 This is another flowchart illustrating the information frame transmission method provided in an embodiment of this application;

[0061] Figure 27 This is another interactive schematic diagram of information frame transmission between communication devices provided in the embodiments of this application;

[0062] Figure 28 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application;

[0063] Figure 29 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application;

[0064] Figure 30 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application;

[0065] Figure 31This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application;

[0066] Figure 32 This is a schematic diagram of a communication device provided in an embodiment of this application. Detailed Implementation

[0067] It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0068] This application provides an information frame transmission method, communication device, and storage medium. Compared with traditional methods, this application binds the ML-KEM algorithm with the PASN interaction process, reducing the risk of quantum computer attacks and thus improving the security of PASN interaction. Based on this, this application provides two PASN interaction schemes: one is a PASN interaction process based on a single ML-KEM, and the other is a PASN interaction process based on two ML-KEMs. The following embodiments first describe the PASN interaction process based on a single ML-KEM:

[0069] Figure 1 This is a flowchart illustrating an information frame transmission method provided in an embodiment of this application. The method can be applied to a first device, which in this embodiment can be a STA, AP, or Seamless Mobility Domain Management Entity (SMD-ME). The second device can also be a STA, AP, or SMD-ME. The first and second devices can perform a PASN interaction process through three information frames, and negotiate and generate key information based on this. Figure 1 As shown, the method may include:

[0070] S101. Send a first information frame to the second device; wherein the first information frame includes the public key information and ML-KEM information of the first device.

[0071] S102, Receive a second information frame sent by the second device; wherein the second information frame includes encrypted text information based on public key information, a first message integrity code (MIC) and the ML-KEM information of the second device.

[0072] S103. Decrypt the encrypted text information based on the private key information of the first device to obtain the first ML-KEM shared key.

[0073] S104. Generate a second MIC based on the first ML-KEM shared key.

[0074] S105, Send a third information frame to the second device; wherein the third information frame includes the second MIC.

[0075] Optionally, the first device described above may include one of the following:

[0076] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0077] The second device mentioned above may include one of the following:

[0078] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0079] In this embodiment, the first device and the second device exchange three information frames to implement the PASN interaction process. That is, the first, second, and third information frames can be PASN authentication frames. The PASN interaction process can be a security negotiation between AP and STA, a security negotiation between APs, a security negotiation between STAs, a security negotiation between STA and SMD-ME, or a security negotiation between SMD-MEs.

[0080] Figure 2 This is a schematic diagram illustrating an interaction between a first device and a second device for transmitting authentication frames, as provided in an embodiment of this application. Figure 2 As shown, the first device and the second device interact through three authentication frames to generate and transmit key information, and verify whether the key information negotiated by both parties is consistent through the first MIC and the second MIC.

[0081] Optionally, before the first device sends the first information frame, the first device may also receive a seventh information frame sent by the second device; wherein the seventh information frame includes PASN indication information supporting ML-KEM, to inform the first device that it supports PASN interaction based on ML-KEM. The seventh information frame can be various types of management frames, such as Beacon frames periodically sent by the second device, probe response frames replied by the second device, Multi-Access Point Coordination (MAPC) action frames, or other types of management frames (e.g., the RSNXE field in the management frame contains PASN indication information supporting ML-KEM).

[0082] The first device obtains the capabilities of the second device through the seventh information frame and decides whether to join the network. If it decides to join, the first device generates a pair of public key information and private key information based on the ML-KEM algorithm. The length of the public key information and private key information is related to the ML-KEM algorithm. The first device can send the generated public key information and ML-KEM information to the second device in the first information frame, and store the private key information locally. Figure 3 A schematic diagram of the structure of the first information frame provided in an embodiment of this application is shown below. Figure 3 As shown, the first information frame may include frame number (1), frame type information (PASN), RSNE, RSNXE of the first device, public key information, PASN parameters, and AKMP Data-1 based information.

[0083] The ML-KEM information can be either an indication of the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, Authentication and Key Management Protocol (AKMP) field, and / or Authentication algorithm numbers field. For example, the ML-KEM information can be located in the Authentication Key Management (AKM) subfield of the RSNE field in the first information frame.

[0084] Optionally, the ML-KEM information includes an ML-KEM-based authentication mode and / or an ML-KEM type. For example, the ML-KEM-based authentication mode may be included in the AKMP field of the first information frame, and the ML-KEM type may be included in the authentication algorithm number field or the AKMP field of the first information frame. Optionally, the ML-KEM-based authentication mode may include at least one of the following: an ML-KEM-based Open mode (i.e., an authentication-free mode), a peer-to-peer authentication mode based on password and ML-KEM, a ML-KEM-based Fast Initial Link Setup (FILS) mode, or a ML-KEM-based Fast Basic Service Set Transition (FT) mode.

[0085] Optionally, based on the difference in the length of the public key information / private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding public key information / private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0086] After receiving the first information frame, the second device locally generates a random number, and based on this random number and the first device's public key information, generates encrypted text information and a second ML-KEM shared key, and generates a first MIC based on the second ML-KEM shared key. The first MIC is used by the first device to verify whether the key information negotiated by both communicating parties is consistent. Optionally, the second device may generate a second PTK based on the second ML-KEM shared key, generate a second key confirmation key (KCK) based on the second PTK, and generate the first MIC based on the second KCK. Further, the second device sends a second information frame to the first device, the second information frame including encrypted text information, its supported / selected ML-KEM information, and the first MIC. Figure 4 This is a schematic diagram of the structure of a second information frame provided in an embodiment of this application, such as... Figure 4 As shown, the second information frame may include frame number (2), frame type information (PASN), RSNE and RSNXE of the second device, encrypted text information (ciphertext), PASN parameters, AKMP Data-2 information, and the first MIC generated by the second device.

[0087] Optionally, after receiving the first information frame, the second device may further detect whether the length / type of the public key information contained in the first information frame matches the ML-KEM type indicated in the first device's ML-KEM information. If they do not match, the second device may indicate the mismatch between the public key information and the ML-KEM type via the second information frame, or send a fourth information frame to the first device. The fourth information frame contains indication information indicating the mismatch between the public key information and the ML-KEM type. For example, the fourth information frame could be a deauthentication request frame. After receiving the fourth information frame, the first device terminates the PASN process.

[0088] The first device receives the second information frame sent by the second device, decrypts the encrypted text information based on the private key information corresponding to the public key information to obtain the first ML-KEM shared key, generates the second MIC based on the first ML-KEM shared key, and sends a third information frame to the second device, the third information frame containing the second MIC.

[0089] Specifically, the first device can generate the first PTK based on the first ML-KEM shared key and a certain algorithm. Optionally, the first device can generate the first PTK in one of the following ways:

[0090] Method 1: Generate the first PTK based on the pairwise master key (PMK), the first ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation (Pre-Association Secure Negotiation Pairwise Transport Key Derivation), and a hash function. For example, the algorithm for generating the first PTK is as follows:

[0091] PTK = KDF-HASH-NNN(PMK, "PASN PTK Derivation", DEV1 MAC address information || DEV2 MAC address information || First ML-KEM shared key);

[0092] KDF-HASH-NNN: a hash function. The specific hash function information is determined by the key suite information in the RSNE field of the second information frame. The hash function can be a hash function of the SHA3 class, such as SHA3-256 or SHA3-512.

[0093] PMK: Paired master key information;

[0094] PASN PTK Derivation: A type of tag;

[0095] DEV1 MAC address information: Basic Service Set Identifier (BSSID) information of the first device, or its corresponding AP or STA Multi-Link Device (MLD) MAC address information, or Transmitter Address (TA) information, or SMD-ME MAC address;

[0096] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD MAC or non-APMLD MAC address information, or Receiver Address (RA) information, or SMD-ME MAC address;

[0097] First ML-KEM shared key: represents the shared key obtained by the first device from decrypting encrypted text information based on the private key information;

[0098] ||: Connector symbol.

[0099] Method 2: The first device can also directly determine the first ML-KEM shared key as the first PTK.

[0100] After generating the first PTK, the first device can split the first PTK to obtain the first KCK, the first Temporary Key (TK), the first Key Derivation Key (KDK), and the first Key Encryption Key (KEK). Therefore, the length of the first PTK is determined by the sum of the lengths of the first KCK, the first TK, the first KDK, and the first KEK.

[0101] First PTK_bits = First KCK_bits + First TK_bits + First KDK_bits + First KEK_bits;

[0102] First KCK = ExtractBits(First PTK, 0, First KCK_bits);

[0103] First KEK = ExtractBits(First PTK, First KCK_bits, First KEK_bits);

[0104] First TK = ExtractBits(First PTK, First KCK_bits + First KEK_bits, First TK_bits);

[0105] First KDK = ExtractBits(First PTK, First KCK_bits + First KEK_bits + First TK_bits, First KDK_bits).

[0106] Where ExtractBits is the number of bits captured, FirstKCK_bits is the number of bits in the first KCK, FirstTK_bits is the number of bits in the first TK, FirstKEK_bits is the number of bits in the first KEK, and FirstKDK_bits is the number of bits in the first KDK.

[0107] Among them, the first KCK is used to verify the first MIC and generate the second MIC, the first TK is used to encrypt subsequent data frames or other management frames, the first KDK is used to generate other key information, and the first KEK is used to encrypt authentication frames.

[0108] After obtaining the first KCK, the first device can generate the second MIC using at least one of the following parameters: public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the first information frame, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and the first KCK.

[0109] Optionally, if decryption of the encrypted text information based on the private key information fails, the first device may discard the second information frame, not send the third information frame, or send a fifth information frame to the second device. The status code in the fifth information frame is used to indicate that the decryption of the encrypted text information has failed, thereby terminating the PASN interaction process. Optionally, the first device may also indicate that the decryption of the encrypted text information has failed through the status code in the third information frame.

[0110] Optionally, the first device generates a fourth MIC based on a preset algorithm and a first ML-KEM shared key, and verifies whether the fourth MIC is the same as the first MIC. If the fourth MIC is different from the first MIC (i.e., the first MIC verification fails), the first device may discard the second information frame, not send the third information frame, or send a fifth information frame to the second device. The status code in the fifth information frame is used to indicate that the first MIC verification failed, thereby terminating the PASN interaction process. For example, the fifth information frame may be a deauthentication request frame. Optionally, the first device may also indicate that the first MIC verification failed through the status code in the third information frame.

[0111] Optionally, if the encrypted text information is successfully decrypted using the private key information, and the fourth MIC is the same as the first MIC (i.e. the first MIC is successfully verified), then the status code in the third information frame indicates a success message.

[0112] Optionally, the first device may generate the fourth MIC using at least one of the following parameters: public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the second information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and first KCK.

[0113] Optionally, after receiving the third information frame, the second device calculates the third MIC based on a preset algorithm and the second ML-KEM shared key, and verifies whether the third MIC is the same as the second MIC. If the third MIC and the second MIC are the same, the second device determines that the key negotiated with the first device is the same; otherwise, if the third MIC and the second MIC are different, the second device determines that the key negotiated with the first device is different. The key includes the ML-KEM shared key, PTK, KCK, TK, KDK, and / or KEK. Further, the second device can also send a sixth information frame to the first device. The sixth information frame can be understood as a response frame to the third information frame, containing the verification result of the second MIC. If the third MIC is different from the second MIC (i.e., the second MIC verification fails), the status code in the sixth information frame indicates a failure; in this case, the sixth information frame can be an information frame terminating the PASN interaction process. If the third MIC is the same as the second MIC (i.e., the second MIC verification succeeds), the status code in the sixth information frame indicates a success.

[0114] Optionally, if the second MIC is successfully verified by the third MIC, the second device calls the MLME-SETKEYS.request primitive to install the locally generated key information.

[0115] Optionally, if the first device receives a sixth information frame indicating success from the second device, the first device may call the MLME-SETKEYS.request primitive to install the locally generated key information.

[0116] During PASN interaction, an ML-KEM shared key is generated based on the ML-KEM algorithm (the first ML-KEM shared key for the first device and the second ML-KEM shared key for the second device). Other key information (such as PTK, KCK, TK, KDK and / or KEK) is further generated based on the ML-KEM shared key, making the generated key information resistant to quantum computer attacks, thereby improving the security of Wi-Fi system communication.

[0117] Figure 5This is another schematic flowchart illustrating the information frame transmission method provided in this application embodiment. This method can be applied to a second device. In this embodiment, the first device can be a STA, AP, or SMD-ME, and the second device can also be a STA, AP, or SMD-ME. The first and second devices can perform a PASN interaction process through three information frames, and negotiate and generate key information based on this. Figure 5 As shown, the method may include:

[0118] S501, Receive a first information frame sent by the first device; wherein the first information frame includes the public key information and ML-KEM information of the first device.

[0119] S502. Generate encrypted text information and a second ML-KEM shared key based on the public key information, and generate a first MIC based on the second ML-KEM shared key.

[0120] S503, Send a second information frame to the first device; wherein the second information frame includes encrypted text information, the first MIC and the ML-KEM information of the second device.

[0121] S504. Receive a third information frame sent by the first device; wherein the third information frame includes a second MIC generated by the first device.

[0122] Optionally, the first device described above may include one of the following:

[0123] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0124] The second device mentioned above may include one of the following:

[0125] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0126] In this embodiment, the first device and the second device exchange three information frames to implement the PASN interaction process. That is, the first, second, and third information frames can be PASN authentication frames. The PASN interaction process can be a security negotiation between AP and STA, a security negotiation between APs, a security negotiation between STAs, a security negotiation between STA and SMD-ME, or a security negotiation between SMD-MEs.

[0127] Optionally, before receiving the first information frame sent by the first device, the second device may also send a seventh information frame to the first device; wherein the seventh information frame includes PASN indication information supporting ML-KEM, to inform the first device that it supports PASN interaction based on ML-KEM. The seventh information frame can be various types of management frames, such as Beacon frames periodically sent by the second device, probe response frames, MAPC frames, or other types of management frames (e.g., the RSNXE field in the management frame contains PASN indication information supporting ML-KEM).

[0128] The first device obtains the capabilities of the second device through the seventh information frame and decides whether to join the network. If it decides to join, the first device generates a pair of public key information and private key information based on the ML-KEM algorithm. The length of the public key information and private key information is related to the ML-KEM algorithm. The first device can send the generated public key information and ML-KEM information to the second device in the first information frame.

[0129] The ML-KEM information can be either an indication of the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, AKMP field, and / or the authentication algorithm numbers field. For example, the ML-KEM information can be located in the AKM subfield of the RSNE field in the first information frame.

[0130] Optionally, the ML-KEM information includes an ML-KEM-based authentication mode and / or an ML-KEM type. For example, the ML-KEM-based authentication mode may be included in the AKMP field of the first information frame, and the ML-KEM type may be included in the AAN field or AKMP field of the first information frame. Optionally, the ML-KEM-based authentication mode may include at least one of the following: an ML-KEM-based Open mode (i.e., an authentication-free mode), a peer-to-peer authentication mode based on password and ML-KEM, an ML-KEM-based FILS mode, or an ML-KEM-based FT mode.

[0131] Optionally, based on the difference in the length of the public key information / private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding public key information / private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0132] After receiving the first information frame, the second device checks whether the length / type of the public key information contained in the first information frame matches the ML-KEM type indicated in the first device's ML-KEM information. If they do not match, the second device indicates the mismatch between the public key information and the ML-KEM type via the second information frame, or sends a fourth information frame to the first device. The fourth information frame contains indication information that the public key information does not match the ML-KEM type. For example, the fourth information frame could be a deauthentication request frame. Upon receiving the fourth information frame, the first device terminates the PASN process.

[0133] After successful public key information verification, the second device locally generates a random number, and based on this random number and the first device's public key information, generates encrypted text information and a second ML-KEM shared key, and generates a first MIC based on the second ML-KEM shared key. The first MIC is used by the first device to verify whether the key information negotiated by both communicating parties is consistent. Optionally, the second device can generate a second PTK based on the second ML-KEM shared key, generate a second KCK based on the second PTK, and generate the first MIC based on the second KCK. Further, the second device sends a second information frame to the first device, the second information frame including encrypted text information, its supported / selected ML-KEM information, and the first MIC.

[0134] Specifically, the second device generates a second PTK based on the second ML-KEM shared key and a certain algorithm. Optionally, the second device can generate the second PTK in one of the following ways:

[0135] Method 1: Generate the second PTK based on the PMK, the second ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, and a hash function. For example, the algorithm for generating the second PTK is as follows:

[0136] PTK = KDF-HASH-NNN(PMK, "PASN PTK Derivation", DEV1 MAC address information || DEV2 MAC address information || Second ML-KEM shared key);

[0137] KDF-HASH-NNN: a hash function. The specific hash function information is determined by the key suite information in the RSNE field of the second information frame. The hash function can be a hash function of the SHA3 class, such as SHA3-256 or SHA3-512.

[0138] PMK: Paired master key information;

[0139] PASN PTK Derivation: A type of tag;

[0140] DEV1 MAC address information: The BSSID information of the first device, or its corresponding AP MLD address information, or TA information, or the MAC address of the SMD-ME;

[0141] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or RA information, or SMD-ME MAC address;

[0142] Second ML-KEM shared key: represents the shared key obtained by the first device based on public key information and random number encryption;

[0143] ||: Connector symbol.

[0144] Method 2: Directly determine the second ML-KEM shared key as the second PTK.

[0145] After generating the second PTK, the second device can split the second PTK to obtain the second KCK, second TK, second KDK, and second KEK. Therefore, the length information of the second PTK is determined by the sum of the lengths of the second KCK, second TK, second KDK, and second KEK.

[0146] Second PTK_bits = Second KCK_bits + Second TK_bits + Second KDK_bits + Second KEK_bits;

[0147] Second KCK = ExtractBits(Second PTK, 0, Second KCK_bits);

[0148] Second KEK = ExtractBits(Second PTK, Second KCK_bits, Second KEK_bits);

[0149] Second TK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits, Second TK_bits);

[0150] Second KDK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits + Second TK_bits, Second KDK_bits).

[0151] Where ExtractBits is the number of bits captured, the second KCK_bits is the number of bits in the second KCK, the second TK_bits is the number of bits in the second TK, the second KEK_bits is the number of bits in the second KEK, and the second KDK_bits is the number of bits in the second KDK.

[0152] Among them, the second KCK is used to generate the first MIC and verify the second MIC, the second TK is used to encrypt subsequent data frames or other management frames, the second KDK is used to generate other key information, and the second KEK is used to encrypt authentication frames.

[0153] After obtaining the second KCK, the second device can generate the first MIC using at least one of the following parameters: public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the second information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and the second KCK.

[0154] Upon receiving the second information frame, the first device decrypts the encrypted text information based on the private key information. If decryption fails, the first device may discard the second information frame, not send the third information frame, or send a fifth information frame to the second device. The second device receives the fifth information frame sent by the first device. The status code in the fifth information frame indicates that the decryption of the encrypted text information has failed, thereby terminating the PASN interaction process based on the fifth information frame. Optionally, the first device may also indicate that the decryption of the encrypted text information has failed using the status code in the third information frame.

[0155] After successfully decrypting the encrypted text information to obtain the first ML-KEM shared key, the first device generates a fourth MIC based on a preset algorithm and the first ML-KEM shared key, and verifies whether the fourth MIC is the same as the first MIC. If the fourth MIC is different from the first MIC (i.e., the first MIC verification fails), the first device may discard the second information frame, not send the third information frame, or send a fifth information frame to the second device. The second device receives the fifth information frame sent by the first device. The status code in the fifth information frame is used to indicate that the first MIC verification failed, thereby terminating the PASN interaction process according to the fifth information frame. For example, the fifth information frame may be a deauthentication request frame. Optionally, the first device may also indicate that the first MIC verification failed through the status code in the third information frame.

[0156] Furthermore, the first device can generate a second MIC based on the first ML-KEM shared key and send a third information frame to the second device, the third information frame containing the second MIC. If the encrypted text information is successfully decrypted and the first MIC is successfully verified, the status code in the third information frame indicates a success message.

[0157] It should be noted that the generation process of the second MIC can be referred to the specific description of the above embodiments, and will not be repeated here. The second device receives the third information frame sent by the first device, calculates the third MIC based on the preset algorithm and the second ML-KEM shared key, and verifies whether the third MIC is the same as the second MIC. If the third MIC and the second MIC are the same, the second device determines that the key negotiated with the first device is the same; otherwise, if the third MIC and the second MIC are different, the second device determines that the key negotiated with the first device is different. The key includes the ML-KEM shared key, PTK, KCK, TK, KDK and / or KEK (that is, the first ML-KEM shared key is equal to the second ML-KEM shared key, the first PTK is equal to the second PTK, the first KCK is equal to the second KCK, the first TK is equal to the second TK, the first KDK is equal to the second KDK, and the first KEK is equal to the second KEK).

[0158] Optionally, the second device can generate the third MIC using at least one of the following parameters: public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the first information frame, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and the second KCK; wherein the second KCK is obtained by splitting the second PTK, and the second PTK is obtained by using the second ML-KEM shared key.

[0159] Furthermore, the second device can also send a sixth information frame to the first device. This sixth information frame can be understood as a response frame to the third information frame, containing the verification result of the second MIC. Specifically, if the third MIC is different from the second MIC (i.e., the second MIC verification failed), the sixth information frame contains a status code indicating a failure. In this case, the sixth information frame can be a frame terminating the PASN interaction process. If the third MIC is the same as the second MIC (i.e., the second MIC verification succeeded), the sixth information frame contains a status code indicating a success.

[0160] Optionally, if the second MIC is successfully verified by the third MIC, the second device calls the MLME-SETKEYS.request primitive to install the locally generated key information.

[0161] Optionally, if the first device receives a sixth information frame indicating success from the second device, the first device may call the MLME-SETKEYS.request primitive to install the locally generated key information.

[0162] During PASN interaction, an ML-KEM shared key is generated based on the ML-KEM algorithm (the first ML-KEM shared key for the first device and the second ML-KEM shared key for the second device). Other key information (such as PTK, KCK, TK, KDK and / or KEK) is further generated based on the ML-KEM shared key, making the generated key information resistant to quantum computer attacks, thereby improving the security of Wi-Fi system communication.

[0163] The following examples illustrate the PASN interaction process based on two-stage ML-KEM:

[0164] Figure 6 This is another flowchart illustrating the information frame transmission method provided in this application. The method can be applied to a first device, which in this embodiment can be a STA, AP, or SMD-ME. The second device can also be a STA, AP, or SMD-ME. The first and second devices can perform a PASN interaction process through four information frames, and negotiate and generate key information based on this. Figure 6 As shown, the method may include:

[0165] S601. Send a first information frame to the second device; wherein the first information frame includes the first public key information and ML-KEM information of the first device.

[0166] S602, Receive a second information frame sent by the second device; wherein the second information frame includes first encrypted text information based on the first public key information, the second public key information of the second device, and the ML-KEM information of the second device.

[0167] S603. Based on the first private key information of the first device, decrypt the first encrypted text information to obtain the first ML-KEM shared key.

[0168] S604. Generate second encrypted text information and a second ML-KEM shared key based on the second public key information.

[0169] S605. Generate a first MIC based on at least one of the first ML-KEM shared key and the second ML-KEM shared key.

[0170] S606. Send a third information frame to the second device; wherein the third information frame includes second encrypted text information and a first MIC.

[0171] S607. Receive a fourth information frame sent by the second device; wherein the fourth information frame includes a second MIC generated by the second device.

[0172] Optionally, the first device described above may include one of the following:

[0173] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobile domain management entity.

[0174] The second device mentioned above may include one of the following:

[0175] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobile domain management entity.

[0176] In this embodiment, the first device and the second device exchange four information frames to realize the PASN interaction process. The PASN interaction process can be a security negotiation between AP and STA, a security negotiation between APs, a security negotiation between STAs, a security negotiation between STAs and SMDs, or a security negotiation between SMDs.

[0177] Optionally, the first information frame, the second information frame, the third information frame, and the fourth information frame may be a beacon frame, a probe request frame, a probe response frame, a (re)association request frame, a (re)association response frame, a Multi-Access Point Coordination (MAPC) action frame, or an authentication frame, etc.

[0178] Figure 7 This is a schematic diagram illustrating an interaction between a first device and a second device for transmitting information frames, as provided in an embodiment of this application. Figure 7 As shown, the first device and the second device interact through four information frames to generate and transmit key information, and verify whether the key information negotiated by both parties is consistent through the first MIC and the second MIC.

[0179] Optionally, before the first device sends the first information frame, the first device may also receive an eleventh information frame sent by the second device; wherein the eleventh information frame includes PASN indication information supporting ML-KEM, to inform the first device that it supports PASN interaction based on ML-KEM. The eleventh information frame can be various types of management frames, such as Beacon frames periodically sent by the second device, probe response frames, MAPC frames, or other types of management frames (e.g., the RSNXE field in the management frame contains PASN indication information supporting ML-KEM).

[0180] The first device obtains the capabilities of the second device through the eleventh information frame and decides whether to join the network. If it decides to join, the first device generates a pair of first public key information and first private key information based on the ML-KEM algorithm. The length of the first public key information and the first private key information is related to the ML-KEM algorithm. The first device can send the generated first public key information and its own ML-KEM information to the second device in the first information frame, and the first private key information is stored locally. Figure 8 Another structural diagram of the first information frame provided in the embodiments of this application is shown below. Figure 8 As shown, the first information frame may include frame number (1), frame type information (PASN), RSNE and RSNXE of the first device, first public key information (Public key1), PASN parameters, and AKMP Data-1 based information.

[0181] The ML-KEM information can be either an indication of the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, authentication and AKMP field, and / or authentication algorithm numbers field. For example, the ML-KEM information can be located in the AKM subfield of the RSNE field in the first information frame.

[0182] Optionally, the ML-KEM information includes an ML-KEM-based authentication mode and / or an ML-KEM type. For example, the ML-KEM-based authentication mode may be included in the AKMP field of the first information frame, and the ML-KEM type may be included in the AAN field or AKMP field of the first information frame. Optionally, the ML-KEM-based authentication mode may include at least one of the following: an ML-KEM-based Open mode (i.e., an authentication-free mode), a peer-to-peer authentication mode based on password and ML-KEM, an ML-KEM-based FILS mode, or an ML-KEM-based FT mode.

[0183] Optionally, based on the difference in the length of the first public key information / first private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding first public key information / first private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0184] Optionally, based on the two-way ML-KEM interaction, the ML-KEM algorithm types used by the first device and the second device can be the same or different. When the two devices use different ML-KEM algorithms to generate the corresponding public and private key information, the first device and the second device need to indicate the ML-KEM algorithm type used to generate the public and private key information in RSNE / RSNXE, respectively. For example, if the first device uses ML-KEM-512 to generate the first public and private key information, and the second device uses ML-KEM-768 to generate the second public and private key information, then the first device and the second device need to indicate the ML-KEM algorithm type used in RSNE / RSNXE, respectively.

[0185] Optionally, after receiving the first information frame, the second device may further detect whether the length / type of the first public key information contained in the first information frame matches the ML-KEM type indicated in the ML-KEM information of the first device. If they do not match, the second device may indicate the mismatch between the first public key information and the ML-KEM type via the second information frame, or send a fifth information frame to the first device; wherein the fifth information frame contains indication information that the first public key information does not match the ML-KEM type. The first device receives the fifth information frame sent by the second device and terminates the PASN process based on the fifth information frame. Optionally, the fifth information frame may be a deauthentication request frame.

[0186] After the first public key information is successfully detected, the second device locally generates a random number. Based on this random number, the first device's first public key information, and a certain algorithm, it generates a first encrypted text message and a third ML-KEM shared key, and sends a second information frame to the first device. The second information frame contains the first encrypted text message, the second device's second public key information, and the ML-KEM information it supports / selects. It should be noted that the second device generates a pair of second public key information and second private key information based on the ML-KEM algorithm. The length of the second public key information and the second private key information is related to the ML-KEM algorithm it supports / selects. The second public key information is sent to the first device via the second information frame, while the second private key information is stored locally. Figure 9 Another structural diagram of the second information frame provided in the embodiments of this application is shown below. Figure 9 As shown, the second information frame may include frame number (2), frame type information (PASN), RSNE and RSNXE of the second device, second public key information (Publickey2), first encrypted text information (ciphertext1), PASN parameters, and AKMPData-2 based information.

[0187] The first device receives the second information frame and checks whether the length / type of the second public key information contained in the second information frame matches the ML-KEM type indicated in the second device's ML-KEM information. If they do not match, the first device either sends a third information frame to indicate that the second public key information does not match the ML-KEM type, or sends a sixth information frame to the second device. The sixth information frame contains indication information that the second public key information does not match the ML-KEM type. Upon receiving the sixth information frame, the second device terminates the PASN process. Optionally, the sixth information frame may be a deauthentication request frame.

[0188] Optionally, the first device decrypts the first encrypted text information based on the first private key information corresponding to the first public key information to obtain the first ML-KEM shared key, and generates a random number locally. Based on this random number, the second device's second public key information, and a certain algorithm, it generates second encrypted text information and a second ML-KEM shared key. It then generates a first MIC based on at least one of the first and second ML-KEM shared keys. The first MIC is used by the second device to verify whether the key information negotiated by the communicating parties is consistent. Optionally, the first device may generate a first PTK based on at least one of the first and second ML-KEM shared keys, generate a first KCK based on the first PTK, and generate the first MIC based on the first KCK. Further, the first device sends a third information frame to the second device, the third information frame including the second encrypted text information and the first MIC. Figure 10 This is another structural diagram of the third information frame provided in the embodiments of this application, as shown below. Figure 10 As shown, the third information frame may include frame number (3), frame type information (PASN), RSNE and RSNXE of the second device, second encrypted text information (ciphertext2), PASN parameters, AKMP Data-2 information, and the first MIC generated by the second device.

[0189] Alternatively, the first device may generate the first PTK in one of the following ways:

[0190] Method 1: Generate the first PTK based on the PMK, the first ML-KEM shared key, the second ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, and a hash function. For example, the algorithm for generating the first PTK is as follows:

[0191] PTK = KDF-HASH-NNN(PMK, "PASN PTK Derivation", DEV1 MAC address information || DEV2 MAC address information || First ML-KEM shared key || Second ML-KEM shared key)

[0192] KDF-HASH-NNN: a hash function. The specific hash function information is determined by the key suite information in the RSNE field of the first or second information frame. The hash function can be a hash function of the SHA3 class, such as SHA3-256 or SHA3-512.

[0193] PMK: Paired master key information;

[0194] PASN PTK Derivation: A type of tag;

[0195] DEV1 MAC address information: The BSSID information of the first device, or its corresponding AP MLD address information, or TA information, or the MAC address of the SMD-ME;

[0196] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or RA information, or SMD-ME MAC address;

[0197] First ML-KEM shared key: represents the shared key obtained by the first device from decrypting the first encrypted text information based on the first private key information;

[0198] Second ML-KEM shared key: Represents the shared key obtained by the first device through encryption based on the second public key information;

[0199] ||: Connector symbol.

[0200] Method 2: The first device can also directly determine at least one of the first ML-KEM shared key and the second ML-KEM shared key as the first PTK.

[0201] After generating the first PTK, the first device can split the first PTK to obtain the first KCK, first TK, first KDK, and first KEK. Therefore, the length information of the first PTK is determined by the sum of the lengths of the first KCK, first TK, first KDK, and first KEK.

[0202] First PTK_bits = First KCK_bits + First TK_bits + First KDK_bits + First KEK_bits;

[0203] First KCK = ExtractBits(First PTK, 0, First KCK_bits);

[0204] First KEK = ExtractBits(First PTK, First KCK_bits, First KEK_bits);

[0205] First TK = ExtractBits(First PTK, First KCK_bits + First KEK_bits, First TK_bits);

[0206] First KDK = ExtractBits(First PTK, First KCK_bits + First KEK_bits + First TK_bits, First KDK_bits).

[0207] Where ExtractBits is the number of bits captured, FirstKCK_bits is the number of bits in the first KCK, FirstTK_bits is the number of bits in the first TK, FirstKEK_bits is the number of bits in the first KEK, and FirstKDK_bits is the number of bits in the first KDK.

[0208] Among them, the first KCK is used to generate the first MIC and verify the second MIC, the first TK is used to encrypt subsequent data frames or other management frames, the first KDK is used to generate other key information, and the first KEK is used to encrypt authentication frames.

[0209] After obtaining the first KCK, the first device can generate the first MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the first information frame, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and the first KCK.

[0210] Optionally, if the first device fails to decrypt the first encrypted text information using the first private key information, the first device may discard the second information frame, not send the third information frame, indicate the decryption failure of the first encrypted text information through the status code in the third information frame, or send a seventh information frame to the second device, the status code in the seventh information frame being used to indicate the decryption failure of the first encrypted text information, thereby terminating the PASN interaction process. Optionally, the seventh information frame may be a deauthentication request frame.

[0211] The second device receives the third information frame sent by the first device, decrypts the second encrypted text information based on the second private key information corresponding to the second public key information to obtain the fourth ML-KEM shared key, generates the second MIC based on at least one of the second ML-KEM shared key and the fourth ML-KEM shared key, and sends the fourth information frame to the first device, the fourth information frame containing the second MIC. Figure 11 This is a schematic diagram of the structure of the fourth information frame provided in an embodiment of this application, as shown below. Figure 11 As shown, the fourth information frame may include frame number (4), AKMP Data-4 information, and a second MIC generated by the second device.

[0212] Optionally, if decryption of the second encrypted text information fails, the second device may discard the third information frame, not send the fourth information frame, or send an eighth information frame to the first device. The status code in the eighth information frame indicates that decryption of the second encrypted text information has failed, thereby terminating the PASN interaction process. For example, the eighth information frame may be a deauthentication request frame. Optionally, the first device may also indicate that decryption of the second encrypted text information has failed through the status code in the fourth information frame.

[0213] Optionally, the second device can also calculate a third MIC based on a preset algorithm and at least one of a third ML-KEM shared key and a fourth ML-KEM shared key, and verify whether the third MIC is the same as the first MIC. If the third MIC is different from the first MIC (i.e., the first MIC verification fails), the second device can discard the third information frame, not send the fourth information frame, or send an eighth information frame to the first device. The status code in the eighth information frame is used to indicate that the first MIC verification failed, thereby terminating the PASN interaction process. For example, the eighth information frame can be a deauthentication request frame. Optionally, the first device can also indicate that the first MIC verification failed through the status code in the fourth information frame.

[0214] Optionally, if the second encrypted text information is successfully decrypted using the second private key information, and the third MIC is the same as the first MIC (i.e. the first MIC is successfully verified), then the status code in the fourth information frame indicates a success message.

[0215] The first device receives a fourth information frame sent by the second device, the fourth information frame containing the second MIC. The first device calculates the fourth MIC according to a preset algorithm and at least one of the first ML-KEM shared key and the second ML-KEM shared secret key, and verifies whether the fourth MIC is the same as the second MIC. If the fourth MIC and the second MIC are the same, the first device determines that the key negotiated with the second device is the same; otherwise, if the fourth MIC and the second MIC are different, the first device determines that the key negotiated with the second device is different. The key includes the ML-KEM shared secret key, PTK, KCK, TK, KDK, and / or KEK. Further, the first device can also send a response frame to the second device for the fourth information frame, the response frame containing the verification result of the second MIC. If the fourth MIC is different from the second MIC (i.e., the second MIC verification fails), the status code in the response frame indicates a failure, thereby terminating the PASN interaction process. If the fourth MIC is the same as the second MIC (i.e., the second MIC verification succeeds), the status code in the response frame indicates a success.

[0216] Optionally, if the second MIC is successfully verified by the fourth MIC, the first device calls the MLME-SETKEYS.request primitive to install the locally generated key information.

[0217] Optionally, if the second device receives a response frame indicating success from the first device, the second device may call the MLME-SETKEYS.request primitive to install locally generated key information.

[0218] Optionally, the first device may generate the fourth MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the second information frame, frame body of the fourth information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and first KCK.

[0219] During PASN interaction, an ML-KEM shared key is generated based on the ML-KEM algorithm (the first and second ML-KEM shared keys for the first device, and the third and fourth ML-KEM shared keys for the second device). Other key information (such as PTK, KCK, TK, KDK, and / or KEK) is further generated based on the ML-KEM shared key, making the generated key information resistant to quantum computer attacks, thereby improving the security of Wi-Fi system communication.

[0220] Figure 12 This is another schematic flowchart illustrating the information frame transmission method provided in this application. The method can be applied to a second device. In this embodiment, the first device can be a STA, AP, or SMD-ME, and the second device can also be a STA, AP, or SMD-ME. The first and second devices can perform a PASN interaction process through four information frames, and negotiate and generate key information based on this. Figure 12 As shown, the method may include:

[0221] S1201, Receive a first information frame sent by the first device; wherein, the first information frame includes the first public key information and ML-KEM information of the first device.

[0222] S1202. Generate first encrypted text information and third ML-KEM shared key based on the first public key information.

[0223] S1203. Send a second information frame to the first device; wherein the second information frame includes first encrypted text information, second public key information of the second device, and ML-KEM information of the second device.

[0224] S1204. Receive a third information frame sent by the first device; wherein the third information frame includes a first MIC generated by the first device and second encrypted text information based on the second public key information.

[0225] S1205. Based on the second private key information of the second device, decrypt the second encrypted text information to obtain the fourth ML-KEM shared key.

[0226] S1206. Generate a second MIC based on at least one of the third ML-KEM shared key and the fourth ML-KEM shared key.

[0227] S1207. Send a fourth information frame to the first device; wherein the fourth information frame includes the second MIC.

[0228] Optionally, the first device described above may include one of the following:

[0229] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobile domain management entity.

[0230] The second device mentioned above may include one of the following:

[0231] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobile domain management entity.

[0232] In this embodiment, the first device and the second device exchange four information frames to realize the PASN interaction process. The PASN interaction process can be a security negotiation between AP and STA, a security negotiation between APs, a security negotiation between STAs, a security negotiation between STA and SMD-ME, or a security negotiation between SMD-MEs.

[0233] Optionally, the first, second, third, and fourth information frames can be beacon frames, probe request frames, probe response frames, (re)association request frames, (re)association response frames, MAPC action frames, or authentication frames, etc. Optionally, before the first device sends the first information frame, the second device can also send an eleventh information frame to the first device; wherein the eleventh information frame includes PASN indication information supporting ML-KEM, to inform the first device that it supports PASN interaction based on ML-KEM. The eleventh information frame can be various types of management frames; for example, it can be a Beacon frame periodically sent by the second device, a probe response frame, a MAPC frame, or other types of management frames (e.g., the RSNXE field in the management frame contains PASN indication information supporting ML-KEM).

[0234] The first device obtains the capabilities of the second device through the eleventh information frame and decides whether to join the network. If it decides to join, the first device generates a pair of first public key information and first private key information based on the ML-KEM algorithm. The length of the first public key information and the first private key information is related to the ML-KEM algorithm. The first device can send the generated first public key information and its own ML-KEM information to the second device in the first information frame, and the first private key information is stored locally.

[0235] The ML-KEM information can be either an indication of the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, authentication and AKMP field, and / or authentication algorithm number field. For example, the ML-KEM information can be located in the AKM subfield of the RSNE field in the first information frame.

[0236] Optionally, the ML-KEM information includes an ML-KEM-based authentication mode and / or an ML-KEM type. For example, the ML-KEM-based authentication mode may be included in the AKMP field of the first information frame, and the ML-KEM type may be included in the AAN field or AKMP field of the first information frame. Optionally, the ML-KEM-based authentication mode may include at least one of the following: an ML-KEM-based Open mode (i.e., an authentication-free mode), a peer-to-peer authentication mode based on password and ML-KEM, an ML-KEM-based FILS mode, or an ML-KEM-based FT mode.

[0237] Optionally, based on the difference in the length of the first public key information / first private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding first public key information / first private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0238] The second device receives the first information frame sent by the first device and checks whether the length / type of the first public key information contained in the first information frame matches the ML-KEM type indicated in the ML-KEM information of the first device. If they do not match, the second device indicates that the first public key information does not match the ML-KEM type via the second information frame, or sends a fifth information frame to the first device; wherein the fifth information frame contains indication information that the first public key information does not match the ML-KEM type. Optionally, the fifth information frame may be a deauthentication request frame.

[0239] After the first public key information is successfully detected, the second device locally generates a random number. Based on this random number, the first device's first public key information, and a certain algorithm, it generates a first encrypted text message and a third ML-KEM shared key, and sends a second information frame to the first device. The second information frame contains the first encrypted text message, the second device's second public key information, and the ML-KEM information it supports / selects. It should be noted that the second device generates a pair of second public key information and second private key information based on the ML-KEM algorithm. The length of the second public key information and the second private key information is related to the ML-KEM algorithm it supports / selects. The second device sends the second public key information to the first device via the second information frame, and the second private key information is stored locally.

[0240] The first device receives the second information frame and checks whether the length / type of the second public key information contained in the second information frame matches the ML-KEM type indicated in the second device's ML-KEM information. If they do not match, the first device either sends a third information frame to indicate that the second public key information does not match the ML-KEM type, or sends a sixth information frame to the second device. The sixth information frame contains indication information that the second public key information does not match the ML-KEM type. Upon receiving the sixth information frame, the second device terminates the PASN process. Optionally, the sixth information frame may be a deauthentication request frame.

[0241] Optionally, the first device decrypts the first encrypted text information based on the first private key information corresponding to the first public key information to obtain the first ML-KEM shared key, and generates a random number locally. Based on this random number, the second device's second public key information, and a certain algorithm, it generates second encrypted text information and a second ML-KEM shared key. It then generates a first MIC based on at least one of the first and second ML-KEM shared keys. The first MIC is used by the second device to verify whether the key information negotiated by the communicating parties is consistent. Optionally, the first device may generate a first PTK based on at least one of the first and second ML-KEM shared keys, generate a first KCK based on the first PTK, and generate the first MIC based on the first KCK. Further, the first device sends a third information frame to the second device, the third information frame including the second encrypted text information and the first MIC.

[0242] Optionally, if the first device fails to decrypt the first encrypted text information using the first private key information, the first device may discard the second information frame, not send the third information frame, indicate the decryption failure of the first encrypted text information through the status code in the third information frame, or send a seventh information frame to the second device. The status code in the seventh information frame is used to indicate the decryption failure of the first encrypted text information. The second device receives the seventh information frame sent by the first device, thereby terminating the PASN interaction process. Optionally, the seventh information frame may be a deauthentication request frame.

[0243] The second device receives a third information frame, decrypts the second encrypted text information based on the second private key information corresponding to the second public key information to obtain a fourth ML-KEM shared key, and generates a second MIC based on at least one of the third and fourth ML-KEM shared keys. The second MIC is used by the first device to verify whether the key information negotiated by the communicating parties is consistent. Optionally, the second device may generate a second PTK based on at least one of the third and fourth ML-KEM shared keys, generate a second KCK based on the second PTK, and generate a second MIC based on the second KCK. Further, the second device sends a fourth information frame to the first device, the fourth information frame containing the second MIC.

[0244] Specifically, the second device generates a second PTK based on a certain algorithm and at least one of a third ML-KEM shared key and a fourth ML-KEM shared key. Optionally, the second device can generate the second PTK in one of the following ways:

[0245] Method 1: Generate the second PTK based on the PMK, the third ML-KEM shared key, the fourth ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, and a hash function. For example, the algorithm for generating the second PTK is as follows:

[0246] PTK = KDF-HASH-NNN(PMK, "PASN PTK Derivation", DEV1 MAC address information || DEV2 MAC address information || Second ML-KEM shared key || Fourth ML-KEM shared key)

[0247] KDF-HASH-NNN: a hash function. The specific hash function information is determined by the key suite information in the RSNE field of the first or second information frame. The hash function can be a hash function of the SHA3 class, such as SHA3-256 or SHA3-512.

[0248] PMK: Paired master key information;

[0249] PASN PTK Derivation: A type of tag;

[0250] DEV1 MAC address information: The BSSID information of the first device, or its corresponding AP MLD address information, or TA information, or the MAC address of the SMD-ME;

[0251] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or RA information, or SMD-ME MAC address;

[0252] The third ML-KEM shared key: represents the shared key obtained by the second device through encryption based on the first public key information;

[0253] Fourth ML-KEM shared key: represents the shared key obtained by the second device through decryption of the second encrypted text information;

[0254] ||: Connector symbol.

[0255] Method 2: Directly determine at least one of the third ML-KEM shared key and the fourth ML-KEM shared key as the second PTK.

[0256] After generating the second PTK, the second device can split the second PTK to obtain the second KCK, second TK, second KDK, and second KEK. Therefore, the length information of the second PTK is determined by the sum of the lengths of the second KCK, second TK, second KDK, and second KEK.

[0257] Second PTK_bits = Second KCK_bits + Second TK_bits + Second KDK_bits + Second KEK_bits;

[0258] Second KCK = ExtractBits(Second PTK, 0, Second KCK_bits);

[0259] Second KEK = ExtractBits(Second PTK, Second KCK_bits, Second KEK_bits);

[0260] Second TK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits, Second TK_bits);

[0261] Second KDK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits + Second TK_bits, Second KDK_bits).

[0262] Where ExtractBits is the number of bits captured, the second KCK_bits is the number of bits in the second KCK, the second TK_bits is the number of bits in the second TK, the second KEK_bits is the number of bits in the second KEK, and the second KDK_bits is the number of bits in the second KDK.

[0263] Among them, the second KCK is used to verify the first MIC and generate the second MIC, the second TK is used to encrypt subsequent data frames or other management frames, the second KDK is used to generate other key information, and the second KEK is used to encrypt authentication frames.

[0264] After obtaining the second KCK, the second device can generate the third MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the first information frame, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and the second KCK. Further, the second device verifies whether the third MIC is the same as the first MIC. If the third MIC and the first MIC are the same (i.e., the first MIC verification is successful), the second device determines that the key negotiated by the first device is the same; otherwise, if the third MIC and the first MIC are different (i.e., the first MIC verification fails), the second device determines that the key negotiated with the first device is different. This key includes the ML-KEM shared key, PTK, KCK, TK, KDK, and / or KEK. If the third MIC is different from the first MIC (i.e., the first MIC verification fails), the second device may discard the third information frame, not send the fourth information frame, or send an eighth information frame. The status code in the eighth information frame indicates that the first MIC verification failed, thereby terminating the PASN interaction process. For example, the eighth information frame may be a deauthentication request frame. Optionally, the first device may also indicate that the first MIC verification failed through the status code in the fourth information frame.

[0265] After obtaining the second KCK, the second device can also generate the second MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, RSNE field in the beacon frame, RSNXE field in the beacon frame, frame body of the second information frame, frame body of the fourth information frame, MAC address information of the first device, MAC address information of the second device, and the second KCK.

[0266] Optionally, if decryption of the second encrypted text information based on the second private key information fails, the second device may discard the third information frame, not send the fourth information frame, or send an eighth information frame. The status code in the eighth information frame indicates that decryption of the second encrypted text information has failed, thereby terminating the PASN interaction process. For example, the eighth information frame may be a deauthentication request frame. Optionally, the first device may also indicate that decryption of the second encrypted text information has failed through the status code in the fourth information frame.

[0267] Optionally, if the second encrypted text information is successfully decrypted using the second private key information, and the third MIC is the same as the first MIC (i.e. the first MIC is successfully verified), then the status code in the fourth information frame indicates a success message.

[0268] The first device receives a fourth information frame sent by the second device, the fourth information frame containing the second MIC. The first device calculates the fourth MIC according to a preset algorithm and at least one of the first ML-KEM shared key and the second ML-KEM shared secret key, and verifies whether the fourth MIC is the same as the second MIC. If the fourth MIC and the second MIC are the same, the first device determines that the key negotiated with the second device is the same; otherwise, if the fourth MIC and the second MIC are different, the first device determines that the key negotiated with the second device is different. The key includes the ML-KEM shared secret key, PTK, KCK, TK, KDK, and / or KEK. Further, the first device can also send a response frame to the second device for the fourth information frame, the response frame containing the verification result of the second MIC. If the fourth MIC is different from the second MIC (i.e., the second MIC verification fails), the status code in the response frame indicates a failure, thereby terminating the PASN interaction process. If the fourth MIC is the same as the second MIC (i.e., the second MIC verification succeeds), the status code in the response frame indicates a success.

[0269] Optionally, if the second MIC is successfully verified by the fourth MIC, the first device calls the MLME-SETKEYS.request primitive to install the locally generated key information.

[0270] Optionally, if the second device receives a response frame indicating success from the first device, the second device may call the MLME-SETKEYS.request primitive to install locally generated key information.

[0271] Optionally, the first device may generate the fourth MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the second information frame, frame body of the fourth information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and first KCK.

[0272] During PASN interaction, an ML-KEM shared key is generated based on the ML-KEM algorithm (the first and second ML-KEM shared keys for the first device, and the third and fourth ML-KEM shared keys for the second device). Other key information (such as PTK, KCK, TK, KEK, and / or KDK) is further generated based on the ML-KEM shared key, making the generated key information resistant to quantum computer attacks, thereby improving the security of Wi-Fi system communication.

[0273] Figure 13 This is another interactive schematic diagram illustrating the transmission of information frames between a first device and a second device, as provided in an embodiment of this application. For example... Figure 13 As shown, the first device and the second device interact through six information frames to generate and transmit key information, and verify the consistency of the negotiated key information through the first MIC and the second MIC. In this embodiment, the information frame transmission process can include two stages. The first stage can be a probing stage, in which the first device transmits its supported ML-KEM capability information to the second device, and the second device obtains the first device's public key information (i.e., the first public key information) through a query. The probing stage can include the following steps S1301-S1303. Subsequently, the second stage can be triggered according to the needs of the second device. The second stage can be a PASN authentication stage, in which the first device and the second device execute the PASN interaction process through three authentication frames, and negotiate and generate key information based on this. The PASN authentication stage can include the following steps S1304-S1306. Figure 13 As shown, the method may include:

[0274] S1301, The first device sends the ninth information frame to the second device.

[0275] Among them, the ninth information frame ( Figure 13Information frame 9) includes information on the ML-KEM capabilities supported by the first device. For example, the ninth information frame can be a Beacon frame, which provides information on the ML-KEM capabilities supported by the first device. As shown in Table 1, the first device indicates its supported ML-KEM capabilities through one or more bits in the RSNXE field of the Beacon frame. For example, it can use three reserved bits, X, X+1, and X+2, where X represents any number and is used only for differentiation.

[0276] Table 1

[0277]

[0278]

[0279] S1302, The second device sends the tenth information frame to the first device.

[0280] Among them, the tenth information frame (such as Figure 13 Information frame 10) is used to query the first public key information corresponding to the target ML-KEM information. The target ML-KEM information can be one or more of the ML-KEM capability information. That is, the second device can select one or more ML-KEM capability information as the target ML-KEM information based on the ML-KEM capability information supported by the first device, based on its own supported ML-KEM information, or based on its preferred ML-KEM information, and carry the selected one or more target ML-KEM information in the tenth information frame to request the first device to query the first public key information corresponding to one or more target ML-KEM information. Optionally, the RSNXE field in the tenth information frame contains one or more target ML-KEM information selected by the second device. Optionally, the tenth information frame can be a probe request frame.

[0281] S1303, The first device sends a first information frame to the second device.

[0282] Among them, the first information frame (i.e. Figure 13 Information frame 1) serves as the response frame of the tenth information frame, including one or more target ML-KEM information selected by the second device, and the first public key information corresponding to the one or more target ML-KEM information. Optionally, the first information frame may be a probe response frame. Figure 14 This illustrates a structural diagram of the first public key information, such as... Figure 14As shown, the first public key information may include one or more public key elements, such as element ID (element identifier information, used to uniquely identify the field), length (length information, used to indicate the length of the public key itself or the length of the entire public key field), ML-KEM type (ML-KEM type information, used to identify the specific algorithm corresponding to ML-KEM, such as ML-KEM-512, ML-KEM-768, ML-KEM-1024) and public key (the public key information itself).

[0283] Furthermore, the first device can generate different public key information for different second devices, that is, it can generate different public key information for different second devices based on the identification information (such as the MAC address information of the second device) contained in the tenth information frame.

[0284] S1304, The second device sends a second information frame to the first device.

[0285] Among them, the second information frame (such as Figure 13 The information frame 2) includes first encrypted text information based on the first public key information, second public key information of the second device, and ML-KEM information of the second device.

[0286] Optionally, the second device generates a first encrypted text message and a third ML-KEM shared key based on the first public key information and a locally generated random number. Figure 15 This is a schematic diagram of a structure of a second information frame provided in an embodiment of this application. This second information frame can be obtained by extending PASN authentication frame 1, such as... Figure 15 As shown, the second information frame may include frame number (1), frame type information (PASN), RSNE and RSNXE of the second device, public key information (Public key 2), first encrypted text information (ciphertext 1), PASN parameters, and AKMP Data-1 based information.

[0287] S1305, The first device sends a third information frame to the second device.

[0288] Among them, the third information frame (such as Figure 13 The information frame 3) includes second encrypted text information and a first MIC. Optionally, the first device decrypts the first encrypted text information based on the first private key information to obtain a first ML-KEM shared key, generates second encrypted text information and a second ML-KEM shared key based on the second public key information and a locally generated random number, and generates the first MIC based on a preset algorithm and at least one of the first ML-KEM shared key and the second ML-KEM shared key.

[0289] Figure 16 This is a schematic diagram of a third information frame provided in an embodiment of this application. This third information frame can be obtained by extending PASN authentication frame 2, such as... Figure 16 As shown, the third information frame may include frame number (2), frame type information (PASN), RSNE and RSNXE of the first device, second encrypted text information (ciphertext2), PASN parameters, AKMP Data-2 information, and the first MIC generated by the first device.

[0290] S1306, The second device sends a fourth information frame to the first device.

[0291] Among them, the fourth information frame (such as Figure 13 Information frame 4) includes a second MIC generated by the second device. Optionally, the second device decrypts the second encrypted text information based on the second private key information to obtain a fourth ML-KEM shared key, and generates a third MIC and a second MIC based on a preset algorithm and at least one of the third and fourth ML-KEM shared keys. The third MIC is used to verify the first MIC.

[0292] Optionally, after receiving the fourth information frame, the first device may generate a fourth MIC based on a preset algorithm and at least one of the first ML-KEM shared key and the second ML-KEM shared key. The fourth MIC is used to verify the second MIC.

[0293] It should be noted that the generation process of the first MIC, the second MIC, the third MIC, and the fourth MIC, as well as the verification process of the first MIC using the third MIC and the verification process of the second MIC using the fourth MIC, can all refer to the description in the above embodiments, and will not be repeated here.

[0294] In this embodiment, the first device and the second device can query public key information through three information frames. Subsequently, the PASN interaction process is executed through three information frames (such as authentication frames). Without the need to add new PASN authentication frames, the ML-KEM algorithm is integrated with the PASN interaction process, so that the generated key information can resist attacks from quantum computers, thereby improving the security of Wi-Fi system communication.

[0295] Figure 17 This is a schematic diagram of an information frame transmission device provided in an embodiment of this application. The device is integrated into a first device, such as... Figure 17 As shown, the device may include a transmitting module 1701, a receiving module 1702, and a processing module 1703.

[0296] Specifically, the sending module 1701 is used to send a first information frame to the second device; wherein, the first information frame includes the public key information of the first device and ML-KEM-based information;

[0297] The receiving module 1702 is used to receive a second information frame sent by the second device; wherein, the second information frame includes encrypted text information based on public key information, a first information integrity check code MIC, and the ML-KEM information of the second device;

[0298] Processing module 1703 is used to decrypt encrypted text information based on the private key information of the first device to obtain a first ML-KEM shared key; and to generate a second MIC based on the first ML-KEM shared key;

[0299] The sending module 1701 is also used to send a third information frame to the second device; wherein the third information frame includes the second MIC.

[0300] Optionally, ML-KEM information includes ML-KEM-based authentication modes and / or ML-KEM types.

[0301] Optionally, the ML-KEM-based authentication modes include at least one of the following: ML-KEM-based Open mode; peer authentication mode based on cryptography and ML-KEM; ML-KEM-based FILS mode; and ML-KEM-based FT mode.

[0302] Optionally, the ML-KEM type includes at least one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

[0303] Optionally, the ML-KEM information is located in at least one of the following fields: RSNE field, RSNXE field, AKMP field, and authentication algorithm number field.

[0304] Optionally, the receiving module 1702 is further configured to receive a fourth information frame sent by the second device; wherein the fourth information frame includes indication information indicating that the public key information does not match the ML-KEM type;

[0305] The processing module 1703 is also used to discard the second information frame or not send the third information frame or send the fifth information frame to the second device through the sending module 1701 in the event that the encrypted text information decryption fails and / or the first MIC verification fails; wherein, the status code in the fifth information frame is used to indicate that the encrypted text information decryption fails and / or the first MIC verification fails.

[0306] The receiving module 1702 is also used to receive a sixth information frame sent by the second device; wherein the status code in the sixth information frame is used to indicate the verification result of the second MIC.

[0307] Optionally, the status code in the third information frame is used to indicate one of the following states: encrypted text information decryption failed; first MIC verification failed; success message.

[0308] Optionally, the processing module 1703 is also configured to generate a first PTK based on the first ML-KEM shared key.

[0309] Optionally, the processing module 1703 is further configured to generate the first PTK based on the PMK, the first ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, and the hash function; or, to determine the first ML-KEM shared key as the first PTK.

[0310] Optionally, the processing module 1703 is also used to generate a second MIC using at least one of the following parameters:

[0311] The information includes public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the first information frame, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and the first KCK; wherein the first KCK is obtained based on the first PTK.

[0312] Optionally, the receiving module 1702 is further configured to receive a seventh information frame sent by the second device before the sending module 1701 sends the first information frame to the second device; wherein the seventh information frame includes PASN indication information supporting ML-KEM.

[0313] Optionally, the first device includes one of the following:

[0314] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point cooperation capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME;

[0315] The second device includes one of the following:

[0316] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0317] Figure 18 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application. The apparatus is integrated into a second device, such as... Figure 18As shown, the device may include a receiving module 1801, a processing module 1802, and a transmitting module 1803.

[0318] Specifically, the receiving module 1801 is used to receive a first information frame sent by the first device; wherein, the first information frame includes the public key information and ML-KEM information of the first device;

[0319] The processing module 1802 is used to generate encrypted text information and a second ML-KEM shared key based on the public key information, and to generate a first MIC based on the second ML-KEM shared key;

[0320] The sending module 1803 is used to send a second information frame to the first device; wherein, the second information frame includes encrypted text information, the first MIC and the ML-KEM information of the second device;

[0321] The receiving module 1801 is used to receive a third information frame sent by the first device; wherein the third information frame includes a second MIC generated by the first device.

[0322] Optionally, ML-KEM information includes ML-KEM-based authentication modes and / or ML-KEM types.

[0323] Optionally, the ML-KEM-based authentication modes include at least one of the following: ML-KEM-based Open mode; peer authentication mode based on cryptography and ML-KEM; ML-KEM-based FILS mode; and ML-KEM-based FT mode.

[0324] Optionally, the ML-KEM type includes at least one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

[0325] Optionally, the ML-KEM information is located in at least one of the following fields: RSNE field, RSNXE field, AKMP field, and authentication algorithm number field.

[0326] Optionally, the sending module 1803 is further configured to send a fourth information frame to the first device when it detects that the public key information does not match the ML-KEM type; wherein the fourth information frame includes indication information that the public key information does not match the ML-KEM type;

[0327] The receiving module 1801 is also used to receive a fifth information frame sent by the first device; wherein, the status code in the fifth information frame is used to indicate that the encrypted text information decryption failed and / or the first MIC verification failed;

[0328] The sending module 1803 is also used to send a sixth information frame to the first device; wherein the status code in the sixth information frame is used to indicate the verification result of the second MIC.

[0329] Optionally, the status code in the third information frame is used to indicate one of the following states: encrypted text information decryption failed; first MIC verification failed; success information.

[0330] Optionally, the processing module 1802 is also configured to generate a second PTK based on the second ML-KEM shared key.

[0331] Optionally, the processing module 1802 is further configured to generate a second PTK based on the PMK, the second ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, and the hash function; or, to determine the second ML-KEM shared key as the second PTK.

[0332] Optionally, the processing module 1802 is further configured to calculate and obtain the third MIC according to the preset algorithm and the second ML-KEM shared key, and verify whether the third MIC is the same as the second MIC; if the third MIC is different from the second MIC, terminate the PASN interaction process.

[0333] Optionally, the processing module 1802 is also configured to generate a first MIC using at least one of the following parameters:

[0334] The information includes public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the second information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, and the second KCK; wherein the second KCK is obtained based on the second PTK.

[0335] Optionally, the sending module 1803 is further configured to send a seventh information frame to the first device before the receiving module 1801 receives the first information frame sent by the first device; wherein the seventh information frame includes PASN indication information supporting ML-KEM.

[0336] Figure 19 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application. The apparatus is integrated into the first device, such as... Figure 19 As shown, the device may include a transmitting module 1901, a receiving module 1902, and a processing module 1903.

[0337] The sending module 1901 is used to send a first information frame to the second device; wherein, the first information frame includes the first public key information and ML-KEM information of the first device;

[0338] The receiving module 1902 is used to receive a second information frame sent by the second device; wherein, the second information frame includes first encrypted text information based on the first public key information, the second public key information of the second device, and the ML-KEM information of the second device;

[0339] Processing module 1903 is used to decrypt first encrypted text information based on the first private key information of the first device to obtain a first ML-KEM shared key; generate second encrypted text information and a second ML-KEM shared key based on the second public key information; and generate a first MIC based on at least one of the first ML-KEM shared key and the second ML-KEM shared key.

[0340] The sending module 1901 is also used to send a third information frame to the second device; wherein the third information frame includes second encrypted text information and a first MIC;

[0341] The receiving module 1902 is also used to receive a fourth information frame sent by the second device; wherein the fourth information frame includes a second MIC generated by the second device.

[0342] Optionally, ML-KEM information includes ML-KEM-based authentication modes and / or ML-KEM types.

[0343] Optionally, the ML-KEM-based authentication modes include one of the following: ML-KEM-based Open mode; peer authentication mode based on cryptography and ML-KEM; ML-KEM-based FILS mode; and ML-KEM-based FT mode.

[0344] Optionally, the ML-KEM type includes one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

[0345] Optionally, the receiving module 1902 is further configured to receive a fifth information frame sent by the second device; wherein the fifth information frame is triggered by the second device when it detects an indication that the first public key information does not match the ML-KEM type, and the fifth information frame includes the indication that the first public key information does not match the ML-KEM type.

[0346] The sending module 1901 is further configured to send a sixth information frame to the second device when it detects that the second public key information does not match the ML-KEM type; wherein the sixth information frame includes indication information that the second public key information does not match the ML-KEM type;

[0347] The processing module 1903 is also configured to, in the event that the first encrypted text information fails to be decrypted, discard the second information frame, not send the third information frame, or send a seventh information frame to the second device through the sending module 1901; wherein, the status code in the seventh information frame is used to indicate that the first encrypted text information has failed to be decrypted;

[0348] The receiving module 1902 is also used to receive an eighth information frame sent by the second device; wherein the status code in the eighth information frame is used to indicate that the second encrypted text information failed to be decrypted and / or the first MIC verification failed.

[0349] Optionally, the status code in the fourth information frame is used to indicate one of the following states: the second encrypted text information failed to be decrypted; the first MIC verification failed; or a success message was received.

[0350] Optionally, the processing module 1903 is further configured to calculate a third MIC based on a preset algorithm and at least one of a first ML-KEM shared key and a second ML-KEM shared key, and verify whether the third MIC is the same as the second MIC; if the third MIC is different from the second MIC, terminate the PASN interaction process.

[0351] Optionally, the processing module 1903 is further configured to generate a first PTK based on a first ML-KEM shared key and / or a second ML-KEM shared key.

[0352] Optionally, the processing module 1903 is further configured to generate a first PTK based on the PMK, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, the hash function, and at least one of the first ML-KEM shared key and the second ML-KEM shared key; or, to determine at least one of the first ML-KEM shared key and the second ML-KEM shared key as the first PTK.

[0353] Optionally, the processing module 1903 is also configured to generate the first MIC using at least one of the following parameters:

[0354] The information includes first public key information, second public key information, first encrypted text information, second encrypted text information, RSNE field in the beacon frame, RSNXE field in the beacon frame, frame body of the first information frame, frame body of the third information frame, MAC address information of the first device, MAC address information of the second device, and first KCK; wherein, the first KCK is obtained based on the first PTK.

[0355] Optionally, the sending module 1901 is further configured to send a ninth information frame to the second device before sending the first information frame to the second device; wherein the ninth information frame includes ML-KEM capability information supported by the first device;

[0356] The receiving module 1902 is also used to receive the tenth information frame sent by the second device; the tenth information frame is used to query the first public key information corresponding to the target ML-KEM information, and the target ML-KEM information is one or more of the ML-KEM capability information.

[0357] Figure 20 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application. The apparatus is integrated into a second device, such as... Figure 20 As shown, the device may include: a receiving module 2001, a processing module 2002, and a transmitting module 2003.

[0358] Specifically, the receiving module 2001 is used to receive a first information frame sent by the first device; wherein, the first information frame includes the first public key information and ML-KEM information of the first device;

[0359] Processing module 2002 is used to generate first encrypted text information and third ML-KEM shared key based on the first public key information;

[0360] The sending module 2003 is used to send a second information frame to the first device; wherein, the second information frame includes first encrypted text information, second public key information of the second device, and ML-KEM information of the second device;

[0361] The receiving module 2001 is also used to receive a third information frame sent by the first device; wherein the third information frame includes a first MIC generated by the first device and second encrypted text information based on the second public key information;

[0362] The fourth ML-KEM shared key is obtained by decrypting the second encrypted text information based on the second private key information of the second device.

[0363] Processing module 2002 is also used to generate a second MIC based on at least one of the third ML-KEM shared key and the fourth ML-KEM shared key;

[0364] The sending module 2003 is also used to send a fourth information frame to the first device; wherein the fourth information frame includes a second MIC.

[0365] Optionally, the sending module 2003 is further configured to send a fifth information frame to the first device when it detects that the first public key information does not match the ML-KEM type; wherein the fifth information frame includes indication information that the first public key information does not match the ML-KEM type;

[0366] The receiving module 2001 is also configured to receive a sixth information frame sent by the first device; wherein the sixth information frame includes an indication that the second public key information does not match the ML-KEM type; or to receive a seventh information frame sent by the first device; wherein the status code in the seventh information frame is used to indicate that the decryption of the first encrypted text information has failed.

[0367] The processing module 2002 is also configured to discard the third information frame or not send the fourth information frame or send the eighth information frame to the first device through the sending module 2003 if the second encrypted text information fails to be decrypted and / or the first MIC verification fails; wherein, the status code in the eighth information frame is used to indicate that the second encrypted text information failed to be decrypted and / or the first MIC verification failed.

[0368] Optionally, the status code in the fourth information frame is used to indicate one of the following states: the second encrypted text information failed to be decrypted; the first MIC verification failed; or a success message was received.

[0369] Optionally, the receiving module 2001 is further configured to receive a ninth information frame sent by the first device; wherein the ninth information frame includes ML-KEM capability information supported by the first device;

[0370] The sending module 2003 is also used to send a tenth information frame to the first device; wherein the tenth information frame is used to query the first public key information corresponding to the target ML-KEM information, and the target ML-KEM information is one or more of the ML-KEM capability information.

[0371] Optionally, the processing module 2002 is also configured to generate a second PTK based on a third ML-KEM shared key and / or a fourth ML-KEM shared key.

[0372] Optionally, the processing module 2002 is further configured to generate a second PTK based on the PMK, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, the hash function, and at least one of the third ML-KEM shared key and the fourth ML-KEM shared key; or, to determine at least one of the third ML-KEM shared key and the fourth ML-KEM shared key as the second PTK.

[0373] Optionally, the processing module 2002 is also configured to generate a second MIC using at least one of the following parameters:

[0374] The information includes first public key information, second public key information, first encrypted text information, second encrypted text information, RSNE field in the beacon frame, RSNXE field in the beacon frame, frame body of the second information frame, frame body of the fourth information frame, MAC address information of the first device, MAC address information of the second device, and second KCK; wherein, the second KCK is obtained based on the second PTK.

[0375] In one embodiment, an information frame transmission method, communication device, and storage medium are also provided. Compared with traditional methods, this application embodiment binds the ML-KEM algorithm with a cryptographically based simultaneous authentication of equals (SAE) process, reducing the attack capabilities of quantum computers and thus improving the security of SAE interaction. Based on this, this application embodiment provides two SAE interaction schemes: one is an SAE interaction process based on a single ML-KEM, and the other is an SAE interaction process based on two ML-KEMs. The following embodiments first describe the SAE interaction process based on a single ML-KEM:

[0376] Figure 21 This is another flowchart illustrating the information frame transmission method provided in this application. The method can be applied to a first device, which in this embodiment can be a STA, AP, or SMD-ME. The second device can also be a STA, AP, or SMD-ME. The first and second devices can perform an SAE interaction process through four information frames, and key information is generated based on cryptographic negotiation. Figure 21 As shown, the method may include:

[0377] S2101. Send a first information frame to the second device; wherein the first information frame includes the public key information and ML-KEM information of the first device.

[0378] S2102, Receive a second information frame sent by the second device; wherein the second information frame includes encrypted text information based on public key information and ML-KEM information of the second device.

[0379] S2103. Based on the private key information of the first device, decrypt the encrypted text information to obtain the first ML-KEM shared key, and generate the first verification information based on the first ML-KEM shared key and the first password or a variant of the first password.

[0380] S2104. Send a third information frame to the second device; wherein the third information frame includes the first verification information.

[0381] S2105. Receive a fourth information frame sent by the second device; wherein the fourth information frame includes second verification information generated by the second device.

[0382] Optionally, the first device described above may include one of the following:

[0383] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobile domain management entity.

[0384] The second device mentioned above may include one of the following:

[0385] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobile domain management entity.

[0386] In this embodiment, the first device and the second device exchange four information frames to implement the SAE interaction process. That is, the first, second, third, and fourth information frames can be authentication frames. The SAE interaction process can be authentication between AP and STA, authentication between APs, authentication between STAs, authentication between STAs and SMD-ME, or authentication between SMD-MEs.

[0387] Figure 22 This is another interactive schematic diagram illustrating the transmission of information frames between a first device and a second device, as provided in an embodiment of this application. For example... Figure 22 As shown ( Figure 22 Taking authentication frame interaction as an example, the first device and the second device interact through four information frames to perform password authentication, key information generation and transmission, and verify whether the key information negotiated by both parties is consistent through the first MIC and the second MIC.

[0388] Optionally, before the first device sends the first information frame, the second device may also send a fifth information frame to the first device. The fifth information frame carries the ML-KEM capability set information of the second device. The first device receives the fifth information frame sent by the second device and obtains the capabilities of the second device based on the fifth information frame. Optionally, the fifth information frame may be a Beacon frame, a probe response frame, a MAPC management frame, or other types of management frames used to provide the ML-KEM capability set information of the second device.

[0389] In an alternative implementation, before the first device authenticates with the second device, or before the first device performs a roaming operation, the second device may also indicate the ML-KEM capability set information of its neighboring devices through the Reduced NeighbourReport (RNR) and Neighbour Report (NR) fields in the fifth information frame. In this case, the fifth information frame may be a Beacon frame, a probe response frame, or a Fast BSS transition management (BTM) request frame, etc.

[0390] The first device obtains the capabilities of the second device through the fifth information frame and decides whether to join the network. If it decides to join, the first device sends the first information frame. The first device can generate a pair of public and private key information based on the ML-KEM algorithm. The length of the public and private key information is related to the ML-KEM algorithm. The first device sends the generated public key information and ML-KEM information to the second device in the first information frame, while the private key information is stored locally.

[0391] The ML-KEM information can be either information about the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, AKMP field, and / or the authentication algorithm numbers field. For example, the ML-KEM information can be located in the AKM subfield of the RSNE field in the first information frame.

[0392] Optionally, the ML-KEM information includes the ML-KEM type. Based on the difference in the length of the public key information / private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding public key information / private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0393] The second device receives the first information frame, generates encrypted text information and a second ML-KEM shared key based on the first device's public key information, and sends a second information frame to the first device. The second information frame includes the generated encrypted text information and ML-KEM information it supports / selects. Optionally, the second device can generate the encrypted text information and the second ML-KEM shared key based on the first device's public key information, a locally generated random number, and a second password (the second password is a password held by the second device, or a variant of the second password). For example, the formula for generating the encrypted text information is as follows:

[0394] (K 第二 ,C)<--en.func(ek,m|pwd);

[0395] Among them, K 第二 This represents the second ML-KEM shared key, which is the shared key generated by the second device based on the ML-KEM algorithm;

[0396] C indicates encrypted text information;

[0397] m represents a random number;

[0398] ek represents the public key information of the first device;

[0399] pwd represents a password or a variant of a password. For the second device, pwd is the second password.

[0400] en.func represents an encryption algorithm based on ML-KEM;

[0401] | indicates a logical OR operation.

[0402] Optionally, after receiving the first information frame, the second device may further detect whether the length / type of the public key information contained in the first information frame matches the ML-KEM type indicated in the first device's ML-KEM information. If they do not match, the second device may indicate the mismatch between the public key information and the ML-KEM type via the second information frame, or send a sixth information frame to the first device. The sixth information frame contains indication information indicating the mismatch between the public key information and the ML-KEM type. For example, the sixth information frame could be a deauthentication request frame. After receiving the sixth information frame, the first device terminates the SAE process.

[0403] The first device receives a second information frame sent by the second device, decrypts the encrypted text information based on the private key information corresponding to the public key information to obtain a first ML-KEM shared key, generates first verification information based on the first ML-KEM shared key and a first password, and sends a third information frame to the second device, the third information frame containing the first verification information. The first verification information is used by the second device to verify whether the key information negotiated between the two communicating parties is consistent.

[0404] Specifically, the first device can generate a first KCK and a first PMK based on a certain algorithm, a first ML-KEM shared key, and a first password, and generate first verification information based on the first KCK. For example, the algorithm for generating the first KCK and the first PMK is as follows:

[0405] (1) keyseed = H(pwd, K 第一 );

[0406] (2), ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed, "ml-kel-KCK and PMK", C);

[0407] Or, ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed,"ml-kel-KCK andPMK",C,ek);

[0408] (3), the first KCK=ExtractBits(ml-kel_kck_and_pmk,0,Q);

[0409] (4). The first PMK=ExtractBits((ml-kel_kck_and_pmk,Q,PMK_bits).

[0410] Where Q represents the length of the (digital) hash function;

[0411] ExtractBits: indicates the number of bits captured, PMK_bits indicates the number of PMK bits;

[0412] C: Indicates encrypted text information;

[0413] ek: Represents the public key information of the first device;

[0414] K 第一 : Represents the first ML-KEM shared key, that is, the shared key obtained by the first device based on decrypting the encrypted text information;

[0415] KDF-Hash-Length: Represents the key generation function;

[0416] ml-kel-KCK and PMK: represent an input parameter.

[0417] H() represents a hash function. For example, the H() function may be SHA3, such as SHA3-256() or SHA3-512(). The output length of SHA3-256() is 256, and the output length of SHA3-512() is 512.

[0418] Optionally, the first device may also generate the first PMK using at least one of the following parameters: encrypted text information, a first ML-KEM shared key, and a first password. Optionally, the first device may generate the first PTK using at least one of the following parameters: the first PMK, PTK Derivation, the MAC address information of the first device, and the MAC address information of the second device. For example, the algorithms for generating the first PTK and the first PCK are as follows:

[0419] (1) keyseed = (pwd, K 第一 )

[0420] (2), First PMK=KDF-Hash-Length(keyseed,“ml-kel PMK”,C);

[0421] Alternatively, the first PMK = KDF-Hash-Length(keyseed, "ml-kel PMK", C, ek);

[0422] (3) First PTK = KDF-HASH-NNN(First PMK, "PTK Derivation", DEV1 MAC address information || DEV2 MAC address information);

[0423] KDF-HASH-NNN: is the hash function for key generation. The specific hash function information is determined by the key suite information in the RSNE field of the second information frame. The hash function may be a SHA3-256 or SHA3-512 hash function of the SHA3 class.

[0424] First PMK: is the paired master key information;

[0425] ml-kel PMK: is an input parameter;

[0426] PTK Derivation: A type of tag;

[0427] C: Indicates encrypted text information;

[0428] ek: Represents the public key information of the first device;

[0429] DEV1 MAC address information: The BSSID information of the first device, or its corresponding AP MLD address information, or TA information;

[0430] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or RA information;

[0431] First ML-KEM shared key: represents the shared key obtained by the first device from decrypting encrypted text information based on the private key information;

[0432] ||: Connector symbol.

[0433] After generating the first PTK, the first device can split the first PTK to obtain the first KCK, first TK, first KDK, and first KEK. Therefore, the length information of the first PTK is determined by the sum of the lengths of the first KCK, first TK, first KDK, and first KEK.

[0434] First PTK_bits = First KCK_bits + First TK_bits + First KDK_bits + First KEK_bits;

[0435] First KCK = ExtractBits(First PTK, 0, First KCK_bits);

[0436] First KEK = ExtractBits(First PTK, First KCK_bits, First KEK_bits);

[0437] First TK = ExtractBits(First PTK, First KCK_bits + First KEK_bits, First TK_bits);

[0438] First KDK = ExtractBits(First PTK, First KCK_bits + First KEK_bits + First TK_bits, First KDK_bits).

[0439] Where ExtractBits is the number of bits captured, FirstKCK_bits is the number of bits in the first KCK, FirstTK_bits is the number of bits in the first TK, FirstKEK_bits is the number of bits in the first KEK, and FirstKDK_bits is the number of bits in the first KDK.

[0440] Among them, the first KCK is used to generate the first verification information and verify the second verification information, the first TK is used to encrypt subsequent data frames or other management frames, the first KDK is used to generate other key information, and the first KEK is used to encrypt authentication frames.

[0441] Optionally, the first pairwise master key identifier (PMKID), serving as the identifier information of the first PMK, can be generated from encrypted text information and / or public key information as direct or indirect parameters. For example, the formula for generating the first PMKID is as follows:

[0442] First PMKID = ExtractBits(C, 0, 128);

[0443] Alternatively, the first PMKID = ExtractBits(C|ek,0,128);

[0444] In this context, | is the connector; 128 is the number of bits, but it can also be other values.

[0445] Optionally, the aforementioned first verification information may be a first MIC or a first confirmation information. After obtaining the first KCK, the first device may generate the first MIC using at least one of the following parameters: public key information, encrypted text information, first ML-KEM shared key, first KCK, first cipher, first cipher variant, frame body of the third information frame, MAC address information of the first device, MAC address information of the second device, RSNE field in the beacon frame, and RSNXE field in the beacon frame.

[0446] Optionally, the first device may generate the first confirmation information using at least one of the following parameters: public key information, encrypted text information, first ML-KEM shared key, first KCK, first password, and first password variant.

[0447] Optionally, if decryption of the encrypted text information based on the private key information fails, the first device may indicate the decryption failure via a status code in a third information frame, or send an eighth information frame to the second device, wherein the status code in the eighth information frame indicates the decryption failure, thereby terminating the SAE interaction process. For example, the first device may send a deauthentication request frame to the second device, the status code of which indicates the decryption failure.

[0448] The second device receives a third information frame and calculates third verification information based on a preset algorithm, a second ML-KEM shared key, and a second cipher or a variant of the second cipher. It then verifies whether the third verification information matches the first verification information. If the third verification information and the first verification information are the same, the second device determines that it holds the same cipher as the first device, and that the keys negotiated are identical. This key includes the ML-KEM shared key, PTK, KCK, TK, KEK, and / or KDK (i.e., the first ML-KEM shared key equals the second ML-KEM shared key, the first PTK equals the second PTK, the first KCK equals the second KCK, the first TK equals the second TK, the first KDK equals the second KDK, and the first KEK equals the second KEK). Conversely, if the third verification information and the first verification information are different, the second device determines that it holds a different cipher than the first device, meaning authentication fails.

[0449] Optionally, the aforementioned third verification information may be a third MIC or third confirmation information. When the third verification information is a third MIC, the second device may generate the third MIC using at least one of the following parameters: public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, second ML-KEM shared key, second cipher, second cipher variant, and second KCK.

[0450] When the third verification information is the third confirmation information, the second device can generate the third confirmation information using at least one of the following parameters: public key information, encrypted text information, second ML-KEM shared key, second password, second password variant and second KCK; wherein, the second KCK is obtained based on the second ML-KEM shared key and the second password.

[0451] Furthermore, if the third verification information is different from the first verification information (i.e. the first verification information verification fails), the second device can also send a seventh information frame to the first device, and the status code in the seventh information frame indicates that the first verification information verification failed.

[0452] Furthermore, the second device can also generate second verification information based on the second ML-KEM shared key and the second cipher or a variant of the second cipher, and send a fourth information frame to the first device, the fourth information frame containing the second verification information. The second verification information is used by the first device to verify whether the key information negotiated between the two communicating parties is consistent.

[0453] The first device receives the fourth information frame and calculates the fourth verification information according to the preset algorithm, the first password, and the first ML-KEM shared key. It then verifies whether the fourth verification information matches the second verification information. If the fourth verification information and the second verification information are the same, the first device determines that it holds the same password as the second device, and that the keys negotiated based on the password are identical. This key includes the ML-KEM shared key, PTK, KCK, TK, KDK, and / or KEK (i.e., the first ML-KEM shared key equals the second ML-KEM shared key, the first PTK equals the second PTK, the first KCK equals the second KCK, the first TK equals the second TK, the first KDK equals the second KDK, and the first KEK equals the second KEK). Conversely, if the fourth verification information and the second verification information are different, the first device determines that it holds a different password than the second device, meaning authentication fails. In the case where the fourth verification information and the second verification information are different, the first device can also send an eighth information frame to the second device. The status code of the eighth information frame indicates that the second verification information verification failed. For example, the eighth information frame could be a deauthentication request frame.

[0454] Optionally, the aforementioned fourth verification information may be a fourth MIC or a fourth confirmation information. When the fourth verification information is a fourth MIC, the first device may generate the fourth MIC using at least one of the following parameters: public key information, encrypted text information, the MAC address information of the first device, the MAC address information of the second device, the frame body of the fourth information frame, the RSNE field in the beacon frame, the RSNXE field in the beacon frame, the first ML-KEM shared key, the first cipher, the first cipher variant, and the first KCK.

[0455] When the fourth verification information is the fourth confirmation information, the second device can generate the fourth confirmation information using at least one of the following parameters: public key information, encrypted text information, first ML-KEM shared key, first password, first password variant, and first KCK.

[0456] During SAE interaction, an ML-KEM shared key is generated based on the ML-KEM algorithm (the first ML-KEM shared key for the first device and the second ML-KEM shared key for the second device). Other key information is further generated based on the ML-KEM shared key and the password, so that the generated key information can resist attacks from quantum computers, thereby improving the security of Wi-Fi system communication.

[0457] Figure 23This is another flowchart illustrating the information frame transmission method provided in this application. The method can be applied to a second device. In this embodiment, the first device can be a STA, AP, or SMD-ME, and the second device can also be a STA, AP, or SMD-ME. The first and second devices can perform an SAE interaction process through four information frames, and generate key information based on cryptographic negotiation. Figure 23 As shown, the method may include:

[0458] S2301. Receive a first information frame sent by the first device; wherein the first information frame includes the public key information and ML-KEM information of the first device;

[0459] S2302. Generate encrypted text information and a second ML-KEM shared key based on public key information.

[0460] S2303, Send a second information frame to the first device; wherein the second information frame includes encrypted text information and the ML-KEM information of the second device.

[0461] S2304. Receive a third information frame sent by the first device; wherein the third information frame includes first verification information generated by the first device.

[0462] S2305. Generate second verification information based on the second ML-KEM shared key and the second password or a variant of the second password.

[0463] S2306. Send a fourth information frame to the first device; wherein the fourth information frame includes second verification information.

[0464] Optionally, the first device described above may include one of the following:

[0465] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0466] The second device mentioned above may include one of the following:

[0467] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0468] In this embodiment, the first device and the second device exchange four information frames to implement the SAE interaction process. That is, the first, second, third, and fourth information frames can be authentication frames. The SAE interaction process can be authentication between AP and STA, authentication between APs, authentication between STAs, authentication between STAs and SMD-ME, or authentication between SMD-MEs.

[0469] Optionally, before the first device sends the first information frame, the second device may also send a fifth information frame to the first device, the fifth information frame carrying the second device's ML-KEM capability set information. Optionally, the fifth information frame may be a Beacon frame, probe response frame, MAPC management frame, or other types of management frames used to provide the second device's ML-KEM capability set information.

[0470] In an alternative implementation, before the first device authenticates with the second device, or before the first device performs a roaming operation, the second device may also indicate the ML-KEM capability set information of its neighboring devices through the RNR and NR fields in the fifth information frame. In this case, the fifth information frame may be a Beacon frame, a probe response frame, or a Fast BSS transition management (BTM) request frame, etc.

[0471] The first device obtains the capabilities of the second device through the fifth information frame and decides whether to join the network. If it decides to join, the first device sends the first information frame. The first device can generate a pair of public and private key information based on the ML-KEM algorithm. The length of the public and private key information is related to the ML-KEM algorithm. The first device sends the generated public key information and ML-KEM information to the second device in the first information frame, while the private key information is stored locally.

[0472] The ML-KEM information can be either information about the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, authentication and AKMP field, and / or authentication algorithm numbers field. For example, the ML-KEM information can be located in the AKM subfield of the RSNE field in the first information frame.

[0473] Optionally, the ML-KEM information includes the ML-KEM type. Based on the difference in the length of the public key information / private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding public key information / private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0474] The second device receives the first information frame, generates encrypted text information and a second ML-KEM shared key based on the first device's public key information, and sends a second information frame to the first device. The second information frame includes the generated encrypted text information and ML-KEM information it supports / selects. Optionally, the second device can generate the encrypted text information and the second ML-KEM shared key based on the first device's public key information, and a locally generated random number or a second password (the second password is a password held by the second device) or parameters transformed from the second password. For example, the algorithm for generating the encrypted text information is as follows:

[0475] (K 第二 ,C)<--en.func(ek,m|pwd);

[0476] Among them, K 第二 This represents the second ML-KEM shared key, which is the shared key generated by the second device based on the ML-KEM algorithm;

[0477] C indicates encrypted text information;

[0478] m: represents a random number

[0479] ek represents the public key information of the first device;

[0480] pwd represents the password; for the second device, pwd is the second password.

[0481] en.func represents an encryption algorithm based on ML-KEM;

[0482] | indicates a logical OR operation.

[0483] Optionally, after receiving the first information frame, the second device may further detect whether the length / type of the public key information contained in the first information frame matches the ML-KEM type indicated in the ML-KEM information of the first device. If they do not match, the second device may indicate the mismatch between the public key information and the ML-KEM type via the second information frame, or send a sixth information frame to the first device to terminate the SAE process. The sixth information frame contains indication information that the public key information does not match the ML-KEM type. For example, the sixth information frame could be a deauthentication request frame.

[0484] Optionally, the second device can generate a second KCK and a second PMK based on a certain algorithm, a second ML-KEM shared key, and a second password. For example, the algorithms for generating the second KCK and the second PMK are as follows:

[0485] (1) keyseed = H(pwd, K 第二 );

[0486] (2), ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed, "ml-kel-KCK and PMK", C);

[0487] Or, ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed,"ml-kel-KCK andPMK",C,ek);

[0488] (3), the second KCK=ExtractBits(ml-kel_kck_and_pmk,0,Q);

[0489] (4). The second PMK=ExtractBits((ml-kel_kck_and_pmk,Q,PMK_bits).

[0490] Where Q represents the length of the (digital) hash function;

[0491] ExtractBits: indicates the number of bits captured, PMK_bits indicates the second PMK bit;

[0492] C: Indicates encrypted text information;

[0493] ek: Represents public key information;

[0494] K 第二 : This indicates the second ML-KEM shared key, which is the shared key obtained by the second device through encryption based on the public key information of the first device;

[0495] KDF-Hash-Length: Represents the key generation function;

[0496] keyseed: Represents the seed, an intermediate parameter value;

[0497] ml-kel-KCK and PMK: represent an input parameter.

[0498] H() represents a hash function. For example, the H() function may be SHA3, such as SHA3-256() or SHA3-512(). The output length of SHA3-256() is 256, and the output length of SHA3-512() is 512.

[0499] Optionally, the second device may also generate a second PMK using at least one of the following parameters: encrypted text information, a second ML-KEM shared key, and a second password. Optionally, the second device may also generate a second PTK using at least one of the following parameters: a second PMK, PTK Derivation, the MAC address information of the first device, and the MAC address information of the second device. For example, the algorithms for generating the second PTK and second PCK are as follows:

[0500] (1) keyseed = (pwd, K 第二 )

[0501] (2), Second PMK=KDF-Hash-Length(keyseed,“ml-kel PMK”,C);

[0502] Alternatively, the second PMK = KDF-Hash-Length(keyseed, "ml-kel PMK", C, ek);

[0503] (3) Second PTK = KDF-HASH-NNN(Second PMK, "PTK Derivation", DEV1 MAC address information || DEV2 MAC address information);

[0504] KDF-HASH-NNN: is the hash function for key generation. The specific hash function information is determined by the key suite information in the RSNE field of the second information frame. The hash function may be a SHA3-256 or SHA3-512 hash function of the SHA3 class.

[0505] The second PMK: is the paired master key information;

[0506] ml-kel PMK: is an input parameter;

[0507] PTK Derivation: A type of tag;

[0508] C: Indicates encrypted text information;

[0509] ek: Represents the public key information of the first device;

[0510] DEV1 MAC address information: The BSSID information of the first device, or its corresponding AP MLD address information, or TA information;

[0511] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or RA information;

[0512] Second ML-KEM shared key: represents the shared key obtained by the second device through encryption based on the public key information of the first device;

[0513] ||: Connector symbol.

[0514] After generating the second PTK, the second device can split the second PTK to obtain the second KCK, second TK, second KDK, and second KEK. Therefore, the length information of the second PTK is determined by the sum of the lengths of the second KCK, second TK, second KDK, and second KEK.

[0515] Second PTK_bits = Second KCK_bits + Second TK_bits + Second KDK_bits + Second KEK_bits;

[0516] Second KCK = ExtractBits(Second PTK, 0, Second KCK_bits);

[0517] Second KEK = ExtractBits(Second PTK, Second KCK_bits, Second KEK_bits);

[0518] Second TK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits, Second TK_bits);

[0519] Second KDK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits + Second TK_bits, Second KDK_bits).

[0520] Where ExtractBits is the number of bits captured, the second KCK_bits is the number of bits in the second KCK, the second TK_bits is the number of bits in the second TK, the second KEK_bits is the number of bits in the second KEK, and the second KDK_bits is the number of bits in the second KDK.

[0521] Among them, the second KCK is used to verify the first verification information and generate the second verification information, the second TK is used to encrypt subsequent data frames or other management frames, the second KDK is used to generate other key information, and the second KEK is used to encrypt authentication frames.

[0522] Optionally, the second PMKID, serving as the identifier of the second PMK, can be generated from encrypted text information and / or public key information as direct or indirect parameters. For example, the formula for generating the second PMKID is as follows:

[0523] Second PMKID = ExtractBits(C,0,128);

[0524] Alternatively, the second PMKID = ExtractBits(C|ek,0,128);

[0525] In this context, | is the connector; 128 is the number of bits, but it can also be other values.

[0526] The first device receives a second information frame sent by the second device, decrypts the encrypted text information based on the private key information corresponding to the public key information to obtain a first ML-KEM shared key, generates first verification information based on the first ML-KEM shared key and a first cipher or a variant of the first cipher, and sends a third information frame to the second device, the third information frame containing the first verification information. The first verification information is used by the second device to verify whether the key information negotiated between the two communicating parties is consistent.

[0527] The second device receives a third information frame and calculates third verification information based on a preset algorithm, a second ML-KEM shared key, and a second cipher or a variant of the second cipher. It then verifies whether the third verification information matches the first verification information. If the third verification information and the first verification information are the same, the second device determines that it holds the same cipher as the first device, and that the keys negotiated are identical. This key includes the ML-KEM shared key, PTK, KCK, TK, KDK, and / or KEK (i.e., the first ML-KEM shared key equals the second ML-KEM shared key, the first PTK equals the second PTK, the first KCK equals the second KCK, the first TK equals the second TK, the first KDK equals the second KDK, and the first KEK equals the second KEK). Conversely, if the third verification information and the first verification information are different, the second device determines that it holds a different cipher than the first device, meaning authentication fails.

[0528] Optionally, the aforementioned third verification information may be a third MIC or third confirmation information. When the third verification information is a third MIC, the second device may generate the third MIC using at least one of the following parameters: public key information, encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, second ML-KEM shared key, second cipher, second cipher variant, and second KCK.

[0529] When the third verification information is the third confirmation information, the second device can generate the third confirmation information using at least one of the following parameters: public key information, encrypted text information, second ML-KEM shared key, second password, second password variant and second KCK.

[0530] Furthermore, if the third verification information is different from the first verification information (i.e. the first verification information verification fails), the second device can also send a seventh information frame to the first device, and the status code in the seventh information frame indicates that the first verification information verification failed.

[0531] Optionally, the second device may also generate second verification information based on the second ML-KEM shared key and the second cipher or a variant of the second cipher, and send a fourth information frame to the first device, the fourth information frame containing the second verification information. The second verification information is used by the first device to verify whether the key information negotiated between the two communicating parties is consistent.

[0532] Optionally, the second verification information may include a second MIC or second confirmation information. When the second verification information is a second MIC, the second device may generate the second MIC using at least one of the following parameters: public key information, encrypted text information, the frame body of the fourth information frame, a second ML-KEM shared key, a second cipher, a second cipher variant, and a second KCK.

[0533] When the second verification information is the second confirmation information, the second device can generate the second confirmation information using at least one of the following parameters: public key information, encrypted text information, second ML-KEM shared key, second password, second password variant, and second KCK.

[0534] The first device receives a fourth information frame sent by the second device, calculates fourth verification information according to a preset algorithm and the first ML-KEM shared key, and verifies whether the fourth verification information is the same as the second verification information. If the fourth verification information and the second verification information are the same, the first device determines that it holds the same password as the second device, and that the keys negotiated based on the password are the same. This key includes the ML-KEM shared key, PTK, KCK, TK, KDK, and / or KEK (i.e., the first ML-KEM shared key equals the second ML-KEM shared key, the first PTK equals the second PTK, the first KCK equals the second KCK, the first TK equals the second TK, the first KDK equals the second KDK, and the first KEK equals the second KEK). Conversely, if the fourth verification information and the second verification information are different, the first device determines that it holds a different password than the second device, i.e., authentication fails. In the case where the fourth verification information and the second verification information are different, the first device can also send an eighth information frame to the second device. The status code of the eighth information frame is used to indicate that the second verification information verification failed. For example, the eighth information frame could be a deauthentication request frame.

[0535] Optionally, the aforementioned fourth verification information may be a fourth MIC or a fourth confirmation information. When the fourth verification information is a fourth MIC, the first device may generate the fourth MIC using at least one of the following parameters: public key information, encrypted text information, the MAC address information of the first device, the MAC address information of the second device, the frame body of the fourth information frame, the RSNE field in the beacon frame, the RSNXE field in the beacon frame, the first ML-KEM shared key, the first cipher, the first cipher variant, and the first KCK.

[0536] When the fourth verification information is the fourth confirmation information, the second device can generate the fourth confirmation information using at least one of the following parameters: public key information, encrypted text information, first ML-KEM shared key, first password, first password variant, and first KCK.

[0537] During SAE interaction, an ML-KEM shared key is generated based on the ML-KEM algorithm (the first ML-KEM shared key for the first device and the second ML-KEM shared key for the second device). Other key information is further generated based on the ML-KEM shared key and the password, so that the generated key information can resist attacks from quantum computers, thereby improving the security of Wi-Fi system communication.

[0538] The following examples illustrate the SAE interaction process based on dual ML-KEM:

[0539] Figure 24 This is another flowchart illustrating the information frame transmission method provided in this application. The method can be applied to a first device, which in this embodiment can be a STA, AP, or SMD-ME. The second device can also be a STA, AP, or SMD-ME. The first and second devices can perform an SAE interaction process through four information frames, and key information is generated based on cryptographic negotiation. Figure 24 As shown, the method may include:

[0540] S2401. Send a first information frame to the second device; wherein, the first information frame includes the first public key information and ML-KEM information of the first device;

[0541] S2402, Receive a second information frame sent by the second device; wherein the second information frame includes first encrypted text information based on the first public key information, the second public key information of the second device, and the ML-KEM information of the second device.

[0542] S2403. Based on the first private key information of the first device, decrypt the first encrypted text information to obtain the first ML-KEM shared key.

[0543] S2404. Generate second encrypted text information and a second ML-KEM shared key based on the second public key information.

[0544] S2405. Generate first verification information based on at least one of the first ML-KEM shared key and the second ML-KEM shared key, and the first password or a variant of the first password.

[0545] S2406. Send a third information frame to the second device; wherein the third information frame includes second encrypted text information and first verification information.

[0546] S2407. Receive the fourth information frame sent by the second device; wherein the fourth information frame includes the second verification information generated by the second device.

[0547] Optionally, the first device described above may include one of the following:

[0548] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0549] The second device mentioned above may include one of the following:

[0550] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0551] In this embodiment, the first device and the second device exchange four information frames to realize the SAE interaction process. The SAE interaction process can be authentication between AP and STA, authentication between AP, authentication between STA and STA, authentication between STA and SMD-ME, or authentication between SMD-ME and SMD-ME.

[0552] Figure 25 This is another interactive schematic diagram illustrating the transmission of information frames between a first device and a second device, as provided in an embodiment of this application. For example... Figure 25 As shown ( Figure 25 Taking authentication frame interaction as an example, the first device and the second device perform password authentication, key information generation and transmission based on bidirectional ML-KEM and four information frame interactions, and verify whether the key information negotiated by both parties is consistent through the first MIC and the second MIC.

[0553] Optionally, before the first device sends the first information frame, the second device may also send a fifth information frame to the first device. The fifth information frame carries the ML-KEM capability set information of the second device. The first device receives the fifth information frame sent by the second device and obtains the capabilities of the second device based on the fifth information frame. Optionally, the fifth information frame may be a Beacon frame, a probe response frame, a MAPC management frame, or other types of management frames used to provide the ML-KEM capability set information of the second device.

[0554] In an alternative implementation, before the first device authenticates with the second device, or before the first device performs a roaming operation, the second device may also indicate the ML-KEM capability set information of its neighboring devices through the RNR and NR fields in the fifth information frame. In this case, the fifth information frame may be a Beacon frame, a probe response frame, or a fast BTM request frame, etc.

[0555] The first device obtains the capabilities of the second device through the fifth information frame and decides whether to join the network. If it decides to join, the first device sends the first information frame. The first device can generate a pair of first public key information and first private key information based on the ML-KEM algorithm. The length of the first public key information and the first private key information is related to the ML-KEM algorithm. The first device sends the generated first public key information and ML-KEM information to the second device in the first information frame, while the first private key information is stored locally.

[0556] The ML-KEM information can be either information about the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, AKMP field, and / or the authentication algorithm numbers field. For example, the ML-KEM information can be located in the AKM subfield of the RSNE field in the first information frame.

[0557] Optionally, the ML-KEM information includes the ML-KEM type. Based on the difference in the length of the public key information / private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding public key information / private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0558] The second device receives the first information frame, generates first encrypted text information and a third ML-KEM shared key based on the first device's first public key information, and sends a second information frame to the first device. The second information frame includes the generated first encrypted text information, the second device's second public key information, and ML-KEM information it supports / selects. It should be noted that the second device generates a pair of second public key information and second private key information based on the ML-KEM algorithm. The length of the second public key information and the second private key information is related to the ML-KEM algorithm it supports / selects. The second device sends the second public key information to the first device through the second information frame, and the second private key information is stored locally.

[0559] Optionally, the second device can generate the first encrypted text information and the third ML-KEM shared key based on a certain algorithm, the first public key information, and locally generated random numbers, or a second cipher or a variant of the second cipher. For example, the formula for generating the first encrypted text information is as follows:

[0560] (K 第三 ,C1)<--en.func(ek1,m|pwd);

[0561] Among them, K 第三 This represents the third ML-KEM shared key, which is the shared key generated by the second device based on the ML-KEM algorithm;

[0562] C1 represents the first encrypted text information;

[0563] m represents a random number;

[0564] ek1 represents the first public key information of the first device;

[0565] pwd represents the password; for the second device, pwd is the second password.

[0566] en.func represents an encryption algorithm based on ML-KEM;

[0567] | indicates a logical OR operation.

[0568] Optionally, based on the two-way ML-KEM interaction, the ML-KEM algorithm types used by the first device and the second device can be the same or different. When the two devices use different ML-KEM algorithms to generate the corresponding public and private key information, the first device and the second device need to indicate the ML-KEM algorithm type used to generate the public and private key information in RSNE / RSNXE, respectively. For example, if the first device uses ML-KEM-512 to generate the first public and private key information, and the second device uses ML-KEM-768 to generate the second public and private key information, then the first device and the second device need to indicate the ML-KEM algorithm type used in RSNE / RSNXE, respectively. Optionally, after receiving the first information frame, the second device may further detect whether the length / type of the first public key information contained in the first information frame matches the ML-KEM type indicated in the ML-KEM information of the first device. If they do not match, the second device may indicate the mismatch between the first public key information and the ML-KEM type via the second information frame, or send a sixth information frame to the first device; wherein the sixth information frame contains indication information indicating the mismatch between the first public key information and the ML-KEM type. The first device receives the sixth information frame sent by the second device and terminates the SAE process based on the sixth information frame. Optionally, the sixth information frame may be a deauthentication request frame.

[0569] The first device receives a second information frame and checks whether the length / type of the second public key information contained in the second information frame matches the ML-KEM type indicated in the second device's ML-KEM information. If they do not match, the first device indicates the mismatch between the second public key information and the ML-KEM type via a third information frame, or sends a seventh information frame to the second device. The seventh information frame contains indication information that the second public key information does not match the ML-KEM type. Optionally, the seventh information frame may be a deauthentication request frame.

[0570] Optionally, the first device decrypts the first encrypted text information based on the first private key information corresponding to the first public key information to obtain the first ML-KEM shared key, and generates the second encrypted text information and the second ML-KEM shared key according to a certain algorithm, the second public key information of the second device, and a locally generated random number or a first password (the first password is the password held by the first device) or a variant of the first password. For example, the formula for generating the second encrypted text information is as follows:

[0571] (K 第二 ,C2)<--en.func(ek2,m|pwd);

[0572] Among them, K 第二 This represents the second ML-KEM shared key, which is the shared key generated by the first device based on the ML-KEM encryption algorithm;

[0573] C2 represents the second encrypted text message;

[0574] m represents a random number;

[0575] ek2 represents the second public key information of the second device;

[0576] pwd represents the password; for the first device, pwd is the first password.

[0577] en.func represents an encryption algorithm based on ML-KEM;

[0578] | indicates a logical OR operation.

[0579] Furthermore, the first device can generate first verification information based on at least one of the first cipher / first cipher variant and the first ML-KEM shared key and the second ML-KEM shared key, and send a third information frame to the second device. The third information frame includes second encrypted text information and the first verification information. The first verification information is used by the second device to verify whether the key information negotiated between the communicating parties is consistent. Specifically, the first device can generate a first KCK and a first PMK based on a certain algorithm, the first cipher / first cipher variant, and at least one of the first ML-KEM shared key and the second ML-KEM shared key, and generate the first verification information based on the first KCK.

[0580] Optionally, the first device may generate a first KCK based on at least one of a first password, a first password variant, first encrypted text information, second encrypted text information, and a first ML-KEM shared key and a second ML-KEM shared key; or, the first device may generate a first KCK based on at least one of a first password, a first password variant, first encrypted text information, second encrypted text information, first public key information, second public key information, and a first ML-KEM shared key and a second ML-KEM shared key; or the first device may determine the first KCK based on a first PTK. For example, the algorithms for generating the first KCK and the first PMK are as follows:

[0581] (1) keyseed = H(pwd, K);

[0582] (2), ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed, "ml-kel-KCK and PMK", C);

[0583] Or, ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed,"ml-kel-KCK andPMK",C,ek);

[0584] (3), the first KCK=ExtractBits(ml-kel_kck_and_pmk,0,Q);

[0585] (4). The first PMK=ExtractBits((ml-kel_kck_and_pmk,Q,PMK_bits).

[0586] Where Q represents the length of the (digital) hash function;

[0587] ExtractBits: indicates the number of bits captured, PMK_bits indicates the number of PMK bits;

[0588] C: Represents the first encrypted text information and / or the second encrypted text information;

[0589] ek: represents the first public key information and / or the second public key information;

[0590] K: represents at least one of the first ML-KEM shared key and the second ML-KEM shared key;

[0591] KDF-Hash-Length: Represents the key generation function;

[0592] ml-kel-KCK and PMK: represent an input parameter.

[0593] H() represents a hash function. For example, the H() function may be SHA3, such as SHA3-256() or SHA3-512(). The output length of SHA3-256() is 256, and the output length of SHA3-512() is 512.

[0594] Optionally, the first device generates the first PMK using at least one of the following parameters: encrypted text information, a first password, a first ML-KEM shared key, and a first ML-KEM shared key. Optionally, the first device generates the first PTK using at least one of the following parameters: the first PMK, PTK Derivation, the MAC address information of the first device, and the MAC address information of the second device.

[0595] For example, the generation algorithms for the first PTK and the first PMK are represented as follows:

[0596] (1) keyseed = (pwd, K)

[0597] (2), First PMK=KDF-Hash-Length(keyseed,“ml-kel PMK”,C);

[0598] Alternatively, the first PMK = KDF-Hash-Length(keyseed, "ml-kel PMK", C, ek);

[0599] (3) First PTK = KDF-HASH-NNN(First PMK, "PTK Derivation", DEV1 MAC address information || DEV2 MAC address information);

[0600] KDF-HASH-NNN: is the hash function for key generation. The specific hash function information is determined by the key suite information in the RSNE field of the first or second information frame. The hash function may be a SHA3-256 or SHA3-512 hash function, etc.

[0601] First PMK: is the paired master key information;

[0602] ml-kel PMK: is an input parameter;

[0603] PTK Derivation: A type of tag;

[0604] DEV1 MAC address information: The BSSID information of the first device, or its corresponding AP MLD address information, or TA information;

[0605] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or RA information;

[0606] K: represents at least one of the first ML-KEM shared key and the second ML-KEM shared key;

[0607] C: Represents at least one of the first encrypted text information and the second encrypted text information;

[0608] ek: indicates at least one of the first public key information and the second public key information;

[0609] ||: Connector symbol.

[0610] After generating the first PTK, the first device can split the first PTK to obtain the first KCK, first TK, first KDK, and first KEK. Therefore, the length information of the first PTK is determined by the sum of the lengths of the first KCK, first TK, first KDK, and first KEK.

[0611] First PTK_bits = First KCK_bits + First TK_bits + First KDK_bits + First KEK_bits;

[0612] First KCK = ExtractBits(First PTK, 0, First KCK_bits);

[0613] First KEK = ExtractBits(First PTK, First KCK_bits, First KEK_bits);

[0614] First TK = ExtractBits(First PTK, First KCK_bits + First KEK_bits, First TK_bits);

[0615] First KDK = ExtractBits(First PTK, First KCK_bits + First KEK_bits + First TK_bits, First KDK_bits).

[0616] Where ExtractBits is the number of bits captured, FirstKCK_bits is the number of bits in the first KCK, FirstTK_bits is the number of bits in the first TK, FirstKEK_bits is the number of bits in the first KEK, and FirstKDK_bits is the number of bits in the first KDK.

[0617] Among them, the first KCK is used to generate the first verification information and verify the second verification information, the first TK is used to encrypt subsequent data frames or other management frames, the first KDK is used to generate other key information, and the first KEK is used to encrypt authentication frames.

[0618] Optionally, the first PMKID, serving as the identifier of the first PMK, can be generated from encrypted text information and / or public key information as direct or indirect parameters. For example, the formula for generating the first PMKID is as follows:

[0619] First PMKID = ExtractBits(C, 0, 128);

[0620] Alternatively, the first PMKID = ExtractBits(C|ek,0,128);

[0621] Where | is the connector; 128 is the number of bits, which can also be other values; C represents the first encrypted text information and / or the second encrypted text information; and ek represents the first public key information and / or the second public key information.

[0622] After obtaining the first KCK, the first device may optionally generate the first MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, second ML-KEM shared key, first KCK, first cipher, first cipher variant, frame body of the third information frame, MAC address information of the first device, MAC address information of the second device, RSNE field in the beacon frame, and RSNXE field in the beacon frame.

[0623] Optionally, the first device may generate the first confirmation information using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, second ML-KEM shared key, first KCK, first password, and first password variant.

[0624] Optionally, if decryption of the first encrypted text information based on the first private key information fails, the first device may send an eighth information frame to the second device. The status code in the eighth information frame indicates that decryption of the first encrypted text information has failed, thereby terminating the SAE interaction process. Optionally, the eighth information frame may be a deauthentication request frame, and the status code contained in the deauthentication request frame indicates that decryption of the first encrypted text information has failed. In some optional embodiments, the first device may also indicate that decryption of the first encrypted text information has failed via a status code in a third information frame.

[0625] The second device receives the third information frame, decrypts the second encrypted text information based on the second private key information corresponding to the second public key information to obtain the fourth ML-KEM shared key, generates second verification information based on the second cipher / second cipher variant, and at least one of the third ML-KEM shared key and the fourth ML-KEM shared key, and sends the fourth information frame to the first device, the fourth information frame containing the second verification information.

[0626] Optionally, if the decryption of the second encrypted text information fails, the second device may send a ninth information frame to the first device. The status code in the ninth information frame indicates that the decryption of the second encrypted text information has failed, thereby terminating the SAE interaction process. For example, the ninth information frame may be a deauthentication request frame. Optionally, the second device may also indicate the decryption failure of the second encrypted text information through the status code in the fourth information frame.

[0627] Optionally, the second device can also calculate and obtain third verification information based on a preset algorithm, a second password / variant of the second password, and at least one of a third ML-KEM shared key and a fourth ML-KEM shared key, and verify whether the third verification information is the same as the first verification information. If the third verification information is different from the first verification information (i.e., the first verification information verification fails), the second device can discard the third information frame, not send the fourth information frame, or send a ninth information frame to the first device. The status code in the ninth information frame is used to indicate that the first verification information verification failed, thereby terminating the SAE interaction process. For example, the ninth information frame can be a deauthentication request frame. Optionally, the second device can also indicate that the first verification information verification failed through the status code in the fourth information frame.

[0628] Optionally, the aforementioned third verification information may be a third MIC or third confirmation information. When the third verification information is a third MIC, the second device may generate the third MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, third ML-KEM shared key, fourth ML-KEM shared key, second cipher, second cipher variant, and second KCK.

[0629] When the third verification information is the third confirmation information, the second device can generate the third confirmation information using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth ML-KEM shared key, second password, second password variant, and second KCK.

[0630] The first device receives a fourth information frame and calculates fourth verification information based on a preset algorithm, a first password / a first password variant, and at least one of a first ML-KEM shared key and a second ML-KEM shared key. It then verifies whether the fourth verification information matches the second verification information. If the fourth verification information and the second verification information are the same, the first device determines that it holds the same password as the second device, and that the keys negotiated based on the passwords are identical. This key includes the ML-KEM shared key, PTK, KCK, TK, KDK, and / or KEK (i.e., the first ML-KEM shared key equals the second ML-KEM shared key, the first PTK equals the second PTK, the first KCK equals the second KCK, the first TK equals the second TK, the first KDK equals the second KDK, and the first KEK equals the second KEK). Conversely, if the fourth verification information and the second verification information are different, the first device determines that it holds a different password than the second device, i.e., authentication fails. In the case where the fourth verification information and the second verification information are different, the first device can also send an eighth information frame to the second device. The status code of the eighth information frame indicates that the second verification information verification failed. For example, the eighth information frame could be a deauthentication request frame.

[0631] Optionally, the aforementioned fourth verification information may be a fourth MIC or a fourth confirmation information. When the fourth verification information is a fourth MIC, the first device may generate the fourth MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the fourth information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, first ML-KEM shared key, second ML-KEM shared key, first cipher, first cipher variant, and first KCK.

[0632] When the fourth verification information is the fourth confirmation information, the second device can generate the fourth confirmation information using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, second ML-KEM shared key, first password, first password variant, and first KCK.

[0633] Optionally, the third or fourth information frame may also include key information related to multicast or broadcast security protection, such as a multicast frame encryption key (Group Temporal Key, GTK), a multicast frame integrity key (Integrity Group Temporal Key, IGTK), or a beacon frame integrity key (Beacon Integrity Group Temporal Key, BIGTK). The information field containing the multicast or broadcast key portion is protected by KEK encryption.

[0634] During SAE interaction, a bidirectional ML-KEM shared key is generated through interaction, and other key information is further generated based on the ML-KEM shared key and password. This makes the generated key information resistant to attacks by quantum computers, thereby improving the security of Wi-Fi system communication.

[0635] Figure 26 This is another flowchart illustrating the information frame transmission method provided in this application. The method can be applied to a second device. In this embodiment, the first device can be a STA, AP, or SMD-ME, and the second device can also be a STA, AP, or SMD-ME. The first and second devices can perform an SAE interaction process through four information frames, and generate key information based on cryptographic negotiation. Figure 26 As shown, the method may include:

[0636] S2601. Receive a first information frame sent by the first device; wherein the first information frame includes the first public key information and ML-KEM information of the first device.

[0637] S2602. Generate first encrypted text information and third ML-KEM shared key based on the first public key information.

[0638] S2603. Send a second information frame to the first device; wherein the second information frame includes first encrypted text information, second public key information of the second device, and ML-KEM information of the second device.

[0639] S2604. Receive a third information frame sent by the first device; wherein the third information frame includes first verification information generated by the first device and second encrypted text information based on the second public key information.

[0640] S2605. Based on the second private key information of the second device, decrypt the second encrypted text information to obtain the fourth ML-KEM shared key.

[0641] S2606. Generate second verification information based on at least one of the third ML-KEM shared key and the fourth ML-KEM shared key, and a second cipher or a variant of the second cipher.

[0642] S2607. Send a fourth information frame to the first device; wherein the fourth information frame includes second verification information.

[0643] Optionally, the first device described above may include one of the following:

[0644] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0645] The second device mentioned above may include one of the following:

[0646] Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, SMD-ME.

[0647] In this embodiment, the first device and the second device exchange four information frames to realize the SAE interaction process. The SAE interaction process can be authentication between AP and STA, authentication between AP, authentication between STA and STA, authentication between STA and SMD-ME, or authentication between SMD-ME and SMD-ME.

[0648] Optionally, before the first device sends the first information frame, the second device may also send a fifth information frame to the first device, the fifth information frame carrying the second device's ML-KEM capability set information. Optionally, the fifth information frame may be a Beacon frame, probe response frame, MAPC management frame, or other types of management frames used to provide the second device's ML-KEM capability set information.

[0649] In an alternative implementation, before the first device authenticates with the second device, or before the first device performs a roaming operation, the second device may also indicate the ML-KEM capability set information of its neighboring devices through the RNR and NR fields in the fifth information frame. In this case, the fifth information frame may be a Beacon frame, a probe response frame, or a fast BTM request frame, etc.

[0650] The first device obtains the capabilities of the second device through the fifth information frame and decides whether to join the network. If it decides to join, the first device sends the first information frame. The first device can generate a pair of first public key information and first private key information based on the ML-KEM algorithm. The length of the first public key information and the first private key information is related to the ML-KEM algorithm. The first device sends the generated first public key information and ML-KEM information to the second device in the first information frame, while the first private key information is stored locally.

[0651] The ML-KEM information can be either information about the ML-KEM capabilities supported by the first device or information about the ML-KEM algorithm selected by the first device. The ML-KEM information can be located in the RSNE field, RSNXE field, AKMP field, and / or the authentication algorithm numbers field. For example, the ML-KEM information can be located in the AKM subfield of the RSNE field in the first information frame.

[0652] Optionally, the ML-KEM information includes the ML-KEM type. Based on the difference in the length of the public key information / private key information, the ML-KEM type may include at least one of the following: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with corresponding public key information / private key information lengths of 800 / 1632, 1184 / 2400, and 1568 / 3168, respectively.

[0653] The second device receives the first information frame, generates first encrypted text information and a third ML-KEM shared key based on the first device's first public key information, and sends a second information frame to the first device. The second information frame includes the generated first encrypted text information, the second device's second public key information, and ML-KEM information it supports / selects. It should be noted that the second device generates a pair of second public key information and second private key information based on the ML-KEM algorithm. The lengths of the second public key information and the second private key information are related to the ML-KEM algorithm it supports / selects. The second device sends the second public key information to the first device via the second information frame, while the second private key information is stored locally. Optionally, the second device can generate the first encrypted text information and the third ML-KEM shared key based on a certain algorithm, the first public key information, a locally generated random number, or a second password. For example, the formula for generating the first encrypted text information is as follows:

[0654] (K 第三 ,C1)<--en.func(ek1,m|pwd);

[0655] Among them, K 第三This represents the third ML-KEM shared key, which is the shared key generated by the second device based on the ML-KEM algorithm;

[0656] C1 represents the first encrypted text information;

[0657] m represents a random number;

[0658] ek1 represents the first public key information of the first device;

[0659] pwd represents the password; for the second device, pwd is the second password.

[0660] en.func represents an encryption algorithm based on ML-KEM;

[0661] | indicates a logical OR operation.

[0662] Optionally, after receiving the first information frame, the second device may further detect whether the length / type of the first public key information contained in the first information frame matches the ML-KEM type indicated in the ML-KEM information of the first device. If they do not match, the second device may indicate the mismatch between the first public key information and the ML-KEM type via the second information frame, or send a sixth information frame to the first device; wherein the sixth information frame contains indication information indicating that the first public key information does not match the ML-KEM type. Optionally, the sixth information frame may be a deauthentication request frame.

[0663] The first device receives a second information frame and checks whether the length / type of the second public key information contained in the second information frame matches the ML-KEM type indicated in the second device's ML-KEM information. If they do not match, the first device indicates the mismatch between the second public key information and the ML-KEM type via a third information frame, or sends a seventh information frame to the second device. The second device receives the seventh information frame and terminates the SAE process based on it. The seventh information frame contains indication information indicating the mismatch between the second public key information and the ML-KEM type. Optionally, the seventh information frame may be a deauthentication request frame.

[0664] Optionally, the first device decrypts the first encrypted text information based on the first private key information corresponding to the first public key information to obtain the first ML-KEM shared key, and generates the second encrypted text information and the second ML-KEM shared key according to a certain algorithm, the second public key information of the second device, and a locally generated random number or a first password (the first password is the password held by the first device) or a variant of the first password. Further, the first device can also generate first verification information based on the first password and at least one of the first ML-KEM shared key and the second ML-KEM shared key, and send a third information frame to the second device. The third information frame includes the second encrypted text information and the first verification information. The first verification information is used by the second device to verify whether the key information negotiated by the communicating parties is consistent.

[0665] Optionally, if decryption of the first encrypted text information based on the first private key information fails, the first device may send an eighth information frame to the second device. The second device receives the eighth information frame and, based on the eighth information frame, terminates the SAE process. The status code in the eighth information frame indicates that decryption of the first encrypted text information has failed. Optionally, the eighth information frame may be a deauthentication request frame, and the status code contained in the deauthentication request frame indicates that decryption of the first encrypted text information has failed. In some optional embodiments, the first device may also indicate that decryption of the first encrypted text information has failed using the status code in a third information frame.

[0666] The second device receives the third information frame, decrypts the second encrypted text information based on the second private key information corresponding to the second public key information to obtain the fourth ML-KEM shared key, generates second verification information based on the second cipher / second cipher variant, and at least one of the third and fourth ML-KEM shared keys, and sends a fourth information frame to the first device, the fourth information frame containing the second verification information. The second verification information is used by the first device to verify whether the key information negotiated by the communicating parties is consistent.

[0667] Specifically, the second device can generate a second KCK and a second PMK based on a certain algorithm, a second password / variant, and at least one of a third ML-KEM shared key and a fourth ML-KEM shared key, and generate second verification information based on the second KCK. For example, the algorithms for generating the second KCK and the second PMK are as follows:

[0668] (1) keyseed = H(pwd, K);

[0669] (2), ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed, "ml-kel-KCK and PMK", C);

[0670] Or, ml-kel_kck_and_pmk=KDF-Hash-Length(keyseed,"ml-kel-KCK andPMK",C,ek);

[0671] (3), the second KCK=ExtractBits(ml-kel_kck_and_pmk,0,Q);

[0672] (4). The second PMK=ExtractBits((ml-kel_kck_and_pmk,Q,PMK_bits).

[0673] Where Q represents the length of the (digital) hash function;

[0674] ExtractBits: indicates the number of bits captured, PMK_bits indicates the number of PMK bits;

[0675] C: Represents the first encrypted text information and / or the second encrypted text information;

[0676] ek: Represents the first public key information and / or the second public key information;

[0677] K: represents at least one of the third ML-KEM shared key and the fourth ML-KEM shared key;

[0678] KDF-Hash-Length: Represents the key generation function;

[0679] ml-kel-KCK and PMK: represent an input parameter.

[0680] H() represents a hash function. For example, the H() function may be SHA3, such as SHA3-256() or SHA3-512(). The output length of SHA3-256() is 256, and the output length of SHA3-512() is 512.

[0681] Optionally, the second device generates the second PMK using at least one of the following parameters: first encrypted text information, second encrypted text information, second password, second password variant, third ML-KEM shared key, and fourth ML-KEM shared key. Optionally, the first device generates the second PTK using at least one of the following parameters: second PMK, PTK Derivation, MAC address information of the first device, and MAC address information of the second device.

[0682] For example, the second PTK and second PCK generation algorithms are represented as follows:

[0683] (1) keyseed = (pwd, K)

[0684] (2), Second PMK=KDF-Hash-Length(keyseed,“ml-kel PMK”,C);

[0685] Alternatively, the second PMK = KDF-Hash-Length(keyseed, "ml-kel PMK", C, ek);

[0686] (3) Second PTK = KDF-HASH-NNN(Second PMK, "PTK Derivation", DEV1 MAC address information || DEV2 MAC address information);

[0687] KDF-HASH-NNN: is the hash function for key generation. The specific hash function information is determined by the key suite information in the RSNE field of the first or second information frame. The hash function may be a SHA3-256 or SHA3-512 hash function, etc.

[0688] The second PMK: is the paired master key information;

[0689] ml-kel PMK: A label;

[0690] PTK Derivation: A type of tag;

[0691] DEV1 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or TA information;

[0692] DEV2 MAC address information: BSSID information of the second device, or its corresponding AP MLD address information, or RA information;

[0693] K: represents at least one of the third ML-KEM shared key and the fourth ML-KEM shared key;

[0694] C: Represents at least one of the first encrypted text information and the second encrypted text information;

[0695] ek: indicates at least one of the first public key information and the second public key information;

[0696] ||: Connector symbol.

[0697] After generating the second PTK, the second device can split the second PTK to obtain the second KCK, second TK, second KDK, and second KEK. Therefore, the length information of the second PTK is determined by the sum of the lengths of the second KCK, second TK, second KDK, and second KEK.

[0698] Second PTK_bits = Second KCK_bits + Second TK_bits + Second KDK_bits + Second KEK_bits;

[0699] Second KCK = ExtractBits(Second PTK, 0, Second KCK_bits);

[0700] Second KEK = ExtractBits(Second PTK, Second KCK_bits, Second KEK_bits);

[0701] Second TK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits, Second TK_bits);

[0702] Second KDK = ExtractBits(Second PTK, Second KCK_bits + Second KEK_bits + Second TK_bits, Second KDK_bits).

[0703] Where ExtractBits is the number of bits captured, the second KCK_bits is the number of bits in the second KCK, the second TK_bits is the number of bits in the second TK, the second KEK_bits is the number of bits in the second KEK, and the second KDK_bits is the number of bits in the second KDK.

[0704] Optionally, the second PMKID, serving as the identifier of the second PMK, can be generated from encrypted text information and / or public key information as direct or indirect parameters. For example, the formula for generating the second PMKID is as follows:

[0705] Second PMKID = ExtractBits(C2,0,128);

[0706] Alternatively, the second PMKID = ExtractBits(C2|ek1,0,128);

[0707] Wherein, | is the connector; 128 is the number of bits, which can also be other values. The encrypted text information here may include first encrypted text information and / or second encrypted text information, and the public key information may include first public key information and / or second public key information.

[0708] Among them, the second KCK is used to generate the second verification information and verify the first verification information, the second TK is used to encrypt subsequent data frames or other management frames, the second KDK is used to generate other key information, and the second KEK is used to encrypt authentication frames.

[0709] After obtaining the second KCK, the second device may optionally generate the second MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth ML-KEM shared key, second KCK, second cipher, second cipher variant, frame body of the fourth information frame, MAC address information of the first device, MAC address information of the second device, RSNE field in the beacon frame, and RSNXE field in the beacon frame.

[0710] Optionally, the second device may generate the second confirmation information using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth ML-KEM shared key, second KCK, second password, and second password variant.

[0711] Optionally, if the decryption of the second encrypted text information fails, the second device may send a ninth information frame to the first device. The status code in the ninth information frame indicates that the decryption of the second encrypted text information has failed, thereby terminating the SAE interaction process. For example, the ninth information frame may be a deauthentication request frame. Optionally, the second device may also indicate the decryption failure of the second encrypted text information through the status code in the fourth information frame.

[0712] Optionally, the second device can also calculate and obtain third verification information based on a preset algorithm, a second password / variant of the second password, and at least one of a third ML-KEM shared key and a fourth ML-KEM shared key, and verify whether the third verification information is the same as the first verification information. If the third verification information is different from the first verification information (i.e., the first verification information verification fails), the second device can discard the third information frame, not send the fourth information frame, or send a ninth information frame to the first device. The status code in the ninth information frame is used to indicate that the first verification information verification failed, thereby terminating the SAE interaction process. For example, the ninth information frame can be a deauthentication request frame. Optionally, the second device can also indicate that the first verification information verification failed through the status code in the fourth information frame.

[0713] Optionally, the aforementioned third verification information may be a third MIC or third confirmation information. When the third verification information is a third MIC, the second device may generate the third MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the third information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, third ML-KEM shared key, fourth ML-KEM shared key, second cipher, second cipher variant, and second KCK.

[0714] Optionally, when the third verification information is the third confirmation information, the second device can generate the third confirmation information using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth ML-KEM shared key, second password, second password variant, and second KCK.

[0715] The first device receives the fourth information frame and calculates the fourth verification information based on a preset algorithm, the first password / first password variant, and at least one of the first ML-KEM shared key and the second ML-KEM shared key. It then verifies whether the fourth verification information matches the second verification information. If the fourth verification information and the second verification information are the same, the first device sends an eighth information frame to the second device. The eighth information frame carries success information, indicating successful authentication. If the fourth verification information and the second verification information are different, the first device sends an eighth information frame to the second device. The status code of the eighth information frame indicates a failure.

[0716] Optionally, the aforementioned fourth verification information may be a fourth MIC or a fourth confirmation information. When the fourth verification information is a fourth MIC, the first device may generate the fourth MIC using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, MAC address information of the first device, MAC address information of the second device, frame body of the fourth information frame, RSNE field in the beacon frame, RSNXE field in the beacon frame, first ML-KEM shared key, second ML-KEM shared key, first cipher, first cipher variant, and first KCK.

[0717] When the fourth verification information is the fourth confirmation information, the second device can generate the fourth confirmation information using at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, second ML-KEM shared key, first password, first password variant, and first KCK.

[0718] During SAE interaction, a bidirectional ML-KEM shared key is generated through interaction, and other key information is further generated based on the ML-KEM shared key and password. This makes the generated key information resistant to attacks by quantum computers, thereby improving the security of Wi-Fi system communication.

[0719] Figure 27 This is another interactive schematic diagram illustrating the transmission of information frames between a first device and a second device, as provided in an embodiment of this application. For example... Figure 27As shown, the first device and the second device interact through seven information frames to generate and transmit cryptographic key information, and verify the consistency of the cryptographically negotiated key information between the two parties through the first MIC and the second MIC. In this embodiment, the information frame transmission process can include two stages. The first stage can be a probing stage, in which the first device transmits its supported ML-KEM capability information to the second device, and the second device obtains the first device's public key information (i.e., the first public key information) through a query. The probing stage can include the following steps S2701-S2703. Subsequently, the second stage can be triggered according to the needs of the second device. The second stage can be an SAE authentication stage, in which the first device and the second device perform the SAE interaction process through four authentication frames, and generate key information based on cryptographic negotiation. The SAE authentication stage can include the following steps S2704-S2707. Figure 27 As shown, the method may include:

[0720] S2701, The second device sends the tenth information frame to the first device.

[0721] Among them, the tenth information frame ( Figure 27 The tenth information frame (10) includes information on the ML-KEM capabilities supported by the second device. For example, the tenth information frame may be a Beacon frame, which provides information on the ML-KEM capabilities supported by the second device. For instance, the first device may indicate its supported ML-KEM capabilities through one or more bits in the RSNXE field of the Beacon frame.

[0722] S2702, The first device sends the eleventh information frame to the second device.

[0723] Among them, the eleventh information frame ( Figure 27 Information frame 11) is used to query the first public key information corresponding to the target ML-KEM information. The target ML-KEM information can be one or more of the ML-KEM capability information. That is, the first device can select one or more ML-KEM capability information as the target ML-KEM information based on the ML-KEM capability information supported by the second device, based on its own supported ML-KEM information, or based on its preferred ML-KEM information, and carry the selected one or more target ML-KEM information in the eleventh information frame to request the second device to query the first public key information corresponding to one or more target ML-KEM information. Optionally, the RSNXE field in the eleventh information frame contains one or more target ML-KEM information selected by the first device. Optionally, the eleventh information frame can be a probe request frame.

[0724] S2703, The second device sends the twelfth information frame to the first device.

[0725] Among them, the twelfth information frame ( Figure 27 Information frame 12) serves as a response frame to the eleventh information frame, including one or more target ML-KEM information and the first public key information corresponding to the one or more target ML-KEM information. Optionally, the twelfth information frame can be a probe response frame. Optionally, the twelfth information frame can be a unicast or broadcast type information frame. See also... Figure 14 The first public key information may include one or more public key elements, such as element ID (element identifier information, used to uniquely identify the field), length (length information, used to indicate the length of the public key itself or the length of the entire public key field), ML-KEM type (ML-KEM type information, used to identify the specific algorithm corresponding to ML-KEM, such as ML-KEM-512, ML-KEM-768, ML-KEM-1024) and public key (the public key information itself).

[0726] Furthermore, the second device can generate different public key information for different first devices, that is, it can generate different public key information for different first devices based on the identification information (such as the MAC address information of the first device) contained in the twelfth information frame.

[0727] S2704, The first device sends the first information frame to the second device.

[0728] The first information frame includes first encrypted text information based on the first public key information, second public key information of the first device, and ML-KEM information of the first device.

[0729] Optionally, the first device generates a first encrypted text message and a first ML-KEM shared key based on the first public key information and a locally generated random number or a first password.

[0730] S2705, The second device sends a second information frame to the first device.

[0731] Specifically, the second device generates a second encrypted text message and a third ML-KEM shared key based on the second public key information provided by the first device, and a locally generated random number or a second password. Optionally, the second device can also decrypt the first encrypted text message based on the first private key information to obtain a fourth ML-KEM shared key, generate the second encrypted text message based on the second password, and at least one of the third and fourth ML-KEM shared keys, and send a second information frame to the first device. The second information frame includes the second encrypted text message and the ML-KEM information of the second device.

[0732] S2706, The first device sends a third information frame to the second device.

[0733] The first device decrypts the second encrypted text information based on the second private key information to obtain the second ML-KEM shared key. Based on the first password and at least one of the first and second ML-KEM shared keys, it generates first verification information and fourth verification information, and sends a third information frame to the second device. The third information frame contains the first verification information, which is used by the second device to confirm whether the key negotiated with the first device is consistent. Optionally, the first verification information includes a first MIC or first confirmation information. The fourth verification information is used to verify the second verification information.

[0734] S2707, The second device sends a fourth information frame to the first device.

[0735] The second device generates second and third verification information based on a second cryptography and at least one of a third and a fourth ML-KEM shared key, and sends a fourth information frame to the first device. The fourth information frame contains the second verification information. The second verification information includes a second MIC or second confirmation information, and is used by the first device to confirm whether the key information negotiated between it and the second device is consistent. The third verification information is used to verify the first verification information.

[0736] It should be noted that the generation process of the first verification information, the second verification information, the third verification information, and the fourth verification information, as well as the verification process of the first verification information using the third verification information and the verification process of the second verification information using the fourth verification information, can all refer to the description in the above embodiments, and will not be repeated here.

[0737] In this embodiment, the first device and the second device can query public key information through three information frames, and then execute the SAE interaction process through four information frames (such as authentication frames). The ML-KEM algorithm is integrated with the SAE interaction process, so that the generated key information can resist attacks from quantum computers, thereby improving the security of Wi-Fi system communication.

[0738] In one embodiment, an information frame transmission method is also provided, applied to a first device, comprising:

[0739] Send a first information frame to the second device; wherein the first information frame includes the public key information and ML-KEM information of the first device;

[0740] Receive a second information frame sent by a second device; wherein the second information frame includes encrypted text information based on public key information and ML-KEM information of the second device;

[0741] The first ML-KEM shared key is obtained by decrypting the encrypted text information based on the private key information of the first device, and the first verification information is generated based on the first ML-KEM shared key and the first password or a variant of the first password.

[0742] Send a third information frame to the second device; wherein the third information frame includes the first verification information;

[0743] Receive a fourth information frame sent by the second device; wherein the fourth information frame includes second verification information generated by the second device.

[0744] In one embodiment, it further includes:

[0745] Receive a fifth information frame sent by the second device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or the neighboring devices of the second device.

[0746] In one embodiment, the ML-KEM information resides in at least one of the following fields:

[0747] The fields are RSNE, RSNXE, AKMP, and Information Algorithm Number.

[0748] In one embodiment, the ML-KEM information includes at least one of the following:

[0749] ML-KEM-512;

[0750] ML-KEM-768;

[0751] ML-KEM-1024.

[0752] In one embodiment, when the first verification information is a first MIC, the first MIC is generated using at least one of the following parameters:

[0753] The information includes public key information, encrypted text information, a first ML-KEM shared key, a first KCK, a first cipher, a first cipher variant, the frame body of a third information frame, the MAC address information of the first device, the MAC address information of the second device, the RSNE field in the beacon frame, and the RSNXE field in the beacon frame; wherein, the first KCK is obtained based on the first ML-KEM shared key and the first cipher or the first cipher variant.

[0754] In one embodiment, when the first verification information is the first confirmation information, the first confirmation information is generated using at least one of the following parameters:

[0755] Public key information, encrypted text information, first ML-KEM shared key, first KCK, first cipher, and first cipher variant; wherein, the first KCK is obtained based on the first ML-KEM shared key and the first cipher / first cipher variant.

[0756] In one embodiment, it also includes at least one of the following:

[0757] Receive the sixth information frame sent by the second device; wherein the sixth information frame includes an indication that the public key information does not match the ML-KEM type;

[0758] Receive the seventh information frame sent by the second device; wherein the status code in the seventh information frame is used to indicate that the first verification information verification failed;

[0759] If the decryption of the encrypted text information fails or the verification of the second verification information fails, an eighth information frame is sent; the status code in the eighth information frame is used to indicate that the decryption of the encrypted text information fails or the verification of the second verification information fails.

[0760] In one embodiment, the first PMK is generated using at least one of the following parameters:

[0761] Encrypted text information, first ML-KEM shared key, first password, first password variant.

[0762] In one embodiment, the first PTK is generated using at least one of the following parameters:

[0763] First PMK, PTK Derivation, MAC address information of the first device, MAC address information of the second device.

[0764] In one embodiment, the first PMKID is generated using at least one of the following parameters:

[0765] Encrypted text information and public key information.

[0766] In one embodiment, an information frame transmission method is also provided, applied to a second device, comprising:

[0767] Receive a first information frame sent by a first device; wherein the first information frame includes the public key information and ML-KEM information of the first device;

[0768] Generate encrypted text information and a second ML-KEM shared key based on public key information;

[0769] Send a second information frame to the first device; wherein the second information frame includes encrypted text information and the ML-KEM information of the second device;

[0770] Receive a third information frame sent by the first device; wherein the third information frame includes first verification information generated by the first device;

[0771] Generate second verification information based on the second ML-KEM shared key and the second cryptography / second cryptography variant;

[0772] A fourth information frame is sent to the first device; wherein the fourth information frame includes second verification information.

[0773] In one embodiment, when the second verification information is the second MIC, the second MIC is generated using at least one of the following parameters:

[0774] The frame contains public key information, encrypted text information, a second ML-KEM shared key, a second KCK, a second cipher, a variant of the second cipher, and the frame body of a fourth information frame; wherein the second KCK is obtained based on the second ML-KEM shared key and the second cipher.

[0775] In one embodiment, when the second verification information is the second confirmation information, the second confirmation information is generated using at least one of the following parameters:

[0776] Public key information, encrypted text information, second ML-KEM shared key, second KCK, second cipher, and second cipher variant; wherein, the second KCK is obtained based on the second ML-KEM shared key and the second cipher / second cipher variant.

[0777] In one embodiment, it further includes:

[0778] Send a fifth information frame to the first device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or the neighboring devices of the second device.

[0779] In one embodiment, it also includes at least one of the following:

[0780] If a mismatch is detected between the public key information and the ML-KEM type, a sixth information frame is sent to the first device; wherein, the sixth information frame includes indication information indicating that the public key information does not match the ML-KEM type;

[0781] If the first verification fails, a seventh information frame is sent; the status code in the seventh information frame is used to indicate that the first verification failed.

[0782] The system receives an eighth information frame sent by the first device; wherein the status code in the eighth information frame is used to indicate that the encrypted text information failed to be decrypted or the second verification information failed to be verified.

[0783] In one embodiment, the second PMK is generated using at least one of the following parameters:

[0784] Encrypted text information, second ML-KEM shared key, second password, and second password variant.

[0785] In one embodiment, the second PTK is generated using at least one of the following parameters:

[0786] Second PMK, PTK Derivation, MAC address information of the first device, and MAC address information of the second device.

[0787] In one embodiment, an information frame transmission method is also provided, applied to a first device, the method comprising:

[0788] Send a first information frame to the second device; wherein the first information frame includes the first public key information and ML-KEM information of the first device;

[0789] Receive a second information frame sent by a second device; wherein the second information frame includes first encrypted text information based on the first public key information, the second public key information of the second device, and the ML-KEM information of the second device;

[0790] The first ML-KEM shared key is obtained by decrypting the first encrypted text information based on the first private key information of the first device.

[0791] Generate a second encrypted text message and a second ML-KEM shared key based on the second public key information;

[0792] First verification information is generated based on at least one of the first ML-KEM shared key and the second ML-KEM shared key, and a first password or a variant of the first password;

[0793] Send a third information frame to the second device; wherein the third information frame includes second encrypted text information and first verification information;

[0794] Receive a fourth information frame sent by the second device; wherein the fourth information frame includes second verification information generated by the second device.

[0795] In one embodiment, it further includes:

[0796] Receive a fifth information frame sent by the second device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or the neighboring devices of the second device.

[0797] In one embodiment, the ML-KEM information resides in at least one of the following fields:

[0798] The fields are RSNE, RSNXE, AKMP, and Information Algorithm Number.

[0799] In one embodiment, the ML-KEM information includes at least one of the following:

[0800] ML-KEM-512;

[0801] ML-KEM-768;

[0802] ML-KEM-1024.

[0803] In one embodiment, when the second verification information is the first MIC, the first MIC is generated using at least one of the following parameters:

[0804] The information includes: first public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, second ML-KEM shared key, first KCK, first cipher, first cipher variant, frame body of the third information frame, MAC address information of the first device, MAC address information of the second device, RSNE field in the beacon frame, and RSNXE field in the beacon frame.

[0805] In one embodiment, when the first verification information is the first confirmation information, the first confirmation information is generated using at least one of the following parameters:

[0806] First public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, first KCK, first cipher, first cipher variant.

[0807] In one embodiment, it also includes at least one of the following:

[0808] Receive the sixth information frame sent by the second device; wherein the sixth information frame includes an indication that the first public key information does not match the ML-KEM type;

[0809] If the second public key information is detected to be mismatched with the ML-KEM type, a seventh information frame is sent to the second device; wherein, the seventh information frame includes indication information that the second public key information is mismatched with the ML-KEM type;

[0810] Send an eighth information frame to the second device; wherein, the status code in the eighth information frame is used to indicate that the first encrypted text information failed to be decrypted or the second verification information failed to be verified.

[0811] Receive the ninth information frame sent by the second device; wherein the status code in the ninth information frame is used to indicate that the second encrypted text information failed to be decrypted or the first verification information failed to be verified.

[0812] In one embodiment, it also includes at least one of the following:

[0813] A first KCK is generated based on at least one of a first password, a first password variant, a first encrypted text message, a second encrypted text message, and a first ML-KEM shared key and a second ML-KEM shared key;

[0814] A first KCK is generated based on at least one of the first cipher, a first cipher variant, a first encrypted text message, a second encrypted text message, a first public key message, a second public key message, and a first ML-KEM shared key and a second ML-KEM shared key;

[0815] Determine the first KCK based on the first PTK;

[0816] The first KCK is used to generate the first verification information and to verify the second verification information.

[0817] In one embodiment, the first PMK is generated using at least one of the following parameters:

[0818] First encrypted text information, second encrypted text information, first password, first ML-KEM shared key, first ML-KEM shared key.

[0819] In one embodiment, the first PTK is generated using at least one of the following parameters:

[0820] First PMK, PTK Derivation, MAC address information of the first device, MAC address information of the second device.

[0821] In one embodiment, the first PMKID is generated using at least one of the following parameters:

[0822] First encrypted text information, second encrypted text information, first public key information, and second public key information.

[0823] In one embodiment, an information frame transmission method is also provided, applied to a second device, comprising:

[0824] Receive a first information frame sent by a first device; wherein the first information frame includes the first public key information and ML-KEM information of the first device;

[0825] Generate a first encrypted text message and a third ML-KEM shared key based on the first public key information;

[0826] Send a second information frame to the first device; wherein the second information frame includes first encrypted text information, second public key information of the second device, and ML-KEM information of the second device;

[0827] Receive a third information frame sent by the first device; wherein the third information frame includes second encrypted text information based on the second public key information and first verification information generated by the first device;

[0828] The fourth ML-KEM shared key is obtained by decrypting the second encrypted text information based on the second private key information of the second device.

[0829] The second verification information is generated based on at least one of the third ML-KEM shared key and the fourth ML-KEM shared key, and a second cryptography or a variant of the second cryptography.

[0830] A fourth information frame is sent to the first device; wherein the fourth information frame includes second verification information.

[0831] In one embodiment, when the second verification information is the second MIC, the second MIC is generated using at least one of the following parameters:

[0832] First public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth ML-KEM shared key, second KCK, second cipher, second cipher variant, fourth information frame body, MAC address information of the first device and MAC address information of the second device.

[0833] In one embodiment, when the second verification information is the second confirmation information, the second confirmation information is generated using at least one of the following parameters:

[0834] First public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth MK-KEM shared key, second KCK, second cipher, and second cipher variant.

[0835] In one embodiment, it further includes:

[0836] Send a fifth information frame to the first device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or the neighboring devices of the second device.

[0837] In one embodiment, it also includes at least one of the following:

[0838] If an indication is detected that the first public key information does not match the ML-KEM type, a sixth information frame is sent to the first device; wherein the sixth information frame includes the indication that the first public key information does not match the ML-KEM type.

[0839] Receive the seventh information frame sent by the first device; wherein the seventh information frame includes an indication that the second public key information does not match the ML-KEM type;

[0840] The system receives an eighth information frame sent by the first device; wherein the status code in the eighth information frame is used to indicate that the first encrypted text information failed to be decrypted or the second verification information failed to be verified.

[0841] A ninth information frame is sent to the first device; wherein the status code in the ninth information frame is used to indicate that the second encrypted text information failed to be decrypted or the first verification information failed to be verified.

[0842] In one embodiment, it also includes at least one of the following:

[0843] The second KCK is generated based on the second password, the first encrypted text information, the second encrypted text information, and at least one of the third ML-KEM shared key and the fourth ML-KEM shared key;

[0844] The second KCK is generated based on at least one of the second password, the first encrypted text information, the second encrypted text information, the first public key information, the second public key information, and the third ML-KEM shared key and the fourth ML-KEM shared key;

[0845] Determine the second KCK based on the second PTK;

[0846] The second KCK is used to generate the second verification information and to verify the first verification information.

[0847] In one embodiment, the second PMK is generated using at least one of the following parameters:

[0848] First encrypted text information, second encrypted text information, second password, second password variant, third ML-KEM shared key, fourth ML-KEM shared key.

[0849] In one embodiment, the second PTK is generated using at least one of the following parameters:

[0850] Second PMK, PTK Derivation, MAC address information of the first device, and MAC address information of the second device.

[0851] In one embodiment, the third or fourth information frame also includes key information related to multicast or broadcast security protection.

[0852] Figure 28 This is a schematic diagram of an information frame transmission device provided in an embodiment of this application. The device is integrated into a first device, such as... Figure 28 As shown, the device includes: a transmitting module 2801, a receiving module 2802, and a processing module 2803.

[0853] Specifically, the sending module 2801 is used to send a first information frame to the second device; wherein, the first information frame includes the public key information and ML-KEM information of the first device;

[0854] The receiving module 2802 is used to receive a second information frame sent by the second device; wherein the second information frame includes encrypted text information based on public key information and ML-KEM information of the second device;

[0855] The processing module 2803 is used to decrypt the encrypted text information based on the private key information of the first device to obtain the first ML-KEM shared key, and generate the first verification information based on the first ML-KEM shared key and the first password or a variant of the first password;

[0856] The sending module 2801 is also used to send a third information frame to the second device; wherein the third information frame includes first verification information;

[0857] The receiving module 2802 is also used to receive a fourth information frame sent by the second device; wherein the fourth information frame includes second verification information generated by the second device.

[0858] In one embodiment, the receiving module 2802 is further configured to receive a fifth information frame sent by the second device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or neighboring devices of the second device.

[0859] In one embodiment, the ML-KEM information is located in at least one of the following fields: RSNE field, RSNXE field, AKMP field, and information algorithm number field.

[0860] In one embodiment, the ML-KEM information includes at least one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

[0861] In one embodiment, when the first verification information is the first MIC, the first MIC is generated by at least one of the following parameters: public key information, encrypted text information, first ML-KEM shared key, first KCK, first cipher, first cipher variant, frame body of the third information frame, MAC address information of the first device, MAC address information of the second device, RSNE field in the beacon frame and RSNXE field in the beacon frame; wherein, the first KCK is obtained based on the first ML-KEM shared key and the first cipher.

[0862] In one embodiment, when the first verification information is the first confirmation information, the first confirmation information is generated by at least one of the following parameters: public key information, encrypted text information, first ML-KEM shared key, first KCK, first password, and first password variant; wherein, the first KCK is obtained based on the first ML-KEM shared key and the first password.

[0863] In one embodiment, the receiving module 2802 is further configured to receive a sixth information frame sent by the second device; and to receive a seventh information frame sent by the second device; wherein the sixth information frame includes indication information indicating that the public key information does not match the ML-KEM type; and the status code in the seventh information frame is used to indicate that the first verification information verification failed.

[0864] The sending module 2801 is also used to send an eighth information frame in the event that the encrypted text information fails to be decrypted or the second verification information fails to be verified; wherein the status code in the eighth information frame is used to indicate that the encrypted text information fails to be decrypted or the second verification information fails to be verified.

[0865] In one embodiment, the first PMK is generated using at least one of the following parameters:

[0866] Encrypted text information, first ML-KEM shared key, first password, first password variant.

[0867] In one embodiment, the first PTK is generated using at least one of the following parameters:

[0868] First PMK, PTK Derivation, MAC address information of the first device, MAC address information of the second device.

[0869] In one embodiment, the first PMKID is generated using at least one of the following parameters:

[0870] Encrypted text information and public key information.

[0871] Figure 29 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application. The apparatus is integrated into a second device, such as... Figure 29 As shown, the device includes: a receiving module 2901, a processing module 2902, and a transmitting module 2903.

[0872] Specifically, the receiving module 2901 is used to receive a first information frame sent by the first device; wherein, the first information frame includes the public key information and ML-KEM information of the first device;

[0873] Processing module 2902 is used to generate encrypted text information and a second ML-KEM shared key based on public key information;

[0874] The sending module 2903 is used to send a second information frame to the first device; wherein the second information frame includes encrypted text information and the ML-KEM information of the second device;

[0875] The receiving module 2901 is also configured to receive a third information frame sent by the first device; wherein the third information frame includes first verification information generated by the first device;

[0876] Processing module 2902 is also used to generate second verification information based on the second ML-KEM shared key and the second cryptography or a variant of the second cryptography;

[0877] The sending module 2903 is also used to send a fourth information frame to the first device; wherein the fourth information frame includes second verification information.

[0878] In one embodiment, when the second verification information is the second MIC, the second MIC is generated by at least one of the following parameters: public key information, encrypted text information, second ML-KEM shared key, second KCK, second cipher, second cipher variant and frame body of the fourth information frame; wherein the second KCK is obtained based on the second ML-KEM shared key and the second cipher.

[0879] In one embodiment, when the second verification information is the second confirmation information, the second confirmation information is generated by at least one of the following parameters: public key information, encrypted text information, second ML-KEM shared key, second KCK and second password; wherein, the second KCK is obtained based on the second ML-KEM shared key and second password or a variant of the second password.

[0880] In one embodiment, the sending module 2903 is further configured to send a fifth information frame to the first device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or the neighboring devices of the second device.

[0881] In one embodiment, the sending module 2903 is further configured to send a sixth information frame to the first device when a mismatch is detected between the public key information and the ML-KEM type; and to send a seventh information frame when the verification of the first verification information fails based on the second ML-KEM shared key and the second password or a variant of the second password; wherein the sixth information frame includes indication information that the public key information does not match the ML-KEM type; and the status code in the seventh information frame is used to indicate that the verification of the first verification information has failed.

[0882] The receiving module 2901 is also used to receive the eighth information frame sent by the first device; wherein the status code in the eighth information frame is used to indicate that the encrypted text information failed to be decrypted or the second verification information failed to be verified.

[0883] In one embodiment, the second PMK is generated using at least one of the following parameters: encrypted text information, a second ML-KEM shared key, and a second password.

[0884] In one embodiment, the second PTK is generated using at least one of the following parameters: the second PMK, PTKDerivation, the MAC address information of the first device, and the MAC address information of the second device.

[0885] Figure 30 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application. The apparatus is integrated into the first device, such as... Figure 30 As shown, the device includes: a transmitting module 3001, a receiving module 3002, and a processing module 3003.

[0886] Specifically, the sending module 3001 is used to send a first information frame to the second device; wherein, the first information frame includes the first public key information and ML-KEM information of the first device;

[0887] The receiving module 3002 is used to receive a second information frame sent by the second device; wherein, the second information frame includes first encrypted text information based on the first public key information, the second public key information of the second device, and the ML-KEM information of the second device;

[0888] The processing module 3003 is used to decrypt the first encrypted text information based on the first private key information of the first device to obtain the first ML-KEM shared key; generate the second encrypted text information and the second ML-KEM shared key based on the second public key information; and generate the first verification information based on at least one of the first ML-KEM shared key and the second ML-KEM shared key, and the first password.

[0889] The sending module 3001 is also used to send a third information frame to the second device; wherein the third information frame includes second encrypted text information and first verification information;

[0890] The receiving module 3002 is also used to receive a fourth information frame sent by the second device; wherein the fourth information frame includes second verification information generated by the second device.

[0891] In one embodiment, the receiving module 3002 is further configured to receive a fifth information frame sent by the second device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or the neighboring devices of the second device.

[0892] In one embodiment, the ML-KEM information is located in at least one of the following fields: RSNE field, RSNXE field, AKMP field, and information algorithm number field.

[0893] In one embodiment, the ML-KEM information includes at least one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

[0894] In one embodiment, when the second verification information is the first MIC, the first MIC is generated by at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, second ML-KEM shared key, first KCK, first cipher, first cipher variant, frame body of the third information frame, MAC address information of the first device, MAC address information of the second device, RSNE field in the beacon frame, and RSNXE field in the beacon frame.

[0895] In one embodiment, when the first verification information is the first confirmation information, the first confirmation information is generated by at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, first ML-KEM shared key, first KCK, first password, and first password variant.

[0896] In one embodiment, the receiving module 3002 is further configured to receive a sixth information frame sent by the second device; wherein the sixth information frame includes indication information indicating that the first public key information does not match the ML-KEM type;

[0897] The sending module 3001 is further configured to send a seventh information frame to the second device when it detects that the second public key information does not match the ML-KEM type; wherein the seventh information frame includes indication information that the second public key information does not match the ML-KEM type;

[0898] The sending module 3001 is also used to send an eighth information frame to the second device; wherein, the status code in the eighth information frame is used to indicate that the first encrypted text information failed to be decrypted or the second verification information failed to be verified.

[0899] The receiving module 3002 is also used to receive the ninth information frame sent by the second device; wherein the status code in the ninth information frame is used to indicate that the second encrypted text information failed to be decrypted or the first verification information failed to be verified.

[0900] In one embodiment, the processing module 3003 is further configured to perform at least one of the following:

[0901] A first KCK is generated based on at least one of a first password, a first password variant, a first encrypted text message, a second encrypted text message, and a first ML-KEM shared key and a second ML-KEM shared key;

[0902] A first KCK is generated based on at least one of the first cipher, a first cipher variant, a first encrypted text message, a second encrypted text message, a first public key message, a second public key message, and a first ML-KEM shared key and a second ML-KEM shared key;

[0903] Determine the first KCK based on the first PTK;

[0904] The first KCK is used to generate the first verification information and to verify the second verification information.

[0905] In one embodiment, the first PMK is generated by at least one of the following parameters: first encrypted text information, second encrypted text information, first password, first password variant, first ML-KEM shared key, and first ML-KEM shared key.

[0906] In one embodiment, the first PTK is generated using at least one of the following parameters: first PMK, PTKDerivation, MAC address information of the first device, and MAC address information of the second device.

[0907] In one embodiment, the first PMKID is generated using at least one of the following parameters: first encrypted text information, second encrypted text information, first public key information, and second public key information.

[0908] Figure 31 This is another schematic diagram of the information frame transmission apparatus provided in the embodiments of this application. The apparatus is integrated into a second device, such as... Figure 31 As shown, the device includes a receiving module 3101, a processing module 3102, and a transmitting module 3103.

[0909] Specifically, the receiving module 3101 is used to receive a first information frame sent by the first device; wherein, the first information frame includes the first public key information and ML-KEM information of the first device;

[0910] Processing module 3102 is used to generate first encrypted text information and third ML-KEM shared key based on the first public key information;

[0911] The sending module 3103 is used to send a second information frame to the first device; wherein, the second information frame includes first encrypted text information, second public key information of the second device, and ML-KEM information of the second device;

[0912] The receiving module 3101 is also used to receive a third information frame sent by the first device; wherein the third information frame includes first verification information generated by the first device and second encrypted text information based on the second public key information;

[0913] The processing module 3102 is further configured to decrypt the second encrypted text information based on the second private key information of the second device to obtain the fourth ML-KEM shared key; and generate second verification information based on at least one of the third ML-KEM shared key and the fourth ML-KEM shared key, and the second password.

[0914] The sending module 3103 is also used to send a fourth information frame to the first device; wherein the fourth information frame includes second verification information.

[0915] In one embodiment, when the second verification information is the second MIC, the second MIC is generated by at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth ML-KEM shared key, second KCK, second cipher, second cipher variant, frame body of the fourth information frame, MAC address information of the first device and MAC address information of the second device.

[0916] In one embodiment, when the second verification information is the second confirmation information, the second confirmation information is generated by at least one of the following parameters: first public key information, second public key information, first encrypted text information, second encrypted text information, third ML-KEM shared key, fourth MK-KEM shared key, second KCK, second password, and second password variant.

[0917] In one embodiment, the sending module 3103 is further configured to send a fifth information frame to the first device; wherein the fifth information frame includes ML-KEM capability set information of the second device and / or the neighboring devices of the second device.

[0918] In one embodiment, the sending module 3103 is further configured to send a sixth information frame to the first device when an indication that the first public key information does not match the ML-KEM type is detected; wherein the sixth information frame includes the indication that the first public key information does not match the ML-KEM type.

[0919] The receiving module 3101 is also used to receive a seventh information frame sent by the first device; and to receive an eighth information frame sent by the first device; wherein the seventh information frame includes an indication that the second public key information does not match the ML-KEM type; and the status code in the eighth information frame is used to indicate that the first encrypted text information failed to be decrypted or the second verification information failed to be verified.

[0920] The sending module 3103 is also used to send a ninth information frame to the first device; wherein the status code in the ninth information frame is used to indicate that the second encrypted text information failed to be decrypted or the first verification information failed to be verified.

[0921] In one embodiment, the processing module 3102 is further configured to: generate a second KCK based on at least one of a second password, a second password variant, a first encrypted text message, a second encrypted text message, and at least one of a third ML-KEM shared key and a fourth ML-KEM shared key;

[0922] The second KCK is generated based on at least one of the second cipher, a variant of the second cipher, the first encrypted text information, the second encrypted text information, the first public key information, the second public key information, and the third ML-KEM shared key and the fourth ML-KEM shared key;

[0923] Determine the second KCK based on the second PTK;

[0924] The second KCK is used to generate the second verification information and to verify the first verification information.

[0925] In one embodiment, the second PMK is generated using at least one of the following parameters: first encrypted text information, second encrypted text information, second password, second password variant, third ML-KEM shared key, and fourth ML-KEM shared key.

[0926] In one embodiment, the second PTK is generated using at least one of the following parameters: the second PMK, PTKDerivation, the MAC address information of the first device, and the MAC address information of the second device.

[0927] In one embodiment, the third or fourth information frame also includes key information related to multicast or broadcast security protection.

[0928] In one embodiment, the internal structure diagram of the above-mentioned communication device can be as follows: Figure 32 As shown, the communication device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data generated during information frame transmission. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the information frame transmission method provided in any of the above embodiments.

[0929] Those skilled in the art will understand that Figure 32The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the communication device to which the present application is applied. Specific communication devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0930] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the information frame transmission method provided in any of the above embodiments.

[0931] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. Computer-readable storage media include (a non-exhaustive list): electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), electrically erasable, programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0932] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, the data signals carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0933] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, radio frequency (RF), or any suitable combination thereof.

[0934] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination of programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, Ruby, and Go) and conventional procedural programming languages ​​(such as the "C" language or similar programming languages). The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a Local Area Network (LAN) or a Wide Area Network (WAN)), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0935] Those skilled in the art will understand that the term user terminal encompasses any suitable type of wireless user equipment, such as mobile phones, portable data processing devices, portable web browsers, or vehicle-mounted mobile stations.

[0936] Generally, the various embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. For example, some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, although this application is not limited thereto.

[0937] Embodiments of this application can be implemented by executing computer program instructions through the data processor of a mobile device, for example, in a processor entity, or through hardware, or through a combination of software and hardware. The computer program instructions can be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages.

[0938] Any block diagram of logical flow in the accompanying drawings of this application may represent program steps, or may represent interconnected logic circuits, modules, and functions, or may represent a combination of program steps and logic circuits, modules, and functions. The computer program may be stored in memory. The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as, but not limited to, read-only memory (ROM), random access memory (RAM), optical storage devices and systems (Digital Multifunction Discs, DVDs, or CDs), etc. Computer-readable media may include non-transitory storage media. The data processor may be of any type suitable to the local technical environment, such as, but not limited to, general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and processors based on multi-core processor architectures.

Claims

1. A method for transmitting information frames, characterized in that, Applied to the first device, including: Send a first information frame to the second device; wherein, the first information frame includes the public key information of the first device and the ML-KEM key encapsulation mechanism information based on the lattice model; Receive a second information frame sent by the second device; wherein the second information frame includes encrypted text information based on the public key information, a first information integrity check code (MIC), and the ML-KEM information of the second device; The encrypted text information is decrypted based on the private key information of the first device to obtain the first ML-KEM shared key; Generate a second MIC based on the first ML-KEM shared key; A third information frame is sent to the second device; wherein the third information frame includes the second MIC.

2. The method according to claim 1, characterized in that, The ML-KEM information includes ML-KEM-based authentication modes and / or ML-KEM types.

3. The method according to claim 2, characterized in that, The ML-KEM-based authentication mode includes at least one of the following: Open mode based on ML-KEM; Peer-to-peer authentication model based on cryptography and ML-KEM; FILS mode for establishing a fast initial connection based on ML-KEM; Rapid transfer of basic service sets based on ML-KEM to FT mode.

4. The method according to claim 2, characterized in that, The ML-KEM type includes at least one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

5. The method according to claim 1, characterized in that, The ML-KEM information is located in at least one of the following fields: The robust secure network element RSNE field, the extended robust secure network element RSNXE field, the authentication and key management protocol AKMP field, and the authentication algorithm number field.

6. The method according to claim 1, characterized in that, It also includes at least one of the following: Receive a fourth information frame sent by the second device; wherein the fourth information frame includes an indication that the public key information does not match the ML-KEM type; In the event that the encrypted text information fails to be decrypted and / or the first MIC verification fails, the second information frame is discarded, the third information frame is not sent, or a fifth information frame is sent to the second device; wherein, the status code in the fifth information frame is used to indicate that the encrypted text information failed to be decrypted and / or the first MIC verification failed; The system receives a sixth information frame sent by the second device; wherein the status code in the sixth information frame is used to indicate the verification result of the second MIC.

7. The method according to claim 1, characterized in that, The status code in the third information frame is used to indicate one of the following states: The encrypted text information failed to be decrypted; The first MIC verification failed; Success message.

8. The method according to claim 1, characterized in that, Also includes: A first paired temporary key PTK is generated based on the first ML-KEM shared key.

9. The method according to claim 8, characterized in that, The step of generating the first PTK based on the first ML-KEM shared key includes: The first PTK is generated based on the pairwise master key PMK, the first ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation derived from the securely negotiated pairwise transport key before extended association, and a hash function. Alternatively, the first ML-KEM shared key can be determined as the first PTK.

10. The method according to claim 8, characterized in that, The second MIC is generated using at least one of the following parameters: The public key information, the encrypted text information, the MAC address information of the first device, the MAC address information of the second device, the frame body of the first information frame, the frame body of the third information frame, the RSNE field in the beacon frame, the RSNXE field in the beacon frame, and the first key confirmation key KCK; wherein, the first KCK is obtained based on the first PTK.

11. The method according to claim 1, characterized in that, Before sending the first information frame to the second device, the method further includes: The device receives a seventh information frame sent by the second device; wherein the seventh information frame includes PASN indication information supporting ML-KEM.

12. The method according to claim 1, characterized in that, The first device includes one of the following: Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobility domain management entity; The second device includes one of the following: Single-link device, multi-link device, single-radio multi-link device, enhanced multi-radio multi-link device, fast BSS transfer initiator in roaming domain, single-link access point, access point with multi-access point collaboration capability, multi-link access point, fast BSS transfer responder in roaming domain, seamless mobile domain management entity.

13. A method for transmitting information frames, characterized in that, Applied to a second device, including: Receive a first information frame sent by the first device; wherein the first information frame includes the public key information and ML-KEM information of the first device; Based on the public key information, encrypted text information and a second ML-KEM shared key are generated, and a first MIC is generated based on the second ML-KEM shared key; Send a second information frame to the first device; wherein the second information frame includes the encrypted text information, the first MIC, and the ML-KEM information of the second device; The system receives a third information frame sent by the first device; wherein the third information frame includes a second MIC generated by the first device.

14. The method according to claim 1, characterized in that, The ML-KEM information includes ML-KEM-based authentication modes and / or ML-KEM types.

15. The method according to claim 14, characterized in that, The ML-KEM-based authentication mode includes at least one of the following: Open mode based on ML-KEM; Peer-to-peer authentication model based on cryptography and ML-KEM; FILS pattern based on ML-KEM; FT mode based on ML-KEM.

16. The method according to claim 14, characterized in that, The ML-KEM type includes at least one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

17. The method according to claim 13, characterized in that, The ML-KEM information is located in at least one of the following fields: The fields are RSNE, RSNXE, AKMP, and Authentication Algorithm Number.

18. The method according to claim 13, characterized in that, It also includes at least one of the following: If the public key information is detected to be mismatched with the ML-KEM type, a fourth information frame is sent to the first device; wherein, the fourth information frame includes indication information indicating that the public key information is mismatched with the ML-KEM type; The system receives a fifth information frame sent by the first device; wherein the status code in the fifth information frame is used to indicate that the encrypted text information failed to be decrypted and / or the first MIC verification failed. A sixth information frame is sent to the first device; wherein the status code in the sixth information frame is used to indicate the verification result of the second MIC.

19. The method according to claim 13, characterized in that, The status code in the third information frame is used to indicate one of the following states: The encrypted text information failed to be decrypted; The first MIC verification failed; Success message.

20. The method according to claim 13, characterized in that, Also includes: A second PTK is generated based on the second ML-KEM shared key.

21. The method according to claim 20, characterized in that, The step of generating the second PTK based on the second ML-KEM shared key includes: The second PTK is generated based on the PMK, the second ML-KEM shared key, the MAC address information of the first device, the MAC address information of the second device, the PASN PTK Derivation, and a hash function; Alternatively, the second ML-KEM shared key can be determined as the second PTK.

22. The method according to claim 13, characterized in that, Also includes: The third MIC is calculated based on the preset algorithm and the second ML-KEM shared key, and it is verified whether the third MIC is the same as the second MIC. If the third MIC is different from the second MIC, the PASN interaction process is terminated.

23. The method according to claim 20, characterized in that, The first MIC is generated using at least one of the following parameters: The public key information, the encrypted text information, the MAC address information of the first device, the MAC address information of the second device, the frame body of the second information frame, the RSNE field in the beacon frame, the RSNXE field in the beacon frame, and the second KCK; wherein, the second KCK is obtained based on the second PTK.

24. The method according to claim 13, characterized in that, Before receiving the first information frame sent by the first device, the method further includes: A seventh information frame is sent to the first device; wherein the seventh information frame includes PASN indication information supporting ML-KEM.

25. A method for transmitting information frames, characterized in that, Applied to the first device, including: Send a first information frame to the second device; wherein the first information frame includes the first public key information and ML-KEM information of the first device; Receive a second information frame sent by the second device; wherein the second information frame includes first encrypted text information based on the first public key information, the second public key information of the second device, and the ML-KEM information of the second device; Based on the first private key information of the first device, the first encrypted text information is decrypted to obtain the first ML-KEM shared key; Generate a second encrypted text message and a second ML-KEM shared key based on the second public key information; A first MIC is generated based on at least one of the first ML-KEM shared key and the second ML-KEM shared key; Send a third information frame to the second device; wherein the third information frame includes the second encrypted text information and the first MIC; The device receives a fourth information frame sent by the second device; wherein the fourth information frame includes a second MIC generated by the second device.

26. The method according to claim 25, characterized in that, The ML-KEM information includes ML-KEM-based authentication modes and / or ML-KEM types.

27. The method according to claim 26, characterized in that, The ML-KEM-based authentication mode includes one of the following: Open mode based on ML-KEM; Peer-to-peer authentication model based on cryptography and ML-KEM; FILS pattern based on ML-KEM; FT mode based on ML-KEM.

28. The method according to claim 26, characterized in that, The ML-KEM type includes one of the following: ML-KEM-512; ML-KEM-768; ML-KEM-1024.

29. The method according to claim 25, characterized in that, It also includes at least one of the following: The device receives a fifth information frame sent by the second device; wherein the fifth information frame is triggered by the second device when it detects an indication that the first public key information does not match the ML-KEM type, and the fifth information frame includes the indication that the first public key information does not match the ML-KEM type. If the second public key information is detected to be mismatched with the ML-KEM type, a sixth information frame is sent to the second device; wherein, the sixth information frame includes indication information that the second public key information is mismatched with the ML-KEM type; If the first encrypted text information fails to be decrypted, the second information frame is discarded, the third information frame is not sent, or a seventh information frame is sent to the second device; wherein, the status code in the seventh information frame is used to indicate that the first encrypted text information failed to be decrypted. The system receives an eighth information frame sent by the second device; wherein the status code in the eighth information frame is used to indicate that the decryption of the second encrypted text information failed and / or the verification of the first MIC failed.

30. The method according to claim 25, characterized in that, The status code in the fourth information frame is used to indicate one of the following states: The second encrypted text message failed to be decrypted; The first MIC verification failed; Success message.

31. The method according to claim 25, characterized in that, Also includes: The third MIC is calculated based on a preset algorithm and at least one of the first ML-KEM shared key and the second ML-KEM shared key, and the third MIC is verified to be the same as the second MIC. If the third MIC is different from the second MIC, the PASN interaction process is terminated.

32. The method according to claim 25, characterized in that, Also includes: A first PTK is generated based on the first ML-KEM shared key and / or the second ML-KEM shared key.

33. The method according to claim 32, characterized in that, The step of generating the first PTK based on the first ML-KEM shared key and / or the second ML-KEM shared key includes: A first PTK is generated based on the PMK, the MAC address information of the first device, the MAC address information of the second device, the PASN PTKDerivation, the hash function, and at least one of the first ML-KEM shared key and the second ML-KEM shared key; Alternatively, at least one of the first ML-KEM shared key and the second ML-KEM shared key may be determined as the first PTK.

34. The method according to claim 32, characterized in that, The first MIC is generated using at least one of the following parameters: The information includes first public key information, second public key information, first encrypted text information, second encrypted text information, RSNE field in the beacon frame, RSNXE field in the beacon frame, frame body of the first information frame, frame body of the third information frame, MAC address information of the first device, MAC address information of the second device, and first KCK; wherein, the first KCK is obtained based on the first PTK.

35. The method according to claim 25, characterized in that, Before sending the first information frame to the second device, the method further includes: Send a ninth information frame to the second device; wherein the ninth information frame includes ML-KEM capability information supported by the first device; The device receives a tenth information frame sent by a second device; the tenth information frame is used to query the first public key information corresponding to the target ML-KEM information, wherein the target ML-KEM information is one or more of the ML-KEM capability information.

36. A method for transmitting information frames, characterized in that, Applied to a second device, including: Receive a first information frame sent by the first device; wherein the first information frame includes the first public key information and ML-KEM information of the first device; Generate a first encrypted text message and a third ML-KEM shared key based on the first public key information; Send a second information frame to the first device; wherein the second information frame includes the first encrypted text information, the second public key information of the second device, and the ML-KEM information of the second device; The device receives a third information frame sent by the first device; wherein the third information frame includes a first MIC generated by the first device and second encrypted text information based on the second public key information; Based on the second private key information of the second device, the second encrypted text information is decrypted to obtain the fourth ML-KEM shared key; A second MIC is generated based on at least one of the third ML-KEM shared key and the fourth ML-KEM shared key; A fourth information frame is sent to the first device; wherein the fourth information frame includes the second MIC.

37. The method according to claim 36, characterized in that, It also includes at least one of the following: If the first public key information is detected to be mismatched with the ML-KEM type, a fifth information frame is sent to the first device; wherein, the fifth information frame includes indication information that the first public key information is mismatched with the ML-KEM type; The first device receives a sixth information frame; wherein the sixth information frame is triggered by the first device when it detects an indication that the second public key information does not match the ML-KEM type, and the sixth information frame includes the indication that the second public key information does not match the ML-KEM type. The system receives a seventh information frame sent by the first device; wherein the status code in the seventh information frame is used to indicate that the first encrypted text information failed to be decrypted or the second MIC verification failed; in the case that the second encrypted text information failed to be decrypted and / or the first MIC verification failed, the system discards the third information frame or does not send the fourth information frame or sends an eighth information frame to the first device; wherein the status code in the eighth information frame is used to indicate that the second encrypted text information failed to be decrypted and / or the first MIC verification failed.

38. The method according to claim 36, characterized in that, The status code in the fourth information frame is used to indicate one of the following states: The second encrypted text message failed to be decrypted; The first MIC verification failed; Success message.

39. The method according to claim 36, characterized in that, Also includes: Receive a ninth information frame sent by the first device; wherein the ninth information frame includes ML-KEM capability information supported by the first device; Send a tenth information frame to the first device; wherein the tenth information frame is used to query the first public key information corresponding to the target ML-KEM information, and the target ML-KEM information is one or more of the ML-KEM capability information.

40. The method according to claim 36, characterized in that, Also includes: The second PTK is generated based on the third ML-KEM shared key and / or the fourth ML-KEM shared key.

41. The method according to claim 40, characterized in that, The step of generating the second PTK based on the third ML-KEM shared key and / or the fourth ML-KEM shared key includes: The second PTK is generated based on the PMK, the MAC address information of the first device, the MAC address information of the second device, the PASN PTKDerivation, the hash function, and at least one of the third ML-KEM shared key and the fourth ML-KEM shared key; Alternatively, at least one of the third ML-KEM shared key and the fourth ML-KEM shared key may be identified as the second PTK.

42. The method according to claim 40, characterized in that, The second MIC is generated using at least one of the following parameters: The information includes first public key information, second public key information, first encrypted text information, second encrypted text information, RSNE field in the beacon frame, RSNXE field in the beacon frame, frame body of the second information frame, frame body of the fourth information frame, MAC address information of the first device, MAC address information of the second device, and second KCK; wherein, the second KCK is obtained based on the second PTK.

43. A communication device, characterized in that, include: A memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method according to any one of claims 1-42.

44. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-42.

Images