Communication method and apparatus

Abstract

The present application relates to the technical field of communications. Provided are a communication method and apparatus. A terminal acquires a first identifier and a first long-term key of the terminal, and the terminal can send to a network a first message carrying a second identifier that is determined on the basis of the first identifier, so as to trigger mutual authentication, such that the network can determine, on the basis of the second identifier, a second long-term key that is symmetric to the first long-term key of the terminal, and authenticates the terminal on the basis of the second long-term key. The terminal can generate a random number on the basis of the first identifier, and authenticates the network on the basis of the first long-term key, first authentication data from the network, and the random number. The terminal and the network perform mutual authentication by means of symmetric keys, without the need for complex computations. Furthermore, during the mutual authentication between the terminal and the network, the random number for the mutual authentication is generated on the basis of the first identifier, and the network and the terminal do not need to carry the random number during signaling interaction for the mutual authentication, thereby further improving the efficiency of mutual authentication, and saving on signaling resources.

Description

Communication method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on December 28, 2023, with application number 202311862415.5 and application name "A Communication Method and Device", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The embodiments of the present application relate to the field of communication technology, and in particular to a communication method and apparatus. Background Art

[0004] In mobile communication networks, user equipment (UE) authenticates itself with the network using the subscription data in its subscriber identity module (SIM) or universal subscriber identity module (USIM) to gain access to the network. Regardless of the authentication method used, the network must obtain the UE's permanent identity to obtain the corresponding long-term key, K, to proceed with the authentication process.

[0005] However, if the permanent identity is sent directly in plain text, it will expose the user's permanent identity, thereby compromising the user's privacy. Therefore, in the 5th generation (5G) network, an encryption mechanism for the user's permanent identity has been introduced. When a user first registers, the user's permanent identity information is encrypted to ensure the security of the user's permanent identity information. However, the existing encryption method for user permanent identity information requires an asymmetric encryption mechanism with high communication and computational overhead, which may be unaffordable for some terminals with limited capabilities. Summary of the Invention

[0006] The present application provides a communication method and apparatus to protect the security of user identity information.

[0007] In a first aspect, the present application provides a communication method that can be applied to a terminal or a chip of a terminal, which is not specifically limited here. The terminal can be a mobile phone, an in-vehicle device, an Internet of Things device, etc. The method is executed as follows:

[0008] Obtain a first identifier of the terminal and a first long-term key of the terminal; send a first message, wherein the first message is used to trigger two-way authentication, the first message includes a second identifier of the terminal, the second identifier is used to determine a second long-term key for authenticating the terminal in the two-way authentication, the second identifier is determined based on the first identifier, and the second long-term key and the first long-term key are symmetric keys; receive first authentication data; perform authentication of the network in the two-way authentication based on a random number, the first long-term key and the first authentication data, wherein the random number is generated based on the first identifier.

[0009] The above-mentioned two-way authentication can be understood as a two-way authentication between the terminal and the network identity, such as a primary authentication. The above-mentioned first identifier can be a random sequence code in the configuration parameters of the SIM or USIM, or a sequence code that follows the format of the mobile communication network user identity identifier. The first identifier can also include a network identifier, such as a public land mobile network identifier (PLMN) identifier, etc., and this does not specifically limit how to construct the first identifier. The first identifier can be updated with the number of times the two-way authentication occurs. For example, the first identifier corresponding to the Xth primary authentication between the terminal and the network is identifier A, and the first identifier corresponding to the X+1th primary authentication between the terminal and the network is identifier B, and identifier A is different from identifier B. Optionally, the terminal can obtain the first identifier from the configuration parameters of the SIM or USIM of the terminal. Alternatively, after the two-way authentication between the terminal and the network is successful, the device on the network side generates a new first identifier and sends it to the terminal. After the terminal stores the new first identifier, the terminal reads the first identifier from the storage location of the new first identifier (for example, SIM, USIM, or ME). How the terminal obtains the first identifier is not specifically limited here.

[0010] In addition, the terminal may determine the second identifier based on the first identifier. For example, the first identifier may be encrypted to obtain the second identifier; or the first identifier and the terminal's first long-term key may be encrypted to obtain the second identifier. How to determine the second identifier based on the first identifier is not specifically limited herein.

[0011] In this application, a terminal can trigger bidirectional authentication by sending a first message carrying a second identifier to the network. This allows the network to determine a second long-term key symmetric to the terminal's first long-term key based on the second identifier and authenticate the terminal based on the second long-term key. The terminal can then generate a random number based on the first identifier and authenticate the network based on the first long-term key, first authentication data from the network, and the random number. The terminal and the network use a symmetric key for bidirectional authentication, eliminating the need for complex calculations and simplifying processing logic. This is affordable for terminals with limited capabilities.

[0012] In the process of two-way authentication between the terminal and the network, random numbers are also used. In this application, the random number for two-way authentication is generated based on the first identifier. The network and the terminal do not need to carry the random number during the signaling interaction of two-way authentication, which can further improve the efficiency of two-way authentication and save signaling resources.

[0013] In one optional embodiment, the terminal further receives the encrypted ciphertext and decrypts the encrypted ciphertext using the communication key to obtain a third identifier of the terminal, where the communication key is derived from the first long-term key. The third identifier is used to generate a message for the terminal to re-trigger two-way authentication. The terminal may further store the third identifier.

[0014] In the present application, the terminal can update the first identifier based on the third identifier. When the terminal and the network device perform two-way authentication again, the terminal can determine a new second identifier based on the updated first identifier. Based on this, the second identifier in the first message is different each time the two-way authentication is performed. Even if the second identifier is stolen, the identity information of the terminal cannot be obtained, thereby ensuring the security of the identity information of the terminal. Therefore, the message sent by the terminal to trigger the two-way authentication may not include the permanent identity identifier of the terminal, but may include the second identifier determined based on the updated first identifier. Even if an attacker obtains the second identifier in the first message, the identity of the terminal cannot be deciphered.

[0015] In an optional manner, the first message further includes: second authentication data for authenticating the terminal.

[0016] In the present application, the terminal directly carries the second authentication data for authenticating the terminal in the first message, which facilitates the network to directly authenticate the terminal and can improve the efficiency of two-way authentication.

[0017] In an optional manner, the terminal further sends a confirmation message indicating that the terminal has successfully received the third identifier, so that the network device can determine that the terminal has received the third identifier and can store the third identifier.

[0018] In an optional manner, a terminal parameter update process is used to receive the encrypted ciphertext.

[0019] In this application, the terminal can improve data processing efficiency by reusing the existing terminal parameter update process to receive encrypted ciphertext.

[0020] In an optional manner, the terminal further sends a confirmation message of successfully receiving the third identifier, so that the device on the network side clearly knows the timing of storing the third identifier.

[0021] In an optional manner, the second identifier is determined according to a combination of the following parameters:

[0022] The first identifier; or the first identifier and the first long-term key; or the first identifier, the first long-term key, and a count value, wherein the count value indicates the number of times the terminal triggers two-way authentication.

[0023] In this application, the second identifier can be determined based on the first identifier, such as by reusing the first identifier as the second identifier, or by encrypting the first identifier to determine the second identifier. This method is simple and convenient. The second identifier can also be determined based on the first identifier and the first long-term key, such as by performing an encryption operation or a hash operation on the first identifier and the first long-term key. The second identifier can also be determined based on the first identifier, the first long-term key, and a count value indicating the number of times the terminal triggers two-way authentication, such as by performing an encryption operation or a hash operation on the first identifier, the long-term key, and the count value.

[0024] On the second aspect, the present application provides a communication method, which can be applied to a device on the network side or a chip of a device on the network side, which is not specifically limited here. The device on the network side may include unified data management (UDM), authentication server function (AUSF), security anchor function (SEAF), and / or authentication credential repository and processing function (ARPF), etc. The device on the network side may be one of the network elements, or multiple network elements, or a device composed of multiple network elements, which is not specifically limited here. Execute as follows:

[0025] Receive the second identifier of the terminal; determine the first identifier of the terminal and a second long-term key for authenticating the terminal in two-way authentication based on the second identifier, where the second long-term key and the first long-term key of the terminal are symmetric keys; determine verification data based on the second long-term key and a random number, where the verification data is used to authenticate the terminal in two-way authentication, where the random number is determined based on the first identifier; determine first authentication data used to authenticate the network in two-way authentication based on the second long-term key and the random number; and send the first authentication data. Specifically, the above steps can be performed using UDM or ARPF.

[0026] In an optional manner, second authentication data for authenticating the terminal is received; and authentication of the terminal is performed based on the verification data and the second authentication data. Specifically, the UDM / AUSF may receive the second authentication data, and the AUSF may authenticate the terminal based on the verification data and the second authentication data, which is not specifically limited in this application.

[0027] In an optional manner, receiving the second authentication data for authenticating the terminal includes the authentication server function (e.g., AUSF) receiving an authentication request message carrying the second authentication data and the second identifier of the terminal; the authentication server function (e.g., AUSF) storing the second authentication data and sending the second identifier of the terminal to the unified data management function (e.g., UDM or ARPF); receiving the second identifier of the terminal includes the unified data management function (e.g., UDM or ARPF) receiving the second identifier of the terminal from the authentication server function (e.g., AUSF); determining the first identifier and the second long-term key of the terminal based on the second identifier, and determining the verification data based on the second long-term key and the random number includes: the unified data management function (e.g., UDM or ARPF) determining the first identifier and the second long-term key of the terminal based on the second identifier, and determining the verification data based on the second long-term key and the random number; the unified data management function (e.g., UDM or ARPF) sending the verification data to the authentication server function (e.g., AUSF); performing authentication of the terminal based on the verification data and the second authentication data includes: the authentication server function (e.g., AUSF) performing authentication of the terminal based on the verification data and the second authentication data.

[0028] In an optional manner, receiving the second authentication data for authenticating the terminal includes the authentication server function (e.g., AUSF) receiving an authentication request message, the authentication request message carrying the second authentication data and the second identifier of the terminal; the method also includes: sending the second identifier and the second authentication data of the terminal to a unified data management function (e.g., UDM or ARPF); receiving the second identifier of the terminal includes the unified data management function receiving the second identifier and the second authentication data of the terminal from the authentication server function (e.g., UDM or ARPF); determining the first identifier and the second long-term key of the terminal based on the second identifier, and determining the verification data based on the second long-term key and the random number includes: the unified data management function (e.g., UDM or ARPF) determines the first identifier and the second long-term key of the terminal based on the second identifier, and determines the verification data based on the second long-term key and the random number; performing authentication of the terminal based on the verification data and the second authentication data includes: the unified data management function (e.g., UDM or ARPF) performs authentication of the terminal based on the verification data and the second authentication data.

[0029] In an optional manner, the first authentication data is determined based on the second long-term key and the random number, and sending the first authentication data includes: the unified data management function (for example, UDM or ARPF) determines the first authentication data based on the second long-term key and the random number, and sends the first authentication data to the terminal through the authentication server function.

[0030] In an optional manner, a security anchor function (eg, SEAF) receives a first message, the first message being used to trigger bidirectional authentication, the first message including a second identifier of the terminal and second authentication data; the security anchor function sends an authentication request message to an authentication server function.

[0031] In an optional manner, when the terminal is successfully authenticated, a third identifier is generated, and the third identifier is used to generate a message for the terminal to trigger two-way authentication again; the third identifier is encrypted using a communication key to obtain an encrypted ciphertext, wherein the communication key is derived from the second long-term key; and the encrypted ciphertext is sent.

[0032] In an optional manner, the network-side device further stores a third identifier.

[0033] In an optional manner, before storing the third identifier, the receiving terminal receives confirmation information of successfully receiving the third identifier.

[0034] In an optional manner, the encrypted ciphertext is sent using a terminal parameter update process.

[0035] In a third aspect, the present application provides a communication method that can be applied to a terminal or a chip of the terminal, which is not specifically limited here. The terminal can be a mobile phone, a vehicle-mounted device, an Internet of Things device, etc. The execution is as follows:

[0036] Obtain a first key identifier of the terminal, where the first key identifier indicates a first long-term key of the terminal; generate a communication key based on the first key identifier and the first long-term key; determine an identity hiding identifier, where the identity hiding identifier includes a first encrypted ciphertext and a first key identifier, where the first encrypted ciphertext is obtained by encrypting the first subscription permanent identifier of the terminal using the communication key; and send the identity hiding identifier.

[0037] In this application, the terminal generates a communication key based on a first key identifier and a first long-term key, and encrypts a first subscription permanent identifier preconfigured in the terminal based on the communication key to obtain a first encrypted ciphertext. The first encrypted ciphertext and the first key identifier are then sent to the network as the content of the identity hiding identifier, so that the network can determine the second long-term key and verify the first subscription permanent identifier. In this method, the terminal and the network use symmetric (identical) communication keys for encryption and decryption, which can reduce the data processing complexity of the subscription permanent identifier encryption.

[0038] Specifically, the first key identifier is used to determine the second long-term key on the network side, and the second long-term key and the first long-term key are symmetric keys.

[0039] In an optional manner, the terminal further receives a second encrypted ciphertext and decrypts the second encrypted ciphertext using the communication key to obtain a second key identifier of the terminal, which is used to generate an identity hiding identifier for the terminal to re-access the network. Furthermore, the terminal may also store the second key identifier.

[0040] In this application, the terminal can update the first key identifier based on the second key identifier. When the terminal accesses the network again, it can determine the communication key based on the second key identifier and the first long-term key, and encrypt the first subscription permanent identifier based on the communication key. The communication key is different from the communication key determined based on the first key identifier and the first long-term key. Based on this, each time the terminal accesses the network, the first encrypted ciphertext encrypted with the communication key in the identity hiding identifier is different. Even if the identity hiding identifier is stolen, the user's identity information cannot be decrypted, thereby ensuring the security of the user's identity information.

[0041] In an optional manner, the terminal further sends a confirmation message of successfully receiving the second key identifier, so that the device on the network side clearly specifies the timing for storing the second key identifier.

[0042] In an optional manner, a terminal parameter update process is adopted to receive the second encrypted ciphertext.

[0043] In the present application, the terminal can improve data processing efficiency by reusing the existing terminal parameter update process to receive the second encrypted ciphertext.

[0044] In a fourth aspect, the present application provides a communication method, which can be applied to a device on the network side or a chip of a device on the network side. The device on the network side may include UDM, AUSF, SEAF, and / or ARPF, etc. The device on the network side may be one network element, or multiple network elements, or a device equipped with multiple network elements, which is not specifically limited here. Execute as follows:

[0045] An identity-hiding identifier of a receiving terminal is provided, where the identity-hiding identifier includes a first encrypted ciphertext and a first key identifier; a second long-term key and a pre-configured second subscription permanent identifier of the terminal are determined based on the first key identifier, where the second long-term key and the first long-term key of the terminal are symmetric keys; the first encrypted ciphertext is decrypted based on a communication key to obtain the first subscription permanent identifier of the terminal, where the communication key is derived from the second long-term key; and the terminal is authenticated based on the first subscription permanent identifier and the second subscription permanent identifier.

[0046] In an optional manner, when the terminal is successfully authenticated, a second key identifier is generated, which is used to generate an identity hiding identifier for the terminal to access the network again; the second key identifier is encrypted using the communication key to obtain a second encrypted ciphertext; and the second encrypted ciphertext is sent.

[0047] In an optional manner, the second key identifier is stored.

[0048] In an optional manner, before storing the second key identifier, the receiving terminal receives confirmation information of successfully receiving the second key identifier.

[0049] In an optional manner, the second encrypted ciphertext is sent using a terminal parameter update process.

[0050] In a fifth aspect, an embodiment of the present application provides a communication device, which may be a terminal (such as the terminal in the first aspect (or the third aspect) or a chip disposed inside the terminal) or a network-side device (such as the network-side device in the second aspect (or the fourth aspect) or a chip disposed inside the network-side device). The communication device has the functions of implementing the above-mentioned first to fourth aspects. For example, the communication device includes modules or units or means corresponding to the steps involved in the above-mentioned first to fourth aspects. The functions or units or means may be implemented by software, or by hardware, or the corresponding software implementation may be executed by hardware.

[0051] In one possible design, the communication device includes a processing unit and a transceiver unit, wherein the transceiver unit can be used to send and receive signals to achieve communication between the communication device and other devices, for example, the transceiver unit is used to receive a first message; the processing unit can be used to perform some internal operations of the communication device. The transceiver unit can be called an input / output unit, a communication unit, etc., and the transceiver unit can be a transceiver; the processing unit can be a processor. When the communication device is a module (such as a chip) in a communication device, the transceiver unit can be an input / output interface, an input / output circuit, or an input / output pin, etc., and can also be called an interface, a communication interface, or an interface circuit, etc.; the processing unit can be a processor, a processing circuit, or a logic circuit, etc.

[0052] In another possible design, the communication device includes a processor and may also include a transceiver, the transceiver is used to send and receive signals, and the processor executes program instructions to complete the method in any possible design or implementation of the first to fourth aspects above. The communication device may also include one or more memories, the memories are used to couple with the processor, and the memories can store the necessary computer programs or instructions for implementing the functions involved in the first aspect above. The processor can execute the computer program or instructions stored in the memory, and when the computer program or instructions are executed, the communication device implements the method in any possible design or implementation of the first to fourth aspects above.

[0053] In another possible design, the communication device includes a processor, which can be coupled to a memory. The memory can store the necessary computer programs or instructions for implementing the functions of the first to fourth aspects described above. The processor can execute the computer programs or instructions stored in the memory. When the computer programs or instructions are executed, the communication device implements the method in any possible design or implementation of the first to fourth aspects described above.

[0054] In another possible design, the communication device includes a processor and an interface circuit, wherein the processor is used to communicate with other devices through the interface circuit and execute the method in any possible design or implementation of the first to fourth aspects above.

[0055] It can be understood that in the fifth aspect above, the processor can be implemented by hardware or by software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, etc.; when implemented by software, the processor can be a general-purpose processor, which is implemented by reading the software code stored in the memory. In addition, the above processors can be one or more, and the memories can be one or more. The memory can be integrated with the processor, or the memory and the processor can be set separately. In the specific implementation process, the memory can be integrated with the processor on the same chip, or can be set on different chips respectively. The embodiment of the present application does not limit the type of memory and the setting method of the memory and the processor.

[0056] In a sixth aspect, an embodiment of the present application provides a communication system, which includes the above-mentioned terminal and network-side equipment.

[0057] In a seventh aspect, the present application provides a chip system, which includes a processor and may also include a memory, for implementing the methods described in aspects 1 to 4. The chip system may be composed of a chip or may include a chip and other discrete devices.

[0058] In an eighth aspect, the present application further provides a computer-readable storage medium, in which computer-readable instructions are stored. When the computer-readable instructions are executed on a computer, the computer executes the methods in the first to fourth aspects.

[0059] In a ninth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the methods of the embodiments of the first to fourth aspects above.

[0060] For the technical effects that can be achieved in the above-mentioned second to ninth aspects, please refer to the description of the technical effects that can be achieved by the corresponding possible design schemes in the above-mentioned first aspect, and this application will not repeat them here. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] FIG1 is a schematic diagram of a 5G network architecture provided in an embodiment of the present application;

[0062] FIG2 shows a schematic structural diagram of a SUCI;

[0063] FIG3A shows a schematic diagram of 5G key derivation;

[0064] FIG3B shows a schematic diagram of a UPU process;

[0065] FIG4A shows a schematic flow chart of a communication method provided in an embodiment of the present application;

[0066] FIG4B shows a schematic flow chart of a communication method provided in an embodiment of the present application;

[0067] FIG5 shows a flow chart of a communication method provided in an embodiment of the present application;

[0068] FIG6 shows a flow chart of a communication method provided in an embodiment of the present application;

[0069] FIG7 shows a flow chart of a communication method provided in an embodiment of the present application;

[0070] FIG8A shows a schematic flow chart of a communication method provided in an embodiment of the present application;

[0071] FIG8B shows a flow chart of a communication method provided in an embodiment of the present application;

[0072] FIG9 shows a schematic structural diagram of a SUCI provided in an embodiment of the present application;

[0073] FIG10 shows a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0074] FIG11 shows a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0075] FIG12 shows a schematic structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0076] In order to make the purpose, technical solutions and advantages of this application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The specific operating methods in the method embodiments can also be applied to the device embodiments or system embodiments. In the description of this application, unless otherwise specified, "multiple" means two or more. Therefore, the implementation of the device and method can refer to each other, and the repeated parts will not be repeated.

[0077] The technical solutions provided in the embodiments of the present application can be applied to 5G systems, or to future communication systems or other similar communication systems. In addition, the technical solutions provided in the embodiments of the present application can be applied to cellular links, public land mobile networks (PLMN), machine to machine (M2M) networks, Internet of Things (IoT) networks or other networks. It can also be applied to links between devices, such as device to device (D2D) links. D2D links can also be called sidelinks, where sidelinks can also be called side links or side links, etc. In the embodiments of the present application, the above terms all refer to links established between devices of the same type, and their meanings are the same. The so-called devices of the same type can be links between terminal devices, links between base stations, links between relay nodes, etc., and the embodiments of the present application do not limit this. For links between devices, there are D2D links defined in Release (Rel) 12 / 13 of the Third Generation Partnership Project (3GPP), as well as V2X links defined for vehicle-to-vehicle, vehicle-to-mobile, or vehicle-to-any-entity connections in Releases 14 / 15. Also included are V2X links based on the New Radio (NR) system defined in Release 18 and later.

[0078] Figure 1 is a schematic diagram of a 5G network architecture applicable to this application. The 5G network architecture shown in Figure 1 may include three parts: the terminal device part, the data network (DN), and the operator network part. The functions of some of the network elements are briefly described below.

[0079] Among them, the operator network may include one or more of the following network elements: authentication server function (AUSF), network exposure function (NEF), policy control function (PCF), unified data management (UDM), unified data repository (UDR), network repository function (NRF), access and mobility management function (AMF), session management function (SMF), access network and user plane function (UPF), etc. In the above-mentioned operator network, the part other than the radio access network part can be called the core network part. In a possible implementation method, the operator network also includes an application function (AF). Alternatively, the AF may not belong to the operator network, but to a third party.

[0080] A terminal device, also known as user equipment (UE), is a device with wireless transceiver capabilities. It can be deployed on land, indoors or outdoors, handheld or in a vehicle; on water (such as ships); or in the air (such as on airplanes, balloons, and satellites). Terminal devices can be mobile phones, tablets, computers with wireless transceiver capabilities, virtual reality (VR) terminals, augmented reality (AR) terminals, wireless terminals used in industrial control, wireless terminals used in self-driving cars, wireless terminals used in remote medical care, wireless terminals used in smart grids, wireless terminals used in transportation safety, wireless terminals used in smart cities, and wireless terminals used in smart homes.

[0081] The above-mentioned terminal device can establish a connection with the operator network through the interface provided by the operator network (such as N1, etc.), and use the data and / or voice services provided by the operator network. The terminal device can also access the DN through the operator network, use the operator services deployed on the DN, and / or services provided by a third party. Among them, the above-mentioned third party may be a service provider other than the operator network and the terminal device, and can provide data and / or voice services to the terminal device. Among them, the specific form of the above-mentioned third party can be determined according to the actual application scenario and is not limited here.

[0082] The core network part includes user plane functions and control plane functions.

[0083] User plane functions include UPF. As the interface with the data network, UPF performs functions such as user plane data (such as packet data) forwarding, quality of service (QoS) control, session / flow-level billing and statistics, and bandwidth limiting.

[0084] The control plane functions mainly carry out user registration and authentication, mobility management, and delivery of data packet forwarding policies and QoS control policies to the user plane functions. The control plane functions can be further refined to include other network elements besides the UPF, such as the AMF and SMF.

[0085] The AMF primarily handles user registration, location management, and access authentication / authorization during user mobility. It is also responsible for communicating user policies between the terminal device and the PCF. The connection between the terminal device and the AMF is called a non-access stratum (NAS) connection, and the messages transmitted between the terminal device and the AMF are NAS messages.

[0086] SMF is mainly responsible for establishing corresponding session connections when users initiate services and providing specific services to users, such as sending data packet forwarding strategies and QoS strategies to UPF based on the NG4 interface between SMF and UPF.

[0087] AUSF is mainly responsible for authenticating users and determining the legitimacy of terminal devices to determine whether the terminal devices are allowed to access the network.

[0088] UDM is mainly responsible for storing the contract data of terminal devices, user access authorization and other functions.

[0089] UDR is mainly responsible for the storage and access of contract data, policy data, application data and other types of data.

[0090] PCF is mainly responsible for issuing business-related policies to AMF or SMF.

[0091] NEF is mainly used to support the opening of capabilities and events.

[0092] The AF primarily communicates application-side requirements for the network to the PCF, enabling the PCF to generate corresponding policies. The AF can be a third-party functional entity or an application service deployed by an operator, such as the Internet Protocol (IP) Multimedia Subsystem (IMS) voice call service.

[0093] NRF can be used to provide network element discovery capabilities, providing network element information corresponding to the network element type based on requests from other network elements. NRF also provides network element management services such as network element registration, update, and deregistration, as well as network element status subscription and push.

[0094] A DN is a network located outside of a carrier network. A carrier network can connect to multiple DNs, and a variety of services can be deployed on the DN, providing data and / or voice services to terminal devices. For example, a DN is the private network of a smart factory. Sensors installed in the workshop can be terminal devices. The DN houses a sensor control server, which provides services to the sensors. Sensors can communicate with the control server, receive instructions from the control server, and transmit collected sensor data to the control server based on the instructions. Another example is a DN that is a company's internal office network. An employee's mobile phone or computer can be a terminal device, allowing them to access information and data resources on the company's internal office network.

[0095] In Figure 1, Nnssf, Nausf, Nnef, Nnrf, Npcf, Nudm, Naf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface sequence numbers. The meanings of these interface sequence numbers can be found in the 3GPP protocol and are not limited here.

[0096] It is understood that the above-mentioned network element or function can be a network element in a hardware device, a software function running on dedicated hardware, or a virtualized function instantiated on a platform (e.g., a cloud platform). Optionally, the above-mentioned network element or function can be implemented by a single device, or by multiple devices, or can be a functional module within a single device, and this is not specifically limited in the embodiments of the present application.

[0097] The access and mobility management function (also referred to as the mobility management function), the authentication server function, and the unified data management in the embodiment of the present application can be the AMF, AUSF, and UDM in Figure 1, respectively, or they can be network elements with the above-mentioned AMF, AUSF, and UDM functions in future communications such as the sixth generation (6G) network. The embodiment of the present application is not limited to this.

[0098] To facilitate understanding of the embodiments of the present application, the following briefly describes the terms or processing procedures involved in the embodiments of the present application.

[0099] 1) SUCI is obtained by encrypting the terminal's SUPI and is used to protect the user's identity information. The SUCI data structure is shown in Figure 2 and includes SUPI-type, Home Network Identifier, Routing Indicator, Protection Scheme Id, Home Network Public Key Id, and Scheme Output.

[0100] SUPI-type represents the SUPI type, consisting of values ​​ranging from 0 to 7. It identifies the type of SUPI hidden in the SUCI. Refer to Table 1 below for indications. For example, 0 indicates that the SUPI is of IMSI type. This field also allows you to determine whether the SUPI uses IMSI or NAI format.

[0101] Table 1

[0102] The Home Network Identifier represents the home network identifier. When the SUPI type is IMSI, the Home Network Identifier consists of two parts:

[0103] Mobile Country Code (MCC), consisting of three decimal digits, the MCC uniquely identifies the country of residence of the mobile subscription;

[0104] Mobile Network Code (MNC), consisting of two or three decimal digits, identifies the home PLMN or SNPN of the mobile subscription.

[0105] When the SUPI type is Network Specific Identifier, GLI, or GCI, the Home Network Identifier consists of a series of characters with variable length representing the domain name as specified in section 2.2 of IETF RFC 7542. For GLI or GCI, the domain name shall correspond to the realm part specified in the SUPI NAI format.

[0106] Among them, Routing Indicator represents the routing identifier, which consists of a 1 to 4 decimal number allocated by the home network operator and provided in the USIM, allowing the network signaling with SUCI to be routed to the AUSF and UDM instances that can serve the user together with the home network identifier. If the routing indication is not configured on the USIM or ME, this data field should be set to 0.

[0107] The Protection Scheme Id field represents the protection scheme identifier used for SUPI encryption and is a value in the range of 0-15. The Protection Scheme Id field represents the null scheme or non-null scheme specified in Annex C of 3GPP TS 33.501, or the protection scheme specified by the HPLMN. If the SUPI type is GLI or GCI, the null scheme should be used. 3GPP currently defines this value as follows:

[0108] null-scheme (value is 0x0);

[0109] Profile (value is 0x1);

[0110] Profile (value is 0x2);

[0111] Values ​​0x3-0xB are reserved for future standardized protection schemes, and 0xC-0xF are reserved for proprietary protection schemes specified by the home operator.

[0112] The Home Network Public Key Id field represents the home network public key information and consists of a value from 0 to 255. It represents one of the public key identifiers provided by the HPLMN or SNPN, and identifies the network-side public key used to generate the SUPI. This field shall be set to 0 if and only if the null protection scheme is used.

[0113] Among them, Scheme Output represents the result of encrypting the MSIN part of the IMSI or the username part of the NAI, and consists of a string of variable length or hexadecimal digits, depending on the protection scheme used. Specifically, the ME generates a new ECC (elliptic curve cryptography) temporary public key based on the protection scheme identifier and the parameters specified by the ECIES algorithm, uses the temporary public key and the public key allocated by the home network stored in the USIM, and performs the encryption operation defined in the ECIES specification in SEGE to obtain Scheme Output. Specifically, the secret value generated by the key exchange algorithm is first used as the input of the key derivation function KDF to generate the corresponding protection key, that is:

[0114] Generate key data K of length enckeylen+icblen+mackeylen.

[0115] Parse the leftmost enckeylen octet of K as the encryption key EK, parse the middle icblen octet of K as ICB (encrypted input), and parse the rightmost mackeylen octet of K as the MAC key MK. The final output Scheme Output is the concatenation of the ECC temporary public key (Eph.public key), the ciphertext value (Ciphertext value) generated by encrypting SUPI with EK, the MAC tag value (MAC-tag value) generated by MACing the generated ciphertext value with MK, and any other parameters.

[0116] 2) 5G key deduction can be understood by referring to Figure 3A. The key hierarchy includes the following keys: K (terminal long-term key), CK, IK, AUSF key (K AUSF ), SEAF key (K SEAF ), AMF key (K AMF ), NAS integrity key (K NASint ), NAS encryption key (K NASenc ), N3IWF key (K N3IWF ), gNB key (K gNB ), RRC integrity key (K RRCint ), RRC encryption key (K RRCenc ), UP integrity key (K UPint ), UP encryption key (K UPenc ). Take the network side as an example:

[0117] In the HPLMN, the UDM derives the AUSF key based on the CK and IK and provides the AUSF key to the AUSF. The AUSF derives the SEAF key based on the AUSF key and provides the SEAF key to the SEAF in the serving network.

[0118] In the service network, SEAF derives the AMF key based on the SEAF key and provides the AMF key to AMF.

[0119] The AMF derives the NAS integrity key and NAS cipher key from the AMF key. These keys are used to protect NAS messages transmitted over the NAS connection between the AMF and the terminal device. Furthermore, the AMF derives the N3IWF key and gNB key from the AMF key and provides the N3IWF with the key to protect subsequent non-3GPP access data traffic. The AMF also provides the gNB key and next hop (NH) parameters to the gNB.

[0120] The gNB generates the RRC integrity key, RRC encryption key, UP integrity key, and UP encryption key based on the gNB key and NH parameters. The RRC integrity key and RRC encryption key are used to protect RRC messages transmitted between the gNB and the terminal device; the UP integrity key and UP encryption key are used to protect user plane data transmitted between the gNB and the terminal device.

[0121] Furthermore, the NAS integrity key, RRC integrity key, and UP integrity key are all used to protect the integrity of messages. The NAS encryption key, RRC encryption key, and UP encryption key are all used to encrypt and protect messages.

[0122] Take the NAS integrity key and NAS encryption key as an example:

[0123] When the AMF sends a downlink NAS message to a terminal device, the AMF and the terminal device can perform integrity protection on the downlink NAS message based on the NAS integrity key. Specifically, the AMF can generate a message authentication code (MAC) for integrity protection based on the NAS message and the NAS integrity key, and then send the NAS message and MAC to the terminal device. Accordingly, the terminal device receives the MAC and NAS message from the AMF and performs integrity verification on the NAS message based on the MAC and the locally stored NAS integrity key. Furthermore, the AMF and the terminal device can also perform encryption protection on the downlink NAS message based on the NAS encryption key. Specifically, the AMF can encrypt the NAS message based on the NAS encryption key to obtain an encrypted NAS message, and then the AMF sends the encrypted NAS message to the terminal device. Accordingly, the terminal device receives the encrypted NAS message from the AMF and decrypts the encrypted NAS message based on the locally stored NAS encryption key.

[0124] Similarly, when the terminal device sends an uplink NAS message to the AMF, the terminal device and the AMF may perform integrity protection on the uplink NAS message based on the NAS integrity key, and perform encryption protection on the uplink NAS message based on the NAS encryption key. For details, please refer to the description of the AMF sending a downlink NAS message to the terminal device above.

[0125] It is understood that when transmitting NAS messages between the AMF and the terminal device, both integrity protection and encryption protection can be performed, or one of the two protections can be performed. In this application, integrity protection and encryption protection can be collectively referred to as security protection.

[0126] 3) Bidirectional authentication means that the terminal authenticates the network side through the subscription data (such as the long-term key K) in the (U)SIM card, thereby obtaining authorization to access the network. Taking 5G as an example, there are three bidirectional authentication methods: 5G-AKA (5G Authentication and Key Management), EAP-AKA (Extensible Authentication Protocol-Authentication and Key Management), and EAP-TLS (Extensible Authentication Protocol-TLS). Among them, in the 5G-AKA process, the home network authentication center provides a set of 5G authentication vectors and corresponding verification data HXRES* to the security anchor point (SEAF) of the access network. After the access network authenticates the UE with these parameters, it is also necessary to send the UE's authentication response to the home network authentication center for further authentication. The home network then sends the authentication result to the access network. In 5G, the above-mentioned bidirectional authentication can also be called 5G main authentication. The above-mentioned authentication method can be understood with reference to the existing protocol and will not be explained in detail here.

[0127] 4) The UE parameter update process (UPU process for short) is a process triggered by the UDM after the UE successfully authenticates and registers with the 3GPP system (such as the 5G system). Please refer to Figure 3B for understanding. The following is an example of data interaction between the UE, AMF, AUSF and UDM. The execution is as follows:

[0128] Step 301: UDM decides to execute UPU.

[0129] Specifically, when the UE registers to the 5G system, the UDM decides to perform UPU using the control plane procedure. If the final consumer of the UE parameters to be updated (e.g., updating routing ID data) is the USIM, the UDM should use the security group mechanism to protect these parameters to update the parameters stored on the USIM. The UDM should then construct the UE parameter update data (UPU data) by including the parameters protected by the security group (if any) and any UE parameters whose final consumer is the ME.

[0130] Step 302: UDM sends a Nausf_UPUProtection (UPU protection) message to AUSF, which carries the identity SUPI and UPU data.

[0131] Specifically, UDM should choose to send the latest K AUSF If the UDM decides that the UE confirms that the security check of the received UE parameter update data is successful, the UDM shall set the corresponding indication in the UE parameter update data and include the ACK indication in the Nausf_UPUProtection service operation message to indicate that UPU-XMAC-I is required. UE (UE performs MAC calculation on UPU confirmation message), wherein UPU-XMAC-IUE is based on K AUSF The results are deduced and will not be explained in detail here.

[0132] Step 303, AUSF sends a Nausf_UPUProtection Response (UPU protection response) message to UDM, which carries UPU-MAC-I AUSF (AUSF performs MAC calculation on UE parameter update data) and Counter UPU (UPU counter).

[0133] If the UDM message carries an ACK indication, this response message should also carry UPU-XMAC-I UE Among them, UPU-MAC-I AUSF Refer to the existing agreement according to K AUSF The results are deduced and will not be explained in detail here.

[0134] Step 304: UDM sends a Nudm_SDM_Notification (Subscriber Data Management Service Data Management, SDM) message to AMF, which carries UPU data, UPU-MAC-I AUSF and Counter UPU .

[0135] If the UDM sends an ACK indication, the AMF shall temporarily store the expected UPU-XMAC-I UE .

[0136] Step 305: AMF sends a downlink NAS transmission message to the served UE, which carries UPU data, UPU-MAC-I AUSF and Counter UPU .

[0137] Step 306: The UE verifies the UPU data.

[0138] Specifically, the UE can update the data and Counter according to the received UE parameters. UPU UPU-MAC-I is calculated in the same way as AUSF AUSF , and verify whether it is the same as the UPU-MAC-I received in the UPU transparent container in the downlink NAS transmission message AUSF If the UPU-MAC-I AUSF If the authentication is successful and the UPU data contains parameters protected by the security packet, the ME shall forward the security packet to the USIM. AUSF If the verification is successful and the UPU data contains any parameters not protected by the security data packet, the ME shall update its stored parameters with the parameters received in the UDM update data.

[0139] Step 307: If the UDM has requested UE confirmation and the UE has successfully verified and updated the UE parameter update data provided by the UDM, the UE shall send an uplink NAS transfer message to the serving AMF.

[0140] Specifically, the UE should generate UPU-MAC-I UE , and generate the UPU-MAC-I UE Included in uplink NAS transmission messages.

[0141] Step 308: AMF shall send Nudm_SDM_Info (SDM information) request message to UDM, which carries UPU-MAC-I UE .

[0142] Step 309, UDM shall receive the received UPU-MAC-I UE The expected UPU-XMAC-I temporarily stored by the UDM in step 304 UE Make a comparison.

[0143] UPU may also involve other specific details, which are not explained here. You can refer to the existing protocols for understanding.

[0144] 5) Long-term key

[0145] A key shared by the user (terminal) and the core network, such as the unified data management network element (UDM). The long-term key of the terminal can be pre-configured in the SIM card, for example, stored in a secure environment of the SIM card. The long-term key of the network can be stored in the UDM. For ease of description, the long-term key of the terminal is referred to as the first long-term key, and the long-term key of the network is referred to as the second long-term key. It should be understood that when a symmetric key algorithm is used, the first long-term key and the second long-term key are the same, and accordingly, the key identifiers are also the same. Therefore, the first long-term key and the second long-term key can be referred to as long-term keys without distinction.

[0146] 6) The first identifier can be understood as a temporary identity identifier of the terminal. This first identifier can be updated as the number of mutual authentications occurs. For example, the first identifier corresponding to the Xth mutual authentication between the terminal and the network is identifier A, and the first identifier corresponding to the X+1th mutual authentication between the terminal and the network is identifier B. Identifiers A and B are different. This is merely an example and is not intended to be limiting.

[0147] The first identifier may be a random sequence code or a sequence code in the format of a mobile communication network user identity identifier. In addition to the above information, the first identifier may also include a network identifier, such as a PLMN identifier, etc., and how to construct the first identifier is not specifically limited.

[0148] Optionally, the terminal may obtain the first identifier from the configuration parameters of the terminal's SIM or USIM. Alternatively, after successful bidirectional authentication between the terminal and the network, the network-side device generates a new first identifier and sends it to the terminal. After the terminal stores the new first identifier, the terminal reads the first identifier from the storage location of the new first identifier (e.g., SIM, USIM, or ME). How the terminal obtains the first identifier is not specifically limited herein.

[0149] Optionally, the terminal may pre-configure multiple first identifiers, such as a resource pool of first identifiers.

[0150] In an optional implementation, each first identifier is used for a single bidirectional authentication, thereby allowing the first identifier to be different for each of the multiple bidirectional authentications. For example, each time a bidirectional authentication with the network is performed, a first identifier is selected from a resource pool of first identifiers as the first identifier for bidirectional authentication, and the first identifier is simultaneously deleted from the resource pool.

[0151] In another optional implementation, each first identifier can be used for multiple bidirectional authentications, but the first identifiers used by the same terminal in two consecutive bidirectional authentications are different. For example, each time bidirectional authentication with the network is performed, a first identifier is selected from a resource pool of first identifiers as the first identifier used for bidirectional authentication.

[0152] For the above configuration method, the network side also configures the first identifier accordingly, for example, the first identifier is configured in the UDM or ARPF, and the configuration method is the same as the terminal.

[0153] 7) The second identifier is determined based on the first identifier in 6).

[0154] The second identifier is updated as the first identifier is updated. For example, if the first identifier is identifier A, the corresponding second identifier is identifier 1; if the first identifier is identifier B, the corresponding second identifier is identifier 2. This is merely an example and is not intended to be limiting. The second identifier can be carried in a bidirectional authentication request message between the terminal and the network, indicating the terminal's identity information during the bidirectional authentication process between the terminal and the network device.

[0155] The second identifier is determined based on the first identifier. Specifically, the first identifier can be reused as the second identifier (that is, the first identifier and the second identifier are the same identifier), or the first identifier can be encrypted to determine the second identifier. The second identifier can also be determined based on the first identifier and the long-term key of the terminal (the first long-term key or the second long-term key), such as the terminal (or the device on the network side) performs an encryption operation or a hash operation on the first identifier and the first long-term key to obtain the second identifier. For example, KID=H(K, RAND), where H represents a hash operation. If the terminal calculates the second identifier, then K represents the first long-term key; if the device on the network side calculates the second identifier, then K represents the second long-term key. RAND represents the first identifier, and KID represents the second identifier.

[0156] When the terminal applies to access the network and performs the process of two-way authentication on the network, the above process may fail due to network congestion, equipment failure on the network side, etc. If the terminal still uses the second identifier that failed to execute the above process to perform the access and two-way authentication process again, there may be a security risk. Based on this, the second identifier can also be determined based on the first identifier, the first long-term key of the terminal, and a count value indicating the number of times the terminal triggers two-way authentication, such as performing an encryption operation or a hash operation on the first identifier, the first long-term key, and the count value to obtain the second identifier. For example, KID = H (K, RAND, COUNT), where COUNT represents the count value, H represents the hash operation, K represents the first long-term key, RAND represents the first identifier, and KID represents the second identifier.

[0157] Optionally, the device on the network side (for example, UDM or ARPF) can pre-calculate the second identifier based on the first identifier, and store the correspondence between the first identifier, the second identifier, and the second long-term key. Specifically, the device on the network side can refer to the method in which the above-mentioned terminal determines the second identifier based on the first identifier to perform pre-calculation to obtain the pre-calculated second identifier, which is not explained in detail here. It should be noted that when the device on the network side pre-calculates the second identifier, the first long-term key involved in calculating the second identifier needs to be replaced with the second long-term key.

[0158] 8) Symmetric key algorithms, also known as symmetric encryption algorithms, private key encryption algorithms, and shared key encryption algorithms, are a type of encryption algorithm in cryptography. These algorithms use the same key for encryption and decryption.

[0159] In this document, unless otherwise specified, " / " means "or." For example, A / B can mean A or B. "And / or" in this document simply describes an association relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, and B exists alone. Furthermore, "at least one" means one or more, and "plurality" means two or more. Terms such as "first" and "second" do not limit the quantity or order of execution, and terms such as "first" and "second" do not necessarily specify differences.

[0160] It should be noted that, herein, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0161] In order to protect user privacy, an asymmetric encryption processing mechanism is currently used to encrypt the permanent identity identifier (such as the above-mentioned SUPI). However, this encryption processing mechanism has high computational complexity and large computational consumption, and is not feasible for some terminal devices.

[0162] Based on this, the present application provides a processing solution based on a symmetric encryption processing mechanism to protect the identity information of the terminal. Specifically, the second identifier can be determined using a first identifier pre-configured by the terminal (applicable to the initial access to the network and bidirectional authentication) or an updated first identifier from the network side (applicable to subsequent access to the network and bidirectional authentication). Based on the second identifier, a bidirectional authentication process is performed between the terminal and the network, without using SUCI to perform a bidirectional authentication process between the terminal and the network (for example, 5G primary authentication), as in embodiment one. As another optional method, the existing SUCI structure can also be modified, and the network can be accessed based on the modified SUCI, as in embodiment two. The present application does not specifically limit which specific solution is used to encrypt the identity information of the terminal. The following describes the embodiments of the present application in detail. The terminal in the following embodiments can be the terminal itself or a chip inside the terminal. The terminal can be a mobile phone, a vehicle-mounted device, an Internet of Things device, etc. The network can be a device on the network side or a chip of a device on the network side, which is not specifically limited here. The device on the network side can include UDM, AUSF, SEAF, and / or ARPF, etc. The device on the network side can be one network element or multiple network elements, or a device equipped with multiple network elements, which is not specifically limited here. The following is explained based on different embodiments, which are as follows:

[0163] Implementation Method 1

[0164] The following is a detailed description of the technical solution of the present application with reference to a specific method embodiment in conjunction with Figure 4A. It should be noted that Figure 4A is a schematic flow chart of a method embodiment of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 4A. In addition, the various steps in Figure 4A can be performed in a different order from that presented in Figure 4A, and it is possible that not all operations in Figure 4A need to be performed. Figure 4A uses the terminal and the network side device as an example for illustration. In actual application, it may also involve interaction with other devices, which will not be explained in detail here. As shown in Figure 4A, the method is performed as follows:

[0165] Step 401: The terminal obtains a first identifier of the terminal and a first long-term key of the terminal.

[0166] Optionally, the terminal may obtain the first identifier from the configuration parameters of the SIM or USIM of the terminal. Alternatively, after the two-way authentication between the terminal and the network is successful, the device on the network side generates a new first identifier and sends it to the terminal. After the terminal stores the new first identifier, the terminal reads the first identifier from the storage location of the new first identifier (for example, SIM, USIM, or ME). Specifically, the first identifier can be understood with reference to 6) above, which will not be elaborated here. The first long-term key of the terminal can be obtained from the configuration parameters of the SIM or USIM of the terminal. Specifically, the first long-term key can be understood with reference to 5) above, which will not be elaborated here. It should be understood that the terminal can be configured with a corresponding relationship between the first identifier and the first long-term key. The network side is configured with a corresponding relationship between the first identifier and the second long-term key (the second long-term key and the first long-term key are symmetric keys).

[0167] In addition, the terminal also determines the second identifier based on the first identifier, which can be understood by referring to the above 7) and will not be repeated here.

[0168] In step 402, the terminal sends a first message, wherein the first message is used to trigger bidirectional authentication and includes a second identifier. Correspondingly, the network-side device receives the first message.

[0169] The first message can be understood as a two-way authentication request message or a registration request message. The present application does not specifically limit the message type of the first message. The first message can be sent by reusing existing message signaling or by using new message signaling, which is not specifically limited here.

[0170] Optionally, the first message further includes: second authentication data for authenticating the terminal, which facilitates the network to directly authenticate the terminal and improves the efficiency of two-way authentication. The second authentication data can be derived based on the first long-term key and the first identifier. For example, RES*=KDF(CK||IK, SN Name, L0, RAND, L1, RES, L2), where RES* is the second authentication data, KDF is the key derivation function, CK=f3(K, RAND), IK=f4(K, RAND), SN name is the service network name, L0 is the length corresponding to the service network name, RAND is the first identifier, L1 is the length of the first identifier, RES=f2(K, RAND), and L2 is the length of RES. It should be understood that the second authentication data may not be sent at the same time as the second identifier, that is, it may be sent using a different message from the second identifier, which is not specifically limited in this application. It should be understood that the second authentication data may also be generated by the terminal after step 405 is executed and when it is determined that the terminal has successfully authenticated the network.

[0171] In addition, the above-mentioned first message may also include indication information, which is used to indicate the method for determining the second identifier. Specifically, the indication information is used to indicate that the second identifier is directly determined based on the first identifier, or is determined based on the first identifier and the first long-term key, or is determined based on the first identifier, the first long-term key and the count value. For example, if the indication information is index1, it indicates that the second identifier is directly determined based on the first identifier. If the indication information is index2, it indicates that the second identifier is determined based on the first identifier and the first long-term key. If the indication information is index3, it indicates that the second identifier is determined based on the first identifier, the first long-term key and the count value. In the case where the second identifier is determined based on the first identifier, the first long-term key and the count value, the first message may also include the count value, so that the device on the network side can more quickly determine the second long-term key that is symmetrical with the first long-term key based on the count value and the second identifier.

[0172] In step 403, the network-side device determines the first identifier of the terminal and a second long-term key for authenticating the terminal in two-way authentication according to the second identifier, wherein the second long-term key and the first long-term key are symmetric keys.

[0173] Specifically, the device on the network side may store the first identifier and the second long-term key, for example, UDM storage or ARPF storage.

[0174] The device on the network side can pre-calculate based on the stored first identifier, determine the second identifier, and store the correspondence between the first identifier, the pre-calculated second identifier, and the second long-term key. It should be understood that the pre-calculation can also use parameters such as the second long-term key, which is not limited in this application. For details, please refer to the description in 7) above. After receiving the second identifier in step 402, the device on the network side can search for the pre-calculated second identifier that is the same as the received second identifier, and determine the second long-term key based on the correspondence between the pre-calculated second identifier and the second long-term key. In addition, the device on the network side can also determine the first identifier based on the correspondence between the pre-calculated second identifier and the first identifier.

[0175] Alternatively, the device on the network side stores the correspondence between the first identifier and the second long-term key. After the device on the network side (for example, UDM) receives the second identifier, it calculates the corresponding second identifier based on the first identifier stored by the device on the network side, and compares the calculated second identifier with the received second identifier to see if they are the same. If they are the same, the first identifier corresponding to the calculated second identifier and the second long-term key corresponding to the first identifier are determined. As a different implementation method, the device on the network side can calculate the corresponding second identifier for each first identifier and then compare it, or it can calculate a second identifier and then compare it, and stop calculating and comparing until the same second identifier is obtained through comparison. This application does not limit this.

[0176] In step 404, the network-side device determines first authentication data for authenticating the network in two-way authentication based on the second long-term key and the random number.

[0177] Specifically, the device on the network side can deduce the first authentication data based on the second long-term key and the random number used for two-way authentication. For example, UDM determines the first authentication data or ARPF determines the first authentication data. Among them, after the device on the network side receives the second identifier, the device on the network side determines the first identifier based on the second identifier. Afterwards, the device on the network side can generate a random number based on the first identifier. For example, directly use the first identifier as a random number; intercept part of the content in the first identifier as a random number. Alternatively, perform an encryption operation or a hash operation on the first identifier to determine the random number; perform an encryption operation or a hash operation on part of the content in the first identifier to determine the random number. Since the random number is generated based on the first identifier, the network and the terminal do not need to carry the random number during the signaling interaction of two-way authentication, which can further improve data processing efficiency and save signaling resources.

[0178] The following example describes the derivation process for the first authentication data. The network-side device determines the corresponding random number based on the first identifier and calculates the corresponding first authentication data based on the second long-term key and the random number. For example, the UDM uses the random number and the second long-term key to perform an operation to obtain the AK. It then performs an operation based on the random number, the second long-term key, the generated sequence number, and the identifier AMF to obtain the MAC: AUTN = (SQN XOR AK) || AMF || MAC, where AUTN is the first authentication data.

[0179] In the above step 404, the network side device determines the first authentication data based on the second long-term key, which can be understood by referring to step 505 in Figure 5, or step 605 in Figure 6, or step 705 in Figure 7.

[0180] In step 405, the network-side device sends first authentication data, and the terminal receives the first authentication data accordingly.

[0181] Specifically, the sending of the first authentication data by the device on the network side can be understood as multiple network elements transmitting the first authentication data to the terminal. For example, the UDM sends the first authentication data to the AUSF. Afterwards, the AUSF sends the first authentication data to the SEAF. The SEAF sends the first authentication data to the UE. The execution process of the sending of the first authentication data by the device on the network side can be understood with reference to steps 506, 508, and 509 in Figure 5 below, or with reference to steps 606, 612, and 613 in Figure 6 below, or with reference to steps 706, 709, and 710 in Figure 7 below, which will not be repeated here.

[0182] Step 406: The terminal performs authentication of the network in the two-way authentication according to the random number, the first long-term key and the first authentication data.

[0183] The random number is generated by the terminal according to the first identifier, which can be understood by referring to the network side device generating a random number according to the first identifier in step 404 above, and will not be described in detail here. The first long-term key can be obtained by referring to step 401 above.

[0184] Optionally, the terminal determines third verification data based on the first long-term key and the random number, and verifies the third verification data and the first authentication data.

[0185] Specifically, after the terminal receives the first authentication data (AUTN = (SQN XOR AK) || AMF || MAC), it performs an operation based on the first long-term key and the random number to obtain AK. Then, it performs an XOR operation on AK and the first authentication data to obtain SQN, and verifies whether SQN is within the correct range. If so, it performs an operation on SQN, AMF in the first authentication data, and the first long-term key to obtain MAC', and compares the MAC in the first authentication data with MAC' to see if they are the same. If they are the same, the terminal successfully authenticates the network. Among them, AK and MAC' can be considered as the third verification data.

[0186] In an optional implementation, after the terminal successfully authenticates the network, second authentication data for authenticating the terminal is generated and sent to the network. For example, the AUSF and / or SEAF receives the second authentication data and verifies it based on the first verification data and / or the second verification data in step 404.

[0187] Optionally, if the first message in step 402 does not include the second authentication data, then after step 406 is executed and it is determined that the terminal has successfully authenticated the network, the terminal further sends the second authentication data. After the network-side device receives the second authentication data, it may execute step 407. Optionally, if the first message in step 402 includes the second authentication data, the network-side device may execute step 407 after step 402. It should be understood that the order of steps 407 and 404 is not limited.

[0188] In step 407, the network-side device determines verification data according to the second long-term key and the random number, and performs authentication of the terminal in the two-way authentication according to the verification data, wherein the random number is determined according to the first identifier.

[0189] Specifically, the network-side device may determine the verification data based on the second long-term key and the random number, wherein the random number is as described in step 404 .

[0190] Optionally, if the first message includes the second authentication data in step 402, in an optional implementation, the network-side device determines the first verification data according to the second long-term key and the random number, and uses the first verification data to verify the second authentication data.

[0191] In another optional implementation, the other network-side device receives and stores the second authentication data. The network-side device determines the first verification data based on the second long-term key and the random number, and sends the first verification data to the other network-side device. The other network-side device verifies the received second authentication data based on the first verification data. In a specific implementation, the network-side device is a UDM, and the other network-side device is an AUSF.

[0192] Optionally, if the second authentication data is not sent in the first message of step 402, but the terminal generates the second authentication data and sends it to the device on the network side after step 406, the device on the network side determines the first verification data based on the second long-term key and the random number, and sends the first verification data to other network side devices. The other network side devices store the first verification data and use the first verification data to verify the second authentication data after receiving the second authentication data. For example, the UDM may determine the first verification data and send the first verification data to the AUSF, and the AUSF stores the first verification data so that the received second authentication data can be verified after the terminal side sends the second authentication data in step 406.

[0193] In an optional implementation, after AUSF stores the first verification data, it may also calculate the second verification data and send the second verification data to SEAF. SEAF stores the second verification data so that it can subsequently verify the received second authentication data after the terminal side sends the second authentication data in step 406.

[0194] For example, the UDM determines the first verification data XRES* based on the second long-term key and the random number, and sends the first verification data to the AUSF; the AUSF determines the second verification data HXRES* based on the first verification data XRES*.

[0195] After receiving the second authentication data, the device on the network side may perform authentication on the terminal according to the verification data and the second authentication data.

[0196] Specifically, the UDM determines first verification data XRES* based on the second long-term key and a random number, and sends the first verification data XRES* to the AUSF. The AUSF stores the first verification data XRES* and determines second verification data HXRES* based on the first verification data XRES*. The AUSF sends the second verification data HXRES* to the SEAF, which stores the second verification data HXRES*. Furthermore, the SEAF receives the second authentication data RES* from the terminal and calculates third authentication data HRES* based on the second authentication data RES*. The SEAF verifies the second verification data HXRES* against the third authentication data HRES*. If the second verification data HXRES* and the third authentication data HRES* are identical, the SEAF successfully authenticates the terminal. The SEAF sends the second authentication data RES* to the AUSF. The AUSF verifies the second authentication data RES* against the first verification data XRES*. If the second authentication data RES* and the first verification data XRES* are identical, the AUSF successfully authenticates the terminal. If the SEAF and AUSF successfully authenticate the terminal, the network is deemed to have successfully authenticated the terminal.

[0197] The above step 407 can be understood with reference to steps 512 to 514 in FIG. 5 , or with reference to step 607 in FIG. 6 , or with reference to step 707 in FIG. 7 , and will not be described in detail here.

[0198] In this application, a terminal can trigger bidirectional authentication by sending a first message carrying a second identifier to the network. This allows the network to determine a second long-term key symmetric to the terminal's first long-term key based on the second identifier and authenticate the terminal based on the second long-term key. The terminal can then generate a random number based on the first identifier and authenticate the network based on the first long-term key, first authentication data from the network, and the random number. The terminal and the network use a symmetric key for bidirectional authentication, eliminating the need for complex calculations and simplifying processing logic. This is affordable for terminals with limited capabilities.

[0199] Furthermore, during the two-way authentication process between the terminal and the network, the random number for the two-way authentication is generated based on the first identifier. The network and the terminal do not need to carry the random number during the signaling interaction for the two-way authentication, thereby further improving the efficiency of the two-way authentication and saving signaling resources.

[0200] When the terminal and the network perform two-way authentication again, the first identifier can be updated so that the second identifier in the first message is different each time the two-way authentication is performed. Even if the second identifier is stolen during a certain two-way authentication, the identity information of the terminal cannot be obtained, thereby ensuring the security of the identity information of the terminal. Referring to Figure 4B, after executing the above steps 401 to 407, the following steps are also included:

[0201] Step 408: When the terminal is successfully authenticated, the network-side device generates a third identifier, which is used to generate a message for the terminal to trigger two-way authentication again.

[0202] Specifically, the third identifier can be a random number generated by a random number generator. Alternatively, the third identifier can be composed of a random number generated by a random number generator and a proprietary identifier (for example, a PLMN identifier). Alternatively, the device on the network side (for example, UDM) maintains a resource pool of third identifiers, and each time the network successfully authenticates the terminal, a third identifier is randomly selected from the resource pool. Alternatively, the device on the network side maintains an increasing serial number with a fixed length, and each time the network successfully authenticates a terminal, the current serial number is selected as the third identifier of the terminal. The method for generating the third identifier is not specifically limited here. The above step 408 can be performed by UDM or ARPF.

[0203] Optionally, the network-side device stores a third identifier. It should be understood that the third identifier is an updated first identifier, for example, used to generate a message for the terminal to re-trigger the two-way authentication, that is, to use the third identifier as the first identifier in step 401 during the next two-way authentication. Specifically, the network-side device may replace the original first identifier with the third identifier, or the network-side device may retain the original first identifier and further store the third identifier. This is not limited.

[0204] In step 409, the device on the network side encrypts the third identifier using the communication key to obtain an encrypted ciphertext, wherein the communication key is derived based on the second long-term key.

[0205] Specifically, the communication key may be a key derived from the second long-term key, or a key derived from the first identifier and the second long-term key. The method for generating the communication key is not specifically limited herein.

[0206] The above step 409 may be performed by the UDM or ARPF. For example, the UDM generates a third identifier, and the UDM encrypts the third identifier using the communication key to obtain encrypted ciphertext. The above step 409 may also be performed by the AUSF. For example, the UDM sends the third identifier to the AUSF, the AUSF receives the third identifier, and then the AUSF encrypts the third identifier using the communication key to obtain encrypted ciphertext.

[0207] Optionally, the network device may further use the communication key to encrypt the first identifier and the third identifier to obtain an encrypted ciphertext.

[0208] In step 410, the network device sends the encrypted ciphertext, and the terminal receives the encrypted ciphertext accordingly.

[0209] The encrypted ciphertext can be transmitted to the terminal by the UDM or ARPF via the AUSF and SEAF. Optionally, the network-side device can also transmit the encrypted ciphertext using the terminal parameter update process. For example, the encrypted ciphertext can be transmitted via the UPU process. Specifically, the encrypted ciphertext is used as UPU data in the UPU process.

[0210] Optionally, the network-side device may further encrypt and transmit the third identifier using a UPU process. Specifically, the third identifier is used as UPU data in the UPU process.

[0211] In step 411, the terminal decrypts the encrypted ciphertext using the communication key to obtain the third identifier of the terminal.

[0212] After obtaining the third identifier, the terminal may store the third identifier. It should be understood that the third identifier is an updated first identifier, for example, used to generate a message for the terminal to re-trigger the two-way authentication, i.e., to use the third identifier as the first identifier in step 401 during the next two-way authentication. Specifically, the terminal may replace the original first identifier with the third identifier, or the terminal may retain the original first identifier and further store the third identifier. This is not limited.

[0213] Optionally, after decrypting the encrypted ciphertext to obtain the third identifier, the terminal may send a confirmation message to the network device indicating that the terminal has successfully received the third identifier. After receiving the confirmation message, the network device may store the third identifier.

[0214] In the present application, the terminal can update the first identifier based on the third identifier. When the terminal and the network device perform two-way authentication again, the terminal can determine a new second identifier based on the updated first identifier. Based on this, the second identifier in the first message is different each time the two-way authentication is performed. Even if the second identifier is stolen, the identity information of the terminal cannot be obtained, thereby ensuring the security of the identity information of the terminal. Therefore, the message sent by the terminal to trigger the two-way authentication may not include the permanent identity identifier of the terminal, but may include the second identifier determined based on the updated first identifier. Even if an attacker obtains the second identifier in the first message, the identity of the terminal cannot be deciphered.

[0215] In the schemes of Figures 4A and 4B above, the terminal's identity uses the first identifier instead of the SUPI in the existing process for bidirectional authentication. It should be understood that while SUPI is not used for bidirectional authentication in this embodiment, it can still be retained. After bidirectional authentication is complete, the network device still uses SUPI internally as the user's identity in the process, allowing the network device to track user logs and other information. Specifically, the network device can determine the SUPI based on the first identifier or the second identifier and then use the SUPI. For example, in the aforementioned UPU process, SUPI can still be used instead of the first identifier as the terminal's identity.

[0216] The following processing flow with reference to Figures 5 to 7 will expand on the solution of the present application. The following figures take two-way authentication as an example for explanation, but it is not limited to two-way authentication as the main authentication, and other authentications can also be used. The following takes the data interaction between UE, SEAF, AUSF and UDM as an example for explanation, wherein UDM can also be ARPF. Some network elements may be jointly set up, such as SEAF and AUSF, or SEAF, AUSF and UDM are jointly set up, which is not specifically limited here. Before the execution of the process in Figures 5 to 7 below, both UE and UDM can pre-configure a long-term key and a first identifier. Specifically, the UE pre-configures a first long-term key and a first identifier. The UDM pre-configures a second long-term key and a first identifier.

[0217] Referring to Figure 5, the execution is as follows:

[0218] Step 501: The UE obtains a first identifier of the UE and a first long-term key of the UE, and determines a second identifier according to the first identifier.

[0219] Specifically, the first identifier can be obtained with reference to step 401 in FIG. 4A . In an optional implementation, the UE obtains the first long-term key from the USIM and the first identifier from the ME. This application does not specifically limit the method for obtaining the first identifier and the first long-term key. The characteristics of the first identifier can be understood with reference to step 6) above and are not further described here.

[0220] The method for determining the second identifier can be understood by referring to 7), which will not be elaborated here.

[0221] Step 502: The UE sends a second identifier to the SEAF. Correspondingly, the SEAF receives the second identifier.

[0222] Specifically, the second identifier may be carried in the first message, which may be a registration request message or an identity response message. That is, the second identifier may be carried in the registration request message initiated by the UE, or the second identifier may be carried in the identity response message sent by the UE after the network initiates the identity request.

[0223] The first message may also carry a count value, for example, when a count value is introduced when determining the second identifier. In addition, the first message may also carry an indication of a two-way authentication method, such as the above-mentioned 5G-AKA, EAP-AKA, or EAP-TLS.

[0224] Step 503: SEAF sends a second identifier to AUSF. Correspondingly, AUSF receives the second identifier.

[0225] Step 504: SEAF sends the second identifier to UDM. Correspondingly, UDM receives the second identifier.

[0226] It should be understood that the second identifier can be transmitted between devices on the network side through different messages.

[0227] For example, after receiving the first message, SEAF sends an authentication request message to AUSF, and after receiving the authentication request message, AUSF sends an authentication vector acquisition request message to UDM / ARPF. The authentication request message and the authentication vector acquisition request message carry the parameters introduced in 502 above.

[0228] In step 505, the UDM determines the first identifier of the terminal and the second long-term key for authenticating the UE in the two-way authentication based on the second identifier, and determines the first authentication data used to authenticate the network in the two-way authentication based on the second long-term key and the random number, wherein the random number is generated based on the first identifier, and the second long-term key and the first long-term key of the UE are symmetric keys.

[0229] Specifically, after receiving the second identifier, the UDM determines the second long-term key and the first identifier, which can be understood by referring to the description of step 403 in Figure 4A above and will not be repeated here. In addition, the method of generating the random number can also be understood by referring to step 403 in Figure 4A above.

[0230] The UDM may determine the first authentication data AUTN according to the second long-term key and the random number. It should be understood that the operation of the UDM in this application may also be performed by the ARPF. For ease of description, the UDM is used as an example in the following.

[0231] Optionally, the UDM also determines the first verification data XRES* based on the second long-term key and the random number.

[0232] For example, UDM calculates CK and IK based on the second long-term key and the random number, where CK=f3(K, RAND)IK=f4(K, RAND), where f3 and f4 are encryption functions, K is the second long-term key, and RAND is a random number. Then, UDM further deduces the first authentication data AUTN and the first verification data (XRES*) based on CK and IK. XRES* can be used by AUSF for network authentication of the terminal. XRES can be determined by encryption calculation of the second long-term key and the random number, for example, XRES=f2(K, RAND), where f2 is an encryption function, K is the second long-term key, and RAND is a random number. XRES* is determined by encryption calculation of CK, IK, random number, and service network name. For example, XRES*=KDF(CK||IK, SN Name, L0, RAND, L1, XRES, L2), where KDF is a key derivation function, SN name is the service network name, L0 is the length corresponding to the service network name, RAND is a random number, L1 is the length of the random number, and L2 is the length of XRES. AUTN can be determined by encrypting the random number and the authentication management field AMF. For example, AUTN=SQN xor AK||AMF||MAC, where xor is exclusive OR, SQN is the sequence number maintained by the UE and UDM, MAC=f1(SQN||RAND||AMF), AK=f5(RAND). The above f1, f2, f3, f4, and f5 are only examples, and the encryption function is not specifically limited here. Optionally, if the random number determined based on the first identifier is the same as the first identifier, the random number used in the above determination of the first authentication data and the first verification data can also be replaced by the first identifier.

[0233] Optionally, during key derivation, KID is also used as input, that is, CK=f3(K, RAND, KID), IK=f4(K, RAND, KID), where KID is the second identifier.

[0234] It should be understood that the execution order of the determination action of the UDM in this application is not limited, for example, the first verification data XRES* may be determined first and then the first authentication data may be determined, which is not limited in this application. Other embodiments are similar.

[0235] In step 506, the UDM sends the first authentication data to the AUSF. Optionally, in step 506, the UDM also sends the first verification data to the AUSF. Accordingly, the AUSF receives the first authentication data and the first verification data.

[0236] Specifically, the first authentication data and / or the first verification data are transmitted via an authentication vector acquisition response message.

[0237] Step 507: AUSF stores the first verification data.

[0238] Optionally, the AUSF stores the first verification data. Thus, in step 514, the UE can be authenticated based on the first verification data. A key is deduced based on the first verification data to obtain the second verification data. For example, the AUSF deduces the first verification data XRES* to obtain the second verification data HXRES*. This can be understood by referring to the 5G primary authentication, which will not be described here.

[0239] Step 508: AUSF sends first authentication data to SEAF.

[0240] Optionally, the AUSF also sends second verification data to the SEAF. Accordingly, the SEAF receives the first authentication data and the second verification data and stores the second verification data. Thus, the SEAF can perform verification based on the second verification data in step 512.

[0241] Specifically, the second verification data and / or the first authentication data are transmitted through an authentication response message.

[0242] Step 509: SEAF sends first authentication data to UE. Correspondingly, UE receives the first authentication data.

[0243] This step 509 can be sent via a NAS message. Specifically, it can be an authentication request message. To distinguish the authentication request message in step 503, the authentication request message in step 509 can be referred to as a second authentication request message, and the authentication request message in step 503 can be referred to as a first authentication request message.

[0244] In step 510, the UE performs authentication of the network in a two-way authentication according to the random number, the first long-term key, and the first authentication data.

[0245] If the terminal successfully authenticates the network, second authentication data is generated based on the first long-term key and the random number.

[0246] It should be noted that the UE includes two parts, the ME and the USIM. The ME can receive the first authentication data, and the USIM can calculate the second authentication data. Specifically, the ME can forward the first authentication data received in the NAS message to the USIM.

[0247] The UE performs authentication of the network in the bidirectional authentication based on the random number, the first long-term key and the first authentication data. This can be understood by referring to the description of step 406 above and will not be repeated here.

[0248] If the terminal successfully authenticates the network, the second authentication data is generated based on the first long-term key and the random number. For example, RES*=KDF(CK||IK, SN Name, L0, RAND, L1, RES, L2), where RES* is the second authentication data, KDF is the key derivation function, CK=f3(K, RAND), IK=f4(K, RAND), SN name is the service network name, L0 is the length corresponding to the service network name, RAND is a random number, L1 is the length of the random number, RES=f2(K, RAND), and L2 is the length of RES. The above f2, f3, and f4 are only examples, and the encryption function is not specifically limited here. Optionally, if the random number determined based on the first identifier is the same as the first identifier, the random number used in the above determination of the first authentication data and verification data can also be replaced by the first identifier.

[0249] Optionally, during key derivation, KID is also used as input, that is, CK=f3(K, RAND, KID), IK=f4(K, RAND, KID), where KID is the second identifier.

[0250] Step 511: The UE sends second authentication data to the SEAF. Correspondingly, the SEAF receives the second authentication data.

[0251] Specifically, the second authentication data may be carried in an authentication response message.

[0252] Step 512: SEAF performs authentication based on the second authentication data.

[0253] Specifically, SEAF calculates third authentication data HRES* based on the second authentication data and verifies the third authentication data HRES* with the second verification data HXRES*. The specific calculation and verification methods can be understood with reference to 5G primary authentication and are not described here. If the third authentication data HRES* and the second verification data HXRES* are the same, authentication is successful. Specifically, this indicates that the UE has permission to access the visited network. It should be understood that the network-side authentication of the UE may specifically include the authentication in step 512 and / or the authentication in step 514.

[0254] In step 513, SEAF sends the second authentication data to AUSF, and AUSF receives the second authentication data accordingly.

[0255] Specifically, the second authentication data may be carried in an authentication request message and transmitted. For the sake of distinction, the authentication request message may be referred to as a third authentication request message.

[0256] Step 514, AUSF performs authentication based on the second authentication data.

[0257] Specifically, the AUSF performs verification based on the second authentication data RES* and the first verification data XRES*. If RES* and XRES* are the same, the UE is deemed to have been successfully authenticated. Specifically, this indicates that the UE has permission to access the home network.

[0258] In step 515a, AUSF sends the authentication result to SEAF, and SEAF receives the authentication result accordingly.

[0259] In step 515b, the AUSF sends the authentication result to the UDM, and the UDM receives the authentication result accordingly.

[0260] The execution order of step 515a and step 515b is not specifically limited here. If the AUSF believes that the UE has the authority to access the home network, the authentication result is authentication success. If the AUSF believes that the UE does not have the authority to access the home network, the authentication result is authentication failure.

[0261] Furthermore, the network side can also update the first identifier. The steps are as follows:

[0262] Step 516: If the authentication result received by the UDM is successful, a third identifier is generated for the UE.

[0263] Optionally, the UDM can also encrypt the third identifier to generate encrypted ciphertext. For example, if the third identifier is RAND', the UDM can encrypt RAND' to generate encrypted ciphertext. This can be understood by referring to steps 408 and 409 in Figure 4B above and will not be further described here.

[0264] Step 517: The UDM sends the encrypted ciphertext or the third identifier to the UE through the UPU process.

[0265] For example, the encrypted ciphertext is transmitted through the UPU process. Specifically, the encrypted ciphertext is used as the UPU data in the UPU process.

[0266] Optionally, the UDM may also use the UPU process to encrypt and transmit the third identifier. Specifically, the third identifier is used as UPU data in the UPU process. FIG5 illustrates step 517 in which the UDM sends encrypted ciphertext to the UE through the UPU process.

[0267] In step 518a, the UE decrypts the encrypted ciphertext to obtain the third identifier, or directly decrypts to obtain the third identifier.

[0268] Optionally, the UE stores a third identifier. It should be understood that the third identifier is an updated first identifier, for example, used to generate a message for the terminal to re-trigger the two-way authentication, that is, to use the third identifier as the first identifier in step 501 during the next two-way authentication. Specifically, the UE may replace the original first identifier with the third identifier, or the UE may retain the original first identifier and further store the third identifier. This is not limited.

[0269] Optionally, after obtaining the third identifier, the UE sends a confirmation message to the UDM indicating that the UE successfully receives the third identifier, so as to trigger the execution of step 518b.

[0270] In step 518b, the UDM stores the third identifier.

[0271] Specifically, the UDM may update the first identifier to the third identifier, as shown in step 518a. In addition, the UDM may also pre-calculate a new second identifier based on the third identifier.

[0272] The execution order of step 518a and step 518b is not specifically limited here.

[0273] While this method uses symmetric cryptography to protect user privacy, the first identifier replaces the random number in the primary authentication process, saving overhead. Furthermore, in quantum-resistant scenarios, the use of a 256-bit symmetric cryptographic algorithm can achieve beneficial quantum-resistant effects, reducing the computational and transmission costs introduced by post-quantum cryptography.

[0274] Referring to Figure 6, the execution is as follows:

[0275] In step 601, the UE obtains its first identifier and its first long-term key, and determines its second identifier based on the first identifier. The UE also generates second authentication data based on the first long-term key and a random number. The random number is generated based on the first identifier. The acquisition of the first identifier and the first long-term key, as well as the determination of the second identifier, can be understood with reference to step 501 in Figure 5 above and will not be further described here.

[0276] The generation of the second authentication data can be understood by referring to step 510 in FIG. 5 , which will not be described in detail here.

[0277] Step 602: The UE sends a second identifier and second authentication data to the SEAF. Correspondingly, the SEAF receives the second identifier and second authentication data.

[0278] Specifically, the second identifier and the second authentication data may be carried in the first message, which may be a registration request message or an identity response message. That is, the second identifier and the second authentication data may be carried in a registration request message initiated by the UE, or the second identifier and the second authentication data may be carried in an identity response message sent by the UE after the network initiates an identity request.

[0279] The first message may also carry a count value, for example, when a count value is introduced when determining the second identifier. In addition, the first message may also carry an indication of a two-way authentication method, such as the above-mentioned 5G-AKA, EAP-AKA, or EAP-TLS.

[0280] The second authentication data may be determined with reference to step 510 in FIG. 5 , and is not specifically limited here.

[0281] Step 603: SEAF forwards the second identifier and the second authentication data to AUSF. Correspondingly, AUSF receives the second identifier and the second authentication data.

[0282] Step 604: AUSF forwards the second identifier to the UDM. Correspondingly, the UDM receives the second identifier.

[0283] Optionally, the AUSF stores second authentication data.

[0284] Optionally, the AUSF further forwards the second authentication data to the UDM. Accordingly, the UDM receives the second authentication data.

[0285] It should be understood that the second identifier can be transmitted between devices on the network side through different messages, and the second authentication data and the second identifier can be carried in the same message.

[0286] For example, after receiving the first message, SEAF sends an authentication request message to AUSF, and after receiving the authentication request message, AUSF sends an authentication vector acquisition request message to UDM. The authentication request message and the authentication vector acquisition request message carry the parameters introduced in step 602 above.

[0287] In step 605, the UDM determines the first identifier of the terminal and the second long-term key for authenticating the UE in the two-way authentication based on the second identifier, and determines the first authentication data for authenticating the network in the two-way authentication based on the second long-term key and the random number, wherein the random number is generated based on the first identifier, and the second long-term key and the first long-term key of the UE are symmetric keys.

[0288] The first authentication data may be determined by referring to step 505 in FIG5 , which will not be described in detail herein. In addition, the first verification data may also be determined by referring to step 505 in FIG5 .

[0289] In step 606, the UDM sends the first authentication data to the AUSF, and the AUSF receives the first authentication data accordingly.

[0290] Optionally, if the AUSF stores the second authentication data in step 604, the UDM further sends the first verification data to the AUSF in step 606. Accordingly, the AUSF receives the first verification data.

[0291] Specifically, the first authentication data and / or the first verification data may be transmitted via an authentication vector acquisition response message.

[0292] Step 607: UDM / AUSF authenticates the second authentication data.

[0293] Step 607 in FIG6 is illustrated by taking the authentication of the second authentication data by the AUSF as an example.

[0294] If the AUSF forwards the second authentication data to the UDM in step 604, the UDM may use the first verification data to verify the second authentication data to thereby authenticate the terminal.

[0295] If the AUSF does not forward the second authentication data to the UDM in step 604, the AUSF verifies the second authentication data received in step 603 and stored in step 604 based on the first verification data received in step 606, thereby authenticating the terminal. That is, the AUSF stores the second authentication data in step 604.

[0296] Specifically, the UDM / AUSF performs authentication based on the second authentication data RES* and the first verification data XRES*. If RES* and XRES* are the same, it is considered that the UE is successfully authenticated.

[0297] It should be noted that the above step 607 can occur after the first verification data is determined in step 605 on the UDM side, or after the first verification data is received in step 606 on the AUSF side, and is not limited here.

[0298] Step 608: UDM obtains the authentication result.

[0299] In one optional implementation, the UDM verifies the second authentication data according to step 607 to obtain an authentication result. In another optional implementation, the AUSF verifies the second authentication data according to step 607 to obtain an authentication result, and sends the authentication result to the UDM, thereby obtaining the authentication result. In Figure 6, step 608 is described using the example of the AUSF sending the authentication result to the UDM.

[0300] Furthermore, the network side can also update the first identifier. The steps are as follows:

[0301] Step 609: If the authentication result received by the UDM is successful, a third identifier is generated for the UE.

[0302] Optionally, the UDM can also encrypt the third identifier to generate encrypted ciphertext. For example, if the third identifier is RAND', the UDM can encrypt RAND' to generate encrypted ciphertext. This can be understood by referring to steps 408 and 409 in Figure 4B or step 516 in Figure 5, and will not be further described here.

[0303] Step 610: UDM sends a third identifier or encrypted ciphertext to AUSF.

[0304] In FIG6 , step 610 is taken as an example in which the UDM sends the third identifier to the AUSF.

[0305] In step 611, AUSF encrypts the third identifier to generate an encrypted ciphertext.

[0306] Optionally, UDM may also encrypt the third identifier to generate encrypted ciphertext, and send the encrypted ciphertext to AUSF.

[0307] If in the above step 609, the UDM generates a third identifier and encrypts the third identifier to generate an encrypted ciphertext, then the above step 610 is for the UDM to send the encrypted ciphertext to the AUSF, and the above step 611 may not be executed.

[0308] In step 612, AUSF sends the encrypted ciphertext and the first authentication data to SEAF. Correspondingly, SEAF receives the encrypted ciphertext and the first authentication data.

[0309] Specifically, the encrypted ciphertext and / or the first authentication data are transmitted through an authentication response message.

[0310] It should be understood that the first authentication data and the encrypted ciphertext can be sent through the same message; or they can be sent through different messages, for example, after step 607, AUSF sends the first authentication data and after step 610 or 611, AUSF sends the first encrypted ciphertext.

[0311] In step 613, SEAF sends the encrypted ciphertext and the first authentication data to the UE. Correspondingly, the UE receives the encrypted ciphertext and the first authentication data.

[0312] This step 613 can be sent via a NAS message. Specifically, it can be an authentication request message. To distinguish the authentication request message in step 603, the authentication request message in step 613 can be referred to as a second authentication request message, and the authentication request message in step 603 can be referred to as a first authentication request message.

[0313] Similar to the description of step 612, the first authentication data and the encrypted ciphertext can be sent through the same message; or they can be sent through different messages.

[0314] In step 614, the UE performs authentication of the network in the two-way authentication according to the random number, the first long-term key, and the first authentication data.

[0315] The specific authentication can be understood by referring to step 510 in FIG. 5 , which will not be described in detail here.

[0316] If the terminal successfully authenticates the network, it decrypts the encrypted ciphertext to obtain a third identifier and stores the third identifier. It should be understood that this third identifier is an updated first identifier, for example, used to generate a message for the terminal to re-trigger the two-way authentication, i.e., the third identifier is used as the first identifier in step 601 during the next two-way authentication. Specifically, the UE may replace the original first identifier with the third identifier, or the UE may retain the original first identifier and further store the third identifier. This is not limited.

[0317] Step 615: The UE sends a message indicating that the network authentication is successful to the UDM via the SEAF and AUSF. Correspondingly, the UDM receives the message indicating that the UE has successfully authenticated the network.

[0318] It should be understood that step 609 can also be performed after step 615, that is, UDM generates a third identifier (the encrypted ciphertext is similar and will not be repeated here) and sends the third identifier when it determines that both bidirectional authentications are successful.

[0319] Alternatively, the UDM may generate the third identifier first and then send the third identifier after step 615. That is, the UDM sends the third identifier when it determines that both bidirectional authentications are successful.

[0320] Step 616: The UDM stores the third identifier.

[0321] Specifically, the UDM may update the first identifier to the third identifier, as shown in step 518a. In addition, the UDM may also pre-calculate a new second identifier based on the third identifier.

[0322] While using a symmetric cryptographic mechanism to protect user privacy, this method combines the transmission of the terminal's identity (i.e., the first identifier), primary authentication, and the transmission of a new terminal identity (i.e., the third identifier), thereby reducing transmission costs. Furthermore, in quantum-resistant scenarios, the use of a 256-bit symmetric cryptographic algorithm can achieve the beneficial effect of quantum-resistant attacks and reduce the computational and transmission costs introduced by post-quantum cryptographic algorithms. Furthermore, this process sends the second identifier together with the second authentication data used to authenticate the terminal, saving signaling overhead and improving data processing efficiency.

[0323] Referring to Figure 7, the execution is as follows:

[0324] Steps 701 to 708 are the same as the execution process of steps 601 to 608 in FIG. 6 , which can be understood by reference and will not be described in detail here.

[0325] In step 709, the AUSF sends the first authentication data to the SEAF, and the SEAF receives the first authentication data accordingly.

[0326] Specifically, the first authentication data is delivered via an authentication vector acquisition response message.

[0327] In step 710, SEAF sends first authentication data to UE. Correspondingly, UE receives the first authentication data.

[0328] This step 710 can be sent via a NAS message. Specifically, it can be an authentication request message. To distinguish the authentication request message in step 703, the authentication request message in step 710 can be referred to as a second authentication request message, and the authentication request message in step 703 can be referred to as a first authentication request message.

[0329] Step 711: The UE performs authentication of the network in a two-way authentication according to the random number, the first long-term key, and the first authentication data.

[0330] This can be understood by referring to step 510 in FIG. 5 , and will not be described in detail here.

[0331] Step 712: The UE sends a message indicating that the network authentication is successful to the UDM via the SEAF and AUSF. Correspondingly, the UDM receives the message indicating that the UE has successfully authenticated the network.

[0332] Step 713: If the authentication result received by the UDM is successful, a third identifier is generated for the UE.

[0333] Optionally, the UDM may further encrypt the third identifier to obtain an encrypted ciphertext. For example, if the third identifier is RAND', the UDM may encrypt RAND' to generate an encrypted ciphertext.

[0334] The process of generating the third identifier and encrypting the third identifier can be understood by referring to steps 408 and 409 in FIG. 4B , or step 516 in FIG. 5 , or step 609 in FIG. 6 , and will not be described in detail here.

[0335] Step 714: The UDM sends the third identifier or encrypted ciphertext to the UE through the UPU process.

[0336] This can be understood by referring to step 517 in Figure 5 above, which will not be described in detail here. In Figure 7, step 714 is used as an example to illustrate that the UDM sends encrypted ciphertext to the UE through the UPU process.

[0337] In step 715a, the UE decrypts the encrypted ciphertext to obtain the third identifier, or directly decrypts to obtain the third identifier.

[0338] Optionally, the UE stores a third identifier. It should be understood that the third identifier is an updated first identifier, for example, used to generate a message for the terminal to re-trigger the two-way authentication, that is, to use the third identifier as the first identifier in step 701 during the next two-way authentication. Specifically, the UE may replace the original first identifier with the third identifier, or the UE may retain the original first identifier and further store the third identifier. This is not limited.

[0339] Optionally, after obtaining the third identifier, the UE sends a confirmation message to the UDM indicating that the UE successfully receives the third identifier, so as to trigger the execution of step 715b.

[0340] In step 715b, the UDM stores the third identifier.

[0341] Specifically, the UDM may update the first identifier to the third identifier, as shown in step 715a. In addition, the UDM may also pre-calculate a new second identifier based on the third identifier.

[0342] The execution order of step 715a and step 715b is not specifically limited here.

[0343] While using a symmetric cryptographic mechanism to protect user privacy, this method combines the transmission process of the terminal identity (i.e., the first identifier), the main authentication, and the new terminal identity (i.e., the third identifier), thereby saving transmission consumption. In addition, in the scenario of anti-quantum attack, the use of a 256-bit symmetric cryptographic algorithm can achieve the beneficial effect of anti-quantum attack and reduce the computational and transmission consumption introduced by the post-quantum cryptographic algorithm. In addition, this process sends the second identifier together with the second authentication data used to authenticate the terminal, which can save signaling overhead and improve data processing efficiency. In addition, compared with the solution of Figure 6, the solution of Figure 7 has smaller changes and is more adapted to the needs of the current communication system.

[0344] Implementation Method 2:

[0345] The technical solution of the present application is described in detail below with reference to a specific method embodiment in conjunction with Figure 8A. It should be noted that Figure 8A is a schematic flow chart of a method embodiment of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 8A. In addition, the various steps in Figure 8A can be performed in a different order from that presented in Figure 8A, and it is possible that not all operations in Figure 8A need to be performed. Figure 8A uses the terminal and the network-side devices as an example for illustration. In actual application, it may also involve interaction with other devices, which will not be explained in detail here. As shown in Figure 8A, the method is performed as follows:

[0346] Step 801: A terminal obtains a first key identifier of the terminal, where the first key identifier indicates a first long-term key of the terminal.

[0347] Optionally, the terminal may obtain the first key identifier from the configuration parameters of the SIM or USIM of the terminal. Alternatively, after the terminal's identity authentication is successful, the network-side device generates a new first key identifier and sends it to the terminal. After the terminal stores the new first key identifier, the terminal reads the first key identifier from the storage location of the new first key identifier (e.g., SIM, USIM, or ME).

[0348] In an optional implementation manner, the first key identifier is obtained from the ME, and the first long-term key is obtained from the USIM or SIM.

[0349] In another optional implementation, the first long-term key and the first key identifier are obtained from the USIM or SIM. The first key identifier may be a temporary key identifier generated by the network after successful terminal authentication and sent to the UE, and the first key identifier is not specifically limited here.

[0350] In addition, the terminal also obtains a first subscription permanent identifier pre-configured in the terminal. Specifically, the terminal may obtain the first subscription permanent identifier from a SIM or a USIM.

[0351] Optionally, the terminal may pre-configure multiple first key identifiers, such as a first key identifier resource pool. In one optional implementation, each first key identifier is used only for one identity authentication, so that the first key identifier for each of the multiple identity authentications is different. For example, each time the terminal authenticates with the network, a first key identifier is selected from the first key identifier resource pool as the first key identifier for identity authentication, and the selected first key identifier is deleted from the first key identifier resource pool.

[0352] In another optional implementation, after a first key identifier is selected from a resource pool of first key identifiers as a first key identifier used for identity authentication, the selected first key identifier is not deleted.

[0353] Step 802: The terminal generates a communication key based on the first key identifier and the first long-term key.

[0354] Specifically, the terminal may use the first long-term key to perform an encryption operation on the first key identifier to obtain a communication key. For example, the communication key is a symmetric key used to encrypt and protect the SUPI, where EK||MK=KDF(K, KID, SN Name), where EK||MK is the communication key, K is the first long-term key, KID is also the first key identifier, SN Name is the serving network name, and KDF is a key derivation function.

[0355] Step 803: The terminal determines an identity hiding identifier, where the identity hiding identifier includes a first encrypted ciphertext and a first key identifier. The first encrypted ciphertext is obtained by encrypting the first subscription permanent identifier of the terminal using the communication key.

[0356] The identity hiding identifier may be understood as SUCI, and the first subscription permanent identifier may be understood as SUPI, which are not specifically limited herein.

[0357] Specifically, if the first key identifier is KID, the structure of the SUCI in this application is shown in Figure 9 , which is equivalent to replacing the Home Network Public Key ID in the existing SUCI with KID. The SUPI is encrypted using the communication key EK to generate a first encrypted ciphertext C. The ciphertext generated by SUPI encryption is integrity-protected using the communication key MK to generate a message authentication code (MAC tag value). The scheme-out portion of the SUCI is the concatenation of the first encrypted ciphertext C and the message authentication code (MAC tag value), i.e., C||MAC tag value.

[0358] Since a symmetric mechanism is used, the scheme out part of SUCI does not need to transmit a temporary public key. Instead, only the encrypted first ciphertext and the message authentication code MAC tag value can be sent.

[0359] In step 804, the terminal sends an identity concealing identifier, and the network device receives the identity concealing identifier accordingly.

[0360] The above step 804 may be sent via a registration request or an identity authentication request, which is not specifically limited here.

[0361] Step 805: The network-side device determines a second long-term key and a pre-configured second subscription permanent identifier of the terminal according to the first key identifier. The second long-term key and the first long-term key of the terminal are symmetric keys.

[0362] Specifically, the network-side device obtains the first key identifier from the received identity hiding identifier based on the data structure of the identity hiding identifier. For example, the first key identifier KID is obtained from the location where the KID is stored in the SUCI. The network-side device (e.g., UDM or ARPF) may preconfigure a correspondence between the first key identifier, the second long-term key, and the preconfigured second subscription permanent identifier of the terminal. After receiving the first key identifier, the network-side device may retrieve the second long-term key and the preconfigured second subscription permanent identifier based on the first key identifier.

[0363] In step 806, the network-side device determines a communication key based on the second long-term key, and uses the communication key to decrypt the first encrypted ciphertext to obtain the first subscription permanent identifier of the terminal.

[0364] The method for determining the communication key in the above step 806 can be understood by referring to step 802 and will not be repeated here.

[0365] Specifically, after the network-side device determines the communication key CK||MK, the network-side device can obtain the first encrypted ciphertext C and the message authentication code MAC tag value from the received identity hiding identifier based on the data structure of the identity hiding identifier. First, the message authentication code MAC tag value is verified using the communication key MK and the first encrypted ciphertext. If the verification passes, the first encrypted ciphertext C is decrypted using the communication key CK to obtain the first subscription permanent identifier of the terminal. The verification of the MAC tag value can be performed as follows: using the communication key MK to perform a MAC calculation on the first encrypted ciphertext C to obtain the message authentication code MAC tag value2, and comparing MAC tag value2 with the MAC tag value to see if they are the same. If they are the same, the verification passes; otherwise, the verification fails.

[0366] Step 807: The network-side device authenticates the terminal according to the first subscription permanent identifier and the second subscription permanent identifier.

[0367] Both the above steps 806 and 807 can be executed by UDM or ARPF.

[0368] Specifically, if the first subscription permanent identifier and the second subscription permanent identifier are the same, the terminal authentication is successful; if they are not the same, the terminal authentication fails. Specifically, the network side device can deduce the communication keys EK and MK based on the first key identifier, the service network, etc., and use MK to perform integrity verification on the MAC tag value of the schemeout part. If the MAC tag value verification passes, the first encrypted ciphertext is decrypted using EK to obtain the decoded SUPI (that is, the first subscription permanent identifier). The network side device compares the decrypted SUPI with the pre-configured SUPI retrieved by the first key identifier in the above step 805 to see if they are consistent; if they are consistent, the network side device considers that the terminal identity authentication is successful.

[0369] In this application, the terminal generates a communication key based on a first key identifier and a first long-term key, and encrypts a first subscription permanent identifier preconfigured in the terminal based on the communication key to obtain a first encrypted ciphertext. The first encrypted ciphertext and the first key identifier are then sent to the network as the content of the identity hiding identifier, so that the network can determine the second long-term key and verify the first subscription permanent identifier. In this method, the terminal and the network use symmetric (identical) communication keys for encryption and decryption, which can reduce the data processing complexity of the subscription permanent identifier encryption.

[0370] After the network successfully authenticates the terminal, the first key identifier can be updated to ensure that the first key identifier in the SUCI is different during terminal authentication. Even if the first key identifier is stolen during a terminal authentication, the terminal's identity cannot be obtained, thereby ensuring the security of the terminal's identity information. Referring to FIG. 8B , after executing steps 801 to 807, the following steps are also included:

[0371] Step 808: When the network-side device successfully authenticates the terminal, it generates a second key identifier, which is used to generate an identity hiding identifier for the terminal to access the network again.

[0372] Specifically, the second key identifier can be a random number generated by a random number generator. Alternatively, the second key identifier can be composed of a random number generated by a random number generator and a proprietary identifier (for example, a PLMN identifier). Alternatively, the device on the network side (for example, UDM) maintains a resource pool of second key identifiers, and each time the network successfully authenticates the terminal, a second key identifier is randomly selected from the resource pool. Alternatively, the device on the network side maintains an increasing serial number with a fixed length, and each time the network successfully authenticates a terminal, the current serial number is selected as the second key identifier of the terminal. The method for generating the second key identifier is not specifically limited here. The above step 808 can be performed by UDM or ARPF.

[0373] Optionally, the device on the network side stores a second key identifier. It should be understood that the second key identifier is an updated first key identifier, for example, used to generate an identity hiding identifier for the terminal to access the network again, that is, the second key identifier is used as the first key identifier in step 801 the next time the terminal accesses the network. Specifically, the UDM can replace the original first key identifier with the second key identifier, or the UDM can retain the original first key identifier and further store the second key identifier. No limitation is made.

[0374] In step 809 , the network-side device encrypts the second key identifier using the communication key to obtain a second encrypted ciphertext.

[0375] If the terminal passes the identity authentication, a second key identifier is generated for the terminal. The UDM or ARPF can use the EK to encrypt the second key identifier to obtain a second encrypted ciphertext.

[0376] In step 810, the network-side device sends a second encrypted ciphertext.

[0377] The second encrypted ciphertext in step 810 can be transmitted to the terminal by the UDM or ARPF via the AUSF and SEAF. Optionally, the network-side device can also transmit the encrypted ciphertext using a terminal parameter update process. For example, the encrypted ciphertext can be transmitted via the UPU process. Specifically, the second encrypted ciphertext is used as UPU data in the UPU process.

[0378] Optionally, the network-side device may further encrypt and transmit the second key identifier using a UPU process. Specifically, the second key identifier is used as UPU data in the UPU process.

[0379] In step 811, the terminal decrypts the second encrypted ciphertext using the communication key to obtain the second key identifier of the terminal.

[0380] Accordingly, the terminal may store a second key identifier. It should be understood that the second key identifier is an updated first key identifier, for example, used to generate an identity-hiding identifier for the terminal to re-access the network. That is, the second key identifier is used as the first key identifier in step 801 the next time the terminal accesses the network. Specifically, the terminal may replace the original first key identifier with the second key identifier, or the terminal may retain the original first key identifier and further store the second key identifier. This is not limited.

[0381] Optionally, after decrypting the second encrypted ciphertext to obtain the second key identifier, the terminal may send a confirmation message to the network device indicating that the terminal has successfully received the second key identifier. After receiving the confirmation message, the network device may store the second key identifier.

[0382] In this application, the terminal can update the first key identifier based on the second key identifier. When the terminal accesses the network again, it can determine the communication key based on the second key identifier and the first long-term key, and encrypt the first subscription permanent identifier based on the communication key. The communication key is different from the communication key determined based on the first key identifier and the first long-term key. Based on this, each time the terminal accesses the network, the first encrypted ciphertext encrypted with the communication key in the identity hiding identifier is different. Even if the identity hiding identifier is stolen, the user's identity information cannot be decrypted, thereby ensuring the security of the user's identity information.

[0383] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of device interaction. It is understandable that, in order to implement the above functions, each device may include a hardware structure and / or software module that performs each function. Those skilled in the art should easily appreciate that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0384] In the embodiments of the present application, the functional units of the device can be divided according to the above method examples. For example, each functional unit can be divided according to each function, or two or more functions can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or software functional units.

[0385] In the case of adopting an integrated unit, Figure 10 shows a possible exemplary block diagram of the communication device involved in the embodiments of the present application. As shown in Figure 10, the communication device 1000 may include: a processing unit 1001 and a transceiver unit 1002. The processing unit 1001 is used to control and manage the actions of the communication device 1000. The transceiver unit 1002 is used to support communication between the communication device 1000 and other devices. Optionally, the transceiver unit 1002 may include a receiving unit and / or a sending unit, which are used to perform receiving and sending operations respectively. Optionally, the communication device 1000 may also include a storage unit for storing program code and / or data of the communication device 1000. The transceiver unit may be referred to as an input / output unit, a communication unit, etc., and the transceiver unit may be a transceiver; the processing unit may be a processor. When the communication device is a module (such as a chip) in a communication device, the transceiver unit may be an input / output interface, an input / output circuit, or an input / output pin, etc., and may also be referred to as an interface, a communication interface, or an interface circuit, etc.; the processing unit may be a processor, a processing circuit, or a logic circuit, etc. Specifically, the device may be the aforementioned terminal, network side equipment such as SEAF, AUSF, and UDM, etc. The specific execution process may refer to the description of the aforementioned method embodiment and will not be elaborated here.

[0386] In one embodiment, the communication device 1000 is a terminal, and the processing unit 1001 is used to obtain a first identifier of the terminal and a first long-term key of the terminal; the transceiver unit 1002 is used to send a first message, wherein the first message is used to trigger two-way authentication, the first message includes a second identifier, and the second identifier is used to determine a second long-term key for authenticating the terminal in the two-way authentication, the second identifier is determined based on the first identifier, and the second long-term key and the first long-term key are symmetric keys; the transceiver unit 1002 is also used to receive first authentication data; the processing unit 1001 is also used to perform authentication of the network in the two-way authentication based on a random number, the first long-term key and the first authentication data, wherein the random number is generated based on the first identifier.

[0387] In an optional manner, the transceiver unit 1002 is also used to receive encrypted ciphertext; the processing unit 1001 is also used to decrypt the encrypted ciphertext using the communication key to obtain a third identifier of the terminal, wherein the communication key is derived from the first long-term key, and the third identifier is used to generate a message for the terminal to trigger two-way authentication again.

[0388] In an optional manner, the first message further includes: second authentication data for authenticating the terminal.

[0389] In an optional manner, the transceiver unit 1002 is further configured to send a confirmation message indicating that the terminal has successfully received the third identifier.

[0390] In an optional manner, the transceiver unit 1002 is further configured to receive the encrypted ciphertext using a terminal parameter update procedure.

[0391] In an optional manner, the second identifier is determined by one of the following:

[0392] The first identifier; or the first identifier and the first long-term key; or the first identifier, the first long-term key, and a count value, wherein the count value indicates the number of times the terminal triggers two-way authentication.

[0393] In one embodiment, the communication device 1000 is a device on the network side (for example, UDM), and the transceiver unit 1002 is used to receive the second identifier of the terminal; the processing unit 1001 is used to determine the first identifier of the terminal and the second long-term key for authenticating the terminal in two-way authentication based on the second identifier, and the second long-term key and the first long-term key of the terminal are symmetric keys; the verification data is determined based on the second long-term key and the random number, and the verification data is used to perform authentication of the terminal in two-way authentication, and the random number is determined based on the first identifier; the first authentication data used to authenticate the network in two-way authentication is determined based on the second long-term key and the random number; the transceiver unit 1002 is also used to send the first authentication data.

[0394] In another embodiment, the communication device 1000 is a terminal, and the processing unit 1001 is used to obtain a first key identifier of the terminal, where the first key identifier indicates a first long-term key of the terminal; generate a communication key based on the first key identifier and the first long-term key; determine an identity hiding identifier, where the identity hiding identifier includes a first encrypted ciphertext and a first key identifier, where the first encrypted ciphertext is obtained by encrypting the first subscription permanent identifier of the terminal using the communication key; and the transceiver unit 1002 is used to send the identity hiding identifier.

[0395] In an optional manner, the transceiver unit 1002 is also used to receive a second encrypted ciphertext; the processing unit 1001 is also used to decrypt the second encrypted ciphertext using the communication key to obtain a second key identifier of the terminal, and the second key identifier is used to generate an identity hiding identifier for the terminal to access the network again.

[0396] In an optional manner, the transceiver unit 1002 is further configured to receive the second encrypted ciphertext using a terminal parameter update procedure.

[0397] In another embodiment, the communication device 1000 is a network-side device (such as UDM or ARPF), and the transceiver unit 1002 is used to receive an identity hiding identifier of the terminal, which includes a first encrypted ciphertext and a first key identifier; the processing unit 1001 is used to determine a second long-term key and a pre-configured second subscription permanent identifier of the terminal based on the first key identifier, and the second long-term key and the first long-term key of the terminal are symmetric keys; the first encrypted ciphertext is decrypted based on the communication key to obtain the first subscription permanent identifier of the terminal, and the communication key is deduced from the second long-term key; the terminal is authenticated based on the first subscription permanent identifier and the second subscription permanent identifier.

[0398] In an optional manner, when the terminal is successfully authenticated, the processing unit 1001 is also used to generate a second key identifier, which is used to generate an identity hiding identifier for the terminal to access the network again; the second key identifier is encrypted using the communication key to obtain a second encrypted ciphertext; and the transceiver unit 1002 is also used to send the second encrypted ciphertext.

[0399] In an optional manner, the processing unit 1001 is configured to store the second key identifier.

[0400] In an optional manner, before the processing unit 1001 stores the second key identifier, the transceiver unit 1002 is further configured to receive confirmation information indicating that the terminal has successfully received the second key identifier.

[0401] In an optional manner, the transceiver unit 1002 is further configured to send the second encrypted ciphertext using a terminal parameter update procedure.

[0402] As shown in Figure 11, this application also provides a communication device 1100. The communication device 1100 can be a chip or a chip system. The communication device can be located in the device involved in any of the above method embodiments, such as a first terminal, a network device, etc., to perform the corresponding actions of the device.

[0403] Optionally, the chip system may consist of the chip, or may include the chip and other discrete devices.

[0404] The communication device 1100 includes a processor 1110 .

[0405] The processor 1110 is configured to execute the computer program stored in the memory 1120 to implement the actions of each device in any of the above method embodiments.

[0406] The communication device 1100 may further include a memory 1120 for storing computer programs.

[0407] Optionally, memory 1120 and processor 1110 are coupled. Coupling is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. Optionally, memory 1120 and processor 1110 are integrated.

[0408] The processor 1110 and the memory 1120 can be one or more without limitation.

[0409] Optionally, in actual applications, the communication device 1100 may or may not include a transceiver 1130, as illustrated by a dashed box in the figure. The communication device 1100 can exchange information with other devices via the transceiver 1130. The transceiver 1130 can be a circuit, a bus, or any other device capable of exchanging information.

[0410] In a possible implementation, the communication device 1100 may be the first terminal or the network device in the implementation of the above methods.

[0411] The specific connection medium between the transceiver 1130, processor 1110, and memory 1120 is not limited in the embodiments of the present application. In FIG11 , the memory 1120, processor 1110, and transceiver 1130 are connected via a bus. The bus is represented by a bold line in FIG11 . The connection between other components is for illustrative purposes only and is not intended to be limiting. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, FIG11 uses only a single bold line, but this does not imply that there is only one bus or a single type of bus. In the embodiments of the present application, the processor can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present application can be directly executed by a hardware processor or by a combination of hardware and software modules within the processor.

[0412] In an embodiment of the present application, the memory may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., or a volatile memory (volatile memory), such as a random-access memory (RAM). The memory may also be any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory in an embodiment of the present application may also be a circuit or any other device that can implement a storage function, for storing computer programs, program instructions and / or data.

[0413] Based on the above embodiments, referring to FIG12 , the embodiment of the present application also provides another communication device 1200, including: an interface circuit 1210 and a logic circuit 1220; the interface circuit 1210 can be understood as an input and output interface, which can be used to execute the receiving and sending steps of each device in any of the above method embodiments; the logic circuit 1220 can be used to run code or instructions to execute the method executed by each device in any of the above embodiments, which will not be repeated.

[0414] Based on the above embodiments, embodiments of the present application further provide a computer-readable storage medium storing instructions that, when executed, cause the method executed by each device in any of the above method embodiments to be implemented. The computer-readable storage medium may include any medium capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory, a random access memory, a magnetic disk, or an optical disk.

[0415] Based on the above embodiments, an embodiment of the present application provides a communication system, which includes the terminal, UDM, AUSF, SEAF, and / or ARPF and other devices mentioned in any of the above method embodiments, and can be used to execute the method executed by each device in any of the above method embodiments.

[0416] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0417] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0418] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0419] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

Claims

1. A communication method, characterized in that, Comprising: Obtaining a first identifier of a terminal and a first long-term key of the terminal; Sending a first message, wherein the first message is used to trigger mutual authentication, the first message includes a second identifier of the terminal, the second identifier is used to determine a second long-term key for authenticating the terminal in the mutual authentication, the second identifier is determined according to the first identifier, and the second long-term key and the first long-term key are symmetric keys; Receiving first authentication data; Performing authentication of the network in the mutual authentication according to a random number, the first long-term key, and the first authentication data, wherein the random number is generated according to the first identifier.

2. The method according to claim 1, characterized in that, The first message further includes: second authentication data for authenticating the terminal.

3. The method according to claim 1 or 2, characterized in that, Further comprising: Receiving an encrypted ciphertext; Decrypting the encrypted ciphertext using a communication key to obtain a third identifier of the terminal, wherein the communication key is derived from the first long-term key, and the third identifier is used to generate a message for the terminal to trigger mutual authentication again.

4. The method according to claim 3, wherein Further comprising: Sending a confirmation message that the terminal has successfully received the third identifier.

5. The method according to claim 3 or 4, characterized in that, The receiving the encrypted ciphertext includes: Receiving the encrypted ciphertext by adopting a terminal parameter update process.

6. According to the method described in any one of claims 1-5, characterized in that, The second identifier is determined according to one of the following parameter combinations: The first identifier; or, The first identifier, the first long-term key; or, The first identifier, the first long-term key, a count value, wherein the count value indicates the number of times the terminal triggers the mutual authentication.

7. A communication method, characterized in that, Comprising: Receiving a second identifier of a terminal; Determining a first identifier of the terminal and a second long-term key for authenticating the terminal in the mutual authentication according to the second identifier, the second long-term key and the first long-term key of the terminal being symmetric keys; Determining verification data according to the second long-term key and a random number, the verification data being used to perform authentication of the terminal in the mutual authentication, the random number being generated according to the first identifier; Determining first authentication data for authenticating the network in the mutual authentication according to the second long-term key and the random number; Sending the first authentication data.

8. The method according to claim 7, wherein Further comprising: Receiving second authentication data for authenticating the terminal; Performing authentication of the terminal according to the verification data and the second authentication data.

9. The method according to claim 8, wherein The receiving the second authentication data for authenticating the terminal includes that an authentication server function receives an authentication request message, and the authentication request message carries the second authentication data and the second identifier of the terminal; The method further includes: the authentication server function stores the second authentication data and sends the second identifier of the terminal to a unified data management function; The receiving the second identifier of the terminal includes that the unified data management function receives the second identifier of the terminal from the authentication server function; Determining the first identifier of the terminal and the second long - term key according to the second identifier, and determining the verification data according to the second long - term key and the random number includes: The unified data management function determines the first identifier of the terminal and the second long - term key according to the second identifier, and determines the verification data according to the second long - term key and the random number; The method further includes: The unified data management function sends the verification data to the authentication server function; Performing the authentication of the terminal according to the verification data and the second authentication data includes: The authentication server function performs the authentication of the terminal according to the verification data and the second authentication data.

10. The method according to claim 8, wherein Receiving the second authentication data for authenticating the terminal includes that the authentication server function receives an authentication request message, and the authentication request message carries the second authentication data and the second identifier of the terminal; The method further includes: Sending the second identifier of the terminal and the second authentication data to the unified data management function; Receiving the second identifier of the terminal includes that the unified data management function receives the second identifier of the terminal and the second authentication data from the authentication server function; Determining the first identifier of the terminal and the second long - term key according to the second identifier, and determining the verification data according to the second long - term key and the random number includes: The unified data management function determines the first identifier of the terminal and the second long - term key according to the second identifier, and determines the verification data according to the second long - term key and the random number; Performing the authentication of the terminal according to the verification data and the second authentication data includes: The unified data management function performs the authentication of the terminal according to the verification data and the second authentication data.

11. The method according to claim 9, characterized in that Determining the first authentication data according to the second long - term key and the random number, and sending the first authentication data includes: The unified data management function determines the first authentication data according to the second long - term key and the random number, and sends the first authentication data to the terminal through the authentication server function.

12. According to the method described in any one of claims 7-11, characterized in that, Further includes: The security anchor function receives a first message, the first message is used to trigger the mutual authentication, and the first message includes the second identifier of the terminal and the second authentication data; The security anchor function sends the authentication request message to the authentication server function.

13. According to the method described in any one of claims 7-12, characterized in that, Further includes: In the case of successful authentication of the terminal, a third identifier is generated, and the third identifier is used to generate a message for the terminal to trigger mutual authentication again; Encrypting the third identifier with a communication key to obtain an encrypted ciphertext, where the communication key is derived from the second long - term key; Sending the encrypted ciphertext.

14. The method according to claim 13, characterized in that, Further includes: Storing the third identifier.

15. The method according to claim 14, wherein, Before storing the third identifier, further includes: Receiving a confirmation message that the terminal has successfully received the third identifier.

16. The method according to any one of claims 13-15, characterized in that, Sending the encrypted ciphertext includes: Sending the encrypted ciphertext using the terminal parameter update process.

17. A communication method, characterized in that, Includes: Obtain a first key identifier of a terminal, where the first key identifier indicates a first long-term key of the terminal; Generate a communication key based on the first key identifier and the first long-term key; Determine an identity hiding identifier, where the identity hiding identifier includes a first ciphertext and the first key identifier, and the first ciphertext is obtained by encrypting a first subscription permanent identifier of the terminal using the communication key; Send the identity hiding identifier.

18. The method according to claim 17, wherein Further includes: Receive a second ciphertext; Decrypt the second ciphertext using the communication key to obtain a second key identifier of the terminal, where the second key identifier is used to generate the identity hiding identifier for the terminal to access the network again.

19. The method according to claim 18, wherein Further includes: Send a confirmation message that the terminal has successfully received the second key identifier.

20. The method according to claim 18 or 19, characterized in that, The receiving the second ciphertext includes: Receiving the second ciphertext by adopting a terminal parameter update process.

21. A communication method, characterized in that, Includes: Receive an identity hiding identifier of a terminal, where the identity hiding identifier includes a first ciphertext and a first key identifier; Determine a second long-term key and a pre-configured second subscription permanent identifier of the terminal according to the first key identifier, where the second long-term key and the first long-term key of the terminal are symmetric keys; Decrypt the first ciphertext based on the communication key to obtain the first subscription permanent identifier of the terminal, where the communication key is deduced from the second long-term key; Authenticate the terminal according to the first subscription permanent identifier and the second subscription permanent identifier.

22. The method according to claim 21, wherein Further includes: When the authentication of the terminal is successful, generate a second key identifier, where the second key identifier is used to generate the identity hiding identifier for the terminal to access the network again; Encrypt the second key identifier using the communication key to obtain a second ciphertext; Send the second ciphertext.

23. The method according to claim 22, wherein Further includes: Store the second key identifier.

24. The method according to claim 23, wherein Before storing the second key identifier, further includes: Receive a confirmation message that the terminal has successfully received the second key identifier.

25. The method according to claim 23, characterized in that The sending the second ciphertext includes: Sending the second ciphertext by adopting a terminal parameter update process.

26. A communication device, characterized in that, Includes: Implement functional modules for the method described in any one of claims 1-6, or any one of claims 7-16, or any one of claims 17-20, or any one of claims 21-25.

27. A communication device, characterized in that, Includes: At least one processor and a memory; The memory is used to store computer programs or instructions; The at least one processor is used to execute the computer programs or instructions so that the method described in any one of claims 1-25 is executed.

28. A chip system, characterized in that, The chip system includes: a processing circuit; the processing circuit is coupled to a storage medium; The processing circuit is used to execute some or all of the computer programs or instructions in the storage medium. When the some or all of the computer programs or instructions are executed, they are used to implement the method described in any one of claims 1-25.

29. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a computer, cause the method according to any one of claims 1-25 to be executed.

30. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are run on a computer, the method according to any one of claims 1-25 is caused to be executed.

Images