Mutual Authentication between User Equipment and Evolved Packet Core

Abstract

A user equipment (UE), an evolved Node B (eNB) in a wireless communication system, and a method of operating the same are provided. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: receiving, from an evolved Node B (eNB), a public land mobile network (PLMN) identifier for isolated evolved universal terrestrial radio access network (E-UTRAN) operation (IOPS) for public safety; and activating an IOPS universal subscriber identity module (USIM) application of the UE, wherein the IOPS USIM application uses a security certificate configured for IOPS, wherein the security certificate includes an international mobile subscriber identity (IMSI) for IOPS and an access class status 11 or 15, wherein the security certificate is a different set of security certificates for IOPS that is independent of the security certificate for normal operation, and wherein the normal operation includes non-IOPS mode operation based on a backhaul connection to an evolved packet core (EPC).

Description

[0001] This application is a divisional application of a patent application for "Mutual Authentication between User Equipment and Evolved Packet Core" with an application date (international application date) of January 11, 2016, an application number of 201680004082.4 (international application number PCT / KR2016 / 000231). Technical Field

[0002] The present disclosure generally relates to a wireless communication system, and more particularly, to an apparatus and method for mutual authentication between a user equipment (UE) and an evolved packet core (EPC). Background Art

[0003] The 3rd Generation Partnership Project (3GPP) has initiated work on isolated operation for public safety (IOPS) in the evolved universal terrestrial radio access network (E-UTRAN), with the goal of ensuring the ability of public safety users to communicate continuously in mission-critical situations. IOPS supports recoverable mission-critical network operations regardless of the existence of a connection (such as a backhaul link) between an evolved Node B (eNodeB) and the core network. From a security perspective for public safety use, the main requirements are access of public safety UEs to the isolated E-UTRAN and secure operation of the UEs in the isolated E-UTRAN operation mode.

[0004] In addition, it is difficult to provide authentication for UEs when the eNodeB loses its connection to the core network. When the eNodeB is not communicating with the core network (such as being disconnected), the home subscriber server (HSS) (authentication center (AuC)) is unavailable (or unreachable) to the eNodeB for passing access requests received from the UE to the core network and obtaining a security context for access control and secure communication. When the backhaul link to the core network is unavailable, a public safety eNodeB (local evolved packet core (EPC)) can operate autonomously or coordinate with other nearby eNodeBs to provide communication with local routing near public safety UEs in an area. The isolated E-UTRAN operation mode also provides the ability to create a service radio access network (RAN) without a backhaul link by deploying one or more separate stand-alone eNodeBs (NeNBs). From a security perspective, the isolated E-UTRAN operation mode may have two operation modes:

[0005] The signaling backhaul connection to the EPC is active. Thus, communication with the AuC or HSS is possible (mode 1); and

[0006] There is no signaling backhaul connection to the EPC; thus, communication with the AuC or HSS is not possible (mode 2).

[0007] In the case of Mode 1, normal 3GPP security operations are possible. Additionally, in the case of Mode 2, the isolated E-UTRAN must ensure that both user data and network signaling security are at a level comparable to that provided by Mode 1. Communication that occurs between the UE and the NeNB and communication between different NeNBs require the provision of security features. In conventional systems and methods, including a complete user database of potential users in the eNodeB for authentication and authorization is not a feasible solution. Additionally, there is a high security risk in the exposure of an eNodeB in a state where the subscription certificate has been cracked. In addition to security authentication, security operations (such as integrity protection, replay protection, confidentiality protection) are required to mitigate the distribution of unauthorized disaster information and the eavesdropping of communication between public safety UEs. Summary of the Invention

[0008] Technical Problem

[0009] Therefore, a simple and robust mechanism is needed to solve the above security problems when the eNodeB is not connected to the core network.

[0010] Solution

[0011] One aspect of the present disclosure is to provide an apparatus and method for authenticating the EPC for IOPS.

[0012] Another aspect of the present disclosure is to provide an apparatus and method for authentication between the UE and the local EPC.

[0013] Another aspect of the present disclosure is to provide an apparatus and method for receiving an IOPS Public Land Mobile Network (PLMN) identifier (ID) broadcast by the local EPC, where the IOPS PLMN ID indicates that the local EPC is in the IOPS mode.

[0014] Another aspect of the present disclosure is to provide an apparatus and method for activating a Universal Subscriber Identity Module (USIM) that supports the IOPS mode in the UE based on the IOPS PLMN ID received from the local EPC.

[0015] Another aspect of the present disclosure is to provide an apparatus and method for authenticating the local EPC in response to receiving the IOPS PLMN ID.

[0016] Another aspect of the present disclosure is to provide an apparatus and method for sending a first request message to the local EPC.

[0017] Another aspect of the present disclosure is to provide an apparatus and method for receiving a second request message including a flag from the local EPC in response to the first request message.

[0018] Another aspect of the present disclosure is to provide an apparatus and method for broadcasting an IOPS PLMN ID, where the IOPS PLMN ID indicates that the local EPC is in the IOPS mode.

[0019] Another aspect of the present disclosure is to provide an apparatus and method for receiving a first request message from a UE.

[0020] Another aspect of the present disclosure is to provide an apparatus and method for generating a flag in response to receiving the first request message.

[0021] Another aspect of the present disclosure is to provide an apparatus and method for sending a second request message including the generated flag to the UE to authenticate the local EPC.

[0022] According to one aspect of the present disclosure, a method for operating a user equipment enabling the operation of an isolated evolved universal mobile telecommunications system terrestrial radio access network (E-UTRAN) for public safety (IOPS) is provided. The method includes: receiving, from an eNodeB (eNB) having IOPS capabilities, a system information block (SIB) message including an IOPS public land mobile network (PLMN) identifier; activating a dedicated IOPS universal subscriber identity module (USIM) application based on the IOPS PLMN identifier; and authenticating the eNB having IOPS capabilities based on the dedicated IOPS USIM application.

[0023] According to another aspect of the present disclosure, a method for operating an eNB having IOPS capabilities is provided. The method includes: broadcasting an SIB message including the IOPS PLMN identifier; and authenticating an IOPS-enabled UE based on a dedicated IOPS USIM application, where the dedicated IOPS USIM application is activated by the UE based on the IOPS PLMN identifier.

[0024] According to another aspect of the present disclosure, an apparatus for an IOPS-enabled UE is provided. The apparatus includes: a controller, and at least one transceiver operably coupled to the controller, where the controller is configured to: receive, from an eNB having IOPS capabilities, an SIB message including the IOPS PLMN identifier; activate a dedicated IOPS USIM application based on the IOPS PLMN identifier; and authenticate the eNB having IOPS capabilities based on the dedicated IOPS PLMN application.

[0025] According to another aspect of the present disclosure, there is provided an apparatus for an eNB having IOPS capabilities. The apparatus includes: a controller, and at least one transceiver operatively coupled to the controller, wherein the controller is configured to: broadcast an SIB message including an IOPS PLMN identifier; and enable an IOPS-capable UE based on authentication of a dedicated IOPS USIM application, wherein the dedicated IOPS USIM application is activated by the UE based on the IOPS PLMN identifier.

[0026] Advantages of the Invention

[0027] Embodiments of the present disclosure can effectively maintain public safety in a wireless environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The above and other aspects, features, and advantages of certain embodiments of the present disclosure will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which:

[0029] Figure 1A and 1B is a block diagram of an authentication system between a UE and a local EPC according to an embodiment of the present disclosure;

[0030] Figure 2 is a block diagram of a UE for authenticating an eNodeB or a local EPC according to an embodiment of the present disclosure;

[0031] Figure 3 is a block diagram of an eNodeB or a local EPC for authenticating a UE according to an embodiment of the present disclosure;

[0032] Figure 4A is a flowchart of an authentication method between a UE and a local EPC according to an embodiment of the present disclosure;

[0033] Figure 4B is a flowchart of a method for authenticating an eNodeB or a local EPC according to an embodiment of the present disclosure;

[0034] Figure 5A is a flowchart of an authentication method between a UE and an eNodeB or a local EPC according to an embodiment of the present disclosure;

[0035] Figure 5B is a flowchart of a method for authenticating an eNodeB or a local EPC according to an embodiment of the present disclosure;

[0036] Figure 6 is a sequence diagram for performing authentication between a UE and an eNodeB or a local EPC according to an embodiment of the present disclosure;

[0037] Figure 7is a sequence diagram for performing mutual authentication between a UE and an eNodeB or a local EPC according to an embodiment of the present disclosure;

[0038] Figure 8A and 8B is a schematic diagram of a key derivation method according to an embodiment of the present disclosure;

[0039] Figure 9 is a sequence diagram for authenticating an eNodeB or a local EPC using an IOPS international mobile subscriber identity (IMSI) according to an embodiment of the present disclosure;

[0040] Figure 10 is a sequence diagram for authenticating an eNodeB or a local EPC using a system information block (SIB) message according to an embodiment of the present disclosure;

[0041] Figure 11 is a sequence diagram for authenticating an eNodeB or a local EPC by using an IMSI and an international mobile station equipment identity (IMEI) according to an embodiment of the present disclosure;

[0042] Figure 12 is a flowchart of a method for authenticating an eNodeB or a local EPC according to an embodiment of the present disclosure;

[0043] Figure 13 is for K ASME (K eNodeB ) a sequence diagram of identity-based encryption for an exchange message flow;

[0044] Figure 14 is a block diagram of a computing environment of a method and system for implementing authentication between a UE and a local EPC according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0045] The embodiments herein and details of their various features and advantages are described more fully below with reference to the non-limiting embodiments shown in the accompanying drawings and described in detail below. Descriptions of well-known components and processing techniques are omitted so as not to unnecessarily obscure the embodiments herein. In addition, the various embodiments described herein are not necessarily mutually exclusive, and some embodiments may be combined with one or more other embodiments to form new embodiments. Unless otherwise specified, the term "or" as used herein refers to a non-exclusive or. The examples used herein are only intended to facilitate understanding of the methods by which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Therefore, the examples should not be construed as limiting the scope of the present disclosure.

[0046] The present disclosure is described below with reference to the accompanying drawings, in which like reference numerals indicate corresponding elements.

[0047] Before describing the embodiments in detail, definitions of key terms used herein are provided. Unless otherwise defined, all terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. The following is a glossary of terms used in this disclosure:

[0048] eNodeB with isolated E-UTRAN IOPS capabilities: An eNodeB with the ability to operate in the IOPS mode, which provides local Internet Protocol (IP) connectivity and public safety services to one or more IOPS-enabled UEs through a local EPC when the eNodeB loses its backhaul to the Macro EPC or does not have a backhaul to the Macro EPC.

[0049] IOPS network: An IOPS network includes one or more eNodeBs operating in the IOPS mode and connected to a local EPC.

[0050] Local EPC: The local EPC is an entity that provides the functions utilized by an eNodeB in the IOPS operating mode instead of the Macro EPC to support public safety services. In addition, the local EPC can include a Mobility Management Entity (MME), a Serving Gateway / Packet Data Network Gateway (SGW / PGW), a Home Subscriber Server (HSS) function, or a combination thereof.

[0051] Macro EPC: The EPC that serves the eNodeB when not in the IOPS operating mode.

[0052] Standalone evolved packet system (EPS): A deployable system that can provide wireless access (through a deployable eNodeB with IOPS capabilities), local IP connectivity, and public safety services to IOPS-enabled UEs in the absence of a normal EPS.

[0053] IOPS-enabled UE: A UE configured to use a network operating in the IOPS mode. A UE is a combination of a Universal Integrated Circuit Card (UICC) and a Mobile Equipment (ME).

[0054] In an embodiment of the present disclosure, after losing backhaul communication, IOPS provides the ability to maintain a communication level for public safety users through an eNodeB with IOPS capabilities (or a set of connected eNodeBs with IOPS capabilities). The isolated E-UTRAN operation mode is also applicable to form a detached EPS deployment, i.e., the deployment of one or more independent eNBs with IOPS capabilities, creating a serving radio access network without backhaul communication and also providing local IP connectivity and services to public safety users in the absence of normal EPS architecture availability. 3GPP Technical Specification 22.346 lists the general requirements for the Long Term Evolution (LTE) network in IOPS. A description of the architectural concept of IOPS is given in the informative appendix K of 3GPP TS23.401. In addition, 3GPP TS23.401 provides security guidelines for operating a public safety network using the local EPC method in a scenario without a backhaul link to the Macro EPC. The local EPC method assumes that the IOPS network can include any one of the following:

[0055] A local EPC and a single isolated eNodeB with IOPS capabilities (or a deployable eNodeB with IOPS capabilities), which can be co-located or have connectivity to the local EPC; or

[0056] A local EPC and two or more eNodeBs with IOPS capabilities (or deployable eNodeBs with IOPS capabilities), which have connectivity to a single local EPC.

[0057] In addition, the local EPC includes the MME, SGW or PGW, HSS functionality, or a combination thereof. When the eNodeB is in the IOPS mode, the public safety network operator designates the PLMN identity of the IOPS operation mode for broadcasting in the SIB message through the eNodeB. Only authorized IOPS-enabled UEs can access the PLMN indicated as the IOPS PLMN.

[0058] Embodiments herein disclose a method for authentication between a UE and a local EPC. The method includes receiving an IOPS PLMN ID broadcast by the local EPC, where the IOPS PLMN ID indicates that the local EPC is in the IOPS mode. In addition, the method includes activating a USIM in the UE that supports the IOPS mode based on the IOPS PLMN ID received from the local EPC.

[0059] In one embodiment, the method includes sending a first request message to a local EPC. The first request message is an ATTACH request message. Additionally, the method includes receiving, after receiving the first request message, a second request message from the local EPC that includes a flag. In an embodiment of the present disclosure, the second request message is an AUTHENTICATION (AUTH) request message. Additionally, the method includes authenticating the local EPC based on the flag.

[0060] In one embodiment, authenticating the local EPC based on the flag includes generating a candidate flag. After generating the candidate flag, it is determined whether there is a match between the flag received from the local EPC and the candidate flag. Additionally, the local EPC is authenticated in response to determining a match between the flag and the candidate flag.

[0061] In one embodiment, authenticating the local EPC based on the flag includes extracting a key related to the local EPC by decrypting the flag and authenticating the local EPC based on the key.

[0062] In one embodiment, the method further includes sending response information including at least one parameter to the local EPC to authenticate the UE. Additionally, the method includes receiving an acceptance message from the local EPC.

[0063] In one embodiment, the flag is at least one of a random number (RAND) and an authentication token (AUTN) of an authentication and key agreement (AKA) procedure, a key encrypted using the public key of the UE, an IMSI, or a combination thereof.

[0064] In one embodiment, the ATTACH request message includes at least one of an access class, an IMSI, the capabilities of the UE, an IMEI, and a closed subscriber group (CSG) cell ID.

[0065] Embodiments herein disclose a method for authentication between a UE and a local EPC. The method includes broadcasting an IOPS PLMN ID by the local EPC, where the IOPS PLMN ID indicates that the local EPC is in the IOPS mode.

[0066] In one embodiment, the method includes receiving a first request message from the UE. Additionally, the method includes generating a flag in response to receiving the first request message. Additionally, the method includes sending a second request message including the generated flag to the UE to authenticate the local EPC.

[0067] In one embodiment, the method further includes receiving a response message including at least one parameter from the UE. Additionally, the method includes authenticating the UE based on the at least one parameter. Additionally, the method includes sending an acceptance message to the UE.

[0068] Unlike conventional systems and methods, the method of the present disclosure provides a method for access authentication for IOPS. In addition to normal subscription certificates, the apparatus of the present disclosure provides service or RAN certificates for access control (e.g., permit or prohibit) of IOPS operations between the UE and the eNodeB (or local EPC) based on dedicated unique subscription certificates. Further, the method of the present disclosure provides access class, IMEI, IMSI, or CSG ID specific certificates in addition to normal subscription certificates for access control (e.g., mutual authentication) when the eNodeB is detached from the core network (e.g., EPC).

[0069] Unlike conventional systems and methods, the apparatus of the present disclosure includes a function for generating an authentication vector (AV) in the eNodeB for IOPS access control and secure communication. Further, the apparatus of the present disclosure may provide an authentication and key agreement (AKA) procedure on radio resource control (RRC) signaling, where the AKA procedure is provided by a packet data convergence protocol (PDCP) entity or a new entity on top of PDCP. The AKA procedure may also provide access class control using authentication management field (AMF) bits.

[0070] Further, the apparatus of the present disclosure handles requirements such as secure storage and execution environment, mutual authentication between the UE and the isolated E-UTRAN, authorization (i.e., broadcast, multicast, and unicast), air protection (e.g., integrity, confidentiality, and replay protection), cryptographic independent keys for one-to-one communication, and authentic disaster-resistant information dissemination.

[0071] Now referring to the drawings, and more particularly, to Figures 1A to 14 , in which like reference characters throughout the drawings denote corresponding features, embodiments are illustrated by way of example.

[0072] Figure 1A is a block diagram of a system 100a for authentication between a UE and a local EPC according to an embodiment shown herein. The system 100a includes a UE 102, an eNodeB 104, a Macro EPC 106, and a local EPC 108. In one embodiment, the local EPC 108 may be located within the eNodeB 104.

[0073] Referring to Figure 1A , the UE 102 includes a UICC unit 102a (or may simply be referred to as a UICC or a subscriber identity module (SIM) card in the UE 102). In one embodiment, the local EPC 108 may include at least one of an MME, an SGW or a PGW, and an HHS function. The UE 102 may be a laptop computer, a desktop computer, a mobile phone, a mobile station, a mobile terminal, a smart phone, a personal digital assistant (PDA), a tablet computer, a phablet, or any other electronic device.

[0074] The UICC unit 102a includes applications (such as SIM, Universal Subscriber Identity Module (USIM), and IP Multimedia Services Identity Module (ISIM)). In one embodiment, in addition to the applications in the UICC unit 102a, another dedicated USIM application (such as an IOPS application) is included by the operator or by the public safety community or agent to enable the UE 102 to communicate in the IOPS operation mode.

[0075] In one embodiment, to ensure that the support for the IOPS operation mode does not endanger the security of normal operation, when the eNodeB (such as the local EPC) operates in the IOPS operation mode, an authentication and key agreement (AKA) procedure is performed between the USIM application dedicated to the IOPS mode in the UICC unit 102a present in the UE 102 and the local HSS (included in the local EPC 108). This also applies to the case of losing backhaul communication and switching the eNodeB 104 to support isolated E-UTRAN operation for the UE group enabled for IOPS.

[0076] In addition, the USIM application dedicated to the IOPS operation mode uses a different set of security certificates independent of the security certificates for normal operation. The certificates are configured in the local EPC 108 and the UICC unit 102a before the start of the IOPS operation mode. The USIM application dedicated to the IOPS operation mode in the UE 102 has a different set of security certificates containing one or more of the following:

[0077] The permanent key "K" (uniquely assigned for the IOPS operation mode);

[0078] The PLMN identity assigned for IOPS network operation;

[0079] The IMSI (uniquely assigned for the IOPS operation mode); or

[0080] The access class status 11 or 15 (subject to regional / country regulatory requirements or operator policies).

[0081] The certificates are preset within the local EPC 108 to support the IOPS operation mode, where the public safety department requires to provide services to the UE 102 in the case of losing backhaul communication. The set of IOPS network security certificates in the local EPC 108 is only stored in the case of the UE 102 authenticated for operation in the IOPS network. Administrative presetting is used to keep the security certificates for all authenticated UE 102 up-to-date at the local EPC 108.

[0082] In one embodiment, the IOPS application (e.g., a USIM application dedicated to the IOPS operation mode) is configured with access classes (described below as "c", "d", "e", "f", and "g") for the normal EPC (for restrictive purposes). In addition to the existing access classes defined in the 3rd Generation Partnership Project (3GPP), an operator can configure new access classes (described below as "h").

[0083] a) Class 0 - 9: Normal behavior

[0084] b) Class 10: Emergency call

[0085] c) Class 15: PLMN staff

[0086] d) Class 14: Emergency services (including IOPS)

[0087] e) Class 13: Utilities (e.g., water, gas suppliers, or IOPS)

[0088] f) Class 12: Security services (including IOPS)

[0089] g) Class 11: For PLMN use (including IOPS)

[0090] h) Class xx: IOPS service

[0091] First, the UE 102 connects to the Macro EPC 106 via the eNodeB 104 of the normal application. Whenever the eNodeB 104 disconnects from the Macro EPC 106 (e.g., the backhaul link), the eNodeB 104 activates the IOPS operation mode. In an embodiment of the present disclosure, whenever there is no backhaul link connection between the eNodeB 104 and the Macro EPC 106, the eNodeB 104 triggers the local EPC 108 (e.g., within the eNodeB 104). In addition, the eNodeB 104 can act as the local EPC 108 and perform the functions of the local EPC 108.

[0092] In addition, the eNodeB 104 or the local EPC 108 broadcasts the PLMN ID for IOPS operations and adopts access classes such as "11" or "15". The UE 102 detects the IOPS PLMN ID in the cell. If the UE 102 cannot find another suitable cell for serving the Macro EPC 106 or the user manually selects the IOPS PLMN, the UE 102 activates and uses the USIM application dedicated to IOPS network access, so that if authorized, the UE 102 connects to the eNodeB 104 or the local EPC 108 and obtains a local IP address. Then, the public safety services supported by the IOPS network can be accessed.

[0093] In one embodiment, the IOPS key "K i " is associated with the access class and is shared between the UE 102 and the eNodeB 104 or the local EPC 108. The eNodeB 104 or the local EPC 108 is preconfigured with a list of keys "K i " for different access classes of the UE 102. The UE 102 (such as the UICC unit 102a or the security environment (such as the KNOX workspace, etc.)) is preconfigured with "K i " based on its access class. The UICC unit 102a is configured or preset by the mobile network operator (MNO) using over-the-air procedures and can be protected by the SIM or USIM toolkit for presetting. The security environment such as KNOX is configured or preset by the MNO or a third party such as the public safety department, the national regulatory agency, etc. using a mobile device management (MDM) solution (such as an MDM partner).

[0094] Since the access classes are very limited, a very limited number of keys are required in the eNodeB 104 or the local EPC 108 to provide secure access to the public safety UE 102. The "K i " is selected by the eNodeB 104 or the local EPC 108 based on the access class of the UE 102. The keys corresponding to the access classes are as follows:

[0095] a) Classes 0 - 9: K 1

[0096] b) Classes 10 - IOPS: K 7

[0097] c) Class 15 - PLMN staff: K 2

[0098] d) Class 14 - Emergency services: K 3

[0099] e) Class 13 - Utilities (such as water / gas suppliers): K4

[0100] f) Class 12 - Security Service: K 5

[0101] g) Class 11 - For PLMN Use: K 6

[0102] In one embodiment, an existing SIM, USIM or ISIM application has an IOPS key (K i ) with a different key index i in addition to the normal or regular network access key "K" based on an access class.

[0103] In one embodiment, the eNodeB 104 or the local EPC 108 activates IOPS - specific authentication (e.g., AKA) by setting the Authentication Management Field (AMF) bits. The AMF has 16 bits, where bit "0" is used as a separator bit, bits "1" to "7" are reserved for future standardization use, and bits "8" to "15" can be used for proprietary purposes. The 16 bits in the AMF are numbered from "0" to "15", where bit "0" is the most significant bit and bit "15" is the least significant bit. At least one bit is used to indicate the IOPS security certificate or key index i and the "K i " (verification and derivation of AV) or the allowed access class and the corresponding key "K i " to be used. Table 1 below shows the role of the AMF bits to indicate IOPS operations, the key index to be used, or the allowed access class (or the corresponding key "K i "). If the network operation is equivalent to IOPS, the bit (leaving out the "separator bit") in the AMF field of AUTN should be set to 1 to indicate to the UE 102 that the AV can only be used for AKA in the IOPS context.

[0104] Table 1

[0105] 5 4 3 2 1 0

[0106] If the network operation is equivalent to IOPS, bit "1" in the AMF field of AUTN should be set to 1 to indicate to the UE 102 that the AV can only be used for AKA in the IOPS context.

[0107] Bit "2" indicates the key index (the key used for or to be used for generating or verifying AV) (LTE subscription key).

[0108] Bits "3" to "7" indicate the access class (which is allowed access and the corresponding key used for or to be used for generating or verifying AV).

[0109] In one embodiment, bits “3” to “6” indicate the access class (which is permitted to access and is used or to be used to generate or verify the corresponding key for the AV). The eNodeB 104 or the local EPC 108 generates the AV (AUC function in a secure environment). Optionally, the eNodeB 104 or the local EPC 108 may be preconfigured with the AVs (for different access classes) instead of generating the AVs. The Oracle Access Management (OAM) server preconfigures a list of AVs in the eNodeB 104 or the local EPC 108 (for different access classes). The preconfiguration of the AVs in the eNodeB 104 or the local EPC 108 does not provide the required security level because any stolen eNodeB or local EPC can leak the AVs and a femtocell can use the stolen AVs to gain access to a specific area.

[0110] Although Figure 1A the eNodeB 104 and the local EPC 108 are shown as two separate entities, the present disclosure is not limited thereto. For example, the local EPC 108 may be available inside the eNodeB 104. For example, as Figure 1B shown, the functions of the local EPC 108 may be preset (or configured) in the eNodeB 104 without explicitly showing the local EPC 108 outside or inside the eNodeB 104.

[0111] Figure 1B is a block diagram of a system 100b for authentication between a UE and an eNodeB 104 serving as the local EPC 108 according to an embodiment disclosed herein. The functions of the local EPC 108 may be preset or configured to the eNodeB 104 so that the eNodeB 104 can serve as the local EPC 108 when the connection between the eNodeB 104 and the Macro EPC is lost.

[0112] Figure 1A and Figure 1B show the system 100a and the system 100b, respectively. However, the present disclosure is not limited thereto. In one embodiment, the system 100a and the system 100b may include fewer components or additional components. In addition, the labels or names of the components are for illustrative purposes only and are not intended to limit the scope of the present disclosure. One or more components may be combined to perform the same or substantially the same functions in the system 100a and the system 100b.

[0113] Figure 2It is a block diagram of a UE 102 for authenticating an eNodeB 104 or a local EPC 108 according to an embodiment disclosed herein. The UE 102 includes a UICC unit 102a, a controller unit 202, a storage unit 204, and a communication unit 206. The controller unit 202, the storage unit 204, and the communication unit 206 may be located within the UICC unit 102a. Some of the units such as the controller unit 202, the storage unit 204, and the communication unit 206 may be located within the UICC unit 102a. The UICC unit 102a includes a USIM application that supports the IOPS operation mode.

[0114] Referring to Figure 2 , the UICC unit 102a or the controller unit 202 may be configured to send a first request message to the eNodeB 104 or the local EPC 108. In one embodiment, the first request message is an ATTACH request message. The ATTACH request message may include an access class, an IMSI, the capabilities of the UE 102, an IMEI, a CSG cell ID, or a combination thereof.

[0115] In addition, the UICC unit 102a or the controller unit 202 may be configured to receive a second request message including a flag from the eNodeB 104 or the local EPC 108. In one embodiment, the second request message is an AUTH request message. The flag may be a RAND and AUTH of the AKA procedure, a key encrypted using the public key of the UE 102 or the UICC unit 102a, an IMSI, a message authentication code (MAC-I) for integrity, or a combination thereof. In addition, the UICC unit 102a or the controller unit 202 may be configured to authenticate the eNodeB 104 or the local EPC 108 based on the received flag.

[0116] After receiving the flag from the eNodeB 104 or the local EPC 108, the UICC unit 102a or the controller unit 202 may be configured to generate a candidate flag. The candidate flag may be a RAND and AUTH of the AKA procedure, a key encrypted using the public key of the UE 102 or the UICC unit 102a, an IMSI, a response message (RES), or a combination thereof. In addition, the present disclosure is described below with reference to FIGS. 5 and Figure 6 described in this disclosure.

[0117] In one embodiment, after receiving a flag from eNodeB 104 or the local EPC 108, the UICC unit 102a or the controller unit 202 may be configured to extract a key related to eNodeB 104 or the local EPC 108 by decrypting the flag. In addition, the UICC unit 102a or the controller unit 202 may be configured to authenticate eNodeB 104 or the local EPC 108 based on the key. In addition, the present disclosure is described below with reference to Figure 12 Describe the present disclosure.

[0118] In addition, the UICC unit 102a or the controller unit 202 may be configured to provide at least one parameter for a response message to eNodeB 104 or the local EPC 108 to authenticate the UE 102. In one embodiment, the response message is an AUTH response message. The parameter may be RES, MAC-I, or a combination thereof. In addition, the UICC unit 102a or the controller unit 202 may be configured to receive an acceptance message from eNodeB 104 or the local EPC 108. The acceptance message is an ATTACH acceptance message. The storage unit 204 may be configured to store the flag received from eNodeB 104 or the local EPC 108.

[0119] In addition, the storage unit 204 may include one or more computer-readable storage media. The storage unit 204 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical discs, floppy disks, flash memories, or electrically programmable read-only memories (EPROMs) or electrically erasable programmable read-only memories (EEPROMs). Additionally, in some examples, the storage unit 204 may be considered a non-transitory storage medium. The term "non-transitory" may mean that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be construed to indicate that the storage unit 204 is immovable. In some examples, the storage unit 204 may be configured to store a larger amount of information than a memory. In certain examples, the non-transitory storage medium may store data that can change over time (e.g., in random access memory (RAM) or a cache). The communication unit 206 may be configured to communicate internally between units and externally with the network.

[0120] Figure 2 The units of the UE 102 are shown, but it should be understood that the present disclosure is not limited thereto. In one embodiment, the UE 102 may include fewer units or additional units. In addition, the labels or names of the units are for illustrative purposes only and are not intended to limit the scope of the present disclosure. One or more units may be combined to perform the same or substantially the same functions in the UE 102.

[0121] Figure 3FIG. is a block diagram of an eNodeB 104 or a local EPC 108 for authenticating a UE 102 according to an embodiment disclosed herein. The eNodeB 104 or the local EPC 108 described herein may correspond to, for example, but not limited to, an LTE network, Enhanced Data Rate for GSM Evolution (EDGE) Radio Access Network (GERAN) for Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS) Radio Access Network (UTRAN), Evolved UTRAN (EUTRAN), or any other network. In an embodiment of the present disclosure, the eNodeB 104 or the local EPC 108 includes a Receiver (Rx) unit 302, a Controller unit 304, a Storage unit 306, and a Transmitter (Tx) unit 308.

[0122] Referring to Figure 3 , the Rx unit 302 may be configured to receive one or more signaling messages from the UE 102 and the network. The Controller unit 304 may be configured to receive a first request message from the UE 102 using the Rx unit 302. In one embodiment, the first request message is an ATTACH request message. The ATTACH request message may include an access class, an IMSI, the capabilities of the UE 102, an IMEI, a CSG cell ID, or a combination thereof. In addition, the Controller unit 304 may be configured to generate a flag after receiving the first request message. In one embodiment, the flag may be a RAND and AUTH of the AKA procedure, a key decrypted using the public key of the UE 102 or the UICC unit 102a, an IMSI, or a combination thereof. In addition, the Controller unit 304 may be configured to send a second request message including the generated flag to the UE 102 using the Tx unit 308. The flag is used by the Controller unit 304 to authenticate the eNodeB 104 or the local EPC 108.

[0123] In addition, the Controller unit 304 may be configured to receive a response message including at least one parameter from the UE 102 using the Rx unit 302. The response message is an AUTH response message. The parameter may be a RES, a MAC-I, or a combination thereof. In addition, the Controller unit 304 may be configured to authorize the UE 102 based on at least one parameter. The Controller unit 304 authorizes the UE 102 after verifying the RES received from the UE 102. The Controller unit 304 may be configured to authorize the UE 102 after verifying the MAC-I. In addition, the Controller unit 304 may be configured to send an ATTACH acceptance message to the UE 102 using the Tx unit 308. The Storage unit 306 may be configured to store the generated flag, which may also be used by the Controller unit 304 to derive a key.

[0124] In addition, storage unit 306 may include one or more computer-readable storage media. Storage unit 306 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical discs, floppy disks, flash memory, or in the form of EPROM or EEPROM. Additionally, in some examples, storage unit 306 may be considered a non-transitory storage medium. The term "non-transitory" may refer to the storage medium not being embodied in a carrier wave or propagated signal. However, the term "non-transitory" should not be construed to indicate that storage unit 306 is immovable. For example, storage unit 306 may be configured to store a larger amount of information than memory storage. For example, the non-transitory storage medium may store data that can change over time (e.g., in RAM or high-speed flash memory).

[0125] Figure 3 eNodeB 104 or local EPC 108 is shown, but it should be understood that the present disclosure is not limited thereto. In one embodiment, eNodeB 104 or local EPC 108 may include fewer or more units. Additionally, the labels or names of the units are for illustrative purposes only and are not intended to limit the scope of the present disclosure. One or more units may be combined to perform the same or substantially the same functions in eNodeB 104 or local EPC.

[0126] Figure 4A is a flowchart of an authentication method 400a between UE 102 and local EPC 108 according to embodiments disclosed herein.

[0127] In step 402a, method 400a receives the IOPS PLMN ID broadcast by local EPC 108, where the IOPS PLMN ID indicates that local EPC 108 is in the IOPS mode. Method 400a allows UE 102 to receive the IOPS PLMN ID broadcast by local EPC 108, where the IOPS PLMN ID indicates that local EPC 108 is in the IOPS mode. In step 404a, method 400a activates the USIM application in UICC unit 102a. Method 400a allows UE 102 to activate the USIM application in UICC unit 102a. In step 406a, method 400a authenticates local EPC 108. Method 400a allows USIM 102b to authenticate local EPC 108.

[0128] The various acts, actions, blocks, steps, etc. in method 400a may be performed in the order shown, in a different order, or simultaneously. Additionally, in one embodiment, some of the acts, actions, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope and spirit of the present disclosure.

[0129] Figure 4B It is a flowchart of a method 400b for authenticating an eNodeB 104 or a local EPC 108 according to an embodiment of the present disclosure.

[0130] Referring to FIG. 4, in step 402b, the method 400b sends a first request message to the eNodeB 104 or the local EPC 108. The method 400b allows the UE 102 to send the first request message to the eNodeB 104 or the local EPC 108. In one embodiment, the first request message is an ATTACH request message. The ATTACH request message can include, for example, an access class, an IMSI, the capabilities of the UE 102, an IMEI, a CSG cell ID, or a combination thereof.

[0131] In step 404b, the method 400b receives a second request message including a flag from the eNodeB 104 or the local EPC 108. In one embodiment, the second request message is an AUTH request message. In one embodiment, the method 400b allows the UE 102 to receive the second request message including the flag from the eNodeB 104 or the local EPC 108.

[0132] In step 406b, the method 400b generates a candidate flag using the IOPS application. In one embodiment, the method 400b allows the UE 102 to generate the candidate flag using the IOPS application. In one embodiment, the candidate flag can be a MAC-I.

[0133] In step 408b, the method 400b determines whether there is a match between the flag received from the eNodeB 104 or the local EPC 108 and the candidate flag. In one embodiment, the method 400b allows the UE 102 to determine whether there is a match between the flag received from the eNodeB 104 or the local EPC 108 and the candidate flag.

[0134] In step 410b, the method 400b authenticates the eNodeB 104 or the local EPC 108 after determining a match between the flag and the candidate flag. In one embodiment, the method 400b allows the UE 102 to authenticate the eNodeB 104 or the local EPC 108 after determining a match between the flag and the candidate flag.

[0135] In step 412b, the method 400b sends a response message including at least one parameter to the eNodeB 104 or the local EPC 108 to authenticate the UE 102. In one embodiment, the method 400b allows the UE 102 to send a response message including at least one parameter to the eNodeB 104 or the local EPC 108 to authenticate the UE 102. The parameter can be, for example, a RES, a MAC-I, or a combination thereof generated using the IOPS application.

[0136] In step 414b, method 400b includes receiving an acceptance message (e.g., an ATTACH acceptance message) from eNodeB 104 or local EPC 108. In one embodiment, method 400b allows UE 102 to receive an ATTACH acceptance message from eNodeB 104 or local EPC 108.

[0137] The various acts, actions, blocks, steps, etc. of method 400b may be performed in the order shown, in a different order, or simultaneously. Additionally, in one embodiment, some of the acts, actions, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope and spirit of the present disclosure.

[0138] Figure 5A is a flowchart of an authentication method 500a between UE 102 and eNodeB 104 or local EPC 108 according to embodiments disclosed herein.

[0139] In step 502, method 500a broadcasts an IOPS PLMN ID (i.e., using SIB), where the IOPS PLMN ID indicates that eNodeB 104 or local EPC 108 is in the IOPS mode. Method 500a allows the controller unit 304 to broadcast the IOPS PLMN ID to UE 102 to authenticate eNodeB 104 or local EPC 108, where the IOPS PLMN ID indicates that eNodeB 104 or local EPC 108 is in the IOPS mode.

[0140] The various acts, actions, blocks, steps, etc. in method 500a may be performed in the order shown, in a different order, or simultaneously. Additionally, in one embodiment, some of the acts, actions, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope and spirit of the present disclosure.

[0141] Figure 5B is a flowchart of a method 500b for authenticating eNodeB 104 or local EPC 108 according to embodiments disclosed herein.

[0142] Refer to Figure 5B, in step 502b, method 500b receives a first request message from UE 102. Method 500b allows controller unit 304 to receive the first request message from UE 102. In step 504b, method 500b retrieves a flag generated in local EPC 108 using the IOPS certificate of that particular UE 102. Method 500b allows controller unit 304 to retrieve the flag generated in local EPC 108 using the IOPS certificate of that particular UE 102.

[0143] In step 506b, method 500b sends a second request message including the generated flag to UE 102 to authenticate eNodeB 104 or local EPC 108. In one embodiment, method 500b allows controller unit 304 to send a second request message including the generated flag to UE 102 to authenticate eNodeB 104 or local EPC 108. In step 508b, method 500b receives a response message from UE 102 that includes at least one parameter. Method 500b allows controller unit 304 to receive the response message from UE 102 that includes at least one parameter.

[0144] In step 510b, method 500b authenticates UE 102 based on the at least one parameter. In an embodiment of the present disclosure, method 500b allows controller unit 304 to authenticate UE 102 based on the at least one parameter. In step 512b, method 500b sends an acceptance message to UE 102. In one embodiment, method 500b allows controller unit 304 to send the acceptance message to UE 102.

[0145] The various acts, actions, blocks, steps, etc. of method 500b may be performed in the order shown, in a different order, or simultaneously. Additionally, in one embodiment, some of the acts, actions, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope and spirit of the present disclosure.

[0146] Figure 6 is a sequence diagram 600 for performing authentication between UE 102 and eNodeB 104 or local EPC 108 according to embodiments of the present disclosure disclosed herein. In one embodiment, the signaling sequence describes the communication between UE 102 and eNodeB 104 or local EPC 108.

[0147] Refer to Figure 6, in step 602, the UE 102 sends a first request message to the eNodeB 104 or the local EPC 108. In one embodiment, the first request message is an ATTACH request message, where the ATTACH request message includes an access class, an IMSI, the capabilities of the UE 102, or a combination thereof. In one embodiment, the UE 102 sends the first request message without including an access class in the message.

[0148] In step 604, after receiving the first request message, the eNodeB 104 or the local EPC 108 sends a data request message (i.e., an AUTH data request message) to the security environment 600a. The data request message includes an access class, an IMSI, or a combination thereof. Based on the received access class, the eNodeB 104 or the local EPC 108 requests the security environment 602 (which may be included in the eNodeB 104 or the local EPC 108 or may be outside the eNodeB 104 or the local EPC 108) to provide an AV to authenticate the UE 102 and authorize access to secure communication in the IOPS operation mode.

[0149] In step 606, after receiving the data request message, the security environment 600a uses "K" selected by the eNodeB 104 based on the access class provided by the UE 102 to derive the AV. If the access class is not provided by the UE 102, the eNodeB 104 generates an AV using the permitted or allowed access class (i.e., access class 11) and indicates the access class in the AMF so that the UE 102 can use the AMF to identify the access class and the corresponding key to generate or verify the AV (if this is permitted). i In step 608, the security environment 600a sends a data response message (e.g., an AUTH data response message) to the eNodeB 104 or the local EPC 108. The data response message includes RAND, expected response (XRES), AUTH, and K

[0150] In step 610, after receiving the data response message, the eNodeB 104 or the local EPC 108 stores the K included in the data response message eNodeB and XRES. In addition, the eNodeB 104 or the local EPC 108 selects an Evolved Packet System (EPS) encryption algorithm (EEA) and an EPS integrity algorithm (EIA) and derives further keys.

[0151] eNodeB

[0152] ​​In step 612, the eNodeB 104 or the local EPC 108 sends a second request message including flags to the UE 102. The flags can be RAND and AUTH of the AKA procedure, a key encrypted using the public key of the UE 102, IMSI, MAC-I, or a combination thereof. The System Management Controller (SMC) procedure is executed along with the AKA authentication procedure. This is performed by including selected cryptographic techniques. In addition, MAC-I is generated using the selected cryptographic techniques and a security key derived from the key of the AV (i.e., the key corresponding to the RAND and AUTH of the AV included in the message). The SMC procedure is executed separately when the eNodeB 104 or the local EPC 108 operates in the IOPS operation mode.

[0153] In step 614, after receiving the second request message, the UE 102 sends a data request message (such as an AUTH data request message) to the UICC unit 102a. The data request message includes RAND, AUTN, or a combination thereof.

[0154] In step 616, after receiving the data request message, the UICC unit 102a generates candidate flags. The candidate flags can be RES, RAND and AUTH of the AKA procedure, a key encrypted using the public key of the UE 102, IMSI, or a combination thereof. The candidate flags are generated in either the UE 102 or the USIM application. In addition, the UICC unit 102a or the controller unit 202 determines whether there is a match between the flags received from the eNodeB 104 or the local EPC 108 and the generated candidate flags. Once a match is determined, the UICC unit 102a or the controller unit 202 authenticates the eNodeB 104 or the local EPC 108.

[0155] In step 618, after authenticating the eNodeB 104 or the local EPC 108, the UICC unit 102a or the controller unit 202 sends a data response message to the UE 102. The data response message includes RES, K eNodeB or a combination thereof.

[0156] In step 620, after receiving the data response message, the UE 102 generates further keys. The UE 102 uses K ASME (either the access stratum (AS) security key or the non-access stratum (NAS) security key) to obtain other keys. In addition, if the SMC procedure is executed along with the AKA procedure, the UE 102 verifies the MAC-I.

[0157] In step 622, the UE 102 sends a response message including at least one parameter to the eNodeB 104 or the local EPC 108 to authenticate the UE 102. The parameter can be RES, MAC-I, or a combination thereof.

[0158] In step 624, after receiving the response message, the eNodeB 104 or the local EPC 108 verifies whether the RES is equal to XRES (e.g., through the PDCP entity or a new entity in the eNodeB 104 or the local EPC 108). If the RES is equal to XRES, the authentication is successful and the UE 102 is authenticated.

[0159] In step 626, after the UE 102 is successfully authenticated, the eNodeB 104 or the local EPC 108 grants the UE 102 access rights and performs further protected data exchange between the UE 102 and the eNodeB 104 or the local EPC 108 in a secure manner.

[0160] In step 628, the eNodeB 104 or the local EPC 108 sends an acceptance message (i.e., an ATTACH acceptance message) to the UE 102.

[0161] Figure 7 Sequence diagram 700 is for performing authentication between the UE 102 and the eNodeB 104 or the local EPC 108 according to the embodiments disclosed herein. The signaling sequence describes the communication between the UE 102 and the eNodeB 104 or the local EPC 108.

[0162] Refer to Figure 7 , in step 702, the eNodeB 104 or the local EPC 108 sends an SIB message to the UE 102. The SIB message includes an IOPS PLMN ID, an IOPS CSG ID, or a combination thereof.

[0163] In step 704, the UE 102 sends a first request message to the eNodeB 104 or the local EPC 108. The first request message is an ATTACH request message. The ATTACH request message includes an IMSI, the capabilities of the UE 102, a CSG cell ID, or a combination thereof. The UE 102 sends the request message without including an access class in the message.

[0164] In step 706, after receiving the request message, eNodeB 104 or the local EPC 108 sends a data request message to the security environment 600a which is part of the Authentication Center (AuC). The data request message is an AUTH data request message. The AUTH data request message includes a CSG ID, an IMSI, or a combination thereof. eNodeB 104 or the local EPC 108 requests the security environment 600a (e.g., the AuC can be included in eNodeB 104 or can be located outside eNodeB 104) to provide an AV to authenticate the UE 102 and grant access rights for secure communication in the IOPS operation mode.

[0165] In step 708, after receiving the data request message, the security environment 600a uses "K" selected by eNodeB 104 or the local EPC 108 based on at least one of the IMSI and the access class provided by the UE 102 i to derive the AV. If the access class is not provided by the UE 102, eNodeB 104 or the local EPC 108 generates the AV using an allowed or permitted access class (e.g., access class 11) and indicates the access class in the AMF so that the UE 102 can use the AMF to identify the access class and the corresponding key to generate or verify the AV (if this is permitted).

[0166] In step 710, the security environment 600a (e.g., the AuC) sends a data response message to eNodeB 104 or the local EPC 108. The data response message is an AUTH data response message. The AUTH data response message includes RAND, XRES, AUTH, K ASME (K eNodeB ) or a combination thereof.

[0167] In step 712, after receiving the data response message, eNodeB 104 or the local EPC 108 stores the K ASME (K eNodeB ) and XRES included in the data response message. In addition, eNodeB 104 or the local EPC 108 selects EEA and EIA and derives further keys.

[0168] In step 714, eNodeB 104 or the local EPC 108 sends a second request message including flags to the UE 102. The flags can be the RAND and AUTH of the AKA procedure, the key K ASME (K eNodeB)), MAC-I, or a combination thereof. The SMC procedure is executed along with the AKA authentication procedure. This is executed by including selected cryptographic techniques. In addition, MAC-I is generated using selected techniques and a security key derived from the key of the AV (e.g., the key corresponds to the RAND and AUTH of the AV included in the message). The SMC procedure is executed separately when the eNodeB 104 or the local EPC 108 operates in the IOPS operation mode.

[0169] In step 716, after receiving the second request message, the UE 102 sends a data request message to the UICC unit 102a or the controller unit 202. The data request message is an AUTH data request message. The AUTH data request message includes RAND, AUTH, or a combination thereof.

[0170] In step 718, after receiving the data request message, the UICC unit 102a or the controller unit 202 generates a candidate flag using the IOPS application. The candidate flag can be RAND and AUTH, RES, IMSI, MAC-I, a key encrypted using a public key, or a combination thereof of the AKA procedure. The candidate flag is generated in one of the USIM applications included in the UE 102 or the UICC unit 102a. In addition, the UICC unit 102a or the controller unit 202 determines whether there is a match between the flag received from the eNodeB 104 or the local EPC 108 and the generated candidate flag. Once the match is determined, the UICC unit 102a or the controller unit 202 authenticates the eNodeB 104 or the local EPC 108.

[0171] In step 720, after authenticating the eNodeB 104 or the local EPC 108, the UICC unit 102a or the controller unit 202 sends a data response message to the UE 102. The data response message is an AUTH data response message. The AUTH data response message includes RES, K ASME (K eNodeB ) or a combination thereof.

[0172] In step 722, after receiving the data response message, the UE 102 generates a further key. The UE 102 uses K ASME (e.g., only the AS security key or the NAS security key) to generate a further key. In addition, if the SMC procedure is executed along with the AKA procedure, the UE 102 verifies MAC-I.

[0173] In step 724, the UE 102 sends a response message including at least one parameter to the eNodeB 104 or the local EPC 108 to authenticate the UE 102. The at least one parameter can be RES, MAC-I, or a combination thereof.

[0174] In step 726, after receiving the response message, eNodeB 104 or the local EPC 108 verifies the MAC-I and authenticates the UE 102.

[0175] In step 728, after the UE 102 is successfully authenticated, eNodeB 104 or the local EPC 108 grants the UE 102 access rights and further protected data exchange between the UE 102 and the eNodeB 104 or the local EPC 108 is performed in a secure manner.

[0176] In step 730, eNodeB 104 or the local EPC 108 sends an acceptance message to the UE 102.

[0177] Figure 8A and 8B is a diagram of a key derivation method according to an embodiment disclosed herein. The key derivation method is performed by the UE 102 and the eNodeB 104 or the local EPC 108; further key derivation for communication protection is described below. In an embodiment of the present disclosure, detailed key derivation can be used for other solutions detailed in the present disclosure. RAND, IMSI, eNodeB ID, or a combination thereof can be used as input for key derivation. The equation (1) for K ASME-IOPS is as follows:

[0178] K ASME-IOPS = EPS AKA algorithm (K i , uniqueness parameter, RAND, SQN, <other possible parameters>)(1)

[0179] Referring to Figure 8A and Figure 8B , in one embodiment, all other parameters are optional except for K i . The serial number (SN) ID can be the eNodeB ID. The eNodeB ID is included and broadcast in the SIB signaling message. Generally, the 20 MSB of the 28-bit field identifies the eNodeB 104 or the local EPC 108.

[0180] As shown in Figure 8A , in one embodiment, the NAS key is not used. The derived K ASME is used as the eNodeB 104 or the local EPC 108, and the NAS signaling (if any) is protected using the AS security context. In addition, when the NAS security context is not derived, only the AS security context is derived by the source eNodeB and provided to the target eNodeB during a handover from the eNodeB 104 or the local EPC 108 to another eNodeB, where the NAS terminates at the connected eNodeB.

[0181] As shown in Figure 8B In one embodiment, the NAS key is derived and the NAS terminates at the eNodeB 104 or the local EPC 108. The eNodeB 104 or the local EPC 108 performs the mobility management procedure. When switching from the eNodeB 104 to another eNodeB, the NAS key (if derived and used) may be retained in the eNodeB 104. Only the target specific AS security context is derived by the eNodeB 104 and provided to another eNodeB where the NAS terminates at the authenticated eNodeB.

[0182] Figure 9 is a sequence diagram 900 for authenticating the eNodeB 104 or the local EPC108 using the IOPS IMSI according to the embodiments disclosed herein. In addition to the access class sent to the eNodeB 104 or the local EPC 108, the IMSI can be used for access control and identification of the IOPS key. For example, the IMSI within the UE 102 is as follows:

[0183] IMSI 1 : xxxyyabcdef1234 associated with the key K 1

[0184] MCC xxx country code

[0185] MNC yy(y)IOPS network

[0186] MSIN abcde1234 identification number with IOPS service capabilities (e.g., ending with 1234)

[0187] IMSI 2 : 404685505601234 associated with the key K 2

[0188] MCC 404 country

[0189] MNC 68MNO

[0190] MSIN 5505601234

[0191] Referring to Figure 9 In one embodiment, the signaling sequence describes the communication between the UE 102 and the eNodeB 104 or the local EPC108.

[0192] In step 902, the UE 102 sends including the IMSI 2 ​​The ATTACH request message to eNodeB 104 or the local EPC 108. In addition, the UE 102 sends an ATTACH request message to access eNodeB 104 or the local EPC 108 in the normal operation mode.

[0193] In step 904, after receiving the ATTACH request message including the IMSI 2 the eNodeB 104 or the local EPC 108 sends an ATTACH reject message to the UE 102. The ATTACH reject message indicates that the eNodeB 104 or the local EPC 108 is in the IOPS operation mode.

[0194] In step 906, the UE 102 sends an ATTACH request message including the IMSI 1 to the eNodeB 104 or the local EPC 108.

[0195] In step 908, after receiving the ATTACH request message including the IMSI 1 the eNodeB 104 or the local EPC 108 verifies whether the IMSI 1 is authenticated for the IOPS operation mode. In addition, if the verification is successful, an AV corresponding to the IMSI 1 is generated by the eNodeB 104 or the local EPC 108.

[0196] In step 910, after the verification is successful and the authentication vector is generated, the eNodeB 104 or the local EPC 108 sends an AUTH request message including flags to the UE 102. The flags can be AUTH, RAND, Key Signature Architecture without keys (KSI), key index, or a combination thereof.

[0197] In step 912, the UE 102 verifies AUTH by using the key index included in the AUTH request message provided by the eNodeB 104 or the local EPC 108 to identify the key.

[0198] In step 914, after the verification is successful, the UE 102 sends an AUTH response message including RES (such as a parameter) to the eNodeB 104 or the local EPC 108 to authenticate the UE 102.

[0199] In step 916, after receiving the AUTH response message, eNodeB 104 or the local EPC 108 verifies whether RES is equal to XRES (e.g., by the PDCP entity or a new entity in eNodeB 104 or the local EPC 108). If RES is equal to XRES, the authentication is successful and the UE 102 is authenticated.

[0200] In step 918, an SMC procedure or integrity protected communication is performed between the UE 102 and eNodeB 104 or the local EPC 108. The SMC procedure is performed separately when eNodeB 104 or the local EPC 108 operates in the IOPS mode.

[0201] Figure 10 FIG. 1000 is a sequence diagram of authenticating eNodeB 104 or the local EPC 108 using SIB messages according to an embodiment disclosed herein. The signaling sequence describes the communication between the UE 102 and eNodeB 104 or the local EPC 108.

[0202] Referring to Figure 10 , in step 1002, eNodeB 104 or the local EPC 108 sends an SIB message to the UE 102 indicating that eNodeB 104 or the local EPC 108 is in the IOPS operation mode.

[0203] In step 1004, after receiving the SIB message, the UE 102 identifies that eNodeB 104 or the local EPC 108 is in the IOPS operation mode. In addition, the UE 102 selects an IMSI 1 , since the UE 102 is capable of operating in the IOPS mode and has an IOPS subscription key.

[0204] In step 1006, the UE 102 sends an ATTACH request message including the IMSI 1 to eNodeB 104 or the local EPC 108.

[0205] In step 1008, after receiving the ATTACH request message including the IMSI 1 , eNodeB 104 or the local EPC 108 verifies whether the IMSI 1 is authenticated for the IOPS operation mode. In addition, if the verification is successful, an AV corresponding to the IMSI 1 is generated by eNodeB 104 or the local EPC 108.

[0206] In step 1010, after successful verification and generation of the AV, eNodeB 104 or the local EPC 108 sends an AUTH request message including flags to the UE 102. The flags can be AUTH, RAND, KSI, key index, or a combination thereof.

[0207] In step 1012, the UE 102 verifies the AUTH by using the key index included in the AUTH request message provided by the eNodeB 104 or the local EPC 108 to identify the key.

[0208] In step 1014, after successful verification, the UE 102 sends an AUTH response message including RES (such as a parameter) to the eNodeB 104 or the local EPC 108 to authenticate the UE 102.

[0209] In step 1016, after receiving the AUTH response message, the eNodeB 104 or the local EPC 108 verifies whether the RES is equal to the XRES (e.g., through the PDCP entity or a new entity in the eNodeB 104 or the local EPC 108). If the RES is equal to the XRES, the authentication is successful and the UE 102 is authenticated.

[0210] In step 1018, the SMC procedure or integrity-protected communication is performed between the UE 102 and the eNodeB 104 or the local EPC 108. The SMC procedure is performed separately when the eNodeB 104 or the local EPC 108 operates in the IOPS mode.

[0211] Figure 11 FIG. 1100 is a sequence diagram for authenticating the eNodeB 104 or the local EPC 108 using the IMSI and IMEI according to an embodiment disclosed herein. In addition to the access class sent to the eNodeB 104 or the local EPC 108, the IMEI can be used for the identification of the IOPS key and access control. For example, the format of the IMEI in the UE 102 is as described in Table 2 below:

[0212] Table 2

[0213]

[0214] Refer to Figure 11 , in the embodiments of the present disclosure, the signaling sequence describes the communication between the UE 102 and the eNodeB 104 or the local EPC 108.

[0215] In step 1102, the eNodeB 104 or the local EPC 108 sends an SIB message indicating that the eNodeB 104 or the local EPC 108 is in the IOPS operation mode to the UE 102.

[0216] In step 1104, after receiving the SIB message, the UE 102 recognizes that the eNodeB 104 or the local EPC 108 is in the IOPS operation mode. In addition, the UE 102 selects an IMSI 1 , because the UE 102 is capable of operating in the IOPS mode and has an IOPS subscription key.

[0217] In step 1106, the UE 102 sends an ATTACH request message including the IMSI 1 and the IMEI to the eNodeB 104 or the local EPC 108.

[0218] In step 1108, after receiving the ATTACH request message including the IMSI 1 and the IMEI, the eNodeB 104 or the local EPC 108 verifies whether the IMSI 1 or the IMEI is authorized for the IOPS operation mode. In addition, if the verification is successful, an AV corresponding to the IMSI 1 or the IMEI is generated by the eNodeB 104 or the local EPC 108.

[0219] In step 1110, after the verification is successful and the AV is generated, the eNodeB 104 or the local EPC 108 sends an AUTH request message including flags to the UE 102. The flags can be AUTH, RAND, KSI, key index, or a combination thereof.

[0220] In step 1112, the UE 102 verifies the AUTH by identifying the key using the key index included in the AUTH request message provided by the eNodeB 104 or the local EPC 108.

[0221] In step 1114, after the verification is successful, the UE 102 sends an AUTH response message including RES (such as a parameter) to the eNodeB 104 or the local EPC 108 to authorize the UE 102.

[0222] In step 1116, after receiving the AUTH response message, the eNodeB 104 or the local EPC 108 verifies whether the RES is equal to the XRES (e.g., through the PDCP entity or a new entity in the eNodeB 104 or the local EPC 108). If the RES is equal to the XRES, the authentication is successful and the UE 102 is authenticated.

[0223] In step 1118, an SMC procedure or integrity protected communication is performed between UE 102 and eNodeB 104 or local EPC 108. The SMC procedure is performed separately when eNodeB 104 or local EPC 108 operates in the IOPS mode.

[0224] Figure 12 is a flowchart of a method 1200 for authenticating eNodeB 104 or local EPC 108 according to an embodiment disclosed herein. In step 1202, method 1200 sends an ATTACH request message to eNodeB 104 or local EPC 108. Method 1200 allows USIM 102b to send an ATTACH request message to eNodeB 104 or local EPC 108. The ATTACH request message may include, for example, an access class, IMSI, capabilities of UE 102, IMEI, CSG cell ID, or a combination thereof.

[0225] Referring to Figure 12 , in step 1204, method 1200 receives a second request message (e.g., an AUTH request message) including a flag from eNodeB 104 or local EPC 108. Method 1200 allows USIM 102b to receive a second request message including a flag from eNodeB 104 or local EPC 108.

[0226] In step 1206, method 1200 includes extracting a key associated with eNodeB 104 or local EPC 108 by decrypting the flag. Method 1200 allows USIM 102b to extract a key associated with eNodeB 104 or local EPC 108 by decrypting the flag.

[0227] In step 1208, method 1200 authenticates eNodeB 104 or local EPC 108 based on the key. Method 1200 allows USIM 102b to authenticate eNodeB 104 or local EPC 108 based on the key. Method 1200 allows USIM 102b to authenticate eNodeB 104 or local EPC 108.

[0228] In step 1210, method 1200 sends a response message (e.g., an AUTH response message) including at least one parameter to eNodeB 104 or local EPC 108 to authenticate UE 102. Method 1200 allows USIM 102b to send an AUTH response message including at least one parameter to eNodeB 104 or local EPC 108 to authenticate UE 102. The at least one parameter may be, for example, RES, MAC-I, or a combination thereof.

[0229] In step 1212, method 1200 receives an acceptance message (such as an ATTACH acceptance message) from eNodeB 104 or the local EPC 108. Method 1200 allows USIM 102b to receive the ATTACH acceptance message from eNodeB 104 or the local EPC 108.

[0230] The various behaviors, actions, blocks, steps, etc. of method 1200 may be performed in the order shown, in a different order, or simultaneously. Additionally, in one embodiment, some of the behaviors, actions, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope and spirit of the present disclosure.

[0231] Figure 13 is an identity-based cryptography (IBC) sequence diagram 1300 for K ASME (K eNodeB ) exchange message flows. IBC is used to perform key exchange to protect communications between UE 102 and eNodeB 104 or the local EPC 108 operating in the IOPS mode. UE 102 has a private key corresponding to its IMSI, IMEI, or mobile subscriber integrated services digital network number (MSISDN) (such as a public key) and related parameters preset in USIM 102b. Conventional private key / public key is used instead of IBC.

[0232] Referring to Figure 13 , eNodeB 104 has a private key corresponding to its identity (such as a peripheral component interconnect (PCI) or eNodeB ID as a public key) and related parameters preset. Conventional private key / public key is used instead of IBC. eNodeB 104 or the local EPC 108 may have a list (or range) of the IMSI, IMEI, or MSISDN of UE 102 with public security enabled. The communication between UE 102 and eNodeB 104 or the local EPC 108 is protected as follows: eNodeB 104 or the local EPC 108 uses the IMSI to protect the data for a specific UE 102 (the data may be the key K ASME ). When communicating with eNodeB 104 or the local EPC 108, UE 102 uses the eNodeB-ID (such as PCI, eNodeB ID, etc.) to protect the data.

[0233] In addition, by using IBC, K ASME (or K eNodeB)Shared between the eNodeB 104 or the local EPC 108 and the UE 102 for a certain period or a certain session. The private key related to the IMSI or the eNodeB ID is securely stored in the USIM 102b or a secure environment. The signaling sequence describes the communication between the UE 102 and the eNodeB 104 or the local EPC 108.

[0234] In step 1302, the eNodeB 104 or the local EPC 108 sends an SIB message to the UE 102, indicating that the eNodeB 104 or the local EPC 108 is in the IOPS operation mode.

[0235] In step 1304, after receiving the SIB message, the UE 102 identifies that the eNodeB 104 or the local EPC 108 is in the IOPS operation mode. In addition, the UE 102 selects the IMSI 1 , because the UE 102 is capable of operating in the IOPS mode and has an IOPS subscription key (such as a private key).

[0236] In step 1306, the UE 102 sends an ATTACH request message including the IMSI 1 to the eNodeB 104 or the local EPC 108.

[0237] In step 1308, after receiving the ATTACH request message including the IMSI 1 , the eNodeB 104 or the local EPC 108 verifies whether the IMSI 1 is authorized for the IOPS operation mode. In addition, if the verification is successful, a K 1 for the IMSI ASME is generated.

[0238] In operation 1310, after the verification is successful and the key is generated, the eNodeB 104 or the local EPC 108 sends a flag to the UE 102. The flag includes the K 1 encrypted using the IMSI ASME (or K eNodeB ). The flag includes the MAC-I of the message calculated from the RRC initial key derived from K eNodeB , the selected security technology, and the KSI (such as the index of K eNodeB ).

[0239] In step 1312, after receiving the AUTH request message, the UE 102 decrypts and obtains the K ASME (or K eNodeB)。In addition, if received in a message, the UE 102 derives a key and verifies the MAC-I.

[0240] In step 1314, the UE 102 sends an AUTH response message including the MAC-I (e.g., a parameter) to the eNodeB 104 or the local EPC 108 to authenticate the UE 102.

[0241] In step 1316, after receiving the AUTH response message, the eNodeB 104 or the local EPC 108 verifies the MAC-I. Once the verification is successful, the UE 102 is authenticated by the eNodeB 104 or the local EPC 108.

[0242] In step 1318, an SMC procedure or integrity protected communication is performed between the UE 102 and the eNodeB 104 or the local EPC 108. The SMC procedure is performed separately when the eNodeB 104 or the local EPC 108 operates in the IOPS mode.

[0243] In an embodiment of the present disclosure, the SMC procedure (e.g., step 1318) can be performed separately. The SMC procedure can be performed together with key distribution instead of a separate SMC procedure (e.g., steps 1310, 1312, and 1314).

[0244] Figure 14 is a block diagram of a computing environment of a method and system for implementing authentication between the UE 102 and the local EPC 108 according to the embodiments disclosed herein.

[0245] Referring to Figure 14 , the computing environment 1402 includes at least one processing unit 1408 equipped with a control unit 1404 and an arithmetic logic unit (ALU) 1406, a memory 1410, a storage device 1412, a plurality of network devices 1416, and a plurality of input / output (I / O) devices 1414. The processing unit 1408 is responsible for processing technical instructions. The processing unit 1408 receives commands from the control unit 1404 to perform its processing. In addition, any logical and arithmetic operations involved in the instruction execution are calculated by means of the ALU 1406.

[0246] The computing environment 1402 may include a plurality of homogeneous or heterogeneous cores, a plurality of CPUs of different types, special media, and other accelerators. The processing unit 1408 is responsible for processing technical instructions. In addition, the processing unit 1408 can be on a single chip or on multiple chips.

[0247] The technology including the instructions and code required for implementation is stored in one or both of the memory 1410 and the storage device 1412. When executed, the instructions can be fetched from the corresponding memory 1410 or storage device 1412 and executed by the processing unit 1408.

[0248] In any hardware implementation scenario, each network device 1416 or external I / O device 1414 can be connected to the computing environment 1402 to support implementation through the network device 1416 and the I / O device 1414.

[0249] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and executes network management functions to control components. The components shown in FIGS. 1 to Figure 14 include blocks that can be at least one of a hardware device or a combination of a hardware device and a software unit.

[0250] The foregoing description of the embodiments of the present disclosure embodies the general nature of the present disclosure herein. Therefore, others can modify or change the above specific embodiments by using existing knowledge for various applications without departing from the scope and gist of the present disclosure. Therefore, such adaptations and modifications are intended to be included within the meaning and scope of the equivalents of the disclosed embodiments. It should be understood that the terms used herein are for descriptive purposes and not for limitation. Therefore, although the embodiments of the present disclosure have been described herein, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the spirit and scope of the present disclosure as defined by the appended claims and their equivalents.

Claims

1. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: receiving, from an evolved Node B (eNB), a Public Land Mobile Network (PLMN) identifier for isolated Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN) operations (IOPS) for public safety; and activating an IOPS Universal Subscriber Identity Module (USIM) application of the UE, wherein the IOPS USIM application uses a security certificate configured for IOPS, wherein the security certificate includes an International Mobile Subscriber Identity (IMSI) for IOPS and an access class status 11 or 15, wherein the security certificate is a different set of security certificates for IOPS that is independent of the security certificates for normal operation, and wherein the normal operation includes non-IOPS mode operation based on a backhaul connection to an Evolved Packet Core (EPC).

2. The method according to claim 1, wherein the access class status includes access class status 11 as defined in the 3rd Generation Partnership Project (3GPP).

3. The method according to claim 1, wherein the access class status allows the UE to access the eNB while shielding other non-IOPS-enabled UEs in a cell associated with the eNB.

4. The method according to claim 1, wherein the eNB has no connectivity to a macro EPC while being connected to a local EPC.

5. The method according to claim 1, wherein the USIM application is dedicated to the IOPS and uses the different set of security certificates that is independent of the security certificates for the normal operation.

6. The method according to claim 1, wherein the different set of security certificates includes at least one of the following: a permanent key K, uniquely assigned for the IOPS; a Public Land Mobile Network (PLMN) identifier, assigned for IOPS network operation; the IMSI, uniquely assigned for the IOPS; and the access class status 11 or 15, subject to regional / country regulatory requirements and operator policies.

7. A user equipment UE in a wireless communication system, the user equipment UE comprising: a transceiver; and at least one processor, coupled to the transceiver and configured to: receive, from an evolved Node B (eNB), a Public Land Mobile Network (PLMN) identifier for isolated Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN) operations (IOPS) for public safety; and activate an IOPS Universal Subscriber Identity Module (USIM) application of the UE, wherein the IOPS USIM application uses a security certificate configured for IOPS, wherein the security certificate includes an International Mobile Subscriber Identity (IMSI) for IOPS and an access class status 11 or 15, wherein the security certificate is a different set of security certificates for IOPS that is independent of the security certificates for normal operation, and Among them, the normal operation includes operation in a non-IOPS mode based on a backhaul connection to an evolved packet core (EPC).

8. The UE according to claim 7, wherein, the access class status includes access class status 11 defined in the 3rd Generation Partnership Project (3GPP).

9. The UE according to claim 7, wherein, the access class status allows the UE to access the eNB while shielding other non-IOPS-enabled UEs in the cell associated with the eNB.

10. The UE according to claim 7, wherein, the eNB is in the IOPS mode, and wherein the eNB has no connectivity to the macro EPC while being connected to a local EPC.

11. The UE according to claim 7, wherein, the USIM application is dedicated to the IOPS and uses a different set of security certificates independent of the security certificates for the normal operation.

12. The UE according to claim 7, wherein, the different set of security certificates includes at least one of the following: A permanent key K, uniquely assigned for the IOPS; A public land mobile network (PLMN) identifier, assigned for IOPS network operation; The IMSI, uniquely assigned for the IOPS; and The access class status 11 or 15, subject to regional / country regulatory requirements and operator policies.

13. A method performed by an evolved Node B (eNB) in a wireless communication system, the method comprises: Sending a public land mobile network (PLMN) identifier for isolated evolved universal mobile telecommunications system terrestrial radio access network (E-UTRAN) operation (IOPS) for public safety to a user equipment (UE); wherein the IOPS universal subscriber identity module (USIM) application of the UE is activated based on the PLMN identifier, wherein the IOPS USIM application uses security certificates configured for the IOPS, wherein the security certificates configured in the USIM application of the UE include an international mobile subscriber identity (IMSI) and an access class status 11 or 15 for the IOPS, wherein the security certificates are a different set of security certificates independent of the security certificates for normal operation for the IOPS, and wherein the normal operation includes operation in a non-IOPS mode based on a backhaul connection to an evolved packet core (EPC).

14. The method according to claim 13, wherein, the access class status includes access class status 11 defined in the 3rd Generation Partnership Project (3GPP).

15. The method according to claim 13, wherein, the access class status allows the UE to access the eNB while shielding other non-IOPS-enabled UEs in the cell associated with the eNB.

16. The method according to claim 13, wherein, the eNB is in the IOPS mode, and wherein the eNB has no connectivity to the macro EPC while being connected to a local EPC.

17. The method according to claim 13, wherein, The USIM application is specifically for the IOPS and uses a different set of security certificates independent of the security certificates for the normal operation.

18. The method according to claim 13, wherein, the different set of security certificates includes at least one of the following: a permanent key K, uniquely assigned for the IOPS; a Public Land Mobile Network (PLMN) identifier, assigned for IOPS network operation; the IMSI, uniquely assigned for the IOPS; and the access class status 11 or 15, subject to regional / country regulatory requirements and operator policies.

19. An evolved Node B (eNB) in a wireless communication system, the evolved Node B (eNB) comprising: a transceiver; and at least one processor configured to: send a Public Land Mobile Network (PLMN) identifier for isolated Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN) operation (IOPS) for public safety to a User Equipment (UE); wherein, the IOPS Universal Subscriber Identity Module (USIM) application of the UE is activated based on the PLMN identifier, wherein, the IOPS USIM application uses security certificates configured for the IOPS, wherein, the security certificates configured in the USIM application of the UE include the International Mobile Subscriber Identity (IMSI) for the IOPS and the access class status 11 or 15, wherein, the security certificates are a different set of security certificates for the IOPS independent of the security certificates for the normal operation, and wherein, the normal operation includes non-IOPS mode operation based on a backhaul connection to an Evolved Packet Core (EPC).

20. The eNB according to claim 19, wherein, the access class status includes the access class status 11 defined in the 3rd Generation Partnership Project (3GPP).

21. The eNB according to claim 19, wherein, the access class status allows the UE to access the eNB while shielding other non-IOPS-enabled UEs in the cell associated with the eNB.

22. The eNB according to claim 19, wherein, the eNB is in the IOPS mode, and wherein, the eNB has no connectivity to the macro EPC while being connected to a local EPC.

23. The eNB according to claim 19, wherein, the USIM application is specifically for the IOPS and uses a different set of security certificates independent of the security certificates for the normal operation.

24. The eNB according to claim 19, wherein, the different set of security certificates includes at least one of the following: a permanent key K, uniquely assigned for the IOPS; a Public Land Mobile Network (PLMN) identifier, assigned for IOPS network operation; the IMSI, uniquely assigned for the IOPS; and the access class status 11 or 15, subject to regional / country regulatory requirements and operator policies.

Images