Method for communication and communication device

Abstract

A method for communication and a communication device are provided. The method comprises the following steps: a first device generates a first key based on a shared key; the first device receives a second random number of the second device; the first device generates first authentication information of the first device based on the first key; the first device sends a first message to the second device, wherein the first message comprises the first authentication information; wherein the first authentication information is generated according to one or more of the following information: device information, service related information, an identifier of a device forwarding the first message, a first random number of the first device, and a second random number. Compared with the prior art, the first authentication information can bear more information. Therefore, the authentication attribute can be added, so that the security authentication process based on the first authentication information can verify more information. In addition, the security authentication process based on the first authentication information can also realize key negotiation.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a method and a communication device for communication. Background Technology

[0002] To meet communication security requirements, communication devices need to undergo security authentication before communication interaction. Security authentication can be one-way or two-way. Taking two-way security authentication as an example, both parties in the communication can authenticate each other. When both parties pass the security authentication, they can transmit encrypted data.

[0003] In communication systems, various security authentication protocols have been proposed for different terminals. However, these security authentication schemes suffer from the problem of limited authentication attributes. Summary of the Invention

[0004] This application provides a method and a communication device for communication. The various aspects covered by this application are described below.

[0005] In a first aspect, a method for communication is provided, the method comprising: a first device generating a first key based on a shared key; the first device receiving a second random number from a second device; the first device generating first authentication information based on the first key; the first device sending a first message to the second device, the first message including the first authentication information; wherein the first authentication information is generated based on one or more of the following: information related to the first device in relation to a service, an identifier of the device forwarding the first message, a first random number of the first device, and a second random number.

[0006] In a second aspect, a method for communication is provided, the method comprising: a second device sending a second random number; the second device receiving a first message sent by a first device; wherein the first message includes first authentication information of the first device, the first authentication information being generated based on a first key, and the first authentication information being generated based on one or more of the following information: information related to the first device as to a service, an identifier of the device forwarding the first message, a first random number of the first device, and a second random number, and the first key being generated based on a shared key.

[0007] Thirdly, a method for communication is provided, the method comprising: a third device receiving a first message sent by a first device; the third device sending the first message to a second device; wherein the first message includes first authentication information of the first device, the first authentication information being generated based on a first key, and the first authentication information being generated based on one or more of the following information: service-related information of the first device, an identifier of the device forwarding the first message, a first random number of the first device, and a second random number of the second device, and the first key being generated based on a shared key.

[0008] Fourthly, a communication device is provided, which is a first device, comprising: a key generation unit for generating a first key based on a shared key; a first receiving unit for receiving a second random number from a second device; a generation unit for generating first authentication information of the first device based on the first key; and a first sending unit for sending a first message to the second device, the first message including the first authentication information; wherein the first authentication information is generated based on one or more of the following: information related to the first device's business, an identifier of the device forwarding the first message, a first random number of the first device, and a second random number.

[0009] Fifthly, a communication device is provided, which is a second device, comprising: a second transmitting unit for transmitting a second random number; and a second receiving unit for receiving a first message transmitted by a first device; wherein the first message includes first authentication information of the first device, the first authentication information being generated based on a first key, and the first authentication information being generated based on one or more of the following information: information related to the first device as a service, an identifier of the device forwarding the first message, a first random number of the first device, and a second random number, and the first key being generated based on a shared key.

[0010] A sixth aspect provides a communication device, which is a third device, comprising: a third receiving unit for receiving a first message sent by a first device; and a third sending unit for sending the first message to a second device; wherein the first message includes first authentication information of the first device, the first authentication information being generated based on a first key, and the first authentication information being generated based on one or more of the following information: service-related information of the first device, an identifier of the device forwarding the first message, a first random number of the first device, and a second random number of the second device, and the first key being generated based on a shared key.

[0011] In a seventh aspect, a communication device is provided, including a processor and a memory, the memory for storing one or more computer programs, the processor for calling the computer programs in the memory to cause the communication device to perform some or all of the steps in the above method.

[0012] Eighthly, embodiments of this application provide a communication system including the aforementioned communication device. In another possible design, the system may further include other devices that interact with the communication device as described in the embodiments of this application.

[0013] Ninthly, embodiments of this application provide a computer-readable storage medium storing a computer program that causes a communication device to perform some or all of the steps in the methods described above.

[0014] In a tenth aspect, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a communication device to perform some or all of the steps of the methods described in the foregoing aspects. In some implementations, the computer program product may be a software installation package.

[0015] In one aspect, embodiments of this application provide a chip including a memory and a processor, the processor being able to call and run a computer program from the memory to implement some or all of the steps described in the methods of the above aspects.

[0016] Compared with related technologies, the first authentication information in this application can be generated based on one or more of the following: device information, service-related information, the identifier of the device forwarding the first information, and security parameters. In other words, the first authentication information can carry more information. Therefore, this application can add authentication attributes, thereby enabling the security authentication process based on the first authentication information to verify more information. Furthermore, since the first authentication information is generated based on the first key, the security authentication process based on the first authentication information can achieve key negotiation. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the wireless communication system used in the embodiments of this application.

[0018] Figure 2 A schematic diagram of the key derivation architecture for 5GAKA and EAP-AKA'.

[0019] Figure 3A This is a schematic diagram of the encryption part of the ASCON-AEAD algorithm.

[0020] Figure 3B This is a schematic diagram of the decryption part of the ASCON-AEAD algorithm.

[0021] Figure 4 This is a schematic flowchart of a communication method provided in an embodiment of this application.

[0022] Figure 5 This is a schematic diagram of a key derivation architecture provided in an embodiment of this application.

[0023] Figure 6 This is a schematic diagram of another key derivation architecture provided in the embodiments of this application.

[0024] Figure 7 This is a schematic flowchart of a communication method provided in Embodiment 1 of this application.

[0025] Figure 8 This is a schematic flowchart of a communication method provided in Embodiment 2 of this application.

[0026] Figure 9 This is a schematic flowchart of a communication method provided in Embodiment 3 of this application.

[0027] Figure 10 This is a schematic flowchart of a communication method provided in Embodiment 4 of this application.

[0028] Figure 11 This is a schematic flowchart of a communication method provided in Embodiment 5 of this application.

[0029] Figure 12 This is a schematic structural diagram of a communication device provided in an embodiment of this application.

[0030] Figure 13 This is a schematic structural diagram of another communication device provided in the embodiments of this application.

[0031] Figure 14 This is a schematic structural diagram of another communication device provided in the embodiments of this application.

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

[0033] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0034] Communication system Figure 1 This is the wireless communication system 100 used in the embodiments of this application. The wireless communication system 100 may include communication devices. The communication devices may include access network device 110, terminal 120, and core network device 130.

[0035] Figure 1 An exemplary network device and two terminals are shown. Optionally, the wireless communication system 100 may include multiple network devices and each network device may include other numbers of terminals within its coverage area. This application embodiment does not limit this.

[0036] It should be understood that the technical solutions of the embodiments of this application can be applied to various communication systems, such as: 5th generation (5G) systems or New Radio (NR), Long Term Evolution (LTE) systems, LTE frequency division duplex systems, LTE time division duplex systems, etc. The technical solutions provided in this application can also be applied to future communication systems, such as 6th generation mobile communication systems, satellite communication systems, etc.

[0037] The terminal in the embodiments of this application may be referred to as a user equipment (UE), access terminal, mobile terminal, wireless terminal, user unit, or user agent. The terminal in the embodiments of this application may be a device that provides voice and / or data connectivity to a user, such as a handheld device with wireless connectivity, an in-vehicle device, etc. The terminal in the embodiments of this application may also be a mobile phone, tablet computer, laptop computer, PDA, mobile internet device, wearable device, etc.

[0038] The network device in this application embodiment can be a device used for communication with a terminal. The network device may include access network equipment or a base station, communicating with the terminal 120 located within a specific coverage area. The access network equipment in this application embodiment can refer to a NodeB (NodeB), evolved NodeB (eNB), next-generation base station (gNB), relay station, home base station, network controller, access point (AP), etc., that connects the terminal to the wireless network. The base station can also be a device that performs base station functions in wireless communication, a network-side device in a 6G network, or a device that performs base station functions in a future communication system. The base station can support networks with the same or different access technologies. The embodiments of this application do not limit the specific technology or device form used in the access network equipment.

[0039] The network equipment may include core network equipment 130. In this embodiment, the core network may include entities that process and forward user signaling and data. For example, the core network may include entities such as Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Gateway, Location Management Function (LMF), Authentication Service Function (AUSF), and Unified Data Management Function (UDM). The AUSF can receive AMF requests for terminal authentication, request keys from the UDM, and then forward the issued keys to the AMF for authentication processing. The UDM may include functions such as generating and storing user subscription data and managing authentication data, and supports interaction with external third-party servers.

[0040] Network devices and terminals can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on airplanes, balloons, and satellites. This application does not limit the scenario in which the network devices and terminals are located.

[0041] It should be understood that all or part of the functions of the communication device in this application can also be implemented by software functions running on hardware, or by virtualization functions instantiated on a platform (such as a cloud platform).

[0042] Zero-power communication technology With the development of wireless communication technology, the integration of wireless communication systems with various vertical industries such as logistics, manufacturing, transportation, and energy has become a trend. In these industries, terminals typically require characteristics such as low cost, small size (e.g., ultra-thin), maintenance-free operation, and long lifespan. To address this, zero-power communication technology has been proposed. Zero-power communication systems can be used in scenarios such as wireless industrial sensor networks, smart agriculture, smart warehousing and logistics, and smart homes.

[0043] Zero-power technology primarily combines radio frequency (RF) energy harvesting, backscattering, and low-power computing technologies to achieve the advantage of device nodes not requiring a power supply. The core of RF energy harvesting is converting RF energy into DC. This energy can be stored in batteries or capacitors, or directly used to drive logic circuits, digital chips, or sensors, enabling functions and applications such as modulation and transmission of backscattered signals, and the acquisition and processing of sensor information.

[0044] In zero-power communication technology, terminals can be divided into three categories based on their energy source and energy usage: passive zero-power terminals, semi-passive zero-power terminals, and active zero-power terminals.

[0045] It's worth noting that during standardization discussions, zero-power IoT can also be called Ambient Power-enabled Internet of Things (AIoT), or simply Ambient IoT. AIoT devices can refer to IoT devices that use various environmental energy sources such as radio frequency energy, light energy, solar energy, thermal energy, and mechanical energy. AIoT devices may have no energy storage capacity or very limited energy storage capacity (e.g., using capacitors with a capacitance of tens of microseconds).

[0046] Security Certification To meet communication security requirements, communication devices can perform security authentication before communication interactions. Security authentication can be bidirectional, meaning both parties can authenticate each other. Once both parties' authentications are successful, encrypted data can be transmitted.

[0047] In communication systems, various security authentication protocols have been proposed for different terminals. Taking the 3GPP standard as an example, security authentication protocols can be applied to one or more of the following: ordinary terminals, Cellular Internet of Things (CIoT) devices, and Machine-Type Communication (MTC) devices. Security authentication schemes suitable for ordinary terminals may include 5GAKA, EAP-AKA', or EPSAKA, etc. Security authentication schemes suitable for CIoT devices may include CP CIoT security schemes suitable for small-value data transmissions. The BEST authentication scheme is specifically designed for MTC devices. The BEST authentication scheme can be implemented based on different authentication protocols. For example, the BEST authentication scheme can be implemented based on the following authentication protocols: 5GAKA, EAP-AKA', EPSAKA, GBA, or AKMA.

[0048] Different security authentication schemes can correspond to different key derivation architectures. For example, Figure 2 This is a schematic diagram of the key derivation architecture of 5GAKA and EAP-AKA'.

[0049] As can be seen from the key derivation structure described above, communication devices need to derive multiple types of keys. For example, in schemes such as 5GAKA, EAP-AKA', and EPSAKA, which are applicable to ordinary terminals, the keys that need to be derived may include non-access stratum control plane keys, access stratum control plane keys, user plane keys, and intermediate keys.

[0050] Overhead of security authentication In 3GPP standard authentication schemes, when using two-way authentication, the security computation overhead required for the terminal and network device to perform the authentication process is the same, requiring one f1, f2 operation and one HMAC operation. Different authentication schemes have different key derivation architectures, and their corresponding computational overheads also differ. For example, 5GAKA requires one f3, f4, f5 operation and 10 HMAC-SHA256 operations. EAP-AKA' requires one f3, f4, f5 operation and 11 HMAC-SHA256 operations.

[0051] Authentication encryption algorithm To support high security and performance in computationally limited environments, lightweight Authenticated Encryption with Associated Data (AEAD) algorithms have gained increasing attention. AEAD is a form of encryption that simultaneously provides confidentiality, integrity, and authentication. Its emergence stems from the fact that simple encryption and decryption algorithms lack authentication capabilities; the decryptor cannot know whether the decrypted information has been tampered with by a man-in-the-middle. Therefore, an algorithm that combines encryption and authentication is needed.

[0052] The AEAD algorithm primarily uses the Advanced Encryption Standard (AES) algorithm with Galois or Counter modes. While this algorithm is efficient in most cases, its use is limited by resource constraints. Therefore, the demand for lightweight algorithms is growing. ASCON, with its high security and low implementation cost, was selected as a lightweight cryptographic standard by the National Institute of Standards and Technology (NIST). The AEAD and hash algorithms within ASCON were selected by NIST as lightweight cryptographic algorithm standards.

[0053] The ASCON-AEAD algorithm consists of two parts: encryption and decryption. The algorithm as a whole uses a sponge cryptographic structure. Figure 3A This is a schematic diagram of the encryption part of the ASCON-AEAD algorithm. Figure 3B This is a schematic diagram of the decryption part of the ASCON-AEAD algorithm.

[0054] The encryption and decryption processes in the ASCON-AEAD algorithm are basically the same in terms of process and structure. For example... Figure 3A As shown, the encryption part includes four stages: initialization, associated data, plaintext (ciphertext), and finalization. Figure 3BAs shown, the decryption process includes four stages: initialization, associated data, ciphertext, and end. The ASCON-AEAD algorithm primarily involves the following parameters: key K, plaintext P, associated information A, ciphertext C, pre-configured initialization vector IV, and random number N. A can include one or more of the following: the plaintext to be protected, the ciphertext, the device's identity information, and additional information such as an IP address. ASCON-AEAD generates an authentication tag (hereinafter referred to as T). That is, the output of ASCON-AEAD can include the authentication tag T. The authentication tag T can be used to authenticate the integrity of the associated information A.

[0055] The difference between the encryption and decryption parts lies in the reversed input and output of plaintext and ciphertext. The ASCON-AEAD encryption part can accept K, A, and P as inputs, and C and T as outputs. The decryption part can accept K, A, and C as inputs, and P and T' as outputs. A can be authenticated by comparing T and T'.

[0056] As mentioned above, related technologies have proposed various security authentication protocols applicable to different terminals. However, the inventors of this application have discovered that the security authentication schemes of related technologies suffer from the problem of having a single authentication attribute. Therefore, this application proposes a security authentication scheme. The following is an example... Figure 4 Taking an example, we will illustrate the technical solution proposed in this application.

[0057] Figure 4 This is a schematic flowchart of a communication method provided in an embodiment of this application.

[0058] Figure 4 The operation can be performed by a first device and a second device. For example, the first device may include a terminal, and the second device may include a network device.

[0059] In some embodiments, the first device may be an AIoT terminal. The second device may include one or more network devices. The second device may, for example, include a UDM that stores or manages shared keys. Alternatively, the second device may include one or more of the following: Network Function (NF) and Application Function (AF) devices. The NF may include one or more of the following: AMF, AUSF, Session Management Function (SMF), Network Exposure Function (NEF), Key Management Server (KMS), Authentication and Key Management for Applications (AKMA) Anchor Function (AAnF), Bootstrapping Server Function (BSF), Home Public Land Mobile Network (HPLMN) Security Endpoint (HSE), Unified Data Repository (UDR), Security Anchor Function (SEAF), and a dedicated core network for authentication. Alternatively, the second device may include a gateway for a wireless local area network (WLAN).

[0060] In cases where the second device includes an AF device and a UDM, a secure channel can be established between the AF device and the UDM. Establishing the secure channel can be performed before authentication.

[0061] Figure 4 The method shown may include step S430.

[0062] In step S430, the first device generates first authentication information based on the first key.

[0063] The authentication information described in this application can be used for one or more of the following in the implementation: identity authentication of the corresponding communication device, secure transmission authentication, security and / or integrity authentication of transmitted content, key negotiation, etc. Only after successful verification can the communication device communicate with the other party. For example, the first authentication information of the first device can be used to verify one or more of the following: identity authentication of the first device, secure transmission status authentication of the first device, security and / or integrity authentication of the transmitted content of the first device. Furthermore, the first authentication information is generated based on the first key. Therefore, based on the first authentication information, operations such as key negotiation between the first device and the second device can be implemented.

[0064] The first key can be a shared key between the first device and the second device. The shared key can be the root key in a key derivation architecture. Taking an AIoT terminal as the first device and a network device as an example, the shared key can be a key shared between the AIoT terminal and the network device. In some embodiments, the shared key can be a symmetric key, meaning that the shared key stored in the first device and the second device can be the same.

[0065] The first key can be generated or derived from a shared key. Figure 4 The method shown may include step S410. In step S410, the first device derives a first key based on the shared key.

[0066] As one implementation, a first key can be derived from a shared key through a first key derivation function. The input parameters of the first key derivation function may include one or more of the following: a shared key, a first identifier of the first device, the length of the first identifier, a first random number, the length of the first random number, a second random number, the length of the second random number, and a fixed value assigned by a third party. The fixed value could be, for example, FC=0x7E. Based on step S410, the key derivation architecture proposed in this application is as follows: Figure 5 As shown. In Figure 5 The first key in the middle is through K AF The shared key is represented by K. In some embodiments, the first key can also be represented by K. NF or K gate Indicates. For example... Figure 5 As shown, the shared key K can be used to derive the first key K. AF .Depend on Figure 5 As can be seen, the key derivation architecture proposed in this application is more lightweight. Therefore, during security authentication, communication devices can reduce the computational overhead of deriving keys, thereby reducing energy consumption. For example, when the first device is an AIoT terminal, the lightweight key derivation architecture can further save the computational overhead of the AIoT terminal, enabling it to complete the communication process with less energy consumption.

[0067] It should be noted that the first random number can be generated by the first device. The second random number can be generated by the second device. Figure 4 The method shown may include step S420. In step S420, the second device sends a second random number to the first device.

[0068] As mentioned above, the first authentication information can be generated based on the first key. The first authentication information can also be generated based on one or more of the following: device information, service-related information, the identifier of the device forwarding the first information, security parameters, etc. These will be explained separately below.

[0069] Device information can be used to indicate the identity of the device participating in security authentication. For example, device information may include one or more of the following: the identity information of a first device and the identity information of a second device. The identity information of the first device may include: AIoT ID. The identity information of the second device may include one or more of the following: AF ID, NF ID, and Public Land Mobile Network (PLMN) ID.

[0070] Business-related information can be used to indicate information related to the transmission of business data. For example, business-related information may include one or more of the following: service type identity, plaintext of the business data, and ciphertext of the business data.

[0071] The device that forwards the first message may include a base station and / or a third device. For example, the identifier of the device forwarding the first message may include one or more of the following: the identifier of the terminal device (as a relay node), and the identifier of the base station. The identifier of the terminal device may include one or more of the following: Subscription Concealed Identifier (SUCI), Subscription Permanent Identifier (SUPI), and Generic Public Subscription Identifier (GPSI). The identifier of the base station may include: RAN node identity.

[0072] Security parameters can be used to achieve secure transmission. For example, security parameters may include one or more of the following: a first random number from a first device, a second random number from a second device, parameters related to secure computation, etc.

[0073] The first authentication information can be obtained based on a first algorithm. The first algorithm can be, for example, the ASCON-AEAD algorithm. The input to the first algorithm can include the parameters used to generate the first authentication information. For example, the input or associated data A of the first algorithm can include one or more of the following: a first key, information related to the first device and the service, the identifier of the device forwarding the first message, a first random number, and a second random number. The first authentication information can include the verification tag T output by the first algorithm.

[0074] Compared with related technologies, the first authentication information in this application can be generated based on one or more of the following: device information, business-related information, the identifier of the device forwarding the first information, and security parameters. In other words, the first authentication information can carry more information. Therefore, this application can add authentication attributes, thereby enabling the security authentication process based on the first authentication information to verify more information.

[0075] Figure 4 The method shown may include step S440.

[0076] In step S440, the first device can send a first message to the second device.

[0077] The first message may include initial authentication information. For example, the first message may include an authentication request sent by a first device. In the case of two-way authentication, the first message may include an authentication request and / or an authentication response message.

[0078] In some implementations, the first device may send the first message via one or more communication devices. Figure 4 For example, one or more communication devices may include a third device performing the action. Step S440 may include: the first device sending a first message to the third device; and the third device sending a first message to the second device.

[0079] By forwarding the first message through a third device, the third device can participate in the communication process between the first and second devices, thereby further reducing the energy consumption of the first device. For example, the first device can be an AIoT terminal, and the third device can be a regular terminal. The AIoT terminal can communicate with the regular terminal with lower energy consumption, while the regular terminal can provide more energy to communicate with the second device, thus enabling the AIoT terminal to communicate with the third device while consuming less energy.

[0080] Considering that the third device can forward information between the first and second devices, the third device can also be called a relay node or proxy node of the first device.

[0081] In some embodiments, the first device may send the first message without going through a third device. For example, if the third device is a normal device, the first device may send the first message directly to the third device through a base station.

[0082] In addition to the initial authentication information, the first message may also include ciphertext corresponding to the business data. This ciphertext can correspond to the business data and / or signaling. The ciphertext is obtained by encrypting the plaintext business data and / or signaling.

[0083] In related technologies, authentication information and ciphertext are transmitted in two separate messages. This application transmits authentication information and ciphertext in a single message, reducing the transmission of at least one message and thus lowering the power consumption of the communication device. In other words, based on this application, authentication and key confirmation of the communication device can be achieved with a single signaling message, thereby ensuring the confidentiality and integrity of received business data. Furthermore, for zero-power terminal communication, this application meets the ultra-low power consumption requirements of zero-power terminals by optimizing the terminal's security computation overhead and the number of transmissions. Simultaneously, this application reduces the energy consumption required for communication processing in zero-power terminals, further ensuring the normal operation of zero-power terminals under conditions of limited energy supply, ultimately improving the user experience.

[0084] In some embodiments, the ciphertext can be generated based on a first key. That is, the first key can be used to achieve: confidentiality protection of signaling and / or business data, integrity protection of signaling and / or business data, and communication authentication.

[0085] In some embodiments, both the ciphertext and the first authentication information can be generated based on a first key. For example, the first key can be input into a first algorithm, which can output the ciphertext and the first authentication information. The input to the first algorithm may include, for example, the first key and service data. The output of the first algorithm may include, for example, the ciphertext and the first authentication information. The input to the first algorithm may also include associated data A. Associated data A may include data used to determine the first authentication information. For example, associated data A may include one or more of the following: the first key, information related to the first device and the service, the identifier of the device forwarding the first message, a first random number, a second random number, and service data. The service data may include transmitted data and / or the full text of the message, etc.

[0086] In related technologies, communication devices need to perform authentication and encryption operations separately, requiring at least two operations. In this application, the first algorithm enables authentication and encryption with a single operation. Therefore, this application reduces computational consumption and meets the low-power requirements of zero-power terminals. Furthermore, as mentioned above, the first algorithm may include the ASCON-AEAD algorithm. The ASCON-AEAD algorithm is a lightweight algorithm, offering the advantage of low cost and alleviating the pressure on the limited hardware and software resources of communication devices.

[0087] In some embodiments, the ciphertext can be obtained based on a second key derived from the first key, and the first authentication information can be obtained based on a third key. The third key can be a different key from the second key. In these embodiments, the second key can be used to encrypt data, i.e., to protect the confidentiality of signaling and / or business data. Therefore, the second key can also be called a confidentiality key. The third key can be used to verify the integrity of the ciphertext and also to perform authentication. Therefore, the third key can also be called an integrity protection verification code. Alternatively, the third key can also have the functionality of RES. When the first authentication information is obtained based on the third key, the first authentication information may include a Message Authentication Code (MAC).

[0088] Based on the second and / or third key, the key derivation architecture can be as follows: Figure 6 As shown. A shared key K can be used to derive a first key K. AF First key K AF A second key K can be derived. CK and the third key K IK .

[0089] As one implementation, a second key can be derived from a second key derivation function. The input to the second key derivation function can include one or more of the following: a first key, and a fixed value assigned by a third party. For example, the fixed value could be FC=0x7E. The output of the second key derivation function can include one or more of the following: a first random number, the length of the first random number, a second random number, the length of the second random number, and the second key.

[0090] As one implementation, a third key can be derived from a third key derivation function. The input to the third key derivation function can include one or more of the following: a first key, and a fixed value assigned by a third party. For example, the fixed value could be FC=0x7E or FC=0x6B. The output of the third key derivation function can include one or more of the following: a first random number, the length of the first random number, a second random number, the length of the second random number, and the third key.

[0091] At least two items in the key derivation functions described above can be the same. For example, the second key derivation function can be the same as the third key derivation function. As one implementation, both the second and third key derivation functions can be KDF functions. When the second and third key derivation functions are the same, the input to the second key derivation function (which can also be called the third key derivation function) can further include: the key identifier of the key to be output, and the length of the key identifier. For example, if the second key needs to be output, the key identifier can be 0x00; if the third key needs to be output, the key identifier can be 0x01. Or, if the second key needs to be output, the key identifier can be 0x01; if the third key needs to be output, the key identifier can be 0x00.

[0092] The third key includes RES In this case, the fourth key derivation function can be used to generate RES. The input parameters of the fourth key derivation function may include one or more of the following: a shared key, a first random number, a second random number, the length of the first random number, the length of the second random number, RES, the length of RES, and a fixed value assigned by a third party. The fixed value may be, for example, FC = 0x6B. RES can be generated using the f2 function. The input to the f2 function may include one or more of the following: a shared key, and a random number R2. The f2 function can be obtained based on the specifications in TS 35.206.

[0093] Both parties to the authentication can use the key derivation method described above to derive the corresponding key. That is, both parties can use the above method to derive one or more of the first key, second key, and third key. Taking a second device including a UDM as an example, the second device can derive the first key based on the first random number, the second random number, and the shared key. Alternatively, the second device can request other communication devices to derive the key. Taking a second device including an AF device as an example, the second device can send a second request. This second request can be used to derive the first key. The communication device receiving the second request can be a UDM. When the UDM receives the second request, the second device can derive the first key. The method for deriving the first key can be referred to above and will not be repeated here.

[0094] This application does not limit the length of the aforementioned keys. For example, the length of the shared key, the first key, the second key, or the third key can be greater than or equal to 128 bits.

[0095] As one implementation, based on the second and third keys, the first or second device can use confidentiality and integrity protection algorithms from related technologies. For example, the confidentiality and integrity protection algorithms in TS33.501 can be used.

[0096] Based on the above method, the first device can generate ciphertext and first authentication information. The second device can receive the ciphertext and first authentication information via a first message. After receiving the first message, the second device can verify the first authentication information. If the first authentication information verification is successful, the second device can decrypt the ciphertext to obtain the business data. If the first authentication information verification fails, the second device can reject the first message.

[0097] If the first device uses the first algorithm, the second device can also verify the first authentication information based on the first algorithm. The input to the first algorithm run by the second device may include one or more of the following: a first key, ciphertext, and associated information A. The output of the first algorithm may include plaintext business data and / or verification information T'. The second device can determine whether the verification was successful by comparing the verification tag T and the verification information T' in the first authentication information.

[0098] If the first device uses the confidentiality and integrity protection algorithm in TS33.501, the UDM can verify the first authentication information. That is, the second device can include the UDM, or the second device (e.g., the AF device) can forward the first authentication information to the UDM. After the UDM successfully verifies the first authentication information, the UDM can reply with an authentication success message to the AF device. Upon receiving the authentication success message, the AF device can use the corresponding key derivation function to derive a second key and a third key. The third key can be used for MAC verification. If MAC verification fails, the first message can be rejected. If MAC verification succeeds, the second key can be used to decrypt the ciphertext to obtain the plaintext service data and / or signaling.

[0099] In some embodiments, the first key can also be used to generate second authentication information for the second device. That is, based on the first key, authentication information for both communicating parties can be generated. Taking the first device as a terminal and the second device as a network device as an example, the first key can be used to generate bidirectional authentication information between the terminal and the network device.

[0100] As mentioned above, the ciphertext and / or the first authentication information can be obtained using random numbers (including a first random number and / or a second random number). Random numbers not only increase authentication security but also help detect and prevent replay attacks. Since the random number is highly likely to be different from previously generated random numbers, if the receiver finds that the first random number and / or second random number are the same for two transmissions, the receiver can determine that a replay attack has occurred and abandon receiving the corresponding data.

[0101] To achieve authentication, the first device can perform the authentication process based on the first authentication information. The authentication process can be bidirectional or unidirectional.

[0102] The following explains one-way authentication. One-way authentication can enable secure authentication from a first device to a second device, or from a second device to a first device.

[0103] In one-way authentication, the first device can send a first authentication request to the second device. This first authentication request can be used to request the second device to authenticate the first device. The following example, using an AIoT terminal as the first device and a network device as the second device, illustrates one-way authentication in detail. During the initial access of the AIoT terminal, AIoT registration can trigger the network device to authenticate the AIoT terminal. For example, the AIoT terminal can send a first authentication request including first authentication information. Taking the ASCON-AEAD algorithm as an example, the AIoT terminal can calculate the ciphertext C and the verification tag T, and send C and T to the network device through the first authentication request. Based on the first authentication request, the network device can authenticate and register the AIoT terminal. If authentication and registration are successful, the network device can send an authentication response to the AIoT terminal. After receiving the authentication response, the AIoT terminal can continue to authenticate the network device or choose not to. If the AIoT terminal does not authenticate the network device, the above process achieves one-way authentication from the network device to the AIoT terminal.

[0104] In one-way authentication, the second device can send a first authentication request to the first device. This first authentication request can be used to request the first device to authenticate the second device. The following example, using the second device as an AIoT terminal and the first device as a network device, illustrates one-way authentication in detail. After the AIoT terminal has successfully registered with the network device, the network device can trigger the AIoT terminal to authenticate itself. For example, the network device can send an authentication request to the AIoT terminal including first authentication information. Taking the first algorithm as an example, which includes the ASCON-AEAD algorithm, the network device can calculate the ciphertext C and the verification tag T, and send C and T to the AIoT terminal through the first authentication request. In response to receiving the authentication request, the AIoT terminal can authenticate the network device and generate a context. If authentication is successful, the AIoT terminal can send an authentication response to the network device. After receiving the authentication response, the network device can continue to authenticate the AIoT terminal or choose not to authenticate it. If the network device does not authenticate the AIoT terminal, the above process achieves one-way authentication from the AIoT terminal to the network device.

[0105] The following describes two-way authentication. Two-way authentication enables mutual authentication between a first device and a second device. Taking an AIoT terminal as the first device and a network device as the second device as an example, the two-way authentication process can include authentication of the AIoT terminal by the network device and authentication of the network device by the AIoT terminal. In some embodiments, the first device can send a first authentication request. The first authentication request can be used to request two-way identity authentication between the first device and the second device. After receiving the first authentication request, the second device can generate second authentication information and send it to the first device via a first authentication response, so that the first device can authenticate the second device. After the first device successfully authenticates the second device, the first device can send the first authentication information to the second device, so that the second device can authenticate the first device. If the second device also successfully authenticates the first device, the above two-way authentication process is successful, and the first device can communicate securely with the second device.

[0106] The following description uses a second device including a UDM as an example to illustrate the transmission of the first authentication request. It is understood that the UDM in the embodiments below can also be replaced by other communication devices with the function of storing or managing shared keys.

[0107] As one implementation method, UDM can directly receive the first authentication request sent by the first device through the access network device.

[0108] In one implementation, the first authentication request can be sent to the UDM via the access network device and one or more core network entities. Upon receiving the first authentication request, one or more core network entities can forward it to the UDM. These one or more core network entities may include one or more of the following: AMF, AUSF, HSE, UDR, SEAF, and a dedicated NF for forwarding the first authentication request.

[0109] The first random number generated by the first device can be included in the first authentication request. After receiving the first random number, the second device can generate second authentication information and / or ciphertext.

[0110] Based on the first random number, replay attacks can also be identified and prevented. As one implementation, after receiving the first random number, the second device can verify whether it is the same as a previously received random number. If the received first random number is the same as a previously received first random number, the second device can reject the first authentication request.

[0111] The second random number generated by the second device can be included in the first authentication response. After receiving the second random number, the first device can generate the first authentication information and / or ciphertext.

[0112] Based on the second random number, replay attacks can be identified and avoided. As one implementation, after receiving the second random number, the first device can verify whether it is the same as a previously received random number. If the received second random number is the same as a previously received second random number, the first device can reject the first authentication request.

[0113] In some embodiments, the second device may also generate second authentication information. For example, a second request may also be used to request the generation of second authentication information. Upon receiving a second request, the second device may generate the second authentication information and the first key.

[0114] In some embodiments, the UDM may not generate second authentication information. If the UDM does not generate second authentication information, other devices may generate it. For example, if the second device includes an AF device, the AF device may generate second authentication information. The response information to the second request sent by the UDM may include the second authentication information. If the response information to the second request received by the AF device does not include the second authentication information, the AF device may generate the second authentication information.

[0115] The following describes a method for generating second authentication information. This method can be applied to any network device. For example, it can be used with UDM or AF devices. The second authentication information can be generated using a security algorithm or a key derivation function. For example, the second device can derive the second authentication information (including MAC) based on the security algorithms f1 / f2 / f3 / f4 / f5 specified in TS 35.206. The input to the security algorithm can include one or more of the following: a shared key, a first random number, a second random number, etc. The output of the security algorithm can be a MAC. Alternatively, the second device can generate the MAC using a key derivation function. The input to the key derivation function can include one or more of the following: a first key, a first random number, the length of the first random number, a second random number, the length of the second random number, and a fixed value assigned by a third party. The fixed value can be, for example, FC=0x7E.

[0116] The second device can send the second authentication information to the first device. Upon receiving the second authentication information, the first device can verify it. If the second authentication information is generated using UDM calculation, the first device can derive a new verification code to verify the second authentication information. If the second authentication information is generated using AF, the first device can derive a first key using the shared key and derive a new verification code based on the first key. The process of deriving the new verification code can be the same as the process of generating the second authentication information.

[0117] In some embodiments, the first device sends the second authentication information to the security function module for verification. The security module may, for example, include a Universal Integrated Circuit Card (UICC). The process of deriving the new verification code described above can be performed by the security module.

[0118] If the first device fails to verify the second authentication information, it may refuse to respond to the second device's authentication request, and the authentication process will terminate. If the first device successfully verifies the second authentication information, it may continue the authentication process.

[0119] In some embodiments, the verification of the second authentication information can be combined with the transmission of the first message. For example, if the second authentication information is successfully verified, the first device can send the first message. If the second authentication information fails to be verified, the first device may not send the first message.

[0120] In some embodiments, the shared key may be associated with a first identifier of the first device. During the authentication process, the second device may receive the first identifier to determine the shared key associated with the first identifier.

[0121] The first identifier can be used to distinguish the first device from other communication devices. This application does not limit the type of the first identifier. For example, the first identifier may include one or more of the following identifiers of the first device: AIoT identifier, SUCI, SUPI.

[0122] In some implementations, the first device can send a first authentication request to a third device. The third device can verify the first authentication request; if the verification passes, it can forward the first authentication request to the second device. If the verification fails, the third device can reject the first authentication request. In the case of rejecting the first authentication request, the third device may choose not to send the first authentication request to the second device.

[0123] When a third device sends a first authentication request, the first authentication request may be a first authentication request processed by the third device. For example, the processed first authentication request may include information about the third device. As one possible implementation, the processed first authentication request may include a second identifier. The second identifier may, for example, include the third device's SUCI.

[0124] This application does not limit the method by which the third device verifies the first authentication request. As one possible implementation, the third device can manage the mapping relationship between its second identifier and the first identifier. In some embodiments, the third device can share this mapping relationship with the second device. The third device can verify the authentication based on whether a mapping relationship exists between the first identifier and the third device's second identifier. If a mapping relationship exists between the first identifier and the second identifier, the verification will pass. If no mapping relationship exists between the first identifier and the second identifier, the verification may fail.

[0125] In some embodiments, the first authentication request may be sent by the first device itself.

[0126] In some embodiments, the sending of the first authentication request may be triggered by a second device or a third device. That is, the second device and / or the third device may actively wake up the first device, thereby causing the first device to send the first authentication request. The information used to wake up the first device may be first trigger information. In response to the first device receiving the first trigger information, the first device may send the first authentication request. For example, when the third device and / or the second device has a service requirement, the third device and / or the second device may wake up the first device.

[0127] To facilitate understanding of this application, the following describes this application in detail through Examples 1 to 5.

[0128] Example 1 Figure 7 This is a schematic flowchart of a communication method provided in Embodiment 1. Figure 7 The method shown can be executed by AIoT terminals, access network devices, AF devices, and UDMs.

[0129] The AF device in Example 1 is merely an example. That is, the AF device in Example 1 can be replaced by one or more of the following: AMF, AUSF, HSE, UDR, SEAF, and core network dedicated NF.

[0130] The AIoT terminal and UDM share a shared key K and an AIoT ID.

[0131] Figure 7 The method shown may include steps S710 to S797.

[0132] Step S710: A secure channel is established between the AF device and the UDM.

[0133] Step S715: When the network device has a service requirement, the access network device actively wakes up the AIoT terminal.

[0134] In step S720, the AIoT terminal generates a random number R1.

[0135] In step S730, the AIoT terminal sends an authentication request message. This authentication request is the first authentication request. The authentication request includes the AIoT terminal's ID and R1.

[0136] Step S730 may include steps S731 or S732.

[0137] In step S731, the AIoT terminal sends an authentication request message directly to the UDM through the access network device. This authentication request message contains the AIoT ID and a random number R1.

[0138] In step S732, the AIoT device sends an authentication request message to the AF device through the access network device. This authentication request message contains the AIoT ID and a random number R1. Upon receiving this message, the AF sends a key request message to the UDM, which also contains the AIoT ID and the random number R1.

[0139] In step S740, after receiving the aforementioned key request message or authentication request message, UDM derives key K. AF .

[0140] Step S740 may include, for example, steps S741 to S742.

[0141] In step S741, UDM obtains the shared key K based on the AIoT ID and generates a random number R2.

[0142] Step S742, UDM derives key K based on key derivation function KDF. AF The input parameters of the Key Derivation Function (KDF) include the shared key K, AIoT ID, the length of the AIoT ID, random number R1, the length of random number R1, random number R2, the length of random number R2, and a fixed value assigned by a third party, such as FC=0x7E.

[0143] Optionally, step S740 may also include step S743.

[0144] In step S743, the UDM derives the MAC based on the security algorithms f1 / f2 / f3 / f4 / f5 specified in TS 35.206. The inputs to the security algorithms include parameters such as the key K, random number R1, and random number R2.

[0145] In step S750, the UDM sends a key reply message to the AF device. The key reply message may include K AF And a random number R2. Optionally, the key reply message may also include a MAC address.

[0146] In step S760, the AF device responds to the key message and performs the corresponding operation.

[0147] Step S760 may include step S761 or S762.

[0148] In step S761, if the key reply message contains a MAC, the AF device will not generate a MAC and will directly forward the message to the AIoT terminal.

[0149] Step S762: If the key reply message does not contain a MAC, the AF device generates a MAC using the f1 function / key derivation function.

[0150] If the f1 function is used, then the input parameters include K. AF Random numbers R1 and R2. If a key derivation function is used, then the input parameters include K. AF , random number R1, length of random number R1, random number R2 and length of random number R2, fixed value assigned by a third party, such as FC=0x7E.

[0151] Step S760 further includes step S763. In step S763, the AF device sends an authentication response message to the AIoT terminal, which contains a random number R2 and a MAC.

[0152] Step S770: AIoT terminal verifies MAC.

[0153] Step S770 may be preceded by step S765. In step S765, after the AIoT terminal receives the authentication response message, the AIoT terminal may transmit random number R1, random number R2, and MAC to its own security function module (such as UICC; if there is no security function module, then no transmission operation is required).

[0154] Step S770 may include step S771 or step S772.

[0155] Step S771: If the MAC is generated by the UDM, then the security function module derives a new verification code to verify the MAC. The AIoT terminal derives the key K. AF The process of generating new verification codes is the same as that on the network device side.

[0156] Step S772: If the MAC is calculated and generated by the AF device, then the security function module derives key K using the shared key K. AF This generates a new verification code to verify the MAC address. The AIoT terminal derives the key K. AF The process of generating new verification codes is the same as that on the network device side.

[0157] After step S770, if MAC verification fails, the AIoT terminal refuses to respond to the authentication reply message, and the process terminates. If MAC verification succeeds, the AIoT terminal can proceed to step S780.

[0158] Step S780 may include steps S781 or S782.

[0159] Step S781: If the AIoT uses the ASCON-AEAD algorithm as the cryptographic algorithm, then the AIoT terminal uses the ASCON-AEAD algorithm to output ciphertext C and verification tag T, and sends them to AF. The input of the ASCON-AEAD algorithm includes K. AF And business data.

[0160] Step S782: If the AIoT terminal uses the confidentiality and integrity protection algorithm in TS33.501, then the AIoT terminal uses the key derivation function KDF to generate the confidentiality key K. CK-AIoT and integrity key K IK-AIoT The input parameters of this algorithm include: K AF This includes the encryption algorithm identifier / security algorithm identifier, the length of the encryption algorithm identifier / security algorithm identifier, a fixed value assigned by a third party (e.g., FC=0x7E), and the identifier of the key to be output. For example, if the confidentiality key K is to be output... CK-AIoT Then the identifier of the key to be output is 0x00; if the integrity key K is to be output... IK-AIoT Therefore, the identifier of the key to be output is 0x01. The output of this algorithm includes: the length of the identifier of the key to be output, random number R1, the length of random number R1, random number R2, and the length of random number R2, etc. AIoT uses key K. CK-AIoT After encrypting and protecting the business data, ciphertext C is generated, and then key K is used. IK-AIoT The ciphertext C is protected to generate the verification code MAC1. The AIoT terminal uses the KDF function to generate RES. The input parameters of the KDF function include the shared key K, random numbers R1 and R2, the lengths of R1 and R2, RES, the length of RES, and a fixed value assigned by a third party (e.g., FC=0x6B). The AIoT terminal uses the f2 function to generate RES, with input parameters including the root key K and the random number R2.

[0161] Step S790, the AIoT terminal will send C, MAC1 and RES Send to the AF device. Alternatively, the AIoT terminal sends C and T to the AF device.

[0162] After step S790, AF may execute step S792 or step S793.

[0163] Step S792: If AIoT uses the ASCON-AEAD algorithm, then AF is based on the ASCON-AEAD algorithm and uses K AF The AF device takes the encrypted text C and the verification tag T as input and outputs plaintext business data data and verification information T'. If the verification of T fails, the AIoT terminal identity is invalid, and the AF device rejects the message in step S790. If the AF device receives a normal output, the AIoT terminal identity is valid, and the AF device can further receive the message in step S790.

[0164] Step S793: If AIoT uses the confidentiality and integrity protection algorithm in TS33.501, then AF will... Forwarded to UDM.

[0165] After step S793, UDM can execute steps S794 and S795.

[0166] Step S794, UDM uses the KDF function to generate RES ', to verify RES The generation process and the RES on the AIoT side same.

[0167] Step S795, if RES If verification is successful, the UDM replies with an authentication success message to the AF device. If RES If verification fails, then the message sent by the AF device is rejected.

[0168] After step S795, the AF device can execute steps S796 and S797.

[0169] Step S796: After the AF device receives the authentication success message, the AF device uses the key derivation function KDF to generate the confidentiality key K. CK-AIoT and integrity key K IK-AIoT The derivation process is the same as on the AIoT side.

[0170] Step S797, the AF device uses key K IK-AIoT Verify MAC1. If MAC1 verification is successful, then use key K. CK-AIoT Decrypt the ciphertext C to obtain data. If MAC1 verification fails, then reject the authentication success message.

[0171] Example 2 Figure 8 This is a schematic flowchart of a communication method provided in Embodiment 2. Figure 7 The method shown can be used by AIoT terminals and ordinary terminals ( Figure 8This is performed through the UE (User Equipment), access network devices, AF (Automatic Front-End Device), and UDM (User Device Management). The UE acts as a proxy node between the AIoT terminal and the network device.

[0172] The AF device in Example 2 is merely an example. The AF device in Example 2 can be replaced by one or more of the following: AMF, AUSF, HSE, UDR, SEAF, and core network dedicated NF.

[0173] The AIoT terminal shares key K with the UDM. The AIoT terminal does not have a SUPI, but shares an AIoT ID with the UE. The UE manages the mapping relationship between its own SUPI and AIoT ID. The UE also shares this mapping relationship with the UDM.

[0174] Figure 8 The method shown may include steps S810 to S897.

[0175] Step S810: A secure channel is established between the AF device and the UDM.

[0176] Step S816: When the network device and / or UE have service requirements, the access network device and / or UE actively wake up the AIoT terminal.

[0177] In step S820, the AIoT terminal generates a random number R1.

[0178] In step S830, the AIoT terminal sends an authentication request message to the UDM. This authentication request is the first authentication request. The authentication request includes the AIoT terminal's ID and R1.

[0179] Step S830 may include steps S831 and S832.

[0180] Step S831: The AIoT terminal sends a first authentication request message to the UE.

[0181] In step S832, after the UE receives the first authentication request, the UE first determines whether there is a mapping relationship between the AIoT ID and its own SUPI. If there is no mapping, the request from the AIoT terminal is rejected. If there is a mapping relationship, step S833 or S834 is executed.

[0182] In step S833, the UE sends an authentication request message directly to the UDM through the access network device. This authentication request message contains the UE's SUPI-encrypted SUCI, AIoT ID, and random number R1.

[0183] In step S834, the UE sends an authentication request message to the AF device through the access network device. This authentication request message contains the UE's SUPI-encrypted SUCI, AIoT ID, and random number R1. Upon receiving this message, the AF sends a key request message to the UDM, which contains the SUCI, AIoT ID, and random number R1.

[0184] In step S840, after receiving the aforementioned key request message or authentication request message, UDM derives key K. AF .

[0185] Step S840 may include, for example, steps S841 to S842.

[0186] In step S841, UDM obtains the shared key K based on the AIoT ID and generates a random number R2.

[0187] UDM can decrypt the SUCI carried in the message to obtain SUPI, and obtain the shared key K between SUPI and AIoT ID based on the mapping relationship between SUPI and AIoT ID.

[0188] Step S842, UDM derives key K based on key derivation function KDF. AF The input parameters of the Key Derivation Function (KDF) include the shared key K, AIoT ID, the length of the AIoT ID, random number R1, the length of random number R1, random number R2, the length of random number R2, and a fixed value assigned by a third party, such as FC=0x7E.

[0189] Optionally, step S840 may also include step S843.

[0190] In step S843, the UDM derives the MAC based on the security algorithms f1 / f2 / f3 / f4 / f5 specified in TS 35.206. The inputs to the security algorithms include parameters such as the key K, random number R1, and random number R2.

[0191] In step S850, the UDM sends a key reply message to the AF device. The key reply message may include K AF And a random number R2. Optionally, the key reply message may also include a MAC address.

[0192] In step S860, the AF device responds to the key message and performs the corresponding operation.

[0193] Step S860 may include step S861 or S862.

[0194] In step S861, if the key reply message contains a MAC, the AF device will not generate a MAC and will directly forward the message to the AIoT terminal.

[0195] Step S862: If the key reply message does not contain a MAC, the AF device generates a MAC using the f1 function / key derivation function.

[0196] If the f1 function is used, then the input parameters include K. AF Random numbers R1 and R2. If a key derivation function is used, then the input parameters include K. AF , random number R1, length of random number R1, random number R2 and length of random number R2, fixed value assigned by a third party, such as FC=0x7E.

[0197] Step S860 also includes steps S863 and S864.

[0198] In step S863, the AF device sends an authentication response message to the AIoT terminal, which contains the AIoT ID, random number R2, and MAC.

[0199] In step S864, after receiving the authentication reply message, the UE forwards the authentication reply message to the AIoT.

[0200] Step S870: AIoT terminal verifies MAC.

[0201] Step S870 may be preceded by step S865. In step S865, after the AIoT terminal receives the authentication response message, the AIoT terminal may transmit random number R1, random number R2, and MAC to its own security function module (such as UICC; if there is no security function module, then no transmission operation is required).

[0202] Step S870 may include step S881 or step S882.

[0203] Step S871: If the MAC is calculated and generated by the UDM, then the security function module derives a new verification code to verify the MAC. The AIoT terminal derives the key K. AF The process of generating new verification codes is the same as that on the network device side.

[0204] Step S872: If the MAC is calculated and generated by the AF device, then the security function module derives key K using the shared key K. AF This generates a new verification code to verify the MAC address. The AIoT terminal derives the key K. AF The process of generating new verification codes is the same as that on the network device side.

[0205] After step S870, if MAC verification fails, the AIoT terminal refuses to respond to the authentication reply message, and the process terminates. If MAC verification succeeds, the AIoT terminal can proceed to step S880.

[0206] Step S880 may include step S881 or S882.

[0207] Step S881: If the AIoT uses the ASCON-AEAD algorithm as the cryptographic algorithm, then the AIoT terminal uses the ASCON-AEAD algorithm to output ciphertext C and verification tag T, and sends them to AF. The input of the ASCON-AEAD algorithm includes K. AF And business data.

[0208] Step S882: If the AIoT terminal uses the confidentiality and integrity protection algorithm in TS33.501, then the AIoT terminal uses the key derivation function KDF to generate the confidentiality key K. CK-AIoT and integrity key K IK-AIoT The input parameters of this algorithm include: K AF This includes the encryption algorithm identifier / security algorithm identifier, the length of the encryption algorithm identifier / security algorithm identifier, a fixed value assigned by a third party (e.g., FC=0x8E), and the identifier of the key to be output. For example, if the confidentiality key K is to be output... CK-AIoT Then the identifier of the key to be output is 0x00; if the integrity key K is to be output... IK-AIoT Therefore, the identifier of the key to be output is 0x01. The output of this algorithm includes: the length of the identifier of the key to be output, random number R1, the length of random number R1, random number R2, and the length of random number R2, etc. AIoT uses key K. CK-AIoT After encrypting and protecting the business data, ciphertext C is generated, and then key K is used. IK-AIoT The ciphertext C is protected to generate the verification code MAC1. The AIoT terminal uses the KDF function to generate RES. The input parameters of the KDF function include the shared key K, random numbers R1 and R2, the lengths of R1 and R2, RES, the length of RES, and a fixed value assigned by a third party (e.g., FC=0x6B). The AIoT terminal uses the f2 function to generate RES, with input parameters including the root key K and the random number R2.

[0209] Step S890, the AIoT terminal will send C, MAC1 and RES Send to the UE. Alternatively, the AIoT terminal sends C and T to the UE.

[0210] In step S891, the UE will send C, MAC1, and RES Send to the AF device. Alternatively, the UE sends C and T to the AF device.

[0211] After step S890 or S891, the AF device may execute step S892 or S893.

[0212] Step S892: If AIoT uses the ASCON-AEAD algorithm, then AF is based on the ASCON-AEAD algorithm and uses K AF The AF device takes the encrypted text C and the verification tag T as input and outputs plaintext business data data and verification information T'. If the verification of T fails, the AIoT terminal identity is invalid, and the AF device rejects the message in step S890. If the AF device receives a normal output, the AIoT terminal identity is valid, and the AF device can further receive the message in step S890.

[0213] Step S893: If AIoT uses the confidentiality and integrity protection algorithm in TS33.501, then AF will... Forwarded to UDM.

[0214] After step S893, UDM can execute steps S894 and S895.

[0215] Step S894, UDM uses KDF functions to generate RES ', to verify RES The generation process and the RES on the AIoT side same.

[0216] Step S895, if RES If verification is successful, the UDM replies with an authentication success message to the AF device. If RES If verification fails, then the message sent by the AF device is rejected.

[0217] After step S895, the AF device can execute steps S896 and S897.

[0218] Step S896: After the AF device receives the authentication success message, the AF device uses the key derivation function KDF to generate the confidentiality key K. CK-AIoT and integrity key K IK-AIoT The derivation process is the same as on the AIoT side.

[0219] Step S897, the AF device uses key K IK-AIoT Verify MAC1. If MAC1 verification is successful, then use key K. CK-AIoT Decrypt the ciphertext C to obtain data. If MAC1 verification fails, then reject the authentication success message.

[0220] Example 3 Figure 9 This is a schematic flowchart of a communication method provided in Embodiment 3. Figure 9 The method shown can be executed by AIoT terminals, access network devices, AF devices, and UDMs.

[0221] The AF device in Example 3 is merely an example. The AF device in Example 3 can be replaced by one or more of the following: AMF, AUSF, HSE, UDR, SEAF, and core network dedicated NF.

[0222] The AIoT terminal and UDM share a shared key K and an AIoT ID.

[0223] Figure 7 The method shown may include steps S910 to S997.

[0224] Step S910: A secure channel is established between the AF device and the UDM.

[0225] Step S915: When there is a service requirement on the network device side, the access network device actively wakes up the AIoT terminal.

[0226] Step S920: When the AIoT terminal needs to actively send an authentication request, the AIoT terminal generates a random number R1.

[0227] In step S930, the AIoT terminal sends an authentication request message. This authentication request is the first authentication request. The authentication request includes the AIoT terminal's ID and R1.

[0228] Step S930 may include steps S931 or S932.

[0229] In step S931, the AIoT terminal sends an authentication request message directly to the UDM through the access network device. This authentication request message contains the AIoT ID and a random number R1.

[0230] In step S932, the AIoT device sends an authentication request message to the AF device through the access network device. This authentication request message contains the AIoT ID and a random number R1. Upon receiving this message, the AF sends a key request message to the UDM, which also contains the AIoT ID and the random number R1.

[0231] In step S940, after receiving the aforementioned key request message or authentication request message, UDM derives key K. AF .

[0232] Step S940 may include, for example, steps S941 to S942.

[0233] In step S941, UDM obtains the shared key K based on the AIoT ID and generates a random number R2.

[0234] Step S942, UDM derives key K based on key derivation function KDF. AFThe input parameters of the Key Derivation Function (KDF) include the shared key K, AIoT ID, the length of the AIoT ID, random number R1, the length of random number R1, random number R2, the length of random number R2, and a fixed value assigned by a third party, such as FC=0x7E.

[0235] Optionally, step S940 may also include step S943.

[0236] In step S943, the UDM derives the MAC based on the security algorithms f1 / f2 / f3 / f4 / f5 specified in TS 35.206. The inputs to the security algorithms include parameters such as the key K, random number R1, and random number R2.

[0237] In step S950, the UDM sends a key reply message to the AF device. The key reply message may include K AF And a random number R2. Optionally, the key reply message may also include a MAC address.

[0238] In step S960, the AF device responds to the key message and performs the corresponding operation.

[0239] Step S960 may include steps S961 or S962.

[0240] In step S961, if the key reply message contains a MAC, the AF device will not generate a MAC and will directly forward the message to the AIoT terminal.

[0241] Step S962: If the key reply message does not contain a MAC, the AF device generates a MAC using the f1 function / key derivation function.

[0242] If the f1 function is used, then the input parameters include K. AF Random numbers R1 and R2. If a key derivation function is used, then the input parameters include K. AF , random number R1, length of random number R1, random number R2 and length of random number R2, fixed value assigned by a third party, such as FC=0x7E.

[0243] Step S960 further includes step S963. In step S963, the AF device sends an authentication response message to the AIoT terminal, which contains a random number R2 and a MAC.

[0244] Step S970: AIoT terminal verifies MAC.

[0245] Step S970 may be preceded by step S965. In step S965, after the AIoT terminal receives the authentication response message, the AIoT terminal may transmit random number R1, random number R2, and MAC to its own security function module (such as UICC; if there is no security function module, then no transmission operation is required).

[0246] Step S970 may include step S971 or step S972.

[0247] Step S971: If the MAC is calculated and generated by the UDM, then the security function module derives a new verification code to verify the MAC. The AIoT terminal derives the key K. AF The process of generating new verification codes is the same as that on the network device side.

[0248] Step S972: If the MAC is calculated and generated by the AF device, then the security function module derives key K using the shared key K. AF This generates a new verification code to verify the MAC address. The AIoT terminal derives the key K. AF The process of generating new verification codes is the same as that on the network device side.

[0249] After step S970, if MAC verification fails, the AIoT terminal refuses to respond to the authentication reply message, and the process terminates. If MAC verification succeeds, the AIoT terminal can proceed to step S980.

[0250] Step S980 may include steps S981 or S982.

[0251] Step S981: If the AIoT uses the ASCON-AEAD algorithm as the cryptographic algorithm, then the AIoT terminal uses the ASCON-AEAD algorithm to output ciphertext C and verification tag T, and sends them to AF. The input of the ASCON-AEAD algorithm includes K. AF And business data.

[0252] Step S982: If the AIoT terminal uses the confidentiality and integrity protection algorithm in TS33.501, then the AIoT terminal uses the key derivation function KDF to generate the confidentiality key K. CK-AIoT and integrity key K IK-AIoT The input parameters of this algorithm include: K AF This includes the encryption algorithm identifier / security algorithm identifier, the length of the encryption algorithm identifier / security algorithm identifier, a fixed value assigned by a third party (e.g., FC=0x7E), and the identifier of the key to be output. For example, if the confidentiality key K is to be output... CK-AIoT Then the identifier of the key to be output is 0x00; if the integrity key K is to be output... IK-AIoTTherefore, the identifier of the key to be output is 0x01. The output of this algorithm includes: the length of the identifier of the key to be output, random number R1, the length of random number R1, random number R2, and the length of random number R2, etc. AIoT uses key K. CK-AIoT After encrypting and protecting the business data, ciphertext C is generated, and then key K is used. IK-AIoT The ciphertext C is protected to generate the verification code MAC1. The AIoT terminal uses the KDF function to generate RES. The input parameters of the KDF function include the shared key K, random numbers R1 and R2, the lengths of R1 and R2, RES, the length of RES, and a fixed value assigned by a third party (e.g., FC=0x6B). The AIoT terminal uses the f2 function to generate RES, with input parameters including the root key K and the random number R2.

[0253] Step S990, the AIoT terminal will send C, MAC1 and RES Send to the AF device. Alternatively, the AIoT terminal sends C and T to the AF device.

[0254] After step S990, AF may execute step S992 or step S993.

[0255] Step S992: If AIoT uses the ASCON-AEAD algorithm, then AF is based on the ASCON-AEAD algorithm and uses K AF The AF device takes the encrypted text C and the verification tag T as input and outputs plaintext business data data and verification information T'. If the verification of T fails, the AIoT terminal identity is invalid, and the AF device rejects the message in step S990. If the AF device receives a normal output, the AIoT terminal identity is valid, and the AF device can further receive the message in step S990.

[0256] Step S993: If AIoT uses the confidentiality and integrity protection algorithm in TS33.501, then AF will... Forwarded to UDM.

[0257] After step S993, UDM can execute steps S994 and S995.

[0258] Step S994, UDM uses the KDF function to generate RES ', to verify RES The generation process and the RES on the AIoT side same.

[0259] Step S995, if RES If verification is successful, the UDM replies with an authentication success message to the AF device. If RES If verification fails, then the message sent by the AF device is rejected.

[0260] After step S995, the AF device can execute steps S996 and S997.

[0261] Step S996: After the AF device receives the authentication success message, the AF device uses the key derivation function KDF to generate the confidentiality key K. CK-AIoT and integrity key K IK-AIoT The derivation process is the same as on the AIoT side.

[0262] Step S997, the AF device uses key K IK-AIoT Verify MAC1. If MAC1 verification is successful, then use key K. CK-AIoT Decrypt the ciphertext C to obtain data. If MAC1 verification fails, then reject the authentication success message.

[0263] Example 4 Figure 10 This is a schematic flowchart of a communication method provided in Embodiment 4. Figure 10 The method shown can be performed by an AIoT terminal or a local area network gateway (such as a gateway in a WLAN network). The AIoT terminal and the local area network gateway share the key K and the AIoT ID.

[0264] Figure 10 The method shown may include steps S1010 to S1095.

[0265] Step S1010: When the gateway has a business requirement, the gateway actively wakes up the AIoT terminal.

[0266] In step S1020, the AIoT terminal generates a random number R1.

[0267] In step S1030, the AIoT terminal sends an authentication request message to the gateway. The authentication request message contains the AIoT ID and a random number R1.

[0268] Step S1040: The local area network gateway generates authentication information (MAC). Step S1040 may include steps S1041 to S1043.

[0269] Step S1041: After receiving the authentication request message, the gateway obtains K based on the AIoT ID and generates a random number R2.

[0270] Step S1042, the gateway derives key K based on the key derivation function KDF. gateThe input parameters of the Key Derivation Function (KDF) include: key K, AIoT ID, length of AIoT ID, random number R1, length of random number R1, random number R2, length of random number R2, and a fixed value assigned by a third party, such as FC=0x7E.

[0271] Step S1043: The gateway generates a MAC address using the f1 function / key derivation function. If the f1 function is used, the input parameters include: K gate Random numbers R1 and R2. If a key derivation function is used, the input parameters include: K gate The random number R1, the length of the random number R1, the random number R2, the length of the random number R2, and a fixed value assigned by a third party (e.g., FC=0x7E).

[0272] In step S1050, the gateway sends an authentication response message to the AIoT terminal. The authentication response message contains a random number R2 and a MAC address.

[0273] Step S1070, the AIoT terminal uses the K-derived key K gate And verify the MAC address.

[0274] After the AIoT terminal receives the authentication response message, it derives key K from shared key K. gate This generates a new verification code to verify the MAC address. The terminal generates a derived key K. gate The process of generating a new verification code is the same as that of the gateway.

[0275] Step S1081: If MAC verification is successful, the AIoT terminal outputs ciphertext C and verification tag T using the ASCON-AEAD algorithm. The input of this algorithm includes K. gate And business data.

[0276] In step S1082, if MAC verification fails, the AIoT terminal refuses to respond to the authentication reply message, and the process terminates.

[0277] After step S1081, step S1090 is executed. In step S1090, the AIoT terminal sends the ciphertext C and / or the verification tag T to the gateway.

[0278] Step S1095: After the gateway receives the ciphertext C, it uses the ASCON-AEAD algorithm and K... gate The AIoT terminal takes encrypted data C and verification tag T as input and outputs plaintext business data and verification information T'. Verification tag T is then verified using verification information T'. If verification of T fails, the AIoT terminal's identity is invalid, and the message is rejected. If the gateway receives a normal output, the AIoT terminal's identity is valid, and the message is accepted.

[0279] Example 5 Figure 11 This is a schematic flowchart of a communication method provided in Embodiment 4. Figure 11 The method shown can be performed by an AIoT terminal or a local area network gateway (such as a gateway in a WLAN network). The AIoT terminal and the local area network gateway share the key K and the AIoT ID.

[0280] Figure 10 The method shown may include steps S1120 to S1195.

[0281] Step S1120: The AIoT terminal generates a random number R1.

[0282] In step S1130, the AIoT terminal actively sends an authentication request message to the gateway. The authentication request message contains the AIoTID and a random number R1.

[0283] Step S1140: The local area network gateway generates authentication information (MAC). Step S1140 may include steps S1141 to S1143.

[0284] Step S1141: After receiving the authentication request message, the gateway obtains K based on the AIoT ID and generates a random number R2.

[0285] Step S1142, the gateway derives key K based on the key derivation function KDF. gate The input parameters of the Key Derivation Function (KDF) include: key K, AIoT ID, length of AIoT ID, random number R1, length of random number R1, random number R2, length of random number R2, and a fixed value assigned by a third party, such as FC=0x7E.

[0286] Step S1143: The gateway generates a MAC address using the f1 function / key derivation function. If the f1 function is used, the input parameters include: K gate Random numbers R1 and R2. If a key derivation function is used, the input parameters include: K gate The random number R1, the length of the random number R1, the random number R2, the length of the random number R2, and a fixed value assigned by a third party (e.g., FC=0x7E).

[0287] In step S1150, the gateway sends an authentication response message to the AIoT terminal. The authentication response message contains a random number R2 and a MAC address.

[0288] Step S1170, the AIoT terminal uses the K-derived key K gate And verify the MAC address.

[0289] After the AIoT terminal receives the authentication response message, it derives key K from shared key K. gate This generates a new verification code to verify the MAC address. The terminal generates a derived key K. gate The process of generating a new verification code is the same as that of the gateway.

[0290] Step S1181: If MAC verification is successful, the AIoT terminal outputs ciphertext C and verification tag T using the ASCON-AEAD algorithm. The input of this algorithm includes K. gate And business data.

[0291] In step S1182, if MAC verification fails, the AIoT terminal refuses to respond to the authentication reply message, and the process terminates.

[0292] After step S1181, step S1190 is executed. In step S1190, the AIoT terminal sends the ciphertext C and / or the verification tag T to the gateway.

[0293] Step S1195: After the gateway receives the ciphertext C, it uses the ASCON-AEAD algorithm and K... gate The AIoT terminal takes encrypted data C and verification tag T as input and outputs plaintext business data and verification information T'. Verification tag T is then verified using verification information T'. If verification of T fails, the AIoT terminal's identity is invalid, and the message is rejected. If the gateway receives a normal output, the AIoT terminal's identity is valid, and the message is accepted.

[0294] The method embodiments of this application have been described in detail above. The apparatus embodiments of this application are described in detail below. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments. Therefore, any parts not described in detail can be referred to the foregoing method embodiments.

[0295] Figure 12 This is a schematic structural diagram of a communication device 1200 provided in an embodiment of this application. The communication device 1200 is a first device. The communication device 1200 includes a key generation unit 1210, a first receiving unit 1220, a generation unit 1230, and a first sending unit 1240.

[0296] The key generation unit 1210 is used to generate a first key based on the shared key.

[0297] The first receiving unit 1220 is used to receive the second random number from the second device; The generation unit 1230 is used to generate first authentication information of the first device based on the first key.

[0298] The first sending unit 1240 is used to send a first message to the second device, the first message including first authentication information.

[0299] The first authentication information is generated based on one or more of the following: information related to the first device and the business, the identifier of the device that forwarded the first message, the first random number of the first device, and the second random number.

[0300] In some embodiments, the generation unit 1230 is further configured to: generate ciphertext corresponding to the business data based on the first key; wherein the first message further includes the ciphertext.

[0301] In some embodiments, both the ciphertext and the first authentication information are obtained based on a first algorithm.

[0302] In some embodiments, the communication device 1200 is further configured to: generate a second key and a third key based on a first key, wherein the second key and the third key are different; the generation unit 1220 is further configured to: generate ciphertext based on the second key; and generate first authentication information based on the third key.

[0303] In some embodiments, the first key is further used to generate second authentication information for the second device.

[0304] In some embodiments, the communication device 1200 is further configured to: send a first authentication request; wherein the first authentication request is used to request two-way identity authentication between the first device and the second device.

[0305] In some embodiments, the communication device 1200 is further configured to: receive a first authentication response sent by the second device, the first authentication response being used to respond to the first authentication request, the first authentication response including the second random number; verify whether the second random number is the same as a previously received random number; and refuse to respond to the first authentication response if the second random number is the same as the previously received random number.

[0306] In some embodiments, the first authentication response further includes second authentication information of the second device, and the communication device is further configured to: verify the second authentication information; and refuse to respond to the first authentication response if the verification of the second authentication information fails.

[0307] In some embodiments, the first authentication request includes a first identifier of the first device, which is associated with the shared key.

[0308] In some embodiments, the first identifier includes one or more of the following identifiers of the first device: AIoT identifier, SUCI, SUPI.

[0309] In some embodiments, the first authentication request is sent via a third device, and if there is no mapping relationship between the first identifier and the second identifier of the third device, the first authentication request is rejected.

[0310] In some embodiments, sending the first authentication request includes: in response to the first device receiving the first trigger information, sending the first authentication request.

[0311] In some embodiments, the first device is an AIoT terminal, and the second device includes one or more network devices.

[0312] Figure 13 This is a schematic structural diagram of another communication device 1300 provided in an embodiment of this application. The communication device 1300 is a second device. The communication device 1300 may include a second transmitting unit 1310 and a second receiving unit 1320.

[0313] The second sending unit 1310 is used to send a second random number.

[0314] The first sending unit 1320 is used to receive a first message sent by the first device; wherein the first message includes first authentication information of the first device, the first authentication information is generated based on a first key, and the first authentication information is generated based on one or more of the following information: information related to the first device and the service, the identifier of the device forwarding the first message, a first random number and a second random number of the first device, and the first key is generated based on a shared key.

[0315] In some embodiments, the first message may also include ciphertext corresponding to the business data, which is generated based on the first key.

[0316] In some embodiments, both the ciphertext and the first authentication information are obtained based on a first algorithm.

[0317] In some embodiments, the second key and the third key are both generated based on the first key, and the second key and the third key are different. The ciphertext generated based on the first key includes: the ciphertext generated based on the second key; the first authentication information generated based on the first key includes: the first authentication information generated based on the third key.

[0318] In some embodiments, the first key is further used to generate second authentication information for the second device.

[0319] In some embodiments, the communication device 1300 is further configured to: receive a first authentication request sent by the first device; wherein the first authentication request is used to request two-way identity authentication between the first device and the second device.

[0320] In some embodiments, the first authentication request includes the first random number, and the communication device 1300 is further configured to: verify whether the first random number is the same as a previously received random number; and refuse to respond to the first authentication request if the first random number is the same as the previously received random number.

[0321] In some embodiments, the communication device 1300 is further configured to: send a first authentication response, the first authentication response being used to respond to the first authentication request, the first authentication response including the second random number.

[0322] In some embodiments, the first authentication request includes a first identifier of the first device, which is associated with the shared key.

[0323] In some embodiments, the first identifier includes one or more of the following identifiers of the first device: AIoT identifier, SUCI, SUPI.

[0324] In some embodiments, the first authentication request is sent via a third device, and if there is no mapping relationship between the first identifier and the second identifier of the third device, the first authentication request is rejected.

[0325] In some embodiments, receiving the first authentication request sent by the first device includes: receiving the first authentication request sent by the first device in response to the first device receiving first trigger information.

[0326] In some embodiments, the communication device 1300 is further configured to: generate the first key based on the first random number, the second random number, and the shared key.

[0327] In some embodiments, the communication device 1300 is further configured to: generate second authentication information for the second device.

[0328] In some embodiments, the communication device 1300 is further configured to: send a second request, the second request being used to request the derivation of the first key.

[0329] In some embodiments, the second request is further configured to request the generation of second authentication information for the second device.

[0330] In some embodiments, the communication device 1300 is further configured to: receive response information of the second request; and generate the second authentication information if the response information of the second request does not contain the second authentication information of the second device.

[0331] In some embodiments, the first device is an AIoT terminal, and the second device includes one or more network devices.

[0332] Figure 14 This is a schematic structural diagram of another communication device 1400 provided in an embodiment of this application. The communication device 1400 is a third device. The communication device 1400 includes a third receiving unit 1410 and a third transmitting unit 1420.

[0333] The third receiving unit 1410 is used to receive a first message sent by the first device; the third sending unit 1420 is used to send the first message to the second device; wherein, the first message includes first authentication information of the first device, the first authentication information is generated based on a first key, and the first authentication information is generated based on one or more of the following information: information related to the first device and the service, the identifier of the device forwarding the first message, a first random number of the first device and a second random number of the second device, and the first key is generated based on a shared key.

[0334] In some embodiments, the first message may further include ciphertext corresponding to business data, which is generated based on the first key.

[0335] In some embodiments, both the ciphertext and the first authentication information are obtained based on a first algorithm.

[0336] In some embodiments, the second key and the third key are both generated based on the first key, and the second key and the third key are different, wherein the ciphertext is generated based on the first key; the ciphertext is generated based on the second key; wherein the first authentication information generated based on the first key includes: the first authentication information is generated based on the third key.

[0337] In some embodiments, the first key is further used to generate second authentication information for the second device.

[0338] In some embodiments, the communication device 1400 is further configured to: receive a first authentication request sent by the first device; send the first authentication request to the second device; wherein the first authentication request is used to request two-way identity authentication between the first device and the second device.

[0339] In some embodiments, the third sending unit includes: sending the first authentication request to the second device when a first condition is met; wherein the first condition includes: there is a mapping relationship between the first identifier and the second identifier of the third device.

[0340] In some embodiments, receiving the first authentication request sent by the first device includes: receiving the first authentication request sent by the first device in response to the first device receiving first trigger information.

[0341] In some embodiments, the first device is an AIoT terminal, and the second device includes one or more network devices.

[0342] In optional embodiments, the first receiving unit 1220, the first transmitting unit 1240, the second transmitting unit 1310, the second receiving unit 1320, the third receiving unit 1410, or the third transmitting unit 1420 can be a transceiver 1530, and the key generation unit 1210 or the generation unit 1230 can be a processor 1510. The communication device 1200, communication device 1300, or communication device 1400 may further include a memory 1520, specifically as follows... Figure 15 As shown.

[0343] Figure 15 This is a schematic structural diagram of a communication apparatus according to an embodiment of this application. Figure 15 The dashed lines indicate that the unit or module is optional. The device 1500 can be used to implement the methods described in the above method embodiments. The device 1500 can be a chip, a terminal, or a network device.

[0344] Apparatus 1500 may include one or more processors 1510. The processor 1510 may support apparatus 1500 in implementing the methods described in the preceding method embodiments. The processor 1510 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a Central Processing Unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0345] The apparatus 1500 may further include one or more memories 1520. The memories 1520 store a program that can be executed by the processor 1510, causing the processor 1510 to perform the methods described in the preceding method embodiments. The memories 1520 may be independent of the processor 1510 or integrated into the processor 1510.

[0346] The device 1500 may also include a transceiver 1530. The processor 1510 can communicate with other devices or chips via the transceiver 1530. For example, the processor 1510 can send and receive data with other devices or chips via the transceiver 1530.

[0347] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to a terminal or network device provided in this application, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0348] This application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to a terminal or network device provided in this application embodiment, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0349] This application also provides a computer program. This computer program can be applied to the terminal or network device provided in this application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0350] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0351] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0352] In the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0353] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship such as instruction and being instructed, configuration and being configured.

[0354] In this application embodiment, "predefined" or "preconfigured" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminals and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0355] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0356] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0357] In the embodiments of this application, "comprising" can refer to direct inclusion or indirect inclusion. Optionally, "comprising" mentioned in the embodiments of this application can be replaced with "indicating" or "used to determine". For example, "A includes B" can be replaced with "A indicates B" or "A is used to determine B".

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

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

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

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

[0362] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially 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, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Video Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

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

Claims

1. A method for communication, characterized in that, include: The first device generates the first key based on the shared key; The first device receives the second random number from the second device; The first device generates first authentication information based on the first key; The first device sends a first message to the second device, the first message including the first authentication information; The first authentication information is generated based on one or more of the following: device information, service-related information, the identifier of the device that forwarded the first message, the first random number of the first device, and the second random number.

2. The method according to claim 1, characterized in that, Also includes: The first device generates ciphertext corresponding to the business data based on the first key; The first message also includes the encrypted text.

3. The method according to claim 2, characterized in that, Both the ciphertext and the first authentication information are obtained based on the first algorithm.

4. The method according to claim 2, characterized in that, Also includes: The first device generates a second key and a third key based on the first key, wherein the second key and the third key are different; The first device generates ciphertext corresponding to the business data based on the first key, including: The first device generates the ciphertext based on the second key; The first device generates first authentication information based on the first key, including: The first device generates the first authentication information based on the third key.

5. The method according to any one of claims 1-4, characterized in that, The first key is also used to generate second authentication information for the second device.

6. The method according to any one of claims 1-4, characterized in that, The first device is an AIoT terminal, and the second device includes one or more network devices.

7. A method for communication, characterized in that, include: The second device sends a second random number; The second device receives the first message sent by the first device; The first message includes first authentication information of the first device, which is generated based on a first key and is generated according to one or more of the following: device information, service-related information, the identifier of the device forwarding the first message, a first random number of the first device, and a second random number. The first key is generated based on a shared key.

8. The method according to claim 7, characterized in that, The first message also includes ciphertext corresponding to the business data, which is generated based on the first key.

9. The method according to claim 8, characterized in that, Both the ciphertext and the first authentication information are obtained based on the first algorithm.

10. The method according to claim 8, characterized in that, Both the second key and the third key are generated based on the first key, but the second key and the third key are different. The ciphertext, generated based on the first key, includes: The ciphertext was generated based on the second key; The first authentication information, generated based on the first key, includes: The first authentication information is generated based on the third key.

11. The method according to any one of claims 7-10, characterized in that, The first key is also used to generate second authentication information for the second device.

12. The method according to any one of claims 7-10, characterized in that, Also includes: The second device generates the first key based on the first random number, the second random number, and the shared key.

13. The method according to claim 12, characterized in that, Also includes: The second device generates the second authentication information for the second device.

14. The method according to any one of claims 7-10, characterized in that, The first device is an AIoT terminal, and the second device includes one or more network devices.

15. A communication device, wherein the communication device is a first device, characterized in that, The device includes a memory and a processor, the memory being used to store a program and the processor being used to invoke the program in the memory to cause the first device to perform the method as described in any one of claims 1-6.

16. A communication device, wherein the communication device is a second device, characterized in that, The device includes a memory and a processor, the memory being used to store a program and the processor being used to invoke the program in the memory to cause the second device to perform the method as described in any one of claims 7-14.

Images