WO2025139994A1 - Communication method and apparatus - Google Patents

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

A communication method and device

CROSS-REFERENCE TO RELATED APPLICATIONS

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", all contents of which are incorporated by reference in this application.

Technical Field

The embodiments of the present application relate to the field of communication technology, and in particular, to a communication method and device.

Background Art

In a mobile communication network, the user equipment (UE) authenticates itself with the network through the subscription data in the subscriber identity module (SIM) or the universal subscriber identity module (USIM) to obtain authorization to access the network. Regardless of the authentication method, the network needs to obtain the permanent identity of the UE in order to obtain the corresponding long-term key K based on the permanent identity and then proceed with the authentication process.

However, if the permanent identity is sent directly in plain text, the user's permanent identity will be exposed, thereby destroying the user's privacy. Therefore, in the 5th generation (5G) network, an encryption mechanism for the user's permanent identity is introduced. When the user registers for the first time, the user's permanent identity information is encrypted to ensure the security of the user's permanent identity information. However, the existing encryption processing method for the user's permanent identity information requires the use of an asymmetric encryption mechanism with large communication and computing overhead, which may be unaffordable for individual terminals with limited capabilities.

Summary of the invention

The present application provides a communication method and device to protect the security of user identity information.

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

Obtain a first identifier of a 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.

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 user identity of the mobile communication network. 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 occurrences of the two-way authentication. 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). It is not specifically limited here how the terminal obtains the first identifier.

In addition, the terminal may determine the second identifier based on the first identifier. For example, the first identifier is encrypted to obtain the second identifier; or the first identifier and the first long-term key of the terminal are encrypted to obtain the second identifier. How to determine the second identifier based on the first identifier is not specifically limited here.

In the present application, the terminal can trigger two-way authentication by sending a first message carrying a second identifier to the network, so that the network can determine a second long-term key symmetric to the first long-term key of the terminal based on the second identifier, and authenticate the terminal based on the second long-term key. The terminal can generate a random number based on the first identifier, and authenticate the network based on the first long-term key, the first authentication data from the network, and the random number. The terminal and the network use a symmetric key method for two-way authentication, which does not require complex calculations and simplifies the processing logic. For terminals with limited capabilities, this is affordable.

In the process of two-way authentication between the terminal and the network, random numbers are also used. In this application, the random number of two-way authentication is generated according to the first identifier, and the network and the terminal do not need to carry random numbers during the signaling interaction of two-way authentication, thereby further improving the efficiency of two-way authentication and saving signaling resources.

In an optional manner, the terminal also receives the encrypted ciphertext and decrypts 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 the two-way authentication again. Furthermore, the terminal may also store the third identifier.

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 includes the second identifier determined based on the updated first identifier. Even if the attacker obtains the second identifier in the first message, the identity of the terminal cannot be deciphered.

In an optional manner, the first message also includes: second authentication data for authenticating the terminal.

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

In an optional manner, the terminal further sends a confirmation message indicating that the terminal has successfully received the third identifier, so that the device on the network side determines that the terminal side has received the third identifier, and thus the third identifier can also be stored.

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

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

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.

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

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.

In the present application, the second identifier can be determined based on the first identifier, such as reusing the first identifier as the second identifier, or 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 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 the 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 long-term key, and the count value.

In 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:

Receive the second identifier of the terminal; determine the first identifier of the terminal and the second long-term key for authenticating the terminal in the two-way authentication according to the second identifier, the second long-term key and the first long-term key of the terminal are symmetric keys; determine verification data according to the second long-term key and the random number, the verification data is used to perform the authentication of the terminal in the two-way authentication, the random number is determined according to the first identifier; determine the first authentication data used for authenticating the network in the two-way authentication according to the second long-term key and the random number; send the first authentication data. Specifically, the above steps can be performed by UDM or ARPF.

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 perform authentication of the terminal based on the verification data and the second authentication data, which is not specifically limited in this application.

In an optional manner, receiving second authentication data for authenticating a terminal includes an authentication server function (e.g., AUSF) receiving an authentication request message carrying the second authentication data and a 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 a 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 verification data based on the second long-term key and a 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 verification data based on the second long-term key and a random number; the unified data management function (e.g., UDM or ARPF) sending 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.

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

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: a 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.

In an optional manner, a security anchor function (eg, SEAF) receives a first message, the first message is used to trigger two-way authentication, the first message includes a second identifier of the terminal and second authentication data; the security anchor function sends an authentication request message to an authentication server function.

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.

In an optional manner, the device on the network side also stores a third identifier.

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

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

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

Obtain a first key identifier of the terminal, the first key identifier indicating 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, 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; send the identity hiding identifier.

In the present application, the terminal generates a communication key based on the first key identifier and the first long-term key, and encrypts the 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 side as the content of the identity hiding identifier, so that the network side can determine the second long-term key and verify the first subscription permanent identifier. In this way, the terminal and the network side use symmetric (identical) communication keys for encryption and decryption, which can reduce the data processing complexity of the subscription permanent identifier encryption.

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.

In an optional manner, the terminal also receives a second encrypted ciphertext and uses the communication key to decrypt the second encrypted ciphertext to obtain a second key identifier of the terminal, which is used to generate an identity hiding identifier for the terminal to access the network again. Further, the terminal may also store the second key identifier.

In the present application, the terminal can update the first key identifier based on the second key identifier. When the terminal accesses the network again, the communication key can be determined based on the second key identifier and the first long-term key, and the first subscription permanent identifier can be encrypted 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 network is accessed, the first encrypted ciphertext encrypted by the communication key in the identity hiding identifier is different, and 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.

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 knows the timing of storing the second key identifier.

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

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.

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 with multiple network elements, which is not specifically limited here. Execute as follows:

An identity-hiding identifier of a receiving terminal is provided, wherein 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 according to the first key identifier, wherein 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, wherein the communication key is derived from the second long-term key; and the terminal is authenticated according to the first subscription permanent identifier and the second subscription permanent identifier.

In an optional manner, when the terminal is successfully authenticated, a second key identifier is generated, the second key identifier 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.

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

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

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

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 device on the network side (such as the device on the network side in the second aspect (or the fourth aspect) or a chip disposed inside the device on the network side). The communication device has the functions of implementing the above-mentioned first to fourth aspects. For example, the communication device includes a module or unit 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 may be implemented by hardware.

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 realize 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.

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 aspect to the fourth aspect. The communication device may also include one or more memories, the memory is used to couple with the processor, and the memory can store the necessary computer programs or instructions for implementing the functions involved in the first aspect. 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 aspect to the fourth aspect.

In another possible design, the communication device includes a processor, which can be used to couple with a memory. The memory can store necessary computer programs or instructions for implementing the functions involved in the first to fourth aspects 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.

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.

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 can be separately set from the processor. 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.

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

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 the first to fourth aspects above. The chip system may be composed of a chip, or may include a chip and other discrete devices.

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.

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 described above.

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

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

FIG2 shows a schematic diagram of the structure of a SUCI;

FIG3A shows a schematic diagram of 5G key derivation;

FIG3B shows a schematic diagram of a UPU process;

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

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

FIG5 is a schematic diagram showing a flow chart of a communication method provided in an embodiment of the present application;

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

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

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

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

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

FIG10 shows a schematic diagram of the structure of a communication device provided in an embodiment of the present application;

FIG11 is a schematic diagram showing the structure of a communication device provided in an embodiment of the present application;

FIG12 shows a schematic diagram of the structure of a communication device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The specific operating method in the method embodiment can also be applied to the device embodiment or system embodiment. Among them, in the description of the present application, unless otherwise specified, the meaning of "multiple" is two or more. Therefore, the implementation of the device and the method can refer to each other, and the repetitions will not be repeated.

The technical solution provided in the embodiment of the present application can be applied to a 5G system, or to a future communication system or other similar communication systems. In addition, the technical solution provided in the embodiment of the present application can be applied to a cellular link, a public land mobile network (PLMN), a machine to machine (M2M) network, an Internet of Things (IoT) network or other networks. It can also be applied to links between devices, such as a device to device (D2D) link. A D2D link can also be referred to as a sidelink, where the sidelink can also be referred to as a side link or a side link, etc. In the embodiment 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 embodiment of the present application does not limit this. For the links between terminal devices, there are D2D links defined in Release (Rel)-12/13 of the third generation partnership project (3GPP), and V2X links defined by 3GPP for vehicle-to-vehicle, vehicle-to-mobile phone, or vehicle-to-any-entity for the Internet of Vehicles, including Rel-14/15. It also includes V2X links based on the new radio (NR) system in Rel-18 and subsequent versions.

Reference Figure 1 is a schematic diagram of a 5G network architecture applicable to the present application. The 5G network architecture shown in Figure 1 may include three parts, namely, a terminal device part, a data network (DN) and an operator network part. The functions of some of the network elements are briefly introduced below.

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 wireless 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.

Terminal device, also known as user equipment (UE), is a device with wireless transceiver function. It can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on the water (such as ships); it can also be deployed in the air (such as airplanes, balloons and satellites). Terminal devices can be mobile phones, tablet computers, computers with wireless transceiver functions, virtual reality (VR) terminals, augmented reality (AR) terminals, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc.

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 expression of the above-mentioned third party can be determined according to the actual application scenario, and is not limited here.

The core network part includes user plane functions and control plane functions.

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

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

Among them, AMF mainly performs the registration process when users access, as well as location management, access authentication/authorization and other functions during user mobility. In addition, it is also responsible for transmitting user policies between terminal devices and PCF. The connection between terminal devices and AMF can be called a non-access stratum (NAS) connection, and the messages transmitted between terminal devices and AMF are NAS messages.

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 policies and QoS policies to UPF based on the NG4 interface between SMF and UPF.

AUSF is mainly responsible for authenticating users and determining the legitimacy of terminal devices to determine whether to allow terminal devices to access the network.

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

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

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

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

AF mainly transmits the application side's requirements on the network side to PCF, so that PCF generates corresponding policies. 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.

NRF can be used to provide network element discovery functions and provide 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, deregistration, and network element status subscription and push.

DN is a network outside the operator network. The operator network can access multiple DNs. Multiple services can be deployed on DN, which can provide data and/or voice services to terminal devices. For example, DN is the private network of a smart factory. The sensors installed in the workshop of the smart factory can be terminal devices. The control server of the sensors is deployed in DN, and the control server can provide services for the sensors. The sensors can communicate with the control server, obtain instructions from the control server, and transmit the collected sensor data to the control server according to the instructions. For another example, DN is the internal office network of a company. The mobile phones or computers of the company's employees can be terminal devices. The employees' mobile phones or computers can access information and data resources on the company's internal office network.

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 meanings defined in the 3GPP protocol and are not limited here.

It is understandable that the above 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 network element or function can be implemented by one device, or by multiple devices, or a functional module in one device, which is not specifically limited in the embodiments of the present application.

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 embodiments of the present application may be the AMF, AUSF, and UDM in FIG. 1 , respectively, or may be a network element having the above-mentioned AMF, AUSF, and UDM functions in future communications such as the sixth generation (6G) network, and the embodiments of the present application are not limited to this.

In order to facilitate understanding of the embodiments of the present application, the terms or processing flows involved in the embodiments of the present application are briefly described below.

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

Among them, SUPI-type represents the type of SUPI, which consists of values in the range of 0 to 7 and is used to identify the type of SUPI hidden in SUCI. Refer to the following Table 1 for indication, for example, 0 indicates that the SUPI is of IMSI type. In addition, this field can also be used to determine whether the SUPI uses the IMSI or NAI format.

Table 1

Among them, Home Network Identifier represents the home network identifier. When the SUPI type is IMSI, the home network identifier consists of two parts:

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

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

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

Among them, Routing Indicator represents the routing identification, which consists of 1 to 4 decimal numbers 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.

Where Protection Scheme Id represents the protection scheme identifier used for SUPI encryption, and consists of values in the range of 0-15. Protection Scheme Id represents the null scheme or non-null scheme specified in Appendix 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. Currently, 3GPP defines this value as follows:

null-scheme (value is 0x0);

Profile<A>(value is 0x1);

Profile<B>(value is 0x2);

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

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

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:

Generate key data K of length enckeylen+icblen+mackeylen.

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 MAC calculation of the generated ciphertext value using MK, and any other parameters.

2) 5G key derivation 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:

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 service network.

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

AMF derives NAS integrity key and NAS encryption key based on AMF key, which can be used to protect NAS messages transmitted on NAS connection between AMF and terminal equipment. In addition, AMF can also derive N3IWF key and gNB key based on AMF key, and provide N3IWF key to N3IWF, which is used to protect the subsequent non-3GPP access data traffic, and provide gNB key and next hop (NH) parameter to gNB.

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 the RRC messages transmitted between the gNB and the terminal device; the UP integrity key and UP encryption key are used to protect the user plane data transmitted between the gNB and the terminal device.

Furthermore, the NAS integrity key, RRC integrity key, and UP integrity key are all used to protect the integrity of the message. The NAS encryption key, RRC encryption key, and UP encryption key are all used to encrypt and protect the message.

Take NAS integrity key and NAS encryption key as an example:

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

Similarly, when the terminal device sends an uplink NAS message to the AMF, the terminal device and the AMF can 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.

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 protections can be performed. In this application, integrity protection and encryption protection can be collectively referred to as security protection.

3) Bidirectional authentication means that the terminal authenticates with the network through the subscription data (such as long-term key K) in the (U)SIM card, so as to obtain 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, and 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 by referring to the existing protocol and will not be explained in detail here.

4) UE parameter update process (UE parameter updata), referred to as UPU process, is the process triggered by UDM after UE successfully authenticates and registers to 3GPP system (such as 5G system). Please refer to Figure 3B for understanding. The following takes the data interaction between UE, AMF, AUSF and UDM as an example, and is executed as follows:

Step 301, UDM decides to execute UPU.

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 the routing ID data) is the USIM, the UDM shall use the security grouping mechanism to protect these parameters to update the parameters stored on the USIM. The UDM shall then construct the UE parameter update data (UPU data) by including the parameters protected by the security grouping (if any) and any UE parameters whose final consumer is the ME.

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

Specifically, UDM shall choose to initiate the above call to the AUSF holding the latest K _AUSF of the UE. If UDM decides that the security check of the received UE parameter update data is successful, 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 _UE is required (UE performs MAC calculation on the UPU confirmation message), where UPU-XMAC-IUE is derived from K _AUSF with reference to the existing protocol and will not be described in detail here.

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).

If the UDM message carries an ACK indication, the response message should also carry UPU-XMAC-I _UE . UPU-MAC-I _AUSF is derived from K _AUSF with reference to the existing protocol and will not be described in detail here.

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 .

If the UDM sends an ACK indication, the AMF shall temporarily store the expected UPU-XMAC-I _UE .

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

Step 306: The UE verifies the UPU data.

Specifically, the UE may calculate the UPU-MAC-I _AUSF in the same manner as the received UE parameter update data and AUSF on the Counter _UPU , and verify whether it matches the UPU-MAC-I _AUSF value received in the UPU transparent container in the downlink NAS transport message. If the UPU-MAC-I _AUSF verification succeeds and the UPU data contains parameters protected by a security packet, the ME shall forward the security packet to the USIM. If the UPU-MAC-I _AUSF verification succeeds and the UPU data contains any parameters not protected by a security packet, the ME shall update its stored parameters with the parameters received in the UDM update data.

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 transport message to the serving AMF.

Specifically, the UE should generate UPU-MAC-I _UE and include the generated UPU-MAC-I _UE in the uplink NAS transmission message.

Step 308: AMF shall send a Nudm_SDM_Info (SDM information) request message to UDM, which carries UPU-MAC-I _UE .

In step 309 , the UDM shall compare the received UPU-MAC-I _UE with the expected UPU-XMAC-I _UE temporarily stored by the UDM in step 304 .

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

5) Long-term key

A key shared by a user (terminal) and a core network such as a 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 identifier is also the same. Therefore, the first long-term key and the second long-term key can be indistinguishable and are both referred to as long-term keys.

6) The first identifier can be understood as a temporary identity identifier of the terminal, and the first identifier can be updated as the number of two-way authentications occurs. For example, the first identifier corresponding to the Xth two-way authentication between the terminal and the network is identifier A, and the first identifier corresponding to the X+1th two-way authentication between the terminal and the network is identifier B, and identifier A is different from identifier B. This is only an exemplary description and is not specifically limited.

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.

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). How the terminal obtains the first identifier is not specifically limited here.

Optionally, the terminal may preconfigure multiple first identifiers, such as a resource pool of first identifiers.

In an optional implementation, each first identifier is used for one two-way authentication, so that the first identifier of each two-way authentication in multiple two-way authentications is different. For example, each time a two-way authentication is performed with the network, a first identifier is selected from a resource pool of first identifiers as the first identifier used for the two-way authentication, and the first identifier is deleted from the resource pool.

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

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.

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

The second identifier is updated as the first identifier is updated. For example, if the first identifier is identifier A, the second identifier corresponding to the first identifier is identifier 1; if the first identifier is identifier B, the second identifier corresponding to the first identifier is identifier 2. This is only an example and is not specifically limited. The second identifier can be carried in a two-way authentication request message between the terminal and the network, and indicates the identity information of the terminal in the two-way authentication process between the terminal and the network device.

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.

When the terminal applies to access the network and executes the process of two-way network authentication, 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 execute the access and two-way authentication process again, there may be security risks. Based on this, the second identifier can also be determined based on the first identifier, the first long-term key of the terminal, and the 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.

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 pre-calculate the second identifier according to the first identifier in accordance with the above-mentioned terminal 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.

8) Symmetric key algorithm, also known as symmetric encryption algorithm, private key encryption algorithm, shared key encryption algorithm, is a type of encryption algorithm in cryptography. This type of algorithm uses the same key for encryption and decryption, that is, the key is the same.

In this document, unless otherwise specified, "/" means "or", for example, A/B can mean A or B. "And/or" in this document is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, "at least one" means one or more, and "plurality" means two or more. The words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not limit them to be different.

It should be noted that, in this document, the words "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

In order to protect user privacy, there is an asymmetric encryption processing mechanism that encrypts the permanent identity (such as the above-mentioned SUPI). However, the encryption processing mechanism has high computational complexity and large computational consumption, and is unbearable for some terminal devices.

Based on this, the present application provides a processing scheme based on a symmetric encryption processing mechanism to protect the identity information of the terminal. Specifically, the second identifier can be determined using the first identifier pre-configured by the terminal (applicable to the first access to the network and two-way authentication) or the updated first identifier from the network side (applicable to subsequent access to the network and two-way authentication). And based on the second identifier, a two-way authentication process is performed between the terminal and the network, without using SUCI to perform a two-way authentication process between the terminal and the network (for example, 5G main authentication), such as implementation method one. As another optional method, the existing SUCI structure can also be modified, and the network can be accessed based on the modified SUCI, such as implementation method two. The present application does not specifically limit which specific scheme is used to encrypt the identity information of the terminal. The following specifically introduces the implementation method of the present application. The terminal in the following implementation method 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 may 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 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 configured by multiple network elements, which is not specifically limited here. The following is an explanation based on different embodiments, which are as follows:

Implementation Method 1

In conjunction with Figure 4A, the technical solution of the present application is described in detail with a specific method embodiment. 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 executed in a different order from that presented in Figure 4A, and it is possible that not all operations in Figure 4A need to be executed. Figure 4A takes 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 executed as follows:

Step 401: A terminal obtains a first identifier of the terminal and a first long-term key of the terminal.

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 repeated 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 repeated 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).

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.

Step 402: The terminal sends a first message, wherein the first message is used to trigger two-way authentication and includes a second identifier. Correspondingly, the device on the network side receives the first message.

The first message mentioned above can be understood as a two-way authentication request message or a registration request message, and 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.

Optionally, the first message further includes: second authentication data for authenticating the terminal, so that the network can directly authenticate the terminal and improve the efficiency of two-way authentication. The second authentication data can be derived from 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.

In addition, the above-mentioned first message may also include indication information, and the indication information 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.

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.

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.

The device on the network side can perform pre-calculation 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.

Alternatively, a device on the network side stores the correspondence between the first identifier and the second long-term key. After receiving the second identifier, the device on the network side (for example, UDM) 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, determine the first identifier corresponding to the calculated second identifier, and the second long-term key corresponding to the first identifier. 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 compare it, and stop calculating and comparing until the same second identifier is obtained through comparison. This application does not limit this.

Step 404: The device on the network side determines the first authentication data used to authenticate the network in the two-way authentication according to the second long-term key and the random number.

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 random numbers during the signaling interaction of two-way authentication, which can further improve data processing efficiency and save signaling resources.

The following example introduces the deduction process of the first authentication data. The device on the network side 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, UDM uses the random number and the second long-term key to perform operations to obtain AK, and performs operations based on the random number, the second long-term key, the generated serial number and the identification bit AMF to obtain MAC, AUTN = (SQN XOR AK) || AMF || MAC, where AUTN is the first authentication data.

In the above step 404, the network side device determines the first authentication data according to 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.

Step 405: The device on the network side sends the first authentication data. Correspondingly, the terminal receives the first authentication data.

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, UDM sends the first authentication data to AUSF. Afterwards, AUSF sends the first authentication data to SEAF. 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.

Step 406: The terminal 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.

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

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.

Specifically, after the terminal receives the first authentication data (AUTN = (SQN XOR AK) || AMF || MAC), it performs calculations based on the first long-term key and the random number to obtain AK. Then, AK is XORed with the first authentication data to obtain SQN, and it is verified whether SQN is within the correct range. If so, the SQN, the AMF in the first authentication data, and the first long-term key are calculated to obtain MAC', and the MAC in the first authentication data and MAC' are compared 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.

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, AUSF and/or SEAF receives the second authentication data and performs verification according to the first verification data and/or the second verification data in step 404.

Optionally, if the first message in the above step 402 does not include the second authentication data, then after step 406 is executed, and if it is determined that the terminal successfully authenticates the network, the terminal also sends the second authentication data. After the network-side device receives the second authentication data, step 407 may be executed. 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 step 407 and step 404 is not limited.

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.

Specifically, the device on the network side may determine the verification data according to the second long-term key and the random number, wherein the random number refers to the introduction in step 404.

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.

In another optional implementation, other network side devices receive and save 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 devices. The other network side devices verify the received second authentication data based on the first verification data. In a specific implementation, the network side device is UDM, and the other network side device is AUSF.

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. 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.

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 as to verify the received second authentication data after the terminal side sends the second authentication data in step 406.

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

After receiving the second authentication data, the device on the network side can perform authentication on the terminal according to the verification data and the second authentication data.

Specifically, UDM determines the first verification data XRES* based on the second long-term key and the random number, and sends the first verification data XRES* to AUSF; AUSF stores the first verification data XRES*, and determines the second verification data HXRES* based on the first verification data XRES*. AUSF sends the second verification data HXRES* to SEAF, and SEAF stores the second verification data HXRES*. Further, SEAF receives the second authentication data RES* from the terminal, and calculates the third authentication data HRES* based on the second authentication data RES*. SEAF verifies the second verification data HXRES* with the third authentication data HRES*. If the second verification data HXRES* is the same as the third authentication data HRES*, SEAF successfully authenticates the terminal. SEAF sends the second authentication data RES* to AUSF. AUSF verifies the second authentication data RES* with the first verification data XRES*. If the second authentication data RES* is the same as the first verification data XRES*, AUSF successfully authenticates the terminal. If SEAF and AUSF successfully authenticate the terminal, it is considered that the network successfully authenticates the terminal.

The above step 407 can be understood by referring to steps 512 to 514 in FIG. 5 , or by referring to step 607 in FIG. 6 , or by referring to step 707 in FIG. 7 , and will not be described in detail here.

In the present application, the terminal can trigger two-way authentication by sending a first message carrying a second identifier to the network, so that the network can determine a second long-term key symmetric to the first long-term key of the terminal based on the second identifier, and authenticate the terminal based on the second long-term key. The terminal can generate a random number based on the first identifier, and authenticate the network based on the first long-term key, the first authentication data from the network, and the random number. The terminal and the network use a symmetric key method for two-way authentication, which does not require complex calculations and simplifies the processing logic. For terminals with limited capabilities, this is affordable.

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, and 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.

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 FIG. 4B , after executing the above steps 401 to 407, it also includes:

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

Specifically, the third identifier may be a random number generated by a random number generator. Alternatively, the third identifier may be composed of a random number generated by a random number generator and a proprietary identifier (for example, a PLMN identifier). Alternatively, a device on the network side (for example, UDM) maintains a resource pool of third identifiers, and each time the network successfully authenticates a terminal, a third identifier is randomly selected from the resource pool. Alternatively, a device on the network side maintains an increasing serial number of 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.

Optionally, the device on the network side 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 trigger the two-way authentication again, that is, the third identifier is used as the first identifier in step 401 during the next two-way authentication. Specifically, the device on the network side can replace the original first identifier with the third identifier, or the device on the network side retains the original first identifier and further stores the third identifier. No limitation is made.

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 from the second long-term key.

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.

The above step 409 may be performed by UDM or ARPF, for example, UDM generates a third identifier, and UDM uses the communication key to encrypt the third identifier to obtain an encrypted ciphertext. The above step 409 may also be performed by AUSF, for example, UDM sends the third identifier to AUSF, AUSF receives the third identifier, and then AUSF uses the communication key to encrypt the third identifier to obtain an encrypted ciphertext.

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

Step 410: The device on the network side sends the encrypted ciphertext. Correspondingly, the terminal receives the encrypted ciphertext.

The encrypted ciphertext may be transmitted to the terminal by the UDM or ARPF via the AUSF and SEAF. Optionally, the device on the network side may also use the terminal parameter update process to transmit the encrypted ciphertext. 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.

Optionally, the device on the network side may also use a UPU process to encrypt and transmit the third identifier. Specifically, the third identifier is used as UPU data in the UPU process.

Step 411: The terminal uses the communication key to decrypt the encrypted ciphertext to obtain the third identifier of the terminal.

After the terminal obtains the third identifier, the third identifier can be stored. It should be understood that the third identifier is an updated first identifier, for example, used to generate a message for the terminal to trigger the two-way authentication again, that is, the third identifier is used as the first identifier in step 401 during the next two-way authentication. Specifically, the terminal can replace the original first identifier with the third identifier, or the terminal retains the original first identifier and further stores the third identifier. No limitation is made.

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

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 includes the second identifier determined based on the updated first identifier. Even if the attacker obtains the second identifier in the first message, the identity of the terminal cannot be deciphered.

In the scheme of Figures 4A-4B above, the terminal's identity uses the first identifier to replace the SUPI in the existing process for two-way authentication. It should be understood that although SUPI is not used as a two-way authentication in this embodiment, it can still be retained. In the process after the two-way authentication is completed, the network side device still uses SUPI as the user's identity identifier so that the network side device can track the user's log and other information. Specifically, the network side device can determine the SUPI based on the first identifier or the second identifier, and then use the SUPI. For example, in the above UPU process, SUPI can still be used instead of using the first identifier as the terminal identifier.

The following processing flow with reference to Figures 5 to 7 is used to expand the scheme 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 the following Figures 5 to 7, 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.

Referring to Figure 5, the execution is as follows:

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.

Specifically, the first identifier may be obtained with reference to step 401 in FIG. 4A above. In an optional implementation, the UE obtains the first long-term key from the USIM and obtains 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 may be understood with reference to 6) above and will not be described in detail here.

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

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

Specifically, the second identifier may be carried in the first message, and the first message may be a registration request message or an identity response message. That is, the registration request message initiated by the UE may carry the second identifier, or the network side may initiate an identity request, so that the identity response message sent by the UE carries the second identifier.

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 indication information of a two-way authentication method, that is, the indication information of the above-mentioned 5G-AKA, EAP-AKA, or EAP-TLS.

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

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

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

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.

Step 505, 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.

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 FIG. 4A above, and will not be repeated here. In addition, the method of generating random numbers can also be understood by referring to step 403 in FIG. 4A above.

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 the present application may also be specifically performed by the ARPF. For ease of description, the UDM is used as an example in the following.

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

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 deduce the first authentication data AUTN and the first verification data (XRES*) based on CK and IK. Wherein, 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 serial number maintained by the UE and UDM, MAC＝f1(SQN||RAND||AMF), AK＝f5(RAND), and 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 according to 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.

Optionally, when deducing the key, KID is also used as input, that is, CK=f3(K, RAND, KID), IK=f4(K, RAND, KID), where KID is the second identifier.

It should be understood that the execution order of the determination action of the UDM in the present application is not limited, for example, the first verification data XRES* may be determined first and then the first authentication data may be determined, and the present application does not make any limitation. Other embodiments are similar.

Step 506: UDM sends first authentication data to AUSF. Optionally, in step 506, UDM also sends first verification data to AUSF. Accordingly, AUSF receives the first authentication data and the first verification data.

Specifically, the first authentication data and/or the first verification data is transmitted through an authentication vector acquisition response message.

Step 507, AUSF stores the first verification data.

Optionally, AUSF stores the first verification data. Thus, in step 514, the UE can be authenticated based on the first verification data. The key is deduced based on the first verification data to obtain the second verification data. For example, AUSF deduce the first verification data XRES* to obtain the second verification data HXRES*. This can be understood by referring to the 5G main authentication, which will not be elaborated here.

Step 508, AUSF sends first authentication data to SEAF.

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

Specifically, the second verification data and/or the first authentication data are transmitted via an authentication response message.

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

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 called a second authentication request message, and the authentication request message in step 503 can be called a first authentication request message.

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.

If the terminal successfully authenticates the network, the second authentication data is generated according to the first long-term key and the random number.

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.

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. This can be understood by referring to the description of step 406 above and will not be repeated here.

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 the verification data can also be replaced by the first identifier.

Optionally, when deducing the key, KID is also used as input, that is, CK=f3(K, RAND, KID), IK=f4(K, RAND, KID), where KID is the second identifier.

Step 511: UE sends second authentication data to SEAF. Correspondingly, SEAF receives the second authentication data.

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

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

Specifically, SEAF calculates the third authentication data HRES* based on the second authentication data, and verifies the third authentication data HRES* and the second verification data HXRES*. The specific calculation and verification methods can be understood with reference to the 5G main authentication, which will not be repeated here. If the third authentication data HRES* and the second verification data HXRES* are the same, the authentication is successful. Specifically, it means that the UE has the right to access the visited network. It should be understood that the authentication of the UE by the network side can specifically include the authentication in step 512 and/or the authentication in step 514.

Step 513: SEAF sends the second authentication data to AUSF. Accordingly, AUSF receives the second authentication data.

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

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

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, it is considered that the UE is successfully authenticated. Specifically, it means that the UE has the authority to access the home network.

Step 515a, AUSF sends the authentication result to SEAF. Correspondingly, SEAF receives the authentication result.

Step 515b, AUSF sends the authentication result to UDM. Correspondingly, UDM receives the authentication result.

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, and if the AUSF believes that the UE does not have the authority to access the home network, the authentication result is authentication failure.

Furthermore, the network side may also update the first identifier. The steps are as follows:

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

Optionally, the UDM may also 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. This may be understood by referring to steps 408 and 409 in FIG. 4B above, and will not be described in detail here.

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

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.

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. In FIG5, step 517 is used as an example for UDM to send encrypted ciphertext to UE through the UPU process.

Step 518a: The UE decrypts the encrypted ciphertext to obtain the third identifier, or directly decrypts to obtain the third identifier.

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 trigger the two-way authentication again, that is, the third identifier is used as the first identifier in step 501 during the next two-way authentication. Specifically, the UE can replace the original first identifier with the third identifier, or the UE retains the original first identifier and further stores the third identifier. No limitation is made.

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.

Step 518b: The UDM stores the third identifier.

Specifically, the UDM may update the first identifier to the third identifier, see step 518a for details. In addition, the UDM may also pre-calculate a new second identifier based on the third identifier.

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

This method uses a symmetric encryption mechanism to protect user privacy. At the same time, the first identifier also replaces the random number in the main authentication process, which can save the cost of the main authentication process. In addition, in the scenario of anti-quantum attack, the use of a 256-bit symmetric encryption algorithm can achieve the beneficial effect of anti-quantum attack and reduce the computing and transmission consumption introduced by the post-quantum encryption algorithm.

Referring to Figure 6, the execution is as follows:

In step 601, the UE obtains the first identifier of the UE and the first long-term key of the UE, and determines the second identifier according to the first identifier. The UE also generates second authentication data according to the first long-term key and a random number. The random number is generated according to the first identifier. The acquisition of the first identifier and the first long-term key, and the determination of the second identifier can be understood with reference to step 501 in FIG. 5 above, and will not be repeated here.

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.

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

Specifically, the second identifier and the second authentication data may be carried in the first message, and the first message 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 the registration request message initiated by the UE, or the network side may initiate an identity request, so that the identity response message sent by the UE carries the second identifier and the second authentication data.

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 indication information of a two-way authentication method, that is, the indication information of the above-mentioned 5G-AKA, EAP-AKA, or EAP-TLS.

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

Step 603: SEAF forwards the second identifier and the second authentication data to AUSF. Accordingly, AUSF receives the second identifier and the second authentication data.

Step 604: AUSF forwards the second identifier to UDM. Accordingly, UDM receives the second identifier.

Optionally, the AUSF stores second authentication data.

Optionally, the AUSF also forwards the second authentication data to the UDM. Accordingly, the UDM receives the second authentication data.

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.

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.

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.

The first authentication data may be determined by referring to step 505 in Fig. 5 above, which will not be described in detail herein. In addition, the first verification data may also be determined by referring to step 505 in Fig. 5 above.

Step 606: UDM sends the first authentication data to AUSF. Correspondingly, AUSF receives the first authentication data.

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

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

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

Step 607 in FIG. 6 is illustrated by taking the AUSF authenticating the second authentication data as an example.

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.

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 according to the first verification data received in step 606, thereby authenticating the terminal. That is, the AUSF stores the second authentication data in step 604.

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.

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.

Step 608: UDM obtains the authentication result.

In an optional implementation, the UDM verifies the second authentication data according to the above step 607 to obtain an authentication result. In another optional implementation, the AUSF verifies the second authentication data according to the above step 607 to obtain an authentication result, and sends the authentication result to the UDM, so that the UDM obtains the authentication result. In FIG6 , step 608 is described by taking the example of the AUSF sending the authentication result to the UDM.

Furthermore, the network side may also update the first identifier. The steps are as follows:

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

Optionally, the UDM may also 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. This may be understood by referring to steps 408 and 409 in FIG. 4B above, or step 516 in FIG. 5, which will not be described in detail here.

Step 610, UDM sends a third identifier or encrypted ciphertext to AUSF.

In FIG. 6 , step 610 in which the UDM sends the third identifier to the AUSF is taken as an example for explanation.

Step 611, AUSF encrypts the third identifier to generate an encrypted ciphertext.

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

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 that the UDM sends the encrypted ciphertext to the AUSF, and the above step 611 may not be executed.

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.

Specifically, the encrypted ciphertext and/or the first authentication data are transmitted via an authentication response message.

It should be understood that the first authentication data can be sent through the same message as the encrypted ciphertext; it can also 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.

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.

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 called a second authentication request message, and the authentication request message in step 603 can be called a first authentication request message.

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

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.

The specific authentication may be understood by referring to step 510 in FIG. 5 above, which will not be described in detail here.

If the terminal successfully authenticates the network, the encrypted ciphertext is decrypted to obtain the third identifier, and the third identifier is stored. It should be understood that the third identifier is the updated first identifier, for example, used to generate a message for the terminal to trigger the two-way authentication again, that is, the third identifier is used as the first identifier in step 601 during the next two-way authentication. Specifically, the UE can replace the original first identifier with the third identifier, or the UE can retain the original first identifier and further store the third identifier. No limitation is made.

Step 615: UE sends a message of successful network authentication to UDM through SEAF and AUSF. Correspondingly, UDM receives the message of successful network authentication of UE.

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) and sends the third identifier when determining that both authentications are successful.

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 determining that both bidirectional authentications are successful.

Step 616: The UDM stores the third identifier.

Specifically, the UDM may update the first identifier to the third identifier, see step 518a for details. In addition, the UDM may also pre-calculate a new second identifier based on the third identifier.

This method uses a symmetric cryptographic mechanism to protect user privacy while combining the transmission of the terminal's identity (i.e., the first identification), the main authentication, and the transmission process of the new terminal identity (i.e., the third identification), 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 computation and transmission consumption introduced by the post-quantum cryptographic algorithm. In addition, this process sends the second identification together with the second authentication data used to authenticate the terminal, which can save signaling overhead and improve data processing efficiency.

Referring to Figure 7, the execution is as follows:

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

Step 709: AUSF sends the first authentication data to SEAF. Accordingly, SEAF receives the first authentication data.

Specifically, the first authentication data is transmitted through an authentication vector acquisition response message.

Step 710: SEAF sends first authentication data to UE. Correspondingly, UE receives the first authentication data.

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

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.

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

Step 712: UE sends a message of successful network authentication to UDM through SEAF and AUSF. Correspondingly, UDM receives the message of successful network authentication of UE.

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

Optionally, UDM can also encrypt the third identifier to obtain encrypted ciphertext. For example, if the third identifier is RAND', UDM can encrypt RAND' to generate encrypted ciphertext.

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.

Step 714: UDM sends a third identifier or encrypted ciphertext to the UE through the UPU process.

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 taken as an example for explaining that the UDM sends encrypted ciphertext to the UE through the UPU process.

Step 715a: The UE decrypts the encrypted ciphertext to obtain the third identifier, or directly decrypts to obtain the third identifier.

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 trigger the two-way authentication again, that is, the third identifier is used as the first identifier in step 701 during the next two-way authentication. Specifically, the UE can replace the original first identifier with the third identifier, or the UE retains the original first identifier and further stores the third identifier. No limitation is made.

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.

Step 715b: UDM stores the third identifier.

Specifically, the UDM may update the first identifier to the third identifier, see step 715a for details. In addition, the UDM may also pre-calculate a new second identifier based on the third identifier.

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

This method combines the transmission process of the terminal identity (i.e., the first identification) transmission, the main authentication and the new terminal identity (i.e., the third identification) transmission process while using a symmetric cryptographic mechanism to protect user privacy, 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 calculation and transmission consumption introduced by the post-quantum cryptographic algorithm. In addition, the process sends the second identification 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 scheme of Figure 6, the scheme of Figure 7 has smaller changes and is more adapted to the needs of the current communication system.

Implementation Method 2:

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

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.

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).

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 the SIM.

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 the terminal is successfully authenticated and sent to the UE, and the first key identifier is not specifically limited herein.

In addition, the terminal also obtains a first subscription permanent identifier preconfigured in the terminal. Specifically, the terminal may obtain the first subscription permanent identifier from a SIM or a USIM.

Optionally, the terminal may preconfigure multiple first key identifiers, for example, a first key identifier resource pool. In an optional implementation, each first key identifier is used only for one identity authentication, so that the first key identifier for each identity authentication in multiple identity authentications is different. For example, each time when authenticating with the network, a first key identifier is selected from the first key identifier resource pool as the first key identifier used for identity authentication, and the selected first key identifier in the first key identifier resource pool is deleted.

In another optional implementation manner, 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.

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

Specifically, the terminal may use the first long-term key to perform encryption operation on the first key identifier to obtain the communication key. For example, the communication key is a symmetric key for encrypting and protecting the SUPI, 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 service network name, and KDF is the key derivation function.

Step 803: The terminal determines 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 a communication key.

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.

Specifically, if the first key identifier is KID, then the structure of SUCI in this application is shown in FIG9 , which is equivalent to replacing the Home Network Public Key Id in the existing SUCI with KID. Among them, the communication key EK is used to encrypt SUPI to generate a first encrypted ciphertext C, and the communication key MK is used to encrypt the ciphertext generated by SUPI to perform integrity protection, and generate a message authentication code MAC tag value. The scheme out part of SUCI is the concatenation of the first encrypted ciphertext C and the message authentication code MAC tag value, that is, C||MAC tag value.

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.

Step 804: The terminal sends an identity hiding identifier. Correspondingly, the device on the network side receives the identity hiding identifier.

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

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

Specifically, the device on the network side obtains the first key identifier from the received identity hiding identifier according to the data structure of the identity hiding identifier, for example, obtains the first key identifier KID from the location where the SUCI stores the KID, and the device on the network side (for example, UDM or ARPF) can pre-configure the correspondence between the first key identifier and the second long-term key and the pre-configured second subscription permanent identifier of the terminal. After receiving the first key identifier, the device on the network side can retrieve the second long-term key and the pre-configured second subscription permanent identifier according to the first key identifier.

Step 806: The device on the network side determines the communication key according to 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.

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.

Specifically, after the device on the network side determines the communication key CK||MK, the device on the network side can obtain the first encrypted ciphertext C and the message authentication code MAC tag value from the received identity hiding identifier according to 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 MAC tag value can be performed in the following manner: the first encrypted ciphertext C is MAC calculated using the communication key MK to obtain the message authentication code MAC tag value2, and the MAC tag value2 is compared to see if they are the same. If they are the same, the verification passes, and if they are not the same, the verification fails.

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

The above steps 806 and 807 can both be executed by UDM or ARPF.

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 check on the MAC tag value of the schemeout part. If the MAC tag value is verified, 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.

In the present application, the terminal generates a communication key based on the first key identifier and the first long-term key, and encrypts the 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 side as the content of the identity hiding identifier, so that the network side can determine the second long-term key and verify the first subscription permanent identifier. In this way, the terminal and the network side use symmetric (identical) communication keys for encryption and decryption, which can reduce the data processing complexity of the subscription permanent identifier encryption.

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

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

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 of 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 generation method of the second key identifier is not specifically limited here. The above step 808 can be performed by UDM or ARPF.

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 retains the original first key identifier and further stores the second key identifier. No limitation is made.

Step 809: The device on the network side uses the communication key to encrypt the second key identifier to obtain a second encrypted ciphertext.

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

Step 810: The device on the network side sends a second encrypted ciphertext.

The second encrypted ciphertext in the above step 810 may be transmitted to the terminal by the UDM or ARPF via the AUSF and SEAF. Optionally, the device on the network side may also use the terminal parameter update process to transmit the encrypted ciphertext. For example, the encrypted ciphertext is transmitted through the UPU process. Specifically, the second encrypted ciphertext is used as the UPU data in the UPU process.

Optionally, the device on the network side may also use a UPU process to encrypt and transmit the second key identifier. Specifically, the second key identifier is used as UPU data in the UPU process.

Step 811: The terminal uses the communication key to decrypt the second encrypted ciphertext to obtain a second key identifier of the terminal.

Accordingly, the terminal may store the second key identifier, and 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 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. No limitation is made.

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

In the present application, the terminal can update the first key identifier based on the second key identifier. When the terminal accesses the network again, the communication key can be determined based on the second key identifier and the first long-term key, and the first subscription permanent identifier can be encrypted 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 network is accessed, the first encrypted ciphertext encrypted by the communication key in the identity hiding identifier is different, and 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.

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 corresponding to each function. It should be easily appreciated by those skilled in the art 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 the form of hardware or computer software driving hardware 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 exceed the scope of the present application.

The embodiment of the present application can divide the functional units of the device according to the above method example, 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 in the form of software functional units.

In the case of using an integrated unit, FIG10 shows a possible exemplary block diagram of a communication device involved in an embodiment of the present application. As shown in FIG10, 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 the communication of the communication device 1000 with other devices. Optionally, the transceiver unit 1002 may include a receiving unit and/or a sending unit, which are respectively used to perform receiving and sending operations. 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 above-mentioned terminal, network side equipment such as SEAF, AUSF and UDM, etc. The specific execution process may refer to the description of the above-mentioned method embodiment and will not be described in detail here.

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.

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 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 two-way authentication again.

In an optional manner, the first message also includes: second authentication data for authenticating the terminal.

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.

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

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

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.

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.

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, the first key identifier indicating 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, 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; the transceiver unit 1002 is used to send the identity hiding identifier.

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.

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

In another embodiment, the communication device 1000 is a device on the network side (such as UDM or ARPF), and the transceiver unit 1002 is used to receive the identity hiding identifier of the terminal, and the identity hiding identifier includes a first encrypted ciphertext and a first key identifier; the processing unit 1001 is used to determine the second long-term key and the pre-configured second subscription permanent identifier of the terminal according to 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 derived from the second long-term key; the terminal is authenticated according to the first subscription permanent identifier and the second subscription permanent identifier.

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.

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

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 that the terminal successfully receives the second key identifier.

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

As shown in FIG11 , the present application also provides a communication device 1100. The communication device 1100 may be a chip or a chip system. The communication device may be located in a device involved in any of the above method embodiments, such as a first terminal, a network device, etc., to perform actions corresponding to the device.

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

The communication device 1100 includes a processor 1110 .

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

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

Optionally, the memory 1120 is coupled to the processor 1110. Coupling is an indirect coupling or communication connection between devices, units or modules, which can be electrical, mechanical or other forms, for information exchange between devices, units or modules. Optionally, the memory 1120 is integrated with the processor 1110.

The processor 1110 and the memory 1120 may be one or more and are not limited.

Optionally, in practical applications, the communication device 1100 may include or exclude the transceiver 1130, which is illustrated by a dotted box in the figure. The communication device 1100 may exchange information with other devices through the transceiver 1130. The transceiver 1130 may be a circuit, a bus, or any other device that can be used for information exchange.

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

In the embodiment of the present application, the specific connection medium between the above-mentioned transceiver 1130, the processor 1110 and the memory 1120 is not limited. In the embodiment of the present application, the memory 1120, the processor 1110 and the transceiver 1130 are connected by a bus in FIG. 11, and the bus is represented by a thick line in FIG. 11. The connection mode between other components is only for schematic illustration and is not limited. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in FIG. 11, but it does not mean that there is only one bus or one type of bus. In the embodiment 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, a discrete hardware component, and can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiment of the present application. The general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware processor to be executed, or a combination of hardware and software modules in the processor can be executed.

In the embodiments 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 the 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 the embodiments 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.

Based on the above embodiments, referring to FIG. 12 , the embodiments of the present application also provide another communication device 1200, including: an interface circuit 1210 and a logic circuit 1220; the interface circuit 1210 can be understood as an input-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 codes or instructions to execute the method executed by each device in any of the above embodiments, which will not be repeated.

Based on the above embodiments, the embodiments of the present application further provide a computer-readable storage medium, which stores instructions. When the instructions are executed, the method executed by each device in any of the above method embodiments is implemented. The computer-readable storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, and other media that can store program codes.

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.

It should be understood by those skilled in the art 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. Moreover, 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 disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

The present application is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product 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 process and/or box 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 process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

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 work in a specific manner, so that the instructions stored in the computer-readable memory produce a 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.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby 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 (30)

A communication method, characterized by comprising: Obtaining a first identification of a terminal and a first long-term key of the terminal; Sending a first message, wherein the first message is used to trigger bidirectional 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 bidirectional 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; Authentication of the network in the two-way authentication is performed 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. The method according to claim 1 is characterized in that the first message also includes: second authentication data for authenticating the terminal. The method according to claim 1 or 2, characterized in that it also includes: Receive encrypted ciphertext; The encrypted ciphertext is decrypted 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 two-way authentication again. The method according to claim 3, further comprising: A confirmation message is sent indicating that the terminal has successfully received the third identifier. The method according to claim 3 or 4, characterized in that the receiving of the encrypted ciphertext comprises: The encrypted ciphertext is received using a terminal parameter update process. The method according to any one of claims 1 to 5, characterized in that the second identifier is determined according to a combination of the following parameters: the first identifier; or the first identifier, 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 the two-way authentication. A communication method, characterized by comprising: a second identifier of a receiving terminal; Determine, according to the second identifier, the first identifier of the terminal and a second long-term key for authenticating the terminal in two-way authentication, where the second long-term key and the first long-term key of the terminal are symmetric keys; Determine verification data according to the second long-term key and a random number, where the verification data is used to perform authentication of the terminal in the two-way authentication, and the random number is determined according to the first identifier; Determine first authentication data for authenticating a network in the two-way authentication according to the second long-term key and the random number; The first authentication data is sent. The method according to claim 7, further comprising: receiving second authentication data for authenticating the terminal; The authentication of the terminal is performed according to the verification data and the second authentication data. The method according to claim 8, characterized in that the receiving of the second authentication data for authenticating the terminal comprises the authentication server function receiving an authentication request message, the authentication request message carrying the second authentication data and the second identifier of the terminal; The method further comprises: the authentication server function storing the second authentication data and sending the second identification of the terminal to the unified data management function; The receiving terminal's second identifier includes the unified data management function receiving the terminal's second identifier from the authentication server function; The determining the first identification and the second long-term key of the terminal according to the second identification, and determining the verification data according to the second long-term key and the random number comprises: the unified data management function determines the first identification and the second long-term key of the terminal according to the second identification, and determines the verification data according to the second long-term key and the random number; The method further comprises: the unified data management function sending the verification data to the authentication server function; The performing of the authentication of the terminal according to the verification data and the second authentication data comprises: the authentication server function performing the authentication of the terminal according to the verification data and the second authentication data. The method according to claim 8, characterized in that the receiving of the second authentication data for authenticating the terminal comprises the authentication server function receiving an authentication request message, the authentication request message carrying the second authentication data and the second identifier of the terminal; The method further comprises: sending a second identification of the terminal and the second authentication data to a unified data management function; The receiving terminal's second identification includes the unified data management function receiving the terminal's second identification and the second authentication data from the authentication server function; The determining the first identification and the second long-term key of the terminal according to the second identification, and determining the verification data according to the second long-term key and the random number comprises: the unified data management function determines the first identification and the second long-term key of the terminal according to the second identification, and determines the verification data according to the second long-term key and the random number; The performing of the authentication on the terminal according to the verification data and the second authentication data includes: the unified data management function performing the authentication on the terminal according to the verification data and the second authentication data. The method according to claim 9 is characterized in that the first authentication data is determined 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. The method according to any one of claims 7 to 11, further comprising: The security anchor function receives a first message, where the first message is used to trigger the two-way authentication, and the first message includes a second identifier of the terminal and the second authentication data; The security anchor function sends the authentication request message to the authentication server function. The method according to any one of claims 7 to 12, further comprising: In the case where the terminal is successfully authenticated, a third identifier is generated, wherein the third identifier is used to generate a message for the terminal to trigger two-way authentication again; Encrypting the third identifier using a communication key to obtain an encrypted ciphertext, wherein the communication key is derived from the second long-term key; The encrypted ciphertext is sent. The method according to claim 13, further comprising: The third identifier is stored. The method according to claim 14, characterized in that before storing the third identifier, it also includes: Receive confirmation information that the terminal successfully receives the third identifier. The method according to any one of claims 13 to 15, characterized in that the sending of the encrypted ciphertext comprises: The encrypted ciphertext is sent using a terminal parameter update process. A communication method, characterized by comprising: Acquire 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 encrypted ciphertext and the first key identifier, where the first encrypted ciphertext is obtained by encrypting a first subscription permanent identifier of the terminal using the communication key; The identity concealing identifier is sent. The method according to claim 17, further comprising: receiving a second encrypted ciphertext; The second encrypted ciphertext is decrypted 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. The method according to claim 18, further comprising: Send a confirmation message that the terminal successfully receives the second key identifier. The method according to claim 18 or 19, characterized in that the receiving the second encrypted ciphertext comprises: The second encrypted ciphertext is received using a terminal parameter update process. A communication method, characterized by comprising: An identity hiding identifier of a receiving terminal, wherein the identity hiding identifier includes a first encrypted 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, wherein the second long-term key and the first long-term key of the terminal are symmetric keys; decrypting the first encrypted ciphertext based on a communication key to obtain a first subscription permanent identifier of the terminal, wherein the communication key is derived from the second long-term key; The terminal is authenticated based on the first subscription permanent identifier and the second subscription permanent identifier. The method according to claim 21, further comprising: In the case where the terminal is successfully authenticated, generating a second key identifier, wherein 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 encrypted ciphertext; The second encrypted ciphertext is sent. The method according to claim 22, further comprising: The second key identifier is stored. The method according to claim 23, characterized in that before storing the second key identifier, it also includes: Receive confirmation information that the terminal successfully receives the second key identifier. The method according to claim 23, characterized in that the sending of the second encrypted ciphertext comprises: The second encrypted ciphertext is sent using the terminal parameter update process. A communication device, characterized by comprising: a functional module for implementing the method according to 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. A communication device, characterized in that it comprises: at least one processor and a memory; The memory is used to store computer programs or instructions; The at least one processor is configured to execute the computer program or instructions so that the method according to any one of claims 1 to 25 is performed. A chip system, characterized in that the chip system comprises: a processing circuit; the processing circuit is coupled to a storage medium; The processing circuit is used to execute part or all of the computer programs or instructions in the storage medium, and when the part or all of the computer programs or instructions are executed, it is used to implement the method according to any one of claims 1 to 25. A computer-readable storage medium, characterized in that the computer-readable storage medium stores instructions, and when the instructions are executed by a computer, the method according to any one of claims 1 to 25 is executed. A computer program product comprising a computer program or an instruction, characterized in that when the computer program or the instruction is run on a computer, the method according to any one of claims 1 to 25 is executed.