WO2022174729A1 - Method for protecting identity identification privacy, and communication apparatus - Google Patents

Abstract

The present application provides a method for protecting identity identification (ID) privacy, and a communication apparatus. In the method, by changing an existing air interface message, an attacker cannot determine, from a message from a network side, whether a UE ID constructed by the attacker is valid. Specifically, regardless of whether the UE ID is valid, the network side sends, to a UE, an air interface message of which both a message type and a message format are consistent, or the network side carries, in a message of rejecting registration, a reason value irrelevant to whether the UE ID is valid, thereby preventing the attacker from guessing the UE ID from the air interface message and a subsequent process, and increasing the attack difficulty of the attacker. Moreover, the network side is not required to further verify a message sent by the attacker in the subsequent process, but directly sends a rejection message, thereby saving signaling overhead and calculation consumption.

Description

Method and communication device for protecting identity privacy

This application claims the priority of the Chinese patent application with the application number 202110193034.7 and the invention titled "Method and Communication Device for Protecting the Privacy of Identity Identification", which was filed with the State Intellectual Property Office of China on February 20, 2021, the entire contents of which are incorporated by reference in this application.

technical field

The present application relates to the field of communication, and, more particularly, to the field of methods and communication devices for protecting the privacy of identity identifiers.

Background technique

Security is a key element to consider in the definition and specification of mobile networks. In the process of ensuring the security of the mobile network, checking whether the user equipment (UE) has the right to access the network is the most important part. In this link, the verification of the terminal identity (UE identity, UE ID) and the main authentication are the two most important steps. The purpose of verifying the UE ID is to ensure that the UE is a legitimate user, that is, to ensure that the UE ID is valid. The purpose of primary authentication is to achieve mutual authentication between the UE and the network.

At present, in the registration and main authentication process, when the UE ID is invalid or valid, the attacker can attack the mobile network according to the unsecured message between the UE and the network side, resulting in user privacy leakage.

SUMMARY OF THE INVENTION

The present application provides a method and a communication device for protecting the privacy of an identity identifier. By changing the existing air interface message, the attacker cannot judge whether the UE ID is valid from the message from the network side, preventing the attacker from guessing from the air interface message and subsequent procedures. UE ID, which increases the difficulty of the attacker's attack.

In a first aspect, a method for protecting the privacy of an identity identifier is provided, comprising: a first device receiving a first request message from a second device, where the first request message is used by the second device to request to register in a network, the first request message being A request message includes a first identifier; the first device receives a first message from a third device, where the first message is used to request the second device to authenticate the network or to indicate that the second device fails to register in the network; The first device sends an authentication request message to the second device according to the first message, where the authentication request message includes a first authentication parameter, and the first authentication parameter is used for the second device to authenticate the network.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: the authentication request message includes a first random number.

In the above technical solution, for a second device that is not a legitimate user of the network, the network side randomly constructs an authentication request message so that the message type and message format of the air interface message returned to the second device are the same as the message type when the second device is a legitimate user. It is consistent with the message format, so that the attacker cannot guess the first identifier from the message type and message format, and it also prevents the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first logo.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: when the first message is used to request the second device to authenticate the network, the first authentication parameter is based on the The first parameter carried is generated; when the first message is used to indicate that the second device fails to register in the network, the first authentication parameter is randomly generated by the first device.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: in a situation where the first message is used to request the second device to authenticate the network, the first device determines the network according to the first message The second device belongs to a legitimate user of the network; in the case where the first message is used to indicate that the second device fails to register in the network, the first device determines according to the first message that the second device does not belong to the network legitimate user.

It should be noted that when the second device is not a legitimate user of the network, and other devices on the network side (such as the third device and the fourth device in this application) construct false authentication parameters, then the third device sends the third device to the third device. A device sends a first message for requesting the second device to authenticate the network, and the first device determines that the second device is a legitimate user according to the first message.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: in a situation where the first device determines that the second device belongs to a legitimate user of the network, the first authentication parameter corresponds to the first authentication parameter based on the first identification Root key generation.

In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: the first authentication parameter includes an authentication token and a home network expected response.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: the first parameter includes the first authentication parameter.

In a second aspect, a method for protecting identity privacy is provided, comprising: a fourth device receiving a second request message from a third device, where the second request message is used to request the second device to register in the network, the first The second request message includes the first identifier; the fourth device sends a second message to the third device, where the second message is used to request the second device to authenticate the network or to indicate that the second device fails to register in the network , the second message includes a second authentication parameter, and the second authentication parameter includes a parameter for the second device to authenticate the network.

In the above technical solution, for a second device that is not a legal user of the network, the network side randomly constructs an authentication request message so that the message type and message format of the air interface message returned to the second device are the same as the message when the second device is a legal user. The type and message format are consistent, so that the attacker cannot guess the first identifier from the message type and message format, and it also avoids the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain effective the first identification.

With reference to the second aspect, in some implementations of the second aspect, the method further includes: in a situation where the fourth device determines that the second device belongs to a legitimate user of the network according to the first identifier, the fourth device The second authentication parameter is generated according to the second parameter, and the second parameter includes the root key corresponding to the first identifier; when the fourth device determines according to the first identifier that the second device does not belong to a legitimate user of the network Next, the fourth device randomly generates the second authentication parameter.

With reference to the second aspect, in some implementations of the second aspect, the second parameter further includes a sequence value corresponding to the first identifier.

With reference to the second aspect, in some implementations of the second aspect, the method further includes: when the fourth device determines according to the first identifier that the second device does not belong to a legitimate user of the network, the second message for requesting the second device to authenticate the network.

With reference to the second aspect, in some implementations of the second aspect, the method further includes: the second authentication parameter includes at least one of the following: an authentication token, an expected response, and an authentication service function key.

In a third aspect, a method for protecting identity privacy is provided, comprising: a third device receiving a third request message from a first device, where the third request message is used by the second device to request registration in a network, and the third device The third request message includes the first identifier; the third device receives a second message from the fourth device, and the second message is used to request the second device to authenticate the network or to indicate that the second device fails to register in the network ; the third device sends a first message to the first device according to the second message, the first message includes a third authentication parameter, and the third authentication parameter includes a parameter for the second device to authenticate the network.

In the above technical solution, for a second device that is not a legal user of the network, the network side randomly constructs an authentication request message so that the message type and message format of the air interface message returned to the second device are the same as the message when the second device is a legal user. The type and message format are consistent, so that the attacker cannot guess the first identifier from the message type and message format, and it also avoids the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain effective the first identification.

With reference to the third aspect, in some implementations of the third aspect, the method further includes: in the case that the second message is used to request the second device to authenticate the network, the third authentication parameter is based on the The second parameter carried is generated; when the second message is used to indicate that the second device fails to register in the network, the third authentication parameter is randomly generated by the third device.

With reference to the third aspect, in some implementations of the third aspect, the method further includes: when the second message is used to request the second device to authenticate the network, the third device determines the network according to the second message The second device belongs to a legitimate user of the network; in the case where the second message is used to indicate that the second device fails to register in the network, the third device determines according to the second message that the second device does not belong to the network legitimate user.

With reference to the third aspect, in some implementations of the third aspect, the method further includes: in a situation where the third device determines that the second device belongs to a legitimate user of the network, the third authentication parameter corresponds to the first identifier based on Root key generation.

With reference to the third aspect, in some implementations of the third aspect, the method further includes: the third authentication parameter includes an authentication token and a home network expected response.

With reference to the third aspect, in some implementations of the third aspect, the method further includes: the second parameter includes the third authentication parameter.

In a fourth aspect, a method for protecting identity privacy is provided, comprising: a first device receiving a fourth request message from a second device, where the fourth request message is used to request a network to authenticate the second device, and the fourth request The message includes a first identifier; the first device receives a sixth response message from the third device, and the sixth response message is used to indicate that the network refuses to serve the second device; the first device sends a message to the second device according to the sixth response message. The second device sends a fourth response message, the fourth response message is used to indicate that the network refuses to serve the second device, the fourth response message includes a first cause value, the first cause value and whether the second device is Legitimate users belonging to the network are irrelevant.

In the above technical solution, when the second device fails to register with the network because it is not a legal user of the network, the network side selects a reason value irrelevant to whether the second device is a legal user, so that the attacker cannot obtain the message type and message format of the air interface message. It can prevent the attacker from guessing the first identifier from the air interface message, and also avoid the attacker guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first identifier. an identification.

With reference to the fourth aspect, in some implementations of the fourth aspect, the method further includes: the first device determines, according to the sixth response message, that the second device does not belong to a legitimate user of the network.

With reference to the fourth aspect, in some implementations of the fourth aspect, the method further includes: the first device generates the first cause value, or the first device receives the first cause value.

In a fifth aspect, a method for protecting identity privacy is provided, comprising: a fourth device receiving a fifth request message from a third device, where the fifth request message is used to request the network to authenticate the second device, the fifth request message The message includes a first identifier; the fourth device sends a fifth response message to the third device, where the fifth response message is used to indicate that the network refuses to serve the second device, and the fifth response message includes a second cause value, The second cause value is independent of whether the second device belongs to a legitimate user of the network.

In the above technical solution, when the second device fails to register with the network because it is not a legal user of the network, the network side selects a reason value irrelevant to whether the second device is a legal user, so that the attacker cannot obtain the message type and message format of the air interface message. It can prevent the attacker from guessing the first identifier from the air interface message, and also avoid the attacker guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first identifier. an identification.

With reference to the fifth aspect, in some implementations of the fifth aspect, the method further includes: the fourth device generating the second cause value.

In a sixth aspect, a method for protecting the privacy of an identity identifier is provided, comprising: a third device receiving a sixth request message from the first device, where the sixth request message is used to request the network to authenticate the second device, the sixth request message The message includes a first identifier; the third device receives a fifth response message from the fourth device, where the fifth response message is used to instruct the network to refuse to serve the second device; the third device sends a request to the second device according to the fifth response message. The first device sends a sixth response message, the sixth response message is used to indicate that the network refuses to serve the second device, the sixth response message includes a third cause value, the third cause value and whether the second device is Legitimate users belonging to the network are irrelevant.

In the above technical solution, when the second device fails to register with the network because it is not a legal user of the network, the network side selects a reason value irrelevant to whether the second device is a legal user, so that the attacker cannot obtain the message type and message format of the air interface message. It can prevent the attacker from guessing the first identifier from the air interface message, and also avoid the attacker guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first identifier. an identification.

With reference to the sixth aspect, in some implementations of the sixth aspect, the method further includes: determining, by the third device, that the second device does not belong to a legitimate user of the network according to the fifth response message.

With reference to the sixth aspect, in some implementations of the sixth aspect, the method further includes: the third device generates the third cause value, or the third device receives the third cause value.

In a seventh aspect, an apparatus for protecting the privacy of an identity identifier is provided, comprising: a transceiver module configured to receive a first request message from a second device, where the first request message is used by the second device to request registration in a network, The first request message includes a first identifier; the transceiver module is further configured to receive a first message from a third device, where the first message is used to request the second device to authenticate the network or to indicate that the second device is in The registration in the network fails; the transceiver module is further configured to send an authentication request message to the second device according to the first message, where the authentication request message includes a first authentication parameter, and the first authentication parameter is used for authentication of the second device the network.

In the above technical solution, for a second device that is not a legal user of the network, the network side randomly constructs an authentication request message so that the message type and message format of the air interface message returned to the second device are the same as the message when the second device is a legal user. The type and message format are consistent, so that the attacker cannot guess the first identifier from the message type and message format, and it also avoids the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain effective the first identification.

With reference to the seventh aspect, in some implementations of the seventh aspect, the apparatus further includes: when the first message is used to request the second device to authenticate the network, the first authentication parameter is based on the The first parameter carried is generated; when the first message is used to indicate that the second device fails to register in the network, the first authentication parameter is randomly generated by the first device.

With reference to the seventh aspect, in some implementations of the seventh aspect, the apparatus further includes a processing module configured to: in the case that the first message is used to request the second device to authenticate the network, according to the first message A message determines that the second device belongs to a legitimate user of the network; in the case where the first message is used to indicate that the second device fails to register in the network, it is determined according to the first message that the second device does not belong to the network. legitimate user.

With reference to the seventh aspect, in some implementations of the seventh aspect, the apparatus further includes: in the case that the first message is used to request the second device to authenticate the network, the first authentication parameter corresponds to the first identification based on Root key generation.

With reference to the seventh aspect, in some implementations of the seventh aspect, the apparatus further includes: the first authentication parameter includes an authentication token and a home network expected response.

With reference to the seventh aspect, in some implementations of the seventh aspect, the apparatus further includes: the first parameter includes the first authentication parameter.

In an eighth aspect, an apparatus for protecting the privacy of an identity identifier is provided, comprising: a transceiver module configured to receive a second request message from a third device, where the second request message is used to request the second device to register in the network, The second request message includes the first identifier;

The transceiver module is further configured to send a second message to the third device, where the second message is used to request the second device to authenticate the network or to indicate that the second device fails to register in the network, the second message A second authentication parameter is included, the second authentication parameter including a parameter for the second device to authenticate the network.

In the above technical solution, for a second device that is not a legal user of the network, the network side randomly constructs an authentication request message so that the message type and message format of the air interface message returned to the second device are the same as the message when the second device is a legal user. The type and message format are consistent, so that the attacker cannot guess the first identifier from the message type and message format, and it also avoids the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain effective the first identification.

With reference to the eighth aspect, in some implementations of the eighth aspect, the apparatus further includes a processing module, the processing module is configured to: determine, at the fourth device, that the second device does not belong to the legal system of the network according to the first identifier In the case of the user, the second authentication parameter is generated according to the second parameter, and the second parameter includes the root key corresponding to the first identification; in the fourth device, according to the first identification, it is determined that the second device does not belong to the network In the case of a legitimate user, the second authentication parameter is randomly generated.

With reference to the eighth aspect, in some implementations of the eighth aspect, the processing module is further configured to, when the fourth device determines according to the first identifier that the second device does not belong to a legitimate user of the network, the first The second message is used to request the second device to authenticate the network.

With reference to the eighth aspect, in some implementations of the eighth aspect, the apparatus further includes: the second authentication parameter includes at least one of the following: an authentication token, an expected response, and an authentication service function key.

In a ninth aspect, an apparatus for protecting the privacy of an identity identifier is provided, comprising: a transceiver module configured to receive a third request message from the first device, where the third request message is used by the second device to request registration in the network, The third request message includes a first identifier; the transceiver module is further configured to receive a second message from the fourth device, where the second message is used to request the second device to authenticate the network or to indicate that the second device is in The registration in the network fails; the third device sends a first message to the first device according to the second message, where the first message includes a third authentication parameter, and the third authentication parameter includes a parameter for the second device to authenticate the network parameter.

In the above technical solution, for a second device that is not a legitimate user of the network, the network side randomly constructs an authentication request message so that the message type and message format of the air interface message returned to the second device are the same as the message type when the second device is a legitimate user. It is consistent with the message format, so that the attacker cannot guess the first identifier from the message type and message format, and it also prevents the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first logo.

In conjunction with the ninth aspect, in some implementations of the ninth aspect, the device further includes:

When the second message is used to request the second device to authenticate the network, the third authentication parameter is generated based on the second parameter carried in the second message;

When the second message is used to indicate that the second device fails to register in the network, the third authentication parameter is randomly generated by the third device.

With reference to the ninth aspect, in some implementations of the ninth aspect, the apparatus further includes a processing module, and the processing module is configured to, in the case that the second message is used to request the second device to authenticate the network, according to the second The message determines that the second device belongs to the legal user of the network; in the case where the second message is used to indicate that the second device fails to register in the network, it is determined according to the second message that the second device does not belong to the legal user of the network. user.

With reference to the ninth aspect, in some implementations of the ninth aspect, the apparatus further includes: in a situation where the third device determines that the second device belongs to a legitimate user of the network, the third authentication parameter corresponds to the first identifier based on Root key generation.

With reference to the ninth aspect, in some implementations of the ninth aspect, the apparatus further includes: the third authentication parameter includes an authentication token and a home network expected response.

With reference to the ninth aspect, in some implementations of the ninth aspect, the apparatus further includes: the second parameter includes the third authentication parameter.

In a tenth aspect, an apparatus for protecting the privacy of an identity identifier is provided, comprising: a transceiver module for receiving a fourth request message from a second device, where the fourth request message is used to request the network to authenticate the second device, the The four-request message includes the first identifier; the transceiver module is further configured to receive a sixth response message from the third device, where the sixth response message is used to indicate that the network refuses to serve the second device; the transceiver module is also configured to use sending a fourth response message to the second device according to the sixth response message, the fourth response message is used to indicate that the network refuses to serve the second device, the fourth response message includes a first cause value, the first The reason value is independent of whether the second device belongs to a legitimate user of the network.

In the above technical solution, when the second device fails to register with the network because it is not a legal user of the network, the network side selects a reason value irrelevant to whether the second device is a legal user, so that the attacker cannot obtain the message type and message format of the air interface message. It can prevent the attacker from guessing the first identifier from the air interface message, and also avoid the attacker guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first identifier. an identification.

With reference to the tenth aspect, in some implementations of the tenth aspect, the apparatus further includes a processing module configured to determine, according to the sixth response message, that the second device does not belong to a legitimate user of the network.

With reference to the tenth aspect, in some implementations of the tenth aspect, the processing module is further configured to generate the first cause value, or the transceiver module is further configured to receive the first cause value.

In an eleventh aspect, an apparatus for protecting the privacy of an identity identifier is provided, comprising: a transceiver module for receiving a fifth request message from a third device, where the fifth request message is used to request the network to authenticate the second device, the The fifth request message includes a first identifier; the transceiver module is further configured to send a fifth response message to the third device, where the fifth response message is used to indicate that the network refuses to serve the second device, and the fifth response message A second cause value is included, the second cause value being independent of whether the second device belongs to a legitimate user of the network.

In the above technical solution, when the second device fails to register with the network because it is not a legal user of the network, the network side selects a reason value irrelevant to whether the second device is a legal user, so that the attacker cannot obtain the message type and message format of the air interface message. It can prevent the attacker from guessing the first identifier from the air interface message, and also avoid the attacker guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first identifier. an identification.

With reference to the eleventh aspect, in some implementations of the eleventh aspect, the apparatus further includes a processing module, where the processing module generates the second cause value, or the transceiver module is further configured to receive the second cause value.

A twelfth aspect provides an apparatus for protecting the privacy of an identity identifier, comprising: a transceiver module for receiving a sixth request message from a first device, where the sixth request message is used to request the network to authenticate the second device, the The sixth request message includes the first identifier; the transceiver module is further configured to receive a fifth response message from the fourth device, where the fifth response message is used to indicate that the network refuses to serve the second device; the transceiver module is further configured to is used to send a sixth response message to the first device, where the sixth response message is used to indicate that the network refuses to serve the second device, wherein, in the case that the second device belongs to a legitimate user of the network, the sixth response message is used to indicate that the network refuses to serve the second device. The response message includes a first cause value, and the sixth response message includes a third cause value, and the third cause value is independent of whether the second device belongs to a legitimate user of the network.

In the above technical solution, when the second device fails to register with the network because it is not a legal user of the network, the network side selects a reason value irrelevant to whether the second device is a legal user, so that the attacker cannot obtain the message type and message format of the air interface message. It can prevent the attacker from guessing the first identifier from the air interface message, and also avoid the attacker guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective first identifier. an identification.

With reference to the twelfth aspect, in some implementations of the twelfth aspect, the apparatus further includes a processing module, and the processing module is configured to generate the third cause value, or the transceiver module is further configured to receive the third cause value.

With reference to the twelfth aspect, in some implementations of the twelfth aspect, the apparatus further includes: the processing module is further configured to determine, according to the fifth response message, that the second device does not belong to a legitimate user of the network.

A thirteenth aspect provides a communication device, comprising: a processor and a memory; the memory for storing a computer program; the processor for executing the computer program stored in the memory, so that the communication device executes the first The methods and embodiments of any one of the one to sixth aspects.

A fourteenth aspect provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program runs on a computer, the computer is made to execute any one of the first to sixth aspects. Methods and embodiments described in one aspect.

A fifteenth aspect provides a chip system, comprising: a processor for calling and running a computer program from a memory, so that a communication device installed with the chip system performs any one of the first to sixth aspects. methods and examples described.

Description of drawings

FIG. 1 shows a network architecture suitable for this embodiment of the present application.

FIG. 2 shows another network architecture suitable for this embodiment of the present application.

FIG. 3 shows a schematic interaction diagram of a registration and main authentication process.

FIG. 4 shows a schematic interaction diagram of another registration and main authentication process.

FIG. 5 shows a schematic interaction diagram of yet another registration and main authentication process.

FIG. 6 shows a schematic interaction diagram of an example of the method for protecting the privacy of an identity identifier of the present application.

FIG. 7 shows a schematic interaction diagram of still another example of the method for protecting the privacy of an identity identifier of the present application.

FIG. 8 shows a schematic interaction diagram of still another example of the method for protecting the privacy of an identity identifier of the present application.

FIG. 9 shows a schematic interaction diagram of still another example of the method for protecting the privacy of an identity identifier of the present application.

FIG. 10 shows a schematic interaction diagram of still another example of the method for protecting the privacy of an identity identifier of the present application.

FIG. 11 shows a schematic interaction diagram of still another example of the method for protecting the privacy of an identity identifier of the present application.

FIG. 12 shows a schematic block diagram of an example of a communication device for protecting the privacy of an identity identifier of the present application.

FIG. 13 shows a schematic block diagram of yet another example of the communication apparatus for protecting the privacy of an identity identifier of the present application.

Detailed ways

The technical solutions provided in the embodiments of the present application can be applied to various communication systems, for example: a global system for mobile communications (GSM) system, a code division multiple access (CDMA) system, a wideband code division multiple access (CDMA) system, address (wideband code division multiple access, WCDMA) system, general packet radio service (general packet radio service, GPRS), long term evolution (long term evolution, LTE) system, LTE frequency division duplex (frequency division duplex, FDD) system, LTE time division duplex (TDD), universal mobile telecommunication system (UMTS), worldwide interoperability for microwave access (WiMAX) communication system, 5th generation (5G) ) system or new radio (NR) or future 3GPP system, etc.

Generally speaking, traditional communication systems support a limited number of connections and are easy to implement. However, with the development of communication technology, mobile communication systems will not only support traditional communication, but also support, for example, device to device (device to device, D2D) communication, machine to machine (M2M) communication, machine type communication (MTC), vehicle to everything (V2X) communication (also known as vehicle network communication), for example, Vehicle-to-vehicle (V2V) communication (also known as vehicle-to-vehicle communication), vehicle-to-infrastructure (V2I) communication (also known as vehicle-to-infrastructure communication), vehicle and pedestrian ( Vehicle to pedestrian, V2P) communication (also known as vehicle-to-person communication), vehicle to network (V2N) communication (also known as vehicle-to-network communication).

FIG. 1 provides a network architecture, and each network element that may be involved in the network architecture will be described below with reference to FIG. 1 .

1. User equipment (UE): can be called terminal equipment, terminal, access terminal, subscriber unit, subscriber station, mobile station, mobile station, remote station, remote terminal, mobile equipment, user terminal, wireless communication equipment, User Agent or User Device. The UE may also be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a wireless communication capability handheld devices, computing devices or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in 5G networks or future evolution of public land mobile networks (PLMN) or non-terrestrial The terminal equipment of the network (Non-Terrestrial Networks, NTN), etc., can also be terminal equipment, logical entities, intelligent equipment, such as terminal equipment such as mobile phones and intelligent terminals, or communication equipment such as servers, gateways, base stations, controllers, or objects. Internet-connected devices, such as sensors, electricity meters, water meters and other Internet of things (IoT) devices. It can also be a drone with communication capabilities (Unmanned Aerial Vehicle or Uncrewed Aerial Vehicle, UAV). This embodiment of the present application does not limit this.

2. Universal mobile telecommunications system (UMTS) terrestrial radio access network (UMTS terrestrial radio access network, UTRAN): such as the third generation (3rd generation, 3G)/second generation (2nd generation, 2G) connection access the network.

3. Global system for mobile communication (GSM)/enhanced data rate for GSM evolution (EDGE) terrestrial radio access network (GSM/EDGE terrestrial radio access network, GERAN): such as 3G /2G access network.

4. Evolved universal terrestrial radio access network (E-UTRAN): such as the fourth generation (4th generation, 4G) access network.

5. Serving gateway (S-GW) entity: It can be responsible for user plane processing, reasoning and forwarding of data packets and other functions.

6. Public data network (PDN) gateway (PDN gateway, P-GW) entity: user plane data link anchor point between the 3rd Generation Partnership Project (3rd Generation Partnership Project, 3GPP) and non-3GPP networks , which can be responsible for managing data routing between 3GPP and non-3GPP.

7. Mobility Management Entity (MME): It is mainly responsible for functions such as mobility management, bearer management, user authentication and authentication, and selection of S-GW and P-GW.

8. Operator's IP services: For example, it can be an IP multimedia subsystem (IMS), and IMS is a general network architecture that provides multimedia services based on an Internet Protocol (Internet Protocol, IP) network; another example It can be a packet switching service (packet switching service, PSS) and so on.

9. Policy and charging rules function (PCRF): It is the policy and charging control policy decision point of service data flow and IP bearer resources. It can select and provide policy and charging execution function units. Available policy and charging control decisions.

10. Home subscriber server (HSS): can support the main user database of the IMS network entity used to handle calls/sessions. The HSS can include user profiles, perform user authentication and authorization, and provide information about Information about the user's physical location.

11. Serving general packet radio service (GPRS) support node (serving GPRS support node, SGSN): can complete routing and forwarding of packet data packets, mobility management, session management, logical link management, authentication and encryption, CDR generation and output functions.

In this network architecture, the LTE-Uu interface is the reference point between the terminal and the E-UTRAN; the S1-U interface is the reference point between the E-UTRAN and the S-GW entity; the N5 interface is the S-GW entity and the P-GW entity. - the reference point between the GW entities; the SGi interface is the reference point between the P-GW entity and the IMS; the Rx interface is the reference point between the IMS and the PCRF; the Gx interface is the reference point between the P-GW entity and the PCRF ; Control plane interface S1-MME connects MME with E-UTRAN, similar to the control part of the wireless network layer in UMTS network, etc.; S11 interface is the reference point between MME and S-GW entity; S12 interface is UTRAN/GERAN The S4 interface is the reference point between the SGSN and the S-GW entity; the S6a interface is the reference point between the MME and the HSS; the S3 interface is the reference point between the MME and the SGSN.

FIG. 2 provides another network architecture, and each network element that may be involved in the network architecture will be described below with reference to FIG. 2 .

1. UE: It has been introduced above with reference to FIG. 1 , and it is not repeated here for brevity.

2. Access network (AN): It provides network access functions for authorized users in a specific area, and can use different quality transmission tunnels according to user levels and business needs. The access network may be an access network using different access technologies. There are two types of current radio access technologies: 3GPP access technologies (such as those employed in 3G, 4G or 5G systems) and non-3rd Generation Partnership Project (non-3GPP) access technologies. 3GPP access technology refers to the access technology that conforms to 3GPP standard specifications. The access network using 3GPP access technology is called Radio Access Network (RAN). Among them, the access network equipment in the 5G system is called Next generation Node Base station (gNB). A non-3GPP access technology refers to an access technology that does not conform to 3GPP standard specifications, for example, an air interface technology represented by an access point (AP) in wifi.

An access network that implements access network functions based on wireless communication technology can be called a radio access network (RAN). The radio access network can manage radio resources, provide access services for terminals, and then complete the forwarding of control signals and user data between the terminal and the core network.

The radio access network can be, for example, a base station (NodeB), an evolved NodeB (evolved NodeB, eNB or eNodeB), a base station (gNB) in a 5G mobile communication system, a base station in a future mobile communication system, or an AP in a WiFi system, etc., It can also be a wireless controller in a cloud radio access network (CRAN) scenario, or the access network device can be a relay station, an access point, an in-vehicle device, a wearable device, and a network in the future 5G network equipment or network equipment in a future evolved PLMN network, etc. The embodiments of the present application do not limit the specific technology and specific device form adopted by the wireless access network device.

3. Access and mobility management function (AMF) entity: mainly used for mobility management and access management, etc., and can be used to implement mobility management entity (mobility management entity, MME) functions in addition to sessions Other functions other than management, such as lawful interception, or access authorization (or authentication) functions.

4. Session management function (SMF) entity: mainly used for session management, UE IP address allocation and management, selection of manageable user plane functions, policy control, or termination point of charging function interface and downlink data notification, etc. .

5. User plane function (User Plane Function, UPF) entity: that is, a data plane gateway. It can be used for packet routing and forwarding, or quality of service (QoS) processing of user plane data. User data can be accessed to a data network (DN) through this network element. In this embodiment of the present application, it can be used to implement the function of the user plane gateway.

6. Data Network (DN): A network for providing data transmission. For example, an operator's service network, an Internet (Internet) network, a third-party service network, and the like.

7. Authentication server function (AUSF) entity: mainly used for user authentication, etc.

8. Network exposure function (NEF) entity: used to securely open services and capabilities provided by the 3GPP network function to the outside.

9. Network storage function ((network function (NF) repository function, NRF) entity: used to store the network function entity and the description information of the services it provides, as well as support service discovery, network element entity discovery, etc.

10. Policy control function (PCF) entity: a unified policy framework for guiding network behavior, providing policy rule information for control plane function network elements (such as AMF, SMF network elements, etc.).

11. Unified data management (UDM) entity: used to handle user identification, access authentication, registration, or mobility management, etc.

12. Application function (AF) entity: used to perform data routing affected by applications, access network open function network elements, or interact with the policy framework to perform policy control, etc. For example, it may be a V2X application server, a V2X application enabling server, or a drone server (which may include a drone monitoring server, or a drone application service server).

In the network architecture shown in Figure 2, the N1 interface is the reference point between the terminal and the AMF entity; the N2 interface is the reference point between the AN and the AMF entity, used for non-access stratum (NAS) messages Sending, etc.; N3 interface is the reference point between (R)AN and UPF entity, used to transmit user plane data, etc.; N4 interface is the reference point between SMF entity and UPF entity, used to transmit tunnels such as N3 connections Identification information, data buffer indication information, and downlink data notification messages and other information; the N6 interface is the reference point between the UPF entity and the DN, and is used to transmit data on the user plane.

In addition to the network elements mentioned in FIG. 1 and FIG. 2 , the present application also relates to an entity full-anchor function entity (Security Anchor Function, SEAF).

It should be understood that the network architecture shown in FIG. 1 and FIG. 2 can be applied to the embodiments of the present application. In addition, the network architecture applicable to the embodiments of the present application is not limited to this, and any network architecture that can implement the functions of the above network elements All are applicable to the embodiments of the present application.

It should also be understood that the AMF entity, SMF entity, UPF entity, NEF entity, AUSF entity, NRF entity, PCF entity, UDM entity shown in FIG. 1 or FIG. 2 , and the SEAF entity also involved in this application can be understood as the core Network elements used to implement different functions in the network, for example, can be combined into network slices as needed. These core network elements may be independent devices, or may be integrated into the same device to implement different functions, which is not limited in this application. It should be noted that the above-mentioned "network element" may also be referred to as an entity, a device, an apparatus, or a module, etc., which is not particularly limited in this application.

It should also be understood that the above naming is only used to distinguish different functions, and does not mean that these network elements are independent physical devices. This application does not limit the specific form of the above network elements, for example, they can be integrated in the same physical device , or they can be different physical devices. In addition, the above nomenclature is only for the convenience of distinguishing different functions, and should not constitute any limitation to the present application, and the present application does not exclude the possibility of adopting other nomenclature in the 5G network and other future networks. For example, in a 6G network, some or all of the above-mentioned network elements may use the terms in 5G, and may also use other names. A unified description is provided here, and details are not repeated below.

It should also be understood that the name of the interface between each network element in FIG. 1 or FIG. 2 is just an example, and the name of the interface in a specific implementation may be other names, which are not specifically limited in this application. In addition, the names of the messages (or signaling) transmitted between the above network elements are only an example, and do not constitute any limitation on the functions of the messages themselves.

In the process of defining and establishing a specification of a mobile network, security is regarded as a key consideration and a core issue, and the most important step is to verify whether the UE is authorized to access the network. To achieve this goal, UE ID verification and primary authentication are the two most important steps. The purpose of UE ID verification is to ensure that the UE is a legitimate user, that is, the UE ID is valid. The purpose of primary authentication is to achieve mutual authentication between the UE and the network. The UE and the network side maintain the UE ID and its corresponding root key respectively. It should be noted that this application uses authentication and key agreement (AKA) under the 5G system as the background technology for description, and the technical solution of this application is also applicable to the extensible authentication protocol-authentication and key agreement (extensible key agreement). authentication protocol-AKA, EAP-AKA), Extensible Authentication Protocol-Transport Layer Security (EAP-Transport Layer Security, EAP-TLS) and other authentication methods, or can also be applied to other authentication methods. For convenience, this application Only AKA is used as an example to illustrate, but the comparison is not limited.

For the convenience of description, some terms involved in this application are described below.

User permanent identifier (subscription permanent identifier, SUPI), user concealed identifier (subscription concealed identifier, SUCI), sequence number (sequence number, SQN), home network authentication vector (home environment authentication vector, HE AV), random number (random, RAND), authentication token (AUTN), response (response, RES), expected response (XRES), AUSF key (Kausf), authentication management field (AMF), access network authentication vector (serving environment authentication vector, SE AV), message authentication code (message authentication code, MAC), home network expected response (home expected response, HXRES), expected message authentication code (expected message authentication code, XMAC), mobile country code ( mobile country code (MCC), mobile network code (MNC), mobile subscriber identification number (MSIN), home network expected response (HXRES), message authentication code - resynchronization (message authentication code-resynchronization, MAC-S).

FIG. 3 shows a schematic interaction diagram of the registration and main authentication processes when the UE is a legitimate user. As shown in Figure 3:

S301, the UE sends an N1 message (N1 message) to the SEAF.

During the initial registration process, the UE sends a registration request message to the SEAF, and the message carries the UE ID. The UE ID can be SUPI, SUCI or other identifiers. Among them, SUPI is the permanent identity of the UE, and SUCI is the hidden identity of the UE; it can be understood that the SUCI can be regarded as the encrypted identity of the SUPI.

S302, the SEAF sends an authentication request message (Nausf auth request) to the AUSF, and the message carries the UE ID.

S303, the AUSF sends an authentication request message (Nudm auth request) to the UDM, and the message carries the UE ID.

S304, when the UE ID received in the UDM is SUCI, it is necessary to parse the SUCI into SUPI first, and check whether the SUPI is valid in the database. For example, when the UDM can find the SUPI in the database, the SUPI is considered valid; when the SUPI cannot be found, the SUPI is considered invalid.

S305, when the SUPI is valid, the UDM sends an authentication response message (Nudm auth response) to the AUSF, and the authentication response message includes the 5G HE AV. Optionally, the authentication response message may also include the SUPI.

Specifically, when the SUPI is valid, the UDM searches for the root key and SQN corresponding to the UE, generates a random number RAND, and calculates and constructs the home network authentication vector HE AV, which includes RAND, AUTN and XRES*. The UDM also needs to calculate the Kausf and send the authentication vector and Kausf to the AUSF. Among them, RAND is 128bit, and the format of AUTN is

AK and SQN are 48 bits, AMF (authentication management field) is 16 bits, MAC length is 64 bits, and XRES* is 128 bits.

It should be noted that when the identity identifier carried in step S303 is SUCI, the authentication response message may also carry SUPI; when the identity identifier carried in step S303 is SUPI, the authentication response message does not need to carry the information element SUPI .

It should be understood that two-way authentication is performed between the UE and the network side, and the network side first calculates an authentication vector for the UE to verify the network side. After the UE successfully verifies the network side, the UE calculates an authentication vector, which is used for the network to verify the UE.

S306, the AUSF calculates the visited network authentication vector (SE AV) according to the home network authentication vector (HE AV), and sends an authentication response message (nausf auth response) to the SEAF, and the message carries the visited network authentication vector (SE AV). The Visited Network Authentication Vector (SE AV) includes RAND, AUTN and HXRES*, where HXRES* is obtained after hashing XRES*.

S307, the SEAF sends an authentication request message (auth repuest) to the UE, and the message carries RAND, AUTN and HXRES*.

S308, after receiving the authentication request message (auth response), the UE authenticates the network, and one of the following situations may occur:

Possible case one, the authentication fails. Specifically, the authentication failure also includes the following two situations:

In case 1, the UE calculates the XMAC according to the root key and the parameters in the AUTN message. When the XMAC and the MAC are not equal, the UE returns an authentication failure message to the network side. The authentication failure message includes the reason value, which is the MAC failure. , the process ends.

In case 2, the UE calculates the XMAC according to the root key and the parameters in the AUTN message. When the XMAC is equal to the MAC, but the SQN is not within the correct range, the UE replies to the network with an authentication failure message, which includes the cause value. , the reason value is synchronization failure. The UE calculates the synchronization parameter AUTS, AUTS=Conc(SQNMS)||MAC-S,

MAC-S=f1*K(SQNMS||RAND||AMF). Among them, Conc A||B means connecting A and B together, means that SQNMS represents the SQN on the UE side,

Indicates A XOR B, f5*(A) means using f5* algorithm for A, f1*(A) means using f1* algorithm for A, f5*K means using f5* algorithm with K as the input key, f1* K means that K is the input key when using the f1* algorithm. It should be noted that both A and B here are character data. The authentication failure message also carries the AUTS. If SEAF receives the authentication failure message, it sends AUTS to UDM via AUSF. When the UDM verifies that the AUTS is correct, the UDM re-initiates the authentication, that is, re-calculates the authentication vector and sends it to the AUSF; otherwise, the process ends.

In the second possible case, the authentication is passed.

Specifically, when the XMAC and the MAC are equal and the SQN information matches, the UE replies an authentication success message to the network side, and the message carries the authentication vector (RES*) calculated by the UE, and triggers subsequent steps.

S309, SEAF and AUSF verify whether the authentication vector sent by the UE is correct, that is, the network side authenticates the UE.

Specifically, SEAF first performs hash calculation on RES* to obtain HRES*, and when HRES=HXRES*, the SEAF check is passed, and RES* is sent to AUSF. AUSF compares RES* and XRES*, and when RES*=XRES*, it means that the AUSF check is passed.

S310a, when the network side (SEAF/AUSF) fails to authenticate the UE, the SEAF sends an authentication reject message (authentication reject) to the UE.

Or, in S310b, when the network side authenticates the UE successfully, after the network side completes the relevant registration process, the SEAF sends a registration accept message (registration accept) to the UE.

FIG. 4 shows a schematic interaction diagram of the registration and main authentication processes when the UE is an illegal user. As shown in Figure 4:

S401 to S404 are the same as S301 to S304 in FIG. 3 , and details are not repeated here.

S405, when the SUPI is invalid, the UDM returns an error response message (error response) to the AUSF, which can be carried in the error response message, for example, the reason value is udm-error-unknown-subscription.

S406, AUSF receives an error response message (error response), and sends an error response message (error response) to SEAF, where the error response message carries a cause value, for example, the cause value may be udm-error-unknown-subscription.

S407, the SEAF sends a registration failure message (registration reject) to the UE, and the registration failure message may carry a cause value, for example, the cause value is 3, indicating that the UE is an illegal UE.

Fig. 5 shows a schematic interaction diagram of the network side sending a registration rejection message to the UE when the UE is a legitimate user. As shown in Figure 5:

S501 to S504 are the same as S301 to S304 in FIG. 3 , and details are not repeated here.

S505, the network refuses to serve the current UE, and the specific implementation may be in multiple ways, such as S505a or S505b or S505c below.

S505a, caused by the UE identification reason: for example, the UE ID is invalid. The UDM returns a failure response message to the AUSF, and the failure response message carries a cause value, for example, the cause value can be udm-error-unknown-subscription;

S505b, caused by the UE contracting reason: for example, the UE is in arrears or enters the blacklist of the network. The UDM may still return a failure response message to the AUSF, and the failure response message carries the cause value. For example, the cause value can be PLMN not allowed or 5GS services not allowed;

S505c, caused by network reasons: for example, network congestion or unauthorized service network. The UDM may still return a failure response message to the AUSF, and the failure response message carries the cause value, for example, Congestion or Serving network not authorized.

It should be understood that after the UDM receives the UE ID, it needs to judge whether the UE identity is valid, whether the network is available, and whether the UE has signed a contract. When the judgment results of the above conditions are all "Yes", the UDM will return to the UE. Authentication request message, otherwise, the UDM will return a registration rejection message to the UE, and the registration rejection message carries a reason value, which indicates that the reason for the UE registration failure corresponds to the condition that the UE does not meet. Specifically, for the situation that the network refuses to serve the UE, see three possible scenarios in step S505.

It should be understood that the order in which the UDM judges the UE according to the above conditions is not fixed, but is adjusted based on implementation.

S506, the AUSF receives the error message, and sends a failure response message to the SEAF, the message carries a cause value, and the cause value is consistent with the cause value carried in the failure response message in step S505.

S507, the SEAF sends a registration failure message to the UE, the message carries a cause value, and the cause value is consistent with the cause value carried in the failure response message in step S505.

It can be known from Fig. 3 and Fig. 4 that when the UE ID is valid or invalid, the messages (that is, S307 and S407) returned by the SEAF to the UE are different. The above messages are all unsecured messages transmitted over the air interface, and attackers can obtain the messages. Therefore, an attacker can use this vulnerability to determine whether the UEID is valid through the reply message. Specific steps are as follows:

First, the attacker constructs the UE ID. For example, the configuration of SUPI is MCC+MNC+MSIN. Among them, MCC and MNC are public information, which can be obtained by attackers. After the attacker constructs possible MSINs, the combination becomes SUPI. The composition of SUCI is SUPI type+MCC+MNC+routing indicator+protection scheme ID+home network public key id+scheme output. For SUCI, except scheme output, other information elements can be considered as public information, which can be obtained by attackers. After the attacker constructs a possible MSIN, the scheme output is calculated using the chosen encryption algorithm. Subsequently, the attacker sends a registration request message to SEAF, which carries the UE ID. The attacker obtains the return message of SEAF from the air interface. When the returned message is an authentication request message and carries AUTN and RAND, the representative constructed SUPI is valid. When the returned message is a registration failure message and the cause value is illegal UE, the SUPI constructed on behalf of the user is invalid.

In other words, in the registration and main authentication procedures, when the UE ID is invalid or valid, the messages exchanged between the UE and the network side are different. Currently, an attacker can construct a UE ID and send it to the network. Through the reply message from the network to the UE, it is judged whether the constructed UE ID is valid, resulting in the disclosure of identity privacy privacy.

Specifically, according to the above attack method, an attacker can traverse and construct possible SUPIs and try them in sequence. Thus, the attacker obtains the SUPI data set of all users of the target operator, and accordingly obtains the number of users of the target operator. Alternatively, after obtaining a valid SUPI, the attacker attacks the UE in combination with other attack methods (such as a tracking (likability) attack, continuously tracking the location of the UE corresponding to the SUPI, etc.), resulting in leakage of user privacy.

The technical solutions in the present application will be described below with reference to the accompanying drawings.

The method 600 for protecting the privacy of an identity identifier according to an embodiment of the present application will be described in detail below with reference to FIG. 6 . FIG. 6 is a schematic interaction diagram of the method 600 of the present application.

S601, the second device sends a first request message to the first device, where the first request message is used for the second device to register in the network. The first request message includes a first identifier.

It should be noted that, in the network architecture of this application, the first device may belong to the first network, for example, a roaming network, and the third device and the fourth device belong to a second network, such as a home network; or, It is also possible that the first device, the third device and the fourth device all belong to the second network, for example, the home network. As an example, the SEAF belongs to the network, that is, the roaming network, and the AUSF and UDM belong to the second network, that is, the home network; or, as an example, the SEAF, AUSF, and UDM all belong to the second network, the home network. This application does not limit the situation that the first device, the third device and the fourth device belong to the network.

It should be understood that, for convenience, the SEAF is used as the first device for description in this application, and the first device may also be other devices or network elements with the same or similar functions, which is not limited in this application.

It should be understood that when the second device is a normal terminal device, the first identification is an identification corresponding to the second device, which may be the identification of the second device, including the SUPI and UE ID mentioned in this application, and also include Other identifiers with the same or similar function. The network side stores relevant information about the first identifier. Therefore, the first identification is valid. When the second device is an attack device deployed by an attacker, the part of the first identifier that is not public information is fabricated by the attacker. The network side does not store relevant information about the first identifier. Therefore, the first identification may be invalid.

S602, the first device sends a third request message to the third device, where the third request message also includes the first identifier.

It should be understood that, for convenience, the AUSF is used as the third device for description in the embodiments of this application, and the third device may also be other devices or network elements with the same or similar functions, which is not limited in this application.

Exemplarily, the third request message may be used to request the network to initiate an authentication process or to request the second device to register with the network.

S603, the third device sends a second request message to the fourth device, where the second request message also includes the first identifier.

It should be understood that, for convenience, the UDM is used as the fourth device for description in the embodiments of this application, and the fourth device may also be other devices or network elements with the same or similar functions, which is not limited in this application.

Exemplarily, the second request message may be used to request the network to initiate an authentication process or to request the second device to register with the network.

S604, generating authentication parameters.

The specific implementation of S604 may be in various manners, for example, S604a or S604b or S604c below.

S604a, the fourth device generates a second authentication parameter.

Specifically, when the fourth device determines that it is necessary to request the second device to authenticate the network, the fourth device generates the second authentication parameter according to the second parameter, and the second parameter includes the root key corresponding to the first identifier; When the fourth device determines that the registration of the second device in the network fails, the fourth device randomly generates the second authentication parameter.

Exemplarily, the method for the fourth device to determine that it is necessary to request the second device to authenticate the network may be that the fourth device verifies that the user identifier is valid. Exemplarily, when the fourth device can find the SUPI in the database, it considers that the SUPI is valid, that is, the user ID is valid;

Exemplarily, the method for the fourth device to determine that the registration of the second device in the network fails may be that the fourth device verifies that the user identifier is invalid. Exemplarily, when the fourth device cannot find the SUPI in the database, it considers that the SUPI is invalid, that is, the user ID is invalid.

S604b, the third device generates a third authentication parameter.

Specifically, when the second message is used to request the second device to authenticate the network, the third authentication parameter is generated based on the second parameter carried in the second message; the second message is used to indicate the second When the device fails to register in the network, the third authentication parameter is randomly generated by the third device.

Exemplarily, when the fourth device determines according to the first identifier that the second device does not belong to a legitimate user of the network, the second message indicates that the second device fails to register in the network, and the optional carrying reason value is Invalid user ID. The third device determines, according to the second message, that the registration of the second device in the network fails, and the reason for the failure is an illegal user identifier, and randomly generates a third authentication parameter.

S604c, the first device generates a first authentication parameter.

Specifically, when the first message is used to request the second device to authenticate the network, the first authentication parameter is generated based on the first parameter carried in the first message; the first message is used to indicate the second device In the event that the device fails to register in the network, the first authentication parameter is randomly generated by the first device.

Exemplarily, when the third device determines that the second device does not belong to a legitimate user of the network, the first message indicates that the second device fails to register in the network, and the optional cause value is an illegal user identifier. . The first device determines, according to the first message, that the registration of the second device in the network fails, and the reason for the failure is an illegal user identifier, and randomly generates a third authentication parameter.

S605, the fourth device sends the second message to the third device,

Corresponding to S604a, that is, when S604a is executed, the second message includes the second authentication parameter; when S604a is not executed, the second message is used to indicate that the second device fails to register in the network, the second message including the failure reason value, etc.;

S606, the third device sends the first message to the first device,

Corresponding to S604b, that is, when S604b is executed, the first message includes the third authentication parameter; when S604a is not executed, the first message is used to indicate that the second device fails to register in the network. Including the failure reason value, etc.;

S607: The first device sends an authentication request message to the second device, where the authentication request message includes the first authentication parameter.

Corresponding to S604C, that is, when S604C is executed, the first message includes the third authentication parameter.

The authentication request message may further include a first random number, and the first random number may be generated based on the root key and sequence value corresponding to the first identifier, or may also be in other manners, which are not limited in this application.

It should be understood that, corresponding to step S604, when the second device does not belong to a legitimate user of the network, the first authentication parameter is fictitious.

It should be noted that when the second device does not belong to a legal user of the network, the message type and message format when the first device sends the authentication request message to the second device are the same as when the second device belongs to a legal user of the network. When the device sends the authentication request message to the second device, the message type and the message format are consistent, so when the second device is an attacker, the second device cannot judge whether the UE ID is valid from the received message format and message type.

In this embodiment of the present application, for a second device that is not a legal user of the network, the network side randomly constructs an authentication request message, so that the message type and message format of the air interface message returned to the second device are the same as the message when the second device is a legal user. The type and message format are consistent, so that the attacker cannot guess the first identifier from the message type and message format, and it also avoids the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain effective the first identification.

It should be noted that, in this embodiment of the present application, the message indicates that the second device fails to register in the network or the message indicates that the network refuses to serve the second device to express the same effect, which is not limited in this application.

The method 700 for protecting the privacy of an identity identifier according to an embodiment of the present application will be described in detail below with reference to FIG. 7 . FIG. 8 is a schematic interaction diagram of the method 700 of the present application.

S701. The second device sends a fourth request message to the first device, where the fourth request message is used to request the network to authenticate the second device, and the fourth request message includes the first identifier.

It should be understood that the second device in this application may be a normal user equipment or a terminal device, and for the network, the second device may or may not be a legal user. The second device can also be an attacker. When the second device is a legitimate user, the first identifier is an identifier corresponding to the second device, which may be the identifier of the second device, including the SUPI and UE ID mentioned in this application, and also other devices with the same or similar The identification of the function. It should be noted that when the second device is an attacker, the part of the first identifier that is not public information is fabricated by the attacker.

S702, the first device sends a sixth request message to the third device, where the sixth request message includes the first identifier.

It should be understood that, for convenience, the AUSF is used as the third device for description in the embodiments of this application, and the third device may also be other devices or network elements with the same or similar functions, which is not limited in this application.

Exemplarily, the sixth request message may be used to request the network to initiate an authentication process or to request the second device to register with the network.

S703, the third device sends a fifth request message to the fourth device, where the fifth request message includes the first identifier.

It should be understood that, for convenience, the UDM is used as the fourth device for description in the embodiments of this application, and the fourth device may also be other devices or network elements with the same or similar functions, which is not limited in this application.

Exemplarily, the fifth request message may be used to request the network to initiate an authentication process or to request the second device to register with the network.

S704, in the case that the fourth device refuses to serve the second device, select a reason value.

The reason why the fourth device determines that it refuses to serve the second device may be that the fourth device verifies that the user identity is invalid. Exemplarily, when the fourth device cannot find the SUPI in the database, it considers that the SUPI is invalid, that is, the user ID is invalid.

The reason why the fourth device determines that it refuses to serve the second device may also be that the 5G network is unavailable. Exemplarily, the fourth device cannot find in the subscription data that the second device is not subscribed to the 5G network.

The decision by the fourth device to refuse to serve the second device may also be due to other reasons, which will not be repeated here.

S704a, the fourth device selects a second cause value, and the second cause value has nothing to do with whether the second device belongs to a legitimate user of the network.

Specifically, the fourth device determines that the reason for refusing to serve the second device is that the fourth device verifies that the user identifier is invalid, and selects the second reason value.

Exemplarily, when the fourth device cannot find the SUPI in the database, it considers that the SUPI is invalid, that is, the user ID is invalid, and selects the second reason value, which can be, for example, PLMN not allowed, or 5GS services not allowed, or Congestion;

S704b, the third device selects a third cause value, and the third cause value has nothing to do with whether the second device belongs to a legitimate user of the network.

Specifically, in the case that the second message is used to refuse to serve the second device, and the indication reason is that the second device does not belong to a legitimate user of the network, the third device selects the third reason value.

Exemplarily, when the fourth device determines that the second device does not belong to a legitimate user of the network according to the first identifier, the second message indicates that the network refuses to serve the second device, and the optional carrying reason value is an illegal user identifier. The third device determines that the network refuses to serve the second device according to the second message, and the failure reason is an illegal user ID, and selects the third reason value. For example, the third reason can be PLMN not allowed, or 5GS services not allowed, or Congestion.

S704c, the first device selects a first cause value, and the first cause value has nothing to do with whether the second device belongs to a legitimate user of the network.

Specifically, in the case that the first message is used to refuse to serve the second device, and the indication reason is that the second device does not belong to a legitimate user of the network, the first device selects the first reason value.

Exemplarily, when the third device determines that the second device does not belong to a legitimate user of the network, the first message indicates that the network refuses to serve the second device, and the optional carrying reason value is an illegal user identifier. The first device judges that the network refuses to serve the second device according to the first message, and the failure reason is an illegal user identity, and selects the first reason value. For example, the first reason can be PLMN not allowed, or 5GS services not allowed, or Congestion, or Serving network not authorized.

S705, the fourth device sends a fifth response message to the third device.

Corresponding to S704a, that is, when S704a is executed, the second cause value is included in the fifth response message; when S704a is not executed, the cause value included in the fifth response message may be the same as the second cause value, or may be the same as the second cause value. The reason value is different.

S706, the third device sends a sixth response message to the first device.

Corresponding to S704b, that is, when S704b is executed, the sixth response message includes the third cause value; when S704a is not executed, the cause value included in the sixth response message may be the same as the third cause value, or may be the same as the third cause value. The reason value is different.

S707: The first device sends a fourth response message to the second device, where the fourth response message is used to indicate that the network refuses to serve the second device, and the fourth response message includes the first reason value.

Corresponding to S704c, that is, when S704c is executed, the first cause value included in the fourth response message is selected by the first device.

It should be understood that when the second device performs the registration and authentication process with the network, there are many possible reasons why the network refuses to serve the second device. Steps S505a, S505b, and S505c in FIG. 5 list three main possible reasons. When the second device is a legitimate user, that is, when the first identifier is valid, the reason value carried in the fourth response message sent by the first device to the second device directly indicates the reason why the network refuses to serve the second device, such as PLMN not allowed, or 5GS services not allowed, or Congestion, or Serving network not authorized. When the second device is not a legitimate user, that is, when the first identifier is invalid, the cause value carried in the fourth response message sent by the first device to the second device does not directly indicate the cause value related to the cause of the UE identifier in step S505a , but the cause value selected in step S704 that has nothing to do with the cause of the UE identification, so that when the second device is an attacker, it cannot determine whether the first identification is valid or invalid according to the cause value carried in the message in step S707 of.

In this embodiment of the present application, when the second device fails to register with the network because it is not a legal user of the network, the network side selects a reason value that is irrelevant to whether the second device is a legal user, so that the attacker cannot obtain the message type and message of the air interface message. Judging whether the first identifier is valid in the format prevents the attacker from guessing the first identifier from the air interface message, and also avoids the attacker from guessing the first identifier through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain an effective identifier. first logo.

It should be noted that, in this embodiment of the present application, the message indicates that the second device fails to register in the network or the message indicates that the network refuses to serve the second device to express the same effect, which is not limited in this application.

The method 800 for protecting the privacy of an identity identifier according to an embodiment of the present application will be described in detail below with reference to FIG. 8 . FIG. 8 is a schematic interaction diagram of the method 800 of the present application.

S801 to S806 are the same as S401 to S406 in FIG. 4 , and details are not repeated here.

As an example, the error response messages (error response) of S805 and S806 may carry authentication method indication information. For example, the authentication algorithm used by the indicator 1 is 5G-AKA, and the authentication algorithm used by the indicator 2 is EAP-AKA', etc.

S807. The SEAF constructs authentication parameters, and generates a false response message.

Specifically, SEAF receives an error response message, and the cause value carried in the message indicates that the UE ID is invalid. For example, the cause value can be udm-error-unknown-subscription. SEAF does not send a registration rejection message to the UE, but sends an authentication request message. . The authentication request message is consistent with the authentication request message in S307, and the carried parameters such as authentication parameters are constructed by SEAF. Exemplarily, SEAF randomly generates 128-bit RAND, randomly generates 128-bit fake AUTN, and randomly generates 128-bit fake HXRES*. The AUTN format is

AK and SQN are 48 bits, Authentication Management Field is 16 bits, MAC is the message verification code, and the length is 64 bits.

After SEAF receives the error response message, SEAF marks the UE ID as invalid and stores it in the context. After the UE releases the connection, the context is deleted. As an example, when the SEAF marks the UE ID authentication failure with the context, it stores the cause value indicating that the UE ID is invalid into the context, or stores the instruction information indicating that the UE ID is invalid into the context, or, other methods can also be used. Marked in context, this application does not limit this.

It should be noted that when the authentication method is other authentication methods (such as EAP-AKA', EAP-TLS, etc.), the SEAF is constructed correspondingly according to the message format of the authentication method. For example, when the authentication method is EAP-AKA', the authentication request message sent by SEAF to UE carries EAP-Request/AKA'-Challenge message (including RAND and AUTN), ngKSI, ABBA, SEAF constructs the above parameters.

As an example, the SEAF may select the format of the constructed message according to the authentication method indication information. For example, when receiving indication 1, construct an authentication request message carrying AUTN and RAND. When receiving indication 2, construct an authentication request message carrying EAP-Request/AKA'-Challenge message (including RAND and AUTN), ngKSI, and ABBA.

S808, the SEAF sends an authentication request message to the UE, and the message carries the RAND, the fake AUTN, and the fake HXRES* constructed in S807.

It should be understood that in this solution, when the UE ID is invalid, the message type and message format sent by the SEAF to the UE are the same as when the UE ID is valid, so that the attacker cannot judge whether the UE ID is valid from the message type and message format.

S809. When the UE is a normal user, the UE fails to verify the AUTN, and executes S810a.

When the UE is an attacker, it is impossible to verify whether the AUTN is authentic, and the UE can construct and send various possible messages, such as S810a or S810b or S810c. The attacker can guess whether the UE ID is valid through the network's response to different messages.

It should be understood that the attacker does not have the root key corresponding to the UE ID, and cannot verify whether the AUTN is the real AUTN sent when the UE ID is valid or the fake AUTN constructed by SEAF itself. Therefore, the attacker cannot judge whether the UE ID is valid from the content of the message.

S810a, the UE sends an authentication failure message to the SEAF, carrying the cause value as MAC failure.

S810b, the UE sends an authentication failure message to the SEAF, which carries the cause value of the synchronization failure and the AUTS. As a possible attack method, the UE constructs AUTS randomly. Therefore AUTS is invalid.

S810c, the UE sends an authentication response message to the SEAF, which carries the authentication vector (RES) calculated by the UE. As a possible attack method, the UE constructs AUTS randomly. Therefore RES is invalid.

S811, SEAF receives the message of S810a or S810b or S810c, and performs the following operations according to the content of the message:

When the message is S810a and the cause value is MAC failure, it is processed according to the existing flow.

When the message is S810b, as an example, SEAF can check the context corresponding to the UE ID. When the context marks the authentication failure of the UE ID (for example, the UE ID is invalid, etc.), the received authentication failure message is discarded, the message carrying the AUTS is not sent to the AUSF, but an authentication rejection message is directly replied to the UE, that is, S812.

It should be understood that when the UE is an attacker, the AUTS is constructed by the attacker. Because the attacker cannot know the root key for calculating the AUTS, the AUTS cannot pass the UDM check, and the above operations avoid signaling overhead.

When the message is S810c, SEAF has two modes of operation:

Mode 1, SEAF can check the context corresponding to the UE ID. When the context marks that the UE ID authentication fails, for example, the UE ID is invalid, etc., the SEAF discards the received authentication response message, does not send a message carrying the RES to the AUSF, but directly replies an authentication rejection message to the UE, that is, S812.

It should be understood that when the UE is an attacker, the RES is constructed by the attacker. Because the attacker cannot know the root key for calculating the AUTS, the RES cannot pass the SEAF check, and the above operations avoid computational consumption.

In the second method, SEAF calculates HRES* according to the existing method, and compares HRES* and HXRES*. When the two are not equal, the SEAF sends an authentication rejection message to the UE, that is, S812.

It should be understood that through the operation on the SEAF in S811, when the UE ID is invalid, the message can not be sent to the AUSF, thereby avoiding changes and influences on the AUSF and the UDM.

In this embodiment of the present application, when the UE is not a legal user of the network, that is, the UE ID is invalid, the message returned to the UE does not use the registration rejection message carrying the special cause value, but uses the UE is a legal user of the network, that is, the UE ID is valid. The message type of the authentication request message used is the same as the message format, which prevents the attacker from guessing the SUPI from the air interface message, and also avoids the attacker from guessing the SUPI through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain A valid SUPI.

It should be understood that even if the attacker tries to guess whether the UE ID is valid through S810, in this solution, the UE can only obtain the authentication rejection message and cannot obtain more information, that is, it is impossible to guess whether the UE ID is valid through S810

The method 900 for protecting the privacy of an identity identifier according to an embodiment of the present application will be described in detail below with reference to FIG. 9 . FIG. 9 is a schematic interaction diagram of the method 900 of the present application.

S901 to S904 are the same as S401 to S404 in FIG. 4 , and details are not repeated here.

S905, the UDM constructs authentication parameters.

Specifically, after the UDM parses and obtains the SUPI corresponding to the UE, it determines whether the SUPI is valid. The determination method may be by querying the user ID database. When the SUPI can be found, it means that the SUPI is valid, that is, the UE is a legitimate user of the network. On the contrary, SUPI is invalid, that is, the UE is not a legitimate user of the network. When the SUPI is invalid, that is, the UE is not a legitimate user of the network, the UDM does not return an error message to the AUSF, but constructs authentication parameters and sends an authentication request message. The authentication request message is consistent with the authentication request message in S305. Exemplary, including randomly generating 128-bit RAND, randomly generating 128-bit fake AUTN, generating 128-bit XRES*, and randomly generating 256-bit fake Kausf, where the AUTN format is

AK and SQN are 48 bits, Authentication Management Field is 16 bits, MAC is the message verification code, and the length is 64 bits.

It can be understood that the method by which the UDM constructs the authentication parameters has nothing to do with the root key.

The UDM marks the UE ID as invalid and stores it in the context. After the UE releases the connection, the context is deleted. As an example, when the SEAF marks the UE ID authentication failure with the context, it stores the cause value indicating that the UE ID is invalid into the context, or stores the instruction information indicating that the UE ID is invalid into the context, or, other methods can also be used. Marked in context, this application does not limit this.

It should be noted that when the authentication method is other authentication methods (such as EAP-AKA', EAP-TLS, etc.), the UDM performs corresponding construction according to the message format of the authentication method. For example, when the authentication method is EAP-AKA', the authentication request message sent by the UDM to the AUSF carries the authentication vector AV' (RAND, AUTN, XRES, CK', IK'), and the UDM constructs the above parameters with reference to the specific format.

S906, the UDM sends an authentication response message to the AUSF, and the message carries the authentication vector and Kausf.

It should be understood that when the UE ID is valid or invalid, the message format sent by the UDM to the AUSF is the same, and the AUSF cannot judge whether the UE ID is valid from the message type and message format.

S907, AUSF sends an authentication response message to SEAF, and the message carries RAND, false AUTN and false HXRES*.

AUSF calculates the Visited Network Authentication Vector (SE AV) according to the Home Network Authentication Vector (HE AV), and sends an authentication response message to SEAF, which carries the Visited Network Authentication Vector (SE AV); the Visited Network Authentication Vector (SE AV) includes RAND , false AUTN and false HXRES*.

S908, the SEAF sends an authentication request message to the UE, and the message carries the RAND, the false AUTN and the false HXRES*.

It should be understood that in this solution, when the UE ID is invalid, the format of the message sent by the SEAF to the UE is the same as when the UE ID is valid, so that the attacker cannot judge whether the UE ID is valid from the message type and message format.

S909, when the UE is a normal user, the UE fails to check the AUTN, and executes S910a.

When the UE is an attacker, it is impossible to verify whether the AUTN is authentic, and the UE can construct and send various possible messages, such as S910a or S910b or S910c. The attacker can guess whether the UE ID is valid through the network's response to different messages.

It should be understood that the attacker does not have the root key corresponding to the UE ID, and cannot verify whether the AUTN is the real AUTN sent when the UE ID is valid or the fake AUTN constructed by SEAF itself. Therefore, the attacker cannot judge whether the UE ID is valid from the content of the message.

S910a, the UE sends an authentication failure message to the SEAF, carrying the cause value as MAC failure.

S910b, the UE sends an authentication failure message to the SEAF, which carries the cause value of the synchronization failure and the AUTS. SEAF will send this message to UDM via AUSF for checksum processing. As a possible attack method, the UE constructs AUTS randomly. Therefore AUTS is invalid.

S910c, the UE sends an authentication response message to the SEAF, which carries the authentication vector (RES) calculated by the UE. As a possible attack method, the UE constructs AUTS randomly. Therefore RES is invalid.

S911, SEAF receives the message in step 10, and performs the following operations according to the content of the message:

When the message is MAC failure in the message carrying cause value in S910a, it is processed according to the existing mechanism.

When the message is S910b, UDM has two operation modes:

Manner 1, the UDM follows the existing mechanism and sends an authentication failure message to the UE after checking the AUTS, that is, S912b. The authentication failure message is sent by the UDM to the UE via the AUSF and SEAF, which is the same as the existing mechanism.

In the second way, the UDM can check the context corresponding to the UE ID. When the context marks the UE ID authentication failure, for example, the UE ID is invalid, etc., the UDM discards the received authentication failure message, does not verify the AUTS, but returns an authentication rejection message to the UE through the AUSF and AMF.

It should be understood that when the UE is an attacker, the AUTS is constructed by the attacker. Because the attacker cannot know the root key for calculating the AUTS, the AUTS cannot pass the UDM check, and the above operations avoid computational overhead.

When the message is S910c, SEAF calculates HRES* in the existing way, and compares HRES* and HXRES*. When the two are not equal, the SEAF sends an authentication rejection message to the UE, that is, S911c.

It should be understood that when the message in S910b or S910c is received in S911, the SEAF reply message is the same when the UE ID is valid or invalid. Therefore, the attacker cannot judge whether the UE ID is valid from the message in S911. However, through the operation on the UDM in S911, when the UE ID is invalid, the AUTS can not be checked, thereby saving computational overhead.

It should be understood that even if the attacker tries to guess whether the UE ID is valid through S909, in this solution, the UE can only obtain the authentication rejection message and cannot obtain more information, that is, it is impossible to guess whether the UE ID is valid through S909.

In this embodiment of the present application, when the UE is not a legal user of the network, that is, the UE ID is invalid, the message returned to the UE does not use the registration rejection message carrying the special cause value, but uses the UE is a legal user of the network, that is, the UE ID is valid. The message type of the authentication request message used is the same as the message format, which prevents the attacker from guessing the SUPI from the air interface message, and also avoids the attacker from guessing the SUPI through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain A valid SUPI. Meanwhile, the embodiments of the present application can also prevent network elements other than the UDM from being captured and attacking as an attacker.

The method 1000 for protecting the privacy of an identity identifier according to an embodiment of the present application will be described in detail below with reference to FIG. 10 . FIG. 10 is a schematic interaction diagram of the method 1000 of the present application.

S1001 to S1005 are the same as S401 to S405 in FIG. 4 , and details are not repeated here.

As an example, the error response message may carry indication information for indicating the authentication method. For example, the authentication algorithm used by the indicator 1 is 5G-AKA, and the authentication algorithm used by the indicator 2 is EAP-AKA', etc.

S1006, the AUSF constructs authentication parameters.

The AUSF receives the error response message sent by the UDM, and the error response message carries the cause value, which is udm-error-unknown-subscription. The AUSF sends an Authentication Request message. The authentication request message is consistent with the authentication request message in S306, and the parameters carried therein, such as authentication parameters, are constructed by AUSF. Exemplarily, construct a fake 5G SE AV, which includes randomly generating 128-bit RAND, randomly generating 128-bit fake AUTN, and randomly generating 128-bit fake HXRES*.

It should be noted that when the authentication method is other authentication methods (such as EAP-AKA', EAP-TLS, etc.), the AUSF is constructed correspondingly according to the message format of the authentication method. For example, when the authentication method is EAP-AKA', the authentication request message sent by AUSF to SEAF carries the EAP-Request/AKA'-Challenge message (including RAND and AUTN), and AUSF constructs the above parameters with reference to the specific format.

As an example, the SEAF may choose to construct the message format according to the authentication method indication information. For example, when receiving indication 1, construct an authentication request message carrying 5G SE AV. When receiving indication 2, construct an authentication request message carrying EAP-Request/AKA'-Challenge message (including RAND and AUTN).

S1007, the AUSF sends an authentication response message to the SEAF, and the message carries the 5G SE AV. Optionally, the message may carry indication information to indicate that the current UE ID is invalid.

S1008 to S1012, when the AUSF judges that the current UE ID is invalid, the steps consistent with S808 to S812 in FIG. 8 are performed. Specifically, the AUSF may judge that the current UE ID is invalid according to the received indication information that the UE ID is invalid.

In this embodiment of the present application, when the UE is not a legal user of the network, that is, the UE ID is invalid, the message returned to the UE does not use the registration rejection message carrying the special cause value, but uses the UE is a legal user of the network, that is, the UE ID is valid. The message type of the authentication request message used is the same as the message format, which prevents the attacker from guessing the SUPI from the air interface message, and also avoids the attacker from guessing the SUPI through the subsequent process; it increases the attack difficulty of the attacker, making it difficult for the attacker to obtain A valid SUPI.

The method 1100 for protecting the privacy of an identity identifier according to an embodiment of the present application will be described in detail below with reference to FIG. 11 . FIG. 11 is a schematic interaction diagram of the method 1100 of the present application.

S1101 to S1106 are the same as S401 to S406 in FIG. 4 , and details are not repeated here.

S1107, SEAF selects a cause value, or constructs a cause value. The reason value is not related to invalid UE ID.

SEAF receives the message sent by AUSF. When the message indicates that the UE ID is invalid, it selects the failure cause value carried in the registration rejection message. The cause value can be PLMN not allowed, Congestion, etc.

It should be understood that the cause value here may be any one or more cause values that meet the conditions of S505b and S505c in FIG. 5 , instead of using a cause value indicating an illegal UE. It should be understood that when the UE ID is valid, the SEAF may also send the cause values involved in S505b and S505c to the UE, so this solution makes it impossible for an attacker to distinguish whether the UE ID is valid.

S1108, the SEAF sends a registration rejection message, where the registration rejection message carries the reason value selected in S1107.

In this embodiment of the present application, when the UE is not a legitimate user of the network, that is, when the UE ID is invalid, the cause value returned to the UE indicating the cause of the registration failure does not use the cause value related to whether the UE ID is valid, so that the attacker cannot use the registration Judging whether the UE ID is valid based on the message type and message format of the rejection message prevents attackers from guessing SUPI from air interface messages, and also avoids attackers guessing SUPI through subsequent processes; it increases the attack difficulty for attackers, making it difficult for attackers to obtain A valid SUPI.

In the above, the methods provided by the embodiments of the present application are described in detail with reference to FIGS. 6 to 11 . Hereinafter, the device provided by the embodiment of the present application will be described in detail with reference to FIG. 12 to FIG. 13 .

FIG. 12 is a schematic block diagram of a communication apparatus for protecting the privacy of an identity identifier provided by an embodiment of the present application. As shown in FIG. 12 , the communication device 10 may include a transceiver module 11 and a processing module 12 .

The transceiver module 11 may be used to receive information sent by other devices, and may also be used to send information to other devices. For example, the first request message is received or the third request message is sent. The processing module 12 may be used to perform content processing of the device, for example, to generate the first parameter.

In a possible design, the communication apparatus 10 may correspond to the first device or SEAF in the above method embodiment.

Specifically, the communication apparatus 10 may correspond to the first device or SEAF in any one of the methods 600 to 1100 according to the embodiments of the present application, and the communication apparatus 10 may include a method for executing the corresponding method by the first device or the SEAF. The modules of the operations performed by the SEAF, and each unit in the communication apparatus 10 is respectively in order to realize the operations performed by the first device or the SEAF in the corresponding method.

Exemplarily, when the communication apparatus 10 corresponds to the first device in the method 600, the transceiver module 11 is configured to execute steps S601, S602, S606, and S607, and the processing module 12 is configured to execute step S604c.

Exemplarily, when the communication device 10 corresponds to the SEAF in the method 700, the transceiver module 11 is configured to execute steps S701, S702, S706, and S707, and the processing module 12 is configured to execute step S704c.

Exemplarily, when the communication device 10 corresponds to SEAF in the method 800, the transceiver module 11 is configured to execute steps S801, S802, S806, S808, S810a or S810b or S810c, S812, and the processing module 12 is configured to execute steps S807, S811.

Exemplarily, when the communication device 10 corresponds to the SEAF in the method 900, the transceiver module 11 is configured to perform steps S901, S902, S907, S908, S910a or S910b or S910c, S912b.

Exemplarily, when the communication device 10 corresponds to SEAF in the method 1000, the transceiver module 11 is configured to execute steps S1001, S1002, S1007, S1008, S1010a or S1010b or S1010c, S1012, and the processing module 12 is configured to execute steps S1011.

Exemplarily, when the communication device 10 corresponds to SEAF in the method 1100, the transceiver module 11 is configured to execute steps S1101, S1102, S1106, and S1108, and the processing module 12 is configured to execute step S1107.

Specifically, in a possible embodiment, the transceiver module 11 is configured to receive a first request message from the second device, where the first request message is used for the second device to request to register in the network, and the first request message The message includes a first identifier; the transceiver module 11 is further configured to receive a first message from a third device, where the first message is used to request the second device to authenticate the network or to indicate that the second device is in the network The registration fails; the transceiver module is further configured to send an authentication request message to the second device according to the first message, where the authentication request message includes a first authentication parameter, and the first authentication parameter is used by the second device to authenticate the network.

Further, in the case that the first message is used to request the second device to authenticate the network, the first authentication parameter is generated based on the first parameter carried in the first message; the first message is used to indicate the second device In the event that the device fails to register in the network, the first authentication parameter is randomly generated by the first device.

In addition, the apparatus further includes a processing module 12, and the processing module 12 is configured to: in the case that the first message is used to request the second device to authenticate the network, determine the legality of the second device belonging to the network according to the first message User; when the first message is used to indicate that the second device fails to register in the network, determine according to the first message that the second device does not belong to a legitimate user of the network.

The apparatus further includes: when the first message is used to request the second device to authenticate the network, the first authentication parameter is generated based on the root key corresponding to the first identifier.

The apparatus also includes: the first authentication parameter includes an authentication token and a home network expected response.

The apparatus further includes: the first parameter includes the first authentication parameter.

In another possible embodiment, the transceiver module 11 is configured to receive a fourth request message from the second device, where the fourth request message is used to request the network to authenticate the second device, and the fourth request message includes the first request message. identification; the transceiver module 11 is also used to receive a sixth response message from the third device, and the sixth response message is used to indicate that the network refuses to serve the second device; the transceiver module 11 is also used to Six response messages send a fourth response message to the second device, the fourth response message is used to indicate that the network refuses to serve the second device, the fourth response message includes a first cause value, the first cause value and the It is irrelevant whether the second device belongs to a legitimate user of the network.

The apparatus further includes a processing module 12, and the processing module 12 is configured to determine, according to the sixth response message, that the second device does not belong to a legitimate user of the network.

The processing module 12 is further configured to generate the first cause value, or the transceiver module 11 is further configured to receive the first cause value.

In a possible design, the communication apparatus 10 may correspond to the fourth device or UDM in the above method embodiment.

Specifically, the communication apparatus 10 may correspond to the fourth device or UDM in any one of the methods 600 to 1100 according to the embodiments of the present application, and the communication apparatus 10 may include a fourth device or UDM for executing the corresponding method. The modules of the operations performed by the UDM, and each unit in the communication apparatus 10 is respectively in order to realize the operations performed by the fourth device or the UDM in the corresponding method.

Exemplarily, when the communication apparatus 10 corresponds to the fourth device in the method 600, the transceiver module 11 is configured to execute steps S603 and S605, and the processing module 12 is configured to execute step S604a.

Exemplarily, when the communication device 10 corresponds to the UDM in the method 700, the transceiver module 11 is configured to execute steps S703 and S705, and the processing module 12 is configured to execute step S704a.

Exemplarily, when the communication device 10 corresponds to the UDM in the method 600, the transceiver module 11 is configured to execute steps S803 and S805, and the processing module 12 is configured to execute step S804.

Exemplarily, when the communication device 10 corresponds to the UDM in the method 900, the transceiver module 11 is configured to execute steps S903 and S906, and the processing module 12 is configured to execute steps S904, S905, and S911.

Exemplarily, when the communication device 10 corresponds to the UDM in the method 1000, the transceiver module 11 is configured to execute steps S1003 and S1005, and the processing module 12 is configured to execute step S1004.

Exemplarily, when the communication device 10 corresponds to the UDM in the method 1100, the transceiver module 11 is configured to execute steps S1103 and S1105, and the processing module 12 is configured to execute step S1104.

Specifically, in a possible embodiment, the transceiver module 11 is configured to receive a second request message from a third device, where the second request message is used to request the second device to register in the network, and the second request message The message includes a first identifier; the transceiver module 11 is further configured to send a second message to the third device, where the second message is used to request the second device to authenticate the network or to indicate that the second device is in the network The registration fails, and the second message includes a second authentication parameter, and the second authentication parameter includes a parameter for the second device to authenticate the network.

The apparatus further includes a processing module 12, and the processing module 12 is configured to: generate the second authentication parameter according to the second parameter when the fourth device determines according to the first identification that the second device belongs to a legitimate user of the network , the second parameter includes the root key corresponding to the first identifier; in the case that the fourth device determines that the second device does not belong to a legitimate user of the network according to the first identifier, the second authentication parameter is randomly generated.

The processing module 12 is further configured to, when the fourth device determines according to the first identifier that the second device does not belong to a legitimate user of the network, the second message is used to request the second device to authenticate the network.

The apparatus further includes: the second authentication parameter includes at least one of the following: an authentication token, an expected response, and an authentication service function key.

In another possible embodiment, the transceiver module 11 is configured to receive a fifth request message from a third device, where the fifth request message is used to request the network to authenticate the second device, and the fifth request message includes the first identifier; the transceiver module 11 is further configured to send a fifth response message to the third device, where the fifth response message is used to indicate that the network refuses to serve the second device, and the fifth response message includes a second cause value, The second cause value is independent of whether the second device belongs to a legitimate user of the network.

The apparatus further includes a processing module 12, the processing module 12 generates the second cause value, or the transceiver module is further configured to receive the second cause value.

In a possible design, the communication apparatus 10 may correspond to the second network device or UDM in the above method embodiment.

Specifically, the communication apparatus 10 may correspond to the third device or AUSF in any one of the methods 600 to 1100 according to the embodiments of the present application, and the communication apparatus 10 may include a third device or AUSF for performing the corresponding method in the Modules of operations performed by the AUSF, and each unit in the communication apparatus 10 is respectively in order to implement the operations performed by the third device or the AUSF in the corresponding method.

Exemplarily, when the communication apparatus 10 corresponds to the third device in the method 600, the transceiver module 11 is configured to execute steps S602, S603, S605, and S606, and the processing module 12 is configured to execute step S604b.

Exemplarily, when the communication device 10 corresponds to the AUSF in the method 700, the transceiver module 11 is configured to execute steps S702, S703, S705, and S706, and the processing module 12 is configured to execute step S704b.

Exemplarily, when the communication device 10 corresponds to the AUSF in the method 800, the transceiver module 11 is configured to perform steps S802, S803, S805, and S806.

Exemplarily, when the communication device 10 corresponds to the AUSF in the method 900, the transceiver module 11 is configured to perform steps S902, S903, S906, and S907.

Exemplarily, when the communication device 10 corresponds to the AUSF in the method 1000, the transceiver module 11 is configured to execute steps S1002, S1003, S1005, and S1007, and the processing module 12 is configured to execute step S1006.

Exemplarily, when the communication device 10 corresponds to the AUSF in the method 1100, the transceiver module 11 is configured to perform steps S1002, S1003, S1005, and S1006.

Specifically, in a possible embodiment, the transceiver module 11 is configured to receive a third request message from the first device, where the third request message is used for the second device to request to register in the network, and the third request message The message includes the first identifier; the transceiver module 11 is further configured to receive a second message from the fourth device, where the second message is used to request the second device to authenticate the network or to indicate that the second device is in the network The registration fails; the transceiver module 11 is further configured to send a first message to the first device according to the second message, where the first message includes a third authentication parameter, and the third authentication parameter includes a parameter for the second device to authenticate the parameters of the network.

Wherein, when the second message is used to request the second device to authenticate the network, the third authentication parameter is generated based on the second parameter carried in the second message; in the second message is used to instruct the second device In the case of registration failure in the network, the third authentication parameter is randomly generated by the third device.

The apparatus further includes a processing module 12, which is configured to determine, according to the second message, that the second device belongs to a legitimate user of the network when the second message is used to request the second device to authenticate the network; The second message is used to instruct the second device to determine that the second device does not belong to a legitimate user of the network according to the second message in the event that the second device fails to register in the network.

The apparatus further includes: when the third device determines that the second device belongs to a legitimate user of the network, the third authentication parameter is generated based on the root key corresponding to the first identifier.

The apparatus also includes: the third authentication parameter includes an authentication token and a home network expected response.

The apparatus further includes: the second parameter includes the third authentication parameter.

In another possible embodiment, the transceiver module 11 is configured to receive a sixth request message from the first device, where the sixth request message is used to request the network to authenticate the second device, and the sixth request message includes the first identification; the transceiver module 11 is further configured to receive a fifth response message from the fourth device, and the fifth response message is used to indicate that the network refuses to serve the second device; the transceiver module 11 is also configured to send a message to the first device A device sends a sixth response message, the sixth response message is used to indicate that the network refuses to serve the second device, wherein, in the case that the second device belongs to a legitimate user of the network, the sixth response message includes the first A cause value, the sixth response message includes a third cause value, and the third cause value has nothing to do with whether the second device belongs to a legitimate user of the network.

The apparatus further includes a processing module 12, and the processing module 12 is configured to generate the third cause value, or the transceiver module is further configured to receive the third cause value.

The processing module 12 is further configured to determine, according to the fifth response message, that the second device does not belong to a legitimate user of the network.

FIG. 13 is a schematic diagram of an apparatus 20 for protecting the privacy of an identity identifier according to an embodiment of the present application.

In a possible design, the apparatus 20 may be a first device or a SEAF, including various devices with a security anchor function, or may be a chip or a system-on-a-chip located on the SEAF.

In a possible design, the apparatus 20 may be a fourth device or UDM, including various devices capable of processing user identification, access authentication, registration, or mobility management, or may be a chip or a UDM located on the UDM. Chip system, etc.

In a possible design, the apparatus 20 may be a third device or an AUSF, including various devices with authentication service functions, or may be a chip or a chip system located on the AUSF, or the like.

The apparatus 20 may include a processor 21 (ie, an example of a processing module) and a memory 22 . The memory 22 is used for storing instructions, and the processor 21 is used for executing the instructions stored in the memory 22, so that the apparatus 20 implements the execution of the devices in the various possible designs described above in the methods corresponding to FIG. 6 to FIG. 11 . step.

Further, the device 20 may further include an input port 23 (ie, an example of a transceiver module) and an output port 24 (ie, another example of a transceiver module). Further, the processor 21, the memory 22, the input port 23 and the output port 24 can communicate with each other through an internal connection path to transmit control and/or data signals. The memory 22 is used to store a computer program, and the processor 21 can be used to call and run the computer program from the memory 22 to control the input port 23 to receive signals, control the output port 24 to send signals, and complete the process of the terminal device in the above method. step. The memory 22 may be integrated in the processor 21 or may be provided separately from the processor 21 .

Optionally, if the information transmission device 20 is a communication device, the input port 23 is a receiver, and the output port 24 is a transmitter. The receiver and the transmitter may be the same or different physical entities. When they are the same physical entity, they can be collectively referred to as transceivers.

Optionally, if the device 20 is a chip or a circuit, the input port 23 is an input interface, and the output port 24 is an output interface.

As an implementation manner, the functions of the input port 23 and the output port 34 can be considered to be implemented by a transceiver circuit or a dedicated chip for transceiver. The processor 21 can be considered to be implemented by a dedicated processing chip, a processing circuit, a processor or a general-purpose chip.

As another implementation manner, a general-purpose computer may be used to implement the device provided by the embodiments of the present application. The program codes that will implement the functions of the processor 21 , the input port 23 and the output port 24 are stored in the memory 22 , and the general-purpose processor implements the functions of the processor 21 , the input port 23 and the output port 24 by executing the codes in the memory 22 .

Wherein, each module or unit in the apparatus 20 may be used to perform each action or process performed by the device (eg, terminal device) performing random access in the above method, and detailed description thereof is omitted here to avoid redundant description.

For the concepts related to the technical solutions provided by the embodiments of the present application involved in the apparatus 20, for explanations and detailed descriptions and other steps, please refer to the descriptions of the foregoing methods or other embodiments, which will not be repeated here.

It should be understood that, in this embodiment of the present application, the processor may be a central processing unit (CPU, central processing unit), and the processor may also be other general-purpose processors, digital signal processors (DSP, digital signal processors), dedicated integrated Circuit (application specific integrated circuit, ASIC), off-the-shelf programmable gate array (field programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

It should also be understood that the memory in the embodiments of the present application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically programmable Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory. Volatile memory may be random access memory (RAM), which acts as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), Double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (synchlink DRAM, SLDRAM) and direct Memory bus random access memory (direct rambus RAM, DR RAM).

The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented in software, the above-described embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer may be a general purpose computer, special purpose computer, computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be downloaded from a website site, computer, server or data center Transmission to another website site, computer, server or data center by wire (eg, infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, a data center, or the like that contains one or more sets of available media. The usable media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media. The semiconductor medium may be a solid state drive.

It should be understood that the term "and/or" in this document is only an association relationship to describe associated objects, indicating that there can be three kinds of relationships, for example, A and/or B, which can mean that A exists alone, and A and B exist at the same time , there are three cases of B alone. In addition, the character "/" in this document generally indicates that the related objects are an "or" relationship.

It should be understood that, in various embodiments of the present application, the size of the sequence numbers of the above-mentioned processes does not mean the sequence of execution, and the execution sequence of each process should be determined by its functions and internal logic, and should not be dealt with in the embodiments of the present application. implementation constitutes any limitation.

Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementations should not be considered beyond the scope of this application. Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, device and unit described above may refer to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment. In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The functions, if implemented in the form of software functional units and sold or used as independent products, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product in essence, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk and other mediums that can store program codes.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited to this. should be covered within the scope of protection of this application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (28)

1. A method for protecting the privacy of an identity identifier, comprising:

   The first device receives a first request message from the second device, where the first request message is used by the second device to request registration in the network, and the first request message includes a first identifier;

   The first device receives a first message from a third device, where the first message is used to request the second device to authenticate the network or to indicate that the second device fails to register in the network;

   The first device sends an authentication request message to the second device according to the first message, where the authentication request message includes a first authentication parameter, and the first authentication parameter is used by the second device to authenticate the network .
2. The method according to claim 1, wherein the method further comprises:

   When the first message is used to request the second device to authenticate the network, the first authentication parameter is generated based on the first parameter carried in the first message;

   When the first message is used to indicate that the registration of the second device in the network fails, the first authentication parameter is randomly generated by the first device.
3. The method according to claim 1 or 2, wherein the method further comprises:

   When the first message is used to request the second device to authenticate the network, the first device determines, according to the first message, that the second device belongs to a legitimate user of the network;

   When the first message is used to indicate that the second device fails to register in the network, the first device determines, according to the first message, that the second device does not belong to a legitimate user of the network.
4. The method according to any one of claims 1 to 3, wherein the method further comprises:

   When the first message is used to request the second device to authenticate the network, the first authentication parameter is generated based on the root key corresponding to the first identifier.
5. The method according to any one of claims 1 to 4, wherein the method further comprises:

   The first authentication parameters include an authentication token and a home network expected response.
6. The method according to any one of claims 2 to 5, wherein the method further comprises:

   The first parameter includes the first authentication parameter.
7. A method for protecting the privacy of an identity identifier, comprising:

   The fourth device receives a second request message from the third device, where the second request message is used to request the second device to register in the network, and the second request message includes the first identifier;

   The fourth device sends a second message to the third device, where the second message is used to request the second device to authenticate the network or to indicate that the second device fails to register in the network, The second message includes second authentication parameters including parameters for the second device to authenticate the network.
8. The method according to claim 7, wherein the method further comprises:

   In the case where the fourth device determines according to the first identifier that the second device belongs to a legitimate user of the network, the fourth device generates the second authentication parameter according to the second parameter, and the second The parameter includes the root key corresponding to the first identifier;

   In a situation where the fourth device determines according to the first identifier that the second device does not belong to a legitimate user of the network, the fourth device randomly generates the second authentication parameter.
9. The method according to claim 7 or 8, wherein the method further comprises:

   When the fourth device determines according to the first identifier that the second device does not belong to a legitimate user of the network, the second message is used to request the second device to authenticate the network.
10. The method according to any one of claims 7 to 9, wherein the method further comprises:

    The second authentication parameter includes at least one of the following: an authentication token, an expected response, and an authentication service function key.
11. A method for protecting the privacy of an identity identifier, comprising:

    The third device receives a third request message from the first device, the third request message is used by the second device to request to register in the network, and the third request message includes the first identifier; the third device receives the a second message of the fourth device, where the second message is used to request the second device to authenticate the network or to indicate that the second device fails to register in the network;

    The third device sends a first message to the first device according to the second message, the first message includes a third authentication parameter, and the third authentication parameter includes a parameter for the second device to authenticate the parameters of the network.
12. The method according to claim 11, wherein the method further comprises:

    When the second message is used to request the second device to authenticate the network, the third authentication parameter is generated based on the second parameter carried in the second message;

    When the second message is used to indicate that the registration of the second device in the network fails, the third authentication parameter is randomly generated by the third device.
13. The method according to claim 11 or 12, wherein the method further comprises:

    When the second message is used to request the second device to authenticate the network, the third device determines, according to the second message, that the second device belongs to a legitimate user of the network;

    When the second message is used to indicate that the second device fails to register in the network, the third device determines, according to the second message, that the second device does not belong to a legitimate user of the network.
14. The method according to any one of claims 11 to 13, wherein the method further comprises:

    When the third device determines that the second device belongs to a legitimate user of the network, the third authentication parameter is generated based on the root key corresponding to the first identifier.
15. The method according to any one of claims 11 to 14, wherein the method further comprises:

    The third authentication parameters include an authentication token and a home network expected response.
16. The method according to any one of claims 11 to 14, wherein the method further comprises:

    The second parameter includes the third authentication parameter.
17. A method for protecting the privacy of an identity identifier, comprising:

    The first device receives a fourth request message from the second device, where the fourth request message is used to request the network to authenticate the second device, and the fourth request message includes the first identifier;

    The first device receives a sixth response message from the third device, where the sixth response message is used to instruct the network to refuse to serve the second device;

    The first device sends a fourth response message to the second device according to the sixth response message, where the fourth response message is used to instruct the network to refuse to serve the second device, and the fourth response message The message includes a first cause value independent of whether the second device is a legitimate user of the network.
18. The method according to claim 17, wherein the method further comprises:

    The first device determines, according to the sixth response message, that the second device does not belong to a legitimate user of the network.
19. The method according to claim 17 or 18, wherein the method further comprises:

    The first device generates the first cause value, or the first device receives the first cause value.
20. A method for protecting the privacy of an identity identifier, comprising:

    The fourth device receives a fifth request message from the third device, where the fifth request message is used to request the network to authenticate the second device, and the fifth request message includes the first identifier;

    The fourth device sends a fifth response message to the third device, where the fifth response message is used to instruct the network to refuse to serve the second device, and the fifth response message includes a second cause value, The second cause value is independent of whether the second device belongs to a legitimate user of the network.
21. The method according to claim 20, wherein the method further comprises:

    The fourth device generates the second cause value.
22. A method for protecting the privacy of an identity identifier, comprising:

    The third device receives a sixth request message from the first device, where the sixth request message is used to request the network to authenticate the second device, and the sixth request message includes the first identifier;

    The third device receives a fifth response message from the fourth device, where the fifth response message is used to instruct the network to refuse to serve the second device;

    The third device sends a sixth response message to the first device according to the fifth response message, where the sixth response message is used to instruct the network to refuse to serve the second device, and the sixth response message The message includes a third cause value that is independent of whether the second device is a legitimate user of the network.
23. The method of claim 22, wherein the method further comprises:

    The third device determines, according to the fifth response message, that the second device does not belong to a legitimate user of the network.
24. The method according to claim 22 or 23, wherein the method further comprises:

    The third device generates the third cause value, or the third device receives the third cause value.
25. A device for protecting the privacy of an identity identifier, comprising:

    A module for implementing the method of any one of claims 1 to 6; or, a module for implementing the method of any one of claims 7 to 10; or, for implementing any one of claims 11 to 16. A module of the method; or, a module for implementing the method of any one of claims 17 to 19; or, a module for implementing the method of any one of claims 20 to 21; or, A module for implementing the method of any one of claims 22 to 24.
26. A communication device, comprising:

    processor and memory;

    the memory for storing computer programs;

    the processor for executing the computer program stored in the memory, so that the communication device executes the communication method according to any one of claims 1 to 6, or executes any one of claims 7 to 10 The communication method described, or the communication method described in any one of claims 11 to 16, or the communication method described in any one of claims 17 to 19, or the execution of any one of claims 20 to 21 the communication method described in claim 22, or execute the communication method described in any one of claims 22 to 24.
27. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, and when the computer program runs on a computer, the computer is made to execute any one of claims 1 to 6. The communication method described in item 1, or the communication method described in any one of claims 7 to 10, or the communication method described in any one of claims 11 to 16, or the execution of any one of claims 17 to 19. One of the communication methods described, or the communication method according to any one of claims 20 to 21, or the communication method according to any one of claims 22 to 24.
28. A chip system, characterized by comprising: a processor for calling and running a computer program from a memory, so that a communication device installed with the chip system executes the communication according to any one of claims 1 to 6 method, or perform the communication method described in any one of claims 7 to 10, or perform the communication method described in any one of claims 11 to 16, or perform the communication method described in any one of claims 17 to 19 The communication method, or the communication method according to any one of claims 20 to 21, or the communication method according to any one of claims 22 to 24 is executed.

Images