CN116235462A

CN116235462A - Method for protecting encrypted user identity from replay attacks

Info

Publication number: CN116235462A
Application number: CN202080105425.2A
Authority: CN
Inventors: 邢真; 游世林; 刘宇泽; 彭锦; 高峰; 林兆骥; 张博山
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2020-09-30
Filing date: 2020-09-30
Publication date: 2023-06-06
Also published as: TW202142011A; WO2022067667A1

Abstract

The present disclosure relates generally to registration and authentication procedures between a wireless terminal and a core network, and in particular to detection of a registration replay attack from the core network side to reduce leakage of confidential user information based on a registration message timestamp communicated from the wireless terminal to the core network. The timestamp transmitted by the registration request is effectively hidden from exposure in the radio interface by being hidden together with the permanent subscription identifier of the wireless terminal. The core network detects that the timestamp in the registration and/or authentication information lags the current universal time (e.g., coordinated universal time, UTC time) by an amount greater than a maximum allowable delay threshold, which is used as an indication that a registration replay attack is present. Upon such detection, the core network may stop communicating the request and response information, which may result in leakage of confidential information of the wireless terminal and, in some cases, denial of service for the terminal device or network.

Description

Method for protecting encrypted user identity from replay attacks

Technical Field

The present disclosure relates to registration and authentication procedures between a mobile terminal and a core network. In particular, the present disclosure relates to protecting encrypted user information from replay attacks (replay attacks).

Background

The wireless terminal device may communicate with its home core network via a serving network. The wireless terminal may initiate a registration and authentication procedure before gaining access to the home core network. The wireless terminal, the serving network, and the home core network interact with each other to authenticate the wireless terminal to the network and to authenticate the network to the wireless terminal. The access credentials are generated upon successful registration and authentication to enable further communication between the wireless terminal and the network. Communication messages between a UE and a network via a wireless interface, whether encrypted or unencrypted, may be subject to hacking. A hacker may obtain confidential information about the wireless terminal via such an attack.

Disclosure of Invention

The present disclosure relates generally to registration and authentication procedures between a wireless terminal and a core network, and in particular to detection of a registration replay attack from the core network side to reduce leakage of confidential user information based on a registration message timestamp communicated from the wireless terminal to the core network. The timestamp transmitted with the registration request is hidden by being together with the permanent subscription identifier of the wireless terminal, thereby effectively avoiding exposure in the radio interface. The core network detects that the timestamp in the registration and/or authentication information lags the current universal time (e.g., coordinated universal time (Universal Time Coordinated), UTC time) by an amount greater than a maximum allowable delay threshold, which is used as an indication that a registration replay attack is present. Upon such detection, the core network may stop communicating the request and response information, which may result in leakage of confidential information of the wireless terminal and, in some cases, denial of service (denial-of-service) for the terminal device or network.

In some implementations, a method for generating a subscription data item is disclosed, the method performed by a first network element in a network. The method comprises the following steps: acquiring a time stamp indicating the current time; obtaining a subscription identifier identifying a first network element; combining the timestamp with the subscription identifier to obtain a composite data item; encrypting the composite data item to obtain an encrypted composite data item; and generating a subscription data item comprising the encrypted composite data item as a hidden identity of the first network element and a type indicator for indicating a type of the hidden identity.

In some other embodiments, a method for processing an authentication message initiated from a first network element in a network is disclosed, the method being performed by a second network element in the network. The authentication message includes a subscription data item having a hidden identity of the first network element and a type indicator indicating a type of the hidden identity, and the method includes: parsing the authentication message to obtain a hidden identity and a type indicator; decrypting the hidden identity to obtain an unhidden data item; and upon determining from the type indicator that the hidden identity is a composite data item, parsing the unhidden data item to obtain a first timestamp indicating when the authentication message originated from the first network element, and a subscription identifier of the first network element.

In some other embodiments, a network element is disclosed. The network device generally includes 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 any of the methods described above.

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

The above-described embodiments and other aspects and embodiments thereof are described in more detail in the following figures, description and claims.

Drawings

Fig. 1 shows an exemplary communication network including a terminal device, a carrier network, a data network, and a service application.

Fig. 2 shows an exemplary network function or network node in a communication network.

Fig. 3 illustrates an exemplary network function or network node in a wireless communication network.

Fig. 4 shows an example data structure of a subscriber hidden identity for network registration and authentication of a wireless terminal.

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

Fig. 6 shows an example data and logic flow for re-authentication when a wireless terminal (user equipment (UE)) detects an authentication sequence number desynchronization.

Fig. 7 shows example data and logic flow for registration/authentication between a wireless terminal (user equipment (UE)) and a core network based on a temporary identity and authentication sequence number assigned by an unverified network of the wireless terminal.

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 network assigned temporary identity and authentication sequence number for successful authentication of the wireless terminal.

Fig. 9 shows example data and logic flows for primary network registration/authentication between a wireless terminal (user equipment (UE)) and a core network based on detection of a subscriber hidden identity and hidden authentication sequence number of the wireless terminal and authentication sequence number desynchronization from the network side.

Fig. 10 shows example data and logic flows for registration/authentication between a wireless terminal (user equipment (UE)) and a core network based on detection of a temporary identity and authentication sequence number assigned by an unverified network of the wireless terminal and an authentication sequence number desynchronization from the network side.

Fig. 11 shows example data and logic flows for registration/authentication between a wireless terminal (user equipment (UE)) and a core network based on detection of a network-assigned temporary identity and authentication sequence number for successful authentication of the wireless terminal and authentication sequence number desynchronization from the network side.

Fig. 12 shows example data and logic flows for primary network registration/authentication between a wireless terminal (user equipment (UE)) and a core network based on a hidden identity of a user and a hidden timestamp of a corresponding registration message and detection of a registration replay attack from the network side via the registration message timestamp.

Fig. 13 shows example data and logic flows for registration/authentication between a wireless terminal (user equipment (UE)) and a core network based on a temporary identity assigned by an unverified network of the wireless terminal and a hidden timestamp of a corresponding registration message and detection of a registration replay attack from the network side via the registration message timestamp.

Detailed Description

Example communication network

As shown at 100 in fig. 1, an exemplary communication network may include

terminal devices

110 and 112, a carrier network 102, various service applications 140, and other data networks 150. Carrier network 102 may include, for example, access network 120 and core network 130. Carrier network 102 may be configured to: voice, data, and other information (collectively referred to as data traffic) is communicated between

terminal devices

110 and 112, between

terminal devices

110 and 112 and service application 140, or between

terminal devices

110 and 112 and other data networks 150. After an authentication process, which is described in further detail below, a communication session and corresponding data path may be established and configured for such data.

Access network 120 may be configured to: providing

terminal devices

110 and 112 with network access to core network 130. The 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 application 140 may be hosted by various application servers that may be accessed by

terminal devices

110 and 112 through core network 130 of carrier network 102. Service application 140 may be deployed as a data network external to core network 130. Likewise, other data networks 150 may be accessed by

terminal devices

110 and 112 through core network 130 and 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 may be virtualized and implemented as virtual machines or software entities. The network nodes may each be configured with one or more types of network functions. These network nodes or network functions may together provide provisioning and routing functions for the core network 130. The terms "network node" and "network function" are used interchangeably in this disclosure.

Fig. 2 further illustrates 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 illustrated in fig. 2, one of ordinary skill in the art will appreciate that each of these network nodes or functions may be instantiated as multiple instances of network nodes distributed throughout the core network 130. As shown in fig. 2, the core network 130 may include, but is not limited to, network nodes such as an access management network node (access management network node, amann) 230, an authentication network node (authentication network node, AUNN) 260, a network data management network node (network data management network node, NDMNN) 270, a session management network node (session management network node, SMNN) 240, a data routing network node (data routing network node, DRNN) 250, a policy control network node (policy control network node, 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 the various solid line connection lines in fig. 2. Such signaling and data exchanges may be carried by signaling or data messages that follow a predetermined format or protocol.

The embodiments described above in fig. 1 and 2 are applicable to both wireless and wireline communication systems. Fig. 3 illustrates an exemplary cellular wireless communication network 300 based on a general implementation of the communication network 200 of fig. 2. Fig. 3 shows that wireless communication network 300 may include wireless terminal or User Equipment (UE) 310 (acting as terminal device 110 of fig. 2), radio access network (radio access network, RAN) 320 (acting as access network 120 of fig. 2), service application 140, data Network (DN) 150, and core network 130, core network 130 including access management function (access management function, AMF) 330 (acting as AMNN 230 of fig. 2), session management function (session management function, SMF) 340 (acting as SMNN 240 of fig. 2), application function (application function, AF) 390 (acting as adnn 210 of fig. 2), user plane function (user plane function, UPF) 350 (acting as DRNN 250 of fig. 2), policy control function 322 (acting as PCNN 220 of fig. 2), authentication server function (authentication server function, AUSF) 360 (acting as AUNN 260 of fig. 2), and universal data management/authentication credential repository and processing function (universal data management/authentication credential repository and processing function, UDM/ARPF) 370 (acting as udnn 270 of fig. 2). Again, although only a single instance of some network functions or nodes for the wireless communication network 300 (and in particular the core network 130) are shown in fig. 3, one of ordinary skill in the art will appreciate that each of these network nodes or functions may have multiple instances 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, a tablet, an Internet of Things (IoT) device, a distributed sensor network node, a wearable device, etc. The UE 310 may include a mobile station (ME) and a system subscription module (System Subscription Module, SIM). The SIM module may be implemented, for example, in the form of a universal mobile telecommunications SIM (Universal Mobile Telecommunication SIM, USIM) that includes some computing power for network registration and authentication. The calculations required to perform network registration and authentication may be performed by the USIM or by the ME in the UE. For example, RAN 320 may include a plurality of radio base stations distributed throughout a service area of a carrier network. Communication between UE 310 and RAN 320 may be carried in an over-the-air (OTA) radio interface, as shown at 311 in fig. 3.

Continuing with FIG. 3, UDM 370 may form 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), as shown in 370 of fig. 3, for storing long-term security credentials for user authentication and for using such long-term security credentials as input to perform the computation of authentication vectors and encryption keys, as described in more detail below. To prevent unauthorized exposure of the UDM/ARPF data, the UDM/ARPF 370 may be located in a secure network environment of a network operator or third party.

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

The SMF 340 may be assigned by the AMF/SEAF 330 to a particular communication session instantiated in the wireless communication network 300. The SMF 340 may be responsible for allocating the UPF 350 to support communication sessions in the user data plane and data flows therein, and for provisioning/adjusting the allocated UPF 350 (e.g., for formulating packet detection and forwarding rules for the allocated UPF 350). Instead of being assigned by the SMF 340, the UPF 350 may be assigned by the AMF/SEAF 330 to a particular communication session and data flow. The UPFs 350 allocated and equipped by the SMF 340 and the 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, between UE 310 and service application 140. DN 150 and service applications 140 can include, but are not limited to, data networks and services provided by operators of wireless communication network 300 or by third party data networks and service providers.

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

PCF 322 may be responsible for managing and providing AMF/SEAF 330 and SMF 340 with various levels of policies and rules applicable to communication sessions associated with UE 310. Thus, for example, AMF/SEAF 330 may allocate SMFs 340 for a communication session in accordance with 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 of 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 RANs 320 and AMFs/SEAFs 330 associated with the RANs 320. RAN 320 and AMF/SEAF 330 may or may not belong to a home carrier network (e.g., it 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 to refer broadly to an access network having AMF/SEAF that belongs to another carrier network or to the same home core carrier network). The serving network's AMF/SEAF 330 may communicate with the UE 310's home carrier network's AUSF 360 and UDM/ARPF 370 for authentication and then with the home carrier network's SMF 340 and PCF 322 to establish a communication session upon successful authentication.

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

Authentication procedure, linkable-of-Service (DoS) attack

The registration and authentication procedure may involve the UE 310 communicating with its home UDM/ARPF 370 via the serving RAN 320, the serving AMF/SEAF 330, the home AUSF 360, and the home UDM/ARPF, as described in more detail below. During the registration and authentication process, the UE 310 verifies whether it is communicating with a legitimate network and the network likewise verifies whether the UE 310 is authorized to access the network. Upon successful authentication between the UE 310 and the core network 300, a temporary access identity may be assigned to the UE 310 for further communication with the core network. Such temporary access identifiers may be frequently modified/replaced to reduce user identity, location and communication content tradeoffs for attackers. Authentication may be initiated by UE 310 sending a registration request to service AMF/SEAF 330 containing its hidden or encrypted unique permanent identity, such as a subscriber hidden identity (Subscriber Concealed Identity, sui). Upon successful registration, a temporary identity such as a globally unique temporary identity (Global Unique Temporary Identity, GUTI) or the like may be assigned by the AMF/SEAF 330 to the UE 310 for further access by the network.

As a result of external attacks via the radio interface, the identity, location or communication content of the user may be compromised. Examples of attacks include, but are not limited to, a linkable attack and a denial of service (DoS) attack. For example, a sui intercepted by an attacker via a radio interface may be used in a linkable attack, wherein it is possible for the attacker to determine if a UE observed at a certain location/time X is the same as a UE observed at some other location/time Y, thereby tracking the UE. For example, an attacker may record the sui that has been used by UE a over the radio interface. In the case of UE a using GUTI for authentication instead of sui, an attacker may also perform an active attack to obtain sui, e.g. destroy GUTI when it is sent by UE a, which with a high probability results in sui requests of AMF/SEAF 330 and sui transmissions from UE as a response. When later UE B issues a registration request to a false base station that the same attacker operates as a relay station, the attacker can modify the registration request of UE B by exchanging its sui or GUTI with the sui of UE a that was previously captured, and forward the modified request to the network. The attacker then monitors the response between the network and UE B to determine if UE B is identical to UE a, making it possible to track this UE. For example, the attacker then observes via the monitoring radio interface whether a successful authentication and key agreement (Authentication and Key Agreement, AKA) run is performed and whether the registration request is accepted by the network, and if so, UE a and UE B will be determined by the attacker to be the same UE.

Such a linkable attack cannot be mitigated by hiding only the content of the AKA response, as an attacker can detect from various subsequent messages intercepted in the radio interface whether AKA operation was successful without knowing the content of the AKA response. In the case where the contents of the AKA response are not hidden, these contents may be used directly by an attacker to determine if the attacked UE is present in the vicinity of the pseudo base station.

Thus, by replaying the sui, the attacker observes whether a successful AKA run is performed with replaying the sui, i.e. whether the replayed registration request is accepted by the network. If so, the attacker can link the UE observed at one location with the UE observed at another location (where the sui is replayed). When performed by an attacker at several locations, even though the attacked UE may still be anonymous, the anonymous UE may be tracked at different locations, with its privacy and untraceability compromised.

As another example, the network may be subject to DoS attacks in which an attacker replays the sui. In particular, an attacker may replay the sui to place the network and/or UE under heavy duty when performing frequent and repeated procedures, such as the sui un-concealment procedure and authentication procedure. This is particularly likely to occur when the unhiding scheme (e.g., elliptic curve integrated encryption scheme (Elliptical Curve Integrated Encryption Scheme, ECIES)) does not have any mechanism to detect or adjust whether the received SUCI was sent by the UE to the network the previous one.

Thus, if an attacker initiates a sui replay attack multiple times, the UDM and UE may be forced to expend a large amount of resources to process the replayed sui and authentication request messages, respectively, because these messages appear legitimate. This initiates DoS attacks on both UDM and UE. DoS attacks on the UE may result in reduced processing power and rapid battery drain for the UE. DoS attacks on UDMs may result in reduced processing power of the UDM and delayed responses to legitimate registration requests and other types of requests.

Hidden authentication sequence number

In some embodiments, to combat the above-mentioned linkable and DoS attacks, the UE 310 and carrier network may maintain a pair of sequence numbers (alternatively referred to as authentication sequence numbers) to track the authentication and re-authentication of the UE. These sequence numbers may be referred to as SQNs _MS (on the UE side) and SQN _HE (on the carrier network side). For example, SQN _HE May be maintained in a Home Environment (HE) by the UDM/ARPF 370. 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 carrier network may maintain SQN _MS And SQN _HE Synchronization between them. For example, during an authentication or re-authentication process,detection of de-synchronization by the UE 310 or the network may be used to indicate potential attacks and other problems.

In some embodiments, for synchronization of sequence numbers, the SQN maintained by the UE 310 _MS May be delivered to the carrier network during some authentication procedures. Likewise, the SQN maintained by UDM/ARPF _HE May also be delivered to the UE. However, to protect these sequence numbers from leakage, their transmission may be minimized and when transmission is necessary, they may be delivered in encrypted form that is considered secure. In one exemplary embodiment, described in more detail below, the SQN _MS May be transmitted along with and in the 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 the authentication procedure. SQN from UDM/ARPF side _HE May be communicated to the UE by embedding and encrypting in an authentication vector, as described in further detail below.

Specifically, SQN _MS May be protected by being transmitted to the AMF/SEAF 330 via a radio interface after encryption based on, for example, elliptic Curve Integrated Encryption Scheme (ECIES). In other words, the use of hidden ECIES for SUPI during the authentication procedure can be extended to accommodate SQN _MS And SUPI. In some embodiments, the SUPI may be associated with a SQN _MS Combines and performs symmetric encryption under ECIES as one plain text block. SQN (SQN) _MS And SUPI may be in cascade, interleaved, or the like. For example, in the case of authentication using an international mobile subscriber identity (International Mobile Subscriber Identity, IMSI) instead of SUPI, a mobile subscription identification number (Mobile Subscription Identification Number, MSIN) (e.g., 9 to 10 digits) and SQN _MS May be combined and encrypted/hidden by the UE. Accordingly, ECIES-based symmetric decryption may be used to un-conceal SUPI (or MSIN) and SQN in the home network _MS 。

Hidden registration time stamp

In some other embodiments, to combat the above sui replay attacks, the UE 310 may communicate a timestamp to the network along with the sui in the registration or authentication request message. Such a timestamp may be relied upon by the network to detect a sui replay attack. Similar to the authentication sequence number described above, a timestamp may be combined with the SUPI, followed by the execution of the ECIES encryption on the combination. The combination of SUPI and time stamps may be based on other forms of concatenation, interleaving.

The hiding of the timestamp of the registration/authentication request may be performed instead of or in addition to the hiding of the authentication sequence number above. For example, the SUPI, sequence number, and/or timestamp may be combined (e.g., concatenated or interleaved) and then encrypted using the ECIES scheme.

SUCI data structure

SUPI (or MSIN) and SQN _MS And/or the hidden concatenation of timestamps may be transmitted to the AMF/SEAF 330 of the serving network as part of the sui data structure. An example of a sui data structure 400 is shown in fig. 4. The SUCI structure 400 includes a SUPI type field 402, ranging in value from 0 to 7, for example, for identifying the type of identifier that is hidden in the "scheme out" field 412 as well as other fields of the SUCI structure 400. As an 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 (Global Line Identifier, GLI)

-3: global cable identifier (Global Cable Identifier, GCI)

-4: and SQN _MS And/or SUPI of message timestamp combination (concatenation)

-5 to 7: for other indicator reserved values.

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

Authentication based on hidden SUPI and authentication sequence number

Fig. 5 illustrates an example data and logic flow 500 for assuming successful authentication between a UE 310 and a network using a data packet containing SQN _MS Is subject to primary network registration/authentication between the UE 310 and the home core networks AUSF 360 and UDM/ARPF 370 via the serving network AMF/SEAF 330. Logic and data flow 500 may include the following exemplary steps with corresponding step numbers in fig. 5.

1. During the primary authentication process 500, the USIM and ME connect the SUPI of the UE 310 with the current SQN maintained by the USIM or ME via, for example, concatenation or interleaving _MS And (5) combining. SUPI and SQN _MS The combined (e.g., concatenated or interleaved) plain text blocks of (a) may be encrypted in USIM or ME using ECIES methods. The SUCI data structure following FIG. 4 can be constructed to include SUPI and SQN _MS Is a combination of the encryption of (a). The "SUPI type" field of the SUCI structure (402 of FIG. 4) may be set to indicate that the SUCI structure contains SUPI and SQN _MS Is a hidden combination of (a) and (b). For example, the value "4" may be set in the "SUPI type" field of the SUPI structure.

The ue may use the SQN containing the concealment in the registration request message _MS The registration request message is sent from the UE 310 to the serving AMF/SEAF 330.

3. Upon receiving the registration request message from UE 310, whenever serving AMF/SEAF 330 wishes to initiate authentication, serving AMF/SEAF 330 may invoke an AUSF service (denoted as a ausf_ue authentication service) by sending an AUSF service request message (denoted as a ausf_ue authentication request message) to home AUSF 360. For example, the Nausf UE Authentication _authentication request message may contain a hidden SUPI and SQN embedded therein _MS And a service network name.

4. Upon receipt of the Nausf_UEAuthenticate request message, the home AUSF 360 may check whether the request AMF/SEAF 330 in the serving network is eligible to use the serving network name contained in the Nausf_ UE Authentication _Authenticate request by comparing the received serving network name with the expected serving network name. The 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, the AUSF 360 may respond to the UE 310 indicating that the serving network is not authorized in a response message (denoted as a nausf_ue authentication_authentication response). If the serving network is authorized to use the received serving network name, a UDM authentication request message (denoted as a 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:

-comprising hidden SUPI and SQN _MS SUCI of (F); and

-a service network name.

5. Upon receipt of the nudm_ueauthentication_get request, the home UDM/ARPF 370 may invoke a subscription identifier unhidden function (Subscription Identifier De-concealment Function, SIDF) if it determines from the SUPI type field of the received sui data structure that the SUPI type is with the SQN _MS A combined SUPI. Thus, the SIDF may un-conceal the received SUCI before the UDM 370 is able to process the request to obtain SUPI and SQN _MS . Based on the SUPI, the UDM/ARPF 370 may perform its authentication procedure. De-hiding SQN _MS May be stored in the UDM 370 for future use (as described in more detail below with reference to fig. 6). The UDM 370 may further generate a new SQN _HE Which is larger than the current SQN maintained by the UDM _HE . Then, the current SQN _HE Refreshed SQN _HE And (5) replacing. Authentication vector is also based on refreshed SQNs _HE And other information to generate (the components of the authentication vector are in step 6 below).

6. For each nudm_authentication_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 the authentication management field (Authentication Management Field, AMF) separation bit set to "1". The UDM/ARPF 370 can then derive the AUSF secret Key K _AUSF And calculation eXpected RESponse (represented by XRES). Finally, UDM/ARPF 370 may be derived from a random number (denoted RAND), an authentication key (denoted AUTN), XRES and K _AUSF Creates HE AV. For example, AUTN contains SQN _HE Is a piece of information of (a). The UDM/ARPF 370 may then return the HE AV to the AUSF 360 in a response to the AUSF 360 (represented by the nudm_ue authentication_get response) along with an indication that the HE AV is to be used for AKA. The UDM/ARPF 370 may include the unhidden SUPI in the nudm_ueauthentication_get response.

Ausf 360 may temporarily store XRES along with SUPI received from UDM/ARPF 370.

8. AUSF 360 may then calculate the XRES (represented by HXRES) from the hashes of XRES and the K _AUSF SEAF key (by K) _SEAF Representation) and replacing XRES with HXRES and K in the HE AV generating AV _SEAF Replacement K _AUSF And AV is generated from HE AV received from the UDM/ARPF 370.

9. The AUSF 360 may then remove K _SEAF And returns a service context authentication vector (denoted as SE AV, including RAND, AUTN, and HXRES) to SEAF 330 in a response message (denoted as nausf_ueauthentication_authentication response)

The seaf 330 may send RAND, AUTN included in AV to the UE in a non-access stratum (NAS) message authentication request. The message may also include an ngKSI to be used by the UE and AMF to identify K _AMF And a partial local security context (created if authentication is successful). The ME may forward RAND and AUTN received in the NAS message authentication request to the USIM.

11. Upon receiving the RAND and AUTN, the UE (e.g., USIM or ME) may verify the freshness of the AV by checking whether the AUTN is acceptable. For example, the UE may extract the SQN contained in the AUTN _HE And with local SQN _MS A comparison is made. If SQN _HE Not less than SQN _MS The UE may determine that sequence number synchronization was successful. Otherwise, the UE determines that the sequence number synchronization fails. When the UE determines the sequence number SQN _MS And SQN _HE Upon synchronization, the UE performs the remaining steps in fig. 5 as described below. If it isSequence number synchronization is confirmed, the USIM can calculate a response (denoted by RES). The USIM may return RES, CK, IK to the ME. If the USIM calculates Kc (i.e., GPRS Kc) from CK and IK using transfer function c3 and sends it to the ME, the ME may ignore such GPRS Kc and not store it on the USIM or in the ME. ME may then calculate RES from RES. ME can calculate K from CK IK _AUSF . ME can be derived from K _AUSF K is calculated in (1) _SEAF . The ME accessing the network may check during authentication whether the "split bit" in the AMF field of the AUTN is set to 1. The "partition bit" is bit 0 of the AMF field of the AUTN. At the time of determining SQN _MS And SQN _HE During the sequence number synchronization, the UE uses the extracted SQN _HE Updating (or replacing) its SQN _MS For future synchronization purposes.

Ue 310 may return RES in a NAS message authentication response to SEAF.

13. SEAF 330 may then calculate HRES from RES and SEAF 330 may compare HRES to HXRES. If they are consistent, the SEAF 330 may consider the authentication of the UE 310 to be successful from the perspective of the serving network. When authentication is successful, the remaining steps of fig. 5 below are followed. If not, the SEAF 330 may notify the network of the authentication failure by, for example, sending a response message with a failure code and/or dropping/stopping/exiting the authentication. If the UE is not reached (e.g., no response is obtained from the UE) and RES is never received by SEAF 330, the SEAF may consider the authentication to be failed and indicate the failure to AUSF 360.

Seaf 330 may send RES received from UE 310 to AUSF 360 in a message (represented by a ausf_ue authentication_authentication request message).

15. When AUSF 360 receives the ausf_ueauthentication_authentication request message including RES as an authentication acknowledgement, it can verify whether AV has expired. If the AV has expired, then AUSF 360 may consider the authentication of UE 310 unsuccessful from the perspective of the home network. Upon successful authentication, the AUSF 360 may store K _AUSF . AUSF 360 may compare the received RES with the stored XRES. If RES and XRES are equal, thenFrom the perspective of the home network, AUSF 360 may consider authentication of UE 310 to be successful and follow the remaining steps of fig. 5 below. The AUSF 360 may notify the UDM 370 of the authentication result. Upon failure (RES and XRES are not equal), AUSF 360 may notify the network of the failure to authenticate and/or discard/stop/exit authentication by, for example, sending a response message with a failure code.

Ausf 360 may indicate to SEAF 330 in a response message (denoted as a nausf_ue authentication_authentication response) whether authentication was successful from the perspective of the home network. If the authentication is successful, K _SEAF May be sent to SEAF 330 in a nausf_ueauthentication_authentication response. If authentication is successful, AUSF 360 may also include SUPI in the Nausf_UEauthentication_authentication response message.

Ausf 360 may use a request message (denoted as a nudm_ue authentication_resultconfirmation request) to inform the UDM 370 of the result and time of the authentication procedure with the UE 310. The request may include SUPI, a timestamp of the authentication, an authentication type (e.g., EAP method or AKA), and a service network name.

UDM 370 can store the authentication status (SUPI, authentication result, timestamp, and service network name) of UE 310 and use the current SQN _HE Updating its previously stored SQN _MS For future authentication sequence number synchronization purposes.

Udm 370 may reply to AUSF 360 with a response message (denoted nudm_ue authentication_resultconfirmation response).

20. Upon receiving a subsequent UE-related procedure (e.g., nudm_uecm\u from AMF 330

Registration_request), the UDM 370 may apply actions according to home operator policies to detect and implement protection from certain types of fraud.

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

The verification steps 13 and 15 may fail, indicating that the UE cannot be authenticated. In those cases, the fault message may be sent to the UDM 370 in a cascaded manner. Similar to step 18 above, UDM 370 can still store authentication state and use current SQN _HE Updating stored SQNs _MS 。

Sequence number synchronization failure handling

As in step 11 shown in fig. 5 and as described above, when the SQN is extracted from the AUTN received from the AMF 310 _HE Less than local SQN _MS At this time, the UE 310 may determine that sequence number synchronization fails. Fig. 6 shows an example logic and data flow 600 for re-authentication (RA) after such a serial number synchronization failure.

In RA0, as shown in fig. 6, the UE 310 may not calculate the SQN embedded for transmission to the AMF 330 _MS Such as AUTS) to avoid SQN _MS Another exposure in the radio interface. In contrast, the UE 310 transmits a response message only to the AMF 330 indicating a cause of a failure for desynchronization as a sequence number. Such desynchronization may occur, for example, when UE 310 and the network are subject to a sui replay attack. As an example of RA1, the UE 310 may respond with a NAS message authentication failure with only a cause value indicating that the failure reason is SQN failure/mismatch without computing and sharing the AUTS with the network.

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

In RA3, upon receiving the Nausf_UEauthentication_authentication request message from AMF 330, AUSF 360 sends a request message (denoted as Nudm_ UE Authentication _get request message) to UDM/ARPF 370.

In RA4, when the UDM/ARPF 370 receives a Nudm_UEauthentication_get request message from the AUSF 360, the ARPF 370 may be mapped to the HE/AuC. The UDM/ARPF 370 may send a response message (represented by a nudm_ueauthentication_get response message) for use by using the SQN stored in the UDM 370 _MS (e.g., in steps 5 or 18 of FIG. 5) rather than a refreshed SQN _HE Re-authentication of the UE with the new authentication vector. The AUSF 360 operates following the principles of steps 6-11 of fig. 5 with the new acknowledgement of the UE 310The course of the syndrome.

GUTI identity verification with SUPI failure

Fig. 7 shows a logic and data flow 700 for a registration/authentication procedure initiated by a UE 310 using a network-assigned temporary identifier, such as a GUTI obtained via a previous registration and authentication procedure, such as step 21 in the sui registration procedure shown in fig. 5. Steps 0-2 of fig. 7 are described below.

Ue 310 may initiate a registration procedure using a temporary identity such as GUTI.

Ue 310 may use the temporary identity GUTI in a registration request message that is sent to service AMF/SEAF 330.

2. The serving AMF/SEAF 330 may attempt to obtain the SUPI of the UE from the old AMF/SEAF 702, e.g., as identified in the registration message, and if the serving AMF/SEAF 330 fails to obtain the UE context from the old AMF/SEAF 702 (step 2a of fig. 7), the serving AMF/SEAF 330 may send an identity request message with an identity type to the UE 310 (step 2b of fig. 7). Upon receipt of the identity request message, the UE 310 may send to the AMF/SEAF 330 a message with the current SQN embedded _MS Identity response message of the sui of (step 2c of fig. 7).

The remaining steps 3-21 in the logic and data flow 700 basically use the sui to perform the authentication process and reflect steps 3-21 in the 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 described in detail here.

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

In addition, the verification steps 13 and 15 may fail, indicating that the UE 310 cannot be authenticated by the network. In those cases, the fault message may be sent to the UDM 370 in a cascaded manner, as described above with respect to fig. 5. Similar to step 18 in fig. 7 and described above for step 18 of fig. 5, the UDM may still store the authentication state and use the current SQN _HE Updating stored SQNs _MS 。

GUTI authentication with successful SUPI retrieval

Fig. 8 shows a logic and data flow 800 for a registration/authentication procedure initiated by a UE 310 using a network-assigned temporary identifier, such as a GUTI obtained via a previous registration and authentication procedure, such as step 21 in the sui registration procedure shown in fig. 5 or fig. 7, wherein the sui of the UE is successfully identified by the serving network. Logic and data flow 800 of fig. 8 is similar to 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 for the UE 310 _MS 。

Ue 310 may initiate a registration procedure with GUTI.

Ue 310 may use the GUTI in the registration request message instead of the sui, which is sent to AMF/SEAF 330.

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

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

4. Upon receipt of the Nausf_UEAuthenticate request message, the home AUSF 360 may check whether the request AMF/SEAF 330 in the serving network is eligible to use the serving network name contained in the Nausf_ UE Authentication _Authenticate request by comparing the received serving network name with the expected serving network name. The 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 a response message (represented by a Nausf UE Authentication _authentication response). The AUSF 360 may then send a request message (denoted nudm_ue authentication) to the home UDM/ARPF 370

A_get request). The nudm_ue authentication_get request may include the SUPI of the UE and the service network name.

5. Home upon receiving a nudm_ueauthentication_get request from home AUSF 360

The UDM/ARPF 370 may select a SUPI-based authentication method. At the home UDM 370, the home environment AV vector uses a SQN that is greater than the refresh of the previous sequence number for the UE 310 _HE To be generated.

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 the SUPI, rather than the sui, is communicated from the serving network to the home network during the authentication process. Thus, the SQN of the UE _MS Will not be transferred to the home UDM/ARPF 370 and the SQN previously stored at the home UDM as shown in step 0 of fig. 8 _MS Will not use the current SQN _MS To update.

The remaining steps 6-21 in the logic and data flow 800 of fig. 8 basically perform an authentication process reflecting 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 connection with fig. 5 and are not repeated here.

Furthermore, if in step 11 of fig. 8 the SQN synchronization check fails at the UE, the 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 the previously stored SQN _MS . Due to the lack of updates in GUTI authentication steps 1-5 in the logical and data flow 800, the SQN maintained at UDM 370 _MS Will not become out of sync because any successful authentication (in the logic and data flow 800 of fig. 8, 500 of fig. 7, and 700 of fig. 7) will cause the SQN maintained at the UDM 370 _MS Update (or synchronize) with the current SQN at step 18 as these logical and data streams _HE Replacing stored SQNs _MS As a result of (a).

In addition, 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 casesAnd as described above with respect to fig. 5, the fault message may be sent to the UDM 370 in a cascaded manner. Similar to step 18 in fig. 8 and described above for step 18 of fig. 5, UDM 370 may still store the authentication state and use the current SQN _HE Updating stored SQNs _MS 。

Using SQNs to combat SUCI replay attacks from a network

In some embodiments, the SUCI replay attack may be based on the UE-side sequence number SQN _MS And HE side sequence number SQN _HE Detected at the network side. As step 1-5 shown in fig. 5 and 7 is embedded with hidden permanent UE identity and hidden SQN _MS As a result of the transmission of the SUCI of (2), SQN _MS Becomes available to the network side.

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

Specifically, in step 5 of the logical sum data flow 900, upon receiving the nudm_ueauthentication_get request sent from the home AUSF 360, the home UDM 370 may invoke the SIDF if the SUPI type is with the SQN _MS The combined SUPI, the SIDF procedure may un-conceal the received SUPI to obtain the SUPI and SQN associated with the UE 310 before the home UDM 370 is able to handle the request _MS 。

For the sui 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 determination:

if the home UDM 370 has not already had a locally stored SQN for the UE 310 _MS It can store the SQN received with the sui _MS And further selects an authentication method based on the SUPI and based on the refresh and the added SQN _HE To generate AV.

If the home UDM 370 has a previously stored SQN for the UE 310 _MS It can be configured asSQN to be received _MS With previously stored SQNs _MS A comparison is made.

If the comparison reveals a received SQN _MS Less than or equal to the previously stored SQN _MS The home UDM 370 determines that a sui replay attack has occurred and responds with a fault code or discards the message to stop the authentication process.

O however, if the comparison shows a received SQN _MS SQN larger than store _MS The home UDM 370 may alternatively be configured to select a SUPI-based authentication method, generate a refresh and added SQN-based _HE And continues the rest of the authentication process in fig. 9.

O if SQN _HE Less than or equal to stored SQN _MS The home UDM 370 discards the AV and SQN _HE And generates a SQN with refresh _HE Is a new AV of (c).

The remaining steps in the logic and data flow 900 of fig. 9, except for step 5, basically perform an authentication process that reflects the corresponding steps in the logic and data flow 500 of fig. 5. These steps are summarized in fig. 9 and explained above in connection with fig. 5 and are not repeated here.

Similarly, fig. 10 illustrates logic and data flow 1000 for a registration/authentication procedure initiated by UE 310 using a network-assigned temporary identifier, such as a GUTI obtained via a previous registration and authentication procedure, such as step 21 in the sui registration procedure illustrated in fig. 9. The steps of fig. 10 are similar to those of fig. 7, except that step 5 includes a process for detecting a sui replay attack. 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. Thus, the steps summarized in fig. 10 are not described in detail herein.

Further, fig. 11 illustrates a registration/authentication procedure initiated by the UE 310 using a network-assigned temporary identifier, such as a GUTI obtained via a previous registration and authentication procedure (such as step 21 from the sui registration procedure shown in fig. 9 or 11), wherein the sui of the UE is successfully identified by the serving network. Each of FIG. 11The steps are similar to those of fig. 8, except that in step 5, the UDM 370 may select a SUPI-based authentication method and generate a SQN-based authentication method _HE And if SQN) _HE Less than or equal to SQN _MS The UDM 370 may discard the AV and SQN _HE And generates new AV and SQN _HE 。

Furthermore, if in step 11 of fig. 9, 10 and 11 the SQN synchronization check fails at the UE, the 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 the previously stored SQN _MS 。

Countering SUCI replay attacks from a network using registration request message timestamps

In some implementations, the sui replay attack may be detected at the network side based on the UE registration request timestamp. As a result of the transmission of the sui embedded with both the hidden UE identity and the hidden timestamp as described above, the registration timestamp becomes available to the network side.

Fig. 12 shows an example logic and data flow 1200 for a registration/authentication procedure initiated by a UE 310 using a sui with a hidden network identity (e.g., SUPI) and a hidden registration request timestamp. Logic and data flow 1200 is similar to logic and data flow 900 of fig. 9 except that the information hidden in the sui includes a UE identity and a registration request timestamp instead of a UE identity and SQN _MS And in step 5, the sui replay attack detection procedure is performed by the home UDM 370 based on the registration request timestamp instead of the authentication sequence number. Example steps 1-5 of the logic and data flow 1200 shown in fig. 12 are described in more detail below.

1. During the primary authentication process, the UE 310 (e.g., USIM) combines the SUPI with a registration request or MESSAGE timestamp (denoted message_time) by concatenation, interleaving, or other combination. For example, message_time may represent a UTC-based TIME when a MESSAGE (e.g., a registration or authentication MESSAGE) is sent. The SUCI data structure following FIG. 4 can be structured to include a cryptographic 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, the value "4" may be set in the "SUPI type" field of the SUPI structure.

The UE may use the sui containing the hidden message_time in a registration request MESSAGE sent from the UE 310 to the service AMF/SEAF 330.

3. Upon receiving the registration request message from UE 310, whenever AMF/SEAF 330 wishes to initiate authentication, serving AMF/SEAF 330 may invoke an AUSF service (denoted as a nasf_ueauthentication service) by sending an AUSF service request message (denoted as a nasf_ueauthentication_request message) to AUSF 360. For example, the Nausf_UEAuthority_Authority request MESSAGE may contain SUCI embedded with hidden SUPI and MESSAGE_TIME, and a service network name.

4. Upon receipt of the Nausf_UEAuthentication_Authentication request message, the home AUSF 360 may check whether the request AMF/SEAF 330 in the service network has access to the service network name contained in the Nausf_UEAuthentication_Authentication request by comparing the received service network name with the expected service network name. The AUSF 360 may temporarily store the received service network name. If the serving network is not authorized to use the received serving network name, the AUSF 360 may respond to the UE 310 indicating that the serving network is not authorized in a response message (denoted as a nausf_ue authentication_authentication response). If the serving network is authorized to use the received serving network name, a UDM authentication request message (denoted as a Nudm_UEauthentication_get request) may be sent from the home AUSF 360 to the home UDM/ARPF 370. The nudm_ UE Authentication _get request sent from the AUSF 360 to the UDM 370 may include the following information:

SUPI comprising hidden SUPI and message_time; and

-a service network name.

5. Upon receiving the nudm_ueauthentication_get request from the home AUSF 360, the home UDM 370 may invoke the SIDF, and if the SUPI type is a SUPI combined with message_time, the SIDF process may un-conceal the received sui to obtain the 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, home UDM 370 may compare the received MESSAGE_TIME with the current UTC-based TIME and make the following exemplary determinations:

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. Max_delay may be predetermined, for example, based on an estimated data transmission speed between the UE 310 and the UDM 370. Max_delay may be further adjusted as desired.

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, home UDM 370 may be configured to select the SUPI-based authentication method, generate AV, and continue the remaining authentication steps of fig. 12.

The remaining steps in the logic and data flow 1200 of fig. 12, except steps 1-5, basically perform an authentication procedure reflecting the corresponding steps in the logic and data flow 500 of fig. 5, except that in step 11 the SQN involving the UE side may not be required _MS Updating, and in step 18, the SQN may not need to be involved on the network side _MS Updating. These steps are summarized in fig. 12 and explained above in connection with fig. 5 and are not 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, such as via a previous registration and authentication process (such as the GUTI obtained from step 21 in the SUCI registration process shown in FIG. 12.) the various steps of FIG. 13 are similar to those of FIG. 7 except that steps 1-5 use hidden timestamps instead of SQNs _MS (as described in steps 1-5 of fig. 12), step 5 includes a process for detecting a sui replay attack similar to step 5 in logic and data flow 1200 shown in fig. 12 and described in detail above, at step 11, may not need to involve SQN on UE side _MS Updating, and in step 18, the SQN on the network side may not be involved _MS Updating. Thus, the steps summarized in fig. 13 are not described in detail herein.

Combination of hidden SQNMS and hidden registration request message time stamp

In some other embodiments, the SQN _MS And registration message time stamps may be used. In other words, SQN _MS And the registration message timestamp may both be combined with the SUPI and hidden to generate the sui for use in registration and authentication. As such, the various logic and data flows in fig. 5, 7, 9, 10, and 11 may be combined with the logic and data flows in fig. 12 and 13 to form other logic and data flows. For example, SQN _MS Both the registration message timestamp and the storage SQN may be transferred to _MS And both the sequence number and the timestamp may be used to detect and respond to the sui replay attack.

The foregoing drawings and description provide specific example embodiments and implementations. The described subject matter may, however, be embodied in various different forms and, thus, covered or claimed subject matter is not to be construed as limited to any example embodiments set forth herein. Is intended to be directed to a reasonably broad scope to the claimed or covered subject matter. The subject matter may be embodied as, among other things, methods, devices, components, systems, or non-transitory computer-readable media for storing computer code. Accordingly, embodiments may take the form of hardware, software, firmware, storage media, or any combination thereof, for example. For example, the method embodiments described above may be implemented by a component, apparatus, or system comprising a memory and a processor by executing computer code stored in the memory.

Throughout the specification and claims, terms may have the meanings explicitly set forth above or below, with the meanings explicitly set forth. 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 claimed subject matter include, in whole or in part, combinations of example embodiments.

Generally, terms are to be understood, at least in part, from the usage of the context. For example, terms such as "and," "or," "and/or," as used herein may include a wide variety of meanings that may depend, at least in part, on the context in which the terms are used. Typically, if "or" is used to associate a list such as A, B or C, it is intended to mean A, B and C, used herein in an inclusive sense, and A, B or C, used herein in an exclusive sense. Furthermore, the term "one or more" as used herein, depending at least in part on the context, may be used to describe any feature, structure, or characteristic in a singular sense, or may be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, terms such as "a," "an," or "the" may be understood as expressing a singular or plural of usage depending at least in part on the context. In addition, the term "based on" may be understood as not necessarily intended to convey an exclusive set of factors, but may also allow for additional factors not necessarily explicitly described to be present, depending at least in part on the 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 in any single embodiment 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, 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 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 may 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

1. A method for generating subscription data items, the method being performed by a first network element in a network, the method comprising:

Acquiring a time stamp indicating the current time;

obtaining a subscription identifier identifying the first network element;

combining the timestamp with the subscription identifier to obtain a composite data item;

encrypting the composite data item to obtain an encrypted composite data item; and

the subscription data item is generated, the subscription data item comprising the encrypted composite data item as a hidden identity of the first network element and a type indicator for indicating a type of the hidden identity.

2. The method of claim 1, wherein obtaining the subscription identifier comprises: a permanent subscription identity stored in a subscription module of the first network element is retrieved.

3. The method of claim 1, wherein the timestamp is generated in a coordinated Universal Time (UTC) time format.

4. The method of claim 1, wherein the subscription identifier and the timestamp are combined via one of concatenation or interleaving.

5. The method of claim 1, wherein the type indicator comprises a unique value for indicating that a hidden identity in the subscription data item is a combination of the subscription identifier and the timestamp.

6. The method of claim 1, wherein encrypting the composite data item to obtain an encrypted composite data item comprises: the composite data item is encrypted according to an Elliptic Curve Integrated Encryption Scheme (ECIES) scheme to obtain the encrypted composite data item.

7. The method of claim 1, wherein the first network element comprises a User Equipment (UE).

8. The method of claim 1, wherein the subscription data items form a subscription hidden identifier (sui).

9. The method of claim 1, wherein the subscription identifier comprises a unique subscription permanent identifier (SUPI) of the first network element.

10. The method of claim 1, further comprising:

generating a first message comprising a subscription data item for requesting registration or authentication of a first network element with a network; and

the first message is transmitted to a second network element in the network for registration or authentication.

11. The method of claim 10, wherein the first message comprises one of:

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

An identity response message is responded to by the first network element in response to an identity request from the network.

12. The method of claim 11, wherein the network comprises a 5G communication network and the first message is transmitted via an N1 interface.

13. A method for processing an authentication message initiated from a first network element in a network, the method being performed by a second network element in the network, the authentication message comprising a subscription data item having a hidden identity of the first network element and a type indicator indicating a type of the hidden identity, and the method comprising:

parsing the authentication message to obtain the hidden identity and the type indicator;

decrypting the hidden identity to obtain an unhidden data item; and

upon determining from the type indicator that the hidden identity is a composite data item, parsing the un-hidden data item to obtain a first timestamp indicating when the authentication message originated from the first network element, and a subscription identifier of the first network element.

14. The method of claim 13, further comprising: a second timestamp is obtained indicating when the authentication message was received by the second network element.

15. The method of claim 14, wherein the second network element is configured to maintain a maximum transmission time delay threshold, and wherein the method further comprises: the maximum transmission time delay threshold is subtracted from the second timestamp to obtain an expiration timestamp.

16. The method of claim 15, further comprising: discarding and terminating processing of the authentication message in response to the first timestamp being less than the expiration timestamp.

17. The method of claim 15, further comprising: responsive to the first timestamp being less than the expiration timestamp, a response message to the authentication message including a fault code is sent.

18. The method of claim 15, further comprising, in response to the first timestamp being greater than or equal to the expiration timestamp, and the first timestamp being less than the second timestamp:

generating an authentication vector; and

and sending a response message to the authentication message including the authentication vector and the subscription identifier.

19. The method of claim 18, wherein the network comprises a 5G communication network and the response message is transmitted via an N13 interface.

20. The method of claim 15, wherein the maximum transmission time delay threshold is predetermined based on a data transmission speed between the first network element and the second network element.

21. The method of claim 13, wherein the first timestamp is generated in a coordinated Universal Time (UTC) time format.

22. The method of claim 13, wherein when indicating that the hidden identity is a composite data item, the type indicator comprises a unique value for indicating that the hidden identity in the subscription data item is a combination of a subscription identifier and a timestamp.

23. The method of claim 13, 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).

24. The method of claim 13, wherein the subscription data items form a subscription hidden identifier (sui).

25. The method of claim 13, wherein the subscription identifier comprises a subscription permanent identifier (SUPI) of the first network element.

26. The first network element of any one of claims 1 to 12, comprising a processor configured to implement the method of any one of claims 1 to 12.

27. The second network element of any one of claims 13 to 25, comprising a processor configured to implement the method of any one of claims 13 to 25.

28. 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 to 25.