Authentication method, key generation method and equipment

Abstract

The invention relates to an authentication method, a key generation method, equipment, a computer readable storage medium, a computer program product and a computer program. The method comprises: a first device receiving a first message from a first network device, the first message carrying an MAC, an authentication parameter and an identifier of a second device; the first device sends a second message to the second device, the second message carrying the MAC and the authentication parameter, the authentication parameter is used by the second device to obtain a verification MAC based on a root key, and the verification MAC is used by the second device to authenticate a core network side device in combination with the MAC. The root key is a key shared by the second device and the core network side device.

Description

[0001] This application is a divisional application of patent application filed on May 6, 2023, with application number 202380097723.5 and title "Authentication Method, Key Generation Method and Apparatus". Technical Field

[0002] This application relates to the field of communications, and more specifically, to an authentication method, a key generation method, an apparatus, a computer-readable storage medium, a computer program product, and a computer program. Background Technology

[0003] In related technologies, the authentication process between the UE (User Equipment) and the core network, as well as the key negotiation process, involve computationally complex functions and intricate key architectures. However, zero-power devices, such as A-IoT devices, also require access to networks, such as the core network. Therefore, the challenge lies in enabling A-IoT devices to achieve authentication with the network side while maintaining security, using computationally less complex methods. Summary of the Invention

[0004] This application provides an authentication method, a key generation method, an apparatus, a computer-readable storage medium, a computer program product, and a computer program.

[0005] This application provides an authentication method, including:

[0006] The first device receives a first message from a first network device, the first message carrying MAC, authentication parameters, and the identifier of the second device;

[0007] The first device sends a second message to the second device. The second message carries the MAC and the authentication parameters. The authentication parameters are used by the second device to obtain the verification MAC based on the root key. The verification MAC is used by the second device to authenticate the core network side device in combination with the MAC. The root key is a key shared by the second device and the core network side device.

[0008] This application provides an authentication method, including:

[0009] The second device receives a second message from the first device, the second message carrying a message authentication code (MAC) and authentication parameters;

[0010] The second device calculates and verifies the MAC based on the authentication parameters and the root key, where the root key is a key shared by the second device and the core network side device;

[0011] If the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

[0012] This application provides an authentication method, including:

[0013] A first network device sends a first message to a first device, wherein the first message carries a message authentication code (MAC), authentication parameters, and an identifier of the second device. The authentication parameters are used by the second device to obtain a verification MAC based on a root key. The verification MAC is used by the second device to authenticate core network side devices in conjunction with the MAC. The root key is a key shared by the second device and all core network side devices.

[0014] This application provides a key generation method, including:

[0015] An electronic device calculates an integrity protection key and / or an encryption key, wherein the integrity protection key is associated with key generation parameters and a third random number, and the encryption key is associated with key generation parameters and a fourth random number. The key generation parameters include an anonymous key and / or a first random number. The integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt transmitted data and / or decrypt received data.

[0016] This application provides an authentication method, including:

[0017] The first device receives a first message from a first network device, the first message carrying authentication parameters and the identifier of the second device;

[0018] The first device sends a second message to the second device, the second message carrying authentication parameters;

[0019] The first device receives a third message from the second device, the third message carrying a first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices;

[0020] The first device sends a fourth message to the first network device, the fourth message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0021] This application provides an authentication method, including:

[0022] The second device receives a second message from the first device, the second message carrying authentication parameters;

[0023] The second device calculates the first RES based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and all core network side devices;

[0024] The second device sends a third message to the first device, the third message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0025] This application provides an authentication method, including:

[0026] The first network device sends a first message to the first device, the first message carrying authentication parameters and the identifier of the second device;

[0027] The first network device receives a fourth message from the first device, the fourth message carrying the first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices;

[0028] If the first network device determines that the second device has been authenticated when the first RES is the same as the first verification RES.

[0029] This application provides an authentication method, including:

[0030] The first device sends a second message to the second device, the second message carrying authentication parameters;

[0031] The first device receives a third message from the second device, the third message carrying a second RES, the second RES being related to the authentication parameters and the first key;

[0032] The first device generates a second verification RES based on the authentication parameters and the first key;

[0033] If the second verification RES is the same as the second verification RES, the first device determines that the second device has passed authentication.

[0034] This application provides an authentication method, including:

[0035] The second device receives a second message from the first device, the second message carrying authentication parameters;

[0036] The second device calculates the second RES based on the authentication parameters and the physical layer key, wherein the first key is associated with the first device;

[0037] The second device sends a third message to the first device, the third message carrying the second RES, the second RES being used by the first device to authenticate the second device.

[0038] This application provides a first device, including:

[0039] A first communication unit is configured to receive a first message from a first network device, the first message carrying a MAC, authentication parameters, and an identifier of a second device; and to send a second message to the second device, the second message carrying the MAC and the authentication parameters, the authentication parameters being used by the second device to obtain a verification MAC based on a root key, the verification MAC being used by the second device to authenticate a core network-side device in conjunction with the MAC, and the root key being a key shared by the second device and the core network-side device.

[0040] This application provides a second device, including:

[0041] The second communication unit is used to receive a second message from the first device, the second message carrying a message authentication code (MAC) and authentication parameters;

[0042] The second processing unit is used to calculate the verification MAC based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and the core network side device; if the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

[0043] This application provides a first network device, including:

[0044] The third communication unit is used to send a first message to the first device, wherein the first message carries a message authentication code (MAC), authentication parameters, and an identifier of the second device. The authentication parameters are used by the second device to obtain a verification MAC based on the root key. The verification MAC is used by the second device to authenticate core network side devices in conjunction with the MAC. The root key is a key shared by the second device and all core network side devices.

[0045] This application provides an electronic device, including:

[0046] The fourth processing unit is used to calculate an integrity protection key and / or an encryption key, wherein the integrity protection key is related to key generation parameters and a third random number, the encryption key is related to the key generation parameters and a fourth random number, the key generation parameters include an anonymous key and / or a first random number, the integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt the sent data and / or decrypt the received data.

[0047] This application provides a first device, including:

[0048] A first communication unit is configured to receive a first message from a first network device, the first message carrying authentication parameters and an identifier of a second device; send a second message to the second device, the second message carrying authentication parameters; receive a third message from the second device, the third message carrying a first RES, the first RES being obtained by the second device based on the authentication parameters and a root key, the root key being a key shared by the second device and all core network side devices; and send a fourth message to the first network device, the fourth message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0049] This application provides a second device, including:

[0050] The second communication unit is configured to receive a second message from the first device, the second message carrying authentication parameters; and to send a third message to the first device, the third message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0051] The second processing unit is used to calculate the first RES based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and all core network side devices.

[0052] This application provides a first network device, including:

[0053] The third communication unit is configured to send a first message to the first device, the first message carrying authentication parameters and the identifier of the second device; and to receive a fourth message from the first device, the fourth message carrying the first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices;

[0054] The third processing unit is used to determine that the second device has passed authentication if the first RES is the same as the first verification RES.

[0055] This application provides a first device, including:

[0056] A first communication unit is configured to send a second message to a second device, the second message carrying authentication parameters; and to receive a third message from the second device, the third message carrying a second RES, the second RES being associated with the authentication parameters and the first key.

[0057] A first processing unit is configured to generate a second verification RES based on the authentication parameters and the first key; and to determine that the second device authentication is successful if the second verification RES is the same as the first verification RES.

[0058] This application provides a second device, including:

[0059] The second communication unit is configured to receive a second message from the first device, the second message carrying authentication parameters; and to send a third message to the first device, the third message carrying the second RES, the second RES being used by the first device to authenticate the second device.

[0060] The second processing unit is used to calculate the second RES based on authentication parameters and a first key, wherein the first key is associated with the first device.

[0061] This application provides a first device, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the first device to perform the described method.

[0062] This application provides a second device, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the second device to perform the method described above.

[0063] This application provides a first network device, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the first network device to perform the methods described above.

[0064] This application provides an electronic device including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the electronic device to perform the methods described above.

[0065] This application provides a chip for implementing the above method.

[0066] Specifically, the chip includes a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to perform the methods described above.

[0067] This application provides a computer-readable storage medium for storing a computer program, which, when run by a device, causes the device to perform the above-described method.

[0068] This application provides a computer program product, including computer program instructions that cause a computer to perform the above-described method.

[0069] This application provides a computer program that, when run on a computer, causes the computer to perform the above-described method.

[0070] By employing the scheme provided in this embodiment, the first device sends authentication parameters to the second device, enabling the second device to directly calculate the verification MAC based on the authentication parameters and the root key shared with the core network device. The second device then authenticates the core network device based on the received MAC. This ensures the security of the authentication process between the second device and the core network device while avoiding complex calculations on the second device's side, thus improving its processing efficiency, especially suitable for devices with lower computing power. Attached Figure Description

[0071] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of this application.

[0072] Figure 2 This is a schematic flowchart of an authentication method according to an embodiment of this application.

[0073] Figure 3 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0074] Figure 4 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0075] Figure 5 This is a schematic flowchart of a key generation method according to an embodiment of this application.

[0076] Figures 6-20 These are schematic diagrams of various example processes, key architectures, and authentication architectures according to an embodiment of the present application.

[0077] Figure 21 This is a schematic flowchart of an authentication method according to an embodiment of this application.

[0078] Figure 22 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0079] Figure 23 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0080] Figure 24 This is a schematic flowchart of an authentication method according to an embodiment of this application.

[0081] Figure 25 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0082] Figure 26 This is a schematic diagram illustrating a scenario where AIoT devices access a network in related technologies.

[0083] Figure 27 This is a diagram of the AKA certification process.

[0084] Figure 28 This is a schematic diagram of the authentication architecture for related technologies.

[0085] Figure 29 This is a schematic diagram of the key architecture in related technologies.

[0086] Figure 30 This is a schematic block diagram of a first device according to an embodiment of the present application.

[0087] Figure 31 This is a schematic block diagram of a second device according to an embodiment of this application.

[0088] Figure 32 This is a schematic block diagram of a first network device according to an embodiment of the present application.

[0089] Figure 33 This is a schematic block diagram of an electronic device according to an embodiment of this application.

[0090] Figure 34 This is a schematic block diagram of a communication device according to an embodiment of this application.

[0091] Figure 35 This is a schematic block diagram of a chip according to an embodiment of this application.

[0092] Figure 36 This is a schematic block diagram of a communication system according to an embodiment of this application. Detailed Implementation

[0093] The technical solutions of this application embodiment can be applied to various communication systems, such as GSM, CDMA, WCDMA, GPRS, LTE, LTE-A, NR, NR evolution, WLAN, WiFi, or other communication systems.

[0094] This application describes various embodiments in conjunction with network devices and terminals. The terminal can be mobile or fixed, and may also be referred to as a mobile station, user unit, etc. The terminal can be a station in a WLAN, or a smart terminal, wireless modem, laptop, tablet, etc. In this application's embodiments, the terminal can be a VR / AR terminal, industrial control terminal, autonomous driving terminal, telemedicine terminal, smart grid terminal, transportation safety terminal, smart city terminal, or smart home wireless terminal, etc. By way of example and not limitation, in this application's embodiments, the terminal can also be a wearable device.

[0095] In this embodiment, the network device can be a device for communicating with a terminal. The network device can be an access point in a WLAN, a base station in GSM, CDMA, or WCDMA, an evolved base station in LTE, a relay station, a network device (gNB) in a vehicle-mounted device, wearable device, or NR network, or a network device in a future evolved PLMN network, or a network device in a non-terrestrial network, etc. By way of example and not limitation, in this embodiment, the network device can have mobility characteristics; for example, the network device can be a mobile device.

[0096] It should be understood that the terms "system" and "network" are often used interchangeably in this document. The term "and / or" in this document merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should be understood that the term "instruction" mentioned in the embodiments of this application can be a direct instruction, an indirect instruction, or an indication of a related relationship. For example, A instructing B can mean that A directly instructs B, for example, B can be obtained through A; it can also mean that A indirectly instructs B, for example, A instructs C, B can be obtained through C; or it can mean that there is a related relationship between A and B. In the description of the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an related relationship between two things, or a relationship of instruction and being instructed, configuration and being configured, etc.

[0097] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0098] Figure 1An exemplary communication system 100 is illustrated. This communication system includes a network device 110 and two terminals 120. In one possible implementation, the communication system 100 may include multiple network devices 110, and the coverage area of ​​each network device 110 may include other numbers of terminals 120; this embodiment does not limit this. In one possible implementation, the communication system 100 may also include mobility management entities, access and mobility management functions, and other network entities; this embodiment does not limit this. The network devices may further include access network devices and core network devices. That is, the communication system may also include multiple core networks for communicating with the access network devices. The access network devices may be base stations for LTE, LTE-A, or NR systems. Figure 1 Taking the communication system shown as an example, the communication equipment may include network devices and terminals with communication functions. The communication equipment may also include other devices in the communication system, such as network controllers, mobility management entities and other network entities. This application embodiment does not limit this.

[0099] Figure 2 This is a schematic flowchart illustrating an authentication method according to an embodiment of this application. The method includes at least a portion of the following.

[0100] S210, the first device receives a first message from the first network device, the first message carrying MAC, authentication parameters and the identifier of the second device;

[0101] S220. The first device sends a second message to the second device. The second message carries the MAC and the authentication parameters. The authentication parameters are used by the second device to obtain the verification MAC based on the root key. The verification MAC is used by the second device to authenticate the core network side device in combination with the MAC. The root key is a key shared by the second device and the core network side device.

[0102] Figure 3 This is a schematic flowchart of an authentication method according to another embodiment of this application. The method includes at least a portion of the following.

[0103] S310, the second device receives a second message from the first device, the second message carrying a message authentication code (MAC) and authentication parameters;

[0104] S320. The second device calculates the verification MAC based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and all core network side devices.

[0105] S330. If the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

[0106] Figure 4 This is a schematic flowchart of an authentication method according to another embodiment of this application. The method includes at least a portion of the following.

[0107] S410. The first network device sends a first message to the first device, wherein the first message carries a message authentication code (MAC), authentication parameters, and the identifier of the second device. The authentication parameters are used by the second device to obtain a verification MAC based on the root key. The verification MAC is used by the second device to authenticate the core network side device in combination with the MAC. The root key is a key shared by the second device and all core network side devices.

[0108] Figure 5 This is a schematic flowchart of a key generation method according to another embodiment of this application. The method includes at least a portion of the following.

[0109] S510. The electronic device calculates an integrity protection key and / or an encryption key, wherein the integrity protection key is related to a key generation parameter and a third random number, the encryption key is related to the key generation parameter and a fourth random number, the key generation parameter includes an anonymous key and / or a first random number, the integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt the transmitted data and / or decrypt the received data.

[0110] The core network side equipment includes one or more core network devices and an authentication server (AS).

[0111] The second device is an Ambient IoT (AIoT) device, which can also be represented as an A-IoT device. This embodiment does not exhaustively list all possible representations. In some possible examples, the second device can also be a zero-power device, such as an active zero-power device, a passive zero-power device, or a semi-passive zero-power device, etc. Optionally, the second device can be called a tag, and optionally, it can also be an IoT device, etc. In other possible examples, the second device can be a terminal with low computing power. All possible names or possible devices for the second device are not exhaustively listed here.

[0112] The first device includes at least one of the following: a terminal device, an access network device, an authentication device (Authenticator), and a first core network device. The first core network device may include at least one of the following: AMF (Access and Mobility Management Function), SEAF (Security Anchor Function), or a core network element dedicated to AIoT services (e.g., simply referred to as an AIoT network element); additionally, the first core network device may also be a network element of other core networks, which are not exhaustively listed here.

[0113] The one or more core network devices may include at least one of the following: AUSF, UDM (Unified Data Management), and ARPF (Authentication Credential Repository and Processing Function). It should be understood that this is merely illustrative; in actual processing, the one or more core network devices may also include other core network devices, but this is not an exhaustive list. The first network device may be one of the aforementioned core network-side devices; for example, the first network device is AUSF (Authentication Server Function) or an authentication server.

[0114] In some possible implementations, the authentication parameters include one of the following: an anonymous key (AK) or a first random number.

[0115] The second device calculates the verification MAC based on the authentication parameters and the root key, which may include one of the following: the second device calculates the verification MAC based on the anonymous key and the root key using a first calculation method; the second device calculates the anonymous key by XORing the first random number and the root key, and then calculates the verification MAC based on the anonymous key and the root key using the first calculation method; the second device calculates the first random number by XORing the anonymous key and the root key, and then calculates the verification MAC based on the first random number and the root key using the first calculation method; or the second device calculates the verification MAC based on the first random number and the root key using the first calculation method.

[0116] Optionally, the authentication parameters include an anonymous key. Accordingly, the second device calculates the verification MAC based on the authentication parameters and the root key, which may include one of the following: the second device calculates the verification MAC based on the anonymous key and the root key using a first calculation method; the second device XORs the anonymous key and the root key to calculate the first random number, and then calculates the verification MAC based on the first random number and the root key using the first calculation method.

[0117] Here, the first calculation method may include at least one of the following: a second authentication function, a hash algorithm, Advanced Encryption Standard (AES), ACSON, SNOW 3G (SnowThirdGeneration), or ZUC (ZUChongzhi). The second authentication function can be represented as f2(); the hash algorithm can be represented as HASH(), which may include HMAC-SHA-256 (Hashbased Message Authentication Code-Secure Hash Algorithm-256), or other hash algorithms, which are not exhaustively listed in this embodiment. Furthermore, the above first calculation method is only illustrative; in actual processing, other algorithms that can be used to calculate or verify MAC addresses may also be included within the above first calculation method, which are not exhaustively listed here.

[0118] For example, the second device calculates the verification MAC based on the anonymous key and the root key using a first calculation method, which can be calculated using the following formula: MAC' = f2(Kr, AK), where MAC' represents the verification MAC, f2() represents the first calculation method specifically as the second authentication function, Kr represents the root key, and AK represents the anonymous key. The root key can be represented not only as Kr, but also as K, PSK (PreShared Key), PMK (Pairwise Master Key), etc. Correspondingly, Kr in the various formula examples provided in this embodiment (including below) can be replaced with K, PSK, PMK, etc., which are not exhaustively listed here.

[0119] For example, the second device can calculate the first random number based on the XOR operation of the anonymous key and the root key using the following formula: Where RAND represents the first random number, Kr represents the root key, and AK represents the anonymity key. This represents an XOR operation. The second device calculates the verification MAC based on the first random number and the root key using the first calculation method. The calculation can be performed using the following formula: MAC' = f2(Kr, RAND). The meaning of each parameter in this formula is the same as in the previous embodiment and will not be repeated.

[0120] Optionally, the authentication parameters include a first random number. Correspondingly, the second device's calculation of the verification MAC based on the authentication parameters and the root key may include one of the following: the second device calculates the verification MAC using a first calculation method based on the first random number and the root key; the second device XORs the first random number and the root key to calculate the anonymous key, and then uses the first calculation method to calculate the verification MAC based on the anonymous key and the root key.

[0121] For example, the second device calculates the verification MAC based on the first random number and the root key using the first calculation method, which can be calculated using the following formula: MAC'=f2(Kr,RAND), where MAC' represents the verification MAC, f2() represents the first calculation method specifically the second authentication function, Kr represents the root key, and RAND represents the first random number.

[0122] For example, the second device can calculate the anonymous key based on the first random number and the root key by XORing, using the following formula: Where RAND represents the first random number, Kr represents the root key, and AK represents the anonymity key. This represents an XOR operation. The second device calculates the verification MAC based on the anonymous key and the root key using the first calculation method. The calculation can be performed using the following formula: MAC' = f2(Kr, AK), where the meaning of each parameter in the formula is the same as in the previous embodiment and will not be repeated.

[0123] Optionally, the second message also carries service parameters, which include at least one of the following: a type parameter indicating the type of AIoT service, an identifier of a server with AIoT service functionality, and a type parameter indicating the type of AIoT authentication.

[0124] The type parameter used to indicate the AIoT service type can be an identifier, such as a first identifier used to indicate the AIoT service type. The specific value or content of the first identifier can be set according to the actual situation. For example, the first identifier can include the content description information "AIoT service"; or the first identifier can include a value, such as a value of 01 indicating the AIoT service type; or the first identifier can be other values ​​or other content, as long as it is uniquely used to indicate that the current service type is the AIoT service type, it is within the protection scope of this embodiment.

[0125] The type parameter used to indicate the AIoT authentication type can be another identifier, such as a second identifier used to indicate the AIoT authentication type. The specific value or content of the second identifier can be set according to the actual situation. For example, the second identifier can include the content description information "AIoT authentication"; or the second identifier can include a value, such as a value of 00 indicating the AIoT authentication type; or the first identifier can be other values ​​or other content, as long as it is uniquely used to indicate that the current authentication type is AIoT authentication type, it is within the protection scope of this embodiment.

[0126] A server with AIoT service capabilities can refer to a server that provides AIoT-related services. For example, it could be an AF (Application Function) network element, a core network element with AIoT service capabilities, or other servers; these are not exhaustively listed here. The aforementioned identifiers can include network identifiers and / or IDs; network identifiers can include at least one of the following: IP address (Internet Protocol Address), MAC (Media Access Control Address), etc.

[0127] The second message may carry the aforementioned authentication parameters, service parameters, and MAC. Alternatively, the second message may carry authentication parameters and MAC, and the authentication parameters may include at least one of the following: an anonymous key, a first random number, and service parameters; for example, the authentication parameters may include an anonymous key; or the authentication parameters may include a first random number; or the authentication parameters may include an anonymous key and service parameters; or the authentication parameters may include a first random number and service parameters.

[0128] The second device calculates the verification MAC based on the anonymous key and the root key using a first calculation method, including: the second device calculates the verification MAC based on the service parameters, the anonymous key, and the root key using the first calculation method; and / or, the second device calculates the verification MAC based on the first random number and the root key using a first calculation method, including: the second device calculates the verification MAC based on the service parameters, the first random number, and the root key using the first calculation method.

[0129] For example, taking the first calculation method as specifically the second authentication function, the second device uses the first calculation method to calculate the verification MAC based on the service parameters, the anonymous key, and the root key. The calculation can be performed using the following formula: MAC'=f2(Kr, AK, service parameters), where the meaning of each parameter is the same as in the previous embodiment and will not be repeated.

[0130] For example, taking the first calculation method as specifically the second authentication function, the second device uses the first calculation method to calculate the verification MAC based on the service parameters, the first random number and the root key. The following formula can be used to calculate it: MAC'=f2(Kr, RAND, service parameters), where the meaning of each parameter is the same as in the previous embodiment and will not be repeated.

[0131] It should be noted that the above example only uses the second authentication function as the first calculation method to illustrate the generation of the verification MAC. In actual processing, any one of the first calculation methods mentioned above can be used to calculate the verification MAC, but it will not be elaborated on one by one.

[0132] In some possible implementations, the method further includes one of the following: the first network device receives the MAC and the authentication parameters from the second network device; the first network device generates the authentication parameters, and the first network device calculates the MAC based on the root key and the authentication parameters.

[0133] The method by which the first network device generates the authentication parameters is not limited in this embodiment. It should be noted that the authentication parameters may include an anonymous key or a first random number. The first network device can pre-generate an anonymous key and a first random number, and then use either one as the authentication parameter. The method by which the first network device generates the first random number is not limited in this embodiment. The relationship between the anonymous key and the first random number can be that the anonymous key is obtained by XORing the first random number with the root key.

[0134] The first network device calculates the MAC based on the root key and the authentication parameters, including one of the following: the first network device calculates the MAC based on the anonymous key and the root key using a first calculation method; the first network device calculates the anonymous key by XORing the first random number and the root key, and then calculates the MAC based on the anonymous key and the root key using the first calculation method; the second device calculates the first random number by XORing the anonymous key and the root key, and then calculates the MAC based on the first random number and the root key using the first calculation method; the second device calculates the MAC based on the first random number and the root key using the first calculation method. The detailed description of the first calculation method is the same as in the previous embodiments and will not be repeated.

[0135] Optionally, the authentication parameters include an anonymous key. The first network device calculates the MAC based on the authentication parameters and the root key, which may include one of the following: the first network device calculates the MAC based on the anonymous key and the root key using a first calculation method; the first network device XORs the anonymous key and the root key to calculate the first random number, and then uses the first calculation method to calculate the MAC based on the first random number and the root key.

[0136] For example, the first network device calculates the MAC based on the anonymous key and the root key using a first calculation method, which can be calculated using the following formula: MAC = f2(Kr, AK), where MAC represents MAC, f2() represents the first calculation method specifically the second authentication function, Kr represents the root key, and AK represents the anonymous key.

[0137] For example, the first network device calculates the first random number based on the XOR operation of the anonymous key and the root key. The formula that can be used is the same as in the previous embodiments and will not be repeated. The first network device calculates the MAC based on the first random number and the root key using the first calculation method. The following formula can be used for calculation: MAC = f2(Kr, RAND). The meaning of each parameter in this formula is the same as in the previous embodiments and will not be repeated.

[0138] Optionally, the authentication parameters include a first random number. Accordingly, the first network device calculating the MAC based on the authentication parameters and the root key may include one of the following: the first network device calculating the MAC based on the first random number and the root key using a first calculation method; the first network device XORing the first random number and the root key to calculate the anonymous key, and then using the first calculation method to calculate the MAC based on the anonymous key and the root key.

[0139] The first network device calculates the MAC based on the first random number and the root key using the first calculation method, and the formula used is the same as in the previous embodiments. The formulas used by the first network device to calculate the anonymous key based on the first random number and the root key via XOR, and to calculate the verification MAC based on the anonymous key and the root key using the first calculation method, are also the same as in the previous embodiments, and therefore will not be repeated.

[0140] It should be noted that the above example only uses the first calculation method as the second authentication function as an example. In actual processing, the first calculation method is not limited to the second authentication function mentioned above. Any one of the hash algorithm, Advanced Encryption Standard AES, ACSON, SNOW 3G, and ZUC can be used as the first calculation method. Other calculation methods can also be used as the first calculation method. This embodiment does not exhaustively list them.

[0141] Optionally, the first network device calculates the MAC based on the anonymous key and the root key using the first calculation method, including: the first network device calculates the MAC based on service parameters, the anonymous key, and the root key using the first calculation method; and / or, the first network device calculates the MAC based on the first random number and the root key using the first calculation method, including: the first network device calculates the MAC based on service parameters, the first random number, and the root key using the first calculation method.

[0142] In this case, the first message also carries the service parameters. The description of the service parameters is the same as in the previous embodiments and will not be repeated. The first message may carry the aforementioned authentication parameters, service parameters, and MAC. Alternatively, the first message may carry authentication parameters and MAC, and the authentication parameters may include at least one of the following: an anonymous key, a first random number, and service parameters; for example, the authentication parameters may include an anonymous key; or the authentication parameters may include a first random number; or the authentication parameters may include an anonymous key and service parameters; or the authentication parameters may include a first random number and service parameters. This embodiment does not limit the method by which the first network device generates or obtains the service parameters.

[0143] For example, taking the first calculation method as specifically the second authentication function, the first network device calculates the MAC based on the service parameters, the anonymous key, and the root key using the first calculation method. The calculation can be performed using the following formula: MAC = f2(Kr, AK, service parameters), where the meaning of each parameter is the same as in the previous embodiment and will not be repeated.

[0144] For example, taking the first calculation method as specifically the second authentication function, the first network device calculates the MAC based on the service parameters, the first random number and the root key using the first calculation method. The calculation can be performed using the following formula: MAC = f2(Kr, RAND, service parameters), where the meaning of each parameter is the same as in the previous embodiment and will not be repeated.

[0145] Optionally, the second network device can be a core network device, that is, the second network device can be a second core network device. Since the second network device is a core network device, the second network device stores the root key corresponding to the aforementioned second device. This embodiment does not limit the method by which the second network device generates or obtains the root key corresponding to the second device.

[0146] The second network device may be at least one of the aforementioned core network side devices. For example, the second network device may include at least one of the following: UDM, ARPF. Furthermore, this embodiment does not limit the method by which the second network device obtains its MAC address.

[0147] The first network device receiving the MAC address and authentication parameters from the second network device may further include: the first network device receiving service parameters, the MAC address, and the authentication parameters from the second network device. In this case, the first message also carries the service parameters. The description of the service parameters is the same as in the previous embodiments and will not be repeated. The way the first message can carry the aforementioned service parameters is also the same as in the previous embodiments and will not be elaborated further.

[0148] In this example, the method by which the second network device calculates the MAC address is the same as that of the first network device, so it will not be repeated here.

[0149] It should also be noted that the algorithm used by the first or second network device to calculate the MAC should be the same as the algorithm used by the second device to calculate the verification MAC. For example, taking the first and second network devices as examples, the first network device also uses a hash algorithm to calculate the MAC based on the anonymous key and the root key, and the second device uses a hash algorithm to calculate the verification MAC based on the anonymous key and the root key. Other cases are the same as described above and will not be elaborated further.

[0150] In some possible implementations, the processing of the second device may further include: if the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

[0151] The second device can also perform the following processing: the second device determines whether the verification MAC is the same as the MAC. Additionally, it may include: if the verification MAC is different from the MAC, the second device fails to authenticate the core network side device. Furthermore, if the second device fails to authenticate the core network side device, it may not perform subsequent processing, or the second device may send a message indicating authentication failure of the core network side device to the first device (e.g., through the first device to the first network device).

[0152] The aforementioned second device completing the authentication of the core network side device can also be referred to as the second device successfully authenticating the identity of the core network side device, or the second device successfully authenticating the identity of the core network side device, or the second device successfully authenticating the core network side device.

[0153] In some possible implementations, the third message may carry at least one of the following: a first RES (Response), which is used by the core network side device to authenticate the second device; and a second RES, which is used by the first device to authenticate the second device.

[0154] In some possible examples, the third message mentioned above carries the first RES.

[0155] In this scenario, the processing of the first device may include: the first device sending a fourth message to the first network device, the fourth message carrying the first RES. Further, the first device may also send a response message to the second device. For example, if the first device receives a notification from the first network device that the second device has passed authentication, the first device sends a response message to the second device in response to the third message, indicating that the core network device has passed authentication of the second device. Correspondingly, the processing of the first network device after receiving the fourth message from the first device may include: if the first RES is the same as the first verification RES, the first network device determines that the second device has passed authentication. For example, after determining that the second device has passed authentication, the first network device may also send a notification that the second device has passed authentication to the first device. For example, it may also include: if the first RES and the first verification RES are different, the first network device determines that the second device has failed authentication, and thus can end the processing, or it may send a notification of authentication failure to the second device; subsequent possible processing is not limited here. Further, it may also include: if it determines that the second device has passed authentication, the first network device sends a notification that the second device has passed authentication to the first device.

[0156] The aforementioned second device calculates the first RES in one of the following ways: the second device calculates the first RES based on the first random number and the root key using the first calculation method; or the second device calculates the first RES based on the anonymous key and the root key using the first calculation method.

[0157] Optionally, the second device calculating the first RES based on the first random number and the root key using the first calculation method can mean that, when the second device calculates the verification MAC based on the anonymous key and the root key using the first calculation method, the second device calculates the first RES based on the first random number and the root key using the first calculation method. That is, the parameters used to calculate the first RES (or the first verification RES) are at least partially different from the parameters used to calculate the verification MAC (or MAC) in the aforementioned embodiments. Furthermore, the specific algorithm used to calculate the first RES can also be different from the algorithm used to calculate the MAC; for example, the first RES may use a hash algorithm, while the MAC may use a second authentication function.

[0158] For example, the second device calculates the verification MAC based on the anonymous key and the root key using the first calculation method, which can be calculated using the following formula: MAC' = f2(Kr, AK). The second device calculates the first RES based on the first random number and the root key using the first calculation method, which can be calculated using the following formula: RES = f2(Kr, RAND). Where RES represents the first RES, Kr represents the root key, RAND represents the first random number, and AK represents the anonymous key. The meanings of other contents in the above formulas are the same as in the aforementioned embodiments and will not be repeated.

[0159] Furthermore, service parameters can be added to calculate the first RES. The second device calculating the first RES using the first calculation method based on the first random number and the root key can include: the second device calculating the first RES using the first calculation method based on the service parameters, the first random number, and the root key. For example, the second device calculating the first RES using the first calculation method based on the service parameters, the first random number, and the root key can use the following formula: RES = f2(Kr, RAND, service parameters), where the meaning of each item in the formula is the same as in the aforementioned embodiments and will not be repeated.

[0160] It should be understood that when the second device calculates the first RES based on the service parameters, the first random number, and the root key using the first calculation method, the second device can also calculate the verification MAC using the service parameters, the anonymous key, and the root key, or the second device can also calculate the verification MAC using only the anonymous key and the root key. All of these processing methods are within the scope of protection of this embodiment.

[0161] Optionally, the second device calculating the first RES based on the anonymous key and the root key using the first calculation method can refer to the following: when the second device calculates the verification MAC based on the first random number and the root key using the first calculation method, the second device calculates the first RES based on the anonymous key and the root key using the first calculation method.

[0162] For example, the second device calculates the verification MAC based on the first random number and the root key using the first calculation method, which can be calculated using the following formula: MAC' = f2(Kr, RAND). The second device calculates the first RES based on the anonymous key and the root key using the first calculation method, which can be calculated using the following formula: RES = f2(Kr, AK), where RES represents the first RES. The meanings of other contents in the formula are the same as in the aforementioned embodiments and will not be repeated.

[0163] Furthermore, service parameters can be added to calculate the first RES. The second device calculating the first RES based on the anonymous key and the root key using the first calculation method may include: the second device calculating the first RES based on the service parameters, the anonymous key, and the root key using the first calculation method. For example, it can be expressed by the following formula: RES = f2(Kr, AK, service parameters), where the meaning of each item in the formula is the same as in the aforementioned embodiments and will not be repeated.

[0164] It should be understood that when the second device uses the first calculation method based on the service parameters, the anonymous key, and the first root key RES, the second device can use the service parameters, the first random number, and the root key to calculate the MAC verification, or the second device can use only the first random number and the root key to calculate the MAC verification. All of these processing methods are within the scope of protection of this embodiment.

[0165] On the first network device side, obtaining the first verification RES may include one of the following: the first network device receives the first verification RES from the second network device; the first network device calculates the first verification RES based on the root key and the authentication parameters using the first calculation method. Wherein, the first network device calculating the first verification RES based on the root key and the authentication parameters using the first calculation method includes one of the following: the first network device calculates the first verification RES based on the first random number and the root key using the first calculation method; the first network device calculates the first verification RES based on the anonymous key and the root key using the first calculation method.

[0166] The first verification RES can be the first expected response (XRES). In the following text, unless otherwise specified, the first verification RES and the first XRES have the same meaning and will not be explained again.

[0167] The first network device calculating the first verification RES based on the first random number and the root key using the first calculation method can refer to the following: when the first network device calculates the MAC based on the anonymous key and the root key using the first calculation method, the first network device calculates the first verification RES based on the first random number and the root key using the first calculation method.

[0168] For example, the first network device calculates the MAC based on the anonymous key and the root key using the first calculation method, which can be calculated using the following formula: MAC = f2(Kr, AK). The first network device calculates the first verification RES based on the first random number and the root key using the first calculation method, which can be calculated using the following formula: XRES = f2(Kr, RAND), where XRES represents the first verification RES. The meanings of other contents in the formula are the same as in the aforementioned embodiments and will not be repeated.

[0169] Furthermore, service parameters can be added to calculate the first verification RES. The first network device calculating the first verification RES using the first calculation method based on the first random number and the root key can include: the first network device calculating the first verification RES using the first calculation method based on the service parameters, the first random number, and the root key. For example, the second device calculating the first verification RES using the first calculation method based on the service parameters, the first random number, and the root key can use the following formula: XRES = f2(Kr, RAND, service parameters), where the meaning of each item in the formula is the same as in the aforementioned embodiments and will not be repeated.

[0170] It should be understood that when the first network device (or second network device) calculates the first verification RES based on the service parameters, the first random number, and the root key using the first calculation method, the first network device (or second network device) may also calculate the MAC using the service parameters, the anonymous key, and the root key, or the first network device may only use the anonymous key and the root key to calculate the MAC. In the case where the first network device (or second network device) calculates the first verification RES based on the first random number and the root key using the first calculation method, the first network device (or second network device) may also calculate the MAC using the service parameters, the anonymous key, and the root key, or the first network device (or second network device) may only use the anonymous key and the root key to calculate the MAC; all of the above processing methods are within the protection scope of this embodiment.

[0171] The first network device calculates the first verification RES based on the anonymous key and the root key using the first calculation method, which can refer to: when the first network device calculates the MAC based on the first random number and the root key using the first calculation method, the first network device calculates the first verification RES based on the anonymous key and the root key using the first calculation method.

[0172] For example, the first network device calculates the MAC based on the first random number and the root key using the first calculation method, which can be calculated using the following formula: MAC = f2(Kr, RAND). The first network device calculates the first verification RES based on the anonymous key and the root key using the first calculation method, which can be calculated using the following formula: XRES = f2(Kr, AK), where XRES represents the first verification RES. The meanings of other contents in the formula are the same as in the aforementioned embodiments and will not be repeated.

[0173] Furthermore, service parameters can be added to calculate the first authentication RES. The first network device calculating the first authentication RES based on the anonymous key and the root key using the first calculation method may include: the first network device calculating the first authentication RES based on the service parameters, the anonymous key, and the root key using the first calculation method. For example, it can be expressed by the following formula: XRES = f2(Kr, AK, service parameters), where the meaning of each item in the formula is the same as in the aforementioned embodiments and will not be repeated.

[0174] It should be understood that when the first network device (or second network device) uses the first calculation method based on the service parameters, the anonymous key, and the root key first verification RES, the first network device (or second network device) can calculate the MAC using the service parameters, the first random number, and the root key, or the first network device (or second network device) can calculate the MAC using only the first random number and the root key. All of these processing methods are within the protection scope of this embodiment.

[0175] The aforementioned first network device receiving the first authentication RES from the second network device can refer to the first network device receiving the first authentication RES, MAC address, and authentication parameters from the second network device. Simultaneously, the first network device can also receive service parameters from the second network device; the description of these service parameters is the same as in the previous embodiments and will not be repeated here.

[0176] For example, the first network device may simultaneously receive the first authentication RES, MAC, and authentication parameters from the second network device, but only carries the MAC and authentication parameters in a first message and sends it to the first device; correspondingly, after receiving the first message, the first device carries the MAC and authentication parameters from the first message in a second message and sends it to the second device. As another example, the first network device may simultaneously receive the first authentication RES, MAC, authentication parameters, and service parameters from the second network device, but only carries the MAC, authentication parameters, and service parameters in a first message and sends it to the first device; correspondingly, after receiving the first message, the first device carries the MAC, authentication parameters, and service parameters from the first message in a second message and sends it to the second device. It should also be noted that if the second network device obtains the first authentication RES, the specific method by which the second network device calculates the first authentication RES should be the same as the method by which the first network device calculates the first authentication RES in the above embodiments, and therefore will not be repeated. In addition, the aforementioned first message may also carry the identifier of the second device.

[0177] The parameters and specific calculation functions used by the second device to calculate the first RES and by the first network device (or the second network device) to calculate the first verification RES should be the same. For example, if the second device uses the second authentication function to calculate the first RES based on the service parameters, the anonymous key, and the root key, then the first network device (or the second network device) should also use the second authentication function to calculate the first verification RES based on the service parameters, the anonymous key, and the root key. Or, for example, if the second device uses a hash algorithm to calculate the first RES based on the first random number and the root key, then the first network device (or the second network device) should also use a hash algorithm to calculate the first verification RES based on the first random number and the root key.

[0178] In some possible examples, the third message mentioned above carries the first RES, and the first message also carries the first verification RES.

[0179] In this scenario, the first device can authenticate the second device on behalf of the first network device. The processing by the first device after receiving the third message from the second device may include: if the first RES is the same as the first verification RES, the first device determines that the authentication of the second device is successful. In this example, the methods by which the first network device obtains the first verification RES and the second device obtains the first RES are the same as in the previous examples, and therefore will not be repeated. Furthermore, the first device may also send a response message to the second device. For example, if the first device determines that the authentication of the second device is successful, the first device sends a response message to the second device in response to the third message. This response message is used to instruct the core network side device to authenticate the second device successfully.

[0180] In some possible examples, the third message mentioned above carries a second RES.

[0181] In this scenario, the processing by the first device after receiving the third message from the second device may include: if the first device determines that the second device has been successfully authenticated if the second verification RES is the same as the second RES. Further, it may also include: the first device sending a response message to the second device, the response message indicating that the second device has been successfully authenticated.

[0182] Accordingly, the processing of the second device may include: the second device receiving a response message from the first device, the response message being in response to the third message, the response message being used to indicate that the second device has been authenticated.

[0183] For example, in indirect mode, the second device connects to the core network through a terminal device and a corresponding first access network device. In this case, the first device is the terminal device. Alternatively, if the first device is a terminal device, it can be a proxy UE or a relay UE, etc. In this example, the terminal device (e.g., a UE) verifies the second RES, and if the second verification RES is the same as the second RES, it determines that the second device has passed authentication.

[0184] For example, in Direct mode, the second device connects to the core network through a corresponding access network device. In this case, the first device is an access network device (e.g., the access network device corresponding to the second device), or the first device can be a first core network device, such as an AMF, SEAF, or a core network element dedicated to AIoT (or IoT), etc. In this example, the access network device (e.g., gNB) or the first core network device (e.g., AMF, SEAF, or a core network element dedicated to AIoT) verifies the second RES, and if the second verification RES is the same as the second RES, the second device is determined to be authenticated successfully.

[0185] Additionally, it may include: if the first device determines that the authentication of the second device has failed when the second verification RES is different from the second RES, the processing may be terminated, or the first device may send an authentication failure notification to the second device. Here, the possible subsequent processing is not limited.

[0186] The second device calculates the second RES in one of the following ways: the second device calculates the second RES based on the anonymous key and the first key using a first calculation method, wherein the first key is associated with the first device; the second device calculates the second RES based on the first random number and the first key using a first calculation method; or the second device calculates the second RES based on the first RES and the first key using a first calculation method.

[0187] The first key can be at least one of the following: a first intermediate key calculated based on the identifier of the first device and a second random number, or a physical layer key, wherein the physical layer key is a key shared by the second device and the first device.

[0188] The physical layer key can be a shared key generated between the second device and the first device through the channel source characteristics of the air interface. This embodiment does not limit the specific generation method of the physical layer key, as long as it is the same key shared by the second device and the first device, it is within the protection scope of this embodiment.

[0189] The first intermediate key can be calculated by: using a second calculation method to calculate the first intermediate key based on the identifier of the first device and a second random number; or using the second calculation method to calculate the first intermediate key based on the identifier of the first device, the second random number and the anonymous key.

[0190] The second calculation method may at least include a key derivation function (KEF). Furthermore, the second calculation method may also include one of the following: XOR calculation, or direct connection calculation. It should be understood that this is merely an illustrative example; in actual processing, the second calculation method may be other calculation methods, which are not exhaustively listed in this embodiment.

[0191] The first device mentioned above can be the aforementioned terminal device, and correspondingly, the identifier of the first device can be the UE ID; the first device mentioned above can be the aforementioned first access network device, and correspondingly, the identifier of the first device can be represented as gNB ID (or eNBID or other possible types of access network device ID); the first device mentioned above can be the first core network device, and correspondingly, the identifier of the first device can be represented as the identifier of the first core network element, or the identifier of the intermediate network element, or the identifier of the core network element, etc.

[0192] Taking the first device as the first core network device as an example, the above-mentioned calculation method for the first intermediate key based on the identifier of the first device and the second random number can be expressed as: Km = KDF(intermediate network element identifier, second random number). Alternatively, the calculation method for the first intermediate key based on the identifier of the first device, the second random number, and the anonymous key can be expressed as: Km = KDF(AK, intermediate network element identifier, second random number), where Km represents the first intermediate key and AK represents the anonymous key. If the first device is a terminal device, the above-mentioned calculation formula for the first intermediate key can be adaptively replaced with Km = KDF(UE ID, second random number) or Km = KDF(AK, UE ID, second random number). The above-mentioned first device can also be adaptively replaced if it is a first access network device; these alternatives are not exhaustively listed here.

[0193] In addition, the aforementioned second random number can be sent from the first device to the second device; this embodiment does not limit the generation method and the timing of sending the second random number. For example, it can be carried in the aforementioned second message. As long as it is before the calculation of the second RES, it is within the protection scope of this embodiment, and we will not exhaustively list them here.

[0194] For example, taking the first calculation method as the second authentication function, the second device calculates the second RES based on the anonymous key and the physical layer key using the first calculation method, which can be expressed as: RES' = f2(physical layer key, AK), where RES' represents the second RES. The meanings of other contents in the formula are the same as in the aforementioned embodiments and will not be repeated. Alternatively, the second device calculates the second RES based on the anonymous key and the first intermediate key using the first calculation method, which can be expressed as: RES' = f2(Km, AK). The meanings of the contents in the formula are the same as in the aforementioned embodiments and will not be repeated.

[0195] For example, taking the first calculation method as the second authentication function, the second device calculates the second RES based on the first random number and the physical layer key using the first calculation method, which can be expressed as: RES' = f2(physical layer key, RAND), where RES' represents the second RES. The meanings of other contents in the formula are the same as in the aforementioned embodiments and will not be repeated. Alternatively, the second device calculates the second RES based on the anonymous key and the first intermediate key using the first calculation method, which can be expressed as: RES' = f2(Km, RAND). The meanings of the contents in the formula are the same as in the aforementioned embodiments and will not be repeated.

[0196] For example, taking the first calculation method as the second authentication function, the second device calculates the second RES based on the first RES and the physical layer key using the first calculation method, which can be expressed as: RES' = f2(physical layer key, RES), where RES' represents the second RES and RES represents the first RES. The meanings of other contents in the formula are the same as in the aforementioned embodiments and will not be repeated. Alternatively, the second device calculates the second RES based on the first RES and the first intermediate key using the first calculation method, which can be expressed as: RES' = f2(Km, RES). The meanings of the contents in the formula are the same as in the aforementioned embodiments and will not be repeated.

[0197] The first device calculates the second verification RES in one of the following ways: the first device calculates the second verification RES using a first calculation method on the anonymous key and the first key; the first device calculates the second verification RES using a first calculation method on the first random number and the first key; or the first device calculates the second verification RES using a first calculation method on the first verification RES and the first key. For example, the second verification RES can also be a second XRES. Unless otherwise specified below, the second verification RES and the second XRES have the same meaning and will not be explained again. The description of the first key is the same as in the foregoing embodiments and will not be repeated.

[0198] Optionally, the authentication parameters received by the first device may include an anonymous key or a first random number; if the authentication parameters include an anonymous key, the first device may perform a first calculation method to calculate the anonymous key and the first key to obtain the second verification RES; if the authentication parameters include a first random number, the first device may perform a first calculation method to calculate the first random number and the first key to obtain the second verification RES.

[0199] Optionally, the aforementioned first verification RES can be sent from the first network device to the first device. For example, the aforementioned first message can also carry the first verification RES. If the first message carries the first verification RES, the first device can choose to use a first calculation method to calculate the first verification RES and the first key to obtain the second verification RES. Alternatively, if the first message carries the first verification RES, the first device can also use the anonymous key or the first random number included in the authentication parameters to calculate the second verification RES. All of these are within the scope of protection of this embodiment, and not all possible cases are exhaustively listed here.

[0200] Optionally, the first device can also obtain the root key. The first device can XOR the root key with the anonymous key included in the authentication parameters to obtain a first random number; or, the first device can XOR the root key with the first random number included in the authentication parameters to obtain an anonymous key; or, the first device can use the root key and authentication parameters, in the same way as the second device, to generate the first verification RES. In this case, the first device can generate the second verification RES using any of the above methods.

[0201] For example, taking the first calculation method as the second authentication function, the first device uses the first calculation method to calculate the anonymous key and the first key to obtain the second verification RES. If the first key is a physical layer key, it can be expressed as: XRES' = f2(physical layer key, AK), where XRES' represents the second verification RES. The meaning of other contents in the formula is the same as in the previous embodiment and will not be repeated. If the first key is a first intermediate key, it can be expressed as XRES' = f2(Km, AK).

[0202] For example, taking the first calculation method as the second authentication function, the first device uses the first calculation method to calculate the first random number and the first key to obtain the second verification RES. If the first key is a physical layer key, it can be expressed as: XRES' = f2(physical layer key, RAND), where XRES' represents the second verification RES. The meaning of other contents in the formula is the same as in the previous embodiment and will not be repeated. If the first key is a first intermediate key, it can be expressed as XRES' = f2(Km, RAND).

[0203] For example, taking the first calculation method as the second authentication function, the first device uses the first calculation method to calculate the first verification RES and the first key to obtain the second verification RES. If the first key is a physical layer key, it can be expressed as: XRES' = f2(physical layer key, XRES), where XRES' represents the second verification RES and XRES represents the first verification RES. The meanings of other contents in the formula are the same as in the aforementioned embodiments and will not be repeated. If the first key is a first intermediate key, it can be expressed as XRES' = f2(Km, XRES).

[0204] The parameters (or parameter types) and specific calculation functions used by the second device to calculate the second RES and the first device to calculate the second verification RES should be the same. For example, if the second device uses the second authentication function to calculate the second RES based on the anonymous key and the physical layer key, then the first device should also use the second authentication function to calculate the second verification RES based on the anonymous key and the physical layer key. Or, for example, if the second device uses a hash algorithm to calculate the second RES based on the first RES and the physical layer key, then the first device should also use a hash algorithm to calculate the second verification RES based on the first verification RES and the physical layer key.

[0205] In some other possible examples, the third message mentioned above carries the first RES and the second RES.

[0206] In this scenario, the processing by the first device may include: the first device sending a fourth message to the first network device, the fourth message carrying the first RES; and the first device determining that the second device's authentication is successful if the second verification RES is the same as the second RES. Alternatively, it may include: the first device determining that the second device's authentication is unsuccessful (or fails) if the second verification RES is different from the second RES.

[0207] The processing by the first network device may include: if the first RES is the same as the first verification RES, the first network device determines that the authentication of the second device is successful. Further, it may also include: the first network device sending a notification to the first device that the authentication of the second device is successful (or passed). Additionally, the processing by the first network device may also include: if the first RES and the first verification RES are different, the first network device determines that the authentication of the second device is unsuccessful (or fails). If the first network device determines that the authentication of the second device is unsuccessful (or fails), the first network device may terminate the processing, or the first network device may send a notification to the first device that the authentication of the second device failed (or was unsuccessful); subsequent possible processing is not limited here.

[0208] The processing by the first device may further include one of the following: If the first device determines that the second device has passed authentication and receives a notification from the first network device that the second device has passed (or succeeded) authentication, the first device sends a response message to the second device, indicating that the second device has passed authentication; if the first device determines that the second device has failed authentication, and / or receives a notification from the first network device that the second device has failed authentication, the first device sends a response message to the second device, indicating that the second device has failed authentication. Further, the response message may carry information such as the first device's failure to authenticate the second device and / or the core network side device's failure to authenticate the second device, which is not limited here.

[0209] In this example, the methods by which the second device calculates the first RES and the second RES, the first device obtains the second verification RES, and the first network device obtains the first verification RES are all the same as in the previous embodiments, and will not be repeated.

[0210] Regarding the foregoing embodiments, it should be further noted that when the second device, the first device, and the first network device execute the above authentication method, the second device may only perform authentication on the core network side based on the verification MAC and the MAC. Alternatively, in addition to the second device performing authentication on the core network side based on the verification MAC and the MAC, the first network device may further perform authentication on the second device based on the first RES and the first verification RES, and / or the first device may perform authentication on the second device based on the second RES and the second verification RES. All of the above possible solutions are within the scope of protection of this embodiment.

[0211] Furthermore, since the AK needs to be sent, algorithms that can be reverse-derived, such as XOR, cannot be used to generate the MAC and XRES. Because Kr is a unique, non-repeating key shared only by each second device and the core network side device, an attacker intercepting the AK cannot obtain RAND or Kr. Therefore, generating and sending the AK is secure and features low power consumption. Sending the MAC is also secure, and since the MAC is generated based on Kr, and only the AUSF possesses Kr, verifying the MAC can verify the identity of the core network side device. Furthermore, since the RES is generated based on Kr, and only the second device and the core network side device possess Kr, the core network side device can verify the identity of the second device by verifying the RES. Moreover, since RES' (i.e., the second RES) and XRES' (i.e., the second verification RES) are generated based on the physical layer key, and only the second device and the first device possess the shared physical layer key, the first device can verify the identity of the second device by verifying RES'.

[0212] In some possible implementations, the second device and the first device perform key negotiation.

[0213] The processing of the second device further includes: the second device calculating an integrity protection key and / or an encryption key, wherein the integrity protection key is related to a key generation parameter and a third random number, the encryption key is related to the key generation parameter and a fourth random number, the key generation parameter includes an anonymous key and / or a first random number, the integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt the sent data and / or decrypt the received data.

[0214] The processing of the first device may further include: the first device calculating an integrity protection key and / or an encryption key, wherein the integrity protection key is related to a key generation parameter and a third random number, the encryption key is related to the key generation parameter and a fourth random number, the key generation parameter includes an anonymous key and / or a first random number, the integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt the sent data and / or decrypt the received data.

[0215] For example, the key generation parameter can be directly extracted from the authentication parameters. For instance, if the authentication parameters include an anonymous key, then the key generation parameter is the anonymous key contained in the authentication parameters; or, if the authentication parameters include a first random number, then the key generation parameter is the first random number contained in the authentication parameters.

[0216] For example, the key generation parameter described above differs from the authentication parameter described above. This key generation parameter can be obtained when the second device performs any one of the aforementioned processes—calculating the verification MAC, calculating the first RES, and calculating the second RES—based on the authentication parameter. For instance, the authentication parameter includes an anonymous key, and a first random number is obtained when the second device performs any one of the aforementioned processes—calculating the verification MAC, calculating the first RES, and calculating the second RES—and the second device uses this first random number as the key generation parameter; or, for another example, the authentication parameter includes a first random number, and an anonymous key is obtained when the second device performs any one of the aforementioned processes—calculating the verification MAC, calculating the first RES, and calculating the second RES—and the second device uses this anonymous key as the key generation parameter.

[0217] In some possible examples, the second device and the first device negotiate an integrity protection key.

[0218] The aforementioned integrity protection key is used for integrity protection of the second device and network entities (such as the first device). The network entity may include, but is not limited to, at least one of the following: UE, other network devices; other network devices may include: AP, small cell, gNB, CPE, AMF, UPF, MEC, etc. Since the second device and the first device need to generate their own integrity protection keys for integrity protection processing, the parameters and calculation methods used by the second device and the first device to generate their respective integrity protection keys should be the same. Therefore, in this example, the second device and the first device are referred to as electronic devices to describe the generation method of the integrity protection key. It should be noted that the electronic device in this example can be either the second device or the first device, without further explanation.

[0219] The calculation of the integrity protection key includes one of the following: calculating the integrity protection key based on the anonymous key and a third random number using a second calculation method; calculating the integrity protection key based on the first random number and the third random number using the second calculation method; calculating the integrity protection key based on the anonymous key, the first key, and the third random number using the second calculation method; calculating the integrity protection key based on the first random number, the first key, and the third random number using the second calculation method; calculating the integrity protection key based on a second intermediate key and a third random number using the second calculation method, wherein the second intermediate key is related to the key generation parameters; calculating the integrity protection key based on a third intermediate key and a third random number using the second calculation method, wherein the third intermediate key is related to the root key and the key generation parameters.

[0220] The method further includes at least one of the following: calculating the second intermediate key based on the anonymous key using a third calculation method; calculating the second intermediate key based on the first random number using the third calculation method; calculating the second intermediate key based on the anonymous key and the first key using a third calculation method; calculating the second intermediate key based on the first random number and the first key using the third calculation method; calculating the third intermediate key based on the root key and the first random number using the third calculation method; calculating a fourth intermediate key based on the root key and the first random number using the third calculation method, and calculating the third intermediate key based on the fourth intermediate key using the second calculation method; calculating the third intermediate key based on the root key, the first key, and the first random number using the third calculation method; calculating the fourth intermediate key based on the root key and the first random number using the third calculation method, and calculating the third intermediate key based on the fourth intermediate key and the first key using the second calculation method.

[0221] The third calculation method includes one of the following: third key generation function, XOR calculation, direct connection calculation, and KDF.

[0222] Optionally, the integrity protection key is calculated using the second calculation method based on the anonymous key and the third random number. For example, it can be expressed as: Where KI represents the integrity protection key, NONCE1 represents the third random number, and AK represents the anonymity key; or it can be represented as: Where KDF() is the key derivation function, the meanings of other contents in this formula are the same as in the previous embodiments, and will not be repeated; or it can be expressed as: In this formula, "||" represents direct calculation. The meanings of the other contents are the same as those in the previous embodiments and will not be repeated.

[0223] Optionally, the integrity protection key is calculated using a second calculation method based on the anonymous key, the first key, and the third random number.

[0224] For example, if the first key mentioned above can specifically be a physical layer key, then the above processing can be expressed as: Where KI represents the integrity protection key, NONCE1 represents the third random number, and AK represents the anonymity key. The meanings of the other contents in this formula are the same as in the previous embodiment and will not be repeated. Alternatively, it can be expressed as: Where KDF() is the key derivation function, the meanings of the other contents in this formula are the same as in the previous embodiment, and will not be repeated here. Or it can be expressed as: In this formula, "||" represents direct calculation. The meanings of the other contents are the same as those in the previous embodiments and will not be repeated.

[0225] For example, the aforementioned first key can specifically be a first intermediate key. The method for generating this first intermediate key has been detailed in the preceding embodiments and will not be repeated here. Accordingly, the above processing can be expressed as: Where KI represents the integrity protection key, NONCE1 represents the third random number, AK represents the anonymity key, and Km is the first intermediate key. Alternatively, it can be represented as: Where KDF() is the key derivation function, the meanings of the other contents in this formula are the same as in the previous embodiment, and will not be repeated here. Or it can be expressed as: In this formula, "||" represents direct calculation. The meanings of the other contents are the same as those in the previous embodiments and will not be repeated.

[0226] Optionally, the second device calculates the integrity protection key based on the first random number and the third random number using a second calculation method. For example, Other calculation formulas can be replaced in a similar way, which will not be elaborated here.

[0227] Optionally, the integrity protection key is calculated using the second calculation method based on the first random number, the first key, and the third random number.

[0228] Taking the first key as the physical layer key as an example, AK (anonymous key) in the above KI calculation formula can be replaced with the first random number RAND, for example, Other calculation formulas can be replaced in a similar way, which will not be elaborated here.

[0229] Taking the first key as the first intermediate key as an example, AK (anonymous key) in the above KI calculation formula can be replaced with the first random number RAND, for example, Other calculation formulas can be replaced in a similar way, which will not be elaborated here.

[0230] Optionally, the second device calculates the integrity protection key based on the second intermediate key and the third random number using the second calculation method. Here, the second intermediate key is generated in one of the following ways: calculating the second intermediate key based on the anonymous key using the third calculation method; calculating the second intermediate key based on the first random number using the third calculation method; calculating the second intermediate key based on the anonymous key and the first key using the third calculation method; or calculating the second intermediate key based on the first random number and the first key using the third calculation method.

[0231] It should be understood that the aforementioned second intermediate key may also be referred to as an authentication key in some possible examples.

[0232] In one possible example, the second intermediate key is calculated based on the anonymous key using a third calculation method, which can be achieved using the following formula: Ka represents the second intermediate key (or authentication key). In some other possible examples, the second intermediate key is calculated based on the first random number using a third calculation method, which can be represented as: It should be understood that the above is only an illustrative example. In actual processing, a third calculation method may also be used to calculate the second intermediate key based on the anonymous key and the first random number, such as Ka=AK||RAND. This is not exhaustive.

[0233] In one possible example, the first key is a physical layer key. The second intermediate key is calculated based on the physical layer key and the anonymous key using a third calculation method, which can be achieved using the following formula: In this formula, Ka represents the second intermediate key (or authentication key), f3() represents the third key generation function, and AK represents the anonymity key. The formula for calculating Ka can also be modified by replacing f3() with an XOR operation, for example, expressed as: Alternatively, f3() or the XOR calculation can be replaced with a direct calculation "||", for example, the above formula can be expressed as Alternatively, a third calculation method can be used to calculate the second intermediate key based on the physical layer key and the first random number. In this example, the anonymous key (AK) in the calculation formula of the above example can be replaced with the first random number (RAND), for example... Other possible calculation methods are the same as those in the previous examples and will not be elaborated on one by one. Since the physical layer key is a shared key between the second device and the first device and has Shannon information theory security, the second intermediate key (or authentication key) is secure.

[0234] In one possible example, the first key is a first intermediate key. The second intermediate key is calculated based on the first intermediate key and the anonymous key using a third calculation method, which can be achieved using the following formula: The second intermediate key is calculated using a third calculation method based on the first intermediate key and the first random number. In this example, the anonymous key (AK) in the calculation formula of the previous example can be replaced with the first random number (RAND), for example... Other possible calculation methods are the same as those in the previous examples, and will not be elaborated on one by one.

[0235] In the examples of calculating the second intermediate key described above, a fifth random number can also be added. For example, using a third calculation method to calculate the second intermediate key based on the physical layer key, the fifth random number, and the anonymous key, the above process can be represented as: Where NONCE3 represents the fifth random number; this fifth random number may be configured or sent by the first network device for the second device and / or the first device, and this embodiment does not limit it. For example, the second intermediate key can be calculated using the third calculation method based on the anonymous key and the fifth random number, using the following formula: The processing methods after adding a fifth random number in the above examples will not be exhaustively listed here.

[0236] The integrity protection key is calculated using the second calculation method based on the second intermediate key and the third random number, and can be expressed by the following formula: Where KI represents the integrity protection key, Ka represents the second intermediate key, and NONCE1 represents the third random number. For example, the above formula for calculating KI can also replace the XOR calculation with a direct connection calculation "||", such as the formula above can be expressed as: For example, the above formula for calculating KI can also be expressed using KDF; for instance, the above formula can be represented as follows: .

[0237] Optionally, the second device uses a second calculation method to calculate the integrity protection key based on the third intermediate key and the third random number.

[0238] In this case, the calculation method of the third intermediate key may include one of the following: calculating the third intermediate key based on the root key and the first random number using the third calculation method; calculating the third intermediate key based on the root key and the anonymous key using the third calculation method; calculating the third intermediate key based on the root key, the first key, and the first random number using the third calculation method; calculating a fourth intermediate key based on the root key and the first random number using the third calculation method, and calculating the third intermediate key based on the fourth intermediate key using the second calculation method; calculating a fourth intermediate key based on the root key and the first random number using the third calculation method, and calculating the third intermediate key based on the fourth intermediate key and the first key using the second calculation method.

[0239] The difference between this example and the previous one in the process of calculating the third intermediate key is that a root key is added to calculate the third intermediate key in this example.

[0240] In one possible example, the first key is a physical layer key. Accordingly, the third intermediate key is calculated based on the physical layer key, the root key, and the first random number using a third calculation method. This can be done using the following formula: Where Ka' represents the third intermediate key, the meanings of other contents in the above formula are the same as in the previous embodiment and will not be repeated. For example, the above formula for calculating the third intermediate key can also replace f3() with XOR, for example, expressed as... Alternatively, f3() or the XOR calculation can be replaced with a direct calculation "||", for example, the above formula can be expressed as .

[0241] Alternatively, if the first key is the first intermediate key, then the third intermediate key is calculated based on the first intermediate key, the root key, and the first random number using the third calculation method. This can be done using the following formula: The meanings of the contents in the above formula are the same as in the previous embodiments, and will not be repeated. For example, the above formula for calculating the third intermediate key can also replace f3() with XOR, or f3() or XOR calculation can be replaced with direct connection calculation "||", and so on. It should be understood that Ka' is used to represent the third intermediate key in this example to distinguish it from Ka representing the second intermediate key in the previous embodiments. In some other possible examples, Ka' in the above formula can also be directly represented as Ka, and these will not be exhaustively listed here.

[0242] Alternatively, the third intermediate key can be calculated based on the root key and the first random number using a third calculation method, which can be achieved using the following formula: The formula for calculating the third intermediate key mentioned above can also be replaced with other methods such as XOR or direct connection calculation, which will not be exhaustively listed here.

[0243] Alternatively, the third intermediate key can be calculated based on the root key and the anonymous key using a third calculation method, which can be achieved using the following formula: The meanings of the contents in the above formula are the same as in the previous embodiments, and will not be repeated. For example, the above formula for calculating the third intermediate key can also replace f3() with XOR, or f3() or XOR calculation can be replaced with direct connection calculation "||", and so on. It should be understood that Ka' is used to represent the third intermediate key in this example to distinguish it from Ka representing the second intermediate key in the previous embodiments. In some other possible examples, Ka' in the above formula can also be directly represented as Ka, and these will not be exhaustively listed here.

[0244] Accordingly, the second device calculates the integrity protection key based on the third intermediate key and the third random number using the second calculation method, which can be expressed as: Where KI represents the integrity protection key, NONCE1 represents the third random number, and the meanings of other contents in this formula are the same as in the previous embodiment, and will not be repeated here. The XOR calculation in the above formula can also be replaced by direct connection calculation or KDF calculation, which will not be elaborated here.

[0245] In another possible example, a third calculation method is used to calculate a fourth intermediate key based on the root key and the first random number.

[0246] The third calculation method, which calculates the fourth intermediate key based on the root key and the first random number, can be expressed as follows: ,in, This represents the fourth intermediate key. The meanings of other contents in the formula are the same as in the previous embodiments and will not be repeated. It should be understood that this example uses... The fourth intermediate key is used to distinguish it from the second intermediate key represented by Ka and the third intermediate key represented by Ka' in the aforementioned embodiments. In some other possible examples, the above formula... It can also be directly represented as Ka, which will not be exhaustively listed here. In addition, the XOR calculation in the above formula can also be replaced by KDF or direct connection calculation, which will not be elaborated here.

[0247] Taking the first key as the physical layer key as an example, the third intermediate key is calculated based on the fourth intermediate key and the physical layer key using the second calculation method, which can be expressed as: In this formula, kb is the third intermediate key. The meanings of the other contents are the same as in the previous embodiment and will not be repeated.

[0248] Taking the first key as the first intermediate key as an example, the third intermediate key is calculated using the second calculation method based on the fourth intermediate key and the physical layer key, which can be expressed as: The meaning of the contents in this formula is the same as in the aforementioned embodiments, and will not be repeated here. The above f2() can also be replaced with other calculation methods in the aforementioned second calculation method, which will not be repeated here.

[0249] The calculation of the third intermediate key based on the fourth intermediate key using the second calculation method can be expressed as follows: In the examples above, f2() can also be replaced with other calculation methods in the second calculation method mentioned above, which will not be elaborated here.

[0250] Accordingly, the integrity protection key is calculated using the second calculation method based on the third intermediate key and the third random number, which can be expressed as: Where KI represents the integrity protection key, NONCE1 represents the third random number, and the meanings of other contents in this formula are the same as in the previous embodiment, and will not be repeated here. The XOR calculation in the above formula can also be replaced by direct connection calculation or KDF calculation, which will not be elaborated here. In addition, in order to distinguish it from the third intermediate key represented by Ka' in the previous embodiment, the third intermediate key is represented as kb in this embodiment. In actual processing, the above The representation of 'kb' can also be replaced, as long as the calculation method is the one provided in this example, it is within the protection scope of this embodiment.

[0251] It should be noted that the above is an exemplary description of generating an integrity protection key, using an electronic device as the execution subject. If the electronic device is a second device, any one or more of the aforementioned processes for generating the integrity protection key can be executed, and will not be elaborated further. If the electronic device is a first device, if the first device can obtain the root key, it can execute the aforementioned process for generating the third intermediate key and the fourth intermediate key. Furthermore, since the first device possesses a physical layer key, it can execute the aforementioned process for generating the second intermediate key.

[0252] In some possible examples, the first device may also receive at least one of a second, third, and fourth intermediate key from the first network device. That is, the first message may also carry at least one of the following: the second intermediate key, the third intermediate key, and the fourth intermediate key.

[0253] The first message also carries at least one of the following: a second intermediate key, a third intermediate key, and a fourth intermediate key; the method further includes one of the following: the first network device receives at least one of the second intermediate key, the third intermediate key, and the fourth intermediate key sent by the second network device; the first network device calculates the third intermediate key using a third calculation method based on a physical layer key, the root key, and the first random number, wherein the physical layer key is a key shared between the second device and the first device; the first network device calculates the fourth intermediate key using the third calculation method based on the root key and the first random number; the first network device calculates the third intermediate key using the second calculation method based on the fourth intermediate key and the physical layer key; the first network device calculates the second intermediate key using the third calculation method based on the physical layer key and the anonymous key; the first network device calculates the second intermediate key using the third calculation method based on the physical layer key and the first random number.

[0254] The specific processing of the first network device generating the second, third, and fourth intermediate keys is the same as in the previous embodiments and will not be repeated. It should be noted that the first message may carry only the third intermediate key, only the fourth intermediate key, or both the third and fourth intermediate keys, or all of the above keys; this embodiment does not limit this.

[0255] The first network device receiving at least one of the second, third, and fourth intermediate keys from the second network device can mean that the first network device directly obtains at least one of the second, third, and fourth intermediate keys from the second network device. The specific processing for the second network device to generate each intermediate key is the same as in the previous embodiments and will not be repeated.

[0256] Regarding the above process for generating integrity protection keys, it should also be noted that the second device and the first device need to use the same parameters and the same calculation formula to calculate their respective integrity protection keys. For example, they can both use the physical layer key, the anonymous key, and the third random number to perform an XOR calculation to obtain their respective integrity protection keys.

[0257] In addition, the above is only an illustrative example. In the actual process of generating integrity protection keys, other parameters can be added, such as the identifier of the second device. Not all possible parameters are listed here.

[0258] In the above example, if a physical layer key is used, since the physical layer key is a shared key generated between the second and first devices through the channel source characteristics over the air interface, it possesses Shannon information theory security. Therefore, sending the third random number (i.e., NONCE1) is secure, and the integrity protection key generated using the third random number and the physical layer key is also secure. Furthermore, since the physical layer key does not require cryptographic computation, it has low power consumption, making it more suitable for AIoT devices. Because the physical layer key is a shared key between the second and first devices, only a specific first device can obtain the correct integrity protection key to verify message integrity. Even if an attacker obtains the third random number, they cannot obtain the integrity protection key; therefore, the integrity protection key is secure.

[0259] In some possible implementations, the second device and the first device negotiate an encryption key.

[0260] Both the second device and the first device need to generate their own encryption keys to encrypt the data transmitted between them. The parameters and calculation methods used by the second device and the first device to generate their respective encryption keys should be the same. Therefore, in this example, the second device and the first device are referred to as electronic devices to explain the method of generating encryption keys. It should be noted that the electronic device in this example can be either the second device or the first device, without repeating the explanation.

[0261] In this embodiment, the detailed description of the key generation parameters is the same as that in the previous embodiments, and will not be repeated.

[0262] The calculation of the encryption key may include one of the following: calculating the encryption key using a second calculation method on a fourth random number and the anonymous key; calculating the encryption key using the second calculation method based on a first random number and the fourth random number; calculating the encryption key using the second calculation method based on the anonymous key, the first key, and the fourth random number; calculating the encryption key using the second calculation method based on the first random number, the first key, and the fourth random number; calculating the encryption key using the second calculation method based on a second intermediate key and the fourth random number, wherein the second intermediate key is related to the key generation parameters; or calculating the encryption key using the second calculation method based on a third intermediate key and the fourth random number, wherein the third intermediate key is related to the root key and the key generation parameters.

[0263] The calculation methods for the second and third intermediate keys are the same as those in the previous implementation method, so they will not be repeated in this implementation method.

[0264] Optionally, the encryption key is calculated using the second calculation method based on the anonymous key and the fourth random number. For example, it can be represented as: Where Kc represents the encryption key, NONCE2 represents the fourth random number, and AK represents the anonymity key; or it can be represented as: Where KDF() is the key derivation function, the meanings of other contents in this formula are the same as in the previous embodiments, and will not be repeated; or it can be expressed as: In this formula, "||" represents direct calculation. The meanings of the other contents are the same as those in the previous embodiments and will not be repeated.

[0265] Optionally, the encryption key is calculated using a second calculation method based on the anonymous key, the first key, and the fourth random number.

[0266] For example, if the first key mentioned above can specifically be a physical layer key, then the encryption key can be calculated using the second calculation method on the fourth random number, the physical layer key, and the anonymous key, as follows: Where Kc represents the encryption key, NONCE2 represents the fourth random number, and AK represents the anonymous key. The meanings of other contents in this formula are the same as in the previous embodiments and will not be repeated. For example, the encryption key calculated using the second calculation method with the fourth random number, the physical layer key, and the anonymous key can be expressed as: Where KDF() is the key derivation function, the meanings of other contents in this formula are the same as in the previous embodiments, and will not be repeated. For another example, the integrity protection key calculated using the second calculation method based on the physical layer key, the anonymous key, and the third random number can be expressed as: In this formula, "||" represents direct calculation. The meanings of the other contents are the same as those in the previous embodiments and will not be repeated.

[0267] For example, if the first key mentioned above can specifically be a first intermediate key, then the encryption key can be calculated using the second calculation method on the fourth random number, the first intermediate key, and the anonymous key, as follows: Where Kc represents the encryption key, NONCE2 represents the fourth random number, AK represents the anonymity key, and Km represents the first intermediate key. Alternatively, it can be represented as: Where KDF() is the key derivation function, the meanings of the other contents in this formula are the same as in the previous embodiment, and will not be repeated here. Or it can be expressed as: In this formula, "||" represents direct calculation. The meanings of the other contents are the same as those in the previous embodiments and will not be repeated.

[0268] Optionally, the encryption key is calculated using a second calculation method based on the first key, the first random number, and the fourth random number. That is, AK (anonymous key) in the above Kc calculation formula can be replaced with the first random number RAND. Other calculation formulas can also be replaced similarly, which will not be elaborated here.

[0269] Optionally, the encryption key is calculated using the second calculation method based on the second intermediate key and the fourth random number, wherein the second intermediate key is related to the physical layer key and the key generation parameters. Here, the generation method of the second intermediate key is the same as in the previous embodiment and will not be described again; the second intermediate key can be represented as Ka.

[0270] The second device calculates the encryption key based on the second intermediate key and the fourth random number using the second calculation method, which can be expressed by the following formula: Where Kc represents the encryption key, Ka represents the second intermediate key, and NONCE2 represents the fourth random number. For example, the above calculation formula can also replace the XOR calculation with a direct connection calculation "||", or it can be replaced with KDF, etc., which will not be elaborated here.

[0271] Optionally, the second device uses a second calculation method to calculate the encryption key based on the third intermediate key and the fourth random number.

[0272] In one possible example, the encryption key is calculated using the second calculation method based on the third intermediate key and the fourth random number, which can be expressed as: Where Kc represents the encryption key, NONCE2 represents the fourth random number, and the meanings of other elements in this formula are the same as in the previous embodiments, and will not be repeated here. The XOR calculation in the above formula can also be replaced by direct connection calculation or KDF calculation, which will not be elaborated here.

[0273] In yet another possible example, the encryption key is calculated using the second calculation method based on the third intermediate key and the fourth random number, which can be expressed as: The meanings of each element in this formula are the same as in the aforementioned embodiments, and will not be repeated here. The XOR calculation in the above formula can also be replaced by direct connection calculation or KDF calculation, which will not be elaborated here. In the above examples, the calculation methods and generation parameters of Ka' and Kb are the same as in the aforementioned embodiments, and therefore will not be repeated.

[0274] Optionally, the encryption key is calculated using a second calculation method based on the first key, the third intermediate key, and the third random number. Here, the third intermediate key may be related to the root key.

[0275] For example, the first network device may negotiate with the second device in advance to generate a pairwise master key (PMK) based on the shared root key used for mutual authentication, and use this shared key as the aforementioned third intermediate key. Then, the first network device may send the third intermediate key to the second device via a first message, thereby enabling the second device and the first device to share the third intermediate key.

[0276] For example, the first key is the physical layer key, and the encryption key is calculated using the second calculation method based on the first key, the third intermediate key, and the third random number, which can be expressed as: Where Ks represents the encryption key, NONCE1 represents the third random number, and PMK represents the third intermediate key. For example, it can be calculated using the following formula: Where KDF() is the key derivation function, the meanings of the other contents in this formula are the same as in the previous embodiments, and will not be repeated. For example, the following formula is used for calculation: In this formula, "||" represents direct calculation. The meanings of the other contents are the same as those in the previous embodiments and will not be repeated.

[0277] It should also be noted that in the above process of generating the integrity protection key, encryption key, first RES, second RES, MAC, first verification RES, second verification RES, and verification MAC, the identifier of the second device and / or the identifier of the first device can be added. For example, when calculating the MAC (or verification MAC), the ID of the second device and the ID of the first device can be added; for example, when calculating the encryption key (or integrity protection key), the physical layer key (or the first intermediate key), the root key, the random number, and the ID of the second device (and / or the ID of the first device) can be XORed, etc. Not all possible cases are exhaustively listed here.

[0278] In some possible implementations, the second device and the first device may also use their respective integrity protection keys and / or encryption keys during the communication process.

[0279] Optionally, the third message also carries a first integrity verification code.

[0280] Optionally, the third message may also carry a third random number and / or a fourth random number.

[0281] Optionally, the second device receives a response message from the first device, the response message being in response to the third message, the response message carrying at least one of the following: an indication that the integrity verification of the third message has passed, a second integrity verification code, the fourth random number, and an encrypted group key.

[0282] Optionally, the first device sends a response message to the second device, the response message being in response to the third message, the response message carrying at least one of the following: an indication that the integrity verification of the third message has passed, a second integrity verification code, the fourth random number, and an encrypted group key.

[0283] Optionally, the second message may also carry at least one of the following: the third random number, the third integrity verification code, the encrypted group key, and the fourth random number.

[0284] The specific details regarding the transmission of random numbers used to generate integrity protection keys and / or encryption keys, as well as the processing of obtaining integrity verification codes in the aforementioned messages, are as follows.

[0285] In some possible examples, the first device sending a second message to the second device may include: the first device generating a third random number; the first device generating an integrity protection key based on key generation parameters and the third random number; the first device calculating a third integrity verification code based on the integrity protection key; the first device sending the second message to the second device; the second message carrying the third random number and the third integrity verification code.

[0286] The processing by the second device may include: the second message also carries a third random number and the third integrity verification code; the second device calculates the verification MAC based on the authentication parameters and the root key, including: the second device generates an integrity protection key based on the key generation parameters and the third random number; the second device verifies the third integrity verification code based on the integrity protection key to obtain a second verification result; if the second verification result indicates that the integrity verification of the second message is successful, the second device calculates the verification MAC based on the authentication parameters and the root key.

[0287] In other words, in this example, the third random number is generated by the first device, and the first device performs integrity protection processing when sending the second message. On the second device side, the integrity protection key is first obtained based on the third random number carried in the second message, and then the third integrity verification code carried in the second message is verified. When the integrity verification of the second message passes, the second device performs the aforementioned calculation and verification MAC processing.

[0288] The aforementioned calculation of the third integrity verification code by the first device based on the integrity protection key can refer to the first device calculating the third integrity verification code based on the original content of the second message using the integrity protection key. The original content of the second message can refer to the original content that the second message needs to carry, such as the first random number, the third random number, authentication parameters, and MAC address, etc.

[0289] The second device verifies the third integrity verification code based on the integrity protection key to obtain a third verification result. This can refer to the second device calculating a third verification code based on the original content of the second message using the integrity protection key. If the third verification code and the third integrity verification code are the same, the second verification result is obtained to indicate that the integrity verification of the second message has passed. If the third verification code and the third integrity verification code are different, the second verification result is obtained to indicate that the integrity verification of the second message has failed.

[0290] Furthermore, the third message also carries a first integrity verification code. When the second device completes the aforementioned calculation and verification MAC processes and sends the third message to the first device, the second device can calculate the first integrity verification code based on the integrity protection key of the original content of the third message, and then send the third message carrying the first integrity verification code and the original content to the first device. In this example, the original content of the third message may include the content shown in the foregoing embodiments, which will not be elaborated here.

[0291] Accordingly, after the first device receives the third message from the second device, the processing of the first device may further include: the first device verifying the first integrity verification code based on the integrity protection key to obtain a third verification result; if the third verification result indicates that the integrity verification of the third message has passed, the first device sends a response message to the second device, the response message responding to the third message, and the response message also indicating that the integrity verification of the third message has passed.

[0292] The aforementioned second device calculating the first integrity verification code based on the integrity protection key and the original content of the third message can refer to: the second device calculating the first integrity verification code based on the integrity protection key and the original content of the third message. The original content of the third message can refer to the original content that the second message needs to carry; however, it will not be exhaustively listed here.

[0293] In this example, when the first device determines that the integrity verification of the third message has passed, it can also determine that the content carried by the third message has not been tampered with; similarly, when the second device determines that the integrity verification of the second message has passed, it can also determine that the third random number carried by the second message has not been tampered with.

[0294] In another example, the third message carries the third random number, and further processing on the second device side may include: the second device generating the third random number; the second device generating the integrity protection key based on key generation parameters and the third random number. Accordingly, the third message includes a first integrity verification code.

[0295] Here, the second device may perform the process of generating a third random number after confirming that the core network side device has passed authentication. Further, after generating the integrity protection key, the second device calculates a first integrity verification code based on the original message of the third message and the integrity protection key, and generates a third message carrying the original message and the first integrity verification code. The original message may refer to the information that the third message needs to carry. For example, in this example, the original message may at least carry the aforementioned third random number. Other content that may be carried in the original message is the same as in the previous embodiments and will not be repeated.

[0296] The processing after receiving the third message on the first device side includes: the first device generating an integrity protection key based on the key generation parameters and the third random number; the first device verifying the first integrity verification code based on the integrity protection key to obtain a fourth verification result; if the fourth verification result indicates that the integrity verification of the third message has passed, the first device sending a response message to the second device, the response message responding to the third message, the response message indicating that the integrity verification of the third message has passed, and the response message carrying a second verification code calculated based on the integrity protection key.

[0297] Here, the first device verifies the first integrity verification code in the third message based on the integrity protection key to obtain a fourth verification result. This can include: the first device calculates a first verification code based on the original message contained in the third message using the integrity protection key, and verifies the first verification code and the first integrity verification code to obtain a fourth verification result. Further, verifying the first verification code and the first integrity verification code to obtain a fourth verification result can include one of the following: if the first verification code and the first integrity verification code are the same, a fourth verification result indicating that the integrity verification of the third message has passed is obtained; if the first verification code and the first integrity verification code are different, a fourth verification result indicating that the integrity verification of the third message has failed is obtained. The specific processing by which the first device calculates the first verification code based on the integrity protection key in the original message contained in the third message is similar to the aforementioned processing by which the second device calculates the first integrity verification code based on the integrity protection key in the original message of the third message, and will not be repeated here.

[0298] In other words, since the parameters and calculation methods used by the first device and the second device to generate the integrity protection key are the same, the first code to be verified obtained by the first device should be the same as the first integrity verification code, and thus the first device can determine that the integrity verification is passed (or successful or completed).

[0299] Processing on the second device side: The second device receives a response message from the first device. This response message is in response to the third message and carries indication information indicating that the integrity verification of the third message has passed, as well as a second integrity verification code. Further, the second device verifies the second integrity verification code based on the integrity protection key to obtain a first verification result.

[0300] Here, the second device verifies the second integrity verification code based on the integrity protection key to obtain a first verification result, which may include: the second device calculating a second verification code based on the original content contained in the response message using the integrity protection key, and verifying based on the second verification code and the second integrity verification code to obtain a first verification result. Further, verifying based on the second verification code and the second integrity verification code to obtain a first verification result may include one of the following: if the second verification code and the second integrity verification code are the same, a verification result indicating that the integrity verification of the response message has passed is obtained; if the second verification code and the second integrity verification code are different, a verification result indicating that the integrity verification of the response message has failed is obtained. The method for calculating the second verification code is similar to the method for calculating the first integrity verification code, except that the second device uses the original content in the response message to calculate the second verification code, which will not be repeated here. The original content in the response message is not limited in this embodiment. In this case, the second verification code and the second integrity verification code obtained by the second device should be the same, and thus the second device can determine that the integrity verification has passed (or succeeded or completed).

[0301] In some possible examples, the aforementioned third message can also be directly sent from the second device to the first network device. Correspondingly, after generating an integrity protection key, the first network device generates its own verification code based on the integrity protection key. If its generated verification code is the same as the first integrity verification code carried in the third message, the integrity verification of the third message is confirmed to be successful. Then, it obtains the first RES from the third message. If the first RES is the same as the first verification RES it stores, it determines that the verification of the second device is successful. Furthermore, the first network device can also send a response message to the second device. This response message responds to the third message, and the response message can carry a second integrity verification code generated based on the integrity protection key. After generating its own second verification code, if the second verification code is the same as the second integrity verification code, it determines that the integrity protection key negotiation between the two devices is complete.

[0302] It should be noted that in this example, the third message mentioned above can be forwarded by the first device to the first network device; the response message can be forwarded by the first device to the second device. However, the first device does not perform any further processing on the third message. The method by which the first network device generates the third integrity protection key can be the same as the method described above for generating integrity protection keys, and will not be repeated here.

[0303] In one possible example, if the second device and the first device each perform integrity verification on the received message based on their respective integrity protection keys and the verification passes, the second device and the first device can negotiate the encryption key.

[0304] Optionally, the second device can perform integrity protection on the third message when sending it. Correspondingly, if the integrity verification of the third message passes, the first device generates an encryption key and sends a fourth random number in a response message to the second device; the second device generates an encryption key based on the fourth random number carried in the response message. This third message can be used to instruct the second device to complete the authentication of the core network side equipment.

[0305] In the processing performed by the first device, after the first device receives the third message, the method may further include: the first device generating a fourth random number; the first device obtaining an encryption key based on the fourth random number and key generation parameters; and the first device sending a response message to the second device, the response message carrying the fourth random number.

[0306] In the processing performed by the second device, the response message also carries a fourth random number; the method further includes: when the first verification result indicates that the integrity verification of the response message has passed, the second device calculates an encryption key based on the fourth random number and the key generation parameters.

[0307] For example, the conditions for the first device to generate the fourth random number may include at least one of the following: the third message integrity verification is passed, or the second device authentication is passed.

[0308] For example, if the aforementioned third message does not carry the second RES or the first RES, then the first device generating the fourth random number may include: the first device generating the fourth random number when the integrity verification of the third message passes. That is, the first device only generates the encryption key when the integrity verification of the third message passes. In this example, the aforementioned response message can also be used to indicate that the integrity verification of the third message has passed. For example, if the third message carries the second RES and / or the first RES, and the third message carries the first verification code, then the first device generating the fourth random number may also include: the first device generating the fourth random number when it determines that the second device has passed authentication, and the third verification result indicates that the integrity verification of the third message has passed. Here, determining that the second device has passed authentication may include the first device receiving the second device authentication notification from the first network device, and / or the first device itself verifying that the second RES is the same as the second verification RES, thus determining that the second device has passed authentication.

[0309] Optionally, if the second device verifies the integrity of the second message, it can generate an encryption key when sending the third message and include a fourth random number in the third message. Correspondingly, if the first device verifies the integrity of the third message, it generates an encryption key based on the fourth random number included in the third message.

[0310] In this example, the processing of the second device is described as follows: the third message carries a fourth random number; the method further includes: the second device generating the fourth random number; and the second device calculating an encryption key based on the fourth random number and key generation parameters.

[0311] The processing description on the first device side is as follows: the third message carries a fourth random number, and the method further includes: the first device obtains an encryption key based on the fourth random number and key generation parameters.

[0312] For example, the conditions for the second device to generate the fourth random number may include at least one of the following: the second message integrity verification is passed, or the core network side device is authenticated. The third message can be used to instruct the second device to complete the authentication of the core network side device, and the third message can also be used to instruct the second message integrity verification to be passed.

[0313] For example, the conditions under which the first device obtains the encryption key based on the fourth random number and key generation parameters may include at least one of the following: the third message integrity verification is passed, or the first device determines that the second device has been authenticated.

[0314] For example, if the aforementioned third message does not carry the second RES or the first RES, then the first device obtains the encryption key if the third verification result indicates that the integrity verification of the third message has passed. For example, if the third message carries the second RES and / or the first RES, and the third message carries the first verification code, then the first device obtains the encryption key if it determines that the second device has passed authentication and the third verification result indicates that the integrity verification of the third message has passed.

[0315] It should also be noted that after the first device generates the encryption key, it can also send a response message to the second device. This response message can carry an indication that the integrity verification of the third message has been passed, as well as an indication that the second device has been authenticated.

[0316] In some possible examples, integrity verification is not required between the second device and the first device, but the second device and the first device can negotiate encryption keys to obtain encryption keys that are used to encrypt the data transmitted between the second device and the first device.

[0317] Optionally, in the processing performed by the first device, after the first device receives the third message, the method may further include: the first device generating a fourth random number; the first device obtaining an encryption key based on the fourth random number and key generation parameters; and the first device sending a response message to the second device, the response message carrying the fourth random number. This third message may only be used to instruct the second device to complete authentication of the core network side device.

[0318] In the processing performed by the second device, the response message also carries a fourth random number; the method further includes: the second device receiving a response message from the first device, the response message responding to the third message, the response message carrying a fourth random number; the second device calculating an encryption key based on the fourth random number and key generation parameters.

[0319] For example, if the aforementioned third message does not carry the second RES, the first RES, or the first verification code, then the first device can directly generate the fourth random number. For example, if the third message carries the second RES and / or the first RES, then the first device generates the fourth random number after determining that the second device has passed authentication. Here, the explanation regarding determining that the second device has passed authentication is the same as in the aforementioned embodiments and will not be repeated.

[0320] Optionally, the processing of the second device is described as follows: the third message carries a fourth random number; the method further includes: the second device generating the fourth random number; the second device calculating an encryption key based on the fourth random number and key generation parameters. The processing of the first device is described as follows: the third message carries a fourth random number, and the method further includes: the first device obtaining an encryption key based on the fourth random number and key generation parameters.

[0321] For example, the conditions for the second device to generate the fourth random number may include completing authentication of the core network-side device. The aforementioned third message is used to instruct the second device to complete authentication of the core network-side device.

[0322] For example, if the aforementioned third message does not carry the second RES or the first RES, the first device directly calculates the encryption key. If the third message carries the second RES and / or the first RES, the first device calculates the encryption key if it determines that the second device has passed authentication.

[0323] After the first device generates the encryption key, it can also send a response message to the second device, which can be used to indicate that the second device has been successfully authenticated.

[0324] In some possible implementations, the first device may also send one or more keys to a key management function entity (or network element).

[0325] For example, the first device can send the integrity protection key and / or encryption key to the key management function entity. The key management function entity can store the integrity protection key and / or encryption key, so that if the first device and / or the second device are moved, the first device and / or the second device or other devices do not need to regenerate their respective integrity protection keys and encryption keys, thereby improving the system's processing efficiency.

[0326] For example, the first device can send the second intermediate key and / or the third intermediate key to the key management function entity. The key management function entity can store the second intermediate key and / or the third intermediate key, so that if the first device and / or the second device or other devices move, the first device and / or the second device or other devices do not need to regenerate the second intermediate key and / or the third intermediate key, but can directly generate their respective integrity protection keys and encryption keys based on the second intermediate key and / or the third intermediate key, thereby improving the system's processing efficiency.

[0327] The aforementioned key management function entity can be any one or more network-side devices, such as AMF, access network devices, SEAF, AUSF, etc. The access network device can be at least one of a base station, gNB, eNB, etc. We will not exhaustively list all possible devices here. The aforementioned key management function entity can be a Key Management Service (KMS) entity or a Key Management Function (KMF) entity.

[0328] In some possible implementations, the processing flow of the above authentication method may be triggered by a second device.

[0329] Before the second device receives the second message sent by the first device, the process may further include: the second device sending an authentication request to the first device, the authentication request carrying the identifier of the second device.

[0330] The processing of the first device may further include: the first device receiving an authentication request from the second device, the authentication request carrying the identifier of the second device; and the first device forwarding the authentication request to the first network device.

[0331] The processing of the first network device may further include: the first network device receiving an authentication request from the first device, the authentication request carrying the identifier of the second device.

[0332] After receiving the authentication request, the first network device performs the aforementioned process of obtaining the MAC address and authentication parameters, which will not be repeated here. Then, the first network device sends the first message to the first device.

[0333] After receiving the first message from the first network device, the first device sends a second message to the second device.

[0334] After receiving the second message from the first device, the second device performs the aforementioned calculation and verification MAC processing, as well as the authentication of network-side devices based on the verification MAC and the MAC, which will not be repeated here.

[0335] After the second device completes authentication of the core network-side device, the method may further include: the second device sending a third message to the first device, the third message instructing the second device to complete authentication of the core network-side device. Correspondingly, the method of the first device may further include: the first device receiving a third message from the second device, the third message instructing the second device to complete authentication of the core network-side device; the first device sending a fourth message to the first network device, the fourth message instructing the second device to complete authentication of the core network-side device. The processing method of the first network device may further include: the first network device receiving a fourth message from the first device, wherein the fourth message instructs the second device to complete authentication of the core network-side device.

[0336] The following is combined with Figure 6 The authentication method provided in the foregoing embodiments will be described by way of example. Figure 6 In this context, the second device is considered an A-IoT device. Figure 6 For simplicity, this example uses A-IoT, with the first device being a UE, the first network device being an AUSF, and the second network device being a UDM and / or ARPF. It should be understood that... Figure 6 For simplicity, the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. Figure 6 The authentication method processing flow includes:

[0337] A-IoT devices (i.e., A-IoT) and core network devices share a unique, non-repeating root key Kr, which serves as the security credential for A-IoT devices. It should be understood that here we are referring to only one A-IoT device. In actual operation, there can be multiple A-IoT devices. Since the processing for each A-IoT device is identical, we will not elaborate on them individually.

[0338] Step 601: The A-IoT device sends an authentication request to the UE, carrying the A-IoT ID.

[0339] Step 602: The UE forwards the authentication request to the AUSF, carrying the A-IoT ID.

[0340] Step 603: AUSF forwards the authentication request to UDM / ARPF. UDM / ARPF generates the first random number RAND, and then generates anonymous keys AK, MAC, and XRES (i.e., the aforementioned first verification RES) based on Kr. AK, MAC, and RES are then sent to AUSF.

[0341] For example, Figure 7a In other words, the generation architecture for the above parameters can include: MAC = f2(Kr, AK), XRES = f2(Kr, RAND). f2 can also be replaced by algorithms such as HMAC-SHA-256, AES, ACSON, SNOW 3G, and ZUC. Since AK needs to be sent, algorithms that can be reverse-derived, such as XOR, cannot be used to generate MAC and XRES. Because Kr is a unique, non-repeating key shared only by each A-IoT device and the core network, an attacker intercepting AK cannot obtain RAND or Kr. Therefore, generating and sending AK is secure and features low power consumption. Sending MAC is also secure, and since MAC is generated based on Kr, and only AUSF possesses Kr, verifying MAC can verify the identity of the core network.

[0342] For example, Figure 7b In other words, the generation architecture for the above parameters can include: MAC = f2(Kr, AK, service parameters), XRES = f2(Kr, RAND, service parameters). f2 can also be replaced by algorithms such as HMAC-SHA-256, AES, ACSON, SNOW 3G, ZUC, etc.

[0343] Step 604: The AUSF sends an authentication response to the UE, carrying the AK and MAC addresses. The authentication response may also carry the A-IoTID. This authentication response is the first message in the aforementioned embodiment.

[0344] Step 605: The UE forwards an authentication response to the A-IoT device, carrying the AK and MAC addresses. The authentication response message in this step is the second message in the aforementioned embodiment.

[0345] Step 606: After receiving the authentication response message, the A-IoT device calculates MAC'. After successfully verifying the MAC based on MAC', it determines that the AUSF identity has been successfully verified and calculates RES. The RES in this step is the first RES in the aforementioned embodiment.

[0346] For example, the computing methods of A-IoT devices may include: MAC'=f2(Kr,AK), RES=f2(Kr,RAND). Since RES is generated based on Kr, and only A-IoT devices possess Kr, the core network side devices can verify the identity of A-IoT devices by verifying RES.

[0347] Step 607: After the A-IoT device successfully verifies its identity with the core network, it calculates the integrity protection key KI.

[0348] For example, this step may include: the A-IoT device generating a third random number, NONCE1; and then based on the formula... The integrity protection key is calculated. The XOR ⊕ algorithm used for KI generation can also be direct ||, or KDF algorithms such as HMAC-SHA-256, etc. Other optional KI generation parameters include A-IoT ID, etc. This integrity protection key is used to protect the integrity of A-IoT devices and network entities. Network entities can include, but are not limited to, at least one of the following: UE, other network devices; other network devices can include: AP, small cell, gNB, CPE, AMF, UPF, MEC, etc. Since the physical layer key is a shared key generated between the A-IoT device and the UE through the channel source characteristics of the air interface, it has Shannon information theory security. Therefore, sending NONCE1 is secure and will not leak KI. The KI generated using NONCE1 and the physical layer key is also secure. Furthermore, since the physical layer key does not require cryptographic computation, it has low power consumption.

[0349] Step 608: The A-IoT device sends an authentication confirmation to the UE. This message carries RES, NONCE1 (i.e., the third random number in the aforementioned embodiment). The A-IoT device uses KI to protect the integrity of the authentication confirmation message before sending it. The authentication confirmation message in this step is the third message in the aforementioned embodiment.

[0350] Step 609: After receiving the authentication confirmation message, the UE generates... , for UE Perform integrity verification on the authentication confirmation message.

[0351] Should It can be an integrity protection key on the UE side, theoretically Similar to the previously mentioned KI, this example uses different notation to distinguish the integrity protection keys generated by different devices. This example uses a physical layer key to generate the integrity protection key KI. Since the physical layer key is a shared key generated between the A-IoT device and the UE through the channel source characteristics of the air interface, it possesses Shannon information theory security. Therefore, only this specific UE can verify message integrity. Furthermore, only a specific UE can obtain the physical layer key; therefore, even if an attacker obtains NONCE1, they cannot obtain KI, thus KI is secure.

[0352] Step 610: After completing the integrity verification, the UE confirms that the RES has not been tampered with, sends an authentication confirmation to the AUSF, which carries the RES; and generates a fourth random number (NONCE 2), using NONCE 2 to generate an encryption key (Kc), which is used for message encryption protection between the UE and the A-IoT device. This authentication confirmation can be the fourth message in the aforementioned embodiments. For example, .

[0353] Step 611, the UE sends an authentication response to the A-IoT device, before sending... The authentication response, which protects integrity, carries NONCE2. Here, the authentication response can be the response message in the aforementioned embodiments, i.e., the response message in response to the third message. Since the physical layer key is a shared key between the A-IoT device and the UE, it possesses Shannon information theory security. Only a specific UE can obtain the physical layer key; therefore, even if an attacker obtains NONCE2, they cannot obtain the physical layer key. Kc generated using NONCE2 and the physical layer key is also secure. Furthermore, since the physical layer key does not require cryptographic computation, Kc generation is characterized by low power consumption.

[0354] Step 612, the UE sends Kc and .

[0355] It should be understood that the processing of steps 612 and 611 can be performed in any order.

[0356] Step 613: The A-IoT device receives the authentication response, verifies its integrity using KI, confirms that NONCE2 has not been tampered with, and generates Kc using NONCE2. The method for generating Kc is the same as in the previous example and will not be repeated here.

[0357] Additionally, step 614 can be performed on the AUSF side to verify RES. The specific method for AUSF to verify RES is the same as in the aforementioned embodiments and will not be repeated here.

[0358] Combination Figure 8The key generation architecture is illustrated below. The A-IoT device and the AUSF / UDM / ARPF share the root key Kr. In negotiating KI and Kc, the A-IoT device and the UE obtain their respective Kc and KI using the same method. KI is obtained by combining the physical layer key, AK, and a third random number (NONCE1), while Kc is obtained by combining the physical layer key, AK, and a fourth random number. Finally, the UE sends Kc and KI to the KMS, thus enabling the UE, A-IoT device, and KMS to share the same Kc and KI. Figure 8 In this example, the physical layer key is optional and is therefore represented by a dashed box. That is, in some possible examples, KI is obtained by combining AK with a third random number (i.e., NONCE1), and Kc is obtained by combining AK with a fourth random number. The various possible examples for generating KI and Kc are the same as in the previous embodiments and will not be repeated. Figure 8 In this paper, there is no distinction between KI and KI', nor is there a distinction between Kc generated by different devices. This is because KI and KI' should theoretically be the same, and Kc obtained by different devices using the same method and algorithm should also be the same. Therefore, in Figure 8 No distinction is made in the description.

[0359] Combination Figure 8 To illustrate the key generation architecture further, the root key Kr is shared between the A-IoT device and the AUSF / UDM / ARPF sides; during the negotiation of KI and Kc, the A-IoT device and the access network device (e.g., Figure 8 Each access network device (gNB) obtains its Kc and KI in the same way. KI is obtained by combining the physical layer key (optionally), AK, and a third random number (NONCE1), while Kc is obtained by combining the physical layer key (optionally), AK, and a fourth random number. Finally, the access network device sends Kc and KI to the KMS, thus enabling the access network device, A-IoT device, and KMS to share the same Kc and KI.

[0360] Combination Figure 8To further illustrate the key generation architecture, the root key Kr is shared between the A-IoT device and the AUSF / UDM / ARPF sides. During the negotiation of KI and Kc, the A-IoT device and the first core network device (such as any one of the various first core network devices described in the preceding embodiments, not exhaustively listed here) obtain their respective Kc and KI in the same way. KI is obtained by combining the physical layer key (optionally), AK, and a third random number (i.e., NONCE1), while Kc is obtained by combining the physical layer key (optionally), AK, and a fourth random number. Finally, the first core network device sends Kc and KI to the KMS, thus enabling the first core network device, the A-IoT device, and the KMS to share the same Kc and KI.

[0361] The above authentication method simplifies the processing flow compared to the existing AKA process. A-IoT devices can obtain RES and MAC through simple operations such as XOR and f2, thus completing bidirectional authentication with the network. Furthermore, the key negotiation process is also simplified. In this authentication method, the A-IoT device and the UE (or other authentication proxy devices, such as AP, smallcell, CPE, etc.) obtain a shared key (including encryption and integrity protection keys) based on the physical layer key and XOR operations. If needed, the UE shares the session key with the KMS for mobility or key generation. Additionally, in the above example, the UE can be replaced with an access network device, thus matching both indirect and direct modes. Furthermore, either the UE or the AUSF can authenticate the A-IoT device; for example, the AUSF can send XRES to the UE, which then performs RES verification. The above examples place certain requirements on the computing power and power consumption of A-IoT devices. AUSF may need to perform simplified MAC calculations. The UE does not need to know the root key Kr of the A-IoT device, which provides strong security. The A-IoT device does not need to use complex calculation methods, such as KDF to generate keys. The UE can act as an authentication agent to complete authentication.

[0362] Combination Figure 9 This section provides another exemplary description of the authentication method provided in the foregoing embodiments. Figure 9 In this example, taking the second device as an A-IoT device (referred to as A-IoT for simplicity), the first device as a UE, the first network device as an AUSF, and the second network device as a UDM and / or ARPF, it should be understood that... Figure 9 For simplicity, the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. Figure 9 The authentication method processing flow includes:

[0363] The processing steps 901 to 904 are the same as described above. Figure 6 Steps 601 to 604 in the example are processed the same way, and will not be described again.

[0364] Step 905: The UE receives the authentication response and calculates the authentication key Ka.

[0365] For example, Ka = f3 (AK, physical layer key), where Ka is the second intermediate key in the aforementioned embodiment. Since the physical layer key is a shared key generated between the A-IoT device and the UE through the channel source characteristics of the air interface, it possesses Shannon information theory security, therefore Ka is secure. The authentication response received by the UE can be the first message from the aforementioned embodiment.

[0366] For example, This means that instead of using the physical layer key to obtain Ka, the fifth random number NONCE3 can be used to calculate the authentication key.

[0367] For example, In other words, the authentication key can be calculated using the AK, the physical layer key, and the fifth random number.

[0368] Step 906: The UE forwards an authentication response to the A-IoT device, carrying the AK and MAC addresses. The authentication response sent by the UE to the A-IoT device can be the second message in the aforementioned embodiment.

[0369] Step 907: After receiving the authentication response, the A-IoT device calculates MAC', and after successfully verifying the MAC based on MAC', it confirms that the AUSF identity has been successfully verified, calculates RES, and calculates the authentication key Ka.

[0370] For example, MAC' = f2(Kr, AK), RES = f2(Kr, RAND), Ka = f3(AK, physical layer key), where MAC' is the authentication MAC. Because the f3 function is required, power consumption is relatively high. The authentication key Ka can be shared with other network entities (UE, or other network devices such as AP, small cell, gNB, CPE, AMF, UPF, MEC, etc.). Kc and KI can be generated based on Ka, and keys between A-IoT devices and other devices can also be generated, thus offering considerable flexibility.

[0371] Step 908: After the A-IoT device successfully verifies its AUSF identity, it calculates the KI.

[0372] For example, the A-IoT device generates a random number NONCE1 (i.e., the third random number) using the formula... The KI is calculated. The XOR algorithm used to generate KI can also be direct connection ||, KDF algorithm such as HMAC-SHA-256, etc. Other optional KI generation parameters can include A-IoT ID, etc.

[0373] Step 909: The A-IoT device sends an authentication confirmation to the UE, carrying RES and NONCE1. In this step, the A-IoT device uses KI to protect the integrity of the authentication confirmation message before sending it. This authentication confirmation can be the third message in the aforementioned embodiments.

[0374] Step 910: After receiving the authentication confirmation, the UE generates a KI and performs integrity verification on the authentication confirmation message based on the KI.

[0375] In this step In this example, the integrity protection key generated by the UE is not distinguished from the integrity protection key generated by the A-IoT device.

[0376] Step 911: After completing the integrity verification, the UE confirms that the RES has not been tampered with, sends an authentication confirmation to the AUSF, which carries the RES; and generates a fourth random number (NONCE 2), using NONCE2 to generate an encryption key (Kc), which is used for message encryption protection between the UE and the A-IoT device. This authentication confirmation can be the fourth message in the aforementioned embodiments. For example, Kc = Ka⊕NONCE2.

[0377] In step 912, the UE sends an authentication response to the A-IoT device, protecting the authentication response message with KI integrity before sending. The authentication response message carries NONCE2.

[0378] In step 913, the UE sends Ka to the network-side Key Management Function (KMF) entity. The processing of steps 912 and 913 can be performed in any order.

[0379] Step 914: The A-IoT device receives the authentication response, verifies its integrity using KI, confirms that NONCE2 has not been tampered with, and generates Kc using NONCE2. The method for generating Kc is the same as in step 911, and will not be described in detail here.

[0380] Additionally, step 915 can be performed on the AUSF side to verify RES. The specific method for AUSF to verify RES is the same as in the aforementioned embodiments and will not be repeated here.

[0381] For example, in combination Figure 10 In other words, the generation architecture for the above parameters can include: MAC = f2(Kr, AK), XRES = f2(Kr, RAND). f2 can also be replaced by algorithms such as HMAC-SHA-256, AES, ACSON, SNOW 3G, and ZUC. Since AK needs to be sent, algorithms that can be reverse-derived, such as XOR, cannot be used to generate MAC and XRES. Because Kr is a unique, non-repeating key shared only by each A-IoT device and the core network, an attacker intercepting AK cannot obtain RAND or Kr. Therefore, generating and sending AK is secure and features low power consumption. Sending MAC is also secure, and since MAC is generated based on Kr, and only AUSF possesses Kr, verifying MAC can verify the identity of the core network. Furthermore, an authentication key Ka is added, Ka = f3(AK, physical layer key).

[0382] Combination Figure 11 The key generation architecture described above is illustrated below. The root key Kr is shared between the A-IoT device and the AUSF / UDM / ARPF sides. In the negotiation of KI and Kc, the authentication key Ka is first obtained based on AK and the physical layer key. This Ka is obtained by both the UE and the A-IoT device using the same method. Ka can be sent to KMS, allowing other A-IoT devices and other network elements to share it. Key Ka can be shared with other network elements (UE, or other network devices such as AP, small cell, gNB, CPE, AMF, UPF, MEC, etc.). Kc and KI can be generated based on Ka, as well as keys between A-IoT devices and other devices, thus offering considerable flexibility. Furthermore, the UE and A-IoT device each calculate Kc and KI using the same method. Kc is obtained by combining Ka with a third random number (NONCE1), and Kc is obtained by combining Ka with a fourth random number. Figure 11 In this context, the physical layer key is optional and is therefore represented by a dashed box. In other words, in some possible examples, Ka can be obtained by combining AK with a fifth random number instead of using the physical layer key, which will not be elaborated further.

[0383] Combination Figure 11To illustrate the key generation architecture further, the root key Kr is shared between the A-IoT device and the AUSF / UDM / ARPF. In negotiating KI and Kc, an authentication key Ka is first obtained based on AK and the physical layer key (optionally). This Ka is obtained by both the gNB and the A-IoT device using the same method. Ka can be sent to the KMS, allowing other A-IoT devices and other network elements to share it. The key Ka can be shared with other network elements (UE, or other network devices such as AP, small cell, gNB, CPE, AMF, UPF, MEC, etc.). Kc and KI can be generated based on Ka, as well as keys between the A-IoT device and other devices, offering considerable flexibility. Furthermore, the gNB and A-IoT device each calculate Kc and KI using the same method. Kc is obtained by combining Ka with a third random number (NONCE1), and Kc is obtained by combining Ka with a fourth random number.

[0384] Combination Figure 11 To illustrate the key generation architecture further, the root key Kr is shared between the A-IoT device and the AUSF / UDM / ARPF. In the negotiation of KI and Kc, the authentication key Ka is first obtained based on AK and the physical layer key (optionally). This Ka is obtained by both the first core network device and the A-IoT device using the same method. Ka can be sent to KMS, allowing other A-IoT devices and other network elements to share it. Key Ka can be shared with other network elements (UE, or other network devices such as AP, small cell, gNB, CPE, AMF, UPF, MEC, etc.). Kc and KI can be generated based on Ka, as well as keys between A-IoT devices and other devices, offering considerable flexibility. Furthermore, the first core network device and the A-IoT device each calculate Kc and KI using the same method. Kc is obtained by combining Ka with a third random number (NONCE1), and Kc is obtained by combining Ka with a fourth random number.

[0385] Combination Figure 12 The authentication method provided in the foregoing embodiments will be further illustrated by example. Figure 12 In this example, taking the second device as an A-IoT device (referred to as A-IoT for simplicity), the first device as a UE, the first network device as an AUSF, and the second network device as a UDM and / or ARPF, it should be understood that... Figure 12 For simplicity, the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. Figure 12 The authentication method processing flow includes:

[0386] The processing steps 1201 to 1205 are the same as described above. Figure 6 Steps 601 to 605 in the example are processed the same way, and will not be described in detail.

[0387] Step 1206: After receiving the authentication response message, the A-IoT device calculates MAC', and after successfully verifying the MAC based on MAC', it determines that the AUSF identity has been successfully verified, and calculates RES (i.e., the first RES) and RES' (i.e., the aforementioned second RES).

[0388] For example, , MAC' = f2 (Kr, AK), RES = f2 (Kr, RAND).

[0389] The calculation of RES' can be one of the following: RES' = f2(physical layer key, AK), RES' = f2(physical layer key, RAND), RES' = f2(physical layer key, RES).

[0390] It should be pointed out that, Figure 12 The explanation uses the UE as an example to illustrate the concept. In real-world scenarios, Figure 12 The UE in the above can also be replaced by a core network element (i.e., the scenario where the first device can be the first core network device). When the first device is the first core network device, the above calculation method of RES' can also be replaced by using the first intermediate key (Km) for calculation. For example, the above calculation method of Km, as in the previous embodiment, can include Km=KDF(intermediate network element identifier, second random number) or Km=KDF(AK, intermediate network element identifier, second random number), which will not be repeated here; correspondingly, the above calculation method of RES' can be replaced by one of the following: RES'= f2(Km, RAND), RES'= f2(Km, RAND), RES'= f2(Km, RES).

[0391] Step 1207 and the aforementioned Figure 6 The steps are the same as in step 607, so I will not repeat them.

[0392] Step 1208: The A-IoT device sends an authentication confirmation message to the UE, carrying RES, RES', and NONCE1. In this step, the A-IoT device uses KI to protect the integrity of the authentication confirmation message before sending it. Figure 11 For the sake of brevity, the authentication confirmation message is represented as "authentication confirmation".

[0393] Step 1209: After receiving the authentication confirmation message, the UE generates... , for UE Perform integrity verification on the authentication confirmation message.

[0394] Step 1210: If the UE passes the integrity verification of the authentication confirmation message, the UE generates XRES' and verifies whether the received RES' and the calculated XRES' are the same.

[0395] XRES' can be generated in one of the following ways: XRES' = f2(physical layer key, AK), XRES' = f2(physical layer key, RAND), or XRES' = f2(physical layer key, RES). Since RES' is generated based on the physical layer key, and only A-IoT devices possess the physical layer key, verifying RES' can verify the identity of the A-IoT device.

[0396] If the received RES' and the calculated XRES' are the same, proceed to steps 1211 to 1215, the specific descriptions of which are the same as in the previous example. Figure 6 Steps 610 to 614 are the same and will not be repeated.

[0397] It should be noted that the above Figure 6 , Figure 9 , Figure 12 Exemplary descriptions are provided for scenarios where the first device is a UE in Indirect mode. In some possible examples, in Direct mode, the above... Figure 6 , Figure 9 , Figure 12 The UE in the text can also be replaced by an access network device, such as a gNB, or, as mentioned above. Figure 6 , Figure 9 , Figure 12 The UE in the text can also be replaced by the first core network device, such as AMF, SEAF, core network element dedicated to AIoT (or IoT), etc. No all possible examples are listed here.

[0398] For example, in combination Figure 13 In terms of, with Figure 12 The generation architecture of the above parameters in the example authentication method processing flow can be described, and may include: MAC = f2(Kr, AK), XRES = f2(Kr, RAND), XRES' = f2(physical layer key, AK), or XRES' can be derived from XRES. f2 can also be replaced by algorithms such as HMAC-SHA-256, AES, ACSON, SNOW 3G, and ZUC. Figure 13The provided example uses XRES' (which can be understood as the aforementioned RES') to add authentication between the A-IoT device and the UE. Since the UE does not have Kr, but only AK and RES, the generation of RES' (or XRES') cannot be based on Kr, but on AK and / or RES.

[0399] Combination Figure 14 The authentication method provided in the foregoing embodiments will be further illustrated by example. Figure 14 In this example, taking the second device as an A-IoT device (referred to as A-IoT for simplicity), the first device as a base station (which can be either a base station or a UE), the first network device as AUSF, and the second network device as UDM and / or ARPF, it should be understood that in Figure 14 For simplicity, the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. Figure 14 The authentication method processing flow includes:

[0400] Steps 1401-1402 are the same as in the previous example. Figure 6 Steps 601 to 602 are the same and will not be repeated.

[0401] Step 1403: AUSF forwards the authentication request to UDM / ARPF. UDM / ARPF generates the first random number RAND, and then generates anonymous keys AK, MAC, XRES (i.e. the aforementioned first verification RES), and Ka' based on Kr. AK, MAC, XRES, and Ka' are then sent to AUSF.

[0402] This example uses the third intermediate key from the aforementioned embodiment, denoted as Ka'. For example, MAC = f2(Kr, AK), XRES = f2(Kr, RAND); This example uses the third intermediate key from the aforementioned embodiment, denoted as Ka'. For example, .

[0403] Alternatively, the aforementioned third intermediate key can also be calculated without using the physical layer key, for example... For example, the aforementioned third intermediate key can also be used to replace the physical layer key with the first intermediate key for calculation, for example... Various exemplary calculation methods for the third intermediate key have been described in detail in the foregoing embodiments and will not be repeated here.

[0404] Step 1404: The AUSF sends an authentication response to the base station, carrying MAC, AK, and Ka'. This authentication response can be the second message in the previous embodiment.

[0405] Step 1405: The base station sends an authentication response to the A-IoT device, carrying the MAC address and AK, but not the Ka'.

[0406] Step 1406: The A-IoT device calculates MAC', and after successfully verifying the MAC based on MAC', it confirms successful AUSF identity verification, calculates Ka', and calculates the integrity protection key KI. Additionally, in this step, the A-IoT device can also generate RES (i.e., the aforementioned first RES).

[0407] This key Ka' or KI is used to share with A-IoT devices and network entities (UE, or other network devices such as AP, smallcell, gNB, CPE, AMF, UPF, MEC, etc.).

[0408] For example, the computations performed by an A-IoT device may include at least one of the following: , MAC'=f2 (Kr, AK), RES=f2 (Kr, RAND), .

[0409] Furthermore, the A-IoT device generates a random number NONCE1 (i.e., the aforementioned third random number), and the method for generating KI after generating Ka' can be... .

[0410] For example, the fourth intermediate key that can be calculated in step 1403 above is the aforementioned fourth intermediate key. ,Right now Furthermore, both the base station and A-IoT can generate Kb based on the fourth intermediate key using the following formula. Both base stations and A-IoT can generate KI based on Kb, for example, represented as... .

[0411] In the above example, Ka', It generates replaceable XOR ⊕ algorithms, direct connection algorithms ||, KDF algorithms such as HMAC-SHA-256, f3(), etc. In addition, other optional Ka' generation parameters include A-IoT ID, NONCE, etc.

[0412] In step 1407, the A-IoT device sends an authentication confirmation message to the base station, which carries the RES. The A-IoT device can use KI to protect the integrity of the authentication confirmation message before sending it.

[0413] Step 1408: After receiving the authentication confirmation message, the base station generates KI and uses KI to perform integrity verification on the authentication confirmation message, then sends the authentication confirmation to AUSF, which carries RES. In this step, the base station can also generate Kc, for example, using the aforementioned Ka' to generate Kc. The specific processing method is the same as in the previous embodiment, and the steps are repeated.

[0414] Step 1409: After the AUSF verification RES passes, the verification of the A-IoT device is completed.

[0415] For example, in step 1407 above, the AIoT device can directly send the authentication confirmation message to AUSF, which generates KI based on the aforementioned Ka'. After the integrity verification of KI is passed, it is confirmed that RES has not been tampered with. The RES in the authentication confirmation message is verified, and after passing the verification, it can be determined that the A-IoT device has been verified.

[0416] For example, AUSF can share Ka' with a server or KMS, and the KMS and server can further generate other keys based on Ka'.

[0417] For example, in step 1404, after receiving the authentication response from AUSF, the base station generates a KI. In step 1405, the base station performs integrity protection on the authentication response message forwarded to the A-IoT device based on the KI. In step 1406, after receiving the authentication response message, the A-IoT device also generates a KI, performs integrity verification on the authentication response message, thereby completing KI negotiation and protecting the integrity of the authentication response message. In step 1406, the A-IoT device can generate a Kc. When executing step 1407, before sending the authentication confirmation message, it performs integrity protection and encryption on the message and carries a fourth random number in the authentication confirmation message. In step 1408, after receiving the authentication confirmation message, the base station generates a Kc based on the fourth random number, decrypts the authentication confirmation message, and performs integrity verification based on the KI, thereby completing key negotiation.

[0418] Figure 14 In this example, unlike previous embodiments, the third intermediate key Ka' is generated by the network side and sent to the base station or UE. The base station or UE then uses the physical layer key to generate KI and Kc. The AUSF can share Ka with the server or KMS, and the KMS and server can further generate other keys based on Ka.

[0419] It should be noted that the above Figure 14 This is an exemplary description of a scenario where the first device is a base station in Direct mode. In some possible examples, in Direct mode, the above... Figure 14The base station can also be replaced with a first core network device, such as AMF, SEAF, or any core network element dedicated to AIoT (or IoT). In some possible examples, in Indirect mode, the above... Figure 14 The base station in the text can also be replaced by the UE; not all possible examples are listed here.

[0420] For example, Figure 15 In terms of, with Figure 14 The generation architecture of the above parameters in the example authentication method processing flow can be described, and may include: , MAC = f2 (Kr, AK), XRES = f2 (Kr, RAND), .

[0421] Combination Figure 16 The generation architecture of the aforementioned keys is illustrated below. The A-IoT device and the AUSF / UDM / ARPF sides share the root key Kr, and AK can be obtained based on the root key. Both the A-IoT device and the AUSF / UDM / ARPF sides can generate Ka (i.e., Ka' in the previous example) based on Kr and the physical layer key. During the negotiation of KI and Kc between the A-IoT device and the base station, both the A-IoT device and the base station use the same method to obtain their respective Kc and KI based on Ka. Furthermore, the base station sends Ka to the KMS, thus enabling the base station, A-IoT devices, KMS, and other network elements (as in the previous example, not repeated here) to share the same Ka. Figure 16 In this context, the physical layer key is optional and is therefore represented by a dashed box. This means that in some possible examples, Ka may not be calculated using the physical layer key. The various calculation methods are the same as in the aforementioned embodiments and will not be elaborated upon further. Combined with... Figure 16 To further illustrate the key generation architecture described above, the A-IoT device and the AUSF / UDM / ARPF sides share the root key Kr, and AK can be obtained based on the root key. Both the A-IoT device and the AUSF / UDM / ARPF sides can generate Ka (i.e., Ka' in the previous example) based on Kr and the physical layer key (optionally). During the negotiation of KI and Kc between the A-IoT device and the UE, both sides use the same method to obtain their respective Kc and KI based on Ka. Additionally, the UE sends Ka to the KMS, thus enabling the UE, A-IoT device, KMS, and other network elements (as in the previous example, not repeated here) to share the same Ka. Combined with... Figure 16To illustrate the key generation architecture described above, the A-IoT device shares a root key Kr with the AUSF / UDM / ARPF side and can obtain AK based on the root key. Both the A-IoT device and the AUSF / UDM / ARPF side can generate Ka (i.e., Ka' in the previous example) based on Kr and the physical layer key (optionally). During the negotiation of KI and Kc between the A-IoT device and the first core network device, both sides use the same method to obtain their respective Kc and KI based on Ka. Furthermore, the first core network device sends Ka to the KMS, thus enabling the first core network device, the A-IoT device, the KMS, and other network elements (as in the previous example, without further elaboration) to share the same Ka.

[0422] Combination Figure 17 The authentication method provided in the foregoing embodiments will be further illustrated by example. Figure 17 In this example, taking the second device as an A-IoT device (referred to as A-IoT for simplicity), the first device as an Authenticator, and the first network device as an AS, the processing flow includes:

[0423] The A-IoT device (i.e., A-IoT) and the AS share a unique and non-repeating root key Kr, which can be a pairwise master key (PMK) generated after the AS and A-IoT authenticate each other. The AS sends the PMK to the Authenticator in the authentication response message, and the A-IoT and the Authenticator share the PMK (in the aforementioned embodiment, the PMK is referred to as the third intermediate key).

[0424] Step 1701: The A-IoT device sends an authentication request to the Authenticator, carrying the A-IoT ID.

[0425] Step 1702: The Authenticator forwards the authentication request to the AS, carrying the A-IoT ID.

[0426] Step 1703: AS generates the first random number RAND, and then generates the anonymous key AK, MAC, and XRES (i.e. the aforementioned first verification RES) based on Kr.

[0427] For example, Figure 17 In general, the methods for generating the above parameters include: MAC = f2(Kr, AK), XRES = f2(Kr, RAND). f2 can also be replaced by algorithms such as HMAC-SHA-256, AES, ACSON, SNOW 3G, and ZUC.

[0428] Step 1704: AS sends an authentication response to Authenticator, carrying AK, MAC, and PMK. This authentication response may also carry the A-IoT ID. This authentication response is the first message in the aforementioned embodiment.

[0429] Step 1705: The Authenticator forwards an authentication response to the A-IoT device, carrying the AK and MAC addresses. The authentication response message in this step is the second message from the aforementioned embodiment.

[0430] Step 1706: After receiving the authentication response message, the A-IoT device calculates MAC'. After successfully verifying the MAC based on MAC', it determines that the AS identity has been successfully verified and calculates RES. The RES in this step is the first RES in the aforementioned embodiment.

[0431] For example, the computation of an AIoT device may include: , MAC'=f2(Kr,AK), RES=f2(Kr,RAND).

[0432] Step 1707: The A-IoT device calculates the encryption key Ks.

[0433] For example, this step may include: the A-IoT device generating a third random number, NONCE1; and then based on the formula... Calculate the integrity protection key. The XOR ⊕ algorithm used for Ks generation can also be direct ||, KDF algorithms such as HMAC-SHA-256, etc. Other optional Ks generation parameters include A-IoT ID, etc.

[0434] Step 1708: The A-IoT device sends an authentication confirmation to the Authenticator, which carries RES, NONCE1 (i.e., the third random number in the aforementioned embodiment). The authentication confirmation message in this step is the third message in the aforementioned embodiment.

[0435] Step 1709: After receiving the authentication confirmation message, the Authenticator generates Ks as the encryption key.

[0436] Step 1710: The Authenticator sends an authentication confirmation to the AS, which carries the RES.

[0437] Step 1711: The Authenticator sends an authentication response to the A-IoT device. This authentication response can be the response message in the aforementioned embodiment, i.e., the response message in response to the third message.

[0438] Additionally, step 1712 can be performed on the AS side to verify RES. The specific method for AS to verify RES is the same as in the aforementioned embodiments and will not be repeated here.

[0439] Combination Figure 18 Regarding the above Figure 17 The generation architecture for each key is illustrated below. The root key Kr is shared between the A-IoT device and the AS side; AK can be obtained based on Kr. In the negotiation of Ks, both the A-IoT device and the authentication device use the same method to combine the physical layer key and PMK to obtain their respective Ks. Figure 18 In this context, the physical layer key is optional and is therefore represented by a dashed box. In other words, in some possible examples, Ks may not be calculated using the physical layer key, which will not be elaborated further.

[0440] In some possible implementations, the authentication method provided in this embodiment may also be triggered by a first device or the network side.

[0441] Alternatively, the authentication process can be triggered by the server.

[0442] The processing of the first network device may include: the first network device receiving a trigger message from the server, the trigger message carrying the identifier of the second device and / or the identifier of the device group to which the second device belongs.

[0443] The aforementioned server can be a server with AIoT service capabilities, such as an AF, other servers, or A-IoT network elements; there are no restrictions on this.

[0444] After receiving the trigger message from the server, the first network device can perform the process of sending the first message in the aforementioned embodiment.

[0445] Optionally, the trigger message mentioned above carries only the identifier of the second device. Correspondingly, the first message mentioned above carries only the identifier of the second device. This first message can also be called an authentication request (or authentication request message). Subsequently, the second device and the first device can perform the same processing as in the previous embodiments, such as interacting with the second message and the third message, which will not be repeated here.

[0446] Optionally, the trigger message carries the device group identifier of the second device. That is, the trigger message can carry a group ID. In this case, the aforementioned first message carries the identifier of the device group to which the second device belongs. In this case, the first message can also be called an authentication request (or authentication request message).

[0447] Furthermore, the first message also carries the identifier of the device group to which the second device belongs, and the second message is used to request authentication; after receiving the first message, the first device sends a second message to the second device. This sending of the second message by the first device to the second device may include: the first device generating a fourth random number; the first device obtaining an encryption key based on the fourth random number, the physical layer key, and key generation parameters; the first device encrypting the group key based on the encryption key to obtain an encrypted group key; and the first device sending a second message to the second device, the second message also carrying the encrypted group key and the fourth random number.

[0448] The method for generating the encryption key described above is the same as that in the previous embodiments, and will not be described again.

[0449] Optionally, the first device may also generate the aforementioned group key. The generation method of the group key may include one of the following: the first device uses a third calculation method to calculate the group key based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the identifier of each device, and the third random number.

[0450] The first device uses the third calculation method to calculate the group key based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the identifier of each device, and the third random number;

[0451] The first device uses the third calculation method to calculate the group key based on the identifier of the first device, the intermediate key of each device in the group to which the second device belongs, the identifier of each device, and the third random number;

[0452] The first device uses the third calculation method to calculate the group key based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the identifier of each device, and the third random number;

[0453] The first device uses a third calculation method to calculate the group key based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the first key of each device, the identifier of each device, and the third random number;

[0454] The first device uses the third calculation method to calculate the group key based on the identifier of the first device, the intermediate key of each device in the group to which the second device belongs, the first key of each device, the identifier of each device, and the third random number;

[0455] The first device uses the third calculation method to calculate the group key based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the first key of each device, the identifier of each device, and the third random number.

[0456] The third calculation method described above is the same as that in the previous embodiments and will not be repeated. In the following examples, KDF is used as the third calculation method for illustration; other methods that can be included in the third calculation method for calculating the group key are not exhaustively listed. The third random number can be generated by the first device, and its generation method is not limited.

[0457] For example, the intermediate key of each device can be the second intermediate key, the third intermediate key, or the fourth intermediate key of each device. The calculation methods of the second, third, and fourth intermediate keys of each device are the same as those of the aforementioned second, third, and fourth intermediate keys, so they will not be repeated in this embodiment.

[0458] For example, the intermediate key of each device described above can also be a fourth intermediate key for each device, that is, an intermediate key obtained in a different way than in the previous embodiments. This fourth intermediate key can be calculated using a third calculation method based on key generation parameters and the device's identifier. The key generation parameters include an anonymous key and a first random number. For instance, the fourth intermediate key of any of the devices described above can be calculated using the following formula: Ka = f3(AK, RAND, A-IoT ID), where A-IoT ID is the device's identifier. It should be understood that the above is merely an illustrative example, and the methods for generating the intermediate key for each device are not exhaustively listed here.

[0459] Optionally, taking the first key of each device as the physical layer key of each device as an example, the first device uses a third calculation method to calculate the group key based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the physical layer key of each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula:

[0460] ;

[0461] Where K-Group represents the group key, and KDF() represents the KDF computation function. ~ This represents the anonymous key for each device. An XOR operation is performed on the anonymous keys of each device, where i represents the i-th device in the device group, and i is a positive integer. "Indicates direct connection calculation, ~ This represents the physical layer key for each device. An XOR operation is performed on the physical layer keys of each of these devices. This represents the identifier of each device; UEID is the identifier of the UE if the first device is a UE; base station ID is the identifier of the base station if the first device is a base station (in some possible examples, the base station ID can also be represented as base station IE); NONCE1 represents a third random number. Optionally, in the above formula, XOR calculation can be replaced by direct calculation, and direct calculation can also be replaced by XOR calculation; Optionally, It can be replaced by using XOR calculation or direct connection calculation for the identifier of each device. All of the above possible calculation methods are within the protection scope of this embodiment and will not be exhaustively listed.

[0462] Optionally, taking the first key of each device as the first intermediate key of each device as an example, the first device calculates the group key using a third calculation method based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the first intermediate key of each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula:

[0463] ;

[0464] in, ~ This represents the first intermediate key for each device. The meanings of the remaining parameters are the same as in the previous example and will not be exhaustively listed.

[0465] Optionally, the group key can be calculated using a third calculation method based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the identifier of each device, and the third random number. That is, the group key is calculated without using the first key, and can be expressed by the following formula:

[0466] The meanings of the parameters in the formula are the same as in the previous example, and will not be repeated here.

[0467] Optionally, the first device calculates the group key using the third calculation method based on the identifier of the first device, the anonymous key for each device in the group to which the second device belongs, the intermediate key for each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula:

[0468] ;

[0469] Where K-Group represents the group key, and KDF() represents the KDF computation function. ~ This represents the anonymous key for each device. An XOR operation is performed on the anonymous keys of each device, where i represents the i-th device in the device group, and i is a positive integer. "Indicates direct connection calculation, ~ This represents the intermediate key for each device. An XOR operation is performed on the intermediate keys of each device. The meanings of other contents in the formula are the same as in the previous embodiments and will not be repeated.

[0470] Optionally, taking the first key of each device as the physical layer key of each device as an example, the first device calculates the group key based on the identifier of the first device, the intermediate key of each device in the group to which the second device belongs, the physical layer key of each device, the identifier of each device, and the third random number using the third calculation method. The calculation can be performed using the following formula:

[0471] ;

[0472] Where K-Group represents the group key, and KDF() represents the KDF computation function. ~ This represents the physical layer key of each device. An XOR operation is performed on the physical layer keys of each device, where i represents the i-th device in the device group, and i is a positive integer. "Indicates direct connection calculation, ~ This represents the intermediate key for each device. An XOR operation is performed on the intermediate keys of each device. The meanings of other contents in the formula are the same as in the previous embodiments and will not be repeated.

[0473] Optionally, taking the first key of each device as the first intermediate key of each device as an example, the first device calculates the group key based on the identifier of the first device, the intermediate key of each device in the group to which the second device belongs, the first intermediate key of each device, the identifier of each device, and the third random number using the third calculation method. The calculation can be performed using the following formula:

[0474] ;

[0475] The meanings of each part of the formula are the same as those in the aforementioned embodiments, and will not be repeated.

[0476] Optionally, taking the first key of each device as the physical layer key of each device as an example, the first device calculates the group key using the third calculation method based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the physical layer key of each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula:

[0477] The meanings of each item in the formula are the same as those in the aforementioned embodiments, and will not be repeated.

[0478] In the above formula, XOR calculation can be replaced by direct connection calculation, and direct connection calculation can also be replaced by XOR calculation; optionally, It can be replaced by using XOR calculation or direct connection calculation for the identifier of each device. All of the above possible calculation methods are within the protection scope of this embodiment and will not be exhaustively listed.

[0479] Optionally, taking the first key of each device as the first intermediate key of each device as an example, the first device calculates the group key using the third calculation method based on the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the first intermediate key of each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula:

[0480] The meanings of each item in the formula are the same as those in the aforementioned embodiments, and will not be repeated.

[0481] Optionally, the first device may calculate the group key in one of the following ways: the first device uses a third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the identifier of each device, and the third random number;

[0482] The first device uses the third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the identifier of each device, and the third random number;

[0483] The first device uses the third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the intermediate key of each device in the group to which the second device belongs, the physical layer key of each device, the identifier of each device, and the third random number;

[0484] The first device uses the third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the identifier of each device, and the third random number;

[0485] The first device uses a third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the first key of each device, the identifier of each device, and the third random number;

[0486] The first device uses the third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the identifier of each device, and the third random number;

[0487] The first device uses the third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the intermediate key of each device in the group to which the second device belongs, the first key of each device, the identifier of each device, and the third random number;

[0488] The first device uses the third calculation method to calculate the group key based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the intermediate key of each device, the first key of each device, the identifier of each device, and the third random number.

[0489] This example mainly adds a device group key to the calculation of the aforementioned generation group keys. The following only uses variations of some formulas as examples for illustration, and will not exhaustively list all the aforementioned formulas:

[0490] Optionally, taking the first key as the physical layer key as an example, the first device calculates the group key using the third calculation method based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the physical layer key of each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula: ;

[0491] Where K-Group represents the group key, and KDF() represents the KDF computation function. ~ This represents the anonymous key for each device. An XOR operation is performed on the anonymous keys of each device, where i represents the i-th device in the device group, and i is a positive integer. "Indicates direct connection calculation, ~ This represents the physical layer key for each device. An XOR operation is performed on the physical layer keys of each of these devices. This represents the identifier of each device: UEID is the identifier of the UE if the first device is a UE; Base Station ID is the identifier of the base station if the first device is a base station (in some possible examples, the Base Station ID can also be represented as Base Station IE); Group ID is the identifier of the device group; and NONCE1 represents a third random number. Optionally, in the above formula, XOR calculation can be replaced by direct calculation, and direct calculation can also be replaced by XOR calculation; Optionally, It can be replaced by using XOR calculation or direct connection calculation for the identifier of each device. All of the above possible calculation methods are within the protection scope of this embodiment and will not be exhaustively listed.

[0492] Optionally, taking the first key as the first intermediate key as an example, the first device calculates the group key using a third calculation method based on the identifier of the device group, the identifier of the first device, the anonymous key of each device in the group to which the second device belongs, the first intermediate key of each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula: ;

[0493] The meanings of each element in the formula are the same as in the aforementioned embodiments, and will not be repeated here.

[0494] Optionally, the first device calculates the group key using the third calculation method based on the identifier of the device group, the identifier of the first device, the anonymous key for each device in the group to which the second device belongs, the intermediate key for each device, the identifier of each device, and the third random number. The calculation can be performed using the following formula:

[0495] ;

[0496] Where K-Group represents the group key, and KDF() represents the KDF computation function. ~ This represents the anonymous key for each device. An XOR operation is performed on the anonymous keys of each device, where i represents the i-th device in the device group, and i is a positive integer. "Indicates direct connection calculation, ~ This represents the intermediate key for each device. An XOR operation is performed on the intermediate keys of each device. The meanings of other contents in the formula are the same as in the previous embodiments and will not be repeated.

[0497] The processing of the second device is as follows: the second device decrypts the encrypted group key based on the encryption key to obtain the group key, which is used to encrypt the data transmitted between the second device and the first device.

[0498] Furthermore, the second message is used to request authentication, and the second message also carries an encrypted group key and a fourth random number; the second device sends a third message to the first device, including: the second device obtaining an encryption key based on the fourth random number and key generation parameters; the second device decrypting the encrypted group key based on the encryption key to obtain the group key; the second device sending a third message to the first device, the third message being a message encrypted based on the group key.

[0499] It should be noted that after receiving the second message, the aforementioned second device will still perform the aforementioned calculation and verification of MAC, and the specific processing method is the same as that in the aforementioned embodiment.

[0500] Optionally, the second device can further generate an integrity protection key to perform integrity protection processing on the third message. The processing method is the same as in the aforementioned embodiments and will not be repeated here. It should be noted that in this embodiment, the aforementioned fourth intermediate key can also be used to generate the integrity protection key, and then the second calculation method is used to calculate the integrity protection key based on the second intermediate key, the third random number, and the physical layer key. The same processing method is also used on the first device side to generate the integrity protection key, and will not be repeated here.

[0501] Optionally, the first device may send the intermediate key and group key of each of the above devices to the key management function entity so that the key management function entity can use them for mobility management.

[0502] Combination Figure 19 The authentication method provided in the foregoing embodiments will be described by way of example. Figure 19 In this example, the second device is an A-IoT device (referred to as A-IoT for simplicity), the first device is a UE / base station, and the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. Figure 19 The authentication method processing flow includes:

[0503] Step 1901: The server sends a trigger message, which may carry the AIoT ID and / or Group ID.

[0504] Step 1902: After receiving the trigger message, AUSF requests an authentication vector from UDM / ARPF. UDM / ARPF generates the authentication vector and sends it to AUSF. The authentication vector may include MAC, AK, and XRES.

[0505] Step 1903: AUSF sends an authentication request to the UE / base station, carrying the MAC, AK, A-IoT ID, and Group ID.

[0506] Step 1904: The UE / base station generates the Ka of each device in the device group and then generates the group key (K-Group).

[0507] The Ka mentioned above may refer to the intermediate key of each device in the foregoing embodiments. The detailed description of the intermediate key is the same as that in the foregoing embodiments, and the generation of the group key is also the same as that in the foregoing embodiments, so it will not be described again.

[0508] Optionally, the UE / base station sends the Ka of each device and the group key to the KMS.

[0509] Step 1905: The UE / base station sends an authentication request (which may include AK, MAC, and encrypted K-Group).

[0510] Step 1906: After receiving the authentication response, the A-IoT device calculates MAC'. Upon successful MAC verification based on MAC', it confirms successful AUSF identity verification, calculates RES, and then calculates Ka and KI. For example, , MAC' = f2 (Kr, AK), RES = f2 (Kr, RAND), Ka=f3 (AK, RAND, A-IOT ID), Where MAC' is the verification MAC, Ka is the intermediate key of the aforementioned device, and KI is the integrity protection key generated by the AIoT device.

[0511] In step 1905 above, the authentication request may also carry a fourth random number. In step 1906, the A-IoT device may also obtain an encryption key based on the fourth random number, the physical layer key, and the key generation parameters. The second device decrypts the encrypted group key based on the encryption key to obtain the group key.

[0512] Step 1907: The A-IoT device sends an authentication response (carrying RES), which can be fully guaranteed by KI.

[0513] In this step, the authentication response can also be a message encrypted based on the group key.

[0514] In step 1908, after generating the KI, the UE / base station verifies the integrity of the authentication response. Upon successful verification, it sends an authentication confirmation to the AUSF, which carries the RES. The KI generated by the UE / base station can be called the integrity protection key. The method by which the UE / base station generates the KI is the same as that of the aforementioned AIoT device and will not be repeated. In this step, if the authentication response is still a message encrypted based on the group key, the UE / base station can also use the group key to decrypt the authentication response and perform verification and integrity protection processes, which will not be repeated.

[0515] Additionally, step 1909 can be performed on the AUSF side to verify RES. The specific method for AUSF to verify RES is the same as in the aforementioned embodiments and will not be repeated here.

[0516] Optionally, the authentication process can be triggered by the first device.

[0517] The processing of the first device may include: the first device sending an authentication request to the first network device, the authentication request carrying the identifier of the second device and / or the identifier of the device group to which the second device belongs. Correspondingly, the processing of the first network device may include: the first network device receiving an authentication request from the first device, the authentication request carrying the identifier of the second device and / or the identifier of the device group to which the second device belongs.

[0518] Furthermore, after receiving the authentication request, the first network device can execute the process of sending the first message as described in the previous embodiment. Unlike the previous embodiment, in this embodiment, the first message can also carry the identifier of the device group to which the second device belongs. Additionally, before sending the authentication request to the first network device, the first device can also send a trigger message to the second device (or each device in the device group to which the second device belongs), and this trigger message can carry the identifier of the second device and / or the identifier of the device group to which the second device belongs.

[0519] In this scenario, after receiving the first message, the first device sends a second message to the second device to request authentication. The processing of the second message by the second device can be the same as in the aforementioned embodiments, and the processing of the second device sending the third message to the first device can also be the same, so it will not be elaborated further.

[0520] The processing after the first device receives the third message may further include: the first device generating a fourth random number; the first device obtaining an encryption key based on the fourth random number, the physical layer key, and key generation parameters; the first device encrypting the group key based on the encryption key to obtain an encrypted group key; and the first device sending a response message to the second device, the response message responding to the third message, the response message carrying the fourth random number and the encrypted group key, the group key being used to encrypt data transmitted between the second device and the first device.

[0521] The generation methods for the encryption keys and group keys are the same as those in the previous embodiments, and will not be repeated here.

[0522] The processing by the second device may include: the second device receiving a response message from the first device, the response message being in response to the third message; the second device verifying the response message based on the integrity protection key to obtain a verification result; if the verification result indicates that the integrity verification of the response message is successful, the second device obtaining a fourth random number from the response message; the second device obtaining an encryption key based on the fourth random number, the physical layer key, and key generation parameters; the second device obtaining an encrypted group key from the response message; and the second device decrypting the encrypted group key based on the encryption key to obtain the group key, the group key being used to encrypt data transmitted between the second device and the first device.

[0523] The method by which the second device obtains the encryption key is the same as in the previous embodiment. After the second device obtains the key, it can use the key to encrypt the data sent and decrypt the data received. No further limitations are imposed here.

[0524] Combination Figure 20 The authentication method provided in the foregoing embodiments will be described by way of example. Figure 20 In this example, the second device is an A-IoT device (referred to as A-IoT for simplicity), the first device is a UE / base station, and the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. Figure 20 The authentication method processing flow includes:

[0525] Step 2001: The UE / base station sends a trigger message to the A-IoT device, which may carry the AIoT ID and / or Group ID.

[0526] Step 2002: The UE / base station sends an authentication request to the AUSF, which may carry the AIoT ID and / or Group ID.

[0527] The processing in steps 2003 to 2005 is the same as described above. Figure 19 Steps 1902 to 1904 are the same and will not be repeated.

[0528] Step 2006: The UE / base station sends an authentication request (which may include AK and MAC addresses).

[0529] Step 2007: After receiving the authentication response, the A-IoT device calculates MAC'. Upon successful MAC verification based on MAC', it confirms successful AUSF identity verification, calculates RES, and then calculates Ka and KI. For example, , MAC' = f2 (Kr, AK), RES = f2 (Kr, RAND), Ka=f3 (AK, RAND, A-IOT ID), Where MAC' is the verification MAC, Ka is the intermediate key of the aforementioned device, and KI is the integrity protection key generated by the AIoT device.

[0530] Step 2008: The A-IoT device sends an authentication response (carrying RES), which can be fully authenticated using KI.

[0531] Step 2009: After generating the KI, the UE / base station verifies the integrity of the authentication response. Upon successful verification, it sends an authentication confirmation to the AUSF, which carries the RES. The KI generated by the UE / base station can be called the integrity protection key. The method by which the UE / base station generates the KI is the same as that of the aforementioned AIoT device and will not be repeated.

[0532] Additionally, step 2010 can be executed on the AUSF side to verify RES. The specific method for AUSF to verify RES is the same as in the aforementioned embodiments and will not be repeated here.

[0533] In step 2011, the UE / base station sends a response message to the A-IoT device, which may carry the encrypted K-Group (group key). Specifically, the UE / base station may also obtain an encryption key based on the fourth random number, the physical layer key, and key generation parameters; and encrypt the group key based on the encryption key to obtain the encrypted group key. Additionally, the response message may also carry the fourth random number.

[0534] Correspondingly, the A-IoT device can also obtain an encryption key based on the fourth random number, the physical layer key, and the key generation parameters; the second device decrypts the encrypted group key based on the encryption key to obtain the group key.

[0535] It should be noted that the above Figure 19 , Figure 20 Exemplary descriptions are provided for scenarios where the first device is a UE or a base station in either Indirect mode or Direct mode, respectively. In some possible examples, in Direct mode, the above... Figure 19 , Figure 20 The UE / base station can also be replaced by the first core network equipment, such as AMF, SEAF, core network elements dedicated to AIoT (or IoT), etc. Not all possible examples are listed here.

[0536] As can be seen, by adopting the above authentication method, the second device can receive authentication parameters and then directly calculate the verification MAC based on the authentication parameters and the root key shared with the core network device. Based on the verification MAC, the core network device is then authenticated. In this way, while ensuring the security of the authentication process between the second device and the core network device, the second device avoids performing complex calculations, improving its processing efficiency, and is particularly suitable for devices with lower computing power.

[0537] Figure 21 This is a schematic flowchart illustrating an authentication method according to an embodiment of this application. The method includes at least a portion of the following.

[0538] S2110, The first device receives a first message from the first network device, the first message carrying authentication parameters and the identifier of the second device;

[0539] S2120, The first device sends a second message to the second device, the second message carrying authentication parameters;

[0540] S2130. The first device receives a third message from the second device, the third message carrying a first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices;

[0541] S2140, the first device sends a fourth message to the first network device, the fourth message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0542] Figure 22 This is a schematic flowchart of an authentication method according to another embodiment of this application. The method includes at least a portion of the following.

[0543] S2210, The second device receives a second message from the first device, the second message carrying authentication parameters;

[0544] S2220. The second device calculates the first RES based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and all core network side devices.

[0545] S2230, the second device sends a third message to the first device, the third message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0546] Figure 23 This is a schematic flowchart of an authentication method according to another embodiment of this application. The method includes at least a portion of the following.

[0547] S2310, The first network device sends a first message to the second device, the first message carrying authentication parameters and the identifier of the second device.

[0548] S2320. The first network device receives a fourth message from the first device, the fourth message carrying the first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices.

[0549] S2330. If the first RES is the same as the first verification RES, the first network device determines that the second device has passed authentication.

[0550] The definitions of the core network side device, the first device, the one or more core network devices, the first network device, and the second network device are the same as those in the previous embodiments, and therefore will not be repeated.

[0551] Optionally, the authentication parameters include one of the following: an anonymous key, a first random number; the second device calculates the first RES based on the authentication parameters and the root key, including one of the following: the second device calculates the first RES based on the first random number and the root key using the first calculation method; the second device calculates the first RES based on the anonymous key and the root key using the first calculation method.

[0552] Accordingly, the processing of the first network device also includes one of the following: the first network device receives the authentication parameters and the first verification RES sent by the second network device; the first network device calculates the first verification RES based on the root key and the authentication parameters using the first calculation method.

[0553] In this embodiment, the methods for generating the first RES and the first verification RES are the same as those in the previous embodiments, and will not be described again.

[0554] Optionally, the method further includes one of the following: the first network device receives the authentication parameters and the first verification RES sent by the second network device; the first network device calculates the first verification RES based on the root key and the authentication parameters using the first calculation method.

[0555] Optionally, the third message further carries a second RES, which is used by the first device to authenticate the second device; the method further includes one of the following: the second device calculates the second RES based on the anonymous key and the physical layer key using a first calculation method, wherein the physical layer key is a key shared between the second device and the first device; the second device calculates the second RES based on the first random number and the physical layer key using the first calculation method; the second device calculates the second RES based on the first RES and the physical layer key using the first calculation method.

[0556] The processing of the first device further includes: if the second verification RES is the same as the second RES, the first device determines that the second device has passed authentication.

[0557] The method further includes one of the following: the first device calculates the second verification RES using a first calculation method on an anonymous key and a physical layer key, wherein the physical layer key is a key shared between the second device and the first device; the first device calculates the second verification RES using a first calculation method on a first random number and a physical layer key; the first device calculates the second verification RES using a first calculation method on a first verification RES and a physical layer key. The first message also carries the first verification RES.

[0558] In this embodiment, the methods for generating the second RES and the second verification RES are the same as those in the previous embodiments, and will not be described again.

[0559] The authentication method provided in this embodiment differs from the previous embodiments in that it does not perform MAC verification. Apart from omitting the calculation of MAC and MAC verification, the detailed descriptions of the second, third, first, and fourth messages, as well as the processes for negotiating the integrity protection key, encryption key, generating and transmitting the group key between the second and first devices, are all the same as in the previous embodiments and will not be repeated here.

[0560] As can be seen, by adopting the above authentication method, the first device can send authentication parameters to the second device, enabling the second device to directly calculate the first RES based on the authentication parameters and the root key shared with the core network side device. The first RES is then sent to the first network device through the first device, allowing the core network side to authenticate the second device. This ensures security while avoiding complex calculations on the second device side, improving its processing efficiency, and is particularly suitable for devices with lower computing power.

[0561] Figure 24This is a schematic flowchart illustrating an authentication method according to an embodiment of this application. The method includes at least a portion of the following.

[0562] S2410, The first device sends a second message to the second device, the second message carrying authentication parameters;

[0563] S2420, The first device receives a third message from the second device, the third message carrying a second RES, the second RES being related to the authentication parameters and the first key;

[0564] S2430, The first device generates a second verification RES based on the authentication parameters and the first key;

[0565] S2440. If the second verification RES is the same as the second verification RES, the first device determines that the second device has passed authentication.

[0566] Figure 25 This is a schematic flowchart of an authentication method according to another embodiment of this application. The method includes at least a portion of the following.

[0567] S2510, The second device receives a second message from the first device, the second message carrying authentication parameters;

[0568] S2520, The second device calculates the second RES based on the authentication parameters and the first key, wherein the first key is associated with the first device;

[0569] S2530, the second device sends a third message to the first device, the third message carrying the second RES, the second RES being used by the first device to authenticate the second device.

[0570] The definitions of the core network side device, the first device, the one or more core network devices, the first network device, and the second network device are the same as those in the previous embodiments, and therefore will not be repeated.

[0571] Optionally, the second device calculates the second RES based on the authentication parameters and the physical layer key, including one of the following: the second device calculates the second RES based on the anonymous key and the physical layer key using a first calculation method, wherein the physical layer key is a key shared between the second device and the first device; the second device calculates the second RES based on the first random number and the physical layer key using the first calculation method; or the second device calculates the second RES based on the first RES and the physical layer key using the first calculation method.

[0572] The first device generates a second verification RES, including one of the following: the second device calculates the second RES based on the anonymous key and the physical layer key using a first calculation method, wherein the physical layer key is a key shared between the second device and the first device; the second device calculates the second RES based on the first random number and the physical layer key using the first calculation method; or the second device calculates the second RES based on the first RES and the physical layer key using the first calculation method.

[0573] In this embodiment, the methods for generating the second RES and the second verification RES are the same as those in the previous embodiments, and will not be described again.

[0574] The authentication method provided in this embodiment differs from the previous embodiments in that it does not perform MAC verification or the first RES verification. Furthermore, the detailed descriptions of the second, third, first, and fourth messages, as well as the processes of negotiating the integrity protection key, negotiating the encryption key, generating and transmitting the group key between the second and first devices, are the same as in the previous embodiments, and therefore will not be repeated.

[0575] As can be seen, by adopting the above authentication method, the second device can receive authentication parameters and then directly calculate the first RES based on the authentication parameters and the root key shared with the core network side device. This first RES is then sent to the first network device through the first device, enabling the core network side to authenticate the second device. In this way, while ensuring security, the second device avoids performing complex calculations, improving its processing efficiency, and is particularly suitable for devices with lower computing power.

[0576] Finally, the beneficial effects of the solution provided in this embodiment will be explained in conjunction with relevant technologies.

[0577] Ambient IoT is a new type of IoT terminal researched in 3GPP R19. It is an IoT device powered by energy harvesting, with no battery or limited energy storage capacity. The device cost is extremely low, but computing power is extremely limited. Currently, there are two network architectures in the industry, which can be summarized as Direct mode and Indirect mode. (See [link to relevant documentation]). Figure 26 As shown, Figure 26 The above shows the direct connection mode, in which the AIoT device directly connects to the access network device (such as a base station) on the network side, and then the base station connects to the core network and then to the AIoT AF; Figure 26 The image below shows the non-direct connection mode, where the AIoT device accesses the base station through other terminal devices (such as relay UE or proxy UE), and then accesses the 5G core network and AIoTAF through the base station.

[0578] In related technologies, a UE must undergo authentication and key negotiation processes to successfully access a 5G network and use network resources. The network authorizes the UE to use network resources and services based on the authentication result. The 3GPP security series standards define the 5G AKA process and the cryptographic algorithms used. The authentication and authorization credentials used in the UE's AKA process are the symmetric root key K, which is centrally stored on the network side by the UDM / ARPF network elements of the core network. Each authorization requires the acquisition of authorization credentials in the UDM, and the corresponding authentication calculation is performed by the core network.

[0579] Regarding the above AKA process, as follows: Figure 27 As shown, it may include:

[0580] S2701. Upon receiving the authentication request, the UDM / ARPF generates an AV (Authentication Vector). Specifically, the UDM / ARPF creates a 5G HE AV (Home Environment Authentication Vector), where the Authentication Management Field (AMF) separator is set to "1". Then, the UDM / ARPF should derive the KAUSF (Key Authentication Server Function) and calculate XRES* (Expected Response). Finally, the UDM / ARPF should create the 5G HE AV from RAND (Random number), AUTN (Authentication Token), XRES*, and KAUSF. S2702. The UDM should return the 5G HE AV to the AUSF. S2703. The AUSF should temporarily store the XRES* along with the received SUCI or SUPI. S2704. The AUSF should generate a 5G AV based on the 5G HE AV received from the UDM / ARPF, calculate HXRES* from XRES* and KSEAF from KAUSF, replace XRES* with HXRES* in the 5G HE AV, and replace KAUSF with KSEAF. S2705. The AUSF removes KSEAF and returns the 5G SE AV to the SEAF. S2706. The SEAF sends RAND and AUTN to the UE. S2707. The USIM calculates the response RES. The USIM should return RES, CK, and IK to the ME. Then the ME should calculate RES* from RES. S2708. The UE returns RES* to the SEAF. S2709. The SEAF calculates HRES* from RES* and compares HRES* and HXRES*. If they match, from the perspective of the serving network, the SEAF should consider authentication successful. Otherwise, the SEAF should consider authentication failed and indicate the failure to the AUSF. S2710. SEAF sends the RES* received from the UE to AUSF. S2711. AUSF compares the received RES* with the stored XRES*. If RES* and XRES* are equal, AUSF should consider authentication successful. AUSF should notify UDM of the authentication result. S2712. AUSF instructs SEAF to verify success from the home network's perspective.

[0581] Figure 28 The authentication architecture corresponding to the above processing flow, combined with Figure 28It can be seen that the calculation methods for each parameter in the above processing flow can include: anonymous key AK = f5K (RAND), retrieval sequence number SQN = (SQN * AK) * AK, XMAC = f1K (SQN || RAND || AMF), RES = f2K (RAND), CK = f3K (RAND), IK = f4K (RAND), AK = f5K (RAND); functions f1~f5 are the MILENAGE cryptographic algorithms defined by the ETSI SAGE group. For example, the method for generating the KAUSF used in the above process can use the following parameters to form the KDF input and calculate the KAUSF: FC = 0x6A, P0 = serving network name, L0 = length of the serving network name, P1 = SQN AK. L1 = length of SQN AK (i.e., 0x00 0x06). The input key KEY should be equal to the concatenated CK || CK. It can be seen that the parameter calculations in the above process are quite complex.

[0582] Combination Figure 29 In the above processing flow, the UE and the network side need to perform 8 KDF calculations to obtain the final encryption key KE2Menc and integrity protection key KE2Eint. Therefore, the 5G AKA and key architecture is relatively complex and is not suitable for security authentication of A-IoT devices, nor does it support authentication and key negotiation between A-IoT devices and UEs.

[0583] In related technologies, RFID systems typically consist of a reader and tags, and can operate in different frequency bands. Tags can be categorized as passive, active, or semi-active based on their power supply method. For passive tags, the coupling method with the reader is divided into near-field coupling and far-field coupling. Near-field coupling relies on induction, meaning that changes in the tag coil current caused by mutual inductance between the reader and the tag can be detected by the reader; far-field coupling relies on backscatter communication.

[0584] In related technologies, two-way authentication between the reader and the tag may include: 1. The reader generates a random number. and will Send to the tag. 2: The tag receives the data. Then, random numbers are also generated locally. Tags utilize hash functions and PSK pairs. Calculated (Message integrity check code). Finally, , , Send to the reader / writer. 3: The reader / writer will receive... With local A comparison is performed; if they are not equal, the comparison is ignored; if they are equal, the reader / writer uses the hash function and PSK to perform the comparison. Calculated ,Compare and If they are not equal, ignore them; if they are equal, the reader's authentication tag is valid, and the reader continues to use the hash function and PSK. calculate Finally , Send to the tag. 4: The tag will receive... With local Perform a comparison; if they are not equal, ignore them; if they are equal, use a hash function and PSK to compare them. calculate , will receive With local calculation A comparison is performed; if they are not equal, the result is ignored; if they are equal, the tag authentication reader is valid, and the tag will return the authentication result to the reader. 5: If the tag and reader need to communicate securely, they will each communicate through... Export the session key. It is a key derivation algorithm.

[0585] The above analysis shows that the f1-f5 and KDF functions used in the AKA authentication and key negotiation processes of related technologies have high computational complexity and complex key architectures, making them unsuitable for security authentication of A-IoT devices and failing to support authentication and key negotiation between A-IoT devices and UEs. Furthermore, authentication and key negotiation between tags and readers cannot support authentication and key negotiation between A-IoT devices and the network. In contrast to the aforementioned related technologies, the various embodiments provided in this application can achieve mutual authentication between the second device and the core network side device, as well as mutual authentication between the second device and the first device. The second device can directly use the authentication parameters sent from the network side and its own root key to perform authentication processing, ensuring security while reducing the computational requirements of the second device. Additionally, in the various embodiments provided in this application, the negotiation of integrity protection keys and encryption keys does not require multiple complex calculations; it only requires physical layer keys, anonymous keys, random numbers, etc., making it more suitable for devices with lower computing power.

[0586] Figure 30This is a schematic diagram of the composition structure of a first device according to an embodiment of this application, including:

[0587] The first communication unit 3010 is configured to receive a first message from a first network device, the first message carrying a MAC, authentication parameters, and an identifier of a second device; and to send a second message to the second device, the second message carrying the MAC and the authentication parameters, the authentication parameters being used by the second device to obtain a verification MAC based on a root key, the verification MAC being used by the second device to authenticate a core network-side device in conjunction with the MAC, and the root key being a key shared by the second device and the core network-side device.

[0588] Figure 31 This is a schematic diagram of the composition structure of a second device according to an embodiment of this application, including:

[0589] The second communication unit 3110 is used to receive a second message from the first device, the second message carrying a message authentication code (MAC) and authentication parameters;

[0590] The second processing unit 3120 is used to calculate the verification MAC based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and the core network side device; if the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

[0591] Figure 32 This is a schematic diagram of the composition structure of a first network device according to an embodiment of the present application, including:

[0592] The third communication unit 3210 is used to send a first message to the first device, wherein the first message carries a message authentication code (MAC), authentication parameters, and an identifier of the second device. The authentication parameters are used by the second device to obtain a verification MAC based on a root key. The verification MAC is used by the second device to authenticate core network side devices in conjunction with the MAC. The root key is a key shared by the second device and all core network side devices.

[0593] Figure 33 This is a schematic diagram of the composition structure of an electronic device according to an embodiment of this application, including:

[0594] The fourth processing unit 3310 is used to calculate an integrity protection key and / or an encryption key, wherein the integrity protection key is related to a key generation parameter and a third random number, the encryption key is related to the key generation parameter and a fourth random number, the key generation parameter includes an anonymous key and / or a first random number, the integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt the sent data and / or decrypt the received data.

[0595] This application provides a first device, including:

[0596] A first communication unit is configured to receive a first message from a first network device, the first message carrying authentication parameters and an identifier of a second device; send a second message to the second device, the second message carrying authentication parameters; receive a third message from the second device, the third message carrying a first RES, the first RES being obtained by the second device based on the authentication parameters and a root key, the root key being a key shared by the second device and all core network side devices; and send a fourth message to the first network device, the fourth message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0597] This application provides a second device, including:

[0598] The second communication unit is configured to receive a second message from the first device, the second message carrying authentication parameters; and to send a third message to the first device, the third message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

[0599] The second processing unit is used to calculate the first RES based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and all core network side devices.

[0600] Figure 32 This is a schematic diagram of the composition structure of a first network device according to an embodiment of the present application, including:

[0601] The third communication unit 3210 is configured to send a first message to the first device, the first message carrying authentication parameters and the identifier of the second device; and receive a fourth message from the first device, the fourth message carrying the first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices;

[0602] The third processing unit 3220 is used to determine that the second device authentication is successful when the first RES is the same as the first verification RES.

[0603] Figure 30 This is a schematic diagram of the composition structure of a first device according to an embodiment of this application, including:

[0604] The first communication unit 3010 is configured to send a second message to the second device, the second message carrying authentication parameters; and receive a third message from the second device, the third message carrying a second RES, the second RES being related to the authentication parameters and the first key;

[0605] The first processing unit 3020 is configured to generate a second verification RES based on the authentication parameters and the first key; and determine that the second device authentication is successful if the second verification RES is the same as the first verification RES.

[0606] This application provides a second device, including:

[0607] The second communication unit is configured to receive a second message from the first device, the second message carrying authentication parameters; and to send a third message to the first device, the third message carrying the second RES, the second RES being used by the first device to authenticate the second device.

[0608] The second processing unit is used to calculate the second RES based on authentication parameters and a first key, wherein the first key is associated with the first device.

[0609] The device in this application embodiment can realize the corresponding functions of each device in the foregoing authentication method embodiments. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in the second device, or first device, or first network device, or electronic device can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the second device, or first device, or first network device, or electronic device in the application embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0610] Figure 34 This is a schematic structural diagram of a communication device 3400 according to an embodiment of this application. The communication device 3400 includes a processor 3410, which can call and run computer programs from memory to enable the communication device 3400 to implement the methods in the embodiments of this application.

[0611] In one possible implementation, the communication device 3400 may further include a memory 3420. The processor 3410 can retrieve and run computer programs from the memory 3420 to enable the communication device 3400 to implement the methods described in the embodiments of this application.

[0612] The memory 3420 can be a separate device independent of the processor 3410, or it can be integrated into the processor 3410.

[0613] In one possible implementation, the communication device 3400 may further include a transceiver 3430, which the processor 3410 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0614] The transceiver 3430 may include a transmitter and a receiver. The transceiver 3430 may further include an antenna, and the number of antennas may be one or more.

[0615] In one possible implementation, the communication device 3400 may be the first device, the second device, or the first network device in the embodiments of this application, and the communication device 3400 may implement the corresponding processes implemented by the first device, the second device, or the first network device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0616] Figure 35 This is a schematic structural diagram of a chip 3500 according to an embodiment of this application. The chip 3500 includes a processor 3510, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0617] In one possible implementation, chip 3500 may further include memory 3520. Processor 3510 can retrieve and run computer programs from memory 3520 to implement the methods executed by the access network device or the first core network device in this embodiment. Memory 3520 may be a separate device independent of processor 3510, or it may be integrated into processor 3510.

[0618] In one possible implementation, the chip 3500 may further include an input interface 3530. The processor 3510 can control the input interface 3530 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips. In another possible implementation, the chip 3500 may further include an output interface 3540. The processor 3510 can control the output interface 3540 to communicate with other devices or chips; specifically, it can output information or data to other devices or chips.

[0619] In one possible implementation, the chip can be applied to the first device, or the second device, or the first network device, or the electronic device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the first device, or the second device, or the first network device, or the electronic device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0620] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0621] The processors mentioned above can be general-purpose processors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other programmable logic devices, transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processors mentioned above can be microprocessors or any conventional processor.

[0622] The aforementioned memory can be volatile memory or non-volatile memory, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM).

[0623] It should be understood that the above-described memory is exemplary but not restrictive. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0624] Figure 36This is a schematic block diagram of a communication system 3600 according to an embodiment of this application. The communication system 3600 includes a second device 3610, a first device 3620, and a first network device 3630. The second device 3610, the first device 3620, and the first network device 3630 can respectively implement the corresponding functions performed by the second device, the first device, and the first network device in the above-described method.

[0625] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

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

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

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

Claims

1. An authentication method, comprising: The first device receives a first message from a first network device, the first message carrying MAC, authentication parameters, and the identifier of the second device; The first device sends a second message to the second device. The second message carries the MAC and the authentication parameters. The authentication parameters are used by the second device to obtain the verification MAC based on the root key. The verification MAC is used by the second device to authenticate the core network side device in combination with the MAC. The root key is a key shared by the second device and the core network side device.

2. An authentication method, comprising: The second device receives a second message from the first device, the second message carrying a message authentication code (MAC) and authentication parameters; The second device calculates and verifies the MAC based on the authentication parameters and the root key, where the root key is a key shared by the second device and the core network side device; If the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

3. A key generation method, comprising: An electronic device calculates an integrity protection key and / or an encryption key, wherein the integrity protection key is associated with key generation parameters and a third random number, and the encryption key is associated with key generation parameters and a fourth random number. The key generation parameters include an anonymous key and / or a first random number. The integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt transmitted data and / or decrypt received data.

4. The method according to claim 3, wherein, The electronic device is either a first device or a second device; the second device is an AIoT device, and the first device includes at least one of the following: a terminal device, an access network device, an authentication device, and a first core network device.

5. The method according to claim 4, wherein, The computational integrity protection key includes one of the following: The integrity protection key is calculated using a second calculation method based on the anonymous key and a third random number. The integrity protection key is calculated using the second calculation method based on the first random number and the third random number; The integrity protection key is calculated using a second calculation method based on the anonymous key, the first key, and a third random number. The integrity protection key is calculated using the second calculation method based on the first random number, the first key, and the third random number. The integrity protection key is calculated using the second calculation method based on the second intermediate key and the third random number, wherein the second intermediate key is related to the key generation parameters; The integrity protection key is calculated using the second calculation method based on the third intermediate key and the third random number. The third intermediate key is related to the root key and the key generation parameters.

6. The method according to claim 4, wherein, The calculation encryption key includes one of the following: The encryption key is calculated using the fourth random number and the anonymous key using the second calculation method; The encryption key is calculated using the second calculation method based on the first random number and the fourth random number; The encryption key is calculated using a second calculation method based on the anonymous key, the first key, and the fourth random number. The encryption key is calculated using the second calculation method based on the first random number, the first key, and the fourth random number. The encryption key is calculated using the second calculation method based on the second intermediate key and the fourth random number, wherein the second intermediate key is related to the key generation parameters; The encryption key is calculated using the second calculation method based on the third intermediate key and the fourth random number, wherein the third intermediate key is related to the root key and the key generation parameters.

7. An authentication method, comprising: The second device receives a second message from the first device, the second message carrying authentication parameters; The second device calculates the first RES based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and all core network side devices; The second device sends a third message to the first device, the third message carrying the first RES, the first RES being used by the core network side device to authenticate the second device.

8. The method according to claim 7, wherein, The authentication parameters include one of the following: an anonymous key, a first random number; the second device calculates a first RES based on the authentication parameters and the root key, including one of the following: The second device uses the first calculation method to calculate the first RES based on the first random number and the root key; The second device uses the first calculation method to calculate the first RES based on the anonymous key and the root key.

9. The method according to claim 8, wherein, The second device calculates the first RES based on the first random number and the root key using the first calculation method, including: the second device calculates the first RES based on the service parameters, the first random number and the root key using the first calculation method; And / or, the second device calculates the first RES based on the anonymous key and the root key using the first calculation method, including: the second device calculates the first RES based on the service parameters, the anonymous key and the root key using the first calculation method.

10. The method according to claim 9, wherein, The second message also carries the service parameters, which include at least one of the following: a type parameter indicating the type of AIoT service, an identifier of a server with AIoT service functionality, and a type parameter indicating the type of AIoT authentication.

11. An authentication method, comprising: The first network device sends a first message to the first device, the first message carrying authentication parameters and the identifier of the second device; The first network device receives a fourth message from the first device, the fourth message carrying the first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices; If the first network device determines that the second device has been authenticated when the first RES is the same as the first verification RES.

12. The method according to claim 11, wherein, The authentication parameters include one of the following: anonymous key, first random number.

13. The method according to claim 12, wherein, The method also includes one of the following: The first network device receives the authentication parameters and the first verification RES sent by the second network device; The first network device calculates the first verification RES based on the root key and the authentication parameters using the first calculation method.

14. A first device, comprising: The first communication unit is configured to receive a first message from a first network device, the first message carrying a MAC, authentication parameters, and the identifier of the second device. A second message is sent to the second device, the second message carrying the MAC and the authentication parameters. The authentication parameters are used by the second device to obtain the verification MAC based on the root key. The verification MAC is used by the second device to authenticate the core network side device in combination with the MAC. The root key is a key shared by the second device and the core network side device.

15. A second device, comprising: The second communication unit is used to receive a second message from the first device, the second message carrying a message authentication code (MAC) and authentication parameters; The second processing unit is used to calculate the verification MAC based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and the core network side device. If the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

16. An electronic device comprising: The fourth processing unit is used to calculate an integrity protection key and / or an encryption key, wherein the integrity protection key is related to key generation parameters and a third random number, the encryption key is related to the key generation parameters and a fourth random number, the key generation parameters include an anonymous key and / or a first random number, the integrity protection key is used to calculate an integrity verification code, and the encryption key is used to encrypt the sent data and / or decrypt the received data.

17. A second device, comprising: The second communication unit is used to receive a second message from the first device, the second message carrying authentication parameters; Send a third message to the first device, the third message carrying the first RES, the first RES being used by the core network side device to authenticate the second device; The second processing unit is used to calculate the first RES based on the authentication parameters and the root key, wherein the root key is a key shared by the second device and all core network side devices.

18. A first network device, comprising: The third communication unit is used to send a first message to the first device, wherein the first message carries authentication parameters and the identifier of the second device; Receive a fourth message from the first device, the fourth message carrying the first RES, the first RES being obtained by the second device based on the authentication parameters and the root key, the root key being a key shared by the second device and all core network side devices; The third processing unit is used to determine that the second device has passed authentication if the first RES is the same as the first verification RES.

19. A first device, comprising: A transceiver, a processor, and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the first device to perform the method as described in claim 1.

20. A second device, comprising: A transceiver, a processor, and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the second device to perform the method as claimed in claim 2 or any one of claims 7 to 10.

21. A first network device, comprising: A transceiver, a processor, and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the first network device to perform the method as described in any one of claims 11 to 13.

22. An electronic device, comprising: A transceiver, a processor, and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 3 to 6.

23. A computer-readable storage medium for storing a computer program that, when run by a device, causes the device to perform the method as described in any one of claims 1, 2, 3 to 6, 7 to 10, or 11 to 13.

Images