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

Authentication method, key generation method and device Technical Field

[0001] The present application relates to the field of communications, and more specifically, to an authentication method, a key generation method, a device, a computer-readable storage medium, a computer program product, and a computer program. Background Art

[0002] In related technologies, the authentication and key negotiation processes between UE (User Equipment) and the core network use highly complex computational functions and key structures. However, zero-power devices, such as A-IoT devices, also need to access networks such as the core network. Therefore, how to ensure the security of A-IoT devices while achieving authentication with the network using less complex computational methods becomes a challenge.

[0003] Summary of the Invention

[0004] Embodiments of the present application provide an authentication method, a key generation method, a device, a computer-readable storage medium, a computer program product, and a computer program.

[0005] This embodiment of the present application provides an authentication method, including:

[0006] The first device receives a first message from the first network device, where the first message carries a MAC, an authentication parameter, and an identifier of the second device;

[0007] The first device sends a second message to the second device, and the second message carries 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. 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 embodiment of the present application provides an authentication method, including:

[0009] The second device receives a second message from the first device, where the second message carries a message authentication code MAC and an authentication parameter;

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

[0011] When the verification MAC is identical to the MAC, the second device completes authentication of the core network side device.

[0012] This embodiment of the present 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 a 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 a core network side device in combination with the MAC, and the root key is a key shared by the second device and all core network side devices.

[0014] This embodiment of the present application provides a key generation method, including:

[0015] 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 sent data and / or decrypt received data.

[0016] This embodiment of the present application provides an authentication method, including:

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

[0018] The first device sends a second message to the second device, where the second message carries an authentication parameter;

[0019] The first device receives a third message from the second device, where the third message carries a first RES, where the first RES is obtained by the second device based on the authentication parameters and a root key, where the root key is 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, where the fourth message carries the first RES, and the first RES is used by a core network side device to authenticate the second device.

[0021] This embodiment of the present application provides an authentication method, including:

[0022] The second device receives a second message from the first device, where the second message carries the authentication parameter;

[0023] The second device calculates a first RES based on the authentication parameter and a root key, where 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, where the third message carries the first RES, and the first RES is used by a core network side device to authenticate the second device.

[0025] This embodiment of the present application provides an authentication method, including:

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

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

[0028] When the first RES is identical to the first verification RES, the first network device determines that the second device is authenticated successfully.

[0029] This embodiment of the present application provides an authentication method, including:

[0030] The first device sends a second message to the second device, where the second message carries the authentication parameter;

[0031] The first device receives a third message from the second device, where the third message carries a second RES, and the second RES is related to the authentication parameter and the first key;

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

[0033] When the second verification RES is identical to the second RES, the first device determines that the second device authentication is successful.

[0034] This embodiment of the present application provides an authentication method, including:

[0035] The second device receives a second message from the first device, where the second message carries the authentication parameter;

[0036] The second device calculates a second RES based on the authentication parameter and a physical layer key, the first key being associated with the first device;

[0037] The second device sends a third message to the first device, where the third message carries the second RES, and the second RES is used by the first device to authenticate the second device.

[0038] An embodiment of the present 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 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 combination with the MAC, the root key being a key shared by the second device and the core network side device.

[0040] This embodiment of the present application provides a second device, including:

[0041] A second communication unit, configured to receive a second message from the first device, where the second message carries a message authentication code MAC and an authentication parameter;

[0042] The second processing unit is used to calculate the verification 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; when the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

[0043] An embodiment of the present 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 a root key, the verification MAC is used by the second device to authenticate the core network side device in combination with the MAC, and the root key is a key shared by the second device and all core network side devices.

[0045] An embodiment of the present application provides an electronic device, including:

[0046] a fourth processing unit, configured 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 transmitted data and / or decrypt received data.

[0047] An embodiment of the present application provides a first device, including:

[0048] The 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] An embodiment of the present 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 an authentication parameter; send a third message to the first device, the third message carrying the first RES, and the first RES is used by the core network side device to authenticate the second device;

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

[0052] An embodiment of the present application provides a first network device, including:

[0053] a third communication unit, configured to send a first message to the first device, the first message carrying authentication parameters and an 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 a 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 configured to determine that the second device authentication is successful when the first RES is the same as the first verification RES.

[0055] An embodiment of the present application provides a first device, including:

[0056] a first communication unit, configured to send a second message to a second device, the second message carrying an authentication parameter; and receive a third message from the second device, the third message carrying a second RES, the second RES being related to the authentication parameter and the first key;

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

[0058] An embodiment of the present application provides a second device, including:

[0059] a second communication unit, configured to receive a second message from the first device, the second message carrying authentication parameters; and 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 configured to calculate a second RES based on the authentication parameter and a first key, where the first key is associated with the first device.

[0061] An embodiment of the present application provides a first device, comprising a transceiver, a processor, and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the first device performs the above method.

[0062] An embodiment of the present application provides a second device, comprising a transceiver, a processor, and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the second device performs the above method.

[0063] An embodiment of the present application provides a first network device, comprising a transceiver, a processor, and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the first network device performs the above method.

[0064] An embodiment of the present application provides an electronic device, comprising a transceiver, a processor, and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the electronic device performs the above method.

[0065] The embodiment of the present application provides a chip for implementing the above method.

[0066] Specifically, the chip includes: a processor, which is used to call and run a computer program from a memory, so that a device equipped with the chip executes the above method.

[0067] An embodiment of the present application provides a computer-readable storage medium for storing a computer program, which enables a device to perform the above method when the computer program is executed by the device.

[0068] An embodiment of the present application provides a computer program product, including computer program instructions, which enable a computer to execute the above method.

[0069] An embodiment of the present application provides a computer program, which, when executed on a computer, enables the computer to execute the above method.

[0070] By adopting the solution provided in this embodiment, the first device sends authentication parameters to the second device, allowing the second device to directly calculate a verification MAC based on the authentication parameters and a 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, improving its processing efficiency. This approach is particularly suitable for devices with lower computing power. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] FIG1 is a schematic diagram of an application scenario according to an embodiment of the present application.

[0072] FIG2 is a schematic flowchart of an authentication method according to an embodiment of the present application.

[0073] FIG3 is a schematic flowchart of an authentication method according to another embodiment of the present application.

[0074] FIG4 is a schematic flowchart of an authentication method according to another embodiment of the present application.

[0075] FIG5 is a schematic flowchart of a key generation method according to an embodiment of the present application.

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

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

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

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

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

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

[0082] FIG26 is a schematic diagram of a scenario in which an AIOT device accesses a network in related technology.

[0083] FIG27 is a schematic diagram of the AKA authentication process.

[0084] FIG28 is a schematic diagram of an authentication architecture of a related technology.

[0085] FIG29 is a schematic diagram of a key architecture in related art.

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

[0087] FIG31 is a schematic block diagram of a second device according to an embodiment of the present application.

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

[0089] FIG33 is a schematic block diagram of an electronic device according to an embodiment of the present application.

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

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

[0092] Figure 36 is a schematic block diagram of a communication system according to an embodiment of the present application. DETAILED DESCRIPTION

[0093] The technical solutions of the embodiments of the present application 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] The embodiments of the present application describe various embodiments in conjunction with network devices and terminals. The terminals can be mobile or fixed, and can also be referred to as mobile stations, user units, etc. The terminal can be a site in a WLAN, and can be a smart terminal, wireless modem, laptop computer, tablet computer, or other terminal. In the embodiments of the present application, the terminal can be a VR terminal / AR terminal, an industrial control terminal, an unmanned driving terminal, a telemedicine terminal, a smart grid terminal, a transportation safety terminal, a smart city terminal, or a wireless terminal for a smart home, etc. As an example and not a limitation, in the embodiments of the present application, the terminal can also be a wearable device.

[0095] In the embodiment of the present application, the network device may be a device for communicating with a terminal, and the network device may be an access point in WLAN, a base station in GSM, CDMA, or WCDMA, an evolved base station in LTE, or a relay station, or a network device (gNB) in an in-vehicle device, a wearable device, and an NR network, or a network device in a future evolved PLMN network, or a network device in a non-terrestrial network, etc. As an example and not a limitation, in the embodiment of the present application, the network device may have a mobile feature, for example, the network device may be a mobile device.

[0096] It should be understood that the terms "system" and "network" are often used interchangeably in this article. The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the objects associated before and after are in an "or" relationship. It should be understood that the "indication" mentioned in the embodiments of this application can be a direct indication, an indirect indication, or an indication of an association relationship. For example, A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association relationship between A and B. In the description of the embodiments of this application, the term "corresponding" can mean that there is a direct or indirect correspondence between the two, or it can mean that there is an association relationship between the two, or it can mean a relationship between indication and indication, configuration and configuration, etc.

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

[0098] Figure 1 exemplarily illustrates a communication system 100. The 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 each network device 110 may include a different number of terminals 120 within its coverage area, although this embodiment of the present application does not limit this. In one possible implementation, the communication system 100 may also include a mobility management entity, access and mobility management functions, and other network entities, although this embodiment of the present application does not limit this. The network devices may 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 of LTE, LTE-A, or NR systems. Taking the communication system shown in Figure 1 as an example, the communication devices may include network devices and terminals with communication functions. The communication devices may also include other devices in the communication system, such as network controllers, mobility management entities, and other network entities, although this embodiment of the present application does not limit this.

[0099] Figure 2 is a schematic flow chart of an authentication method according to an embodiment of the present application. The method includes at least part of the following contents.

[0100] S210. The first device receives a first message from a first network device, where the first message carries a MAC address, authentication parameters, and an 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 a verification MAC based on a 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 is a schematic flow chart of an authentication method according to another embodiment of the present application. The method includes at least part of the following contents.

[0103] S310. The second device receives a second message from the first device, where the second message carries a message authentication code (MAC) and authentication parameters.

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

[0105] S330: When the verification MAC is identical to the MAC, the second device completes authentication of the core network side device.

[0106] Figure 4 is a schematic flow chart of an authentication method according to another embodiment of the present application. The method includes at least part of the following contents.

[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 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 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] FIG5 is a schematic flow chart of a key generation method according to another embodiment of the present application. The method includes at least part of the following contents.

[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 sent data and / or decrypt received data.

[0110] The core network side device includes one of the following: 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 expressed as an A-IoT device. This embodiment does not enumerate all possible representations. In some possible examples, the second device can also be a zero-power device, for example, an active zero-power device, or a passive zero-power device, or a semi-passive zero-power device, etc. Optionally, the second device can be called a tag, and optionally the second device can also be an IoT device, etc. In other possible examples, the second device can be a terminal with lower computing power. All possible names or possible devices of the second device are not enumerated 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), and a core network element dedicated to AIoT services (for example, it can be referred to as an AIoT network element). In addition, the first core network device may also be a network element of other core networks, which are not exhaustive here.

[0113] The one or more core network devices may include at least one of the following: AUSF, UDM (Unified Data Management Function), ARPF (Authentication credential Repository and Processing Function). It should be understood that this is only an exemplary description. In actual processing, the one or more core network devices may also include other core network devices, but they are not listed here exhaustively. The first network device may be one of the aforementioned core network side devices. Exemplarily, the first network device is AUSF (Authentication Server Function) or a verification server.

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

[0115] The second device calculates the verification MAC based on the authentication parameter 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 the first calculation method; the second device calculates the anonymous key based on the first random number and the root key XOR, and 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 random number based on the anonymous key and the root key XOR, and 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 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 calculating the verification MAC based on the authentication parameters and the root key may include one of the following: the second device calculating the verification MAC based on the anonymous key and the root key using a first calculation method; the second device calculating the first random number based on an exclusive OR of the anonymous key and the root key, and the second device calculating 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, an Advanced Encryption Standard (AES), ACSON, SNOW 3G (Snow Third Generation), or ZUC (ZUChongzhi). The second authentication function may be represented by f2(); the hash algorithm may be represented by HASH(), and the hash algorithm may include HMAC-SHA-256 (Hash based Message Authentication Code-Secure Hash Algorithm-256), or other hash algorithms may be used, which are not exhaustive in this embodiment. In addition, the above-mentioned first calculation method is only for illustrative purposes. In actual processing, other algorithms that can be used to calculate MAC or verify MAC may also be included in the above-mentioned first calculation method, which are not exhaustive here.

[0118] Exemplarily, 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), wherein MAC' represents the verification MAC, f2() represents the first calculation method, specifically the second authentication function, Kr represents the root key, and AK represents the anonymous key. In addition to being expressed as Kr, the above-mentioned root key can also be expressed as any one of K, PSK (PreShared Key), PMK (Pairwise Master Key), etc. Correspondingly, Kr in each formula example provided in this embodiment (including the following) can be replaced by K, PSK, PMK, etc., and the list is not exhaustive here.

[0119] Exemplarily, the second device calculates the first random number based on the XOR of the anonymous key and the root key, which may be calculated using the following formula: Among them, RAND represents the first random number, Kr represents the root key, and AK represents the anonymous key. 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 meaning of each parameter in this formula is the same as that in the previous embodiment and is not repeated here.

[0120] Optionally, the authentication parameter includes a first random number. Accordingly, the second device calculating the verification MAC based on the authentication parameter and the root key may include one of the following: the second device calculating the verification MAC based on the first random number and the root key using a first calculation method; the second device calculating the anonymous key based on an exclusive OR of the first random number and the root key, and the second device calculating the verification MAC based on the anonymous key and the root key using the first calculation method.

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

[0122] Exemplarily, the second device calculates the anonymous key based on the XOR of the first random number and the root key, which may be calculated using the following formula: Among them, RAND represents the first random number, Kr represents the root key, and AK represents the anonymous key. The second device calculates the verification MAC based on the anonymous key and the root key using the first calculation method, and can use the following formula: MAC'=f2(Kr,AK), where the meaning of each parameter in the formula is the same as in the above embodiment and is not repeated here.

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

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

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

[0126] A server with AIoT service functions may refer to a server that provides AIoT-related services, for example, it may be an AF (Application Function) network element, or it may be a network element with AIoT service functions on the core network side, or it may be other servers, which are not exhaustively listed here. The above-mentioned identifier may include a network identifier and / or ID; the network identifier may include: an IP address (Internet Protocol Address), a MAC (Media Access Control Address), and the like at least one.

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

[0128] The second device calculates the verification MAC based on the anonymous key and the root key using the 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 the 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, still taking the first calculation method as the second authentication function as an example, the second device calculates the verification MAC based on the service parameters, the anonymous key and the root key using the first calculation method, which can be calculated using the following formula: MAC'=f2

[0130] (Kr, AK, service parameters), where the meaning of each parameter is the same as in the previous embodiment and will not be repeated here.

[0131] For example, still taking the first calculation method as the second authentication function as an example, 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, and can be calculated 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.

[0132] 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 above first calculation methods can be used to calculate the verification MAC, but they are not described one by one.

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

[0134] This embodiment does not limit the manner in which the first network device generates the authentication parameters. It should be noted that the authentication parameters may include an anonymous key or a first random number. The first network device may pre-generate an anonymous key and a first random number, and then use either of the two as the authentication parameter. This embodiment does not limit the manner in which the first network device generates the first random number. The relationship between the anonymous key and the first random number may be: the anonymous key is obtained by XORing the first random number with the root key.

[0135] The first network device calculates the MAC based on the root key and the authentication parameter, 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 based on the first random number and the root key XOR, and the first network device 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 based on the anonymous key and the root key XOR, and the second device 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 above-mentioned first calculation method is the same as that of the aforementioned embodiment and will not be repeated here.

[0136] Optionally, the authentication parameter includes an anonymous key. The first network device calculating the MAC based on the authentication parameter and the root key may include one of the following: the first network device calculating the MAC based on the anonymous key and the root key using a first calculation method; the first network device calculating the first random number based on an exclusive OR of the anonymous key and the root key, and the first network device calculating the MAC based on the first random number and the root key using the first calculation method.

[0137] Exemplarily, the first network device uses a first calculation method to calculate the MAC based on the anonymous key and the root key, and can be calculated using the following formula: MAC = f2(Kr, AK), where MAC represents MAC, f2() represents that the first calculation method is specifically the second authentication function, Kr represents the root key, and AK represents the anonymous key.

[0138] Exemplarily, the first network device calculates the first random number based on the anonymous key and the root key using an exclusive OR operation. The formula that can be used is the same as in the previous embodiment and is not repeated here. 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: MAC = f2(Kr, RAND). The meaning of each parameter in this formula is the same as in the previous embodiment and is not repeated here.

[0139] Optionally, the authentication parameter includes a first random number. Accordingly, the first network device calculating the MAC based on the authentication parameter 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 calculating the anonymous key based on an exclusive OR of the first random number and the root key, and the first network device calculating the MAC based on the anonymous key and the root key using the first calculation method.

[0140] The first network device calculates the MAC based on the first random number and the root key using a first calculation method, and the formula that can be used is the same as that in the aforementioned embodiment. The first network device calculates the anonymous key based on the XOR of the first random number and the root key, and the first network device calculates the verification MAC based on the anonymous key and the root key using the first calculation method. The formulas used are also the same as those in the aforementioned embodiment and are therefore not further described.

[0141] It should be pointed out that the above is only an illustrative explanation using the first calculation method as the second authentication function. In actual processing, the first calculation method may not be limited to the above-mentioned second authentication function. Any one of the above-mentioned 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 list them all.

[0142] 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 the 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 the service parameters, the first random number and the root key using the first calculation method.

[0143] In this case, the first message also carries the service parameters. The description of the service parameters is the same as that in the aforementioned embodiment and will not be repeated. Among them, 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 include at least one of the following: an anonymous key, a first random number, and a service parameter; for example, the authentication parameter includes an anonymous key; or the authentication parameter includes a first random number; or the authentication parameter includes an anonymous key and a service parameter; or the authentication parameter includes a first random number and a service parameter. This embodiment does not limit the manner in which the first network device generates the service parameter or obtains the service parameter.

[0144] For example, still taking the first calculation method as the second authentication function as an example, the first network device uses the first calculation method to calculate the MAC based on the service parameters, the anonymous key and the root key, and can be calculated 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.

[0145] For example, still taking the first calculation method as the second authentication function as an example, the first network device uses the first calculation method to calculate the MAC based on the service parameters, the first random number and the root key, and can be calculated 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.

[0146] Optionally, the second network device can be a device on the core network side, that is, the second network device can be a second core network device. Since the second network device is a device on the core network side, the second network device stores the root key corresponding to the aforementioned second device. This embodiment does not limit the way in which the second network device generates or obtains the root key corresponding to the second device.

[0147] The second network device may also 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 and ARPF. In addition, the embodiment does not limit the manner in which the second network device obtains the MAC address.

[0148] The first network device receiving the MAC address and the authentication parameters from the second network device may also 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 embodiment and is not repeated here. The manner in which the first message can carry the service parameters is also the same as in the previous embodiment and is not repeated here.

[0149] In this example, the method for calculating MAC by the second network device is the same as the method for calculating MAC by the first network device, and thus will not be described repeatedly.

[0150] It should also be noted that the algorithm used by the first network device or the 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, using the first network device and the second device as an example, 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 situations are the same as described above and are not detailed here.

[0151] In some possible implementations, the processing by the second device may further include: when the verification MAC is identical to the MAC, the second device completing authentication of the core network side device.

[0152] The second device may also perform the following processing: the second device determines whether the verification MAC is the same as the MAC. In addition, the second device may also perform the following processing: 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, subsequent processing may not be performed, or the second device may send a message to the first device (for example, to the first network device through the first device) indicating that the authentication of the core network side device has failed.

[0153] The above-mentioned second device completes the authentication of the core network side device, which can also be called the second device successfully authenticates the identity of the core network side device, or the second device successfully authenticates the identity of the core network side device, or the second device successfully authenticates the core network side device.

[0154] 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.

[0155] In some possible examples, the third message carries the first RES.

[0156] In this case, the first device's processing may include: the first device sending a fourth message to the first network device, the fourth message carrying the first RES. Furthermore, the first device may also send a response message to the second device. For example, after the first device receives a notification from the first network device that the second device has been successfully authenticated, the first device sends a response message to the second device, the response message being in response to the third message and indicating that the core network device has successfully authenticated the second device. Accordingly, the first network device's processing 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 determining that the second device has been successfully authenticated. Exemplarily, after determining that the second device has been successfully authenticated, the first network device may also send a notification to the first device that the second device has been successfully authenticated. Exemplarily, the first network device may also determine that if the first RES is different from the first verification RES, the first network device determines that the second device has not been successfully authenticated, thereby terminating the processing, or sending a notification of authentication failure to the second device via the first device. Possible subsequent processing is not limited herein. Furthermore, if the second device has been successfully authenticated, the first network device may send a notification to the first device that the second device has been successfully authenticated.

[0157] The manner in which the aforementioned second device calculates the first RES includes 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.

[0158] Optionally, the second device calculates the first RES based on the first random number and the root key using the first calculation method, which may 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 first verification RES) are at least partially different from the parameters used to calculate the verification MAC (or MAC) in the aforementioned embodiment. In addition, the specific algorithm used to calculate the first RES may also be different from the specific algorithm used to calculate the MAC. For example, if a hash algorithm is used to calculate the first RES, the second authentication function may be used to calculate the MAC.

[0159] 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). 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 the other contents in the above formula are the same as in the previous embodiment and are not repeated here.

[0160] Furthermore, a service parameter may be added to calculate the first RES. The second device calculating the first RES based on the first random number and the root key using the first calculation method may include: the second device calculating the first RES based on the service parameter, the first random number, and the root key using the first calculation method. For example, the second device calculating the first RES based on the service parameter, the first random number, and the root key using the first calculation method may use the following formula: RES = f2(Kr, RAND, service parameter), where the meaning of each content in the formula is the same as in the aforementioned embodiment and is not repeated here.

[0161] It should be understood that, when the second device uses the first calculation method to calculate the first RES based on the service parameters, the first random number, and the root key, the second device may use the service parameters, the anonymous key, and the root key to calculate the verification MAC, or the second device may use only the anonymous key and the root key to calculate the verification MAC. When 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 may use the service parameters, the anonymous key, and the root key to calculate the verification MAC, or the second device may use only the anonymous key and the root key to calculate the verification MAC. The above processing methods are all within the scope of protection of this embodiment.

[0162] Optionally, the second device uses the first calculation method to calculate the first RES based on the anonymous key and the root key, which may mean that when the second device uses the first calculation method to calculate the verification MAC 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.

[0163] 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 may 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 may be calculated using the following formula: RES = f2(Kr, AK), where RES represents the first RES. The meanings of the other contents in the formula are the same as in the previous embodiment and are not repeated here.

[0164] Furthermore, a service parameter may 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 parameter, the anonymous key, and the root key using the first calculation method. For example, the following formula may be used: RES = f2(Kr, AK, service parameter), where the meaning of each element in the formula is the same as in the previous embodiment and is not further described.

[0165] It should be understood that, when the second device adopts the first calculation method based on the service parameters, the anonymous key and the root key first RES, the second device may use the service parameters, the first random number and the root key to calculate and verify the MAC, or the second device may also use only the first random number and the root key to calculate and verify the MAC. When the second device adopts the first calculation method based on the anonymous key and the root key first RES, the second device may use the service parameters, the first random number and the root key to calculate and verify the MAC, or the second device may also use only the first random number and the root key to calculate and verify the MAC. The above processing methods are all within the protection scope of this embodiment.

[0166] On the first network device side, a method for 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. The method for the first network device to calculate 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.

[0167] The first verification RES may be a first expected response (XRES). In the following text, unless otherwise specified, the first verification RES and the first XRES have the same meaning and are not explained repeatedly.

[0168] The first network device adopts the first calculation method to calculate the first verification RES based on the first random number and the root key, which may mean that when the first network device adopts the first calculation method to calculate the MAC based on the anonymous key and the root key, the first network device adopts the first calculation method to calculate the first verification RES based on the first random number and the root key.

[0169] For example, the first network device calculates the MAC based on the anonymous key and the root key using the first calculation method, which may 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 may be calculated using the following formula: XRES = f2(Kr, RAND), where XRES represents the first verification RES. The meanings of the other contents in the formula are the same as in the previous embodiment and are not repeated here.

[0170] Furthermore, a service parameter may be added to calculate the first verification RES. The first network device adopts the first calculation method to calculate the first verification RES based on the first random number and the root key, which may include: the first network device adopts the first calculation method to calculate the first verification RES based on the service parameter, the first random number and the root key. For example, the second device adopts the first calculation method to calculate the first verification RES based on the service parameter, the first random number and the root key, which may adopt the following formula: XRES = f2(Kr, RAND, service parameter), wherein the meaning of each content in the formula is the same as that in the aforementioned embodiment and is not repeated here.

[0171] It should be understood that, when the first network device (or second network device) adopts the first calculation method to calculate the first verification RES based on the service parameters, the first random number and the root key, the first network device (or second network device) can use the service parameters, the anonymous key and the root key to calculate the MAC, or the first network device can also use only the anonymous key and the root key to calculate the MAC. When the first network device (or second network device) adopts the first calculation method to calculate the first verification RES based on the first random number and the root key, the first network device (or second network device) can use the service parameters, the anonymous key and the root key to calculate the MAC, or the first network device (or second network device) can also use only the anonymous key and the root key to calculate the MAC. The above processing methods are all within the protection scope of this embodiment.

[0172] The first network device uses the first calculation method to calculate the first verification RES based on the anonymous key and the root key, which may mean: when the first network device uses the first calculation method to calculate the MAC based on the first random number and the root key, the first network device uses the first calculation method to calculate the first verification RES based on the anonymous key and the root key.

[0173] 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 may 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 may be calculated using the following formula: XRES = f2(Kr, AK), where XRES represents the first verification RES. The meanings of the other contents in the formula are the same as in the previous embodiment and are not repeated here.

[0174] Furthermore, a service parameter may be added to calculate the first verification RES. The first network device calculating the first verification RES based on the anonymous key and the root key using the first calculation method may include: the first network device calculating the first verification RES based on the service parameter, the anonymous key, and the root key using the first calculation method. For example, the following formula may be used: XRES = f2(Kr, AK, service parameter), where the meaning of each element in the formula is the same as in the previous embodiment and is not further described.

[0175] It should be understood that, when the first network device (or second network device) adopts the first calculation method to first verify RES based on the service parameters, the anonymous key and the root key, the first network device (or second network device) can use the service parameters, the first random number and the root key to calculate MAC, or the first network device (or second network device) can also use only the first random number and the root key to calculate MAC. When the first network device (or second network device) adopts the first calculation method to first verify RES based on the anonymous key and the root key, the first network device (or second network device) can use the service parameters, the first random number and the root key to calculate MAC, or the first network device (or second network device) can also use only the first random number and the root key to calculate MAC. The above processing methods are all within the protection scope of this embodiment.

[0176] The first network device receiving the first verification RES from the second network device may refer to the first network device receiving the first verification RES, MAC, and authentication parameters from the second network device. Simultaneously, the first network device may also receive service parameters from the second network device. The description of the service parameters is the same as in the previous embodiment and is not repeated here.

[0177] For example, the first network device may receive the first verification RES, MAC, and authentication parameters sent by the second network device at the same time, but only carries the MAC and authentication parameters in the first message and sends it to the first device; accordingly, after the first device receives the first message, it carries the MAC and authentication parameters in the first message in the second message and sends it to the second device. For another example, the first network device may receive the first verification RES, MAC, authentication parameters, and service parameters sent by the second network device at the same time, but only carries the MAC, authentication parameters, and service parameters in the first message and sends it to the first device; accordingly, after the first device receives the first message, it carries the MAC, authentication parameters, and service parameters in the first message in the second message and sends it to the second device. It should also be pointed out that if the first verification RES is obtained by the second network device, the specific method for the second network device to calculate the first verification RES should be the same as the method for the first network device to calculate the first verification RES in the above embodiment, so it will not be repeated. In addition, the above-mentioned first message may also carry the identifier of the second device.

[0178] The parameters and specific calculation functions used by the second device to calculate the first RES and the first network device (or second network device) to calculate the first verification RES should be the same. For example, 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 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; for another example, 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 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.

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

[0180] In this case, the first device can authenticate the second device instead of the first network device, and the processing after the first device receives the third message from the second device may include: the first device determines that the authentication of the second device is successful when the first RES is the same as the first verification RES. In this example, the way the first network device obtains the first verification RES and the way the second device obtains the first RES are the same as the above examples, so they are not repeated. Furthermore, the first device can also send a response message to the second device. For example, when the first device determines that the authentication of the second device is successful, the first device sends a response message to the second device, and the response message responds to the third message. The response message is used to indicate that the core network side device has successfully authenticated the second device.

[0181] In some possible examples, the third message carries the second RES.

[0182] In this case, the processing after the first device receives the third message from the second device may include: if the second verification RES is the same as the second RES, the first device determines that the second device is authenticated. Further, it may also include: the first device sends a response message to the second device, where the response message is used to indicate that the authentication of the second device is successful.

[0183] Accordingly, the processing of the second device may include: the second device receiving a response message from the first device, the response message being a response to the third message, and the response message being used to indicate that authentication of the second device is successful.

[0184] Exemplarily, in indirect mode, the second device is connected to the core network through a terminal device and a first access network device corresponding to the terminal device. In this case, the first device is a terminal device. In addition, when the first device is a terminal device, the first device can be a proxy UE or a relay UE. In this example, the terminal device (such as a UE) verifies the second RES and determines that the second device is authenticated if the second verification RES is the same as the second RES.

[0185] Exemplarily, in direct mode, the second device is connected to the core network through a corresponding access network device. In this case, the first device is an access network device (for example, it can be an access network device corresponding to the second device), or the first device can be a first core network device, for example, it can be at least one of an AMF, a SEAF, a core network element dedicated to AIoT (or IoT), etc. In this example, the access network device (such as a gNB) or the first core network device (such as an AMF, a SEAF, a core network element dedicated to AIoT) verifies the second RES, and if the second verification RES is the same as the second RES, it is determined that the second device is authenticated.

[0186] In addition, it may also include: when the second verification RES is different from the second RES, the first device determines that the authentication of the second device fails, and then ends the processing, or the first device sends a notification of authentication failure to the second device. The possible subsequent processing is not limited here.

[0187] The manner in which the second device calculates the second RES includes one of the following: the second device calculates the second RES based on the anonymous key and the first key using the first calculation manner, and the first key is related to the first device; the second device calculates the second RES based on the first random number and the first key using the first calculation manner; the second device calculates the second RES based on the first RES and the first key using the first calculation manner.

[0188] The first key may be at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

[0189] Among them, 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 the same key is shared between the second device and the first device, it is within the protection scope of this embodiment.

[0190] The first intermediate key may be calculated in the following manner: using the second calculation method to calculate the first intermediate key based on the identifier of the first device and the 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.

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

[0192] The above-mentioned first device may be the above-mentioned terminal device, and accordingly, the identifier of the first device may be the UE ID; the above-mentioned first device may be the above-mentioned first access network device, and accordingly, the identifier of the first device may be expressed as the gNB ID (or eNB ID or ID of other possible types of access network devices); the above-mentioned first device may be the first core network device, and accordingly, the identifier of the first device may be expressed as the identifier of the first core network network element, or the intermediate network element identifier, or the core network element identifier, etc.

[0193] Taking the first device as the first core network device as an example, the above-mentioned second calculation method is used to calculate the first intermediate key based on the identifier of the first device and the second random number, which can be expressed as: Km=KDF(intermediate network element identifier, second random number). Alternatively, the second calculation method is used to calculate the first intermediate key based on the identifier of the first device, the second random number and the anonymous key, which 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 above-mentioned first device is a terminal device, the calculation formula of the above-mentioned first intermediate key can be adaptively replaced with Km=KDF(UE ID, second random number) or Km=KDF(AK, UE ID, second random number). If the above-mentioned first device is a first access network device, it can also be adaptively replaced, and they are not listed one by one here.

[0194] In addition, the above-mentioned second random number can be sent by the first device to the second device; this embodiment does not limit the generation method and sending timing of 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 is executed, it is within the protection scope of this embodiment and is not exhaustively listed here.

[0195] Exemplarily, taking the first calculation method as the second authentication function as an example, the second device uses the first calculation method to calculate the second RES based on the anonymous key and the physical layer key, which can be expressed as: RES' = f2 (physical layer key, AK), where RES' represents the second RES, and the meaning of the other contents in the formula is the same as in the aforementioned embodiment and is not repeated. Alternatively, the second device uses the first calculation method to calculate the second RES based on the anonymous key and the first intermediate key, which can be expressed as: RES' = f2 (Km, AK), and the meaning of the contents in the formula is the same as in the aforementioned embodiment and is not repeated.

[0196] Exemplarily, taking the first calculation method as the second authentication function as an example, 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, and the meaning of the other contents in the formula is the same as in the aforementioned embodiment and is not 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), and the meaning of the contents in the formula is the same as in the aforementioned embodiment and is not repeated.

[0197] Exemplarily, taking the first calculation method as the second authentication function as an example, 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, RES represents the first RES, and the meaning of the other contents in the formula is the same as in the aforementioned embodiment and is not 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), and the meaning of the contents in the formula is the same as in the aforementioned embodiment and is not repeated.

[0198] The method for the first device to calculate the second verification RES includes one of the following: the first device uses the first calculation method to calculate the anonymous key and the first key to obtain the second verification RES; the first device uses the first calculation method to calculate the first random number and the first key to obtain the second verification RES; the first device uses the first calculation method to calculate the first verification RES and the first key to obtain the second verification RES. Exemplarily, 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 are not explained repeatedly. The description of the first key is the same as that of the previous embodiment and is not repeated.

[0199] Optionally, the authentication parameters received by the above-mentioned first device may include an anonymous key or a first random number; if the authentication parameters include an anonymous key, the first device may execute the processing of calculating the anonymous key and the first key using the first calculation method to obtain the second verification RES; if the authentication parameters include the first random number, the first device may calculate the first random number and the first key using the first calculation method to obtain the second verification RES.

[0200] Optionally, the first verification RES may be sent by the first network device to the first device. For example, the first message may also carry the first verification RES. If the first message carries the first verification RES, the first device may choose to use the 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 may 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 all possible scenarios are not exhaustively enumerated here.

[0201] Optionally, the first device may also obtain a root key. The first device may perform an XOR calculation based on the anonymous key included in the authentication parameters and the root key to obtain the first random number. Alternatively, the first device may perform an XOR calculation based on the first random number included in the authentication parameters and the root key to obtain the anonymous key. Alternatively, the first device may use the root key and authentication parameters in the same manner as the second device to generate the first verification RES. In this case, the first device may use any of the above methods to generate the second verification RES.

[0202] Exemplarily, taking the first calculation method as the second authentication function as an example, 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, and the meaning of other contents in the formula is the same as the previous embodiment and will not be repeated; if the first key is the first intermediate key, it can be expressed as XRES'=f2(Km, AK).

[0203] Exemplarily, taking the first calculation method as the second authentication function as an example, 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 that in the previous embodiment and will not be repeated. If the first key is the first intermediate key, it can be expressed as XRES'=f2(Km, RAND).

[0204] Exemplarily, taking the first calculation method as the second authentication function as an example, 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, XRES represents the first verification RES, and the meaning of other contents in the formula is the same as the previous embodiment and will not be repeated; if the first key is the first intermediate key, it can be expressed as XRES'=f2(Km, XRES).

[0205] The parameters (or parameter types) used by the second device to calculate the second RES and the first device to calculate the second verification RES, as well as the specific calculation functions, 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, 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; for another example, if the second device uses a hash algorithm to calculate the second RES based on the first RES and the physical layer key, 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.

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

[0207] In this case, 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; and the first device determining that the authentication of the second device is successful when the second verification RES is the same as the second RES. In addition, the processing may also include: the first device determining that the authentication of the second device is unsuccessful (or failed) when the second verification RES is different from the second RES.

[0208] The processing of the first network device may include: the first network device determines that the authentication of the second device is successful when the first RES is the same as the first verification RES. Further, it may also include: the first network device sends a notification to the first device that the authentication of the second device is successful. In addition, the processing of the first network device may also include: the first network device determines that the authentication of the second device is not successful (or failed) when the first RES is different from the first verification RES. When the first network device determines that the authentication of the second device is not successful (or failed), the first network device may end the processing, or the first network device sends a notification to the first device that the authentication of the second device has failed (or failed). The possible subsequent processing is not limited here.

[0209] The processing of the first device may also include one of the following: when the first device determines that the second device has been authenticated, and the first device receives a notification from the first network device that the authentication of the second device has been passed (or succeeded), sending a response message to the second device, the response message being used to indicate that the authentication of the second device has been passed; when the first device determines that the authentication of the second device has not been passed (or failed), and / or the first device receives a notification from the first network device that the authentication of the second device has failed (or failed), sending a response message to the second device, the response message being used to indicate that the authentication of the second device has failed (or failed). Furthermore, the response message may further carry content 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.

[0210] In this example, the manner in 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 the same as those in the previous embodiment and are not described repeatedly.

[0211] Regarding the aforementioned embodiment, it should be further explained that when the second device, the first device, and the first network device execute the aforementioned authentication method, only the second device may authenticate the core network side based on the verification MAC and MAC. Alternatively, the second device may authenticate the core network side based on the verification MAC and MAC, and further the first network device may authenticate the second device based on the first RES and the first verification RES, and / or the first device may authenticate 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.

[0212] In addition, since AK needs to be sent, MAC and XRES cannot be generated using algorithms that can be reversed, such as XOR. Since Kr is a unique and non-repeating key shared only between each second device and the core network side device, an attacker cannot obtain RAND or Kr even if he intercepts AK, so generating and sending AK is safe and has the characteristics of low power consumption. Sending MAC is also safe, and since MAC is generated based on Kr, only AUSF has Kr, so verifying MAC can verify the identity of the core network side device. Moreover, since RES is generated based on Kr, only the second device and the core network side device have Kr, so the core network side device can verify the identity of the second device by verifying 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, only the second device and the first device have a shared physical layer key, so the first device can verify the identity of the second device by verifying RES'.

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

[0214] The processing of the second device also includes: the second 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, and the encryption key is related to the key generation parameter and a fourth random number, and 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 sent data and / or decrypt received data.

[0215] The processing of the first device may also include: the first 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, and the encryption key is related to the key generation parameter and a fourth random number, and 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 sent data and / or decrypt received data.

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

[0217] Exemplarily, the key generation parameters are different from the authentication parameters. The key generation parameters may be obtained when the second device performs any one of the aforementioned processes of calculating and verifying the MAC, calculating the first RES, or calculating the second RES based on the authentication parameters. For example, if the authentication parameters include an anonymous key, a first random number is obtained when the second device performs any one of the aforementioned processes of calculating and verifying the MAC, calculating the first RES, or calculating the second RES, and the second device uses the first random number as the key generation parameter. For another example, if the authentication parameters include the first random number, an anonymous key is obtained when the second device performs any one of the aforementioned processes of calculating and verifying the MAC, calculating the first RES, or calculating the second RES, and the second device uses the anonymous key as the key generation parameter.

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

[0219] The above-mentioned integrity protection key is used to protect the integrity of the second device and the network entity (such as the first device). Among them, 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 (cell), gNB, CPE, AMF, UPF, MEC, etc. Since the second device side and the first device side need to generate their own integrity protection keys respectively for integrity protection processing, the parameters and calculation methods used by the second device and the first device side to generate their own 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 explain 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, and no repeated explanation is given.

[0220] The calculation of the integrity protection key includes one of the following: using a second calculation method to calculate the integrity protection key based on the anonymous key and a third random number; using the second calculation method to calculate the integrity protection key based on the first random number and the third random number; using the second calculation method to calculate the integrity protection key based on the anonymous key, the first key and the third random number; using the second calculation method to calculate the integrity protection key based on the first random number, the first key and the third random number; using the second calculation method to calculate the integrity protection key based on the second intermediate key and the third random number, the second intermediate key is related to the key generation parameter; using the second calculation method to calculate the integrity protection key 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 parameter.

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

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

[0223] Optionally, the second calculation method is used to calculate the integrity protection key based on the anonymous key and the third random number. For example, it can be expressed as: Wherein, KI represents the integrity protection key, NONCE1 represents the third random number, and AK represents the anonymous key; or it can be expressed as: KI = KDF(AK, NONCE1), wherein KDF() is a key derivation function, and the meaning of the other contents in the formula is the same as that in the aforementioned embodiment and is not repeated here; or it can be expressed as: KI = AK||NONCE1, wherein "||" represents direct calculation, and the meaning of the other contents in the formula is the same as that in the aforementioned embodiment and is not repeated here.

[0224] Optionally, a second calculation method is adopted to calculate the integrity protection key based on the anonymous key, the first key and a third random number.

[0225] For example, the first key may be a physical layer key, and the above process may be expressed as follows: Wherein, KI represents the integrity protection key, NONCE1 represents the third random number, AK represents the anonymous key, and the meanings of the other contents in the formula are the same as those in the aforementioned embodiment and are not repeated here. Alternatively, it can be expressed as: KI = KDF(physical layer key, AK, NONCE1), where KDF() is a key derivation function, and the meanings of the other contents in the formula are the same as those in the aforementioned embodiment and are not repeated here. Alternatively, it can be expressed as: KI = physical layer key || AK || NONCE1, where "||" represents direct calculation, and the meanings of the other contents in the formula are the same as those in the aforementioned embodiment and are not repeated here.

[0226] For example, the first key may be a first intermediate key. The generation method of the first intermediate key has been described in detail in the above embodiment and will not be repeated here. Accordingly, the above process can be expressed as follows: Where KI represents the integrity protection key, NONCE1 represents the third random number, AK represents the anonymity key, and Km represents the first intermediate key. Alternatively, it can be expressed as: KI = KDF(Km, AK, NONCE1), where KDF() is the key derivation function. The meaning of the other contents in this formula is the same as in the previous embodiment and is not repeated here. Alternatively, it can be expressed as: KI = Km||AK||NONCE1, where "||" represents direct calculation. The meaning of the other contents in this formula is the same as in the previous embodiment and is not repeated here.

[0227] 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. Similar replacements can be made for other calculation formulas, which will not be detailed here.

[0228] Optionally, the second calculation method is used to calculate the integrity protection key based on the first random number, the first key and the third random number.

[0229] Taking the first key as the physical layer key as an example, the AK (anonymous key) in the calculation formula of the above KI can be replaced with the first random number RAND, for example, Similar replacements can be made for other calculation formulas, which will not be detailed here.

[0230] Taking the first key as the first intermediate key as an example, the AK (anonymous key) in the calculation formula of the above KI can be replaced with the first random number RAND, for example, Similar replacements can be made for other calculation formulas, which will not be detailed here.

[0231] 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: using the third calculation method to calculate the second intermediate key based on the anonymous key; using the third calculation method to calculate the second intermediate key based on the first random number; using the third calculation method to calculate the second intermediate key based on the anonymous key and the first key; or using the third calculation method to calculate the second intermediate key based on the first random number and the first key.

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

[0233] In one possible example, a third calculation method is used to calculate the second intermediate key based on the anonymous key, which can be calculated using the following formula: Ka = f3(AK), where Ka represents the second intermediate key (or authentication key). In other possible examples, a third calculation method is used to calculate the second intermediate key based on the first random number, which can be expressed as Ka = f3(RAND). It should be understood that the above is only an example. In actual processing, the 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 an exhaustive example.

[0234] 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 calculated using the following formula: Ka = f3 (AK, physical layer key), where Ka represents the second intermediate key (or authentication key), f3() represents the third key generation function, and AK represents the anonymous key. The above calculation formula for Ka can also replace f3() with an exclusive OR, for example, it can be expressed as Alternatively, f3() or XOR calculation can be replaced by direct calculation "||", for example, the above formula can be expressed as Ka=AK||physical layer key. Alternatively, a third calculation method is used to calculate the second intermediate key based on the physical layer key and the first random number. The calculation formula of this example can replace the anonymous key (i.e. AK) in the calculation formula of the above example with the first random number (i.e. RAND), such as Ka=f3(RAND, physical layer key). Other possible calculation methods are the same as the above examples and will not be described 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.

[0235] 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 calculated using the following formula: Ka = f3(AK, Km). The second intermediate key is calculated based on the first intermediate key and the first random number using a third calculation method. In this example, the anonymous key (i.e., AK) in the calculation formula of the above example can be replaced with the first random number (i.e., RAND), for example, Ka = f3(RAND, Km). Other possible calculation methods are the same as in the above example and are not described in detail.

[0236] In each of the above examples of calculating the second intermediate key, a fifth random number may also be added. For example, the third calculation method is used to calculate the second intermediate key based on the physical layer key, the fifth random number, and the anonymous key. The above processing can be expressed as: Ka = f3 (AK, physical layer key, NONCE3), where NONCE3 represents the fifth random number; the fifth random number may be configured or sent by the first network device to the second device and / or the first device, and this embodiment does not limit it. For another example, the third calculation method is used to calculate the second intermediate key based on the anonymous key and the fifth random number. The following formula can be used for calculation: Ka = f3 (AK, NONCE3). The processing methods after adding the fifth random number in the above examples are not exhaustive here.

[0237] The second calculation method is used to calculate the integrity protection key based on the second intermediate key and the third random number, which can be expressed by the following formula: Wherein, KI represents the integrity protection key, Ka represents the second intermediate key, and NONCE1 represents the third random number. For example, the above KI calculation formula can also replace the XOR calculation with a direct calculation "||", for example, the above formula can be expressed as KI = Ka || NONCE1. For example, the above KI calculation formula can also use a KDF, for example, the above formula can be expressed as KI = KDF(Ka, NONCE1).

[0238] Optionally, the second device calculates the integrity protection key based on the third intermediate key and the third random number using a second calculation method.

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

[0240] In the process of calculating the third intermediate key, the difference from the previous example is that the root key is added to calculate the third intermediate key in this example.

[0241] In a 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. The calculation may be performed using the following formula:

[0242] Ka′=f3(Kr, RAND, physical layer key), where Ka′ represents the third intermediate key. The meanings of other contents in the above formula are the same as those in the above embodiment and are not repeated here. For example, the calculation formula of the third intermediate key can also replace f3() with XOR, for example, it can be expressed as Alternatively, f3() or the XOR calculation may be replaced by a direct calculation "||", for example, the above formula may be expressed as Ka'=Kr||RAND|| physical layer key.

[0243] Alternatively, if the first key is the first intermediate key, the third calculation method is used to calculate the third intermediate key based on the first intermediate key, the root key and the first random number. The following formula can be used for calculation: Ka′=f3(Kr, RAND, Km). The meaning of the content in the above formula is the same as that in the above embodiment and will not be repeated. For example, the calculation formula of the above third intermediate key can also replace f3() with XOR, or can also replace f3() or XOR calculation with direct calculation "||", which will not be exhaustive. It should be understood that Ka' is used to represent the third intermediate key in this example in order to distinguish it from Ka in the above embodiment that represents the second intermediate key. In some other possible examples, Ka' in the above formula can also be directly expressed as Ka, which will not be exhaustively listed here.

[0244] Alternatively, a third calculation method is used to calculate the third intermediate key based on the root key and the first random number, and the following formula can be used: Ka′=f3(Kr, RAND). In the above calculation formula for the third intermediate key, f3() can also be replaced by other methods such as XOR or direct calculation, which are not exhaustive here.

[0245] Alternatively, a third calculation method is used to calculate the third intermediate key based on the root key and the anonymous key, and the following formula can be used for calculation: Ka′=f3(Kr,AK). The meaning of the content in the above formula is the same as that in the above embodiment and will not be repeated. For example, the calculation formula of the above third intermediate key can also replace f3() with XOR, or f3() or XOR calculation can also be replaced with direct calculation "||", which will not be exhaustive. It should be understood that Ka' is used to represent the third intermediate key in this example in order to distinguish it from Ka in the above embodiment that represents the second intermediate key. In some other possible examples, Ka' in the above formula can also be directly expressed as Ka, which will not be exhaustively listed here.

[0246] Correspondingly, 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: Wherein, KI represents the integrity protection key, NONCE1 represents the third random number, and the meaning of the other contents in the formula is the same as that in the above embodiment and is not repeated here. The XOR calculation in the above formula can also be replaced by direct calculation or KDF calculation, which is not repeated here.

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

[0248] The fourth intermediate key is calculated based on the root key and the first random number using the third calculation method, which can be expressed as: Among them, Ka″ represents the fourth intermediate key, and the meaning of other contents in the formula is the same as that in the aforementioned embodiment and is not repeated here. It should be understood that Ka″ is used to represent the fourth intermediate key in this example in order to distinguish it from the second intermediate key represented by Ka and the third intermediate key represented by Ka' in the aforementioned embodiment. In some other possible examples, Ka″ in the above formula can also be directly expressed as Ka, which is not exhaustive here. In addition, the XOR calculation in the above formula can also be replaced by KDF or direct calculation, which is not repeated here one by one.

[0249] Taking the first key as the physical layer key as an example, the second calculation method is used to calculate the third intermediate key based on the fourth intermediate key and the physical layer key, which can be expressed as: Kb=f2(physical layer key, Ka″), where kb is the third intermediate key. The meaning of other contents in this formula is the same as that in the previous embodiment and will not be repeated.

[0250] Taking the first key as the first intermediate key as an example, the second calculation method is used to calculate the third intermediate key based on the fourth intermediate key and the physical layer key, which can be expressed as: Kb=f2(Km, Ka″). The meaning of the content in this formula is the same as that in the aforementioned embodiment and is not repeated here. The above f2() can also be replaced by other calculation methods in the aforementioned second calculation method, which are not repeated here one by one.

[0251] The third intermediate key is calculated based on the fourth intermediate key using the second calculation method, which can be expressed as: Kb=f2(Ka″). f2() in the above examples can also be replaced by other calculation methods in the above second calculation method, which will not be described here one by one.

[0252] Accordingly, the integrity protection key is calculated based on the third intermediate key and the third random number using the second calculation method, which can be expressed as: Among them, KI represents the integrity protection key, NONCE1 represents the third random number, and the meaning of other contents in the formula is the same as that in the aforementioned embodiment and will not be repeated here. The XOR calculation in the above formula can also be replaced by direct calculation or KDF calculation, which will not be repeated here. In addition, in this embodiment, in order to distinguish it from the third intermediate key represented by Ka' in the aforementioned embodiment, the third intermediate key is represented as kb. In actual processing, the above Ka″ and kb can also be replaced with alternative representations. As long as the calculation method is the calculation method provided in this example, it is within the protection scope of this embodiment.

[0253] It should be noted that the above description of integrity protection key generation is based on an electronic device as the execution subject. If the electronic device is a second device, it can perform any one or more of the aforementioned processes for generating integrity protection keys, and detailed description is omitted. If the electronic device is a first device, if the first device can obtain the root key, the first device can perform the aforementioned processes for generating the third intermediate key and the fourth intermediate key. Furthermore, because the first device possesses the physical layer key, it can also perform the aforementioned processes for generating the second intermediate key.

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

[0255] 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 also 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 uses a third calculation method to calculate the third intermediate key based on the physical layer key, the root key, and the first random number, and the physical layer key is a key shared between the second device and the first device; the first network device uses the third calculation method to calculate the fourth intermediate key based on the root key and the first random number; the first network device uses the second calculation method to calculate the third intermediate key based on the fourth intermediate key and the physical layer key; the first network device uses the third calculation method to calculate the second intermediate key based on the physical layer key and the anonymous key; the first network device uses the third calculation method to calculate the second intermediate key based on the physical layer key and the first random number.

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

[0257] The first network device receiving at least one of the second intermediate key, the third intermediate key, and the fourth intermediate key sent by the second network device may mean that the first network device directly obtains at least one of the second intermediate key, the third intermediate key, and the fourth intermediate key from the second network device. The specific process of the second network device generating each intermediate key is the same as in the previous embodiment and is not repeated here.

[0258] Regarding the above-mentioned process of 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, 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.

[0259] In addition, the above is only an exemplary description. When actually generating the integrity protection key, other parameters may be added, such as the identifier of the second device. All possible parameters are not exhaustively listed here.

[0260] In the above example, if a physical layer key is used, since the physical layer key is a shared key generated between the second device and the first device through the channel source characteristics of the air interface, it has Shannon information theory security. Therefore, sending the third random number (i.e., NONCE1) is safe, and the integrity protection key generated using the third random number and the physical layer key is also safe. In addition, since the physical layer key does not require cryptographic calculations, it has the characteristics of low power consumption and is more suitable for use in AIOT devices. Since the physical layer key is a shared key between the second device and the first device, only a specific first device can obtain the correct integrity protection key and then verify the integrity of the message. Even if an attacker obtains the third random number, he cannot obtain the integrity protection key. Therefore, the integrity protection key is secure.

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

[0262] The second device side and the first device side need to generate their own encryption keys respectively to encrypt the data transmitted between the two. The parameters and calculation methods used by the second device and the first device to generate their own 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 the encryption keys. It should be pointed out that the electronic device in this example can be either the second device or the first device, and no repeated explanation will be given.

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

[0264] The calculation of the encryption key may include one of the following: using the second calculation method to calculate the encryption key on the fourth random number and the anonymous key; using the second calculation method to calculate the encryption key based on the first random number and the fourth random number; using the second calculation method to calculate the encryption key based on the anonymous key, the first key and the fourth random number; using the second calculation method to calculate the encryption key based on the first random number, the first key and the fourth random number; using the second calculation method to calculate the encryption key based on the second intermediate key and the fourth random number, the second intermediate key is related to the key generation parameter; using the second calculation method to calculate the encryption key based on the third intermediate key and the fourth random number, the third intermediate key is related to the root key and the key generation parameter.

[0265] The calculation method of the second intermediate key and the third intermediate key is the same as that in the previous embodiment, and thus will not be repeated in this embodiment.

[0266] Optionally, the encryption key is calculated based on the anonymous key and the fourth random number using the second calculation method. For example, it can be expressed as: Wherein, Kc represents the encryption key, NONCE2 represents the fourth random number, and AK represents the anonymous key; or it can be expressed as: Kc = KDF(AK, NONCE2), wherein KDF() is a key derivation function, and the meaning of the other contents in the formula is the same as that in the aforementioned embodiment and will not be repeated; or it can be expressed as: Kc = AK||NONCE2, wherein "||" represents direct calculation, and the meaning of the other contents in the formula is the same as that in the aforementioned embodiment and will not be repeated.

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

[0268] For example, the first key may be a physical layer key. Then, the encryption key is calculated using the second calculation method on the fourth random number, the physical layer key, and the anonymous key, which can be expressed as: Among them, Kc represents the encryption key, NONCE2 represents the fourth random number, AK represents the anonymous key, and the meanings of the other contents in the formula are the same as those in the aforementioned embodiment and are not repeated here. For another example, the encryption key is calculated using the second calculation method for the fourth random number, the physical layer key and the anonymous key, which can be expressed as: Kc = KDF (physical layer key, AK, NONCE2), wherein KDF() is a key derivation function, and the meanings of the other contents in the formula are the same as those in the aforementioned embodiment and are not repeated here. For another example, the integrity protection key is calculated based on the physical layer key, the anonymous key and the third random number using the second calculation method, which can be expressed as: Kc = physical layer key || AK || NONCE2, wherein "||" is a direct calculation, and the meanings of the other contents in the formula are the same as those in the aforementioned embodiment and are not repeated here.

[0269] For example, the first key may be a first intermediate key. Then, the encryption key is calculated using the second calculation method on the fourth random number, the first intermediate key, and the anonymous key, which can be expressed as: Wherein, 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 expressed as: Kc = KDF(Km, AK, NONCE2), where KDF() is the key derivation function. The meaning of the other contents in this formula is the same as in the above embodiment and is not repeated here. Alternatively, it can be expressed as: Kc = Km||AK||NONCE2, where "||" represents direct calculation. The meaning of the other contents in this formula is the same as in the above embodiment and is not repeated here.

[0270] Optionally, a second calculation method is used to calculate the encryption key based on the first key, the first random number, and the fourth random number. That is, the AK (anonymous key) in the above calculation formula of Kc can be replaced with the first random number RAND. Similar replacements can be made for other calculation formulas, which are not detailed here.

[0271] Optionally, the encryption key is calculated using the second calculation method based on a second intermediate key and the fourth random number, where the second intermediate key is related to the physical layer key and the key generation parameter. Here, the second intermediate key is generated in the same manner as in the previous embodiment and is not further described. The second intermediate key can be represented as Ka.

[0272] 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: Wherein, 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 calculation "||", or can also be replaced with KDF, etc., which will not be repeated here.

[0273] Optionally, the second device calculates the encryption key based on the third intermediate key and the fourth random number using a second calculation method.

[0274] In a possible example, the encryption key is calculated based on the third intermediate key and the fourth random number using the second calculation method, which can be expressed as: Wherein, Kc represents the encryption key, NONCE2 represents the fourth random number, and the meaning of the other contents in the formula is the same as in the above embodiment and is not repeated here. The XOR calculation in the above formula can also be replaced by direct calculation or KDF calculation, which is not repeated here.

[0275] In another possible example, the encryption key is calculated based on the third intermediate key and the fourth random number using the second calculation method, which can be expressed as: The meaning of each content in this formula is the same as that in the above embodiment and is not repeated here. The XOR calculation in the above formula can also be replaced by direct calculation or KDF calculation, which is not repeated here. In the above example, the calculation method and generation parameters of Ka' and Kb are the same as those in the above embodiment, so they are not repeated here.

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

[0277] For example, the first network device may pre-negotiate with the second device to generate a pairwise master key (PMK) based on a shared root key during mutual authentication, and use the shared key as the third intermediate key. The first network device may then send the third intermediate key to the first device via a first message, thereby enabling the second and first devices to share the third intermediate key.

[0278] For example, the first key is a physical layer key, and the encryption key is calculated based on the first key, the third intermediate key, and the third random number using the second calculation method, which can be expressed as: Wherein, Ks represents the encryption key, NONCE1 represents the third random number, and PMK represents the third intermediate key. For another example, the following formula can be used for calculation: Ks = KDF(physical layer key, PMK, NONCE1), where KDF() is the key derivation function. The meaning of the other contents in this formula is the same as that of the above embodiment and is not repeated here. For another example, the following formula is used for calculation: Ks = physical layer key || PMK || NONCE1, where "||" represents direct calculation. The meaning of the other contents in this formula is the same as that of the above embodiment and is not repeated here.

[0279] It should also be noted that in the above-mentioned process of generating the integrity protection key, encryption key, first RES, second RES, MAC, first verification RES, second verification RES, and verification MAC, the identification of the second device and / or the identification of the first device can also be added. For example, when calculating the MAC (or verifying the 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 first intermediate key), the root key, the random number and the ID of the second device (and / or the ID of the first device) are used to perform an XOR calculation, etc., and all possible situations are not enumerated here.

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

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

[0282] Optionally, the third message further carries a third random number and / or a fourth random number.

[0283] Optionally, the second device receives a response message from the first device, the response message responds to the third message, and the response message carries 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.

[0284] Optionally, the first device sends a response message to the second device, the response message responds to the third message, and the response message carries 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.

[0285] Optionally, the second message further carries at least one of the following: the third random number, the third integrity verification code, the encrypted group key, and the fourth random number.

[0286] The following describes in detail the processes of transmitting the random numbers used to generate the integrity protection key and / or encryption key in the above-mentioned messages and obtaining the integrity verification code.

[0287] 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 a key generation parameter 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 a third random number and the third integrity verification code.

[0288] The processing of the second device may include: the second message also carries a third random number and the third integrity verification code; the second device calculates a 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 parameter 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; when the second verification result indicates that the integrity verification of the second message has passed, the second device calculates the verification MAC based on the authentication parameters and the root key.

[0289] That is, in this example, the third random number is generated by the first device, and when sending the second message, the first device performs integrity protection processing. The second device first derives the integrity protection key based on the third random number carried in the second message, and then verifies the third integrity verification code carried in the second message. If the second message integrity verification passes, the second device performs the aforementioned processing such as calculating and verifying the MAC.

[0290] The calculation by the first device based on the integrity protection key to obtain the third integrity verification code may refer to the calculation by the first device based on the integrity protection key of the original content of the second message to obtain the third integrity verification code. The original content of the second message may refer to content originally required to be carried by the second message, such as the first random number, the third random number, authentication parameters, and MAC.

[0291] The second device verifies the third integrity verification code based on the integrity protection key to obtain a third verification result, which may mean that the second device calculates the third code to be verified based on the original content of the second message based on the integrity protection key, and when the third code to be verified and the third integrity verification code are the same, obtains a second verification result to indicate that the integrity verification of the second message passes; when the third code to be verified and the third integrity verification code are different, obtains a second verification result to indicate that the integrity verification of the second message fails (or fails).

[0292] Furthermore, the third message also carries a first integrity verification code. After the second device completes the aforementioned MAC calculation and verification and sends the third message to the first device, it can calculate the first integrity verification code based on the integrity protection key from the original content of the third message. The second device then sends 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 described in the preceding embodiments and is not further described here.

[0293] Correspondingly, after the first device receives the third message from the second device, the processing of the first device may also include: the first device verifies the first integrity verification code based on the integrity protection key to obtain a third verification result; when 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, and the response message responds to the third message, and the response message is also used to indicate that the integrity verification of the third message has passed.

[0294] The second device calculating the first integrity verification code based on the original content of the third message using the integrity protection key may refer to the second device calculating the first integrity verification code based on the original content of the third message using the integrity protection key. The original content of the third message may refer to content that the second message originally needs to carry, and this list is not exhaustive.

[0295] 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 determine that the third random number carried by the second message has not been tampered with.

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

[0297] Here, the second device may be a device that generates a third random number when it is determined that the core network side device has passed authentication. Further, after the second device generates the integrity protection key, it calculates the 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 carry at least the third random number mentioned above. The other contents that can be carried in the original message are the same as those in the previous embodiment and will not be repeated.

[0298] The processing after the first device receives the third message includes: the first device generates an integrity protection key based on the key generation parameter and the third random number; the first device verifies the first integrity verification code based on the integrity protection key to obtain a fourth verification result; when the fourth 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 responds to the third message, the response message is used to indicate that the integrity verification of the third message has passed, and the response message carries the second verification code calculated based on the integrity protection key.

[0299] 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, which may include: the first device calculates a first code to be verified based on the original message included in the third message based on the integrity protection key, and verifies the code based on the first code to be verified and the first integrity verification code to obtain a fourth verification result. Furthermore, the verification based on the first code to be verified and the first integrity verification code to obtain a fourth verification result may include one of the following: if the first code to be verified and the first integrity verification code are the same, obtaining a fourth verification result indicating that the integrity verification of the third message has passed; if the first code to be verified and the first integrity verification code are different, obtaining a fourth verification result indicating that the integrity verification of the third message has failed. The specific processing by the first device of calculating the first code to be verified based on the original message included in the third message based on the integrity protection key to obtain the first code to be verified is similar to the processing by the second device of calculating the first integrity verification code based on the original message of the third message based on the integrity protection key, and will not be repeated here.

[0300] That is, since the parameters and calculation method used by the first device and the second device to generate the integrity protection key are the same, the first code to be verified and the first integrity verification code obtained by the first device should be the same, and then the first device can determine that the integrity verification has passed (or succeeded or completed).

[0301] Processing on the second device: The second device receives a response message from the first device, the response message being in response to the third message and carrying an indication that the integrity verification of the third message has passed, and a second integrity verification code. Furthermore, the second device verifies the second integrity verification code based on the integrity protection key, obtaining a first verification result.

[0302] 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 calculates a second code to be verified based on the original content contained in the response message based on the integrity protection key, and verifies the code based on the second code to be verified and the second integrity verification code to obtain the first verification result. Furthermore, the verification based on the second code to be verified and the second integrity verification code to obtain the first verification result may include one of the following: if the second code to be verified and the second integrity verification code are identical, obtaining a verification result indicating that the integrity verification of the response message has passed; if the second code to be verified and the second integrity verification code are different, obtaining a verification result indicating that the integrity verification of the response message has failed. The above-mentioned method for calculating the second code to be verified is similar to the method for the second device to calculate the first integrity verification code, except that the second device uses the original content in the response message to calculate the second code to be verified, which is not repeated here. The original content in the response message is not limited in this embodiment. In this case, the second code to be verified obtained by the second device should be identical to the second integrity verification code, and the second device can then determine that the integrity verification has passed (or succeeded or completed).

[0303] In some possible examples, the third message can also be sent directly from the second device to the first network device. Accordingly, after the first network device generates the integrity protection key, it generates its own verification code based on the integrity protection key. If the verification code generated by itself is the same as the first integrity verification code carried by the third message, it confirms that the integrity verification of the third message has passed. Then, it obtains the first RES from the third message. If the first RES is the same as the first verification RES stored by itself, it determines that the verification of the second device has passed. Furthermore, the first network device can also send a response message to the second device. The response message responds to the third message, and the response message can carry the second integrity verification code generated based on the integrity protection key. After the second device generates 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 is complete.

[0304] It should be noted that in this example, the third message can be forwarded by the first device to the first network device, and the response message can be forwarded by the first device to the second device. However, the first device does not further process the third message. The method for generating the third integrity protection key by the first network device can be the same as the method for generating the integrity protection key described above, and is not repeated here.

[0305] In a possible example, the second device and the first device respectively perform integrity verification on the received message based on their respective integrity protection keys, and if the verification passes, the second device and the first device may negotiate an encryption key.

[0306] Optionally, the second device may perform integrity protection on the third message when sending it. Accordingly, if the integrity of the third message is successfully verified, the first device generates an encryption key and sends a response message containing a fourth random number to the second device. The second device then generates an encryption key based on the fourth random number carried in the response message. The third message may be used to instruct the second device to complete authentication of the core network device.

[0307] In the processing performed by the first device, after the first device receives the third message, the method may further include: the first device generates a fourth random number; the first device obtains an encryption key based on the fourth random number and a key generation parameter; and the first device sends a response message to the second device, wherein the response message carries the fourth random number.

[0308] In the processing performed by the second device, the response message also carries a fourth random number; the method also 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 parameter.

[0309] Exemplarily, the condition for the first device to generate the fourth random number may include at least one of the following: passing the third message integrity verification and passing the second device authentication.

[0310] For example, if the aforementioned third message does not carry the second RES or the first RES, then the aforementioned first device generates a fourth random number, which may include: when the integrity verification of the third message is passed, the first device generates a fourth random number. That is, the aforementioned first device will only generate an encryption key when the integrity verification of the third message is passed. In this example, the aforementioned response message can also be used to indicate that the integrity verification of the third message is 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 aforementioned first device generates a fourth random number, which may also include: when the first device determines that the second device is authenticated and the third verification result indicates that the integrity verification of the third message is passed, the first device generates a fourth random number. Here, regarding determining that the second device is authenticated, it may include the first device receiving the authentication of the second device sent by the first network device at the same time, and / or the first device itself verifies that the second RES is the same as the second verification RES, determining that the second device is authenticated.

[0311] Optionally, if the second device passes the integrity verification of the second message, the second device may generate an encryption key when sending the third message and include the fourth random number in the third message. Correspondingly, if the first device passes the integrity verification of the third message, it may generate an encryption key based on the fourth random number included in the third message.

[0312] 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 generates a fourth random number; the second device calculates an encryption key based on the fourth random number and a key generation parameter.

[0313] The processing on the first device side is described 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 a key generation parameter.

[0314] Exemplarily, the conditions for the second device to generate the fourth random number may include at least one of the following: passing the integrity verification of the second message and completing authentication of the core network side device. The third message may be used to indicate that the second device has completed authentication of the core network side device, and the third message may also be used to indicate that the integrity verification of the second message has passed.

[0315] Exemplarily, the conditions for the first device to obtain the encryption key based on the fourth random number and the key generation parameter may include at least one of the following: the third message integrity verification is passed, and the first device determines that the second device is authenticated.

[0316] For example, if the third message does not carry the second RES or the first RES, 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, the first device obtains the encryption key if it determines that the second device has been authenticated and the third verification result indicates that the integrity verification of the third message has passed.

[0317] 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. The response message can carry indication information that the integrity verification of the third message has passed, and can also carry indication information that the authentication of the second device has passed.

[0318] 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 an encryption key to respectively obtain encryption keys, which are used to encrypt data transmitted between the second device and the first device.

[0319] 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 a key generation parameter; and the first device sending a response message to the second device, the response message carrying the fourth random number. The third message may be used only to instruct the second device to complete authentication of the core network side device.

[0320] In the processing performed by the second device, the response message also carries a fourth random number; the method also includes: the second device receives a response message from the first device, the response message responds to the third message, and the response message carries a fourth random number; the second device calculates an encryption key based on the fourth random number and a key generation parameter.

[0321] Exemplarily, if the third message does not carry the second RES, the first RES, or the first verification code, the first device can directly generate the fourth random number. Exemplarily, if the third message carries the second RES and / or the first RES, the first device generates the fourth random number upon determining that the second device has been authenticated. The description of determining that the second device has been authenticated is the same as in the previous embodiment and is not repeated here.

[0322] Optionally, the processing on 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. The processing on the first device is described as follows: the third message carries a fourth random number; the method further includes: the first device obtaining an encryption key based on the fourth random number and key generation parameters.

[0323] Exemplarily, the condition for the second device to generate the fourth random number may include completing authentication of the core network side device. The third message is used to instruct the second device to complete authentication of the core network side device.

[0324] Exemplarily, if the 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 when determining that the second device has passed authentication.

[0325] After the first device generates the encryption key, it may also send a response message to the second device. The response message may be used to indicate that the authentication of the second device is successful.

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

[0327] Exemplarily, the first device may send the integrity protection key and / or encryption key to a key management function entity. The key management function entity may store the integrity protection key and / or encryption key. Thus, when the first device and / or the second device moves, 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 system processing efficiency.

[0328] Exemplarily, the first device may send the second intermediate key and / or the third intermediate key to the key management function entity. The key management function entity may store the second intermediate key and / or the third intermediate key. Further, when the first device and / or the second device moves, 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. Instead, the first device and / or the second device or other devices directly generate their respective integrity protection keys and encryption keys based on the second intermediate key and / or the third intermediate key, thereby improving system processing efficiency.

[0329] The key management function entity may be any one or more network-side devices, such as an AMF, an access network device, a SEAF, an AUSF, etc. The access network device may be at least one of a base station, a gNB, an eNB, etc., and all possible devices are not exhaustively listed here. The key management function entity may be a key management service (KMS) entity or a key management function (KMF) entity.

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

[0331] Before the second device receives the second message sent by the first device, the method may further include: the second device sending an authentication request to the first device, where the authentication request carries an identifier of the second device.

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

[0333] The processing by the first network device may further include: the first network device receiving an authentication request from the first device, where the authentication request carries an identifier of the second device.

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

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

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

[0337] After the second device completes the authentication of the core network side device, the method may further include: the second device sends a third message to the first device, the third message being used to indicate that the second device has completed the authentication of the core network side device. Correspondingly, the method of the first device may further include: the first device receives a third message from the second device, the third message being used to indicate that the second device has completed the authentication of the core network side device; the first device sends a fourth message to the first network device, the fourth message being used to indicate that the second device has completed the authentication of the core network side device. The processing method of the first network device may further include: the first network device receives a fourth message from the first device, wherein the fourth message is used to indicate that the second device has completed the authentication of the core network side device.

[0338] The following is an illustrative description of the authentication method provided in the aforementioned embodiment in conjunction with FIG6 . In FIG6 , the second device is an A-IoT device (shown as A-IoT in FIG6 for simplicity), the first device is a UE, the first network device is an AUSF, and the second network device is a UDM and / or ARPF as an example. It should be understood that in FIG6 , the first network device and the second network device are combined and represented as AUSF / UDM / ARPF for simplicity. The authentication method processing flow of FIG6 includes:

[0339] The A-IoT device (i.e., A-IoT) and the core network side devices share a unique, non-repeated root key, Kr, which serves as the security credential of the A-IoT device. It should be understood that A-IoT is only one A-IoT device here. In actual processing, there can be multiple A-IoT devices. Since the processing of each A-IoT device is the same, it will not be described in detail one by one.

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

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

[0342] In step 603, AUSF forwards the authentication request to UDM / ARPF. UDM / ARPF generates a first random number RAND, and then generates anonymous keys AK, MAC, and XRES (i.e., the aforementioned first verification RES) based on Kr, and sends AK, MAC, and RES to AUSF.

[0343] For example, referring to FIG. 7a , the generation architecture of the above parameters may include: MAC=f2(Kr, AK), XRES=f2(Kr, RAND). Among them, f2 can also be replaced by HMAC-SHA-256, AES, ACSON, SNOW3G, ZUC and other algorithms. Since AK needs to be sent, MAC and XRES cannot be generated by algorithms that can be reversed, such as XOR. Since Kr is a unique and non-repeated key shared only by each A-IoT device and the core network, an attacker cannot obtain RAND or Kr even if he intercepts AK. Therefore, generating and sending AK is safe and has the characteristics of low power consumption. Sending MAC is also safe, and since MAC is generated based on Kr, only AUSF has Kr, so verifying MAC can verify the identity of the core network.

[0344] For example, referring to FIG. 7b , the generation architecture of the above parameters may 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, and ZUC.

[0345] In step 604, the AUSF sends an authentication response to the UE, which carries the AK and MAC, and may also carry the A-IoT ID. The authentication response is the first message in the aforementioned embodiment.

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

[0347] In step 606, after receiving the authentication response message, the A-IoT device calculates MAC', and after successfully verifying MAC based on MAC', determines that the AUSF identity is successfully verified and calculates RES. The RES in this step is the first RES in the above embodiment.

[0348] Exemplarily, the calculation method of the A-IoT device may include: MAC'=f2(Kr, AK), RES=f2(Kr, RAND). Since RES is generated based on Kr, and only A-IoT devices have Kr, the core network side device can verify the identity of the A-IoT device by verifying RES.

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

[0350] Exemplarily, the processing of this step may include: the A-IoT device generates a third random number, namely NONCE1; then based on the formula Calculate the integrity protection key. The XOR of KI is used to generate The algorithm can also be direct||, and the KDF algorithm can be HMAC-SHA-256. Other optional KI generation parameters include the A-IoT ID. This integrity protection key is used to protect the integrity of A-IoT devices and network entities. Network entities may include, but are not limited to, at least one of the following: UE or other network devices; other network devices may include: AP, small cell, gNB, CPE, AMF, UPF, MEC, etc. Because the physical layer key is a shared key generated between the A-IoT device and UE using the channel source characteristics of the air interface and has Shannon information theoretic security, sending NONCE1 is secure and does not leak the KI. The KI generated using NONCE 1 and the physical layer key is also secure. Furthermore, because the physical layer key does not require cryptographic calculations, it has low power consumption.

[0351] In step 608, the A-IoT device sends an authentication confirmation message to the UE. This message carries RES and NONCE1 (the third random number in the aforementioned embodiment). The A-IoT device integrity-protects the authentication confirmation message with KI before sending it. The authentication confirmation message in this step is the third message in the aforementioned embodiment.

[0352] Step 609: After receiving the authentication confirmation message, the UE generates KI' and uses KI' to perform integrity verification on the authentication confirmation message.

[0353] This KI′ can be the integrity protection key on the UE side. In theory, KI′ should be the same as the aforementioned KI. This example uses different symbols to distinguish the integrity protection keys generated by different devices. This example uses a physical layer key to generate the integrity protection key KI. Because 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, only this specific UE can verify the integrity of the message. In addition, only a specific UE can obtain the physical layer key. Therefore, even if an attacker obtains NONCE1, they cannot obtain KI, and KI is secure.

[0354] Step 610: After the UE completes the integrity check and confirms that the RES has not been tampered with, it sends an authentication confirmation to the AUSF, which carries the RES; and generates a fourth random number (NONCE 2), and uses NONCE2 to generate an encryption key (Kc), which is used to encrypt and protect messages between the UE and the A-IoT device. The authentication confirmation can be the fourth message in the aforementioned embodiment. For example,

[0355] In step 611, the UE sends an authentication response to the A-IoT device, which is previously integrity-protected with KI′ and carries NONCE2. Here, the authentication response can be the response message in the aforementioned embodiment, that is, 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 and has Shannon information theory security, only a specific UE can obtain the physical layer key. Therefore, even if an attacker obtains NONCE2, the physical layer key cannot be obtained. Kc generated using NONCE2 and the physical layer key is also secure. In addition, since the physical layer key does not require cryptographic calculations, Kc generation has the characteristics of low power consumption.

[0356] Step 612: The UE sends Kc and KI′ to the KMS entity on the network side.

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

[0358] In step 613, the A-IoT device receives the authentication response, verifies the integrity of the NONCE2 using KI, confirms that NONCE2 has not been tampered with, and generates Kc using NONCE2. The generation method of Kc is the same as the previous example and will not be repeated here.

[0359] In addition, step 614 can also be executed on the AUSF side to verify RES. The specific method of AUSF verifying RES is the same as that in the previous embodiment and will not be repeated.

[0360] In conjunction with Figure 8, the key generation architecture is exemplified, and the root key Kr is shared on the A-IoT device side and the AUSF / UDM / ARPF side; in the process of negotiating KI and Kc, the A-IoT device and the UE side use the same method to obtain their respective Kc and KI, wherein KI is obtained by using the physical layer key, AK and a third random number (i.e., NONCE1), and Kc is obtained by using the physical layer key, AK and a fourth random number. Finally, the UE will send Kc and KI to the KMS, so that the UE, the A-IoT device and the KMS share the same Kc and KI. In Figure 8, the physical layer key is optional and is therefore represented as a dotted box, that is, in some possible examples, KI is obtained by using AK and a third random number (i.e., NONCE1), and Kc is obtained by using AK and a fourth random number. The various possible examples of generating KI and Kc are the same as those in the previous embodiment and will not be repeated here. In FIG8 , 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, no distinction is made in FIG8 .

[0361] In conjunction with Figure 8, another exemplary description of the key generation architecture is provided. The root key Kr is shared between the A-IoT device and the AUSF / UDM / ARPF side. In the process of negotiating KI and Kc, the A-IoT device and the access network device (such as the gNB in ​​Figure 8) use the same method to obtain their respective Kc and KI. KI is obtained by using the physical layer key (optional), AK, and a third random number (i.e., NONCE1). Kc is obtained by using the physical layer key (optional), AK, and a fourth random number. Finally, the access network device sends Kc and KI to the KMS, so that the access network device, A-IoT device, and KMS share the same Kc and KI.

[0362] In conjunction with Figure 8, another exemplary description of the key generation architecture is given. The root key Kr is shared on the A-IoT device side and the AUSF / UDM / ARPF side. In the process of negotiating KI and Kc, the A-IoT device and the first core network device (such as any one of the various first core network devices in the aforementioned embodiment, not exhaustively listed here) obtain their respective Kc and KI in the same way, wherein KI is obtained by using the physical layer key (optionally), AK and a third random number (i.e., NONCE1), and Kc is obtained by using the physical layer key (optionally), AK and a fourth random number. Finally, the first core network device will send Kc and KI to the KMS, so that the first core network device, the A-IoT device and the KMS share the same Kc and KI.

[0363] The processing flow of the above-mentioned authentication method is simpler than the AKA process of the prior art. The A-IoT device can obtain RES and MAC through simple operations such as XOR and f2, thereby completing two-way authentication with the network. In addition, the key negotiation process is also simplified. In the above-mentioned authentication method, the A-IoT device and the UE (or other authentication agent devices, such as AP, small cell, CPE, etc.) obtain a shared key (including an encryption key and an integrity protection key) based on the physical layer key and XOR operation. If necessary, the UE shares the session key with the KMS for mobility or to generate other keys. In addition, in the above-mentioned example, the UE can also be replaced by an access network device, so that both indirect and direct modes can be matched, and the above-mentioned UE or AUSF can verify the A-IoT device. For example, the AUSF can send the XRES to the UE, and the UE performs the verification of the RES. The above example has 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 is more secure. The A-IoT device does not need to use more complex calculation methods, such as KDF to generate keys. The UE can act as an authentication agent to complete the authentication.

[0364] In conjunction with Figure 9, another exemplary description of the authentication method provided in the above embodiment is given. In Figure 9, taking the second device as an A-IoT device (illustrated 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 as an example, it should be understood that in Figure 9, for simplicity, the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. The authentication method processing flow of Figure 9 includes:

[0365] The processing of steps 901 to 904 is the same as that of steps 601 to 604 in the example of FIG. 6 , and thus will not be described in detail.

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

[0367] For example, Ka = f3(AK, physical layer key), where Ka is the second intermediate key in the aforementioned embodiment. Because the physical layer key is a shared key generated between the A-IoT device and the UE using the channel source characteristics of the air interface and has Shannon information theoretic security, Ka is secure. The authentication response received by the UE may be the first message in the aforementioned embodiment.

[0368] Exemplarily, Ka=f3(AK, NONCE3), that is, the physical layer key may not be used to obtain Ka, but the fifth random number NONCE3 may be used to calculate the authentication key.

[0369] Exemplarily, Ka=f3(AK, physical layer key, NONCE3), that is, the authentication key can be calculated using AK, the physical layer key and the fifth random number.

[0370] In step 906, the UE forwards the authentication response to the A-IoT device, including the AK and MAC. The authentication response sent by the UE to the A-IoT device may be the second message of the aforementioned embodiment.

[0371] In step 907, after receiving the authentication response, the A-IoT device calculates MAC', and after successfully verifying MAC based on MAC', determines that the AUSF identity is successfully verified, calculates RES, and calculates the authentication key Ka.

[0372] For example, MAC' = f2(Kr, AK), RES = f2(Kr, RAND), Ka = f3(AK, physical layer key), where MAC' is the verification MAC. Because the f3 function is required, power consumption is higher. 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.). Ka can be used to generate Kc and KI, and can also generate keys between A-IoT devices and other devices, providing greater flexibility.

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

[0374] 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 the KI can also be a direct connection||, a KDF algorithm such as HMAC-SHA-256, etc. Other optional KI generation parameters can also include the A-IoT ID.

[0375] In step 909, the A-IoT device sends an authentication confirmation message to the UE, carrying RES and NONCE1. In this step, the A-IoT device uses KI to integrity-protect the authentication confirmation message before sending it. This authentication confirmation message can be the third message in the above embodiment.

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

[0377] In this step In this example, no distinction is made between the integrity protection key generated by the UE and the integrity protection key generated by the A-IoT device.

[0378] Step 911: After the UE completes the integrity check and confirms that the RES has not been tampered with, it sends an authentication confirmation to the AUSF, which carries the RES; and generates a fourth random number (NONCE 2), and uses NONCE2 to generate an encryption key (Kc), which is used to encrypt and protect messages between the UE and the A-IoT device. The authentication confirmation can be the fourth message in the aforementioned embodiment. For example,

[0379] In step 912, the UE sends an authentication response to the A-IoT device, using the KI to protect the integrity of the authentication response message before sending it. The authentication response message carries NONCE2.

[0380] In step 913, the UE sends Ka to the network-side key management function KMF entity. Steps 912 and 913 may be processed in any order.

[0381] In step 914, the A-IoT device receives the authentication response, verifies the integrity with KI, confirms that NONCE2 has not been tampered with, and generates Kc with NONCE2. The generation method of Kc is the same as step 911 and is not repeated here.

[0382] In addition, step 915 can also be executed on the AUSF side to verify RES. The specific method of AUSF verifying RES is the same as that in the previous embodiment and will not be repeated.

[0383] For example, with reference to FIG10 , the generation architecture of the above parameters may include: MAC=f2(Kr, AK), XRES=f2(Kr, RAND). Among them, f2 can also be replaced by HMAC-SHA-256, AES, ACSON, SNOW3G, ZUC and other algorithms. Since AK needs to be sent, MAC and XRES cannot be generated by algorithms that can be reversed, such as XOR. Since Kr is a unique and non-repeating key shared only by each A-IoT device and the core network, an attacker cannot obtain RAND or Kr even if he intercepts AK. Therefore, generating and sending AK is safe and has the characteristics of low power consumption. Sending MAC is also safe, and since MAC is generated based on Kr, only AUSF has Kr, so verifying MAC can verify the identity of the core network. Furthermore, an authentication key Ka is added, Ka=f3(AK, physical layer key).

[0384] In conjunction with Figure 11, the above-mentioned key generation architecture is exemplified. The root key Kr is shared on the A-IoT device side with the AUSF / UDM / ARPF side. In the process of negotiating KI and Kc, the authentication key Ka is first obtained based on AK and the physical layer key. The Ka is obtained by the UE and the A-IoT device in the same way. The Ka can be sent to the KMS, so that other A-IoT and other network elements can share the Ka. The key Ka can be used to share 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, and keys can also be generated between A-IoT devices and other devices, so it is more flexible. Furthermore, the UE and the A-IoT device each calculate Kc and KI in the same way, where Kc is obtained by combining Ka with a third random number (i.e., NONCE1), and Kc is obtained by combining Ka with a fourth random number. In FIG11 , the physical layer key is optional and is therefore represented by a dotted box. That is, in some possible examples, Ka may be obtained by combining AK with a fifth random number instead of using the physical layer key, which will not be elaborated.

[0385] Figure 11 illustrates another exemplary key generation architecture. The A-IoT device shares the root key Kr with the AUSF / UDM / ARPF. During the negotiation of KI and Kc, an authentication key Ka is first derived based on the AK and (optionally) the physical layer key. This Ka is derived identically by both the gNB and the A-IoT device. This Ka is 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 (UEs, or other network devices such as APs, small cells, gNBs, CPEs, AMFs, UPFs, and MECs). Ka can be used to generate Kc and KI, as well as to generate keys between the A-IoT device and other devices, providing greater flexibility. Furthermore, both the gNB and the A-IoT device calculate Kc and KI identically, with Kc derived from Ka combined with a third random number (i.e., NONCE1), and Kc derived from Ka combined with a fourth random number.

[0386] In conjunction with Figure 11, another exemplary description of the key generation architecture is given. The root key Kr is shared on the A-IoT device side with the AUSF / UDM / ARPF side; in the process of negotiating KI and Kc, the authentication key Ka is first obtained based on AK and the physical layer key (optionally). The Ka is obtained in the same way by the first core network device and the A-IoT device; the Ka can be sent to the KMS, so that other A-IoT and other network elements share the Ka. The key Ka can be used to share 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, and keys can also be generated between the A-IoT device and other devices, so it is more flexible. Furthermore, the first core network device and the A-IoT device each calculate Kc and KI in the same way, where Kc is obtained by combining Ka with a third random number (i.e., NONCE1), and Kc is obtained by combining Ka with a fourth random number.

[0387] In conjunction with Figure 12, the authentication method provided in the above embodiment is further exemplified. In Figure 12, the second device is an A-IoT device (illustrated as A-IoT for simplicity), the first device is a UE, the first network device is an AUSF, and the second network device is a UDM and / or ARPF. It should be understood that in Figure 12, the first network device and the second network device are combined and represented as AUSF / UDM / ARPF for simplicity. The authentication method processing flow of Figure 12 includes:

[0388] The processing of steps 1201 to 1205 is the same as that of steps 601 to 605 in the example of FIG. 6 , and thus will not be described in detail.

[0389] In step 1206, after receiving the authentication response message, the A-IoT device calculates MAC', and after successfully verifying MAC based on MAC', determines that the AUSF identity is successfully verified, and calculates RES (i.e., the first RES) and RES' (i.e., the aforementioned second RES).

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

[0391] RES' can be calculated in one of the following ways: RES'=f2(physical layer key, AK), RES'=f2(physical layer key, RAND), RES'=f2(physical layer key, RES).

[0392] It should be pointed out that the description in Figure 12 is based on the example of the first device being UE. In actual scenarios, the UE in Figure 12 can also be replaced by a core network element (that is, the first device can be a scenario in which the first core network device is a first core network device). In the case where the first device is a first core network device, the calculation method of the above-mentioned RES' can also be replaced by using the first intermediate key (Km) for calculation. For example, the calculation method of the above-mentioned Km, as in the aforementioned 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; accordingly, the calculation method of the above-mentioned RES' can be replaced by one of the following: RES'=f2(Km, RAND), RES'=f2(Km, RAND), RES'=f2(Km, RES).

[0393] Step 1207 is the same as step 607 in FIG. 6 and is not described in detail.

[0394] In 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 integrity-protects the authentication confirmation message with KI before sending it. For simplicity, the authentication confirmation message is referred to as "Authentication Confirmation" in Figure 11.

[0395] Step 1209: After receiving the authentication confirmation message, the UE generates KI′ and uses KI′ to perform integrity verification on the authentication confirmation message.

[0396] In step 1210, if the UE passes the integrity verification of the authentication confirmation message, the UE generates XRES' and verifies whether the received RES' is the same as the calculated XRES'.

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

[0398] When the received RES' is identical to the calculated XRES', subsequent steps 1211 to 1215 are executed. The specific descriptions of steps 1211 to 1215 are the same as those of steps 610 to 614 in the aforementioned example FIG. 6 and are not repeated here.

[0399] It should be noted that Figures 6, 9, and 12 above respectively provide exemplary illustrations of scenarios in which the first device is a UE in Indirect mode. In some possible examples, in Direct mode, the UE in Figures 6, 9, and 12 above may also be replaced with an access network device, such as a gNB, or the UE in Figures 6, 9, and 12 above may also be replaced with a first core network device, such as an AMF, SEAF, a core network element dedicated to AIoT (or IoT), and the like. All possible examples are not exhaustive here.

[0400] For example, in conjunction with FIG13 , the generation architecture of the above parameters in the authentication method processing flow illustrated in FIG12 may include: MAC = f2(Kr, AK), XRES = f2(Kr, RAND), XRES' = f2(physical layer key, AK), or XRES' can also be obtained based on XRES. Among them, f2 can also be replaced by algorithms such as HMAC-SHA-256, AES, ACSON, SNOW 3G, and ZUC. The example provided in Figure 13 uses XRES' (which can be replaced by the aforementioned RES') to increase the 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.

[0401] In conjunction with Figure 14, the authentication method provided in the above embodiment is further exemplified. In Figure 14, the second device is an A-IoT device (for the sake of simplicity, it is illustrated as A-IoT), the first device is a base station (the first device can be a base station or a UE), the first network device is AUSF, and the second network device is UDM and / or ARPF as an example. It should be understood that in Figure 14, for the sake of simplicity, the first network device and the second network device are combined and represented as AUSF / UDM / ARPF. The authentication method processing flow of Figure 14 includes:

[0402] Steps 1401 to 1402 are the same as steps 601 to 602 in the aforementioned example FIG. 6 and are not described in detail.

[0403] Step 1403, AUSF forwards the authentication request to UDM / ARPF, UDM / ARPF generates a first random number RAND, and then generates anonymous keys AK, MAC, XRES (ie the aforementioned first verification RES), Ka' based on Kr, and sends AK, MAC, XRES, Ka' to AUSF.

[0404] This example uses the third intermediate key of the aforementioned embodiment as an example, and represents the third intermediate key as Ka'. MAC=f2(Kr, AK), XRES=f2(Kr, RAND); this example uses the third intermediate key of the aforementioned embodiment as an example, and represents the third intermediate key as Ka'. Exemplarily, Ka'=f3(Kr, RAND, physical layer key).

[0405] In addition, the third intermediate key can be calculated without using the physical layer key, for example, Ka′=f3(Kr, RAND); or, for example, the third intermediate key can be calculated by replacing the physical layer key with the first intermediate key, for example, Ka′=f3(Kr, RAND, Km). Various exemplary calculation methods for the third intermediate key have been described in detail in the previous embodiments and will not be repeated here.

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

[0407] In step 1405, the base station sends an authentication response to the A-IoT device, which carries MAC and AK but does not carry Ka'.

[0408] In step 1406, the A-IoT device calculates MAC'. After successfully verifying MAC based on MAC', the AUSF identity is confirmed to be successfully verified. Ka' and the integrity protection key KI are calculated. In addition, the A-IoT device may also generate RES (i.e., the first RES mentioned above) in this step.

[0409] The key Ka' or KI is used to share between A-IoT devices and network entities (UE, or other network devices such as AP, small cell, gNB, CPE, AMF, UPF, MEC, etc.).

[0410] Exemplarily, the calculations performed by the A-IoT device may include at least one of the following: MAC'=f2(Kr, AK), RES=f2(Kr, RAND), Ka'=f3(Kr, RAND, physical layer key).

[0411] Furthermore, the A-IoT device generates a random number NONCE1 (i.e., the aforementioned third random number), and generates KI after generating Ka' in the following manner:

[0412] Exemplarily, the fourth intermediate key Ka″ can be calculated in step 1403, that is, Furthermore, both the base station and A-IoT can generate Kb based on the fourth intermediate key using the following formula: Kb = f2 (physical layer key, Ka ″); both the base station and A-IoT can generate KI based on Kb, for example, expressed as

[0413] In the above example, Ka' and Ka" generate the XOR that can be used interchangeably. algorithm, direct connection algorithm||, KDF algorithm such as HMAC-SHA-256, f3(), etc. In addition, other optional Ka' generation parameters include A-IoT ID, NONCE, etc.

[0414] In step 1407, the A-IoT device sends an authentication confirmation message to the base station. The message carries the RES. The A-IoT device can use the KI to perform integrity protection on the authentication confirmation message before sending it.

[0415] In step 1408, after receiving the authentication confirmation message, the base station generates a KI and uses the KI to perform an integrity check on the authentication confirmation message. The KI then sends the authentication confirmation to the AUSF, which carries the RES. In this step, the base station may also generate a 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 not repeated here.

[0416] Step 1409: After the AUSF verifies that RES is passed, the A-IoT device is verified.

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

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

[0419] Exemplarily, in step 1404, the base station generates a KI after receiving the authentication response from the AUSF. 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, the A-IoT device also generates a KI after receiving the authentication response message, performs an integrity check on the authentication response message, thereby completing the KI negotiation and integrity protecting the authentication response message. In step 1406, the A-IoT device can generate a Kc, and when executing step 1407, before sending the authentication confirmation message, the message is secured and encrypted, and the fourth random number is carried 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 an integrity check based on the KI to complete the key negotiation.

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

[0421] It should be noted that Figure 14 above is an exemplary illustration of a scenario in which the first device is a base station in Direct mode. In some possible examples, in Direct mode, the base station in Figure 14 above can also be replaced by a first core network device, such as AMF, SEAF, a core network element dedicated to AIoT (or IoT), and so on. In some possible examples, in Indirect mode, the base station in Figure 14 above can also be replaced by a UE. All possible examples are not exhaustive here.

[0422] For example, referring to FIG15 , the generation architecture of the above parameters in the authentication method processing flow illustrated in FIG14 may include: MAC=f2(Kr, AK), XRES=f2(Kr, RAND), Ka′=f3(Kr, RAND, physical layer key).

[0423] In conjunction with Figure 16, the generation architecture of each of the above keys is exemplified. The root key Kr is shared on the A-IoT device side and the AUSF / UDM / ARPF side, and AK can be obtained based on the root key; on the A-IoT device side and the AUSF / UDM / ARPF side, Ka (i.e., Ka' in the aforementioned example) can be generated based on Kr and the physical layer key. In the process of negotiating KI and Kc between the A-IoT device side and the base station side, the A-IoT device and the base station use the same method to obtain their respective Kc and KI based on Ka. In addition, the base station will send Ka to KMS, so that the base station, A-IoT device, KMS and other network elements (the same as the aforementioned example will not be repeated) share the same Ka. In Figure 16, the physical layer key is optional and is therefore represented as a dotted box, that is, in some possible examples, Ka can be calculated without using the physical layer key. The various calculation methods are the same as those in the aforementioned embodiment and will not be repeated. In conjunction with Figure 16, another exemplary explanation of the generation architecture of each of the above keys is given. The root key Kr is shared on the A-IoT device side and the AUSF / UDM / ARPF side, and AK can be obtained based on the root key; on the A-IoT device side and the AUSF / UDM / ARPF side, Ka (that is, Ka' in the above example) can be generated based on Kr and the physical layer key (optionally). In the process of negotiating KI and Kc between the A-IoT device side and the UE, the A-IoT device and the UE side use the same method to obtain their respective Kc and KI based on Ka. In addition, the UE will send Ka to the KMS, so that the UE, A-IoT device, KMS and other network elements (the same as the above example will not be repeated) share the same Ka. In conjunction with Figure 16, another exemplary explanation of the generation architecture of each of the above keys is given. The root key Kr is shared on the A-IoT device side and the AUSF / UDM / ARPF side, and AK can be obtained based on the root key; on the A-IoT device side and the AUSF / UDM / ARPF side, Ka (that is, Ka' in the aforementioned example) can be generated based on Kr and the physical layer key (optionally). In the process of negotiating KI and Kc between the A-IoT device side and the first core network device, the A-IoT device and the first core network device side use the same method to obtain their respective Kc and KI based on Ka. In addition, the first core network device will send Ka to KMS, so that the first core network device, A-IoT device, KMS and other network elements (the same as the aforementioned example will not be repeated) share the same Ka.

[0424] In conjunction with Figure 17, the authentication method provided in the above embodiment is further illustrated. In Figure 17, taking the second device as an A-IoT device (for simplicity, it is represented as A-IoT), the first device as an authentication device (Authenticator), and the first network device as an AS as an example, the processing flow includes:

[0425] The A-IoT device (i.e., A-IoT) and the AS share a unique root key Kr. For example, the AS and A-IoT can generate a pairwise master key (PMK) after mutual authentication. The AS sends the PMK to the Authenticator in the authentication response message. The A-IoT and the Authenticator share the PMK (in the aforementioned embodiment, the PMK is referred to as the third intermediate key).

[0426] In step 1701, the A-IoT device sends an authentication request to the authenticator, carrying the A-IoT ID.

[0427] In step 1702, the authenticator forwards the authentication request to the AS, carrying the A-IoT ID.

[0428] In step 1703, the AS generates a first random number RAND, and then generates an anonymous key AK, MAC, and XRES (ie, the aforementioned first verification RES) based on Kr.

[0429] For example, referring to FIG17 , the generation methods of 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.

[0430] In step 1704, the AS sends an authentication response to the Authenticator, which carries the AK, MAC, and PMK. The authentication response may also carry the A-IoT ID. This authentication response is the first message in the aforementioned embodiment.

[0431] In step 1705, the Authenticator forwards the authentication response to the A-IoT device, carrying the AK and MAC. The authentication response message in this step is the second message in the above embodiment.

[0432] In step 1706, after receiving the authentication response message, the A-IoT device calculates MAC' and successfully verifies MAC based on MAC', confirming that the AS identity has been successfully verified and calculating RES. The RES in this step is the first RES in the above embodiment.

[0433] For example, the calculation of AIOT devices may include: MAC'=f2(Kr,AK), RES=f2(Kr,RAND).

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

[0435] Exemplarily, the processing of this step may include: the A-IoT device generates a third random number, namely NONCE1; then based on the formula Calculate the integrity protection key. Ks is generated using the XOR The algorithm can also be direct connection||, KDF algorithm such as HMAC-SHA-256, etc. Other optional Ks generation parameters include A-IoT ID, etc.

[0436] In step 1708, the A-IoT device sends an authentication confirmation message to the Authenticator. The message carries RES and NONCE1 (ie, the third random number in the aforementioned embodiment). The authentication confirmation message in this step is the third message in the aforementioned embodiment.

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

[0438] Step 1710: The Authenticator sends an authentication confirmation to the AS, and the authentication confirmation carries a RES.

[0439] In step 1711, the Authenticator sends an authentication response to the A-IoT device. The authentication response may be the response message in the aforementioned embodiment, that is, a response message in response to the third message.

[0440] In addition, the AS side may also perform step 1712 to verify the RES. The specific method of the AS verifying the RES is the same as that in the above embodiment and will not be repeated.

[0441] In conjunction with Figure 18, the generation architecture of the various keys in Figure 17 is illustrated. The A-IoT device and the AS share a root key, Kr; AK is derived based on this Kr. During the negotiation of Ks, the A-IoT device and the authentication device use the same method to combine the physical layer key and PMK to derive their respective Ks. In Figure 18, the physical layer key is optional and is therefore represented by a dashed box. This means that in some possible examples, Ks can be calculated without using the physical layer key, which is not described in detail.

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

[0443] Optionally, the authentication process may be triggered by the server.

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

[0445] The above-mentioned server can be a server with AIoT service functions, such as AF, or other servers, or called A-IoT network elements, which are not limited here.

[0446] After receiving the trigger message from the server, the first network device may execute the process of sending the first message in the aforementioned embodiment.

[0447] Optionally, the trigger message carries only the identifier of the second device. Correspondingly, the first message carries only the identifier of the second device. The first message may also be referred to as an authentication request (or authentication request message). The second device and the first device may subsequently perform the same processing as in the aforementioned embodiment, such as exchanging the second and third messages, which will not be repeated here.

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

[0449] Furthermore, the first message also carries an identifier of the device group to which the second device belongs, and the second message is used to request authentication. After the first device receives the first message, the first device sends a second message to the second device. The first device sending the second message 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 a key generation parameter; the first device encrypting the group key based on the encryption key to obtain an encrypted group key; and the first device sending the second message to the second device, the second message also carrying the encrypted group key and the fourth random number.

[0450] The method of generating the above encryption key is the same as that in the previous embodiment and will not be repeated.

[0451] Optionally, the first device may further generate the group key. The generation method of the group key may include one of the following: 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 identifier of each device, and the third random number;

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

[0453] The first device calculates the group key using the third calculation method 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;

[0454] 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 identifier of each device, and the third random number;

[0455] The first device calculates the group key by 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 key of each device, the identifier of each device, and the third random number;

[0456] The first device calculates the group key using the third calculation method 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;

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

[0458] The third calculation method described above is the same as that in the previous embodiment and is not described again. In the following examples, the third calculation method is described using KDF as an example, and other methods for calculating the group key that may be included in the third calculation method are not exhaustive. The third random number described above may be generated by the first device, and its generation method is not limited.

[0459] Exemplarily, the intermediate key of each of the above-mentioned devices can be the second intermediate key of each device, or the third intermediate key of each device, or the fourth intermediate key of each device. The calculation method of the second intermediate key, the third intermediate key and the fourth intermediate key of each device is the same as the calculation method of the aforementioned second intermediate key, the third intermediate key and the fourth intermediate key, so they are not repeated in this embodiment.

[0460] Exemplarily, the intermediate key of each of the above-mentioned devices may also be the fourth intermediate key of each device, that is, an intermediate key obtained in a manner different from that of the aforementioned embodiment. The fourth intermediate key may be calculated based on the key generation parameters and the device identification using a third calculation method, and the key generation parameters include an anonymous key and a first random number. For example, the fourth intermediate key of any of the above-mentioned devices may be calculated using the following formula: Ka = f3 (AK, RAND, A-IOT ID), where A-IoT ID is the device identification. It should be understood that the above is merely an exemplary description, and the generation method of the intermediate key of each device is not exhaustive.

[0461] Optionally, taking the case where the first key of each device is 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:

[0462] Among them, K-Group represents the group key, KDF() represents the KDF calculation function, AK A-IoT-1 ~AK A-IoT-i Represents the anonymous key of each device, and performs XOR calculation on the anonymous key of each device, where i represents the i-th device in the device group, i is a positive integer, "||" represents direct connection calculation, PK A-IoT-1 ~PK A-IoT-i Represents the physical layer key of each device, performs an XOR calculation on the physical layer key of each of the above devices, (A-IoTID-1, ..., A-IoTID-i) represents the identification of each device, UEID is the identification of the UE when the first device is a UE, base station ID is the identification of the base station when the first device is a base station (in some possible examples, the base station ID can also be represented as a base station IE), and NONCE1 represents a third random number. Optionally, in the above formula, the XOR calculation can be replaced by a direct calculation, and the direct calculation can also be replaced by an XOR calculation; optionally, (A-IoTID-1, ..., A-IoTID-i) can be replaced by an XOR calculation or a direct calculation for the identification of each device. The above various possible calculation methods are all within the protection scope of this embodiment and are not exhaustive.

[0463] 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 may be performed using the following formula:

[0464] Among them, Km A-IoT-1 ~Km A-IoT-i Represents the first intermediate key of each device. The meanings of the remaining parameters are the same as the above examples and are not exhaustive.

[0465] Optionally, a third calculation method is used 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. That is, the group key is calculated without using the first key. The following formula can be used to express the group key:

[0466] The meaning of each parameter in the formula is 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 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. The group key may be calculated using the following formula:

[0468] Among them, K-Group represents the group key, KDF() represents the KDF calculation function, AK A-IoT-1 ~AK A-IoT-i Represents the anonymous key of each device, and performs XOR calculation on the anonymous key of each device, where i represents the i-th device in the device group, i is a positive integer, "||" represents direct connection calculation, Ka A-IoT-1 ~Ka A-IoT-i represents the intermediate key of each device, and the intermediate key of each device is XORed. The meaning of other contents in the formula is the same as that in the above embodiment and will not be repeated.

[0469] Optionally, taking the case where the first key of each device is the physical layer key of each device as an example, 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 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:

[0470] Among them, K-Group represents the group key, KDF() represents the KDF calculation function, PK A-IoT-1 ~PK A-IoT-i Represents the physical layer key of each device, and performs XOR calculation on the physical layer key of each device, where i represents the i-th device in the device group, i is a positive integer, "||" represents direct connection calculation, Ka A-IoT-1~Ka A-IoT-i represents the intermediate key of each device, and the intermediate key of each device is XORed. The meaning of other contents in the formula is the same as that in the above embodiment and will not be repeated.

[0471] 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 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. The calculation may be performed using the following formula:

[0472] The meanings of the various contents of the formula are the same as those in the above embodiment and will not be repeated.

[0473] Optionally, taking the first key of each device as the physical layer key of each device as an example, 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 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:

[0474] The meaning of each content in the formula is the same as that in the above embodiment and will not be repeated.

[0475] In the above formula, XOR calculation can be replaced by direct calculation, and direct calculation can also be replaced by XOR calculation; optionally, (A-IoTID-1, ..., A-IoTID-i) can be replaced by XOR calculation or direct calculation for the identification of each device. The above various possible calculation methods are all within the protection scope of this embodiment and are not exhaustive.

[0476] Optionally, taking the first key of each device as the first intermediate key of each device as an example, 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 intermediate 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 meaning of each content in the formula is the same as that in the above embodiment and will not be repeated.

[0478] Optionally, the manner in which the first device calculates the group key may include one of the following: the first device calculates the group key using a third calculation manner 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;

[0479] 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, an anonymous key for each device in the group to which the second device belongs, an intermediate key of each device, the identifier of each device, and the third random number;

[0480] 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 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;

[0481] 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 intermediate key of each device, the identifier of each device, and the third random number;

[0482] The first device calculates the group key by 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 key of each device, the identifier of each device, and the third random number;

[0483] 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, an anonymous key for each device in the group to which the second device belongs, an intermediate key of each device, the identifier of each device, and the third random number;

[0484] The first device calculates the group key by using the third calculation method 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;

[0485] 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 where the second device is located, the intermediate key of each device, the first key of each device, the identifier of each device, and the third random number.

[0486] This example mainly adds the device group key to the calculations for generating the group key described above. The following only uses some of the modified formulas as examples for illustration, without enumerating all the above formulas one by one:

[0487] Optionally, taking the first key as a physical layer key as an example, 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 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:

[0488] Among them, K-Group represents the group key, KDF() represents the KDF calculation function, and the anonymous key A-IoT-1 ~Anonymous Key A-IoT-i Represents the anonymous key of each device, and performs XOR calculation on the anonymous key of each device, where i represents the i-th device in the device group, i is a positive integer, "||" represents direct connection calculation, PK A-IoT-1 ~PK A-IoT-i Represents the physical layer key of each device, performs an XOR calculation on the physical layer key of each of the above devices, (A-IoTID-1, ..., A-IoTID-i) represents the identification of each device, UEID is the identification of the UE when the first device is a UE, base station ID is the identification of the base station when the first device is a base station (in some possible examples, the base station ID can also be expressed as a base station IE), Group ID is the identification of the device group, and NONCE1 represents a third random number. Optionally, in the above formula, the XOR calculation can be replaced by a direct calculation, and the direct calculation can also be replaced by an XOR calculation; optionally, (A-IoTID-1, ..., A-IoTID-i) can be replaced by an XOR calculation or a direct calculation for the identification of each device. The above various possible calculation methods are all within the protection scope of this embodiment and are not exhaustive.

[0489] Optionally, taking the first key as a first intermediate key as an example, 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 intermediate key of each device, the identifier of each device, and the third random number. The calculation may be performed using the following formula:

[0490] The meanings of the various contents in the formula are the same as those in the above embodiment and will not be repeated here.

[0491] 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, an anonymous key for each device in the group to which the second device belongs, an intermediate key of each device, the identifier of each device, and the third random number. The group key may be calculated using the following formula:

[0492] Among them, K-Group represents the group key, KDF() represents the KDF calculation function, and the anonymous key A-IoT-1 ~Anonymous Key A-IoT-i Represents the anonymous key of each device, and performs XOR calculation on the anonymous key of each device, where i represents the i-th device in the device group, i is a positive integer, "||" represents direct connection calculation, Ka A-IoT-1 ~Ka A-IoT-i represents the intermediate key of each device, and the intermediate key of each device is XORed. The meaning of other contents in the formula is the same as that in the above embodiment and will not be repeated.

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

[0494] Furthermore, the second message is used to request authentication, and the second message also carries the encrypted group key and a fourth random number; the second device sends a third message to the first device, including: the second device obtains an encryption key based on the fourth random number and the key generation parameter; the second device decrypts the encrypted group key based on the encryption key to obtain the group key; the second device sends a third message to the first device, and the third message is a message encrypted based on the group key.

[0495] It should be noted that after receiving the second message, the aforementioned second device will still perform the aforementioned processing such as calculating and verifying MAC, and the specific processing method is the same as that in the aforementioned embodiment.

[0496] Optionally, the second device may further generate an integrity protection key and perform integrity protection on the third message. This process is the same as in the previous embodiment and is not repeated here. It should be noted that in this embodiment, the integrity protection key may also be generated using the aforementioned fourth intermediate 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 integrity protection key is also generated on the first device using the same process and is not repeated here.

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

[0498] In conjunction with Figure 19, an exemplary description of the authentication method provided in the above embodiment is given. In Figure 19, the second device is an A-IoT device (for simplicity, it is represented as A-IoT), the first device is a UE / base station, and the first network device and the second network device are combined to represent AUSF / UDM / ARPF as an example. The authentication method processing flow of Figure 19 includes:

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

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

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

[0502] In step 1904, the UE / base station generates Ka for each device in the device group and then generates a group key (K-Group).

[0503] The above-mentioned Ka may refer to the intermediate key of each device in the aforementioned embodiment. The detailed description of the intermediate key is the same as that in the aforementioned embodiment, and the generation of the group key is also the same as that in the aforementioned embodiment, and they will not be repeated.

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

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

[0506] Step 1906: After receiving the authentication response, the A-IoT device calculates MAC', and after successfully verifying MAC based on MAC', determines that the AUSF identity is successfully verified, calculates RES, and calculates Ka and KI. For example, MAC'=f2(Kr, AK), RES=f2(Kr, RAND), Ka=f3(AK, RAND, A-IOT ID), KI=KDF(Ka, NONCE1, physical layer key), 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.

[0507] In the above step 1905, 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 parameter; the second device decrypts the encrypted group key based on the encryption key to obtain the group key.

[0508] In step 1907, the A-IoT device sends an authentication response (carrying RES), which can be secured by KI.

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

[0510] In step 1908, after the UE / base station generates the KI, it verifies the authentication response and sends an authentication confirmation to the AUSF upon success. The authentication confirmation carries the RES. The KI generated by the UE / base station can be called an integrity protection key. The method for generating the KI by the UE / base station is the same as that of the aforementioned AIOT device and will not be repeated here. In this step, if the authentication response is also 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 other processing such as verification and security. This will not be repeated here.

[0511] In addition, step 1909 can also be executed on the AUSF side to verify RES. The specific method of AUSF verifying RES is the same as that in the previous embodiment and will not be repeated.

[0512] Optionally, the authentication process may be triggered by the first device.

[0513] The processing by 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 by 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.

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

[0515] In this case, after receiving the first message, the first device sends a second message to the second device requesting authentication. The processing of the second device based on the second message 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, which is not repeated here.

[0516] The processing after the first device receives the third message may also include: the first device generates a fourth random number; the first device obtains an encryption key based on the fourth random number, the physical layer key and the key generation parameter; the first device encrypts the group key based on the encryption key to obtain an encrypted group key; the first device sends a response message to the second device, the response message responds to the third message, the response message carries the fourth random number and the encrypted group key, and the group key is used to encrypt data transmitted between the second device and the first device.

[0517] The generation method of the encryption key and the generation method of the group key are the same as those in the previous embodiment and will not be described in detail.

[0518] The processing of the second device may include: the second device receives a response message from the first device, the response message responds to the third message; the second device verifies the response message based on the integrity protection key to obtain a verification result; when the verification result indicates that the integrity verification of the response message is passed, the second device obtains a fourth random number from the response message; the second device obtains an encryption key based on the fourth random number, a physical layer key and a key generation parameter; the second device obtains the encrypted group key from the response message; the second device decrypts the encrypted group key based on the encryption key to obtain the group key, and the group key is used to encrypt data transmitted between the second device and the first device.

[0519] The manner in which the second device obtains the encryption key is the same as in the aforementioned embodiment. After the second device obtains the group key, it can use the group key to encrypt the transmitted data and decrypt the received data, which is not limited here.

[0520] In conjunction with Figure 20, an exemplary description of the authentication method provided in the above embodiment is given. In Figure 20, the second device is an A-IoT device (for simplicity, it is represented as A-IoT), the first device is a UE / base station, and the first network device and the second network device are combined to represent AUSF / UDM / ARPF as an example. The authentication method processing flow of Figure 20 includes:

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

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

[0523] The processing of steps 2003 to 2005 is the same as that of steps 1902 to 1904 in FIG. 19 , and will not be repeated.

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

[0525] Step 2007: After receiving the authentication response, the A-IoT device calculates MAC', and after successfully verifying MAC based on MAC', determines that the AUSF identity is successfully verified, calculates RES, and calculates Ka and KI. For example, MAC'=f2(Kr, AK), RES=f2(Kr, RAND), Ka=f3(AK, RAND, A-IOT ID), KI=KDF(Ka, NONCE1, physical layer key), 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.

[0526] In step 2008, the A-IoT device sends an authentication response (carrying RES), which can be secured by KI.

[0527] In step 2009, the UE / base station generates the KI and verifies the authentication response. Upon success, it sends an authentication confirmation to the AUSF, which carries the RES. The KI generated by the UE / base station is called an integrity protection key. The KI generated by the UE / base station is similar to that of the AIOT device and is not described here.

[0528] In addition, step 2010 can also be executed on the AUSF side to verify RES. The specific method of AUSF verifying RES is the same as that in the previous embodiment and will not be repeated.

[0529] 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 derive an encryption key based on the fourth random number, the physical layer key, and key generation parameters; and encrypt the group key using the encryption key to obtain the encrypted group key. Additionally, the response message may also carry the fourth random number.

[0530] 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 parameter; the second device decrypts the encrypted group key based on the encryption key to obtain the group key.

[0531] It should be noted that Figures 19 and 20 above are exemplary illustrations of scenarios where the first device is a UE or a base station in Indirect mode or Direct mode, respectively. In some possible examples, in Direct mode, the UE / base station in Figures 19 and 20 above can also be replaced with a first core network device, such as AMF, SEAF, a core network element dedicated to AIoT (or IoT), and so on. All possible examples are not exhaustive here.

[0532] As can be seen, by adopting the above authentication method, the second device can receive the authentication parameters, then directly calculate the verification MAC based on the authentication parameters and the root key shared with the core network device. The core network device is authenticated based on the received MAC. This ensures the security of the authentication process between the second device and the core network device while avoiding the need for complex calculations on the second device, thereby improving the processing efficiency of the second device. This is particularly suitable for devices with lower computing power.

[0533] Figure 21 is a schematic flow chart of an authentication method according to an embodiment of the present application. The method includes at least part of the following contents.

[0534] S2110. The first device receives a first message from a first network device, where the first message carries authentication parameters and an identifier of the second device.

[0535] S2120. The first device sends a second message to the second device, where the second message carries authentication parameters.

[0536] S2130. The first device receives a third message from the second device. The third message carries a first RES. The first RES is obtained by the second device based on the authentication parameters and a root key. The root key is a key shared by the second device and all core network devices.

[0537] S2140. The first device sends a fourth message to the first network device. The fourth message carries the first RES. The first RES is used by a core network side device to authenticate the second device.

[0538] Figure 22 is a schematic flow chart of an authentication method according to another embodiment of the present application. The method includes at least part of the following contents.

[0539] S2210. The second device receives a second message from the first device, where the second message carries authentication parameters.

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

[0541] S2230. The second device sends a third message to the first device. The third message carries the first RES. The first RES is used by a core network side device to authenticate the second device.

[0542] Figure 23 is a schematic flow chart of an authentication method according to another embodiment of the present application. The method includes at least part of the following contents.

[0543] S2310. The first network device sends a first message to the first device, where the first message carries authentication parameters and an identifier of the second device.

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

[0545] S2330. When the first RES is identical to the first verification RES, the first network device determines that the second device is authenticated successfully.

[0546] 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 embodiment, so they are not repeated.

[0547] 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.

[0548] Correspondingly, 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 uses the first calculation method to calculate the first verification RES based on the root key and the authentication parameters.

[0549] In this embodiment, the methods of generating the first RES and the first verification RES are the same as those in the above embodiments and are not described in detail.

[0550] Optionally, the method further includes one of the following: the first network device receives the authentication parameter 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 parameter using the first calculation method.

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

[0552] The processing by the first device further includes: when the second verification RES is the same as the second RES, the first device determines that the second device authentication is successful.

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

[0554] In this embodiment, the methods of generating the second RES and the second verification RES are the same as those in the above embodiments and are not described in detail.

[0555] The authentication method provided in this embodiment differs from the previous embodiment in that MAC verification is not performed. Except for not performing MAC calculation and MAC verification, the authentication method provided in this embodiment is the same as that in the previous embodiment. The detailed description of the second message, third message, first message, and fourth message, as well as the integrity protection key negotiation, encryption key negotiation, group key generation, and transmission between the second device and the first device, and other processes are the same as those in the previous embodiment and are therefore not repeated.

[0556] As can be seen, by adopting the above authentication method, the first device can send authentication parameters to the second device, which in turn allows the second device to directly calculate the first RES based on the authentication parameters and the root key shared with the core network device. This first RES is then sent to the first network device via the first device, allowing the core network to authenticate the second device. This method ensures security while avoiding complex calculations on the second device, improving the processing efficiency of the second device. It is particularly suitable for devices with low computing power.

[0557] Figure 24 is a schematic flow chart of an authentication method according to an embodiment of the present application. The method includes at least part of the following contents.

[0558] S2410. The first device sends a second message to the second device, where the second message carries authentication parameters.

[0559] S2420. The first device receives a third message from the second device, where the third message carries a second RES, and the second RES is related to the authentication parameter and the first key.

[0560] S2430. The first device generates a second verification RES based on the authentication parameter and the first key;

[0561] S2440: If the second verification RES is the same as the second RES, the first device determines that the second device authentication is successful.

[0562] Figure 25 is a schematic flow chart of an authentication method according to another embodiment of the present application. The method includes at least part of the following contents.

[0563] S2510. The second device receives a second message from the first device, where the second message carries authentication parameters.

[0564] S2520. The second device calculates a second RES based on the authentication parameter and a first key, where the first key is related to the first device.

[0565] S2530: The second device sends a third message to the first device, where the third message carries the second RES, and the second RES is used by the first device to authenticate the second device.

[0566] 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 embodiment, so they are not repeated.

[0567] 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 uses the first calculation method to calculate the second RES based on the anonymous key and the physical layer key, and the physical layer key is a key shared between the second device and the first device; the second device uses the first calculation method to calculate the second RES based on the first random number and the physical layer key; the second device uses the first calculation method to calculate the second RES based on the first RES and the physical layer key.

[0568] The first device generates a second verification RES, including one of the following: the second device uses the first calculation method to calculate the second RES based on the anonymous key and the physical layer key, and the physical layer key is a key shared between the second device and the first device; the second device uses the first calculation method to calculate the second RES based on the first random number and the physical layer key; the second device uses the first calculation method to calculate the second RES based on the first RES and the physical layer key.

[0569] In this embodiment, the methods of generating the second RES and the second verification RES are the same as those in the above embodiments and are not described in detail.

[0570] The authentication method provided in this embodiment is different from the aforementioned embodiment in that MAC verification is not performed and verification of the first RES is not performed. In addition, the detailed description of the above-mentioned second message, third message, first message and fourth message, as well as the negotiation of integrity protection keys, negotiation of encryption keys, generation and transmission of group keys between the second device and the first device, etc., can all be the same as those in the aforementioned embodiment, and therefore will not be repeated.

[0571] 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 device. This first RES is sent to the first network device via the first device, allowing the core network to authenticate the second device. This method not only ensures security, but also avoids the second device from performing complex calculations, thereby improving the processing efficiency of the second device. It is particularly suitable for devices with low computing power.

[0572] Finally, the beneficial effects of the solution provided by this embodiment are described in combination with relevant technologies.

[0573] Ambient IoT is a new type of IoT terminal studied in 3GPP Release 19. It is an IoT device powered by energy harvesting and lacks batteries or has 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. For example, see Figure 26. The top of Figure 26 shows the direct mode, in which the AIOT device directly connects to the access network device (such as a base station) on the network side. The base station then connects to the core network and then to the AIOT AF. The bottom of Figure 26 shows the indirect mode, in which the AIOT device connects to the base station through other terminal devices (such as relay UE or proxy UE), and then connects to the 5G core network and AIOT AF through the base station.

[0574] In related technologies, a UE must undergo authentication and key negotiation before accessing a 5G network and using network resources. Based on the authentication results, the network authorizes the UE to use network resources and services. The 3GPP security standards define the 5G AKA process and the cryptographic algorithms used. The authentication and authorization credentials used in the UE's AKA process are based on a symmetric root key, K, which is centrally stored on the network side by the UDM / ARPF network element in the core network. Each authorization requires the UDM to obtain the authorization credentials and the core network to perform the corresponding authentication calculations.

[0575] The AKA process described above, as shown in FIG27 , may include:

[0576] S2701. In response to the received authentication request, UDM / ARPF generates an AV (Authentication Vector). That is, UDM / ARPF creates a 5G HE AV (Home Environment Authentication Vector) with the Authentication Management Field (AMF) separation bit set to "1". Then, UDM / ARPF should derive KAUSF (Key Authentication Server Function) and calculate XRES* (Expected Response). Finally, UDM / ARPF should create a 5G HE AV from RAND (Random number), AUTN (Authentication Token), XRES* and KAUSF. S2702. UDM should return the 5G HE AV to AUSF. S2703. AUSF should store XRES* and temporarily store XRES* together with the received SUCI or SUPI. S2704. The AUSF generates a 5G AV based on the 5G HE AV received from the UDM / ARPF, calculates HXRES* from XRES* and KSEAF from KAUSF, replaces XRES* in the 5G HE AV with HXRES*, and replaces 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 returns RES, CK, and IK to the ME. The ME then calculates RES* from the RES. S2708. The UE returns RES* to the SEAF. S2709. The SEAF calculates HRES* from RES* and compares HRES* with HXRES*. If they match, the SEAF considers the authentication successful from the serving network's perspective. Otherwise, the SEAF considers the authentication failed and indicates the failure to the AUSF. S2710. The SEAF sends the RES* received from the UE to the AUSF. S2711. The AUSF compares the received RES* with the stored XRES*. If RES* and XRES* are equal, the AUSF shall consider the authentication successful. The AUSF shall notify the UDM of the authentication result. S2712. The AUSF indicates to the SEAF whether the authentication was successful from the perspective of the home network.

[0577] FIG28 is the authentication architecture corresponding to the above-mentioned process flow. In conjunction with FIG28 , it can be seen that the calculation method of each parameter in the above-mentioned process flow may 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 to f5 are the MILENAGE cryptographic algorithms defined by the ETSI SAGE group. Exemplarily, the method for generating the KAUSF used in the above process can use the following parameters to form the input of the KDF and calculate the KAUSF: FC = 0x6A, P0 = serving network name, L0 = length of the serving network name, The input key KEY should be equal to the concatenation of CK||CK. It can be seen that the parameter calculation in the above process is relatively complicated.

[0578] With reference to 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, 5G AKA and key architecture are relatively complex and are not suitable for security authentication of A-IoT devices. They also do not support authentication and key negotiation between A-IoT devices and UEs.

[0579] In related technologies, RFID systems typically consist of a reader and a tag, operating in different frequency bands. Tags can be categorized as passive, active, or semi-active based on their power supply method. Passive tags are coupled to the reader using either near-field or far-field coupling. Near-field coupling relies on induction, where the mutual inductance between the reader and tag causes changes in the tag coil current that can be detected by the reader. Far-field coupling relies on backscatter communication.

[0580] In related technologies, two-way authentication between a reader and a tag may include: 1. The reader generates a random number RN r RN r Sent to the tag. 2: The tag receives RN r After that, the local also generates a random number RN t The tag uses hash function and PSK to identify the RN. r ||RN t Calculate and get MIC1 (message integrity check code). Finally, RN r , RN t 3: The reader sends the received RNr With local RN r Do a comparison, if they are not equal, ignore them; if they are equal, the reader uses the hash function and PSK to compare RN r ||RN t Calculate MIC′1, compare MIC1 with MIC′1, if they are not equal, ignore them; if they are equal, the reader authenticates the tag is legal, and the reader continues to use the hash function and PSK to authenticate the RN t Calculate MIC2 and finally RN t , MIC2 is sent to the tag. 4: The tag receives the RN t With local RN t Do a comparison, if they are not equal, ignore them; if they are equal, use the hash function and PSK to compare RN t Calculate MIC'2 and compare the received MIC2 with the locally calculated MIC'2. If they are not equal, ignore them. If they are equal, the tag authenticates the reader as legitimate and returns the authentication result to the reader. 5: If the tag and reader need to communicate securely, each uses KDH (PSK, TID||RID||RN r ||RN t ) derives the session key, KDH() is a key derivation algorithm.

[0581] Through the above analysis, it can be seen that the f1-f5 function and KDF function used in the AKA authentication process and key negotiation process in the related art have high computational complexity and a complex key architecture, which are not suitable for the security authentication of A-IoT devices, nor do they support authentication and key negotiation between A-IoT devices and UEs. Authentication and key negotiation are performed between tags and readers, but authentication and key negotiation cannot be supported between A-IoT devices and networks. Compared with the above-mentioned related technologies, the aforementioned various embodiments provided by this application can realize 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, and the second device can directly use the authentication parameters sent by the network side and its own root key to implement authentication processing, which ensures security while reducing the computing power requirements on the second device side. In addition, in the various embodiments provided by this application, in the process of negotiating integrity protection keys and encryption keys, there is no need to perform complex calculations multiple times, and it can be achieved based on physical layer keys, anonymous keys, random numbers, etc., which is more suitable for devices with lower computing power.

[0582] FIG30 is a schematic diagram of the composition structure of a first device according to an embodiment of the present application, including:

[0583] The first communication unit 3010 is used to receive a first message from a first network device, where the first message carries a MAC, an authentication parameter, and an identifier of a second device; and send a second message to the second device, where the second message carries the MAC and the authentication parameter, where the authentication parameter is used by the second device to obtain a verification MAC based on a root key, where the verification MAC is used by the second device to authenticate a core network side device in combination with the MAC, where the root key is a key shared by the second device and the core network side device.

[0584] FIG31 is a schematic diagram of the structure of a second device according to an embodiment of the present application, including:

[0585] The second communication unit 3110 is configured to receive a second message from the first device, where the second message carries a message authentication code MAC and authentication parameters;

[0586] The second processing unit 3120 is used to calculate the verification 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; when the verification MAC is the same as the MAC, the second device completes the authentication of the core network side device.

[0587] FIG32 is a schematic diagram of the composition structure of a first network device according to an embodiment of the present application, including:

[0588] 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 the core network side device in combination with the MAC, and the root key is a key shared by the second device and all core network side devices.

[0589] FIG33 is a schematic diagram of the structure of an electronic device according to an embodiment of the present application, including:

[0590] 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, and the encryption key is related to the key generation parameter and a fourth random number, and 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 sent data and / or decrypt received data.

[0591] An embodiment of the present application provides a first device, including:

[0592] The 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.

[0593] An embodiment of the present application provides a second device, including:

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

[0595] The second processing unit is configured to calculate a first RES based on the authentication parameter and a root key, where the root key is a key shared by the second device and all core network side devices.

[0596] FIG32 is a schematic diagram of the composition structure of a first network device according to an embodiment of the present application, including:

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

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

[0599] FIG30 is a schematic diagram of the composition structure of a first device according to an embodiment of the present application, including:

[0600] The first communication unit 3010 is configured to send a second message to a second device, where the second message carries authentication parameters; and receive a third message from the second device, where the third message carries a second RES, where the second RES is related to the authentication parameters and the first key.

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

[0602] An embodiment of the present application provides a second device, including:

[0603] a second communication unit, configured to receive a second message from the first device, the second message carrying authentication parameters; and 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;

[0604] The second processing unit is configured to calculate a second RES based on the authentication parameter and a first key, where the first key is associated with the first device.

[0605] The device of the embodiment of the present application can realize the corresponding functions of each device in the aforementioned authentication method embodiment. The process, function, implementation method and beneficial effect corresponding to each module (submodule, unit or component, etc.) in the second device, or the first device, or the first network device, or the electronic device can be found in the corresponding description in the above method embodiment, which will not be repeated here. It should be noted that the functions described in the second device, or the first device, or the first network device, or the electronic device in the embodiment of the application can be implemented by different modules (submodules, units or components, etc.), or by the same module (submodule, unit or component, etc.).

[0606] Figure 34 is a schematic structural diagram of a communication device 3400 according to an embodiment of the present application. The communication device 3400 includes a processor 3410, which can call and run a computer program from a memory to enable the communication device 3400 to implement the method in the embodiment of the present application.

[0607] In a possible implementation, the communication device 3400 may further include a memory 3420. The processor 3410 may call and execute a computer program from the memory 3420 to enable the communication device 3400 to implement the method in the embodiment of the present application.

[0608] The memory 3420 may be a separate device independent of the processor 3410 , or may be integrated into the processor 3410 .

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

[0610] 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.

[0611] In one possible implementation, the communication device 3400 may be the first device, or the second device, or the first network device of the embodiment of the present application, and the communication device 3400 can implement the corresponding processes implemented by the first device, or the second device, or the first network device in the various methods of the embodiment of the present application. For the sake of brevity, they will not be repeated here.

[0612] 35 is a schematic structural diagram of a chip 3500 according to an embodiment of the present application. The chip 3500 includes a processor 3510, which can call and execute a computer program from a memory to implement the method according to the embodiment of the present application.

[0613] In one possible implementation, the chip 3500 may further include a memory 3520. The processor 3510 may call and execute a computer program from the memory 3520 to implement the method performed by the access network device or the first core network device in the embodiment of the present application. The memory 3520 may be a separate device independent of the processor 3510 or integrated into the processor 3510.

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

[0615] 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 embodiment of the present 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 each method of the embodiment of the present application. For the sake of brevity, they will not be repeated here.

[0616] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0617] The processor mentioned above may be a general-purpose processor, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other programmable logic devices, transistor logic devices, discrete hardware components, etc. The general-purpose processor mentioned above may be a microprocessor or any conventional processor, etc.

[0618] The memory mentioned above may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM).

[0619] It should be understood that the above-mentioned memories are exemplary but not restrictive. For example, the memories in the embodiments of the present 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 RAM RAM (DR RAM), etc. In other words, the memories in the embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memories.

[0620] Figure 36 is a schematic block diagram of a communication system 3600 according to an embodiment of the present 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 be used to implement the corresponding functions implemented by the second device, the first device, and the first network device in the above method, respectively.

[0621] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function in accordance with the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode to another website, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0622] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean 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 the present application.

[0623] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0624] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included within the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. An authentication method, comprising: The first device receives a first message from a first network device, where the first message carries a MAC, an authentication parameter, and an identifier of a second device; The first device sends a second message to the second device, and the second message carries the MAC and the authentication parameters. 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 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. The method according to claim 1, wherein: The authentication parameter includes one of the following: an anonymous key, a first random number.

3. The method according to claim 2, wherein: The method further comprises: The first device receives a third message from the second device, where the third message is used to instruct the second device to complete authentication of the core network side device; The first device sends a fourth message to the first network device, where the fourth message is used to instruct the second device to complete authentication of the core network side device.

4. The method according to claim 3, wherein: The third message carries at least one of the following: A first RES, where the first RES is used by the core network side device to authenticate the second device; A second RES, where the second RES is used by the first device to authenticate the second device.

5. The method according to claim 4, wherein: The fourth message carries the first RES.

6. The method according to claim 5, wherein: The second message also carries service parameters, which include at least one of the following: a type parameter for indicating the type of environment-powered Internet of Things AIoT service, an identifier of a server with AIoT service function, and a type parameter for indicating the type of AIoT authentication.

7. The method according to claim 5, wherein: The method further comprises: When the second verification RES is identical to the second RES, the first device determines that the second device is authenticated successfully.

8. The method according to claim 7, wherein: The method further comprises one of the following: The first device calculates the second verification RES on the anonymous key and the first key using a first calculation method, and the first key is related to the first device; The first device calculates the second verification RES on the first random number and the first key using a first calculation method; The first device calculates the second verification RES based on the first verification RES and the first key by using a first calculation method.

9. The method according to claim 8, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

10. The method according to claim 8, wherein: The first message also carries the first verification RES.

11. The method according to any one of claims 3 to 10, wherein: The method further comprises: The first 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 sent data and / or decrypt received data.

12. The method according to claim 11, wherein: The third message also carries a first integrity verification code.

13. The method according to claim 11 or 12, wherein: The third message also carries the third random number and / or the fourth random number.

14. The method according to claim 11 or 12, wherein: The method further comprises: The first device sends a response message to the second device, the response message responds to the third message, and the response message carries at least one of the following: indication information that the integrity verification of the third message has passed, the second integrity verification code, the fourth random number, and the encrypted group key.

15. The method according to claim 11 or 12, wherein: The second message also carries at least one of the following: the third random number, the third integrity verification code, the encrypted group key, and the fourth random number.

16. The method according to any one of claims 1 to 15, wherein: The method further comprises: The first device receives an authentication request from the second device, where the authentication request carries an identifier of the second device; The first device forwards the authentication request to the first network device.

17. The method according to any one of claims 1 to 15, wherein: The method further comprises: The first device sends an authentication request to the first network device, where the authentication request carries an identifier of the second device and / or an identifier of a device group to which the second device belongs.

18. The method according to any one of claims 1 to 17, wherein: The core network side device includes a core network, or a verification server; the first network device is an AUSF or AS; the second device is an AIoT device; 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.

19. An authentication method, comprising: The second device receives a second message from the first device, where the second message carries a message authentication code MAC and an authentication parameter; The second device calculates and verifies the MAC based on the authentication parameter and the root key, where the root key is a key shared by the second device and the core network side device; When the verification MAC is identical to the MAC, the second device completes authentication of the core network side device.

20. The method according to claim 19, wherein: The authentication parameter includes one of the following: an anonymous key, a first random number.

21. The method according to claim 20, wherein: The second device calculates a verification MAC based on the authentication parameter and the root key, including 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 based on the XOR of the first random number and the root key, and 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 random number based on the anonymous key and the root key XOR, and 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 verification MAC based on the first random number and the root key using a first calculation method.

22. The method according to claim 21, wherein: The second device calculates the verification MAC based on the anonymous key and the root key in a first calculation manner, including: the second device calculates the verification MAC based on a service parameter, the anonymous key and the root key in a first calculation manner; 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 a first calculation method.

23. The method according to claim 21 or 22, wherein: The method further comprises: The second device sends a third message to the first device, and the third message is used to indicate that the second device The side device completes the authentication.

24. The method according to claim 23, wherein: The third message carries at least one of the following: A first RES, where the first RES is used by the core network side device to authenticate the second device; A second RES, where the second RES is used by the first device to authenticate the second device.

25. The method according to claim 24, wherein: The method further comprises one of the following: The second device calculates a first RES based on the first random number and the root key using the first calculation method; The second device calculates a first RES based on the anonymous key and the root key using the first calculation method.

26. The method according to claim 25, 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 parameter, 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.

27. The method according to any one of claims 24 to 26, wherein: The method further comprises one of the following: The second device calculates the second RES based on the anonymous key and a first key using a first calculation method, where the first key is related to the first device; The second device calculates the second RES based on the first random number and the first key using the first calculation method; The second device calculates the second RES based on the first RES and the first key by using the first calculation method.

28. The method according to claim 27, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

29. The method according to claim 22 or 26, wherein: The second message also carries the service parameters, which include at least one of the following: a type parameter for indicating the AIoT service type, an identifier of a server with AIoT service function, and a type parameter for indicating the AIoT authentication type.

30. The method according to any one of claims 23 to 28, wherein: The method further comprises: The second 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 sent data and / or decrypt received data.

31. The method according to claim 30, wherein: The third message also carries a first integrity verification code.

32. The method according to claim 30 or 31, wherein: The third message also carries a third random number and / or a fourth random number.

33. The method according to claim 30 or 31, wherein: The method further comprises: The second device receives a response message from the first device, the response message responds to the third message, and the response message carries at least one of the following: indication information that the integrity verification of the third message has passed, a second integrity verification code, the fourth random number, and an encrypted group key.

34. The method according to claim 30 or 31, wherein: The second message also carries at least one of the following: the third random number, the third integrity verification code, the encrypted group key, and the fourth random number.

35. The method according to claim 33 or 34, wherein: The second message is used to request authentication, and the method further includes: The second device decrypts the encrypted group key based on the encryption key to obtain the group key, where the group key is used to encrypt data transmitted between the second device and the first device.

36. The method according to any one of claims 19 to 35, wherein: The method further comprises: The second device sends an authentication request to the first device, where the authentication request carries an identifier of the second device.

37. The method according to any one of claims 21, 22, 25-27, wherein: The first calculation method includes one of the following: a second authentication function, a hash algorithm, AES, ACSON, SNOW 3G, and ZUC.

38. The method according to any one of claims 19 to 37, wherein: The core network side equipment includes: one or more core network devices or verification servers; the second device is an environment-powered Internet of Things AIoT device; the first device includes at least one of the following: terminal equipment, access network equipment, authentication equipment, and first core network equipment.

39. An authentication method, comprising: 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 a 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 a core network side device in combination with the MAC, and the root key is a key shared by the second device and all core network side devices.

40. The method of claim 39, wherein: The authentication parameter includes one of the following: an anonymous key, a first random number.

41. The method of claim 40, wherein: The method further comprises one of the following: The first network device receives the MAC and the authentication parameter from the second network device; The first network device generates the authentication parameter, and the first network device calculates the MAC based on the root key and the authentication parameter.

42. The method according to claim 41, wherein: The first network device calculates the MAC based on the root key and the authentication parameter, 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 based on the XOR of the first random number and the root key, and 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 random number based on the XOR of the anonymous key and the root key, and 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 MAC based on the first random number and the root key using a first calculation method.

43. The method of claim 42, wherein: 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 the service parameter, 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 the service parameters, the first random number and the root key using the first calculation method.

44. The method of claim 43, wherein: The method further comprises: The first network device receives a fourth message from the first device, wherein the fourth message is used to instruct the second device to complete authentication of the core network side device.

45. The method of claim 44, wherein: The fourth message carries the first RES; and the method further includes: The first network device determines that the authentication of the second device is successful when the first RES is identical to the first verification RES.

46. ​​The method of claim 45, wherein: The first message also carries the first verification RES.

47. The method according to claim 45 or 46, wherein: The method further comprises 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 parameter using the first calculation method.

48. The method of claim 47, wherein: The first network device calculates the first verification RES based on the root key and the authentication parameter using the first calculation method, including one of the following: The first network device calculates a first verification RES based on the first random number and the root key using the first calculation method; The first network device calculates a first verification RES based on the anonymous key and the root key using the first calculation method.

49. The method of claim 48, wherein: The first network device calculates the first verification RES based on the first random number and the root key using the first calculation method, including: the first network device calculates the first verification RES based on the service parameter, the first random number and the root key using the first calculation method; And / or, the first network device calculates the first verification RES based on the anonymous key and the root key using the first calculation method, including: the first network device calculates the first verification RES based on service parameters, the anonymous key and the root key using the first calculation method.

50. The method of claim 43 or 49, wherein: The first message also carries the service parameters, which include at least one of the following: a type parameter for indicating the type of AIoT service, an identifier of a server with AIoT service function, and a type parameter for indicating the type of AIoT authentication.

51. The method according to any one of claims 39-50, wherein: The first message also carries at least one of the following: a second intermediate key, a third intermediate key, and a fourth intermediate key; and 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 second intermediate key based on the anonymous key using a third calculation method; The first network device calculates the second intermediate key based on the first random number using the third calculation method; The first network device calculates the second intermediate key based on the anonymous key and the first key using a third calculation method; The first network device calculates the second intermediate key based on the first random number and the first key using the third calculation method; The first network device calculates the third intermediate key based on the root key and the first random number using the third calculation method; The first network device calculates the third intermediate key based on the root key and the anonymous key using the third calculation method; The first network device calculates the third intermediate key based on the root key, the first key and the first random number using the third calculation method; The first network device calculates a fourth intermediate key based on the root key and the first random number using the third calculation method, and calculates the third intermediate key based on the fourth intermediate key using the second calculation method; The first network device calculates a fourth intermediate key based on the root key and the first random number using the third calculation method, and calculates the third intermediate key based on the fourth intermediate key and the first key using the second calculation method.

52. The method according to any one of claims 39 to 51, wherein: The first message also carries an identifier of a device group to which the second device belongs; and the method further includes one of the following: The first network device receives an authentication request from the first device, where the authentication request carries an identifier of the second device and / or an identifier of a device group to which the second device belongs; The first network device receives a trigger message from a server, where the trigger message carries an identifier of the second device and / or an identifier of a device group to which the second device belongs.

53. The method according to any one of claims 39 to 52, wherein: The core network side equipment includes: one or more core network devices or verification servers; the second device is an AIoT device; the first device includes at least one of the following: a terminal device, an access network device, an authentication device, a first core network device; the first network device is an AUSF or a verification server; the second network device includes at least one of the following: a user data management UDM, an authentication credential storage and processing function ARPF.

54. A key generation method comprising: 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 sent data and / or decrypt received data.

55. The method of claim 54, wherein: The electronic device is 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.

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

57. The method of claim 55, wherein: The computing of the encryption key comprises one of the following: Calculate the encryption key using the second calculation method on the fourth random number and the anonymous key; Calculate the encryption key based on the first random number and the fourth random number using the second calculation method; Calculate the encryption key based on the anonymous key, the first key and the fourth random number using a second calculation method; Calculate the encryption key based on the first random number, the first key and the fourth random number using the second calculation method; Calculating the encryption key based on a second intermediate key and the fourth random number using the second calculation method, where the second intermediate key is related to the key generation parameter; The encryption key is calculated based on a third intermediate key and the fourth random number using the second calculation method, where the third intermediate key is related to the root key and the key generation parameter.

58. The method of claim 56 or 57, wherein: The method further comprises at least one of the following: Calculate the second intermediate key based on the anonymous key using a third calculation method; Calculate the second intermediate key based on the first random number using the third calculation method; Calculate the second intermediate key based on the anonymous key and the first key using a third calculation method; Calculate the second intermediate key based on the first random number and the first key using the third calculation method; Calculate the third intermediate key based on the root key and the first random number using the third calculation method; Calculate the third intermediate key based on the root key and the anonymous key using the third calculation method; Calculate the third intermediate key based on the root key, the first key and the first random number using the third calculation method; Using the third calculation method to calculate a fourth intermediate key based on the root key and the first random number, and using the second calculation method to calculate the third intermediate key based on the fourth intermediate key; The fourth intermediate key is calculated based on the root key and the first random number using the third calculation method, and the third intermediate key is calculated based on the fourth intermediate key and the first key using the second calculation method.

59. The method of claim 55, wherein: The electronic device is the second device, and the method further includes: The second device decrypts the encrypted group key based on the encryption key to obtain the group key, where the group key is used to encrypt data transmitted between the second device and the first device.

60. The method of claim 55, wherein: The electronic device is the first device, and the method further includes: The first device encrypts the group key based on the encryption key to obtain the encrypted group key.

61. The method of claim 60, wherein: The method further comprises one of the following: The first device calculates the group key by 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; The first device calculates the group key by using the third calculation method based on the identifier of the first device, an anonymous key of each device in the group to which the second device belongs, an intermediate key of each device, the identifier of each device, and the third random number; The first device calculates the group key by using the third calculation method 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; The first device calculates the group key by 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 identifier of each device, and the third random number; The first device calculates the group key by 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 key of each device, the identifier of each device, and the third random number; The first device calculates the group key by using the third calculation method 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; 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 key of each device, the identifier of each device, and the third random number.

62. The method of claim 60, wherein: The method further comprises one of the following: The first device calculates the group key by 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 where the second device belongs, the identifier of each device, and the third random number; The first device calculates the group key by 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 where the second device belongs, the intermediate key of each device, the identifier of each device, and the third random number; The first device calculates the group key by the third calculation method based on the identifier of the device group, the identifier of the first device, the intermediate key of each device in the group where the second device belongs, the physical layer key of each device, the identifier of each device and the third random number; The first device calculates the second device by 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 where the second device is located, the intermediate key of each device, the identifier of each device, and the third random number. Group key; The first device calculates the group key by 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 where the second device belongs, the first key of each device, the identifier of each device, and the third random number; The first device calculates the group key by 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 where the second device belongs, the intermediate key of each device, the identifier of each device, and the third random number; The first device calculates the group key by using the third calculation method based on the identifier of the device group, the identifier of the first device, the intermediate key of each device in the group where the second device belongs, the first key of each device, the identifier of each device, and the third random number; 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 where the second device is located, the intermediate key of each device, the first key of each device, the identifier of each device, and the third random number.

63. The method according to any one of claims 56-58, 61, and 62, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

64. An authentication method, comprising: The first device receives a first message from a first network device, where the first message carries an authentication parameter and an identifier of a second device; The first device sends a second message to the second device, where the second message carries an authentication parameter; The first device receives a third message from the second device, where the third message carries a first RES, where the first RES is obtained by the second device based on the authentication parameter and a root key, where the root key is a key shared by the second device and all core network side devices; The first device sends a fourth message to the first network device, where the fourth message carries the first RES, and the first RES is used by a core network side device to authenticate the second device.

65. The method of claim 64, wherein: The third message also carries a second RES, and the method further includes: When the second verification RES is identical to the second RES, the first device determines that the second device is authenticated successfully.

66. The method of claim 65, wherein: The method further comprises one of the following: The first device calculates the second verification RES on the anonymous key and the first key using a first calculation method, and the first key is related to the first device; The first device calculates the second verification RES on the first random number and the first key using a first calculation method; The first device calculates the second verification RES based on the first verification RES and the first key by using a first calculation method.

67. The method of claim 66, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

68. The method of claim 66, wherein: The first message also carries the first verification RES.

69. The method according to any one of claims 64 to 68, wherein: The core network side equipment includes: one or more core network devices or verification servers; the second device is an environment-powered Internet of Things AIoT device; the first device includes at least one of the following: terminal equipment, access network equipment, authentication equipment, and first core network equipment.

70. An authentication method comprising: The second device receives a second message from the first device, where the second message carries the authentication parameter; The second device calculates a first RES based on the authentication parameter and a root key, where 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, where the third message carries the first RES, and the first RES is used by a core network side device to authenticate the second device.

71. The method of claim 70, wherein: The authentication parameter includes one of the following: an anonymous key, a first random number; the second device calculates the first RES based on the authentication parameter and the root key, including one of the following: The second device calculates a first RES based on the first random number and the root key using the first calculation method; The second device calculates a first RES based on the anonymous key and the root key using the first calculation method.

72. The method of claim 71, 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 parameter, 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.

73. The method of claim 72, wherein: The second message also carries the service parameters, which include at least one of the following: a type parameter for indicating the AIoT service type, an identifier of a server with AIoT service function, and a type parameter for indicating the AIoT authentication type.

74. The method according to any one of claims 70 to 73, wherein: The third message also carries a second RES, where the second RES is used by the first device to authenticate the second device; and the method further includes one of the following: The second device calculates the second RES based on the anonymous key and a first key using a first calculation method, where the first key is related to the first device; The second device calculates the second RES based on the first random number and the first key using the first calculation method; The second device calculates the second RES based on the first RES and the first key by using the first calculation method.

75. The method of claim 74, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

76. The method of claim 75, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

77. The method according to any one of claims 70 to 76, wherein: The core network side equipment includes: one or more core network devices or verification servers; the second device is an environment-powered Internet of Things AIoT device; the first device includes at least one of the following: terminal equipment, access network equipment, authentication equipment, and first core network equipment.

78. An authentication method comprising: The first network device sends a first message to the first device, where the first message carries the authentication parameter and the identifier of the second device; The first network device receives a fourth message from the first device, where the fourth message carries the first RES, where the first RES is obtained by the second device based on the authentication parameter and a root key, where the root key is a key shared by the second device and all core network side devices; The first network device determines that the second device is authenticated if the first RES is identical to the first verification RES.

79. The method of claim 78, wherein: The authentication parameter includes one of the following: an anonymous key, a first random number.

80. The method of claim 79, wherein: The method further comprises one of the following: The first network device receives the authentication parameter 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 parameter using the first calculation method.

81. The method of claim 80, wherein: The core network side equipment includes: one or more core network devices or verification servers; the second device is an AIoT device; the first device includes at least one of the following: a terminal device, an access network device, an authentication device, a first core network device; the first network device is an AUSF or a verification server; the second network device includes at least one of the following: a user data management UDM, an authentication credential storage and processing function ARPF.

82. An authentication method, comprising: The first device sends a second message to the second device, where the second message carries an authentication parameter; The first device receives a third message from the second device, the third message carries a second RES, and the second RES is related to the authentication parameter and the first key; The first device generates a second verification RES based on the authentication parameter and the first key; When the second verification RES is identical to the second RES, the first device determines that the second device is authenticated successfully.

83. The method of claim 82, wherein: The method also includes: the first device receiving a first message from a first network device, where the first message carries an authentication parameter and an identifier of a second device.

84. The method of claim 83, wherein: The first device generates a second verification RES based on the authentication parameter and the first key, including one of the following: The first device calculates the second verification RES on the anonymous key and the first key using a first calculation method, and the first key is related to the first device; The first device calculates the second verification RES on the first random number and the first key using a first calculation method; The first device calculates the second verification RES based on the first verification RES and the first key by using a first calculation method.

85. The method of claim 84, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

86. The method of claim 84, wherein: The first message also carries the first verification RES.

87. The method according to any one of claims 82 to 86, wherein: The second device is an environment-powered Internet of Things (AIoT) device; 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.

88. An authentication method comprising: The second device receives a second message from the first device, where the second message carries the authentication parameter; The second device calculates a second RES based on the authentication parameter and a first key, the first key being associated with the first device; The second device sends a third message to the first device, where the third message carries the second RES, and the second RES is used by the first device to authenticate the second device.

89. The method of claim 88, wherein: The authentication parameter includes one of the following: an anonymous key, a first random number; the second device calculates a second RES based on the authentication parameter and the first key, including one of the following: The second device calculates the second RES based on the anonymous key and the first key using a first calculation method; The second device calculates the second RES based on the first random number and the first key using the first calculation method; The second device calculates the second RES based on the first RES and the first key by using the first calculation method.

90. The method of claim 89, wherein: The first key is at least one of the following: a first intermediate key calculated based on the identification of the first device and a second random number, and a physical layer key, where the physical layer key is a key shared by the second device and the first device.

91. The method according to any one of claims 88 to 90, wherein: The first device includes at least one of the following: a terminal device, an access network device, and an authentication device; the second device is an environment-powered Internet of Things (AIoT) device.

92. A first device, comprising: A first communication unit, configured to receive a first message from a first network device, wherein the first message carries a MAC, an authentication parameter, and an identifier of a second device; A second message is sent to the second device, where the second message carries the MAC and the authentication parameters, where the authentication parameters are 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 the core network side device in combination with the MAC, where the root key is a key shared by the second device and the core network side device.

93. A second device, comprising: A second communication unit, configured to receive a second message from the first device, where the second message carries a message authentication code MAC and an authentication parameter; A second processing unit, configured to calculate a verification MAC based on the authentication parameter and a root key, where the root key is a key shared by the second device and a core network side device; When the verification MAC is identical to the MAC, the second device completes authentication of the core network side device.

94. 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 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 the core network side device in combination with the MAC, and the root key is a key shared by the second device and all core network side devices.

95. An electronic device comprising: a fourth processing unit, configured 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 sent data and / or decrypt received data.

96. A first device, comprising: A first communication unit, configured to receive a first message from a first network device, wherein the first message carries an authentication parameter and an identifier of a second device; Sending a second message to the second device, where the second message carries authentication parameters; receiving a third message from the second device, where the third message carries a first RES, where the first RES is obtained by the second device based on the authentication parameter and a root key, where the root key is a key shared by the second device and all core network side devices; A fourth message is sent to the first network device, where the fourth message carries the first RES, and the first RES is used by a core network side device to authenticate the second device.

97. A second device, comprising: A second communication unit, configured to receive a second message from the first device, wherein the second message carries an authentication parameter; Sending a third message to the first device, where the third message carries the first RES, and the first RES is used by a core network side device to authenticate the second device; The second processing unit is used to calculate a first RES based on the authentication parameter and a root key, where the root key is a key shared by the second device and all core network side devices.

98. A first network device, comprising: A third communication unit, configured to send a first message to the first device, where the first message carries the authentication parameter and the identifier of the second device; receiving a fourth message from the first device, where the fourth message carries the first RES, where the first RES is obtained by the second device based on the authentication parameter and a root key, where the root key is a key shared by the second device and all core network side devices; The third processing unit is configured to determine that the second device authentication is successful when the first RES is the same as the first verification RES.

99. A first device, comprising: A first communication unit, configured to send a second message to a second device, where the second message carries an authentication parameter; receiving a third message from the second device, the third message carrying a second RES, the second RES being related to the authentication parameter and the first key; A first processing unit, configured to generate a second verification RES based on the authentication parameter and the first key; When the second verification RES is the same as the second RES, it is determined that the second device authentication is successful.

100. A second device, comprising: A second communication unit, configured to receive a second message from the first device, wherein the second message carries an authentication parameter; Sending a third message to the first device, where the third message carries the second RES, and the second RES is used by the first device to authenticate the second device; The second processing unit is configured to calculate a second RES based on the authentication parameter and a first key, where the first key is related to the first device.

101. A first device, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory so that the first device performs the method as described in any one of claims 1 to 18, or claims 64 to 69, or claims 82 to 87.

102. A second device, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory so that the second device performs the method as described in any one of claims 19 to 38, or claims 70 to 77, or claims 88 to 91.

103. A first network device, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory so that the first network device executes the method as described in any one of claims 39 to 53 or claims 78 to 81.

104. An electronic device comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory so that the electronic device executes the method as described in any one of claims 54 to 63.

105. A chip, comprising: A processor for calling and running a computer program from a memory so that a device equipped with the chip performs a method as described in any one of claims 1 to 18, or claims 19 to 38, or claims 39 to 53, or claims 54 to 63, or claims 64 to 69, or claims 70 to 77, or claims 78 to 81, or claims 82 to 87, or claims 88 to 91.

106. A computer-readable storage medium for storing a computer program, which, when executed by a device, causes the device to perform the method described in any one of claims 1 to 18, or claims 19 to 38, or claims 39 to 53, or claims 54 to 63, or claims 64 to 69, or claims 70 to 77, or claims 78 to 81, or claims 82 to 87, or claims 88 to 91.

107. A computer program product comprising computer program instructions which cause a computer to perform a method as described in any one of claims 1 to 18, or claims 19 to 38, or claims 39 to 53, or claims 54 to 63, or claims 64 to 69, or claims 70 to 77, or claims 78 to 81, or claims 82 to 87, or claims 88 to 91.

108. A computer program, the computer program causing a computer to perform the method of any one of claims 1 to 18, or claims 19 to 38, or claims 39 to 53, or claims 54 to 63, or claims 64 to 69, or claims 70 to 77, or claims 78 to 81, or claims 82 to 87, or claims 88 to 91.

Images