CN116569516A - Method for preventing leakage of authentication serial number of mobile terminal - Google Patents

Abstract

The present disclosure relates generally to the registration and authentication process between a wireless terminal and a core network, and in particular, to protecting the authentication serial number of a wireless terminal when it is transmitted via a wireless communication interface during the registration and authentication process not to be leaked. Specifically, an incremented authentication serial number is maintained by the wireless terminal and used synchronously with another authentication serial number maintained by the network side (under normal network operation) to track the registration and authentication activities of the terminal device, and to help detect Interface certain types of malicious attacks on wireless endpoints (for example, registration replay). The terminal-side serial number is sent to the network through a concealment mechanism similar to that of the permanent user identity of the wireless terminal to reduce its exposure to the wireless interface, and by tracking and updating the terminal-side and network-side serial numbers upon successful authentication or re-authentication The serial number of the wireless terminal can be synchronized with the authentication serial number of the network side.

Description

Method for Preventing Authentication Serial Number Leakage of Mobile Terminal

technical field

The present disclosure generally relates to a registration and authentication process between a mobile terminal and a core network, and in particular, relates to a technique for preventing leakage of an authentication serial number.

Background technique

A wireless end device can communicate with its home core network via the serving network. Before accessing the home core network, the wireless terminal can initiate a registration and authentication process. The wireless terminal, serving network, and home core network interact with each other to authenticate the wireless terminal to the network and to authenticate the network to the wireless terminal. After successful registration and authentication, access credentials are generated to enable further communication between the wireless terminal and the network. Communication messages (whether encrypted or unencrypted) transmitted between the UE and the network via the wireless interface can be attacked by hackers. A hacker may obtain confidential information about a wireless terminal via such an attack.

Contents of the invention

The present disclosure relates generally to the registration and authentication process between a wireless terminal and a core network, and in particular, to protecting the authentication serial number of a wireless terminal when it is transmitted via a wireless communication interface during the registration and authentication process not to be leaked. Specifically, an incremented authentication serial number is maintained by the wireless terminal and used synchronously with another authentication serial number maintained by the network side (under normal network operation) to track the registration and authentication activities of the terminal device, and to help detect Interface certain types of malicious attacks on wireless endpoints (for example, registration replay). The terminal-side serial number is sent to the network by a concealment mechanism similar to that of the permanent user identity of the wireless terminal to reduce its exposure to the wireless interface, and by tracking and updating the terminal-side and network-side serial numbers upon successful authentication or re-authentication The serial number of the wireless terminal can be synchronized with the authentication serial number of the network side.

In some example implementations, a method performed by a first network element of a communication network for authenticating a second network element to access the communication network is disclosed. The method may include: receiving an authentication message initiated from the second network element; de-concealing the authentication message to obtain the de-concealment sequence number maintained by the first network element and the de-concealment of the second network element User identification; storing the de-hidden serial number in the first network element; generating a new serial number, and generating an authentication vector based on the new serial number; sending the authentication vector to the second network element ; and when receiving an authentication response message for the authentication vector from the second network element, replacing the de-hidden sequence number stored in the first network element with the new sequence number.

In some other implementations, another method performed by a first network element of a communication network for authenticating a second network element to access the communication network is disclosed. The method may include: receiving an authentication message initiated from the second network element, wherein the authentication message includes the de-hidden user identity of the second network element; generating a new serial number, and based on the new serial number Generate an authentication vector with a serial number; send the authentication vector to the second network element; and when receiving an authentication response message to the authentication vector from the second network element, replace the previously stored serial number with the new serial number The serial number associated with the first network element.

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 the above method.

In still other implementations, a computer program product is disclosed. The computer program product may include a non-transitory computer-readable program medium having stored thereon computer code which, when executed by one or more processors, causes the one or more processors to implement the method described above.

Other aspects and alternatives of the above-described embodiments and their implementations are explained in more detail in the following figures, description and claims.

Description of drawings

Figure 1 shows an exemplary communication network comprising terminal devices, a carrier network, a data network and service applications.

Fig. 2 shows exemplary network functions or network nodes in a communication network.

Fig. 3 shows exemplary network functions or network nodes in a wireless communication network.

FIG. 4 shows an exemplary data structure of a user concealed identity for network registration and authentication of a wireless terminal.

FIG. 5 shows an exemplary data and logic flow for primary network registration/authentication between a wireless terminal (User Equipment (User Equipment, UE)) and a core network based on the wireless terminal's user concealed identity and concealed authentication serial number .

FIG. 6 illustrates an exemplary data and logic flow for re-authentication when a wireless terminal (User Equipment (UE)) detects desynchronization of an authentication sequence number.

7 shows exemplary data and data for registration/authentication between a wireless terminal (User Equipment (User Equipment, UE)) and a core network based on a network-assigned temporary identity and an authentication serial number of a wireless terminal that cannot be verified. logical flow.

8 shows exemplary data and data for registration/authentication between a wireless terminal (User Equipment (User Equipment, UE)) and a core network based on a network-assigned temporary identity and an authentication serial number based on successful verification of the wireless terminal. logical flow.

Fig. 9 shows that when the desynchronization of the authentication sequence number from the network side is detected, the wireless terminal (user equipment (User Equipment, UE)) and the core network are used based on the user hidden identity of the wireless terminal and the hidden authentication sequence number. Exemplary data and logic flow for main network registration/authentication.

FIG. 10 shows the temporary identity and authentication serial number assigned by the network based on the wireless terminal that cannot be verified when the authentication serial number is detected from the network side. Exemplary data and logic flow for registration/authentication between networks.

Figure 11 shows the temporary identity and authentication serial number assigned by the network based on the successful verification of the wireless terminal when the authentication serial number desynchronization from the network side is detected for the wireless terminal (User Equipment (User Equipment, UE)) and the core Exemplary data and logic flow for registration/authentication between networks.

Fig. 12 shows that when a registration replay attack via a registration message time stamp from the network side is detected, a user concealment identifier and a concealment time stamp based on a corresponding registration message are used for wireless terminals (user equipment (User Equipment, UE)) and Exemplary data and logic flow for main network registration/authentication between core networks.

FIG. 13 shows the detection of a registration replay attack from the network side via a registration message timestamp based on the network-assigned temporary identity of the wireless terminal that cannot be verified and the hidden timestamp of the corresponding registration message for a wireless terminal (user). Exemplary data and logic flow of registration/authentication between a device (User Equipment, UE) and a core network.

Detailed ways

Exemplary communication network

As shown at 100 in FIG. 1 , an exemplary communication network may include terminal devices 110 and 112 , carrier network 102 , various service applications 140 and other data network 150 . For example, carrier network 102 may include access network 120 and core network 130 . Carrier network 102 may be configured to transport voice, data, and other information between end devices 110 and 112 , between end devices 110 and 112 and service application 140 , or between end devices 110 and 112 and other data networks 150 (collectively referred to as data services). Following the authentication process described in further detail below, a communication session and corresponding data path may be established and configured for such data transfer.

Access network 120 may be configured to provide end devices 110 and 112 with network access to core network 130 . Core network 130 may include various network nodes or network functions configured to control communication sessions and perform network access management and data traffic routing. Service applications 140 may be hosted by various application servers accessible by end devices 110 and 112 through core network 130 of carrier network 102 . The service application 140 may be deployed as a data network external to the core network 130 . Likewise, end devices 110 and 112 may access other data networks 150 through core network 130 and other data networks may appear as data destinations or data sources for particular communication sessions instantiated in carrier network 102 .

The core network 130 of FIG. 1 may include various network nodes or functions that are geographically distributed and interconnected to provide network coverage of 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 can be virtualized and implemented as virtual machines or software entities. Each network node can be configured with one or more types of network functions. These network nodes or network functions may collectively provide the provisioning and routing functions of the core network 130 . The terms "network node" and "network function" are used interchangeably in this disclosure.

FIG. 2 further shows an exemplary division of network functions in the core network 130 of the communication network 200 . Although only a single instance of a network node or function is shown in FIG. 2 , those of ordinary skill in the art will understand that each of these network nodes or functions can be instantiated as a network distributed throughout the core network 130 Multiple instances of a node. As shown in FIG. 2, the core network 130 may include but not limited to network nodes, for example, an access management network node (AccessManagement Network Node, AMNN) 230, an authentication network node (Authentication Network Node, AUNN) 260, a network data management network node (Network Data Management Network Node, NDMNN) 270, session management network node (Session Management Network Node, SMNN) 240, data routing network node (Data Routing Network Node, DRNN) 250, policy control network node (Policy Control NetworkNode, PCNN) 220 and an application data management network node (Application Data Management Network Node, ADMNN) 210. Exemplary signaling and data exchanges between various types of network nodes over various communication interfaces are represented by various solid connecting lines in FIG. 2 . Such signaling and data exchanges may be carried by signaling or data messages following a predetermined format or protocol.

The implementations described above in Figures 1 and 2 can be applied to both wireless and wired communication systems. FIG. 3 shows an exemplary cellular wireless communication network 300 based on a general implementation of the communication network 200 of FIG. 2 . 3 shows that a wireless communication network 300 may include a wireless terminal or user equipment (User Equipment, UE) 310 (used as the terminal device 110 in FIG. 2 ), a radio access network (Radio Access Network, RAN) 320 (used as the terminal device 110 in FIG. 2’s access network 120), service application 140, data network (Data Network, DN) 150 and core network 130, the core network includes access and mobility management function (Access and Mobility Management Function, AMF) 330 (used as FIG. 2 AMNN 230), session management function (Session Management Function, SMF) 340 (used as SMNN 240 of Fig. 2), application function (Application Function, AF) 390 (used as ADMNN 210 of Fig. 2), user plane management function (User PlaneFunction, UPF) 350 (used as DRNN 250 in FIG. 2), policy control function 322 (used as PCNN 220 in FIG. 2), authentication server function (Authentication Server Function, AUSF) 360 (used as AUNN 260 in FIG. ), and a unified data management/authentication credential repository and processing function (Unified Data Management/AuthenticationCredential Repository and Processing Function, UDM/ARPF) 370 (used as UDMNN 270 of FIG. 2). In addition, although only a single instance of some network functions or nodes of the wireless communication network 300 (especially the core network 130) is shown in FIG. There may be multiple instances of each distributed throughout the wireless communication network 300 .

In FIG. 3 , UE 310 may be implemented as various types of wireless devices or terminals configured to access core network 130 via RAN 320 . The UE 310 may include, but is not limited to, a mobile phone, a laptop computer, a tablet computer, an Internet-of-Things (IoT) device, a distributed sensor network node, a wearable device, and the like. UE 310 may include a mobile station (Mobile Station, ME) and a subscriber identity module (Subscriber Identity Module, SIM). A SIM module may eg be implemented in the form of a Universal Mobile Telecommunications System SIM (USIM), which includes some computing capabilities for network registration and authentication. Computations required to perform network registration and authentication can be performed by the USIM or by the ME in the UE. For example, RAN 320 may include a number of radio base stations distributed in the service area of a carrier network. The communication between UE 310 and RAN 320 may be carried in an over-the-air (OTA) radio interface, as shown by 311 in FIG. 3 .

Continuing with FIG. 3, UDM 370 may constitute a persistent store or database for user contracts and subscription profiles and data. The UDM may also include an Authentication Credential Repository and Processing Function (ARPF, shown at 370 in FIG. 3 ) for storing long-term security credentials for user authentication, and for executing authentication vectors using such long-term security credentials as input and the computation of the encryption key, 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.

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 signaling management from UE to Non-Access Stratum (Non-Access Stratum, NAS), and responsible for provisioning registration and access of UE 310 to core network 130, and allocation of SMF 340 to support a specific UE communication needs. AMF/SEAF 330 may further be responsible for UE mobility management. The AMF may also include a security anchor function (Security Anchor Function, SEAF, shown in 330 of Figure 3), as described in more detail below, the security anchor function interacts with the AUSF 360 and the UE 310 for user authentication and Management of encryption/decryption keys at various levels. AUSF 360 may 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.

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

Service applications 140 may be managed and provisioned by AF 390 via, for example, network exposure functionality provided by core network 130 (not shown in FIG. 3 but shown in FIG. 7 described below). SMF 340 may interact with AF 390 associated with service application 140 via communication interface 313 in managing a particular communication session involving service application 140 (eg, between UE 310 and service application 140 ).

PCF 322 may be responsible for managing and providing to AMF/SEAF 330 and SMF 340 various levels of policies and rules applicable to communication sessions associated with UE 310 . Thus, for example, AMF/SEAF 330 may assign SMF 340 to a communication session according to policies and rules associated with UE 310 and obtained from PCF 322 . Likewise, SMF 340 may assign UPF 350 to handle data routing and forwarding for communication sessions according to policies and rules obtained from PCF 322 .

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 . RAN 320 and AMF/SEAF 330 may or may not belong to a home carrier network (e.g., may be associated with another carrier network to which UE 310 is not subscribed, and may be referred to as a serving network, and the term "serving network" may be used Generally refers to an access network with an AMF/SEAF belonging to another carrier network or belonging to the same home core carrier network). AMF/SEAF 330 of the serving network may communicate with AUSF 360 and UDM/ARPF 370 of the home carrier network of UE 310 for authentication, and then communicate with SMF 340 and PCF 322 of the home carrier network to establish a communication session after successful authentication .

The various devices, terminals, and network nodes described above may include computing and communication components, such as processors, memories, various communication interfaces, various user display/operation interfaces, operating systems, and configured to implement various Example application.

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

The registration and authentication process may involve UE 310 communicating with its Home UDM/ARPF 370 via Serving RAN 320, Serving AMF/SEAF 330, Home AUSF 360 and Home UDM/ARPF, as described in more detail below. During the registration and authentication process, UE 310 verifies that it is communicating with a legitimate network, and the network also verifies that UE 310 is authorized to access the network. After successful authentication between the UE 310 and the core network 300, a temporary access identity may be assigned to the UE 310 for further communication with the core network. Such temporary access identifiers can be frequently modified/replaced to reduce the compromise of user identity, location, and communication content to attackers. Authentication can be initiated by the UE 310 sending a registration request to the serving AMF/SEAF 330, the registration request containing its concealed or encrypted unique permanent identity, eg Subscriber Concealed Identity (SUCI). Moreover, after successful registration, a temporary user identity such as a Global Unique Temporary Identity (GUTI) can be allocated to the UE 310 by the AMF/SEAF 330 for further access to the network.

As a result of an external attack via the wireless interface, the user's identity, location or communication content 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 a wireless interface can be used in a linkability attack, where it is possible for an attacker to determine whether a UE observed at a certain location/time X is the same as a UE observed at some other location/time Y , so as to track the UE. For example, an attacker can record the SUCI already used by UE A over the radio interface. In the case that UE A uses GUTI instead of SUCI for authentication, an attacker can also perform an active attack to obtain SUCI, e.g. by destroying GUTI when sent by UE A, which would likely result in a SUCI request by AMF/SEAF 330 and as Responsive SUCI transmission from UE. When some UE B later issues a registration request to a fake base station operated by the same attacker as a relay station, the attacker can modify UE B's registration request by exchanging its SUCI or GUTI with UE A's previously captured SUCI, and transfer The modified request is forwarded 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 and thus potentially track 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, and if so, UE A and UE B will be The attacker identified as the same UE.

This linkability attack cannot be mitigated by merely hiding the content of the AKA response, since an attacker can detect whether the AKA run was successful from various subsequent messages intercepted in the wireless interface without knowing the content of the AKA response. In the case that the content of the AKA response is not concealed, the attacker can directly use such content to determine whether the attacked UE is present near the fake base station.

Therefore, by replaying the SUCI, the attacker observes whether AKA can be successfully performed using the replayed SUCI, that is, whether the replayed registration request is accepted by the network. If so, an attacker could link a UE observed at one location with a UE observed at another location (replay its SUCI). When the attacker executes in several locations, even though the attacked UE may remain anonymous, it is possible to track the anonymous UE in different locations, and its privacy and untraceability are compromised.

As another example, the network may be subject to a DoS attack by an attacker by replaying SUCI. Specifically, an attacker may replay SUCI to cause the network and/or UE to perform frequent and repetitive procedures (eg, SUCI de-hiding procedure and authentication procedure). This can especially happen when the de-concealment scheme (e.g. Elliptical Curve Integrated Encryption Scheme (ECIES)) does not have any mechanism to detect or adjust whether the received SUCI is the one previously sent by the UE to the network .

In this way, if an attacker launches a SUCI replay attack many times, the UDM and UE may be forced to spend a lot of resources to process the replayed SUCI and authentication request messages separately, since these messages appear to be legitimate. This triggers a DoS attack on UDM and UE. The DoS attack on the UE may cause the UE's processing capability to decrease and the battery to be drained rapidly. A DoS attack on the UDM can cause the UDM to degrade its processing capabilities and delay responses to legitimate registration requests and other types of requests.

Hidden authentication serial number

In some implementations, to combat the aforementioned linkability and DoS attacks, UE 310 and the carrier network can maintain a pair of sequence numbers (or called authentication sequence numbers) to track authentication and re-authentication of UEs. These sequence numbers may be referred to as SQN _MS (on the UE side) and SQN _HE (on the carrier network side). For example, the SQN _HE may be maintained by the UDM/ARPF 370 in a home environment (HomeEnvironment, HE). These sequence numbers are only allowed to increase as the UE is authenticated and re-authenticated. Under normal network access conditions, the UE 310 and the carrier network can maintain synchronization between the SQN _MS and the SQN _HE . For example, detection of desynchronization by the UE 310 or the network during an authentication or re-authentication process may indicate potential attacks and other problems.

In some implementations of sequence number synchronization, the SQN _MS maintained by UE 310 may be communicated to the carrier network during some authentication procedures. Likewise, the SQN _HE maintained by UDM/ARPF can also be transmitted to the UE. However, in order to protect these serial numbers from being compromised, their transmission can be minimized and, when transmission is necessary, can be transmitted in an encrypted form which is considered secure. In one exemplary implementation described in more detail below, during the authentication process, the SQN _MS may be together with and in the same manner the transmission of the Subscription Permanent Identifier (SUPI) from the UE 310 to the AMF/SEAF 330 of the serving network transmission. Also, the SQN _HE from the UDM/ARPF side is embedded and encrypted in the authentication vector to be transmitted to the UE, as described in further detail below.

Specifically, the SQN _MS may be secured by sending to the AMF/SEAF 330 via a wireless interface after encryption based on, for example, an Elliptical Curve Integrated Encryption Scheme (ECIES). In other words, the use of ECIES to hide SUPI during the authentication process can be extended to accommodate SQN _MS and SUPI. In some implementations, SUPI can be combined with SQN _MS and used as a plaintext block for symmetric encryption under ECIES. The combination of SQN _MS and SUPI can have the forms of concatenation, interleaving, and the like. For example, in the case where the International Mobile Subscriber Identity (IMSI) replaces the SUPI for authentication, the Mobile Subscriber Identification Number (MSIN) (for example, 9 to 10 digits) and the SQN _MS can be identified by UE combines and encrypts/conceals. Correspondingly, in the home network, ECIES-based symmetric decryption can be used to hide SUPI (or MSIN) and SQN _MS .

Hidden Registration Timestamp

In some other implementations against the SUCI replay attack described above, the UE 310 may transmit the timestamp to the network along with the SUCI in a registration or authentication request message. Networks can rely on such timestamps to detect SUCI replay attacks. Similar to the authentication serial number described above, the timestamp can be combined with SUPI, and ECIES encryption is then performed on the combination. Combinations of SUPI and timestamps can be based on other forms of concatenation, interleaving.

The concealment of the time stamp of the registration/authentication request can be performed as an alternative or in addition to the concealment of the authentication serial number described above. For example, SUPI, serial number, and/or timestamp can be combined (eg, concatenated or interleaved) and then encrypted using the ECIES scheme.

SUCI data structure

The hidden concatenation of SUPI (or MSIN) and SQN _MS and/or timestamp can be sent to the AMF/SEAF 330 of the serving network as part of the SUCI data structure. An example of a SUCI data structure 400 is shown in FIG. 4 . The SUCI structure 400 includes a SUPI type field 402 , whose value ranges, for example, from 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 field 402 to indicate the following SUPI types:

-0: IMSI

-1: Network specific identifier

-2: Global Line Identifier (GLI)

-3: Global Cable Identifier (GCI)

-4: SUPI combined (eg, concatenated) with SQN _MS and/or message timestamps

-5 to 7: Reserved values for other indicators.

The SUPI type values and type correspondences listed above are for illustration purposes only. Other correspondences may be used. For example, other values including reserved values may be used to indicate that SUPI is hidden in combination with SQN _MS and/or registration message timestamps. Other fields of SUCI structure 400 include, for example, home network identifier 404 , routing indicator 406 , protection scheme identifier 408 , and home network public key identifier 410 .

Authentication based on hidden SUPI and authentication serial number

Figure 5 shows an 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 using hidden SUCI with SQN _MS , Assume that the authentication between UE 310 and the network is successful. Logic and data flow 500 may include the following exemplary steps, which have corresponding step numbers in FIG. 5 .

1. During the main authentication process 500, the USIM and ME combine the SUPI of the UE 310 and the current SQN _MS maintained by the USIM or ME via eg concatenation or interleaving. The combined (eg, concatenated or interleaved) plaintext blocks of SUPI and SQN _MS can be encrypted using the ECIES method in the USIM or ME. The SUCI data structure following Figure 4 can be constructed to include a cryptographic combination of SUPI and SQN _MS . The "SUPI Type" field of the SUCI structure (402 of FIG. 4 ) may be set to indicate that the SUCI structure contains a hidden combination of SUPI and SQN _MS . For example, a value of "4" may be set in the "SUPI Type" field of the SUCI structure.

2. The UE may use the SUCI data structure containing the hidden SQN _MS in the Registration Request message sent from the UE 310 to the Serving AMF/SEAF 330 .

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 AUSF service (indicated as Nausf_UEAuthentication service). For example, the Nausf_UEAuthentication_Authenticate request message may contain SUCI and service network name embedded with hidden SUPI and SQN _MS .

4. Once the Nausf_UEAuthentication_Authenticate request message is received, the home AUSF 360 can check whether the requesting AMF/SEAF 330 in the serving network is authorized to use the The service network name for . Home AUSF 360 may temporarily store the received service network name. If the serving network is not authorized to use the received serving network name, AUSF 360 may respond to UE 310 in a response message denoted 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 Nudm_UEAuthentication_Get request may be sent from home AUSF 360 to home UDM/ARPF 370 . A Nudm_UEAuthentication_Get request may contain the following information:

- SUPI containing hidden SUPI and SQN _MS ; and

- service network name.

5. Once the Nudm_UEAuthentication_Get request is received, if the home UDM/ARPF 370 determines that the SUPI type is the SUPI combined with the SQN _MS according to the SUPI type field of the received SUCI data structure, the UDM/ARPF 370 can call the user identification de-hiding function (De- concealment Function, SIDF). Therefore, before the UDM 370 is able to process the request, the SIDF can de-conceal the received SUCI to obtain SUPI and SQN _MS . Based on SUPI, UDM/ARPF 370 can perform its authentication process. The de-concealed SQN _MS may be stored in UDM 370 for future use (as described in more detail below with reference to FIG. 6). UDM 370 can also generate a new SQN _HE that is larger than the current SQN _HE maintained by the UDM. Then, the current SQN _HE is replaced by the updated SQN _HE . An authentication vector is also generated based on the updated SQN _HE and other information (the components of the authentication vector are in step 6 below).

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) break bit set to "1". UDM/ARPF 370 can then derive the AUSF key K _AUSF and compute the eXpected RESponse represented by XRES*. Finally, UDM/ARPF 370 can create the HE AV from the random number represented by RAND, the authentication key represented by AUTN, XRES* and K _AUSF . For example, AUTN contains information of SQN _HE . UDM/ARPF 370 may then return the HE AV to AUSF 360 in a response to AUSF 360 represented by the Nudm_UEAuthentication_Get response, along with an indication that the HE AV is to be used for AKA. UDM/ARPF 370 may include the de-hidden SUPI in the Nudm_UEAuthentication_Get response.

7. The AUSF 360 can temporarily store the XRES* along with the SUPI received from the UDM/ARPF 370 .

8. The AUSF 360 can then generate an AV based on the HE AV received from the UDM/ARPF 370 by computing the hash XRES denoted HXRES* from XRES* and the SEAF key denoted K _SEAF from K _AUSF , And replace XRES* with HXRES* and K _AUSF with K _SEAF in HE AV.

9. AUSF 360 may then remove K _SEAF and return to SEAF 330 the Service Context Authentication Vector (comprising RAND, AUTN, and HXRES*) denoted SE AV in a Response message denoted Nausf_UEAuthentication_Authenticate Response

10. The SEAF 330 may send the RAND and AUTN included in the AV to the UE in a non-access stratum (Non-Access Stratum, NAS) message authentication request. The message may also include the ngKSI that the UE and the AMF will use to identify the K _AMF and part of the local security context created in case of successful authentication. The ME may forward the RAND and AUTN received in the NAS message authentication request to the USIM.

11. Upon receiving RAND and AUTN, the UE (eg USIM or ME) can verify the freshness of the AV by checking if AUTN is acceptable. For example, the UE can extract the SQN _HE contained in the AUTN and compare it with the local SQN _MS . If SQN _HE is not less than SQN _MS , the UE may determine that the sequence number synchronization is successful. Otherwise, the UE determines that the sequence number synchronization fails. When the UE determines that the sequence numbers SQN _MS and SQN _HE are synchronized, the UE performs the remaining steps in Figure 5, as described below. If sequence number synchronization is confirmed, the USIM may compute a response denoted by RES. USIM can return RES, CK, IK to ME. If USIM calculates Kc based on CK and IK using conversion function c3 (ie GPRS Kc) and sends it to ME, ME can ignore this GPRS Kc and not store GPRS Kc on USIM or in ME. The ME may then calculate RES* based on RES. The ME may calculate K _AUSF based on CK||IK. The ME may calculate K _SEAF based on K _AUSF . The ME accessing the network can check whether the "separation bit" in the AMF field of the AUTN is set to 1 during authentication. The "break bit" is bit 0 of the AMF field of AUTN. Once the sequence number synchronization between the SQN _MS and SQN _HE is determined, the UE updates (or replaces) its SQN _MS with the extracted SQN _HE for future synchronization purposes.

12. UE 310 may return RES* to SEAF in a NAS message Authentication Response.

13. SEAF 330 can then calculate HRES* based on RES*, and SEAF 330 can compare HRES* and HXRES*. If they are consistent, from the perspective of the serving network, SEAF 330 may consider that the authentication of UE 310 is successful. When authentication is successful, follow the remaining steps in Figure 5 below. If unsuccessful, SEAF 330 may notify the network of authentication failure by, for example, sending a response message with a failure code and/or discarding/stopping/exiting authentication. If the UE is not contacted (eg, no response is obtained from the UE), and SEAF 330 never receives a RES*, SEAF may consider authentication to have failed and indicate failure to AUSF 360 .

14. SEAF 330 may send the RES* received from UE 310 to AUSF 360 in a message denoted by a Nausf_UEAuthentication_Authenticate request message.

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

16. The AUSF 360 may indicate to the SEAF 330 in a response message denoted Nausf_UEAuthentication_Authenticate response whether the authentication was successful from the perspective of the home network. If authentication is successful, K _SEAF may be sent to SEAF 330 in the Nausf_UEAuthentication_Authenticate response. If authentication is successful, AUSF 360 may also include SUPI in the Nausf_UEAuthentication_Authenticate response message.

17. The AUSF 360 may inform the UDM 370 of the result and time of the authentication procedure with the UE 310 using a request message denoted Nudm_UEAuthentication_ResultConfirmation request. The request may include the SUPI, the timestamp of the authentication, the authentication type (eg, EAP method or AKA), and the serving network name.

18. UDM 370 can store UE 310 authentication status (SUPI, authentication result, time stamp and serving network name) and update its previously stored SQN _MS with current SQN _HE for future authentication serial number synchronization purposes.

19. UDM 370 may reply to AUSF 360 with a response message denoted Nudm_UEAuthentication_ResultConfirmation response.

20. Upon receipt of subsequent UE related procedures (eg Nudm_UECM_Registration_Request from AMF 330), UDM 370 may apply actions according to the home operator's policies to detect and enable protection against certain types of fraud.

21. Finally, AMF 330 allocates a GUTI to UE 310 for further authentication.

Authentication steps 13 and 15 may fail, indicating that the UE cannot be authenticated. In these cases, fault messages may be sent to UDM 370 in series. Similar to step 18 above, UDM 370 may still store the authentication status and update the stored SQN _MS with the current SQN _HE .

Serial number synchronization failure processing

In step 11 as shown in FIG. 5 and described above, when the SQN _HE extracted from the AUTN received by the AMF 310 is smaller than the local SQN _MS , the UE 310 may determine that the sequence number synchronization fails. FIG. 6 illustrates an example logic and data flow 600 for re-authentication (RA) following such a sequence number synchronization failure.

In RA0, as shown in FIG. 6, the UE 310 may not calculate any authentication failure information (eg, AUTS) embedded with the SQN _MS for transmission to the AMF 330 to avoid another exposure of the SQN _MS in the radio interface. Instead, UE 310 simply sends a response message to AMF 330 indicating that the reason for the failure was sequence number desynchronization. Such desynchronization may occur, for example, when the UE 310 and the network are under a SUCI replay attack. As an example of RA1, UE 310 may respond to NAS message authentication failure with only a cause value indicating the reason for failure as SQN failure/mismatch, without computing and sharing the AUTS with the network.

In RA2, when receiving an authentication failure message from UE 310, SEAF 330 may send a request message denoted Nausf_UEAuthentication_Authenticate request message to AUSF 360 .

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

In RA4, when UDM/ARPF 370 receives a Nudm_UEAuthentication_Get request message from AUSF 360, ARPF 370 may be mapped to HE/AuC. UDM/ARPF 370 may send a response message represented by a Nudm_UEAuthentication_Get response message for utilizing the new SQN _MS stored in UDM 370 (for example, in step 5 or 18 of _FIG . Authentication vector for UE re-authentication. AUSF 360 runs the new authentication process with UE 310 following the principles of steps 6-11 of FIG. 5 .

SUPI failed GUTI authentication

FIG. 7 shows a logic and data flow 700 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. 5 GUTI obtained in step 21) of the SUCI registration process shown. Steps 0-2 in Fig. 7 are described below.

0. The UE 310 can use a temporary identity such as a GUTI to initiate the registration process.

1. The UE 310 may use the temporary identity GUTI in the Registration Request message, which is sent to the Serving AMF/SEAF 330 .

2. The Serving AMF/SEAF 330 may try to obtain the UE's SUPI from the old AMF/SEAF 702, e.g. Step 2a), then the serving AMF/SEAF 330 may send an identity request message with an identity type to the UE 310 (step 2b of FIG. 7 ). When receiving the Identity Request message, UE 310 may send an Identity Response message to AMF/SEAF 330, wherein the SUCI is embedded in the current SQN _MS (step 2c of FIG. 7).

The remaining step 3-21 in logic and data flow 700 essentially uses SUCI to perform the authentication process and corresponds to step 3-21 in logic and data flow 500 of FIG. 5 . These steps are shown in FIG. 7 and explained above with respect to FIG. 5 and will not be repeated here.

Additionally, if the SQN synchronization check fails at UE 310 in step 11 of FIG. 7, the logic and data flow 600 of FIG. 6 may be followed to perform a re-authentication procedure, as described in more detail above.

Furthermore, authentication steps 13 and 15 may fail, indicating that UE 310 cannot be authenticated by the network. In those cases, fault messages may be sent to UDM 370 in a serial fashion as described above for FIG. 5 . Similar to step 18 in Fig. 7 and the above description for step 18 in Fig. 5, the UDM can still store the authentication status and update the stored SQN _MS with the current SQN _HE .

Successfully obtained SUPI's GUTI certification

FIG. 8 shows a logic and data flow 800 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. The GUTI obtained in step 21) of the SUCI registration process, wherein the serving network has successfully identified the SUPI of the UE. The logic and data flow 800 of FIG. 8 is similar to the logic and data flow 500 of FIG. 5 except for steps 0-5, which will be described in more detail below.

0. The home UDM 370 has previously stored the SQN _MS of the UE 310 .

1a. The UE 310 may initiate a registration procedure with the GUTI.

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

2. Serving AMF/SEAF 330 successfully obtains UE context with SUPI from old AMF/SEAF 702 .

3. Whenever the serving AMF/SEAF 330 wishes to initiate authentication, the serving AMF/SEAF 330 can 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 SUPI and the service network name.

4. Once the Nausf_UEAuthentication_Authenticate request message is received, the home AUSF 360 can check whether the requesting AMF/SEAF 330 in the serving network is authorized to use the The service network name for . Home AUSF 360 may temporarily store the received service 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 the response message represented by the Nausf_UEAuthentication_Authenticate response. AUSF 360 may then send a request message to home UDM/ARPF 370 denoted Nudm_UEAuthentication_Get request. The Nudm_UEAuthentication_Get request may include UE's SUPI and serving network name.

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 SUPI. At the home UDM 370, an updated SQN _HE greater than the previous sequence number for the UE 310 is used to generate the home environment AV vector.

The difference between the above-described steps of the logic and data flow 800 of FIG. 8 and the corresponding steps in the logic and data flow 500 of FIG. 5 is that during the authentication process, SUPI is passed from the serving network to the home network instead of SUCI. In this way, the UE's SQN _MS will not be sent to the home UDM/ARPF 370, and the SQN _MS previously stored in the home UDM will not be updated with the current SQN _MS as indicated in step 0 of Figure 8 .

The remaining steps 6-21 in the logic and data flow 800 of FIG. 8 essentially perform an authentication process that corresponds to steps 6-21 in the logic and data flow 500 of FIG. 5 . These steps are summarized in Figure 8 and explained above in conjunction with Figure 5 and will not be repeated here.

Furthermore, if the SQN synchronization check fails at the UE in step 11 of FIG. 8, the logic and data flow 600 of FIG. 6 may be followed to perform a re-authentication procedure, 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 at step RA4 may be based on the previously stored SQN _MS . Any successful authentication (in logic and data flow 800 of FIG. 8, 500 of FIG. 7, and 700 of FIG. 7) will update (or synchronize) the SQN _MS maintained at UDM 370, which is Based on the result of replacing the stored SQN _MS with the current SQN _HE at step 18 of , the update is missing in the GUTI authentication steps 1-5 in the logic and data flow 800, so the SQN _MS maintained at the UDM 370 does not become out of sync.

Furthermore, authentication steps 13 and 15 of the logic and data flow 800 of FIG. 8 may fail, indicating that the UE 310 cannot be authenticated by the network. In those cases, the fault message may be sent in series to UDM 370 as described above for FIG. 5 . Similar to step 18 in FIG. 8 and the above description for step 18 in FIG. 5, UDM 370 may still store the authentication status and update the stored SQN _MS with the current SQN _HE .

Using SQN to counter SUCI replay attack on the network side

In some implementations, a SUCI replay attack may be detected at the network side based on the UE-side sequence number SQN _MS and the HE-side sequence number SQN _HE . The SQN _MS becomes available to the network side due to the transmission of the SUCI embedding the hidden permanent UE identity and the hidden SQN _MS in steps 1-5 shown in Fig. 5 and Fig. 7 .

9 illustrates an example logic and data flow 900 for a registration/authentication process initiated by a UE 310 using SUCI (eg, SUPI) and SQN _MS with concealed network identity. The logic and data flow 900 is similar to the logic and data flow 500 of FIG. 5 , except that in step 5, the SUCI replay attack detection procedure is performed by the home UDM 370 .

Specifically, in step 5 of the logic and data flow 900, upon receiving the Nudm_UEAuthentication_Get request sent from the home AUSF 360, if the SUPI type is SUPI combined with the SQN _MS , the home UDM 370 can invoke SIDF, and the SIDF process can be performed in Home UDM 370 may de-conceal the received SUCI to obtain SUPI and SQN _MS associated with UE 310 before processing the request.

For the SUCI replay attack detection from the network side in step 5 of the logic and data flow 900 of FIG. 9 , the home UDM 370 makes the following exemplary determination process:

- If the home UDM 370 does not have a locally stored SQN _MS of the UE 310, it may store the SQN _MS received through the SUCI, further select an authentication method based on the SUPI, and generate an AV based on the updated and added SQN _HE .

- If the home UDM 370 has a previously stored SQN _MS for the UE 310, it may be configured to compare the received SQN _MS with the previously stored SQN _MS .

If the comparison shows that the received SQN _MS is less than or equal to the previously stored SQN _MS , the home UDM 370 determines that a SUCI replay attack has occurred and either responds with a fault code or discards the message to stop the authentication process.

However, if the comparison shows that the received SQN _MS is larger than the stored SQN _MS , the home UDM 370 may instead be configured to select a SUPI based authentication method, generate an AV based on the updated and added SQN _HE , and continue with remaining authentication process.

If SQN _HE is less than or equal to the stored SQN _MS , the home UDM 370 discards the AV and SQN _HE , and generates a new AV with an updated SQN _HE .

The remaining steps in the logic and data flow 900 of FIG. 9 , except step 5, essentially execute an authentication process corresponding to the corresponding steps in the logic and data flow 500 of FIG. 5 . These steps are summarized in Figure 9 and explained above in conjunction with Figure 5 and will not be repeated here.

Similarly, FIG. 10 shows a logic and data flow 1000 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., GUTI obtained from step 21) in the SUCI registration process shown in Figure 9. The steps in FIG. 10 are similar to those in FIG. 7 except that step 5 includes a process for detecting SUCI replay attacks. Step 5 in the logic and data flow 1000 of FIG. 10 is similar to step 5 in the logic and data flow 900 shown in FIG. 9 and described in detail above. As such, the steps summarized in FIG. 10 will not be described again here.

Furthermore, FIG. 11 shows a registration/authentication process initiated by the UE 310 using a network-assigned temporary identifier, e.g., via a previous registration and authentication process (e.g., from the SUCI registration process shown in FIG. 9 or FIG. Step 21) The obtained GUTI, wherein the serving network has successfully identified the UE's SUPI. The steps in Figure 11 are similar to those in Figure 8, except that in step 5, UDM 370 can select an authentication method based on SUPI, and generate an AV based on SQN _HE , and if SQN _HE is less than or equal to SQN _MS , UDM 370 can discard the AV and SQN _HE , and generate new AV and SQN _HE .

Furthermore, if the SQN synchronization check fails at the UE in step 11 of Figures 9, 10 and 11, the logic and data flow 600 of Figure 6 may be followed to perform a re-authentication procedure, 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 at step RA4 may be based on the previously stored SQN _MS .

Counter SUCI replay attack on the network side by using registration request message timestamp

In some implementations, a SUCI replay attack can be detected on the network side based on the UE registration request timestamp. The registration time stamp becomes available to the network side due to the transmission of SUCI embedding the concealed UE identity and the concealed time stamp as described above.

12 illustrates an example logic and data flow 1200 for a registration/authentication process initiated by UE 310 using SUCI with concealed network identity (eg, SUPI) and concealed registration request timestamp. The logic and data flow 1200 is similar to the logic and data flow 900 of Figure 9, except that the hidden information in SUCI includes UE identity and registration request timestamp instead of UE identity and SQN _MS , and in step 5, the home UDM 370 is based on the registration A timestamp is requested instead of an authentication sequence number to perform the SUCI replay attack detection process.

Exemplary steps 1-5 of the logic and data flow 1200 shown in FIG. 12 are described in more detail below.

1. During the main authentication procedure, UE 310 (eg USIM) combines SUPI and Registration Request or message timestamp denoted as MESSAGE_TIME by concatenation, interleaving or other combination. For example, MESSAGE_TIME may represent the UTC-based time when a message (eg, a registration or authentication message) was sent. The SUCI data structure following Figure 4 can be structured to include an encrypted combination of SUPI and MESSAGE_TIME. The "SUPI Type" field of the SUCI structure (402 of FIG. 4 ) 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.

2. The UE may use the SUCI containing the hidden MESSAGE_TIME in the Registration Request message sent from the UE 310 to the Serving AMF/SEAF 330 .

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

4. Once the Nausf_UEAuthentication_Authenticate request message is received, the home AUSF 360 can check whether the requesting AMF/SEAF 330 in the serving network is authorized to use the The service network name for . AUSF 360 may temporarily store the received service network name. If the serving network is not authorized to use the received serving network name, AUSF 360 may respond to UE 310 in a response message denoted 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 Nudm_UEAuthentication_Get request may be sent from home AUSF 360 to home UDM/ARPF 370 . The Nudm_UEAuthentication_Get request sent from AUSF 360 to UDM 370 may include the following information:

- SUPI containing hidden SUPI and MESSAGE_TIME; and

- service network name.

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

- If the received MESSAGE_TIME is less than the current UTC-based time minus a predetermined maximum delay time (denoted MAX_DELAY), the home UDM 370 may respond with a fault 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 according to an estimated data transmission speed between UE 310 and UDM 370 . MAX_DELAY can be further adjusted as needed.

- 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 with the remainder of FIG. 12 Authentication steps.

The remaining steps in the logic and data flow 1200 of FIG. 12 , except for steps 1-5, essentially perform an authentication process that corresponds to the corresponding steps in the logic and data flow 500 of FIG. A SQN _MS update involving the UE side is required and a SQN _MS update not involving the network side may not be required in step 18 . These steps are summarized in Figure 12 and explained above in conjunction with Figure 5 and will not be repeated here.

Similarly, FIG. 13 shows a logic and data flow 1300 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 the SUCI GUTI obtained in step 21) of the registration process. The individual steps of Figure 13 are similar to those of Figure 7, except that Steps 1-5 use hidden timestamps instead of SQN _MSs (as described in Steps 1-5 of Figure 12), and Step 5 includes a method for detecting SUCI replay _The process of the attack is similar to step 5 in the logic and data flow 1200 shown in FIG. A SQN _MS update that does not involve the network side is required. As such, the steps summarized in FIG. 13 will not be described again here.

Combination of hidden SQN _MS and hidden registration request message timestamps

In some other implementations, both SQN _MS and registration message timestamps may be used. In other words, both the SQN _MS and the registration message timestamp can be combined with SUPI and concealed to generate SUCI for registration and authentication. As such, the various logical data flows in Figures 5, 7, 9, 10, and 11 can be combined with the logic and data flows in Figures 12 and 13 to form other logical and data flows. For example, both the SQN _MS and the registration message timestamp can be transmitted to the home UDM 370 where the SQN _MS is stored, and both the sequence number and the timestamp can be used to detect and respond to SUCI replay attacks.

The above figures and description provide specific exemplary embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms, therefore, it is intended that the subject matter covered or claimed should not be construed as limited to any of the exemplary embodiments set forth herein. It is intended to provide a reasonably broad scope for the subject matter claimed or covered. Also, for example, the subject matter can be embodied as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Thus, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the above-mentioned method embodiments may be implemented by components, devices or systems including a memory and a processor by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have implied or implied nuanced meanings from context to context, in addition to the expressly stated meaning. Likewise, the phrase "in one embodiment/implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment/implementation" as used herein does not necessarily refer to a different embodiment. For example, it is intended that the claimed subject matter comprises, in whole or in part, combinations of the exemplary embodiments.

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

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

Furthermore, the described features, advantages, and characteristics of the present solutions may be combined in any suitable manner in one or more embodiments. Those of ordinary skill in the relevant art will recognize, from the description herein, that the present aspects can be practiced without one or more of the specific features or advantages of a particular embodiment. In other cases, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present invention.

Claims (20)

1. A method performed by a first network element of a communication network for authenticating a second network element to access the communication network, the method comprising:

Receiving an authentication message initiated from the second network element;

the authentication message is unhidden to obtain a unhidden sequence number maintained by the first network element and a unhidden user identity of the second network element;

storing the unhidden sequence number in the first network element;

generating a new sequence number and generating an authentication vector based on the new sequence number;

transmitting the authentication vector to the second network element; and

when an authentication response message to the authentication vector is received from the second network element, the unhidden sequence number stored in the first network element is replaced with the new sequence number.

2. The method of claim 1, wherein after replacing the unhidden sequence number stored in the first network element with the new sequence number, further comprising:

receiving an authentication failure message from the second network element, wherein the authentication failure message is used for indicating that the second network element detects that the sequence number synchronization fails;

generating a re-authentication vector based on the stored replaced de-hidden sequence number; and

and sending the reauthentication vector to the second network element.

3. The method of claim 1, wherein unhiding the authentication message to obtain the unhiding sequence number and the unhiding user identification comprises:

Acquiring a hidden identifier of the second network element from the authentication message;

decrypting the hidden identifier to obtain a decrypted composite data item; and

extracting the unhidden user identity and the unhidden sequence number from the decrypted composite data item.

4. A method according to claim 3, further comprising:

extracting a type indicator from the authentication message, wherein the type indicator is used for indicating the type of the hidden identifier; and

before decrypting the hidden identifier, determining that the type indicator indicates that the hidden identifier comprises a hidden composite data item, wherein the hidden composite data item comprises a hidden user identifier and a hidden serial number.

5. The method of claim 4, wherein the type indicator comprises a unique value when the hidden identifier is indicated to be a composite data item, wherein the unique value is used to indicate that the hidden identifier comprises a hidden combination of a user identifier and a serial number.

6. The method of claim 4, wherein the hidden identifier is encapsulated in a user hidden identifier, sui.

7. A method according to claim 3, wherein the decrypted composite data item comprises the dehazed user identity in series with the dehazed sequence number.

8. A method according to claim 3, wherein the decrypted composite data item comprises the dehazed user identity interleaved with the dehazed sequence number.

9. A method according to claim 3, wherein the hidden identifier is decrypted using an elliptic curve integrated encryption scheme ECIES scheme to obtain the decrypted composite data item.

10. A method according to claim 3, wherein the unhidden subscriber identity comprises a subscriber permanent identity SUPI.

11. The method of 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 credential repository and a processing function, ARPF, of the communication network.

12. The method of claim 1, wherein the authentication message comprises one of:

a registration request message initiated by the first network element; or alternatively

The first network element sends an identity response message in response to an identity request from the communication network.

13. The method of claim 1, wherein the authentication vector is sent to the second network element via at least one other intermediate network element of the communication network.

14. A method performed by a first network element of a communication network for authenticating a second network element to access the communication network, the method comprising:

receiving an authentication message initiated from the second network element, wherein the authentication message contains a unhidden user identifier of the second network element;

generating a new sequence number and generating an authentication vector based on the new sequence number;

transmitting the authentication vector to the second network element; and

when an authentication response message to the authentication vector is received from the second network element, the previously stored sequence number associated with the first network element is replaced with the new sequence number.

15. The method of claim 14, wherein after replacing the previously stored sequence number with the new sequence number, further comprising:

receiving an authentication failure message from the second network element, wherein the authentication failure message is used for indicating that the second network element detects that the sequence number synchronization fails;

generating a reauthentication vector based on the stored replaced serial number; and

and sending the reauthentication vector to the second network element.

16. The method of claim 14, wherein the unhidden subscriber identity comprises a subscriber permanent identity SUPI.

17. The method of claim 14, 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 credential repository and a processing function, ARPF, of the communication network.

18. The method of claim 14, wherein the authentication vector is sent to the second network element via at least one other intermediate network element of the communication network.

19. The first network element of any one of claims 1-18, comprising a processor configured to implement the method of any one of claims 1-18.

20. A computer program product comprising a non-transitory computer readable program medium having computer code stored thereon, which, when executed by a processor, causes the processor to implement the method of any of claims 1-18.