Method for protecting encrypted user identities from replay attacks

Abstract

The present invention generally relates to the registration and authentication process between a wireless terminal and a core network, and in particular, to the detection of registration replay attacks from the core network side to reduce the leakage of confidential user information based on a set of authentication sequence numbers that are synchronously maintained and updated on the wireless terminal side and the core network side. The communication of sequence numbers between the wireless terminal and the core network is minimized and further effectively hidden during a limited number of transmissions to avoid exposure in the radio interface. The detection of sequence number desynchronization between the wireless terminal and the core network is used by the core network to determine a registration replay attack and stop transmitting request and response messages that may result in leakage of confidential information of the wireless terminal and, in some cases, denial of service to the terminal device or the network.

Description

Technical Field

[0001] The present invention generally relates to the field of communications, and in particular to a registration and authentication process between a mobile terminal and a core network. Background Art

[0002] The wireless terminal device can communicate with the home core network of the wireless terminal device via the service network. Before obtaining access to the home core network, the wireless terminal device can initiate a registration and authentication process. The wireless terminal, the service network and the home core network interact with each other to authenticate the wireless terminal device to the network and authenticate the network to the wireless terminal device. After successful registration and authentication, an access credential is generated to enable further communication between the wireless terminal device and the network. Communication messages (whether encrypted or unencrypted) between the UE and the network via the wireless interface may be attacked by hackers. Hackers may obtain confidential information about the wireless terminal through such attacks.

[0003] In the related technologies, during the authentication and registration process, replay attacks are prone to occur, and no effective solution has been proposed yet. Summary of the invention

[0004] The present invention generally relates to the registration and authentication process between a wireless terminal and a core network, and in particular, to the detection of registration replay attacks from the core network side to reduce the leakage of confidential user information based on a set of authentication sequence numbers that are synchronously maintained and updated on the wireless terminal side and the core network side. The communication of sequence numbers between the wireless terminal and the core network is minimized and further effectively hidden during a limited number of transmissions to avoid exposure in the radio interface. The detection of sequence number desynchronization between the wireless terminal and the core network is used by the core network to determine a registration replay attack and stop transmitting request and response messages that may result in leakage of confidential information of the wireless terminal and, in some cases, denial of service to the terminal device or the network.

[0005] In some example implementations, a method for performing an authentication process of a second network element is disclosed, the method being performed by a first network element of a communication network, the authentication process being used to access the communication network. The method may include receiving an authentication message initiated from the second network element; extracting a hidden sequence number from the authentication message to obtain a de-hidden sequence number maintained by the first network element; processing the authentication process based on a determination result of whether a previous sequence number of the second network element is stored in the first network element during a previous authentication process of the second network element; and further processing the authentication process based on a comparison result between the de-hidden sequence number and the previous sequence number when it is determined that the previous sequence number is stored in the first network element.

[0006] In some other implementations, a network device is disclosed. The network device mainly includes one or more processors and one or more memories, wherein the one or more processors are configured to read computer codes from the one or more memories to implement the above-mentioned authentication process method of the second network element performed by the first network element.

[0007] In yet other implementations, a computer-readable storage medium is disclosed, which stores computer codes. When the computer codes are executed by one or more processors, a method for executing an authentication process of a second network element is implemented.

[0008] Other aspects and alternatives of the above-described embodiments and their implementation are explained in more detail in the following drawings and description. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 An exemplary communication network including terminal devices, carrier networks, data networks, and service applications is shown.

[0010] Figure 2 Exemplary network functions or network nodes in a communication network are shown.

[0011] Figure 3 Exemplary network functions or network nodes in a wireless communication network are shown.

[0012] Figure 4 An exemplary data structure for hiding the user's identity for network registration and authentication of a wireless terminal is shown.

[0013] Figure 5 An exemplary logic flow for primary network registration / authentication between a wireless terminal (user equipment (UE)) and a core network based on hidden identity and hidden authentication sequence number of the wireless terminal user is shown.

[0014] Figure 6 An exemplary logic flow for reauthentication when a wireless terminal detects authentication sequence number desynchronization is shown.

[0015] Figure 7 An exemplary logic flow for registration / authentication between a wireless terminal and a core network based on a network-assigned temporary identity and authentication sequence number for an unauthenticated wireless terminal is shown.

[0016] Figure 8 An exemplary logic flow for registration / authentication between a wireless terminal and a core network based on a network assigned temporary identity and authentication sequence number upon successful authentication of the wireless terminal is shown.

[0017] Fig. 9An exemplary logic flow for primary network registration / authentication between a wireless terminal and a core network is shown based on hiding the identity and hiding the authentication sequence number of the user of the wireless terminal, and when desynchronization of the authentication sequence number from the network side is detected.

[0018] Fig.10 An exemplary logic flow for registration / authentication between a wireless terminal and a core network based on a network-assigned temporary identity and authentication sequence number of an unverifiable wireless terminal when an authentication sequence number desynchronization is detected from the network side is shown.

[0019] Fig.11 An exemplary logic flow for registration / authentication between a wireless terminal and a core network is shown based on a network assigned temporary identity and authentication sequence number for successful authentication of the wireless terminal, and when authentication sequence number desynchronization from the network side is detected.

[0020] Fig.12 An exemplary logic flow for primary network registration / authentication between a wireless terminal and a core network is shown based on user-hidden identity and hidden timestamps of corresponding registration messages, and when a registration replay attack via registration message timestamps from the network side is detected.

[0021] Fig.13 An exemplary logic flow for registration / authentication between a wireless terminal and a core network is shown based on a network-assigned temporary identity of an unverifiable wireless terminal and a corresponding hidden timestamp of a registration message, and when a registration replay attack via the registration message timestamp is detected from the network side. DETAILED DESCRIPTION

[0022] Exemplary Communication Network

[0023] like Figure 1 As shown in 100 in FIG. 1 , an exemplary communication network may include terminal devices 110 and 112, a carrier network 102, various service applications 140, and other data networks 150. For example, the carrier network 102 may include an access network 120 and a core network 130. The carrier network 102 may be configured to transmit voice, data, and other information (collectively referred to as data services) between the terminal devices 110 and 112, between the terminal devices 110 and 112 and the service applications 140, or between the terminal devices 110 and 112 and other data networks 150. After the authentication process is described in further detail below, a communication session may be established and a corresponding data path may be configured for such data transmission.

[0024] The access network 120 may be configured to provide network access to the core network 130 to the terminal devices 110 and 112. The core network 130 may include various network nodes or network functions, and the core network 130 is configured to control communication sessions and perform network access management and data traffic routing. The service applications 140 may be hosted by various application servers, wherein the various servers may be accessed by the terminal devices 110 and 112 through the core network 130 of the carrier network 102. The service applications 140 may be deployed as data networks external to the core network 130. Similarly, the terminal devices 110 and 112 may access other data networks 150 through the core network 130, and the other data networks may appear as data destinations or data sources for a specific communication session instantiated in the carrier network 102.

[0025] Figure 1 The core network 130 may include various network nodes or functions that are geographically distributed and interconnected to provide network coverage for the service area of ​​the carrier network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions may be virtualized and implemented as virtual machines or software entities. Each network node may be configured with one or more types of network functions. These network nodes or network functions may jointly provide the supply and routing functions of the core network 130. The terms "network node" and "network function" are used interchangeably in the present invention.

[0026] Figure 2 Further shown is an exemplary division of network functions in the core network 130 of the communication network 200. Figure 2 Only a single instance of a network node or function is shown in the figure, but those skilled in the art will appreciate that each of these network nodes or functions may be instantiated as multiple instances of network nodes distributed throughout the core network 130. Figure 2As shown, the core network 130 may include, but is not limited to, network nodes, such as access management network node (AMNN) 230, authentication network node (AUNN) 260, network data management network node (NDMNN) 270, session management network node (SMNN) 240, data routing network node (DRNN) 250, policy control network node (PCNN) 220, and application data management network node (ADMNN) 210. Exemplary signaling and data exchange between various types of network nodes through various communication interfaces are shown in FIG. Figure 2 The various solid connecting lines in FIG. Such signaling and data exchange may be carried by signaling or data messages that follow a predetermined format or protocol.

[0027] Above Figure 1 and 2 The implementation described in can be applied to both wireless and wired communication systems. Figure 3 Shown based on Figure 2 An exemplary cellular wireless communication network 300 is shown that illustrates a general implementation of the communication network 200 . Figure 3 The wireless communication network 300 may include a wireless terminal or user equipment (UE) 310 (used as Figure 2 terminal device 110), a radio access network (RAN) 320 (used as Figure 2 access network 120), service application 140, data network (DN) 150 and core network 130, the core network includes access management function (AMF) 330 (used as Figure 2 AMNN 230), session management function (SMF) 340 (used as Figure 2 SMNN 240), Application Function (AF) 390 (used as Figure 2 ADMNN 210), user plane function (UPF) 350 (used as Figure 2 DRNN 250), policy control function 322 (used as Figure 2PCNN 220), authentication server function (AUSF) 360 (used as Figure 2 AUNN 260), and Universal Data Management / Authentication Credentials Repository and Processing Function (UDM / ARPF) 370 (used as Figure 2 270). In addition, although Figure 3 Only single instances of some network functions or nodes of the wireless communication network 300 (especially the core network 130) are shown, but a person skilled in the art can understand that each of these network nodes or functions may have multiple instances distributed throughout the wireless communication network 300.

[0028] exist Figure 3 In the RAN 320, UE 310 can be implemented as various types of wireless devices or interrupts, and UE 310 is configured to access the core network through RAN 300. UE 310 may include but is not limited to mobile phones, laptops, tablets, Internet-of-Things (IoT) devices, distributed sensor network nodes, wearable devices, etc. UE 310 may include a mobile station (ME) and a system subscription module (SIM). The SIM module can be implemented, for example, in the form of a universal mobile telecommunications SIM (USIM), which includes some computing capabilities for network registration and authentication. The calculations required to perform network registration and authentication can be performed by the USIM or the ME in the UE. For example, RAN 320 may include multiple radio base stations distributed in the service area of ​​the carrier network. The communication between UE 310 and RAN 320 can be carried in an over-the-air (OTA) radio interface, such as Figure 3 As shown in 311.

[0029] like Figure 3 As shown, UDM 370 may form a permanent store or database for user contract and subscription profiles and data. UDM may also include an authentication credential repository and processing function (ARPF, such as Figure 3 370 ), for storing long-term security credentials for user authentication, and for performing calculations of authentication vectors and encryption keys using such long-term security credentials as input, as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, UDM / ARPF 370 may be located in a secure network environment of a network operator or a third party.

[0030] AMF / SEAF 330 may communicate with RAN 320, SMF 340, AUSF 360, UDM / ARPF 370, and PCF 322 via communication interfaces indicated by various solid lines connecting these network nodes or functions. AMF / SEAF 330 may be responsible for UE to non-access stratum (NAS) signaling management, and for provisioning registration and access of UE 310 to core network 130, and allocation of SMF 340 to support communication requirements of specific UEs. AMF / SEAF 330 may further be responsible for UE mobility management. AMF may also include a security anchor function (SEAF), such as Figure 3 330), as described in more detail below, the security anchor function interacts with AUSF 360 and UE 310 for user authentication and management of encryption / decryption keys at various levels. AUSF 360 can terminate user registration / authentication / key generation requests from AMF / SEAF 330 and interact with UDM / ARPF 370 to complete such user registration / authentication / key generation.

[0031] The SMF 340 may be allocated by the AMF / SEAF 330 for a specific communication session instantiated in the wireless communication network 300. The SMF 340 may be responsible for allocating the UPF 350 to support the communication session and the data flow therein in the user data plane, and for supplying / adjusting the allocated UPF 350 (e.g., for formulating packet detection and forwarding rules for the allocated UPF 350). As an alternative to being allocated by the SMF 340, the UPF 350 may be allocated by the AMF / SEAF 330 for a specific communication session and data flow. The UPF 350 allocated and supplied by the SMF 340 and the AMF / SEAF 330 may be responsible for data routing and forwarding, and for reporting network usage for a specific communication session. For example, the UPF 350 may be responsible for routing end-to-end data flows between the UE 310 and the DN 150, and between the UE 310 and the service application 140. The DN 150 and service applications 140 may include, but are not limited to, data networks and services provided by an operator of the wireless communication network 300 or by third-party data network and service providers.

[0032] The service application 140 may be provided by the AF 390 via a network exposed functionality such as provided by the core network 130 (in Figure 3 Not shown, but described below Figure 7When managing a specific communication session involving a service application 140 (eg, between a UE 310 and a service application 140), the SMF 340 may interact with an AF 390 associated with the service application 140 via a communication interface indicated by 313.

[0033] The PCF 322 may be responsible for managing and providing various levels of policies and rules applicable to the communication session associated with the UE 310 to the AMF / SEAF 330 and the SMF 340. Thus, for example, the AMF / SEAF 330 may assign the SMF 340 to the communication session based on the policies and rules associated with the UE 310 and obtained from the PCF 322. Similarly, the SMF 340 may assign the UPF 350 to handle data routing and forwarding for the communication session based on the policies and rules obtained from the PCF 322.

[0034] In order for the UE 310 to access the core network of its subscribed home carrier network, it may first communicate with the available RAN 320 and the AMF / SEAF 330 associated with the RAN 320. The RAN 320 and the AMF / SEAF 330 may or may not belong to the home carrier network (e.g., may be associated with another carrier network to which the UE 310 does not subscribe, and may be referred to as a serving network, and the term "serving network" may be used to refer generally to an access network having an AMF / SEAF belonging to another carrier network or to the same home core carrier network). The AMF / SEAF 330 of the serving network may communicate with the AUSF 360 and UDM / ARPF 370 of the home carrier network of the UE 310 for authentication, and then communicate with the SMF 340 and PCF 322 of the home carrier network to establish a communication session after successful authentication.

[0035] The various devices, terminals and network nodes mentioned above may include computing and communication components, such as processors, memories, various communication interfaces, various user display / operation interfaces, operating systems and applications configured to implement the various embodiments described in the present invention.

[0036] Authentication process, linkability, and Denial-of-Service (DoS) attacks

[0037] The registration and authentication process may include the UE 310 communicating with its home UDM / ARPF 370 via the serving RAN 320, the serving AMF / SEAF 330, the home AUSF 360 and the home UDM / ARPF, as described in more detail below. During the registration and authentication process, the UE 310 verifies that it is communicating with a legitimate network, and the network similarly verifies that the UE 310 is authorized to access the network. Upon successful authentication between the UE 310 and the core network 300, a temporary access identity may be assigned to the UE 310 for further communications with the core network. Such temporary access identifiers may be frequently modified / replaced to reduce the compromise of the user's identity, location, and communication content to attackers. Authentication may be initiated by the UE 310 sending a registration request to the serving AMF / SEAF 330, which contains its hidden or encrypted unique permanent identity, such as a Subscriber Concealed Identity (SUCI). Furthermore, after successful registration, a temporary identity such as a Global Unique Temporary Identity (GUTI) may be assigned to the UE 310 by the AMF / SEAF 330 for further access to the network.

[0038] As a result of an external attack via the radio interface, the identity, location or content of the user's communications may be compromised. Examples of attacks include, but are not limited to, linkability attacks and denial of service (DoS) attacks. For example, a SUCI intercepted by an attacker via the radio interface may be used for a linkability attack, where it is possible for the attacker to determine whether a UE observed at some location / time X is the same as a UE observed at some other location / time Y, thereby tracking the UE. For example, an attacker may record the SUCI that UE A has used over the radio interface. In the case where UE A uses the GUTI instead of the SUCI for authentication, the attacker may also perform an active attack to obtain the SUCI, for example, by corrupting the GUTI when the SUCI is sent by UE A, which is likely to result in a SUCI request from the AMF / SEAF 330 and the transmission of the SUCI from the UE in response. When some UE B later issues a registration request to a fake base station operated by the same attacker as a relay, the attacker may modify the registration request of UE B by modifying the SUCI or GUTI in the registration request to the SUCI previously captured by UE A, and forward the modified registration request to the network. The attacker then monitors the responses between the network and UE B to determine if UE B is the same as UE A, thereby potentially tracking this UE. For example, the attacker then monitors the radio interface to observe whether a successful Authentication and Key Agreement (AKA) run is performed and whether the network accepts the registration request, if so, UE A and UE B will be determined by the attacker to be the same UE.

[0039] This linkability attack cannot be mitigated by hiding only the content of the AKA response, because the attacker can detect whether the AKA operation is successful from various subsequent messages intercepted in the radio interface without knowing the content of the AKA response. In the case where the content of the AKA response is not hidden, the attacker can directly use such content to determine whether the attacked UE appears near the fake base station.

[0040] Thus, by replaying the SUCI, the attacker observes whether the replayed SUCI performs a successful AKA run, i.e., whether the replayed Registration Request is accepted by the network. If so, the attacker can link a UE observed in one location with a UE observed in another location (replaying its SUCI). When the attacker is executed in several locations, even though the attacked UE may still be anonymous, it is possible to track the anonymous UE in different locations, and its privacy and untraceability are compromised.

[0041] In another embodiment, the network may be subject to a DoS attack by an attacker through replaying the SUCI. Specifically, the attacker may replay the SUCI to overwhelm the network and / or the UE when performing frequent and repeated procedures (e.g., the SUCI de-hiding procedure and the authentication procedure). This may especially occur when the de-hiding scheme (e.g., the Elliptical Curve Integrated Encryption Scheme (ECIES)) does not have any mechanism to detect or adjust whether the received SUCI is the SUCI that the UE previously sent to the network.

[0042] Thus, if an attacker launches SUCI replay attacks multiple times, the UDM and UE may be forced to expend a large amount of resources to process the replayed SUCI and authentication request messages, respectively, because these messages appear to be legitimate. This triggers a DoS attack on the UDM and UE. A DoS attack on the UE may cause a decrease in the processing power of the UE and rapid battery depletion. A DoS attack on the UDM may cause a decrease in the processing power of the UDM and delay responses to legitimate registration requests and other types of requests.

[0043] Hidden authentication serial number

[0044] In some implementations, in order to combat the above-mentioned linkability and DoS attacks, the UE 310 and the carrier network may maintain a pair of sequence numbers (or authentication sequence numbers) to track the authentication and re-authentication of the UE. These sequence numbers may be referred to as SQNs. MS (on the UE side) and SQN HE (On the carrier network side). For example, SQN HE The SQN may be maintained by the UDM / ARPF 370 in a Home Environment (HE). These sequence numbers are only allowed to increase as the UE is authenticated and reauthenticated. Under normal network access conditions, the UE 310 and the carrier network may maintain the SQN MS and SQN HE For example, during an authentication or re-authentication process, detection of desynchronization by the UE 310 or the network can be used to indicate potential attacks and other problems.

[0045] In some implementations of sequence number synchronization, the SQN maintained by UE 310 MS May be transmitted to the carrier network during some authentication process. Likewise, the SQN maintained by the UDM / ARPF HEmay also be transmitted to the UE. However, in order to protect these sequence numbers from being disclosed, their transmission may be minimized and, when transmission is necessary, may be transmitted in an encrypted form that is considered secure. In an exemplary implementation described in more detail below, during the authentication process, the SQNMS may be transmitted together with the Subscription Permanent Identifier (SUPI) from the UE 310 to the AMF / SEAF 330 of the serving network and in the same manner. Furthermore, the SQNMS from the UDM / ARPF side may be transmitted to the UE 310 and the AMF / SEAF 330 of the serving network. HE It may be transmitted to the UE by being embedded in an authentication vector and encrypted, as described in further detail below.

[0046] Specifically, it is possible to perform SQN based on ECIES, for example MS After encryption, it is sent to AMF / SEAF 330 via the radio interface to protect the SQN MS In other words, the use of ECIES for hiding SUPI during the authentication process can be extended to accommodate SQN MS In some implementations, SUPI can be associated with SQN MS The combination of SQNMS and SUPI can be in the form of concatenation, interleaving, etc. For example, in the case where the International Mobile Subscriber Identity (IMSI) is used instead of SUPI for authentication, the Mobile Subscription Identification Number (MSIN) (e.g., 9 to 10 digits) and SQNMS can be used as a plain text block for symmetric encryption under ECIES. MS can be combined and encrypted / hidden by the UE. Accordingly, in the home network, symmetric decryption based on ECIES can be used to de-hide the SUPI (or MSIN) and SQN MS .

[0047] Hidden registration timestamp

[0048] In some other implementations of countering the above SUCI replay attack, the UE 310 may transmit a timestamp together with the SUCI to the network in a registration or authentication request message. The network may rely on such a timestamp to detect SUCI replay attacks. Similar to the above authentication sequence number, the timestamp may be combined with the SUPI, and then the combination may be ECIES encrypted. The combination of the SUPI and the timestamp may be based on other forms of concatenation, interleaving.

[0049] Hiding of the timestamp of the registration / authentication request may be performed as an alternative or in addition to hiding of the authentication sequence number described above. For example, the SUPI, sequence number and / or timestamp may be combined (e.g., concatenated or interleaved) and subsequently encrypted using the ECIES scheme.

[0050] SUCI Data Structure

[0051] SUPI (or MSIN) and SQN MS The hidden concatenation of the and / or timestamps may be sent as part of the SUCI data structure to the AMF / SEAF 330 of the serving network. Figure 4 An example of a SUCI data structure 400 is shown in FIG. The SUCI structure 400 includes a SUPI type field 402, whose value ranges from, for example, 0 to 7, for identifying the type of identifier hidden in the "scheme output" field 412 and other fields of the SUCI structure 400. For example, various values ​​may be used in the field 402 to indicate the following SUPI types:

[0052] -0:IMSI

[0053] -1: Network specific identifier

[0054] -2: Global Line Identifier (GLI)

[0055] -3: Global Cable Identifier (GCI)

[0056] -4: SUPI combined with SQNMS and / or message timestamp (e.g., concatenation)

[0057] -5 to 7: Reserved values ​​for other indicators.

[0058] The SUPI type values ​​and type correspondences listed above are for illustration purposes only, and other correspondences may also be used in embodiments of the present invention. For example, other values ​​including reserved values ​​may be used to indicate hiding the SUPI combined with the SQNMS and / or registration message timestamp. Other fields of the SUCI structure 400 include, for example, a home network identifier 404, a routing indicator 406, a protection scheme identifier 408, and a home network public key identifier 410.

[0059] Authentication based on hidden SUPI and authentication serial number

[0060] Figure 5 shows the use of SQN MSAn exemplary data and logic flow 500 for primary network registration / authentication between UE 310 and home core network AUSF 360 and UDM / ARPF 370 via serving network AMF / SEAF 330, assuming that authentication between UE 310 and the network is successful. The logic and data flow 500 may include the following exemplary steps, which have Figure 5 The corresponding step number in .

[0061] 1. During the primary authentication process 500, the USIM and ME combine the SUPI of the UE 310 and the current SQN maintained by the USIM or ME via, for example, concatenation or interleaving MS SUPI and SQN MS The combination (e.g. concatenated or interleaved) of plain text blocks can be encrypted using the ECIES method in the USIM or ME. Figure 4 The SUCI data structure can be constructed to include SUPI and SQN MS Encrypted combination. SUCI structure ( Figure 4 The "SUPI Type" field of 402) may be set to indicate that the SUCI structure contains a hidden combination of SUPI and SQNMS. For example, a value of "4" may be set in the "SUPI Type" field of the SUCI structure.

[0062] 2. The UE may use the hidden SQN included in the Registration Request message sent from the UE 310 to the serving AMF / SEAF 330 MS SUCI data structure.

[0063] 3. Once the Registration Request message is received from the UE 310, whenever the serving AMF / SEAF 330 wishes to initiate authentication, the serving AMF / SEAF 330 may invoke the AUSF service (denoted as Nausf_UEAuthentication Service) by sending an AUSF Service Request message (denoted as Nausf_UEAuthentication_Authenticate Request message) to the home AUSF 360. For example, the Nausf_UEAuthentication_Authenticate Request message may contain the embedded hidden SUPI and SQN MS The SUCI and the service network name.

[0064] 4. Upon receiving the Nausf_UEAuthentication_Authenticate request message, the home AUSF 360 may check whether the requesting AMF / SEAF 330 in the serving network is authorized to use the serving network name contained in the Nausf_UEAuthentication_Authenticate request by comparing the received serving network name with the expected serving network name. The home AUSF 360 may temporarily store the received serving network name. If the serving network is not authorized to use the received serving network name, the AUSF 360 may respond to the UE 310 in a response message denoted as Nausf_UEAuthentication_Authenticate Response, indicating that the serving network is not authorized. If the serving network is authorized to use the received serving network name, a UDM authentication request message denoted as Nudm_UEAuthentication_Get request may be sent from the home AUSF 360 to the home UDM / ARPF 370. The Nudm_UEAuthentication_Get request may contain the following information:

[0065] - Contains hidden SUPI and SQN MS SUPI; and

[0066] -Service network name.

[0067] 5. Upon receiving the Nudm_UEAuthentication_Get request, if the home UDM / ARPF 370 determines from the SUPI Type field of the received SUCI data structure that the SUPI type is the same as the SQN MS Combined SUPI, UDM / ARPF 370 may call Subscription Identifier De-concealment Function (SIDF). Therefore, before UDM 370 can process the request, SIDF may de-conceal the received SUCI to obtain the SUPI and SQN. MS Based on the SUPI, the UDM / ARPF 370 can perform its authentication process. MS can be stored in the UDM 370 for future use (see below for reference Figure 6 ). UDM 370 can also generate a new SQN HE , which is greater than the current SQN maintained by the UDM HE Then, the current SQN HE Updated SQN HEReplacement. Also based on the updated SQN HE and other information to generate an authentication vector (the components of the authentication vector are in step 6 below).

[0068] 6. For each Nudm_Authenticate_Get request, UDM / ARPF 370 may create a Home Environment Authentication Vector (HEAV). More specifically, UDM / ARPF 370 does this by generating an Authentication Vector (AV) with the Authentication Management Field (AMF) separation bit set to “1”. UDM / ARPF 370 may then derive the AUSF key KAUSF and calculate the eXpected RESponse represented by XRES*. Finally, UDM / ARPF 370 may create a HE AV based on the random number represented by RAND, the authentication key represented by AUTN, XRES*, and KAUSF. For example, AUTN contains SQN HE The UDM / ARPF 370 may then return the HE AV to the AUSF 360 along with an indication that the HE AV will be used for AKA in a response represented by a Nudm_UEAuthentication_Get response to the AUSF 360. The UDM / ARPF 370 may include the de-hidden SUPI in the Nudm_UEAuthentication_Get response.

[0069] 7. The AUSF 360 may temporarily store the XRES* together with the SUPI received from the UDM / ARPF 370.

[0070] 8. The AUSF 360 may then generate the HE AV received from the UDM / ARPF 370 by computing the hash XRES denoted by HXRES* from XRES* and the SEAF key denoted by KSEAF from KAUSF and replacing XRES* with HXRES* and SEAF with KSEAF in the HE AV. SEAF Replace K AUSF Then AV is generated.

[0071] 9.AUSF 360 can then remove K SEAF and returns the service context authentication vector denoted as SEAV (including RAND, AUTN and HXRES*) to SEAF 330 in a response message denoted as Nausf_UEAuthentication_Authenticate response

[0072] 10. The SEAF 330 may send the RAND and AUTN included in the AV to the UE in a non-access stratum (NAS) message Authentication Request. The message may also include the ngKSI, which the UE and AMF will use to identify the KAMF and the partial local security context created if the authentication is successful. The ME may forward the RAND and AUTN received in the NAS message Authentication Request to the USIM.

[0073] 11. Upon receiving RAND and AUTN, the UE (e.g., USIM or ME) can verify the freshness of the AV by checking whether the AUTN can be accepted. For example, the UE can extract the SQN contained in the AUTN HE and with the local SQN MS If SQN HE Not less than SQN MS , the UE can determine that the sequence number synchronization is successful. Otherwise, the UE determines that the sequence number synchronization fails. MS and SQN HE When synchronizing, the UE executes Figure 5 The remaining steps in are as follows. If sequence number synchronization is confirmed, the USIM may calculate a response represented by RES. The USIM may return RES, CK, IK to the ME. If the USIM calculates Kc (i.e., GPRS Kc) from CK and IK using conversion function c3 and sends it to the ME, the ME may ignore such GPRS Kc and not store GPRS Kc on the USIM or in the ME. The ME may then calculate RES* from RES. The ME may calculate K from CK||IK AUSF ME can be obtained from K AUSF Calculate K SEAF The ME of the access network can check during authentication whether the "Separation Bit" in the AMF field of AUTN is set to 1. The "Separation Bit" is bit 0 of the AMF field of AUTN. Once the SQN is determined MS and SQN HE The UE uses the extracted SQN to synchronize the sequence numbers between HE To update (or replace) its SQN MS , for future synchronization purposes.

[0074] 12. UE 310 may return RES* in a NAS Message Authentication Response to SEAF.

[0075] 13. SEAF 330 can then calculate HRES* from RES*, and SEAF 330 can compare HRES* and HXRES*. If they match, SEAF 330 can consider the authentication of UE 310 successful from the perspective of the serving network. When authentication is successful, follow the following steps: Figure 5 If unsuccessful, SEAF 330 may inform the network of the authentication failure by, for example, sending a response message with a failure code and / or dropping / stopping / exiting authentication. If the UE is not contacted (e.g., no response is obtained from the UE), and SEAF 330 never receives RES*, SEAF may consider the authentication to have failed and indicate the failure to AUSF 360.

[0076] 14. The SEAF 330 may send the RES* received from the UE 310 to the AUSF 360 in a message represented by a Nausf_UEAuthentication_Authenticate request message.

[0077] 15. When AUSF 360 receives the Nausf_UEAuthentication_Authenticate request message including RES* as authentication confirmation, it may verify whether the AV has expired. If the AV has expired, AUSF 360 may consider the authentication of UE 310 unsuccessful from the perspective of the home network. After successful authentication, AUSF 360 may store K AUSF AUSF 360 may compare the received RES* with the stored XRES*. If RES* and XRES* are equal, AUSF 360 may consider the authentication of UE 310 to be successful from the perspective of the home network and follow the following steps: Figure 5 AUSF 360 may notify UDM 370 of the authentication result. In case of failure (RES* and XRES* are not equal), AUSF 360 may notify the network of the authentication failure by, for example, sending a response message with a failure code and / or dropping / stopping / exiting the authentication.

[0078] 16. The AUSF 360 may indicate to the SEAF 330 in a response message denoted as Nausf_UEAuthentication_Authenticate Response whether the authentication was successful from the perspective of the home network. If the authentication was successful, the KSEAF may be sent to the SEAF 330 in the Nausf_UEAuthentication_Authenticate Response. If the authentication was successful, the AUSF 360 may also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message.

[0079] 17. AUSF 360 may notify UDM 370 of the result and time of the authentication process with UE 310 using a request message denoted as Nudm_UEAuthentication_ResultConfirmation Request. The request may include SUPI, timestamp of authentication, authentication type (e.g., EAP method or AKA), and serving network name.

[0080] 18. The UDM 370 may store the authentication status (SUPI, authentication result, timestamp and serving network name) of the UE 310 and update its previously stored SQNMS with the current SQNHE for future authentication sequence number synchronization purposes.

[0081] 19. The UDM 370 may reply to the AUSF 360 with a response message denoted as Nudm_UEAuthentication_ResultConfirmation Response.

[0082] 20. Upon receiving subsequent UE-related procedures (e.g., Nudm_UECM_Registration_Request from AMF 330), UDM 370 may apply actions according to the home operator's policies to detect and implement protection against certain types of fraud.

[0083] 21. Finally, AMF 330 allocates GUTI to UE 310 for further authentication.

[0084] Verification steps 13 and 15 may fail, indicating that the UE cannot be authenticated. In these cases, a failure message may be sent to the UDM 370 in tandem. Similar to step 18 above, the UDM 370 may still store the authentication state and use the current SQN HE Update the stored SQN MS .

[0085] Sequence number synchronization failure handling

[0086] In such Figure 5 As shown and described above in step 11, when the SQN is extracted from the AUTN received from the AMF 310 HE Less than the local SQN MS , UE 310 may determine that sequence number synchronization has failed. Figure 6 An exemplary logic and data flow 600 for reauthentication (RA) following such a sequence number synchronization failure is shown.

[0087] In RA0, if Figure 6 As shown, UE 310 may not calculate the embedded SQN MS Any authentication failure information (e.g., AUTS) is transmitted to the AMF 330 to avoid SQN MS Another exposure in the radio interface. Instead, the UE 310 only sends a response message to the AMF 330 indicating that the cause of the failure is sequence number desynchronization. For example, such desynchronization may occur when the UE 310 and the network are subject to a SUCI replay attack. As an example of RA1, the UE 310 may respond to a NAS message authentication failure with only a cause value indicating the cause of the failure as SQN failure / mismatch, without calculating AUTS and sharing it with the network.

[0088] In RA2, upon receiving the authentication failure message from the UE 310, the SEAF 330 may send a request message denoted as a Nausf_UEAuthentication_Authenticate request message to the AUSF 360.

[0089] In RA3, upon receiving the Nausf_UEAuthentication_Authenticate request message from the AMF 330, the AUSF 360 sends a request message denoted as a Nudm_UEAuthentication_Get request message to the UDM / ARPF 370.

[0090] In RA4, when the UDM / ARPF 370 receives the Nudm_UEAuthentication_Get request message from the AUSF 360, the ARPF 370 may be mapped to the HE / AuC. The UDM / ARPF 370 may send a response message represented by a Nudm_UEAuthentication_Get response message for authenticating the HE / AuC by using the SQN stored in the UDM 370. MS (For example, in Figure 5 5 or 18) instead of the updated SQN HE, using the new authentication vector to re-authenticate the UE. AUSF 360 follows Figure 5 The principles of steps 6-11 run a new authentication process with UE 310.

[0091] SUPI failed GUTI authentication

[0092] Figure 7 7 shows a logic and data flow for a registration / authentication process initiated by a UE 310 using a network assigned temporary identifier, e.g., via a previous registration and authentication process (e.g., from Figure 5 The SUCI registration process shown in step 21) obtains the GUTI. Figure 7 Legal person steps 0-2.

[0093] 0. The UE 310 may initiate a registration process using a temporary identity such as a GUTI.

[0094] 1. The UE 310 may use the temporary identity GUTI in the Registration Request message sent to the Serving AMF / SEAF 330.

[0095] 2. The serving AMF / SEAF 330 may attempt to obtain the SUPI for the UE from the old AMF / SEAF 702, as identified, for example, in the registration message, and if the serving AMF / SEAF 330 fails to obtain the UE context from the old AMF / SEAF 702 ( Figure 7 2a), the serving AMF / SEAF 330 may send an identity request message ( Figure 7 Upon receiving the Identity Request message, UE 310 may send an Identity Response message to AMF / SEAF 330, where the SUCI embeds the current SQN MS ( Figure 7 Step 2c).

[0096] The remaining steps 3-21 in the logic and data flow 700 essentially use SUCI to perform the authentication process and reflect Figure 5 The logic and data flow 500 of steps 3-21. These steps are Figure 7 As shown in the above Figure 5 The explanation has been given and will not be repeated here.

[0097] In addition, if Figure 7 If the SQN synchronization check fails at UE 310 in step 11 of Figure 6 Logic and data flow 600 is used to perform the re-authentication process, as described in more detail above.

[0098] Additionally, verification steps 13 and 15 may fail, indicating that UE 310 cannot be authenticated by the network. In those cases, and as described above for Figure 5 As described, fault messages may be sent to the UDM 370 in series. Figure 7 Step 18 and above of Figure 5 As described in step 18 of , the UDM can still store the authentication status and update the stored SQNMS with the current SQNHE.

[0099] Successfully retrieved GUTI certification for SUPI

[0100] Figure 8 8 shows a logic and data flow 800 for a registration / authentication procedure initiated by a UE 310 using a network assigned temporary identifier, e.g., via a previous registration and authentication procedure (e.g., from Figure 5 or Figure 7 Step 21) of the SUCI registration process shown in Figure 1 obtains the GUTI, where the serving network successfully identifies the SUPI of the UE. In addition to steps 0-5, Figure 8 The logic and data flow 800 is similar to Figure 5 The logic and data flow 500 will be described in more detail below.

[0101] 0. The home UDM 370 has previously stored the SQN of the UE 310 MS .

[0102] 1a. UE 310 may initiate a registration procedure with the GUTI.

[0103] 1b. UE 310 may use GUTI in the Registration Request message instead of SUCI sent to AMF / SEAF 330.

[0104] 2. The serving AMF / SEAF 330 successfully obtains the UE context with SUPI from the old AMF / SEAF 702.

[0105] 3. Whenever the serving AMF / SEAF 330 wishes to initiate authentication, the serving AMF / SEAF 330 may invoke the AUSF authentication service by sending a Nausf_UEAuthentication_Authenticate request message to the AUSF 360. The Nausf_UEAuthentication_Authenticate request message may contain the SUPI and the serving network name.

[0106] 4. Upon receiving the Nausf_UEAuthentication_Authenticate request message, the home AUSF 360 may check whether the requesting AMF / SEAF 330 in the serving network is authorized to use the serving network name contained in the Nausf_UEAuthentication_Authenticate request by comparing the received serving network name with the expected serving network name. The home AUSF 360 may temporarily store the received serving network name. If the serving network is not authorized to use the serving network name, the home AUSF 360 may respond by indicating that the serving network is not authorized in a response message represented by Nausf_UEAuthentication_Authenticate response. The AUSF 360 may then send a request message represented by Nudm_UEAuthentication_Get request to the home UDM / ARPF 370. The Nudm_UEAuthentication_Get request may include the UE's SUPI and the serving network name.

[0107] 5. Upon receiving the Nudm_UEAuthentication_Get request from the home AUSF 360, the home UDM / ARPF 370 may select an authentication method based on the SUPI. At the home UDM 370, an updated SQN greater than the previous sequence number for the UE 310 is used HE To generate the belonging environment AV vector.

[0108] Figure 8 The above steps of the logic and data flow 800 are Figure 5 The difference between the logic and the corresponding steps in data flow 500 is that during the authentication process, SUPI is passed from the serving network to the home network instead of SUCI. MS will not be sent to the home UDM / ARPF 370 and if Figure 8 As indicated in step 0 of , the SQNMS previously stored in the home UDM will not be updated with the current SQNMS.

[0109] Figure 8 The remaining steps 6-21 in the logic and data flow 800 essentially perform the authentication process, which reflects the Figure 5 The logic and data flow 500 of steps 6-21. These steps are Figure 8 The above is summarized in Figure 5 The explanation has been given and will not be repeated here.

[0110] In addition, if Figure 8If the SQN synchronization check fails at the UE in step 11, you can follow Figure 6 The re-authentication process is performed by the logic and data flow 600 of the home UDM 370, as described in more detail above. In the re-authentication logic and data flow 600, the new authentication vector generated by the home UDM 370 in step RA4 may be based on the previously stored SQN MS Due to the lack of updates in the GUTI authentication steps 1-5 in the logical and data flow 800, the SQN maintained at the UDM 370 MS will not become out of sync because any successful authentication (in Figure 8 Logic and data flow 800, Figure 7 500 and Figure 7 700) will cause the SQNMS maintained at the UDM 370 to be updated (or synchronized) with the current SQNMS at step 18 of these logical and data flows. HE Replace the stored SQN MS result.

[0111] also, Figure 8 Verification steps 13 and 15 of the logic and data flow 800 may fail, indicating that UE 310 cannot be authenticated by the network. In those cases, and as described above for Figure 5 As described, fault messages may be sent to the UDM 370 in series. Figure 8 Step 18 and above of Figure 5 As described in step 18 of , the UDM 370 can still store the authentication status and use the current SQN HE Update the stored SQN MS .

[0112] Using SQN to counter SUCI replay attacks on the network side

[0113] In some implementation examples, the UE-side sequence number SQN may be used to MS and he side serial number SQN HE Detect SUCI replay attacks on the network side. Figure 5 and Figure 7 In steps 1-5 shown, the SUCI embedded with the hidden permanent UE identity and the hidden SQNMS is transmitted, so the SQNMS becomes available to the network side.

[0114] Fig. 9 FIG. 4 shows the use of a SUCI (eg, SUPI) and SQN with a hidden network identity by a UE 310. MS Example logic and data flow 900 of a registration / authentication process initiated by Figure 5Logic and data flow 500 is shown, except that in step 5, the SUCI replay attack detection process is performed by the home UDM 370.

[0115] Specifically, in step 5 of the logic and data flow 900, upon receiving the Nudm_UEAuthentication_Get request sent from the home AUSF 360, the home UDM 370 may call the SIDF if the SUPI type is the same as the SQN MS If the combined SUPI is present, the SIDF process may de-hide the received SUCI before the home UDM 370 may process the request to obtain the SUPI and SQN associated with the UE 310. MS .

[0116] for Fig. 9 In step 5 of the logic and data flow 900 , upon detection of a SUCI replay attack from the network side, the home UDM 370 makes the following exemplary determination:

[0117] - If the home UDM 370 does not already have the locally stored SQN of the UE 310 MS , the SQN received via SUCI can be stored MS , further selecting an authentication method based on the SUPI, and based on the updated and increased SQN HE Generate AV.

[0118] - If the home UDM 370 has a previously stored SQN for the UE 310 MS , it can be configured to receive the SQN MS With the previously stored SQN MS Make a comparison.

[0119] ○ If the comparison shows the received SQN MS Less than or equal to the previously stored SQN MS , the home UDM 370 determines that a SUCI replay attack has occurred and responds with a fault code or discards the message to stop the authentication process.

[0120] ○ However, if the comparison shows the received SQN MS Larger than the stored SQN MS , the home UDM 370 may alternatively be configured to select a SUPI-based authentication method, generate an updated and increased SQN based on HE AV, and continue Fig. 9 The remaining authentication process in.

[0121] ○If SQN HE Less than or equal to the stored SQN MS, then the UDM 370 discards the AV and SQN HE , and generate an SQN with an update HE New AV.

[0122] Fig. 9 The remaining steps in the logic and data flow 900 except step 5 substantially perform the authentication process, which reflects the authentication process. Figure 5 The corresponding steps in the logic and data flow 500. These steps are Fig. 9 The above is summarized in Figure 5 The explanation has been given and will not be repeated here.

[0123] Similarly, Fig.10 1000 shows a logic and data flow for a registration / authentication process initiated by a UE 310 using a network assigned temporary identifier, e.g., via a previous registration and authentication process (e.g., from Fig. 9 The GUTI is obtained in step 21) of the SUCI registration process shown. In addition, step 5 includes a process for detecting SUCI replay attacks. Fig.10 The steps are similar to Figure 7 steps. Fig.10 The logic and data flow 1000 in step 5 is similar to Fig. 9 The logic and data flow 900 shown in step 5 and described in detail above. Thus, Fig.10 The steps summarized in will not be repeated here.

[0124] also, Fig.11 1 shows a registration / authentication process initiated by UE 310 using a network-assigned temporary identifier, e.g., via a previous registration and authentication process (e.g., from Fig. 9 or Fig.11 Step 21) of the SUCI registration process shown obtains the GUTI, where the serving network successfully identifies the SUPI of the UE. Fig.11 The steps are similar to Figure 8 In addition, in step 5, the UDM 370 may select an authentication method based on the SUPI and select an authentication method based on the SQN. HE Generate AV, if SQN HE Less than or equal to SQN MS , then the UDM 370 can discard the AV and SQN HE , and generate new AV and SQN HE .

[0125] In addition, if Fig. 9 , 10 If the SQN synchronization check fails at the UE in step 11, you can follow Figure 6 The re-authentication process is performed by the logic and data flow 600 of the home UDM 370, as described in more detail above. In the re-authentication logic and data flow 600, the new authentication vector generated by the home UDM 370 in step RA4 may be based on the previously stored SQN MS .

[0126] Using the registration request message timestamp to counter SUCI replay attacks on the network side

[0127] In some implementations, a SUCI replay attack may be detected on the network side based on the UE registration request timestamp.Since the SUCI embedded with the hidden UE identity and the hidden timestamp as described above is transmitted, the registration timestamp becomes available to the network side.

[0128] Fig.12 An exemplary logic and data flow 1200 of a registration / authentication process initiated by a UE 310 using a SUCI with a hidden network identity (eg, SUPI) and a hidden registration request timestamp is shown. The logic and data flow 1200 is similar to Fig. 9 The logic and data flow 900 is the same as that of FIG. 900 , except that the information hidden in the SUCI includes the UE identity and the registration request timestamp instead of the UE identity and the SQN. MS , and in step 5, the home UDM 370 performs the SUCI replay attack detection process based on the registration request timestamp instead of the authentication sequence number.

[0129] The following describes in more detail Fig.12 Exemplary steps 1-5 of logic and data flow 1200 are shown.

[0130] 1. During the primary authentication process, the UE 310 (e.g., USIM) combines the SUPI and the registration request or message timestamp represented as MESSAGE_TIME by concatenation, interleaving or other combination. For example, MESSAGE_TIME may represent the UTC-based time when the message (e.g., registration or authentication message) is sent. Figure 4 The SUCI data structure can be constructed to include an encrypted combination of SUPI and MESSAGE_TIME. Figure 4 The "SUPI Type" field of 402) of the SUCI structure may be set to indicate that the SUCI structure contains a hidden combination of SUPI and MESSAGE_TIME. For example, a value of "4" may be set in the "SUPI Type" field of the SUCI structure.

[0131] 2. The UE may use the SUCI containing the hidden MESSAGE_TIME in the Registration Request message, which is sent from the UE 310 to the serving AMF / SEAF 330.

[0132] 3. Upon receiving the Registration Request message from the UE 310, whenever the AMF / SEAF 330 wishes to initiate authentication, the serving AMF / SEAF 330 may invoke an AUSF service (denoted as Nausf_UEAuthentication Service) by sending an AUSF Service Request message (denoted as Nausf_UEAuthentication_Authenticate Request message) to the AUSF 360. For example, the Nausf_UEAuthentication_Authenticate Request message may contain a SUCI with a hidden SUPI and MESSAGE_TIME embedded therein, and a serving network name.

[0133] 4. Upon receiving the Nausf_UEAuthentication_Authenticate request message, the home AUSF 360 may check whether the requesting AMF / SEAF 330 in the serving network is authorized to use the serving network name contained in the Nausf_UEAuthentication_Authenticate request by comparing the received serving network name with the expected serving network name. The AUSF 360 may temporarily store the received serving network name. If the serving network is not authorized to use the received serving network name, the AUSF 360 may respond to the UE 310 in a response message denoted as Nausf_UEAuthentication_Authenticate Response, indicating that the serving network is not authorized. If the serving network is authorized to use the received serving network name, a UDM authentication request message denoted as Nudm_UEAuthentication_Get request may be sent from the home AUSF 360 to the home UDM / ARPF 370. The Nudm_UEAuthentication_Get request sent from the AUSF 360 to the UDM 370 may include the following information:

[0134] - SUPI including hidden SUPI and MESSAGE_TIME; and

[0135] -Service network name.

[0136] 5. Upon receiving the Nudm_UEAuthentication_Get request from the home AUSF 360, the home UDM 370 may invoke SIDF, and if the SUPI type is a SUPI combined with MESSAGE_TIME, the SIDF procedure may de-hide the received SUCI before the home UDM 370 may process the request to obtain the SUPI and MESSAGE_TIME. For SUCI replay attack detection from the network side in step 5, the home UDM 370 may compare the received MESSAGE_TIME with the current UTC-based time and make the following exemplary determinations:

[0137] - If the received MESSAGE_TIME is less than the current UTC-based time minus a predetermined maximum delay time (denoted as MAX_DELAY), the home UDM 370 may respond with a failure code, or discard and stop processing the message. MAX_DELAY represents, for example, a maximum transmission time threshold. For example, MAX_DELAY may be predetermined based on an estimated data transmission speed between the UE 310 and the UDM 370. MAX_DELAY may be further adjusted as needed.

[0138] If the received MESSAGE_TIME is greater than or equal to the current UTC-based time minus MAX_DELAY, and less than the current UTC-based time, the home UDM 370 may be configured to select a SUPI-based authentication method, generate an AV, and continue Fig.12 The remaining authentication steps.

[0139] Fig.12 The remaining steps except steps 1-5 in the logic and data flow 1200 basically perform the authentication process, which reflects the authentication process. Figure 5 The corresponding steps in the logic and data flow 500, except that the SQN on the UE side may not be involved in step 11 MS Update and in step 18 may need to involve the SQN on the network side MS Update. These steps are in Fig.12 The above is summarized in Figure 5 The explanation has been given and will not be repeated here.

[0140] Similarly, Fig.13 1300 shows a logic and data flow for a registration / authentication procedure initiated by a UE 310 using a network assigned temporary identifier, e.g., via a previous registration and authentication procedure (e.g., from Fig.12 Step 21) of the SUCI registration process shown to obtain the GUTI. Fig.13 The steps are similar to Figure 7 except steps 1-5 use a hidden timestamp instead of the SQN MS (As in Fig.12 ), step 5 includes a process for detecting a SUCI replay attack similar to Fig.12 Step 5 of the logic and data flow 1200 shown and described in detail above, in step 11, there may be no need to involve the SQN on the UE side. MS Update, and in step 18, there may be no need for SQN that does not involve the network side MS Update. In this way, Fig.13 The steps summarized in will not be repeated here.

[0141] Hidden SQN MS and the hidden registration request message timestamp

[0142] In some other implementations, SQN can be used simultaneously MS and the registration message timestamp. In other words, SQN MS Both the registration message timestamp and the SUPI can be combined and hidden to generate the SUCI for registration and authentication. Figure 5 , 7 , 9, 10 and 11 can be used with the various logical data flows Fig.12 and 13 , to form other logic and data flows. MS and registration message timestamps can be transferred to the storage SQN MS The home UDM 370, and both the sequence number and timestamp can be used to detect and respond to SUCI replay attacks.

[0143] The above drawings and descriptions provide specific exemplary embodiments and implementations. However, the described subject matter may be embodied in a variety of different forms, and therefore, the subject matter covered or claimed is intended to be interpreted as not being limited to any exemplary embodiment set forth herein. It is intended to provide a reasonably broad scope for the subject matter claimed or covered. In addition, for example, the subject matter may be embodied as a method, device, component, system, or non-transitory computer-readable medium for storing computer code. Therefore, the embodiments may, for example, take the form of hardware, software, firmware, storage media, or any combination thereof. For example, the above method embodiments may be implemented by a component, device, or system including a memory and a processor by executing a computer code stored in a memory.

[0144] Throughout the specification and claims, in addition to the explicitly stated meanings, terms may have nuanced meanings that are implied or implied in context. Likewise, the phrases "in one embodiment / implementation" used herein do not necessarily refer to the same embodiment, and the phrases "in another embodiment / implementation" used herein do not necessarily refer to a different embodiment. For example, the claimed subject matter is intended to include, in whole or in part, a combination of exemplary embodiments.

[0145] In general, terms can be understood at least in part from their use in context. For example, the terms "and", "or", and "and / or" used herein can include multiple meanings, which can depend at least in part on the context in which the terms are used. Typically, "or" (if used to associate a list, such as A, B, or C) is intended to mean: A, B, and C, used here in an inclusive sense; and A, B, or C, used here in an exclusive sense. In addition, the term "one or more" used herein depends at least in part on the context and can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, the term "one", or "the" can be understood to convey singular usage or to convey plural usage, which depends at least in part on the context. In addition, the term "based on" can be understood to not necessarily be intended to convey a set of exclusive factors, but can allow for the presence of additional factors that are not necessarily explicitly described, which also depends at least in part on the context.

[0146] Throughout the specification, references to features, advantages, or similar language do not imply that all features and advantages that can be achieved with the present solution should be or are included in any single implementation thereof. Rather, language referring to features and advantages is understood to mean that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, throughout the specification, discussion of features and advantages and similar language may, but do not necessarily, refer to the same embodiment.

[0147] In addition, in one or more embodiments, the features, advantages and characteristics of the embodiments of the present invention may be combined in any suitable manner. One of ordinary skill in the relevant art will be able to appreciate that, based on the description herein, the embodiments of the present invention may be implemented without one or more specific features or advantages of a particular embodiment. In other cases, additional features and advantages that may not be present in all embodiments of the embodiments of the present invention may be recognized in certain embodiments.

Claims

1. A method for executing an authentication process of a second network element, the method being executed by a first network element of a communication network, the authentication process being used to access the communication network, the method comprising: receiving an authentication message initiated by the second network element; de-hiding the authentication message to obtain a de-hidden sequence number maintained by the first network element; processing the authentication process based on a determination of whether a previous sequence number of the second network element was stored in the first network element during a previous authentication process of the second network element; upon determining that the previous sequence number is stored in the first network element, further processing the authentication process based on a comparison result between the de-hidden sequence number and the previous sequence number, Wherein, further processing the authentication process according to the comparison result between the de-hidden sequence number and the previous sequence number includes: when the comparison result indicates that the de-hidden sequence number is greater than the previous sequence number: Generate a new serial number; Generate an authentication vector based on the new serial number, After generating the authentication vector based on the new sequence number, the method further includes: Comparing the new sequence number with the dehidden sequence number; When the new sequence number is less than or equal to the de-hidden sequence number, the authentication vector is discarded and another sequence number and another authentication vector are regenerated.

2. The method according to claim 1, wherein: Processing the authentication process according to the determination result includes: When the first network element determines that a previous sequence number of the second network element was not stored in the first network element during any previous authentication process of the second network element: storing the de-hidden sequence number in a first network element; Generate a new serial number; Generate an authentication vector based on the new sequence number.

3. The method according to claim 2, wherein: After generating an authentication vector based on the new sequence number, the method further includes sending the authentication vector to the first network element.

4. The method according to claim 2, further comprising: comparing the new sequence number with the dehidden sequence number; When the new sequence number is less than or equal to the de-hidden sequence number, the authentication vector is discarded and another sequence number and another authentication vector are regenerated.

5. The method according to claim 1, wherein: Further processing the authentication process based on the comparison result between the de-hidden sequence number and the previous sequence number includes: when the comparison result indicates that the de-hidden sequence number is less than or equal to the previous sequence number, discarding the authentication message.

6. The method according to claim 1, wherein: Further processing the authentication process based on the comparison result between the de-hidden sequence number and the previous sequence number includes: when the comparison result indicates that the de-hidden sequence number is less than or equal to the previous sequence number, generating a response message including a fault code.

7. The method according to claim 1, wherein: De-hiding the authentication message to obtain a de-hidden sequence number and a de-hidden subscription identifier maintained by the first network element includes: retrieving the hidden identity of the second network element from the authentication message; Extracting a type indicator from the authentication message, wherein the type indicator is used to indicate a type of hidden identity; determining that the type indicator indicates that the type of the hidden identity includes a composite data item, the composite data item including a hidden subscription identifier and a hidden sequence number; decrypting the composite data item to obtain a decrypted composite data item; and A de-hidden subscription identifier and a de-hidden sequence number are obtained from the decrypted composite data item.

8. The method according to claim 7, wherein: The decrypted composite data item also includes a de-hidden subscription identifier concatenated with the de-hidden sequence number.

9. The method of claim 7, when the type indicator indicates that the type of the hidden identity comprises a composite data item, the type indicator comprises a unique value for indicating that the hidden identity comprises a hidden combination of a subscription identifier and a sequence number.

10. The method according to claim 7, wherein: The decrypted composite data item also includes a de-hidden subscription identifier interleaved with the de-hidden sequence number.

11. The method according to claim 7, wherein: The composite data item is decrypted using an Elliptic Curve Integrated Encryption Scheme (ECIES) scheme to obtain a de-hidden subscription identifier and a de-hidden serial number.

12. The method according to claim 7, wherein: The hidden identity is encapsulated in a subscription hidden identifier SUCI.

13. The method according to claim 7, wherein: The de-hidden subscription identifier includes: a subscription permanent identifier SUPI.

14. The method according to claim 1, wherein: The first network element comprises a user equipment UE and the second network element comprises at least one of a unified data management UDM or an authentication credentials repository and processing function ARPF of the communication network.

15. The method according to claim 1, wherein: The authentication message includes one of the following: a registration request message initiated by the first network element; The first network element responds to the identity request from the communications network with an identity response message.

16. A first network element, comprising a processor, wherein: The processor is configured to implement the method according to any one of claims 1-15.

17. A computer-readable storage medium storing computer codes, which, when executed by a processor, implement the method according to any one of claims 1 to 15.

Images