WO2017009714A1

WO2017009714A1 - Establishing a temporary subscription with isolated e-utran network

Info

Publication number: WO2017009714A1
Application number: PCT/IB2016/001134
Authority: WO
Inventors: Simon MIZIKOVSKY; Nagendra S BYKAMPADI; Suresh P Nair
Original assignee: Alcatel Lucent
Priority date: 2015-07-15
Filing date: 2016-07-15
Publication date: 2017-01-19

Abstract

One aspect provides a first apparatus, e.g. a privacy module of a mobile communications device (UE), configured to generate a random key. The privacy module generates, in response to a Subscribe command originating from a home subscriber server (HSS), a first encryption key from a key of a privacy module of a mobile communication device. The privacy module generates a second encryption key from said first encryption key and a timestamp. A payload of a subscription acknowledgment message from said privacy module is formed by encrypting a random key with said second encryption key. Another aspect provides a second apparatus, e.g. an HSS. The HSS is configured to receive the subscription acknowledgment. The HSS computes a decryption key from a public key of the privacy module, and decrypts a random key from the payload and the decryption key. The random key is then stored in a subscription record of the HSS.

Description

ESTABLISHING A TEMPORARY SUBSCRIPTION WITH ISOLATED E-UTRAN

NETWORK

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of Indian provisional application number 2157/DEL/2015 , filed on July 15 , 2015.

TECHNICAL FIELD

The present invention relates generally to the field of wireless communications, and, more particularly, but not exclusively, to methods and apparatus useful for establishing a temporary subscription with an isolated E-UTRAN network.

BACKGROUND

This section introduces aspects that may be helpful to facilitate a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art. Any techniques or schemes described herein as existing or possible are presented as background for the present invention, but no admission is made thereby that these techniques and schemes were heretofore commercialized, or known to others besides the inventors.

Isolated Evolved Universal Terrestrial Radio Access Network (E-UTRAN) operation for public safety is a feature being developed in the 3 GPP initiative. In an

E-UTRAN system, a number of Evolved Node-B (eNB) devices connect to an evolved packet core (EPC). The Isolated E-UTRAN operation feature, or "IOPS", is directed to addressing a scenario in which, for example, in a disaster situation a backhaul connection to the EPC core is lost for one or more eNBs. In the IOPS mode these eNBs may function as a temporary isolated network for Public Safety personnel until the back haul connection to the regular macro network is re-established. To function as a temporary network, a temporary local EPC core network including a mobility management entity (MME), serving gateway (SGW), and packet data network gateway (PGW) may provide sufficient functionality to support communication within the group of Public Safety personnel. The temporary local EPC core is also expected to support a local home subscriber server (HSS) to provide Authentication and Authorization (AA) of Public Safety (PS) user equipment (UEs). But for public safety functions encompassing a diverse group of police agencies, fire responders, medical teams, etc., possibly from different local or national jurisdictions, it is at least impractical, and perhaps not practically feasible, to create and maintain at every local E-UTRAN location a database of all PS users. Moreover, synchronization with national or regional database is also not feasible since, in the contemplated emergency situation, the backhaul connection of E-UTRAN is assumed to be lost. SUMMARY

The inventor discloses various apparatus and methods that may be beneficially applied to the creation and operation of temporary isolated E-UTRAN networks in the event of a public emergency or other event that isolates public safety terminals from a backhaul network. While such embodiments may be expected to provide improvements in performance and/or reduction of cost of relative to conventional approaches, no particular result is a requirement of the present invention unless explicitly recited in a particular claim.

This disclosure provides a method, e.g. performed by a privacy module such as a UICC of a mobile communications device, or UE. The method includes generating, in response to a Subscribe command originated from a evolved packet core (EPC) home subscriber server (HSS), a first encryption key from a key of a privacy module of a mobile communication device. A second encryption key is generated from the first encryption key and a timestamp. A payload is formed of a subscription acknowledgement message from the privacy module by encrypting a random key with the second encryption key.

Some embodiments further include directing the message to the mobile communications device. In some embodiments the privacy module key is a private key of a public -private key pair of a Universal Integrated Circuit Card (UICC). In some such embodiments the first encryption key is generated as the product of the private key and a public key of a Public Land Mobile Network (PLMN). In some embodiments generating the second encryption key includes hashing the first encryption key with the timestamp. In some embodiments the mobile communication device is configured to direct the payload to the HSS.

Some embodiments provide an apparatus, e.g. a privacy module of a mobile communications device, such a UICC, that includes a processor and a memory coupled to the processor. The memory contains instructions that when executed perform the method of any of the preceding embodiments.

Some embodiments provide another apparatus, e.g. a mobile communications device, that includes a radio-frequency transceiver and a privacy module, e.g. a UICC, configured to perform any of the methods described above. The transceiver is configured to direct a data payload, produced by the privacy module, to an HSS.

The disclosure further provides another method, such as may be performed at an HSS. The method includes receiving a message originated from a privacy module of a mobile communication device, the message including a data payload. A decryption key is computed from a public key of the privacy module. A random key is decrypted, using the decryption key, from the payload and stored in a subscription record of the HSS.

In some embodiments the public key of the privacy module is a UICC public key, and the decryption key is computed from a hash of a timestamp contained in the payload and a transient encryption key computed from the UICC public key and a PLMN private key. Some embodiments further include validating a UICC certificate contained in the payload using a stored public safety public key. Some embodiments further include validating a UICC signature contained in the payload using a trusted UICC public key.

Some embodiments provide an apparatus that includes a processor and a memory coupled to the processor. The memory includes instructions that when executed perform the method of any of the immediately preceding methods. In some such embodiments the processor and memory are components of a local isolated EPC.

Some embodiments provide a non transitory computer-readable medium containing instructions that implement one or more of any of the methods described above. BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:

FIG. 1 illustrates an embodiment, e.g. a method of establishing a temporary local subscription by a UE with an IOPS E-UTRAN and local EPC, which assumes MME capability to conduct SAKKE-based computations;

FIG. 2 illustrates a second embodiment, which assumes a local home subscriber server (HSS) conducts SAKKE-based computations;

FIG. 3 illustrates a third embodiment similar to that of FIG. 2, in which a secret subscription key K; is randomly created by the UE instead of the HSS, and is sent as a part of encrypted payload from the UE to the HSS;

FIG. 4 illustrates a fourth embodiment similar to that of FIG. 3, in which the main secret subscription key K; is pre-provisioned in advance in the IOPS-related USIM on the UICC platform, and a special PLMN-related subscription key is generated from it inside the UICC;

FIG. 5 illustrates a fifth embodiment, in which the local HSS and the UICC are both provisioned with certificates that contain their respective identities (e.g. IOPS_IMSI and PLMN_id) and their Public keys (e.g. PuUICC and PuPLMN);

FIG. 6 illustrates an embodiment of a UE that may implement one or more methods consistent with the disclosure;

FIG. 7 illustrates an embodiment of an EPC that may implement one or more methods consistent with the disclosure; and

FIG. 8-14 illustrate additional details of some steps that may be performed in one or more methods consistent with the disclosure, e.g. the methods illustrated in

FIGs. 1-5.

DEFINITIONS

In the discussion below, the following definitions apply:

AA Authentication and Authorization

AKA Authentication and Key Agreement

AV Authentication Vector CA Certificate Authority

CA_SIGN Certificate Authority Signature

eNB Evolved Node-B

EPC Evolved Packet Core

E-UTRAN Evolved UTRAN

GUTI Globally Unique Temporary Identity

HSS Home Subscriber Server

IMSI International Mobile Subscriber Identity

IOPS Isolated E-UTRAN operation

ASME Secret key derived from the result of successful AKA authentication protocol run

KDF Key Derivation Function

LTE Long-Term Evolution (3 GPP)

MME Mobility Management Entity

PGW Packet data network gateway

PLMN Public Land Mobile Network

PLMN_ID An ID of a PLMN

PS Public Safety

PrPLMN A private key associated with a PLMN

PrUE Private key of a UE

PrUICC UICC private key

PuPLMN A public key associated with a PLMN

PuUE Public key of a UE

PuUICC UICC public key

SAKKE Sakai-Kasahara Key Encryption

SGW Serving gateway

SQN Sequence Number

UE User Equipment

UICC Universal Integrated Circuit Card

USIM Universal Subscriber Identity Module

UTRAN Universal Terrestrial Radio Access Network DETAILED DESCRIPTION

Various embodiments are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be evident, however, that such embodiment(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more embodiments.

A solution to the aforementioned situation of a diverse group of emergency responders, may address one or more of the following issues:

1) A local subscription database of required public safety devices may need to be established on a per-event basis.

2) This local database may be a much smaller subset of the regional or national subscription database of all the public safety devices.

3) A dynamic synchronization of the national and local databases is not feasible since the backhaul is assumed to be lost.

4) Creation of a local subscription record for the PS personnel needs to be done in a reliable and secure manner, for the subsequent authentication and authorization in the isolated E-UTRAN network.

5) It is further assumed, without limitation thereto, that the Public Safety devices (UEs) and the isolated E-UTRAN are operating under the LTE standard. Thus it is preferred to follow the LTE AKA (authentication and key agreement) scheme for authentication and authorization of UE credentials, and follow the security key hierarchy defined for LTE security framework.

Two implementations have been proposed within standards-body working groups to solve the IOPS security problem, both of which fail to adequately address various aspects of the problem.

One such implementation is LTE AKA, as described in 3GPP TS 33.401 version 12.14.0, available at http://www.3gpp.org/DynaReport/33401.htm and incorporated herein by reference in its entirety. This implementation expects a prior offline copying of all public safety subscription records in all local subscription security databases. However, it is difficult or practically impossible to store a local copy of a national database of PS users in a reliable and secure manner in every E- UTRAN and to keep all local copies current.

Another such implementation is described in 3GPP contribution S3-151100, available at http://www.3gpp.org/ftp/tsg_saAVG3_Security/TSGS3_78_Sorrento/Docs/ and incorporated by reference in its entirety. This contribution suggests using the identity- based authentication scheme following "SAKKE" algorithms defined in IETF RFC 6507, 6508, and 6509, respectively available at https://tools.ietf.org/html/rfc6507, and https://tools.ietf.org/html/rfc6508 and https://tools.ietf.org/html/rfc6509, all of which are incorporated by reference herein in their respective entireties. This SAKKE-based authenticated key agreement would be executed for every access by each Public Safety device to the E-UTRAN with Isolated EPC, and result in establishment of the KASME secret key used subsequently for generating conventional LTE security key hierarchy. This solution is computationally heavy when executed for each access of a Public Safety mobile, considering that these mobiles would remain within the disaster area and conduct multiple accesses to the E-UTRAN for extended periods of time, e.g. until the full connectivity to the EPC is fully restored.

Embodiments described herein provide one or more solutions concerning security in temporary IOPS networks that may address some of the issues described above. In various embodiments, instead of relying on national centralized main subscription databases, a temporary local subscription is established with the IOPS local EPC, and this local subscription is used for current and subsequent access using conventional LTE authentication procedures.

Various embodiments include a two-stage process to establish security in isolated E-UTRAN networks:

In a first stage, a local EPC subscription is created for the public safety UEs either using "SAKKE" -based algorithms defined in RFC 6507 and RFC 6508, or using certificates. Public identities of the UE, such as a special IMSI used in cases of connecting to the IOPS E-UTRAN, and the E-UTRAN, such as PLMN_id, are used as a basis for deriving time-limited Public Keys. Any SAKKE-supporting node can derive a Public Key of the corresponding peer with knowledge of that peer's public identity, and a time-specific parameter (e.g. current date). Their associated private keys may be provisioned in advance by the Public Safety authorities using the Key Management System (KMS), and may be periodically updated while there is network connectivity. These public-private key pairs may be used to mutually authenticate the Public Safety UEs and the IOPS E-UTRAN, and securely establish a common secret. This common secret may then be used as a temporary security key for the subscription record in the local HSS. A corresponding record may also be created in the temporary USIM application in the UE, associated with the said special IOPS-specific IMSI.

In a second stage, after the subscription record and secret key are established for the temporary E-UTRAN identified by the specific PLMNid, regular LTE AKA as described in TS 33.401 may be performed.

When the backhaul link to the regular macro network core is re-established, the IOPS mode may be terminated. The local HSS may clean up temporary subscription records, or may retain such for some time based on a local policy in anticipation of another loss of a backhaul.

Five embodiments are now described that each illustrate various steps that may be performed by user equipment and an E-UTRAN, e.g. to establish temporary network access to PS personnel. However, it is understood that such embodiments are not limited to such use, and may employed in any appropriate wireless access system that may benefit from such described steps. Each of the embodiments includes steps carried out between a UE (User Equipment) and associated UICC (Universal Integrated Circuit Card), an MME (Mobility Management Entity) and an HSS (Home Subscriber Server), with the MME and HSS operating as a local EPC. Skilled artisans will appreciate that the EPC is a service layer above the E-UTRAN service layer in the LTE service layer hierarchy. In the following description the UE may sometimes be referred to as a "public safety" or "PS" UE. Steps involved in the described embodiments are presented with the understanding that other additional steps may be performed without going beyond the scope of the disclosure. Embodiment 1 : MME-assisted Local Subscription.

FIG. 1 illustrates a first embodiment, e.g. a method 100, that may be useful in establishing temporary local subscription of the UE with a local EPC and IOPS E- UTRAN. This embodiment assumes without limitation that the MME has the capability to conduct SAKKE-based computations.

The UE identifies an isolated E-UTRAN network by reading the IOPS-mode indication broadcasted by the network. If it doesn't have a subscription record for this temporary network, it enters into a phase to create the subscription record.

In a Step 1.1, the UE sends a 'Subscription Request' message to the MME within the isolated eNB. This message contains an identity of the PS UE such as an IOPS-specific IMSI (IOPS_IMSI), and a random nonce (token) parameter (NonceUE) generated by the UE. The IOPS_IMSI may be preconfigured in an IOPS-specific USIM of the UE. Such configuration may be reserved for public safety personnel.

Both IOPS_IMSI and NonceUE are signed as described by IETF RFC 6507 (SAKKE) using the private key of the UE (Pr_UE). Hence, the request payload is expressed as SIGN[IOPS_IMSI, NonceUEJ_fW_E.

In a Step 1.2, the MME validates the received SIGN value using the UE Public Key (PuUE) derived from the reported UE identity (IOPS_IMSI).

In a Step 1.3, the MME generates a NonceMME and a secret KEY to be used for the temporary subscription with this PLMN. The MME encrypts both parameters using the PuUE, as described in IETF RFC 6508 (SAKKE). The MME further signs the encrypted payload with its own private key PrIOPS. The MME sends a response message back to the UE containing an IOPS-MME-ID and the value

SIGN {Enc [KEY, NonceMME)^} MOPS-

In a Step 1.4, the UE validates the SIGN value in the received payload using the public key of the MME derived from the PLMN_id, and decrypts the received encrypted payload Enc(KEY, NonceMME)puUE by using its own private key to extract the KEY and NonceMME.

In a Step 1.5, two sub-steps are performed:

In a sub-step 1.5a, the PS UE generates a root key K; using KDF(KEY, NonceUE, NonceMME).

In a sub-step 1.5b, the MME also generates the root key, ¾, using KDF(KEY, NonceUE, NonceMME).

In a Step 1.6, two sub-steps are performed: In a sub-step 1.6a the UE sends its generated K; to the UICC, which includes an associated USIM application.

In a sub-step 1.6b, the MME sends its generated K; and the IOPS_IMSI received from the UE in Step 1.1 to the local HSS.

In a Step 1.7, three sub-steps are performed:

In a sub-step 1.7a, the USIM stores the K_;, and SQN=1 into the USIM associated with the preconfigured IOPS_IMSI. A separate USIM instance can be initiated for each of multiple PLMNids, each containing the same pre- provisioned IOPS_IMSI, but a different K_; and associated with a different subscription retained in a PLMN-specific local HSS.

In a sub-step 1.7b, the local HSS creates a subscription record including the IOPSJMSI, K_;, and the SQN (initialized to Ί ').

In a sub- step 1.7c, the local HSS acknowledges to the MME the creation of the subscription record. The acknowledgement includes the IOPS_IMSI of the record created by the HSS.

In a Step 1.8, the UE performs regular LTE access using the subscription record and credentials created for the temporary PLMNid. LTE AKA as described in TS 33.401 is performed and keys are computed, and a current LTE key hierarchy is established.

The method 100 may then proceed as per conventional operation.

Embodiment 2: HSS managed establishment of Local Subscription.

FIG. 2 illustrates a second embodiment, e.g. a method 200, that may be useful in establishing temporary local subscriptions for local EPC and an IOPS E-UTRAN. This embodiment assumes without limitation that the local HSS conducts SAKKE- based computations.

In this embodiment the UE has knowledge that the backhaul is severed via an

IOPS-mode indication broadcast by the system. The temporary subscription to be established by the UE may optionally be with a same PLMN_id that was previously established during full network connectivity. In this embodiment it is assumed that an

IOPS-specific USIM has previously been established. However, consistent with a conventional access request, the UE does not know whether or not this subscription is active in a local HSS associated with advertised PLMN_id. The UE reports its UE_id, for example a currently active GUTI, or IOPS_IMSI. This special IMSI is preconfigured in the IOPS-specific USIM of the Public Safety UE.

In a Step 2.1 , the UE requests access to the E-UTRAN with an Access Request message that includes its UE_id.

In a Step 2.2, if the UE provided a GUTI in Step 2.1, and the MME is not able to resolve the GUTI to the IOPS_IMSI due to severed backhaul, the MME requests and receives a new IOPS_IMSI from the UE.

In a Step 2.3, the MME requests from the HSS an Authentication Vector to authenticate the UE. The request includes the resolved or newly generated

IOPS_IMSI.

In a Step 2.4, the HSS checks its local database for the subscription associated with the IOPS_IMSI. If the record is found, the IOPS-specific temporary subscription for the UE has already being established, and the HSS computes the Authentication Vector (AV). The HSS returns the AV to the MME via a Step 2.15 to authenticate the

UE. Alternatively, if the HSS finds no HSS record associated with the IOPS_IMSI, the method proceeds to a Step 2.5 to establish a temporary subscription.

In the Step 2.5, three sub-steps are performed:

In a sub-step 2.5a, the HSS creates a random key ¾, e.g. having 128 bits, to be used for the temporary Local EPC subscription associated with the

IOPS_IMSI. The HSS also creates a random nonce N;, e.g. having 64 bits.

In a sub-step 2.5b, the HSS uses the IOPS_IMSI of the UE to generate a date-specific public key PuUE of the UE. The HSS encrypts [¾, N;] with the PuUE as described in IETF RFC 6508 (SAKKE).

In a sub-step 2.5c the HSS uses the computes the signature SIGN of the string produced by concatenating the PLMN_id with the encrypted payload. The HSS Private Key PrPLMN is used to compute the SIGN.

In a Step 2.6, the HSS responds to the MME with an AV Reject message and a command to establish a Temporary Local Subscription. The command includes an encrypted and signed payload, SIGN{PLMN_id, E(Ki,Ni)puUE }prPLMN- The encrypted and signed payload computed in the sub-step 2.5c is included in this message. In a Step 2.7 the MME forwards the encrypted and signed payload to the UE with the command to establish a Temporary Local Subscription for the IOPS_IMSI.

In a Step 2.8, three sub-steps are performed:

In a sub-step 2.8a the UE uses the PLMN_id received from the HSS via the MME in the Step 2.7 to create a date-specific public key PuPLMN for the accessed IOPS PLMN. The UE uses the PuPLMN to validate the signature SIGN of the received payload. If SIGN is validated, then the UE knows the instruction to establish a Temporary Local Subscription came from the legitimate HSS associated with the advertised PLMN_id.

In a sub-step 2.8b, the UE uses its own Private Key (PrUE) to decrypt the received encrypted payload containing the K; and N;.

In a sub-step 2.8c the UE computes its own signature SIGN of its IOPS identity (IOPS_IMSI) concatenated with the received decrypted nonce N;. The UE uses its private key PrUE to compute this SIGN.

In a Step 2.9, the UE forwards the decrypted K; to the USIM associated with the IOPS_IMSI to create the local temporary subscription USIM.

In a Step 2.10, the UE sends the Subscription Request to the MME including its IOPS_IMSI concatenated with the nonce N;, signed using private key PrUE of the UE, as computed in the sub-step 2.8c.

In a Step 2.11, the MME issues a subscription request Subscribe_RQ to the HSS, forwarding the signed payload received from the UE in the Step 2.10.

In a Step 2.12, three sub-steps are performed:

In a sub-Step 2.12a, the HSS uses the public key PuUE of the UE generated in the sub-Step 2.5b to validate the SIGN of the signed payload received in Step 2.11.

In a sub-Step 2.12b, the HSS verifies that the nonce N; from the signed payload is the same as was sent in the Step 2.6 to the UE with the command to establish the local subscription.

In a conditional sub-Step 2.12c, if the verification performed in Steps

2.12a and 2.12b is successful, the HSS creates the temporary subscription record for the IOPS_IMSI reported by the UE, in association with the K; created for this record in the sub-Step 2.5a, and an initial SQN=1. In a Step 2.13, the HSS responds to the MME with subscription response RSP indicating successful establishment of the temporary local subscription.

In a Step 2.14, the MME requests an AV from the HSS for the IOPS_IMSI, as in the Step 2.3.

In the Step 2.15, the HSS provides the AV to the MME in response to the AV.

Note that this step may be conditionally reached from Step 2.4 as previously described.

In a Step 2.16, the MME proceeds with conventional AKA authentication. Embodiment 3: HSS managed establishment of Local Subscription with UE assistance.

FIG. 3 illustrates a third embodiment, e.g. a method 300, that may be useful in establishing temporary local subscriptions with a local EPC and an IOPS E-UTRAN.

In this embodiment the secret subscription key K; is randomly created by the UE instead of the HSS, and is sent as a part of encrypted payload from the UE to the HSS.

In this case the HSS does not have to preserve the state, e.g. store the allocated ¾, until completion of subscription establishment.

Several steps of this embodiment are the same as those of Embodiment 2, but in this embodiment the UE is aware that the backhaul is severed by the IOPS mode indication broadcasted by the system. The UE temporary subscription with an IOPS-

PLMN, which may be even have been the same PLMN_id, has been established before, and an IOPS-specific USIM already exists. But the UE does not know whether or not this subscription is active in a local HSS associated with advertised PLMN_id.

Because of the similarity of steps in this embodiment to Embodiment 2, common steps are only briefly described, while steps that are different in Embodiment 3 are described in detail.

Step 3.1 : The UE sends a conventional Access Request to the MME. The UE reports its UE_id, such as either a currently active GUTI, or IOPS_IMSI.

Steps 3.2-3.4: These steps may be as described in Steps 2.2-2.4 in the method 200.

In a Step 3.5, the HSS computes the signature SIGN of the PLMN_id using the HSS Private Key (PrPLMN). In a Step 3.6, the HSS responds to the MME with an AV Reject/Subscribe message, which is treated by the MME as an indication that UE needs to establish a Temporary Local Subscription. The signed PLMN_id computed in Step 3.5 is included in the payload of this message.

In a Step 3.7, the MME sends the signed PLMN_id to the UE with a Subscribe command to establish a Temporary Local Subscription for the IOPS_IMSI.

In a Step 3.8, three sub-steps are performed:

In a sub-step 3.8a, as previously described with respect to the method 200, the UE validates the SIGN by using the Public Key of the PLMN, PuPLMN, to validate the Subscribe request received in Step 3.7.

In a sub-step 3.8b, the UE generates a random ¾.

In a sub-step 3.8c, the UE encrypts the K_; with the Public Key of the PLMN, PuPLMN.

In a sub-step 3.8d, the UE uses its own private key, PrUE, to create its own signature SIGN of its UE_id, e.g. IOPS_IMSI, concatenated with the encrypted K; created in sub- step 3.8c.

In a Step 3.9, the UE forwards to the UICC the K_; to the USIM associated with the IOPS subscription, as described with respect to the method 200.

In a Step 3.10, the UE directs a Subscription Acknowledgement message to the MME, including as the message payload the signed value computed in sub-step

3.8d.

In a Step 3.11, the MME sends a Subscription Request message to the HSS, including the encrypted and signed payload received from the UE in Step 3.10.

In a Step 3.12, three sub-steps are performed:

In a sub-step 3.12a, the HSS validates the SIGN, and if valid, the HSS is assured that subscription request is received from legitimate UE claiming to have the indicated IOPS_IMSI.

In a sub-step 3.12b, the HSS uses its own private key, PrPLMN, to decrypt the received encrypted payload and obtain the K; chosen by the UE for this temporary subscription.

In a sub-step 3.12c, the HSS creates a temporary subscription record using IOPS_IMSI, K_;, and SQN initiated to Ί '. Steps 3.13-3.15 proceed as previously described in Steps 2.13-2.15 of the method 200, and in Step 16 the MME proceeds with conventional AKA authentication. Embodiment 4: HSS managed establishment of Local Subscription with UICC assistance.

FIG. 4 illustrates a fourth embodiment, e.g. a method 400, similar to the method 300. In this embodiment the secret subscription key K; is pre-provisioned in advance in the IOPS-related USIM on the UICC platform, and a special PLMN- related subscription key K is generated from K; inside the UICC. This IOPS- subscription specific secret key K is then encrypted inside the UICC, and is sent as an encrypted payload from the UICC through the UE to the HSS. In this case the subscription key remains secret inside the UICC, and the HSS, as in the method 300, does not have to preserve the state, e.g. store the allocated ¾, until completion of subscription establishment.

Steps 4.1-4.7 are as described with respect to steps 3.1-3.7 of the method 300. In a Step 4.8, similar to Step 3.8a in method 300, the UE validates the signed PLMN_id received from the MME in Step 4.7.

In a Step 4.9, the UE initiates the Provisioning Request to the IOPS-specific USIM on the UICC. With the request, the UE sends the PLMN_id, and indicates that the SQN for this subscription is reset to T.

In a Step 4.10, two sub-steps are performed:

In a sub-step 4.10a, the IOPS USIM generates

In a sub-step 4.10b, the USIM encrypts the K with the public key of the PLMN, PuPLMN.

In a Step 4.11, the USIM returns the encrypted K , E(K ), to the UE.

In a Step 4.12, the UE uses its own private key PrUE to create its own signature SIGN of its UE_id (IOPS_IMSI) concatenated with the encrypted payload received from the USIM created in sub-step 4.10b. The signed payload containing encrypted payload with the K is sent to the MME. In a Step 4.13, the MME sends the Subscription Request to the HSS, the request containing the encrypted and signed pay load received in Step 4.12.

In a Step 4.14, three sub-steps are performed:

In a sub-step 4.14a, the HSS validates the SIGN, and if valid, the HSS is assured that subscription request is received from legitimate UE claiming to have the indicated IOPS_IMSI.

In a sub-step 4.14b, the HSS uses its own Private Key (PrPLMN) to decrypt the received encrypted payload and obtain the K chosen by the UE for this temporary subscription.

In a sub-step 4.14c, the HSS creates a temporary subscription record using IOPS_IMSI, K_; = K from the decrypted payload, and initiating the SQN to 1.

In a Step 4.15, the HSS responds to the MME with Subscription Response indicating successful establishment of the temporary local subscription.

In a Step 4.16, the MME requests an AV from the HSS, as in Step 4.3.

In a Step 4.17, the HSS responds with the AV.

In a Step 4.18, the MME proceeds with conventional AKA authentication.

Embodiment 5: HSS managed establishment of Local Subscription with UE assistance using Certificates.

FIG. 5 illustrates a fifth embodiment, e.g. a method 500, that may be useful in establishing temporary local subscriptions for local EPC and an IOPS E-UTRAN. In this embodiment, the Local HSS and the UICC are both provisioned with Certificates which contain their respective identities (PLMN_id and IOPS_IMSI), and their respective public keys (PuPLMN and PuUICC). The associated private keys are used to digitally sign the certificates presented to the peer for validation.

The certificates containing the identity, public key, and validity of the presenter are signed in advance by a higher level Root CA such as the Industry/3GPP Root key which the UE and the HSS trust. Validation by the receiving peer of the CA signature is done by using pre-provisioned Public Key of the CA (PuCA), and signifies that presented content of the certificate can be trusted. When the contents of the certificate are trusted, the presenter's ID and public key can be used by the receiver for validating and processing the information provided by the presenter.

Steps 5.1-5.4 of the method 500 are as described for the method 300.

In a Step 5.5, the HSS is provisioned with a Certificate which contains the

HSS Identity (PLMN_id), public key (PuPLMN), and Validity period of this certificate. The certificate is signed by a Higher level Root CA such as the Industry/3GPP Root key which UE trusts.

FIG. 9 illustrates aspects of the HSS certificate generation by the HSS. First, the HSS creates a public -private key pair for the PLMN. This process includes first generating a random private key PrPLMN. The HSS Public Key PuPLMN is computed as a Product of multiplication of the randomly generated and secret HSS Private Key PrPLMN by the common publicly known coordinate on an elliptic curve chosen for the IOPS application (F). That is, PuPLMN = PrPLMN*F. Given the known point of elliptic curve F and the Public Key PuPLMN it is mathematically difficult to compute the Private Key PrPLMN due to the hardness of discrete logarithm problem. The contents of the certificate are then assembled, e.g. as the concatenation of PLMN_id, PuPLMN and a validity period. This concatenated value is then signed with the CA private key, PrCA. The signed value CA_SIGN is in turn concatenated with the PLMN_id, PuPLMN and validity period to form the signed

HSS certificate.

Returning to FIG. 5, in a Step 5.6, the HSS responds to the MME with an AV Reject/Subscribe message, containing an indication to the UE that a Temporary Local Subscription needs to be established. The message contains the HSS certificate signed using the PLMN private key PrPLMN associated with the HSS Public Key PuPLMN.

The message can also contain a TimeStamp assuring replay protection.

FIG. 10 illustrates aspects of the signing of the HSS certificate by the HSS. The PLMN_id, PuPLMN, Validity and CA_SIGN fields represent the HSS certificate as shown in FIG. 9. This is in turn concatenated with a new TimeStamp for replay protection, and a message payload, and the concatenated value is signed with the private PLMN key PrPLMN. This signed value is the value signed HSS certificate sent to the MME in Step 5.6. Returning to FIG. 5, in a Step 5.7, the MME forwards the signed HSS certificate to the UE with a Subscribe command to establish a Temporary Local Subscription for the IOPSJMSI.

In a Step 5.8, the UE forwards the Subscribe command with the signed HSS certificate to the UICC/USIM Subscription along with any associated parameters.

In a Step 5.9, four sub-steps are performed:

In a sub-step 5.9a, the UICC validates the received HSS certificate using the provisioned CA Root Key (the Public Key of the CA), and uses the PuPLMN key contained in it to validate the SIGN.

Referring to FIG. 1 1 , details of the validation by the UICC/USIM of the signed HSS certificate are shown. The signed HSS certificate includes the CA_SIGN field. The UICC/USIM validates the CA_SIGN using the pre- provisioned certificate authority public key PuCA. If the CA_SIGN is valid, the UICC/USIM assumes the PuPLMN public key and the Validity value are trusted. The UICC/USIM then also validates the SIGN_PLMN value using the trusted PuPLMN key. If the validation is successful, then the UICC/USIM processes the data within the payload field.

Returning to FIG. 5, in a sub-step 5.9b, the UICC creates the random subscription key ¾.

In a sub-step 5.9c, the UICC is provisioned with a combination of a Public key and a Private key, e.g. PuUICC and PrUICC. FIG. 12 illustrates some aspects of this provisioning, without limitation. The Public Key of the UICC is pre-computed using the secret Private Key of the UICC (PrUICC) multiplied by the point on the elliptic curve publicly known and selected for the IOPS, e.g. , PuUICC = PrUICC*F. The UICC is provisioned with the UICC Certificate which contains the UICC Identity (IOPS_IMSI), its Public key (PuUICC), and Validity period. The certificate is signed by a higher level Root CA such as the Industry/3GPP Root key which UE trusts. The UICC generates the transient secret Ks that will be used to compute the key KE for encrypting the ¾. The Ks is the product of multiplication of the UICC Private Key (PrUICC) by the HSS Public Key (PuPLMN). To generate the encryption key KE the UICC computes the hash of Ks and a data string, e.g. the current TimeStamp. The UICC encrypts the K; with the resulting ¾, thereby producing the UICC payload.

Returning to FIG. 5, in a sub-step 5.9d, the UICC uses its Private Key PrUICC to digitally sign a payload string including the UICC Certificate combined with the Timestamp and encrypted UICC payload created in step 5.9c. FIG. 13 shows some details of this step, without limitation.

Referring to FIG. 5, In a Step 5.10, the UICC forwards the signed payload to the UE with a Subscribe_ACK message.

In a Step 5.11, the UE directs the Subscribe_ACK message to the MME

In a Step 5.12, the MME directs a Subscription Request Subscribe_RQ to the

HSS, including the UICC payload. This is a new Diameter transaction specific for establishment of the Temporary local subscription with the IOPS HSS.

In a Step 5.13, the HSS processes the UICC payload according to the following sub-steps. Some details of the processing are shown in FIG. 14, which may be referred to concurrently in the description of the sub-steps.

In a sub-step 5.13a, the HSS validates the UICC Certificate by verifying the CA_SIGN field of the UICC certificate using the public key of the UICC, PuUICC. If the certificate is valid, the HSS verifies the validity of the TimeStamp. If the TimeStamp is valid, the HSS validates the SIGN_UICC using the trusted PuUICC public key. If the signature is valid, the HSS is assured that subscription request is received from legitimate UICC claiming to have the indicated IOPS_IMSI.

In a sub-step 5.13b, the HSS derives the Transient Key K_s = PrPLMN * PuUICC, and the decryption key K_E = HASH(K_S, Timestamp). The HSS uses the ¾ to decrypt the received encrypted payload and obtain the K; chosen by the UICC for this temporary subscription.

In a sub-step 5.13c, the HSS creates a temporary subscription record using IOPS_IMSI, K_;, and initiating the SQN to 1.

Steps 5.14-5.17 correspond respectively to Steps 4.15-4.18 of FIG. 4, already described above.

Briefly summarizing, without limitation, the embodiments described in methods 100-500 provide for the establishment of a temporary subscription with a local isolated EPC. The embodiments described in the methods 200-500 provide a benefit of concealing the established Root Key K; from the MME, leaving the knowledge of it to only the UE/USIM and the HSS. The embodiments described in the methods 400 and 500 provide the additional benefit of concealing the established K; from the UE, and retaining it in secrecy of the UICC. This aspect complies with basic security expectations of LTE security framework. It requires, however, that encryption of the K is executed on the UICC platform. Providing that this process uses elliptic curve cryptography, it is expected to be easily handled by a modern UICC platform. The embodiments described in the methods 300-500 additionally preserve a stateless nature of the HSS operation. This removes the need for nested processes and HSS-initiated transaction, which is more in-line with some established HSS operation. The embodiment described in the method 500 relies on support of certificates and Public Key Infrastructure instead of Identity-Based cryptography. This allows provisioning a long-lived certificate in the HSS and UICC instead of time-limited Private Keys associated with these node's Identities. Frequent re- provisioning of the short-lived Identity-based Private Keys, although providing benefits of not needing revocation, may prove troublesome for managing IOPS- specific UICC. Based on these various considerations and features, the methods 400 and 500 may be preferred in some implementations, though such potential preference is not to be read as limiting the scope of the claims.

Turning now to FIG. 6, illustrated is a schematic view of an embodiment of a mobile communication device 600 that may be suitable for use as the UE or PS UE described in methods 100-500. More broadly, the device 600 may be or include a mobile phone, tablet computer, laptop computer, or any other similar computing device equipped to communicate wirelessly with an E-UTRAN network. The device

600 includes a processor and memory. The memory may contains instructions that when executed by the processor implement any of the methods 100-500 or any other method within the scope of the PS UE as described herein. The device 600 includes a transmitter and antenna to communicate with a suitable base station, e.g. a local EPC. The device 600 also includes a privacy module, e.g. a UICC, that is configured to operate according to one or more of the methods 100-500. The privacy module includes a processor and local memory (not shown) that may enable the privacy module to perform computations related to authentication of a user to a communication network, and encryption of communications. The processor, memory, transmitter, antenna and privacy module may each be implemented by any conventional or future developed devices that are configured or configurable to operate as described with respect to the methods 100-500.

FIG. 7 illustrates a schematic view of an embodiment of an evolved packet core (EPC) 700 that may be suitable for use as the MME and/or HSS described in methods 100-500. The EPC 700 includes a processor, memory, transmitter and nonvolatile database (DB). The memory may contain instructions that when executed by the processor implement any of the methods 100-500 or any other method within the scope of the MME or HSS as described herein. The EPC 700 includes a transmitter and antenna to communicate with user equipment, e.g. a PS UE such as the device 600. The database (DB) may store various parameters of interest in implementing the methods 100-500 or another method within the scope of the description. For example, the DB may store subscription records of the PS personnel granted network access in any of the methods 100-500 or any other method within the scope of the MME and/or HSS as described herein. The processor, memory, database, transmitter and antenna may each be implemented by any conventional or future developed devices that are configured or configurable to operate as described with respect to the methods 100-500. In various embodiments the EPC 700 includes an MME and an HSS. The MME and HSS may be implemented as an integrated system or as separate and distinct entities configured to communicate with each other to implement embodiments of the disclosure, e.g. one or more of the methods 100-500.

In some embodiments, the HSS retains credentials established for a PS UE or personnel base on local retention policy, e.g. in case needed for future outages. Retention of credentials may reduce computational burden on the EPC 700 in case credentialed personnel require future access, such as in the case of intermittent infrastructure failures.

Unless explicitly stated otherwise, each numerical value and range should be interpreted as being approximate as if the word "about" or "approximately" preceded the value of the value or range. It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of this invention may be made by those skilled in the art without departing from the scope of the invention as expressed in the following claims.

The use of figure numbers and/or figure reference labels in the claims is intended to identify one or more possible embodiments of the claimed subject matter in order to facilitate the interpretation of the claims. Such use is not to be construed as necessarily limiting the scope of those claims to the embodiments shown in the corresponding figures.

Although the elements in the following method claims, if any, are recited in a particular sequence with corresponding labeling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence.

Reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. The same applies to the term "implementation."

Also for purposes of this description, the terms "couple," "coupling," "coupled," "connect," "connecting," or "connected" refer to any manner known in the art or later developed in which energy is allowed to be transferred between two or more elements, and the interposition of one or more additional elements is contemplated, although not required. Conversely, the terms "directly coupled," "directly connected," etc., imply the absence of such additional elements.

The embodiments covered by the claims in this application are limited to embodiments that (1) are enabled by this specification and (2) correspond to statutory subject matter. Non-enabled embodiments and embodiments that correspond to nonstatutory subject matter are explicitly disclaimed even if they formally fall within the scope of the claims. The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those of ordinary skill in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.

The functions of the various elements shown in the figures, including any functional blocks labeled as "processors," may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, in conjunction with the appropriate computer hardware, the particular technique being selectable by the implementer as more specifically understood from the context.

It should be appreciated by those of ordinary skill in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

Although multiple embodiments of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications and substitutions without departing from the invention as set forth and defined by the following claims.

Claims

CLAIMS:

1. A method, comprising:

generating, in response to a Subscribe command originating from a home subscriber server (HSS), a first encryption key from a key of a privacy module of a mobile communication device;

generating a second encryption key from said first encryption key and a timestamp;

forming a payload of a subscription acknowledgment message from said privacy module by encrypting a random key with said second encryption key.

2. The method as recited in Claim 1, further comprising directing said message to said mobile communications device.

3. The method as recited in Claim 1, wherein said privacy module key is a private key of a public-private key pair of a Universal Integrated Circuit Card.

4. The method as recited in Claim 3, wherein said first encryption key is generated as the product of the private key and a public key of a Public Land Mobile Network.

5. The method as recited in Claim 1, wherein generating said second encryption key includes hashing said first encryption key with said timestamp.

6. The method as recited in Claim 1, wherein said mobile communication device is configured to direct said payload to the HSS.

7. An apparatus, comprising:

a processor; and

a memory coupled to the processor and containing instructions that when executed perform the method of any of Claims 1 -6.

8. An apparatus, comprising:

a radio-frequency transceiver; and

a privacy module configured to perform the method of any of Claims 1-6, wherein said transceiver is configured to direct the acknowledgment message to the HSS.

9. A non-transitory computer readable medium that contains instructions that when implemented by a processor implement the method of any one or more of Claims 1-6.

10. A method, e.g. performed at a home subscriber server (HSS), comprising:

receiving a message originated from a privacy module of a mobile communication device, the message including a privacy module payload;

computing a decryption key from a public key of the privacy module;

decrypting a random key from the payload and the decryption key; and storing said random key in a subscription record of the HSS.

11. The method of Claim 10, wherein said public key of the privacy module is a Universal Integrated Circuit Card (UICC) public key, and said decryption key is computed from a hash of a timestamp contained in said payload and a transient encryption key computed from said UICC public key and a Public Land Mobile Network (PLMN) private key.

12. The method of Claim 10, further comprising validating a Universal Integrated Circuit Card (UICC) certificate contained in said payload using a trusted UICC public key.

13. The method of Claim 10, further comprising validating a Universal Integrated Circuit Card (UICC) certificate contained in said message, and granting access by said mobile communication device to a local isolated evolved packet core (EPC) in the event that said certificate is determined to be valid.

14. An apparatus, comprising:

a processor; and

a memory coupled to the processor and containing instructions that when executed perform the method of any of Claims 10-13.

15. The apparatus of Claim 14, wherein said processor and memory are located in a local isolated evolved packet core (EPC).

16. A non-transitory computer readable medium that contains instructions that when implemented by a processor implement the method of any one or more of Claims 10-13.