Communication methods and communication devices

Abstract

Provided are communication methods and communication devices. One method comprises: on the basis of a shared key, a first device generates a first key; the first device receives a second random number of a second device; on the basis of the first key, the first device generates first authentication information of the first device; and the first device sends a first message to the second device, the first message comprising the first authentication information, and the first authentication information being generated according to one or more of the following information: device information, service-related information, an identifier of a device forwarding the first message, and a first random number and a second random number of the first device. Compared with the prior art, the first authentication information of the present application can carry more information. Therefore, the present application can provide authentication attributes, such that first authentication information-based security authentication processes can verify more information. In addition, the first authentication information-based security authentication processes can also negotiate about keys.

Description

Communication method and communication device Technical Field

[0001] The present application relates to the field of communication technology, and more particularly, to a method for communication and a communication device. Background Art

[0002] To meet communication security requirements, communication devices must undergo security authentication before communication can begin. Security authentication can be one-way or two-way. For example, two-way authentication involves both communicating parties performing mutual authentication. Once both parties have successfully authenticated each other, encrypted data can be transmitted.

[0003] In communication systems, related technologies have proposed a variety of security authentication protocols suitable for different terminals. However, the security authentication schemes in related technologies have the problem of a single authentication attribute.

[0004] Summary of the Invention

[0005] The present application provides a method and a communication device for communication. The following introduces various aspects involved in the present application.

[0006] In a first aspect, a method for communication is provided, the method comprising: a first device generates a first key based on a shared key; the first device receives a second random number from a 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, the first message including the first authentication information; wherein the first authentication information is generated based on one or more of the following information: business-related information of the first device, an identifier of a device forwarding the first message, the first random number of the first device, and the second random number.

[0007] 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 is generated based on a first key, and the first authentication information is generated based on one or more of the following information: business-related information of the first device, an identifier of a device forwarding the first message, the first random number of the first device, and the second random number, and the first key is generated based on a shared key.

[0008] According to a third aspect, a method for communication is provided, comprising: a third device receiving a first message sent by a first device; and the third device sending a first message to a 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: business-related information of the first device, an identifier of a 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.

[0009] In a fourth aspect, a communication device is provided, which is a first device and includes: a key generation unit for generating a first key based on a shared key; a first receiving unit for receiving a second random number of a second device; a generation unit for generating first authentication information of the first device based on the first key; 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: business-related information of the first device, an identifier of the device forwarding the first message, the first random number of the first device, and the second random number.

[0010] In a fifth aspect, a communication device is provided, which is a second device and includes: a second sending unit for sending a second random number; a second receiving unit for 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 is generated based on a first key, and the first authentication information is generated based on one or more of the following information: business-related information of the first device, an identifier of the device forwarding the first message, the first random number of the first device, and the second random number, and the first key is generated based on a shared key.

[0011] In a sixth aspect, a communication device is provided, which is a third device and includes: a third receiving unit for receiving a first message sent by a first device; a third sending unit for sending a first message to a 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: business-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 is generated based on a shared key.

[0012] In a seventh aspect, a communication device is provided, comprising a processor and a memory, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the communication device executes some or all of the steps in the above method.

[0013] In an eighth aspect, an embodiment of the present application provides a communication system, which includes the above-mentioned communication device. In another possible design, the system may also include other devices that interact with the communication device in the solution provided in the embodiment of the present application.

[0014] In a ninth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program enables a communication device to execute part or all of the steps in the methods of the above aspects.

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

[0016] In the eleventh aspect, an embodiment of the present application provides a chip, which includes a memory and a processor. The processor can 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.

[0017] Compared to related technologies, the first authentication information of this application can be generated based on one or more of device information, service-related information, the identifier of the device forwarding the first information, and security parameters. That is, the first authentication information can carry more information. Therefore, this application can add authentication attributes, so that the security authentication process based on the first authentication information can verify more information. In addition, because 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] FIG1 is a schematic diagram of a wireless communication system used in an embodiment of the present application.

[0019] FIG2 is a schematic diagram of the key derivation architecture of 5G AKA and EAP-AKA′.

[0020] FIG3A is a schematic diagram of the encryption portion of the ASCON-AEAD algorithm.

[0021] FIG3B is a schematic diagram of the decryption portion of the ASCON-AEAD algorithm.

[0022] FIG4 is a schematic flowchart of a method for communication provided in an embodiment of the present application.

[0023] FIG5 is a schematic diagram of a key derivation architecture provided in an embodiment of the present application.

[0024] FIG6 is a schematic diagram of another key derivation architecture provided in an embodiment of the present application.

[0025] FIG7 is a schematic flowchart of a method for communication provided in Embodiment 1 of the present application.

[0026] FIG8 is a schematic flowchart of a method for communication provided in Embodiment 2 of the present application.

[0027] FIG9 is a schematic flowchart of a method for communication provided in Example 3 of the present application.

[0028] Figure 10 is a schematic flowchart of a method for communication provided in Example 4 of the present application.

[0029] FIG11 is a schematic flowchart of a method for communication provided in Embodiment 5 of the present application.

[0030] FIG12 is a schematic structural diagram of a communication device provided in an embodiment of the present application.

[0031] FIG13 is a schematic structural diagram of another communication device provided in an embodiment of the present application.

[0032] FIG14 is a schematic structural diagram of another communication device provided in an embodiment of the present application.

[0033] FIG15 is a schematic structural diagram of a device for communication provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] The technical solution in this application will be described below with reference to the accompanying drawings.

[0035] Communication System

[0036] FIG1 is a wireless communication system 100 used in an embodiment of the present application. The wireless communication system 100 may include communication devices, including access network devices 110, terminals 120, and core network devices 130.

[0037] FIG1 exemplarily shows a network device and two terminals. Optionally, the wireless communication system 100 may include multiple network devices and each network device may include another number of terminals within its coverage area, which is not limited in the embodiments of the present application.

[0038] It should be understood that the technical solutions of the embodiments of the present application can be applied to various communication systems, such as: fifth generation (5G) system or new radio (NR), long term evolution (LTE) system, LTE frequency division duplex system, LTE time division duplex system, etc. The technical solutions provided in this application can also be applied to future communication systems, such as the sixth generation mobile communication system, satellite communication system, etc.

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

[0040] The network device in the embodiment of the present application may be a device for communicating with a terminal. The network device may include an access network device or a base station, which communicates with a terminal 120 located in a specific coverage area. The access network device in the embodiment of the present application may refer to a node B (NodeB), an evolved base station (eNB), a next-generation base station (gNB), a relay station, a home base station, a network controller, an access point (AP), etc. that accesses the terminal to a wireless network. The base station may also be a device that performs base station functions in wireless communications, a network-side device in a 6G network, a device that performs base station functions in future communication systems, etc. The base station may support networks with the same or different access technologies. The embodiments of the present application do not limit the specific technology and specific device form adopted by the access network device.

[0041] The network device may include a core network device 130. The core network in the embodiment of the present application may include entities for processing and forwarding 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). Among them, AUSF can be used to receive AMF's request for terminal identity authentication, request a key from UDM, and then forward the issued key to AMF for authentication processing. UDM may include functions such as generation and storage of user contract data, management of authentication data, and support interaction with external third-party servers.

[0042] Network devices and terminals can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; they can also be deployed in the air on aircraft, balloons, and satellites. The embodiments of this application do not limit the scenarios in which network devices and terminals are located.

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

[0044] Zero-power communication technology

[0045] 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 generally require low cost, small size (such as ultra-thin), maintenance-free, and long life. To address this, zero-power communication technology has been proposed. Zero-power communication systems can be used in scenarios such as wireless industrial sensing networks, smart agriculture, smart warehousing and logistics, and smart homes.

[0046] Zero-power technology primarily combines RF energy harvesting, backscattering, and low-power computing to achieve the advantage of eliminating the need for power supply devices. The core of RF energy harvesting is to convert RF energy into DC. This energy can be stored in batteries or capacitors, or it can be directly used to drive logic circuits, digital chips, or sensors, completing functions and applications such as modulation and transmission of backscattered signals and collection and processing of sensor information.

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

[0048] It's important to note that during standardization discussions, the Zero Power Internet of Things (ZPIoT) is also referred to as the Ambient Power-Enabled Internet of Things (AIoT), or Ambient IoT for short. AIoT devices can be those that use various ambient energies, such as radio frequency energy, light energy, solar energy, thermal energy, and mechanical energy. AIoT devices can have no energy storage capacity or very limited energy storage capacity (such as using capacitors with a capacity of tens of microfarads).

[0049] Security Certification

[0050] To meet communication security requirements, communication devices can undergo security authentication before any communication occurs. This authentication can be bidirectional. That is, both communicating parties can authenticate each other. Once both parties have successfully authenticated each other, encrypted data can be transmitted.

[0051] In the communication system, the relevant technology has proposed a variety of security authentication protocols suitable for different terminals. Taking the provisions of the 3GPP standard as an example, the security authentication protocol can be applicable to one or more of ordinary terminals, Cellular Internet of Things (CIoT) devices, and Machine-Type Communication (MTC) devices. Security authentication schemes applicable to ordinary terminals may include: 5GAKA, EAP-AKA' or EPSAKA, etc. Security authentication schemes applicable to CIoT devices may include CP CIoT security schemes applicable to small data transmission. The BEST authentication scheme is specifically applicable to MTC devices. The BEST authentication scheme can be implemented based on different authentication protocols. For example, the BSET authentication scheme can be implemented based on the following authentication protocols: 5GAKA, EAPAKA', EPSAKA, GBA or AKMA.

[0052] Different security authentication schemes may correspond to different key derivation architectures. For example, FIG2 is a schematic diagram of the key derivation architectures of 5G AKA and EAP-AKA′.

[0053] As can be seen from the key derivation structure 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 common 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.

[0054] Security authentication overhead

[0055] In 3GPP standard authentication schemes, when using a secure authentication scheme for mutual authentication, the security computational overhead required by both the terminal and the network device during the authentication process is the same: one f1 and f2 operation and one HMAC operation. Different authentication schemes have different key derivation architectures, and the corresponding computational overhead also varies. For example, 5GAKA requires one f3, f4, and f5 operation and 10 HMAC-SHA256 operations. EAP-AKA requires one f3, f4, and f5 operation and 11 HMAC-SHA256 operations.

[0056] Authenticated encryption algorithm

[0057] To support high security and performance in environments with limited computing resources, lightweight Authenticated Encryption with Associated Data (AEAD) algorithms have attracted 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, leaving the decryptor unaware of whether the decrypted information has been tampered with by an intermediary. Therefore, an algorithm that combines both encryption and authentication is required.

[0058] The primary technology used in AEAD algorithms is the Advanced Encryption Standard (AES) algorithm with Galois or Counter mode. While this algorithm can operate efficiently in most cases, there are some resource-constrained scenarios where its use is restricted. Consequently, 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 in ASCON were selected by NIST as a lightweight cryptographic algorithm standard.

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

[0060] The encryption and decryption processes and structures of the ASCON-AEAD algorithm are essentially the same. As shown in Figure 3A , the encryption phase includes four phases: initialization, associated data, plaintext / ciphertext, and finalization. As shown in Figure 3B , the decryption phase includes four phases: initialization, associated data, ciphertext, and finalization. The parameters involved in the ASCON-AEAD algorithm primarily include the key K, plaintext P, associated information A, ciphertext C, a preconfigured initialization vector IV, and a random number N. A can include one or more of the following: the plaintext to be protected, the ciphertext, the device's identity, and additional information such as an IP address. ASCON-AEAD generates an authentication tag (hereinafter referred to as T). Specifically, the output of ASCON-AEAD may include the authentication tag T. The authentication tag T can be used to authenticate the integrity of the associated information A.

[0061] The difference between the encryption and decryption phases is that the plaintext and ciphertext inputs and outputs are reversed. The inputs for ASCON-AEAD encryption can include K, A, and P, and the outputs can include C and T. The inputs for decryption can include K, A, and C, and the outputs can include P and T'. By comparing T and T', A can be authenticated.

[0062] As mentioned above, the related art proposes a variety of security authentication protocols suitable for different terminals. However, the inventors of this application have discovered that the security authentication schemes of the related art suffer from a single authentication attribute. Therefore, they have proposed the security authentication scheme of this application. The following uses Figure 4 as an example to illustrate the technical solution proposed in this application.

[0063] FIG4 is a schematic flowchart of a method for communication provided in an embodiment of the present application.

[0064] The method shown in Figure 4 may be executed 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.

[0065] 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 a shared key. Alternatively, the second device may include one or more of the following: a network function (NF), an application function (AF) device. The NF may include one or more of the following: an AMF, an AUSF, a session management function (SMF), a network exposure function (NEF), a key management server (KMS), an authentication and key management for applications (AKMA) anchor function (AAnF), a bootstrapping server function (BSF), a home public land mobile network (HPLMN) security node (HSE), a unified data repository (UDR), a security anchor function (SEAF), and a core network specifically configured for authentication. Alternatively, the second device may include a wireless local area network (WLAN) gateway.

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

[0067] The method shown in FIG. 4 may include step S430 .

[0068] Step S430: The first device generates first authentication information of the first device based on the first key.

[0069] The authentication information described in this application can be used to implement one or more of the following: identity authentication of the corresponding communication device, secure transmission authentication, transmission content security and / or integrity authentication, key negotiation, etc. Only after the verification is passed 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 information: identity authentication of the first device, authentication of the secure transmission of the first device, and transmission content security and / or integrity authentication of the first device. In addition, 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.

[0070] The first key may be a shared key between the first device and the second device. The shared key may be a root key in a key derivation architecture. For example, if the first device is an AIoT terminal and the second device is a network device, the shared key may be a key shared between the AIoT terminal and the network device. In some embodiments, the shared key may be a symmetric key, meaning that the shared keys stored by the first device and the second device may be the same.

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

[0072] As an implementation method, the first key can be derived from the 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 may be, for example, FC=0x7E. Based on step S410, the key derivation architecture proposed in this application is shown in FIG5 . In FIG5 , the first key is derived from the shared key through K AF In some embodiments, the first key may also be represented by K NF or K gate As shown in Figure 5, the shared key K can be used to derive the first key K AF As can be seen from Figure 5, the key derivation architecture proposed in this application is more lightweight. Therefore, during security authentication, the communication device can reduce the computational overhead of deriving the key of the communication device, 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, so that the AIoT terminal can consume less energy to complete the communication process.

[0073] It should be noted that the first random number may be generated by the first device. The second random number may be generated by the second device. The method shown in FIG4 may include step S420. In step S420, the second device sends the second random number to the first device.

[0074] 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 information: device information, service-related information, the identifier of the device forwarding the first information, security parameters, etc. Each of these is explained below.

[0075] Device information can be used to indicate the identity of the device participating in security authentication. For example, the device information may include one or more of the following: the identity information of the first device, the identity information of the 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, Public Land Mobile Network (PLMN) ID.

[0076] The service-related information may be used to indicate information related to service data transmission. For example, the service-related information may include one or more of the following information: service type identity, plain text corresponding to the service data, and cipher text corresponding to the service data.

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

[0078] The security parameters may be used to implement secure transmission. For example, the security parameters may include one or more of the following: a first random number of the first device, a second random number of the second device, parameters related to secure calculation, and the like.

[0079] 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 described above for generating 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, service-related information of the first device, an 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.

[0080] Compared to related technologies, the first authentication information of this application can be generated based on one or more of device information, service-related information, the identifier of the device forwarding the first information, and security parameters. This means that the first authentication information can carry more information. Therefore, this application can add authentication attributes, allowing the security authentication process based on the first authentication information to verify more information.

[0081] The method shown in FIG. 4 may include step S440 .

[0082] In step S440, the first device may send a first message to the second device.

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

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

[0085] By forwarding the first message via 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 consume less energy to communicate with the regular terminal, and the regular terminal can provide more energy to communicate with the second device, thereby achieving the goal of the AIoT terminal consuming less energy to communicate with the third device.

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

[0087] In some embodiments, the first device may not send the first message through the third device. For example, when the third device is ordinary, the first device may directly send the first message to the third device through the base station.

[0088] In addition to the first authentication information, the first message may also include ciphertext corresponding to the service data. The ciphertext may correspond to the service data and / or signaling. The ciphertext may be obtained by encrypting the plaintext service data and / or signaling.

[0089] In related technologies, authentication information and ciphertext are transmitted in two messages respectively. This application sets the authentication information and ciphertext to be transmitted in one message, which can reduce the transmission of at least one message, thereby reducing the power consumption of the communication device. In other words, based on this application, the authentication and key confirmation of the communication device can be achieved through one signaling, thereby ensuring the confidentiality and integrity of the received business data. In addition, for zero-power terminal communication, this application meets the ultra-low energy consumption requirements of the zero-power terminal by optimizing the terminal's security computing overhead, transmission times and other security costs. At the same time, this application can reduce the energy consumption required for zero-power terminal communication processing, further ensure the normal operation of the zero-power terminal under conditions of limited energy supply, and ultimately improve the user experience of the terminal user.

[0090] In some embodiments, the ciphertext may be generated based on the first key. That is, the first key may be used to implement: confidentiality protection of signaling and / or service data, integrity protection of signaling and / or service data, and communication authentication.

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

[0092] In related technologies, communication devices need to perform authentication and encryption operations separately, meaning they must perform at least two operations. In this application, the first algorithm achieves both authentication and encryption with a single operation. Therefore, this application can reduce computational overhead and meet the low power requirements of zero-power terminals. Furthermore, as mentioned above, the first algorithm can include the ASCON-AEAD algorithm. The ASCON-AEAD algorithm is a lightweight algorithm that offers the advantage of low cost, alleviating the pressure on limited software and hardware resources in communication devices.

[0093] 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 key different from the second key. In these embodiments, the second key can be used to implement data encryption, that is, to implement confidentiality protection of signaling and / or business data. Therefore, the second key can also be called a confidentiality key. The third key can implement ciphertext integrity verification and can also implement authentication. Therefore, the third key can also be called an integrity protection verification code. Alternatively, the third key can also have the function of RES. In the case where the first authentication information is obtained based on the third key, the first authentication information may include a message authentication code (MAC).

[0094] Based on the second key and / or the third key, the key derivation architecture can be as shown in Figure 6. The shared key K can be used to derive the first key K AF The first key K AF The second key K can be derived CK and the third key K IK .

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

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

[0097] At least two of the key derivation functions described above may be the same. For example, the second key derivation function may be the same as the third key derivation function. As an implementation, both the second key derivation function and the third key derivation function may be KDF functions. When the second key derivation function and the third key derivation function are the same, the input of the second key derivation function (which may also be referred to as the third key derivation function) may further include: a 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 may be 0x00; if the third key needs to be output, the key identifier may be 0x01. Alternatively, if the second key needs to be output, the key identifier may be 0x01; if the third key needs to be output, the key identifier may be 0x00.

[0098] When the third key includes RES*, a fourth key derivation function can be used to generate RES*. 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, or a fixed value assigned by a third party. The fixed value may be, for example, FC = 0x6B. RES may be generated using the f2 function. The f2 function's inputs may include one or more of the following: a shared key and a random number R2. The f2 function may be derived based on the specifications in TS 35.206.

[0099] Both parties to the authentication can use the key derivation method described above to derive the corresponding key. That is, both parties to the authentication can use the above method to derive one or more of the first key, the second key, and the third key. Taking the second device including the 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 keys. Taking the second device including the AF device as an example, the second device can send a second request. Among them, the second request can be used to derive the first key. The communication device that receives the second request can be the UDM. When the UDM receives the second request, the second device can derive the first key. The method of deriving the first key can be referred to above and will not be repeated here.

[0100] This application does not limit the length of each of the above 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.

[0101] As an implementation manner, based on the second key and the third key, the first device or the second device may use a confidentiality and integrity protection algorithm in related technologies, such as the confidentiality and integrity protection algorithm in TS33.501.

[0102] 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 the first message. After receiving the first message, the second device can verify the first authentication information. If the first authentication information is verified successfully, the second device can decrypt the ciphertext to obtain the service data. If the first authentication information fails to be verified, the second device can reject the first message.

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

[0104] 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 may include the UDM, or the second device (such as the AF device) may forward the first authentication information to the UDM. After the UDM successfully verifies the first authentication information, the UDM may reply to the AF device with a message of successful authentication. After the AF device receives the message of successful authentication, the AF device may use the corresponding key derivation function to derive the second key and the third key. The MAC can be verified using the third key. If the MAC verification fails, the first message can be rejected. If the MAC verification succeeds, the second key can be used to decrypt the ciphertext to obtain plaintext business data and / or signaling.

[0105] 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 each communicating party can be generated. For example, if the first device is a terminal and the second device is a network device, the first key can be used to generate bidirectional authentication information for both the terminal and the network device.

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

[0107] To implement authentication, the first device may implement an authentication process based on the first authentication information. The authentication process may be bidirectional or unidirectional.

[0108] The following describes one-way authentication, which can implement security authentication of a first device to a second device, or vice versa.

[0109] In one-way authentication, a first device can send a first authentication request to a second device. The first authentication request can be used to request the second device to perform security authentication on the first device. The following describes one-way authentication in detail, taking the first device as an AIoT terminal and the second device as a network device as an example. When the AIoT terminal is initially connected, 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 via the first authentication request. Based on the first authentication request, the network device can authenticate and register the AIoT terminal. If the 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 not. If the AIoT terminal does not authenticate the network device, the above process implements one-way authentication of the AIoT terminal by the network device.

[0110] In one-way authentication, the second device can send a first authentication request to the first device. The first authentication request can be used to request the first device to perform security authentication on the second device. Below, taking the second device as an AIoT terminal and the first device as a network device as an example, one-way authentication is described in detail. After the AIoT terminal has successfully registered with the network device, the network device can trigger the AIoT terminal to authenticate the network device. For example, the network device can send an authentication request including first authentication information to the AIoT terminal. Taking the first algorithm including the ASCON-AEAD algorithm as an example, the network device can calculate the ciphertext C and the verification tag T and send C and T to the AIoT terminal via the first authentication request. In response to receiving the authentication request, the AIoT terminal can authenticate the network device and generate a context. If the 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 not. If the network device does not authenticate the AIoT terminal, the above process implements one-way authentication of the network device by the AIoT terminal.

[0111] The two-way authentication is explained below. Two-way authentication can achieve mutual authentication between the first device and the second device. Taking the first device as an AIoT terminal and the second device as a network device as an example, the two-way authentication process may include the authentication of the AIoT terminal by the network device, and the authentication of the network device by the AIoT terminal. In some embodiments, the first device may send a first authentication request. The first authentication request may 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 may generate second authentication information and send it to the first device through a first authentication response so that the first device authenticates the second device. After the first device successfully authenticates the second device, the first device may send the first authentication information to the second device so that the second device authenticates the first device. If the second device also successfully authenticates the first device, the above-mentioned two-way authentication process is successful, and the first device can communicate securely with the second device.

[0112] The following describes the transmission of the first authentication request by taking the second device including the UDM as an example. It is understandable that the UDM in the following embodiments can also be replaced by other communication devices with the function of storing or managing shared keys.

[0113] As an implementation manner, the UDM may directly receive the first authentication request sent by the first device through the access network device.

[0114] As an implementation method, the first authentication request can be sent to the UDM through the access network device and one or more core network entities. After receiving the first authentication request, the one or more core network entities can forward the first authentication request to the UDM. The one or more core network entities can include one or more of the following: AMF, AUSF, HSE, UDR, SEAF, and a NF specially configured to forward the first authentication request.

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

[0116] The first random number can also be used to identify and prevent replay attacks. As an implementation method, after receiving the first random number, the second device can verify whether the first random number is identical to a previously received random number. If the first random number received this time is identical to a previously received first random number, the second device can reject the first authentication request.

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

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

[0119] In some embodiments, the second device may further generate second authentication information for the second device. For example, the second request may further be used to request generation of the second authentication information. When the second device receives the second request, the second device may generate the second authentication information and the first key.

[0120] In some embodiments, the UDM may not generate the second authentication information. If the UDM does not generate the second authentication information, another device may generate the second authentication information. For example, if the second device includes an AF device, the AF device may generate the 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.

[0121] The following describes a method for generating second authentication information. This method can be applied to any network device. For example, both UDM and AF devices can apply this method. The second authentication information can be generated by a security algorithm or a key derivation function. For example, the second device can derive the second authentication information (for example, including a MAC) based on the security algorithms f1 / f2 / f3 / f4 / f5 specified in TS 35.206. The input of the security algorithm may 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 may be a MAC. Alternatively, the second device may generate a MAC through a key derivation function. The input of the key derivation function may 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 may be, for example, FC=0x7E.

[0122] The second device can send the second authentication information to the first device. After receiving the second authentication information, the first device can verify the second authentication information. If the second authentication information is generated by the UDM calculation, the first device can derive a new verification code to verify the second authentication information. If the second authentication information is generated by the AF, the first device can use the shared key to derive the first key and derive the 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.

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

[0124] If the first device fails to verify the second authentication information, the first device may refuse to respond to the second device's authentication request, and the authentication process terminates. If the first device successfully verifies the second authentication information, the first device may continue to perform the authentication process.

[0125] In some embodiments, verification of the second authentication information may be combined with transmission of the first message. For example, if verification of the second authentication information succeeds, the first device may send the first message. If verification of the second authentication information fails, the first device may not send the first message.

[0126] 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 and thereby determine the shared key associated with the first identifier.

[0127] 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 can include one or more of the following identifiers of the first device: AIoT identifier, SUCI, SUPI.

[0128] In some implementations, the first device may send the first authentication request to a third device. The third device may verify the first authentication request and, if successful, forward the first authentication request to the second device. If unsuccessful, the third device may reject the first authentication request. If the first authentication request is rejected, the third device may not send the first authentication request to the second device.

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

[0130] This application does not limit the manner in which the third device verifies the first authentication request. As a possible implementation, the third device may manage the mapping relationship between the second identifier of the third device and the first identifier. In some embodiments, the third device may share the mapping relationship with the second device. The third device may verify whether a mapping relationship exists between the first identifier and the second identifier of the third device. If a mapping relationship exists between the first identifier and the second identifier, the verification may pass. If no mapping relationship exists between the first identifier and the second identifier, the verification may fail.

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

[0132] In some embodiments, the sending of the first authentication request may be triggered by the second device or the third device. That is, the second device and / or the third device may proactively wake up the first device, causing the first device to send the first authentication request. The information waking up the first device may be the 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 need, the third device and / or the second device may wake up the first device.

[0133] To facilitate understanding of the present application, the present application is described in detail below through Examples 1 to 5.

[0134] Example 1

[0135] Figure 7 is a schematic flow chart of a method for communication provided in Example 1. The method shown in Figure 7 can be performed by an AIoT terminal, an access network device, an AF device, and a UDM.

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

[0137] The AIoT terminal and UDM share the shared key K and AIoT ID.

[0138] The method shown in FIG. 7 may include steps S710 to S797 .

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

[0140] Step S715: When the network device has business needs, the access network device actively wakes up the AIoT terminal.

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

[0142] In step S730, the AIoT terminal sends an authentication request message. This authentication request is a first authentication request. The authentication request includes the ID of the AIoT terminal and R1.

[0143] Step S730 may include step S731 or S732.

[0144] In step S731, the AIoT terminal directly sends an authentication request message to the UDM through the access network device. The authentication request message includes the AIoT ID and the random number R1.

[0145] In step S732, the AIoT sends an authentication request message to the AF device through the access network device. The authentication request message includes the AIoT ID and the random number R1. After receiving the message, the AF sends a key request message to the UDM, which includes the AIoT ID and the random number R1.

[0146] Step S740: After receiving the key request message or authentication request message, the UDM derives the key K AF .

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

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

[0149] Step S742: UDM derives the key K based on the key derivation function KDF. AF The key derivation function KDF input parameters include the shared key K, AIoT ID, the length of the AIoT ID, 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, such as FC=0x7E.

[0150] Optionally, step S740 may further include step S743.

[0151] In step S743, the UDM derives a 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.

[0152] Step S750: 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 further include a MAC.

[0153] Step S760: The AF device responds to the message based on the key and performs corresponding operations.

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

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

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

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

[0158] Step S760 also includes step S763. In step S763, the AF device sends an authentication reply message to the AIoT terminal, where the message includes a random number R2 and a MAC.

[0159] Step S770: The AIoT terminal verifies the MAC.

[0160] Step S765 may be included before step S770. In step S765, after the AIoT terminal receives the authentication reply message, the AIoT terminal may transmit the random number R1, random number R2, and MAC to its own security function module (such as UICC; if no security function module exists, no transmission operation is required).

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

[0162] Step S771: If the MAC is generated by the UDM, 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 a new verification code is the same as that on the network device side.

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

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

[0165] Step S780 may include step S781 or S782.

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

[0167] Step S782: If the AIoT terminal uses the confidentiality and integrity protection algorithm in TS33.501, the AIoT terminal uses the key derivation function KDF to generate the confidentiality key K CK-AIoT and the integrity key K IK-AIoT The input parameters of the algorithm include: K AF And 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 such as FC=0x7E, and the identifier of the key to be output. For example, if you want to output the confidentiality key K CK-AIoT , then the identifier of the key to be output is 0x00; if the integrity key K is to be output IK-AIoT , then 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, the length of random number R2 and other information. AIoT uses the key K CK-AIoT After encrypting the business data data, generate ciphertext C, and then use the key K IK-AIoT The integrity of ciphertext C is protected by generating a 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, the random number R1, the random number R2, the length of R1 and the length of R2, RES, the length of RES, and a fixed value assigned by a third party (for example, FC = 0x6B). The AIoT terminal uses the f2 function to generate RES, and the input parameters include the root key K and the random number R2.

[0168] In step S790, the AIoT terminal sends C, MAC1, and RES* to the AF device. Alternatively, the AIoT terminal sends C and T to the AF device.

[0169] After step S790, the AF may perform step S792 or step S793.

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

[0171] In step S793, if AIoT uses the confidentiality and integrity protection algorithm in TS33.501, the AF forwards RES* to the UDM.

[0172] After step S793 , the UDM may execute steps S794 and S795 .

[0173] In step S794, the UDM generates RES*' using the KDF function to verify RES*. The generation process is the same as that of RES* on the AIoT side.

[0174] Step S795: If the RES* verification succeeds, the UDM sends an authentication success message to the AF device. If the RES* verification fails, the message sent by the AF device is rejected.

[0175] After step S795 , the AF device may perform steps S796 and S797 .

[0176] Step S796: After receiving the authentication success message, the AF device generates a confidentiality key K using the key derivation function KDF. CK-AIoT and the integrity key K IK-AIoT The derivation process is the same as that on the AIoT side.

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

[0178] Example 2

[0179] Figure 8 is a schematic flow chart of a method for communication provided in Example 2. The method shown in Figure 7 can be performed by an AIoT terminal, a common terminal (represented by a UE in Figure 8), an access network device, an AF device, and a UDM. Among them, the UE is a proxy node between the AIoT terminal and the network device side.

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

[0181] The AIoT terminal shares a 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 between its own SUPI and AIoT ID. The UE also shares this mapping with the UDM.

[0182] The method shown in FIG. 8 may include steps S810 to S897 .

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

[0184] Step S816: When the network device side and / or UE have business needs, the access network device and / or UE actively wakes up the AIoT terminal.

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

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

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

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

[0189] In step S832, after receiving the first authentication request, the UE first determines whether the AIoT ID is mapped to its own SUPI. If no mapping exists, the AIoT terminal's request is rejected. If a mapping exists, step S833 or S834 is executed.

[0190] In step S833, the UE directly sends an authentication request message to the UDM through the access network device. The authentication request message includes the UE's SUCI encrypted by its SUPI, the AIoT ID, and a random number R1.

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

[0192] Step S840: After receiving the key request message or authentication request message, the UDM derives the key K AF .

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

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

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

[0196] Step S842: UDM derives the key K based on the key derivation function KDF. AF The key derivation function KDF input parameters include the shared key K, AIoT ID, the length of the AIoT ID, 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, such as FC=0x7E.

[0197] Optionally, step S840 may further include step S843.

[0198] In step S843, the UDM derives a 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.

[0199] Step S850: 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 further include a MAC.

[0200] Step S860: The AF device responds to the message based on the key and performs corresponding operations.

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

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

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

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

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

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

[0207] Step S864: After receiving the authentication reply message, the UE forwards the authentication reply message to the AIoT.

[0208] Step S870, the AIoT terminal verifies the MAC.

[0209] Step S865 may be included before step S870. In step S865, after the AIoT terminal receives the authentication reply message, the AIoT terminal may transmit the random number R1, random number R2, and MAC to its own security function module (such as UICC; if no security function module exists, no transmission operation is required).

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

[0211] Step S871: If the MAC is generated by the UDM, 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 a new verification code is the same as that on the network device side.

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

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

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

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

[0216] Step S882: If the AIoT terminal uses the confidentiality and integrity protection algorithm in TS33.501, the AIoT terminal uses the key derivation function KDF to generate the confidentiality key K CK-AIoT and the integrity key K IK-AIoT The input parameters of the algorithm include: K AF And 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 such as FC=0x8E, and the identifier of the key to be output. For example, if you want to output the confidentiality key K CK-AIoT , then the identifier of the key to be output is 0x00; if the integrity key K is to be output IK-AIoT , then 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, the length of random number R2 and other information. AIoT uses the key K CK-AIoT After encrypting the business data data, generate ciphertext C, and then use the key K IK-AIoT The integrity of ciphertext C is protected by generating a 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, the random number R1, the random number R2, the length of R1 and the length of R2, RES, the length of RES, and a fixed value assigned by a third party (for example, FC = 0x6B). The AIoT terminal uses the f2 function to generate RES, and the input parameters include the root key K and the random number R2.

[0217] In step S890, the AIoT terminal sends C, MAC1, and RES* to the UE. Alternatively, the AIoT terminal sends C and T to the UE.

[0218] Step S891: The UE sends C, MAC1, and RES* to the AF device. Alternatively, the UE sends C and T to the AF device.

[0219] After step S890 or S891 , the AF device may perform step S892 or step S893 .

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

[0221] In step S893, if AIoT uses the confidentiality and integrity protection algorithm in TS33.501, the AF forwards RES* to the UDM.

[0222] After step S893 , the UDM may execute steps S894 and S895 .

[0223] In step S894, the UDM generates RES*' using the KDF function to verify RES*. The generation process is the same as that of RES* on the AIoT side.

[0224] Step S895: If the RES* verification succeeds, the UDM sends an authentication success message to the AF device. If the RES* verification fails, the message sent by the AF device is rejected.

[0225] After step S895, the AF device may perform steps S896 and S897.

[0226] Step S896: After receiving the authentication success message, the AF device generates a confidentiality key K using the key derivation function KDF. CK-AIoT and the integrity key K IK-AIoT The derivation process is the same as that on the AIoT side.

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

[0228] Example 3

[0229] Figure 9 is a schematic flow chart of a method for communication provided in Example 3. The method shown in Figure 9 can be executed by an AIoT terminal, an access network device, an AF device, and a UDM.

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

[0231] The AIoT terminal and UDM share the shared key K and AIoT ID.

[0232] The method shown in FIG. 7 may include steps S910 to S997 .

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

[0234] Step S915: When there is a business demand on the network device side, the access network device actively wakes up the AIoT terminal.

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

[0236] Step S930: The AIoT terminal sends an authentication request message. This authentication request is a first authentication request. The authentication request includes the ID of the AIoT terminal and R1.

[0237] Step S930 may include step S931 or S932.

[0238] In step S931, the AIoT terminal directly sends an authentication request message to the UDM through the access network device. The authentication request message includes the AIoT ID and the random number R1.

[0239] In step S932, the AIoT sends an authentication request message to the AF device through the access network device. The authentication request message includes the AIoT ID and the random number R1. After receiving the message, the AF sends a key request message to the UDM, which includes the AIoT ID and the random number R1.

[0240] Step S940: After receiving the key request message or authentication request message, the UDM derives the key K AF .

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

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

[0243] Step S942: UDM derives the key K based on the key derivation function KDF. AF The key derivation function KDF input parameters include the shared key K, AIoT ID, the length of the AIoT ID, 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, such as FC=0x7E.

[0244] Optionally, step S940 may further include step S943.

[0245] In step S943, the UDM derives a 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.

[0246] Step S950: 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 further include a MAC.

[0247] Step S960: The AF device responds to the message based on the key and performs corresponding operations.

[0248] Step S960 may include step S961 or S962.

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

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

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

[0252] Step S960 also includes step S963. In step S963, the AF device sends an authentication reply message to the AIoT terminal, where the message includes a random number R2 and a MAC.

[0253] Step S970: The AIoT terminal verifies the MAC.

[0254] Step S965 may be included before step S970. In step S965, after the AIoT terminal receives the authentication reply message, the AIoT terminal may transmit the 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).

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

[0256] Step S971: If the MAC is generated by the UDM, 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 a new verification code is the same as that on the network device side.

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

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

[0259] Step S980 may include step S981 or S982.

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

[0261] Step S982: If the AIoT terminal uses the confidentiality and integrity protection algorithm in TS33.501, the AIoT terminal uses the key derivation function KDF to generate the confidentiality key K CK-AIoT and the integrity key K IK-AIoT The input parameters of the algorithm include: K AF And 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 such as FC=0x7E, and the identifier of the key to be output. For example, if you want to output the confidentiality key K CK-AIoT , then the identifier of the key to be output is 0x00; if the integrity key K is to be output IK-AIoT , then 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, the length of random number R2 and other information. AIoT uses the key K CK-AIoT After encrypting the business data data, generate ciphertext C, and then use the key K IK-AIoT The integrity of ciphertext C is protected by generating a 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, the random number R1, the random number R2, the length of R1 and the length of R2, RES, the length of RES, and a fixed value assigned by a third party (for example, FC = 0x6B). The AIoT terminal uses the f2 function to generate RES, and the input parameters include the root key K and the random number R2.

[0262] In step S990, the AIoT terminal sends C, MAC1, and RES* to the AF device. Alternatively, the AIoT terminal sends C and T to the AF device.

[0263] After step S990, the AF may perform step S992 or step S993.

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

[0265] In step S993, if AIoT uses the confidentiality and integrity protection algorithm in TS33.501, the AF forwards RES* to the UDM.

[0266] After step S993 , the UDM may execute steps S994 and S995 .

[0267] In step S994, the UDM generates RES*' using the KDF function to verify RES*. The generation process is the same as that of RES* on the AIoT side.

[0268] Step S995: If the RES* verification succeeds, the UDM sends an authentication success message to the AF device. If the RES* verification fails, the message sent by the AF device is rejected.

[0269] After step S995 , the AF device may perform steps S996 and S997 .

[0270] Step S996: After receiving the authentication success message, the AF device generates a confidentiality key K using the key derivation function KDF. CK-AIoT and the integrity key K IK-AIoT The derivation process is the same as that on the AIoT side.

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

[0272] Example 4

[0273] FIG10 is a schematic flow chart of a method for communication provided in Example 4. The method shown in FIG10 can be performed by an AIoT terminal and a local area network gateway (e.g., a gateway in a WLAN network). The AIoT terminal and the local area network gateway share a key K and an AIoT ID.

[0274] The method shown in FIG. 10 may include steps S1010 to S1095 .

[0275] Step S1010: When the gateway has business needs, the gateway actively wakes up the AIoT terminal.

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

[0277] In step S1030, the AIoT terminal sends an authentication request message to the gateway, which includes the AIoT ID and a random number R1.

[0278] In step S1040, the LAN gateway generates authentication information MAC. Step S1040 may include steps S1041 to S1043.

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

[0280] Step S1042: The gateway derives the 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, fixed value assigned by a third party such as FC=0x7E, and other parameters.

[0281] Step S1043: The gateway generates a MAC using the f1 function / key derivation function. If the f1 function is used, the input parameters include: K gate , random number R1 and random number R2. If a key derivation function is used, the input parameters include: K gate , 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 (for example, FC=0x7E).

[0282] In step S1050, the gateway sends an authentication reply message to the AIoT terminal. The authentication reply message includes a random number R2 and a MAC.

[0283] Step S1070: The AIoT terminal uses K to derive the key K gate and verify the MAC.

[0284] When the AIoT terminal receives the authentication reply message, it uses the shared key K to derive the key K gate , and generates a new verification code to verify the MAC. The terminal derives the key K gate The process of generating a new verification code is the same as that of the gateway.

[0285] Step S1081: If the MAC verification succeeds, the AIoT terminal uses the ASCON-AEAD algorithm to output the ciphertext C and the verification tag T. The input of the algorithm includes K gate and business data.

[0286] Step S1082: If the MAC verification fails, the AIoT terminal refuses to respond to the authentication reply message and the process terminates.

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

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

[0289] Example 5

[0290] FIG11 is a schematic flow chart of a method for communication provided in Example 4. The method shown in FIG11 can be performed by an AIoT terminal and a local area network gateway (e.g., a gateway in a WLAN network). The AIoT terminal and the local area network gateway share a key K and an AIoT ID.

[0291] The method shown in FIG. 10 may include steps S1120 to S1195 .

[0292] In step S1120 , the AIoT terminal generates a random number R1.

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

[0294] In step S1140, the LAN gateway generates authentication information MAC. Step S1140 may include steps S1141 to S1143.

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

[0296] Step S1142: The gateway derives the 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, fixed value assigned by a third party such as FC=0x7E, and other parameters.

[0297] Step S1143: The gateway generates a MAC using the f1 function / key derivation function. If the f1 function is used, the input parameters include: K gate , random number R1 and random number R2. If a key derivation function is used, the input parameters include: K gate , 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 (for example, FC=0x7E).

[0298] In step S1150, the gateway sends an authentication reply message to the AIoT terminal. The authentication reply message includes a random number R2 and a MAC.

[0299] Step S1170: The AIoT terminal uses K to derive the key K gate and verify the MAC.

[0300] When the AIoT terminal receives the authentication reply message, it uses the shared key K to derive the key K gate , and generates a new verification code to verify the MAC. The terminal derives the key K gate The process of generating a new verification code is the same as that of the gateway.

[0301] Step S1181: If the MAC verification succeeds, the AIoT terminal uses the ASCON-AEAD algorithm to output the ciphertext C and the verification tag T. The input of the algorithm includes K gate and business data.

[0302] Step S1182: If the MAC verification fails, the AIoT terminal refuses to respond to the authentication reply message and the process terminates.

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

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

[0305] The method embodiments of the present application are described in detail above, and the device embodiments of the present application are described in detail below. It should be understood that the description of the method embodiments corresponds to the description of the device embodiments, so for parts not described in detail, reference can be made to the above method embodiments.

[0306] FIG12 is a schematic structural diagram of a communication device 1200 provided in an embodiment of the present application. The communication device 1200 is a first device and includes a key generation unit 1210 , a first receiving unit 1220 , a generation unit 1230 , and a first sending unit 1240 .

[0307] The key generating unit 1210 is configured to generate a first key based on the shared key.

[0308] The first receiving unit 1220 is configured to receive a second random number from a second device;

[0309] The generating unit 1230 is configured to generate first authentication information of the first device based on the first key.

[0310] The first sending unit 1240 is configured to send a first message to the second device, where the first message includes first authentication information.

[0311] The first authentication information is generated according to one or more of the following information: information related to the first device and the service, an identifier of the device forwarding the first message, a first random number of the first device, and a second random number.

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

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

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

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

[0316] In some embodiments, the communication device 1200 is further used 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.

[0317] In some embodiments, the communication device 1200 is also used to: receive a first authentication reply sent by the second device, the first authentication reply is used to reply to the first authentication request, and the first authentication reply includes the second random number; verify whether the second random number is the same as the random number received historically; if the second random number is the same as the random number received historically, refuse to respond to the first authentication reply.

[0318] In some embodiments, the first authentication reply 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 reply if verification of the second authentication information fails.

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

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

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

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

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

[0324] FIG13 is a schematic structural diagram of another communication device 1300 provided in an embodiment of the present application. The communication device 1300 is a second device and may include a second sending unit 1310 and a second receiving unit 1320.

[0325] The second sending unit 1310 is configured to send a second random number.

[0326] The first sending unit 1320 is used to receive a first message sent by a 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: business-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, and the first key is generated based on a shared key.

[0327] In some embodiments, the first message also includes ciphertext corresponding to the business data, and the ciphertext is generated based on the first key.

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

[0329] 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 is 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.

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

[0331] In some embodiments, the communication device 1300 is further used 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.

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

[0333] In some embodiments, the communication device 1300 is further used to: send a first authentication reply, where the first authentication reply is used to reply to the first authentication request, and the first authentication reply includes the second random number.

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

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

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

[0337] In some embodiments, the 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.

[0338] In some embodiments, the communication device 1300 is further configured to generate the first key according to the first random number, the second random number and the shared key.

[0339] In some embodiments, the communication device 1300 is further configured to generate second authentication information of the second device.

[0340] In some embodiments, the communication device 1300 is further used to: send a second request, where the second request is used to request to derive the first key.

[0341] In some embodiments, the second request is further used to request generation of second authentication information of the second device.

[0342] 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 include the second authentication information of the second device.

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

[0344] FIG14 is a schematic structural diagram of another communication device 1400 provided in an embodiment of the present application. The communication device 1400 is a third device and includes a third receiving unit 1410 and a third sending unit 1420.

[0345] The third receiving unit 1410 is used to receive a first message sent by a first device; the third sending unit 1420 is used to send the first message to a 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: business-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 is generated based on a shared key.

[0346] In some embodiments, the first message also includes ciphertext corresponding to the business data, and the ciphertext is generated based on the first key.

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

[0348] 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 is generated based on the first key, including: the first authentication information is generated based on the third key.

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

[0350] In some embodiments, the communication device 1400 is further used to: receive a first authentication request sent by the first device; and 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.

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

[0352] In some embodiments, the 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.

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

[0354] In an optional embodiment, the first receiving unit 1220, the first sending unit 1240, the second sending unit 1310, the second receiving unit 1320, the third receiving unit 1410, or the third sending unit 1420 may be a transceiver 1530, and the key generating unit 1210 or the generating unit 1230 may be a processor 1510. The communication device 1200, the communication device 1300, or the communication device 1400 may further include a memory 1520, as specifically shown in FIG15 .

[0355] Figure 15 is a schematic block diagram of a communication device according to an embodiment of the present application. The dashed lines in Figure 15 indicate that the unit or module is optional. Apparatus 1500 may be used to implement the method described in the above method embodiment. Apparatus 1500 may be a chip, a terminal, or a network device.

[0356] The device 1500 may include one or more processors 1510. The processor 1510 may support the device 1500 to implement the method described in the above method embodiment. 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 (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

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

[0358] The apparatus 1500 may further include a transceiver 1530. The processor 1510 may communicate with other devices or chips via the transceiver 1530. For example, the processor 1510 may transmit and receive data with other devices or chips via the transceiver 1530.

[0359] The present application also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to a terminal or network device provided in the present application, and the program enables a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0360] The present 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 the present application, and the program causes a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0361] The embodiments of the present application also provide a computer program. The computer program can be applied to the terminal or network device provided in the embodiments of the present application, and the computer program enables a computer to execute the method performed by the terminal or network device in each embodiment of the present application.

[0362] It should be understood that the terms "system" and "network" in this application can be used interchangeably. In addition, the terms used in this application are only used to explain the specific embodiments of this application and are not intended to limit this application. The terms "first", "second", "third", and "fourth" in the specification and claims of this application and the accompanying drawings are used to distinguish different objects rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0363] In the embodiments of this application, the term "indication" may refer to a direct indication, an indirect indication, or an indication of an association. For example, "A indicates B" may refer to a direct indication of B, e.g., B can obtain information through A; it may refer to an indirect indication of B, e.g., A indicates C, e.g., B can obtain information through C; or it may refer to an association between A and B.

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

[0365] In the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and indication, configuration and configuration, etc.

[0366] In the embodiments of the present application, "pre-defined" or "pre-configured" may be implemented by pre-storing corresponding codes, tables, or other methods that can be used to indicate relevant information in a device (e.g., a terminal or network device), and the present application does not limit the specific implementation method. For example, pre-defined may refer to a definition in a protocol.

[0367] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communications field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0368] In the embodiments of this application, the term "and / or" is simply a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0369] In the embodiments of this application, the term "include" can refer to direct inclusion or indirect inclusion. Alternatively, the term "include" in the embodiments of this application can be replaced with "indicates" or "is used to determine." For example, "A includes B" can be replaced with "A indicates B" or "A is used to determine B."

[0370] In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0371] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0372] The units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0373] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

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

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

Claims

1. A method for communication, characterized in that include: The first device generates a first key based on the shared key; The first device receives a second random number from the second device; generating, by the first device, first authentication information of the first device based on the first key; The first device sends a first message to the second device, where the first message includes the first authentication information; 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 that forwards the first message, a 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 ciphertext.

3. The method according to claim 2, characterized in that The ciphertext and the first authentication information are both obtained based on a 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, where the second key is different from the third key; The first device generating, based on the first key, ciphertext corresponding to the business data includes: The first device generates the ciphertext based on the second key; Generating, by the first device, first authentication information of the first device based on the first key includes: The first device generates the first authentication information based on the third key.

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

6. The method according to any one of claims 1 to 5, characterized in that Also includes: The first device sends a first authentication request; The first authentication request is used to request two-way identity authentication between the first device and the second device.

7. The method according to claim 6, characterized in that The method further comprises: The first device receives a first authentication reply sent by the second device, where the first authentication reply is used to reply to the first authentication request and includes the second random number; The first device verifies whether the second random number is the same as a random number received in the past; In a case where the second random number is identical to the random number received in the past, the first device refuses to respond to the first authentication reply.

8. The method according to claim 7, characterized in that The first authentication reply further includes second authentication information of the second device, and the method further includes: Verifying, by the first device, the second authentication information; In the event that verification of the second authentication information fails, the first device refuses to respond to the first authentication reply.

9. The method according to any one of claims 6 to 8, characterized in that The first authentication request includes a first identifier of the first device, where the first identifier is associated with the shared key.

10. The method according to claim 9, characterized in that The first identifier includes one or more of the following identifiers of the first device: an AIoT identifier supporting ambient power, a hidden user identifier SUCI, and a permanent user identifier SUPI.

11. The method according to any one of claims 6 to 10, characterized in that The first authentication request is sent by a third device. If there is no mapping relationship between the first identifier and the second identifier of the third device, the first authentication request is rejected.

12. The method according to any one of claims 6 to 11, characterized in that The first device sending the first authentication request includes: In response to the first device receiving the first trigger information, the first device sends the first authentication request.

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

14. 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, the first authentication information is generated based on a first key, and 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 the second random number, and the first key is generated based on a shared key.

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

16. The method according to claim 15, characterized in that The ciphertext and the first authentication information are both obtained based on a first algorithm.

17. The method according to claim 15, characterized in that The second key and the third key are both generated based on the first key, and the second key is different from the third key. The ciphertext generated based on the first key includes: The ciphertext is 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.

18. The method according to any one of claims 14 to 17, characterized in that The first key is also used to generate second authentication information of the second device.

19. The method according to any one of claims 14 to 18, characterized in that Also includes: The second device receives the first authentication request sent by the first device; The first authentication request is used to request two-way identity authentication between the first device and the second device.

20. The method according to claim 19, wherein The first authentication request includes the first random number, and the method further includes: The second device verifies whether the first random number is the same as a random number received in the past; In a case where the first random number is identical to the random number received in the past, the second device refuses to respond to the first authentication request.

21. The method according to claim 19 or 20, characterized in that The method further comprises: The first authentication reply sent by the second device is used to reply to the first authentication request, and the first authentication reply includes the second random number.

22. The method according to any one of claims 19-20, characterized in that The first authentication request includes a first identifier of the first device, where the first identifier is associated with the shared key.

23. The method according to claim 22, characterized in that The first identifier includes one or more of the following identifiers of the first device: an AIoT identifier supporting ambient power, a hidden user identifier SUCI, and a permanent user identifier SUPI.

24. The method according to any one of claims 19 to 23, wherein: The first authentication request is sent by a third device. If there is no mapping relationship between the first identifier and the second identifier of the third device, the first authentication request is rejected.

25. The method according to any one of claims 19 to 24, characterized in that The second device receiving the first authentication request sent by the first device includes: In response to the first device receiving the first trigger information, the second device receives the first authentication request sent by the first device.

26. The method according to claims 14-25, characterized in that Also includes: The second device generates the first key according to the first random number, the second random number, and the shared key.

27. The method according to claim 26, characterized in that Also includes: The second device generates second authentication information of the second device.

28. The method according to any one of claims 14 to 27, wherein: Also includes: The second device sends a second request, where the second request is used to request generation of the first key.

29. The method according to claim 28, characterized in that The second request is further used to request generation of second authentication information of the second device.

30. The method according to claim 28 or 29, characterized in that Also includes: The second device receives response information of the second request; In a case where the response information to the second request does not include the second authentication information of the second device, the second device generates the second authentication information.

31. The method according to any one of claims 14 to 30, wherein: The first device is an AIoT terminal, and the second device includes one or more network devices.

32. A method for communication, characterized in that include: The third device receives the first message sent by the first device; The third device sends the first message to the second device; Among them, 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 according to one or more of the following information: device information, service-related information, 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 is generated based on a shared key.

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

34. The method according to claim 33, wherein The ciphertext and the first authentication information are both obtained based on a first algorithm.

35. The method according to claim 33, wherein The second key and the third key are both generated based on the first key, and the second key is different from the third key. The ciphertext is generated based on the first key: The ciphertext is 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.

36. The method according to any one of claims 32 to 35, characterized in that The first key is also used to generate second authentication information of the second device.

37. The method according to any one of claims 32 to 35, characterized in that Also includes: The third device receives the first authentication request sent by the first device; The third device sends the first authentication request to the second device; The first authentication request is used to request two-way identity authentication between the first device and the second device.

38. The method according to claim 37, wherein The third device sending the first authentication request to the second device includes: If the first condition is met, the third device sends the first authentication request to the second device; The first condition includes: there is a mapping relationship between the first identifier and the second identifier of the third device.

39. The method according to any one of claims 37 or 38, characterized in that The third device receiving the first authentication request sent by the first device includes: In response to the first device receiving the first trigger information, the third device receives the first authentication request sent by the first device.

40. The method according to any one of claims 32 to 39, wherein: The first device is an AIoT terminal, and the second device includes one or more network devices.

41. A communication device, characterized in that: The communication device is a first device, and the communication device includes: A key generating unit, configured to generate a first key based on the shared key; a first receiving unit, configured to receive a second random number from a second device; a generating unit, configured to generate first authentication information of the first device based on the first key; A first sending unit, configured to send a first message to the second device, where the first message includes the first authentication information; 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 that forwards the first message, a first random number of the first device, and the second random number.

42. The communication device according to claim 41, wherein The generating unit is further configured to: Generate ciphertext corresponding to the business data based on the first key; The first message also includes the ciphertext.

43. The communication device according to claim 42, characterized in that The ciphertext and the first authentication information are both obtained based on a first algorithm.

44. The communication device according to claim 42, wherein: The communication device is further configured to: generating a second key and a third key based on the first key, wherein the second key is different from the third key; The generating unit is specifically configured to: generating the ciphertext based on the second key; and The first authentication information is generated based on the third key.

45. The communication device according to any one of claims 41 to 44, characterized in that The first key is also used to generate second authentication information of the second device.

46. ​​The communication device according to any one of claims 41 to 45, characterized in that The communication device is further configured to: Sending a first authentication request; The first authentication request is used to request two-way identity authentication between the first device and the second device.

47. The communication device according to claim 46, characterized in that The communication device is further configured to: receiving a first authentication reply sent by the second device, where the first authentication reply is used to reply to the first authentication request, and the first authentication reply includes the second random number; Verify whether the second random number is the same as the random number received historically; If the second random number is identical to the random number received in the past, the first authentication reply is rejected.

48. The communication device according to claim 47, characterized in that The first authentication reply further includes second authentication information of the second device, and the communication device is further configured to: verifying the second authentication information; If the second authentication information verification fails, refuse to respond to the first authentication reply.

49. The communication device according to any one of claims 46 to 48, characterized in that The first authentication request includes a first identifier of the first device, where the first identifier is associated with the shared key.

50. The communication device according to claim 49, wherein The first identifier includes one or more of the following identifiers of the first device: an AIoT identifier supporting ambient power, a hidden user identifier SUCI, and a permanent user identifier SUPI.

51. The communication device according to any one of claims 46 to 50, characterized in that The first authentication request is sent by a third device. If there is no mapping relationship between the first identifier and the second identifier of the third device, the first authentication request is rejected.

52. The communication device according to any one of claims 46 to 51, characterized in that The sending of the first authentication request includes: In response to the first device receiving the first trigger information, the first authentication request is sent.

53. The communication device according to any one of claims 41 to 52, characterized in that The first device is an AIoT terminal, and the second device includes one or more network devices.

54. A communication device, characterized in that The communication device is a second device, and the communication device includes: A second sending unit, configured to send a second random number; A second receiving unit, configured to receive a first message sent by the first device; 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 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 the second random number, and the first key is generated based on a shared key.

55. The communication device according to claim 54, characterized in that The first message also includes ciphertext corresponding to the business data, where the ciphertext is generated based on the first key.

56. The communication device according to claim 55, characterized in that The ciphertext and the first authentication information are both obtained based on a first algorithm.

57. The communication device according to claim 55, characterized in that The second key and the third key are both generated based on the first key, and the second key is different from the third key. The ciphertext generated based on the first key includes: The ciphertext is 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.

58. The communication device according to any one of claims 54 to 57, characterized in that The first key is also used to generate second authentication information of the second device.

59. The communication device according to any one of claims 54 to 58, characterized in that The communication device is further configured to: receiving a first authentication request sent by the first device; The first authentication request is used to request two-way identity authentication between the first device and the second device.

60. The communication device according to claim 59, wherein The first authentication request includes the first random number, and the communication device is further configured to: Verify whether the first random number is the same as the random number received previously; If the first random number is identical to the random number received in the past, the first authentication request is rejected.

61. The communication device according to claim 59 or 60, characterized in that The communication device is further configured to: A first authentication reply is sent, where the first authentication reply is used to reply to the first authentication request, and the first authentication reply includes the second random number.

62. The communication device according to any one of claims 59 to 61, characterized in that The first authentication request includes a first identifier of the first device, where the first identifier is associated with the shared key.

63. The communication device according to claim 62, characterized in that The first identifier includes one or more of the following identifiers of the first device: an AIoT identifier supporting ambient power, a hidden user identifier SUCI, and a permanent user identifier SUPI.

64. The communication device according to any one of claims 59 to 63, characterized in that The first authentication request is sent by a third device. If there is no mapping relationship between the first identifier and the second identifier of the third device, the first authentication request is rejected.

65. The communication device according to any one of claims 59 to 64, characterized in that The receiving the first authentication request sent by the first device includes: In response to the first device receiving the first trigger information, a first authentication request sent by the first device is received.

66. The communication device according to claims 54-65, characterized in that The communication device is further configured to: The first key is generated according to the first random number, the second random number and the shared key.

67. The communication device according to claim 66, characterized in that The communication device is further configured to: Generate second authentication information of the second device.

68. The communication device according to any one of claims 54 to 65, characterized in that The communication device is further configured to: Send a second request, where the second request is used to request generation of the first key.

69. The communication device according to claim 68, characterized in that The second request is further used to request generation of second authentication information of the second device.

70. The communication device according to claim 68 or 69, characterized in that The communication device is further configured to: receiving response information of the second request; In a case where the response information to the second request does not include the second authentication information of the second device, the second authentication information is generated.

71. The communication device according to any one of claims 54 to 70, characterized in that The first device is an AIoT terminal, and the second device includes one or more network devices.

72. A communication device, characterized in that The communication device is a third device, and the communication device includes: a third receiving unit, configured to receive a first message sent by the first device; a third sending unit, configured to send the first message to the second device; 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 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 of the second device, and the first key is generated based on a shared key.

73. The communication device according to claim 72, characterized in that The first message also includes ciphertext corresponding to the business data, where the ciphertext is generated based on the first key.

74. The communication device according to claim 73, characterized in that The ciphertext and the first authentication information are both obtained based on a first algorithm.

75. The communication device according to claim 73, characterized in that The second key and the third key are both generated based on the first key, and the second key is different from the third key. The ciphertext is generated based on the first key: The ciphertext is 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.

76. The communication device according to any one of claims 72 to 75, characterized in that The first key is also used to generate second authentication information of the second device.

77. The communication device according to any one of claims 72 to 76, characterized in that The communication device is further configured to: receiving a first authentication request sent by the first device; sending the first authentication request to the second device; The first authentication request is used to request two-way identity authentication between the first device and the second device.

78. The communication device according to claim 77, characterized in that The third sending unit is used for: If the first condition is met, sending the first authentication request to the second device; The first condition includes: there is a mapping relationship between the first identifier and the second identifier of the third device.

79. The communication device according to any one of claims 77 or 78, characterized in that The receiving the first authentication request sent by the first device includes: In response to the first device receiving the first trigger information, a first authentication request sent by the first device is received.

80. The communication device according to any one of claims 72 to 79, characterized in that The first device is an AIoT terminal, and the second device includes one or more network devices.

81. A communication device, characterized in that The communication device comprises a memory and a processor, wherein the memory is used to store a program, and the processor is used to call the program in the memory so as to enable the communication device to execute the method according to any one of claims 1 to 40.

82. A device, characterized in that The device comprises a processor configured to call a program from a memory so as to enable the device to execute the method according to any one of claims 1 to 40.

83. A chip, characterized in that The device comprises a processor configured to call a program from a memory so that a device equipped with the chip executes the method according to any one of claims 1 to 40.

84. A computer-readable storage medium, characterized in that A program is stored thereon, the program causing a computer to execute the method according to any one of claims 1 to 40.

85. A computer program product, characterized in that The method comprises a program for causing a computer to execute the method according to any one of claims 1 to 40.

86. A computer program, characterized in that The computer program causes a computer to execute the method according to any one of claims 1 to 40.

Images