CN115699672A - Method for preventing encrypted user identity from replay attack - Google Patents

Abstract

The present invention 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 a core network side to reduce leakage of confidential user information based on a set of authentication sequence numbers maintained and updated synchronously at the wireless terminal side and the core network side. Communication of the sequence number between the wireless terminal and the core network is minimized and further effectively hidden from exposure in the radio interface during limited transmission times. The detection of sequence number asynchronism between the wireless terminal and the core network is used by the core network to determine a registration replay attack and to stop transmitting request and response messages which may cause leakage of confidential information of the wireless terminal and in some cases denial of service by the terminal device or the network.

Description

Method for preventing encrypted user identity from replay attack

Technical Field

The present invention relates generally to the field of communications, and more particularly to registration and authentication procedures between a mobile terminal and a core network.

Background

The wireless terminal device may communicate with a home core network of the wireless terminal device via a serving network. The wireless terminal device may initiate registration and authentication procedures 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 device to the network and to authenticate the network to the wireless terminal device. Upon successful registration and authentication, access credentials are generated to enable further communication between the wireless end device and the network. Communication messages between the UE and the network via the 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 invention 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 a core network side to reduce leakage of confidential user information based on a set of authentication sequence numbers maintained and updated synchronously at the wireless terminal side and the core network side. The communication of the sequence number between the wireless terminal and the core network is minimized and further effectively hidden from exposure in the radio interface during limited transmission times. Detection of the sequence number non-synchronization between the wireless terminal and the core network is used by the core network to determine registration replay attacks and to stop transmitting request and response messages that may cause leakage of confidential information of the wireless terminal and in some cases denial of service by the terminal device or the network.

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

In some other implementations, a network apparatus is disclosed. The network device mainly comprises 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 above-described authentication procedure method of the second network element performed by the first network element.

In yet other implementations, a computer-readable storage medium storing computer code which, when executed by one or more processors, implements an execution method of an authentication process of a second network element is disclosed.

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

Drawings

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

Fig. 2 illustrates 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 illustrates an exemplary data structure for a user hidden identity for network registration and authentication of a wireless terminal.

Fig. 5 illustrates an exemplary logic flow for primary network registration/authentication between a wireless terminal (user equipment (UE)) and a core network based on a hidden identity of a user of the wireless terminal and a hidden authentication sequence number.

Fig. 6 illustrates an exemplary logic flow for re-authentication when a wireless terminal detects authentication sequence number desynchronization.

Fig. 7 illustrates an exemplary logic flow for registration/authentication between a wireless terminal and a core network based on a network assigned temporary identity and authentication sequence number for the wireless terminal that cannot be verified.

Fig. 8 illustrates an exemplary logic flow for network assigned temporary identity and authentication sequence number based on successful verification of a wireless terminal and for registration/authentication between the wireless terminal and a core network.

Fig. 9 illustrates an exemplary logic flow for primary network registration/authentication between a wireless terminal and a core network upon detection of authentication sequence number desynchronization from the network side based on a hidden identity and a hidden authentication sequence number of a user of the wireless terminal.

Fig. 10 illustrates an exemplary logic flow for registration/authentication between a wireless terminal and a core network based on a network-assigned temporary identity and an authentication sequence number of the wireless terminal that cannot be verified when authentication sequence numbers are detected to be out of sync from the network side.

Fig. 11 illustrates an exemplary logic flow for registration/authentication between a wireless terminal and a core network upon network-assigned temporary identity and authentication sequence number based on successful verification of the wireless terminal and detection of authentication sequence number desynchronization from the network side.

Fig. 12 illustrates an exemplary logic flow for primary network registration/authentication between a wireless terminal and a core network upon detection of a registration replay attack via a registration message timestamp from the network side based on a hidden identity and a hidden timestamp of a user of a corresponding registration message.

Fig. 13 illustrates an exemplary logic flow for registration/authentication between a wireless terminal and a core network upon detection of a registration replay attack from the network side via a registration message timestamp based on a network-assigned temporary identity of the wireless terminal that cannot be verified and a corresponding hidden timestamp of the registration message.

Detailed Description

Exemplary 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. For example, carrier network 102 may include an access network 120 and a core network 130. Carrier network 102 may be configured to transport voice, data, and other information (collectively referred to as data traffic) between terminal devices 110 and 112, between terminal devices 110 and 112 and service applications 140, or between terminal devices 110 and 112 and other data networks 150. After the authentication process is described in further detail below, a communication session may be established and a corresponding data path may be configured for such data transmission.

Access network 120 may be configured to provide terminal devices 110 and 112 with network access to core network 130. The core network 130 may include various network nodes or network functions, and the core network 130 is configured to control communication sessions and perform network access management and data traffic routing. The service application 140 may be hosted by various application servers that may be accessed by the terminal devices 110 and 112 through the core network 130 of the carrier network 102. The service applications 140 may be deployed as a data network external to the core network 130. Likewise, the terminal devices 110 and 112 may access the other data network 150 through the core network 130, and the other data network may appear as a data destination or data source for the particular communication session instantiated in the 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 for the service areas of the carrier network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions may be virtualized and implemented as virtual machines or software entities. Each network node may be configured with one or more types of network functions. These network nodes or network functions may collectively provide provisioning and routing functions of the core network 130. The terms "network node" and "network function" are used interchangeably in the present invention.

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 shown in fig. 2, those skilled in the art will appreciate that each of these network nodes or functions may be instantiated as multiple instances of network nodes distributed throughout the core network 130. 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 (AMNN) 230, an authentication network node (AUNN) 260, a network data management network node (ndn) 270, a Session Management Network Node (SMNN) 240, a Data Routing Network Node (DRNN) 250, a Policy Control Network Node (PCNN) 220, and an 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 connecting lines in fig. 2. Such signaling and data exchanges may be carried by signaling or data messages that conform to a predetermined format or protocol.

The implementations described above in fig. 1 and 2 may be applied to both wireless and wired 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 illustrates that a wireless communication network 300 may include a wireless terminal or User Equipment (UE) 310 (serving as the terminal device 110 of fig. 2), a Radio Access Network (RAN) 320 (serving as the access network 120 of fig. 2), a service application 140, a Data Network (DN) 150, and a core network 130 including an Access Management Function (AMF) 330 (serving as the AMNN230 of fig. 2), a Session Management Function (SMF) 340 (serving as the SMNN 240 of fig. 2), an Application Function (AF) 390 (serving as the ADMNN 210 of fig. 2), a User Plane Function (UPF) 350 (serving as the DRNN 250 of fig. 2), a policy control function 322 (serving as the PCNN 220 of fig. 2), an authentication server function (AUSF) 360 (serving as the nn 260 of fig. 2), and a universal data management/authentication credential and processing function (UDM/ARPF) 370 (serving as the UDMNN 270 of fig. 2). Furthermore, although only a single instance of some of the network functions or nodes of the wireless communication network 300 (and in particular the core network 130) is shown in fig. 3, it will be understood by those of ordinary skill in the art that each of these network nodes or functions may have multiple instances distributed throughout the wireless communication network 300.

In fig. 3, the UE310 may be implemented as various types of wireless devices or interrupts, the UE310 being configured to access the core network through the RAN 300. The UE310 may include, but is not limited to, a mobile phone, a laptop computer, a tablet, an Internet of Things (IoT) device, a distributed sensor network node, a wearable device, and the like. The UE310 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 telecommunications SIM (USIM), which includes some computing capabilities for network registration and authentication. The calculations required to perform network registration and authentication may be performed by the USIM or ME in the UE. For example, RAN320 may include a plurality of radio base stations distributed in a service area of a carrier network. Communications between the UE310 and the RAN320 may be carried over-the-air (OTA for short) radio interface, as shown at 311 in fig. 3.

As shown in fig. 3, UDM370 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 performing computations of authentication vectors and encryption keys using such long-term security credentials as input, as described in more detail below. To prevent unauthorized exposure of the 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/SEAF330 may communicate with the RAN320, SMF340, AUSF 360, UDM/ARPF 370 and PCF322 via communication interfaces indicated by various solid lines connecting these network nodes or functions. The AMF/SEAF330 may be responsible for signaling management of UEs to a non-access stratum (NAS) and for provisioning registration and access of the UE310 to the core network 130, as well as allocation of the SMF340 to support the communication needs of a particular UE. The AMF/SEAF330 may be further responsible for UE mobility management. The AMF may also include a security anchor function (SEAF for short, as shown in 330 of fig. 3) that interacts with the AUSF 360 and the UE310 for user authentication and management of various levels of encryption/decryption keys, as described in more detail below. The AUSF 360 may terminate user registration/authentication/key generation requests from the AMF/SEAF330 and interact with the UDM/ARPF 370 to complete such user registration/authentication/key generation.

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

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

The PCF322 may be responsible for managing and providing various levels of policies and rules to the AMF/SEAF330 and SMF340 applicable to the communication session associated with the UE 310. Thus, for example, the AMF/SEAF330 may allocate the SMF340 for the communication session based on policies and rules associated with the UE310 and obtained from the PCF 322. Likewise, SMF340 may assign UPF 350 to handle the routing and forwarding of data for a communication session based on policies and rules obtained from PCF 322.

In order for the UE310 to access the core network of the home carrier network to which it is subscribed, it may first communicate with the available RAN320 and the AMF/SEAF330 associated with the RAN 320. The RAN320 and the AMF/SEAF330 may or may not belong to a home carrier network (e.g., may be associated with another carrier network to which the UE310 is not subscribed and may be referred to as a serving network, and the term "serving network" may be used to generally refer to an access network having an AMF/SEAF that belongs to another carrier network or to the same home core carrier network). The AMF/SEAF330 of the serving network may communicate with the AUSF 360 and UDM/ARPF 370 of the home carrier network of the UE310 for authentication and then with the SMF340 and PCF322 of the home carrier network to establish a communication session after successful authentication.

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

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

The registration and authentication procedure may include the UE310 communicating with its home UDM/ARPF 370 via the serving RAN320, the serving AMF/SEAF330, the home AUSF 360, and the home UDM/ARPF, as described in more detail below. During the registration and authentication process, the UE310 verifies that it is communicating with a legitimate network, and the network likewise verifies that the UE310 is authorized to access the network. Upon successful authentication between the UE310 and the core network 300, the UE310 may be assigned a temporary access identity for further communication with the core network. Such temporary access identifiers may be frequently modified/replaced to reduce the harm of user identity, location and communication content to an attacker. Authentication may be initiated by the UE310 sending a registration request to the AMF/SEAF330 of the service, the registration request containing its hidden or encrypted unique permanent Identity, e.g. a user hidden Identity (SUCI). Also, upon successful registration, a Temporary Identity, such as a globally Unique Temporary Identity (GUTI for short), may be assigned to the UE310 by the AMF/SEAF330 for further access to the network.

The identity, location or communication content of the user may be revealed as a result of an external attack via the radio interface. Examples of attacks include, but are not limited to, linkable attacks and denial of service (DoS) attacks. For example, SUCI intercepted by an attacker via the radio interface may be used for a linkability attack, where it is possible for the attacker to determine whether a UE observed at 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 SUCI that UE a has used over the radio interface. In the case where UE a authenticates using a GUTI instead of a sui, the attacker may also perform an active attack to obtain the sui, e.g. by destroying the GUTI when it is sent by UE a, which is likely to result in a sui request by AMF/sea 330 and a sui transmission from the UE as a response. When a certain UE B later sends a registration request to a fake base station operated by the same attacker as a relay station, the attacker can modify the registration request of UE B by modifying the sui or GUTI in the registration request to the sui previously captured by UE a, and forward the modified registration request to the network. The attacker then monitors the response between the network and UE B to determine if UE B is the same as UE a, and thus may track this UE. For example, the attacker then observes whether a successful Authentication and Key Agreement (AKA) run has been performed by monitoring the radio interface and whether the registration request is accepted by the network, and if so, UE a and UE B determine the attacker to be the same UE.

Such a linkability attack cannot be mitigated by just hiding the content of the AKA response, since the attacker can detect from various subsequent messages intercepted in the radio interface whether the AKA run was successful, without knowing the content of the AKA response. In the case where the contents of the AKA response are not hidden, an attacker can directly use such contents to determine whether the attacked UE is present near the fake base station.

Thus, by replaying the sui, the attacker observes whether the replayed sui performed a successful AKA run, i.e. whether the replayed registration request was accepted by the network. If so, the attacker can link (replay their SUCI) the UE observed at one location with the UE observed at another location. When an attacker performs at several locations, it is possible to track anonymous UEs at different locations, whose privacy and untraceability are compromised, even though the attacked UE may still be anonymous.

In another embodiment, the network may be subject to a DoS attack by an attacker through replay of the SUCI. In particular, an attacker can replay the SUCI to overwhelm the network and/or the UE when frequent and repeated processes (e.g., SUCI un-hiding processes and authentication processes) are performed. This may especially occur when the un-concealment Scheme (e.g., elliptic Curve Integrated Encryption Scheme (ECIES) does not have any mechanism to detect or adjust whether the received SUCI is a SUCI that the UE previously sent to the network.

Thus, if an attacker makes a SUCI replay attack multiple times, the UDM and the UE may be forced to spend a large amount of resources to process the replayed SUCI and authentication request messages, respectively, because these messages appear legitimate. This triggers a DoS attack on the UDM and the UE. A DoS attack on a UE may result in a reduction in the processing power of the UE and a rapid drain on the battery. DoS attacks on UDMs may result in a reduction in the processing power of the UDM and delay responses to legitimate registration requests and other types of requests.

Hidden authentication sequence number

In some embodiments, to combat the above-described linkability and DoS attacks, the UE310 and the carrier network may maintain a pair of sequence numbers (alternatively referred to as authentication sequence numbers) to track authentication and re-authentication of the UE. These sequence numbers may be referred to as SQNs _MS (at the UE side) and SQN _HE (on the carrier network side). For example, SQN _HE May be maintained by the UDM/ARPF 370 in a Home Environment (HE). Only these sequence numbers are allowed to increase as the UE is authenticated and re-authenticated. Under normal network access conditions, the UE310 and the carrier network may maintain SQN _MS And SQN _HE Synchronization between them. For example, during an authentication or re-authentication process, detection of desynchronization by the UE310 or the network may be used to indicate potential attacks and other problems.

In some embodiments of sequence number synchronization, the SQN maintained by the UE310 _MS May be communicated to the carrier network during some authentication procedures. Also, SQN maintained by UDM/ARPF _HE May also be transmitted to the UE. However, to protect these serial numbers from leakage, their transmission can be minimized and, when transmission is necessary, can be transmitted in an encrypted form that is considered secure. In one exemplary embodiment described in more detail below, the SQNMS may be transmitted along with and in the same manner as the transmission of a Subscription Permanent Identifier (SUPI) from the UE310 to the AMF/SEAF330 of the serving network during the authentication procedure. Furthermore, SQN from UDM/ARPF side _HE May be transmitted to the UE by embedding and encrypting in the authentication vector, as described in further detail below.

In particular, the SQN can be determined by a method based on, for example, ECIES _MS Encrypted and sent to AMF/SEA via radio interfaceF330 to protect SQN _MS . In other words, the use of ECIES for hiding SUPI during authentication procedures may be extended to accommodate SQN _MS And SUPI. In some embodiments, SUPI may be associated with SQN _MS Combined and used as a plain text block for symmetric encryption under ECIES. The combination of SQNMS and SUPI may be in serial, interleaved, etc. For example, in a case where an International Mobile Subscriber Identity (IMSI) is used for authentication instead of the SUPI, a Mobile Subscriber Identity Number (MSIN) (e.g., 9 to 10 digits) and an SQN (SQN) _MS May be combined and encrypted/hidden by the UE. Accordingly, in the home network, ECIES-based symmetric decryption can be used to de-conceal SUPI (or MSIN) and SQN _MS 。

Hidden registration timestamp

In some other embodiments to combat the sui replay attack described above, the UE310 may transmit a timestamp to the network along with the sui in a registration or authentication request message. The network may rely on such timestamps to detect sui replay attacks. Similar to the authentication serial number described above, the timestamp may be combined with SUPI, and then ECIES encryption is performed on the combination. The combination of SUPI and time stamp 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 described above. For example, SUPI, sequence numbers, and/or timestamps 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 a hidden concatenation of timestamps may be sent as part of the SUCI data structure to the AMF/SEAF330 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, whose value ranges, for example, from 0 to 7, for identifying the type of identifier hidden in the "scheme output" field 412 as well as other fields of the SUCI structure 400. For example, various values may be used in field 402 to indicate the following SUPI types:

-0：IMSI

-1: network specific identifier

-2: global Line Identifier (GLI for short)

-3: global Cable Identifier (Global Cable Identifier, GCI for short)

-4: SUPI in combination with SQNMS and/or message time stamping (e.g., in series)

-5 to 7: retention values of other indicators.

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

Authentication based on hidden SUPI and authentication sequence number

FIG. 5 illustrates using an SQN containment _MS The exemplary data and logic flow 500 for primary network registration/authentication between the UE310 and the home core network AUSF 360 and UDM/ARPF 370 via the serving network AMF/SEAF330 assumes that authentication between the UE310 and the network is successful. The logic and data flow 500 may include the following exemplary steps with corresponding step numbers in fig. 5.

1. During the master authentication process 500, the USIM and ME combine the SUPI of the UE310 and the current SQN maintained by the USIM or ME via, for example, concatenation or interleaving _MS . SUPI and SQN _MS The combined (e.g., concatenated or interleaved) plaintext blocks of (c) may be encrypted in the USIM or ME using ECIES methods. SUCI data structure following FIG. 4 may be constructed to include SUPI and SQN _MS The encryption combination of (1). 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 SQNMS. For example, a value of "4" may be set in the "SUPI type" field of the SUCI structure.

The UE may use the inclusion of concealment in the registration request message sent from the UE310 to the serving AMF/SEAF330SQN _MS The suici data structure of (1).

3. Upon receiving the registration request message from the UE310, the serving AMF/SEAF330 may invoke the AUSF service (denoted as a Nausf UE authentication service) by sending an AUSF service request message (denoted as a Nausf UE authentication request message) to the home AUSF 360 whenever the serving AMF/SEAF330 wishes to initiate authentication. For example, the Nausf UEAutomation Automation request message may contain embedded hidden SUPI and SQN _MS SUCI and service network name.

4. Upon receiving the Nausf-ue authentication-authentication request message, home AUSF 360 may check whether the requesting AMF/SEAF330 in the serving network has the right to use the serving network name contained in the Nausf-ue authentication-authentication request by comparing the received serving network name with the expected serving network name. Home AUSF 360 may temporarily store the received serving network name. If the serving network is not authorized to use the received serving network name, the AUSF 360 may respond to the UE310 in a response message denoted as a Nausf _ UE authentication _ authentication response, indicating that the serving network is not authorized. If the serving network is authorized to use the received serving network name, a UDM authentication request message, denoted as a numm _ UEAuthentication _ Get request, may be sent from the home AUSF 360 to the home UDM/ARPF 370. The Nudm _ UEAutomation _ Get request may contain the following information:

-including hidden SUPI and SQN _MS SUPI of (1); and

-a service network name.

5. Upon receiving the Nudm _ UEAutomation _ Get request, if the home UDM/ARPF 370 determines that the SUPI type is equal to the SQN based on the SUPI type field of the received SUCI data structure _MS Combined SUPI, UDM/ARPF 370 may call a Subscription Identifier De-hiding Function (SIDF). Thus, the SIDF may de-conceal the received SUCI for SUPI and SQN before the UDM370 can process the request _MS . Based on SUPI, UDM/ARPF 370 may perform its authentication procedure.De-hidden SQN _MS May be stored in UDM370 for future use (as described in more detail below with reference to fig. 6). UDM370 may also generate new SQNs _HE Larger than the current SQN maintained by the UDM _HE . Then, the current SQN _HE Updated SQN _HE And (6) replacing. SQN based also on updates _HE And other information to generate an authentication vector (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 (HEAV). More specifically, UDM/ARPF 370 does this by generating an Authentication Vector (AV), with the Authentication Management Field (AMF) separation bit set to "1". UDM/ARPF 370 may then derive the AUSF key KAUSF and calculate an eXpected RESponse, denoted by XRES. Finally, UDM/ARPF 370 may create HE AV from the random number represented by RAND, the authentication key represented by AUTN, XRES, and KAUSF. For example, AUTN includes SQN _HE The information of (a). UDM/ARPF 370 may then return HE AV to AUSF 360 along with an indication that HE AV will be used for AKA in a response to AUSF 360 represented by the numm _ UEAuthentication _ Get response. The UDM/ARPF 370 may include the decaaled SUPI in the Nudm _ UEAutomation _ Get response.

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

8. The AUSF 360 may then generate the HE AV received from UDM/ARPF 370 by computing the hash XRES denoted by HXRES from XRES and the SEAF key denoted by KSEAF from KAUSF, and replacing XRES with HXRES and with K in the HE AV _SEAF Replacement of K _AUSF Further, AV is generated.

AUSF 360 then K can be removed _SEAF And returns to the SEAF330 a service environment authentication vector (including RAND, AUTN, and HXRES) denoted SE AV in a response message denoted Nausf UEAuthentication authentication response

The seaf330 may send the RAND, AUTN included in the AV to the UE in a non-access stratum (NAS) message authentication request. The message may also include an ngKSI that the UE and AMF will use to identify the KAMF and the partial local security context created in case of successful authentication. The ME may forward the RAND and AUTN received in the NAS message authentication request to the USIM.

11. Upon receiving the RAND and AUTN, the UE (e.g., USIM or ME) can verify the freshness of the AV by checking whether the AUTN can be accepted. For example, the UE may extract the SQN contained in the AUTN _HE And local SQN _MS A comparison is made. If SQN _HE Not less than SQN _MS The UE may determine that the 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 sequence number synchronization is confirmed, the USIM may calculate a response represented by RES. The USIM may return RES, CK, IK to the ME. If the USIM calculates Kc (i.e., GPRS Kc) from CK and IK using the conversion function c3 and sends it to the ME, the ME may ignore such GPRS Kc and not store the GPRS Kc on the USIM or in the ME. The ME may then calculate RES from RES. ME can compute K from CK IK _AUSF . ME can be selected from K _AUSF Calculating K _SEAF . The ME of the access network may check during authentication whether the "partition 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. Once SQN is determined _MS And SQN _HE The UE uses the extracted SQN _HE To update (or replace) its SQN _MS For future synchronization purposes.

The ue310 may return RES to the SEAF in a NAS message authentication response.

SEAF330 may then calculate HRES from RES, and SEAF330 may compare HRES with HXRES. If so, the SEAF330 may consider the authentication of the UE310 to be successful from the perspective of the serving network. When the authentication is successful, the remaining steps of FIG. 5 below are followed. If not successful, the SEAF330 may notify the network of the authentication failure by, for example, sending a response message with a fault code and/or discarding/stopping/quitting the authentication. If the UE is not contacted (e.g., no response is obtained from the UE), and the SEAF330 never receives RES, the SEAF may consider the authentication to be a failure and indicate the failure to the AUSF 360.

The seaf330 may send the RES received from the UE310 to the AUSF 360 in a message represented by a Nausf _ UE authentication _ authentication request message.

15. When AUSF 360 receives the Nausf _ UEAuthentication _ authentication request message including RES as an authentication confirmation, it can be verified whether the AV has expired. If the AV has expired, the AUSF 360 may consider the authentication of the UE310 unsuccessful from the home network perspective. After successful authentication, the AUSF 360 may store K _AUSF . The AUSF 360 may compare the received RES with the stored XRES. If RES and XRES are equal, the AUSF 360 may consider the authentication of the UE310 successful from the home network perspective and follow the remaining steps of fig. 5 below. The AUSF 360 may notify the UDM370 of the authentication result. Upon failure (RES and XRES not equal), the AUSF 360 may inform the network of the authentication failure by, for example, sending a response message with a fault code and/or discarding/stopping/logging out the authentication.

The ausf 360 may indicate to the SEAF330 whether the authentication was successful from the point of view of the home network in a response message denoted as the Nausf UEAuthentication authentication response. If the authentication is successful, KSEAF may be sent to the SEAF330 in a Nausf _ UEAutomation _ Automation response. If the authentication is successful, the AUSF 360 may also include SUPI in the Nausf _ UEAutomation _ Automation response message.

The ausf 360 may inform the UDM370 of the result and time of the authentication procedure with the UE310 using a request message denoted as the numm _ UE authentication _ resultconfiguration request. The request may include the SUPI, a timestamp of the authentication, an authentication type (e.g., EAP method or AKA), and a serving network name.

Udm370 may store the authentication status of UE310 (SUPI, authentication result, timestamp and serving network name) and update its previously stored SQNMS with the current SQNHE for future authentication sequence number synchronization purposes.

Udm370 may reply to AUSF 360 with a response message denoted as a numm _ UEAuthentication _ resultconfiguration response.

20. Upon receiving a subsequent UE-related procedure (e.g., the numm UECM Registration Request from the AMF 330), the UDM370 may apply actions according to the home operator's policies to detect and implement protection against certain types of fraud.

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

The verification steps 13 and 15 may fail, indicating that the UE cannot be authenticated. In these cases, the fault message may be sent to the UDM370 in a tandem fashion. Similar to step 18 above, the udm370 may still store the authentication status and use the current SQN _HE Updating stored SQN _MS 。

Sequence number synchronization failure handling

In step 11 as shown in FIG. 5 and described above, the SQN extracted from the AUTN received from the AMF 310 _HE Less than local SQN _MS The UE310 may determine that sequence number synchronization failed. Fig. 6 illustrates an exemplary logic and data flow 600 for re-authentication (RA) after such a sequence number synchronization failure.

In RA0, as shown in FIG. 6, the UE310 may not calculate an embedded SQN _MS For transmission to the AMF 330 to avoid SQN _MS Another exposure in the radio interface. Instead, the UE310 sends a response message only to the AMF 330 indicating that the reason for the failure is sequence number desynchronization. Such desynchronization may occur, for example, when the UE310 and the network are subjected to sui replay attacks. As an example of RA1, the UE310 may respond to NAS message authentication failure with only a cause value indicating the cause of the failure as SQN failure/mismatch, without calculating and sharing the AUTS with the network.

In RA2, upon receiving the authentication failure message from the UE310, the SEAF330 may send a request message denoted as a Nausf _ UE authentication _ authentication request message to the AUSF 360.

In RA3, upon receiving the Nausf-UEAutomation-Automation request message from AMF 330, AUSF 360 sends a request message, denoted Nudm-UEAutomation-Get request message, to UDM/ARPF 370.

In RA4, when UDM/ARPF 370 receives the Nudm _ UEAutomation _ Get request message from AUSF 360, ARPF 370 may be mapped to the HE/AuC. UDM/ARPF 370 may send a response message, represented by a Nudm _ UEAutomation _ Get response message, for use by using the SQN stored in UDM370 _MS (e.g., in step 5 or 18 of figure 5) rather than the updated SQN _HE And carrying out UE re-authentication by using the new authentication vector. The AUSF 360 runs a new authentication procedure with the UE310 following the principles of steps 6-11 of fig. 5.

SUPI failed GUTI authentication

Fig. 7 illustrates the logic and data flow 700 for a registration/authentication procedure initiated by the UE310 using a network-assigned temporary identifier, e.g., a GUTI obtained via a previous registration and authentication procedure (e.g., from step 21 in the SUCI registration procedure shown in fig. 5). Steps 0-2 of FIG. 7 are described below.

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

The ue310 may use the temporary identity GUTI in a registration request message that is sent to the serving AMF/SEAF 330.

2. The serving AMF/SEAF330 may attempt to obtain the SUPI for the UE from the old AMF/SEAF702, as identified, for example, in the registration message, and if the serving AMF/SEAF330 fails to obtain the UE context from the old AMF/SEAF702 (step 2a of fig. 7), the serving AMF/SEAF330 may send an identity request message with the identity type to the UE310 (step 2b of fig. 7). Upon receiving the identity request message, the UE310 may send an identity response message to the AMF/SEAF330, with SUCI embedding the current SQN _MS (step 2c of FIG. 7).

The remaining steps 3-21 in the logic and data flow 700 essentially use the SUCI to perform the authentication process and reflect the 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 are not repeated here.

Additionally, if the SQN synchronization check fails at the UE310 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.

Furthermore, the verification steps 13 and 15 may fail, indicating that the UE310 cannot be authenticated by the network. In those cases, and as described above for fig. 5, the fault message may be sent to the UDM370 in a tandem manner. Similar to step 18 in figure 7 and the description above for step 18 of figure 5, the UDM can still store the authentication status and update the stored SQNMS with the current SQNHE.

GUTI authentication for successful retrieval of SUPI

Fig. 8 illustrates the logic and data flow 800 for a registration/authentication procedure initiated by the UE310 using a network-allocated temporary identifier, e.g., a GUTI obtained via a previous registration and authentication procedure (e.g., from step 21 in the SUCI registration procedure shown in fig. 5 or fig. 7), wherein the serving network successfully identified the SUPI of the UE. The logic and data flow 800 of FIG. 8 is similar to the logic and data flow 500 of FIG. 5, except for steps 0-5, which will be described in more detail below.

0. The home UDM370 has previously stored the SQN of the UE310 _MS 。

1a. The ue310 may initiate a registration procedure with the GUTI.

1b.the ue310 may use GUTI in the registration request message instead of sui sent to AMF/SEAF 330.

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

3. The AMF/SEAF330 of the service may invoke the AUSF authentication service by sending a Nausf UEAutomation authentication authorization request message to the AUSF 360 whenever the AMF/SEAF330 of the service wishes to initiate authentication. The Nausf UEAuthentication authentication request message may include SUPI and a serving network name.

4. Upon receiving the Nausf-ue authentication-authentication request message, home AUSF 360 may check whether the requesting AMF/SEAF330 in the serving network has the right to use the serving network name contained in the Nausf-ue authentication-authentication request by comparing the received serving network name with the expected serving network name. Home AUSF 360 may temporarily store the received serving network name. If the serving network is not authorized to use the serving network name, home AUSF 360 may respond by indicating that the serving network is not authorized in a response message represented by the Nausf UEAuthentication authentication response. AUSF 360 may then send a request message denoted as a Nudm _ UEAutomation _ Get request to home UDM/ARPF 370. The Nudm _ UEAutomation _ Get request may include the SUPI and the serving network name of the UE.

5. Upon receiving the Nudm _ UEauthentication _ Get request from the home AUSF 360, the home UDM/ARPF 370 may select an authentication method based on SUPI. At the home UDM370, an updated SQN is used that is larger than the previous sequence number for the UE310 _HE A home context AV vector is 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 SUPI is delivered from the serving network to the home network instead of sui during the authentication procedure. Thus, SQN of the UE _MS Will not be sent to the home UDM/ARPF 370 and the SQNMS previously stored at the home UDM will not be updated with the current SQNMS as indicated in step 0 of figure 8.

The remaining steps 6-21 in the logic and data flow 800 of fig. 8 essentially perform an authentication process that reflects 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 will not be described again here.

Further, if the SQN synchronization check fails at the UE in step 11 of fig. 8, the re-authentication process 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 UDM370 at step RA4 may be based on the previously stored SQN _MS . SQN maintained at UDM370 due to lack of updates in GUTI authentication steps 1-5 in logic and data stream 800 _MS Will not become out of sync because of any successful authentication (at logic and data flow 800 of fig. 8, 50 of fig. 70 and 700 of figure 7) will cause the SQNMS maintained at the UDM370 to be updated (or synchronized) at step 18 with the current SQN for these logical and data flows _HE SQN for replacement storage _MS The result of (1).

Further, the verification steps 13 and 15 of the logic and data flow 800 of fig. 8 may fail, indicating that the UE310 cannot be authenticated by the network. In those cases, and as described above with respect to fig. 5, the fault message may be sent to the UDM370 in a tandem manner. Similar to step 18 in figure 8 and the description above for step 18 of figure 5, UDM370 may still store the authentication state and use the current SQN _HE Updating stored SQN _MS 。

sSQN for use in countering SUCI replay attack on network side

In some embodiments, the SQN may be based on the UE-side sequence number _MS And he side sequence number SQN _HE SUCI replay attacks are detected on the network side. The SQNMS becomes available to the network side due to the transmission of the SUCI embedding the hidden permanent UE identity and the hidden SQNMS in steps 1-5 shown in fig. 5 and 7.

FIG. 9 illustrates the use of SUCI (e.g., SUPI) and SQN with hidden network identity by the UE310 _MS Exemplary logic and data flow 900 of an initiated registration/authentication process. The logic and data flow 900 is similar to the logic and data flow 500 of fig. 5 except that in step 5, the SUCI replay attack detection procedure is performed by the home UDM370.

Specifically, in step 5 of the logic and data flow 900, upon receiving the Nudm _ UEAuthentication _ Get request sent from the home AUSF 360, the home UDM370 may invoke the SIDF if the SUPI type is the same as the SQN _MS Combined SUPI, the SIDF procedure may then un-conceal the received SUCI to obtain the SUPI and SQN associated with the UE310 before the home UDM370 may process the request _MS 。

For suii replay attack detection from the network side in step 5 of the logic and data flow 900 of fig. 9, the home UDM370 makes the following exemplary determination:

if the home UDM370 does not already have a locally stored SQN for the UE310 _MS Then reception over SUCI may be storedSQN (Sqn) _MS Selecting authentication method further based on SUPI, and based on updated and added SQN _HE An AV is generated.

If the home UDM370 has a previously stored SQN for the UE310 _MS Then it can be configured to receive the SQN _MS SQN with previous storage _MS A comparison is made.

O if the comparison shows a received SQN _MS Less than or equal to previously stored SQN _MS Home UDM370 determines that a SUCI replay attack has occurred and responds with a fault code or discards the message to stop the authentication process.

However, if the comparison shows that the received SQN is correct _MS SQN greater than storage _MS Home UDM370 may alternatively be configured to select a SUPI-based authentication method, generate an updated and augmented SQN _HE And continues with the remaining authentication process in fig. 9.

O if SQN _HE Less than or equal to stored SQN _MS Then home UDM370 discards AV and SQN _HE And generates an SQN with updates _HE The new AV of (1).

The remaining steps in the logic and data flow 900 of fig. 9, except for step 5, essentially 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 described again here.

Similarly, fig. 10 shows a logic and data flow 1000 for a registration/authentication procedure initiated by the UE310 using a network-allocated temporary identifier, e.g., a GUTI obtained via a previous registration and authentication procedure (e.g., from step 21 in the SUCI registration procedure shown in fig. 9). The various steps of fig. 10 are similar to those of fig. 7, except that step 5 includes a process for detecting a SUCI replay attack. Step 5 in logic and data flow 1000 of fig. 10 is similar to step 5 in logic and data flow 900 shown in fig. 9 and described in detail above. Thus, the steps summarized in FIG. 10 are not described repeatedly herein.

Further, fig. 11 illustrates a registration/authentication procedure initiated by the UE310 using a network-allocated temporary identifier, e.g., a GUTI obtained via a previous registration and authentication procedure (e.g., from step 21 in the SUCI registration procedure illustrated in fig. 9 or 11), wherein the serving network successfully identifies the SUPI of the UE. The steps of fig. 11 are similar to those of fig. 8, except that in step 5, UDM370 may select an authentication method based on SUPI and based on SQN _HE Generating AV if SQN _HE Less than or equal to SQN _MS UDM370 may then discard the AV and SQN _HE And generates new AV and SQN _HE 。

Further, if the SQN synchronization check fails at the UE in step 11 of fig. 9, 10 and 11, the re-authentication process 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 UDM370 at step RA4 may be based on the previously stored SQN _MS 。

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

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

Fig. 12 illustrates an exemplary logic and data flow 1200 for a registration/authentication procedure initiated by a UE310 using a SUCI 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 SUCI includes the UE identity and the registration request timestamp, instead of the UE identity and SQN _MS And in step 5 home UDM370 performs a SUCI replay attack detection procedure based on the registration request timestamp instead of the authentication sequence number.

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

1. During the primary authentication procedure, the UE310 (e.g., USIM) combines SUPI and 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 may be constructed to include an encrypted combination of SUPI and MESSAGE _ TIME. The "SUPI type" field of the SUCI structure (402 of fig. 4) may be set to indicate that the SUCI structure contains a hidden combination of SUPI and MESSAGE _ TIME. For example, a value of "4" may be set in the "SUPI type" field of the SUCI structure.

The UE may use the SUCI containing the hidden MESSAGE _ TIME in the registration request MESSAGE sent from the UE310 to the serving AMF/SEAF 330.

3. Upon receiving the registration request message from the UE310, the serving AMF/SEAF330 may invoke an AUSF service (denoted as a Nausf-UE authentication service) by sending an AUSF service request message (denoted as a Nausf-UE authentication-authentication request message) to the AUSF 360 whenever the AMF/SEAF330 wishes to initiate authentication. For example, the Nausf UEAuthentication authentication request MESSAGE may contain the SUCI with the hidden SUPI and MESSAGE TIME embedded and the service network name.

4. Upon receiving the Nausf-UEAuthentication-authentication request message, the home AUSF 360 may check whether the requesting AMF/SEAF330 in the serving network has the right to use the serving network name contained in the Nausf-UEAuthentication-authentication request by comparing the received serving network name with the expected serving 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 UE310 in a response message denoted as a Nausf UE authentication response, indicating that the serving network is not authorized. If the serving network is authorized to use the received serving network name, a UDM authentication request message, denoted as a numm UEAuthentication Get request, may be sent from the home AUSF 360 to the home UDM/ARPF 370. The Nudm _ UEAutomation _ Get request sent from AUSF 360 to UDM370 may include the following information:

-SUPI comprising hidden SUPI and MESSAGE _ TIME; and

-a service network name.

5. Upon receiving the Nudm _ UEAutomation _ Get request from home AUSF 360, home UDM370 may invoke SIDF, which, if the SUPI type is SUPI combined with MESSAGE _ TIME, may un-hide the received SUCI to obtain SUPI and MESSAGE _ TIME before home UDM370 may process the request. For SUCI replay attack detection from the network side in step 5, home UDM370 may compare the received MESSAGE _ TIME with the current UTC-based TIME and make the following exemplary determination:

home UDM370 may respond with a fault code or discard and stop processing the MESSAGE if the received MESSAGE _ TIME is less than the current UTC-based TIME minus a predetermined maximum DELAY TIME (denoted MAX DELAY). MAX DELAY denotes, for example, a maximum transmission time threshold. For example, MAX DELAY may be predetermined based on an estimated data transmission speed between the UE310 and the UDM370. The MAX DELAY may be further adjusted as needed.

If the received MESSAGE TIME is greater than or equal to the current UTC-based TIME minus MAX DELAY, and less than the current UTC-based TIME, home UDM370 may be configured to select the SUPI-based authentication method, generate AV, and continue with the remaining authentication steps of fig. 12.

The remaining steps in logic and data flow 1200 of fig. 12, other than steps 1-5, essentially perform an authentication process that reflects the corresponding steps in logic and data flow 500 of fig. 5, except that the UE-side SQN may not need to be involved in step 11 _MS Updates and SQN relating to the network side may be required in step 18 _MS And (4) updating. These steps are summarized in fig. 12 and explained above in connection with fig. 5, and are not described again here.

Similarly, fig. 13 shows a logic and data flow 1300 for a registration/authentication procedure initiated by the UE310 using a network-allocated temporary identifier, e.g., a GUTI obtained via a previous registration and authentication procedure (e.g., from step 21 in the SUCI registration procedure shown in fig. 12). The steps of FIG. 13 are similar to the diagramStep 7 except that steps 1-5 use hidden timestamps instead of SQN _MS (as described in steps 1-5 of fig. 12), step 5 includes a process for detecting SUCI replay attacks, similar to step 5 in the logic and data flow 1200 shown in fig. 12 and described in detail above, and in step 11, there may not be a need to refer to the SQN on the UE side _MS Updated, and in step 18, the SQN, which does not involve the network side, may not be required _MS And (6) updating. Thus, the steps summarized in FIG. 13 are not repeated here.

Hidden SQN _MS And hidden registration request message timestamp

In some other embodiments, the SQN may be used simultaneously _MS And a registration message timestamp. In other words, SQN _MS And the registration message timestamp can both be combined with SUPI and hidden to generate SUCI for registration and authentication. Thus, the various logical data flows of fig. 5, 7, 9, 10, and 11 may be combined with the logical and data flows of fig. 12 and 13 to form other logical and data flows. For example, SQN _MS And the registration message timestamp can be transmitted to the storage SQN _MS And both the sequence number and the timestamp can be used to detect and respond to sui replay attacks.

The foregoing drawings and description provide specific exemplary embodiments and implementations. The described subject matter may, however, be embodied in many different forms and, thus, it is intended that the covered or claimed subject matter be construed as not limited to any exemplary embodiment set forth herein. It is intended to provide a reasonably broad scope for the claimed or covered subject matter. Further, for example, the subject matter may be embodied as methods, apparatuses, components, systems, or non-transitory computer readable media for storing computer code. Thus, embodiments may take the form of hardware, software, firmware, storage media, or any combination thereof, for example. For example, the above-described method embodiments 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 meanings implied or implied by subtle differences in context other than the meanings explicitly stated. 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, the claimed subject matter is intended to include, in whole or in part, combinations of the exemplary embodiments.

In general, terms may be understood at least in part from the context in which they are used. For example, the terms "and," "or," "and/or" as used herein may include a variety of meanings that may depend at least in part on the context in which the terms are used. Generally, "or" (if used to associate a list, e.g., A, B or C) is intended to mean: A. b and C, as used herein for the inclusive sense; and A, B or C, used herein in the exclusive sense. Furthermore, the term "one or more" as used herein may be used, at least in part, depending on the context, to describe any feature, structure, or characteristic in the singular or may be used to describe a combination of features, structures, or characteristics in the plural. Similarly, the terms "a" and "an" or "the" may be understood to convey a singular use or a plural use, depending, at least in part, on the context. Moreover, the term "based on" may be understood as not necessarily intended to convey an exclusive set of factors, but may allow for the presence of additional factors not necessarily expressly described, again 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 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, 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 embodiments of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the embodiments of the invention 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 invention.

Claims (20)

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

receiving an authentication message initiated by 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 in dependence on a determination of whether a previous sequence number of the second network element was stored in the first network element during a previous authentication procedure of the second network element;

upon determining that the previous sequence number is stored in the first network element, further processing the authentication process according to a comparison between the de-concealed sequence number and the previous sequence number.

2. The method of claim 1, wherein processing the authentication procedure according to the determination comprises:

when the first network element determines that a previous sequence number of the second network element was not stored in the first network element during any previous authentication procedure of the second network element:

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

generating a new serial number;

an authentication vector is generated based on the new sequence number.

3. The method of claim 2, further comprising: sending the authentication vector to the first network element.

4. The method of claim 2, further comprising:

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

discarding the authentication vector and regenerating another sequence number and another authentication vector when the new sequence number is less than or equal to the de-concealed sequence number.

5. The method of claim 1, wherein processing the authentication procedure according to the determination comprises:

when the first network element determines that the previous sequence number was stored in the first network element during the previous authentication procedure, performing a comparison between the previous sequence number and the de-concealed sequence number to obtain a comparison result.

6. The method of claim 5, wherein further processing the authentication process based on the comparison between the de-concealed sequence number and the previous sequence number comprises: discarding the authentication message when the comparison result indicates that the de-concealed sequence number is less than or equal to the previous sequence number.

7. The method of claim 5, wherein further processing the authentication procedure based on the comparison between the de-concealed sequence number and the previous sequence number comprises: generating a response message containing a fault code when the comparison result indicates that the de-concealed sequence number is less than or equal to the previous sequence number.

8. The method of claim 5, wherein further processing the authentication process based on the comparison between the de-concealed sequence number and the previous sequence number comprises: when the comparison result indicates that the de-concealed sequence number is greater than the previous sequence number:

generating a new serial number;

an authentication vector is generated based on the new sequence number.

9. The method of claim 8, further comprising:

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

discarding the authentication vector and regenerating another sequence number and another authentication vector when the new sequence number is less than or equal to the de-concealed sequence number.

10. The method of claim 5, wherein unhiding the authentication message to obtain an unhidden sequence number and an unhidden subscription identifier comprises:

retrieving a hidden identity of the second network element from the authentication message;

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

determining that the type indicator indicates that the type of the hidden identity comprises a composite data item, the composite data item comprising a hidden subscription identifier and a hidden serial number;

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

obtaining a de-concealed subscription identifier and a de-concealed sequence number from the decrypted composite data item.

11. The method of claim 10, wherein the decrypted composite data item further comprises: a de-hidden subscription identifier concatenated with the de-hidden sequence number.

12. The method of claim 10, when the type indicator indicates that the type of the hidden identity comprises a composite data item, the type indicator comprises a unique value to indicate that the hidden identity comprises a hidden combination of a subscription identifier and a sequence number.

13. The method of claim 10, wherein the decrypted composite data item further comprises: a de-concealed subscription identifier interleaved with a de-concealed sequence number.

14. The method of claim 10, wherein the composite data item is decrypted using an Elliptic Curve Integrated Encryption Scheme (ECIES) scheme to obtain a de-concealed subscription identifier and a de-concealed serial number.

15. The method according to claim 10, wherein the hidden identity is encapsulated in a subscription hidden identifier SUCI.

16. The method of claim 10, wherein the de-hidden subscription identifier comprises: subscription permanent identifier SUPI.

17. The method of claim 1, wherein the first network element comprises a User Equipment (UE) and the second network element comprises at least one of a Unified Data Management (UDM) or an authentication credential repository and a processing function (ARPF) of the communication network.

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

a registration request message initiated by the first network element;

the first network element responds to an identity response message of an identity request from the communication network.

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

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

Images