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

Abstract

The present disclosure relates generally to registration and authentication procedures between a wireless terminal and a core network, and in particular, to protecting an authentication sequence number of a wireless terminal from leakage when the authentication sequence number of the wireless terminal is transmitted via a wireless communication interface during the registration and authentication procedures. In particular, an incremented authentication sequence number is maintained by the wireless terminal and used in synchronization (under normal network operation) with another authentication sequence number maintained by the network side to track registration and authentication activities of the terminal device and to help detect some type of malicious attack (e.g., registration replay) on the wireless terminal via the wireless communication interface. The terminal side sequence number is transmitted to the network by a hiding mechanism similar to that of the permanent user identity of the wireless terminal to reduce its exposure to the wireless interface, and the authentication sequence number of the wireless terminal is synchronized with the network side authentication sequence number by tracking and updating the terminal side and network side sequence numbers upon successful authentication or re-authentication.

Description

Method for preventing leakage of authentication serial number of mobile terminal

Technical Field

The present disclosure relates generally to registration and authentication procedures between a mobile terminal and a core network, and in particular to techniques to prevent leakage of authentication sequence numbers.

Background

The wireless terminal device may communicate with its home core network via a serving network. The wireless terminal may initiate registration and authentication procedures prior to accessing 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. Upon successful registration and authentication, access credentials are generated to enable further communication between the wireless terminal and the network. Communication messages (whether encrypted or unencrypted) transmitted between the UE and the network via the wireless interface may be hacked. 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 protecting an authentication sequence number of a wireless terminal from leakage when the authentication sequence number of the wireless terminal is transmitted via a wireless communication interface during the registration and authentication procedures. In particular, an incremented authentication sequence number is maintained by the wireless terminal and used in synchronization (under normal network operation) with another authentication sequence number maintained by the network side to track registration and authentication activities of the terminal device and to help detect some type of malicious attack (e.g., registration replay) on the wireless terminal via the wireless communication interface. The terminal side sequence number is transmitted to the network by a hiding mechanism similar to that of the permanent user identity of the wireless terminal to reduce its exposure to the wireless interface, and the authentication sequence number of the wireless terminal is synchronized with the network side authentication sequence number by tracking and updating the terminal side and network side sequence numbers upon successful authentication or re-authentication.

In some example implementations, a method performed by a first network element of a communication network for authenticating a second network element to access the communication network is disclosed. The method may include: receiving an authentication message initiated from the second network element; the authentication message is unhidden to obtain a unhidden sequence number maintained by the first network element and a unhidden user identity of the second network element; storing the unhidden sequence number in the first network element; generating a new sequence number and generating an authentication vector based on the new sequence number; transmitting the authentication vector to the second network element; and replacing the unhidden sequence number stored in the first network element with the new sequence number when an authentication response message to the authentication vector is received from the second network element.

In some other implementations, another method performed by a first network element of a communication network for authenticating a second network element to access the communication network is disclosed. The method may include: receiving an authentication message initiated from the second network element, wherein the authentication message contains a unhidden user identifier of the second network element; generating a new sequence number and generating an authentication vector based on the new sequence number; transmitting the authentication vector to the second network element; and when an authentication response message to the authentication vector is received from the second network element, replacing the previously stored sequence number associated with the first network element with the new sequence number.

In some other implementations, a network device 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 the above-described methods performed by the first network element.

In yet other implementations, 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 the above-described method.

Other aspects and alternatives to the above embodiments and implementations thereof are explained in more detail in the following drawings, 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 of a user hidden identifier for network registration and authentication of a wireless terminal.

Fig. 5 illustrates exemplary data and logic flows for primary network registration/authentication between a wireless terminal (User Equipment (UE)) and a core network based on a User hidden identity and a hidden authentication sequence number of the wireless terminal.

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

Fig. 7 illustrates exemplary data and logic flows 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 of a wireless terminal that cannot be authenticated.

Fig. 8 illustrates an exemplary data and logic flow for registration/authentication between a wireless terminal (User Equipment (UE)) and a core network based on a successfully authenticated network assigned temporary identity and authentication sequence number of the wireless terminal.

Fig. 9 illustrates exemplary data and logic flows for primary network registration/authentication between a wireless terminal (User Equipment (UE)) and a core network based on a User hidden identification of the wireless terminal and a hidden authentication sequence number upon detection of an authentication sequence number desynchronization from the network side.

Fig. 10 shows exemplary 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 a network of a wireless terminal that cannot be authenticated and an authentication sequence number when an authentication sequence number is detected out of sync from a network side.

Fig. 11 illustrates exemplary data and logic flows for registration/authentication between a wireless terminal (User Equipment (UE)) and a core network based on a successfully authenticated network assigned temporary identity of the wireless terminal and an authentication sequence number upon detection of an authentication sequence number desynchronization from the network side.

Fig. 12 illustrates exemplary data and logic flow for primary network registration/authentication between a wireless terminal (User Equipment (UE)) and a core network based on a User hidden identification and hidden timestamp of a corresponding registration message upon detection of a registration replay attack from the network side via the registration message timestamp.

Fig. 13 illustrates exemplary data and logic flows for registration/authentication between a wireless terminal (User Equipment (UE)) and a core network based on a network-assigned temporary identity of an unverifiable wireless terminal and a hidden timestamp of a corresponding registration message upon detection of a registration replay attack from the network side via the registration message timestamp.

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 transfer 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 application 140, or between terminal devices 110 and 112 and other data network 150. After an authentication procedure described in further detail below, a communication session and corresponding data path may be established and 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 configured to control communication sessions and perform network access management and data traffic routing. Service application 140 may be hosted by various application servers accessible to 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, terminal devices 110 and 112 may access other data network 150 through core network 130, and the other data networks may appear as data destinations or data sources for particular communication sessions instantiated in carrier network 102.

The core network 130 of fig. 1 may include various network nodes or functions that are geographically distributed and interconnected to provide network coverage of the service area of the carrier network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions 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 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 shown 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, for example, 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 implementations described above in fig. 1 and 2 may be applied to 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 the wireless communication Network 300 may include a wireless terminal or User Equipment (UE) 310 (serving as the terminal device 110 of fig. 2), a wireless access Network (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 and mobility management function (Access and Mobility Management Function, AMF) 330 (serving as the AMNN 230 of fig. 2), a session management function (Session Management Function, SMF) 340 (serving as the SMNN 240 of fig. 2), an application function (Application Function, AF) 390 (serving as the adnn 210 of fig. 2), a User plane management function (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 (Authentication Server Function, AUSF) 360 (serving as the AUNN 260 of fig. 2), and a unified Data management/authentication credential repository and processing function (Unified Data Management/Authentication Credential Repository and Processing Function, m/ARPF) 370 (serving as the mnn 270 of fig. 2). Furthermore, while only a single instance of some network functions or nodes of the wireless communication network 300 (and particularly 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 computer, a tablet, an Internet of Things (IoT) device, a distributed sensor network node, a wearable device, and the like. The UE 310 may include a Mobile Station (ME) and a subscriber identity module (Subscriber Identity Module, SIM). The SIM module may be implemented, for example, in the form of a universal wireless communication system subscriber identity module (Universal Mobile Telecommunication System 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 ME in the UE. For example, RAN 320 may include a plurality of radio base stations distributed in 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 indicated at 311 in fig. 3.

Continuing with FIG. 3, UDM 370 may constitute a persistent store or database for user contracts and subscription profiles and data. The UDM may also include an authentication credential repository and processing function (ARPF, as shown in 370 of fig. 3) for storing long-term security credentials for user authentication, and for performing the computation 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 third party.

The AMF/SEAF 330 may communicate with the RAN320, SMF 340, AUSF 360, UDM/ARPF 370 and PCF 322 via communication interfaces indicated by the various solid lines connecting the network nodes or functions. The AMF/SEAF 330 may be responsible for UE-to-Non-Access Stratum (NAS) signaling management and for provisioning registration and Access of the UE 310 to the core network 130, as well as for allocation of the SMF 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 security anchor function (Security Anchor Function, SEAF, as shown in 330 of fig. 3) that interacts with the AUSF 360 and the UE 310 for user authentication and management of various levels of encryption/decryption keys, as described in more detail below. The AUSF 360 may terminate the user registration/authentication/key generation request from the AMF/SEAF 330 and interact with the UDM/ARPF 370 to complete such user registration/authentication/key generation.

The SMF 340 may be allocated by the AMF/SEAF 330 for a particular communication session instantiated in the wireless communication network 300. The SMF 340 may be responsible for assigning UPFs 350 to support communication sessions in the user data plane and data flows therein, and for provisioning/regulating the assigned UPFs 350 (e.g., for formulating packet detection and forwarding rules for the assigned UPFs 350). Instead of being assigned by the SMF 340, the UPF 350 may be assigned by the AMF/SEAF 330 for a particular communication session and data flow. The UPFs 350 allocated and provisioned 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 provisioned by AF 390 via network exposure functions (not shown in fig. 3, but shown in fig. 7 described below) provided, for example, by 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 associated with service application 140 via communication interface 313.

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 SMF 340 for a communication session in accordance with policies and rules associated with UE 310 and obtained from PCF 322. Likewise, SMF 340 may allocate 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., 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 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 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 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/operation 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 include the UE 310 communicating with its home UDM/ARPF 370 via the serving RAN 320, the serving AMF/SEAF 330, the home AUSF360, 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 also verifies whether the UE 310 is authorized to access the network. Upon successful authentication between the UE 310 and the core network 300, the UE 310 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 harm to an attacker from the user identity, location and content of the communication. Authentication may be initiated by the UE 310 sending a registration request to the serving AMF/SEAF 330, the registration request containing its hidden or encrypted unique permanent identity, e.g., user hidden identity (Subscriber Concealed Identity, sui). Also, upon successful registration, a temporary user identity, such as a globally unique temporary user identity (Global Unique Temporary Identity, GUTI), may be assigned by the AMF/SEAF 330 to the UE 310 for further access to the network.

The identity, location or communication content of the user may be compromised due to external attacks via the wireless interface. Examples of attacks include, but are not limited to, a linkable-of-Service (DoS) attack and a Denial of Service (dbs) attack. For example, a sui intercepted by an attacker via a wireless interface may be used for 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 UE a has used over the wireless 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, for example by destroying GUTI when sent by UE a, which is likely to result in sui request by AMF/SEAF 330 and sui transmission from UE in response. When a later UE B issues a registration request to a false base station operated as a relay by the same attacker, the attacker can modify the registration request of UE B by exchanging its sui or GUTI with the sui previously captured by UE a 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, possibly tracking this UE. For example, then, the attacker observes by monitoring the wireless interface whether a successful authentication and key agreement (Authentication and Key Agreement, AKA) run is performed and whether the network accepts the registration request, and if so, UE a and UE B will be 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, since an attacker can detect whether AKA operation was successful from various subsequent messages intercepted in the wireless interface without knowing the content of the AKA response. In the case where the content of the AKA response is not hidden, an attacker can directly use such content to determine whether the attacked UE is present in the vicinity of the pseudo base station.

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

For another example, the network may be subject to DoS attacks by an attacker through replay of the sui. In particular, an attacker may replay the sui to cause the network and/or UE to perform frequent and repeated procedures (e.g., the sui de-hiding procedure and the authentication procedure). This may particularly occur when the de-hiding 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 is one that the UE previously sent to the network.

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 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 delay responses to legitimate registration requests and other types of requests.

Hidden authentication sequence number

In some implementations, to combat the above-described 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) andSQN _HE (on the carrier network side). For example, SQN _HE May be maintained in a Home Environment (HE) by the UDM/ARPF 370. Only these sequence numbers are 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 desynchronization by the UE 310 or network may indicate potential attacks and other problems.

In some implementations of sequence number synchronization, the SQN maintained by the UE 310 _MS May be transmitted to the carrier network during some authentication procedures. Also, the SQN maintained by the UDM/ARPF _HE May also be transmitted to the UE. However, in order to protect these serial numbers from leakage, their transmission may be minimized, and when transmission is necessary, may be transmitted in encrypted form that is considered secure. In one exemplary implementation, described in more detail below, during the authentication process, the SQN _MS May be transmitted along with and in the same manner as the transmission of the user permanent identity (Subscription Permanent Identifier, SUPI) from the UE 310 to the AMF/SEAF330 of the serving network. Furthermore, SQN from UDM/ARPF side _HE Embedded and encrypted in the authentication vector and thereby transmitted to the UE, as described in further detail below.

In particular, the SQN may be protected by being sent to the AMF/SEAF330 via a wireless interface after encryption based on, for example, elliptic curve integrated encryption scheme (Elliptical Curve Integrated Encryption Scheme, ECIES) _MS . In other words, the use of ECIES for hiding SUPI during the authentication procedure can be extended to accommodate SQN _MS And SUPI. In some implementations, SUPI may be associated with SQN _MS Combine and act as a plain text block for symmetric encryption under ECIES. SQN (SQN) _MS And SUPI may be in the form of concatenation, interleaving, etc. For example, in the case of an international mobile subscriber identity (International Mobile Subscriber Identity, IMSI) instead of SUPI for authentication, a mobile subscriber identity 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 conceal SUPI (or MSIN) and SQN in the home network _MS 。

Hidden registration time stamp

In some other implementations to combat the foregoing sui replay attacks, the UE 310 may transmit a timestamp with the sui to the network in a registration or authentication request message. The network may rely on such a timestamp to detect the sui replay attack. Similar to the authentication sequence number described above, a timestamp may be combined with the SUPI, and then the ECIES encryption is performed on the combination. The combination of SUPI and timestamp 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, the SUPI, sequence number, and/or timestamp may be combined (e.g., concatenated or interleaved) and subsequently encrypted using the ECIES scheme.

SUCI data structure

SUPI (or MSIN) and SQN _MS And/or the hidden concatenation of timestamps may be sent 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. 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 (Global Line Identifier, GLI)

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

-4: SUPI and SQN _MS And/or message timestamp combinations (e.g., concatenated)

-5 to 7: reserved values of other indicators.

SUPI type values and type pairs listed aboveThe relationship is for illustration purposes only. Other correspondence may be used. For example, other values including reserved values may be used to indicate hiding and SQN _MS And/or a SUPI of registration message timestamp combinations. Other fields of the sui 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 the use of inclusion SQN _MS The exemplary data and logic flow 500 for 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, assuming successful authentication between the UE 310 and the network. 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 combine the SUPI of the UE 310 and the current SQN maintained by the USIM or ME via, for example, concatenation or interleaving _MS . SUPI and SQN _MS The combined (e.g., concatenated or interleaved) plain text blocks of (i) may be encrypted in USIM or ME using the ECIES method. 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, a value of "4" may be set in the "SUPI type" field of the sui structure.

The UE may use the hidden SQN contained in the registration request message sent from UE 310 to serving AMF/SEAF 330 _MS Is described in detail below).

3. Upon receiving the registration request message from the UE 310, whenever the serving AMF/SEAF 330 wishes to initiate authentication, the serving AMF/SEAF 330 may invoke an AUSF service (denoted as a ausf_ueauthentication service) by sending an AUSF service request message (denoted as a ausf_ueauthentication_request message) to the home AUSF 360. For example, the Nausf_UEAuthority_Authority request message may contain embedded hidden SUPI and SQN _MS SUCI and services of (C)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 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 in a response message denoted as a nausf_ueauthentication_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 Nudm_UEauthentication_get request, may be sent from the home AUSF 360 to the home UDM/ARPF 370. The nudm_ueauthentication_get request may contain the following information:

-comprising hidden SUPI and SQN _MS SUPI of (C); and

-a service network name.

5. Upon receiving the nudm_ueauthentication_get request, if the home UDM/ARPF 370 determines from the SUPI type field of the received SUPI data structure that the SUPI type is the same as the SQN _MS The UDM/ARPF370 may invoke the subscriber identity unhidden function (De-concealment Function, SIDF) by the combined SUPI. Thus, before the UDM 370 is able to handle the request, the SIDF may un-conceal the received SUCI to obtain SUPI and SQN _MS . Based on the SUPI, the UDM/ARPF370 may perform its authentication procedure. De-hidden 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 also generate a new SQN _HE Which is larger than the current SQN maintained by the UDM _HE . Then, the current SQN _HE Updated SQN _HE And (5) replacing. SQN based also on updates _HE And other information, generates an authentication vector (the components of the authentication vector are in step 6 below).

6. For each nudm_authentication_get request, the UDM/ARPF370 may create a Home environment authentication vector (HomeEnvironment Authentication Vector, HE AV). More specifically, the UDM/ARPF370 does this by generating an Authentication Vector (AV), and the authentication management field (Authentication Management Field, AMF) separation bit is set to "1". The UDM/ARPF370 may then derive the AUSF key K _AUSF And eXpected RESponse, denoted by XRES, was calculated. Finally, UDM/ARPF370 may rely on the random number represented by RAND, the authentication key represented by AUTN, XRES and K _AUSF To create the HE AV. For example, AUTN contains SQN _HE Is a piece of information of (a). The UDM/ARPF370 may then return HE AV to the AUSF 360 along with an indication that HE AV will be used for AKA in a response to the AUSF 360, represented by the nudm_ueauthentication_get response. The UDM/ARPF370 may include the unhidden SUPI in the nudm_ueauthentication_get response.

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

8. The AUSF 360 may then generate AV based on HE AV received from the UDM/ARPF370 by: calculate a hashed XRES represented by HXRES from XRES and from K _AUSF Is composed of K _SEAF Indicated SEAF key and replacing XRES with HXRES and K in HE AV _SEAF Replacement K _AUSF 。

Ausf 360 may then remove K _SEAF And returns a service context authentication vector (including RAND, AUTN, and HXRES) denoted as SE AV to SEAF 330 in a response message denoted as a 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 that the UE and AMF will use to identify K _AMF And a partial local security context created in case of successful authentication. 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) can verify the freshness of the AV by checking whether AUTN can be accepted. For example, the UE may extract the SQN contained in the AUTN _HE And with local SQN _MS Ratio of progressCompared with the prior art. 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 sequence number synchronization is confirmed, the USIM can calculate a response indicated by RES. The USIM may return RES, CK, IK to the ME. If the USIM calculates Kc (i.e. GPRS Kc) based on CK and IK using transfer function c3 and sends it to the ME, the ME may ignore this GPRS Kc and not store it on the USIM or in the ME. ME may then calculate RES based on RES. ME may calculate K based on CK IK _AUSF . The ME may be based on K _AUSF Calculation of K _SEAF . The ME of the access network may check during authentication whether the "split bit" in the AMF field of the AUTN is set to 1. The "separation bit" is the 0 th bit of the AMF field of the AUTN. Once the SQN is determined _MS And SQN _HE Sequence number synchronization between them, the UE uses the extracted SQN _HE To update (or replace) its SQN _MS For future synchronization purposes.

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

SEAF 330 may then calculate HRES based on RES and SEAF 330 may compare HRES to HXRES. If so, the SEAF 330 may consider the authentication of the UE 310 successful from the serving network's perspective. When authentication is successful, the remaining steps of fig. 5 below are followed. If unsuccessful, 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 contacted (e.g., no response is obtained from the UE) and the SEAF 330 never receives RES, the SEAF may consider authentication to be failed and indicate failure to the 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_ue authentication_authentication request message including RES is received by AUSF 360 as authentication confirmation, it may be verified whether AV has expired. If AV is alreadyUpon expiration, the AUSF 360 may consider the authentication of the UE 310 to be unsuccessful from the perspective of the home network. After successful authentication, AUSF 360 may store K _AUSF . AUSF 360 may compare the received RES with the stored XRES. If RES and XRES are equal, AUSF 360 may consider the authentication of UE 310 to be successful from the perspective of the home network and follow the 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 authentication failure by, for example, sending a response message with a failure code and/or dropping/stopping/exiting the authentication.

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

Ausf 360 may notify UDM 370 of the result and time of the authentication procedure with UE 310 using a request message denoted nudm_ue authentication_resultconfirmation request. 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_ueauthentication_resultconfirmation response.

20. Upon receiving a subsequent UE-related procedure (e.g., nudm_uecm_registration_request from AMF 330), UDM 370 may apply actions according to the home operator's policy to detect and implement protection against certain types of fraud.

21. Finally, AMF 330 assigns a GUTI to UE 310 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 UDM 370 in a tandem manner. Similar to step 18 above, the udm 370 may still store the authentication state and use the current SQN _HE Updating stored SQNs _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 At this time, the UE 310 may determine that sequence number synchronization fails. Fig. 6 illustrates 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 UE 310 may not calculate the embedded SQN _MS For transmission to the AMF 330 of any authentication failure information (e.g., AUTS) to avoid SQN _MS Another exposure in the wireless interface. In contrast, the UE 310 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 UE 310 and the network are subject to a sui replay attack. As an example of RA1, the UE 310 may respond to NAS message authentication failure with only a cause value indicating the cause of the failure as SQN failure/mismatch, without calculating an aus and without sharing the aus with the network.

In RA2, SEAF 330 may send a request message, denoted as a naf_authentication_authentication request message, to AUSF360 upon receiving an authentication failure message from UE 310.

In RA3, upon receiving the Nausf_UEauthentication_authentication request message from AMF 330, AUSF360 sends a request message, denoted as Nudm_UEauthentication_get request message, to UDM/ARPF 370.

In RA4, when the UDM/ARPF 370 receives a Nudm_UEauthentication_get request message from the AUSF360, the ARPF 370 may be mapped to the HE/AuC. The UDM/ARPF 370 may send a response message represented by the nudm_ueauthentication_get response message for use by using a message stored in the UDM 370 SQN _MS (e.g., in steps 5 or 18 of FIG. 5) rather than updated SQNs _HE And (5) re-authenticating the UE by using the new authentication vector. The AUSF 360 follows the principle of steps 6-11 of fig. 5 to run a new authentication procedure with the UE 310.

GUTI identity verification with SUPI failure

Fig. 7 illustrates logic and data flow 700 for a registration/authentication procedure initiated by UE 310 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 sui registration procedure illustrated in fig. 5). Steps 0-2 in fig. 7 are described below.

Ue 310 may initiate the 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/SEAF702, e.g., identified in the registration message, and if the serving AMF/SEAF 330 fails to obtain the UE context from the old AMF/SEAF702 (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 receiving the identity request message, the UE 310 may send an identity response message to the AMF/SEAF 330, wherein the sui embeds the current SQN _MS (step 2c of fig. 7).

The remaining steps 3-21 in the logic and data flow 700 essentially use the sui to perform an authentication process and correspond to steps 3-21 in the logic and data flow 500 of fig. 5. These steps are illustrated in fig. 7 and explained above with respect to fig. 5 and are not repeated here.

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

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

GUTI authentication to successfully acquire SUPI

Fig. 8 illustrates logic and data flow 800 for a registration/authentication procedure initiated by a UE 310 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 sui registration procedure illustrated in fig. 5 or fig. 7), wherein the serving network successfully identified the sui of the UE. The logic and data flow 800 of FIG. 8 is similar to the logic and data flow 500 of FIG. 5, except for steps 0-5, which will be described in more detail below.

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

Ue 310 may initiate a registration procedure with the GUTI.

Ue 310 may use the GUTI in the registration request message instead of the sui 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. The AMF/SEAF 330 of the service may invoke the AUSF authentication service by sending a Nausf_UEauthentication_authentication request message to the AUSF360 whenever the AMF/SEAF 330 of the service wishes to initiate authentication. The Nausf_UEAuthority_Authority request message may contain SUPI and a service network name.

4. Upon receipt of the Nausf_UEAuthentication_Authentication request message, the home AUSF360 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 home AUSF360 may temporarily store the received service network name. If the serving network is not authorized to use the serving network name, home AUSF360 may respond by indicating that the serving network is not authorized in a response message represented by a nausf_ueauthentication_authentication response. The AUSF360 may then send a request message to the home UDM/ARPF 370, denoted as a nudm_ue authentication_get request. The nudm_ue authentication_get request may include the SUPI of the UE and the service network name.

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

The difference between the above-described steps of the logic and data flow 800 of fig. 8 and the corresponding steps in the logic and data flow 500 of fig. 5 is that the SUPI is transferred from the serving network to the home network instead of the sui during the authentication procedure. Thus, the SQN of the UE _MS Will not be sent to the home UDM/ARPF 370 and, as indicated in step 0 of fig. 8, the SQN previously stored at the home UDM _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 essentially perform an authentication process corresponding to 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 the SQN synchronization check fails at the UE in step 11 of fig. 8, 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 reauthentication logic and data flow 600, the new authentication vector generated by the home UDM 370 at step RA4 may be based on the previously stored SQN _MS . Any successful authentication (in 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), which is with the current SQN at step 18 of these logical and data flows _HE Replacing stored SQNs _MS Based on this, there is a lack of update in GUTI authentication steps 1-5 in the logical and data flow 800, so the SQN maintained at UDM 370 _MS Will not become unsynchronized.

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

Countering SUCI replay attacks by SQN

In some implementations, the SQN may be based on the UE-side sequence number _MS And HE side sequence number SQN _HE And detecting SUCI replay attack at the network side. Since the hidden permanent UE identity and hidden SQN are embedded in the transmission in steps 1-5 shown in fig. 5 and 7 _MS SUCI of (S), SQN _MS Becomes available to the network side.

Fig. 9 illustrates the use of a sui (e.g., SUPI) and SQN with hidden network identity by a UE 310 _MS The exemplary logic and data flow 900 of the initiated 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, if the SUPI type is the sum SQN _MS The combined SUPI, home UDM370 may invoke the SIDF, then the SIDF procedure may conceal the received SUPI before home UDM370 may process the request to obtain the SUPI and SQN associated with UE 310 _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 UDM370 makes the following exemplary determination procedure:

if the home UDM370 has not already had a locally stored SQN for the UE 310 _MS The SQN received through the sui may be stored _MS Authentication methods are further selected based on SUPI, and based on updated and added SQNs _HE An AV is generated.

-if home UDM370 have previously stored SQN for UE 310 _MS May be configured to receive the SQN _MS With previously stored SQNs _MS A comparison is made.

If the comparison shows that the 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.

However, if the comparison reveals a received SQN _MS SQN larger than store _MS The home UDM 370 may alternatively be configured to select a SUPI-based authentication method, generating an update and addition-based SQN _HE And continues the remaining authentication process in fig. 9.

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

The remaining steps in the logic and data flow 900 of fig. 9, except for step 5, essentially perform an authentication process that corresponds to 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, e.g., a GUTI obtained via a previous registration and authentication procedure (e.g., from 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 procedure 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 repeated here.

Further, fig. 11 illustrates a registration/authentication procedure initiated by the UE 310 using the network-assigned temporary identifier, e.g., via a prior registration and authentication procedure (e.g., from fig. 9 or 11Step 21) in the sui registration process of (c), 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, the UDM 370 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 The UDM 370 may discard the AV and SQN _HE And generates new AV and SQN _HE 。

Furthermore, if the SQN synchronization check fails at the UE in step 11 of fig. 9, 10 and 11, 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 reauthentication 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 by 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. Since the sui with the hidden UE identity and hidden timestamp embedded as described above is transmitted, the registration timestamp becomes available to the network side.

Fig. 12 illustrates exemplary logic and data flow 1200 for a registration/authentication procedure initiated by 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 home UDM 370 performs a sui replay attack detection procedure based on the registration request timestamp instead of the authentication sequence number.

Exemplary 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 and registration request or MESSAGE timestamp denoted message_time by concatenation, interleaving, or other combination. For example, message_time may represent 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, a value of "4" may be set in the "SUPI type" field of the sui structure.

The UE may use the sui containing the hidden message_time in a 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/SEAF 330 may invoke an AUSF service (denoted as a ausf_ueauthentication service) by sending an AUSF service request message (denoted as a ausf_ueauthentication_authentication request message) to the AUSF 360 whenever the AMF/SEAF 330 wishes to initiate authentication. For example, the Nausf_UEAuthority_Authority request MESSAGE may contain the SUCI embedded with hidden SUPI and MESSAGE_TIME and the 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 UE310 in a response message denoted as a nausf_ueauthentication_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 Nudm_UEauthentication_get request, may be sent from the home AUSF 360 to the home UDM/ARPF 370. The nudm_ueauthentication_get request sent from the AUSF 360 to the UDM 370 may include the following information:

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 conceal the received sui before the home UDM 370 may process the request to obtain the SUPI and message_time. 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 determination:

if the received MESSAGE TIME is less than the current UTC-based TIME minus a predetermined maximum DELAY TIME (denoted max_delay), the home UDM 370 may respond with a fault code or discard and stop processing the MESSAGE. Max_delay represents, for example, a maximum transmission time threshold. For example, max_delay may be predetermined 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 with 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 corresponding to 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 may not involve a SQN 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 illustrates logic and data flow 1300 of a registration/authentication procedure initiated by UE 310 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 sui registration procedure illustrated in fig. 12). The 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 steps forThe process of detecting a SUCI replay attack, similar to step 5 in logic and data flow 1200 shown in FIG. 12 and described in detail above, may not involve a SQN on the UE side in step 11 _MS Updating, and in step 18, there may be no need to involve SQN on the network side _MS Updating. Thus, the steps summarized in fig. 13 are not repeated here.

_MS Combination of hidden SQN and hidden registration request message timestamp

In some other implementations, the SQNs may be used simultaneously _MS And a registration message timestamp. In other words, SQN _MS And the registration message timestamp may be combined with the SUPI and hidden to generate the sui for registration and authentication. Thus, the various logic data flows in FIGS. 5, 7, 9, 10, and 11 may be combined with the logic and data flows in FIGS. 12 and 13 to form additional logic and data flows. For example, SQN _MS And registration message time stamps can both be transferred to the storage SQN _MS And both the sequence number and the timestamp can be used to detect and respond to the sui replay attack.

The above illustration and description provide specific exemplary embodiments and implementations. The described subject matter may, however, be embodied in various different forms and, thus, the covered or claimed subject matter is intended to be construed as not being limited to any of the example embodiments set forth herein. It is intended to provide a reasonably broad scope to the claimed or covered subject matter. Furthermore, for example, the subject matter may be embodied as methods, apparatus, components, systems, or non-transitory computer-readable media for storing computer code. Thus, embodiments may take the form of hardware, software, firmware, storage medium, 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 other than those specifically stated may be used in the context of a implied or implied nuance. Also, 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.

Generally, terms may be understood, at least in part, from the use of context. 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. In general, "or" (if used to associate a list, e.g., A, B or C) is intended to mean: A. b and C, as used herein, are defined as inclusive; and A, B or C, are 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 the singular sense, or may be used to describe a combination of features, structures, or characteristics in the plural sense. Similarly, the terms "a," "an," or "the" may be understood as conveying a singular usage or a plural usage, depending at least in part on the context. Furthermore, the term "based on" may be understood as not necessarily intended to convey an exclusive set of factors, but rather may allow for additional factors not necessarily explicitly 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 invention 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 aspects may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in view of the description herein, that the present aspects 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 approach.

Claims (20)

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

Receiving an authentication message initiated from the second network element;

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

storing the unhidden sequence number in the first network element;

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

transmitting the authentication vector to the second network element; and

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

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

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

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

and sending the reauthentication vector to the second network element.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

transmitting the authentication vector to the second network element; and

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

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

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

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

and sending the reauthentication vector to the second network element.

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

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

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

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

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