WO2022067628A1

WO2022067628A1 - A method for preventing encrypted user identity from replay attacks

Info

Publication number: WO2022067628A1
Application number: PCT/CN2020/119264
Authority: WO
Inventors: Shilin You; Jiyan Cai; Yuze LIU; Jin Peng; Zhen XING; Zhaoji Lin; Boshan Zhang; Jigang Wang
Original assignee: Zte Corporation
Priority date: 2020-09-30
Filing date: 2020-09-30
Publication date: 2022-04-07
Also published as: CN115699672A

Abstract

This disclosure relates generally to registration and authentication processes between a wireless terminal and a core network and specifically to detection of registration replay attacks from the core network side to reduce leakage of confidential user information based on a set of authentication sequence numbers that are maintained and updated in synchronization on both the wireless terminal side and the core network side. The communication of the sequence numbers between the wireless terminal and the core network is minimized and is further effectively concealed from exposure in the radio interface during the limited number of transmission. A detection of de-synchronization of the sequence numbers between the wireless terminal and the core network is used by the core network to determine registration replay attacks and to stop communicating request and response messages that may lead to leakage of confidential information of the wireless terminal and in some situation, denial-of-service for either the terminal device or the network.

Description

A METHOD FOR PREVENTING ENCRYPTED USER IDENTITY FROM REPLAY ATTACKS

TECHNICAL FIELD

This disclosure is directed generally to registration and authentication process between a mobile terminal and a core network and particularly to preventing replay attacks.

BACKGROUND

A wireless terminal device may communicate with its home core network via a serving network. Prior to obtaining access to the home core network, the wireless terminal may initiate a registration and authentication procedure. The wireless terminal, the serving network, and the home core network interact with one another to authenticate the wireless terminal to the network and authenticate the network to the wireless terminal. Access credentials are generated upon successful registration and authentication to enable further communication between the wireless terminal and the network. The communication messages between the UE and the network via a radio interface, either encrypted or unencrypted, may be subject to attacks by hackers. Confidential information about the wireless terminal may be gained by the hackers via such attacks.

SUMMARY

In some example implementations, a method performed by a first network element of a communication network for an authentication procedure of a second network element for accessing the communication network is disclosed. The method may include receiving an authentication message initiated from the second network element; extracting from the authentication message a concealed sequence number to obtain a de-concealed sequence number maintained by the first network element, and a concealed subscription identifier of the second network element to obtain a de-concealed subscription identifier; processing the authentication procedure depending on a determination outcome of whether a previous sequence number for the second network element was stored in the first network element during a previous authentication procedure of the second network element; and upon determining that the previous sequence number was stored in the first network elements, further processing the authentication procedure depending on a comparison result between the de-concealed sequence number and the previous sequence number.

In some other implementations, a network device is disclosed. The network device main include one or more processors and one or more memories, wherein the one or more processors are configured to read computer code from the one or more memories to implement the method above as performed by the first network element.

In yet some other implementations, a computer program product is disclosed. The computer program product may include a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement the method above.

The above embodiments and other aspects and alternatives of their implementations are explained in greater detail in the drawings, the descriptions, and the claims below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary communication network including terminal devices, a carrier network, 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 example data structure for a subscriber concealed identity used for network registration and authentication of a wireless terminal.

FIG. 5 shows an example data and logic flow for a primary network registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a subscriber concealed identity and a concealed authentication sequence number of the wireless terminal.

FIG. 6 shows an example data and logic flow for re-authentication upon a detection of authentication sequence number de-synchronization by a wireless terminal (user equipment (UE) ) .

FIG. 7 shows an example data and logic flow for registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a network-allocated temporary identity of the wireless terminal that cannot be verified and authentication sequence numbers.

FIG. 8 shows an example data and logic flow for registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a successfully validated network-allocated temporary identity of the wireless terminal and authentication sequence numbers.

FIG. 9 shows an example data and logic flow for a primary network registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a subscriber concealed identity and a concealed authentication sequence number of the wireless terminal and with a detection of authentication sequence number de-synchronization from the network side.

FIG. 10 shows an example data and logic flow for registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a network-allocated temporary identity of the wireless terminal that cannot be verified and authentication sequence numbers with a detection of authentication sequence number de-synchronization from the network side.

FIG. 11 shows an example data and logic flow for registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a successfully validated network-allocated temporary identity of the wireless terminal and authentication sequence numbers, and a detection of authentication sequence number de-synchronization from the network side.

FIG. 12 shows an example data and logic flow for a primary network registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a subscriber concealed identity and a concealed timestamp of a corresponding registration message and with a detection of registration replay attacks via the registration message timestamp from the network side.

FIG. 13 shows an example data and logic flow for registration/authentication between a wireless terminal (user equipment (UE) ) and a core network based on a network-allocated temporary identity of the wireless terminal that cannot be verified and a concealed timestamp of a corresponding registration message, and with a detection of registration replay attacks via the registration message timestamp from the network side.

DETAILED DESCRIPTION

Example Communication Network

An exemplary communication network, shown as 100 in FIG. 1, may include

terminal devices

110 and 112, a carrier network 102, various service applications 140, and other data networks 150. The carrier network 102, for example, may include access networks 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 traffic) among

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 the other data networks 150. Following authentication processes further detailed below, communication sessions and corresponding data paths may be established and configured for such data transmission.

The Access networks 120 may be configured to provide the

terminal devices

110 and 112 network access to the core network 130. The core network 130 may include various network nodes or network functions configured to control the communication sessions and perform network access management and data traffic routing. The service applications 140 may be hosted by various application servers that are accessible by the

terminal devices

110 and 112 through the core network 130 of the carrier network 102. A service application 140 may be deployed as a data network outside of the core network 130. Likewise, the other data networks 150 may be accessible by the

terminal devices

110 and 112 through the core network 130 and may appear as either data destination or data source of a particular communication session instantiated in the carrier network 102.

The core network 130 of FIG. 1 may include various network nodes or functions geographically distributed and interconnected to provide network coverage of a service region 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 as software entities. A network node may each be configured with one or more types of network functions. These network nodes or network functions may collectively provide the provisioning and routing functionalities of the core network 130. The term “network nodes” and “network functions” are used interchangeably in this disclosure.

FIG. 2 further shows an exemplary division of network functions in the core network 130 of a communication network 200. While only single instances of network nodes or functions are illustrated in FIG. 2, those having ordinary skill in the art understand that each of these network nodes or functions may be instantiated as multiple instances of network nodes that are distributed throughout the core network 130. As shown in FIG. 2, 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 the various types of network nodes through various communication interfaces are indicated by the various solid connection lines in FIG. 2. Such signaling and data exchange may be carried by signaling or data messages following predetermined formats or protocols.

The implementations described above in FIGs. 1 and 2 may be applied to both wireless and wireline communication systems. FIG. 3 illustrates an exemplary cellular wireless communication network 300 based on the general implementation of the communication network 200 of FIG. 2. FIG. 3 shows that the wireless communication network 300 may include wireless terminals or user equipment (UE) 310 (functioning as the terminal device 110 of FIG. 2) , radio access network (RAN) 320 (functioning as the access network 120 of FIG. 2) , service applications 140, data network (DN) 150, and core network 130 including access management function (AMF) 330 (functioning as the AMNN 230 of FIG. 2) , session management function (SMF) 340 (functioning as the SMNN 240 of FIG. 2) , application function (AF) 390 (functioning as the ADMNN 210 of FIG. 2) , user plane function (UPF) 350 (functioning as the DRNN 250 of FIG. 2) , policy control function 322 (functioning as the PCNN 220 of FIG. 2) , authentication server function (AUSF) 360 (functioning as the AUNN 260 of FIG. 2) , and universal data management/authentication credential repository and processing function (UDM/ARPF) 370 (functioning as the UDMNN 270 of FIG. 2) . Again, while only single instances for some network functions or nodes of the wireless communication network 300 (the core network 130 in particular) are illustrated in FIG. 3, those of ordinary skill in the art understand that each of these network nodes or functions may have multiple instances that are distributed throughout the wireless communication network 300.

In FIG. 3, the UE 310 may be implemented as various types of wireless devices or terminals that are configured to access the core network 130 via the RAN 320. The UE 310 may include but is not limited to mobile phones, laptop computers, tablets, Internet-of-Things (IoT) devices, distributed sensor network nodes, wearable devices, and the like. The UE 310 may include a mobile station (ME) and a System Subscription Module (SIM) . The SIM module may be implemented, for example, in the form of a Universal Mobile Telecommunication SIM (USIM) that include some computing capability for network registration and authentication. The computing needed for performing network registration and authentication may be performed by the USIM or by the ME in the UE. The RAN 320 for example, may include a plurality of radio base stations distributed throughout the service areas of the carrier network. The communication between the UE 310 and the RAN 320 may be carried in over-the-air (OTA) radio interfaces as indicated by 311 in FIG. 3.

Continuing with FIG. 3, the UDM 370 may form a permanent storage or database for user contract and subscription profile and data. The UDM may further include an authentication credential repository and processing function (ARPF) , as indicated in 370 of FIG. 3) for storage of long-term security credentials for user authentication, and for using such long-term security credentials as input to perform computation of authentication vectors and encryption keys as described in more detail below. To prevent unauthorized exposure of UDM/ARPF data, the UDM/ARPF 370 may be located in a secure network environment of a network operator or a third-party.

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

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

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

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

For the UE 310 to access the core network of the home carrier network to which it subscribes, it may first communicate with an available RAN 320 and an 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., it may be associated with another carrier network to which the UE 310 does not subscribe, and may be referred as a serving network, and the term “serving network” may be used to broadly refer to access network with AMF/SEAF that belong to another carrier network or belong 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 with the SMF 340 and the PCF 322 of the home carrier network for establishing communication sessions upon successful authentication.

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

Authentication Process, Linkability and Denial-of-Service (DoS) Attacks

A registration and authentication procedure may involve the UE 310 communicating with its home UDM/ARPF 370 via, a serving RAN 320, a serving AMF/SEAF 330, a home AUSF 360 and a home UDM/ARPF, as described in more detail below. During the registration and authentication procedure, the UE 310 verified whether it is communicating to a legitimate network and the network likewise verifies whether the UE 310 is authorized to access the network. Upon successfully authentication between the UE 310 and core network 300, a temporary access identity may be allocated to the UE 310 for further communication with the core network. Such temporary access identifier may be modified/replaced frequently to reduce compromises of user identities, locations, and communication contents to attackers. The authentication may be initiated by the UE 310 sending a registration request containing its concealed or encrypted unique permanent identity such as a Subscriber Concealed Identity (SUCI) to the serving AMF/SEAF 330. And upon successful registration, a temporary identity such as a Global Unique Temporary Identity (GUTI) or the like may be allocated by the AMF/SEAF 330 to the UE 310 for further access of the network.

The identity, location, or communication content of the user may be compromised as a result of external attacks via the radio interface. Examples of attacks include but are not limited to linkability attacks and Denial-of-Service (DoS) attacks. For example, a SUCI intercepted by an attacked via the radio interface may be used in a linkability attack, in which it is possible for an attacker to determine whether a UE observed at some location/time X is the same UE observed at some other location/time Y, thereby tracking the UE. For example, the attacker may record a SUCI that has been used by a UE A over the radio interface. In the case that UE A uses a GUTI rather than a SUCI for authentication, the attacker may also execute an active attack to obtain a SUCI by, for example, corrupting the GUTI when it is sent by UE A, which leads with a significant probability to a SUCI request by the AMF/SEAF 330 and a SUCI transmission from the UE in response. When at a later time some UE B makes a registration request to a false base station operated as a relay station by the same attacker, the attacker may modify UE B's registration request by exchanging its SUCI or GUTI with the previously captured SUCI of UE A and forward the modified request to the network. The attacker then monitor the responses between the network and UE B to determine whether UE B is the same as UE A and thus possibly tracing this UE. For example, subsequently, the attacker observes whether a successful Authentication and Key Agreement (AKA) run is performed and the registration request is accepted by the network via monitoring the radio interface, and if so, UE A and UE B would be determined by the attacker as the same UE.

This linkability attack cannot by mitigated by hiding only the content of the AKA response because the attacker can detect from the various subsequent messages intercepted in the radio interface whether the AKA run was successful or not without knowing the content of the AKA response. In the situation where the content of the AKA response is not hidden, such content could be used directly by the attacker to determine whether the UE under attack is present near the false base station.

Thus, by replaying SUCI, an attacker observes whether a successful AKA run is performed with a replayed SUCI, 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 (the SUCI of which is replayed) . When performed at several locations by the attacker, even though the attacked UE may still be anonymous, the anonymous UE may be tracked at different locations, with its privacy and untraceability compromised.

For another example, the network may be subject to DoS attacks by replay of SUCI by an attacker. Specifically, the attacker may replay SUCI to overwhelm the network and/or the UE in performing frequent and repetitive procedures such as SUCI deconcealment procedure and authentication procedure. This could particularly occur when the deconcealment scheme (e.g., an Elliptical Curve Integrated Encryption Scheme (ECIES) ) does not have any mechanisms to detect or adjust for whether a received SUCI was a previous one sent by the UE to the network or not.

As such, if an attacker launches a SUCI replay attack multiple times, the UDM and the UE may be forced to spend a lot of resources to process the replayed SUCI and the authentication request message respectively because these messages would appear legitimate. This raises DoS attacks on the UDM and the UE. A DoS attack on the UE may result in a decrease in the processing capability of the UE and a rapid depletion of the battery. A DoS attack on the UDM may cause the processing power of the UDM to decrease and the response to legitimate registration requests and other types of requests to be delayed.

Concealed Authentication Sequence Numbers

In some implementations to counter the linkability and DoS attacks above, the UE 310 and the carrier network may maintain a pair of sequence numbers (alternatively referred to as authentication sequence number) to track the authentication and re-authentication of the UE. These sequence number may be referred to as SQN _MS (at the UE side) and SQN _HE at the carrier network side. The SQN _HE, for example, may be maintained by the UDM/ARPF 370 in the home environment (HE) . These sequence numbers are only allowed to increase as the UE is authenticated and re-authenticated. The UE 310 and carrier network may maintain a synchronization between SQN _MS and SQN _HE under normal network access conditions. A detection of a de-synchronization by the UE 310 or the network during an authentication or re-authentication process, for example, may be used to indicate potential attacks and other issues.

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

Specifically, the SQN _MS may be protected by being transmitted to the AMF/SEAF 330 via the radio interface after an encryption based on, for example, the Elliptical Curve Integrated Encryption Scheme (ECIES) . In other words, a usage of ECIES for concealment of SUPI during the authentication process may be expanded to accommodate both SQN _MS and SUPI. In some implementations, the SUPI may be combined with SQN _MS and taken as one plain text block for symmetric encryption under ECIES. The combination of SQN _MS and the SUPI may be in the form of concatenation, interleaving, or the like. For example, in case an International Mobile Subscriber Identity (IMSI) is used in place of SUPI for authentication, a Mobile Subscription Identification Number (MSIN) (e.g., 9 to 10 digits) and SQN _MS may be combined and encrypted/conceal by the UE. Correspondingly in the home network, symmetric decryption based on ECIES may be used to de-conceal the SUPI (or MSIN) and the SQN _MS.

Concealed Registration Time Stamp

In some other implementations to counter the SUCI replay attacks above, the UE 310 may communicate a timestamp together with the SUCI in a registration or authentication request message to the network. Such a timestamp may be relied on by the network to detect SUCI replay attacks. Similar to the authentication sequence numbers described above, the timestamp may be combined with the SUPI followed by performing ECIES encryption on the combination. The combination of the SUPI and the timestamp may be based on concatenation, interleaving of other forms.

The concealment of the time stamp of the registration/authentication request may be performed alternative or in additional to the concealment of the authentication sequence numbers above. For example, the SUPI, the sequence number and/or the timestamp may be combined (e.g., concatenated or interleaved) followed by encryption using the ECIES scheme.

SUCI Data Structure

The concealed concatenation of SUPI (or MSIN) and the SQN _MS and/or the timestamp may be transmitted as part of a SUCI data structure to the AMF/SEAF 330 of the serving network. An example of a SUCI data structure 400 is shown in FIG. 4. The SUCI structure 400 contains a SUPI type field 402 with a value ranging from, for example, 0 to 7 for identifying the type of identifier concealed in the “Scheme Output” field 412 as well as other fields of the SUCI structure 400. As an example, the various values may be used in the 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 (e.g., concatenate) with SQN _MS and/or message timestamp

- 5 to 7: reserved values for other indicators.

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

Authentication Based on Concealed SUPI and Authentication Sequence Numbers

FIG. 5 illustrates an example data and logic flow 500 for a primary network registration/authentication between the UE 310 and the home core network AUSF 360 and UDM/ARPF 370 via the serving network AMF/SEAF 330 using concealed SUCI containing SQN _MS, assuming a successful authentication between the UE 310 and the network. The logic and data flow 500 may include the following exemplary steps with corresponding step numbers in FIG. 5.

1. During the primary authentication procedure 500, USIM and the ME combines SUPI of the UE 310 and a current SQN _MS maintained by the USIM or ME, via, for example, concatenation or interleaving. The combined (e.g., concatenated or interleaved) plain text block of the SUPI and the SQN _MS may be encrypted using ECIES method in the USIM or the ME. A SUCI data structure following FIG. 4 may be constructed to include the encrypted combination of the 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 concealed combination of the SUPI and SQN _MS. For example, value “4” may be set in the “SUPI Type” filed of the SUCI structure.

2. UE may use the SUCI data structure containing the concealed SQN _MS in a Registration Request Message, which is sent from the UE 310 to the serving AMF/SEAF 330.

3. Upon receiving the Registration Request Message from the UE 310, the serving AMF/SEAF 330 may invoke an AUSF service (denoted as Nausf_UEAuthentication service) by sending a AUSF service request message (denoted as Nausf_UEAuthentication_Authenticate Request message) to the home AUSF 360 whenever the serving AMF/SEAF 330 wishes to initiate an authentication. The Nausf_UEAuthentication_Authenticate Request message, for example, may contain the SUCI embedded with the concealed SUPI and the SQN _MS, and a serving network name.

4. Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the home AUSF 360 may check that the requesting AMF/SEAF 330 in the serving network is entitled 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 store the received serving network name temporarily. If the serving network is not authorized to use the received serving network name, the AUSF 360 may respond to the UE 310 indicating that the serving network is not authorized in a response message denoted as Nausf_UEAuthentication_Authenticate Response. 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 include the following information:

- The SUCI containing the concealed SUPI and SQN _MS; and

- The serving network name.

5. Upon reception of the Nudm_UEAuthentication_Get Request, the home UDM/ARPF 370 may invoke a Subscription Identifier De-concealment Function (SIDF) if it determines from the SUPI type field of the received SUCI data structure that the SUPI type is SUPI combined with SQN _MS. The SIDF may thus de-conceal the received SUCI to gain SUPI and SQN _MS before the UDM 370 can process the request. Based on the SUPI, the UDM/ARPF 370 may perform its authentication procedure. The de-concealed SQN _MS may be stored in UDM 370 for future use (as described in more detail below with respect to FIG. 6) . The UDM 370 may further generates a fresh SQN _HE, which is greater than a current SQN _HE maintained by the UDM. The current SQN _HE is then replaced by the refreshed SQN _HE. An Authentication vector is also generated based on the refreshed SQN _HE and other information (the component of the authentication vector is in step 6 below) .

6. For each Nudm_Authenticate_Get Request, the UDM/ARPF 370 may create a home environment authentication vector (HE AV) . In more detail, the UDM/ARPF 370 does this by generating an authentication vector (AV) with an Authentication Management Field (AMF) separation bit set to "1" . The UDM/ARPF 370 may then derive an AUSF key K _AUSF and calculate an eXpected RESponse denoted by XRES*. Finally, the UDM/ARPF 370 may create the HE AV from a random number denoted by RAND, an authentication key denoted by AUTN, the XRES*, and the K _AUSF. The AUTN, for example contain information of the SQN _HE. The UDM/ARPF 370 may then return the HE AV to the AUSF 360 together with an indication that the HE AV is to be used for AKA in a response to the AUSF 360 denoted by Nudm_UEAuthentication_Get Response. The UDM/ARPF 370 may include the de-concealed SUPI in the Nudm_UEAuthentication_Get Response.

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

8. The AUSF 360 may then generate an AV from the HE AV received from the UDM/ARPF 370 by computing a hashed XRES denoted by HXRES*from XRES*and a SEAF key denoted by K _SEAF from K _AUSF, and replacing the XRES*with the HXRES*and K _AUSF with K _SEAF in the HE AV to generate the AV.

9. The AUSF 360 may then remove the K _SEAF and return an serving environment authentication vector denoted as SE AV (including the RAND, the AUTN, and the HXRES*) to the SEAF 330 in a response message denoted as Nausf_UEAuthentication_Authenticate Response

10. The SEAF 330 may send RAND, AUTN as included into an AV to the UE in a non-access stratum (NAS) message Authentication Request. This message may also include an ngKSI that will be used by the UE and AMF to identify a K _AMF and the partial native security context that is created if the authentication is successful. The ME may forward the RAND and AUTN received in NAS message Authentication Request to the USIM.

11. At receipt of the RAND and the AUTN, the UE (e.g., USIM or the ME) may verify the freshness of the AV by checking whether the AUTN can be accepted. For example, the UE may extract the SQN _HE contained in the AUTN and compared with the local SQN _MS. If SQN _HE is not smaller than SQN _MS, the UE may determine a sequence number synchronization success. Otherwise, the UE determines sequence number synchronization failure. When the UE determines that the sequence numbers SQN _MS and SQN _HE are synchronized, the UE performs the rest of the steps in FIG. 5 as described below. If sequence number synchronization is confirmed, the USIM may compute a response denoted by RES. The USIM may return the RES, a CK, an IK to the ME. If the USIM computes a Kc (i.e. GPRS Kc) from CK and IK using a conversion function c3, and sends it to the ME, then the ME may ignore such GPRS Kc and not store the GPRS Kc on USIM or in ME. The ME then may compute RES*from RES. The ME may calculate K _AUSF from CK||IK. The ME may calculate K _SEAF from K _AUSF. The ME accessing the network may check during authentication that 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. Upon determination of sequence number synchronization between the SQN _MS and the SQN _HE, the UE updates (or replaces) its SQN _MS with the extracted SQN _HE for future synchronization purposes.

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

13. The SEAF 330 may then compute HRES*from RES*, and the SEAF 330 may compare HRES*and HXRES*. If they coincide, the SEAF 330 may consider the authentication of the UE 310 successful from the serving network point of view. When authentication is successful, the rest steps of FIG. 5 below are followed. If not, the SEAF 330 may inform the network of the authentication failure by, for example, sending a response message with a failure code, and/or discard/stop/quit the authentication. If the UE is not reached (e.g., no response is obtained from the UE) , and the RES*is never received by the SEAF 330, the SEAF may consider authentication as failed, and indicate a failure to the AUSF 360.

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

15. When the AUSF 360 receives as authentication confirmation the Nausf_UEAuthentication_Authenticate Request message including the RES*it may verify whether the AV has expired. If the AV has expired, the AUSF 360 may consider the authentication of the UE 310 as unsuccessful from the home network point of view. Upon successful authentication, the AUSF 360 may store the K _AUSF. The AUSF 360 may compare the received RES*with the stored XRES*. If the RES*and XRES*are equal, the AUSF 360 may consider the authentication of the UE 310 as successful from the home network point of view, and the rest of the steps of FIG. 5 below are followed. The AUSF 360 may inform the UDM 370 about the authentication result. Upon failure (RES*and XRES*are not equal) , the AUSF 360 may inform the network of the authentication failure by, for example, sending a response message with a failure code, and/or discard/stop/quit the authentication.

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 or not from the home network point of view. If the authentication was successful, the K _SEAF may be sent to the SEAF 330 in the Nausf_UEAuthentication_Authenticate Response. If the authentication was successful, then the AUSF 360 may also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message.

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

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

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

20. Upon reception of subsequent UE related procedures (e.g. Nudm_UECM_Registration_Request from the AMF 330) the UDM 370 may apply actions according to home operator’s policy to detect and achieve protection against certain types of fraud.

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

The verification steps 13 and 15 may fail, indicating that the UE cannot be authenticated. In those cases, failure messages may be sent to the UDM 370 in a cascading manner. The UDM 370 may still store the authentication status and update the stored SQN _MS with the current SQN _HE, similar to the step 18 above.

Sequence Number Synchronization Failure Treatment

In step 11 as shown in FIG. 5 and described above, the UE 310 may determine that the sequence number synchronization fails when the SQN _HE extracted from the AUTN received from the AMF 310 is smaller than the local SQN _MS. FIG. 6 shows an example logic and data flow 600 for a 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 (such as AUTS) embedded with SQN _MS for transmission to the AMF 330 to avoid another exposure of the SQN _MS in the radio interface. Instead, the UE 310 only sends a response message to the AMF 330 indicating a cause for the failure as sequence number de-synchronization. Such de-synchronization may occur, for example, when the UE 310 and the network is under SUCI replay attack. As an example of RA1, the UE 310 may respond with an NAS message Authentication Failure only with a cause value indicating the reason for failure as an SQN failure/mismatch without calculating and sharing the AUTS with the network.

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

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

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 HE/AuC. The UDM/ARPF 370 may send a response message denoted by Nudm_UEAuthentication_Get Response message for UE re-authentication with a new authentication vector by using the SQN _MS stored (e.g., in steps 5 or 18 of FIG. 5) in the UDM 370 rather than a refreshed SQN _HE. The AUSF 360 runs a new authentication procedure with the UE 310 following the principle of steps 6-11 of FIG. 5.

GUTI Authentication with SUPI Failure

FIG. 7 shows a logic and data flow 700 for a registration/authentication procedure initiated by the UE 310 using a network-allocated temporary identifier such as a GUTI obtained via a previous registration and authentication process (such as from the step 21 in the SUCI registration procedure illustrated in FIG. 5) . Step 0-2 of FIG. 7 are described below.

0. The UE 310 may initiate a registration procedure using a temporary identity such as a GUTI.

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

2. The serving AMF/SEAF 330 may attempt to obtain SUPI for the UE from an old AMF/SEAF 702 as identified, for example, in the registration message, and if the serving AMF/SEAF 330 fails to get UE context from old the AMF/SEAF 702 (step 2a of FIG. 7) , the serving AMF/SEAF 330 may send an identity request message to the UE 310 with identity type (step 2b of FIG. 7) . The UE 310, upon receiving the identity request message, may send an identity response message to the AMF/SEAF 330 with a SUCI embedded with the current SQN _MS (step 2c of FIG. 7) .

The remaining steps 3-21 in the logic and data flow 700 essentially preform an authentication procedure using SUCI and mirror the steps 3-21 in the logic and data flow 500 of FIG. 5. These steps are illustrated in FIG. 7 and explained above in relation to FIG. 5, and are not duplicatively described here.

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

Further, the verification steps 13 and 15 may fail, indicating that the UE 310 cannot be authenticated by the network. In those cases, and as described above for FIG. 5, failure messages may be sent to the UDM 370 in a cascading manner. The UDM may still store the authentication status and update the stored SQN _MS with the current SQN _HE, similar to the step 18 in FIG. 7 and described above for step 18 of FIG. 5.

GUTI Authentication with Successful SUPI Retrieval

FIG. 8 shows a logic and data flow 800 for a registration/authentication procedure initiated by the UE 310 using a network-allocated temporary identifier such as a GUTI obtained via a previous registration and authentication process (such as from the step 21 in the SUCI registration procedure illustrated in FIG. 5 or FIG. 7) , where the SUPI of the UE is successfully identified by the serving network. 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 are described in more detail below.

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

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

1b. The UE 310 may use GUTI in a registration request message rather than a SUCI, which is sent to the AMF/SEAF 330.

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

3. The serving AMF/SEAF 330 may invoke an AUSF authentication service by sending a Nausf_UEAuthentication_Authenticate Request message to the AUSF 360 whenever the serving AMF/SEAF 330 wishes to initiate an authentication. The Nausf_UEAuthentication_Authenticate Request message may contain the SUPI and the serving network name.

4. Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the home AUSF 360 may check that the requesting AMF/SEAF 330 in the serving network is entitled 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 store the received serving network name temporarily. 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 not authorized in a response message denoted by Nausf_UEAuthentication_Authenticate Response. The AUSF 360 may then send a request message denoted as Nudm_UEAuthentication_Get Request to the home UDM/ARPF 370. The Nudm_UEAuthentication_Get Request may include SUPI of the UE and the serving network name.

5. Upon reception of the Nudm_UEAuthentication_Get Request from the home AUSF 360, the home UDM/ARPF 370 may choose an authentication method base on SUPI. At the home UDM 370, a home environment AV vector is generated with using a refreshed SQN _HE that is larger than a previous sequence number used for the UE 310.

The difference between the above 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 SUPI rather than SUCI is passed from the serving network to the home network during the authentication process. As such, the SQN _MS of the UE would not be transmitted to the home UDM/ARPF 370, and the SQN _MS previously stored at the home UDM as indicated in step 0 of FIG. 8 would not be updated with the current SQN _MS.

The remaining steps 6-21 in the logic and data flow 800 of FIG. 8 essentially preform an authentication procedure that mirrors the steps 6-21 in the logic and data flow 500 of FIG. 5. These steps are summarized in FIG. 8 and explained above in relation to FIG. 5, and are not duplicatively described here.

In addition, if the SQN synchronization check fails at the UE in step 11 of FIG. 8, a re-authentication procedure may be performed following the logic and data flow 600 of FIG. 6, 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 previously stored SQN _MS. The SQN _MS maintained at the UDM 370 would not become out of synchronization due to a lack of update in the GUTI authentication steps 1-5 in the logic and data flow 800 because any successful authentication (in either logic and data flows 800 of FIG. 8, 500 of FIG. 7, and 700 of FIG. 7 would bring the SQN _MS maintained at the UDM 370 up to date (or synchronized) as a result of replacing the stored SQN _MS with the current SQN _HE at step 18 of these logic and data flows.

Further, the verification 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, and as described above for FIG. 5, failure messages may be sent to the UDM 370 in a cascading manner. The UDM 370 may still store the authentication status and update the stored SQN _MS with the current SQN _HE, similar to the step 18 in FIG. 8 and described above for step 18 of FIG. 5.

Countering SUCI Replay Attacks from the Network Side Using SQN

In some implementations, the SUCI replay attacks may be detected on the network side based on the UE side sequence number SQN _MS and the HE side sequence number SQNHE. The SQN _MS becomes available to the network side as a result of the transmission of SUCI embedded with both concealed permanent UE identity and the concealed SQN _MS in steps 1-5 as shown in FIGs. 5 and 7.

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

Specifically in step 5 of the logic and data flow 900, upon reception of the Nudm_UEAuthentication_Get Request sent from the home AUSF 360, the home UDM 370 may invoke SIDF if a SUPI type is SUPI combined with SQN _MS, then the SIDF procedure may de-conceal the received SUCI to gain SUPI and SQN _MS associated with the UE 310 before the home UDM 370 can process 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 example determinations:

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

- If the home UDM 370 has a previous stored SQN _MS for the UE 310, it may be configured to compare the received SQN _MS and 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 respond with a failure code or discard the message to stop the authentication procedure.

○ However, if the comparison shows that the received SQN _MS is greater than the stored SQN _MS, the home UDM 370 may instead be configured to select the authentication method based on SUPI, generate an AV based a refreshed and increased SQN _HE, and proceed with the rest of authentication procedure in of FIG. 9.

○ If the SQN _HE is less than or equal to the stored SQN _MS, the home UDM 370 discards the AV and SQN _HE, and generate a new AV with refreshed SQN _HE.

The remaining steps other than step 5 in the logic and data flow 900 of FIG. 9 essentially preform an authentication procedure that mirror the corresponding steps in the logic and data flow 500 of FIG. 5. These steps are summarized in FIG. 9 and explained above in relation to FIG. 5, and are not duplicatively described here.

Similarly, FIG. 10 illustrates a logic and data flow 1000 for a registration/authentication procedure initiated by the UE 310 using a network-allocated temporary identifier such as a GUTI obtained via a previous registration and authentication process (such as from the step 21 in the SUCI registration procedure illustrated in FIG. 9) . The various steps of the FIG. 10 are similar to those of FIG. 7 except that step 5 includes a procedure for detection of SUCI replay attacks. The step 5 in the logic and data flow 1000 of FIG. 10 is similar to the step 5 in the logic and data flow 900 illustrated in FIG. 9 and described in detail above. As such, the steps summarized in FIG. 10 is not duplicatively described here.

Further, FIG. 11 illustrates registration/authentication procedure initiated by the UE 310 using a network-allocated temporary identifier such as a GUTI obtained via a previous registration and authentication process (such as from the step 21 in the SUCI registration procedure illustrated in FIG. 9 or FIG. 11) , where the SUPI of the UE is successfully identified by the serving network. The various steps of the FIG. 11 are similar to those of FIG. 8 except that in step 5 the UDM 370 may choose the authentication method base on SUPI and generate AV based on SQN _HE, and if the SQN _HE is less than or equal to SQN _MS, the UDM 370 nay discard the AV and SQN _HE, and generate a new AV and SQN _HE.

In addition, if the SQN synchronization check fails at the UE in step 11 of FIGs. 9, 10, and 11, a re-authentication procedure may be performed following the logic and data flow 600 of FIG. 6, 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 previously stored SQN _MS.

Countering SUCI Replay Attacks from the Network Side Using the Registration Request Message Timestamp

In some implementations, the SUCI replay attacks may be detected on the network side based on the UE registration request timestamp. The registration timestamp becomes available to the network side as a result of the transmission of SUCI embedded with both the concealed UE identity and the concealed time stamp as described above.

FIG. 12 shows an example logic and data flow 1200 for a registration/authentication procedure initiated by the UE 310 using a SUCI with concealed network identity (e.g., SUPI) and concealed registration request timestamp. The logic and data flow 1200 is similar to the logic and data flow 900 of FIG. 9 except that the information concealed in the SUCI includes the UE identity and the registration request timestamp rather than the UE identity and the SQN _MS, and that in step 5, the SUCI replay attack detection procedure is performed by the home UDM 370 based on the registration request timestamp rather than authentication sequence number (s) .

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

1. During the primary authentication procedure, the UE 310 (e.g., the USIM) combines the SUPI and a registration request or message time stamp denoted as MESSAGE_TIME by concatenation, interleaving, or other combination manners. The MESSAGE_TIME, for example, may represents the UTC-based time when the message (e.g., registration or authentication message) is sent. A SUCI data structure following FIG. 4 may be constructed to include the encrypted combination of the 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 concealed combination of the SUPI and MESSAGE_TIME. For example, value “4” may be set in the “SUPI Type” filed of the SUCI structure.

2. UE may use SUCI containing the concealed MESSAGE_TIME in a Registration request message, which is sent from the UE 310 to the serving AMF/SEAF 330.

3. Upon receiving the Registration Request Message from the UE 310, the serving AMF/SEAF 330 may invoke an AUSF service (denoted as Nausf_UEAuthentication service) by sending a AUSF service request message (denoted as Nausf_UEAuthentication_Authenticate Request message to the AUSF 360 whenever the AMF/SEAF 330 wishes to initiate an authentication. The Nausf_UEAuthentication_Authenticate Request message, for example, may contain the SUCI embedded with the concealed SUPI and the MESSAGE_TIME, and a serving network name.

4. Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the home AUSF 360 may check that the requesting AMF/SEAF 330 in the serving network is entitled 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 store the received serving network name temporarily. If the serving network is not authorized to use the received serving network name, the AUSF 360 may respond to the UE 310 indicating that the serving network is not authorized in a response message denoted as Nausf_UEAuthentication_Authenticate Response. 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:

- The SUCI containing concealed SUPI and the MESSAGE_TIME; and

- The serving network name.

5. Upon reception of the Nudm_UEAuthentication_Get Request from the home AUSF 360, the home UDM 370 may invoke SIDF if a SUPI type is SUPI combined with MESSAGE_TIME, then the SIDF procedure may de-conceal the received SUCI to gain SUPI and MESSAGE_TIME before the home UDM 370 can process the request. For the SUCI replay attack detection from the network side in step 5, the home UDM 370 may compare the received MESSAGE_TIME and the current UTC-based time and make the following example determinations:

- 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 370may respond with a failure code or discard and stop processing the message. MAX_DELAY represents, for example, a maximum transmission time threshold. The MAX_DELAY may be pre-determined, for example, according to an estimated data transmission speed between the UE 310 and the UDM 370. The MAX_DELAY may further be 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 selects the authentication method based on SUPI, generates AV, and proceed with the rest of the authentication steps of FIG. 12.

The remaining steps other than steps 1-5 in the logic and data flow 1200 of FIG. 12 essentially preform an authentication procedure that mirror the corresponding steps in the logic and data flow 500 of FIG. 5 except that in step 11 the SQN _MS update on the UE side may not need to be involved and that in step 18 the update of SQN _MS on the network side may not need to not be involved. These steps are summarized in FIG. 12 and explained above in relation to FIG. 5, and are not duplicatively described here.

Similarly, FIG. 13 illustrates a logic and data flow 1300 for a registration/authentication procedure initiated by the UE 310 using a network-allocated temporary identifier such as a GUTI obtained via a previous registration and authentication process (such as from the step 21 in the SUCI registration procedure illustrated in FIG. 12) . The various steps of the FIG. 13 are similar to those of FIG. 7 except that steps 1-5 use concealed timestamp rather than SQN _MS (as described in steps 1-5 of FIG. 12) , that step 5 includes a procedure for a detection of SUCI replay attacks similar to the step 5 in the logic and data flow 1200 illustrated in FIG. 12 and described in detail above, that in step 11 the SQN _MS update on the UE side may not need to be involved, and that in step 18 the update of SQN _MS on the network side may not need to not be involved. As such, the steps summarized in FIG. 13 is not duplicatively described here.

Combination of Concealed SQNMS and Concealed Registration Request Message Timestamp

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

The accompanying drawings and description above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly 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. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such 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, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are 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 solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

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

Claims

A method performed by a first network element of a communication network for an authentication procedure of a second network element for accessing the communication network, the method comprising:

receiving an authentication message initiated from the second network element;

de-concealing the authentication message to obtain a de-concealed sequence number maintained by the first network element, and a de-concealed subscription identifier of the second network element;

processing the authentication procedure depending on a determination outcome of whether a previous sequence number for the second network element was stored in the first network element during a previous authentication procedure of the second network element; and

upon determining that the previous sequence number was stored in the first network elements, further processing the authentication procedure depending on a comparison result between the de-concealed sequence number and the previous sequence number.
The method of claim 1, wherein processing the authentication procedure depending on a determination outcome comprises, when the first network element determines that no previous sequence number for the second network element was stored in the first network element during any previous authentication procedure of the second network element:

storing the de-concealed sequence number in the first network element;

generating a new sequence number; and

generating an authentication vector based on the new sequence number.
The method of claim 2, further comprising transmitting the authentication vector towards the first network element.
The method of claim 2, further comprising:

comparing the new sequence number to the de-concealed sequence number; and

when the new sequence number is smaller than or equal to the de-concealed sequence number, discarding the authentication vector and regenerating another sequence number and another authentication vector.
The method of claim 1, wherein processing the authentication procedure depending on a determination outcome comprises, when the first network element determines that a previous sequence number for the second network element was stored in the first network element during a previous authentication procedure of the second network element, performing a comparison between the previous sequence number and the de-concealed sequence number to obtain the comparison result.
The method of claim 5, wherein processing the authentication procedure depending on a comparison result between the de-concealed sequence number and the previous sequence number comprises: when the comparison result indicates that the de-concealed sequence number is less than or equal to the previous sequence number, discarding the authentication message.
The method of claim 5, wherein processing the authentication procedure depending on a comparison result between the de-concealed sequence number and the previous sequence number comprises: when the comparison result indicates that the de-concealed sequence number is less than or equal to the previous sequence number, generating a response message containing a failure code.
The method of claim 5, wherein processing the authentication procedure depending on a comparison result between the de-concealed sequence number and the previous sequence number comprises, when the comparison result indicates that the de-concealed sequence number is larger than the previous sequence number:

generating a new sequence number; and

generating an authentication vector based on the new sequence number.
The method of claim 8, further comprising:

comparing the new sequence number to the de-concealed sequence number; and

when the new sequence number is smaller than or equal to the de-concealed sequence number, discarding the authentication vector and regenerating another sequence number and another authentication vector.
The method of claim 5, wherein de-concealing the authentication message to obtain the de-concealed sequence number and the de-concealed subscription identifier comprises:

retrieving a concealed identity of the second network element form the authentication message;

extracting from the authentication message a type indicator for indicating a type of the concealed identity;

determining that the type indicator indicates that the concealed identity comprises a composite data item including a concealed subscription identifier and a concealed sequence number;

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

obtaining the de-concealed subscription identifier and the de-concealed sequence number from the decrypted composite data item.
The method of claim 10, wherein the decrypted composite data item comprises the de-concealed subscription identifier concatenated with the de-concealed sequence number.
The method of claim 10, the type indicator, when indicating that the concealed identity is a composite data item, comprises a unique value for indicating that the concealed identity comprises a concealed combination of a subscription identifier and a sequence number.
The method of claim 10, wherein the decrypted composite data item comprises the de-concealed subscription identifier interleaved with the de-concealed sequence number
The method of claim 10, wherein the composite data item is decrypted to obtain the de-concealed subscription identifier and the de-concealed sequence number using an Elliptic Curve Integrated Encryption Scheme (ECIES) scheme.
The method of claim 10, wherein the concealed identity is encapsulated in a Subscription Concealed Identifier (SUCI) .
The method of claim 10, wherein the de-concealed subscription identifier comprises a Subscription Permanent Identifier (SUPI) .
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 Processing Function (ARPF) of the communication network.
The method of claim 1, wherein the authentication message comprises one of:

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

an identity response message by the first network element in response to an identity request from the communication network.
The first network element of any one of claims 1-18, comprising a processor configured to implement a method in any one of claims 1-18.
A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by a processor, causing the processor to implement a method of any one of claims 1-18.